Спиральная динамика архитектур и закон Конвея

Закон Конвея

Закон Конвея: "Организации проектируют системы, которые копируют структуру коммуникаций в этой организации".

Мартин Фаулер отмечает, что невнимание к закону Конвея может искажать архитектуру системы. Если архитектура разработана вразрез со структурой организации-разработчика, то в структуре ПО возникают противоречия. Взаимодействие модулей, которое изначально задумывалось как простое, становится сложным, поcкольку команды, ответственные за него, плохо взаимодействуют друг с другом. Полезные альтернативные варианты проектирования даже не рассматриваются, потому что необходимые группы разработчиков не общаются друг с другом.

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

Выходит, нужно проектировать не только архитектуры, но и структуру коммуникаций. Причем можно сначала прикинуть архитектуру согласно функциональным и нефункциональным требованиям, а затем выстроить подходящую проекту структуру коммуникаций. Очевидно, что организационная структура компаний не меняется по щелчку пальцев, есть корпоративная культура, "то, как тут всё устроено". Желательно вооружиться неким системным видением оргструктуры бизнеса, чтобы уметь эффективно выполнять обратный маневр Конвея.

Спиральная динамика для бизнеса

Одной из самых проработанных систем, упорядочивших структуру и динамику бизнес-организаций, является адаптация спиральной динамики к современным компаниям (см. книгу Спиральная динамика для бизнеса).

Необходимо отметить, что это не строгая научная теория. Скорее, набор психологических паттернов поведения, типичных для различных корпоративных ситуаций. Но и сам по себе закон Конвея соединяет два сущностно различных мира: мир человеческих коммуникаций и мир технологической архитектурной строгости. Это как пытаться соединить застольную беседу и теорему Ферма. И тем не менее, связь существует, ведь именно люди делают проекты, и именно из-за их несогласованности зачастую рушатся системы. Наверняка проблема исчезнет, когда AI начнет создавать сложные распределенные системы от первичной диаграммы до автотестов, но пока в разработке участвуют люди, они привносят неустранимый фактор межличностного взаимодействия.

Базовая гипотеза такова, что у организаций лучше получаются системы, которые соответствуют их доминирующему уровню в спиральной динамике для бизнеса (далее СДБ).

Организационно-коммуникационная структура диктует каким должен быть проект, а выбранная в самом начале технологическая архитектура может этому образу совершенно не соответствовать. Если проект требует технологической архитектуры более высокого СДБ-уровня, нежели текущий, то лучше сначала поднять уровень бизнеса, а затем реализовывать проект.

Если бизнес игнорирует закон Конвея, то возникает драма несовпадения организационной и технологической архитектур. Если реальный СДБ-уровень ниже, чем уровень технологической архитектуры проекта, то бизнес будет неосознанно разрушать её, низводя до своего уровня. Если выше, то будет поднимать через серии рефакторингов.

Уровни СДБ

Подробнее об уровнях СДБ можно прочитать в книге. Здесь же приведем только необходимый минимум.

Большинство организаций находятся на красном, синем и оранжевом уровнях.

Принципы СДБ

Взяты отсюда.

1. Доминанта. В организации, как правило, нет единой цельной культуры, но всегда есть доминирующая культура, которая задает принципы управления организацией.

2. Конкурентоспособность. Нет плохих или хороших типов культур. Есть конкурентоспособные и неконкурентоспособные культуры.

3. Последовательность. Развитие корпоративной культуры происходит последовательно, нельзя "перепрыгнуть" через уровень.

4. Фундамент. Новый уровень корпоративной культуры внедряется за счет хорошо работающих инструментов предыдущего уровня - эти инструменты являются фундаментом для следующего уровня.

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

6. Препятствие. Те принципы, за счет которых корпоративная культура развивалась и становилась сильнее, через какое-то время становятся главным препятствием, разрушающим организацию.

7. Фон. При переходе к новому типу корпоративной культуры старый тип никуда не девается, а остается в организации как вполне обыкновенное и всем привычное явление (фон), являющее основой для остальных типов культур.

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

9. Мимикрия. Организация может деградировать (мимикрировать) на ниже находящиеся уровни культуры вследствие непрохождения кризисов. Причем может "проваливаться" сразу на два уровня вниз. Например, это может произойти из-за того, что старые проверенные инструменты предыдущих уровней развития оказываются незаслуженно забытыми.

10. Лидерство. Для развития организации лидер должен находиться на 0,5-1 уровень выше, чем культура организации. Развитие корпоративной культуры организации происходит только за счет улучшения менеджмента лидеров организации.

