Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘Business Rules Manifesto’

Are Business Rules Good for Incremental Design? You Bet!

You can find definitions and discussion of all terms in blue on Business Rules Community: http://www.brcommunity.com/BBSGlossary.pdf From Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, October, 2011, 304 pp, http://www.brsolutions.com/bbs ~~~~~~~~~~~~~ Discussion …  First a definition to make sure we’re on the same page …

incremental design:  developing a system through repeated cycles (iteratively) and in smaller portions at a time (incrementally)

Business rules are unsurpassed for step-by-step enhancement of deployed know-how in business capabilities over time (incremental design).  The Business Rules Manifesto[1] puts it this way:  “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.”  That’s exactly what you need for know-how retention and to move pragmatically toward the know-how economy Support for incremental design with business rules is quite straightforward.  For example, a decision task might start off manual (performed by humans).  As time and resources permit, decision rules for handling the simplest cases can be captured and encoded, removing these cases from the manual workload.  Perhaps you start supporting a modest 20% of all cases.  The only required changes to the system to support additional cases are to specify:

(1) What new cases are covered (by providing appropriate selection criteria). 

(2) What new outcome(s) are needed (if any) for the new cases covered. 

(3) What new (encoded) decision rules should be used for the new cases. 

At a subsequent time, you ramp up to 50% of all cases, then perhaps 80%.  You may never get to 100% – nobody is talking about taking humans completely out of the loop for every operational business decision(!).  The net result is simply applying human resources where best suited, the really hard cases.

Continue Reading

Business Rule Manifesto FAQs Added to BRCommunity.com

I am pleased to announce that a comprehensive set of authoritative FAQs about the Business Rules Manifesto has been added to BRcommunity.com: http://www.brcommunity.com/brm.php The Manifesto is celebrating its 10th anniversary this year – and remains as powerful and as vibrant to today’s business challenges as ever. I will be covering a good many of its insights in my Sunday tutorial, Business Rules: The Why and the What, at this year’s Business Rules Forum conference, part of BBC2012 (Oct. 28 – Nov. 2, Ft. Lauderdale, FL): http://www.buildingbusinesscapability.com/ The FAQs explain in-depth how the Manifesto relates to a great many pressing issues on today’s business agenda, including …
    • Requirements
    • Business Processes
    • Business Analysis
    • Business Agility
    • Enterprise Architecture
    • Zachman Framework  
    • Knowledge Retention
    • Events
    • Enforcement
The new BRCommunity Insider also provides insight into the general positioning and structure of the Manifesto, as well as point-by-point clarification of individual Principles. The Manifesto is just 2-pages and free. It has now been translated into some 15 languages: http://www.businessrulesgroup.org/brmanifesto.htm The Manifesto is a rare thing in our field – a timeless work that seems more and more prescient which each passing year.

Continue Reading

Business Rules and Enforcement: One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #10 Question: How does the Manifesto view the issue of business rule enforcement? Principle 4.6 of the Manifesto states …

Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

Why? Separation of rule specification from enforcement concerns[2] ensures that …
  • The true business intent of the rule itself can be directly validated. Enforcement concerns do not mix things up.
  • The greatest degree of business agility is achieved. Changes to enforcement specifications and changes to the rule itself can be made independently.
  • The highest degree of re-use is supported. The same rule can be subject to different enforcement specifications at different points of application.
Specifying rules independently of responsibility for enforcement is taken to mean all the following.
  • Who. If responsibility for enforcing the rule is given to some role in the organization, that role should not be mentioned in the statement of the business rule.
  • Where. If responsibility for enforcing the rule is assigned to some component of the technical architecture, that component of the technical architecture should not be mentioned in the statement of the business rule.
  • When. In general, every business rule applies to multiple events (flash points). However, those events should not be mentioned in the statement of the business rule.
  • How. If capability for enforcing the rule is laid out in some process or procedure, that process or procedure should not be mentioned in the statement of the business rule.


