Архитектура цифрового мира

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

• Анализ компонентов бизнес-процесса на предмет повторяемости и независимости с выделением в отдельные исполняемые единицы.

• Анализ контекста процесса на предмет разрыва и возможности разделения на составляющие по границам контекста.

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

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

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

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

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

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

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

Как видно из приведенного описания, каждый способ организации управления бизнес-процессами имеет свои преимущества и недостатки, поэтому в современных архитектурных практиках указанные шаблоны скомбинированы следующим образом:

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

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

• Оркестровка локального бизнес-процесса осуществляется с использованием BPM-движка в соответствии с лучшими практиками переноса последнего в парадигму микросервисной архитектуры, представленными ранее по ходу настоящего раздела. Примером такого движка может являться BPM Camunda.

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

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

• Применение шаблона проектирования хореографии для управления глобальным процессом предполагает использование лучших современных практик EDA (наличия платформы событийного обмена, носящей технический характер), а также специальной организации мониторинга его состояния и исполнения экземпляров бизнес-процессов. В качестве платформы событийного обмена может использоваться, например, Apache Kafka.

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

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

Пример распределенного бизнес-процесса, выполняющегося совместно с продуктовыми микросервисами, представлен на Рисунке 17.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.