What role should business rules play in procedural languages and enterprise architecture? How do they relate to platform independence and compliance? What about knowledge retention? This column, the last 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[1]
http://www.businessrulesgroup.org/brmanifesto.htm
Reverse-engineering business rules from legacy systems accurately is virtually impossible. The full, original business intent is simply lost. Reconstruction of business logic has been tried time and time again, often aided by automated tools, but measured against time and cost, seldom achieves satisfactory results. What a waste!
The solution is simply to stop hard-coding business rules into procedural languages. Rules will change and they will be needed for new business initiatives and platforms. The opportunity costs of continuing to follow traditional practices – not to mention the ‘maintenance’ costs – is simply too great. The alternative is applying rule technology that can support rules expressed in more natural (declarative) form.
The Manifesto summarizes these points as follows …
6.2. Executing rules directly – for example in a rules engine – is a better implementation strategy than transcribing the rules into some procedural form.
With computing power so vastly improved, there is less and less reason every day to support business rules using procedural languages. Why are we still programming the evaluation of rules ourselves?! Just as a DBMS removes data management as an application concern, so too does a rule technology for the evaluation of rules.
A related issue is compliance – not just regulatory compliance, but compliance with contractual obligations, deals, agreements, licenses, warranties, and so on. If you want to delight customers, keep your commitments.
To do so you must be able to determine how your systems actually got the outcomes they did. That way, if there’s a mistake you can correct it. So the Manifesto says …
6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.
Today, demonstrating compliance is a largely hit-or-miss affair, always after the fact. Does it have to be? No! A state-of-the-art enterprise architecture is one that logs the rules used to make evaluations and decisions just as a DBMS logs all transactions. Compliance based on rules can and should be built-in.
Another related issue is knowledge retention. The classic test of whether knowledge is tacit or explicit is this: If you lose the person, do you lose the knowledge? Clearly, you want basic business know-how to be explicit, so a basic principle of the Manifesto is …
3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.
Rules capture and encode operational business know-how in a form that can be retained, managed and re-used.
What are rules really about? A well-expressed rule is based on terms and facts (or more accurately, noun concepts and verb concepts). These concepts represent the basic stuff of the business – operational-level things that are talked about, managed and processed day-in and day-out, often many, many thousands of times. Rules provide criteria that guide this operational activity in a consistent way. So the Manifesto emphasizes …
3.4. Rules are basic to what the business knows about itself – that is, to basic business knowledge.
In business, of course, knowledge is not an end in and of itself. Rather, the goal is consistent application of the knowledge – as well as its continuous improvement. Achieving these goals requires that the people who understand the knowledge – business people, subject matter experts, and business analysts – be able to work with it directly and effectively. After all, the true test of knowledge quality is not whether an application program runs, but whether you get the right (or best) results. So the Manifesto says …
9.3. Business people should have tools available to help them verify business rules against each other for consistency.
In the plainest possible terms, IT professionals simply shouldn’t be the ones to determine whether business logic ‘works’.
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