- -
- 100%
- +
• Мы уже отмечали ранее по ходу настоящей главы, что участниками процесса предоставления ценности могут быть на первый взгляд внешние по отношению к продукту элементы. В качестве примера можно привести кредитный продукт и внешние по отношению к финансовой организации банки кредитных историй. Но данные, собираемые в ходе взаимодействия с указанными внешними субъектами, являются исключительно важными с точки зрения продуктовой логики. Поэтому для концептуальной архитектуры продукта также предусматривается отдельный уровень интеграции, который мы обозначаем архитектурно значимым, а потому и отражаем на Рисунке 2.
• Как было отмечено выше, в ходе исполнения жизненного цикла каждого продукта обрабатываются колоссальные объемы данных, в связи с чем выделяется сущность «продукт данных», а продуктовые данные и связанная с ними логика, реализующие данную сущность, включаются в концептуальную архитектуру продукта. Вместе с тем нельзя не учитывать, что хранение и обработка больших объемов данных требуют вложения серьезных трудовых, временных, инфраструктурных и в конечном итоге финансовых ресурсов. Работа в режиме оперативного доступа со всеми данными, ассоциированными с конкретным продуктом, может оказаться избыточным финансовым бременем для организации. Особенно если вспомнить, что современная компания предоставляет своим клиентам и/или партнерам множество продуктов. Для эффективного ответа на указанный вызов следует предусматривать для продуктов решения по архивному хранению данных. Архивное хранение не означает удаление данных. Но подразумевает технологии работы с ними, допускающие определенную экономию, не оказывающую негативного влияния с точки зрения жизненного цикла продукта и его P&L. Вопрос адекватного сопоставления уровней оперативного и архивного хранения данных должен быть решен архитектором. Также отметим необязательность рассматриваемого уровня концептуальной архитектуры продукта – не для каждого продукта архивное хранение может оказаться востребованным.
На данном этапе мы рассмотрели концептуальную архитектуру продукта, максимально близкую к его бизнес-архитектуре. Именно поэтому мы не разделяли на Рисунке 2 уровни архитектуры на составляющие. Мы лишь отметили условными обозначениями основные задачи каждого уровня: обработка логики или работа с данными. Но при дальнейшей детализации архитектуры вопросы структуризации каждого уровня выходят на первый план. Остановимся на них подробнее.
Поскольку мы рассматриваем не конкретный продукт и абстрагируемся от частных архитектурных и технологических решений, то дальнейшие рассуждения касаются характеристик автоматизации современных продуктов, ставших на сегодня стандартом де-факто. Примем для определенности положение, что при разработке каждого уровня продуктовой автоматизации используется парадигма микросервисной архитектуры. И для наглядности и удобочитаемости разобьем соответствующее развитие концептуальной архитектуры продукта на две составляющие, схематично представленные на Рисунках 3 и 4.
На Рисунке 3 представлена детализация архитектуры условно фронтальных слоев продукта, отвечающих за его визуальное представление клиенту/партнеру и обработку связанной с представлением продуктовой логики. Также на этом Рисунке представлен технологический подход к продуктовой автоматизации соответствующего уровня.
Собственно канальная логика реализуется с использованием языков разработки, специфичных для конкретных каналов представления, что и отражено на Рисунке 3. При этом количество реализаций может варьироваться в зависимости от сложности канального представления конкретного продукта. Но исключительно канальной логикой рассматриваемый уровень продуктовой автоматизации не исчерпывается. Мы уже отмечали ранее и в «Архитектуре цифрового мира», и в «Архитектуре цифровых платформ», что современные фронтальные решения должны следовать распределенной архитектуре, например, в формате микрофронтендов, выводили соответствующую архитектурную тенденцию в качестве одной из основных связанных тенденций развития архитектуры. Если продолжить рассматривать архитектуру продукта сквозь призму данной тенденции, то на уровне канального представления необходимо определить компоненты, отвечающие за прием и базовую обработку запросов от компонентов фронтального слоя (микрофронтендов), которые мы на Рисунке 3 определяем микросервисами фронтальной логики. Также нельзя забывать, что кроме обработки клиентских запросов каждый продукт может предоставлять API для разработки партнерских приложений на основе решений организации, создающей и развивающей продукт. Предоставление API в нашем примере осуществляется также в микросервисной парадигме и обозначается на Рисунке 3 микросервисами предоставления API. Отметим, что микросервисы могут в общем случае реализовываться с использованием любого языка разработки, мы в настоящем примере ограничиваем перечень лишь языками программирования высокого уровня.
Но не только наличие распределенных компонентов фронтальной логики характеризует архитектуру фронтального и канального представления современного продукта. Актуальные на сегодня требования к поставляемым на рынок продуктам заключаются в том числе в исключительно высокой нагрузочной способности – продукт должен обеспечивать корректную обработку громадного количества запросов, поступающих по дистанционным каналам обслуживания. И это также отражено на Рисунке 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. Как правило, использование кэширующих компонентов нередко предполагает наличие и долговременного хранилища информации, поэтому при дальнейшей детализации архитектуры в составе рассматриваемого архитектурного слоя будут присутствовать соответствующие компоненты, например, в виде реляционных баз данных, что также предъявляет требования по их поддержке со стороны используемой платформы – в нашем случае омниканальной. Основываясь на приведенном описании, мы можем составить примерный список платформенных сервисов, используемых при автоматизации канальной и канало-специфичной логики: