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.

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

Read more: http://www.brcommunity.com/articles.php?id=b904

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.[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.

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

[1] User Stories: You Don’t Have to Be Agile to Use Them! by Angela Wick, http://www.batimes.com/angela-wick/user-stories-you-don-t-have-to-be-agile-to-use-them.html

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:

1. Business rules must be written. (If you are part of an agile project that believes otherwise, you need to rethink.)
2. 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.

~~~~~~~~~~~

Read about the new knowledge paradigm: http://www.brcommunity.com/articles.php?id=b900

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.

~~~~~~~~~~~

Read about the new knowledge paradigm: http://www.brcommunity.com/articles.php?id=b900

Can you understand that all three of the following business rule statements mean the same thing? Here’s what must be true: If you mow the lawn on Sunday your lawn mower is to be electric; otherwise the lawn is not to be mowed on Sunday.

1. It is permitted that the lawn be mowed on Sunday only if the lawn mower is electric.

2. It is prohibited that the lawn is mowed on Sunday if the lawn mower is not electric.

3. It is obligatory that the lawn not be mowed on Sunday if the lawn mower is not electric.

I’m fairly certain you can. And if you can determine they all mean the same thing, I contend a machine ought to be able to do so too. I mean as stated in this exact same human-friendly, structured natural language form. And tell you that the statements mean the same thing (in effect, that they are redundant). That’s the kind of language-smart (cognitive) capability that business innovators should be expecting – no, demanding – from software vendors.

P.S. In the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR) the three statements are a restricted permission statement, a prohibition statement, and an obligation statement, respectively. You might prefer one or another of these forms of statements, but each is correct and reasonably understandable. Here are the RuleSpeak^©[1] equivalents – even more friendly:

1. The lawn may be mowed on Sunday only if the lawn mower is electric.
   
   
2. The lawn must not be mowed on Sunday if the lawn mower is not electric.
   
   
3. (same as 2)

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

Get trained: Instructor-led, online, interactive training: April 4-6, 2017 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.brsolutions.com/services/online/strategy-to-requirements/

©Business Rule Solutions, LLC 2017. www.BRSolutions.com

[1] Free on www.RuleSpeak.com

A number of years ago, a colleague of ours, Mark Myers, came up with a highly pragmatic test to determine whether some statement represents a business rule or a system rule. 

“Imagine you threw out all the systems running your business and did it all by hand (somehow).  If you still need the statement, it’s a business rule.  If you don’t, it’s not.” 

A colleague on the SBVR[1] standardization team, Don Baisley, puts it another way: 

“Business people don’t set variables and they don’t call functions.”

Business rules represent a form of business communication and must make sense (communicate) to business people.  If some statement doesn’t communicate, it’s not a business rule.  Consider this example: 

If ACT-BL LT 0 then set OD-Flag to ‘yes’. 

Not a business rule.  Consider another example: 

An account must be considered overdrawn if the account balance is less than $0. 

This statement communicates and therefore is a business rule.  Business rules can be technical, but only in terms of the company’s know-how or specialized product/service, not in terms of IT designs or platforms. 

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

Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015

Get the Book: http://www.brsolutions.com/publications/building-business-solutions/ 

Get the Training: Instructor-led, online, interactive training: December 13-15, 2016 – Working with Business Rules: Capture, Specification, Analysis & Management. http://www.brsolutions.com/services/online/working-with-rules/ 

©Business Rule Solutions, LLC 2016. www.BRSolutions.com  

[1] Semantics of Business Vocabulary and Business Rules (SBVR).  First released in January 2008.  Object Management Group.

Dilbert finds himself between a rock and a hard place. He must use the blue recycling bins for company documents, and he must not use the blue recycling bins for company documents. Ever find yourself in a similar situation?

A conflict within or among some business rule(s) is an anomaly such that multiple states or outcomes are required that cannot all be satisfied simultaneously. In other words, the same circumstances or cases require mutually-exclusive states or outcomes. 

Consider the operational business decision, What is the right delivery method for an order? The potential outcome picked up by customer is mutually exclusive with the potential outcome shipped by normal service. (If an order is picked up it can’t be shipped, and if it’s shipped it can’t be picked up.) If some business rule(s) require(s) both outcomes for the very same circumstances or case, a conflict arises. 

In general, only business people or business analysts can resolve conflicts. They reflect matters of business policy.

Want to get rid of conflicts? First you need to know how to find them (hopefully not the same ones regularly, in weekly meetings), then you need to know how to resolve them. There’s a good deal more to that than meets the eye.

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

Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015

Get the Book: http://www.brsolutions.com/publications/building-business-solutions/  

