Alex presented a well structured case for why decision applications should include knowledge extracted from data in addition to knowledge captured from experts. Alex used a fish processing plant as the illustration for his presentation – an interesting choice.
If you have enough data relative to your problem available to you for processing, applying predictive analytics modeling enables you to extract knowlege in the form of risk scores, fitness scores, etc… that can then be leveraged by business rules. To do so, you use standard predictive model building approaches, using tools such as the free ones provided by Project R, or one of the commercial ones.
However, one of the key issues that you will face is how to deploy the models created through the predictive analytics model building. Alex referred to typical model update processes in financial services, where the frictions in the deployment process result in 6 months+ release cycles. I am very famliar with those cases – as a disclosure, Alex and I both worked at HNC a few years ago.
Alex has been very active in the efforts to solve this deployment problem, and has contributed significantly to the creation and growth of the PMML standard. PMML is an interesting effort – it has resulted in its first generations in a well supported model description tool, but suffered from the lack of support for expressing variables. That was a key barrier to adoption, and one of the key difficulties we had to work on when designing and implementing the PMML support for Blaze Advisor.
That problem has been largely (and possibly completely – I have not checked the details) in the latest version of the standard – which is not yet supported by everybody but will be.
Alex wrote a book on PMML: PMML in action. He does cover PMML 4.
Zementis, the company Alex works for, combines Drools and a PMML deployment capability, to let you create decision applications that combine rules capturing the expertise and models managing the risk and are deployed to the cloud.
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
2009 has been a rough year for the business. We had to deal the aftermath of the 2008 economic crisis and start rebuilding.
In those times, I try to keep a French proverb in mind “À quelque chose malheur est bon”. It literally means “Unhappiness is good for something”. In the US, we would rather say “Every cloud has a silver lining”. Given the emergence of Cloud technology as a consequence of the recession, it seems to be quite appropriate.
Capital vanished into thin air, confidence went down the drain as well. Most businesses had to do more with less in those circumstances. the industry focused on better managing finances to run operations. Cloud computing, Software as a Service, that technology with many names, became attractive to finance new projects or to reallocate Capital Expenditures into Operational Expenditures. Less risk, faster execution. Sounds logical.
How we got there though was in my mind a more interesting ounce of wisdom that, if well applied, could turn into real value. Nassim Taleb captured it quite well in the Black Swan. In addition to expected changes — those regulations that are announced in advanced, competitive product announcements, or predictions of the market — there are unexpected changes that need to be dealt with. They may be totally unexpected or events with a probability so low nobody is getting ready for it — the unknown unknowns. Those will never be taken out of the equation. Although we may be tempted to at times, it would only lead to incomplete, insufficient models such as those that brought us where we are.
Learning to live with those unknowns, learning to better handle uncertainty is a skill that became more appreciated in 2009 and that business will start developing more in 2010 and beyond. Our systems should help us made decisions that are not so sensitive to market conditions we believe are here to stay.
Jim Sinur at Gartner is spot on in his blog post about business agility. Agility is what we all know is required in our systems but it is not enough. New capabilities such as Decision Simulation and Decision Optimization are key.
I am predicting that 2010 will see a lot more emphasis on this topic.