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 как практическое руководство

Книга Скелтона и Пайса по сути представляет собой развёрнутое руководство по 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, документацию и платформенные инструменты.