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 ‘structured business vocabulary’

Pleased to Announce Release of Our New Book Edition!

Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php Get it on Amazon: http://goo.gl/HXxN1f What It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide. Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Continue Reading

Basics for Business Architecture: #3 – Structured Business Vocabulary (Concept Model)

Professionals should always focus on business solutions first, then and only then on designing systems. Not just lip service, I mean applying the power techniques of true business architecture[1]. The first two of these techniques are:   The third technique is structured business vocabulary – a concept model. The value-add companies produce today is based on rich operational business knowledge. No business solution can prove truly effective if business people (and the tools they use) are unable to communicate about that knowledge clearly. Who profits from operating in a Tower of Babel? A concept model[2] is about identifying the correct choice of terms to use in business communications (including statements of business rules) especially where subtle distinctions need to be made. A concept model starts with a glossary of business terms and definitions. It puts a premium on high-quality, design-independent definitions, free of data or implementation biases. It also gives structure to business vocabulary. Essential for any true architecture is stability over time. Are the core concepts of an operational business stable over time? Yes.[3] Did you know that?! ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1] Refer to the second edition of Building Business Solutions: Business Analysis with Business Rules, an IIBA Sponsored Handbook, by Ronald G. Ross with Gladys S.W. Lam, (to be published mid 2015). http://www.brsolutions.com/b_building_business_solutions.php
[2] The standard for concept models is the OMG’s Semantics of Business Vocabulary and Business Rules (SBVR). Refer to the SBVR Insider section of www.BRCommunity.com.   
[3] 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

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

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

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