Business Rules, Requirements and Business Analysis: Basic Principles - Part 1

Featured
28363 Views
2 Comments
18 Likes

How do business rules fit with requirements? What role should business rules play in business analysis? Do business rules offer something to agile projects? This column, the first in a series of three, 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

Rules are all around us in the real world – in the games we play, in the laws and regulations of society, in the limits we set for our children – everywhere. Yet for whatever reason, rules are not always featured in requirements and IT methodologies. That’s very strange if you think about it.

Business Rules, Requirements and Business Analysis: Basic Principles - Part 1So the very first point of the Manifesto aims to correct that omission, and by doing so, to bring better balance to requirements …

1.1 Rules are a first-class citizen of the requirements world.

This first point does not suggest that business rules are more important than other requirements – for example, process models – but rather, co-equal. How can you organize or model any kind of activity without knowing the rules?! That understanding leads to the second point of the Manifesto …

1.2 Rules are essential for, and a discrete part of, business models and technology models.

The “discrete part of” in this statement is crucial. It means that rules should not be embedded in other deliverables – for example, use cases – so that the rules can be written once and then applied everywhere (single-sourcing). It also means the rules can be validated directly with business people and subject matter experts. The result is better requirements – and better communication.

Another result is rule independence. The rules can now evolve independently of other architectural components, often much faster. By not hard-coding rules into application programs, much more agile business solutions can be achieved. The Manifesto makes the point 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.

Business rules are what you need to run the business. You would need them even if you had no systems. So it makes sense that business rules should be captured and expressed in a form that business people and subject matter experts can understand. That way they can ensure that the business rules are correct. If you are designing systems – and that usually is the case – there’s simply no point implementing rules that aren’t correct. So the Manifesto says

5.1 Business rules should be expressed in such a way that they can be validated for correctness by business people.

Validation and correctness, however, are not the only focus for business analysis with business rules. Another is whether each rule can be justified as being truly productive for the business. Businesses often accrue so many rules over time (include ‘exceptions’ in that!) that their spiraling complexity results in rapidly diminishing return.

So the cost-effectiveness of every business rule should be assessed, at least informally. To do so, first you must recognize there is cost associated with each rule. The Manifesto makes that point explicit …

8.2 Rules always cost the business something.

A rule’s true cost, however, might not be exactly what you think – the platform costs may be relatively insignificant. Instead, the principal cost of most rules is organizational. Rules must be documented. They must be taught to new hires. They must be explained to external parties. All these things take time – and time is money. Also note carefully: This overhead doesn’t decrease with each additional rule – it increases. The more rules, the more complexity.

The Manifesto in no way suggests that more rules is better. Just the opposite; it emphasizes that a smaller number of good rules is always better. Better to start with a smaller number, then add more as you go. The Manifesto puts it this way …

8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

It’s simply a myth that you have to know all the rules before designing and building productive business systems. Just the opposite is true. You can deploy a simpler solution initially, then add rules later on as time and insight permits. Fortunately, rule-based systems are extremely good at incremental design – the goal of many an agile project.

On to: Business Rules, Business Processes, and Business Agility: Basic Principles - Part 2

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

Footnotes:

[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. 

Like this article:
  18 members liked this article
Featured
28363 Views
2 Comments
18 Likes

COMMENTS

Travis Barker MPA GCPM posted on Thursday, November 15, 2012 3:23 PM
Thanks for the article.

It was very interesting. You make an interesting series of points that help the business analyst to understand the purpose of rules.

They influence outcomes and are an outcome of knowledge. They constraints efforts and are a product of the effort to delineate the constraining parameters.

They are both embedded in the systems they help to negotiate and constrain as well as are the constraint that is embedded in an effort to limit waste and improve quality. Rules are discrete and are limited to the construct to which they refer.

Rules, to the extent that they are value embedded facts that are normalized within the immediate context, can be evaluated and should be evaluated for accuracy and relevance. Rules are not processes or procedures, but provide the constraints in which processes and procedures are identified, evaluated, and implemented.

Rules must be congruent, consistent, and limited to only those that are essential to achieve the output identified by the rule.

Thanks again.
I enjoyed the read.

Travis Barker, MPA GCPM
TravisBarker
The Cynical BSA posted on Monday, May 13, 2013 2:28 PM
Excellent cogent presentation of the centrality of business rules!
SoCalCynic
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC