DMN на страже Time To Market

Привет, меня зовут Алексей, я руковожу цифровыми продажами одного из крупнейших региональных банков нашей страны, а специфика моей работы заключается в том, что под моим крылом сконцентрирован и бизнес и it, которые в едином порыве идут к достижению поставленных бизнес показателей. Практический опыт последних лет показал эффективность такой организационной конструкции и я хотел бы поделиться с вами как наша команда совместно шла к планомерному снижению времени поставки новых изменений для клиентов (что называется Time To Market) на примере внедрения использования нотаций принятия решений DMN.

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

Балансировка с точки зрения бизнеса выглядит как набор бизнес правил, в соответствии с которыми мы понимаем нужно ли нам как-то реагировать на порождающее событие и как именно. Бизнес аналитики пишут постановку, системные аналитики переносят её в тз, разработчики реализуют. Всё достаточно стандартно, проблема лишь в следующем:

Если с 1 и 2 проблемами всё достаточно очевидно, то п3 требует некоторых пояснений. Все дело в том, что работа с таким большим количеством правил легко может привести к тому, что вы получите код, содержащий “миллион” if’ов, особенно, если человек, его пишущий ничего не знает про ту же цикломатическую сложность. Это будет код, вызывающий боль у каждого, кто с ним будет работать, его будет трудно писать, трудно тестировать, а еще труднее развивать.

Для бизнеса это всё выливается как минимум в следующее:

Нас это само собой не устраивает, но это именно те реалии, в которых нам пришлось некоторое время существовать.

Ранее у нас был опыт использования BPMN систем для автоматизации бизнес процессов, а конкретно Camunda, мы успешно использовали её в качестве оркестратора в наших микросервисах и первое что мы решили попробовать, это перенести реализацию из кода во flow-процесс.

Получилось лучше, но не достаточно, вот пример для понимания:

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

К счастью для нас ребята из OMG (Object Management Group), которые ранее как раз и придумали BPMN, в далёком сентябре 2015 опубликовали новый стандарт DMN. На момент публикации имевший версию 1.0, а самая последняя его версия (к дате написания статьи) 1.4 beat от марта 2022г, т.е. стандарт живет и развивается, что не может не радовать.

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

Фактически это означает, что используя этот стандарт, мы автоматически избавляемся от проблем из п1 и п2. Уже неплохо, а если посмотреть, что под капотом у нас xml, для которого существуют визуальные редакторы, наподобие Camunda Modeler, то становится совсем отлично, ведь графическое представление гораздо удобнее для работы, нежели чем plain text, не зря же мы все с вами любим презентации и блок схемы.

Давайте на конкретном кейсе разберём, что это такое. Для наглядности я взял пример таблицы решений с сайта consulting.camunda.com/dmn-simulator/ где вы можете с минимальными усилиями на собственно опыте понять что же это такое:

По сути это таблица, в которой определены:

Если обратиться к примеру, то на входе мы имеем два значения - Время года и Количество гостей - для которых заведено 7 правил (по количеству пронумерованных строк). Если входящих значений несколько, то они всегда обрабатываются по конъюнкции (логическое И), т.е. правило на строке 5 говорит о следующем: если сейчас весна и гостей от 5 до 8, то мы выбираем в качестве блюда стейк.

Если посмотреть на значения в столбце Количество гостей, то можно увидеть часть из большого набора встроенных операторов, которые даёт использование языка выражений FEEL (Friendly Enough Expression Language), являющегося частью спецификации.

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

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

Для этого достаточно будет вот такой зависимости в вашем проекте:

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

Что мы, собственно, по итогу и сделали, начав использовать DMN как внутри уже сущестующих bpmn процессов, выполняемых камундой, так и используя camunda-engine-dmn внутри сервисов, для которых подтягивание всей камунды было бы избыточно.

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

Мы начинали с 3 разных групп сотрудников, требуемых для внесения правок по задачам, связанным с изменениями бизнес логики принятия решений и свели это всё к 1 группе. С точки зрения временных трудозатрат, как прямых, так и связанных с рисками недопонимания или некорректной реализации, мы получили выигрыш в среднем около 70% по сравнению с тем что было. Начать деплоить на бой в 3 раза быстрее я считаю отличным результатом.

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

DMN симулятор https://consulting.camunda.com/dmn-simulator/

Online редактор для dmn диаграмм https://demo.bpmn.io/dmn

Camunda Modeler для работы с dmn диаграммами на десктопах https://camunda.com/download/modeler/

Camunda DMN decision engine https://camunda.com/platform/decision-engine/