Get the Training: Instructor-led, online, interactive training: December 13-15, 2016 – Working with Business Rules: Capture, Specification, Analysis & Management. http://www.brsolutions.com/services/online/working-with-rules/  

©Business Rule Solutions, LLC 2016. www.BRSolutions.com

Software vendors and others mislead people (badly) about the true meaning of business rule. Let’s set the record straight. The OMG standard SBVR (Semantics of Business Vocabulary and Business Rules, 1.4) defines business rule as a rule that is practicable and is under business jurisdiction. The definition has these three parts: (1) rule, (2) practicable, and (3) under business jurisdiction. Let’s look at each part in turn. 1. Rule Rule in business rule means real-world rule – in other words exactly what the dictionary says rule means. Here are the relevant meanings of rule from Merriam-Webster Unabridged Dictionary [MWUD].

guide for conduct or action [MWUD ‘rule’ 1a]

one of a set of usually official regulations by which an activity (as a sport) is governed [e.g.,] *the infield fly rule* *the rules of professional basketball* [MWUD ‘rule’ 1f]

A real-world rule always tends to remove a degree of freedom.  If it does not, it’s not a rule. Also, a real-world rule is declarative. It never does anything. It merely shapes behavior or decisions. If you’re using an approach where rules can actually do things (e.g., execute an action, set a flag or variable, call a function, etc.), they’re not business rules. You’re in TechnologyLand, and a procedural one at that. 2. Under Business Jurisdiction    Business rule includes only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization. The important point with respect to external regulation and law is that your organization has a choice about how to interpret the regulations and laws for deployment into its day-to-day business activity – and even whether to follow them at all. So external regulations are not business rules per se. Business rules include only the rules that a business creates in response to external regulation. SBVR explains:

“… legislation and regulations may be imposed on [the company]; external standards and best practices may be adopted. 

These things are not business rules from the company’s perspective, since it does not have the authority to change them. 

The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.  Similarly, it will create business rules to ensure that standards or best practices are implemented as intended.”

3. Practicable Practicable means a rule is sufficiently detailed and precise that a person who knows about it can apply it effectively and consistently in relevant circumstances. In other words, the person will know what behavior is acceptable or not, or how some concept is to be understood. A practicable business rule is one ready to become a deployed business rule – i.e., applied in day-to-day business activity. Whether the guidance is to be deployed to staff or ultimately to machines is immaterial. You should get the same results either way. Business policies are generally not practicable in this sense. Business rules always are. ~~~~~~~~~~~~~~~~~~~~ Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015 Get the book:http://www.brsolutions.com/b_building_business_solutions.php Get the training: Instructor-led, online, interactive training: October 4-6, 2016 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php ©Business Rule Solutions, LLC 2016. wwwBRSolutions.com 

Operational business decisions happen every minute of every day in your organization. You’d like to think that business managers can truly manage them. You’d also like to think that the results of those decisions are comprehensively correct, consistent, traceable, and repeatable (high quality). But are they? Based on real-life evidence I strongly suspect they often are not. Let’s be clear what kind of decision I mean. Say “decision” and many business people immediately think strategic decision (e.g., whether to enter some new market), or tactical decision (e.g., which supplier to use for a year-long special project). Those are not the kinds of decision I’m not talking about. I’m not talking about project decisions either. When IT professionals talk about “decisions” they often mean branch points within the deep systemic logic executed by machines – classic decision points in data processing. I don’t mean that either. Instead, I mean decisions in the day-to-day, minute-to-minute bread-and-butter operations of the business. Some examples of such operational business decisions:

• Whether to give a mortgage to a given applicant.
• What discounts a premium customer will receive on a purchase.
• Which customer gets preference if some product or resource is in short supply.

Your business makes these kinds of decisions hundreds or thousands of times a day – or hour, or minute. These are the kinds of decisions that regulators, auditors, and compliance officers care about. The kind your business partners deem important because they are directly impacted.   Are the decisions high quality? At a major insurance company a thoroughly competent, highly experienced business system analyst recently told us: “When we looked hard at business rules currently implemented in existing systems, we found at least 30% were flatly wrong.” After a moment’s reflection he added, “That’s a very conservative estimate; the actual figure was probably much higher.” The organization was just beginning to recognize the magnitude of the problem. And whose problem is it? The analyst said, “IT told us they couldn’t solve the problem because it was a business issue not a software issue. And they were absolutely right about that.” We might have thought this case an outlier if we hadn’t heard similar estimates from credible sources in many other companies. And we’ve found the same ourselves. Not long ago we were asked to conduct an audit of implemented business rules in one area of business for a major North American bank. The results frankly astounded us. We double- and triple-checked. No error. To conduct the audit first we harvested 518 business rules from the relevant Policies and Procedures Manual, the printed (and on-line) reference source for loan officers, and expressed them in RuleSpeak. How many business rules were implemented correctly in their automated system? We found zero – zero! – fully aligned. Some 447 were actually not implemented at all; the remainder just partially aligned. You wouldn’t think it possible but it gets even worse. We found 261 business rules implemented in their system that did not appear anywhere in the Manual. What sort of way of doing business is that?! Who (or what!) is making the decisions?! To put things in proper context it helps to appreciate the costs associated with maintaining legacy systems not built on business rules. In a recent visit to a very large health care organization, a high-level manager cited the following statistics. They’re staggering. He reported it takes their organization:

