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

Интеграционная платформа отвечает за наполнение продуктового ИТ-решения данными, мастер-системы для которых находятся вне контура автоматизации продукта, возможно, вне контура организации, рассматриваемый продукт создающей и развивающей. Для реализации указанной задачи интеграционная платформа должна обеспечивать собственно взаимодействие с упомянутыми мастер-системами. В представленном примере для этого используются журнальные компоненты, обеспечивающие событийное взаимодействие. Получаемые данные для оперативности помещаются в хранилище быстрого доступа, реализуемое с использованием кэширующих компонентов. Для обеспечения надежности последних могут применяться компоненты долговременного хранения информации (на Рисунке 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.

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

○ Сервис оркестровки бизнес-процессов (4.1).

○ Сервис хореографии бизнес-процессов (4.2).

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

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

Далее рассмотрим исключительно важный вопрос: каким же образом продукт может использовать платформенные сервисы в своей архитектуре? Схематично логика этого использования представлена на Рисунках 9 и 10, которые иллюстрируют развитие реализации продукта от подхода «множества платформ» к применению современной цифровой платформы. Нумерация используемых платформенных сервисов соответствует Рисунку 8.

На уровне фронтального и канального представления используются платформенные сервисы хранения данных в реляционной СУБД (1.1) и кэш (1.4), журнальной передачи информации (2.1) и управления открытыми API (3). При хранении продуктовых данных используются платформенные сервисы хранения данных в реляционной СУБД (1.1) и кэш (1.4) и журнальной передачи информации (2.1) (см. Рисунок 9).

На уровне продуктовой логики используются платформенные сервисы хранения данных в реляционной СУБД (1.1), журнальной передачи информации (2.1), управления бизнес-процессами в парадигме оркестровки (4.1) и хореографии (4.2). На уровне интеграции и наполнения данными используются платформенные сервисы хранения данных в нереляционной СУБД (1.2) и кэш (1.4), журнальной передачи информации (2.1). На уровне архивного хранения используется платформенный сервис хранения данных в распределенной файловой системе (1.3) (см. Рисунок 10).

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

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

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

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

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

Как же совместить скорейший вывод продукта на рынок и его качественную проработку, учитывающую необходимость корректной архитектуры? Ответ на этот вопрос уже содержится в методиках гибких практик и их адаптациях к применению в крупных компаниях. Продуктовые команды должны создавать MVP (minimum viable product, минимально жизнеспособные версии продуктов), позволяющие оценить реакцию рынка на продукт, скорректировать его в соответствии с пользовательскими предпочтениями и рыночными тенденциями. Но здесь важно не забывать о том, что MVP непременно должен быть верифицируемым. Например, если MVP запускается на некой выделенной группе пользователей, то результат его отработки должен быть применимым и для рынка в целом, не может считаться удовлетворительной ограниченная группа, которая выбрана таким образом, что не отражает последующее рыночное применение полноценной версии продукта. Но, кроме этого, верификация должна осуществляться и в части технической готовности: если MVP показывает себя удачно, но для полноценного запуска необходимо пересмотреть всю архитектуру продукта, с нуля вести его разработку, то такой MVP не может считаться верифицируемым: он не несет ценности для клиентов, а лишь потребляет значимые временные, трудовые и в конечном итоге финансовые ресурсы организации. Как же определить верифицируемость MVP?

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

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

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

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