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?!
I get as excited as the next person about current trends in how work is best organized in digital companies. Those trends include egalitarianism (especially of ideas), transparency of decision-making, openness to experimentation, fact orientation, servant leadership, middle managers as player-coaches, self-organizing and self-directed teams – the list goes on.
You can immerse yourself in all those trends and lead yourself to believe that business is being reinvented. In some sense yes it is, but in the most important sense, no it’s not.
The death of companies is not imminent. Top management is not going to disappear. Organizational hierarchies will continue to exist, even where flattened and energized.
What does that mean for discussion of agility? It means that if you want to pursue true business agility your thinking must be grounded in management imperatives. That is exactly the approach taken by The Business Agility Manifesto.
Put simply, management exists because the business owns assets from which value must be created. The persisting need for strategy, security and optimization all arise from that fundamental fact of life.
The need for business agility arises because the business ecosystem has never before been so dynamic, at least on the compressed timeframes we see today. Business agility is about creating a sustainable means to continuously change and adapt, while preserving, protecting and enriching business assets. Increasingly those assets include knowledge, a point the Manifesto takes as a critical point of departure.
Talking about agility only in terms of how to compact and energize organizational structures (hierarchies), while useful and exciting, fails to address the fundamental raison d’être for companies. Organizational agility is simply not comprehensive business agility. If only it were it that simple! Don’t be fooled. The problem of business agility runs far deeper than surface innovations addressing only work agility can ever resolve.
 Andrew McAfee and Eric Brynjolfsson confirm and explain this point brilliantly in chapter 13 “Are Companies Passé (Hint: No)” in Machine, Platform, Crowd (2017), W.W. Norton & Co, 402pp.
 McAfee and Brynjolfsson use the more elegant term ‘residual rights of ownership’. Their argument (very briefly) runs like this. Since contracts with other parties will always be incomplete, companies with their managers and hierarchies will continue to exist to make decisions in all cases where the contracts fall short. In other words, even with distributed ledgers (blockchains), smart contracts, powerful platforms, and machine intelligence a completely flat (purely egalitarian) business playing field will remain unworkable.
