Business Rules Management Systems (BRMSs), business rules engines, knowledge management systems, expert systems, predictive analytics systems, and decision management systems are only a few of the terms which are currently used to refer to software packages used to specificy, execute and manage business logic (business rules, decisions / knowledge). However, is each term being used to refer to a software package with unique features? Very carefully expressed: probably not. A very important question which then immediately arises is: “How can business logic management systems be classified?” This classification can be very important for organizations since it can support them during the selection process of a BRMS.
Different classification schemes exist to classify BRMSs. Two commonly used schemes are: 1) a classification regarding the variability of a business rule and 2) a classification regarding the life cycle of a business rule. This article elaborates on the second mentioned classification scheme: the classification regarding the life cycle of a business rule.
The classification scheme regarding the life cycle divides BRMSs into four categories: 1) analysis and design systems, 2) pure-play specification systems, 3) pure-play business rule engines, and 4) specification and execution systems. This subdivision is made based on which of the seven development phases are supported by a BRMS (see Figure 1). For the establishement of a business rule, the following seven development phases are traversed: elicitation, design, specification, verification, validation, deployment and execution (see Figure 1). Besides the seven development phases, two additional phases are distinghuised for management and control: evaluation and governance. Both management and control phases require specific functionalities of a BRMS, but this will be discussed in a subsequent article. To the knowledge of the authors, there are currently no software systems available which support all the seven phases.
The first category, analysis and design systems, support the elicitation and design phase. These software systems support a subject matter expert with analysing and annotating source documentation. Analysis and design systems offer the ability to upload the source documentation and to annotate this documentation with regard to several elements. Examples of elements that can be annotated are: contexts, terms, roles, and business rules. Furthermore, these types of software systems also offer the ability to insert the annotated elements in structures, like decision requirements diagrams, context structures and decision structures.
Figure 1: Classification of BRMS regarding the life cycle
The second category, pure-play specification systems, support the design phase, specification phase, verification phase, validation phase, and deployment phase. Beside the design of decision requirements dragrams and associated decision structures, these software systems also support the specification of the underlying business rules, (business) concepts, fact types, and fact values. Most of the pure-play specification systems lack the ability of creating a link from a product (e.g. context structures, business rules, etc) to the source documentation. If such links exist, it is usually very rudementery, for example a hyperlink to a document or website. In contrast, these software systems often include the ability to automatically check if business rules contains lexical, syntactic, or domain errors. In addition, these software systems check if the business rule set contains conflicting, identical or equivalent business rules. The validation process is supported by the establishment of test cases, which can be applied to validate the specified business rules. Furtermore, these systems provide the ability to (automatically or supported by technology) deploy the defined contexts and underlying business rules and facts in (different) business rule engines. An additional last remark that should be made about pure-play specification systems is that many of these software systems currently only provide limited support for the verification phase, validation phase, and even less for the deployment phase.
The third catagory, pure-play business rule engines, are software systems that generally only consist of two components: 1) an engine (inferencer) in which the business rules are executed, and 2) a repository in which the business rules that should be executed are stored. The difference between a Business Rules Management System (BRMS) and a pure-play business rule engine is that an engine is merely focused on the execution of business rules and does not support other phases and activities. This means that, for example, the processes designing and specifying business rules should be carried out in other software systems
The last (fourth) category, specification and execution systems, are software systems that support all the phases from design and/or specification to execution. For this fourth type of systems applies that the deployment phase always leads to the execution performed by means of the execution engine that is included in the system. The difference between a pure-play specification system and a specification and execution system is that when a pure-play specification system is used, the business rules are specified in an implementation-independent way, assuming that the business rules will be executed in a different software system. As mentioned previously, a specification and execution system on the other hand has its own execution engine (inferencer) and the business rules are specified in a specific way in order to be readable by this specific engine.
co-author: Koen Smit
Reviewer: Eline de Haan