Архитектура и бизнес-процессы

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

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

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

• Моделирование процесса при помощи наглядных визуальных средств (полнота поддержки BPMN-нотации может варьироваться в зависимости от конкретного моделирующего средства).

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

• Автоматизированное выполнение шагов процесса в соответствии с заданным алгоритмом.

• Назначение ролей, ответственных за этапы выполнения процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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