iCMG IT Architecture Firm  
Tell a friend
Upcoming Webinar
25 Mar, 3.30 - 5 PM (UAE)
Enterprise Architect
Feedback on Zachman
“John Zachman presents a very compelling argument, that is, every organisation needs an Enterprise Architecture to survive.”
“An excellent and inspiring seminar – we will return to work and start mmediately.I can recommend this seminar with enthusiasm.”
“An excellent course. All CEOs and CIOs should attend.”
Enterprise Architecture 09
  What is the Zachman Framework?

The Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise's systems. It uses a grid model based around 6 basic questions (What, How, Where, Who, When and Why) asked of 5 nominated stakeholder groups (Planner, Owner, Designer, Builder and Subcontractor) to give a holistic view of the enterprise which is being modeled. This framework enables senior business managers and IT professionals to understand the implications of key business and IT strategies that must be established for turbulent times.

The framework is helpful for sorting out very complex, technology and methodology choices and issues that are significant both to general management and to technology management.

"One of the best foundations for an architecture that aligns IT to business. This will help you to create a model that can grow and change as fast as the market evolves".

It was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e.g. buildings or airplanes.)

The Zachman Framework has become de facto standard for Enterprise Architecture for aligning the business goals with Information Technology Investments world over.

Zachman Framework

Download  JPEG and PDF version of the framework

The real strength of this framework

"The framework has been applied in
Global 2000 organizations* such as

Swisscom Mobile
Bank of America
Health  Canada
Allstate Insurance
Federal Express
Johnson & Johnson
NCR Corp
Glaxo SmithKline
General Motors
Canadian Imperial bank
of Commerce
note-* based on public domain information

HurryThe Zachman Framework has also spawned a number of other similar frameworks for applying enterprise architecture in specific domains. These include the Federal Enterprise Architecture Framework (FEAF), The Open Group Architecture Framework (TOGAF) and the Department of Defence Architecture Framework (DoDAF).


It is product neutral
Used heavily by Ford, Volkswagon, Firestone, GM, DOD,  US Treasury, State CIOs
Comprehensive, working model that aligns IT with business by looking at pieces that fit into  the whole of an  enterprise puzzle
Simple, logical model. Not technical
It is a language that helps people think about complex  concepts and communicate
in non-technical terminology
It is a Planning Tool
It is a Problem Solving tool that enables abstraction and simplification without neglecting the complexity of the Enterprise as a whole
The Zachman Framework describes a holistic model of an enterprise's information infrastructure from six perspectives: planner, owner, designer, builder, subcontractor, and the working system. There is no guidance on sequence, process or implementation of the framework. The focus is on ensuring that all aspects of an enterprise are well-organized and exhibit clear relationships that will ensure a complete system regardless of the order in which they are established.

By defining clear architectural design principles, Zachman ensures that any tailored or extended implementation will be equally well built as long as the designer and builder continue to follow the rules.

The Zachman framework is a great way to think about the relationships between systems, data, processes and business.


The major principles that guide the application of the Zachman Framework include:

  • A complete system can be modeled by depicting answers to the questions why, who, what, how, where and when.
  • The six perspectives capture all the critical models required for system development.
  • The constraints for each perspective are additive; those of a lower row are added to those of the rows above to provide a growing number of restrictions.
  • The columns represent different abstractions in an effort to reduce the complexity of any single model that is built. The columns have no order.
  • The model in each column must be unique.
  • Each row represents a unique perspective.
  • Each cell is unique.
  • The inherent logic is recursive.

The Zachman Framework is a simple concept with powerful implications. By understanding any particular aspect of a system at any point in its development, system designers construct a tool that can be very useful in making decisions about changes or extensions. The framework contains 6 rows and 6 columns yielding 36 unique cells or aspects. This can be seen in the framework diagram.

The rows are separated as follows:
The Zachman Framework

 Rows  Description
1. Scope Corresponds to an executive summary for a planner who wants an estimate of the size, cost and functionality of the system.
2. Business model Shows all the business entities and processes and how they interact
3. System model Used by a systems analyst who must determine the data elements and software functions that represent the business model.
4. Technology model Considers the constraints of tools, technology and materials
5. Components Represent individual, independent modules that can be allocated to contractors for implementation.
6. Working system Depicts the operational system.

The columns are separated as follows:

 Columns  Description

Represents the people relationships within the enterprise. The design of the enterprise organization has to do with the allocation of work and the structure of authority and responsibility. The vertical dimension represents delegation of authority and the horizontal represents the assignment of responsibility.


Represents time, or the event relationships that establish performance criteria and quantitative levels for enterprise resources. This is useful for designing the master schedule, the processing architecture, control architecture and timing devices.


Describes the motivations of the enterprise. This reveals the enterprise goals and objectives, business plan, knowledge architecture and knowledge design.


Describes the entities involved in each perspective of the enterprise. Examples include business objects, system data, relational tables or field definitions.


Shows the functions within each perspective. Examples include business processes, software application function, computer hardware function and language control loop.


Shows locations and interconnections within the enterprise. This includes major business geographical locations, separate sections within a logistics network, allocation of system nodes or even memory addresses within the system

The top two rows are intensively business-oriented and can be expressed in business-oriented vocabularies, while the bottom three rows are in the technical domain. The third row acts as a bridge between the business and technical models.

Currently, lots of efforts are underway to map Zachman Framework to various development methodologies and as well as new standards, e.g.
Mapping of Rational Unified Process(RUP) artifacts to the Zachman Framework cells
Mapping of Model Driven Architecture (MDA) to Zachman Framework
Mapping of Enterprise Unified Process (EUP) to Zachman Framework

Business concepts from the top row must be embedded into business objects and components in the bottom rows. The business concepts can be refined over time, but their relationships should not be changed. Generic software objects and components, along with those from a specific domain repository, can be selected to populate the foundation of the system, but specific application-oriented objects must be designed and integrated to implement the system under development.

The order of the columns could be rearranged e.g. motivation column could be designated as frist column. The requirements are captured in the "why" column and the actors are associated with the "who" column. Because, it is generally recommended that service identification precede objects, then the how and what columns can follow. Regardless of the chosen order, note that the columns are related as in the software: the data represent inputs and outputs of the services.
The Framework is a generic classification scheme for design artifacts, ie., descriptive representations of any complex object.

The utility of such a classification scheme is to enable focused concentration on selected aspects of an object without losing a sense of the contextual, or holistic, perspective. In designing and building complex objects, there are simply too many details and relationships to consider simultaneously. However, at the same time, isolating single variables and making design decisions out of context results in sub-optimization with all its attendant costs and dissipation of energy. Restoration of integrity or retrofitting the sub-optimized components of the resultant object, such that they might approximate the purpose for which the object was originally intended, may well be financially prohibitive.

This is the condition in which many Enterprises find themselves after about fifty years of building automated systems, out-of-context. They have a large inventory of "current systems", built out-of-context, not integrated, not supporting the Enterprise, that are consuming enormous amounts of resource for "maintenance" and are far and away too costly to replace.

As a matter of fact, the inventory of existing systems has come to be referred to as "the legacy", a kind-of "albatross", a penalty to be paid for the mistakes of the past.

A balance between the holistic, contextual view and the pragmatic, implementation view can be facilitated by a Framework that has the characteristics of any good classification scheme, ie., it allows for abstractions intended to:
Simplify for understanding and communication and
Clearly focus on independent variables for analytical purposes, but at the same time,
Maintain a disciplined awareness of contextual relationships that are significant to preserve the integrity of the object.

It makes little difference whether the object is physical, like an airplane, or conceptual, like an Enterprise. The challenges are the same. How do you design and build it piece-by- piece such that it achieves its purpose without dissipating its value and raising its cost by optimizing the pieces, sub-optimizing the object.

In summary, the Framework is:


it is easy to understand ... not technical, purely logical. In its most elemental form, it is three perspectives: Owner, Designer, Builder ... and three abstractions: Material, Function, Geometry. Anybody (technical or non-technical) can understand it.?


it addresses the Enterprise in its entirety. Any issues can be mapped against it to understand where they fit within the context of the Enterprise as a whole.


it helps you think about complex concepts and communicate them precisely with few, non-technical words.

Planning Tool

it helps you make better choices as you are never making choices in a vacuum. You can position issues in the context of the Enterprise and see a total range of alternatives.

Problem Solving Tool

it enables you to work with abstractions, to simplify, to isolate simple variables without losing sense of the complexity of the Enterprise as a whole.


it is defined totally independently of tools or methodologies and therefore any tool or any methodology can be mapped against it to understand

Public domain
The framework is now in the public domain
JPEG and PDF version of the framework

The Framework for Enterprise Architecture is not "the answer." It is a tool ... a tool for thinking. If it is employed with understanding, it should be of great benefit to technical and non-technical management alike in dealing with the complexities and dynamics of the Information Age Enterprise. As a originator of the framework, John Zachman has become a cult figure to business and the IT industry in the USA, Europe and Australia. His presentation skills are impressive: he is a dynamic speaker with an engaging presentation style and personality.

Overview      |      Scope    |    Principles    |    Structure     |    Guidance    |    Download
What you will learn?

Framework to consolidate the multiple line of business (LOB) for enterprise profitability

Manage and align organization's strategy, business processes, IT, people
How to relate Business Models, Systems Models and Technology Models
Learn about 30 primitive models for  describing Architecture for Enterprise
How does BPM, SOA & MDA fits in the enterprise scope
Define structure for Architecture Governance
Learn framework for change & complexity management
Effectively define Architecture to prevent "business disintegration"
Framework in Global 2000
"The framework has been applied in
Global 2000 organizations* such as
Swisscom Mobile
Bank of America
Health  Canada
Allstate Insurance
Federal Express
Johnson & Johnson
NCR Corp
Glaxo SmithKline
General Motors
Canadian Imperial bank
of Commerce
* based on public domain information
Architecture for Enterprise
and Information Systems
Architecture for Enterprise and Information System

We know how does architecture looks
like in Construction, Engineering and Manufacturing industries which
has evolved over 100s of years.
What about architecture for Software, Systems & Enterprise ?