Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Getting at the Rest of the Communication Iceberg

communication[1]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

Angela WickMany 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

Continue Reading

Business Rules – Sure You Really Understand Them?

communication-2The 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

Continue Reading

The Conversation of Three Baseball Umpires and How it Relates to Modeling

OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules)[1] last month – comprehensively reorganized for approachability, but not changed.[2] Some thoughts … ~~~~~~~~~~~~~~~~~ Ever hear the conversation that three baseball umpires once had? If you don’t live in a baseball country, it’s an archetypical story, so you’ve probably heard some variant. By the way, in American English a ‘pitch’ is a throw of the ball for the batter to try to hit, not the field of play. Meanings matter!
    • The first umpire says, “Some pitches are balls and some are strikes. I call them as they are.”
    • The second umpire says, “Some pitches are balls and some are strikes. I call them as I see them.”
    • The third umpire says, “Some pitches are balls and some are strikes. But they aren’t nothing till I call them.”
Most modeling techniques primarily focus on modeling the real world as it ‘really is’. They essentially take a first-umpire point of view or maybe second-umpire. I come from that tradition too. My 1987 book Entity Modeling was about doing that … modeling the real world as it ‘really is’. Pretty much all professionals with some IT background come from that world. Working with business people and business rules for the last 25 years, however, has taught me that business is really more of a third-umpire world. Think of laws, regulations, statutes, contracts, agreements, terms & conditions, policies, deals, bids, deeds of sale, warranties, prospectuses, citations, complaints, receipts, notices … and business policies. Even businesses that deal with tangible stuff (e.g., railroads, electrical transmission, infectious diseases, etc.) live in a third-umpire world. And many of the most automated organizations around have no tangible product at all (e.g., finance, insurance, government, etc.). They really exist only in a world of words (between people). It’s humbling to realize that the way the business world ‘really is’ is more directly the product of words exchanged by the players in a conversation game than anything IT professionals can model directly. But why would it be otherwise? Do IT professionals really know better than business owners, business managers, lawyers, engineers, subject matter experts, etc.? Really?! SBVR, in contrast to almost all other standards, doesn’t try to model the way the real world ‘really is’. Instead, its focus is on modeling what is said about the way the world really is. It’s fundamentally a third-umpire standard. You simply have to understand what the words mean – and that’s a human-communication issue. Yes, the SBVR world view is a game changer. It also happens to align closer with some of the most exciting new work in computerization today including cognitive computing and machine learning. I stand accused by peers in the standardization community of wanting to go beyond the ‘capture, exchange and production of information’. Sure, I can live with that. ~~~~~~~~~~ www.BRSolutions.com


[1]For more information on SBVR refer to the SBVR Insider section on www.BRCommunity.com.

Continue Reading

Fundamental Challenges Facing Your Business: #2 – Business Communication

Do people in your company always mean the same thing when they use the same terms? Almost certainly not, right?! So ask yourself, how good are your business communications and requirements likely to be if people don’t mean the same things by the terms they use? And how good is your automation likely to be? Gurus talk about application or functional silos in organizations. I believe the problem is even more basic than that – organizations today essentially have semantic silos. Look under the covers of any broken process or poor set of requirements and you inevitably find poor communication practices. These days you don’t have the time not to define, structure and manage your business vocabulary. These days a concept model[1] is no luxury. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1] Ronald G. Ross, “What Is a Concept Model?” Business Rules Journal, Vol. 15, No. 10 (Oct. 2014), URL:  http://www.BRCommunity.com/a2014/b779.html

Continue Reading

What is a Concept Model?

A concept model organizes the business vocabulary needed to communicate consistently and thoroughly about the know-how of a problem domain. A concept model starts with a glossary of business terms and definitions. It puts a very high premium on high-quality, design-independent definitions, free of data or implementation biases. It also emphasizes rich vocabulary. A concept model is always about identifying the correct choice of terms to use in communications, including statements of business rules and requirements, especially where high precision and subtle distinctions need to be made. The core concepts of a business problem domain are typically quite stable over time.[1] Concept models are can be especially effective where:
    • The organization seeks to organize, retain, build on, manage, and communicate core knowledge or know-how.
    • The project or initiative needs to capture 100s or 1,000s of business rules.
    • There significant push-back from business stakeholders about the perceived technical nature of data models, class diagrams, or data element nomenclature and definition.
    • Outside-the-box solutions are sought when reengineering business processes or other aspects of business capability.
    • The organization faces regulatory or compliance challenges.
