Движок бизнес-правил

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

Движки бизнес-правил являются важным компонентом платформ Low-code и No-code, позволяя бизнес-пользователям управлять логикой через визуальные интерфейсы без навыков программирования^[6][7][8]. Для создания и управления правилами также активно применяется генеративный искусственный интеллект, который даёт возможность формулировать бизнес-логику на естественном языке^[9][10].

В статье, опубликованной в Computerworld, истоки появления движков правил связываются с началом 1990-х годов и продуктами компаний Pegasystems, Fair Isaac Corp, ILOG^[11] и eMerge^[12] от Sapiens.

В период с 2010 по 2020 год произошёл переход от традиционных локальных (on-premise) систем к облачным (cloud-native) и SaaS-решениям. Важным этапом этой трансформации стало архитектурное отделение логики бизнес-правил от основного кода приложения, что значительно повысило гибкость систем^[13][14][15]

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

• Бизнес-правила создают знания;
• Рабочие процессы выполняют бизнес-задачи.

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

Это разделение важно, поскольку одна и та же бизнес-оценка (займ соответствует критериям) или бизнес-событие (маршрутизатор перегружен) могут быть учтены разными рабочими процессами. Если реализовать реакцию на знание, полученное движком правил, прямо внутри самого правила, это существенно снижает возможность повторного использования бизнес-правил, поскольку они становятся специальными для конкретного бизнес-процесса.

Для построения архитектуры, использующей движок бизнес-правил, необходимо наладить интеграцию между платформами BPM (Business Process Management, управление бизнес-процессами) и BRM (Business Rules Management, управление бизнес-правилами) на основе обработки событий и анализа бизнес-оценок, задаваемых правилами. Некоторые продукты на рынке предоставляют такую интеграцию изначально, в других случаях этот уровень абстракции и интеграции необходимо создавать в рамках проекта или организации.

Для интеграции с различными приложениями современные движки правил используют актуальные стандарты программных интерфейсов, такие как REST API, gRPC (для взаимодействия микросервисов) и CloudEvents (для событийно-ориентированных архитектур)^[16][17], которые пришли на смену устаревшим стандартам JSR-94 и SOAP.

В большинстве движков правил предусмотрена возможность создавать абстракцию данных, отражающую бизнес-объекты и отношения, с которыми должны работать правила (бизнес-модель объекта). Такая модель может наполняться данными из разных источников, включая XML, POJO, плоские файлы и др. Стандартизированного языка написания бизнес-правил не существует: многие системы используют синтаксис, похожий на Java, некоторые же позволяют создавать собственные понятные бизнесу языки.

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

В облачных (cloud-native) архитектурах для развертывания движков бизнес-правил применяются современные паттерны проектирования. Паттерн Sidecar предполагает развертывание движка как отдельного вспомогательного контейнера, работающего рядом с основным приложением, что обеспечивает изоляцию логики правил. Бессерверный подход (Serverless) заключается в использовании облачных функций для выполнения бизнес-логики по требованию, обеспечивая автоматическое масштабирование и экономическую эффективность^[18][19][20].

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

Большинство бизнес-ориентированных движков реализуют прямой вывод (forward chaining), который можно разделить на две группы:

• Первая категория — движки с производственными/инференционными правилами. Такие правила отражают поведение «ЕСЛИ условие, ТО действие». Например, для решения вопроса «Можно ли этому клиенту выдать ипотеку?» может использоваться правило: «ЕСЛИ выполнено условие, ТО разрешить ипотеку».
• Второй тип движков реализует реагирующие/правила ECA (событие-условие-действие). Реактивные движки обнаруживают и обрабатывают входящие события или их комбинации. Например, такой движок может оповестить менеджера о нехватке определённых товаров.

Ключевое различие между этими категориями заключается в том, что производственные движки вызываются пользователем или приложением обычно без сохранения состояния (stateless), а реактивные реагируют на события автоматически и, как правило, хранят состояние (stateful). Многие коммерческие движки правил сочетают оба подхода, хотя могут делать упор на одну из моделей: большинство бизнес-ориентированных движков — это прежде всего производственные движки, а сложные системы обработки событий — преимущественно реактивные.

Некоторые движки поддерживают также обратный вывод (backward chaining), при котором движок пытается найти факт, соответствующий заданной цели (goal driven), исходя из уже известных данных.

Также существуют движки, способные переключаться между прямым и обратным выводом во время работы — примером служит система Internet Business Logic.

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

В ряде задач, например при классификации клиентов, оценке неполных данных, вычислении ценности клиента, может применяться нечёткая логика, где используются эвристики, а не булевы правила. Примером служит язык DARL^[21] и связанный с ним движок и редакторы.

С развитием технологий машинного обучения выделяют предиктивные и адаптивные движки бизнес-правил. Предиктивные системы используют прогнозы ML-моделей в качестве входных данных для классического движка, который принимает окончательное решение на основе детерминированной логики. Адаптивные (самообучающиеся) движки способны автоматически модифицировать существующие или создавать новые правила на основе непрерывного анализа поступающих данных^[22].

Отдельным направлением являются гибридные интеллектуальные движки, основанные на концепции нейросимволического искусственного интеллекта. Они сочетают символическую логику традиционных правил и возможности нейронных сетей. В таких системах нейросети применяются для обработки неструктурированных данных и выявления паттернов, а символический компонент (движок правил) обеспечивает строгое применение бизнес-логики, нормативных требований и интерпретируемость принимаемых решений^[23].

Обычный пример использования движков правил — стандартизированное управление доступом к приложениям. Организация OASIS разработала архитектуру движка правил и стандарт поддержки доступа — XACML (eXtensible Access Control Markup Language).

Ключевое отличие движка правил XACML от обычного движка бизнес-правил состоит в отсутствии состояния (stateless) и невозможности изменять состояние данных.

Движок XACML, называемый Policy Decision Point (точка принятия политики), получает на вход бинарный вопрос («Может ли Алиса просматривать документ D?») и возвращает решение (разрешить/запретить).

Для реализации динамической авторизации на основе атрибутов (ABAC) в реальном времени применяются современные технологии, такие как Open Policy Agent (OPA) с декларативным языком Rego, а также концептуальная модель Next Generation Access Control (NGAC)^[24].^[25]