The 3 of us will formally introduce the Manifesto for the first time at the Building Business Capability (BBC) conference Nov. 6-10 in Orlando, FL. Be there to hear all about it and to discuss! http://www.buildingbusinesscapability.com/
Mining business rules from legacy code raises big challenges. They’re often implemented in arcane, highly procedural languages. The person or team who wrote the code is often long gone (or perhaps in India). Bringing them back into a form that business people and business analysts can understand is hard.
To illustrate, here is an as-coded example from a major bank:
For Primary Borrower or any Guarantor, IF [Processing Date – Credit Bureau File Since Date] is < 12 months AND the total # of Type Code of ‘R’ and ‘O’ trade lines is 3 or less AND the total # of ‘I’ and ‘M’ trade lines is zero AND the Industry Code = OC, ON, OZ, DC, DV, DM, DZ, Then result is Refer.
Obviously most business workers are not going to understand that specification or be able to validate what it says. Actually, this example is well above average in readability – most coding languages are even farther removed from daily business parlance. If you want to have real conversations with business partners, core business knowledge needs to be expressed in structured natural language (e.g., in RuleSpeak®), making careful use of common business vocabulary.
The example above is interesting for another reason. Note the outcome of the specification, the portion after the then, is “Refer”, meaning that the matter in question cannot be resolved. This specification actually does nothing but kick work back out to a human!
A specification that simply escalates a case to a human is not a true business rule at all. Rather, it’s an acknowledgement the actual business rule(s) still haven’t been captured and encoded. That knowledge lingers in somebody’s head (hopefully!).
Our broad experience in reverse-engineering business rules has exposed us to harsh reality: No silver bullets. Once business rules have been encoded procedurally, semantics are lost that cannot be resurrected automatically. You’ve made a bargain with the devil.
To speak plainly, most companies have no coherent strategy for integrated compliance. Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent business obligations, the very essence of business rules.
What form of traceability is needed for business obligations? Traceability from governing rules to automated rules, where:
Governing Rules include acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, guarantees, prospectuses, citations, certifications, notices, and business policies
Automated Rules include code tables, parameter settings, procedural code, implementation rule statements, help messages, etc.
Governing rules provide the baseline for running the business. These governing rules must be interpreted and supplemented, ultimately getting implemented in a wide array of platforms and tools.
In most companies today there is virtually no traceability for obligations between governing rules and automated rules. There’s an abyss, a big black hole, where there should be ready knowledge. Where does that leave the company?
Companies’ corporate memory is riddled with disconnects and gaps. Going back in time, it is difficult or impossible to determine who interpreted what governing rules into what implementation components, or why they did it the way they did.
Companies consequently are deeply dependent on hero-professionals to retain tacit knowledge. You hope they remember things correctly and thoroughly – and that they don’t leave the company.
A solution to the compliance challenge requires rethinking and reworking the traceability landscape for obligations to feature three layers of rules, not just two. The middle layer, practicablerules, is key.
practicable rule: an expression of a business rule that a capable (authorized) worker can read and understand and decide directly whether or not the business is in compliance in all circumstances to which the rule applies
Practicable rules are ones you can run the business by, whether or not ultimately automated. They should be expressed in structured natural language (e.g., RuleSpeak®) based on business (not IT or data) vocabulary. Here is an example:
An account may be considered overdrawn only if cash withdrawal is greater than the current balance of the account.
The acid test for whether a business rule is practicable is this:
You can give the statement either to a knowledgeable worker for use in day-to-day business operations to apply manually, or give to IT for implementation in an automated system, and get the same results either way.
Is that possible?! Absolutely!
The re-engineered landscape for compliance and traceability reveals the two distinct interpretations that need to be tracked:
First, governing rules are interpreted into practicable rules.
Second, those practicable rules that can be automated (by no means all of them) are interpreted into specifications that automated platforms can execute.
The key to operational excellence for compliance is committing both kinds of interpretations explicitly to automated corporate memory right as they happen.
By the way, business-side rule management does not have to be pursued at an enterprise scale. You can start out at any scale, including the project level.
Compliance in a broad sense means satisfying obligations and delivering on promises. Even high-quality customer service involves compliance of this kind – your products and services are always what you say they are, and your delivery of them meets customers’ expectations.
Some critical observations:
Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent obligations, the very essence of business rules.
These obligations are constantly amended, extended and (sometimes) terminated, so you need direct traceability for them.
The typical IT view of traceability is far removed from what the business actually needs to manage obligations.
Many professionals are so immersed in system development they cannot easily separate the notion of obligations (business rules) and requirements – e.g., specifications for modifying some system feature or procedure. Say ‘traceability’ and they immediately think traceability for requirements.
How system development needs to trace requirements into system designs is a very different proposition than the traceability needed for business obligations. The two kinds of traceability can and should be separated.
Requirements are about building systems, whereas business rules are about running the business.
Requirements generally fade into the background when a system is delivered, whereas deployment sparks a whole new phase of life for business rules.
I’m deeply concerned that agile software development is taking us giant steps backwards in terms of achieving true business agility. At some companies we visit things are simply out of control. The software development tail wags the business dog.
It’s not just me who thinks so. Here are some comments from recent conversations on social media:
“The business is now at complete mercy of IT Agile to the point where it’s cut out of critical product and service decisions. … IT agile delivery being seen as equivalent to agile/entrepreneurial business which is very far from the case.”
Donna Luehrman, MBA, CBAP
“Agile software development methodology is often antithetical to longer-term business agility and a short-sighted antagonist to the discipline required to achieve it.”
Howard Wiener, President, Codiscent Americas
Agile software development will never get you to agile business because it does not address operational business knowledge (business rules) in a direct or innovative fashion. By coding faster and faster many businesses are simply becoming more and more un-agile. Untold millions of dollars are being sunk into instant legacy. Worse, it may take untold billions of dollars to service that legacy over time. That’s not operational excellence; that’s operational negligence.
If your current approach is based on user stories and use cases and the like ask yourself these questions:
Question 1. Do you address business rules directly in your requirements approach? By ‘directly’ I mean in a systematic, traceable way. Or, do you implicitly assume IT will just somehow get them right?! I think that’s a very bad idea and a very big risk for operational business excellence.
Question 2. What are you doing to ensure governing rules are understandable by business workers and SMEs in the specific way that the business wants them to be interpreted and applied? What are you doing about rules that aren’t automatable? Aren’t those important? And what are you doing to coordinate and disseminate this knowledge to line workers in a systematic, repeatable way?
Is there a place for agile software development? Of course. Just not when it comes to basic operational business knowledge (business rules).
In many respects professionals in our field have a very a limited view of communication. Yes, of course we need to close communication gaps on every project, and among all stakeholders, and with IT. Though never easy, working to close those kinds of communication gaps should be a given.
Instead, we need to talk about a broader kind of communication – the communication of operational business knowledge over time and space. That requires some engineering. Let me put this challenge into perspective.
I recently read an interesting post in social media by Angela Wick about user stories and their role in agile and other requirements methodologies. The post depicted their role as addressing the tip of an iceberg, as in figure 1.
Figure 1. The Role of User Stories in Agile and Other Requirements Methodologies
Many agile gurus describe a user story as a placeholder for a conversation, or a promise of a future conversation. That’s a great characterization because it highlights the crucial point that user stories address only the 10% that you can ‘see’ above the requirements waterline. Over time, each user story must be fully explored and all the hidden detail, the submerged 90%, filled in.
The crucial question is what does all that hidden detail represent? A very sizable portion, certainly far more than half, is operational business knowledge – in other words, business rules.
Once you get that point, a next question naturally arises. Do you really want business analysts and system developers to re-invent and re-specify and re-design all that knowledge from scratch on each new project?! No! There’s nothing agile about that whatsoever(!). That’s simply re-inventing the wheel – over and over and over again.
We have clients telling us that they have achieved proven savings of 75% or more by having relevant business rules available before a project starts.
Pre-existing business rules allows project sponsors to launch projects on the basis of known facts rather than guesswork. It can reduce the difficulty of a project by an order of magnitude and improve the chances of success dramatically.
You should want – actually you should demand – ready-to-reuse, fingertip business rules for projects.
That’s where over-time-and-space communication comes to play. Ready-to-reuse, fingertip business rules represents communication of operational business knowledge across organizational boundaries and through the passage of time.
The things that IT implements under today’s software platforms are mostly not true business rules; rather, they are encoded representations of business rules. Don’t underestimate how pervasively across your organization business rule is misunderstood. What are true business rules?
True business rules are about running the business, not its systems. Your company would need its true business rules even if it had no software. True business rules are simply criteria used in daily business operations to shape behavior or make decisions.
True business rules are not meta-data or information. Only through gross misinterpretation or misunderstanding do they fall under that umbrella (and the related organizational function). Instead, true business rules are a form of knowledge. They are about what you need to know to make things work properly in daily business operations. Knowledge is knowledge. Information is information. They are simply not the same thing.
True business rules are about human communication – people-to-people communication, people having business conversations. True business rules enable business people to communicate operational business knowledge, not just things IT can implement. Such communication is especially important if (as is so often the case these days) the people are displaced by time and space.
Achieving these knowledge-related goals requires two things:
Business rules must be written. (If you are part of an agile project that believes otherwise, you need to rethink.)
Business rules must be written in declarative form using structured natural language. Here is an example of how a true business rule is written.
An account may be considered overdrawn only if cash withdrawal is greater than the current balance of the account.
When it comes to communicating knowledge, Murphy’s Law definitely applies. If something can be misinterpreted it will be misinterpreted. Capturing and expressing true business rules completely and accurately is a rich skill. (By the way, machines should certainly be able to help us with that.)
The need to communicate business rules in structured natural language led our company to create a world-wide set of conventions called Rulespeak® (free on www.RuleSpeak.com, now in 6 languages). There’s simply no substitute for precise, unambiguous communication of operational business knowledge. It’s central to business knowledge engineering.
How effective can true business rules be for things you are likely to want to do in digital?
Replace brick-and-mortar and salespeople or agents with apps.The matter here is quite simple – you’d better know what rules you want to follow. By definition, people will no longer be in the loop to make things right with the customer.
Up-sell or cross-sell products and services. To make the right suggestions you’d better know your customer – deeply and at scale. In other words, you need integrated knowledge about them.
Satisfy regulators or compliance or business partners you’re doing things right. You’ll need to be able to trace equivalent rules through each and every channel. Giving your rules a good life can make all the difference in the world.
Something else you’ll want to do in digital is to differentiate your business products or services. You’ll naturally want customers and clients to perceive your business products as unique or special.
The cheapest way by far to ‘do different’ is not by via new storefronts or websites or channels but rather via true business rules. Think about it. Business rules don’t cost you anything except the time it takes to capture, deploy and manage them.
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”