Что-то подумал и решил написать вообще про BRMS (Business Rule Management Systems). Или, говоря простым языком, про системы управления бизнес правилами.
Постоянно сталкиваюсь с ситуацией, что аббревиатура BRMS на посконных просторах нашей многострадальной Родины для многих звучит как птичий язык. К ERP вроде уже привыкли, привыкли к CRM, BPM, постепенно привыкаем к MDM. Поэтому будем расширять кругозор. Из последних наблюдений, про существование BRMS знают либо глубоко погрузившиеся в информационные технологии бизнес-консультанты, либо передовые граждане, имеющие статус IT MBA (или находящиеся в процессе его получения).
Для начала следует разделить BRE и BRMS. BRE (Business Rule Engine) или движок/механизм исполнения бизнес правил. Это то, что часто можно встретить уже встроенным во многие современные информационные системы и что обеспечивает обработку этих самых бизнес-правил. Если говорить про приложения Oracle, то сразу можно вспомнить AME (Approval Management Engine) входящий в состав Oracle E-Business Suite или Oracle Business Rules используемый для обработки бизнес правил в Oracle BPM.
В случае c AME имеем адский треш из настроек в E-Business Suite и кодировании правил на PL/SQL.
В случае c Oracle Business Rule тоже в общем интуитивно понятно и доступно средне-статистическому бизнес пользователю и, по совместительству, программисту
Зайдем сзади и возьмем, для примера, симбиоз израильской технологической платформы NetWeaver и встроенного адаптированного BRE индийской конторки YASU (вроде бы читается как ЙаСсу). Или более привычным для обывателя будет упоминание SAP ECC. Здесь это выглядит так.
Перечисленные выше примеры, наверное, можно отнести к BRE, встроенным в различные системы. В этом и есть основное отличие BRE от BRMS. BRMS является самодостаточной системой по автоматизации бизнес-правил и регламентов, которая включает в себя как средства создания (моделирования) бизнес-правил, так и исполняемый модуль/движок (BRE).
История BRE/BRMS насчитывает уже несколько десятилетий. Начиналось все с методологии и алгоритмов, которые появились в 70-х годах и которые в конце 80-х получили свою реализацию в виде модулей и самостоятельных информационных систем.
На сегодняшний день каких-то универсальных и общепринятых стандартов для BRMS/BRE не существует, хотя большинство производителей придерживаются индустриальных стандартов OMG (заявляют во всяком случае, что придерживаются).
Одним из ветеранов движения является Haley Office Rules, BRMS-система компании Haley Systems LTD (1989), которую в 2008 году поглотил Oracle. И сейчас у Оракла помимо нескольких, частично перечисленных выше BRE-движков, имеется отдельное направление и линейка продуктов BRMS, которая называется Oracle Policy Automation (OPA). И про которую я, в последнее время, часто езжу тут по ушам редким читателям. Про OPA еще будет, но чуть ниже.
Не сказал бы, что активно слежу за тем, что делают конкурирующие производители BRMS/BRE программного обеспечения, но разделил бы всех на две группы и три класса.
ГРУППЫ BRE/BRMS
Группа 1. Свободно-распространяемые BRMS.
Drools – что сделан на JBoss Rules
InRule – с некоторых пор стал отчасти свободным
OpenRules – тут все открыто, но можно использовать Excel и позиционируется продукт как BDMS Я бы поостерегся, но расшифровка более чем прозрачная Business Decision Management System.
NXBRE и т.п. разработки, которых определенное количество на рынке имеется и используется.
Группа 2. Коммерческие BRMS.
- RedHat JBoss BRMS
- IBM ILOG ODM Enterprise
- Oracle Policy Automation
- Fico Capstone Decision Manager
КЛАССЫ BRE/BRMS
Класс 1. Поддержка JAVA-спецификации JSR-94
IBM ILOG JROOLS, Oracle Policy Automation, Red Hat JBoss Rules
Класс 2. .NET
Drools (поддержка JSR-94), IBM ILOG .NET (поддержка JSR-94), INRULE, NXBRE и т.д. и т.п.
Класс 3. Неведомый винегрет
OpenRules, Coricon (интересный проект), Ruby Rools (для брутальных бородачей в вязаных свитерах ).
Отдельно хотелось бы рассказать про Oracle Policy Automation (OPA).
Отличительные черты OPA для российского рынка и стран СНГ:
- Для формирования модели с бизнес-правилами используются MS Word и MS Excel;
- OPA локализована и бизнес-правила можно писать на русском языке (в общем можно писать правила на любом языке использую OPA RLS (Rapid Language Support Tool));
- Коробочное решение. После создания модели с бизнес-правилами, OPA позволяет работать с моделью как с независимым web-приложением или обращаться к модели через web-сервисы. Можно даже из командной строки к модели обращаться.
- Наличие технической поддержки продукта от крупной корпорации.
OPA опирается в своей работе на общепринятую спецификацию JSR-94, но обогащенную собственной разработкой RML (Rule Markup Language). По новомодному это еще называется изоморфизмом документа с правилами. Чтобы долго не говорить, лучше это показать один раз на картинке:
Пару раз ко мне уже обращались адепты свободно-распространяемых BRE/BRMS с вопросом, что еcли OPA такая крутая и поддерживает JSR-94, можно ли взять и купить только удобное средство моделирования Oracle Policy Modeling, делать правила в нем (в Word и Excel), а готовую модель потом запускать в свободно-распространяемом и бесплатном BRE-движке? Ответ мой был таким. Из “коробки” скорее только не заработает. Если есть желание – ставьте эксперименты.