Компания разделила команды по техническим слоям, после чего изменения одной бизнес-функции стали проходить через множество команд. Какой архитектурный механизм объясняет этот результат?
Это проявление закона Конвея: архитектура системы склонна отражать структуру коммуникаций между командами. Если команды организованы по техническим слоям, то границы системы также часто становятся слоистыми, а изменение одной бизнес-возможности требует координации нескольких команд.
В конце 1960-х годов Мелвин Конвей сформулировал наблюдение, согласно которому организации проектируют системы, отражающие их структуру коммуникаций. Идея появилась как объяснение того, почему архитектурные решения зависят не только от технологий и требований, но и от того, кто с кем регулярно взаимодействует.
Позднее этот принцип стали применять не только для объяснения архитектурных проблем, но и для целенаправленного формирования организационной структуры под желаемые границы системы.
При организации команд по слоям одна бизнес-функция может затрагивать команду пользовательского интерфейса, команду прикладной логики, команду данных и отдельную инфраструктурную команду. Для одного изменения требуются согласование контрактов, несколько очередей задач и последовательные релизы.
Такая структура увеличивает координационную связанность: бизнес-изменение пересекает организационные границы, а архитектура начинает отражать эти границы. В результате растут время поставки, вероятность несовместимых решений и стоимость локального изменения.
Важно не трактовать закон Конвея как строгий технический закон или доказательство того, что любая слоистая команда обязательно создаст плохую архитектуру. Это эвристика о сильной взаимосвязи коммуникаций и проектных границ.
Механизм работает через каналы взаимодействия. Команда обычно оптимизирует решения внутри своей зоны ответственности и согласует с другими командами только публичные точки взаимодействия. Поэтому границы команд постепенно становятся границами компонентов, сервисов или подсистем, а интерфейсы между командами — архитектурными контрактами.
Если целевая архитектура должна быть ориентирована на бизнес-возможности, команды формируют вокруг таких возможностей: например, команда отвечает за оформление заказа от пользовательского сценария до хранения данных и интеграций. Это уменьшает число межкомандных переходов для изменения внутри возможности.
Такой подход часто называют обратным манёвром Конвея: сначала формируют организационные границы, которые должны породить желаемую архитектуру. Он не означает механического создания отдельной команды на каждый сервис. Команда должна обладать достаточной автономией, компетенциями и ответственностью за результат.
У подхода есть компромиссы. Команды по бизнес-возможностям могут дублировать инфраструктурные знания, сложнее распределять редких специалистов и поддерживать единые технические стандарты. Поэтому общие платформенные команды допустимы, если их интерфейс не превращает каждое бизнес-изменение в обязательную межкомандную координацию.
При оценке результата нужно смотреть не только на оргструктуру, но и на фактические зависимости: кто утверждает изменения, где находятся владельцы данных, сколько команд нужно для одного релиза и можно ли независимо тестировать и развёртывать часть системы.
В интернет-магазине команда интерфейсов, команда заказов и команда платежей были разделены по технологиям. Добавление нового способа оплаты требовало изменений в трёх репозиториях, согласования схемы данных и общего окна релиза. Формально компоненты были разделены, но бизнес-функция оставалась организационно распределённой.
Рассматривались два варианта. Можно было сохранить технические команды и улучшить процессы: ввести общие контракты, автоматические проверки и кросс-командное планирование. Это дешевле организационно, но сохраняет постоянную координацию. Другой вариант — сформировать команду бизнес-возможности платежей, включив в неё необходимые компетенции, а платформенную команду оставить владельцем общих инструментов. Это уменьшает число согласований, но требует перераспределения ответственности и частичного дублирования навыков.
Выбрали второй вариант, потому что основная проблема была не в отсутствии интерфейсов, а в том, что одно изменение проходило через несколько постоянных организационных границ. После изменения команда платежей получила ответственность за собственный поток изменений, а взаимодействие с заказами осталось через явно определённый контракт. Результатом стало уменьшение межкомандных зависимостей, но не исчезновение всех интеграционных рисков.
Нет. Организационная структура влияет на архитектуру, но не определяет её полностью. Нужны также явные границы ответственности, устойчивые контракты, владение данными, автоматические проверки зависимостей и архитектурные решения, поддерживающие независимое изменение.
Если команда формально отвечает за бизнес-возможность, но для каждого изменения обязана обращаться к нескольким владельцам общих библиотек или баз данных, фактическая архитектура останется связанной. Поэтому проверять нужно реальные потоки изменений и коммуникаций, а не только названия команд.
Она превращается в крупный узел коммуникаций и сама становится источником связности. Внутри команды может исчезнуть локальная автономия, а изменения разных возможностей начнут конкурировать за один цикл планирования, тестирования и поставки.
Границы следует выбирать по согласованности изменений, ответственности и объёму работы, а не по формальному правилу одна команда — один сервис. Иногда одна команда разумно владеет несколькими небольшими возможностями, если они тесно связаны и могут развиваться без чрезмерной координации.
Нужно посмотреть, где возникает стоимость изменения. Если изменение требует участия нескольких команд из-за распределённой ответственности, разных процессов согласования и отсутствия единого владельца результата, вероятна организационная причина. Если же одна команда может независимо менять компонент, но его интерфейс слишком широк, нестабилен или протекает внутренними деталями, основной дефект находится в архитектурном контракте.
На практике причины могут сочетаться: организационное разделение порождает неудобную границу, а неудобная граница затем закрепляет необходимость постоянного взаимодействия. Поэтому полезно анализировать одновременно карту команд, зависимости компонентов, владельцев данных и историю изменений.