- -
- 100%
- +
Конкретные платформенные сервисы в нашем примере, схематично проиллюстрированном Рисунком 21, существенно детализированы и расширены по сравнению с примером, приведенным на Рисунке 8. Детализация основана на компетенциях команд, задействованных при реализации продуктов (рисунки 16 и 17). Рассмотрим эту детализацию подробнее.
• Первым из платформенных сервисов на Рисунке 21 представлен сервис работы с данными (сервис 1), посредством которого унифицируются операции с данными. Он содержит четыре реализации:
○ Сервис работы с реляционными данными (1.1), используемый для работы с данными, хранящимися в реляционных СУБД, представленный единственной технологической реализацией 1.1.1 – на основе СУБД PostgreSQL.
○ Сервис работы с нереляционными данными (1.2), используемый для работы с данными, которые, например, ввиду требований к обеспечению эластичного масштабирования, хранятся в нереляционных СУБД. Данный сервис содержит две технологические реализации – на основе СУБД Apache Cassandra (1.2.1) и ScyllaDB (1.2.2).
○ Сервис работы с данными, хранящимися в распределенной файловой системе (1.3). Данный сервис может быть востребован, в частности, при реализации технологий архивного хранения либо распределенного хранения документов. Он представлен двумя технологическими реализациями – на основе Apache Hadoop (1.3.1) и S3, например, Ceph или MinIO (1.3.2).
○ Сервис работы с кэширующими технологиями (1.4), обеспечивающий высокопроизводительные операции с данными в оперативной памяти. Он представлен двумя технологическими реализациями – на основе Apache Ignite (1.4.1) и Infinispan (1.4.2).
• Для обеспечения взаимодействия компонентов ИТ-решения между собой в парадигме событийно-ориентированной архитектуры используется платформенный сервис потоковой передачи данных (2). Данный сервис в своей работе задействует возможности платформенного сервиса работы с данными (1). При этом использование сервиса 1 происходит неявно для пользователя – платформенного приложения. Сервис 2 содержит две реализации:
○ Сервис работы с журнальной потоковой передачей информации (2.1), представленный в примере единственной технологической реализацией – на основе программного обеспечения Apache Kafka (2.1.1).
○ Сервис работы с потоковой передачей информации (2.2), представленный в примере единственной технологической реализацией – на основе программного обеспечения Apache Pulsar (2.2.1).
• Для предоставления открытых API, например, в целях создания на основе продукта организации партнерских приложений, продуктовыми командами используется платформенный сервис 3 – сервис управления открытыми API. Данный сервис содержит две технические реализации на основании популярных программных продуктов с открытым исходным кодом:
○ Реализация на основе программного продукта WSO2 (3.1).
○ Реализация на основе программного продукта Gravitee (3.2).
• Продуктовая логика предполагает управление процессами жизненного цикла продукта, а потому нуждается в развитых методиках управления. Помогает в этом продуктовым командам платформенный сервис управления бизнес-процессами (4), содержащий две реализации:
○ Сервис централизованного управления бизнес-процессами в соответствии с шаблоном оркестровки (4.1), представленный двумя технологическими реализациями – на базе программного обеспечения Camunda (4.1.1) и Kogito (4.1.2).
○ Сервис децентрализованного управления бизнес-процессами в соответствии с шаблоном хореографии (4.2), представленный двумя технологическими реализациями – на базе программного обеспечения Camunda (4.2.1) и Kogito (4.2.2).
Подчеркнем, что конкретные технологии приведены исключительно для примера. Указание этих технологий вовсе не означает, что платформенный сервис представляет собой либо просто развернутую технологию, либо всего лишь проксирует ее API. В реальности платформенный сервис, как мы уже неоднократно отмечали, представляет собой сложную сущность, содержащую не только технологии, но и топологии их развертывания, варианты использования, методики масштабирования, надежности и многое другое.
Вышеприведенное описание платформенных сервисов позволяет наглядно проиллюстрировать их применение в рассматриваемом нами примере создания двух цифровых финансовых продуктов, реализуемых командами с различными компетенциями. Схематично применение платформенного подхода и конкретных платформенных сервисов представлено на Рисунках 22 и 23. Данные рисунки в значительной степени основываются на Рисунках 16 и 17, а также на детализации платформенных сервисов, приведенной на Рисунке 21. Для удобства восприятия использование платформенного сервиса 0 не показано, при этом в реальности он задействован при предоставлении всех остальных платформенных сервисов потребителям. Для обозначения продукта электронной банковской гарантии на Рисунках 22 и 23 используется сокращение-аббревиатура ЭБГ.
Рисунок 22. Пример применения платформенного подхода при реализации двух продуктов (часть 1)
Рисунок 23. Пример применения платформенного подхода
при реализации двух продуктов (часть 2)
На Рисунках 22 и 23 представлено соответствие между продуктами (кредитный продукт и электронная банковская гарантия), используемыми продуктовыми командами технологиями (обозначены собственными логотипами) и платформенными сервисами (идентифицированы двойной нумерацией – номер применяемого платформенного сервиса и номер конкретной технологической реализации). Как можно видеть из рисунка, платформенный подход в данном примере обеспечивает гибкость, позволяя использовать унифицированные платформенные сервисы с различной реализацией, максимально удовлетворяющей потребностям команд. В свою очередь потребности определяются, как мы отмечали выше, наличием в продуктовых командах соответствующих компетенций. Основываясь на приведенной в примере структуре платформенных сервисов и командных компетенциях, можно сделать следующие заключения:
• На уровне фронтальной и канальной логики обоими продуктами используются платформенные сервисы работы с данными в части реляционных СУБД и кэширующих компонентов, при этом команда кредитного продукта использует реализации 1.1.1 и 1.4.2, а команда электронных банковских гарантий – 1.1.1 и 1.4.1. Обе продуктовые команды применяют на данном уровне платформенный сервис потоковой передачи данных 2: команда кредитного продукта использует реализацию 2.2.1, команда электронных банковских гарантий – 2.1.1. Кроме этого, продуктовыми командами используется сервис управления открытыми API 3 – 3.1 и 3.2 в части технологических реализаций соответственно.
• На архитектурном уровне канало-специфичной логики продуктовыми командами используется платформенный сервис потоковой передачи данных 2: командой кредитного продукта 2.2.1, а командой электронных банковских гарантий 2.1.1 в части технологической реализации.
• На уровне хранения продуктовых данных командами применяются платформенные сервисы работы с данными в части поддержки реляционных СУБД и кэширующих компонентов, а также сервисы потоковой передачи данных. Технологические реализации соответствуют указанным для слоя фронтальной и канальной логики, при этом топологии и варианты использования сервисов могут быть отличными от применяемых на рассмотренном в предыдущем пункте архитектурном уровне.
• На уровне продуктовой логики команды используют платформенный сервис работы с данными только лишь в части поддержки реляционных СУБД (технологическая реализация 1.1.1), платформенный сервис потоковой передачи данных с технологическими реализациями 2.2.1 для кредитного продукта и 2.1.1 для электронных банковских гарантий, а также платформенный сервис управления бизнес-процессами. Обе продуктовые команды используют шаблоны как оркестровки, так и хореографии, поэтому для кредитного продукта применяются технологические реализации 4.1.1 и 4.2.1, для электронных банковских гарантий 4.1.2 и 4.2.2.
• На уровне интеграционной логики для автоматизации представленных в нашем примере продуктов используются платформенные сервисы работы с данными в части управления нереляционным хранением информации: для кредитного продукта применяется технологическая реализация 1.2.2, для электронной банковской гарантии 1.2.1. Для поддержки высокоэффективной работы с данными в оперативной памяти используются реализации сервиса работы с кэш 1.4.2 и 1.4.1 соответственно. В части применения платформенного сервиса потоковой передачи данных задействованы реализации, аналогичные представленным выше для рассматриваемых цифровых продуктов.
• Для эффективной имплементации архитектурного уровня архивного хранения продуктовых данных используется платформенный сервис работы с данными в реализации работы с распределенной файловой системой. Команда развития кредитного продукта применяет технологическую реализацию 1.3.2, команда развития электронных банковских гарантий – 1.3.1.
Отметим, что наличие общих платформенных сервисов, поддерживающих наборы технологических реализаций, позволяет заложить на уровне платформы общие варианты использования и/или стандартизированные компоненты для всех поддерживаемых реализаций либо их подмножества.
Из представленного выше рассмотрения следует, что продукты и продуктовые команды являются источниками требований к платформе, например, в части расширения поддержки технологических реализаций платформенных сервисов. Важно отметить, что каждый из платформенных сервисов может быть расширен набором реализаций на каждом из представленных на Рисунке 21 уровней иерархии. Разумеется, платформенные сервисы предоставляют потребителям не просто технологические реализации, но и варианты их использования.
При этом компонентная структура продукта (см. Рисунок 20) позволяет членам продуктовых команд при необходимости использовать платформенные сервисы в каждом компоненте цифрового продукта. Проиллюстрируем это примером для продукта электронных банковских гарантий. Схематично пример приведен на Рисунке 24.
Рисунок 24. Использование платформенных сервисов
продуктовыми компонентами
На Рисунке 24 представлены ранее выделенные для примера компоненты продукта, им сопоставлено использование платформенных сервисов в соответствии с ключевыми характеристиками, приводившимися для компонентов продукта выше. Разумеется, это не исключает потенциально более широкого применения платформенного подхода при создании и развитии компонентов, но здесь мы ограничиваем его ранее выделенными ключевыми характеристиками с целью избежать избыточного усложнения. Рассмотрим их подробнее:
• Компонент «Заявка на банковскую гарантию» обладает развитой фронтальной логикой, а также предоставляет открытые API партнерам компании для создания экосистемы на базе продукта. Поэтому при реализации данного компонента используются платформенные сервисы работы с данными в части поддержки реляционных СУБД и кэширования, сервис потоковой передачи данных, а также сервис управления открытыми API. Конкретные технологические реализации сервисов соответствуют ранее приведенным для продукта «Электронные банковские гарантии».
• Компонент «Скоринг заявки» обладает развитой продуктовой логикой, а также поддерживает управление бизнес-процессами. Одновременно с этим на уровне компонента поддерживается реализация архитектурного уровня интеграционной логики, потому что, как рассматривалось ранее, для имплементации задач компонента может потребоваться информация, мастер-системы по которой являются внешними по отношению к продуктовому ИТ-решению. Таким образом, компонент использует платформенный сервис работы с данными, поддерживая реляционное, нереляционное хранение данных, а также работу с кэширующими компонентами. Кроме того, применяется платформенный сервис потоковой передачи данных. Для управления бизнес-процессами используется платформенный сервис управления бизнес-процессами с поддержкой реализации шаблонов как оркестровки, так и хореографии.
• В рамках реализации компонента «Вложения к заявке» ввиду исключительной важности задач оперативного и архивного хранения используются платформенные сервисы работы с данными в части поддержки хранения данных в реляционных СУБД, распределенной файловой системе и в кэш. Также применяется платформенный сервис потоковой передачи данных.
• Компонент «Банковская гарантия» обеспечивает исполнение процессов жизненного цикла продукта, а потому важнейшим архитектурным слоем для него является управление бизнес-процессами вместе с прикладной продуктовой логикой. Ввиду всего вышеперечисленного при реализации компонента используются платформенный сервис работы с данными в части поддержки реляционных СУБД, сервис потоковой передачи данных, сервис управления бизнес-процессами с поддержкой оркестровки и хореографии.
• Компонент «Клиент» в своей реализации учитывает получение данных клиентов из соответствующих мастер-систем (интеграционная логика) и работу с данными (продуктовая логика и оперативное хранение). Поэтому для реализации рассматриваемого компонента используются платформенные сервисы работы с данными (технологические имплементации поддержки реляционных и нереляционных СУБД, а также кэш) и сервис потоковой передачи данных. Технологическая реализация сервиса работы с данными в части поддержки распределенной файловой системы в компоненте не используется, поскольку, как отмечалось ранее по ходу настоящего раздела, слой архивного хранения не столь критичен для работы с клиентскими данными.
Отметим, что при имплементации каждого компонента могут использоваться различные топологии платформенных сервисов (даже при применении одних и тех же сервисов и их реализаций), также могут быть существенные отличия в их вариантах использования. Как следствие, платформа должна обладать гибкостью для поддержки всех требований компонентов, входящих в состав продукта. Представленный нами пример наглядно демонстрирует, что продукты являются источниками развития платформы, предъявляя требования по наличию платформенных сервисов, их технологических реализаций, а также по вариантам использования. В случае отсутствия в составе платформы требуемой функциональности продуктовая команда может ее разработать и по прозрачным правилам добавить в платформу, сделав свои дополнения доступными к использованию всеми потребителями платформы. В роли последних выступают продуктовые команды. Таким образом свойство открытости современной платформы позволяет продуктовым командам не ограничиваться жестко очерченным платформенным функционалом.
Внимательный читатель уже подготовил каверзный вопрос: «Представленный пример продуктовой разработки на базе платформы выглядит избыточно тяжеловесным: платформу необходимо реализовывать долгое время, поддерживать множество реализаций сервисов, все это стоит больших денег. Ранее уважаемый автор постоянно говорил о технологической и топологической унификации. Нет ли здесь противоречий с предыдущими книгами и есть ли вообще смысл в такой платформе и подобном подходе?» Мы со своей стороны поблагодарим читателя за своевременный злободневный вопрос и постараемся развеять его опасения.
В книге «Архитектура цифровых платформ. От настоящего к будущему» мы отмечали, что совершенно необязательно ожидать реализации всей платформы целиком для начала продуктовой разработки. Необходимо определить (и архитектор, являясь лидером технологических изменений, должен играть в этом определении ключевую роль) то ядро платформы, которое позволит запустить продуктовую разработку и впоследствии распараллелить развитие платформы и продуктов на ее основе. По мере повышения зрелости платформы в дело вступает такое свойство современных цифровых платформ, как открытость: продуктовые команды вносят требуемые им изменения в платформу, при этом публикуют их таким образом, чтобы они были доступны всем остальным командам. То есть у платформы есть собственный жизненный цикл, она является постоянно развивающимся живым организмом. В представленном выше примере необязательно создавать все сервисы и их технологические реализации заранее. Например, платформа может содержать технологическую реализацию сервиса работы с нереляционными СУБД на базе программного обеспечения Apache Cassandra, и эта реализация будет использоваться продуктом электронных банковских гарантий. При проектировании кредитного продукта и формировании команды его реализации принимается решение использовать на соответствующем архитектурном слое распределенную СУБД ScyllaDB. Соответствующее расширение профильного платформенного сервиса может осуществить платформенная команда, если в организации еще не стерлась грань между платформенными и продуктовыми командами, а может и продуктовая. Как мы отмечали в предыдущих трудах, платформе должен быть сопоставлен набор методик не только по ее использованию, но и по ее развитию. Продуктовая команда реализует расширение соответствующего платформенного сервиса на предмет поддержки требуемой технологической реализации и публикует данное расширение в общую платформенную структуру. В последующем другие продуктовые команды могут выбирать из двух реализаций сервиса либо добавлять собственный. Основания для выбора могут быть самые различные: наличие компетенций, требования по масштабируемости, имеющиеся наработки и т. д. С технологической точки зрения важно лишь то, чтобы архитектура платформы поддерживала соответствующее расширение, а процесс публикации дополнений был выстроен прозрачным образом, снижающим до минимума возникновение ошибок при дополнении платформенного функционала (полностью исключить возникновение ошибок принципиально невозможно).
Таким образом, указанный подход обеспечивает технологическую унификацию: использование платформенных сервисов является унифицированным, платформа предоставляет развернутые описания вариантов использования платформенных сервисов, технологии, ассоциированные с сервисами, являются закрепленными на каждом конкретном этапе развития как платформы, так и платформенных приложений, расширение технологического базиса диктуется требованиями, возникающими у продуктовых команд, а зачастую ими и реализуется. Но вопрос читателя содержал и финансовую сторону, которая также является немаловажной.
Представленная на Рисунке 21 архитектура платформы (в данном случае имеет смысл говорить о концептуальной архитектуре) является достаточно разнообразной технологически, а создание и поддержка большого количества технологий, топологий их развертывания, наборов вариантов использования в свою очередь требуют серьезных временных, трудовых и финансовых ресурсов. И если выше мы описали потенциальное распределение привлечения трудовых ресурсов на реализацию компонентов платформы во времени, то финансовая сторона нами пока не освещена. А детально ее прояснить мы и не сможем, поскольку не разбираем в настоящем изложении примеры конкретных компаний и их платформ и продуктов. Но можем обрисовать общие направляющие формирования финансовой оценки технологического разнообразия на уровне платформы:
• Чем большее число технологических реализаций сервисов поддерживается на уровне платформы, тем более гибкой оказывается поддержка продуктовых ИТ-решений со стороны платформы. При создании и развитии цифрового продукта становится возможным выбирать те технологические реализации платформенных сервисов и компонентов, которые оказываются выгоднее в том числе с финансовой точки зрения.
• Следует понимать, что одновременно с этим расширение множества технологических реализаций платформенных сервисов повышает стоимость платформы, причем в части как создания, так и развития и сопровождения.
• Размывание границ между платформенными и продуктовыми командами позволяет переложить часть финансовых затрат по развитию платформы на продуктовые команды и учитывать в P&L продуктов (для продуктов с благоприятными рыночными перспективами подобный подход может оказаться вполне приемлемым).
• Публикация дополнений в платформу, осуществляемых продуктовыми командами, позволяет переиспользовать удачные наработки, сокращая общую стоимость владения платформой в организации и повышая эффективность создания и развития новых продуктов с использованием платформенного подхода.
• Множество поддерживаемых платформой технологических реализаций позволяет формировать продуктовые команды таким образом, чтобы снижать стоимость указанных команд как в части снижения требований к компетенциям их членов (ввиду реализации трудоемких инфраструктурных задач на уровне платформы), так и в части набора специалистов с более дешевым техническим бэкграундом, если последний поддерживается на уровне платформы. Данный подход также положительно влияет на P&L продукта.
Современная компания, ориентирующаяся на создание ценности для клиентов и партнеров, должна учитывать эти факторы при формировании финансовой модели и планировании развития платформы и продуктов на ее основе. Конкретные примеры расчета соответствующих финансовых моделей выходят за рамки настоящей книги.
Таким образом, современная архитектура продуктов, подкрепленная платформенным подходом, позволяет эффективно поддерживать работу распределенных команд. Притом поддерживается как работа распределенных команд над одним продуктом, так и распределенная работа множества команд над множеством продуктов, что характерно для современной организации, ставящей себе целью интенсивное развитие в окружающем нас цифровом мире.
На этом мы завершаем рассмотрение организационной распределенности как одного из ключевых трендов развития архитектуры и переходим к распределенности технологической.
Современные технологии изменяют мир таким образом, что получение доступа к цифровым продуктам становится возможным в любой точке земного шара, причем практически мгновенно. Современный цифровой мир является миром дистанционных каналов, что в огромном количестве случаев стирает различия между крупными и мелкими компаниями в части доступности их продуктов и услуг для клиентов и партнеров. Например, если 15 лет назад исключительно принципиальным при выборе финансовой организации для обслуживания было количество точек присутствия (отделений, банкоматов и т. д.) даже на уровне конкретного региона, то на сегодня данный параметр не является столь существенным в части доступности для клиентов и уступил свое место в списке приоритетов качеству предоставляемых организацией продуктов и их удобству с точки зрения конкретного клиента. Однако у каждой медали есть обратная сторона. Современный продукт должен быть доступен посредством дистанционных каналов в режиме 24х7, обеспечивать соответствующий уровень непрерывности, производительности и надежности. И это предъявляет серьезные требования к архитектуре продукта. Архитектура продукта должна быть распределенной – поддерживать распределенное предоставление и исполнение продукта.
Поскольку мы рассматриваем архитектуру обобщенного продукта без свойственной различным организациям конкретики, то для примера возьмем уже обсуждавшийся выше продукт – электронную банковскую гарантию. Детализация концептуальной архитектуры данного продукта представлена на Рисунках 25 и 26.
Рисунок 25. Детализация концептуальной архитектуры продукта «Электронная банковская гарантия» (часть 1)
Рисунок 26. Детализация концептуальной архитектуры
продукта «Электронная банковская гарантия» (часть 2)
На Рисунках 25 и 26 изображена архитектура продукта с указанием используемых при его создании и развитии платформенных сервисов и их технологических реализаций. Мы уже неоднократно отмечали, что архитектура продукта состоит из набора слоев (в настоящем изложении с целью упрощения показано их подмножество). И все архитектурные слои в ходе своей реализации должны обеспечивать поддержку технологической распределенности. Последовательно по слоям рассмотрим, каким образом это может быть достигнуто:
• Уровень фронтального и канального представления должен обеспечивать высокую производительность фронтального слоя цифрового продукта во всех поддерживаемых каналах, надежность предоставления продукта посредством каналов, а также бесшовное расширение числа каналов обслуживания при развитии продукта. Отдельно отметим, что бесшовное выполнение операций во всех поддерживаемых каналах достигается посредством омниканальности, что будет рассмотрено в соответствующем разделе настоящей главы, посвященном связанным тенденциям развития архитектуры. Исходя из вышесказанного, фронтальная логика должна реализовываться с использованием легковесных фреймворков (на Рисунке 25 для примера представлен Angular), при этом должна обеспечиваться модульность создаваемого визуального представления. Одним из вариантов последнего может служить архитектура микрофронтендов, следование которой также будет рассмотрено в настоящей главе в разделе, посвященном связанным тенденциям развития архитектуры. Синхронизированная с логикой представления прикладная логика фронтального уровня должна реализовываться в распределенной парадигме, например, в микросервисной архитектуре, как показано на Рисунке 25. В этом случае становится возможным гибко обеспечивать масштабирование компонентов логики под требования производительности, предъявляемые дистанционными каналами обслуживания, а также поддерживать достаточное количество экземпляров инстанциируемых компонентов для обеспечения требуемого уровня надежности. Но недостаточно просто обеспечивать исполнение логики. Современные архитектурные принципы диктуют, что компоненты реализации логики не должны сохранять своего состояния (быть stateless). В таком случае по ходу собственного исполнения они вынуждены осуществлять огромное количество операций запросов к данным, что оказывает крайне негативное влияние на производительность всего продуктового ИТ-решения. Для ускорения выполнения подобных операций в нашем примере используется компонент кэширования, для которого приведен пример технологии, лежащей в его основе, – Apache Ignite. Для обеспечения поддержки распределенности цифрового продукта применяемая технология и ее топология должны поддерживать распределенное исполнение и эластичное масштабирование. Аналогичные требования предъявляются и к программному обеспечению событийного обмена, использующемуся в нашем примере для обеспечения взаимодействия компонентов уровня фронтальной и канальной логики с компонентами, принадлежащими к смежным архитектурным слоям. Для примера на Рисунках 25 и 26 приводится программное обеспечение Apache Kafka.