Архитектуру часто обсуждают так, будто она существует отдельно от компании. Есть сервисы, базы, API — и есть организационная структура с отделами и руководителями.
На практике эти две карты постоянно влияют друг на друга. Команды чаще меняют то, чем они владеют. Между отделами появляются интерфейсы, согласования и зависимости. Внутри одной команды связь обычно проще.
Эту связь обычно описывают через закон Конвея.
Какую проблему мы решаем
Если одна бизнес-функция проходит через пять команд, то даже небольшое изменение может превратиться в координационный проект.
И наоборот: если команда отвечает за законченный кусок продукта и владеет большей частью нужной технологии, изменения проходят быстрее и с меньшим количеством передач.
Закон Конвея полезен не как теория, а как напоминание: границы команд со временем становятся границами системы.
Что получает бизнес
Главная бизнес-выгода от правильного сочетания архитектуры и структуры команд — меньше координационной стоимости.
Когда одна команда может довести изменение от идеи до продакшена без очереди из согласований, сокращается время выхода функций и легче понимать, кто отвечает за результат.
Это особенно важно при росте компании. Добавление людей само по себе не ускоряет разработку, если любое решение всё равно требует синхронизации нескольких подразделений.
Хорошая организационная граница даёт бизнесу не только понятный ownership, но и более независимый темп изменений.
Что получает команда
Команда получает ясную область ответственности и меньше ежедневных зависимостей от соседей.
Архитектурные интерфейсы начинают совпадать с реальными договорённостями между людьми: кто меняет контракт, кто отвечает за данные, кто принимает решение при сбое.
Но если провести границы слишком жёстко, команды могут начать оптимизировать только свой участок и создавать лишнее дублирование.
Что получает клиент
Клиент выигрывает косвенно: изменения быстрее доходят до продукта, а ответственность за проблемы меньше размывается между подразделениями.
Но клиенту не важно, как называется команда. Если организационная структура заставляет его проходить через несвязанные процессы и разные правила, внутренняя оптимизация компании становится его проблемой.
Чем мы за это платим
Цена — необходимость проектировать не только систему, но и взаимодействие людей.
Иногда для хорошей архитектуры приходится менять ownership, состав команд или зоны ответственности. Это гораздо сложнее, чем нарисовать новый технический diagram.
Есть и риск сделать обратную ошибку: начать перестраивать организацию исключительно под текущую архитектуру, хотя сама архитектура уже устарела.
Когда закон Конвея особенно важен
Он становится заметен, когда компания растёт, появляются независимые продуктовые направления, микросервисы или platform teams.
Если каждое изменение требует участия одних и тех же центральных людей, проблема может быть не только технической — возможно, границы ответственности просто не соответствуют границам продукта.
Что стоит спросить перед решением
- Сколько команд нужно для одного типичного продуктового изменения?
- Кто отвечает за результат целиком, а не за отдельный технический компонент?
- Совпадают ли границы сервисов с реальными зонами ownership?
- Где чаще всего возникают очереди согласований?
- Не пытаемся ли мы решить организационную проблему очередным техническим слоем?
В итоге
Закон Конвея говорит о простой вещи: архитектура — это ещё и карта коммуникаций внутри компании.
Для бизнеса важно не только как разделена система, но и позволяет ли структура команд менять эти части независимо. Иначе техническая модульность остаётся на схеме, а не в скорости компании.