Configuration By Exception: Why BRFplus is Superior to Customizing
If you are reading my blog you will have recognized that the business rule framework BRFplus resp. DSM is my favorite topic at the moment. The reason is simple: I consider it as strategic technology, I’m using it successfully and many colleagues of mine ask me about my experience. Luckily I have very smart colleagues and they are asking me good questions. Today a senior developer heard my explanation about BRFplus and had the following remark:
Ok, you may be right that BRFplus is more powerful and flexible than customizing but customizing has one big advantage: I can use it for configuration by exception. Often my processes are standardized and I can ship the configuration (= business rules) as customizing content. Often this is exactly what the customers want but if they would to change it I create a second customizing table which is empty and filled by customers in a customizing process in a kind of “configuration by exception” approach”: the framework reads the customizing entries from both tables and if there’s an entry found in the second table it overrides the first one. So using customizing you can implement a transparent and lean approach to system configuration by implementing only exceptions. So have to the advantages of both approaches: My applications are running out of the box with reasonable “master customizing” that can be overruled in a “configuration ba exception” approach.
This approach is really clever since it gives a solution to a common challenge: developers want to make implementation and maintenance of a customizing-driven application easier by shipping a “master customizing” which is owned by them and also introduce a two-stage approach that allows to overrule the customizing by customers. This approach has some advantages but also some problems, which I will discuss, too. But at first this was my response:
With BRFplus decision tables you can do exactly the same:
- Just create a names decision table that has the same functionality as the customizing table. Use is in a rule set that can be assigned to a function.
- If a customer wants to have a configuration by exception mechanism he can copy the decision table and create another one for his entries as well as a simple rule that performs the two-stage approach described above.
- Of course speed it up be providing a BRFplus customizing project with exactly this functionality but can be used by the customers (or generate it in the fly using the BRFplus API).
I consider this approach as superior to the customizing solution:
- At first it will be faster since you need no database access – BRFplus compiles everything to code.
- Decision tables are more powerful than customizing tables since they support expressions and ranges. Moreover there are automatic checks for them as well as excel integration.
- They have a version mechanism that is superior to customizing.
- And last but not least there is a solution to a maintenance problem: If your “master customizing” changes this often requires an information process to people who overruled the “master entries”. With traditional transport mechanism (transport / BC Set) this is complicated, but you could use the BRFplus API to inform about changes or generate documentation about changes.
The following discussion shows a very simple fact: SAP solutions are extensible and configurable. The reduce the implementation effort and speed up the implementation process developers created quite sophisticated solutions in the ABAP world that are comparable to paradigms like configuration by exception which are quite common in the (more agile) Java world. But with BRFplus you can implement exactly the same solutions and even improve them.