I am often asked how and when I came to the idea of business rules.  Here's my story.^[1]

Back in the mid-1980s, I used to go to football games at my alma matter, Rice University.  Being then what can only be described as a nerdy school, Rice was always terrible at football.  I would get pretty worked up over the mental errors the players made.  Eventually my wife made me stop going to the games, basically saying it was either her or football — pick!  Sort of just like in the movies.

Before that point, however, I had a real ah-ha moment.  One of those awful games was a real life-changer.

By the end of the first quarter of that game, the other team had already trotted out its second stringers.  It was hopeless.  I got more and more frustrated and bored, so I started thinking about fundamental design issues.  Since football was handy as a convenient case study, I started parsing the elements of the game.  The home team went on to lose very badly, but I scarcely noticed.  I felt I had made a huge discovery, one so obvious that in retrospect that I couldn't believe I hadn't seen it before.

The two basic questions I asked myself were:  (1) What fundamental elements are needed to play the game of football, and (2) Which of those elements are more stable?  If you could segregate the more stable elements from the less stable ones, you could probably build more agile designs.  So I proceeded to do some 'stability' analysis on the game of football.  Here's the lite version of that.

First are the fundamental concepts of the game, as represented by terms.  Second are the ways those concepts can relate ... things that can happen repeatedly at the operational level of the game.  Those are facts we can know about.  Third are the rules of the game.  Fourth are the procedures, the plays that represent the active part of the game.  The plays are what you see happening on the field when you sit in the stadium — the exciting stuff, how points are actually scored.  What you pay to see when you go to the game.

But hold on a second!  What about the rules of the game?!  Where are those rules in business and system models?  They have to be there, somewhere — but where?!  The fact of the matter is that in most business and IT architectures today, rules are everywhere in general and nowhere in particular.

But the rules not only govern the processes and procedures (you get penalized if you get caught breaking them), but also govern the consistency of the data (as referenced by terms and facts).  The missing ingredient is the business rules!  If you want to talk about developing agile software, not to mention run your business more effectively, you need to do something about rules.

Think about it for a second.  I can walk (physically or virtually) into any bookstore, and find a copy of the current rules of football.  But walk into any business and ask them for the rules by which some aspect of the business game is currently being played, and you'll likely just draw blank stares.  Business rules have simply not been treated as first-class citizens of business and IT architectures.  There are no rulebooks.  That's really peculiar.  Try to imagine any organized human activity without well-organized rules.  Now I'm not talking about artificial intelligence (AI) or expert system rules; I'm talking about structural and behavioral rules, ones inherent to running the game.

Now here's the kicker (so to speak).  These rules can change.  For example, the last two rules I listed in the lite analysis above no longer apply at the professional level.  Think about what you go through in your company today to deploy changes to the rules.  It's a hugely time-consuming, cumbersome, and error-prone affair.  It's literally anti-agile.

If you want a good sense of what business rules are about, put procedures (plays, processes, transforms, etc.) aside for a moment.  Think about the first three elements above:  terms, facts, and rules.  What do they have in common?

• Declarative, not procedural.  The terms, facts, and rules are about what you know — not about what you do.
  
  
• Shared, not private.  Stovepipes aren't going to work very well here.  You have a community of practice, and anyone who wants to be part of that community (for football that means referees, players, coaches, spectators, broadcasters, etc.) must buy in.  The alterative, literally, is anarchy.
  
  
• Structured, not ad hoc.  I don't know much about the origins of American football, but I bet the first time it was played they didn't just say hey you guys divide up sides, take this ball out there, and see what happens.  You don't prototype your way blindly to a whole new form of business activity.  It requires some shape and structure to start off with.

I'm not saying you can't break some of the rules — you can.  Rules shape behavior, but don't necessarily 'fix' it.

But two important points there.  First, the more penalties you receive, the less likely you'll be to win the game.  Second, the rules are never embedded in the diagrams of the plays.  Can you imagine how counterproductive and complicated that would be?  In business process models it happens all the time, but most practitioners don't even realize it.  I say, have a separate rulebook!

References

[1] Extracted from "My Story," www.ronross.info

# # #