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.

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.

	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 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).

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 major principles that guide the application of the Zachman Framework include:

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

  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

The columns are separated as follows:

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.

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 ?