Methodologies and Technologies for Rapid Enterprise Architecture Delivery


| Home | Courses | Projects | Papers | Contact Us |


Issue No 14:

 Part 2 of a two-part Series that addresses Enterprise Architecture from a Senior Management Perspective.

Printable PDF Version


Enterprise Architecture for Senior Managers - Part 2

PERTH, AUSTRALIA – November 29, 2000: We discussed the interdependence of Enterprise Architecture and Enterprise Portals in TEN#7 in September 1999. In TEN#13 we covered Part 1 of a two-part article on Enterprise Architecture from a senior management perspective. The complete article highlights the important role that senior managers must take to ensure Enterprise Architecture success. We continue Part 2 of the article in this issue. We discuss the importance of Architecture for Enterprises, and then cover the Zachman Framework for Enterprise Architecture from a senior management perspective.

Clive Finkelstein
TEN - The Enterprise Newsletter

Back to Contents.


In Part 1 we discussed that the establishment of Enterprise Architecture is a vital first step for Commercial, Government or Defense enterprises that conduct e-Business in the 21st Century. Enterprise Architecture is critical for effective e-Commerce systems and databases, and for Enterprise Portals. We compared Enterprise Architecture to Building Architecture, and discussed that Enterprise Architecture has its foundation in the establishment of Strategic Business Plans from a senior management perspective. In fact, the true differentiator of e-Business success is senior management involvement in setting the Strategic Business Plans for e-Business, to be implemented as an Enterprise Information Architecture by IT staff.

The Importance of Architecture for Enterprises

Building architecture considers the design of a building from many perspectives. The catalysts are the requirements of the Planner and the Owner of the building. The Planner is interested in a broad overview of the building’s purpose. This indicates WHY the building is to be constructed, WHO is to occupy it, and WHEN it is to be built. The Owner supplies the purpose and these other details for planning approval. The Owner will also have other requirements to ensure the building meets his specific needs.

From the Planner’s and the Owner’s perspectives above, the Designer (who is an architect) designs the building to address their needs. The Designer then documents the design in a format and in terms relevant to the Builder: as construction blueprints or diagrams; and as construction specifications. They indicate WHAT materials are to be used, HOW construction is to be undertaken, and WHERE various elements of the building are to be located. From the Designer’s perspective, the Builder documents construction details for the Subcontractor to guide construction of components of the building. The end-result of this use of architecture is a building that meets the needs of the Planner and Owner, when built.

Enterprise Architecture considers the design and operation of an enterprise also from many perspectives. The catalysts for Enterprise Architecture are Strategic Business Plans defined by senior management. These address the requirements of the Planners and Owners of the enterprise:  

  • For Public-Sector enterprises, the Government is the Planner. The government’s requirements are expressed in Laws governing the establishment and operation of the relevant authorities. Senior Managers of these authorities are Owners of the databases and systems needed to support the Law defining the relevant authority.
  • For Commercial enterprises, the Board of Directors and Corporate Planning Department are the Planners, while Senior Managers are Owners of the databases and systems needed to implement the plans approved by the Board.
  • For Defense enterprises, the President and Security Council are the Planners, while the Chiefs of Staff are the Owners of the databases and systems needed to implement the Defense plans.

As we saw earlier, an Enterprise defines its Strategic Business Plans in terms of its Mission, Vision and Values at the highest level. From these, it can establish Policies based on specific constraints. These Policies are qualitative guidelines defining boundaries of responsibility. They are also used to define the Organization Structure of the enterprise, made up of Business Units and Functional Areas.

Policies lead to definition of Goals that define what the enterprise has to achieve (measure), by when (time) and the degree of achievement (level).  In turn, Goals result in the definition of Strategies designed to achieve the goals. These Strategies are then allocated to responsible business units or functional areas for their implementation.

Within each Business Unit or Functional Area, the responsible managers define Objectives to ensure that the Strategies are implemented to achieve the higher level Goals. In turn, these Objectives lead to definition of more detailed Tactics, Tasks or Business Processes that are designed to achieve the relevant Objectives. The Implementation of tactics, tasks or business processes is further managed at lower levels by the definition of Key Performance Indicators (KPIs).

Taken together, the above statements document the Strategic Business Plan of an enterprise. They define WHY the enterprise exists (Mission and Vision), WHAT is to be achieved and by WHEN (Goals and Objectives), HOW they are achieved (Strategies and Tactics), WHO are involved (managers and staff), and WHERE (Locations, Business Units and Functional Areas).

In the design of an enterprise, there are many ways of representing things that are of interest to Planners and Owners, from their perspectives. These are expressed as text in the Strategic Business Plan. The strategic plan can also be expressed as diagrams, lists of things of interest to management, and planning details or specifications representing the enterprise. These details are documented in a Strategic Model.

The Strategic Model and the Strategic Business Plan indicate WHAT, HOW, WHERE, WHO, WHEN and WHY. From these, more detail and different diagrams, lists and specifications can be used to address the perspectives of the Designer, Builder and Sub-Contractor. Again, they are interested in WHAT, HOW, WHERE, WHO, WHEN and WHY.

Based on the Strategic Business Plan and the Strategic Model, a clear expression of the requirements of the Planners and Owners of the enterprise can be determined, for use by the Designers. The Designers of the enterprise are typically senior managers and also managers from the Business Units or Functional Areas. They determine WHAT data and information are required to support decision-making by management. They define HOW data and information are used in business processes. They determine WHO, WHEN and WHERE the data and processes are to be made available throughout the enterprise.

