Две команды почти не взаимодействуют напрямую, но совместно реализуют одну бизнес-возможность. Какой архитектурный риск возникает по закону Конвея?
Возникает риск появления архитектурной границы, отражающей не бизнес-связность, а структуру взаимодействия команд. Части одной возможности могут оказаться разделены через интеграционные контракты, ручные согласования и координационные очереди — фактически появится распределённая связанность.
Закон Конвея описывает тенденцию, а не строгий технический закон: архитектура часто повторяет структуру коммуникаций организации. Поэтому границы команд следует проектировать вместе с границами системы.
Идея связана с наблюдением Мелвина Конвея, опубликованным в 1968 году в статье «How Do Committees Invent?». Исходная проблема заключалась в том, что структура коммуникаций между группами разработчиков влияет на структуру создаваемых ими систем.
Позднее этот принцип стали применять при проектировании команд и архитектуры: если для изменения компонента постоянно требуется согласование нескольких слабо взаимодействующих групп, система обычно получает сложную интеграционную границу.
Одна бизнес-возможность может проходить через несколько команд, каждая из которых владеет только техническим слоем: интерфейсом, бизнес-логикой, данными или инфраструктурой. Изменение такой возможности требует последовательных передач работы, синхронизации планов и согласования контрактов.
Основные последствия — увеличение времени поставки, рост числа интеграционных дефектов и размывание ответственности за бизнес-результат. При этом формальное разделение компонентов может выглядеть аккуратно, хотя фактическая зависимость между ними остаётся высокой.
Важно отличать этот риск от простой необходимости взаимодействия. Не всякая межкомандная коммуникация вредна; проблема возникает, когда частые изменения требуют постоянной координации команд, которые не имеют общего цикла поставки и общей ответственности.
Механизм работает через стоимость координации. Архитекторы и разработчики принимают решения в пределах доступных каналов коммуникации, поэтому границы компонентов часто устанавливаются там, где проходят границы команд. Если команды организованы вокруг технических слоёв, система склонна получить горизонтальное разбиение; если команда владеет сквозной бизнес-возможностью, чаще формируется вертикальный срез.
Практический способ уменьшить риск — применить обратный закон Конвея: сначала определить желаемые архитектурные границы, затем сформировать команды, чьи коммуникации поддерживают эти границы. Команда должна по возможности владеть бизнес-возможностью сквозь нужные слои и иметь право самостоятельно изменять большую часть своего решения.
Это не означает, что каждую команду нужно превращать в изолированную автономную группу. Общие платформы, архитектурные стандарты и централизованные компетенции могут быть полезны, но их интерфейсы не должны становиться обязательным маршрутом для большинства изменений бизнес-функции.
Есть и компромисс: чрезмерная автономия приводит к дублированию инфраструктуры, неодинаковым практикам и локальной оптимизации. Поэтому границы нужно проверять по фактическим потокам изменений: кто должен согласовать изменение, сколько компонентов затрагивается и какая команда отвечает за конечный результат.
В интернет-магазине команда каталога владела данными о товарах, команда цен — правилами расчёта, а команда оформления — пользовательским сценарием заказа. Для изменения отображения итоговой цены требовались согласованные релизы трёх команд, хотя для бизнеса это была одна возможность — оформление покупки с понятной стоимостью.
Рассматривались два варианта. Первый — сохранить техническое разделение и улучшить процессы согласования; это требовало меньше организационных изменений, но сохраняло очереди и общую ответственность. Второй — сформировать команду, владеющую сценарием оформления, а каталог и цены предоставить ей через стабильные автономные контракты; этот вариант требовал перераспределения ответственности, зато уменьшал число координационных зависимостей.
Выбрали второй вариант: команда оформления получила сквозную ответственность за пользовательский сценарий, а команды каталога и цен сосредоточились на собственных устойчивых возможностях. В результате изменения сценария стали чаще выполняться внутри одной команды, а межкомандные контракты изменялись реже и более предсказуемо.
1. Означает ли закон Конвея, что архитектура всегда обязана копировать структуру организации?
Нет. Это наблюдаемая тенденция, сила которой зависит от сложности системы, культуры организации, качества технических границ и зрелости инженерных практик. Хорошие контракты, автоматические тесты и сильная архитектурная координация могут ослабить влияние структуры команд, но не устраняют стоимость постоянной коммуникации.
2. Чем обратный закон Конвея отличается от простого разделения системы на команды?
Простое разделение может только перенести существующие границы организации в код. Обратный закон Конвея использует другой порядок рассуждения: сначала определяют желаемую архитектуру и необходимые независимые потоки изменений, затем под них создают команды с подходящими полномочиями и каналами коммуникации.
3. Как понять, что проблема действительно организационно-архитектурная, а не только процессная?
Нужно изучить историю изменений и зависимости между командами. Если одна бизнес-возможность регулярно требует изменений в нескольких командах, последовательных согласований и совместных релизов, а ответственность за результат разделена, проблема затрагивает границы владения. Если же команды могут независимо поставлять изменения, но задержки вызваны только ручными процедурами, сначала следует улучшить процесс, не меняя архитектуру.