My Story: To Play the Game You Need Rules

I grew up in Texas in the 1950s and early 1960s. If you were male and Texan and healthy back then, you played football (American style, with the oblong pigskin). That’s simply what Texans did.

Actually, I loved the game, all rough and tumble. On defense I played back, which meant I ended up on top of piles more often than on the bottom. That was cool.

What I also loved about the game was drawing up the plays (think procedures) for the offense to run. I did it for fun. (Once I had the team actually run a play I had drawn up … and the coach promptly pulled me out of the game. I learned early on that creativity can have its price.) It eventually turned out that I was a lot better at drawing up the plays than actually running them, so my football career was short-lived. Fortunately, my analysis career has worked out a little better.

One of the plays we used to run was called “18 rollout option right”. This was before they had nifty names for plays like they do now, things like “split dog double eagle twist”. (I just made that up, but you get the idea.) Anyway, I can guarantee you there is no team around today that runs a play called “18 rollout option right” or that even diagrams the same. But consider this: You could take a scoreboard from a stadium 50 years ago and use it to run a game of football even today. Now I find that very interesting.

Let me explain a bit more. The thing about American football is that in terms of how it’s played – those procedures you draw up – the game actually evolves rather quickly, quite fast at the professional level. The offences adjust to certain defensive alignments to try to exploit them; then the defenses detect the new offensive tendencies and align themselves differently to thwart them; and so on, round and round endlessly. Where the casual observer sees just a manic clash of armored titans, hard-core multi-year fans see evolution in action. It’s a big part of what makes the game compelling (and keeps the advertising money flowing in).

Now what does that have to do with business analysis and software design?

From 1977 to 1998 I was editor of the Data Base Newsletter. In those days, especially the early years, there was no such thing as analysts who specialized in the software industry. I did some pretty hefty interviews with the pioneers of the database field (including Charles Bachman, E. F. Codd, Chris Date, Michael Stonebraker and others on the theory and engineering side, and John Cullinane, John Maguire, Tom Nies and many others on the business side). These days it’s hard to imagine a world without an independent software industry, from Microsoft on down. But the emerging vendors of independent database management systems (think not sold by hardware manufacturers, IBM in particular) created the original independent software market in the second half of the 1970s.

I also followed database design and software engineering methodologies, and played a part in that, writing one of the first books on data modeling in the mid 1980s. Those days, the methodology wars were a big deal – it was the heyday of gurus and subsequently of computer-assisted software engineering (CASE) tools. There was huge excitement among IT professionals – now you could have your very own workstation for designing software specifications. Expectations soared. Just imagine, soon just push a button and generate running code, potentially improving the productivity of software developers by orders of magnitude.

But I knew it wasn’t going to happen. And I said so, which I guess didn’t make me very popular with certain people. The herd might be about to stampede off a cliff, but it really doesn’t want to hear about it – it’s too caught up in the feeling of just getting somewhere really, really fast.

To oversimplify a bit (but not too much) the problem was this. On the one hand you had process models, and on the other hand you had data models. Each had its own origin and its own logic and they just didn’t sync up. The gap was huge (and for the most part unfortunately still is). Something was missing in the middle, and that something was a very BIG something. I spent a lot of time in the mid-1980’s thinking about this. One day it hit me.

Back then, I used to go to football games at my alma matter, Rice University. Being a nerdy school, in Texas, 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 actually changed my professional life.

By the end of the first quarter of that game, the other team had already trotted out its second stringers (a real insult in Texas terms). It was hopeless. As I got more and more frustrated and bored, my mind sought a less painful, more abstract state (and they didn’t sell beer in the stadium), so I started thinking about fundamental design issues. Call it game-day cognitive dissonance. 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 left the stadium with head pulsing and heart pounding. I sensed 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? (Yes, the accelerating rate of change was already a recognized issue by the 1980s.) 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 rule books. 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 (figuratively). 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. (By the way that’s in essence why the design of the scoreboard is so stable).

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, just have a separate rulebook!

So for more than twenty years now, I’ve been going around asking companies where are your rulebooks? What are you doing to single-source your rules?

Single-sourcing rules means changing cultures and realigning ownership. A lot of business people are starting to really get that these days. As you look at the larger issues of business agility, regulatory compliance, knowledge retention, personalization, etc., etc., the logic is simply compelling. These are things I talk about all the time in my talks with business people and in conferences and seminars.

In some companies, IT professionals prove a harder sell, even though there too the logic is compelling. Some days I wish I could simply invite everyone to go along with me to one of those really bad (beerless) football games. That’s what did it for me!

Postscript: Especially for my colleagues in Europe and the rest of the world who read this, I have one thing to add. Here’s my explanation of why soccer (the game with the round ball, shin guards and two nets) is such a beautiful game, and so revered the world over (even in Texas these days!). Fewest number of rules of any team sport. I didn’t make that up, check it out for yourself! There’s a lesson there: More rules is generally not better. But that’s a different story for a different day.