Что такое закон Конвея

Закон Конвея описывает связь между устройством организации и устройством систем, которые эта организация создаёт.

В упрощённой формулировке:

Архитектура системы воспроизводит структуру коммуникаций между людьми, которые эту систему создают.

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

Если две команды вынуждены постоянно согласовывать изменения через формальные интерфейсы, approvals и очереди задач, похожая граница постепенно появляется и в программной системе.

Если одна команда контролирует всю систему целиком и ежедневно работает внутри общего контекста, архитектура обычно содержит меньше организационно обусловленных границ.

Закон Конвея поэтому говорит не просто об архитектуре.

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

Откуда появился закон

Наблюдение сформулировал программист и исследователь Мелвин Конвей в 1967 году в статье How Do Committees Invent?.

Конвей заметил, что организация, проектирующая систему, ограничена собственной способностью коммуницировать.

Люди не проектируют систему из некоторой нейтральной внешней позиции.

Они работают внутри конкретной структуры:

между ними существуют определённые каналы коммуникации;
у них разные руководители;
у них разные области ответственности;
они находятся в разных командах;
они используют разные процессы;
между ними существуют административные и технические границы;
одни решения они могут принимать самостоятельно, а другие требуют согласования.

Эти ограничения начинают отражаться в создаваемой системе.

Организационная форма постепенно превращается в техническую форму.

Почему закон Конвея вообще работает

Архитектура возникает не только из технических решений

Можно представить архитектуру как результат чистого инженерного проектирования:

сначала архитектор определяет идеальную структуру системы, затем команды её реализуют.

На практике причинность часто работает в обе стороны.

Архитектура определяется не только требованиями системы, но и тем, кто способен принимать какие решения и кто с кем способен эффективно взаимодействовать.

Представим две команды.

Команда A отвечает за платежи.

Команда B отвечает за заказы.

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

Появляются:

Orders Service
      |
      | API
      v
Payments Service

API здесь является не только технической границей.

Он одновременно является организационной границей.

Через него взаимодействуют две разные группы людей.

Коммуникация создаёт архитектурные границы

Каждая коммуникация имеет стоимость.

Разработчик внутри своей команды может написать коллеге сообщение:

Я меняю этот объект, посмотри, пожалуйста.

Если тот же вопрос требует взаимодействия с другой командой, появляется дополнительная структура:

Developer
    ↓
Team Lead
    ↓
Product / Planning
    ↓
Other Team Lead
    ↓
Other Developer

Даже если реальный процесс менее формален, межкомандное взаимодействие почти всегда дороже внутрик командного.

Возникает естественное давление:

уменьшить количество взаимодействий между командами.

Одним из способов становится создание стабильных технических интерфейсов.

Поэтому организационная граница постепенно превращается в API, сервис, компонент, библиотеку, очередь или другой технический контракт.

Архитектура является картой коммуникационной стоимости

Из закона Конвея можно сделать более сильный вывод.

Архитектура системы частично показывает, где организации дорого коммуницировать.

Рассмотрим систему:

Frontend
   |
   v
Backend API
   |
   +-------> Payments
   |
   +-------> Catalog
   |
   +-------> Notifications

Можно предположить, что за этими компонентами стоят разные области ответственности.

Но обратное утверждение делать автоматически нельзя.

По архитектуре нельзя достоверно восстановить организацию.

Однако если границы компонентов постоянно совпадают с границами команд, это уже значимый организационный сигнал.

Пример: функциональные команды

Представим организацию, где существуют отдельные команды:

Frontend Team
Backend Team
Database Team
QA Team
DevOps Team

Тогда даже один бизнес-сценарий проходит через несколько организационных единиц.

Например:

Пользователь оформляет заказ

Для реализации функции могут понадобиться:

Frontend Team
      ↓
Backend Team
      ↓
Database Team
      ↓
QA Team
      ↓
DevOps Team

Функциональность движется горизонтально через организацию.

Архитектура постепенно начинает отражать эту структуру:

UI Layer
   ↓
Backend Layer
   ↓
Database Layer
   ↓
Infrastructure

Здесь технические слои совпадают с организационными слоями.

Это классическое проявление закона Конвея.

Пример: продуктовые команды

Теперь организация меняет структуру.

Появляются команды:

Checkout Team
Catalog Team
Search Team
Account Team

Каждая команда получает специалистов разных профилей.

Например:

Checkout Team

Frontend
Backend
QA
DevOps capability
Product

Теперь коммуникационная граница проходит не между технологиями, а между бизнес-функциями.

