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

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