The recent LinkedIn discussion “What rules representation to choose for which audience?” came to the question about business analysts handing their business rules written in plain English over to IT for an implementation. Here is how I responded:
Handover to technology? This used to be a real problem in the early days of BR adaptation. In real-world cases rules are not described with one simple statement like C above. There are usually exceptions, exceptions to exceptions, mitigation criteria, and so on. To make sure that their plain English rules are “consistent, complete and valid conditions for efficient handover to technology” BAs need either to run the rules through the proper validation and verification tool or at least to test them using representative enough use cases. In both situations, the rules need to be EXECUTABLE.
That’s why initial attempts to force BAs to write “rule-books” that later on will be handed over to programmers as a specification for an implementation failed badly. That’s why the agile approach came to play by insisting that “there should be no documents that cannot be executed”. That’s why initial BR approach was transformed to now commonly accepted Decision Management (DM) approach, when BAs who define business decision logic are also responsible for the testing and ongoing management of such logic. BAs “handover to IT” already well-tested decision models (including rules and related test cases) and only to integrate them with a specific IT infrastructure (DB, messaging, security, etc.) In most cases IT is not supposed to even look at the business logic and simply make sure that the proper decision service is invoked efficiently with the correct data in the production environment.
It could be helpful to consider at least one real-world example. So, below I will briefly talk about two BR approaches based on the major European Patent Office (EPO) project described at this BRForum presentation. In 2007, after BR training from the best BR methodologists, EPO specialists were stuck with writing well-structured MS Word rule-books in plain English specifying how to process patent applications for 80 different countries. Their approach was described as below:
After EPO business analysts (rule book authors) handed their rule books to IT as specifications, several months later they received an implementation based on then selected BRMS. The results produced by that BRMS were quite different from what BAs expected while IT insisted that the rules were implemented in accordance with the specification (rule books) they received. EPO called this approach “a good old way” when business defines the rules and developers implement them.
OpenRules got involved when 20+ rule books were written and each had 50-60 pages. However, EPO already recognized that such a BR approach led them to nowhere. We offered a completely different BR approach:
So, we eliminated a creation of non-executable documents and let BAs to create and maintain executable rules directly in Excel. The BAs were able to execute their rules against test cases created by the same BAs (also in Excel). The fact that BAs now had clearly defined Excel-based decision tables and an ability to execute them directly against their own tests, cleared their minds from necessity to explain the execution logic to IT. As the result, their rules became much simpler, self-documented, and shared between different specialists without additional explanations.
This “new” approach became a foundation for a quick and successful implementation when business is in charge of the business logic. IT only helped with creation of a limited number of rule templates based on which thousands of actual rules were created by BAs. Today, with our latest DMN-like approach, IT does not even need to support custom rule templates as they are provided and supported by the vendor (OpenRules). IT is mainly responsible for the integration. More importantly this approach supports continuing maintenance and enhancement of the enterprise-level rules repository.