Essentials of Business Architecture: Developing your Concept Model: What do you manage and what do the words mean


In the first ten Columns of this series, I have discussed many ideas, models and methods. All of these have tacitly presumed that we have some grip on the business knowledge included in the architectures we are trying to establish. As I have been writing these Columns, without thinking too much about it, I fell into the trap of assuming that we all know our business and how to talk about it. Clearly, nothing could be further from the truth. Communications and terminology assumptions among members of the business gets us into difficulties on a regular basis. It is not unusual for staff in companies to use the same words for different things and different words for the same thing, and it is unusual to find a structured vocabulary. Working recently with two integration efforts after an acquisition drove this challenge home. In each case, it was critical to get common definitions established early so we could merge operations and have a shared IT infrastructure integration as well as to be able to compare results and information. These issues are not only of practical importance to solve semantically but culturally in many cases as well.

In several of the Columns, I have mentioned the importance of a common semantic framework in order to even develop other architectural models, and as the practice of Business Architecture has emerged and evolved in the three years since I have been writing the Column. As I have been applying the methods and techniques described, my teams have increasingly relied on the formal structuring of a Concept Model as the foundation of several other types of domain models. The overall Process Renewal Group (PRG) architectural framework has also evolved to be more workable and easier to communicate to practitioners. This is the latest framework.


In the first Column I intended to provide an overview of the business architecture field introduced an overarching set of concepts that we at PRG have been successfully using to classify and categorize issues of concern. The new version of this model recognizes the iterative nature of the major phases of the development of a business architecture. The approach is certainly more agile in nature and the population of the knowledge required for each domain of interest can only really be well understood in the context of the others despite the need to keep each domain independent in specification but interdependent in real use.

Underlying the Business Design Phase of the architecture is the Concept Model. We will see that the Concept Model will establish the foundation for the business processes needed to act on those concepts, the business capabilities that must be present to make the concepts work, the key performance indicators to assess the state of the business performance and, most directly, the translation of what we need to know about – the information – to keep the organization alive. In addition to these critical architectural building blocks, the Concept Model provides a rigorous foundation for the structuring of business rules to be used in making business decisions. I will start by describing the essential elements of the concept model and then deal with the other domains and how each can leverage the concept model to allow ease of change which is critical for establishing and sustaining business agility.

What is a concept model?

I would like to thank Ron Ross of Business Rules Solutions for providing some of the information for this section of the Column.

Some definitions

The following are some definitions that we will use in this Column.


The concept model is a semantic model and not a data model although it will be indispensable in developing one. There is an Object Management Group standard that establishes the structure of the model to guide practitioners. This standard is named Semantics of Business Vocabulary and Business Rules (SBVR for short). It helps us define the business meanings of concepts and the words used. It is comprised of term definitions (what the words mean) – nouns- and term associations (how the terms are related to one another) – verbs. The model is non-procedural.

Some noun concepts

For the nouns, we typically see a word that represents a real thing such as ‘car’ or a word that represents something less tangible yet important to the business such as ‘trip’. A good business concept defines something fundamental to the business operation that we must know about and that we manage. It is independent of any organization, process or any technology that deals with it. We can also do a quick test to ask if it can be counted. If so then it is probably a viable concept to be modeled.

The sources of concepts are twofold; the stakeholder relationships we have to manage and the set of things we have to manage in order to execute the business.

The stakeholder list we established as part of the identification of strategic Intent and the establishment of a North Star is one source since these relationships have to be managed and we have to capture information about them. For our ongoing banking example, the following is an illustration.


The list of items exchanged with the external ecosystem stakeholders from our earlier context diagram is another.


An illustration for our consumer bank is:


Now we know what to manage and we can start to connect the dots.

Some verb concepts

Verb phrases connect noun concepts to essentially create a sentence that is a statement of truth. The structure of such statements is ‘Subject (noun) – verb – object (noun)’. For example, ‘a mortgage (noun subject) is secured against (verb) a fixed property (noun object)’. In SBVR the set of these concepts is also called a ‘Fact Model’ and it can be shown graphically. A concept model includes both noun concepts and verb wordings that provide the foundational association between business terms without rule constraints.
Although a fact model can (and should) serve as the basis for creating a data model or class diagram, its central business purpose is to support business communications and help define business information. An illustration of the graphical view of a portion of such a model follows.


Such a model can easily be ‘read’ by business people for validation of the truth about the business by simply following the arrows.

Definition of terms

As mentioned previously, all terms in the concept model must be defined. We recommend, if at all possible, to use definitions that are universal, say from a common language dictionary. When terms are specific to an industry and have different meanings than the common vernacular we would use an industry dictionary or glossary entry. As a last resort, we would create definitions that are unique to a particular company or regrettably a specific group within it. Variations among company groups are where the arguments are the greatest. An example of a well-formed noun definition is, ‘A secured credit product is any loan that is backed by a borrower’s asset’. Note that, in the definition itself, there are other terms that may also require definition. Do we know what a ‘borrower’s asset’ is or what qualifies it to be one? Here are several for the illustrated Concept Model.

Notice that some of the terms defined here, as shown in green underscore, are used in the definition of other terms. It is essential that all relevant ones be covered. If stored in a knowledge base of some sort, the embedded terms would be hypertext linked to their own definition.

