Thursday, October 30, 2008

BRE part of the service layer

I just had a look to the presentation from Sandy Kemsley done at the business rule forum: "Mixing Rules and Process" and her blog entry on BPMS and BRMS integration. I can quickly summarize the points she made that I love and share some feedback:
  • Does BPM has Rules? yes but typically not full-features BR. Rule changes may require redeploying processes with IT involvement.
  • Separate rules from process: externalize decision from process. Call BRE from BPE.
  • Benefits from separation: compext rules automate manual process, reuse rule across processes, change rule without processes.
In her blog entry "As a BPM bigot, I see rules as just another part of the services layer... but I didn’t hear that from any of the vendors." It may be because ILOG team was not speaking... ;-)

We are pushing, saying and we are delivering projects since 4 to 5 years where we have a clear separation between decisions done by business rules from process flow, and designing solution where the business process is calling the decision service. In ABRD I even clearly propose this approach as a best practice for the reasons mentionned above:
  • different velocity of change and agility
  • reuse of decision point
  • better version control and change management support in BRMS
What we do observe in the field is that customers are at ease to design a web services or a services (SOA larger definition) that use a rule engine to implement the decision logic supported by these services, but are at pain to deploy executable processes, because not all the other parts (services) of the business process are ready. So BRMS is the first technology deployed in SOA rewampping before BPM. Green field deployment is difficult to find, and legacy application are moving slowly to be rewampped as reusable services. Not to mention the nightmare of data model management.
We are still at the lower left part of the SOA maturity adoption matrix and the Agility Chain Management.

Wednesday, October 1, 2008

JSR94 - an over visioned java standard?

Recently I had to re-do some JSR94 code and I'm still interested by this work done some years ago and I'm still supportive of it. But as Roy Johnson was saying recently during one of his presentation "Where will tomorrow's enterprise innovation come from?". Does JSR94 is one of this "unhealthy Java standard" like JDO was? Done in a period where the Java community wanted to standardize everything ?
For the recall JSR-94 is an industry standard that defines how Java programs deployed in J2SE or J2EE can acquire and interact with a rule engine. Being able to change engine implementation is a nice design approach, but as of today this specification is limited by the fact that there is still no standard to exchange rule definition between engines. So rule written for one engine can not be used by another one. This dramatic limitation is undermining the use of JSR94. And i'm still surprise to see architect asking compliance to it.

Although the horizon is still blue: W3C is working on the final specification for Rule Interchange Format which should help to exchange executable rule definitions between engines supporting this specification. With RIF, JSR94 will make sense in the design of decision service.