Определение подходов к автоматизации бизнес-процессов и связанный с этим выбор конкретных технологий, особенно в крупной организации, - комплексная задача, которая требует учитывать экономические, организационные, функциональные, технические и другие аспекты. Сегодня на рынке существует множество BPM-технологий самого разного масштаба - от легковесных библиотек до крупных платформ. В этой статье мы подготовили сравнительный анализ двух очень непохожих представителей из разных областей этого спектра - Pega и Camunda. По каждой из этих технологий мы, ЛАНИТ - Би Пи Эм, накопили немалый опыт использования и наработали портфолио крупных корпоративных решений. Среди них есть проекты по автоматизации кредитных конвейеров и других бизнес-процессов в крупнейших банках РФ (Сбербанк, ВТБ, Альфа-Банк). Есть проекты как с монолитной, так и с распределенной, микросервисной архитектурой.

Если кратко, Pega - экосистема для IT-поддержки процессного подхода в бизнесе, а Camunda - набор инструментов для реализации процессных приложений.

Функциональная полнота

Pega - low-code платформа для создания корпоративных приложений и автоматизации процессов, обеспечивающая:

• моделирование комплексных бизнес-процессов,

• создание пользовательских интерфейсов (с поддержкой как веб-, так и мобильных клиентов),

• интеграцию с внешними системами,

• реализацию отчетности,

• настройку политик безопасности,

• конфигурирование организационной структуры, бизнес-календарей, профилей пользователей и др.

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

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

Camunda - легковесное специализированное решение на Java, предназначенное в первую очередь для моделирования бизнес-процессов. Оно не обладает многими сопутствующими возможностями, которые есть в Pega (реализация интеграции, отчетности, поддержка разработки и др.), или имеет ограниченные возможности в соответствующих областях (хранение данных, decisioning, UI).

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

Резюме

Pega - полнофункциональная платформа, поддерживающая практически все этапы и аспекты жизни реализуемого решения и IT-проекта.

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

Стоимость приобретения и использования

Pega - платформа с закрытым кодом и платным лицензированием для коммерческого использования.

Camunda - open-source решение, версия Community Edition доступна с лицензиями Apache и MIT и включает в себя все компоненты, необходимые для полноценного использования Camunda в коммерческих проектах. Также есть версия Enterprise Edition, доступная с платной лицензией и включающая в себя дополнительные инструменты и расширенную поддержку. Детали доступны на сайте вендора.

BPM-технология в контексте принципов корпоративного IT

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

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

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

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

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

Существует огромное количество различных аспектов, которым нужно уделить внимание. Среди наиболее очевидных можно выделить следующие.

Открытость технологии

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

Camunda - open-source-решение на базе Java, есть опциональные платные инструменты (Optimize, Cawemo). 

Поддержка 

Pega: на портале вендора в открытом доступе содержится большой объем документации по платформе. Параметры поддержки (SLA) со стороны вендора определяются условиями лицензионного соглашения.

Camunda: на портале вендора в открытом доступе содержится большой объем документации, помимо этого существуют форумы и прочие информационные ресурсы, на которых разработчики могут найти ответы на свои вопросы. Коммерческая поддержка с определенным SLA со стороны вендора доступна под платной лицензией. Также существует некоторая специфика в релизной политике вендора для Community- и Enterprise-версий.

Методология ведения проектов

Pega предлагает (но не принуждает использовать) собственную методологию Pega Express, включающую в себя как общепринятые практики Scrum, так и ряд собственных подходов (например, DCO - Direct Capture of Objectives); эта методология на всем протяжении жизненного цикла проекта поддерживается разнообразным инструментарием - Pega Agile Studio, Pega DevOps и др.

Camunda не предлагает собственных методологий.

Процесс и средства разработки

Pega - это low-code-платформа, поэтому создание приложений на ней практически не требует написания кода на каком-либо языке (лишь в исключительных случаях может быть полезно написание небольшого объема Java- или JavaScript-кода), в целом процесс скорее напоминает визуальное конструирование: разработчик в браузере конфигурирует все аспекты приложения (UI, бизнес-логику, интеграции, отчеты, и т.д.) посредством создания и настройки так называемых "моделей", относящихся к соответствующим функциональным типам.

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

