Закон Конвея (Conway’s Law) имеет большое значение для понимания тех сил, что возникают при формировании команд, и того результата, который они могут оказать на команды в условиях длительного и автономного, неуправляемого и некорректируемого воздействия. И, как следствие, для понимания влияния на разрабатываемые командами программные продукты, поскольку за последнее время они стали более сложными и взаимосвязанными, чем когда-либо прежде. Выдержал ли закон об архитектуре программного обеспечения, сформулированный Мелвином Конвеем в далёком 1968 году, проверку временем?
Короткая справка:
В конце концов, разработка ПО прошла немалый путь: микросервисы, облака, контейнеры, бессерверные технологии. Такие новшества могут помочь командам совершенствоваться на локальном уровне, но чем крупнее организация, тем труднее становится извлечь все плюсы. То, по какому образу и подобию создаются и затем взаимодействуют команды, часто основано на прошлых проектах и/или прежних технологиях, связанных с подходами к формированию организационной структуры компании, которым может исполниться уже не один десяток лет.
Современная трактовка закона – “Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации” (по версии Рут Малан). Она напоминает нам, что организация находится в определённых рамках и вынуждена создавать проекты в определённых границах, которые соответствуют реальной, сложившейся структуре коммуникаций в организации. И это имеет стратегические последствия для любой компании, занимающейся разработкой программных продуктов – создаваемых собственноручно или посредством поставщиков.
Например, организация, структура которой представлена разрозненными функциональными блоками или “колодцами” (команды специализируются на определенной функции: обеспечение качества, администрирование баз данных, обеспечение безопасности и т.п.), вряд ли когда-либо создаст программные продукты, хорошо спроектированные под архитектуру потока. Точно так же компания, которая сформирована в основном вокруг каналов продаж для разных географических регионов, вряд ли сможет создать эффективную архитектуру, которая будет предоставлять множество различных сервисов по всему миру.
Сложившаяся структура коммуникаций внутри компании ограничивает типы решений, которые она может разработать. И это можно использовать в стратегических интересах. Если мы хотим воспрепятствовать возникновению определенных видов проектов — возможно, тех, которые слишком сосредоточены на технических моментах, – мы можем постараться изменить саму структуру организации.
Точно так же, если мы хотим, чтобы компания открыла для себя новые подходы (например, гибкие подходы к разработке) и приняла их, тогда мы можем задаться целью перестроить её определённым образом, чтобы это произошло. Конечно, нет никакой гарантии, что компания примет эти новые подходы, но, по крайней мере, сознательно формируя определённые планы коммуникаций, мы делаем это более вероятным. Формирование организационной структуры с использованием закона Конвея становится ключевым стратегическим направлением деятельности, которое может значительно ускорить открытие и принятие организацией более эффективных подходов к разработке программного обеспечения и помочь избежать менее эффективных.
Чтобы увеличить шансы организации на создание отличных программных продуктов с целевой “поточной” архитектурой, можно использовать инверсию закона Конвея, чтобы перенастроить взаимодействие команд до начала разработки. Да, вначале можно увидеть неприятие и отказ, но при наличии достаточной силы воли со стороны руководства и вовлечённости команд этот подход точно сработает.
Согласно закону Конвея, прежде, чем организовывать и собирать команды, нужно понять, а какая архитектура необходима. В противном случае сложившаяся структура коммуникаций и система мотивации в компании “задавят” планируемую архитектуру и будут определять архитектуру программного обеспечения на основе устоявшихся шаблонов. Формирование команд – это первые наброски будущей архитектуры.
Для создания быстрого и надёжного потока изменений необходимо обратить пристальное внимание на состав команд и спроектировать архитектуру программного обеспечения в соответствии с ним. Базовым звеном в конвейере поставки является команда, поэтому архитектура должна обеспечивать и поддерживать прохождение потока внутри каждой команды. Это означает, что мы можем следовать проверенным передовым практикам в области архитектуры программного обеспечения:
- Low Coupling (низкая связанность) и High Cohesion (высокое зацепление) – шаблоны проектирования, которые нужно рассматривать вместе. Компоненты в системе не имеют сильной зависимости от других компонентов, при этом компоненты содержат связанную бизнес-логику
- Совместимость версий
- Межкомандное тестирование
- На концептуальном уровне архитектура программного обеспечения должна походить на те потоки изменений, которые она обеспечивает; вместо множества взаимосвязанных компонентов следует проектировать потоки возникающих изменений поверх базовой платформы.
Создавая среду по размерам команд, мы помогаем достичь того, что называют “архитектурой причастности“. Такая архитектура способствует лёгкости вовлечения и понимания за счёт ограничения размера модулей и простоты участия за счёт минимизации изменений в подходе. Иными словами, нужна архитектура программного обеспечения, ориентированная на команды, которая максимизирует способность людей работать с ней.
На практике, проектирование структуры организации и разработка программного обеспечения – две стороны одной медали, и обе они должны выполняться одной и той же компетентной группой людей. А насколько хорошо отдел кадров осведомлен о разрабатываемых программных продуктах? Знают ли руководители организации, решающие, как распределять бюджет между командами, о вероятных последствиях своего выбора для жизнеспособности архитектуры программного обеспечения? По сути, нужно привлекать технических специалистов к проектированию организации, поскольку они понимают ключевые концепции дизайна программного обеспечения, такие как API и интерфейсы, абстракция, инкапсуляция и т.д.
Закон Конвея говорит, что структура организации и сложившиеся коммуникации между командами переносятся и отражаются в итоговой архитектуре разработанных программных продуктов. И они сводят на нет все попытки разработать архитектуру программного обеспечения отдельно от формирования самих команд. Выводы из этого простого закона далекоидущи. С одной стороны, имеющийся организационный дизайн ограничивает количество возможных подходов для выбора архитекутры. С другой стороны, на скорость доставки программного обеспечения сильно влияет то, сколько взаимосвязей между командами существует в компании. Поток требует уменьшения количества коммуникаций между командами. Да, совместная работа команд важна в “серых областях” разработки, где для прогресса необходимы обмен опытом при поиске решений проблем. Но в областях, где преобладает исполнение, коммуникации становятся лишними накладными расходами.
Одним из ключевых подходов к достижению целевой архитектуры программного обеспечения (и связанных с этим преимуществ, таких как скорость поставки или время восстановления после сбоя) является формирование таких команд, которые ей соответствуют. Принимая во внимание влияние закона Конвея при планировании архитектур и / или реорганизации команд, вы можете воспользоваться выводами из него и попытаться достичь максимального сближения архитектуры программного продукта и структуры команд в компании.
