Коротко о Team Topologies

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

К своей радости познакомился с некоторым количеством паттернов, о которых только слышал или не слышал вообще. Один из последних - Team Topologies. О нем, а скорее о причинах возникновения класса Socio-Technical oriented patterns в computer scince.

Цель статьи, дать еще один аспект виденья проблематики при работы с ИТ-архитектурой.

Дисклеймер.

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

Socio-Technical oriented patterns:

1 .Человеко-ориентированный подход

Учитывает когнитивные способности людей

Фокусируется на взаимодействии между командами

Рассматривает команды как ключевые элементы системы

2. Социотехническая интеграция

Объединяет социальные и технические аспекты

Учитывает как человеческие, так и технологические факторы

Обеспечивает баланс между ними

3. Системный подход

Рассматривает организацию как целостную систему

Анализирует взаимосвязи между компонентами

Учитывает влияние структуры на процессы

Причины возникновения.

Впомним о главных препосылках, что такое быть архитектором и двинемся дальше.

Рассмотрим причины возникновения с разных сторон.

1. Организационные причины.

Уже давно (по меркам ИТ) мы живем в мире гибких методологий разработки. Те самые гибкие методологии дают возможность поставлять изменения быстро с короткими фазами эволюции решений. Так же, они "из коробки" подразумевают некоторое пренебрежение точностью планирования на длинную перспективу. За счет этого, объем погрешности при достижении крупных целей возрастает, особенно в крупных организациях с разветвленной структурой формирования ценностей. Это приводит к неизбежным проблемам масштабирования гибких методологий (agile-фреймворков) в крупных организациях.

Дополнительные следствия:

• Сложность управления техническими задачами
• Проблемы координации в больших командах
• Сложность определения зависимостей в бизнес-среде
• Определение зон ответственности

Если организация длительное время живет в гибких методологиях, возможно размытие ответственности, целей и бэклога до степени, в которой поставка практически может остановиться.

Я буду не прав, если не вспомню существующие корпоративные фреймворки, такие как Lees и SAFe, но они решают проблемы частично. Без сквозной мотивации, по моему мнению, первый не работает. А по поводу второго, у меня напрашивается вьетнамский флэшбэк: RUP забыли - RUP вспомнили, чуть докрутили и вуаля - назвали масштабируемым фреймворком гибкой разработки.. Простите.

При всем, что я написал выше, не в коей мере не считаю, что agile есть альтернатива.

Вопросы мотивации.

Ключевой частью agile-фреймворков служит мотивация и осознание поставляемой ценности.

Если вы разрабатываете бизнес-продукт, вы ориентированы на метрики этого продукта, формируемые аудиторией продукта же. Если вы работаете в команде технической поддержки, то вы ориентированы на SLA и KPI клиентов и ваша задача сократить количество обращений через, например. инструменты самообслуживания и надежность обслуживаемых систем (привет SRE).

И это самое главное в Team Topologies, при разработке архитектуры решения или ландшафта, вы должны понимать топологию команд их цели, от этого напрямую зависит качество, скорость и работоспособность решения.

2. Технические предпосылки.

В числе которых:

• Рост сложности программных продуктов.
• Ускорение темпов разработки.
• Распределенные команды.

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

У нас достаточно давно появились сервисные продукты, не несущие прямой ценности, но поддерживающие ИТ-ландшафт как сервисные составляющие, например: ESB, BPM-платформы, оркестраторы, Data-lake и так далее. Кстати все перечисленное - антипаттерны. но об этом не сейчас и не здесь.

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

Все системы на картинке завязаны на бэклог корпоративной шины данных (ESB)

Что это все значит? Распределение функциональности по системам зависит должно происходить с осторожностью: чем больше сервисных систем, тем сложнее управлять поставкой общей ценности.

При выделении сервисных функций, нужно понимать capacity команд, которые будут эти функции развивать.

3. Рыночные предпосылки.

• Высокая конкуренция
• Динамичность рынка
• Сложность продуктов

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

Где-то на стыке рыночных предпосылок и организационных существует дублирование функций. Отдельные организационные юниты в большой компании могут пытаться задублировать функционал в своих продуктах. Это обуславливается сложностью коммуникаций (синхронизацией бэклогов), желанием обогатить свой продукт дополнительными привлекательными функциями. Но это неизбежно ведет к нереальному повышению Coupling'а и снижению Cohision, а мы помним из предыдущих статей, что это очень и очень плохо и ведет к фатальным последствиям.

4. Социальные предпосылки.

Потребность в баллансе:

