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

The Procedural Paradigm Won’t Scale: We Need Configuration Agility!

It’s been said that I claim the procedural paradigm won’t scale anymore. Guilty as charged! Let me explain. Procedural vs. Declarative In the big scheme of things, you have two basic choices for conceptualization, and ultimately implementation, of business capabilities: procedural vs. declarative. Let’s make sure we agree on what these terms mean. I’ll draw directly on Merriam-Webster Unabridged to make sure we’re on the same page. If the terms don’t mean what they’re supposed to mean, all bets are off. But I guess that goes without saying, doesn’t it?

procedure: 1a: a particular way of doing or of going about the accomplishment of something 1b (1): a particular course of action (2): a particular step adopted for doing or accomplishing something (3): a series of steps followed in a regular orderly definite way

You can spot the seeds of the scalability problem right away with repeated use of the word “particular” and with the phrase “regular orderly definite way” in the definition. Given the degree of product/service customization desired today, and the accelerating rate of change, how much business activity still occurs in a particular and regular orderly definite way? The answer, of course, is less and less all the time. ‘Exceptions’ have become the rule. The essential characteristic of procedures is that they flow. The flow comprises the steps by which a thing is intended to become a different thing (or the same thing in a different state). The essence of ‘procedure’ is therefore that something will be hopefully transformed. For sure, that’s a very basic, very important, very necessary part of any business capability. The problem arises taking procedure beyond that point. Something declarative, in contrast, doesn’t flow. It just states something that must (or should) be true.

declarative: 2: having the characteristics of or making a declaration : ASSERTIVE;  specifically : constituting a statement that can be either true or false

Business rules are that way; they simply give guidance. They don’t do anything. They don’t flow anywhere. They can’t be anything other than true or false. In short, business rules are fundamentally different than procedures. Big-P Process The traditional procedural paradigm (I’ll call it Big-P Process) embeds business rules in procedures (and in process models and in procedural code).What happens when you treat things that could be declarative in a procedural way? You get bloat. You lose business intent. You produce needless complexity. And you also get what I call configuration stagnation. As you scale, these problems grow exponentially. How many business rules are we talking about? Any given business capability easily has hundreds, sometimes thousands of business rules – especially when you begin to factor in the know-how needed to make smart operational business decisions. And don’t our businesses increasingly depend on ever more complex know-how? Is there any end to that trend in sight? At the scale of today’s business, the Big-P Process paradigm simply doesn’t work. It results in ungovernable business operations and unretainable know-how. Big-P solutions are like setting the business in concrete. It’s all so unnecessary and so counterproductive. It’s just not smart. Configuration Agility The key question for agile business capabilities is how the business is configured (and quickly reconfigured) for operation at any given point in time. In the Big-P paradigm, the building-blocks become thoroughly entangled with flow (procedure). The result is essentially a semantic dead zone. Because things that could be expressed declaratively aren’t, the opportunity is lost to use logic to automatically evaluate business rules (read ‘business practices’) for conflicts, anomalies and other logical defects. The future clearly does not lie in that direction. Instead, it lies with granular, declarative, semantically-rich specification of business configurations in building-block fashion. It lies with the paradigm that can produce the optimal configuration agility. In addition to procedures, smart configuration models will feature at least these other building blocks for business capabilities, all specified at the business level:
  • business rules 
  • operational business decisions 
  • structured business vocabularies (concept models, also known as fact models) 
  • business goals and risks 
  • business events
