A first step in seeing rulebook management clearly is to understand what business rules are and are not.  Put simply, business rules are what business people would need to run the business even if there were no machines.  By "run the business" I mean guide behavior and shape operational decisions.  The business rules might be technical, but 'technical' in terms of the company's know-how or specialized product/service, not 'technical' in terms of computer-ese.  Here are two examples.

Example 1.  If ACT-BL LT 0 then set OD-Flag to 'yes'.  This is not a business rule.

Example 2.  An account must be considered overdrawn if the account balance is less than $0.  This is a business rule.

Business rules are about business communication.  A colleague of mine put the distinction succinctly:  "Business people don't set variables and they don't call functions."

Software Requirements vs. Business Rules

The second step in understanding the need for rulebook management is to be clear that software requirements and business rules are not the same thing.

To bring the distinction into perspective, consider data for a moment.  Would you consider actual business data — not the data definitions but the actual data itself — to be part of software requirements?  No!  That's because the life cycle of data and the life cycle of software requirements are simply not the same.  The life cycle of software requirements, no matter what methodology you use, more or less ends with official software release.  For data, in contrast, that's just the beginning of life.  The data persists.  More importantly it changes over time.  That's the very essence of doing business.  It's a fact so obvious we take it for granted.

The very same is true for business rules.  Official software release is just the beginning of life for business rules.  They persist.  More importantly they change, sometimes rapidly, because our business constantly needs to adjust how it does its business.

The distinction between the software development life cycle and the life cycle of business rules is sometimes hard for those in IT to grasp.  Indeed, if you look at the question through the lens of software development methods, you're almost certain to be confused.  If you look at business rules from the business point of view, however, seeing the distinction (assuming you're not wearing legacy blinders) is far easier.

Eventually all companies will appreciate the distinction I'm making.  Then the need for managing rulebooks as a separate resource (just like databases) will be obvious.  In any case, many pioneering companies today are already well along their way in doing just that.

Size Matters

Before getting too deeply into what rulebook management is about, let me address some fundamental questions about your business.  That's a good way to gain a wider perspective.  By the way, I've asked these questions of many, many audiences and clients worldwide, so I'm reasonably confident of the answers.

How many business rules does your organization have?  After a bit of reflection, the answers inevitably come into the 1000s, and frequently (and probably more accurately) into the 10,000s.  If you think your company has only dozens or 100s of business rules, you don't need to read any further.  You can stop right here.  With due respect, I'm almost certain you're wrong, but you need not go on.  The problem I'm talking about is one of scale, and either you don't have the problem or (more likely) you're just not seeing it.

Do you know where your business rules are today?  Almost everyone says no to this question or, given a little more time to ponder it, they say their business rules are actually everywhere (i.e., not single-sourced).  The rules are in legacy code, in documentation, in help screens, in procedure manuals, in agreements, just in people's heads (that's scary) — everywhere in general and nowhere in particular.  How can you effectively make changes in a business like that?!

What percentage of your business rules change relatively fast?  The good news is that not all the rules actually do.  Across many industries, I've consistently found the answer to be 30-45%.  But some of those business rules change really fast.  And almost all of them change faster than 2 or 3 official software releases per year(!).

How long does it take you to change a business rule the first time?  The time needed for business managers and business analysts to adequately assess the business impact of changing a business rule (or a set of rules) can range anywhere from mere seconds to days or weeks.  Typically the answer is hours or days.  If only assessing business impact were all there was to it!  Remember that your business rules today are everywhere in general and nowhere in particular (not single-sourced).  So that means first you have to track down the existing rule(s), which can often take weeks or sometimes months.  For any given rule, there are probably multiple versions currently 'out there', some likely to be buried deep in legacy code.  That means taking time to reverse-engineer the rules and trying to discern their original intent.  Once you've done that then you must reconcile the multiple versions.  All that work has to be done before you can even begin to assess business impact.  So we're paying a huge price in lowered productivity (and higher drudgery) all the time, day in and day out.  It's so big a price that many organizations don't even see they're paying it.  (But service providers sure know!)

