Conway's Law и Inverse Conway Maneuver

Проблема: архитектура, которую никто не проектировал

В 1967 году программист и исследователь Мелвин Конвей написал статью, в которой сформулировал наблюдение, ставшее одним из самых цитируемых в индустрии: «Организации, проектирующие системы, ограничены дизайном, который копирует коммуникационные структуры этих организаций.» Звучит как академическая абстракция, но на практике это означает поразительно конкретную вещь: если у вас четыре команды, вы почти гарантированно получите систему из четырёх компонентов, причём границы между компонентами будут проходить ровно там, где проходят границы между командами, и никакие архитектурные ревью и RFC не смогут это предотвратить.

Конвей подал эту статью в Harvard Business Review, и ему отказали с формулировкой «тезис не доказан». Впоследствии Фред Брукс процитировал его в «Мифическом человеко-месяце», и наблюдение стало известно как закон Конвея. С тех пор оно подтверждалось эмпирически десятки раз — исследование Microsoft (Nagappan et al., 2008) показало, что организационная структура предсказывает дефекты в коде лучше, чем любые метрики качества кода.

Как это работает на практике

Представьте компанию, в которой есть отдельные команды фронтенда, бэкенда и мобильной разработки. Какую архитектуру они построят? Правильно — трёхслойную, с API между слоями, причём API будет спроектирован не столько из соображений удобства, сколько из необходимости формализовать коммуникацию между командами. Каждое изменение в продукте потребует координации трёх команд, потому что архитектура буквально повторяет оргструктуру.

Или другой пример: компания с офисами в Москве и Новосибирске делает один продукт. Через год окажется, что система естественным образом разделилась на два модуля — один, за который отвечает Москва, и второй, за который Новосибирск, и интерфейс между ними будет толстым и формальным, потому что коммуникация между офисами — это всегда накладные расходы.

Закон Конвея — это не какой-то дефект организаций, от которого можно избавиться, если очень постараться. Это фундаментальное свойство коммуникации: люди, которые работают близко друг к другу, создают плотно связанные системы, а люди, между которыми есть барьеры, создают системы с чёткими (и часто неудобными) границами. Это происходит неизбежно, вопрос лишь в том, осознанно вы к этому подходите или нет.

Inverse Conway Maneuver

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

Хотите перейти на микросервисы? Сначала разделите команды по доменам, а микросервисы появятся естественным образом. Хотите единую платформу? Создайте платформенную команду, и она создаст платформу. Хотите, чтобы ваш API был удобным для внешних потребителей? Выделите команду, которая будет его основным пользователем, и пусть она влияет на дизайн.

На практике всё сложнее, потому что реорганизация команд затрагивает людей, их карьеры и отношения. Но концептуально Inverse Conway Maneuver — одна из самых мощных идей в архитектуре ПО, потому что она переводит разговор из плоскости «какой фреймворк выбрать» в плоскость «как организовать работу людей».

Team Topologies как практическое руководство

Если вы уже читали главу про Team Topologies, то наверняка заметили связь: по сути, вся книга Скелтона и Пайса — это развёрнутое руководство по применению Inverse Conway Maneuver. Четыре типа команд (stream-aligned, platform, enabling, complicated-subsystem) и три модели взаимодействия — это набор строительных блоков для проектирования организации, которая будет производить нужную вам архитектуру.

Скелтон и Пайс аргументируют, что традиционный подход — сначала нарисовать архитектуру, а потом искать людей — работает плохо именно потому, что игнорирует закон Конвея. Архитектура неизбежно деформируется под давлением коммуникационных структур, и единственный способ получить желаемое — выстроить эти структуры соответствующим образом.

Примеры из индустрии

Spotify — один из самых известных примеров сознательного применения Inverse Conway Maneuver, хотя они не использовали этот термин. Их модель «squads, tribes, chapters, guilds» была спроектирована так, чтобы маленькие автономные команды (squads) могли владеть отдельными частями продукта и деплоить их независимо. Архитектура Spotify стала микросервисной не потому, что кто-то написал архитектурный RFC, а потому что оргструктура к этому подталкивала.

Netflix пошёл похожим путём: каждая команда владеет своими сервисами от начала до конца (you build it, you run it), и это привело к архитектуре из сотен независимых микросервисов с чёткими границами, потому что границы сервисов совпадают с границами команд.

Обе компании пришли к этим моделям через итерации и ошибки, и обе позднее признавали, что их модели продолжают эволюционировать.

Когда НЕ стоит бороться с законом Конвея

Есть соблазн видеть в законе Конвея только проблему, которую нужно решить, но иногда он работает в вашу пользу. Если ваша организационная структура исторически сложилась вокруг бизнес-доменов и ваши команды хорошо понимают свои домены, возможно, архитектура, которая органически выросла из этой структуры, — это именно то, что вам нужно, даже если она выглядит не так элегантно, как хотелось бы.

Попытки навязать «правильную» архитектуру вопреки оргструктуре заканчиваются тем, что новая архитектура существует только на диаграммах. Менять нужно либо и то, и другое, либо ничего.

Связь с когнитивной нагрузкой и DX

Закон Конвея объясняет, почему некоторые архитектуры ощущаются как болезненные для разработчиков — дело не в самой архитектуре, а в несоответствии между границами команд и границами системы. Когда разработчику для реализации фичи нужно понимать и изменять код, который принадлежит другой команде, написан в другом стиле и деплоится по другим правилам, когнитивная нагрузка резко возрастает, причём это именно extraneous load — нагрузка, которая не имеет отношения к самой задаче, а вызвана неудачной организацией работы (подробнее в главе про когнитивную нагрузку).

DX-подход состоит в том, чтобы сделать границы команд и системы совпадающими, а взаимодействие между ними — простым и формализованным через хорошие API, документацию и платформенные инструменты.