• Между автономией команд и централизованным управлением
• Между специализацией и универсальностью
• Между скоростью разработки и качеством продукта

Человеческий фактор:

• Необходимость учета когнитивных ограничений
• Важность создания комфортной рабочей среды
• Потребность в профессиональном развитии

Тут просто все, команда работает быстрее, если она ни от кого не зависит (уууу и тут Coupling). Человек работает быстрее если они занимается своей работой. Пирамида Маслоу работает, человек находясь в комфортной среде сконцентрирован на своей деятельности, а не на достижении комфорта.

На этом тут все.

Резюмируя по предпосылкам.

Имеем:

• Сложность в коммуникациях
• Дублирование функций
• Размытие ответственности
• Сложность координации работ
• Задержки в принятии решений
• Снижение эффективности работы
• Стремление человека к комфортной среде
• необходимость в балансе в управлении

Что такое Team Topologies

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

Стоит оговориться, что как бывает с многими современными подходами, из-за team topologies торчат уши Domain Driven Design. Эванс и в особенности Вон Вернон достаточно жирно осветили важность паттернов интеграции с проекцией на команды. Господа Мэтью Скелтон и Мануэль Паис, выпустив свой труд «Team Topologies: Organizing Business and Technology Teams for Fast Flow». в 2019 году дистиллировали интеграционные паттерны выделив вопросы командного взаимодействия и топологии организационной структуры.

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

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

Как она решает описанные выше проблемы?

Решение технологических проблем

Team Topologies эффективно справляется с ростом сложности программных продуктов за счет четкого разделения ответственности между различными типами команд. Специализация потоковых и платформенных команд позволяет концентрироваться на конкретных технических задачах, при этом обеспечивая необходимую экспертизу в сложных подсистемах.

Преодоление организационных ограничений

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

Адаптация к рыночным вызовам

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

Устранение проблем существующих подходов

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

Работа с социальными аспектами

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

Интеграция методологических подходов

Методология органично встраивается в современные практики DevOps, поддерживая непрерывную поставку ценности. Она естественным образом сочетается с микросервисной архитектурой, предлагая аналогичную модульность в организации команд. При этом Team Topologies развивает принципы Agile, добавляя необходимую структурированность и ясность в процессы организации работы.

Применение Team Topologies.

ТТ наиболее эффективна в уже сформированной организационной структуре, когда нужно восстановить или улучшить поток ценности, поставляемый разработкой. Но

Далее я не буду цитировать Мэтью и Мануэля, а постараюсь ограничиться абстрактным примером.

Конечной целью является формирование команд объединенных одним потоком ценностей и масштабирование их по доменам. При этом, команды не разделены на бизнес и технические. Смысл заключается в вовлеченности и как следствие, понимании роли каждого человека в команде, потоке (value stream) и организации.

Для этого мы:

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

2. Определяем типы команд:

• Потоковые команды - команды специализированные на конкретных рабочих потоках, ориентированные на быструю разработку (поставку ценности), обеспечивающие непрерывную поставку
• Команды сложных подсистем - команды работающие над технически сложными компонентами, обладающие глубокой экспертизой в определенных областях, обеспечивающие надежность ключевых подсистем. Пример: геоинформационная система в логистической компании.
• Платформенные команды - команды создающие и развивающие обую технологическую платформу, разрабатывают инструменты и сервисы для других команд, оптимизируют процессы разработки. Как пример: ABS или кредитный конвейер в банке, PMS в гостиничном бизнесе, devops-платформа, частное облако.
• Команды поддержки - обеспечивающие работу других команд, в том числе, команды поддерживающие инновации в организации. Например: неожиданно, техническая поддержка или RND подразделение.

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

3. Определяем паттерны взаимодействия между командами.

К таким паттернам относятся:

• Collaborate & Amplify (Совместная работа и усиление) — это паттерн, при котором команды работают вместе над общими целями, обмениваются знаниями и усиливают друг друга. Команды активно взаимодействуют, проводят совместные ретроспективы, обмениваются экспертизой и помогают друг другу решать сложные задачи. Такой подход особенно эффективен между потоковыми командами и командами сложных подсистем.
• X-As-A-Service (X-как-сервис) — паттерн, при котором одна команда предоставляет другим командам определенные сервисы или платформы. Платформенные команды создают и поддерживают инфраструктуру, инструменты и сервисы, которые другие команды могут использовать как готовые решения. Это снижает когнитивную нагрузку на команды и позволяет им сосредоточиться на своих основных задачах.
• Facilitate (Содействие) — паттерн, в котором команды поддержки помогают другим командам развиваться и преодолевать препятствия. Они предоставляют обучение, консультации, инструменты и методики, необходимые для успешной работы. Этот паттерн часто используется между командами поддержки и другими типами команд.
• Coordinate (Координация) — паттерн, при котором команды согласовывают свои действия для достижения общих целей. Потоковые команды координируют свои усилия с командами сложных подсистем и платформенными командами, чтобы обеспечить бесперебойную поставку ценности. Этот паттерн помогает избежать дублирования усилий и обеспечивает эффективное взаимодействие.

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