Leveraging the concept model

In General

Just having a clear scope of concepts of interest and an understanding of the semantics of the business is extremely helpful in communication, analysis and design and the avoidance of delays and corrections as change efforts proceed. The cost of not all being on the same page in all models is a significant frustration, with real time and cost implications. There are a number of models that will be derived directly from the concept model. These are Information, Capability, Business Process, Measurement and Business Rules.

Information Model

Clearly the business concepts will have a direct traceability to information types. The concept model is missing the cardinality needed for the Information Model and the attributes required to describe the specifics of the data, but the big buckets of information should re-use the names and scope of the concepts although they may be broken into sub types or specializations. The hierarchy of data definitions from concept to logic to physical data, each with their own characteristics, can be traced to the concept model.

Capability Model

In business, all work requires a set of internal capabilities in order to be effective. Obviously, without capability the business fails to function and will not deliver results to stakeholders. Every capability needs both a business context (how it fits and what it supports) as well as a clear purpose. So how can we identify the capabilities to be funded and developed? You guessed it! It is the Concept Model since the capability is centered on something that we have to be able to manage in the business. This structure does not say how good you have to be at it, only that you need that capability in your business at some level of ability to perform. The business Concept Model is a simple way of structuring the inventory of capabilities at a high level within which we can explore the detailed capabilities required. At the highest level, the capability map will mirror the Concept Model quite closely. It should be organizationally agnostic, technologically agnostic, stable over time unless the business model itself is changed, and be traceable up and down to more abstract and more granular levels of capabilities.


Business Process

Developing the top level of a process architecture often seems like a mysterious art. It does not have to be. The Concept Model can, once more, be used to derive the top architecture level of the process model. Every relationship concept proceeds through a life cycle of processes moving it from unawareness and ultimately through to termination. This lifecycle with each external stakeholder naturally defines the value streams and stages along the way. Those relationship concepts are shown in the Concept Model so all processes we conduct with customers, partners, owners, regulators and the like are on the list. In addition, if the other concepts to be handled such as ‘order’ are already defined in the Concept Model then we can also define their lifecycle of activities and get all things that require action into the Process Architecture map.

This means that the process architecture becomes structured, more or less, by the concept model. Our illustration for this follows as a process skeleton as was shown in a previous Essentials of Business Architecture: ‘Prioritizing Process and Capability Change Part 2 “Comprehensive Treatment”‘in this series.



In the measurement Column in this series, I laid the claim that every measurement starts with counting things and putting them into measurement buckets of the same class of data (KPI) about an object of interest. The Concept Model is the first level of counting. I have to know how many orders I have had in order to derive and meaningfully analyse ‘how many were returned or late’. The Concept Model allows us the structure needed to put data into buckets. We can compare concept to concept such as ‘how many orders came from our top 10 customers versus the rest’. We can distribute this data over time so we know how it changes in the first quarter of the year versus the last. We can compare year on year. All of this starts with counting the incidents of the business concepts. The structure of a well-formed measurement system starts with the Concept Model.

Business Rules

Business Rules comply to the structure of the Concept Model if designed using the SBVR standard. As discussed earlier, the terms of the concept items are required in order to set the facts of the model. The verb structure of the concept model shows the truth in the relationship among terms and provides the place upon which the business rules can constrain an otherwise open set of possibilities. Using words such as ‘must’ and ‘should’, the reality of business strategy and business policy as well as the requirement for making business decisions can be expressed. Following our illustration, we could capture the requirement that ‘a consumer must not place an order for a financial transaction that does not have a financial services agreement in place’ or ‘a financial service must incorporate regulations affecting its use’. When structured, the Business rules are built on top of the concept model.


Concept Models are the backbone of Business Architecture and are remarkably stable over time, helping the organization to become more scalable and agile. The understanding that comes from producing one pays off throughout any architecture effort and also any development project, whether waterfall or agile. I strongly recommend that one be developed and leveraged. You will not regret it.

Future Columns

The structured business knowledge gained through the Concept Model will hold together the architecture and be highly reusable. Next time I will return to the architecture journey and pick up where we left of in Column 10.

That’s the way I see it.

Roger Burlton

Roger Burlton

Roger Burlton is Chairman of the BPTrends Board of Advisors and a Founder and Chief Consultant of BPTrends Associates. He is considered a global innovator in methods for Business Process and is recognized internationally for his thought leadership in Business Process Management. Roger has developed and chaired several high profile conferences on Advanced Business and Information Management and Business Process Management, globally.  He currently chairs the annual BPM Forum at the Building Business Capability Conference in the US and the IRM UK BPM Conference in Europe and his pragmatic BPM global seminar series, started in 1991, is the longest continuous running BPM seminar in the world. Rogers is the author of the best selling book, Business Process Management: Profiting from Process and the Business Process Manifesto. He is widely recognized for his thought leadership in business process strategy, business architecture, process analysis and design and process management, measurement and governance.  Roger graduated with a B.A.Sc. in Industrial Engineering from the University of Toronto and is a certified Professional Engineer in the Province of Ontario.


Leave a Reply

Your email address will not be published. Required fields are marked *