company_banner

Как мигрировать большой процесс с IBM BPM на Camunda и не останавливать разработку фич

    image

    Привет, меня зовут Денис, я работаю в Тинькофф и занимаюсь BPM-системами. В этой статье я расскажу, как мигрировать с легаси систем а-ля IBM BPM на опенсорс движок процессов Camunda на примере большого процесса. А в конце приглашу вас на четвертый митап по Camunda, который пройдет 27 февраля в Тинькофф, в Москве (м. Водный Стадион) вечером.


    BPMS-системы и BPMN как способ их программировать


    Идея про то, что через схемки можно программировать, хорошо продается, рынок растёт из года в год. Некоторые предприятия получают действительно классные результаты.
    Чтобы делать хорошие проекты и успешно продаваться, BPMS-системы, помимо “поедания” BPMN-файлов, еще должны уметь:
    • Определять конкретных исполнителей в процессах
    • Предоставлять интерфейсы для пользователей, внедренцев и администраторов
    • Вызывать внешние сервисы, слать и слушать события и т.д. В целом уметь “проваливаться” в код
    • Обеспечивать моделирование и хранение данных
    • Выполнять бизнес-правила
    • Тестировать всё созданное

    У нас в Тинькофф использовалась BPMS IBM BPM, которая помогала нам развиваться за счёт своей комплексности и приемлемого покрытия указанных фич. Но мы решили от неё отказаться.

    Причины отказа от IBM BPM


    Мы поняли, что от большого функционала BPMS системы мы используем только:
    • Интерпретация bpmn-файлов
    • Проваливание в код

    Прочие вещи были вынесены в другие системы, например:
    • Определение исполнителей зависит не только от конкретного процесса, но от множества факторов — больничные, отгулы, потенциальная выгода по конкретной заявке и так далее. Определение исполнителя в таком сценарии требует слишком много контекста, который не уживается в BPMS. По некоторым продуктам мы написали отдельные системы для определения исполнителей, а для некоторых — используем встроенные возможности CRM Siebel.
    • Предоставление интерфейсов тоже уехало в Siebel или самописные CRM-системы. В Siebel как единую систему работы операционных сотрудников, а в самописные системы — потому что нужно было уметь делать что-то красивое и современное на UI.
    • Хранение данных где-то переехало в Siebel — в ситуациях, когда множеству потребителей нужны CRUD-операции над данными, а где-то — в отдельные приложения. IBM BPM позволяет моделировать данные в реляционном стиле, сам создает таблички под модели. Но хранит это всё в одной базе для всех процессов, что создает дополнительную связность и нагрузку на базу.
    • Для бизнес-правил традиционно используем IBM ODM, а сейчас начинаем использовать свой фреймворк на Kotlin.
    • Нормально, в девелоперском стиле, тестировать приложения на IBM BPM мы так и не научились.

    Были и общие вопросы, которые нам не нравились:
    • Мы перешли на Kotlin и Spring, с этим сложно в IBM BPM.
    • Очень мало специалистов или желающих работать c этим продуктом.
    • Сложности совместной разработки схем\кода, по существу монопольный режим разработки.
    • Здоровенный кластер из 4 нод требовал перезагрузки на 3 часа ( ~40 минут на ноду), что дико неудобно.

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

    Например, был код отправки смсок, которым пользовались 2 продукта — РКО и аутсорсная бухгалтерия. Раньше текст был захардкожен на уровне компонента, но теперь процессу “аутсорсной бухгалтерии” захотелось передавать текст смс-ки из процесса. А процессу РКО этого не хотелось, но изменения надо вносить везде.

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

    Почему выбрали Camunda мой коллега Николай писал в предыдущем посте.


    Что такое большой процесс


    Мы решили перенести крупный процесс из IBM (сначала, правда, потренировались на маленьком):
    • Больше 100к инстансов в месяц.
    • Больше 70 квадратиков
    • Больше 30 интеграций с другими системами
    • Быстрорастущий бэклог

    Это процесс открытия расчётного счёта в Тинькофф Бизнес. Такой процесс перенести за один подход не получалось, требовалось бы пауза на 3-4 месяца в разработке, что не очень подходит темпам развития бизнеса.
    Мы решили переезжать по кускам и рефакторить всё, что попадется под руку. А чтобы решить проблему шумных соседей, мы сделали отдельное приложение, которое отвечало только за заявки на РКО.

    На верхнем уровне процесс выглядит так:
    image

    Правила перехода


    №1: Перестали копать


    Мы решили перестать делать новые фичи в старом приложении. Когда в беклоге появилась задача, мы старались идентифицировать квадратик\компонент\сервис к которому он относится и переписывали эту штуку с нуля в Camunda. Иногда по стоимости это было 1.2х (х — если бы делали в IBM), иногда — 3х или 5х.

    №2: Camunda ничего не знает про IBM


    После рефакторинга мы хотели просто выключить старое приложение, поэтому решили новые фичи делать в Camunda так, чтобы она вообще ничего не знала про IBM. Нам помогли две вещи:
    • Бизнес-данные хранились в Siebel
    • Готовые API от Camuda, которые помогают полноценно понять, чем и как завершился процесс.

    В итоге мы сделали процесс в IBM, который запускает и получает результат от Camunda:
    image

    №3: Долгие “ручные задачи” и склеивание процессов


    Сначала мы перенесли простые, одношаговые синхронные вызовы в Camunda и всё работало хорошо. После этого мы стали склеивать эти штуки в нормальные “бизнес-процессы”, где стало появляться ожидание от пользователей.
    Пользователи могут делать свои задачи годами, поэтому у нас начала сыпаться куча задач на ручное исправление процессов из трешхолда. Победили так — просто стали учитывать тип конкретной задачи в Camunda и не учитывать трешхолд на задачах, где возможно долгое ожидание.

    №4: Feature toggling на развилках


    Некоторые куски кода были такие замороченные, что проще было написать с нуля и посмотреть “нормально ли работает”. Для этого ввели в IBM feature toggling со шлюзами. Направляли небольшой поток заявок в Camuda и смотрели ручками, всё ли ок.
    image

    Миграция инстансов из IBM в Camunda


    В конечном счёте процесс в IBM состоял только из вызовов Camunda, а в Camunda была собрано 3 уровня процессов. Сами бизнес-процессы не сильно поменялись, поэтому у нас получилось перенести старые инстансы из IBM в Camunda на те же точки ожидания. И выключить IBM.
    image

    Что делать, если у вас похожая ситуация


    Если хотите переехать на Camunda с легси BPMS, то:
    • Перенесите контекст в отдельную базу.
    • Перенесите пользовательские интерфейсы в отдельное приложение.
    • Перестаньте кодить новый функционал в старом приложении.
    • Используйте односторонние вызовы так, чтобы Camunda не знала о старой системе.
    • Начните с маленьких квадратиков, но не забывайте о длинных пользовательских задачах.

    Такой подход помог нам сократить количество инцидентов в 14 раз, время регресса в 4 раза, дал возможность релизить день-в-день и сократил затраты на ручное тестирование в 4 раза. Сейчас над проектом работает 5 человек и делает такой же объем работы, как 9 человек с IBM. Надеюсь, результаты у вас будут не хуже.

    Приглашение на митап №4 по Camunda


    27 февраля 2020 (четверг) в 19:30 по адресу Москва, Головинское шоссе 5А, бизнес-центр «Водный» проведём очередной митап по Camunda. Зарегистрироваться и прочитать про докладчиков можно по ссылке. Приходите!
    Tinkoff.ru
    IT’s Tinkoff.ru — просто о сложном

    Comments 13

      +1
      А как в Camunde покрывается проблема
      Сложности совместной разработки схем\кода, по существу монопольный режим разработки.

      ? извините, если не по статье вопрос.
        0
        Вполне по теме.

        Мы используем Camunda как зависимость в проекте, поэтому весь код живёт как у людей — в Git.
        С BPMN-файлами (они же XML) примерно так же, только их автоматом не смерджить. Поэтому изредка приходится это делать руками. Если там прям что-то большое, то иногда использую github.com/bpmn-io/bpmn-js-differ
        +1
        Добрый день, Денис. Большое спасибо за статью, как раз хотел увидеть пример успешного внедрения Camunda BPM.
        Несколько не понял, как возник такой профит времени и ресурсе, если в тексте:
        Когда в беклоге появилась задача, мы старались идентифицировать квадратик\компонент\сервис к которому он относится и переписывали эту штуку с нуля в Camunda. Иногда по стоимости это было 1.2х (х — если бы делали в IBM), иногда — 3х или 5х.

        Рискну предположить, что тут сыграл рефакторинг бизнес логики и структуры разработки. Но это проблема разработки и её поддержки, а не платформы.
        По поводу ограничений платформы для разработчика — это в яблочко. Перейти с intellij idea на Eclipse (которым по сути и является IBM Integration Designer) очень тяжело, писать красивый фронт тоже не получится в IBM BPM. Да и специалистов найти — проблема, особенно если учитывать, что система с версиями сильно меняется и порой кампании требуется поддержка старой версии. Это особенность не только IBM BPM, а вообще всех подобных продуктов (Siebel CRM в том числе). Про плюсы данных систем не говорим, это дело отдельной статьи.
        Я понимаю, что есть ряд ограничений по тому, что можно показывать и рассказывать, но, конкретно данный пример кажется крайне абстрактным и выводы связаны не с Camunda, а качественно новым уровнем проектирования информационных систем.
          0
          Профит возник в том, что в итоге стало дешевле и проще разрабатывать, а так же проще найти и замотивировать ребят работать с нормальным стеком.

          Здесь заслуга не только от Camunda, скорее она просто хорошо подошла под наш замысел проектирования, тут я с вами согласен.
            0
            Подскажите, насколько активно идут Java программисты на проект разработки/поддержки проекта на Camunda? По сути, ведь, большая часть кода приложения связана с вызовом Camunda API в том или ином месте и виде.
              0
              Скорее наоборот, это Camunda вызывает код на Java, а не наоборот. За несколько лет только один раз человек отказался работать с Camunda, потому что хотел делать «нормальный код, а не стрелочки двигать». Но за счёт того что это привычный всем спринг и котлин, такого сопротивления, как с IBM, конечно нет.
            0
            Тоже накину. Для процессов на камунде довольно удобно и прикольно писать юнит тесты. Этот момент тоже крайне положительно влияет на разработку и как итог удешевляет ее
            –4
            -Раньше текст был захардкожен на уровне компонента
            -Лицензионные ограничения заставляли нас пихать множество продуктов в один кластер
            -Мы старались переиспользовать общий код внутри разных бизнесовых процессов, что создавало сложности с его модификацией.

            -проще было архитектора заменить, а не движок.
              +1

              А как бы замена архитектора принесла столько же профита, сколько и замена движка?

              0
              Трансляция митапа будет на youtube.com?
                0
                Трансляции не будет, будет запись.
                0
                Для бизнес-правил традиционно используем IBM ODM, а сейчас начинаем использовать свой фреймворк на Kotlin.

                Скажите, почему не использовали встроенный в Camunda (его кстати также можно отдельно вызывать) движок правил DMN или Drools?

                И было бы интересно узнать подход к миграции правил на другую систему, там, как опыт подсказывает, не всегда просто переехать по частям.
                  0
                  Встроенный в камунду иногда используем. Есть неудобства, которые нас не устроили — не весь DMN поддерживается, сложно дебажить и наши правила огромного размера, в них сложно ориентироваться.

                  С друлс тоже самое.

                Only users with full accounts can post comments. Log in, please.