Архитектура начинает двигаться в ту же сторону:

Checkout Service
Catalog Service
Search Service
Account Service

Организация изменила коммуникационную структуру.

Следом изменилось давление на архитектуру.

Закон Конвея и микросервисы

Микросервисную архитектуру часто описывают технически:

независимый deployment;
отдельное хранение данных;
API;
fault isolation;
независимое масштабирование.

Но у микросервисов существует ещё одно важное свойство.

Микросервис может быть границей организационной автономии.

Команда получает возможность:

планировать
→ разрабатывать
→ тестировать
→ deploy
→ эксплуатировать

свою часть системы без постоянной координации с другими командами.

Поэтому микросервисная архитектура тесно связана с организационным устройством.

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

Получается распределённый монолит.

Распределённый монолит как организационная проблема

Представим микросервисы:

A → B → C → D → E

Для реализации одной функции нужно изменить:

Service A
Service B
Service C
Service D

И каждым сервисом владеет отдельная команда.

Тогда одна задача превращается в цепочку зависимостей:

Team A
  ↓
Team B
  ↓
Team C
  ↓
Team D

Даже если технически система состоит из микросервисов, организационно она остаётся сильно связанной.

Архитектура не дала автономии.

Она только превратила внутренние вызовы программы в сетевые вызовы между сервисами.

Закон Конвея и зависимости

Для Engineering Lead здесь появляется важный инструмент диагностики.

Если задача постоянно требует участия нескольких команд, вопрос должен звучать не только:

Почему эта задача такая сложная?

Но и:

Почему ответственность за один результат распределена между несколькими организационными единицами?

Например:

Feature X
 ├── Team A
 ├── Team B
 ├── Team C
 └── Platform Team

Это означает, что delivery зависит от четырёх независимых источников capacity.

Теперь срок определяется не только объёмом работы.

Он определяется:

очередями каждой команды;
приоритетами каждой команды;
доступностью людей;
согласованием контрактов;
последовательностью изменений;
интеграцией;
тестированием;
deployment coordination.

То есть организационная структура сама создаёт delivery risk.

Чем больше организационных границ проходит задача, тем дороже изменение

Можно условно представить изменение как граф:

Requirement
    ↓
Team A
    ↓
Team B
    ↓
Team C
    ↓
Team D
    ↓
Production

Каждая граница добавляет потенциальную стоимость:

coordination
waiting
negotiation
handoff
context transfer
integration
priority conflict

Поэтому одна из задач Engineering Lead заключается не только в управлении работой внутри команды.

Он должен видеть топологию зависимостей между командами.

Закон Конвея и ответственность

Представим компонент, за который одновременно отвечают три команды.

Team A
Team B
Team C
   ↓
Shared Component

У каждой команды есть право изменять компонент.

Но ни одна не отвечает за его состояние целиком.

Возникает размытая ответственность.

Типичные последствия:

технический долг копится;
изменения конфликтуют;
никто не владеет roadmap компонента;
инциденты передаются между командами;
решения принимаются локально;
архитектурная целостность разрушается.

Поэтому техническая граница должна соотноситься с границей ответственности.

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

Но организация должна уметь ответить:

Кто обладает полномочиями принимать решение и кто отвечает за последствия этого решения?

Закон Конвея и ownership

Ownership часто воспринимают как административную запись:

Service A → Team Alpha

Но настоящее ownership означает способность команды управлять жизненным циклом системы.

Команда должна быть способна:

менять код;
изменять архитектуру;
deploy;
наблюдать production;
расследовать инциденты;
управлять техническим долгом;
определять технические ограничения;
принимать связанные с компонентом решения.

Если команда отвечает за сервис, но deployment контролируется другой командой, инфраструктура третьей, данные четвёртой, а архитектурные решения утверждает пятая, ownership становится частичным.

И снова архитектура начинает отражать эту организационную раздробленность.

Закон Конвея и архитектурные зависимости

Архитектурная зависимость часто является отражением организационной зависимости.

Например:

Team A → Service A → Service B ← Team B

Если Team A не может доставить функциональность без изменений Service B, возникает dependency.

Она существует одновременно на двух уровнях:

Технический уровень

Service A зависит от Service B

Организационный уровень

Team A зависит от Team B

Поэтому нельзя полноценно управлять архитектурными зависимостями, рассматривая только код.

Нужно смотреть на систему людей, полномочий и ответственности.

Закон Конвея и границы bounded context

В Domain-Driven Design существует понятие bounded context.

Это граница, внутри которой понятия и модели имеют определённое значение.

