Recently, colleagues and I were talking to the chief software developer at a large client organisation about progress on a major re-engineering effort there. Our concern was whether the project team members could meet a deadline some nine months out for delivering a large-scale prototype. We'd just spent several intensive months developing a comprehensive business model, and they still had several months of system design left to complete.
This chief developer is very sharp — not one to commit to any answer lightly. For the longest while, he said nothing, lost in thought. Finally, eyeing the detailed business diagrams plastered on the walls all around, he said, "If we had already started coding, I would say we had no chance at all. But since we haven't started coding yet, I'd say the chances are pretty good."
I had to run that by several times in my mind before I caught his meaning. "If we had already started coding, I would say we had no chance at all."
I knew he thought that the application coding itself was going to be pretty tough. It would involve using a rules engine, a worldwide distribution network, graphical user interfaces and some significant middleware.
He was saying that if they had to resolve all the business issues while coding, they would never pull it off in time — or probably ever. However, since the project team was tackling the tough business issues upfront (including specifying the business rules), he thought they had a pretty good chance of completing the code by the target date.
In large measure, the business rule approach is simply about asking the right questions of the right people. There is only one way to honestly meet a deadline — and that's to solve the business problem first.
In the early days of building business systems, the business side could essentially sit back and just let them happen. The advantages of automating were so compelling that you could do virtually no wrong. Now, for all practical purposes, business and IT operate inseparably. When undertaking projects, the logical step then would be to put together seamless business/IT project teams and have them follow a business-oriented approach to developing requirements. Yet many companies are nowhere close to doing that today.
All too often, the business side still produces fuzzy, ill-focused "requirements", and the IT side continues doing "requirements" only a notch or two above programming. How can this gap between business professionals and IT professionals in developing requirements be eliminated?
The answer is relatively straightforward. The business needs an organized approach that enables business professionals to drive the development of requirements. This approach must provide a road map that shows how to ask the right kinds of questions about the right things at the right times. What's needed is a business-driven approach.
In traditional development approaches, much is usually lost in the translation of upfront requirements to the actual running system. But writing a set of clear business rules improves communications between the business side and IT, and provides a bridge between business analysis and system design. The business rule approach helps to close the requirements gap between the business side and the IT side.
So what's a business rule? From the business point of view, it's a directive intended to influence or guide behavior. Business rules are literally the encoded knowledge of your business practices. From an IT point of view, a business rule is an atomic piece of reusable business logic.
In a way, everyone knows what business rules are — they're what guide your business in running its day-to-day operations. Without business rules, you'd always have to make decisions on the fly, choosing between alternatives on a case-by-case basis. Doing things that way would be very slow.
Rules are familiar to all of us in real life. We play games by rules, we live under a legal system based on a set of rules, and we set rules for our children. Yet the idea of rules in business systems is ironically foreign to most IT professionals. Say "rules" and many IT professionals think vaguely of expert systems or artificial intelligence. There's little recognition of how central rules actually are to the basic, day-to-day operations of the business.
Not coincidentally, many business-side workers and managers have become so well indoctrinated in procedural views for developing requirements that thinking in terms of rules might seem foreign or abstract. Virtually every methodology is guilty in this regard, whether for business process re-engineering, system development or software design.
This is unfortunate for two reasons:
1. Thinking about any organised activity in terms of rules is actually very natural. For example, imagine trying to explain a game like chess, checkers, baseball or football without explaining the rules.
2. Business-side workers and managers have the knowledge it takes to create good rules.
Take a look at the sample rules that follow, and notice how every aspect of operational control in a business system can be addressed by rules:
- Restrictions: A customer must not place more than three rush orders charged to its credit account.
- Heuristics: A customer with preferred status should have its orders filled immediately.
- Computations: A customer's annual order volume must be computed as total sales closed during the company's fiscal year.
- Inference: A customer must be considered preferred if the customer places more than five orders over $1000.
- Timing: A customer must be archived if the customer doesn't place any orders for 36 consecutive months.
- Triggers: "Send advance notice" must be executed for an order when the order is shipped.
Rules build directly on terms and facts. Terms — like customer, shipment and invoice — should have a precise, unambiguous definition in the business. For example, customer might be defined as: "An organisation or individual person that has placed at least one paid order during the previous two years."
Facts are given by simple, declarative sentences that connect the terms with a verb or verb phrase, such as, "Customer places order."
A "fact model" is a set of fact statements that describe the results of a business operation (see diagram). A fact model should serve as an initial blueprint for a data model, but its primary purpose is to capture knowledge about the business in a structured form, distilled from the business-side workers and managers who possess it.
Rules essentially add the sense of the words must or must not to the terms and facts, as in, "Orders on credit over $1000 must not be accepted without a credit check."
Rules should be expressed in clear, unambiguous, well-structured business English, starting with an explicit subject. Rules should have no fluff and no missing facts. Rules can be qualified, as in "A shipment must be insured if the shipment value is greater than $500." And rules can include timing criteria, as in "A student must be enrolled in at least two courses by the close of registration."
A business is very much like a human body. The knowledge (term and fact) structure is like the skeleton; the processes are the powerful muscles; and the rules are the nervous system that controls the other two. All three are essential and interrelated. But business rules should be separate from the other two. A basic principle of this approach is that rules are independent of processes and procedures. A fringe benefit of that "rule independence" is a huge simplification in the processes.
The result is a "thin process," a long-standing goal of many IT professionals. By taking the rules out of the processes, you can produce processes that are relatively simple and can be changed as the need arises.
In the National Football League, if a play isn't working for a team, it will be gone from its playbook within a couple of games. The plays are essentially throwaways. Similarly, businesses need to view their own procedures as throwaways — cheap enough to discard and replace readily when the procedures no longer work well.
Throwaway procedures are a must for the business to be adaptable and competitive. This deceptively simple idea — made possible by the business rules approach — can revolutionise the way work is done and systems are designed.
Reprinted with permission from Principles of the Business Rule Approach, by Ronald G Ross (Addison-Wesley, 2003). Ross is co-founder and principal of Business Rule Solutions and executive editor of the website BRCommunity.com.
Rules About Business Rules
- Rules should be written and made explicit.
- Rules should be expressed in plain language.
- Rules should exist independent of procedures and workflows.
- Rules should guide or influence behavior in desired ways.
- Rules should be motivated by identifiable and important business factors.
- Rules should be accessible to authorised parties.
- Rules should be specified directly by those people who have relevant knowledge.
- Rules should be managed.
The Rule Book
How many rules does your company have? A thousand? Ten thousand? How easy is it to change any one of those rules?
Many companies today are starting to realise that they have problems with rule management. Rules need to be managed in a consistent or coherent manner.
Your company's book of rules shouldn't be paper-based but rather automated in a database or repository, where the rules can be managed and readily accessed. That way, the book of rules can play a very active role not only during the system development project, but also once the new business system becomes operational. Software tools are now available that enable direct business-side management of rules, opening unprecedented opportunities for the business.