Defining and Naming Data Models Related to the Zachman Framework

BackgroundIn 2007 DAMA Chapter Scandinavia initiated a task force named “DM Network” to further develop data modeling standards, methods and experiences. The network consists today of ten experienced and interested members from Ericsson, IKEA, IRM and other Scandinavian companies.

In Scandinavia, data modeling was established in the 1970 based on Ted Codd’s theories and inspired by Professor Bo Sundgren. This approach is business oriented, descriptive and has focus on normalization.

Global Experts
A group of global experts all related to Scandinavia has been appointed to support the DM Network. Members in this group are Malcolm Chisholm, Steve Hoberman, David Robertson, Bo Sundgren and John Zachman. Their role is to review the proposals developed by the DM Network. Read their reviews in the “Feedback from Our Global Experts” section of this article.

Proposed Naming and Description This is a proposal how to name and describe data models, where we relate to the various rows in Zachman Framework.

Purpose of this ProposalThe purpose of this work is to achieve:

  • A common naming standard
  • A common platform for the further development of data modeling in Scandinavia 
  • High quality traceability from row 1 to row 5 and back

The Proposal
The proposal is naming the data models for each row in the Zachman Framework and giving a short description of each model. This description will be further developed when a proposal has been accepted.

The included PP-slides give a few examples trying to explain the proposal.

Data Models Related to Zachman Framework

Row 1
Creating the business architecture is the responsibility of the top management in the business. They may use an Operating Model further described in Enterprise Architecture as Strategy by Jeanne W. Ross, Peter Weill and David C. Robertson.

The Operating Model (OM)
The Operating Model covers both column “how” and column “what.” It means it is a combination of processes and data and has no strict rules. The main use is as a discussion tool for the top management.

There are four characteristics depending on process integration and process standardization in the business. They are named coordination, unification, diversification and replication. Examples are from Fritidsresor and ITT W&WW; using this approach.

Operational Model – Fritidsresor
Processfokus & tjänsteinventering

Operational Model – ITT W&WW;

Row 2
The enterprise architect creates the Overall Business Information Model (O-BIM) for the “what” column and an Overall Process Model for the “how” column.

The Overall Business Information Model (O-BIM)
The overall model consists of the most important entities in the business. There may be between 25 and 50 entity groups in the business. Each entity group is strictly related to the detailed model on row 3. Each entity group is either master data or event data. The master data may be further divided into Partner, Product or Infrastructure entity groups. See example. An entity group consist of a number of entities that are close to each other. That means they have many relationships with each other. A very important business rule is that one specific entity may only belong to one single entity group. If not, the traceability is ruined and the same data will be captured more than once.

Overall Business Information Model Example – Showing Entity Groups

Overall Business Information Model Example – Showing Most Important Entities

The Process Architecture Map
The most important process is the operational process delivering value to the customer. The customer value in the business is defined and described. In a process-oriented business, everything is dependent on the customer value. To produce and deliver a product – hard thing or soft service – every business needs an infrastructure. The infrastructure process has two main parts: to create the infrastructure and to maintain it. The products or services delivered to the customers must be continuously developed related to the customer value described in the operational process. This development is described in the innovation process. Also the infrastructure needs to be developed. Often a new product requires new infrastructures or changes in the existing one. A number of support processes are needed to keep the main processes running. Typically they are human resources, legal, IT, finance and a number of others that deliver their service to more than one process. Their customers are mostly the process owners of the processes receiving their services. See Michael Hammer – The Agenda (2002) for more reading about business processes.

The enterprise architect relates the Information Model to the Process Architecture using the defined Entity Groups and defining the Process Owner having the main responsibility for each Entity Group.

Row 3
On this level, each entity group at row 2 is detailed. One entity may only exist in one entity group, giving a strict traceability in both directions. During the requirement specification, an Information Model covering the whole project may be developed, but this model is not kept and updated to be further used in other projects.

The Detailed Business Information Model – (D-BIM)
The Detailed Business Information Models are created in the Requirement Process. It is covering a smaller part of the business, for example a specific Business Process, when needing a new IT solution. This is either built in-house or bought from outside.
These models are used by the enterprise architect to create and maintain the detailed model of each Entity Group at row 3. The model must be strictly normalized and contain all entities needed so that every data element in the business may be related to the right entity. See example.

Example Detailed Business Information Model

Row 4
The IT architects relate the Detailed Business Information Models to the current and future solutions described in one or many Logical Data Models. Each Logical Data Model must relate to one and only one Detailed Business Information Model.

The Logical Data Model (LDM)
This model describes an IT solution, and it may be de-normalized if the current solution is not based on a normalized Detailed Business Information Model.