Definition of Concept Model

a model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently

The standard for concept models is the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR).[2] Concept Model vs. Data Model A concept model differs from a data model in important ways. The goal of a concept model is to support the expression of natural-language statements, and supply their semantics – not unify, codify (and sometimes simplify) data. Therefore the vocabulary included in a concept model is far richer, as suits knowledge-intensive problem domains. In short, concept models are concept-centric; data models are thing-entity-or-class-centric. Data models can usually be rather easily derived from concept models; the reverse is much harder (or impossible). Like data models, concept models are often rendered graphically, but free of such distractions to business stakeholders as cardinalities. The Components of Concept Models[3] Noun Concepts. The most basic concepts in a concept model are the noun concepts of the problem domain, which are simply ‘givens’ for the problem space.
    • For BACCM these basic noun concepts are: need, stakeholder, value, change, context, and solution.
    • In finance, basic noun concepts might include financial institution, real-estate property, party, mortgage application, lien, asset, loan, etc.
Verb Concepts. Verb concepts provide basic structural connections between noun concepts. These verb concepts are given standard wordings, so they can be referenced unambiguously.
    • In BACCM some basic wordings for verb concepts include: Value is measured relative to Context, Change is made to implement Solution, Stakeholder has Need.
    • In a financial business, some basic wordings for verb concepts include: Lien is held against Real Estate Property, Party requests Loan, Asset is included in Mortgage Application.
Note that these wordings are not sentences per se; they are the building blocks of sentences (such as business rule statements). Sometimes verb concepts are derived, inferred or computed by definitional rules. This is how new knowledge or information is built up from more basic facts. Other Connections. Since concept models must support rich meaning (semantics), other types of standard connections are used besides verb concepts. These include but are not limited to:
    • Categorizations – e.g., Person and Organization are two categories of Party.
    • Classifications – e.g., ‘Toronto Dominion Bank’ is an instance of Financial Institution.
    • Partitive (Whole-Part) Connections – e.g., Dwelling and Land are two Parts of a Real Estate Property.
    • Roles – e.g., Applicant is the role that Party plays in the verb concept Party requests Loan.
Strengths A concept model:
    • Provides a business-friendly way to communicate with stakeholders about precise meanings and subtle distinctions.
    • Is independent of data design biases and the often limited business vocabulary coverage of data models.
    • Proves highly useful for white-collar, knowledge-rich, decision-laden business processes.
    • Helps ensure that large numbers of business rules and complex decision tables are free of ambiguity and fit together cohesively.
Limitations A concept model:
    • May set expectations too high about how much integration based on business semantics can be achieved on relatively short notice.
    • Requires a specialized skill set based on the ability to think abstractly and non-procedurally about know-how and knowledge.
    • Involves a knowledge-and-rule focus that may be foreign to stakeholders.
    • Requires tooling to actively support real-time use of standard business terminology in writing business rules, requirements, and other forms on business communication.
For more information about Concept Models, refer to Business Rule Concepts 4th ed, by Ronald G. Ross, 2013, Part 2. www.BRSolutions.com


[1] Ronald G. Ross, “How Long Will Your Fact Model Last? — The Power of Structured Business Vocabularies,” Business Rules Journal, Vol. 12, No. 5 (May 2011), URL:  http://www.BRCommunity.com/a2011/b594.html
[2] This discussion is consistent with that standard, but explains concept models from a business point of view. See the SBVR Insider section of www.BRCommunity.com for more information about SBVR.
[3] The first set of examples in each of the following two subsections is from the Business Analysis Core Concepts Model (BACCM), a part of the IIBA’s Business Analysis Body of Knowledge (BABOK), version 3.

Continue Reading

A Quick 5-Item List of What Are Not Business Rules!

