skip to Main Content

This page was archived on 11th March, 2019 and is no longer actively maintained.

Business Rules Management

Last Updated:
Analyst Coverage:

A business rule is an operating principle, practice or policy of an organisation. It has to be adhered to in order to satisfy either a required common approach to a particular event or regulatory requirements for the industry that the organisation is part of. It is a statement of truth about an organisation and is an attempt to describe the operations of an organisation, not an attempt to prescribe how an organisation should operate.

Business rules management software (BRMS) is a software component that is used to define, register, verify consistency, deploy, execute, monitor and manage the variety and complexity of decision logic that is used by operational systems within an organisation or enterprise. This logic, also referred to as business rules, includes policies, requirements, and conditional statements that are used to determine the tactical actions that take place in applications and systems. The BRMS also provides the ability to define the relationships between different rules, and relate some of these rules to IT applications that are affected or need to enforce one or more of the rules.

BRMS includes, at minimum:

  • A repository, allowing the defined rules to be managed in terms of versions and variants and be available for reuse
  • A development environment, which provides tools for both technical developers and business experts to define and manage the business rules
  • A runtime environment, allowing applications to invoke business rules managed within the BRMS and execute it using a business rules engine
  • A management environment that provides the ability to not only monitor the development and runtime environments, but also manage them both.

BRMS products have 3 real components: a development environment where the rules are developed and tested; a runtime environment that applies the rules when the applications are being used live; and a management environment that monitors and control the runtime environment.

In the development environment we need to look at:

  • Architecture – ability to develop a data abstraction that represents the business entities and relationships that rules should be written against.
  • Rules development – currently there is no standard language for rules development, so rules can be expressed in a way similar to conventional programming languages,  in languages resembling natural ones, in user-friendly rule forms such as decision tables and decision trees.
  • Data capture – provide capabilities to capture rules from existing sources including decision tables, drawing packages such as Microsoft Visio and even programming code.
  • Reports, forms and dashboard designer(s) – provision of the ability to create reports, online forms and dashboards.
  • Testing and simulation – ability to test the rules that have been defined and to simulate bsuienss conditions to see how the rules will behave.
  • Interface with standard development and office environments – ability to be integrated with either Eclipse for Java or Microsoft Visual Studio for the .NET Framework environment.

In runtime environment we need to look at:

  • Rules engine – these are the pluggable software components that execute business rules that have been externalised from application code as part of a business rules approach. They make use of chaining methods and algorithms.
  • Runtime API – provision of a call-level interface (may be based on the JSR-94 API standard) in order to allow for integration with different applications, and many rule engines allow for service-oriented integrations through Web-based standards such as WSDL and SOAP.

The requirements that need to be supported in the management environment are:

  • Monitoring  (Business Activity Monitoring)
  • Notification and alerting facilities
  • Business intelligence/online analytical processing (BI/OLAP) support for event analysis
  • Policy support, constraints and tolerance support
  • Interface to systems management tools

With the need for business to be more agile and flexible than it has ever been, in conjunction with scarce resource of time from IT departments, BRMS offers an approach that allows the business to take control of the rules and conditions within their organisation, whilst allowing IT to still have the ability to control and manage the IT environment of the organisation.

Emerging standards are a feature of BRM. In a BRMS, a business representation of rules is mapped to a software system for execution. A BRMS is therefore related to model-driven engineering, such as OMG’s MDA. It is no coincidence that many of the related standards are under the OMG banner. There is no current implementation standard for business rules defined within a BRMS, although there is a standard for a Java Runtime API for rule engines: JSR-94.

Other standards (under development) include:

  • OMG Business Motivation Model (BMM): A model of how strategies, processes, rules, etc fit together for business modelling.
  • OMG Semantics of Business Vocabulary and Business Rules (SBVR): Targets business constraints as opposed to automating business behaviour.
  • OMG Production Rule Representation (PRR): Represents rules for production rule systems that make up most BRMS’ execution targets.
  • W3C RIF: A family of related rule languages for rule interchange.
  • Rule Mark-up Language (RuleML) – web language for rules using XML mark-up and formal semantics.

An interest in vertical frameworks is emerging, largely because one way to differentiate yourself is to provide specialist knowledge about rules in a particular vertical domain. A slightly different picture emerges here in terms of support, with a mix of BRMS vendors from the very small to the very large providing vertical frameworks.

Finally, as usual, Software as a Service (SaaS) is becoming an interesting part of BRM – almost always used to reduce costs, both the up-front costs of the systems themselves and the infrastructure required to support them (although, longterm, it should probably be seen as delivering business agility as much as cost reduction).

There are 5 basic categories that can be used to separate the products out in the market [see the Bloor BRMS Markewt Update, TBA):

  • Stand-alone chargeable – CA (Aion Business Rules Expert), InRule Technology, FICO (Blaze Advisor), Innovations Software Technology (Visual Rules), Informavores, VDE Technologies (Rueltab.NET), Versata.
  • Stand-alone “free” – (Drools), OpenRules Inc (OpenRules), Agilepartner (NxBRE); Sierra Digital Solutions Corp (SRE), Kontac (SmartRules).
  • Expert system – XpertRule Software, Amzi!, EXSYS Logic Programming Associates Ltd (VisiRule).
  • Part of Application package or Infrastructure package – Microsoft (BizTalk Server BRE), SAP (Netweaver BRE), Mindbox (ARTEnterprise), GlobeRanger: iMotion.
  • Part of BPMS suite – IBM (Websphere ILOG family), Oracle (Business Rules), Pegasystems (PegaRULES), Progress Software (Corticon), Esker (DeliveryWare).

The major change to the landscape is the increase in the last category, as major vendors such as IBM and Oracle acquire specialist vendors such as iLog.


Coming soon.


    These organisations are also known to offer solutions:

    • Agilepartner
    • Amzi!
    • Esker
    • EXSYS Logic Programming Associates
    • FICO
    • IBM
    • Informavores
    • Innovations Software Technology
    • InRule Technology
    • Kontac
    • Microsoft
    • Mindbox
    • Pegasystems
    • Sierra Digital Solutions
    • Sparkling Logic
    • VDE Technologies
    • Versata
    • XpertRule Software


    Coming soon.

    Back To Top