Misconceptions about SAP Decision Service Management vs. BRFplus

[former_member190447]

I recently met some customers who asked me for advice about their BRFplus projects. Actually, I am with a customer right now who has been working with BRFplus for years and recently decided to go for SAP Decision Service Management (DSM). Other customers have been pondering this exact decision for quite some time but have not yet made a move forward. Why is that? Or even worse, they haven’t even started to think about DSM at all.

We built DSM to enhance the capabilities of BRFplus. This started by with segregating design time and runtime by introducing the remote deployment of decision services. Then there are plenty of new tools and features that come with DSM, like a debugger, test case administration, trace visualization, multi-system deployment, HANA integration, and more. So for sure, customers should be eager to move from BRFplus to DSM as soon as possible. Unfortunately this is not true as I’ve learned over the last few months. Some customers are hesitant to move to DSM for several reasons. The most popular ones are:

• DSwhat?
• DSM comes with a price tag while BRFplus is free. We can’t spend any more money.
• I need to integrate with HANA and run my rules in a JAVA stack. So as I need to replace BRFplus by other rules engines anyway, I won’t invest in an add-on to BRFplus now.
• BRFplus is good enough. We don’t need anything more. By the way, how can I change rules in the productive system directly?
• We can’t have a central design time system as a single point of failure. If this system fails, the complete system landscape goes down.
• Since we’re using BRFplus with an SAP application that has not yet migrated to DSM, we can’t switch to DSM.

Fortunately, SAP has some convincing answers to these arguments. Looking at our growing customer base, more and more customers see the benefits of DSM over BRFplus. Nevertheless, I feel bad when I see other customers struggling with BRFplus when they could be cheaper, quicker, and better with DSM. So let’s take a closer look at the topics mentioned above.

DSwhat?

From time to time customers ask for BRF, or BRF*, or maybe BFR+, or for any other acronym that has some phonetic proximity to BRFplus. Some customers have never heard the term SAP Decision Service Management and that’s a real shame. So let me sort out these terms.

