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

Рассмотрим реализацию двух продуктов в организации. Условно, в нашем примере организация представляет финансовую сферу, предоставляет она в качестве продуктов кредитные продукты и электронные банковские гарантии. Мы в данном случае для упрощения рассматриваем все кредиты и все гарантии в качестве одного продукта, реальные ситуации гораздо сложнее, зачастую происходит более мелкая грануляция продуктов. И каждый продукт реализуется выделенной продуктовой командой (как уже отмечалось, команды рассматриваются многочисленные и распределенные). Могут ли в этой ситуации команды использовать принципиально различный технологический стек, как было представлено на Рисунках 16 и 17? Безусловно, могут. В наш век применения программного обеспечения с открытым исходным кодом, когда сообщество открытого ПО представляет собой одну из самых больших экосистем в сфере информационных технологий, это более чем возможно. Мы, конечно, критиковали подобный подход с точки зрения финансовой составляющей. Но технологически ничего невозможного в этом нет. Специалисты команд развития владеют самой разной квалификацией, стоимость указанных квалификаций постоянно меняется в рыночных условиях, поэтому вполне вероятно, что разные команды сформировались столь непохожим между собой образом в технологическом плане. И внимательный читатель снова готовит очередной провокационный вопрос: «Возможно ли обеспечить подобную ситуацию платформенным подходом, например, таким, какой был ранее схематично изображен на Рисунке 8?» Мы считаем, что не только ничего невозможного в этом нет, но и предлагаем читателю разобрать пример, который на самом деле является очевидным для тех, кто внимательно изучил предыдущие труды автора, а также настоящее изложение.

Итак, мы расширим пример представления платформенных сервисов. Схематично расширенный пример изображен на Рисунке 21. Структура реализаций платформенных сервисов выбрана таким образом, чтобы соответствовать технологическому многообразию, проиллюстрированному ранее на Рисунках 16 и 17.

В данном примере мы вводим общий платформенный сервис – на Рисунке 21 он так и обозначен «Платформенный сервис». Задача этого сервиса заключается в экранировании платформенного приложения, реализующего цифровой продукт, от особенностей реализации платформы. Почему же возникла необходимость в появлении данного сервиса? Технологическое многообразие, отмечавшееся нами ранее и схематически изображенное на рисунках 16 и 17, во многом является следствием организационной распределенности и многочисленности команд продуктовой разработки. Одним из следствий указанного технологического многообразия, представленного ранее в примерах, является возможность использовать различные фреймворки разработки. Мы пойдем дальше и укажем, что при создании продуктов могут использоваться различные экосистемы разработки. Отметим, что подобное утверждение укладывается в парадигму микросервисной архитектуры – классики данного архитектурного подхода (Мартин Фаулер, Крис Ричардсон и другие) указывали, что поскольку каждый микросервис в общем случае является независимой единицей развертывания, то может реализовываться на том языке программирования, который наиболее применим для его скорейшей реализации конкретным членом команды, ответственным за данный микросервис. То есть в предельном случае каждый микросервис может быть реализован на собственном языке программирования. В нашем примере представлены две экосистемы разработки – Java и. NET, два языка программирования – Java и С#. Отметим, что этими двумя языками программирования приведенные экосистемы разработки не покрываются полностью, возможны и иные варианты, но мы рассматриваем пример, а потому выбираем два указанных языка программирования для упрощения.

Наиболее существенным в нашем примере в контексте экосистем разработки является их значимое отличие: различные виртуальные машины, используемые библиотеки, разная детализация сборки приложений (при внешнем сходстве) и т. д. И в подобных условиях платформенный подход должен поддерживать весь использующийся инструментарий. Для упрощения же использования платформы предлагается применять «фасадные» компоненты (мы берем название от шаблона проектирования «Фасад», подробно рассмотренного в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования», авторы Эрих Гамма, Ричард Хельм, Ральф Джонсон, Джон Влиссидес), экранирующие пользователей, в качестве которых выступают в данном случае платформенные приложения, от деталей реализации. Именно в этой экранизации и состоит важность платформенного сервиса. Он обозначен на Рисунке 21 как 0. Отметим, что мы рассматриваем концептуальную архитектуру, при дальнейшей же архитектурной детализации и в рамках постановки задач на разработку «Платформенный сервис» совершенно не обязательно будет представлен единой сущностью. Например, в рамках детализации компонентной архитектуры он может состоять из набора логических сущностей, зачастую имеющих прямое отношение к разрабатываемым физическим сущностям. На Рисунке 21 он для упрощения показан единой концептуальной сущностью, предоставляющей два типа платформенного SDK клиентам. Предвосхищая потенциальное саркастичное замечание внимательного читателя о переизбытке сущностей различных типов, отметим, что здесь все упомянутые сущности являются необходимыми и полностью соответствуют «бритве Оккама». Подчеркнем, что мы не вводим дополнительно к платформенному SDK платформенный API для упрощения примера.

Конкретные платформенные сервисы в нашем примере, схематично проиллюстрированном Рисунком 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.