Use of Formal Language as Challenge in the Design Process of Rule Systems

[ttrapp]

One critical success factor in business rule projects is the communication between business and IT. This is not surprising since it holds for every IT project, but when it’s about business rules it becomes urgent. The reason is that in business rule projects business people have to define sometimes complex computations which are in fact algorithms. The challenge is that those algorithms are complex artifacts and they have to be designed carefully since they automate core processes.

What skills are needed to define algorithms? How do we get an understanding for algorithms? SAP Mentor DJ Adams gave a TEDx-Talk in Birmingham where he explained why everyone should be learn how to code at school. He argued that information technology is so fundamental in today’s world that everyone needs to understand the basics even if he or she will choose a completely different job in the future. I totally agree with his opinion and for the ones who don’t know his talk I’ll share the link to the Youtube video of this talk about “our computational future”.

But what’s the connection to business rules? I believe that business rules are part of our computational future. With business rules you can control the processes within ERP system so that they are transparent, easy to understand and easy to change. The rules are specified by business people and have to be translated into BRFplus that is in fact a formal domain specific language for rules.

Usually people from an IT department will code those rules BRFplus and they will do it in a way that business people who are the owners of rule systems can read them. In BRFplus this is very easy:

• As a BRFplus developer use (long) texts for BRFplus objects so that your rules are readable like normal text. Moreover use documentation and DDIC binding /resp. domain values so that data elements are displayed together with texts.
• Define a special role for business people so that business people can start the workbench, read (but not change) applications and perform simulation.

With a little bit effort a BRFplus developer is able to explain and to discuss a BRFplus implementation of a rule system with business people who are owner of the rule system. 

But one challenge still remains: how is the rule system created? How do business people explain a BRFplus developer what to do? Here there are two possibilities: a business user can write a specification or he can create it together with a technical expert of a business rule system. I prefer the latter. The reason is that from my experience most specifications are error-prone: they contain typos, sometimes contradictions and sometimes they lack of precision. Therefore it is necessary to find a common language of business people and IT. For me decision tables are a very powerful and easy to understand so I use them very often and with much success. And if there are still misunderstandings between business and IT I prefer a direct conversation.

But what is the root cause of communication problems between business and IT in the area of business rules? From the viewpoint of a rules developer I have to understand the requirements and translate into a formal language. With the help of above mentioned best practices I can do it in a way that business people can understand a rule system. But first I have to understand the business people and their requirements. IMHO one challenge is that many business experts without any IT education or comparable skill have difficulties to understand or think in formal languages. This can lead to consequences in a specification process of a rule system:

• Developers are trained to use a top-down approach. At first they look at the overall structure of a rule system and define functional parts. In most cases they are very easy: in the first step you have to collect all data needed to perform checks and calculations. Then you perform the checks and calculations and later you look at special cases and exceptions. People who are not trained to analyze a problem this way often start to explain business rules by explaining exceptions and special cases. This often will lead to confusion and ugly implementations.
• In the center of a business rule system like BRFplus are rules which have an IF … THEN … ELSE structure. Developers are very familiar with those. So they know that Boolean conditions with many operators like AND/OR are hard to understand and they will use parentheses to make the structure clear. On the other hand some people in business are not aware of the different semantics of “or” and “either or” for example. This can lead to more problems.

The conclusion is very simple: Sometimes business experts are well trained since they’re familiar with software like Excel or Access but there are also others who have difficulties thinking in formal languages and Boolean logic.  I agree with DJ Adams: Everyone should have some basic skills coding so the barrier to specify and understand a formal rule system like BRFplus would lower. This doesn’t mean that everyone should have the skills of an experienced programmer but he should have a vague idea how an algorithm works and that a precise description is needed to create one. 

When talking to business experts I often experience some difficulties to understand what they mean. I would like to give the following advice that could make the conversation easier:

• Think of a rule system as a function with defined input and output parameters.
• Be precise – try to avoid terms like “perhaps” in your specification.
• Try to use a notation like DMN for specification of rule systems.
• Use parentheses if you define complex Boolean conditions.
• Use test cases and the simulation mode in BRFplus.
• Don’t specify a rule systems by writing down special cases first – focus on the general case.

On the other hand I also recommend that a BRFplus developer has at least a basic understanding of the business process and tries to understand how the rule system should work. So it’s the same old story: business and IT have to find to find a common language. I think BRFplus can be “spoken” by both if both sides are willing to do use it.