From an engineering perspective, the secret to agile configuration is ‘late binding’ – that is, bringing all the pieces together for execution (i.e., performance of procedures) as late as possible. That way, performance can be as up-to-date and as flexible as possible. Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I simply see no alternative. Doing more of the same is simply not going to work anymore (and already hasn’t been for a good, long while). [Warning, plug coming]: Smart configuration schemes also address business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book, Building Business Capabilities (see http://www.brsolutions.com/b_building_business_solutions.php) we call systems built using smart configuration models business operation systems (as opposed to ‘information systems’).  

Continue Reading 2 Comments

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

Breaking the Rules: Breach Questions

What should happen when a business rule is broken[1]? As discussed in this post, Business Analysts should answer three questions:
    1. How strictly should the business rule be enforced?
    2. What message is appropriate?
    3. What response is needed?
Developing a friendly, secure business solution requires overt answers to these questions for at least a subset of business rules. (As explained later, defaults can be assumed for the others.) It should also be possible to easily change or evolve the answers (including defaults) after deployment of the business rules, thus permitting the business capability to become incrementally smarter. The goal is context-dependent, pinpoint reaction to breaches in real-time.  Addressing breaches intelligently is key to creating friendly, agile, secure business solutions, ones that can evolve rapidly in day-to-day operation. Breach Question 1.  Enforcement Level How strictly should a behavioral rule[2] be enforced? Example …

Business Rule:  A service representative must not be assigned to good customers in more than 3 states or provinces.

Ask:  How strictly should this business rule be enforced?

Enforcement Level:  Override by pre-authorized actor

Table 1 lists the most common enforcement levels for behavioral rules.[3] Table 1Common Enforcement Levels for Behavioral Rules
Enforcement Level Description
strictly enforced Violations are disallowed in all cases – achieving some newstate successfully is always prevented.
override by pre-authorized actor The behavioral rule is enforced, but an actor with proper before-the-fact authorization may override it.
override with explanation The behavioral rule may be overridden simply by providing an explanation.
guideline Suggested, but not enforced.
  Be sure not to overlook the last enforcement level Table 1.  A business rule that is actively evaluated, but not enforced, is (literally) a guideline. Guidelines are business rules too! Breach Question 2.  Guidance Message What message should be returned when a breach of a business rule occurs? When a business rule is breached, somebody, often a business actor directly engaged in a business process, needs to know about it.  The breach means the work being conducted has strayed outside the boundaries of what the business deems acceptable or desirable.  From a business perspective an error has been made, so some error message should go out.  What should that error message say? As a default, we like to say that the business rule statement is the error message.  From a business point of view, that equivalence must always be true – what else are business rules about?! Rather than saying ‘error message’ (which sounds technical) or ‘violation message’ (which sounds harsh, especially for guidelines), we say guidance message. Generally, guidance messages should be as friendly and as helpful as possible.  For example, guidance messages can be written in a more personal, informative style. More explanation or suggestions can be appended or substituted as desired.  Perhaps a link to other media (e.g., a how-to video) can be provided.  Sometimes the best guidance message takes the form of some icon or signal (e.g., a warning light turning to yellow or red).  Guidance messages frequently need to be specific to the circumstances in which a breach occurs (e.g., what role or user produced it). In all cases, guidance messages should be made available only to people who are qualified and capable. Breach Question 3.  Breach Response Does the breach response for a business rule need to be more selective, rigorous, or comprehensive than simply a message? Example …

Business Rule: A cursory review of a received engineering design must be conducted within 5 business days of the date received.

Ask:  What breach response is appropriate for this business rule?

Breach Response:  The received engineering design must be brought to the attention of the manager of the department by the morning of the next business day.

Breach responses can take any of the following forms:
    • business rule (as illustrated above), or set of business rules
    • processes or procedures
    • sanctions or penalties
    • operational business decisions
    • special notifications, displays or instructions
Multiple breach responses might be desirable for a business rule. They might also need to be specific to the circumstances in which a breach occurs (e.g., what particular part of a process is being performed). Usually, breach responses serve to increase user-friendliness. In cases of potential fraud or malicious business behavior, however, breach responses should be much more aggressive. Defaults Natural defaults for the three breach questions are listed in Table 2. Table 2.  Defaults for the Breach Questions
Breach Question Default
enforcement level strictly enforced
guidance message the business rule statement itself
breach response none
 
[1]Fundamental to business analysis with business rules is the assumption that breaches of business rules can be detected.  If you can’t detect breaches, how can you run the business?! To say it differently, if you can’t detect breaches of a business rule, but you can still run the business, perhaps you don’t need the business rule at all(!).
[2]This breach question applies only to behavioral rules. Since definitional rules must always be true, they are in essence strictly enforced.
[3]Table 12-1 of Business Rule Concepts, 3rd Ed. (Chapter 12) discusses additional enforcement levels.  It also provides tips for designing procedures with business rules.

Continue Reading 3 Comments

What Role for Business Rules in *Requirements*? 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 #2 Question: How do business rules fit with requirements? 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 seldom featured in requirements and IT methodologies. That’s very strange if you think about it. So 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.

 


[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

Business Agility vs. Agile in Software Development: Not Related!

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. We define business agility as follows: 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 Agile in software development is an IT development method featuring rapid iteration and prototyping.  Agile 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! ~~~~~~~~~~~~~~~ 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  

Continue Reading 1 Comment

Not Much Luck So Far Bringing in Thoughts on Agile *Business* Governance …

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the third one: I haven’t been able to find anyone so far talking about agile governance. Why not?! I recently posted this on an architecture and governance forum:

Is there such a thing as ‘agile’ governance’? What would it entail? Looking for ideas or experience in the matter … Here are a few thoughts. I think answers should touch on business policies and business rules. And put agile IT development into perspective. What am I missing? http://goo.gl/nCpPC

Guess what I got back? Thoughts on software platform governance, agile methods applied to business rule development, and more – everything except what I was looking for. Perhaps I’m partly to blame myself. There’s always going to be problems when you (me in this case) don’t define terms. By ‘governance’ I meant *business* governance … the running of business operations. The running of the show. On ‘agile’ I fudged a little. I really meant ‘agile’ simply in its real-world (dictionary) sense of “characterized by ready ability to move quickly and easily with suppleness and grace; characterized by quickness or liveliness of mind, resourcefulness, or adaptability in coping with new and varied situations”. But I knew ‘agile’ would probably invoke the IT sense. So let me try again: Does anybody have any thoughts on *agile governance*? To be more clear this time what I mean by ‘agile governance’ … 

Agile governance: the running of business operations in a manner “characterized by ready ability to move quickly and easily with suppleness and grace; characterized by quickness or liveliness of mind, resourcefulness, or adaptability in coping with new and varied situations” … where business rules, business policy, and rule management play a key role.

Continue Reading 5 Comments

Why Doesn’t the ‘Knowledge Management’ Community Get it?

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the first one: Why is it that people discussing ‘knowledge management’ seem to have so little understanding of the core know-how actually needed to run (and change) day-to-day business activity? Core operational know-how consists of business vocabulary, business policies, and business rules. That ‘knowledge’ is currently locked away in IT applications and platforms (or in people’s heads) where it is virtually immune to change. That’s a boon to service providers and IT departments, but a bane to business agility. What business really needs today is agile governance … but few seem to be talking about that. P.S. Social media won’t help much here. You simply have to ‘do’ business rules.

Continue Reading 5 Comments

The ‘Process’ of Business Analysis is a Great Example of a Social Process

In a recent post, Jonathan ‘Kupe’ Kupersmith said:

“In manufacturing following a process step by step is a good thing. In our world [business analysis] this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project.”.

I believe what Kupe is saying is that the ‘business analysis process’ is not a traditional straight-line process (like old-style manufacturing). Instead, it is what is currently being called (variously) a ‘social process’ or ‘dynamic process’ or ‘case-based process’. Such a process is:
  • Social in that interactions at various times with various people with various kinds of know-how must be orchestrated for optimal results.  
  • Dynamic in that the ‘flow’ is highly situation-based rather than predictably straight-through (static).  
  • Case-Based in that the ‘flow’ of events is based on the particular characteristics of the case (project) at hand, rather on forced conformance with some ideal.
Let me make a couple of observations (which are not points of disagreement with Kupe): 
  • There are many, many companies (even in manufacturing) now beginning to understand that their core business processes should be organized as social/dynamic/case-based rather than traditional/static/straight-line. Customization and personalization of products and services demand it.  
  • Achieving manageable customization and personalization at scale requires an appropriate infrastructure that is business-based.  
  • The need for infrastructure leads inevitably to business vocabulary (business semantics) and business rules. (What’s the alternative??) So business rules are probably even more essential for social/dynamic/case-based processes than traditional/static/straight-line ones.
What do these observations specifically mean for the ‘business analysis process’? I would suggest the following: 
  • Having a standard business vocabulary for the ‘business analysis process’ is key. How many organizations really have one? I see this omission as a huge hole in current BA standards and practices. (Plug: Our new book, Building Business Solutions: Business Analysis with Business Rules, has a 55pp Annotated Glossary. We practice what we preach. http://www.brsolutions.com/b_building_business_solutions.php)  
  • The know-how to support a social/dynamic/case-based ‘business analysis process’ should be expressible as rules. If the know-how can’t be articulated and properly communicated, then how can the process be repeated, learned and scaled? Tacit know-how is simply no longer adequate in a knowledge economy.
~~~~~~~~~~~~~~~  You can find Kupe’s original post on: http://www.batimes.com/kupe-kupersmith/why-business-analysis-processes-are-a-waste-of-time.html

Continue Reading 2 Comments

My New Talk and New Take on Business Architecture at BBC2011: The Architecture of Enterprise Know-How

Business Architecture Summit at BBC2011 – Thurs, Nov 3, 2011 – 10:10am I am giving a talk next week called The Architecture of Enterprise Know-How at the Building Business Capability (BBC2011) event in Florida. If you’re there, I hope you’ll come listen. I’ll be plowing new ground. We’ve done some fascinating work the past several years and now it’s time to talk about it … Does the know-how of the company have intrinsic structure at the enterprise level? Can you use that structure to assess and plan operational business capabilities? Where do business rules, business processes, and business analysis fit in? Every company depends on its special know-how, a point so obvious we often overlook it. The products and services we deliver to customers can never be better than our capacity to organize, manage, revise, and deploy that know-how. In a knowledge economy, operational know-how is king. Current techniques for creating enterprise architectures are largely IT-centric. They focus on processes, data and services rather than on business products and the business capabilities to produce and deliver them. We need to change all that using proven, pragmatic techniques that directly engage business managers. The new approach is highly innovative, business-driven, and surprisingly easy.
  • How to conduct a deep, meaningful, rapid assessment of business capabilities
  • How to identify life-cycle-long, enterprise-wide dependencies
  • How to give Finance the crucial, coordinated touch points it needs
  • How to plan for massive customization and reconfiguration of products
  • How to put the ‘business’ into business architecture and business agility
  • How to rekindle the spark of creative thinking in your organization
 

Continue Reading

The Debate Continues … Business Rules in Zachman 3.0 … and the Upcoming Business Architecture Summit at BBC2011

At the Business Architecture Summit in Ft. Lauderdale (BBC2011 – Oct 31 – Nov 4) I will be joining John Zachman and Roger Burlton for one of our rabble-raising 3Amigo sessions. The session is only an hour long, so I’m sure there will be some fast talking(!). One of the first questions I want John to address is: “Where are the business rules in Zachman 3.0?” The following recent exchange represents my current understanding on the matter. I plan to come back on the record after the event to say what I got right and what I got wrong. Question: Can rules address more than one primitive (column) in the Framework? My Answer: Yes, atomic rules can address multiple primitives – e.g., An accounting must be given by the CFO in Delaware on March 15, 2012. (By ‘atomic’ I mean ‘can’t be reduced into two or more rules without losing meaning.’) In this rule you have a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). So even atomic rules are composites, not primitives. Question: Does rules not being a primitive mean that business rules shouldn’t be treated as a first-class citizen? My Answer: What ‘first-class citizen’ has always meant in the Business Rule Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) and elsewhere is that business rules shouldn’t be subordinate to other kinds of requirements for system design in general, and to what I call ‘Big-P’ processes in particular. Big-P processes are not primitive (think ‘input-process-output’), but rather they amalgamate (think ‘mash-up’) some or even all the other primitives. In other words, Big-P processes are also composite. Composites are about the configuration of the enterprise at any point in time. Business rules are one candidate for that capacity. I believe business rules are a far better choice in that regard than Big-P processes (think ‘business agility’). In any case, business rules being a composite in no way diminishes their importance. The enterprise is not built on primitives alone. If you had only primitives, there would be no configuration, and literally no enterprise.

Continue Reading 1 Comment