Андрей Трушкин - Архитектура цифрового мира

Рисунок 13. Применение микросервисной архитектуры,

продуктового подхода и EDA распределенной командой

разработки

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

Каждый продукт представляет самодостаточную ценность для клиента, поэтому команды, создающие соответствующие продуктовые решения, могут независимо взаимодействовать с клиентами, представителями заказчика и иными заинтересованными лицами, демонстрируя результаты своей работы и получая необходимую обратную связь. При этом команды выбирают решения по структуре своих продуктов таким образом, чтобы исключить зависимость от контрагентов. Платформа событийного обмена, как отмечалось ранее, носит технический характер (в отличие от ESB решений), а потому необходимые настройки уровня хранения и передачи событий могут осуществляться членами команд, например, DevOps-инженерами. Ранее отмечалось, что различные продуктовые команды могут работать в соответствии с собственными моделями данных, не осуществляя синхронизацию последних между собой. На Рисунке 13 данная возможность проиллюстрирована наличием микросервисов «Клиент» в каждой продуктовой области. Поскольку речь идет о разных продуктах, то и команды, их создающие, развивают структуры данных и методы их обработки независимо друг от друга.

Отметим также, что бизнес-процессы обработки заявок на различные продукты могут содержать много общих (с точки зрения структуры бизнес-процесса) элементов. Кредитных продуктов и электронных банковских гарантий это касается в полной мере. Поэтому целесообразно выделить блок управления бизнес-процессами, конкретные элементы которых могут исполняться микросервисами различных продуктовых областей, при общей структуре самих шаблонов процессов. Взаимодействие посредством событийного обмена вносит свою долю независимости в данное решение. Добавим, что на Рисунке 13 само решение по управлению бизнес-процессами представлено обезличено, поскольку конкретика данного вопроса будет рассмотрена в соответствующем разделе.

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

Особого внимания заслуживает тот факт, что для приведенной организации работ первичными являются не управленческие решения (которые также имеют место, пусть и не в столь явном качестве, как в традиционной парадигме), а архитектурные. Соответствующим образом формируются и требования к работе архитектора. Корректным образом спроектированная архитектура решения, задание ключевых направляющих дальнейшего развития и расширения, предоставление адекватного поля самоорганизации командам позволяют существенно повысить эффективность разработки новых информационных систем, а также составляющих их продуктов. Вместе с тем, ошибка, допущенная на этапе проектирования и не выявленная на ранних стадиях работ, может вернуть создаваемое ИТ-решение к ситуации Рисунка 12: распределенные команды начинают зависеть друг от друга, критически растут риски процесса создания решения, цепочка разделения труда оказывается неустойчивой. Данный пример является наглядной иллюстрацией ранее заявленного тезиса: при упрощении разработки каждого отдельного программного компонента сложность их архитектурного проектирования возрастает, при этом цена архитектурной ошибки также растет. Нельзя не упомянуть в данном контексте известный принцип Альберта Эйнштейна: «Упрощать сложно, усложнять легко».

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

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

При соблюдении озвученных выше принципов команды, представленные на Рисунке 13, могут работать независимо друг от друга и располагаться территориально таким образом, насколько это наиболее эффективно с точки зрения цепочки разделения труда. Команда 1 может работать в Москве, команда 2 в Екатеринбурге, команда 3 в Новосибирске. Инфраструктурная поддержка команд разработки может осуществляться из Санкт-Петербурга. Города представлены в качестве иллюстративного примера. В случае создания продуктов, имеющих меньшую зависимость от локализованных правил регулятора, возможно размещение команд в самых разных уголках Земли. Иллюстративно это представлено на Рисунке 14.

Рисунок 14. Географически распределенная команда

разработки

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