vijay.vijayasankar/blog had an interesting post BPM/BRM on an empty stomach in which he raised some valid concerns/asked some interesting questions about business rules. I thought I would do my best to answer them:
1. Business rules reside outside the transaction processing systems in this model. So what happens if that system is not up and running when a transaction gets processed? Sure we can have high availability around such systems too - but is the cost justified?
The simple answer is that the same thing that happens when the database is not working. If you use rules in your architecture, and I believe you should, then the rules environment must be given the same focus that all the other elements get. From a systems perspective, don't forget BRFplus - rules and ABAP which allows you to manage rules and execute them in ABAP. This is not as well integrated with the Netweaver BRM as I would like to see but the folks running the two groups know this needs to change and I am confident it will.
2.Rules act on master data and master data sits in ERP. How do we keep this in sync between the two systems? and again, is it worth the cost?
The data should stay in the ERP system and the rules should just act on it. The best way to use rules is to build decision services that get passed data, execute the rules necessary to answer a business question (is this customer eligible for this product, what is the risk of this transaction) and then retun the result WITHOUT updating the data. The calling transaction handles all the data updates. This means the rules don't have side effects and that means they can be called and reused whenever you need to. No synchornization should be necessary.
3. Some rules are very tightly coupled to the ERP transaction for a variety of reasons, like complexity, performance etc. Pricing, Output determination etc come to mind here. This would mean that some rules exist in ERP and some outside. What is the big advantage then?
See the answer to #1 - one option is to do as SAP is doing and manage ERP logic in BRFplus. Pricing should not be tied tightly to the ERP transaction as this means only the transaction can get the price - the call center, the web site, the marketing system cannot - and this is (or should be) unacceptable. Part of why you move to rules is to ensure that the logic about your critical business decisions is not locked into your ERP system. As I said above you might well end up with some rules in BRFplus for execution on ABAP and others in Netweaver BRM and this is something SAP is going to have to make work.
4. What kind of user does SAP expected to use BRM tool? I have hardly seen a business user who has told me - lets create an Enumeration type, and while we are at it - lets choose java type as java.lang.string
If you are talking about the Rules Composer they clearly expect a programmer to use it. The web-based interfaces are what is intended for a business user. You are quite right about the composer - it is way to technical for business users. Hopefully we will see a version of the Eclipse-based rules components that is less technical (as we have seen on the BPM side) and continued focus on the web-based components.
Closing thoughts:
- Focus on decisions that have lots of rules, rules that change a lot, rules that are really only understood by those with deep domain expertise or where logging exactly how a decision was made is critical. Implement these as decision services that use rules to make a decision but which do not have side effects - that don't change the data. This will make them easier to implement and easier to reuse while focusing on those areas where rules makes the most difference.
- Use BRFplus and Netweaver BRM to manage rules based on where you plan to execute them and pester SAP about tools to manage this!
- Look at each ruleset you develop and decide how to expose it to the business people who understand the rules so they can collaborate with you on the rules and so they can begin to manage some of the rules themselves.
- Don't think of Removing decisioning from the SDLC.
