Ранее рассматривались такие архитектурные практики трансформации как переход к микросервисной архитектуре, использование продуктового подхода и EDA. Нетрудно заметить, что при реализации новых технологических решений в парадигме микросервисной архитектуры монолитный BPM-движок становится узким местом в части скорости разработки: каждая информационная система в микросервисной парадигме разрабатывается несколькими продуктовыми командами, что в свою очередь предъявляет серьезные требования к развитию BPM-движка. Нельзя не отметить, что резко возросшие требования к производительности создаваемых решений предъявляют качественно иные требования к масштабированию всех компонентов ИТ-ландшафта, в том числе BPM-движку.
В рамках перехода к микросервисной архитектуре и продуктовому подходу, подробно рассмотренным в предыдущих разделах, меняется и концепция управления бизнес-процессами. Продуктовый подход предполагает, что силами команды гибкой разработки (возможно, нескольких команд при сложном многофункциональном продукте) будет осуществляться полный цикл работ по автоматизации продукта, предоставляющего самодостаточную ценность для клиентов и/или партнеров. Такой продукт подразумевает в том числе автоматизацию сложных бизнес-процессов, связанных с обработкой его жизненного цикла. При этом отдельные элементы таких бизнес-процессов могут быть действиями, реализуемыми на уровне распределенных компонентов (микросервисов), но их объединение является действием иного порядка, которое имеет смысл назвать управлением бизнес-процессом с продуктовой спецификой или продуктовым бизнес-процессом, в соответствии с современными архитектурными практиками также являющимся микросервисом. Иллюстративно данная концепция представлена на Рисунке 16.
Для иллюстрации взят пример продукта электронной банковской гарантии и один бизнес-процесс заведение банковской гарантии. В соответствии с ранее представленными подходами к проектированию, управление бизнес-процессом реализовано в формате микросервиса. Отметим, что бизнес-процесс как управляющий компонент (в отличие от компонентов, непосредственно выполняющих бизнес-действия), вынесен за пределы продуктовой области и взаимодействует с продуктовыми микросервисами посредством платформы событийного обмена. Структура автоматизации продуктовых бизнес-процессов выглядит следующим образом:
Рисунок 16. BPM-движок в микросервисной архитектуре
Каждый набор микросервисов, обеспечивающих автоматизацию жизненного цикла продукта, должен иметь возможность осуществлять управление бизнес-процессами (содержать один или более BPM-движков), ассоциированными с данным продуктом или группой продуктов.
Применяемые технологии BPM-движков должны обеспечивать простоту и удобство использования в микросервисной топологии развертывания.
BPM-движок должен либо обладать высокой производительностью, либо предоставлять широкие возможности масштабирования (рекомендуемым является сочетание возможностей).
Хранение описаний (схем) бизнес-процессов, исполняемых продуктовым BPM-движком, должно быть локальным по отношению к автоматизации бизнес-функционала. Схемы не должны запрашиваться из удаленного реестра, что позволяет избежать в том числе проблем сетевой латентности.
Важным требованием к системе управления бизнес-процессами в современной архитектуре с учетом применения продуктового подхода и практик EDA является также следующее: низкий порог входа в том числе с точки зрения компетенций. Из представленных на сегодняшний день на рынке решений, удовлетворяющих всем перечисленных требованиям, можно отметить BPM Camunda, являющееся программным обеспечением с открытым исходным кодом.
Как отмечалось выше, реальные бизнес-процессы, выполняющиеся в современных организациях, обладают сложной структурой, включающей сотни и тысячи шагов и бизнес-действий. В случае выполнения подобных процессов одним микросервисом последний нарушит одно из ключевых требований, предъявляемых в парадигме микросервисной архитектуры, заключающееся в простоте каждого микросервиса. Рассмотрим, каким образом возможно решить таковую проблему.
Решение проблемы переноса управления сложными бизнес-процессами в парадигму микросервисной архитектуры состоит из нескольких этапов. Первым из них является технический рефакторинг бизнес-процессов.
Решение проблемы переноса управления сложными бизнес-процессами в парадигму микросервисной архитектуры состоит из нескольких этапов. Первым из них является технический рефакторинг бизнес-процессов.
Важным свойством, облегчающим применение BPM-движков, является наличие развитых средств моделирования процессов с использованием общепринятых нотаций (стандартом де-факто является BPMN). Использование подобных средств качественно улучшает возможности взаимодействия владельца продукта, оперирующего бизнес-понятиями, и команды гибкой разработки, состоящей из технических специалистов.
Вместе с тем, подобный подход несет в себе некоторые риски:
Отражение в бизнес-процессе исключительно логики бизнес-уровня необходимой, но не достаточной части автоматизации, предполагающей исполнение и технических задач. В данном случае расширение техническими задачами специализированных бизнес-действий (компонентов бизнес-процесса) может оказаться некорректным с точки зрения потенциального масштабирования создаваемого ИТ-решения. Более корректным стоит признать включение в состав бизнес-процесса в том формате, в котором уже производится автоматизация, отдельных этапов технического характера. Это и становится первой стадией технического рефакторинга бизнес-процесса.
Отрисовка инструментальными средствами бизнес-процесса целиком без предварительного мелкого гранулирования. В рассматриваемом варианте существует серьезный риск создания монолитного артефакта бизнес-процесса, скорость разработки которого и внесения изменений будет существенно ниже, нежели на уровне продуктовой логики. С учетом того, что изменения в продуктовых бизнес-процессах могут инициироваться на регулярной основе (в зависимости от потребностей рынка, участником которого является автоматизируемая организация), озвученный риск следует признать исключительно важным. Соответственно, приступая к автоматизации бизнес-процесса, следует всегда рассматривать возможность его декомпозиции на составляющие, что становится вторым этапом технического рефакторинга бизнес-процесса.
Таким образом, при осуществлении технического рефакторинга выполняются следующие основные задачи:
Формирование технической карты бизнес-процесса с учетом детализированного бэклога продукта, содержащего как пользовательские истории, так и технические задачи, выполнение которых необходимо в рамках реализации продуктовой логики.
Анализ компонентов бизнес-процесса на предмет повторяемости и независимости с выделением в отдельные исполняемые единицы.
Анализ контекста процесса на предмет разрыва и возможности разделения на составляющие по границам контекста.
Понятие контекста бизнес-процесса было сформулировано еще в период внедрения BPM-систем в классической архитектуре монолитного типа. Данный термин актуален и в настоящее время. Под контекстом бизнес-процесса понимается совокупность информации, характеризующая выполняемые в ходе бизнес-процесса действия, получаемые и обрабатываемые данные, а также служебная информация, необходимая для обработки бизнес-данных.
На основании понятия бизнес-процесса вводится понятие бизнес-транзакции как набора связанных действий, выполняемых в рамках бизнес-процесса. При этом выделяются локальные транзакции, которые могут выполняться в рамках связанного неделимого набора действий (в качестве примера такой локальной транзакции можно рассматривать процесс скоринга кредитной заявки), могущего исполниться лишь целиком и подлежащего отмене в случае возникновения ошибок, и глобальные, состоящие из последовательности локальных. Глобальная транзакция не может быть отменена, поскольку зафиксированы результаты исполнения локальных транзакций, входящих в ее состав. В случае возникновения ошибок по ходу выполнения глобальной транзакции отмена результатов локальных транзакций, завершившихся успешно, возможна посредством выполнения компенсационных действий (алгоритмов), которые, в свою очередь, также могут быть сложными бизнес-процессами. Примером невозможности отмены является ошибочное уведомление клиента о тех или иных событиях по ходу исполнения бизнес-процесса. В данном случае компенсационным алгоритмом может быть отправка корректирующих уведомлений.
Каждая локальная транзакция характеризуется своим транзакционным контекстом, определяющим ее состояние. В общем случае контексты локальных транзакций недоступны друг другу. Контекст бизнес-процесса, представляющего собой глобальную транзакцию, определяется набором контекстов локальных транзакций, входящих в его состав. При этом локальные транзакционные контексты являются непрозрачными друг для друга и могут управляться независимо посредством BPM-движка (в парадигме микросервисной архитектуры различных движков).