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 ‘semantics’

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

What is the Future for Processes?

To understand the future of processes, you must dig a little deeper than many people do. Process thinking goes back well over a 100 years, to the origin of modern iron and automobile production. The raw materials and finished goods of such manufacturing and production processes are literally spatial – 3-dimensional. What can you do to significantly improve productivity in a 3-dimensional world? The answer these days is simple: You build robots. Robotization has literally changed the world during the past 30-40 years. Rather than manufacturing and production processes, however, the world is now increasingly focused on white-collar and digital processes. What 3-dimensional presence do the raw materials and finished goods of these processes have? Well, exactly none. The raw materials and finished goods of these processes aren’t physical and simply have no spatial presence whatsoever (except maybe for paper artifacts). Robots (at least physical ones) aren’t an option. That fact of life makes a huge difference in how you have to think about automation for such processes. Instead, the raw materials and finished goods of such processes are all about your operational business knowledge – your intellectual capital – and your capacity to express and apply it. That capability, in turn, depends directly on your business terminology and business language. For white-collar processes you have no choice – the world is semantic. So you must deal with the subject matter semantically. That takes us in a very different direction than most professionals currently foresee. For one thing it takes us toward natural language and away from diagrams-for-everything. That’s a huge shift in mindset. Imagine having a business conversation with your smart phone about gaps and ambiguities in business policies and in the meanings of the vocabulary you use to talk about subject matter knowledge. Don’t think that’s possible? Have you watched your kids talking to their smart phones lately? Sooner or later businesses will realize that operational business knowledge differentiates their product/services and enables their ever-more-automated processes to function. Capturing, managing and re-using that intellectual capital puts a premium on structured business vocabulary (concept models[1]) and on business rules expressed in structured natural language[2]. Those business rules are the only way you have to ensure quality from white-collar and digital processes. ~~~~~~~ Read more on this topic: Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com
[1] Refer to “What Is a Concept Model?” by Ronald G. Ross,  Business Rules Journal, Vol. 15, No. 10 (Oct. 2014), URL:  http://www.BRCommunity.com/a2014/b779.html
[2] e.g., in RuleSpeak®. Refer to http://www.rulespeak.com/en/

Continue Reading 3 Comments

Concept Models Are Simply Not Data Models

I certainly understand the need for data models, and that fact they should be coordinated/integrated with process models. Who would question that these days?! But to re-engineer business decisions or knowhow-intensive business processes (or both), you need a structured business vocabulary – i.e., a concept model. The purpose of a concept model is to provide the terminology and wordings to write hundreds (or thousands) of rules coherently and consistently. Building such blueprint is not an insignificant undertaking. Yes, a concept model can be used as the basis for designing a model of the data needed to support processes, but that’s not its primary objective. Rather its purpose is to understand what the business rules and decision logic are talking about business-wise at ‘excruciating level of detail’ (to borrow a phrase from John Zachman). A concept model involves hundreds of terms, some whose meanings are obvious, some whose meanings you think are obvious but aren’t, and some whose meanings are simply mysterious. We constantly have to caution against setting expectations too high about how much integration based on business semantics can be achieved on relatively short notice. Even though it seems like ‘defining business terms’ should be relatively easy, concept modeling is by far the hardest work we do. The problem in virtually every organization in the world today is that these business semantics have never been developed well enough (think semantic, rather than functional, silos) to take automation of logic to the next threshold – i.e., to white-collar automation. Yet that’s exactly where a great many organizations currently want (and urgently need) to go. www.BRSolutions.com

Continue Reading 2 Comments

Three Basic Principles for Business Architecture

Here are what I firmly believe are three basic principles for business architecture. To me they are just common sense, but they are certainly not so common in prevailing industry practices. 1. Business architecture should be of, by and for the business. (Otherwise, why add the modifier “business”?!). Our rule of thumb is that if business people don’t use a methodology term naturally, then it has no place in *business* architecture. Ever hear a business person use the term “business use case” or simply “use case” without prompting from IT?! The technique is an obvious misfit for *business* architecture. This is simply a case of IT trying to elevate its own tools to a problem it frankly often doesn’t understand. 2. The blueprinting techniques used for business architecture should apply exactly the same no matter how wide the scope – project, business process, whole business, whole supply chain, etc. These are all business problems (first), just sitting in different ecosystems. Also, it should make no difference whether automation is anticipated or not. (Actually, running business operations by hand may be harder in some respects than if automated. Anyway, systems do sometimes go down.) If a blueprinting approach fails in these regards, it’s not about *business* architecture. 3. A major shortcoming in most current approaches is the absence of attention to specifying semantics and knowledge. These need not be interpreted as anything arcane – they’re not. Basically, ‘semantics and knowledge’ simply means defining business vocabulary – words – in an organized manner, and practicable rules to run the business by. Now what business person hasn’t heard of “words”, “definitions”, and “rules”?! Yet traditional IT methods treat them as alien (or not at all). In a day and age of IBM Watson, how could such practices not be seen as archaic?! ~~~~~~~~~ P.S. Yes, such blueprinting techniques for business architecture do exist, and we practice them – in-depth – all the time with our clients. This is what our book Building Business Solutions: Business Analysis with Business Rules (http://www.brsolutions.com/b_building_business_solutions.php) is all about, as well as our on-line training based on it (http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php). www.BRSolutions.com

Continue Reading 2 Comments

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

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