Наблюдения о связи СДБ и архитектур

Стеклянный потолок. Организационно незрелая компания не способна перейти на более высокий технологический уровень, поскольку не видит преимуществ. Техлиды могут по собственной инициативе переходить на более высокие СДБ-уровни и внедрять соответствующие архитектуры только при молчаливом согласии начальства, которе не до конца понимает смысл реформ, но по какой-то причине лояльно к ним.

Конфликт двух миров. Флуктуации корпоративных культур и переходы между СДБ-уровнями индивидуальны для каждой компании. Нет общей тенденции к тому, чтобы каждый бизнес неизбежно выходил на синий, затем на оранжевый, затем на зеленый уровень и выше. В то время как IT-архитектуры во всем мире имеют перманентную тенденцию к усложнению, что создает потребность в соответствующей корпоративной культуре. Получается, архитектура тянет за собой культуру, если претендует на то, чтобы быть полноценно реализованной.

Матрешка. СДБ-уровни вкладываются друг в друга как матрешка, то есть следующий уровень не отменяет, а вбирает в себя всё лучшее с предыдущих. Подобных эффект справедлив и для эволюции архитектур. Лучшие практики и фреймворки остаются как база, но к ним добавляются те, что соответствуют вызовами более высоких уровней СДБ.

Естественный маппинг СДБ на архитектуры

Ниже, попытка указать какие архитектурные практики наиболее естественны для каждого СДБ-уровня. Это не значит, что маппинг жёсткий, на любом уровне можно внедрить любую архитектуру, но не факт, что она приживется.

Бежевый уровень

Структура коммуникаций отсутствует, равно как и разделение ответственности.

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

Риски: хардкод, спагетти-код, анти-паттерны проектирования.

Пример: Proof-of-Concept для проверки имеет ли идея право на жизнь.

Фиолетовый уровень

Структура коммуникаций хаотична, "кажется Вася делал эту фичу, но это не точно".

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

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

Могут ли на фиолетовом уровне быть внедрены микросервисы? Безусловно, может быть внедрено что угодно, но нет никакой гарантии, что кто-нибудь будет следовать чужим подходам.

Риски: высокая связность кода (high coupling), каждое серьёзное изменение требует структурного и функционального рефакторинга.

Пример: крупная legacy-система, которая не планирует расширение.

Красный уровень

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

Доминирует централизованное управление системой, здесь всё полностью зависит от характера и квалификации первого лица. Архитектурно это не обязательно монолит, но точно появится централизованный блок управления, который соответствует видению мира боссом (по его воле или даже вопреки ей). Никто не заботится о качестве кода, модульности и отказоустйчивости, если только босс специально не обратит на это внимание.

Пример: Имел возможность наблюдать такую ситуацию в одной из компаний с ярко выраженным красным контуром управления, которая внедрила микросервисы и обобщенные библиотеки для использования на многих проектах. Как оказалось, каждая из них содержала не только обобщенный код, но и хардкод, специфичный для отдельных систем. Просто некому было закрыть технический долг и выполнить декомпозицию, поскольку все решения принимал один человек, который "знает лучше". Модель управления была такой, что руководитель лично оценивал загрузку сотрудников и тасовал их между проектами в обход тимлидов. Если бы у проектов были по-настоящему самостоятельные лиды, то они не допустили бы загрязнения своего кода логикой чужих проектов.

Документация, как и на фиолетовом уровне, по-прежнему только в головах, но теперь преимущественно в одной единственной.

Риски удобно классифицировать согласно PAEI модели менеджмента Адизеса:

• P доминанта - сиюминутные решения, сопротивление инновациям, как следствие рост техдолга, появление единой точки отказа

• A доминанта - забюрокраченность, отсутствие Agile/Lean, сопротивление инновациям, как следствие рост техдолга и низкая адаптивность системы

• E доминанта - рисковые необоснованные решения, система развивается слишком быстро и в непредсказуемых направлениях, архитектура не успевает адаптироваться

• I доминанта - функциональные и нефункциональные требования подчинены удобству работы команд (это тот случай, когда можно завести микросервисы под команды, чтобы они не поругались, но при этом могут игнорироваться DDD, нагрузка, потоки данных)

Пример: стартап, построенный вокруг компетенций CTO и CEO в одном лице.

Синий уровень

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

На этом уровне естественна работа по стандартам: Twelve-Factor App, шаблоны проектирования, чёткие согласованные API и протоколы взаимодействия, Service Oriented Architecture, Reactive Manifesto, шины событий, версионирование, CI/CD пайплайны, SDLC, zero-trust.