[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.
[2] For discussion of enforcement specifications, see Breaking the Rules: Breach Questions http://goo.gl/MFxtN

Continue Reading

Flash Points: Where Business Rules Meet Events

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #9 Question: What does principle 6.5 of the Manifesto mean?

The relationship between events and rules is generally many-to-many.

Business rules generally apply at various points in time.  Each of the various points in time when a behavioral rule needs to be evaluated represents an operational business event.    Such events can arise in either business processes or ad hoc business activity. How do you find these operational business events?  Consider the behavioral rule:  A customer must be assigned to an agent if the customer has placed an order.   Figure 1 shows the relevant terms and wordings for this business rule. Figure 1.  Terms and Wordings for the  Agent-Assignment Business Rule   The business rule has been expressed in declarative manner.  This means, in part, that it does not indicate any particular process, procedure, or other means to enforce or apply it.  It is simply a business rule – nothing more, nothing less. The business rule makes no reference to any event where it potentially could be violated or needs to be evaluated.  The business rule does not say, for example, “When a customer places an order, then ….” This observation is extremely important for the following reason.  “When a customer places an order” is not the only event when the business rule could potentially be violated and therefore needs to be evaluated. Actually, there is another event when this business rule could be violated:  “When an agent leaves our company….”  The business rule needs to be evaluated when this event occurs too since the event could pose a violation under the following circumstances:  (a) The agent is assigned to a customer, and (b) that customer has placed at least one order. In other words, the business rule could potentially be violated during two quite distinct kinds of operational business event.  The first – “When a customer places an order …” – is rather obvious.  The second – “When an agent leaves our company …” – might be much less so.  Both events are nonetheless important because either could produce a violation of the business rule. This example is not atypical or unusual in any way.  In general, every business rule producestwo or more kinds of operational business events where it could potentially be violated or needs to be evaluated.  (I mean produces here in the sense of can be analyzed to discover.) These operational business events can be called the business rule’s flash points.  Business rules do exist that are specific to an individual event, but they represent a small minority. Two additional points:
  • Expressing each business rule in declarative form helps ensure none of its flash points is exempted inadvertently.
  • Discovering and analyzing flash points for business rules can also prove useful in validating business rules with business people.  Important (and sometimes surprising) business policy questions often crop up. 
~~~~~~~~~~~~~~~~~~~ Excerpted from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs


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

Continue Reading

Where Rules Fit in the Zachman Framework … Conspicuous in Their Absence?

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #8 Question: Why aren’t rules found in any of the cells of the latest Zachman Framework? The Manifesto says clearly (principle 1.1) that rules should be considered a first-class citizen of the requirements world. Yet rules cannot be found in any of the cells of the latest Zachman Framework. Contradiction? No. For an artifact to appear in a cell of the Framework it must represent a primitive. An artifact that references multiple primitives is considered a composite Rules are intrinsically composite. Even atomic rules can address multiple primitives. (Atomic means “can’t be reduced into two or more rules without losing meaning.”) An example: An accounting must be given by the CFO in Delaware on March 15, 2015. This rule refers to a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). Simply because an artifact is composite, however, doesn’t necessarily make it unimportant. Consider what Zachman calls integration relationships – the connections tying the six primitives together. Integration relationships serve to configure the enterprise at any given point in time. No integration relationships, no enterprise. To illustrate, Zachman frequently rolls the Framework into a cylinder and looks through it like a telescope. The primitives must be tied together through that empty cylinder by integration relationships. What can serve in that role? Traditionally, integration relationships have been implemented by procedural means – hardcoded into application programs. Unfortunately, that’s like setting the business in concrete. It also plays havoc with process as the simple, straightforward primitive it should really be. A much better alternative is rules. Rules, by comparison, are far easier to change. So consider rules as the first-class candidate to achieve configuration agility for the enterprise  


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

Continue Reading

What Role for Business Rules in *Knowledge Retention*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #7 Question: How do business rules relate to 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’.


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

Continue Reading 1 Comment

What Role for Business Rules in *Enterprise Architecture*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #6 Question: What role should business rules play in enterprise architecture? 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.


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

Continue Reading

What Role for Business Rules in *Business Agility*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #5 Question: How do business rules support business agility? 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.  


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

Continue Reading

What Role for Business Rules in *Business Analysis*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #4 Question: What role should business rules play in business analysis? 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.  


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

Continue Reading

What Role for Business Rules in *Business Processes*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #3 Question: How do business rules relate to business processes? 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.

 


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

Continue Reading 1 Comment