Читать книгу: «Цифровой продукт XXI века. Концепция и архитектура», страница 2

Но не только наличие распределенных компонентов фронтальной логики характеризует архитектуру фронтального и канального представления современного продукта. Актуальные на сегодня требования к поставляемым на рынок продуктам заключаются в том числе в исключительно высокой нагрузочной способности – продукт должен обеспечивать корректную обработку громадного количества запросов, поступающих по дистанционным каналам обслуживания. И это также отражено на Рисунке 3.

Как правило, обеспечение быстрого доступа к данным, обрабатываемым на уровне фронтального представления продукта, осуществляется с использованием механизма кэширования информации, например в оперативной памяти. Именно с этой целью на Рисунке 3 размещен компонент кэширования, содержащий данные фронтального представления. Одновременно с этим необходимо обеспечивать наполнение кэш актуальными данными / переносить новые данные из кэширующих компонентов в долговременные хранилища на смежных уровнях автоматизации. Для решения подобной задачи нередко используются технологии поддержки событийного обмена с целью обеспечения минимальной взаимозависимости между компонентами, составляющими продукт. На Рисунке 3 рассматриваемая задача решается журналами «прогрева» кэш, реализуемыми с использованием событийных механизмов.

Рисунок 3. Архитектура продукта (часть 1)

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

Непосредственное хранение продуктовых данных может осуществляться как в долговременном, так и в «быстром» хранилище, предполагающем высокоскоростную обработку информации и ее предоставление, но при этом не являющемся долговременным в классическом понимании этого слова. Поэтому для соответствующего уровня продуктовой автоматизации на Рисунке 3 в качестве примера указано надежное долговременное хранилище информации, реализованное методами СУБД, а также высокоскоростное хранилище с использованием кэширующих механизмов. Приведенные в примере хранилища должны синхронизироваться между собой, а также с иными уровнями автоматизации, предоставляя им данные, а также потребляя их. На Рисунке 3 указанные операции реализуются при помощи решений событийного обмена. Еще раз отметим, что при концептуальной схожести решений, используемых на разных уровнях продуктовой автоматизации, их техническая реализация может оказаться принципиально различной ввиду отличий в вариантах использования. Например, на фронтальном уровне от кэширующих решений, как правило, требуется хранение данных в режиме оперативного доступа, при проведении же продуктовых операций зачастую более насущным является асинхронное выполнение долговременных операций в оперативной памяти. Подобные разительные отличия предъявляют и принципиально различные требования к архитектуре соответствующих решений.

Вторая часть примера детализации архитектуры продукта схематично представлена на Рисунке 4.

Рисунок 4. Архитектура продукта (часть 2)

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

Рассмотрение вопросов организации бизнес-процессов в современной архитектуре представлено в книге «Архитектура цифрового мира», их место в платформенной архитектуре – в книге «Архитектура цифровых платформ. От настоящего к будущему». Место бизнес-процессов в продуктовой архитектуре будет рассмотрено в соответствующем разделе настоящей книги. В рамках же текущей главы отметим, что сложная продуктовая логика априори предполагает и развитый функционал процессного управления, допускающий в ходе реализации применение шаблонов как оркестровки, так и хореографии, для чего необходим развитый движок управления бизнес-процессами – BPM-движок. Использование указанного инструмента позволяет в том числе оперативно вносить изменения в продуктовые бизнес-процессы, минимизируя непосредственное «кодирование» с привлечением высокооплачиваемых разработчиков, что положительно сказывается на P&L продукта.

При этом оперативные данные прикладной логики нуждаются в долговременном хранении. Это касается как контекста процесса (бизнес-данных, ассоциированных с конкретным экземпляром процесса), так и управляющих данных, характеризующих экземпляр процесса в контексте BPM-движка. По умолчанию для решения указанной задачи, как правило, используется СУБД, что и представлено на Рисунке 4. Но нельзя не отметить, что для высокой оперативности доступа к данным нередко применяются кэширующие элементы, не представленные на Рисунке 4 для сохранения удобочитаемости. Контекст процесса и управляющие данные обычно разделяются в ходе хранения.

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

Мы уже отмечали по ходу настоящей главы, что участниками создания ценности могут быть и внешние по отношению к продукту элементы. Например, в кредитном продукте, предоставляемом финансовой организацией, немаловажную роль играет информация, получаемая о клиенте, созаемщиках, поручителях из внешних банков кредитных историй. Данная информация получается в рамках интеграционного взаимодействия продуктового решения с внешними информационными системами, зачастую находящимися за пределами организации, создающей и развивающей конкретный продукт. В такой ситуации и организация в целом, и конкретная продуктовая команда не могут влиять на уровень предоставления внешнего сервиса. Безусловно, существуют контракты на обслуживание, но ценность, предоставляемая клиентам и партнерам, не опирается на контракты, заключаемые организацией, пусть они и однозначно влияют на P&L. В эпоху дистанционных каналов обслуживания любая задержка в получении данных и предоставлении на их основании информации клиенту может оказаться фатальной с точки зрения конкурентоспособности всей организации. Поэтому при детализации слоя интеграции необходимо указать в контексте архитектуры не только интеграционную логику, ответственную за получение данных из внешних источников и отправку в них требуемой информации, но и механизмы, обеспечивающие производительность и надежность детализируемого слоя. В нашем примере, схематично показанном на Рисунке 4, в качестве указанного механизма используется кэширование. При этом для наполнения кэш и обеспечения максимально слабой связности продукта с внешними решениями используется механизм событийного обмена. Подчеркнем, что мы рассматриваем здесь случай внешнего по отношению к организации интеграционного взаимодействия, но приведенные рассуждения справедливы и для интеграций внутренних, когда взаимодействие, например, может осуществляться между несколькими продуктовыми решениями. Принципиальное отличие будет в таком случае заключаться лишь в большей степени влияния на уровень доступности взаимодействующих решений.

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

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

По ходу изложения, представленного в книге «Архитектура цифровых платформ. От настоящего к будущему», мы описывали различия между архитектурным подходом времен SOA, подходом «множества платформ» и современной платформенной автоматизацией. Рассмотрим приведенный выше пример архитектуры продукта в приложении к трем указанным подходам. И начнем с «седой старины» – сервис-ориентированной архитектуры, SOA. Иллюстративно данный подход отображен на Рисунке 5, при этом за основу взят немного измененный Рисунок 2 из книги «Архитектура цифровых платформ. От настоящего к будущему».

Для наглядности предположим, что автоматизация продукта осуществляется при помощи четырех автоматизированных систем (возможно, каждая из них реализована в микросервисной парадигме), при этом интеграция между ними осуществляется посредством корпоративной сервисной шины (ESB), в соответствии с практиками SOA. В этом случае каждая информационная система специализируется на своих функциях, продукт же является результатом их скоординированного исполнения:

• Система 1 отвечает за логику представления и реализует канальную и канало-специфичную продуктовую логику.

• Система 2 предполагает развитую функциональность управления бизнес-процессами, поэтому в ее зону ответственности входят автоматизация прикладной продуктовой логики, а также оркестровка и хореография процессов.

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

• Система 4 отвечает за эффективное хранение данных о продукте.

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

Рисунок 5. Продуктовая автоматизация при использовании концепции SOA

На основании детализации концептуальной архитектуры продукта, схематически приведенной на Рисунках 3 и 4, мы можем отметить, что технологические задачи, решаемые системами 1—4, во многом схожи между собой и связаны друг с другом, например, для каждой системы необходимо решать вопросы хранения данных, масштабирования указанного хранения, проблематику высокопроизводительных вычислений и т. д. При этом если следовать парадигме SOA, то все системы могут быть реализованы с использованием собственного технологического базиса, решать схожие задачи различным образом, что существенно усложняет как внесение значимых изменений в продукт, затрагивающих несколько архитектурных уровней автоматизации, так и организацию поддержки развития продукта. Рассмотрим указанные проблемы более подробно.