При доминанте синего уровня организация довольствуется текущем уровнем автоматизации. Отсутствуют или ограничены механизмы внедрения инноваций, способные преодолеть бюрократию. Маловероятны масштабные рефакторинги.

Agile и Scrum не настроены по-настоящему итеративно, надежность системы важнее и достигается через бюрократический запрет слабопредсказуемых изменений. Рано или поздно всё скатывается в waterfall разработку с редкими и крупными релизами.

Риски: забюрокраченность, отсутствие инноваций, тяжёлая waterfall разработка.

Пример: мобильный клиент для крупного банка-монолиста.

Оранжевый уровень

Структура коммуникаций матричная, с горизонтальными (кросс-функциональные команды) и вертикальными (отделы) связями.

Это высоко конкурентная среда, которой свойственны меритократия и соперничество автономных команд (you build it, you run it).

Именно на этом уровне микросервисы становятся естественной архитектурной базой, повторяющей топологию команд. Вводятся чёткие API контракты как язык взаимодействия между командами.

Появляется реальная потребность в модульной low-coupling архитектуре, Agile и Scrum истинно итеративны, регулярно закрывается техдолг, культура роста проявляется в том, что инновации внедряются регулярно и через бэклог, появляются IaaS/PaaS/SaaS/DaaS (Data-as-a-Service).

Именно на этом уровне внедрение SRE практик становится необходимостью, появляются четкие метрики производительности, трассировка, наблюдаемость. нужно уметь эффективно измерять не только успех, но и конкуренцию. Система оптимизируется под метрики бизнеса и масштабирование. На более низких уровнях SLO/SLA могут не быть четко артикулированы, там систему нужно "просто сдать”, “просто не уронить”, “просто поддерживать".

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

Пример: корпорация уровня Amazon или Netflix со множеством подсистем и внутренне конкурирующих продуктов.

Зеленый уровень

Структура коммуникаций одноранговая сетецентричная.

Цель такой системы - поддерживать миссию компании. Базовая клиентоориентированность диктует потребность в по-настоящему гибкой и адаптируемой архитектуре.

Здесь естественны Event-Driven Architecture, Data Mesh (Data as a Product), Service Mesh (Data Plane + Control Plane), Event Sourcing, платформы управления API (типа WSO2), FinOps.

Система строится скорее вокруг потоков данных, нежели функций. Создаются платформенные команды (Platform Engineering), обслуживающие продуктовые.

"Миссия" самой системы может заключаться в высокоуровневой оркестрации процессов посредством раздачи инструкций о реконфигурации системы (policy-as-code). Программное ядро оформляется в IDP (Internal Developer Platform) - параметризованный расширяемый фреймворк с достаточным количеством степеней свободы, чтобы у миссии компании было пространство для манёвра.

Риски: если компания слишком часто меняет направление, то это приводит к архитектурным пивотам, что парализует стратегическое планирование и в конечном итоге хаотизирует архитектуру.

Пример: Spotify с моделью Squads.

Жёлтый и бирюзовый уровни

Структура коммуникаций "нейрональная", а именно:

• децентрализация управления,

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

• динамические Ad-hoc команды, создаваемые специально под задачу,

• высокий EQ и культура взаимодействия инженеров,

• компетентность ценится выше должности.

Здесь естественны эволюционная архитектура (Evolutionary Architecture), базовая децентрализация процессов и точек управления (например через блокчейн, Edge Computing), Serverless подход. Система должна быть фундаментально устойчива к сбоям (Chaos Engineering) и изменениям требований. Появляется потребность в self-healing.

Это пожалуй первый уровень, где действительно к месту роевой интеллект AI агентов как точек принятия локальных решений с возможностью эволюционного трансформирования системы. Всё, что было до этого, может обойтись и без AI агентов. На красном уровне есть только один агент - начальник. На синем разлилось царство согласованных инструкций, там не потерпят AI-галлюцинаций в стратегических вопросах. На оранжевом уровне могут применить агентов в погоне за улучшенными метриками, но это же и рискованно, когда требуется гарантированный результат. На зеленом уровне миссия диктует решения. Желтый же уровень в силу своей высокой базовой адаптивности не боится ошибок и сбоев в подсистемах. Возможно, настоящий self-healing подход будет реализован именно через агентов.

Риски: сложно достигнуть и ещё сложнее удержаться.

Примеры: желтая - Google и Googleyness, бирюзовая - Valve (по крайней мере согласно их Handbook for new employees).

Выводы

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

Во-первых, стейкхолдеры должны об этом знать.

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