Шестеренки современного банка крутятся в соответствии с финансовыми бизнес-процессами. Они сложнее обычных — это правило работает для всего, к чему вы добавите определение «финансовые». С одной стороны, все усложняют регуляторы, бессчетное количество согласований и вовлеченных сторон. С другой — неповоротливые монолитные BPMS (Business Process Management System). В этом посте мы расскажем, как успешно забросили одну такую систему и ушли в гибкий и функциональный open source.
Программисты отображают бизнес-процессы с помощью разных нотаций. Сейчас стандартом является BPMN (Business Process Model and Notation) — это XML-файлы с привязанными к ним изображениями. Для работы с этой нотацией создаются продукты BPMS — монолитные проприетарные системы, которые стараются вместить в себя максимум инструментов для разработки BPM: от редактора пользовательского интерфейса до системы контроля версий.
Расширить их могут только разработчики, которые уже давно работают с этими системами. В энтерпрайзных BPMS предусмотрены REST API, то есть к системам можно обращаться и получать в ответ данные. Но модификация и глубокая настройка самой BPMS практически невозможны. Работать с такими BPMS возможно только через ограниченный производителем набор инструментов — проприетарную систему контроля версий, компилятор, деплоер — обычно для каждой крупной BPMS разрабатывается целый набор. Эти инструменты развиваются медленно, от релиза к релизу могут сохраняться одни и те же проблемы, поскольку в работе задействовано не так много человек, как в случае с open source. В целом, возможности энтерпрайзных BMPS и потребности их пользователей совпадают очень редко.
В рекламе таких систем говорят про сквозной workflow, говорят, что бизнес сам может менять BPM-процессы на лету. Но на самом деле такое не под силу даже аналитикам — справятся лишь разрабы.
Бизнес-процесс состоит из пользовательских и сервисных задач, последовательности которых ведут к конечной остановке. В BPMS через такие схемы можно отслеживать время выполнения бизнес-процессов, а также разные бизнес-показатели — например KPI.
Изменения разного масштаба в бизнес-процессы нам приходится вносить частенько. Раньше у нас был BPM-процесс для клиентских менеджеров, которые сидят в дополнительных офисах. В 2015 году мы часть офисов закрыли, а менеджеров перевели на выездную работу. Это потребовало больших изменений в BPM-процессах, нужно было вводить другие роли, действия. Или, например, изменился регламент службы экономической безопасности, и вместо двух согласующих теперь стало три.
Сначала мы вносили изменения через BPMS IBM Lombardi. Собрав типичные недостатки систем своего класса, она отличалась еще и отсутствием упорядоченной документации. Создавалось впечатление, что после покупки Lombardi Software софтверный гигант взглянул на аморфное облако сопроводительных статей и решил ничего не трогать. И даже перечитав всю документацию, нельзя было сделать многие вещи. Например, вызвать REST-запрос с HTTPS-аутентификацией по пользовательскому сертификату. К счастью, поиски альтернативы увенчались успехом.
После работы с IBM BPM мы пришли к тому, что разные группы пользователей должны уметь менять бизнес-процессы. Что-то незначительное в онлайн-режиме могут вносить обычные сотрудники бизнес-подразделений. Системные аналитики изменяют последовательность задач в бизнес-процессах. Новые интеграции, изменения в UI и программный код остаются на стороне разработчиков. А чтобы поддерживать такую гибкость, вся BPMS должна быть развернута на микросервисах.
Такой подход мы можем обеспечить с помощью open-source BPMS Camunda. Она представляет собой форк проекта Activity, который группа разработчиков решила сделать более продаваемым. Они привели в порядок документацию и стали развивать Camunda отдельно, зарабатывают на продаже поддержки.
BPMS Camunda позволяет редактировать бизнес-процессы с помощью обычного Java и поддерживает разделение на микросервисы. Переход BPMS на микросервисы дает сразу несколько преимуществ:
В будущем мы планируем перевести на Camunda один из крупнейших наших бизнес-процессов — корпоративное кредитование. Здесь все гораздо сложнее чем у физлиц и даже чем у малого/среднего бизнеса. Применяется не продуктовая, а лимитная схема кредитования, лимиты ограничены по времени, заемщики обычно входят в более крупные организации типа холдингов, а холдинги еще во что-то. Лимиты определяются отдельно для каждой из этих структур, и в каждой структуре есть свои согласующие, состав которых постоянно меняется. Получаем бизнес-процесс из сотен стадий. Мы смогли изменить его с помощью Camunda и решили остаться на ней. Даже если разработчики решат сейчас закрыть проект, текущих возможностей системы хватит еще года на три.
Наша первая версия Camunda стояла на Websphere и по сути мало чем отличалась от IBM Lombardi. Сами приложения, к которым обращался сервис, мы решили написать на Spring Boot. Они деплоились на Tomcat и самостоятельно не работали. Потом оказалось, что Camunda может работать на Tomcat, была разработана версия для Spring Boot. Там же уже стала доступна полноценная микросервисная архитектура. Все приложения, с которыми работал бизнес-процесс, были реализованы на микросервисной архитектуре на основе Spring Cloud.
Затем выяснилось, что быстро менять функциональность можно не только в сервисах, которые обслуживают бизнес-процесс. Сам движок BPM можно подключить к любому springboot-приложению в виде библиотеки.
Camunda как микросервис
Возник вопрос: сколько микросервисов поднимать? Можно было делать на каждый процесс один сервер, и там расположить все микросервисы, либо под каждую задачу сделать свой микросервис и в нем отдельный бизнес-процесс. Второе было бы удобнее, но пришлось бы организовать взаимодействие процессов, разбросанных по отдельным микросервисам. Мы попробовали несколько вариантов и остановились на решении, когда несколько микросервисов отвечает за определенную тематику и там сгруппированы несколько процессов. Общение происходит либо через REST, либо через Rabbit MQ. Сейчас еще запустили пилот на Kafka.
Бизнес-процессы не только отображают бизнес-воркфлоу, но реагируют на события, происходящие в остальных системах. У нас эти события аккумулирует отдельное подразделение Big Data. По итогам анализа этих событий создаются новые бизнес-процессы или изменяются уже существующие — это происходит постфактум, с периодичностью, например, раз в сутки.
В идеале бизнес-процессы должны переходить к тому, чтобы изменяться в режиме онлайн — например при увеличении спроса на определенные услуги автоматически приоритезировать их выполнение и перераспределять ресурсы. Этого можно достичь с помощью автоматизации, взаимодействия, например, Kafka и Camunda, но это вопрос как минимум нескольких лет. Пожалуй, сейчас в сторону изменений в онлайн-режиме больше всего продвинулся полностью онлайновый английский Monzo Bank. И мы тоже над этим работаем.
Программисты отображают бизнес-процессы с помощью разных нотаций. Сейчас стандартом является BPMN (Business Process Model and Notation) — это XML-файлы с привязанными к ним изображениями. Для работы с этой нотацией создаются продукты BPMS — монолитные проприетарные системы, которые стараются вместить в себя максимум инструментов для разработки BPM: от редактора пользовательского интерфейса до системы контроля версий.
Расширить их могут только разработчики, которые уже давно работают с этими системами. В энтерпрайзных BPMS предусмотрены REST API, то есть к системам можно обращаться и получать в ответ данные. Но модификация и глубокая настройка самой BPMS практически невозможны. Работать с такими BPMS возможно только через ограниченный производителем набор инструментов — проприетарную систему контроля версий, компилятор, деплоер — обычно для каждой крупной BPMS разрабатывается целый набор. Эти инструменты развиваются медленно, от релиза к релизу могут сохраняться одни и те же проблемы, поскольку в работе задействовано не так много человек, как в случае с open source. В целом, возможности энтерпрайзных BMPS и потребности их пользователей совпадают очень редко.
В рекламе таких систем говорят про сквозной workflow, говорят, что бизнес сам может менять BPM-процессы на лету. Но на самом деле такое не под силу даже аналитикам — справятся лишь разрабы.
Бизнес-процесс состоит из пользовательских и сервисных задач, последовательности которых ведут к конечной остановке. В BPMS через такие схемы можно отслеживать время выполнения бизнес-процессов, а также разные бизнес-показатели — например KPI.
Изменения разного масштаба в бизнес-процессы нам приходится вносить частенько. Раньше у нас был BPM-процесс для клиентских менеджеров, которые сидят в дополнительных офисах. В 2015 году мы часть офисов закрыли, а менеджеров перевели на выездную работу. Это потребовало больших изменений в BPM-процессах, нужно было вводить другие роли, действия. Или, например, изменился регламент службы экономической безопасности, и вместо двух согласующих теперь стало три.
Сначала мы вносили изменения через BPMS IBM Lombardi. Собрав типичные недостатки систем своего класса, она отличалась еще и отсутствием упорядоченной документации. Создавалось впечатление, что после покупки Lombardi Software софтверный гигант взглянул на аморфное облако сопроводительных статей и решил ничего не трогать. И даже перечитав всю документацию, нельзя было сделать многие вещи. Например, вызвать REST-запрос с HTTPS-аутентификацией по пользовательскому сертификату. К счастью, поиски альтернативы увенчались успехом.
Camunda решает проблемы
После работы с IBM BPM мы пришли к тому, что разные группы пользователей должны уметь менять бизнес-процессы. Что-то незначительное в онлайн-режиме могут вносить обычные сотрудники бизнес-подразделений. Системные аналитики изменяют последовательность задач в бизнес-процессах. Новые интеграции, изменения в UI и программный код остаются на стороне разработчиков. А чтобы поддерживать такую гибкость, вся BPMS должна быть развернута на микросервисах.
Такой подход мы можем обеспечить с помощью open-source BPMS Camunda. Она представляет собой форк проекта Activity, который группа разработчиков решила сделать более продаваемым. Они привели в порядок документацию и стали развивать Camunda отдельно, зарабатывают на продаже поддержки.
BPMS Camunda позволяет редактировать бизнес-процессы с помощью обычного Java и поддерживает разделение на микросервисы. Переход BPMS на микросервисы дает сразу несколько преимуществ:
- Избавление от монолита. Мы можем разделить бизнес-процессы по сегментам, связывая их между собой с помощью Rabbit MQ или Kafka через очереди. Бизнес-процессы можно менять изолированно друг от друга, накатывать изменения, не дожидаясь полного релиза.
- Избавление от сервера бизнес-процессов.
- Масштабирование. Если под нагрузкой начинает падать какой-то из серверов, то его можно клонировать. При пиковых нагрузках можно легко нарастить производительность, запустив несколько экземпляров бизнес-процессов в разных сервисах.
- Версионность. Если, например, необходимо обновить версию Java, можно поднять несколько микросервисов с разными версиями Java и параллельно запустить новую версию. В каждом микросервисе могут быть не только разные версии софта, но и разные языки.
В будущем мы планируем перевести на Camunda один из крупнейших наших бизнес-процессов — корпоративное кредитование. Здесь все гораздо сложнее чем у физлиц и даже чем у малого/среднего бизнеса. Применяется не продуктовая, а лимитная схема кредитования, лимиты ограничены по времени, заемщики обычно входят в более крупные организации типа холдингов, а холдинги еще во что-то. Лимиты определяются отдельно для каждой из этих структур, и в каждой структуре есть свои согласующие, состав которых постоянно меняется. Получаем бизнес-процесс из сотен стадий. Мы смогли изменить его с помощью Camunda и решили остаться на ней. Даже если разработчики решат сейчас закрыть проект, текущих возможностей системы хватит еще года на три.
Наша первая версия Camunda стояла на Websphere и по сути мало чем отличалась от IBM Lombardi. Сами приложения, к которым обращался сервис, мы решили написать на Spring Boot. Они деплоились на Tomcat и самостоятельно не работали. Потом оказалось, что Camunda может работать на Tomcat, была разработана версия для Spring Boot. Там же уже стала доступна полноценная микросервисная архитектура. Все приложения, с которыми работал бизнес-процесс, были реализованы на микросервисной архитектуре на основе Spring Cloud.
Затем выяснилось, что быстро менять функциональность можно не только в сервисах, которые обслуживают бизнес-процесс. Сам движок BPM можно подключить к любому springboot-приложению в виде библиотеки.
Возник вопрос: сколько микросервисов поднимать? Можно было делать на каждый процесс один сервер, и там расположить все микросервисы, либо под каждую задачу сделать свой микросервис и в нем отдельный бизнес-процесс. Второе было бы удобнее, но пришлось бы организовать взаимодействие процессов, разбросанных по отдельным микросервисам. Мы попробовали несколько вариантов и остановились на решении, когда несколько микросервисов отвечает за определенную тематику и там сгруппированы несколько процессов. Общение происходит либо через REST, либо через Rabbit MQ. Сейчас еще запустили пилот на Kafka.
Перспективы BPMS
Бизнес-процессы не только отображают бизнес-воркфлоу, но реагируют на события, происходящие в остальных системах. У нас эти события аккумулирует отдельное подразделение Big Data. По итогам анализа этих событий создаются новые бизнес-процессы или изменяются уже существующие — это происходит постфактум, с периодичностью, например, раз в сутки.
В идеале бизнес-процессы должны переходить к тому, чтобы изменяться в режиме онлайн — например при увеличении спроса на определенные услуги автоматически приоритезировать их выполнение и перераспределять ресурсы. Этого можно достичь с помощью автоматизации, взаимодействия, например, Kafka и Camunda, но это вопрос как минимум нескольких лет. Пожалуй, сейчас в сторону изменений в онлайн-режиме больше всего продвинулся полностью онлайновый английский Monzo Bank. И мы тоже над этим работаем.