1.       Assigning values to variables. 2.       Asserting mandatory GUI fields. 3.       Specifying which data can be viewed by which users. 4.       Expressing which documents are to be routed to which queues. 5.       Orchestrating tasks assignments in an execution environment. Depending on your implementation preferences, specifications for such things might (or might not) appear rule-ish. But … business rules are what you need to run the business, not what you use to set-up systems (even if rule-ish). Such specifications might be representations of business rules, their surrogates, but they are not business rules per se. Business rules are communicated of, by and for people. Big difference! P.S. For examples see RuleSpeak 3.0 (free download): http://www.brsolutions.com/b_ipspeakprimers.php

Continue Reading

Why can’t standards use the real-world meaning of ‘decision’?

A person close to the DMN (Decision Model Notation) standard recently wrote about its definition of “decision”: “This means a technical rather than business-person definition of ‘decision’, as the businessperson is not the target audience for the specification (metamodel) but of the results of the specification (models).” My Response Well, that’s a shame. Many people will be looking toward the DMN for a business vocabulary they can use in communicating with business people. So the communication gap between IT and business is not being closed in the area. My personal opinion is:
  • Computers have become so powerful these days that they should be speaking *our* language (in structured, carefully defined form), not the other way around.
  • Standards (and standards organizations) that fail to move the ball forward in that regard are failing its audience in the larger sense, no matter how good the standard for its chosen area. (And I do hope DMN is good in that latter sense.)

Continue Reading

Feeling Feisty Today. Any of These Points a Burr Under Your Personal Saddle?

1. No government or regulatory or similar body should issue operational policy unless the vocabulary is fully and precisely defined (in people language, as possible under SBVR) and the business rules are spelled out in practicable form (as in RuleSpeak). Try to imagine the amount of time and energy wasted because everybody has to do their own interpretation. Ridiculous in a knowledge economy. (Same basically true for legal contracts and agreements, etc.) There ought to already be an eMarket in off-the-shelf, industry-specific know-how models (vocabulary and rules). It will happen … sooner or later. 2. Is the DMN standard going to solve all your problems? No, of course not. It’s an important step in the revival and reinvigoration of decision tables, but you can already see all-too-familiar patterns of hype and misguided thinking. Yes, I would like the standard … needed badly (if it turns out to be good — an open question, but I sure hope so). 3. The OMG mission focuses on machine interoperability. When people need so badly to speak to other people precisely, and in a day and age when machines have become so powerful that they can begin to speak limited people language, isn’t perhaps the OMG mission a bit outdated or incomplete?

Continue Reading 1 Comment

Externalizing Semantics from Business Processes … Why the Procedural Approach is a Flawed Paradigm for the Knowledge Economy

For IT professionals the state of processes has always reigned supreme. In procedural approaches the internal state of a process is represented by some token. Most computer languages use that approach (the token generally falls through lines of code sequentially). Many current approaches to business process modeling do as well, at least implicitly. But why should business people care about the internal state of any process? For example, if a business person asks How far along are we in processing this order? the person is really asking: Has the order been credit-checked? Has it been filled? Has it been shipped? (etc.). In business operations it’s the state of each operational business thing that matters. True business agility cannot be achieved so long as business processes are perceived as managing state internally (privately). That’s a fundamentally flawed paradigm for business operation today. Instead, business processes must externalize semantics so business people can understand and manage the state of operational business things directly. Externalizing semantics is accomplished by means of SBVR-style structured business vocabularies (concept models) and single-sourced business rules. ~~~~~~~~~~~~~~~~~~~~~~~~~~ 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  

Continue Reading

‘Concept Model’ vs. ‘Fact Model’ … Where in the World are the Instances?

