Team Topologies, Software Architecture & Complexity • James Lewis • GOTO 2022

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

• componentization via services
• organized around business capabilities
• products not project
• decentralized governance

Дальше автор вспоминает про сложности организационного дизайна и так приходит к книге "Team Topologies", про которую у меня есть серия статей с ее обзором:

• Teams as means of Delivery
• Team Topologies that work for flow
• Evolving team interactions for innovation and rapid delivery И вспоминает он про нее в контексте фразы кого-то из Amazon "The bigger we get, the easier it becomes to get bigger" и смысл тут в том, что цель успешного орг дизайна в том, чтобы оптимизировать структуру под поток ценности, а именно это и помогает сделать подходы из team topologies. Забавно, что автор показывает как выглядит процесс создания value (на диаграммах, которые похожи на те, что остаются после Event Storming) и насколько там мало самого программирования:)

Дальше автор переходит к архитектуре программного обеспечения и как она помогает бороться со сложностью окружающего мира и наших решений, которые моделируют его. Рекомендую на эту тему почитать книгу "A Philosophy of Software Design" (у меня есть краткое саммари: 1, 2). В этой книге очень классно разбирается вопрос сложности и борьбы с ней при создании программного обеспечения. Потом автор приходит к понятию complex adaptive system (млекопитающие, города, создание софта?) и показывает какие у них бывают свойства (self-similarity, self-organization, complexity, emergence) и как там работают степенные законы для экономии на масштабе и убывающей полезности по мере масштабирования (кроме Amazon, у которой полезность не убывает - правда, это может быть связано с сетевыми эффектами многосторонних платформ, подробнее в книге "Machine, Platform, Crowd"). В итоге комплексные адаптивные системы оказываются везде вокруг нас и иерархии в них приводят к фрактальным эффектам с эффектом от масштабирования с экспонентой и числом меньше единицы в знаменателе.

После этого автор описывает корпоративный метаболизм - так как организации это тоже complex adaptive system, то по мере масштабирования у них растет количество уровней иерархии и revenue масштабируется сублинейно и метаболизм замедляется. Автор приводит прикольный пример с метаболизмом слона и мыши. Слону надо есть гораздо меньше еды в процентном соотношении от своей массы, чем мыши. Но, одновременно, у слона метаболизм настолько медленный, что он не более раком - клетки просто не успевают состариться. Похожее происходит и в крупных компаниях. Дальше автор рекомендует книгу "Accelerate", которая позволяет мониторить здоровье организации через метрики: MTTR, cycle time, change failure rate, number of deploys. В крупных организациях меньше идет бюджета на R&D, больше процессов и бюрократии, а также иерархий.

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

#TeamTopologies #Software #Architecture #SoftwareArchitecture #Management #Processes #SystemDesign