Rolando Hernandez over at BIZRULES has a post extoling the virtues of Business Rules Engines and how we need tools that executives can use to write rules on their own without using a programmer intermediary.
What’s missing today in the business rules market is a tool that lets
business executives write their own rules. Without IT, without
programming, and maybe even without automation. Just a tool like Word
(for textual rules), Excel (for decision tables), or even Visio (for
decision trees) that simply lets me document "logical business rules".
And then press File, Save as… "billing rules model 1.0", or "audit
rules 1.0", etc. That’s what I want to be able to do.[......]
That sounds farfetched, but I think it’s only a year or two away. By
the way, this is the same thing that database people do for a living.
ERWin anyone? Create a logical database model, select your target
physical databse model technology (i.e. SQLServer, DB2, INGRES, etc.),
then press GO. This approach works for databases. It is inevitable that
this approach will one day soon work for rulebases.
That tickles me. It’s the same argument made for pseudo-natural language. It’s the argument made for SQL all those many years ago, that business users would write SQL directly. That hasn’t come to pass, though SQL, minus the stored procedures, isn’t even Turing complete. That is, there are certain things that a computer can solve that you can’t write in a set of SQL statements. BRE’s, for the most part, are Turing complete, which means that they are rather sharp tools with which you can cut yourself. Some BRE vendors do have tools to analyze a ruleset to see if there are hidden infinite loops, unintended side effects. Good luck with those.
Turing complete means that even very simple rulesets can make for complex behavior. If you don’t believe that, check out the Busy Beaver Problem. The question: of all n-state Turning machines writing blank’s and 1′s starting with a blank tape, what is the maximum number of transitions a machine can make while still halting. We know the results up to n=4. That’s it. Now a Turing machine of this type is dead simple. The complexity of your average 5 rule system is much, much higher.
Not that I think usable tools are not a worthwhile objective. At the least they aid the communication between the business users, analysts and developers. Clearer communication is always desirable. But getting rid of the progammers is not going to get rid of complexity.
There’s a reason you need abstract thinkers when developing systems for complex problems. Sometimes the wish for simpler tools is a wish for simpler problems. You can’t just wish complexity away.
Dietrich, you as always are so right (or rather, I agree with you – but I have been wrong before;)
The closest I have seen to these goals are that non IT uses could validate the logic (on paper) to some extent by looking directly at the rules, but not touch them.
I think that sort of transparent logic is achievable, but thats a world of difference from what that article claims.
Disclaimer: I work on Drools (JBoss Rules). We have plans to achive some sort of constrained non technical rule management, but like you said, a lot of these promises we have all heard before.
I do have a dream of a user friendly REPL type system for rules (well, we kind of already had that with CLIPS ! but without a GUI – unless LISP is a GUI !), but once again, its a world of difference.
If executives really believe that, then I am sure there are many powerful rule vendors willing to lighten their wallets.
I have come to the conclusion that the best way to describe the power of business rules is in their ability to enable collaboration. I came across a great Forrester Research phrase that seemed perfect:
Concurrent Business Engineeering
This was the topic of my post over at ebizQ
http://www.ebizq.net/blogs/decision_management/2006/04/concurrent_business_engineerin.php
It has to be said that this level of collaboration still requires great repository tools (used by IT to design a robust repository), visual metaphors (like Decision Tables, Decision Trees etc) and control over how business analysts and users create and modify rules so that they can work safely. It requires IT design skills in how the rules piece is integrated and it requires good testing and evaluation tools and processes.
You can empower business users to become part of the team that owns the rules that execute in your systems and that has potentially huge value but it does takes work. Business rules management systems are necessary, I think, but not sufficient.
From first hand experience, a general purpose natural language is still a programmer tool. The closest one can come to the ideal goal is to have a focus langauge for a specific domain (aka Domain specific language). Since I’ve worked on compliance systems, i’ll use that as an example.
within the world of compliance, there are common terms like aggregate, fixed income, diversification, restrictions and violations. Using domain specific language techniques, it’s quite feasible to create a langauge that fits a narrow domain. Creating the language requires close team work between a compliance expert, a rule consultant and a language designer. DSL’s are good at solving focused problems from first hand experience.
The approach that I’ve employed in the past is to create a generalized rule language framework, which makes it easy to generate domain specific rule languages. this way, the task of designing and creating a DSL is easier. It’s still far from easy, but better tools can make it easier.
peter
Peter,
I agree that DSL’s are great tools, and your point about them requiring close teamwork is spot on. When ambiguous natural language concepts start creeping into the conversation, the results can be both comical and tragic. Take the concept of “Provider” in healthcare. One party may think that the term referrs only to doctors, another that it covers doctors and any other sort of healthcare service provider (thus the term). Verbs are even more fun.
Generally, a good data model will give you a leg up on getting to a good DSL, but you have to be on guard against sloppy thinking. When the metaphor conflicts with the model, all bets are off.
Yep I agree re the collaboration.
Its unrelated to rules, but the best experience I have had in real life is with the FIT testing framework. We were pining emails around with the domain experts who were able to write the content for the tests, validate etc.
It never struck me that the domain experts craved a button to push to change their rules, what they really want is to have their changes made fast and safe, they don’t care how. Most actually don’t want to dirty their hands pressing buttons, as they are afraid it will go horribly wrong.