Consider the rule:  A log-in must be cancelled if the user enters the wrong password more than 5 times.  Business rule?

Some IT professionals argue that attempting to separate business concerns from IT concerns is unnatural and wasteful.  Worse, they say, it fuels the misconception that there is a business solution independent of the automation solution.  Attempts to separate the two are just an excuse for an incomplete business specification.

I respectfully disagree (strongly!).  With respect to rules in particular, I believe the criteria for distinguishing business rules from system or IT rules are straightforward.  I also believe that it is crucial to do so.  The criteria I use for that purpose are the following.  All three must be true before a rule is a legitimate business rule.

1. The rule must be actionable.  I've talked about this criteria in previous columns.  Briefly, it asks the question, "Do I know what to do or not to do when I read it?"  Consider the statement "no shirt, no service."  It probably qualifies.  Consider the statement "safety always come first."  That's probably not actionable.  (I can't read it and know exactly what to do or not to do.)  It must be interpreted into something that is actionable (e.g., a hard hat must be worn in a construction site).


2. The rule must be about the business, not about either (a) a knowledge/data-recording system that supports the business, or (b) a platform used to implement such a system.


3. The rule must be expressed in the language of the business, not in the language of either (a) or (b) above.

Now let's go back to the rule:  A log-in must be cancelled if the user enters the wrong password more than 5 times.  This rule satisfies criteria 1 and 3, but not 2.  Not a business rule.

How about this example:  No credit card, no order.  This rule does satisfy all three criteria.  So yes, business rule.

What happens if the latter rule is transformed into something implementable, say under a rules engine.  The statement "No credit card, no order" itself remains a business rule.  Its counterpart "If [condition], then [action]" is also a rule, but in a different form.  The business person might not even recognize it any more.  To be a business rule, a business person must be able to recognize it as such in the given form of expression.

What then is the "If [condition], then [action]" statement?  It's been transformed from the original, so it's no longer what we started with.  Now it's a "business-rule-reinterpreted-for-implementation" -- for short, a system or platform rule.  By the way, system rules and platform rules need not always arise from business rules; they can also arise independently in the context and specific contours of a given design or platform.

Does this clear distinction between business rules and system or platform rules ever break down?  One commonly cited example where the line blurs is with security rules.  However, such rules often pertain directly to a system or the data in it.  Consider this example:  A person logged on to the system as a junior adjudicator may request customer data from the customer database only from the local server.  This rule satisfies criteria 1 above -- it's actionable -- but not 2 and maybe not 3.  So not a business rule.  Does that mean the rule becomes any less important to the business?  Of course not.  We are simply being precise about the origin and class of the rule.

A rule of thumb is this:  If you threw away the system -- any system, even pencil and paper -- would the rule still be important in running the business?  Clearly the rule above fails the test.  Consider another example:  A junior adjudicator may be informed only about customers in his local district.  Throw out all the systems, you would still need that rule.  Yes, so business rule.

To reiterate, the distinction between business rules and system or platform rules is both clear-cut and crucial.  Business people want to manage business things, not system things.

Is it really, really always possible to separate rules into these categories?  Another commonly cited example where the line blurs is if your business is software systems; in other words, you are literally in a platform software business not specific to any business application.  In this special case your business vocabulary is indeed technical software vocabulary.  If that's your business vocabulary, then that's your business vocabulary.

But how many of us are actually in that business?  (Aside:  I raise the question partly because that's the business a lot of software-engineering gurus are actually in.  I respectfully submit their view of the world might be a bit skewed because of it.)  In any event, to solve your business problem you must still create a system design, and then implement it on some platform(s).  That will produce system and platform rules, there's just no getting around it.

# # #