BRE vs. BPM
The debate between BPM/Workflow engines and business rules engines (BRE) needs to STOP!!! Although there technically "CAN" be some overlap in an implementation, there "SHOULD NOT" be or customers may suffer refactoring and conversion when they finally define where lines are drawn. Oh yes, and let's not forget the analytics nightmare that can evolve out of this mistake.
Here's the answer...its really simple...okay...ready...everyone listening?
BPM tools are made for process automation, workflow and routing.
BRE's are made for decision management, can use inferencing, and are context sensitive.
Any attempt to select one to do the other is unwise. Period.
There are use cases where the two may be implemented in a complimentary fashion, but I will save that for a future posting.
I welcome comments on this or any post.
posted by JT at 3:19 PM
4 Comments:
Hi James,
thanks for allowing 'anonymous' comments.
Your post is right. A hammer isn't a screwdriver.
Have a nice week-end !
John
The real database isn't really about BRE vs BPM but where business logic should reside. ESBs sometimes have a different answer than BPM.
This doesn't necessarily get cleared up until several folks in the community take the initiative an draw out a publicly available reference architecture showing how these two approaches should interact with each other...
Hi JM,
Thanks for commenting ;-)
Let me begin with a notion that business logic makes its way into all our systems--unless we are building a new calculator. I have read/heard that more than one ESB (notta' product without design patterns for integration mind you)--can persist business logic. Okay. Choose you fate. I like the concept you allude to in your 2nd paragraph. Concerned the vendors won't play well to make this happen...until the big three jump into both spaces. Which my sources tell me they are in watch and wait mode on. I would offer that we have no such thing as an uber-business logic library that would be built interoperable for all systems and perform sub-sec...hmmm...wait...maybe should patent that idea. It is up to architects and developer/ implementors to team up and detemermine the best place to hold a logical aggregate of said business logic. That's all told..."design for change". See it in a blog soon.
Cheers!
Maybe you should on your next blog entry suggest how all of this can be governed?
I am of the belief that folks need a mental model and publicly available reference architectures to keep it all straight.
Not really interested in stirring up additional debate, merely in asking questions hoping additional insights shall emerge...
Post a Comment
<< Home