I spoke briefly last week at the Forrester Technology Leadership Forum about BPM, BI and BR, and had a great response from a couple of the business rules vendors who were in attendance. I’ll be expanding on that topic in a few weeks at the Business Rules Forum in Orlando, where the conference focus this year is on enterprise decisioning, especially as it relates to BPM and BI. I’ll be talking about how BPM, BR and BI can be combined to make a process improvement platform that?s greater than the sum of its parts, by:
- Separating the business rules from the business processes to provide greater agility. This allows rules to be modified independently of processes.
- Adding business intelligence to business processes to provide greater visibility. This exposes process statistics to business stakeholders.
Organizations are embracing business process management to improve their business processes. However, automation of processes isn?t the whole picture: processes must be both agile and transparent to reap the full benefits of BPM, which makes business rules and enterprise decisioning important topics for BPM practitioners.
The Forum Conference has offered a 10% registration discount code to readers of my blog: enter the promotional code 7PGRSP on your registration for 10% off your conference fees. I don’t get a referral fee, this is just a favour to you as my readers.
You can get the full schedule and abstracts (and printable registration) here, and register for the conference here.
I’ll be around for most of the conference, so be sure to look me up if you’re there.
Sandy,
Firstly, thanks for the incredibly interesting and valuable material you post in Column 2 … just love it!
I attended the conference in Brisbane and sat in on Michael’s presentation on BPM Standards (see separate post) … it was very good. I particularly liked the slides in Module 2 that show the evolution of system architecture.
This and some other things covered during the conference made me realise that underlying software functionality isn’t going to disappear, even when a BPM layer is fully implemented. Put another way, you can’t build an entire system using a BPM Suite … BPM needs services to do the ‘leg work’ and for at least the foreseeable future, those services will usually be embedded in a ‘legacy’ application.
As an aside, its interesting to contemplate a pure underlying ‘services architecture’, one built from the ground-up without any pre-existing applications to deal with. How would those service code elements and related data stores be organised? This is a very different challenge to conventional software application design and development.
But finally to my main point … in most cases, complex Business Rules already reside in underlying services functionality – either legacy systems or new services functionality. Perhaps this is where a Business Rules tool should be deployed rather than in a BPM Suite. Defining Business Rules both during process design and also within services layer will be very confusing and likely lead to errors and redundancy.
Just a thought … 🙂
Warwick, thanks for your comments, and I wish that I could have been in Brisbane (they invited me, but I would have had to pitch up the travel expenses 🙁 ).
Agreed that business rules often reside in the underlying services, particularly in legacy systems, but the point is that they likely shouldn’t because they’re not easily changeable and manageable there, nor can they be shared amongst systems that might wish to employ the same rules. In spite of the comments that Jesper of BEA made on his blog about my promotion of the separation of BPM and BR, I agree that they should be separate components, where BPM can call BR as required, but BR shouldn’t be embedded in BPM.