Например:

Ordering
Payments
Shipping
Identity

Такая архитектурная граница особенно хорошо работает, когда совпадает с границей ответственности команды.

Например:

Payments Team
      ↓
Payments Bounded Context

Команда может самостоятельно развивать свою модель.

Если же один bounded context разделён между пятью командами, каждое изменение модели становится координационной задачей.

Закон Конвея и Platform Engineering

Отдельный интересный случай возникает с platform-командами.

Платформа создаётся для уменьшения количества взаимодействий между продуктовой командой и инфраструктурными специалистами.

Без платформы может существовать схема:

Product Team
    ↓
Infrastructure Team
    ↓
Security Team
    ↓
Operations Team

Каждый deployment требует коммуникации.

Platform Engineering пытается превратить эти взаимодействия в продуктовый интерфейс:

Product Team
      ↓
Developer Platform
      ↓
Infrastructure

То есть платформа фактически компилирует организационную коммуникацию в технический интерфейс.

Ручной запрос:

"Создайте мне Kubernetes namespace"

превращается в:

platform create environment

Часть межкомандной коммуникации исчезает.

Это один из наиболее практических примеров применения закона Конвея.

Обратный манёвр Конвея

Если организационная структура влияет на архитектуру, появляется логичный вопрос:

Можно ли специально изменить организацию так, чтобы получить нужную архитектуру?

Да.

Эта идея называется Inverse Conway Maneuver, или обратным манёвром Конвея.

Логика следующая.

Допустим, компания хочет получить архитектуру:

Orders
Payments
Shipping
Catalog

Тогда можно построить команды примерно вокруг этих границ:

Orders Team
Payments Team
Shipping Team
Catalog Team

Теперь коммуникационная структура организации начинает поддерживать требуемую архитектуру.

Архитектура через организационный дизайн

Получается необычная последовательность.

Обычная логика:

Architecture
    ↓
разделяем работу между командами

Обратный манёвр Конвея:

Desired Architecture
      ↓
Team Topology
      ↓
Communication Structure
      ↓
Architecture reinforced by organization

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

Закон Конвея не означает полного детерминизма

Закон Конвея не утверждает:

структура организации
=
архитектура системы

Он описывает давление.

На архитектуру одновременно воздействуют:

доменная модель;
технические ограничения;
история системы;
требования;
инфраструктура;
производительность;
безопасность;
доступные технологии;
организационная структура.

Поэтому правильнее мыслить так:

Organization structure
        ↓
communication constraints
        ↓
coordination cost
        ↓
architectural pressure

Именно последний переход особенно важен.

Организация не механически копируется в код.

Она создаёт силы, под воздействием которых определённые архитектурные решения становятся дешевле, удобнее или вообще возможными.

Почему закон Конвея особенно важен для Engineering Lead

Engineering Lead работает на границе нескольких систем:

People
Process
Architecture
Delivery
Organization

И одна из наиболее опасных ошибок заключается в рассмотрении этих систем независимо.

Например:

У нас архитектурная проблема.

Но причина может находиться в структуре ответственности.

Или:

Команды плохо координируются.

Но причина может находиться в архитектуре, требующей постоянной синхронизации.

Engineering Lead должен видеть причинную цепочку:

организационная структура
        ↓
коммуникации
        ↓
зависимости
        ↓
архитектурные границы
        ↓
delivery
        ↓
качество и скорость изменений

Практический пример

Допустим, существует процесс регистрации клиента.

Для него нужны:

Frontend Team
Identity Team
Billing Team
CRM Team
Platform Team

Каждая команда имеет собственный backlog.

Product Manager спрашивает:

Почему изменение формы регистрации занимает три недели?

Если смотреть только на объём кода, ответ кажется странным.

Работы может быть всего два дня.

Но реальный путь изменения выглядит так:

Frontend
   ↓
Identity
   ↓
Billing
   ↓
CRM
   ↓
Platform
   ↓
Integration testing
   ↓
Release

Время разработки:

2 дня

Время системы:

3 недели

Разница возникает из коммуникационных и организационных зависимостей.

Это уже не проблема производительности отдельного разработчика.

Это свойство системы delivery.

Что должен увидеть Lead

Lead не должен спрашивать только:

Как заставить команды работать быстрее?

Сначала нужно увидеть структуру.

1. Где проходит ответственность?

Кто отвечает за результат целиком?

2. Где находятся зависимости?

Какие команды нужны для изменения?

3. Какие зависимости являются необходимыми?

Например, реальная доменная связь.

