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

What business problems do business rules address?  My take: 1. Ad hoc rules: Most businesses have no organized approach for specifying their business rules. As a result, business workers often make up the rules as they go along. This leads to confusion, contradiction, and operational inefficiency. After-the-fact resolution of these problems wastes time and resources and causes frustration for customers and staff alike.

Business rule solution: Business rules ensure consistency in customer experience and provably on-target results for demonstrating compliance.

2. Miscommunication: Misunderstanding of key business concepts inevitably results in miscommunication. Does preferred customer discount mean the same across all departments? If not, what are the differences? What rules apply? Do these rules differ for different areas of the business? Are the rules consistent?

Business rule solution: A structured business vocabulary provides a foundation on which rules can be directly based.

3. Inaccessible rules: Finding out what rules apply to a given business situation often involves an open-ended search through multiple sources. It is not uncommon in the end to resort to the application source code. Pursuing rules in this fashion is time-consuming, inefficient, and inaccurate.

Business rule solution: An organized approach for managing business rules yields order-of-magnitude improvements in productivity and business agility.

4. Massive differentiation: Many businesses seek to support highly individualized relationships with growing numbers of customers and other partners across multiple jurisdictions for ever more complex products or services. How can businesses massively differentiate and, at the very same time, conduct each business transaction faster, more accurately, and at ever lower costs?

Business rule solution: Business rules support highly scalable customization and personalization and provide a structural solution for managing complexity.

5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the digital age, people expect almost instantaneous implementation of changes. How can line workers consumed with day-to-day activities ever hope to keep up?

Business rule solution: Real-time delivery of business rules to knowledge workers creates a seamless, never-ending, self-training environment.

6. Knowledge walking out the door: By and large, baby boomers created much of the basic operational business capacity and operational systems we see in place in larger organizations today. Much of the related knowledge still sits in their heads – and nowhere else. Now they are retiring. On a smaller scale, people with vital operational knowledge walk out the door almost every day.

Business rule solution: A systematic way of capturing, documenting and managing business rules enables pragmatic knowledge retention.

~~~~~~~~~~

Read to the end for an interesting note about this post. 1. Ad hoc rules: Most businesses have no logical approach for defining their business rules. As a result, business workers often make up the rules as they go along. This leads to confusion, contradiction, and operational inefficiency. After-the-fact resolution of these problems wastes time and resources and causes frustration for customers and staff alike. The larger the organization, the bigger the problem. Also, since many business rules involve monetary transactions (for example, whether a customer should be given a discount, and if so, how much), this problem can also directly affect the bottom line.

Business rule solution: A structured approach helps you think through rules before the fact.

2. Miscommunication: Misunderstanding of key business concepts inevitably results in miscommunication. Does preferred customer discount mean the same across all departments? If not, what are the differences? What rules apply? Do these rules differ for different areas of the business? Are the rules consistent?

Business rule solution: A clear set of concepts provides a foundation on which rules can be directly based.

3. Inaccessible rules: Finding out what rules apply to a given business situation often involves an open-ended search through multiple sources. It is not uncommon in the end to resort to the application source code. Pursuing rules in this fashion is time-consuming, inefficient, and inaccurate.

Business rule solution: A way to manage business rules provides direct accessibility.

4. Massive differentiation: Many businesses seek to support highly individualized relationships with growing numbers of customers and other partners for ever more complex products or services. How can businesses massively differentiate between business parties and, at the very same time, conduct each business transaction faster, more accurately, and at ever lower costs?

Business rule solution: A rule-based approach featuring rapid development and deployment of rules supports differentiation.

5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the Internet age, people expect almost instantaneous implementation of changes. How can line workers consumed with day-to-day activities ever hope to keep up?

Business rule solution: Real-time delivery of business logic to knowledge workers as errors actually occur creates a seamless, never-ending, self-training environment.

6. Knowledge walking out the door: By and large, baby boomers created much of the operational business capacity and operational systems we see in place in larger organizations today. Much of the related knowledge still sits in their heads—and nowhere else. What will happen when they retire? On a smaller scale, people with vital operational knowledge walk out the door almost every day.

Business rule solution: A systematic way of capturing, documenting, and retaining the business rules prevents the loss of knowledge when people leave.