4. Обязательные ритуалы и синхронизация команд.

• Регулярные синхронизации являются ключевым элементом взаимодействия между командами. Они включают в себя периодические встречи для обмена информацией о текущем состоянии проектов, обсуждения возникающих проблем и планирования дальнейших действий. Такие встречи помогают поддерживать единый темп работы и обеспечивают своевременное выявление потенциальных проблем.
• Совместные ретроспективы проводятся для анализа прошедшего периода работы и выявления возможностей для улучшения процессов. Команды собираются вместе, чтобы обсудить успехи и неудачи, поделиться опытом и выработать совместные решения по оптимизации рабочих процессов. Это способствует укреплению взаимодействия между командами и повышению общей эффективности.
• Планирование потоков представляет собой процесс координации работы между потоковыми командами и командами поддержки. Команды согласовывают свои планы, определяют приоритеты и устанавливают временные рамки для выполнения задач. Это помогает избежать конфликтов в ресурсах и обеспечивает плавный поток работы.
• Демонстрации результатов проводятся для представления достижений команд заинтересованным сторонам. Такие мероприятия позволяют получить обратную связь, скорректировать направление работы и убедиться в соответствии результатов ожиданиям. Они также способствуют укреплению доверия между командами и заказчиками.
• Кросс-функциональные сессии организуются для обмена знаниями и опытом между специалистами разных областей. Эти мероприятия помогают командам развивать необходимые навыки и компетенции, а также способствуют созданию общей базы знаний в организации.
• Мониторинг метрик включает регулярный анализ показателей эффективности работы команд. Команды отслеживают ключевые метрики, такие как скорость доставки, качество продукта и удовлетворенность клиентов, что позволяет своевременно выявлять отклонения и принимать корректирующие меры.

Перед тем как поставить точку, еще раз акцентирую важность для управления архитектурой понимания паттерна ТТ:

Для корпоративной архитектуры

• Оптимизация организационной структуры позволяет создать более эффективное взаимодействие между подразделениями. Четкое разделение ролей и ответственностей между различными типами команд способствует устранению дублирования функций и повышению общей производительности. Это особенно важно для крупных организаций, где необходимо обеспечить согласованную работу множества команд.
• Масштабируемость решений обеспечивается за счет модульного подхода к организации команд. Каждая команда может развиваться независимо, при этом сохраняя целостность всей системы. Это позволяет организации гибко реагировать на изменения рынка и масштабировать успешные практики.
• Управление сложностью становится более эффективным благодаря специализации команд. Потоковые команды фокусируются на доставке ценности, команды сложных подсистем решают технические задачи, а платформенные команды обеспечивают необходимую инфраструктуру. Такой подход позволяет управлять сложностью на разных уровнях архитектуры.
• Понимание влияния. Даже без целенаправленного применения ТТ, степень сложности имплементации решения можно оценить исходя из понимания типа команд и протекания потока ценности через сценарии и команды. Это, в свою очередь, дает возможность осознанной оптимизации принимаемого архитектурного решения.

Для solution архитектуры

• Улучшение качества решений достигается через специализацию команд на конкретных областях. Команды сложных подсистем могут углубляться в технические детали, создавая надежные и эффективные решения, в то время как потоковые команды концентрируются на быстрой доставке функционала.
• Ускорение разработки обеспечивается за счет четкого разделения ответственности и оптимизации взаимодействия между командами. Платформенные команды создают общие решения, которые могут использоваться всеми командами, что сокращает время на разработку типовых компонентов.
• Повышение надежности системы достигается благодаря тому, что каждая команда отвечает за свою область компетенции. Специализированные команды могут поддерживать и улучшать качество критически важных компонентов, а платформенные решения обеспечивают единый уровень качества инфраструктуры.
• Гибкость архитектуры поддерживается через паттерны взаимодействия между командами. Возможность быстрого изменения структуры взаимодействия позволяет адаптироваться к новым требованиям без существенной перестройки всей системы.

Ну и все вот это вот позволяет избегать коррупции архитектуры, о которой писал ранее.

На этом все, надеюсь, было полезно. Спасибо за прочтение.