Skip to Content

Vijay Vijayasankar 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.
To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Vijay Vijayasankar
    James, thanks for taking time to respond. I greatly appreciate this. Also, it was great meeting you at teched process slam in Phoenix. I was in the rules team with you.

    Let me request you to expand on point 2 above, lets say we have a rule that affects customers and products. If customer = C1 and product = P1, discount = 10%. If customer = C2 and product = P2, discount = 20%.
    and so on.

    here, C1,C2 ..and P1 P2 etc sit on ERP. Rule sits outside ERP. When you have several customers and products, you cannot write if..then..else for each of them. Rather, we would look up in a table. Where does the table sit? If table sits outside ERP, then there should be a mechanism to make sure that keys of this table have valid cutomers and products that exist in ERP. That is what I refered to as keeping them in sync. There is no update of data with the rules – just that the data that rule references, should be updated and kept in sync with ERP. This is not easy as volume increases.

    Again, thanks for taking time to explain.

    (0) 
  2. Lee Chisholm
    “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.”

    Hi James,
    Does this make sense with BRFplus?  One of the big features of BRFplus is connecting actions directly to the outcome of rules.  IE: Data updates in forms, emails, workflow etc.

    It sounds like from your above comment though that actions such as this should be implemented independent of the rules though.

    Would you suggest that we not use the actions portion of BRFplus’s offering, or just hope that SAP let’s us call rules with a way of voluntarily invoking the corresponding actions (haven’t heard of this type of functionality yet).

    Thanks,
    Lee

    (0) 

Leave a Reply