~~~~~~~~~~ Excerpted from Principles of the Business Rule Approach, by Ronald G. Ross, AddisonWesley, 2003, pp. xx-xxii. Note: This list of benefits was written a dozen years ago. It seems the more things change, the more they stay the same for business rules. About the only thing I would alter today is to add the following buzzwords for the respective benefits.

1. Consistency & Complexity 

3. Business Agility & Compliance

4. Customization & Personalization

6. Knowledge Retention

 www.BRSolutions.com

It’s become more and more apparent that software vendors are misleading people (badly) about the true meaning of ‘business rule’. Time to set the record straight. Here is an authoritative 3-part explanation. Take a moment and reacquaint yourself. As a business-oriented professional you’ll be glad you did!

Reference Sources
[MWUD]	Merriam-Webster Unabridged Dictionary (Version 2.5).  [2000].  Merriam-Webster Inc.
[SBVR]	Semantics of Business Vocabulary and Business Rules (SBVR) (Version 1.0).  [January 2008].  Object Management Group.

  1. Rule When we say rule we always mean real-world rule. Here’s the dictionary meaning of “rule”. That’s what we mean.

[MWUD ‘rule’ 1a]:  guide for conduct or action; [MWUD ‘rule’ 1f]:  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 ‘criteria’  2]:  a standard on which a decision or judgment may be based

A real-world rule always tends to remove some degree of freedom.  If it does not, it’s not a rule.  2. Under Business Jurisdiction    When we say business rule we mean only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization.  The 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: 

“The laws of physics may be relevant to a company … ; legislation and regulations may be imposed on it; 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. Business Rule

[SBVR]:  a rule that is under business jurisdiction

A business rule is a criterion used to:

• guide day-to-day business activity
• shape operational business judgments, or
• make operational business decisions. 

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.  It almost always works.  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 standardization team, Don Baisley, puts it another way:  “Business people don’t set variables and they don’t call functions.” Some people think of business rules as loosely formed, very general requirements.  Wrong.  Business rules have definite form, and are very specific.  Each should give well-formed, practicable guidance Here are a few simple examples expressed in RuleSpeak:  

A customer that has ordered a product must have an assigned agent. 

The sales tax for a purchase must be 6.25% if the purchase is made in Texas. 

A customer may be considered preferred only if the customer has placed more than $10,000 worth of orders during the most recent calendar year.

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. 

More observations about business rules:

• In SBVR a business rule can be either a behavioral rule or a definitional 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.
• Expression of business rules should always be declarative, rather than procedural.
• A business rule statement should use terms and wordings about operational business things that should be based on a structured business vocabulary (concept model).
• Your company’s business rules need to be managed and single-sourced, so we strongly recommend rulebook management.

Business rules are not about mimicking intelligent behavior, they are about running a business.  Mimicking intelligent behavior in a generalized way is far harder (an order of magnitude or more) than capturing the business rules of an organization.  Unfortunately, expert systems have generally focused on the former problem, causing considerable confusion among business practitioners.  ~~~~~~~~~~~~~~~~~~~~  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

A practitioner recently commented: “Everyone has their biased view of what a data model is. Data modeling is art – not science. Give 6 data modelers one set of requirements and you’ll get 7 solutions all distinctively different.” My response: To me that’s a huge problem. No, ‘data’ modeling is not a science, but nor should it be an art. Actually, it should be engineering. Engineered solutions have to stand up to rigorous tests. But we lack that in ‘data’ modeling. Why? Because ‘data’ modeling is divorced from its initial business context, which is operational business communication, including business rules. You need nouns and verbs for that, and those nouns and verbs should stand for well-structured concepts. Give me a model of well-structured concepts that has been ‘proven’ by verbalizing business rules and other formal business communications and I guarantee I can come up with the best data model. I’m talking of course about concept models (sometimes called fact models).

It almost goes without saying (but I’ll say it anyway) that you must know exactly what the words mean in all parts of your business requirements. In running a complex business (and what business isn’t complex these days?!), the meaning of the words can simply never be taken as a ‘given’. Some IT professionals believe that if they can model the behavior of a business capability (or more likely, some information system to support it), structural components of the know-how will somehow fall into place. That’s naïve and simply wrong. Business can no longer afford such thinking. A single, unified business vocabulary (fact model) is a prerequisite for creating a scalable, multi-use body of business rules – not to mention good business requirements. It’s what you need to express what you know precisely, consistently, and without ambiguity. Certainly no form of business rule expression or representation, including decision tables, is viable or complete if not based on one. And I pretty certain that’s true for most other forms of business communication about day-to-day business activity too. What am I missing something here?  ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

