I do not recall standing in a panel at a conference and not getting “The Question”…
What do you think about Rules Standard?
Good question… Although my answer always remains the same: “Standards are incredibly useful and powerful but only when they address a real need from the user community”.
There have been zillions of standard initiatives in the world for all kinds of technologies but only those that were indeed solving a real problem became real standards. There are typically two main ways to get to that point:
- Standard Body Route: a Standard body such as OMG (Object Management Group) or W3C (World Wide Web Consortium) or an Industry Standard body such as ACORD (Insurance) unites vendors and users to brainstorm on needed standard representations
- Vendor Route: either a major technology becomes de-facto standard due to overwhelming adoption or a group of leading vendors get together to agree on a common representation
My strong conviction is that having a Standard for the sake of having a Standard never succeeds. We need to focus on the objectives.
A little History…
Has anyone tried to come up with a Business Rules Standard? If you have been hanging with the Business Rules crowd, you know that many attempts have taken place over time… Let me tell you about a few of them…
A long time ago, over a decade ago, while J2EE was emerging and the JSRs were still furiously active, a group of companies dedicated time to work on a standard interface for rules engines. It was called JSR94. The idea was that you could bind different engines with no source code changes. The same code could target vendor A’s libraries or vendor B’s with a simple change in configuration and compilation.
That effort successfully closed. A standard was born. This JSR94 checkbox appeared on countless Requests for Proposals (RFPs) from that day on and I think it still shows as being a selection criteria here and there. The reality though is that very few companies use it. Why?
- Because it limits what you get out of the vendor… The major vendors have designed and promoted server-side architectures that wrap the rules engine in order to deliver more sophisticated services (transaction-safe on-the-fly rules upgrades, jukebox-style dynamic rules loading…). Selecting the JSR94 APIs is a deliberate choice to give up both flexibility and performance optimizations that are typically sought after by architects!
- Because it does not serve a realistic purpose… Why would you switch vendor when your rules are all implemented in a proprietary format? Changing that invocation source code was 2 lines of code anyway, granted with a few imports to adjust… Changing the rules… That’s a huge investment…
Service Oriented Architecture (SOA) may very well be doing a much better job at solving that integration issue at the rules service level rather than rules engine. A web service is a web service is a web service… As long as the contract exposed by the new web service is consistent with the original web service contract, it should be super easy to mash up one service instead of the other. From that standpoint, JSR94 does not make much sense to me nowadays… With Cloud Computing, this is pretty much history…
If converting the rules appears to be the major piece of work, it seems logical that most Standard efforts revolved around a universal representation for those business rules.
The major issue we face here is the scope of the language. Rules syntax varies from vendor to vendor. If that was not enough, the semantic varies as well. Some vendors offer lots of expressivity, others are more constrained… Natural Language does not fit easily in this vision of a universal language.
RuleML was an early attempt to define a rules language that could be used by any vendor. It got close as far as getting the publicity, but the focus on the “minimum set” made it very impractical. Working for one of the major vendors at the time, we took a serious look at that initiative but it fell short: most if not all real-life implementations leveraged constructs that were not supported by RuleML.
It was a crazy time back then… So you may be able to find a few “Standards” that made their way into RFPs as such but were in fact the proprietary syntax of a single vendor… Sneaky strategy…
Colleen McClintock, from ILOG, reached out to me a couple of times to “make a standard”. Granted, if we had been able to agree on one, we could have swayed the whole industry… At the time, our combined marketshare was around 70% of the overall market. Those two efforts never made it because we could not get any end-users to be vocal about the need, so the investment never made it.
More recently, OMG and W3C launched a few initiatives. the OMG efforts turned into 2 distinct initiatives: SBVR and PRR. The former focuses on the modeling-time representation and the later on the executable business rules. PRR eventually merged with the W3C RIF effort, more focused on the interchange aspect. Those efforts though really lack the voice of the customers. They are driven primarily by academics that care about artificial intelligence. When sitting on those working groups, I was shocked that the simple notion of a rule entity did not make it… How could it be a rules standard?
I am not advocating that those people are not capable… I worry, again with my Product Manager hat on, that this group may be too esoteric on the definitions and not down-to-Earth enough… Without end-users to remind the group what the end-goal is — an interchange format for projects like “mine” –, we may end up yet again with a standard for the sake of having a standard, something that could collect dust on the shelf.
For what purpose?
This may be the Product Manager voice constantly whispering in my ear, but the truth is that I cannot conceive that design happens by chance. If you know the WHAT, then the HOW will become much easier to figure out.
In the case of Business Rules (BRMS), I see a couple of reasons why we may want one Standard…
First there is the “vendor lock in” argument… When selecting a technology vendor, you invest in licenses of course but you also turn your internal business knowledge into a format that is proprietary. Having an interchange format helps reduce the switching cost from vendor to vendor.
Please keep in mind here that there are two parts here:
- Seamless Integration: keep in mind the JSR94 and SOA stories…
- Rules language: This is where we do not yet have a good solution…
And again, what is your use case? Do you worry about upgrading from an entry-level or open-source engine to a full blown BRMS? Or do you want the flexibility to swap you Ferrari for a Rolls Royce (or vice versa)?
The other argument I hear from time to time is to decouple the execution side from the authoring side. My analogy here would be SQL… Although you might be using Oracle or DB2 for execution, you may want to author your SQL code with a cool UI from any vendor. Do not take the analogy too far… I realize of course that SQL is a fantastic solution for the vendor lock-in problem as well. Yes it has a few specificities from vendor to vendor, but it is very portable.
The Interchange format solution would add a layer of transformation between the Business Rules producer and the Business Rules consumer… Similar to the Predictive Model Markup Language (PMML) solutions that exist today… It intuitively sounds like a standard storage representation would allow enterprises to capture their rules in their favorite tool and deploy it seamlessly to any execution engine, skipping the transformation stage, enabling the true universal business rules repository. There is merit in that story, at least for management purposes (maintaining one source of truth, ensuring simultaneous deployment across systems, etc.).
How do we succeed?
With passion and determination! Well, the key here is that passion and determination needs to be shared. We are missing that level of engagement from the practitioners, from the true end-users.
I made an open call to end users when asked that very question at shows like Business Rules Forum or October Rules Fest. As far as I know, no end user joined the effort at OMG… Please chime in if you learn about anyone that did!
I met some people at BPM Summit that were interested in extending the Standard work that was done on BPEL and BPMN to cover Business Rules, so that may be a direction for a Business Rules Standard.
Since some of you seem to be very interested in Standards, I will beg you again to be vocal. You are welcome to comment here of course but we have also set up a thread onto our brand-new community to discuss this very topic. Feel free to join and express your opinion on whether you think we need one or we don’t… This is an open community dedicated to practitioners but also open to vendors (as long as you do not pitch your products blatantly): Sparkling Logic Community
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
