(Posted by guest blogger, James Taylor)
Butler Group released a really well written report on BPM last year - Business Process Management: Building End-to-end Process Solutions for the Agile Business (December 2007) and I took a look at it after being prompted by my earlier post on BPM. It is a really thorough report and highly recommended to anyone looking to develop or extend their BPM strategy. Reviewing this kinds of reports is always a challenge - I don't want to repeat things from the report too much but Butler made this much easier with a free management summary here. First, then, some quotes from the management summary (emphasis mine) with my notes as necessary.
A Business Rules Management System (BRMS) approach to development will reduce the inefficiencies that exist within current development methodologies.
In many ways the report makes the same point about the rules/requirements mismatch and the extent to which mistaking rules (which change) for requirements (that are more stable) is key to project success. I have blogged extensively on this in the Requirements section and gave a presentation recently that you can see here.
The emergence of rules as a subset of BPM is an indication of the growing maturity of the
I have never linked this idea that business rules management is a subset of business process management and I even think they make the case for it being a parallel and equally important market in the report. That said, it is true that the increasing interest in rules from BPM users and vendors is a mark that they are getting smarter about what it takes to be successful.
Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.
Absolutely. Business rules give you a declarative way to define logic that can be shared between services and processes at a more granular level than makes sense for services. Rather than defining tiny reusable packets of code, define reusable rules.
the core value of BPM remains as a solution for building links and integration bridges
between various application systems.
In contrast the core value of EDM is in automating the most effective, most profitable action within those processes.
in the real world getting frontline facilities up and running and keeping them there with
minimum support overheads is what provides the bottomline value.
It can also be expected to deliver an ability to modify the execution of processes that will ultimately enhance the viability of each process solution
These two show how important maintenance, and agility, are in today's information systems and how business rules contribute. Keeping processes up and running means being able to make constant changes to them or, more precisely, to decisions and rules within them. Thus the use of business rules to manage decisions in these processes helps them stay current, viable and valuable.
The report also had a number of other great points.
- They describe BPM as the business interface to SOA and I think that's a great way to look at it. SOA is a very technical thing that makes BPM more effective BPM is a great way for business people to participate in compositing services together.
- One of the critical value propositions of both rules and process management is that of empowering the business to be part of the process of building and evolving their applications, not passive recipients. Code-free development is key to this and a combination of process definition using a BPMS and decision definition using a BRMS is very powerful in this respect, though there are some tricks to getting users involved as I have discussed before.
- They emphasize the value of single source process and rule repositories and the importance of a repository to business rules management (see this post on the difference between a business rules engine and a BRMS). This is linked to lots of discussion of the problems of standards in BPM and similar ones exist in business rule, though progress is also being made their (see this post, for instance).
- I agree that business rule management is ofen the best or even only way to add agility and user control to processes.
- They talk alot about the importance of synching BPM and SOA and I believe the proper definition and management of decision services is critical to this.
So much for the things I think they got right. I do have two areas where I will take issue with the report.
The first is that they blur the use of business rules in decision services or decision making activities and the use of rules to control process. While both are "business rules", I think the inclusion of rules in business process definition is helpful while the use of business rules to automate operational decisions is critical. The report does try and differentiate between "internal" rules not subject to much change and "external" ones that should be managed in a BRMS. I think the difference is between rules tightly tied to a process definition (such as routing or escalation rules) and those that are about business decisions. The latter will often cut across multiple processes and be completely independent of the current way we implement a process. For instance, how we decide a customer can most profitably be treated or what price something costs. Even massive process change would not affect these decisions so they should be managed alongside but separate from processes. Using business rules to manage these decisions is not optional.
The second area of concern is that the only real mention of analytics is in the discussion of Business Activity Monitoring (BAM) where there is some discussion of how to make BAM predictive. I think this follows from the lack of a focus on decisions as without a strong focus on decisions it is not clear how analytics, especially predictive analytics, can be applied. Only thinking about analytics in a BAM context is very limiting, though, so I would encourage you to think about how analytics can improve decisions automated within your processes also.
Read the report - it's a good one - but think about decisions and the automation and improvement of those decisions using business rules and analytics too. Think, in other words, about EDM. Related posts are very similar to the list earlier in the week:
- How should business rules and business process interact?
- Standardizing Decision-based Approaches
- What you need to know about Decision Services
- Business Rules, Business Decisions, Intelligent Processes, Enterprise Decision Management
- Process Management and Decision Management
- The Three Dimensions of Intelligent Business Processes
- Process transformation and decision management
- Great article on business rules and business process