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.

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 …