Develop Agile Enterprise leveraging sustainable IT architecture using micro service, integration, SOA, business rules engine and artificial intelligence services. Jerome Boyer - Cloud integration and AI architect.
Disclaimer: All views expressed on this blog are mine only, and do not represent the views of my current and past employers and customers.

Thursday, October 30, 2008

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.

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

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.

About Me

I'm Technical Director working in the business rule management system market and I currently working on Complex Event Processing offering. During my consulting career I had deployed a lot of business applications using Rule Engine, and I'm very interested by BPM, SOA, and BRMS. I created a methodology based on Agile Manifesto to develop business application using BRMS technology. For the ones I know from the past who googled my name, yes it also the same jerome who was sailing for the French national team in my younger age.