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?!
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/
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.
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.
The world that presents itself to us today is characterized by ever increasing complexity, expanding scale, and accelerating rate of change. A first and fundamental step in coming to grips with that world is simply to realize that operating on the basis of rules is the only viable solution.
Based on that understanding, here are three fundamental principles for a new knowledge paradigm.
Principle 1: Follow the same basic rules through every channel.
Providing consistent customer experience requires applying the same basic business rules through each and every channel. These rules should govern both interactions with customers as well as dissemination of products and services to them.
Some people feel that operating on the basis of rules, and applying basic rules uniformly, produces stiff, inflexible behavior. Not at all! By basing actions on rules, you can see clearly when to bend them, and when to extend them. It’s a basic part of the mindset.
Principle 2: Know what your rules are.
To follow the same basic rules through each channel you must actually know what your rules are. How many companies today actually do with any certainty?! How many have their business rules right at their fingertips?
The key to operational excellence is how well you organize, deploy and re-use operational business knowledge. Business rules, quite simply, are the most fundamental kind of operational business knowledge. What has your company done about business-side rule management?
Principle 3: Give your rules a good life.
Just knowing your rules and keeping them at your fingertips is not enough. You must give your rules a good life – you must keep them evergreen. Business rules must become a living-and-breathing resource of your business.
That’s not the way it is today in most organizations. The business has outsourced its business rules to IT (which in turn has often outsourced them off-shore). The rules get mangled in highly convoluted implementations. There’s no accessibility for easy adjustments, and no traceability for quickly resolving problems. That’s not a winning formula for operational excellence.
“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.”
Jeanine Bradley – Railinc
“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.”