« January 2006 | Main | March 2006 »

February 10, 2006

Rules 1.0

Executives used to have secretaries. Now they have Word.

Companies used to have IT/Finance modelers to do "what if" analysis. Now they have Excel.

Newspapers used to have strippers (no not that kind!) that did page layout by hand. Now they have PageMaker.

In the early days of the Web, you needed a Webmaster to create your website. Now you have FrontPage.

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.

Sure, I'd like to push a button and have that logical rule model artifact go into a business rules repository. Great. If I could push another button and have my logical rule model generate code for whatever Business Rule Engine I'd like to target, now we're talking business rules.

That is the promise of business rules. I want to create a logical rule model, select my technology (i.e. HaleyRules, ILOG, PegaRULES, Versata, Fair Isaac Blaze Advisor, CA AION, Corticon, OpenRules, etc.) and then press GO. I want the tool to transform my logical business rule model into a physical business rule model. Then I want to compile and run.

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.

Let's start by calling the BRMS (business rule management system) a RBMS (rulebase management system) instead. Then we should call the business rules repository the rulebase. Business people will find it much easier to understand rulebases if they can compare it to the familiar database analogy.

We'll still need industrial strength rulebases like the ones I mentioned above. But we'll also need a "lite" rulebase software tool for business executives. Think Word, Excel, Visio.... or Access instead of SQLServer...

What if, or when will Microsoft or some other BRE vendor releases Rules 1.0? How about Microsoft Rules 1.0.? Maybe part of Office? What if executives finally have a tool on their desktop to write the rules? A tool that understands IF and THEN and ELSE and MUST and ONLY IF and MUST NOT etc.

I think a lot of business people have been led to believe that that's what business rules will mean to them. And their expectations are that the rule tool will be as easy to use as Excel or Word. I've noticed more and more companies approving business rule projects where the business people have the expectation that the business rules tool is something they can fire up on their PC... as easily as they do Word or Excel.

Business Rule Engine software products are clearly awesome productivity tools for programmers. But only a few of them could be considered tools for executives. We need to think of the BRE as the tool for IT developers and for rule execution, and the logical rule modeling tool I described above as the rule documentation tool for business executives.

I hope there are some companies working on this idea of a logical rules modeling tool that generates code for my BRE tool of choice.

Stay tuned... What do you think? Does Microsoft Rule? Anyone else?

Differences between process (BPMS) and rules (BRMS)

Interesting post by James Taylor (Fair Isaac / Enterprise Decision Management - a Weblog) about BPMS and BRMS...

"Well at a pretty basic level I think BPMS and BRMS are fundamentally different:

BPMS is about "How should it be carried out?"

  • Standardize processes
  • Facilitate collaboration and compliance
  • Workflow Definition and Management
  • Process Automation
  • Activity Monitoring and Exception Alerts
  • Process Reports
  • Integration Broker

BRMS is about "What should be done?"

  • Standardize operational decisions
  • Facilitate decision automation and maintenance
  • Centralized Business Rules Repository
  • Straight Through Processing
  • Decision Broker "
Good stuff.

My thoughts on BPMS (process) and BRMS (rules) are that you need both. You need a process management tool to manage manual processes and execute automated processes that know HOW to "do the work". You need a rule management tool to manage and execute business rules and make decisions that "decide WHAT work to do".

So in general the rules engine (BRMS) fires rules that decide what processes to run and in what order. Some processes do have simplistic rules for branching form one process to the next. That's OK, because those rules are probably system rules as opposed to business rules anyway. More complex deep rules, of course, belong in the rule engine instead of the process engine.

Locations of visitors to this page