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

Posts Tagged ‘concept analysis’

Legality and Business Rules

How does legality work with business rules? To say that differently how should an intelligent tool work so as to help you establish the business regimen you want to follow where legality is involved? Consider the example of Same-Sex Marriage. Let’s suppose you want to make it illegal. SBVR[1] does not have an innate concept/approach for “legality” in the sense of MWUD[2] 1: attachment to or observance of law. So if you wanted “is legal” in the most direct sense, you must define a unary verb concept for the concept Same-Sex Marriage. In a looser sense, if you are in an organization (business) with the standing to define business rules, you could do several things, as follows. (I’ll make up a bit of vocabulary here.) 1. Specify a behavioral rule A behavioral rule is one that can be potentially violated by people or organizations. The relevant rule might be expressed as follows:

The people united in a marriage must not be of the same gender.

Then you would decide how strictly you want to enforce the rule. Options range from strictly enforced to guideline. The rule would be active when a relevant state of affairs arose (i.e., specific people get married). 2. Define several definitional rules A definitional rule is one that cannot be violated; it exists to ensure the consistency of the concept system you chose to follow. Relevant definitional rules might be expressed as follows:
    • The people united in a marriage are not to be of the same gender.
    • The people united in a same-sex marriage are to be of the same gender.
See the conflict? Your friendly intelligent tool would (immediately) disallow one or the other specification. The rules are clearly in conflict; the logical conflict would simply not be allowed to stand. 3. Define the relevant definitions
    • Marriage: the uniting of people of different genders in wedlock
    • Same-Sex Marriage:  the uniting of people of the same gender in wedlock
Again, your friendly intelligent tool would (immediately) disallow one or the other specifications. The definitions are clearly in conflict; the logical conflict would simply not be allowed to stand. Actually, under the covers, approaches 2 and 3 work exactly the same way In SBVR. SBVR recognized that some people prefer to do things via rules, some with definitions, and if truth be told, most times you will do some of both. ~~~~~~~~~ www.BRSolutions.com  


[1]Semantics of Business Vocabulary and Business Rules
[2]Merriam-Webster Unabridged Dictionary
 

Continue Reading

Controversial Concepts: How to Tackle Defining and Naming Them

Guest Post by Markus Schacher We should first agree on the semantics of underlying concepts and only then start to think about the best terms for those concepts. One particular technique I often apply in such cases is the following: 1.    Name controversial concepts with proxy names such as “Greg”, “Mike” or “John” (or whatever name you prefer) to get potentially misleading names and their implicit connotations out of the way of progress. 2.    Draw a concept diagram showing those concepts as well as important semantic relationships among them. 3.    Formulate intensional definitions for each concept – still using the proxy names. Ensure that those definitions are consistent with the relationships shown on the concept diagram. 4.    Identify one or more communities that “baptize” those concepts by giving them better names. If synonyms and/or homonyms appear among those communities, that’s just how the world is; we simply have to live with it. This is why SBVR formally supports semantic communities as well as speech communities. ~~~~~~~~~~~~~  www.BRSolutions.com

Continue Reading No Comments

What’s the Concept?!

In a data modeling discussion forum, a practitioner recently asked:

Has anyone seen an object super-type used to encompass both Party and System Component?

Examples of Parties: people, organizations

Examples of System Components: projects, proposals, computer systems

In over a dozen responses, not one person asked for a definition! My Response I’m surprised … no amazed … no horrified … by this discussion. It pretty well illustrates my frustration with data modeling. I should simply point out that in the real world, projects and proposal are not system components in the sense probably meant, then stop right there. Clearly the question mixes apples and oranges. But let’s work it through a bit more. What is the thing that that the proposed supertype (more general concept) would represent? … Which is to say, how would you define the notion in your head when you say the corresponding thing exists in the real world? If you can’t define the concept in any coherent way, that should be the end of the discussion. This is why I recommend starting with concept models, instead of data models. Since I’ve done a few data models in my time, I’ll jump to the other side of the fence and propose a definition for the sake of discussion.

more general concept x: an agent that can make and respond to requests

Systems, people, and organizations can all do those things. However, proposals can’t … unless you are talking about a software object representing a proposal. So here’s a revised definition …

more general concept x: a software agent that can make and respond to requests

But any software object can basically do that. Is that what is meant? Are we talking about (a) things that exist (can be jointly classified) in the real world, or (b) things that exist in software representations of the real world? My fear is that concept x is simply a design artifact that doesn’t really correspond to anything. It’s just an optimization for technology’s sake. Do we really want to go there?!

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

Confession Time … I Fell into the Same Vocabulary Trap I Warn Everyone Else About

I have been involved in a great on-going discussion on LinkedIn about data models. I posed the question: Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? You might enjoy joining in: http://goo.gl/MsnXu It was literally 25 messages into the discussion that I realized “data model” was being used in two distinct ways in the discussion. And even then it had to be pointed out by a participant who seemed to know one of the other people.
  • I always mean “data model” in the ‘old’ way, in which the data model supports real-time business operations (or close thereto). In that world, you must design for integrity, which generally means ‘highly normalized’ in the relational sense.
  • In the old-but-not-nearly-as-old world of OLAP, real-time operations and updates are not a concern, so de-normalization (and redundancy) are presumably acceptable. (I’ll leave that question to the experts.)
That’s always the problem with vocabulary – deeply buried assumptions that prevent you from hearing what you need to hear. From experience, I know the trap oh-so-well, but here I fell right into it myself. What’s the answer to the question I posed for “data models” (of the kind I meant)? Focusing on the meaning and structure of business vocabulary, not data, as a core part of business analysis.  Note to self (a rule): When you enter any discussion, be clear what you mean by the terms you use – even (and maybe especially) the ‘obvious’ ones.

Continue Reading 2 Comments