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

More on Concept Model vs. Conceptual Data Model

As part of a continuing dialog, I recently asked these questions: What does the term “conceptual data model” really mean? Is it the best term for what is meant? To me, it sounds like “conceptual data model” might be about “conceptual data”. Surely not(?). What exactly then? (Some of my thoughts on the matter: http://goo.gl/8GX5o.) A practitioner responded with the following 3-part challenge below. With each challenge is my response. Challenge part 1: Which of the following, if any, would you see in a conceptual data model: primary keys, foreign keys, abstract keys, constraints, nulls, non-nulls, 1:1s, 1:Ms, optionality, cardinality, etc.? My response: Wrong approach. Bad definition practice one three counts. 1. Things should be defined in terms of their essence, what they are, not in terms of what are allowed or disallowed. 2. Suppose none of the above were allowed. You’d end up simply with a description of what the thing is not, not what it is. Since you can’t possibly list everything it’s not, the definition is woefully incomplete. 3. The list attempts to describe something in terms of an implementation or design of the thing, not in the thing’s own terms. That’s simply backwards. Challenge part 2: So let’s turn the question around. What would be the minimum types of objects you need to explore a concept, produce a mini model, and convey knowledge about the concept and its relationship to other concepts? My response: To develop a concept you need: 1. A concise definition for the concept, which distinguishes the concept from all other concepts and conveys its essence to the business. 2. A business-friendly signifier (term) for the concept that has only that one meaning (or is properly disambiguated by context). 3. A set of facts that indicates the place of the concept within a structure of other concepts (e.g., classification, categorization). 4. A set of verbs that permits the business to communicate unambiguously about how the concept relates to other concepts (e.g., customer places order). 5. A set of structural rules for the concept and its relations to other concepts, as needed. Why the verbs? Because you can’t write sentences without verbs and business rules can always be written in sentences. ‘Requirements’ should be too(!). Challenge part 3: When you are finished do you call that a ‘conceptual data model’? My response: You notice that I didn’t say anything, directly or indirectly, about “data”. That term is irrelevant. Taking away “data” leaves “conceptual model”. But that term suggests what the model is made of (concepts), not what it is about. Of course the kind of model we’re talking about is made up of concepts – it’s certainly not made of physical material (e.g., wood, plaster, etc.) or through use of math (some formula). That leaves “concept model” (also sometimes called “fact model”). Bingo. Is there a standard for this kind of model? Indeed there is: SBVR (Semantics of Business Vocabulary and Business Rules). See the SBVR Insider section on www.BRCommunity.com for more information.

Continue Reading 2 Comments

How Business Process Models and Business Rules Relate … What State Are You In?

Business Process Models: A completed transform often achieves a business milestone and a new state for some operational business thing(s). Example: claimant notified. Fact Models: In fact models (structured business vocabularies) such states are represented by fact types, for example, claimant is notified (or claimant has been notified if you prefer). A fact model literally represents what things the business can know (remember) about completed transforms and other operational business events. Business Rules: Business rules indicate which states are allowed or required. They should not reference business processes or business tasks by name, just the states they try to achieve. For example, a business rule might be: A claimant may be notified that a claim has been denied only if the specific reason(s) for denial have been determined.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  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 1 Comment

Why So Much Ambiguity and Miscommunication in Requirements? … Something We’ve Learned from Business Rules

Let me share something we’ve learned from our work on business rules. The world’s leading cause of ambiguity in expressing business rules is missing verbs. Stay with me now. Consider this sample business rule: An order must not be shipped if the outstanding balance exceeds credit authorization. As a first-cut statement, that’s perhaps not bad. The more you read it, however, the more ambiguity you’ll find. Clearly, important ideas are hidden or missing. For example: The outstanding balance of what? …order? …customer? …account? …shipment? The credit authorization of what? …order? …customer? …account? …shipment? The hidden or missing ideas are all verb-related. To eliminate the ambiguity, the relevant verb concepts (called fact types in fact modeling) – must be discerned; then the original business rule restated. Suppose the relevant verb concepts can be worded: customer places order customer has credit authorization customer holds account account has outstanding balance Using RuleSpeak (www.RuleSpeak.com – free) the business rule can now be restated: An order must not be shipped if the outstanding balance of the account held by the customer that placed the order exceeds the credit authorization of the customer. Although the resulting statement is a bit wordier, it is far less likely to be misunderstood, misapplied, or mis-implemented. It is now enterprise-robust. The key insight: Wordings for relevant verb concepts should always appear explicitly in expression of business rules. For that matter, wordings should appear explicitly in any form of business communication you want to be understood correctly – including IT requirements. Note: You probably noticed use of the preposition of in the revised business rule. Stand-in prepositions for verb concepts are considered lazyman’s verbs. (Literally, you can’t make complete sentences with only prepositions!) Yes, you can use a preposition to stand in for a full wording, but do so with caution. As a rule of thumb, prepositions are safe only for two cases: (1) properties – e.g., credit authorization and outstanding balance as above. (2) role names – e.g., owner as in the earlier example, owner of a vehicle. ~~~~~~~~~~~~~~  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

Typical Dialog When You Don’t Know the Concepts or Vocabulary … Can Anyone Explain This Soccer Rule to Me??

I’m an avid fan of soccer … and, of course, business rules. I recently found the following business rule via a Twitter search and just had to ask what it meant. FootballRascal – Can’t sign a player and then loan him out to another Premier League club in same window, business rule as fee charged Ronald_G_Ross – For U.S. audience, but avid football fans, what is motivation for not-in-same-window business rule? MeJonWhite – Personally, I have no idea, can’t see the logic. He could go on loan internationally, but not domestically. Ronald_G_Ross – Just one more ques. re not-in-same-window business rule. Uh, what’s a window? Period of time? Season? MeJonWhite – Summer window is July 1st – Sept 1st, it’s just the off season registration period. January is the Jan window. I am still in the dark, but I didn’t want to bug the kind folks any more. What I need is a blueprint to the concepts, a fact model, to bootstrap my way into a meaningful conversation quickly.

Continue Reading

Requirements and Business Rules … All Just a Matter of Semantics (Really)

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

Continue Reading

Something Important All Business Analysts Owe to Business People … Probably Not Something You’d Expect?

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.  

Continue Reading

Just Organizational or Application Silos? … Worse, You Have Semantic Silos

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    

Continue Reading

Moving the Goalposts for Data Modeling … Deliberately. Hey Guys, We’re in a Knowledge Economy.

Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? No. That’s distressing.  Is there an alternative that does? Yes, fact modeling, which is to say structured business vocabularies (concept systems). The core concepts (fact model) of an operational business area are very, very stable. I have outstanding proof (short case study).  See: http://www.brcommunity.com/b594.php. Definitely worth a quick read. I recently made these statements in a data modeling forum, and a practitioner came back with this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, IMO this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Missed the point. Concept anaysis is brain work. You’ll never generate a ‘complete and correct data model’ … you must create it … ith business people and SMEs. The problem with data modeling as practiced today is that there is a large gap between the business view of things and the data model. It gives business-side people a ready excuse to drop out. And its an art rather than a science. You really have no justification building a system until you have a concept blueprint. Currrent data models evolved bottom up, from database design. (I know, I watched it happen. I was editor of the Data Base Newsletter, 1977-1999.) It’s time to approach the problem top-down. There are natural ways to build concept systems. The standard for the new approach is SBVR. (For more, see BRCommunity’s “SBVR Insider”), which in turn is based on ISO 1087 and 704.  We (all of us) need to start practicing like we’re living in a knowledge economy … which in fact we actually already are.

Continue Reading