Оригинал: BPM+ : The Enduring Value of Business Automation Standards
Автор: Брюс Сильвер (Bruce Silver)
Три стандарта автоматизации бизнеса от Object Management Group — BPMN, CMMN и DMN, — продолжают оставаться ключевым активом, приносящим пользу бизнесу. В этой статье мы обсудим для чего они предназначены, как появились и чем помогают бизнесу.
Начало
В самом начале, скажем, в 2000 году, ни в автоматизации бизнеса, ни в каких-то других областях ИТ стандартов практически не существовало. Веб все это изменил. О BPMN я впервые услышал в 2003 году. К тому моменту я уже двенадцать лет занимался чем-то, что называлось workflow — автоматизацией и контролем потока работ, выполняемых людьми, сначала в качестве руководителя разработки, а потом как отраслевой аналитик. Существовало множество продуктов, но все они были полностью проприетарными. И вдруг появилось нечто новое под названием BPM, что обещало все это изменить.
Ранее, помимо workflow, существовала совершенно отдельная технология — интеграция корпоративных приложений (Enterprise Application Integration, EAI). Это тоже была технология автоматизации процессов, но основанная на шине сообщений, предназначенная исключительно для взаимодействия между системами, без участия людей, и опять же полностью проприетарная. Это был хаос.
Затем появилась новая технология под названием веб-сервисы, которая дала возможность объединить существующие решения на основе веб-стандартов. В начале эпохи доткомов веб использовался лишь для рекламы бизнеса, возможно, с элементами электронной коммерции. Но вскоре стало понятно, что стандартные протоколы и XML-данные веба можно использовать для стандартизации вызовов API в новой сервис-ориентированной архитектуре (SOA). Стартап из Кремниевой долины под названием Intalio предложил использовать веб-сервисы для создания нового языка автоматизации процессов под названием BPML, который объединял workflow и интеграцию приложений в рамках этой архитектуры. Но они пошли дальше: удивительно, но решения с использованием этого языка предполагалось определять графически, с помощью нотации под названием BPMN. Цель заключалась в том, чтобы вовлечь бизнес-пользователей в переход на SOA, а BPMN давал надежду на преодоление разрыва между бизнесом и ИТ, который ранее приводил к провалам проектов автоматизации.
Поставщикам корпоративного ПО это тоже понравилось. Функциональность, которая раньше была встроена в их монолитные приложения, теперь могла быть выделена в микросервисы, которые вызывались по мере необходимости и упорядочивались с использованием протоколов Всемирной паутины. Это стало настоящим прорывом. Даже пользовательские задачи workflow можно было бы превратить в сервисы.
По мере своего развития BPMN 1.0 приобрела вид блок-схем с дорожками (swimlanes), которые уже широко использовались бизнес-пользователями, хотя и без стандартной семантики для символов. Теперь, благодаря привязке каждого символа к семантике языка исполнения BPML, BPMN обещала принцип «Как нарисовали — так и работаем» (What You Draw Is What You Execute). Intalio смогла организовать консорциум из более чем 200 компаний-разработчиков софта под названием BPMI.org для поддержки этого нового стандарта автоматизации бизнеса.
Хотя изначально идея казалась перспективной, на самом деле она была преждевременной, поскольку основной стандарт веб-сервисов WSDL еще не был финализирован, и в итоге BPML не смог с ним работать. Поэтому BPML был заменен другим языком — BPEL, который поддерживал этот стандарт. Графическая нотация BPMN осталась популярной среди бизнеса для документирования и улучшения процессов, но она не подходила идеально для автоматизации с использованием BPEL. Некоторые диаграммы, которые можно было нарисовать в BPMN, не могли быть преобразованы в BPEL. Таким образом, BPMN больше не могла претендовать на принцип «как рисуем, так и работаем». В итоге BPMI.org пришел в упадок и был поглощен OMG, который профессионально занимался стандартами.
Тем не менее, BPMN оставался чрезвычайно популярным среди бизнес-пользователей. На самом деле, они не стремились автоматизировать свои процессы, а лишь хотели документировать их для анализа и возможного улучшения. Однако поставщики прикладного ПО и вендоры SOA настаивали на создании новой версии BPMN, которая сделала бы диаграммы исполняемыми. Лишь в 2010 году BPMN 2.0 наконец предоставил диаграммам BPMN полноценный язык исполнения. Я проводил обучение по BPMN версии 1.x с 2007 года и каким-то образом оказался в рабочей группе по BPMN 2.0, представляя интересы тех бизнес-пользователей, которые занимались описательным моделированием.
BPMN 2.0 была широко принята практически всеми поставщиками систем автоматизации процессов. Позже консорциум OMG разработал два других стандарта для автоматизации бизнеса: CMMN для моделирования кейсов и DMN для моделирования решений, основанные на схожем наборе принципов. Три стандарта понадобились, потому что они охватывают разные области. Они были разработаны в разное время и по разным причинам. Поэтому позвольте мне кратко описать, что они делают, их общие принципы и почему они остаются важными сегодня.
BPMN
BPMN был первым. BPMN описывает процесс в виде блок-схемы действий, ведущих от определенного триггерного события к одному из нескольких возможных конечных состояний. Каждое действие обычно представляет либо задачу, выполняемую человеком, либо автоматизированный сервис, впервые объединяя человеко-ориентированный workflow и EAI. Диаграммы включают как обычный магистральный путь (happy path), так и ветви, возникающие при исключениях. На диаграмме легко увидеть последовательность шагов, которые может пройти процесс, но каждый его экземпляр должен следовать какому-либо пути на диаграмме. Это одновременно и его сила, и его основное ограничение.
BPMN остается очень популярным, потому что диаграммы интуитивно понятны. Пользователи в общих чертах понимают их без специального обучения, а то, что вы рисуете, — это то, что выполняется. BPMN может описывать многие процессы из реального мира, но не все.
На самом деле существует два отдельных сообщества пользователей BPMN. Интересно, что они практически не взаимодействуют друг с другом. Одно сообщество использует BPMN исключительно для описания процессов. Их не интересует автоматизация, только документирование и анализ. Эти пользователи BPMN просто хотят задокументировать текущие бизнес-процессы с надеждой на их улучшение, поскольку диаграммы, если они созданы правильно, например, с использованием подхода, изложенного в моей книге «BPMN Method and Style» (книга недавно вышла в русском переводе — прим. перев.), более четко выражают логику процесса, чем длинный текстовый документ. Для них ценность BPMN заключается в том, что он в целом повторяет вид традиционных блок-схем с дорожками (swimlane flowcharts).
Другое сообщество заинтересовано в автоматизации процессов, то есть в фактической реализации новых и улучшенных процессов. Для них ценность BPMN заключается в принципе «как нарисовали — так и работаем». Это позволяет бизнесу точнее определять требования к процессам и теснее сотрудничать с разработчиками, что сокращает сроки разработки решения и в целом повышает заинтересованность бизнес-пользователей.
В качестве преподавателя BPMN я в основном взаимодействовал с первым сообществом. В прошлой жизни, когда я был отраслевым аналитиком, мое общение происходило исключительно со второй группой. Поэтому я хорошо понимаю ожидания обеих сторон. И хотя я считаю, что сообщество, занимающееся описательным моделированием, вероятно, все еще больше по численности, оно сейчас сокращается, и вот почему.
В команде, занимающейся описательным моделированием, обычно проводятся встречи и воркшопы, где модератор задает вопросы: «Как начинается процесс? Что происходит дальше?» и так далее. Это хорошо подходит для фиксации магистрального пути — нормального потока действий, ведущего к успешному конечному состоянию, что является основным интересом. Но диаграммы BPMN также содержат развилки и события, которые определяют пути исключений, поскольку, напомню, каждый экземпляр процесса должен следовать какому-либо пути на диаграмме. Однако на практике таким образом вы никогда не зафиксируете все возможные исключения.
За последнее десятилетие интерес в области улучшения процессов сместился от описательного моделирования к так называемому process mining — автоматическому выявлению процессов. Этот подход предполагает отслеживание ключевых шагов процесса в ходе его выполнения, независимо от того, как они достигаются, и фиксацию временных меток для создания картины всех путей от начала до конца. Важно, что это включает ту небольшую долю экземпляров процесса, которые длятся слишком долго, стоят слишком дорого и становятся причиной жалоб в службу поддержки. Работа с такими экземплярами приводит к значительному улучшению процессов, а их автоматизация требует учета этих ситуаций каким-либо образом.
Некоторые инструменты process mining позволяют передать свои результаты обратно в BPMN, но BPMN требует указать причину отклонения от магистрального пути — какое-то условие на развилке или событие. Это обозначает ключевую слабость BPMN как языка автоматизации — сложность учета всех необычных исключений, которые возникают в реальных сценариях. Необходимо что-то более гибкое.
CMMN
CMMN был создан для работы с такими процессами, которые BPMN не может смоделировать. Он сосредоточен на ключевом отличии от BPMN — выполнении работы по непредсказуемому пути в течение всего ее жизненного цикла, с акцентом на поведение, инициируемое событиями, и на ситуативные решения, принимаемые сотрудниками, обладающими экспертными знаниями.
Кейс в CMMN не описывается блок-схемой, в которой можно четко увидеть порядок действий, а представляется в виде диаграммы состояний, называемых стадиями (stages). Каждая стадия определяет действия, которые могут быть выполнены или в некоторых случаях должны быть выполнены для достижения определенной вехи или перехода в другое состояние. Это обеспечивает большую гибкость и, на самом деле, является более подходящим способом, чем BPMN, для работы с реальными сценариями, в которых невозможно перечислить все возможные последовательности необходимых действий.
Однако это имеет свою цену. Хотя принцип «как нарисовали — так и работаем» сохраняется, то, что нарисовано в CMMN, не так-то просто понять. Диаграммы CMMN интуитивно непонятны, даже если вы хорошо разбираетесь в обозначениях и символах. Каждый элемент на диаграмме проходит через различные состояния жизненного цикла — доступно (available), разрешено (enabled), активно (active), завершено (completed) или прекращено (terminated) — и каждое изменение состояния представлено стандартным событием, которое инициирует переходы состояний в других элементах. В итоге диаграмма, полностью детализированная до отдельных задач, показывает действия, которые могут быть выполнены или должны быть выполнены, а также события, которые запускают изменения в других элементах.
На практике CMMN почти всегда используется вместе с BPMN, поскольку конкретные действия, обычно представляющие собой сочетание автоматизированных сервисов и взаимодействия с человеком, лучше моделировать как процессы BPMN. Таким образом, в типичном решении для автоматизации бизнеса CMMN находится на верхнем уровне, где выбор выполняемых действий остается гибким и управляется событиями. Многие действия в CMMN моделируются как задачи процесса (process tasks), что означает запуск процесса BPMN. Такая организация решения сочетает в себе преимущества гибкости CMMN для обработки событий и исключений в реальных сквозных сценариях и понятной для бизнеса автоматизации детализации необходимых действий с помощью BPMN.
Выше приведен пример из моей книги «CMMN Method and Style», основанный на услугах социальной помощи в одной из европейских стран. Стадия Active Case (Активный кейс) содержит четыре подстадии без каких-либо условий входа. Это означает, что они могут быть активированы в любое время. Треугольный маркер внизу указывает на ручную активацию; без него они активировались бы автоматически. Обратите внимание, что внутри каждой стадии представлены как пользовательские задачи (с иконкой пользователя), так и задачи процессов (с иконкой в виде шеврона).
Внизу расположены еще четыре задачи, которые не входят в подстадии и связаны с административными функциями кейса. Они потенциально могут выполняться в любое время, когда Active Case находится в активном состоянии, но у них есть условия входа (белые ромбы), что означает, что они должны быть инициированы событиями — либо действием пользователя, либо таймером.
Эта диаграмма не включает события, связанные с файлами, такие как получение или обновление документа или данных, которые также могут запускать задачи и определять вход или выход из стадии. Как вы можете видеть, логика кейса очень гибкая — практически любое действие может быть начато в любое время. Однако на этом уровне диаграмма не слишком подробно раскрывает детали действий. Эти детали описаны внутри процессов и задач BPMN.
Вот еще один пример CMMN, который демонстрирует гибкость, необходимую для, казалось бы, такой простой задачи, такой как создание учетной записи пользователя в финансовом учреждении. Да, это простой процесс для BPMN, но он находится в более широком контексте управления статусом пользователя как клиента. Новый клиент должен быть инициализирован и настроен — это еще один процесс BPMN — и только после этого можно добавить одну или несколько учетных записей, пока клиент остается Активным пользователем (Active User).
Вы можете деактивировать пользователя — это еще один процесс, который автоматически завершает стадию Manage Active User (Управление активным пользователем) (черный ромб) и запускает стадию Manage Inactive User (Управление неактивным пользователем). Это происходит через связь с белым ромбом, помеченным как “exit” (выход), где “exit” является событием жизненного цикла, связанным с состоянием “Terminated” (Завершено) стадии Manage Active User.
Единственное, что происходит на стадии Manage Inactive User, — это возможность реактивировать пользователя, что является еще одним процессом. Когда этот процесс завершен, а в стадии больше ничего не остается, стадия считается завершенной. Это означает, что связь с белым ромбом в стадии Manage Active User, помеченная как “complete” (завершение), активирует эту стадию снова.
Маркер в виде решетки (#) на обеих стадиях означает, что после завершения или завершения по принуждению они могут быть повторно активированы; без этого маркера они не могли бы быть повторно запущены.
Наконец, задача процесса Delete user (Удалить пользователя) не имеет условий входа, поэтому она может быть активирована вручную в любое время. После её завершения кейс завершается (черный ромб).
Таким образом, то, что изначально казалось простым процессом — добавлением учетной записи пользователя — в реальном приложении расширяется до кейса, охватывающего весь жизненный цикл клиента.
DMN
DMN описывает не действия, а бизнес-логику, понятную для непрофессионалов в программировании, но при этом пригодную для развертывания в виде исполняемого сервиса. DMN является преемником технологий бизнес-правил (business rule engine) 1990-х годов, но лучше соответствует современной архитектуре, ориентированной на микросервисы. В DMN сервис принятия решений получает одни данные на вход и возвращает другие на выход. Он не выполняет никаких других действий. Как и BPMN и CMMN, проектирование в DMN в значительной степени является графическим.
Диаграмма, которую вы видите здесь, называется Decision Requirements Diagram (Диаграмма требований к решениям). Она показывает зависимости каждого прямоугольника, представляющего решение, от поддерживающих решений и входных данных, которые связаны с ним через входящие стрелки, называемые информационными требованиями (information requirements). Выражение значения для каждого решения может ссылаться только на те информационные требования, которые напрямую с ним связаны. Даже если бизнес-пользователи не могут смоделировать выражения значений, они способны создавать такие диаграммы, которые служат проверяемыми бизнес-требованиями для исполняемого решения.
Однако DMN был разработан так, чтобы позволить непрофессионалам пойти дальше — вплоть до создания исполняемых сервисов принятия решений. Вместо программного кода DMN предоставляет стандартные табличные форматы, называемые boxed expressions (коробочные выражения), которые вычисляют значение каждого решения.
Таблицы решений (Decision tables), как показано выше, являются самым известным типом boxed expressions (коробочных выражений), но существуют и другие, такие как Contexts (Контексты), пример которых показан ниже. В контекстах строки таблицы определяют локальные переменные, называемые context entries (элементы контекста), которые используются для упрощения выражений в последующих строках. Обратите внимание, что выражение значения элемента контекста, например, Loan amount (Сумма кредита), само по себе может быть контекстом или каким-либо другим типом коробочного выражения.
Выражения для каждого элемента контекста (context entry), показанные в серых ячейках, используют язык low code-выражений под названием FEEL (Friendly Enough Expression Language). Хотя FEEL определен в спецификации DMN, он также может быть использован в BPMN и CMMN. Подробнее об этом — позже.
Комбинация DRD (диаграмм требований к решениям), коробочных выражений и FEEL позволяет бизнес-пользователям самостоятельно создавать исполняемую логику решений без программирования. В BPMN и CMMN графическое проектирование ограничивается только схемой процесса или логики кейса, то есть той частью, которая отображается на диаграмме. Чтобы модель стала полностью исполняемой, эти стандарты обычно требуют программирования.
Однако на платформе Trisotech это больше не является необходимым. Когда BPMN и CMMN разрабатывались, они не включали язык выражений, так как предполагалось (и это было верно на тот момент), что детали интеграции систем и пользовательского интерфейса потребуют программирования на языке вроде Java. Но DMN был опубликован через шесть лет, когда программные инструменты стали более продвинутыми. DMN был разработан для того, чтобы позволить непрофессионалам создавать исполняемые сервисы принятия решений с помощью комбинации диаграмм, таблиц и FEEL — стандартного языка low code-выражений.
Язык выражений — это не полноценный язык программирования; он не определяет и не обновляет переменные, а лишь вычисляет значения через формулы. Например, формулы в Excel представляют собой пример языка выражений.
Хотя внедрение FEEL как стандарта идет медленно, даже внутри сообщества управления решениями, многие поставщики инструментов автоматизации бизнеса реализовали собственные языки low code-выражений с целью дать бизнес-командам больше возможностей для сотрудничества с разработчиками. Сегодня такие языки следует рассматривать как важную вторую половину автоматизации бизнеса на основе моделей наряду с диаграммами, состоящими из стандартизированных форм, семантики и операционного поведения.
Цель — сокращение сроков разработки решения, упрощение его поддержки и повышение заинтересованности бизнес-пользователей за счет более тесного взаимодействия с разработчиками.
Общие принципы
В основе стандартов OMG лежат три ключевых принципа.
Первый принцип заключается в том, что все они основаны на моделях — то есть диаграммы и таблицы используются как для описания желаемого решения (того, что называют бизнес-требованиями), так и для создания самого исполняемого решения, возвращаясь к изначальной концепции «как нарисовали — так и работаем».
Хорошо известно, что традиционный метод текстового описания бизнес-требований часто является причиной неудач проектов. Вместо этого модели позволяют экспертам в предметной области создавать схему решения в виде диаграмм и таблиц, которые можно проверить на полноту и внутреннюю согласованность. Более того, элементы и символы, используемые на диаграммах, определены в спецификации, поэтому модели выглядят одинаково и работают одинаково в любом инструменте. И что еще лучше, семантика выполнения для этих элементов также прописана в спецификации, так что то, что вы рисуете, действительно становится тем, что вы выполняете. Вовлечение бизнес-пользователей вместе с ИТ-командой с самого начала проекта ускоряет достижение результата (time-to-value) и повышает уровень принятия решения пользователями.
Во-вторых, модели имеют стандартный формат файла XML, что позволяет обмениваться ими между инструментами без потери качества. На практике это означает, например, что бизнес-пользователи и разработчики могут использовать разные инструменты и обмениваться моделями между ними. Я участвовал в проектах, где бизнес хотел использовать инструмент моделирования X, а ИТ, являясь отдельной организацией, настаивали на использовании инструмента Y для исполнения. Это не очень хорошо, но не фатально, поскольку моделями можно обмениваться между инструментами благодаря стандартному формату.
Третьим принципом является обеспечение нейтральности по отношению к вендорам, что гарантируется процедурами OMG. Проприетарные функции не могут быть частью стандарта, а интеллектуальная собственность (IP) является общественным достоянием. На практике это часто приводит к появлению инструментов с открытым исходным кодом и снижению стоимости программного обеспечения.
Например, многие сегодняшние инструменты для построения диаграмм BPMN выросли из проектов с открытым кодом, и один из таких проектов создал популярную среду исполнения BPMN. С DMN ситуация аналогична. Разработчики инструментов столкнулись с трудностями при создании парсера FEEL, так как в нем имена переменных и функций могут содержать пробелы, пока Red Hat не открыл исходный код своего парсера FEEL и исполняемой среды DMN.
Реализовать эти стандарты сложно, и программное обеспечение с открытым кодом сильно способствует их внедрению.
Долговременная польза для бизнеса
Итак, в чем заключается ценность этих стандартов для бизнеса? Какие преимущества они дают клиентам? На мой взгляд, их можно разделить на три категории.
Во-первых, общие термины и понятия. Я помню времена автоматизации рабочих процессов до появления BPMN. Тогда не существовало общей терминологии. Вы изучали конкретный инструмент, и инструменты предназначались для программистов. Теперь BPMN, CMMN и DMN обеспечивают независимое от инструментов понимание процессов, кейсов и логики принятия решений. Информация об этих технологиях стала гораздо более доступной благодаря книгам, публикациям в интернете и обучающим курсам, вплоть до деталей моделирования и автоматизации. Это, в свою очередь, упрощает найм сотрудников и привлечение поставщиков услуг, уже знакомых с этими технологиями и имеющих опыт работы с ними. Это также снижает затраты на переобучение в случае необходимости смены поставщиков платформ.
Второе преимущество — более быстрое внедрение решений (time-to-value). Сегодня это, возможно, самое важное для клиентов. Решения на основе моделей просто быстрее в составлении требований, в разработке и в адаптации к изменяющимся требованиям по сравнению с традиционными подходами. Быстрее в составлении требований, потому что проще вовлечь экспертов в предметной области и быстрее проверить требований на полноту и внутреннюю согласованность. Быстрее в разработке, потому что вы строите решение на основе стандартных движков автоматизации. Пользовательский код используется только для интеграции с конкретными системами и деталей пользовательского интерфейса. И быстрее в адаптации к изменяющимся требованиям, потому что часто это требует только изменения модели, а не кастомного кода.
Например, поставщик медицинских услуг может запустить портал для регистрации клиентов всего за три месяца вместо года благодаря участию бизнес-пользователей из разных отделов и тесному сотрудничеству между бизнесом и ИТ. Все используют одну и ту же терминологию, одни и те же диаграммы, и то, что вы нарисовали, это то, как вы работаете.
Ключевой особенностью трех стандартов OMG является то, что они были разработаны для совместной работы. Например, в CMMN есть стандартный тип задачи, который вызывает процесс BPMN, и другой тип, который вызывает сервис принятия решений DMN. BPMN может вызывать сервис принятия решений DMN, а на платформе Trisotech — также кейс CMMN. Таким образом, существуют платформы, такие как Trisotech, которые охватывают весь спектр требований к автоматизации бизнеса: событийно-ориентированное управление кейсами, сквозная автоматизация процессов, автоматизация длительных процессов и автоматизация принятия решений. Альтернативой является написание большого количества кастомного кода — дорогостоящего и сложного для адаптации к изменяющимся требованиям — или использование отдельных платформ для управления процессами, решениями и кейсами, что, опять-таки, дорого и требует значительных усилий по интеграции систем.
Единая платформа, которая охватывает все три аспекта, особенно если она основана на моделях, вовлечении бизнеса и независимых от поставщиков стандартах, снижает затраты — на программное обеспечение, внедрение и долгосрочное обслуживание решения.
SDMN, общий язык данных
Хотя BPMN, CMMN и DMN хорошо работают вместе, им все же не хватает общего формата для данных. DMN использует FEEL, но в большинстве инструментов исполняемые модели BPMN и CMMN для определения данных используют языки программирования, такие как Java. Было бы лучше, если бы они имели общий способ определения данных. Trisotech использует FEEL для всех трех типов моделей, что является идеальным решением. Однако сейчас предпринимаются усилия, чтобы сделать этот общий язык данных стандартом.
BPM+ Health — это сообщество практиков HL7 в сфере здравоохранения, которое стремится к отраслевой консолидации вокруг такого общего языка данных, SDMN. Этот язык по сути является FEEL. Технически он определяется стандартом OMG Shared Data Model and Notation (SDMN) — ключевой инициативой BPM+ Health, направленной на унификацию моделирования данных между BPMN, CMMN и DMN.
Моделирование данных в основном используется в исполняемых моделях и опускается в чисто описательных моделях. Задача SDMN заключается в унификации переменных DMN, объектов данных BPMN и элементов файлов кейсов CMMN, описывая их как то, что DMN называет определениями элементов (item definitions).
SDMN определяет стандартизированную логическую модель данных для использования в BPMN, CMMN и DMN. Данные, связанные с определениями SDMN, не привязаны к конкретной модели и могут последовательно использоваться в моделях разных типов. В этом смысле это логическая модель данных, эквивалентная Trisotech Knowledge Entity Modeler. Однако, если KEM определяет концептуальную модель данных с акцентом на семантику терминов, то SDMN является логической моделью данных с фокусом на структуре данных, что DMN называет определениями элементов.
На данный момент SDMN 1.0 все еще находится в стадии бета-версии, но два артефакта иллюстрируют запланированное. Диаграмма DataItem (элемент данных), показанная ниже, описывает названия и типы элементов данных, а также структурные связи между ними.
Кроме того, диаграмма ItemDefinition (Определение элемента), показанная ниже, детализирует структуру каждого элемента данных.
Пользователи Trisotech узнают в этом альтернативный способ создания определений элементов (item definitions), который проще для поставщиков инструментов, не обладающих графическими возможностями Trisotech. Однако я все же предпочитаю сворачиваемую реализацию Trisotech.
Что дальше
В будущем можно ожидать больше решений, разработанных с использованием комбинации BPMN, CMMN и DMN. Обычно CMMN используется на верхнем уровне, где он может охватывать все возможные сценарии в реальном приложении. Конкретные действия лучше всего реализовывать как процессы BPMN, вызываемые из CMMN в виде задачи процесса. Логика принятия решений может вызываться как из CMMN, так и из BPMN в виде задачи решения. Таким образом, становится понятно, почему наличие общих определений данных для всех трех языков моделирования ценно в таких интегрированных решениях.
На платформе Trisotech SDMN уже поддерживается во всех трех языках в виде FEEL, что предоставляет дополнительное преимущество лоукод-автоматизации бизнеса. Начиная с сектора здравоохранения, SDMN сделает этот инструмент интеграции доступным и на других платформах.
Обсудить