Мы уже неоднократно отмечали, что ценность продукта является комплексной, а потому запросы заинтересованных лиц, связанные с изменениями, например рыночной конъюнктуры, приводят к столь же комплексным изменениям продуктовой автоматизации: новые требования к автоматизации могут затрагивать и фронтальное представление продукта, и структуру автоматизируемой продуктовой логики, например, добавляя новые процессы в структуру жизненного цикла продукта, и требовать дополнения продукта новыми внешними данными. Хранение продуктовых данных также в таком случае может требовать обновления. Если каждая из отвечающих за продуктовую автоматизацию информационных систем реализована в собственной архитектурной и технологической парадигме, то и развивает каждую из систем своя команда, состоящая из различных специалистов с самыми разными компетенциями. В таком случае каждое значимое изменение, вносимое в продукт, будет требовать синхронизации деятельности упомянутых команд развития, что является далеко не самым простым процессом, требующим серьезных затрат временных, трудовых и финансовых ресурсов. Очевидно, что в этом случае говорить о лучших рыночных значениях показателя time-to-market не приходится. И P&L продукта в таком случае претерпевает самое драматическое изменение.

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

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

В книге «Архитектура цифровых платформ. От настоящего к будущему» мы также описывали подход к автоматизации, который характеризовали как «множество платформ». Данный подход характеризуется тем, что применяющие его организации создают отдельные программные платформы для того или иного уровня автоматизации. Иногда платформы выделяют по архитектурным уровням, иногда по бизнес-задачам. Так и появляются «омниканальные платформы», «учетные платформы», «платформы CRM», зачастую слабо связанные друг с другом. Рассмотрим применение данного подхода к автоматизации продукта и его концептуальной архитектуре, описанным выше. Схематично оно приведено на Рисунках 6 и 7. Мы вновь разделяем детализацию концептуальной архитектуры продукта на две иллюстрации, чтобы обеспечить наглядность последних.

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

Рисунок 6. Архитектура продукта при «множестве платформ» (часть 1)

Рисунок 7. Архитектура продукта при «множестве платформ» (часть 2)

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

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

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

Как уже указывалось выше, омниканальная платформа используется для автоматизации канало-специфичной и канальной логики. Как представлено на Рисунке 6, в состав данного архитектурного уровня входят микросервисы, отвечающие за непосредственную реализацию логики, микросервисы предоставления API (например, для партнерской экосистемы), компоненты кэширования, обеспечивающие высокое быстродействие фронтального представления продукта, журнальные компоненты событийного обмена, отвечающие за прогрев кэш и взаимодействие компонентов и микросервисов в парадигме событийно-ориентированной архитектуры EDA. Как правило, использование кэширующих компонентов нередко предполагает наличие и долговременного хранилища информации, поэтому при дальнейшей детализации архитектуры в составе рассматриваемого архитектурного слоя будут присутствовать соответствующие компоненты, например, в виде реляционных баз данных, что также предъявляет требования по их поддержке со стороны используемой платформы – в нашем случае омниканальной. Основываясь на приведенном описании, мы можем составить примерный список платформенных сервисов, используемых при автоматизации канальной и канало-специфичной логики:

• Сервис управления открытыми API.

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

• Сервис хранения информации, для которого используются две реализации: реализация хранения в кэш и в реляционных СУБД.

Необходимо подчеркнуть, что в рамках настоящего архитектурного примера мы рассматриваем общее представление платформенных сервисов без избыточной детализации. В реальных примерах могут присутствовать и реляционные, и нереляционные СУБД, различные реализации кратковременного хранения информации и т. д. Также для упрощения примера мы не рассматриваем такие служебные и вспомогательные задачи, как аутентификация, авторизация, управление секретами, логирование, трассировка и т. д.

Учетная платформа (см. Рисунки 6 и 7) отвечает за поддержку выполнения задач хранения продуктовых данных, а также архивного хранения. При этом присутствует надежное долговременное хранение данных в реляционной СУБД, хранение в режиме быстрого доступа с использованием кэширующих элементов, а для архивного хранения еще и использование элементов дешевого хранения в виде распределенной файловой системы, как показано на Рисунке 7. Кроме того, для обеспечения интеграционных взаимодействий и прогрева кэш используются журнальные компоненты, допускающие функционирование в соответствии с принципами событийно-ориентированной архитектуры. По аналогии с омниканальной платформой мы можем составить список платформенных сервисов, предоставляемых учетной платформой своим потребителям:

• Сервис хранения информации, для которого используются три реализации: реализация хранения в кэш, в реляционных СУБД и в распределенной файловой системе.

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

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

• Сервис хранения информации, для которого используются две реализации: реализация хранения в кэш и в нереляционных СУБД.

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

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

• Сервис хранения информации, для которого используется реализация хранения в реляционной СУБД.

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

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