4. Какие зависимости созданы самой организацией?

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

5. Можно ли передать capability внутрь команды?

Например:

Product Team
+
deployment capability
+
testing capability
+
observability capability

6. Можно ли заменить коммуникацию контрактом или платформой?

Например:

request to Platform Team

заменяется:

self-service platform API

Закон Конвея как инструмент диагностики

Если в системе существует странная архитектурная граница, полезно спросить:

Какая организационная структура существовала, когда эта граница появилась?

Например:

UserService
AccountService
ProfileService
IdentityService
CustomerService

Каждый сервис выполняет очень похожую функцию.

Почему существует пять сервисов?

Возможный ответ:

Когда-то существовало пять разных команд.

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

Организации уже может не существовать.

Но её форма продолжает жить в коде.

Архитектура хранит историю организации

Это важное следствие закона Конвея.

Код хранит не только технические решения.

Он хранит историю:

бывших команд;
прошлых реорганизаций;
старых зон ответственности;
конфликтов полномочий;
прежних продуктовых границ;
исчезнувших платформ;
временных организационных решений.

Поэтому некоторые архитектурные решения невозможно понять, рассматривая только текущую структуру компании.

Нужно знать историю.

Реорганизация не меняет архитектуру мгновенно

Представим:

Team A
Team B
Team C

объединили в:

Product Team

Организационная граница исчезла.

Но технические границы:

Service A
Service B
Service C

остались.

Поэтому после реорганизации может возникнуть возможность упростить архитектуру.

Раньше три сервиса были способом независимой работы трёх команд.

Теперь эта причина исчезла.

Но техническая форма продолжает существовать.

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

И обратная проблема

Иногда организация меняется, а архитектура остаётся прежней.

Получается рассогласование:

New Organization
        ≠
Old Architecture

Тогда новая команда формально отвечает за результат, но постоянно пересекает старые архитектурные границы.

Это создаёт:

лишние dependencies;
coordination overhead;
unclear ownership;
cross-team changes;
slow delivery.

Поэтому организационный redesign без архитектурного redesign может дать очень ограниченный эффект.

Главное различение

Закон Конвея часто пересказывают слишком поверхностно:

Команды создают системы похожими на себя.

Это слишком слабая формулировка.

Более полезная причинная модель выглядит так:

Организация задаёт структуру коммуникаций
        ↓
структура коммуникаций задаёт стоимость координации
        ↓
стоимость координации создаёт давление на границы ответственности
        ↓
границы ответственности закрепляются в технических интерфейсах
        ↓
архитектура начинает отражать организацию

То есть ключевым механизмом является стоимость координации.

Практический вывод для Team Lead и Engineering Lead

При анализе архитектуры нужно смотреть не только на компоненты.

Нужно одновременно рисовать две карты.

Техническая карта

Service A
   ↓
Service B
   ↓
Service C

Организационная карта

Team A
   ↓
Team B
   ↓
Team C

А затем накладывать их друг на друга.

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

Если одна команда способна выполнить изменение внутри собственной области ответственности:

Requirement
    ↓
Team
    ↓
Implementation
    ↓
Production

delivery становится значительно более автономным.

Вопрос, который стоит задавать постоянно

При любой архитектурной или организационной границе полезно спрашивать:

Эта граница существует потому, что её требует предметная область, или потому, что так устроена наша организация?

Иногда ответ будет:

И то и другое.

Именно такие границы обычно наиболее устойчивы.

Но если техническая граница существует только потому, что много лет назад две группы сидели в разных департаментах, её стоит поставить под сомнение.

Краткая формула

Закон Конвея можно свести к цепочке:

Structure of organization
        ↓
Structure of communication
        ↓
Structure of coordination
        ↓
Structure of ownership
        ↓
Structure of software

Поэтому организационный дизайн и архитектурный дизайн нельзя считать независимыми дисциплинами.

Меняя границы команд, организация меняет силы, формирующие архитектуру.

Меняя архитектурные границы, организация меняет необходимость коммуникации между командами.

Это две стороны одной системы.

Для Engineering Lead

Практическая ценность закона Конвея не в том, чтобы однажды запомнить фразу Конвея.

Она в способности увидеть за технической проблемой организационную причинность.

Когда изменение требует пяти команд, это не просто неудобство процесса.

Когда один сервис принадлежит трём командам, это не просто проблема ownership.

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

Когда deployment требует отдельной команды, это не просто DevOps-процесс.

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

И поэтому Engineering Lead проектирует не только код и не только работу людей.

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