• There are no SAP products called BRF* or BFR+.
• BRF is an old product that has been obsolete for some time. A few applications still use it though but most of them will switch to BRFplus or DSM soon.
• BRFplus is the rules engine in the SAP ABAP stack.
• SAP Decision Service Management (abbreviated to DSM) is an add-on to BRFplus, which significantly extends its capabilities. It especially permits segregating design time and runtime and comes with many fancy tools and features like test case administration, a debugger (https://scn.sap.com/docs/DOC-48582), trace visualization (https://scn.sap.com/docs/DOC-53794), HANA integration (http://scn.sap.com/docs/DOC-47443, https://scn.sap.com/docs/DOC-51479), and more.

Comprehensive information about DSM can be found at SCN (http://scn.sap.com/docs/DOC-29158). I would also be happy to provide you with an overview session or help you build a POC. Please get in touch with me if you’re interested.

DSM comes with a price tag while BRFplus is free

Yes, it’s true, DSM comes with a license but unfortunately BRFplus isn’t really free either. But BRFplus is part of SAP NetWeaver and as such requires an SAP NetWeaver Foundation for 3^rd Party license. As most customers have this license anyway, they don’t need to put additional money on the table to use BRFplus. So yes, it might look like DSM is more expensive than BRFplus but, on the other hand, several tasks in a project become quicker and easier when you use DSM. Business users can perform steps without IT support; and you become more agile. This leads to a fast return on investment for your DSM implementation. Keep in mind that business rules are changing frequently, and in most cases it is crucial to apply changes immediately. Let me explain this with a concrete example.

Let’s consider the following scenario with BRFplus: You are running pricing rules that determine which product is sold to which customer under which condition. Now your long-time competitor starts a campaign offering discounts for specific products. You decide to run your own campaign to keep up with your competition. So your sales manager changes the rules accordingly to reflect the temporary pricing metric in use during the campaign. This is an easy task, as BRFplus workbench allows to model business rules in a very intuitive way. Of course you need to test these rules before you can use them productively. In order to do so, your IT department needs to replicate masterdata from productive system to QA system, and the rules need to be transported from the development system to the QA system as well. Unfortunately the next transport cycle isn’t due for another three weeks. But your CIO gets you an emergency transport which is run by IT. So within a few days, and with the help of IT, you have rules and data in the QA system and can start testing. When the tests are done, you want to use the rules in your productive system. The next transport cycle still is way in the future. This time you can’t get approval for a special transport. You can’t accept waiting for another two weeks while your competitor steals your customers. So you need to apply the rule changes directly in the productive system. Technically this is possible, but you need to be careful not to spoil your productive system. So you have to implement a sound governance process. Not only to ensure that the correct changes be applied, but also to handle the transport from the QA system to the productive system that will interfere with your manual changes two weeks’ time. So perhaps within a week, and with a lot help from IT, you’ve gotten your rules adapted. Finally, you can start fighting your competition, but by now your competition is a week ahead and you have already lost valued customers and valuable time.

Now, let’s consider the exact same scenario but with DSM in place. Again you need to start a campaign as fast as possible. Your sales manager applies the rule changes in the DSM system, which is the central design time system. As before, he uses BRFplus workbench to do so. Testing can take place directly from within the DSM system. Under the hood, the decision service is being deployed into a staged area of the productive system, so that it doesn’t interfere with the current productive processes. There the test is run, using the actual master data from the productive system. No data replication is needed. The test results are handed back to the DSM system where they can be analyzed. Using test case administration that comes with DSM, you can run regression tests with a large number of test cases. When testing has finished successfully, the sales manager deploys the changed decision service to the productive system. He can do this without IT support. The whole deployment takes less than a minute. Within a few hours, the rules are adapted and can be used productively, and you have countered the competitive threat before it has a significant impact on your business. There is no need to touch the productive system directly, and no need for complex, political negotiations with your IT department to organize emergency support.

So DSM significantly reduces the time from request to realization, comes with massive effort reduction, lets you adapt your rules without IT support, avoids the risk of applying changes directly to a productive system, and allows you to turn a threat into an opportunity. Now compare this to the DSM license costs …

I need to integrate with HANA and run my rules in a JAVA stack

BRFplus and DSM have many things in common. For instance, both of them are ABAP-based, and both generate ABAP code from the rules that are being processed at runtime. But DSM can do more.

Relevant expression types, such as decision tables or database lookups can be pushed down to HANA, avoiding the ABAP layer. Tests revealed performance improvements of up to a factor of 1300. For details, please refer to the documents Dynamic Database View Capability of SAP Decision Service Management (http://scn.sap.com/docs/DOC-47443) and Integrating HANA with SAP Decision Service Management (https://scn.sap.com/docs/DOC-51479) on the DSM page in SCN (http://scn.sap.com/docs/DOC-29158). HANA Stored Procedures can be called from within a decision service so that HANA integration is available. Further DSM with HANA capabilities are currently being developed. Stay tuned.

Just like generating ABAP code, code-generating capabilities for other platforms can be provided. Partner enablement of DSM permits respective code generators to be plugged into DSM. Decision Service Accelerator (http://scn.sap.com/community/brm/blog/2013/10/13/dsa-decision-service-accelerator) from Mouritech (http://www.mouritech.com) is this type of offering for the JAVA stack.

So there is no need to consider other rules engines for HANA integration or for JAVA integration. By the way, there is no other rules engine in the market that allows for the integration with ABAP, JAVA, and HANA.

BRFplus is good enough

BRFplus is good enough is an argument I hear quite frequently. Except often the “good enough” argument comes with questions about specific, desired features or capabilities like applying rules changes to a productive system directly, running regression tests, sharing common rules across multiple systems, or integrating with a HANA database. In most cases DSM provides an answer to these questions. By being able to deploy decision services from the DSM system to a managed system immediately, no more changes are needed in the productive systems. Test case administration, multi-deployment, and HANA integration are capabilities that are provided by DSM out of the box. DSM also offers many features that are very well received by customers, even if they never thought about these before. Those features include the deployment approval workflow (https://scn.sap.com/docs/DOC-53371), debugger (https://scn.sap.com/docs/DOC-48582), trace visualization (https://scn.sap.com/docs/DOC-53794), and of course the segregation of design time and runtime.

So, BRFplus is only good enough as long as you do not eat from the tree of knowledge. And many common requirements of experienced BRFplus customers are fulfilled with DSM.

We cannot have a central design time system as a single point of failure

Most business rules management systems come with a central rules server. When a system needs to process some rules it calls that rules server to process the rules. By this, the rules server becomes a single point of failure for the whole system landscape.

The concept of DSM is central design but with local execution, that is, to translate rules into code that is being deployed to the managed systems. Processing rules in a managed system means executing them locally. The DSM system is only needed as a design time system but not for running the rules. This concept ensures that DSM cannot become a bottleneck for your system landscape. If the DSM system fails, or is being backed up or upgraded, no other system is affected.

We are using BRFplus with an SAP application that has not yet migrated to DSM

Many SAP applications use BRFplus by default. Some applications provide predefined rules, some offer templates, others only define the signature (input/output parameters). In any case, the application does not care where the rules have been built, whether this was done locally with BRFplus or centrally with DSM. In the end, the application only needs to run the code generated from the rules. In most cases you can use DSM in conjunction with applications that have been designed for BRFplus without further ado. SAP Collections Management is one example that was around long before DSM was developed. Nevertheless, the dunning rules can easily be designed using DSM. See the document Next Generation Collections Management with SAP Decision Service Management (https://scn.sap.com/docs/DOC-51478) on the DSM page in SCN (http://scn.sap.com/docs/DOC-29158) for details.

By the way, when switching from BRFplus to DSM, no migration is needed. All decision services, business rules, and objects can be used as they are. The only thing you need to take care of is importing the formerly local rules from the managed system into the DSM system. DSM comes with an import feature that does the job. When a decision service still exists locally in a managed system and you deploy a later version of this decision service into that managed system, the deployed rules will automatically take precedence over the local ones.

Summary

BRFplus is a great rules engine, well proven in the SAP customer base, as well as with many, many SAP applications. Its biggest asset is the fact that it is part of the ABAP stack, which does not hold true for any other rule engine.

Nevertheless there are some shortcomings with BRFplus that are addressed by DSM, making DSM an outstanding decision service management system, tightly integrated into the ABAP stack, permitting a central design time system from which decision services can be deployed throughout the whole system landscape to be executed locally.

All in all usage based license fees for DSM are easily refunded by savings in the project and by challenges that turn into opportunities.

Moving from BRFplus to DSM does not require migration or reengineering. Existing business rules and decision services can be used as they are. DSM can also be used with applications that were designed for BRFplus.

SCN (http://scn.sap.com/docs/DOC-29158) is the single source of truth on DSM.