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

Вместе с тем, подобный подход несет в себе некоторые риски:

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

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

Таким образом, при осуществлении технического рефакторинга выполняются следующие основные задачи:

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

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

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

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

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

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

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

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

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

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

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