Приведенный объемный пример убедительно свидетельствует: на разных уровнях продуктовой автоматизации используются схожие по применимости платформенные сервисы. Но в случае подхода «множества платформ» они предоставляются разными платформами. Соответственно, их способ реализации и варианты использования могут принципиально отличаться. Но в таком случае члены продуктовой команды должны владеть методиками использования каждой платформы, понимать различия, например, сервисов хранения данных в реляционных СУБД на уровне каждой из набора платформ. И внесение значимого изменения в продукт оказывается не менее, а зачастую и более сложным, нежели в парадигме SOA. Поэтому говорить о применимости подхода «множества платформ» в современной продуктовой автоматизации принципиально неверно.

Действительно, в случае значимого изменения, вносимого в продукт, продуктовые команды сталкиваются с необходимостью вносить изменения в использование платформенных сервисов, предоставляемых четырьмя платформами. Предположим, что следствием требуемого изменения становится вопрос развития продукта с точки зрения значимого повышения производительности. Подобное повышение может оказаться связанным с использованием кэширующих компонентов. Реализации платформенных сервисов, использующие кэширующие компоненты, предоставляются тремя платформами: омниканальной, интеграционной и учетной. Соответствующие сервисы могут быть реализованы каждой платформой с использованием различных технологических решений (например, Apache Ignite, Infinispan, Redis, Hazelcast и т. д.), для них могут применяться различные топологии развертывания, потребителям могут быть доступны отличные друг от друга и жестко специфицированные конкретной платформой варианты использования. Таким образом, существенное изменение в продукте, связанное с повышением производительности, потребует погружения продуктовой команды в три принципиально различные реализации сервиса хранения информации в кэш. Аналогичная ситуация будет наблюдаться в случаях хранения информации в реляционных базах данных, использования событийного взаимодействия и т. д. Продуктовые команды будут тратить временные, трудовые и финансовые ресурсы на корректный выбор конкретного платформенного сервиса, а не на реализацию собственно продуктовой логики, что крайне негативно скажется на P&L продукта.

Именно поэтому, как и отмечалось ранее, проблематика современных продуктов, их планирования, проектирования, создания и развития рассматривается в настоящей книге в контексте современного платформенного подхода, которому посвящена книга «Архитектура цифровых платформ. От настоящего к будущему». Рассмотрим применение указанного современного платформенного подхода в нашем примере архитектурной детализации продукта. С этой целью возьмем за основу перечень платформенных сервисов, представленный для подхода «множества платформ», и составим на его основе сводный перечень платформенных сервисов единой, современной, цифровой платформы, в случае если именно к использованию последней придет организация, создающая и развивающая продукт. На Рисунке 8 схематично представлен набор платформенных сервисов, который используется платформенным приложением, реализующим продукт из рассматриваемого нами примера.

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

Учитывая приведенную ранее детализацию архитектуры продукта, мы можем сформулировать использование платформенных сервисов платформенным приложением, реализующим продукт (см. Рисунок 8):

• Продукт использует сервис работы с данными (Сервис 1 на Рисунке 8), содержащий четыре реализации:

○ Сервис работы с реляционными данными (1.1). В качестве основы технологической реализации сервис использует СУБД PostgreSQL.

○ Сервис работы с нереляционными данными (1.2). В качестве основы технологической реализации сервис использует СУБД Apache Cassandra.

○ Сервис работы с распределенной файловой системой (1.3). В качестве основы технологической реализации сервис использует программное обеспечение Apache Hadoop.

○ Сервис работы с кэш (1.4). В качестве основы технологической реализации сервис использует программное обеспечение Apache Ignite.

• Продукт использует сервис потоковой передачи данных (Сервис 2 на Рисунке 8), содержащий две реализации (количество реализаций сознательно увеличено для демонстрации гибкости платформенного подхода):

○ Сервис потоковой передачи информации в журнальной парадигме (2.1). В качестве основы технологической реализации сервис использует программное обеспечение Apache Kafka.

○ Сервис потоковой передачи информации (2.2). В качестве основы технологической реализации сервис использует программное обеспечение Apache Pulsar.

○ Продукт использует сервис управления открытыми API (Сервис 3 на Рисунке 8). Предположим, что сервис содержит единственную реализацию на основе программного обеспечения WSO2.