The Evolution of BRF to BRFplus: From Naming Conventions to Robust and Transparent Governance

[ttrapp]

In the last time I had many interesting talks with experts for the old BRF tool that learned about BRFplus. It is really interesting that those people have a completely different view how to structure rule systems. Today the challenge is that BRF and BRFplus have a different architecture: I recommend you to read this document if are interested in a comparison. This document is technical but it has serious consequences:

• BRF has no mechanism neither for “hiding” rules as privacy concern nor controlled reuse between applications where BRFplus has both.
• BRF is limited but BRFplus is open and extensible: it has an API, multiple extensions points and even parts of its UI is reusable.
• Understanding BRF rules requires expert knowledge – BRFplus rule systems can be created that they are readable by business experts.
• BRF forces you to create rule systems in a bottom up approach since you have to do many preparations until you can start to build up your rules – f.e. using nested expressions to access the context. As consequence in BRF projects you have to create many artifacts until you can start your work. BRFplus is easier to handle and allows more agile approach to creation of rules.

To fight all weaknesses mentioned above good old BRF has only one answer: use proper naming conventions. The challenge is that naming conventions have to be quite sophisticated to cover all those different aspects and often you have to use develop additional tools to ensure that changes and maintenance can performed in a robust way. Those tools are not necessary when you are using BRFplus or they can be built using the BRFplus API with less effort and costs. But let's get back to BRF: with naming conventions you organize separation of concerns, reuse, documentation and keeping control of a plethora of different artifacts. So it is not really surprising that the first question of a BRF expert is what naming conventions you are using in BRFplus. So when you as BRFplus expert try to explain to differences between BRFplus and BRF to a BRF expert it will lead most likely to the following discussion:

Q: I did some experiments with BRFplus workbench and decision tables. This is really cool and we can use it to create complex rules with a few mouse clicks. But can you tell me about BRFplus naming conventions?

A: BRFplus doesn’t require naming conventions. The reason is that technical identification for an object is completely different in BRFplus compared to BRF, only in the context of functions and rule sets the technical names have to be unique. Please consider that there are completely different scenarios for BRFplus. If you implement rule sets on top of a BRFplus application shipped by SAP it is likely that SAP recommends a certain system as implementation guideline and I recommend to be consistent to this system. But don’t expect that this system is the same in the whole business suite since the underlying SAP applications are different and so is are the corresponding BRFplus applications. But there is nothing to worry about it since BRFplus is more transparent and easy to understand compared to BRF.

Q: But I need naming conventions to structure my application.

A: Yes, but at first I recommend that you try out other features like catalogs to structure your application since they offer advanced features. And don’t forget, unlike BRF objects in BRFplus (like rules and expressions) don’t need to have a name.

Q: No name? Weird, what is that good for?

A: If an object has a name you can reuse it and this can be fatal if it is misused in many parts of the application or even in other applications.

Q: Reuse between applications? This wasn’t possible in BRF. But let’s discuss the misuse first. In fact this is really a problem in BRF since it is hard to test the side effects of a change.

A: Exactly. If an object has “local scope” then don’t give a name to it since sometimes it is better to avoid reuse it and to create a new rule. This is so easy with Drag&Drop and sometimes redundancy is good for you since you can perform changes independently.

Q: But will agree that some expressions and of course rule sets should be reusable – and how do I name them?

A: As I told you, have a look at the SAP implementation guideline, and in custom development you have to make a choice – but renaming objects is very simple. In my opinion the longtext is more important than the technical name.

Q: Why?

A: Since they allow you to create rules that are easily readable like running text.

Q: This is cool. So you recommend me to learn how to create readable rule sets, learn about the new features of BRFplus, about features of reuse between applications, how to prevent reuse in some cases and how to create structured BRFplus applications.

A: Exactly. In BRF you can only use naming conventions for all those requirements and you have new possibilities and to learn about them is mission-criticial.

Q: Hey, the fact that you can use object without names has an interesting consequence: I can create rules and expressions on the fly, isn’t it?

A: Yes, you can create your rule system top-down instead of bottom-up. In BRF this wasn’t possible since you had to do many preparations like using nested expressions to access the context. In BRFplus this is much easier and you can focus on business requirements and even create the rule system with business experts together using the BRFplus workbench.

Q: So using BRFplus is more than just performace gain? It is about creation of more readable, more transparent and easy changeable rule systems?

A: Yes. And DSM has even more advantages.

Q: So tell me, what is DSM about? And let’s discuss the transportation mechanism and workbench tooling.

A: Well, that’s not a topic for the coffee-corner. Let’s meet together in the office tomorrow. We can discuss the system landscape and transport mechanism on the whiteboard.

Q: Great. See you tomorrow!

A: Bye, bye!