If you want to hear state-of-the-art machines (bots) talk to each other, see: http://goo.gl/LEIMI Funny! Rude and petty … just like humans sometimes. I don’t think we’re quite there on Star-Trek-style communication with machines(!). If you want to see a suitable set of guidelines for writing unambiguous business rules that machines should be able to understand, see www.RuleSpeak.com (free). RuleSpeak was one of the three reference notations used in creating SBVR, the OMG standard Semantics of Business Vocabularies and Business Rules. (SBVR doesn’t standardize notation.) Don’t try to read the SBVR standard – it’s for logicians, linguists and software engineers. For insight into what SBVR is about, see the SBVR Insider section on www.BRCommunity.com. SBVR itself is a structured vocabulary – essentially a concept system. Clause 11 provides a structured vocabulary for creating structured vocabularies. Clause 12 provides vocabulary for business rules. ‘Structured’ in this context means it includes both noun concepts (nothing unusual about that) and verb concepts (highly unusual). You need verbs to write sentences (propositions). Try writing a 100 business rules without standard verbs. Well, you can do it, but what you’ll get is spaghetti logic and hopeless, bot-like(?) communication.

One of the first rules of business analysis should be never waste business people’s time. One of the fastest ways to waste their time is not knowing what they are talking about … literally … and do nothing about it. So you end up just wasting their time over and over again. Unacceptable. Is there a way to avoid it? Yes, by taking the time to understand exactly what concepts the business people mean when they use the words they use.  I believe business vocabulary should be job one for Business Analysts. If you don’t know (and can’t agree about) what the concepts mean, then (excuse me here for being blunt) you simply don’t know what you’re talking about. (And sometimes, unfortunately, neither do the business people … which is something important BAs should find out as early as possible.) So structured business vocabularies (fact models) are a critical business analysis tool. How else is there to analyze and communicate about complex know-how in a process-independent way?! Looking at the issue the other way around, you can make yourself look really smart about a complex area in a relatively short time by having and following a blueprint. We’ve had that experience many, many times in a wide variety of industries and problem areas. (Try jumping between insurance, pharmaceuticals, electricity markets, eCommerce, race care equipment, credit card fraud, trucking, taxation, healthcare, banking, mortgages, pension administration, ship inspections, and more! We do.) There’s no magic to it – like contractors for the construction of buildings, you must have or create structural blueprints. For operational business know-how, that means bringing an architect’s view to structure the concept system of the problem space …  just a fancy way of saying develop a well-structured business vocabulary. Then a whole lot of things will fall right into place for you. P.S. By the way, I’m not talking about any form of data modeling here. Also, there’s no real need to use the ‘S’ word (semantics) for it.  

Difficulties in communicating within organizations are by no means limited to communications among business workers, Business Analysts, and IT professionals. In many organizations, business workers from different areas or departments often have trouble communicating, even with each other. The business workers seem to live in what we might call semantic silos (reinforced by legacy systems).  A well-managed, well-structured business vocabulary (fact model) should be a central fixture of business operations. We believe it should be as accessible and as interactive as (say) spellcheck in Microsoft Word. Accessible business vocabulary should be a basic element in your plan for rulebook management, requirements development, and managing know-how.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php    

In the new age of social media (and the mature age of email) you might be led to believe that good writing skills are no longer a matter of real concern. At the risk of sounding old-fashioned, I beg to differ … strongly. In fact, I would argue that good writing skills are one of the top 3 or 4 skills Business Analysts should have, right alongside analytical, abstraction, and people skills. Put simply, poor writing skills are one of the top reasons for ambiguity and miscommunication in written requirements, a major concern everywhere I go. A commenter on one of the forums asked “The last time you hired an analysis, did you test their ability to take a concept and specify it in a way that is unambiguous? That’s a special talent that may be overlooked at the time of hiring sometimes.” Just sometimes?!? I don’t necessarily mean English majors. I mean people who can write clearly about structured or technical subjects … and who can be consistent about the meaning of the words they use. Why aren’t universities producing more of that kind of person? What aren’t companies more careful about cultivating that kind of person? From my work on standards (SBVR), I can tell you that writing skills will become more and more important as time goes by … whereas programming skills … well, we pretty much know where those jobs are headed (if not there already). don’t we?