In a dramatic development, the new release of SBVR (1.1) has replaced the term “fact type” with “verb concept”, and the term “fact model” with “concept model”, for all business-facing use.[1] Why the problems with “fact type” and “fact model”? Let me see if I can explain. First some background: Since its inception in the early 2000s, the OMG standard SBVR[2] has focused on “fact type” and “fact model”. That’s no accident – the underpinning of SBVR in formal logic is based on the work of Terry Halpin, who in turn based his work on Sjir Nijssen’s. Sjir Nijssen was using the terms for database models as early as the 1970s. By the way, both bodies of work are world-class. Now to the problems: If someone gives you an example or instance of a customer, where is that customer? In a database? No, of course not. The customer is out there in the real world. Similarly, suppose someone gives you an example of some customer visiting some retail store. Where did that visitation take place? In a database? Again, of course not. The visitation also happened out there in the real world. The bottom line is that when most people talk about things, those things exist or happen in the real world. But not if those people happen to be logicians or database gurus. Then instances of the things they talk about formally are likely to be in some database – i.e., data. The formal terminology is usually more refined – e.g., “population of facts” – but it is what it is. And it’s not the same stuff as is in the real world. Where does that lead you? If you’re a logician or database guru, you need to classify all the facts – hence “fact type”. You also need a model of all the fact types – hence “fact model”. If you’re not a logician or database guru, however, you’re clearly going to need something else. What exactly fits the bill? Here’s a clue: Databases hold data; those data represents facts. Those facts have meaning, but to understand that meaning you need to understand the concepts that are used. In business basically all we have is words to refer to things in the real world. What do those words communicate? The words communicate what you mean; that is, the ideas or concepts you have in your head when you say or write them. So what we need – or more precisely, what we need to share – is a model of what you mean by those words. In short we need a concept model. More on SBVR The world might or might not need another information modeling standard. The point is debatable. The soul of SBVR, however, lies in meaning[3] and language – what concepts we mean by the words we use in business communications (especially but not exclusively business rules). In the standards landscape that focus sets SBVR apart. What kind of language concepts do we need in organizing and expressing meaning? The answer is really quite simple (once you see it) – you need nouns and verbs. Those nouns and verbs stand for concepts – noun concepts and verb concepts, respectively. For example:
  • The noun “customer” might stand for what is meant by the definition “one that purchases some commodity or service”. 
  • The verb “visits” (as in “some customer visits a retail outlet”) might stand for what is meant by the definition “customer physically appears at retail outlet”
There is no other practical way to communicate business concepts and establish relationships among them. You need nouns and verbs to write sentences and convey meaning – it’s as simple as that. Once you look at the problem this way, forcing “fact model” and “fact type” on business people is unnatural and unnecessary. It commits a cardinal sin in business analysis – using unnatural terms for natural business concepts. The most natural terms for the concepts meant by SBVR are “concept model” and “verb concept”. About Business Rules For my part, I didn’t arrive at this understanding through the path above – or for that matter any other path you are likely to guess. The need for the shift dawned on me when I saw business rules being included in populations of facts. Hold on, how could a rule be treated as a fact?! Well, exactly! To a logician or database guru, however, treating a rule as a fact makes perfect sense. Formal logic is all about propositions. A business rule is a proposition taken to be true – in other words, a fact. So of course business rules belong in populations of facts and therefore in fact models. It couldn’t be any other way. And I agree. The only problem is that in SBVR we want to talk directly about the real world. The Bottom Line So a concept model in SBVR is a ‘map’ of noun concepts and their relationships based largely on verb concepts.[4] Actually, it’s more than that. By ‘map’ I don’t mean either of the following on its own:
  • A set of concepts and definitions loosely related (e.g., a glossary) – although definitions are clearly essential. 
  • Some diagram(s) – although often quite useful.
Rather, I mean a non-redundant, integrated, anomaly-free structure of concepts based on interlocking definitions – a blueprint of meanings. How is an SBVR-style concept model different from (and better than) a traditional “conceptual data model” (or entity-relationship diagram)? Instead of mere lines to represent relationships between noun concepts, with an SBVR-style concept model we have verbs. These verbs reveal the intended meanings of the relationships. With verbs I can verbalize – literally communicate (and demonstrate) what is meant. No more hidden meaning!


[1] But not in the underpinning of SBVR in formal logic.
[2] Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section of www.BRCommunity.com for discussion. SBVR 1.0 was released by OMG in December, 2007.
[3] I refuse to use the “S” word here. There’s really no need for it. Few business people I’ve ever met say “semantics” in the course of normal business conversation, except perhaps in the sense of “Oh, that’s just a matter of semantics.” (which indeed, to be fair, it usually is).
[4] I say “largely” because certain important structural elements of concept models, including classifications and categorizations, are not based on verb concepts.

Continue Reading 3 Comments