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