How do business rules relate to business processes? How do business rules support business agility and migration to new business platforms? What does re-use of business rules really mean? This column, the second in a series of three (here's the first), explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it? You may be surprised by what you find here!
Celebrating the 10th Anniversary of the Business Rules Manifesto
http://www.businessrulesgroup.org/brmanifesto.htm
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.
On to: Business Rules, Procedural Languages, and Enterprise Architecture: Basic Principles - Part 3
Author: Ronald G. Ross is recognized internationally as the ‘father of business rules.’ He is Co-founder and Principal of Business Rule Solutions, LLC, where he is active in consulting services, publications, the Proteus® methodology, and RuleSpeak®. Mr. Ross serves as Executive Editor of BRCommunity.com and as Chair of the Business Rules Forum Conference. He is the author of nine professional books, including his latest, Building Business Solutions: Business Analysis with Business Rules with Gladys S.W. Lam (2011, http://www.brsolutions.com/bbs), and the authoritative Business Rule Concepts, now in its third edition (2009, http://www.brsolutions.com/b_concepts.php). Mr. Ross speaks and gives popular public seminars across the globe. His blog: http://www.ronross.info/blog/ . Twitter: Ronald_G_Ross