I can’t blog this session live as John Rymer and Mike Gualtieri have asked me to participate. What follows is a combination of thoughts based on the presentation and post-presentation notes.
The theme of the presentation is that “The next frontier in business process management (BPM) and business rules is automating decisions within business processes”. If you read the blog regularly or you read the book then you will know that I wholeheartedly agree with this (hence my participation). Automating decisions to Forrester is very much what Neil and I call Enterprise Decision Management or EDM. Examples include deciding what to sell, what price to offer, how much credit to grant, what advice to give call center representatives. These decisions typically have a process context – some process is executing and needs a decision taken to continue.
John and Mike discuss three paths to decision automation:
- Use a business rules platform or business rules management system
- Use the rules capability within a business process management system
- Call a defined service developed using traditional code
Obviously I think that a BRMS is the right approach for decisions though BPMS products need rules too as they make defining processes way easier. You can also call a service built with a business rules management system.
They make the point that decision automation and management is the key justification for a business rules management system and they are absolutely right. While there are lots of things you can do with business rules and thus with a business rules management system, the automation and effective management/evolution of decisions is the one that “pays the bills”. It is also true that none of the BPMS vendors, with the honorable exception of Pegasystems, has any depth in rules support (SAP has now acquired YASU but it is not clear how they plan to integrate it so Pegasystems is the only BPMS vendor with real BRMS features).
The deployment of business rules as Decision Services (wiki) is critical as it allows SOA and business rules to complement each other and I like the way John and Mike talk about this. As an aside, Oracle and FileNet (IBM) do have the concept of a Decision Service to allow easy integration. I would point out that Decision Services can be integrated into non-process centric applications, mashups and much more too, not just processes. This is one of the advantages of them.
Like John and Mike I see the use of code and code generation as sub-optimal ways to manage rules – after all, part of the value of using rules is to allow business users to manage those rules and that means they have to be able to test and debug them and code (generated or not) just does not let business users do this.
One of the nice things about decision services is that they allow for data and insight to be brought to bear on automated processes. As John and Mike note, many decisions require analytics as well as rules and embedding the analytics into a decision service works really well while also avoiding the need to have a person look at a report or a dashboard before making a decision.
The separation of decisions is, in many ways, the last step in decomposing the old monolithic application. Here’s a picture we used in the book to show this:
Like John and Mike I think this is going to require new roles, new work arrangements and ever increasing collaboration between the business and IT. In fact the degree to which a rules platform supports this collaboration should be a critical consideration – check out this wiki entry on business user rule management.
Mike and John presented a number of possible reasons for making these investments – consistency, correctness, speed, scalability, changeability and auditability – and I like the list they use. I also like the Decision Yield idea – considering Precision (correctness), Consistency, Agility (changeability), Speed and Cost (scalability). Regardless I would point out that many investments are because of a need to balance these things – compliance with agility, accuracy with speed – not just to deliver one of them.
While the complexity of decision and frequency of change are critical drivers for using business rules, I like the reasons we gave in the book. Use a business rules management system when:
- you have lots of rules
- you have rules that change all the time
- you have complex rules or rules that interact in complex ways
- you have rules that require domain expertise to understand and edit
- you have business users who want or need to manage the rules
Like Mike and John I believe you should start thinking about this now but I would add a couple of things:
- Think about how to bring information management and business process professionals together around decision automation
- Understand data mining, predictive analytics and the related tools and techniques
- Learn about adaptive control or A/B testing as it is really important for decisions
- Last, but most important, become more decision-centric in your thinking.
Oh, and buy the book and come to the EDM Summit of course
