← Назад к блогу

Conway’s Law: почему оргструктура протекает в архитектуру

Conway’s Law: почему оргструктура протекает в архитектуруConway’s Law: почему оргструктура протекает в архитектуру

Есть три команды.

Каждая отвечает за свою область. У каждой свои задачи, приоритеты и релизный цикл.

Через некоторое время в системе появляются три сервиса.

Между командами изменения проходят через долгие согласования. В архитектуре вырастают сложные интеграции.

Одна команда не может получить нужное изменение от другой без очереди, встречи и пары задач в Jira. Вскоре сервисы начинают зависеть друг от друга примерно так же.

Это и есть закон Конвея:

Организации проектируют системы, структура которых повторяет структуру коммуникаций внутри организации.

Архитектура возникает не только из технических решений. На неё влияют:

— границы команд; 
— ownership компонентов; 
— процессы согласования; 
— распределение экспертизы; 
— общие базы и модели данных; 
— возможность самостоятельно выпустить изменение.

Поэтому некоторые архитектурные проблемы невозможно решить одним рефакторингом.

Можно формально разделить монолит на два сервиса. Но если для любого изменения команды по-прежнему должны синхронизироваться, согласовывать общий релиз и вместе менять одну модель данных, независимости не появилось.

На диаграмме сервисы разделены.

В работе — всё ещё один распределённый монолит, только теперь ещё и с сетевыми ошибками.

Есть и обратный подход: Inverse Conway Maneuver. Если нужна определённая архитектура, границы команд сознательно выстраивают так, чтобы её поддерживать.

Например, независимому продуктовому домену нужен end-to-end ownership.

Не только backend.

Не только frontend.

Не несколько таблиц в общей базе.

Команда должна иметь возможность сама провести изменение от идеи до пользователя: изменить код, проверить его, выпустить и отвечать за результат.

Поэтому хороший system design иногда начинается не с вопроса:

«Как разделить сервисы?»

А с вопроса:

«Как между людьми разделены ответственность, решения и право на релиз?»

Нарисовать независимые прямоугольники на диаграмме легко. Сделать так, чтобы команды действительно могли менять их независимо, заметно сложнее.

Люди зачем-то продолжают участвовать в архитектуре.