How long does it take you to change a business rule each time after the first time?  Here the news gets worse.  Once you've gone through all that work the first time, what then happens to the knowledge produced (temporarily) about where the rules are and what they mean?  It evaporates into thin air.  And what happens to the knowledge about who made the call to change the rule, and why they did it?  Ditto.  So the next time the rule changes, back you go, starting at square one on all that track-down work yet again.  And so on, each time the rule changes.  Now most business analysts dislike that kind of work.  (Service providers love it though.)  We're letting this corporate memory disappear right in front of our very eyes.  You can work harder and harder as the rate of change increases, but there's a limit.  I find many business analysts are already working pretty much as hard as they can.  So it's time to start working smarter!

Five Best Practices for Rulebook Management

That leads me to five best practices for rulebook management.

Best Practice #1.  Write your business rules in English, and organize the ones you can into decision tables.  You want guidelines to follow in that regard; that's why we've developed RuleSpeak^® (free on www.RuleSpeak.com).  You need powerful semantics to base your representations on; RuleSpeak is based on SBVR.^[1]

Best Practice #2.  Base your representations on structured business vocabularies — nouns and verbs^[2] — rather than on IT artifacts such as business object models (BOMs), class diagrams, or data models.  Remember what I said earlier about the distinction between business rules and software requirements.  You need business rules to run the business (whether you have software or not); the business rules live on, if and when software is released.  Business rules and software requirements are simply two different things.  The art of writing good business rules is the art of writing good sentences.  To assist in that regard your rulebook management system needs to act like a smart editor, replete with business vocabulary.

Best Practice #3.  Put your rulebook and related business vocabulary at the fingertips of business people and business analysts; don't bury them in repositories for software requirements.  I'll say again:  Business rules and software requirements are not the same thing.  How could the same tool effectively serve business people and business analysts, as well as software developers?!  To emphasize the distinction, I've introduced the term General Rulebook System (GRBS) for business-oriented rulebook management.  Think of a GRBS as more or less a general ledger system, except for business analysts.^[3]

Best Practice #4.  Provide true traceability for business rules.  Where do business rules come from, if not software requirements?  Ultimately they come from laws, regulations, contracts, agreements, business policies — all of what I call the guidance sphere of the business.  When rules change, you need to be able to trace (quickly) to their true origin.  Business traceability and software requirements traceability … well, again they're just not the same thing.

Best Practice #5.  Retain your corporate memory in a GRBS.  Today many of your business rules (and the corporate memory about them) are tacit, rather than explicit.  The classic test for when knowledge is tacit is this:  Lose the person, lose the knowledge.  Many organizations are at significant risk because their business rules and related corporate memory lies with just a few key staff — more often than not soon-to-retire babyboomers.  Many organizations simply do not appreciate their exposure in this regard.  It's another case of a problem so big, they can't see it all around them.

Is there any alternative to the solution I've discussed?  I don't see one.  We live in a fast-changing, highly-regulated, knowledge-intensive world.  It's rapidly becoming more and more so.  Doing the work of business analysis the same way we've always done software development in the past just isn't going to work.  Business rules need to be managed directly as a business proposition — of, by, and for business people and business analysts.

Once you see the big picture, things become clear.  You realize the problem is actually a relatively simple one.  The same is true for its solution, a GRBS.  It's only the scale of the problem making it hard.

That brings me to one last best practice:  Don't start with rulebook management at the enterprise level.  You don't have to.  In fact, you shouldn't — that's a recipe for failure on any kind of new initiative.  Start with one project or one business process or one operational business decision at a time.  Show success.  Get the feel of it.  Show what can be done.  Then go from there.  The initial results might not be perfect (i.e., completely re-usable on an enterprise scale), but simple credibility will ultimately count much more.

References

[1]  Semantics of Business Vocabulary and Business Rules, a standard released (1.0) by OMG in late 2007.  For more about the importance of SBVR, see SBVR Insider on www.BRCommunity.com

[2]  Or terms and facts, organized into a verbal model called a fact model.  See Business Rule Concepts, 3^rd Ed., 2009 — http://www.brsolutions.com/b_concepts.php

[3]  For a best-of-breed example of a GRBS, see RuleXpress — www.RuleArts.com/RuleXpress

# # #