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.
Traceability
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
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
- 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.
- 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.
David Robertson
Bo Sundgren
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