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.
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.
My inner geek gets as excited as the next professional about all the technological innovations adding up to what gurus are calling the digital platform or digital business – or simply digital. This new wave of technological capability features social, mobile, cloud, big data, and more. It promises a host of new capabilities to accelerate innovation including robotics, 3D printing, internet of things, cognitive, and augmented reality. WOW!!
But there’s a little voice inside me counseling caution. When have new platforms or channels ever fixed major business challenges?!
It’s all too easy to get caught up in ChannelMania, a state of virtual panic about introducing the next big thing, keeping up with the Joneses technologically. In the frenzy you can easily lose sight of the hidden business costs.
We should step back, take a deep breath, and ask ourselves some fundamental questions.
How well can we really manage yet more channels?
Do we deliver consistent business results to our customers?
Are we happy with our current lot in managing change?
Does the company have any real strategy to address ever-accelerating complexity?
With all the new agile methods, is the business actually becoming more agile?
It’s not too hard to envision what real operational excellence would look like.
Your customers would get consistent business results through any of many channels.
Rolling out business change would be faster and cheaper.
You could demonstrate compliance at every turn.
You could manage complexity at scale.
You’d provide stellar customer experience at inhuman speeds.
The question, of course, is how do we get there? I argue that we need a new knowledge paradigm. I call it Business Knowledge Engineering.
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“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
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“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.”
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.”