Information Technology staff (data administrators, business analysts and systems analysts) work with these managers and their business expert advisors. From the enterprise business design, they work as Designers of the information systems and databases that will provide the required information needed by management for decision-making. They identify the Business Rules that define WHAT data and information will be used in processes, as well as WHY and HOW. These business rules are used to define application systems and workflows to support managers and staff throughout the enterprise. From this, they define WHAT data is required, and also HOW, WHEN and WHERE it will be processed based on WHO the end-users are. The documentation produced includes Tactical and Operational Data Models, Activity Models, Process Models and Object Models that document these designs.

From the data, activity, process and object models documented by the Designers, the IT Builders (systems analysts, database administrators and programmers) build the databases, application systems and workflows as Information Systems that meet the defined needs of the enterprise.

The Framework for Enterprise Architecture

We discussed how the disciplines of architecture and manufacturing evolved to manage the design, construction and maintenance of buildings and complex manufactured products such as airplanes. John Zachman, an international consultant, saw that experience from these disciplines could also be applied to management of the design, construction and maintenance of similarly complex systems – such as the information systems that support enterprises. The wide variety of lists, text documents, specifications and diagrams in a typical enterprise are difficult to visualize, reference and manage. To assist this management, he defined two frameworks: the Zachman Framework for Information Architecture; and later, the Zachman Framework for Enterprise Architecture.

He saw that columns representing the interrogatives of WHAT (for data), HOW (for process) and WHERE (for location) could be considered from different perspectives, shown as rows in Figure 1

Figure 1: Concepts of the Zachman Framework for Enterprise Architecture [Source: “Building Corporate Portals with XML”, Clive Finkelstein and Peter Aiken, McGraw-Hill (1999)]

  • Row 1 considers Objectives and Scope from the perspective of the Planner

  • Row 2 considers the conceptual Enterprise Model from the perspective of the Owner

  • Row 3 considers the logical System Model from the perspective of the Designer

  • Row 4 considers the physical Technology Model from the perspective of the Builder

  • Row 5 considers Detailed Representations from the perspective of the Subcontractor

Different documentation or representations may be utilized in each cell of the Zachman Framework. For example, a Data Warehouse focuses mainly on data: this is the WHAT (Data) column of Figure 1. An Enterprise Portal focuses on both the WHAT and the HOW columns, while a Transaction Processing System focuses on the HOW column.

The cell formed by intersection of the Objectives / Scope row (of interest to the Planner) and the Data column in Figure 1 shows that a “List of Things” is appropriate for this cell. Similarly, at the intersection of the Process column is a “List of Processes”, while the cell at the intersection with the Location column shows a “List of Locations”.

Consider now the Enterprise Model row (of interest to the Owner). The cell for the Owner row and the Data column shows that “Conceptual Data Model” documentation is appropriate for this cell. This is sometimes also called a “Strategic Data Model”. At the intersection of the Process column for the Owner row is a “Business Process Model”, while the intersection with the Location column shows a “Business Logistics System”.

The next row addresses the System Model from the perspective of the Designer. The cell for this row and the Data column shows that “Logical Data Model” documentation is appropriate. At the intersection of the Process column for the Designer row is the “Application Architecture”. The cell at the intersection with the Location column is “Distributed System Architecture”.

The Builder row addresses the Technology Model. The cell at the intersection of the Builder row and Data column contains “Physical Data Model”. At the intersection of the Process column for the Builder row is the “Systems Design” cell. The intersection of this row with the Location column represents the “Network Architecture”.

Finally the Subcontractor’s row addresses detailed representations: the “Data Definition” of databases in the Data column; “Programs” in the Process column; and “Network Architecture” in the Location column. These result in completion of the required databases and systems.

We have shown and discussed only three columns in Figure 1. The Zachman Framework for Enterprise Architecture has three further interrogatives for a total of six columns – WHO (people), WHEN (time) and WHY (motivation). The complete Zachman Framework is illustrated at the end of this issue, in Figure 2. It is also discussed in the context of Information Warehouses and Enterprise Portals in Chapter 15 of the book: “Building Corporate Portals with XML” by Clive Finkelstein and Peter Aiken (McGraw-Hill, 1999). This book can be ordered directly from by visiting the IES Online Store and clicking on the book cover image in the right frame at

The Zachman Framework is a useful way to discuss complex activities and representations for Enterprise Architecture and also Enterprise Information Architecture. It enables enterprises to precisely plan, design, develop and manage the systems and databases that will be needed for effective e-Business in the 21st Century.

Back to Contents.



TEN Archive
Contact Us





Clive Finkelstein is the "Father" of Information Engineering (IE), developed by him from 1976. He is an International Consultant and Instructor, and was the Managing Director of Information Engineering Services Pty Ltd (IES) in Australia. 

Clive Finkelstein's books, online interviews, courses and details are available at

For More Information, Contact:

  Clive Finkelstein
59B Valentine Ave
Dianella, Perth WA 6059 Australia
Web Site:

(c) Copyright 1995-2015 Clive Finkelstein. All Rights Reserved.

| Home | Courses | Projects | Papers | TEN Archive | Contact Us | [Search |

(c) Copyright 2004-2009 Information Engineering Services Pty Ltd. All Rights Reserved.