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

Традиционный подход

Крупные бизнес-корпорации исторически организованы как набор функциональных подразделений: финансовое, маркетинговое, операционное, HR и так далее. Возникшая необходимость цифровой автоматизации бизнес-процессов побудила компании сформировать очередное функциональное подразделение — IT-отдел. В свою очередь, IT-отдел впоследствии разделили на функциональные команды программистов, тестировщиков, системных администраторов – по принципу объединения групп специалистов, обладающих определенным набором знаний и функций. Паттерн организационного мышления просматривается довольно явно. И его устойчивость связана не столь с нежеланием прилагать усилия для анализа эффективности управления, сколь с большой инерционностью процессов и отсутствием явных вызовов, которые ставили бы успех организации под угрозу.

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

Примечание: Менталитет обособленности (a Silo Mentality) — это нежелание делиться
информацией с сотрудниками других подразделений той же организации. Такое
поведение часто приводит к снижению эффективности организации и, в худшем
случае, приводит к разрушению корпоративной культуры.

Более того, в строго функциональных подразделениях, процесс принятия решений неизбежно замедляется. Затраты на согласование рабочих графиков команд увеличиваются. Квалификация и опыт тех же тестировщиков, к примеру, нуждается в постоянном балансировании с учетом специфики, которая требуется командам разработки. Да и высокий порог входа и необходимость передачи знаний замедляют процесс: привлекаемым извне специалистам требуется постоянное переключение контекста задач для обслуживания запросов, поступающих от различных команд.
Таким образом, когда компании с традиционной организационной структурой столкнулись с необходимостью практически мгновенной реакции на вызовы, непрерывно поступающие от бизнеса, их IT подразделения оказались неспособными обеспечить эффективность решений. Стремительное эволюционирование технологий только усугубили это отставание и усложнили задачи поддержания требуемого уровня мотивации и профессионализма в выделенных, обслуживающих разработку, командах. А поскольку основной задачей IT было и есть эффективное обеспечение полного жизненного цикла автономных продуктов (в том числе, микросервисов), то стало очевидна необходимость реорганизации команд из горизонтально-ориентированных функциональных — в вертикально-ориентированные, самодостаточные и автономные команды.
?

Кросс-функциональные команды

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


Рисунок 1. Функциональные и кросс-функциональные команды.

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

Шамим Мохаммад, ІТ-директор CarMax, говорит: «В стремительно эволюционирующем мире важно создать гибкие, кросс-функциональные продуктовые команды, которые могут быстро перебирать варианты решения задачи. Они наделены всеми необходимыми полномочиями и руководство никогда не говорит им, как решить проблему, а только в чем она заключается и каковы ключевые показатели эффективности, с которыми нужно работать. Такой подход позволяет улучшить обратную связь, значительно ускорить процесс разработки, использовать метод проб и ошибок, чтобы в конечном счете найти наилучшее для клиентов и партнеров решение. Мы также обнаружили, что команды более разумно рискуют и проявляют творческий подход в достижении поставленных целей. Если у вас нет таких полностью интегрированных команд — присмотритесь и подумайте, готовы ли вы к успешной цифровой трансформации?».

Согласно опросам «Massachusetts Institute of Technology» и «Deloitte Global Human Capital Trend» компании с высоким уровнем цифровизации процессов в развитии своих инноваций чрезвычайно зависят от наличия кросс-функциональных команд. 83% зрелых компаний признают, они используют кросс-функциональные команды. Несмотря на возросшую операционную сложность (дополнительные расходы составляют до 16%), компании получили значительное улучшение операционных показателей (до 53%), усовершенствованный доступ к ресурсам и активам (до 37%), большую гибкость (до 12%) и снижение уровня избыточной бюрократии благодаря сокращению иерархии организационной структуры (до 11%).


Рисунок 2. Преимущества адаптации кросс-функциональных команд. Статистика.

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


Рисунок 3. Переход к кросс-функциональной команде.

Возникновение платформенных команд

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

• Синхронизация (согласованность) данных;
• Устаревание данных;
• Безопасность;
• Межсервисная коммуникация;
• Обнаружение сервисов;
• Распределенное логирование и мониторинг;
• Циклические зависимости между сервисами и отладка;
• Тестирование;
• Надежность и отказоустойчивость;
• Производительность.

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

Фактически, при разрастании организации, повышается уровень ее зависимости от используемых технологий. Все чаще возникают множественные области рассогласования, что приводит к потере организацией способности к быстрому продвижению на рынке, оценке появляющихся возможностей и инновациям. Возможным выходом из данной ситуации является переход к использованию «цифровой платформы», состоящей из «блоков возможностей» в важнейших областях деятельности организации (таких как инфраструктура доставки решений или взаимодействие с клиентом). Цифровые платформы позволяют минимизировать брешь между концепциями и инвестициями; повысить стабильность системы и, что еще важнее, — улучшить микроклимат внутри организации.

Многие IT организации задаются вопросом: какое количество персонала необходимо выделить для работы непосредственно над «продуктом», а какое – для работы над «платформой»? Одним из важнейших аргументов пользу подобного разделения персонала является следующий: цифровая платформа нуждается во владельцах, посвятивших себя обеспечению соблюдения принципов, декларируемых платформой, имеющих большой опыт и высокий уровень экспертизы в разработке, внедрении и сопровождении платформ.

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

Как бы ни был прост канал, он все же требует владельца. И если есть множество команд, каждая из которых «владеет своим микросервисом», тогда кто отвечает за их взаимодействие? За обнаружение сервисов, за безопасность, мониторинг на уровне целой системы (или даже на уровне организации, если речь идет о межсистемном уровне)? Кто будет ответственен за всестороннее тестирование? Если мы начнем возлагать эти обязанности на те или иные команды разработки микросервисов, то какова будет наша стратегия и критерии выбора? И, наконец, останутся ли такие команды (разработки, напомню) по-прежнему гибкими и автономными в своих продуктах? Похоже, настал момент, когда на сцене должна появиться команда разработки платформы!

Команда разработки платформы (сокращенно – платформенная команда) — это специализированная кросс-функциональная команда, которая управляет цифровой платформой – базисом для формирования API-интерфейсов, инструментария и служб, знания и поддержка которых организованы в самостоятельный внутренний продукт.

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

• Инфраструктура доставки;
• Архитектура и исправление API;
• Данные самообслуживания;
• Экспериментальная инфраструктура и телеметрия;
• Взаимодействие с клиентом.

Рисунок 4: Стратегия цифровой платформы

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

Несомненно, концепция выделенных специализированных платформенных команд обладает как преимуществами, так и недостатками:

К преимуществам можно отнести:

• унификацию и последовательность каналов коммуникации;
• обеспечение контроля при сохранении гибкости отдельных команд разработки.

К недостаткам можно отнести:

• временные затраты для адаптации стратегии в организации;
• необходимость в дополнительных ресурсах — платформенной команде требуется изучить специфику работы различных микросервисных команд, а также сформировать требования для создания унифицированной платформы;
• если платформа будет неправильно реализована, она станет «узким местом» в процессах организации.

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

Синергия взаимодействия

Итак, как же может происходить взаимодействие с платформенной командой? Существует несколько возможных подходов, среди которых можно выделить два:

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

Рисунок 5: Взаимодействие с командой разработки платформы: слева — платформа как продукт, справа — проникновение в команды.

Заключение

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

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