Row 5 – Development/Installation
When developing a new IT solution or installing a bought solution, the logical model may be de-normalized by purpose or by accident.

The Physical Data Model (PDM)
The physical Data Model must relate strictly to the Logical Data Model, explaining which entity tables are split or consolidated when creating or installing a specific physical solution.

CommentsName of the High-Level Model
A recent article in Information Management by Steve Hoberman discusses the name of the high level data model.

Below is the argument why the name “Business Information Model” is chosen.

We have not chosen to name it a:

  • Conceptual data model because conceptual is not a business word and it is more about information and not data
  • Business data model because business people like “information” better than “data”
  • Subject area model because subject is a too imprecise word
  • Enterprise data model because “enterprise” is used when discussing the total architecture, not just a specific cell.

The “What” column is the one that has the best potential for traceability. Traceability means that the model created at row 2 O-BIM is traced all the way down to row 5 PDM and the other way from row 5 to row 2.

The vision to “capture the same data only once and at its source” requires the traceability to be fulfilled. The included PP-slides give a few examples trying to explain the proposal.

Service Orientation (SOA)
The technical standardization achieved today makes an IT solution independent of the technical platform. This is a major achievement and gives us a great opportunity to fulfil an enterprise architecture giving big business values.

The foundation in a service orientation is the Data Centric Service described by Dirk Krafzig in “Enterprise SOA.” This Data Centric Services may be strictly based on the entity groups in the Overall Business Information Model on row 2.

That means a business will have about 25 – 50 Data Centric Services. This granularity gives a good potential for maximum of reuse in the business. Find more reading about this also in Thomas Erl SOA – Principles of Service Design.

Feedback from Our Global ExpertsMalcolm Chisholm

The matter that the DM Network in Scandinavia has placed before us is of great importance. The higher level data models have received relatively little attention in the past. Yet, they must be the foundation for all data sharing within the enterprise. A collection of independently created logical data models cannot take the place of the higher level models.

Names are very important for reasons additional to the traceability requirement described here. In particular, the need to communicate that such models exist, or ought to exist.

I emphatically agree with the need to identify and model at a high level (row 2) the core things about which a business needs to know to run its business. These are indeed entity groups. I am very glad to see the categorization at this level into Master Data and Event Data as these have profoundly different properties and behaviors.

Steve Hoberman

The proposal looks good to me. Just two comments:

  1. Myself and two other authors are almost done with our high-level modeling book. After the survey done through the Design Challenge list, we settled on using the term “high-level data model” (HDM for short) for the OBIM, and “very high-level data model” (VHDM) for the OM. I think it is a good point in your document to say that the OM is high enough where it can encompass both data and process.
  2. There is a comment in the paragraph on the DBIM that mentions that it must be strictly normalized. I think it is possible to have a dimensional model at the DBIM level as well. A dimensional DBIM would contain the metrics and different levels of detail possible to view the metric in a completely technology-independent structure.
I think this is a great step towards consistency in this area.

David Robertson

There are three things that I especially like about this proposal: the focus on trace-ability, the emphasis on a service-oriented architecture, and the linking of the Operating Model with the BIM. Since the publication of the book Enterprise Architecture as Strategy in 2006, I’ve become increasingly convinced that the concept of an Operating Model, while powerful and necessary, is incomplete without an accompanying BIM. (And, of course, the reverse is true: a BIM without an operating model is an insufficient starting point for a detailed architecture design.) This work is a nice step forward in our thinking about how to design EA.

Bo Sundgren

I published my paper ”An infological Approach to Data Bases” in 1973. In 1979 I met Eskil Swende and Claas Åkesson at Scandinavian Airlines and introduced them to the concept. We worked together with business experts in workshops creating the Data Models. The model was then used when designing the databases.

It has been a great experience for me to see how the concept through the unique and insistent work by IRM has been introduced as Data Modeling in Scandinavia. This paper is a breakthrough in the use of Data Models at the different lines in Zachman Framework. The traceability between the models is a key success factor to achieve an Enterprise Architecture that can be transformed into IT solution supporting a successful and competitive business.

The modern information technology of today gives us good opportunities to fulfill an Overall Information Model into existing IT solutions in a way we did not have in the seventies.

Bo Sundgren has been professor in Informatics and Information Management since 1979, now engaged at the Stockholm University.

John Zachman

I have cooperated with IRM and Eskil Swende since they formed IRM in 1982. They have always been very supporting to my Framework, and I have been able to visit Sweden almost every year. I strongly support the initiative within DAMA Chapter Scandinavia to develop their concept related to Data Modeling. The traceability is and has always been a very important issue in my Framework. To have this jointly described and accepted among a number of Scandinavian main businesses is a major achievement, and I congratulate you to this. Please keep me informed about the further development.

Share this post

scroll to top