• 24 person-years per year to maintain a 30-year old monolithic COBOL legacy system.
• 400 person-days over a 4-month period to make changes to business rules of ‘moderate’ complexity.

The manager admitted sadly, “Truth be told, we work for our legacy systems, not the business.” Beyond these frightening costs the manager also described how a subtle stagnation had crept into the staff’s very way of thinking about their business. “Our business leads are so familiar with the limitations of our legacy systems, they don’t even consider business innovations they know from experience to be difficult for the system to handle. Sometimes I wonder if they can even think through innovation effectively anymore.” With variations it’s a story we hear time and time again. The need for innovation is ever more immediate, but the reality of achieving it ever so distant. Who (or what) is making the decisions is in your organization?! At BRS, we have dedicated ourselves to pioneering innovative techniques for achieving order-of-magnitude improvements in how businesses literally operate themselves. We offer no silver bullets. It’s heavy lifting to put an organization onto a different track with respect to their core knowledge practices. Is it worth it? Absolutely. When we see control over decisions coming back where they belong – into the hands of business managers – the results are always extremely rewarding.

I want to share with you the most intelligent thing I’ve ever heard a manager say on the fly. I’ll give some background first. In one way or another, the situation that evoked what she said may seem quite familiar to you. A few years ago Gladys and I were invited to conduct a one-week facilitated session for a national taxation authority. The objective was to reverse-engineer business rules from a very complex spreadsheet. The manager told us everyone was deathly afraid to touch it because no one understood how it worked. You could never tell what impact making a change would have. Used by many of their systems and embedded in various websites, the spreadsheet was mission-critical. She was finally biting the bullet and assembling some of her best staff to re-engineer it. Everyone knew the spreadsheet by its nickname, Al’s Spreadsheet. It dated to the 1970s when it was implemented under the first generation of automated spreadsheets. Notorious in the organization for more than a generation, it was devilishly convoluted. One of these days I might hold a contest for the world’s most complex spreadsheet. I’ve actually told this story many times around the world, and the audiences’ reaction is inevitably the same – perhaps the same as yours reading this. “No, Al’s Spreadsheet couldn’t possibly be the world’s most complex spreadsheet because my company has the world’s worst!” Around the globe there is extensive core operational business knowledge running businesses day-to-day that is highly inaccessible. Just putting your fingers on it, much less revising it, consumes vast amounts of vital resources. We live in a service provider’s dreamscape. It makes you wonder how brittle (read not agile) many companies’ operations really are today. To return to the story, by mid-week we’d achieved only limited success in deciphering the spreadsheet. Progress was painfully slow. Lapsing momentarily into frustration, an idea popped into my head.  I blurted out, “Hey, why don’t we just go ask Al what this thing really does?!” I assure you my intention was not to provide comic relief. To my chagrin that’s exactly what happened. The whole room erupted into laughter. When the hysteria finally subsided, someone patiently explained to me (barely keeping a straight face) that nobody actually knew who Al was – or indeed, whether Al had actually ever even existed. If so he had long since parted ways with the organization, fading away as all workers sooner or later do into the mists of time. That’s when the manager said the thing that I found so memorable. Looking at no one in particular and staring vaguely into the far distance she said, “No organization should ever depend on absent brains.”. Exactly! To ensure the continuity of operational business knowledge, no organization should ever depend on absent brains – or even on brains that could (and eventually always will) become absent in the future. To say it differently, your operational business knowledge should be encoded explicitly in a form that workers you have never even met yet can understand. Operational business knowledge can be either tacit or explicit (read ‘accessible’). The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’. You make operational business knowledge explicit by expressing it as business rules. So make sure when you lose your Al, he doesn’t walk out the door with the day-to-day knowledge you need to run your business. Encode it as business rules!