Developing Your Concept Model

by Grant HEnson

*The owners of this website may be paid to recommend some precious metals companies. The content on this website, including any positive reviews of these companies and other reviews, may not be neutral or independent.

We have explored a multitude of ideas, models, and methods for business architecture. In doing so, we have implicitly assumed that we have a shared understanding of the business knowledge embedded in the architectures we are endeavoring to establish. However, this presumption can often be a trap, leading us to overlook the potential for miscommunication and semantic discrepancies that are prevalent in most businesses.

For example, employees may use the same words to denote different things, and different words for the same concept. This can lead to confusion that impacts operations, IT infrastructure, and business results. A recent engagement with two integration efforts following a corporate acquisition highlighted this challenge, emphasizing the need for common definitions to facilitate operational merging, IT infrastructure integration, and result comparison.

The Importance of a Common Semantic Framework

A common semantic framework is essential for developing other architectural models. As I have often reiterated, a Concept Model is the foundational stone for several domain models. In the three years I've been writing this column, my teams and I have increasingly relied on the formal structuring of a Concept Model to develop robust domain models. This process has led to the evolution of the Process Renewal Group (PRG) architectural framework, making it more practical and communicable.

The latest framework acknowledges the iterative nature of business architecture development. It suggests an agile approach that highlights the intertwined relationship of the various domains. Each domain must remain independent in specification but interdependent in actual use to fully understand the knowledge required within each domain of interest.

The Central Role of the Concept Model

At the heart of the Business Design phase of the architecture lies the Concept Model. This framework provides a robust foundation for developing necessary business processes, identifying requisite business capabilities, defining key performance indicators (KPIs) for business performance evaluation, and translating the essential information needed to keep the organization operational.

The Concept Model also serves as a rigorous base for structuring business rules used in decision-making processes. In this column, we will begin by detailing the crucial elements of the concept model. We will then explore how the other domains can leverage the Concept Model to facilitate change, a critical factor in establishing and maintaining business agility.

The Essential Elements of the Concept Model

The Concept Model forms a semantic backbone that helps establish a shared understanding of business terms and their interrelations. These conceptual elements primarily include:

Entities: The key concepts or things of interest in a business, such as a "Customer" or a "Product."

Relationships: The connections between entities, defining how one entity interacts or associates with another.

Attributes: The properties or characteristics that define an entity.

Business Rules: The governing principles that define or constrain some aspect of the business.

Understanding and defining these elements in a consistent, shared manner across the organization is the first step towards developing a Concept Model. By serving as a unifying language across all business domains, the Concept Model ensures that all aspects of business architecture, from process design to performance management to decision-making, are grounded in a shared, structured understanding of the business's key concepts.


The Concept Model plays a pivotal role in enabling organizations to manage change and foster business agility. By providing a shared semantic framework, it allows different domains to communicate coherently and consistently, aiding in both the establishment and evolution of robust business architectures.

Related Articles