Хранилищем всех созданных программных артефактов (вместе со всеми ветками разработки / branches) тоже является инсталляция платформы, внешние хранилища не нужны.

Для сборки и поставки также можно использовать средства платформы - Pega DevOps.

Camunda: её среда исполнения процессов (BPMN engine) является Java-библиотекой, которую можно включить в состав разрабатываемого Java-приложения (например, на SpringBoot). Соответственно, процесс разработки с использованием Camunda ничем не отличается от работы над любым Java-проектом, при которой разработчики:

• пишут и отлаживают Java-код в IDE,

• хранят исходный код в системе управления версиями,

• собирают и делают поставки с помощью CI/CD-инструментария.

Спецификой Camunda в данном процессе является использование собственного инструментария для написания BPMN-диаграмм и DMN-правил - Camunda Modeler, это отдельное бесплатное desktop-приложение. 

Vendor lock-in

Ситуация привязки к поставщику (vendor lock-in) в том или ином масштабе возникает при использовании любого вендорского ПО. Заказчика прежде всего беспокоит:

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

• технологическая зависимость - имеет множество собственных проявлений, в том числе:

• сложность миграции с выбранной технологии на другие,

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

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

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

• зависимость от поддержки вендора, влияющая на качество работы с инцидентами.

Если проанализировать обе технологии с точки зрения указанных характеристик, то можно заключить, что негативные последствия от vendor lock-in будут заметно меньше в случае использования Camunda. Это неудивительно, учитывая, что Camunda представляет собой просто набор open-source библиотек и приложений, тогда как Pega является закрытой low-code платформой с высоким порогом входа и существенно большим влиянием на IT- и бизнес-ландшафт организации-заказчика.

С точки зрения бизнес-заказчика: от требований к результатам

Средства для совместной работы с требованиями

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

• Упрощение передачи требований от бизнес-заказчика через аналитиков к разработчикам.

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

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

Обе технологии имеют в своем составе средства, поддерживающие командную работу с требованиями:

Pega предлагает инструмент Pega Agile Studio, который технически является самостоятельным приложением на платформе Pega. Данный продукт позиционируется вендором как средство комплексной поддержки командной работы над проектом по методологии scrum. Pega Agile Studio содержит инструментарий по управлению требованиями, включая поддержку собственных методологических подходов (например, DCO - Direct Capture of Objectives), реализует интеграцию со средами разработки, а также позволяет управлять спринтами, бэклогами, релизами, плюс имеет средства по учету трудозатрат и реализации управленческой отчетности и т.д. Фактически Pega Agile Studio претендует на роль как инструмента совместной работы с требованиями, так и средства управления проектом. Однако практическая применимость этого инструмента очевидно требует отдельного анализа в каждом конкретном проекте.

Camunda предлагает инструмент Cawemo, который технически является отдельной системой, предоставляющей пользователям web-интерфейс. Он обеспечивает совместную работу всех заинтересованных участников с BPMN-диаграммами процессов, с возможностью комментирования, каталогизации, ведения версий, интеграции с Confluence, а также с поддержкой двусторонней синхронизации со стеком разработки (Camunda Modeler).

Мониторинг и оптимизация бизнес-процессов

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

Для решения данной задачи у каждой технологии есть соответствующие средства.

