I do NOT believe the way to achieve business agility is to “build a business knowledge-base that captures all the business rules and mental knowledge in an organization to prepare for change” (as one commenter recently wrote). I do NOT believe that, nor does the Business Agility Manifesto (https://lnkd.in/e5JCFc4) say to do that. As one of its three authors I am 100% certain.

The Manifesto’s message is that change initiatives should be conducted in more knowledge-aware and knowledge-centric fashion than today. As you develop business capabilities (conduct projects) the knowledge should be made explicit (e.g., as business rules, concept models, etc.) and retained. That approach permits not only the given business solution to be more agile, but as the knowledge is managed and extended, solutions built subsequently as well. You build on success.

We three authors spoke together November 10 on the Opinion of Gurus panel at the Building Business Capability (BBC) conference in Orlando, Florida (a spectacular event!). We specifically said NOT to go about things the way the commenter said. So who’s the guilty party that says we do?!

Let’s put you on the hot spot. You are forced to agree or disagree with the following statement, and defend your answer. What would you say?

Empowerment, more than rules, processes or architecture, is key to business agility.

Here’s how I answer: I disagree. How about you?

My reasoning: Professionals in our field are often quite shortsighted with regard to empowerment. Many simply get it wrong. Working within business rules, processes and architectures doesn’t lessen empowerment; it lessens anarchy.

The real nemesis of business agility is things running amok. That’s true at both ends of the spectrum, from customers to IT.

• Customers: Ultimately the most important thing for customers is simple consistency and faithful compliance with the company’s obligations (business rules). That’s what I call high-fidelity customer experience. That capability can’t be achieved without rules, processes and architectures.
• IT: The ability to generate code faster – call it ‘agile software development’ or what you please – does not produce business agility. Business agility requires sustainability. In a digital world it’s not enough simply to put up systems fast and to keep them running. Business rules change, sometimes quite rapidly. You must be able to roll out changes to those business rules at the ‘speed of business’ to systems already implemented. Again, that capability can’t be achieved without rules, processes and architectures.

The industry’s view of empowerment tends to be askew. Who are we trying to empower, and why?

• Customers: Empowerment means the company always meets their expectations. The company has captured the requisite knowledge (business rules) to deal with them correctly and consistently. Customers know they can depend on you to get it right.
• Workers: Empowerment means freedom from having to be hands-on with everyday mundane cases. By having capturing the requisite knowledge (business rules) beforehand, you free up their time to deal creatively with outside-the-box cases.
• Business analysts: Empowerment means business analysts don’t have to reinvent the wheel on every new project. You’ve created deep knowledge reservoirs (of business rules) to jump start each new initiative.

~~~~~~~~~~~~~~~~~~~~~~

Mark Your Calendar: The annual Building Business Capability (BBC) conference is November 6-10, 2017 at the Loews Royal Pacific Resort, Orlando, FL. The BBC is the place to be for professional excellence!

I wouldn’t go so far as to say that process and BPM are meaningless across the board in the digital economy. If you’re manufacturing or producing a physical product, you still do need to think in terms of a modeled and managed business process. Other the other hand, if your products are non-physical – for example, money, time, skills, information, meta-data, etc. – you’d better have a major re-think. The old rules of the game simply don’t apply to white-collar work. Nor do they apply if your business model is about digitally leveraging other people’s idle assets – think Uber. You must still consistently satisfy contractual obligations and regulatory constraints in this new digital world of course. But that’s a business rules problem, not a process problem. A major characteristic of the new digital world is that activity is never static in any sense of the word. You simply get no points for hardwiring repetitive behaviors. You must:

• Continuously make informed operational decisions in the blink of an eye (actually often faster than that).
• Selectively respond to changing circumstances with subtle adjustments.
• Be as dynamic as possible, yet still produce outcomes of predictable, consistent quality.

These too are business rule problems, not process problems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Let’s stand back and think for a moment about the future of your business and its approach to business analysis. What’s really important? My elevator pitch would comprise the following insights.

Insight 1. Order-of-magnitude improvements in business agility are possible … and proven.

Every year for the past 15 years at the Business Rules & Decisions Forum Conference[1], we’ve heard one case study after another about how companies have dramatically improved business agility. Time and time again they report having reduced the cycle time of deploying changes to business rules by an order of magnitude or more. Extensive applied experience exists in the field – such initiatives are not at the bleeding edge.

What’s actually required? Two things: Some new techniques and vision. Are we to be forever prisoners of legacy? Only if we let ourselves.

Insight 2. Doing more of the same, just faster, won’t get you there.

You’ll never get to agile business via agile programming and development. Not ever.

A requirements development and design methodology should result in high-quality systems that are inexpensive to maintain and cost-effective to enhance. How well is yours really doing that in that regard?

Insight 3. It’s not about working harder, just smarter.

Most of us are frankly already working about as hard as we can. That’s not the problem. Rather, it’s about working smarter – and producing more effective business solutions. For that you need (true) business architecture.[2] It includes business strategy, business processes and business rules, and business vocabulary (concept model).[3]

Insight 4. It’s about building business capability, not better business software (though that will happen).

Quick Quiz: Which of the following is/are directly about software?

• Business rules.
• Business architecture.
• Business strategy.
• Business processes.
• Business vocabulary.

None of them! Of course you can use software to manage and implement any of them, but that’s a very different matter. If they’re not about software, then what? Architecting real solutions for real business challenges. Building business-oriented, business-based business capability. Any business software solution that doesn’t base itself today on these new fundamentals will be LOD – legacy on delivery. It’s time we move beyond instant legacy. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com  

Your ability to respond in appropriate ways to pinpoint circumstances where business rules are breached – automatically and independently of processes – provides the mechanism you need to support very smart, very friendly business systems. Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred. Can breaches occur for decision rules too? The answer is yes and no. Read on! A breach occurs for a business rule when the business rule isn’t satisfied upon being applied to some set of circumstances (state of affairs). Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred (e.g., you violated the posted speed limit). The potential for violations of behavioral rules raises several important questions that business analysts should answer in advance of deployment for each behavioral rule[1]:

1. What level of enforcement should be applied.

2. What special response to a violation is appropriate, if any.

3. What special message, if any, should be returned to some worker(s) upon a violation.

Unlike behavioral rules, no definitional rule[2] can ever be violated. Literally, things must be correct under such rules by definition. Let’s take an example. Suppose somebody asserts “2+2=5”. According to the rules of mathematics, we know the correct answer is 4. The answer “5” is deemed irrevocably wrong. But is the asserted answer ever allowed to stand?

• If the rule is defined as a decision rule, the asserted answer is never allowed to stand. More precisely, the assertion would never be recognized to have happened in the first place. If someone asserts “2+2” the answer “4” is concluded immediately. Period. No breach, no opportunity for error.
• If defined as a behavioral rule (one that is not strictly enforced), the asserted answer is allowed to stand, but a violation is recognized. How might that capability be useful? Suppose the error were made by a student in grade school. It might be quite useful for the student and/or a tutor to know about it immediately and automatically. Specifying an appropriate violation response can make such notification happen.

In business, of course, definitional rules can be far more complex. Nonetheless, your ability to respond in appropriate ways to the pinpoint circumstances where certain rule-related events occur – automatically and independently of processes – provides exactly the mechanism you need to support very smart, very friendly operational business decision systems. Decision Rules and Breaches Decision rules[3] are a special kind of definitional rule involving implications (e.g., A implies B). They support inferences and determinations – identifying an appropriate outcome from among a set of alternatives. Like all decision rules, definitional rules cannot be violated. They are simply deemed true by definition. Purely from a business perspective, however, some assertions of fact(s) may make it appear that a breach-like event has occurred. I take pains to emphasize any such perception is purely from the business perspective, not from the perspective of logic. You perceive a breach of a decision rule simply because it’s useful to do so, not because any true violation has occurred. In evaluating some particular case (situation, set of circumstances, or matter of concern), for example, things might not follow the ‘happy path’. Think of a breach of a decision rule as a bump in the road – a gap along the happy path. Let’s return to the three questions listed earlier. Although the first question about enforcement level obviously doesn’t apply to decision rules, adjusted versions of questions 2 and 3 remain in play. Consider the following simple business example. Suppose a bank has this decision rule:

A credit application must be considered discrepancy-free with respect to a credit report for the applicant if all the following are the same:

• name
• date of birth
• Social Security Number
• current address
• previous address

Let’s suppose that an applicant uses just the initial for her middle name on her credit application. If the credit report shows her full middle name, then the names are not the same and the credit application will not be considered discrepancy-free. Note carefully the rule hasn’t been violated; it did its ‘work’ correctly and it did reach the proper conclusion (not discrepancy-free).  But a gap – a breach – for her case has been identified from a business perspective because the rule failed on one of the conditions. We should be able to take advantage of that breach to take appropriate action – selectively, automatically and in real time. For example, the desired response to the breach might be to insert the following to-do item in the work queue of the responsible staff member: “Review discrepancy and manually ok if appropriate”. (The to-do item should naturally also provide ready access to the related documents.) The breach of the rule causes this action to occur automatically. Think about how many decision rules might exist for determining credit-worthiness, and how many selective conditions they might have. Could you build a responsive system by incorporating the selective responses needed into the related process model(s)? Not a chance – that approach won’t scale. Instead, the selective responses need to be specified based on the business-rule side of things. Kinds of Breach Specifications for Decision Rules Breach specifications for a decision rule can be of the following two kinds.[4] Breach Response. A breach response can be an action of virtually any kind. For example, a breach action might be to:

• Add some task(s) to a (non-redundant) to-do list in some appropriate work queue.
• Add some documentation items to a (non-redundant) not-yet-received list.

By these means very selective follow-up processing/handling (“what to do next”) can be organized pertaining to any specific issue (breach) for a given case. Such selectivity is made possible by the granularity of the rules. Breach Message. A specially-worded breach message can be forwarded to any involved party either inside or outside the company. A breach message generally explains one or both of the following at any level of detail desired:

• Why the rule or condition failed. (The rule or condition statement already indicates very precisely what the issue is, but the breach message can explain in a more friendly manner.)
• What should be done to address the issue.

More Complex Example Breach specifications apply selectively and specifically to a decision rule and/or any of its conditions. A breach specification applies if and only if that decision rule and/or condition fails (is not true) in evaluating some specific case (e.g., a specific credit application). An example of a decision rule with condition-specific breach specifications is illustrated in Table 1. Table 1. Example of More Complex Decision Rule with Condition-Specific Breach Specifications

Decision Rule	Breach Response	Breach Message
A fluctuating income must be considered eligible if all the following are true:
Conditions of the Decision Rule
the applicant has a 3-year proven track record of consistent income
the applicant is likely to have comparable income in the future	Add to-do item for that credit application: “Contact employer to verify applicant has reasonable opportunity for future income.”
the income is validated	Add required documentation items not yet received to a pending list for the credit application.	To applicant: “[date] Here’s a list of documentation items related to your income we have not yet received. [pending list].”

  Using Breach Specifications Breach specifications can be:

• General for an entire decision rule including all its conditions. (The example in Table 1 doesn’t include any whole-rule specifications. If the rule did they would appear in the first row.)
• Specific to a given condition.
• Specific to collections of conditions (none shown for the example).

A breach is detected only if the conclusion of the rule as a whole, or some particular condition within it, evaluates to not true. Things being true should be viewed as moving the case along the desired path (i.e., no breach has occurred).[5] Decision rules (and breach specifications) should be expressed carefully so as to preserve this positive orientation. Generally, breach actions should be specified only if something can be done to overcome a failure (of a rule or condition). The goal is to move things forward in the case.[6] In the example above, for instance, if nothing whatsoever can be done to correct an issue, the credit application should simply be declined. A behavioral rule to that effect should be specified. In hierarchies of decisions (e.g., as in Q-Charts[7]) and decision rules (e.g., as based on series of logical dependencies), breach specifications should generally be made only at the lowest level of rule reduction/decomposition. A rule at a higher level in a logical hierarchy only evaluates to not true if some rule(s) below it evaluate to not true. Define breach specifications at the lowest level of granularity. ~~~~~~~~~~ www.BRSolutions.com

---

The point of knowledge (POK) is a real place. POK is where know-how – business rules – are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen. When you start to fully understand business rules, a whole lot of other pieces of the puzzle fall right into place.  You arrive at smart architectures, which gives you smart knowledge management and smart processes. In smart architecture, business systems become knowledge companions, enabling never-ending, on-the-job training.  Flash points of knowledge – real-time evaluation of business rules – enables dynamic processes and personalized, just-in-time delivery of up-to-date guidance. A smart architecture is one equipped to address the formidable challenges facing businesses today – the accelerating rate of change, massive customization, and products and services that are ever richer in knowledge.  Effective engineering of the POK is the new litmus test for agility. The question you should be asking: How do you get your company to the point of knowledge? ~~~~~~~~~~~~~~~~ Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php www.BRSolutions.com  

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.

• An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
• The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
• We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
• Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
• The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).

What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:

• Focuses on real business know-how, not just better GUIs or dialogs.
• Continues vigorously after deployment, not just during development.
• Occurs at a natural business pace, not constrained to software release cycles.

The Manifesto says 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 knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

---

Celebrating the 10^th 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  

Celebrating the 10^th 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.  

This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php ~~~~~~~~~~~~~~~~~ Agile in software development is an IT development method featuring rapid iteration and prototyping. Agile software methods and business agility have nothing to do with each other. Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls. Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually. But the ‘flexibility’ is just an illusion. The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come. It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions. It makes apple-to-apple financial comparisons virtually impossible. And it always costs a lot in ‘maintenance’. There are simply no magic bullets for building business solutions. Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing. All artificial (IT-based) production freeze dates for deployment disappear and the software release cycle becomes irrelevant. The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to. So the answer to my question is that business should be agile. Here then is our definition of business agility: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense.