Андрей Трушкин - Архитектура цифрового мира

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

Пример монолитного BPM-движка в ИТ-ландшафте схематично показан на Рисунке 15.

Рисунок 15. Пример монолитного BPM-движка в ИТ-ландшафте

На Рисунке 15 представлен BPM-движок, обеспечивающий выполнение бизнес-процессов ИТ-ландшафта, выстроенного в монолитной или SOA архитектуре. Некоторое число информационных систем (N – на рисунке) обеспечивают автоматизацию бизнес-действий, организуемых в некоторое число бизнес-процессов (K – на рисунке). Соответственно, монолитный движок должен поддерживать значительное число (в современной организации оба параметра могут варьироваться от сотен до тысяч) сочетаний бизнес-действий и систем. При этом независимое масштабирование невозможно.

Подобная топология развертывания решения по автоматизации бизнес-процессов затрудняла разработку ИТ-решений распределенными командами разработки, а распределенное исполнение (в современном понимании, подробно рассмотренном выше) информационных систем и ИТ-ландшафта в целом исключалось. Долгое время лидирующая роль на рынке BPM-движков принадлежала «закрытым» решениям, поставляемым крупными компаниями – разработчиками программного обеспечения, таким как IBM и Oracle.

Ранее рассматривались такие архитектурные практики трансформации как переход к микросервисной архитектуре, использование продуктового подхода и EDA. Нетрудно заметить, что при реализации новых технологических решений в парадигме микросервисной архитектуры монолитный BPM-движок становится узким местом в части скорости разработки: каждая информационная система в микросервисной парадигме разрабатывается несколькими продуктовыми командами, что в свою очередь предъявляет серьезные требования к развитию BPM-движка. Нельзя не отметить, что резко возросшие требования к производительности создаваемых решений предъявляют качественно иные требования к масштабированию всех компонентов ИТ-ландшафта, в том числе BPM-движку.

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

Для иллюстрации взят пример продукта – электронной банковской гарантии – и один бизнес-процесс – заведение банковской гарантии. В соответствии с ранее представленными подходами к проектированию, управление бизнес-процессом реализовано в формате микросервиса. Отметим, что бизнес-процесс как управляющий компонент (в отличие от компонентов, непосредственно выполняющих бизнес-действия), вынесен за пределы продуктовой области и взаимодействует с продуктовыми микросервисами посредством платформы событийного обмена. Структура автоматизации продуктовых бизнес-процессов выглядит следующим образом:

Рисунок 16. BPM-движок в микросервисной архитектуре

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

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

• BPM-движок должен либо обладать высокой производительностью, либо предоставлять широкие возможности масштабирования (рекомендуемым является сочетание возможностей).

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

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

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

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

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