Pega предлагает специализированное решение Workforce Intelligence, с помощью которого можно как получать информацию о работе существующих процессов, так и анализировать возможные решения по их оптимизации. Кроме того, в рамках базовой платформы есть средства для сбора статистики и формирования на её основе разнообразной отчетности по бизнес-производительности (https://community.pega.com/knowledgebase/articles/reporting/85/report-categories). 

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

С точки зрения IT: технические характеристики и возможности технологий

Архитектура

Pega - платформа, реализованная в виде самостоятельного Java-приложения, поставляемого вендором в формате архива (.ear или .war) или Docker-образа. Платформа работает в рамках JEE-сервера (WebSphere, WebLogic, JBoss) или контейнера сервлетов (Tomcat).

Общая архитектура платформы представлена на следующей схеме:

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

Внутренняя архитектура ядра платформы (компонент Pega Engine на диаграмме выше) представлена на следующей схеме:

Ядро Pega написано на Java, однако, с точки зрения прикладного разработчика, платформа является low-code-средой, т.е. разработчик не пишет Java-код, а описывает все аспекты приложения (UI, бизнес-логику, интеграции, отчеты, и т.д.) в виде набора моделей (model). Модели внутри приложения располагаются в структурированной иерархии классов, задаваемой разработчиком; платформа поддерживает основные принципы ООП: наследование, полиморфизм, инкапсуляция. Также вендор в своих обучающих и сертификационных материалах обобщает лучшие практики и подходы (в том числе паттерны проектирования на платформе Pega, например, ECS - Enterprise Class Structure), которые рекомендует к использованию в реальных проектах. 

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

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

Camunda может использоваться в составе прикладных решений либо как внедренный (embedded) компонент, либо как отдельно работающий (standalone) сервер. В первом случае Camunda подключается к Java-приложению как библиотека, во втором - выполняется как отдельное приложение. 

Общая архитектура Camunda представлена на следующей схеме:

Внутренняя архитектура ядра (компонент Engine на диаграмме выше) представлена на следующей схеме:

• Process Engine Public API: программный интерфейс, посредством которого прикладной код взаимодействует с ядром Camunda. Интерфейс разделен на сервисы, отвечающие за свои функциональные области (конфигурация процессов, взаимодействие с работающими экземплярами процессов, управление задачами и т.д.).

• BPMN 2.0 Core Engine: ядро Camunda. Оно базируется на PVM (Process Virtual Machine) - среде исполнения графовых структур, в состав которой входит парсер BPMN-схем, преобразующий XML-файлы в формате BPMN 2.0 в Java-объекты, а также набор реализаций BPMN-объектов (таких как Gateway или Service Task).

• Job Executor: компонент, ответственный за исполнение фоновых задач (таких, как таймеры и асинхронное возобновление выполнения процессов).

• Persistence Layer: ORM-слой на базе MyBatis, выполняющий хранение состояния выполняемых экземпляров процессов в реляционной БД.

Архитектура прикладных решений

Pega исторически использовалась и продолжает использоваться для реализации крупномасштабных решений с монолитной архитектурой. Как говорилось ранее, платформа поддерживает основные принципы ООП, а также выделение общих компонентов и библиотек. Все это позволяет адекватно структурировать прикладные приложения практически любой сложности. Однако Pega позиционирует себя и как платформа для реализации решений с микросервисной архитектурой (https://www.pega.com/insights/resources/delivering-microservices-benefits-pega), хотя её подходы в этой области очевидно имеют свою специфику.

Camunda не накладывает никаких ограничений и может использоваться в составе прикладных решений с любой архитектурой - монолитной, микросервисной, с выделенным BPM-приложением (“выделенный сервер”, см. далее) и др. Единственно, вендор рекомендует взвешенно относиться к идее построить "BPM-фреймворк для всего", т.к. такое решение несет риски с точки зрения гибкости и ожиданий пользователей и бизнес-заказчика (https://camunda.com/best-practices/estimating-effort/#building-a-custom-bpm-platform).

Масштабирование решений

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

Для иллюстрации ниже приведена диаграмма развертывания платформы в кластере Kubernetes (https://community.pega.com/knowledgebase/articles/client-managed-cloud/85/understanding-pega-deployment-architecture):   

Приведем основные принципы развертывания платформы в подобной конфигурации.

• Все узлы Pega разворачиваются из одного и того же Docker image, и содержат полный платформенный функционал (BPM engine и т.д.).

• Узлы можно параметризовать (механизм node classification) с тем, чтобы разделить их по типам (на схеме - Exposed Nodes, Background Nodes, Embedded Kafka).

• Прикладной функционал можно средствами платформы Pega разделить на логические группы компонентов, и каждую такую группу назначить на тот или иной тип узла, например, UI-компоненты выполняются на Exposed Nodes и доступны извне через балансировщик/ingress, а бизнес-логика процессов выполняется на Background Nodes. Это база для резервирования и независимого масштабирования компонентов во время исполнения.

• БД является общей для всех узлов Pega.

Camunda также поддерживает кластеризацию и контейнерное исполнение, при этом масштабируемость существенным образом зависит от способа, которым Camunda используется в конкретном прикладном решении (см. https://docs.camunda.org/manual/7.13/introduction/architecture/).

• Embedded-режим: Camunda включается в приложение как Java-библиотека, и соответственно масштабируемость всего решения определяется его общей архитектурой (она может быть и монолитной, и микросервисной).

• Разделяемый сервис в рамках одного JEE-контейнера: Camunda выполняется в форме отдельного приложения в рамках того же JEE-контейнера (servlet container или application server), что и прикладные Java-приложения, которые его используют.

• Выделенный сервер: Camunda выполняется в форме отдельно работающего сервера и доступна приложениям как сетевой сервис (через REST API).

• Также поддерживается режим масштабирования, при котором несколько экземпляров Camunda работают с общей БД.

Моделирование бизнес-процессов

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

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

На картинке ниже показан пример кейса в Pega Case Designer (в данном случае это ипотечный процесс):

Ниже показан один из этапов (stage) этого кейса - Review Proposal. Он является третьим этапом кейса ("3. Proposal", см. выше) и реализуется как модель типа Flow: 

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

Camunda представляет бизнес-процессы в виде диаграмм в нотации BPMN 2.0, поддерживается большинство элементов нотации (детально покрытие описывается здесь: https://docs.camunda.org/manual/latest/reference/bpmn20/). Для реализации сложных кейсов имеются возможности по разнообразной координации выполняющихся процессов (запуск подпроцессов, параллельное исполнение, обмен сигналами и т.д.).

Конфигурирование схем процессов выполняется в графическом виде в отдельном desktop-приложении - Camunda Modeler, откуда схемы выгружаются в виде XML-файлов и могут быть включены как ресурсы в Java-приложение. Бизнес-логика приложения реализуется на Java обычным образом в любой среде разработки.

Кроме BPMN 2.0 Camunda также поддерживает подмножества нотаций CMMN 1.1 (https://docs.camunda.org/manual/latest/reference/cmmn11/) и DMN 1.3 (https://docs.camunda.org/manual/latest/reference/dmn/).

Реализация UI

Pega, являясь высокоинтегрированной средой, содержит также и разнообразные средства по реализации пользовательских интерфейсов. Как и все прочие аспекты приложения, UI создается в виде набора моделей и конфигурируется интерактивным образом. Платформа содержит готовый набор UI-компонентов и шаблонов (Pega Cosmos), а также проработанный свод рекомендаций по построению UI/UX.

Помимо собственных средств визуализации, имеющихся у платформы, бизнес-приложение может использовать и любые другие средства построения пользовательских интерфейсов (например, фреймворки React или Angular). Для интеграции со сторонним UI в таких сценариях у платформы Pega есть набор REST-интерфейсов (Digital Experience API). 

Важным преимуществом платформы является развитая поддержка разнообразных клиентских устройств (omnichannel user experience) - desktop браузер, планшеты, смартфоны, причем эта поддержка реализована прозрачно с точки зрения прикладного разработчика: она не требует отдельных усилий по конфигурации UI для разных клиентов, и пользовательский интерфейс автоматически подстраивается под каждый из них "на лету". С технической точки зрения для мобильных клиентов платформа реализует ряд подходов (https://community.pega.com/knowledgebase/documents/pega-platform-architecture-and-technical-brief):

• HTML-интерфейс (HTML 5.0 + JavaScript), адаптированный под мобильные устройства,

• Native-приложение Pega под iOS и Android,

• Mashup: набор библиотек под iOS и Android, содержащих API SDK для платформы Pega, которые можно подключить в стороннее мобильное приложение.

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

• Tasklist (список задач пользователя);

• Cockpit (мониторинг и администрирование процессов).

Очевидно, такой подход нельзя считать универсальным, поэтому приложения, использующие данную технологию и требующие развитого пользовательского интерфейса, практически неизбежно должны полагаться на самостоятельно реализованный UI, благо Camunda является очень открытой технологией с развитыми API.

Вместо вывода

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

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

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

В прошлом году мы провели исследование последней версии платформы Pega 8.6, все подробности можно посмотреть здесь. 

ВАКАНСИИ

Разработчик Pega

Системный аналитик

PR-менеджер

Java developer

Java Team lead