Как следствие Конвейса разрушает вашу организацию данных
У закона Конвея есть дурное следствие, которое остается незамеченным в мире разработчиков, но разрушает вашу организацию данных.
«Вы думаете, что это взлом, но все, что вы взламываете, - это ценность ваших данных». (автор)
Мелвин Конвей, блестящий ученый-компьютерщик, который также изобрел понятие сопрограммы, за последние 20 лет стал довольно известным благодаря закону, названному в его честь:
«Любая организация, разрабатывающая систему (в широком смысле), создаст проект, структура которого является копией коммуникационной структуры организации».
Оказывается, это очень важно, поскольку мы движемся к миру доменно-ориентированного проектирования и микросервисных архитектур. Закон также может быть применен с помощью так называемого обратного маневра Конвея. Но его закон также имеет последствия для мира данных, которые, как правило, не приносят удовольствия.
Вернемся немного назад ...
Закон Конвея подразумевает следствие Конвея
Недавно я заметил кое-что, что связано с этим законом. Мне нравится называть это «следствием Конвея», хотя я почти уверен, что это очень распространенная вещь.
Проще говоря, если ваш отдел разработки предоставляет людям инструмент для именования списков песен, но не предоставляет им возможности для добавления ярлыков / категорий, люди начнут использовать это имя, чтобы делать что-то обычное в их «реальном мире». домен. Они будут использовать имя «X-my-song-list» для обозначения устаревших списков и «JAZZ-my-song-list» для обозначения категорий и так далее и так далее.
В более общем плане ...
«Люди будут адаптировать явные системы, которые они получили, чтобы они соответствовали неявным концепциям реального бизнеса».
Звучит банально, что-то вроде обходного пути. Но эти «неявные концепции» имеют ужасные последствия для информационных организаций этого мира. Эти неявные концепции вполне подходят, если они не важны. Но когда они становятся важными, мир данных рушится ...
Почему следствие Конвейса так плохо для организаций, работающих с данными
Проблема в том, что ценность данных лежит в сфере бизнеса, а не в технической сфере. В нашем примере со списком песен некоторые типичные приложения для обработки данных представляют собой механизм рекомендаций для списков песен или данные внутри инструмента bi для оценки внедрения функции.
Так что же будет? Специалисты по работе с данными, вероятно, воссоздают бизнес-концепцию «ярлыков / категоризации» и извлекут ее из имен. Механизму рекомендаций он понадобится для исключения архивных списков, системе бизнес-аналитики он понадобится для группировки по категориям.
Хуже того, в этом случае две сущности будут реализовывать эту логику.
Проблема в том, что если этот контекст важен в деловом мире, «спазмы» будут расти; При каждом повторном использовании концепции списка песен две группы данных должны будут адаптировать свое понимание этого «неявного бизнес-контекста».
Что нам с этим делать? Мы создаем контекст!
Решение действительно простое: вы либо создаете новый ограниченный контекст, либо помещаете его в тот, который у вас уже есть. Технически это тоже довольно легко сделать, нужно просто наклеить где-нибудь обертку и что-то подделывать, пока не получишь.
В нашем примере, кто бы ни отвечал за домен списка песен / песен, таким образом, создает небольшую заглушку, которая на основе именования предоставляет две простые метки:
- Категория по первому слову,
- и флаг архива на основе ведущего сертификата X.
Вот и все. Когда-нибудь в будущем эта команда предметной области сможет реализовать фактические метки и внести простые и надежные изменения в оболочку, в то время как механизмы рекомендаций и система бизнес-аналитики будут продолжать работать.
Проблема? Это выходит за рамки организации данных
Во-первых, это происходит постоянно. Особенно, когда группы разработчиков повторно используют технические концепции, они иногда забывают неявные концепции, которые будут ограничены техническими концепциями. И это приводит к дилемме:
- для команды разработчиков это «просто техническая концепция», а не бизнес-концепция,
- но для мира данных это становится бизнес-концепцией из-за следствия Конвея.
Нет простого способа решить эту дилемму, кроме как осознать. Архитекторам следует внимательно следить за этими вещами. В этом случае всегда рекомендуется создавать оболочки, которые хотя бы инкапсулируют концепцию. Группы данных также могут создать такую оболочку на своей стороне, чтобы хотя бы сделать проблему прозрачной.
И, наконец, на мой взгляд, самый простой выход из дилеммы - это иметь внимательных менеджеров по продукту. Потому что, если новая функция / продукт начинается с вопроса «зачем мне это делать? И как мне узнать, что я двигаюсь в правильном направлении? », Ответ почти всегда будет включать данные и правильный контекст.
