Business Rules – December 2012

Celebrating the 10th Anniversary of the Business Rules Manifesto1
First, be clear that rules and processes are not the same. The point seems obvious, but it’s surprising how much difficulty many IT professionals have perceiving the difference. Indeed, if you’ve come up coding procedural programs or specifying use cases, seeing that rules are something different than procedural statements can be quite challenging, at least at first. So the Manifesto makes the point explicitly … 
2.2 Rules are not process and not procedure.  They should not be contained in either of these.
The result of separating rules and processes is rule independence, a pervasive idea across the Manifesto’s ten Articles. Its implications are far-reaching. For one thing, rule independence permits re-use of individual rules across all the processes and procedures of a business solution. 
Although IT professionals readily ‘get’ the importance of ‘re-use’, it’s probably not exactly the right term, however, to use for rules. If you were playing a game of chess or football, you wouldn’t say, “We re-use individual rules any time we can.” People don’t naturally talk like that. Instead, you’d probably say something like, “We apply individual rules wherever relevant.” In talking with business people and subject matter experts, we should be careful about wrapping what we say around implicit IT thinking.
Rule independence also provides a new, high-power lever for rule quality, something difficult to achieve when rules are embedded in processes or procedures. Just as for the rulebook of a game, rules for the business need to be cohesive – that is, not conflicting, misleading or incomplete. You also need to apply the rules consistently, so your processes get consistent results in like circumstances. The Manifesto summarizes these important points as follows … 
2.3 Rules apply across processes and procedures.  There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.
Think of business rules as expressing business practices. These practices can cover a wide range of business concerns, including the composition of products, the customization of services for individual customers, operational hand-offs with suppliers, implementation of regulatory constraints, and so forth.
Historically, rules have been embedded (hard-coded) in processes, in many different places and often inconsistently. There is no easy traceability for any given rule. Changing rules inevitably requires IT intervention, along with the associated cost and delay. From a business perspective, the resulting business support is simply not agile.
Business rules support business agility by providing pinpoint means to evaluate and modify business practices. Rules are expressed and managed independently of processes (a.k.a. rule independence). By that means they can be consolidated (single-sourced) and evolved more rapidly and reliability. From a platform point of view, the Manifesto says it this way …
6.1. A business rules application is intentionally built to accommodate continuous change in business rules.  The platform on which the application runs should support such continuous change.
Clearly some platforms are far better than others in this regard. The quality of their support for rules should be a critical factor in selection and design.
Unfortunately, many organizations are trapped as much by legacy platforms as by legacy systems. True business agility requires migration to new platforms as quickly and easily as possible. For example, a central concern of many organizations these days is mobile computing and social media – capabilities not even on the horizon ten years ago when the Manifesto was written. There’s no end to platform innovation in sight – and companies will always want to get on-board faster and faster. Is there any way of doing so without knowing your business rules? No! So the Manifesto recommends …
10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.
Always remember that business rules are what you need to run your business, not to design systems, at least directly. There will never be a future platform for which you do not need to know your business rules.

Follow Ron on Twitter – Ronald_G_Ross – and on his blog:
End Note: 
  1. The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Share this post

Ronald Ross

Ronald Ross

Ronald G. Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994. With BRS’s client roster of Fortune 500 companies and governments, Ron consults,speaks and teaches worldwide. He has served as the chair of the International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference. Ron is also the author of 10 professional books, as well as the executive editor of the Business Rules Journal. Through these publications, as well as on the online forum BRCommunity and his blog, Ron enjoys sharing his knowledge and experience in consulting and business rules. Outside of work, Ron enjoys walking his dogs, travelling with his three children, and tweeting. For fresh nuggets of information, follow him @Ronald_G_Ross!

scroll to top