Оригинал: How CMMN never lived up to its potential
Автор: Найл Дихан (Niall Deehan)
Еще до того, как в 2014 году консорциум Object Management Group (OMG) опубликовал стандарт CMMN, мы в Camunda начали разработку движка CMMN. В последующие годы мы вложили немало сил в поддержку нотации CMMN, инструментов моделирования и администрирования.
Но спустя пару лет мы решили, что больше не будем добавлять в продукты Camunda функциональность CMMN, а только поддерживать существующую. В этой заметке рассказывается об опыте Camunda и ее сообщества по освоению стандарта CMMN, и о том, как мы сначала решили поддержать CMMN, а затем отказались от этой идеи.
Многообещающий CMMN
Появление нотация моделирования кейсов (Case Management Model and Notation, CMMN) стало прямым результатом огромной популярности нотации управления бизнес-процессами (Business Process Model and Notation, BPMN) и интереса к концепции слабо предсказуемых процессов.
Стандарт BPMN был разработан для моделирования полностью предсказуемых, повторяющихся процессов. Как следствие ему недоставало гибкости, чтобы должным образом изображать слабо предсказуемые процессы, в основном управляемые человеком – работником умственного труда.
CMMN был задуман как специализированная нотация для решения этой проблемы от команды, только что выпустившей очень успешный BPMN. Выход CMMN наделал много шуму, и на конференциях отраслевые эксперты с восторгом рисовали радужные возможности, которые появятся теперь, когда можно моделировать слабо предсказуемые процессы.
Весь этот ажиотаж заставил вынудил вендоров BPMN, включая Camunda, быстро исследовать возможность реализовать стандарт CMMN. Предполагалось, что, как и в случае BPMN, реализация нового стандарта будет представлять собой визуальную модель с исполняемой метамоделью, т.е. программный «движок» сможет исполнять графическую схему. Требовалось разработать и вывести на рынок моделер и движок CMMN. Учитывая восторженные ожидания от CMMN, инвестиции в такую разработку казались беспроигрышными.
Опыт реализации CMMN в Camunda
Осознав потенциал исполняемых моделей кейсов, Фалько Менге (Falco Menge) из Camunda присоединился к OMG, чтобы помочь рабочей группе по CMMN завершить работу над стандартом.
Мы рьяно взялись за дело. Будучи компанией, известной BPMN-движком на Java, мы решили начать с движка CMMN. Предполагалось, что параллельно наши конкуренты будут разрабатывать средства моделирования, как это было с BPMN. Поскольку модель стандартизована, пользователь сможет смоделировать диаграмму CMMN в стороннем инструменте, а затем выполнить эту модель в движке Camunda. В итоге мы выпустили движок в том же году, когда был опубликован стандарт. Публикация 2014 года дает представление о том, как быстро мы продвигались.
Причем продвижение было не только в разработке – команда консультантов (в которую тогда входил и я) работала над созданием и проведением тренингов по CMMN. На самом деле этот проект значил для нас не меньше остальных. Масштаб наших усилий не следует недооценивать – компания в то время насчитывала около 25 человек, а значит во внедрение CMMN так или иначе было вовлечено большинство наших сотрудников.
Ранее в том же году мы начали разрабатывать bpmn.js – моделер с открытым исходным кодом, который сегодня используют многие проекты BPMN. Воодушевленные этим успехом, мы начали разрабатывать cmmn.js, чтобы дополнить движок CMNN моделером. Мы планировали это сделать в уже в версии 1.1 Camunda Modeler.
Мы также занялись разработкой вспомогательных инструментов: добавили средство просмотра CMMN в нашу панель управления, чтобы администратор мог видеть текущий статус и историю выполнения кейсов.
В течение нескольких лет после публикации стандарта CMMN Camunda записала в свой актив:
- разработку движка CMMN с открытым исходным кодом
- разработку моделера и средства просмотра диаграмм CMMN
- подготовку и реализацию программы обучения
- разработку инструментов администрирования и отладки процессов CMMN
Стоит отметить, что мы не только мечтали об успехе CMMN, но и активно этому способствовали. Мы сделали CMMN центральной темой докладов на различных конференциях, искали удачные примеры использования CMMN и всячески и всячески популяризировали их среди существующих и потенциальных клиентов.
Изъяны CMMN
Проблемы с CMMN стали возникать постепенно, с течением времени. Но мы продолжали поддерживать стандарт, демонстрируя веру в то, что проблемы удастся решить. А может быть мы просто попали в ловушку безнадежных инвестиций. Первые сигналы о том, что внедрение CMMN займет больше времени, чем BPMN, мы получили от нашего сообщества.
Из разговоров на обучающих семинарах стало ясно, что даже в самых сложных кейсах есть довольно много предсказуемых фрагментов, в моделировании которых CMMN оказывается откровенно слаб. Выходило, что на практике CMMN нужно было использовать вместе с BPMN.
На первый взгляд проблемы тут нет: у нас есть BPMN для предсказуемых, повторяющихся фрагментов и CMMN для менее предсказуемых, динамичных – соединяем лучшее из двух миров. Но у множества пользователей возникал вопрос: стоит ли изучать второй стандарт только ради возможностей, которые предоставляет CMMN? Вопрос резонный, учитывая, что нотация BPMN и сама во многом позволяет работать с динамическими кейсами. Этим воспользовалась, например, IBM, просто добавив функции CMMN в собственную версию BPMN.
В процессе обучении CMMN выяснилось, что эта нотация сложна в освоении. В отличие от BPMN, который, как мы убедились, интуитивно понятен и может использоваться уже после прохождения базового обучения, сразу научиться CMMN не получалось. В отличие от BPMN, основанного на традиционных блок-схемах, в схеме CMMN сложно даже понять где процесс начинается. Что еще хуже, глядя на модель трудно сказать, что может произойти в конкретной ситуации, поскольку значительная часть поведения скрыта в правилах CMMN, а не отображается символами на диаграмме. Например, понять, как работает «часовой» (sentry), удастся только если разработчик позаботился о том, чтобы поместить на схему текстовое описание.
Фундаментальная идея исполняемой графической модели – служить универсальным языком, связующим звеном между разработчиками и аналитиками. Успех BPMN в первую очередь обусловлен тем, что его восприняли и те, и другие. CMMN же во многих случаях оказался чрезмерно сложным для понимания и требовал слишком больших усилия для освоения, особенно в глазах тех, кто до этого изучил BPMN.
Клиенты, мигрировавшие с CMMN обратно на BPMN, отмечали для себя как преимущество то, что события отображаются и помечаются явным образом. Событие, инициирующее опциональную задачу, явно отображается на диаграмме, пусть даже занимая немного больше места.
Кроме того, в BPMN можно изобразить подпроцесс-обработчик в свернутом виде, но при этом показать событие. Получается так же компактно, как CMMN, но более информативно.
Короче говоря, практика использования двух нотаций показала, что BPMN просто лучше, чем CMMN.
Выпустив движок CMMN, мы через некоторое время собрали обратную связь от пользователей. Выяснилось, что люди не хотели использовать движок от Camunda, если они использовали моделер другого вендора. Поэтому мы ожидали увидеть всплеск интереса после выпуска собственного моделера. К сожалению, этого не произошло. Тогда мы снова обратились к нашим клиентам, чтобы узнать, чего, по их мнению, не хватает в CMMN. Ответ был предельно ясен: нам нужны те же возможности администрирования что есть в BPMN. Однако добавление средств администрирование тоже не смогло переломить ситуацию.
Причем проблемы были не только у нас. Первоначальный энтузиазм постепенно угасал, и реализовать функциональность в CMMN стремилось все меньше вендоров. К настоящему времени осталось очень мало средств моделирования и движков CMMN и все меньше желающих связываться с CMMN.
Как Camunda рассталась с CMMN
В сентябре 2019 года наши учредители выпустили 4-е издание книги «Нотация BPM на практике» (Real-Life BPMN), в котором приняли решение убрать главу о CMMN. Свой шаг они мотивировали следующим образом:
«Мы дали CMMN два года на то, чтобы проявить себя, но обнаружили ограниченную ценность этого стандарта в наших проектах, особенно в сравнении с BPMN и DMN. Одна из проблем заключается в том, что большая часть логики в моделях CMMN скрыта в сложных наборах правил, определяющих, какие действия возможны, невозможны, обязательны или не нужны. Эти правила часто описываются в других местах и не отображаются графически. Несколько утрируя, модель CMMN становится своего рода графическим представлением маркированного списка. В итоге мы решили убрать CMMN из этой книги, чтобы не сбивать с толку тех, кто только начинает свой путь в BPM. Вместо этого мы хотим показать, как неструктурированные процессы можно представить с помощью BPMN … и указать на ограничения этого подхода.»
Вы можете возразить, что, возможно, причина непопулярности нового стандарта в недостатках программного обеспечения, а не CMMN. Но примерно в то же время вышел другой стандарт – DMN, и тут мы поняли, каково это – создавать программное обеспечение для сообщества, полного энтузиазма и мотивации.
Опыт внедрения DMN оказался совершенно другим, хотя дорожная карта была той же самой. Про наш опыт внедрения DMN я расскажу как-нибудь в другой раз, а сейчас достаточно сказать, что для нас и для всего сообщества BPM он оказался очень успешным. Таким образом, мы оказались перед дилеммой: тратить больше времени на развитие сообщества CMMN или направить больше ресурсов на DMN, где сообщество восприняло стандарт гораздо быстрее и с большим энтузиазмом? При этом мы должны помнить, что несем ответственность перед клиентами и сообществом за то, чтобы не тратить зря время на ненужные функции.
На тот момент вопрос стоял не о том, следует ли прекратить поддержку CMMN, а о том, стоит ли отложить разработку новых функций, пока мы не увидим на них спрос. Но в итоге мы его так и не дождались.
Часть пользователей по-прежнему используют Camunda для работы с CMMN, но большинство просто трансформировали модели CMMN в модели BPMN, что мне лично очень понравилось.
Сегодня Camunda связывает свое будущее с BPMN и DMN, причем это решение приняло за нас сообщество. Традиционно наши решения в значительной степени принимаются на основе обратной связи от таких членов сообщества, как вы. Заходите на наш форум пообщаться – расскажите, что вы хотели бы видеть в наших продуктах в будущем.