Zachman Framework

Introduction

Enterprise Architecture (EA) is the discipline that defines, organizes, standardizes, and documents an organization’s structure and workflows to create and manage more efficient processes.

A specialty devoted equally to the worlds of IT and business, EA introduces practical standards across departmental units and teams in order to streamline efforts with an intelligent sharing of resources. 

The evolution of Enterprise Architecture brought several frameworks architects may implement when approaching the discipline; one of which is the Zachman framework.

These frameworks describe an example taxonomy of the kinds of architectural “views” that an architect might consider developing, and provide guidelines for making the choice for developing those views.

Other EA frameworks include TOGAF, FEAF, and Gartner's Enterprise Architecture Framework.

What is the Zachman framework?

The Zachman Framework is an enterprise architecture ontology that uses a schema for organizing architectural artifacts (e.g. design documents, specifications, and models). The Zachman Framework for Enterprise Architecture aims to take into account and synergize both the artifact targets (business owners and system builders) and the particular issue that is being addressed (e.g. data and functionality).

The earliest version of this framework was introduced by John Zachman, who released “A Framework for Information Systems Architecture” in the 1980s. In 1992, Zachman proposed six descriptive areas of focus—data, function, network, people, time, and motivation—and six perspectives (also known as “players”)—planner, owner, designer, builder, subcontractor, and enterprise.

“A Framework for Information Systems Architecture” (1987), a conceptual precursor to the “Zachman Framework”, as it appeared in Vol. 26., No. 3 of the IBM Systems Journal.

This is the basis for the modern Zachman framework. This was also a watershed moment in Enterprise Architecture because it provided a completely new way of approaching the discipline.

Zachman saw that information systems were bringing about the complexity that needed to be mapped with clearer classifications and interfaces—a veritable blueprint, or “architecture,” of IT components across an enterprise. Since then there have been several updates of Zachman’s original ontology.

This framework, along with a few others, is used by Enterprise Architects when approaching strategies for the development of information systems architecture.

Ontology vs. Methodology

It is important to note that the Zachman framework is not a methodology, and therefore functions differently. In information science, ontology is a way of showing the properties of a subject area and how they are related. It is the process of defining a set of concepts and categories that represent the subject. 

It is a structure whereas a methodology is a process. A structure is not a process. A structure establishes definition whereas a process provides transformation. In this way, the framework (ontology) is unpredictable and changing, producing various outcomes where nothing is repeatable. A methodology is a process of transformation from one state into another. The Zachman framework is an ontology, differentiating it from other Enterprise Architecture frameworks.

Primitives vs. Composites

An ontology is the classification of the total set of present “primitive” (elemental) components that are important to the existence of an object. A methodology, on the other hand, produces “composite” (compound) implementations of the primitives. Primitives are timeless, whereas composites are temporal. For example, a periodic table of elements is an ontology (primitive), but the chemical process of turning bleach and alkali into saltwater is a process–it uses a defined methodology with a predictable outcome (composite).

Why Zachman?

The Zachman framework provided a fresh perspective of looking at and developing enterprise architecture. It asks the questions of What, How, When, Who, Where, and Why–and the integration and answers to these questions that enable the comprehensive, composite overview of complex ideas used to plan, implement, process and evaluate an organization's enterprise structure.

Zachman intended his framework to extend to the entirety of enterprise architecture and is not just restricted to information architecture. 

The Zachman framework is designed to be a proactive business tool. It can be used to model an organization's existing functions, elements, processes, and business structure.

Unlike TOGAF and other more popular frameworks which are organized around a series of life cycles or steps, Zachman’s ontological approach is mapped around the points of view taken by the various “players” in an organization, providing an effective way of assessing the completeness of software development process models, in terms of an organization's information needs.

Structure of the Zachman Framework

The Zachman framework structure is made up of 36 necessary categories for describing almost anything–especially complex things such as manufactured goods. The structure of the framework is made up of 36 categories set inside six rows and six columns which create a two-dimensional matrix.

The completed structure provides viewpoints and perspectives from each “player” involved in the system’s development process to give a comprehensive overview depending on which stakeholder is using the framework.

Columns

The columns of the Zachman framework tend to represent the interrogatives (or questions) that an enterprise is seeking to answer. These are the What, How, When, Who, Where, and Why mentioned above.

• What – An example question would be what are the objects? What is the data that needs to be examined?
• How – How does it function? What are the business processes?
• Where – Where can the business operations be found?
• When – When do these processes need to be performed? How often, etc.?
• Why – Why is this the chosen route or solution? What are the processes and motivations to get to the solution?

The questions will always differ depending on the rows (see below), which represent who is asking the question and for what purpose. 

Rows

The six rows, on the other hand, represent the different viewpoints or perspectives of the “players” –stakeholders or viewpoints. These could be anyone within an organization; including planners, owners, architects, implementers, etc. However, they can also be represented as viewpoints: scope context, business concepts, system logic, technology, etc. 

• Planner’s View: Scope Contexts – This will define the business purpose and strategy.
• Owner’s View: Business Concepts – This view is defined by the individuals who run an organization, who provide a high-level description of the core guidelines in accordance with the questions posed in the columns.
• Designer’s View: System Logic – Here is where the system and processes will accomplish the organization’s IT needs.
• Implementer’s View: Technology Physics – This will address the production constraints while the system is being implemented.
• Sub-Constructor’s View: Component Assembles – Outlines the implementation-specific details of the system’s individual elements.
• User’s View: Operations Classes – How the system will function in its operational environment.

Rules

Zachman proposed seven basic rules for his framework. These Zachman framework rules help architects and IT managers use the tool efficiently and effectively. 

• Rule 1: It’s important not to add rows or columns to the framework. If you are able to answer the Who, What, Where, How, and Why, then you will be able to derive the answers to any other questions about the subject or object. Adding columns or rows would denormalize the classification scheme. 
• Rule 2: Each column has a simple generic model and can have its own meta-model within that column.
• Rule 3: The specific model for any given cell will have to be customized to the constraints, the semantics, the vocabulary, the terms, and the facts of the row’s perspective. Each cell specializes in its column’s generic model.
• Rule 4: The basic model of each column must be unique. It must avoid overlapping or replicating data in any other column. 
• Rule 5: Do not create diagonal relationships between cells. Columns can be arranged in any order but should have a top-down order starting with the most significant category. The matrix should provide clear answers to complex questions in this way, and is designed to do so–it will not benefit stakeholders to create diagonal relationships between cells.
• Rule 6: Do not change the names of rows and columns as this will cause confusion and miscommunication among stakeholders.
• Rule 7: The logic is generic and recursive which means that it can be used to classify or analyze anything related to the enterprise architecture.

Zachman vs. TOGAF

While Zachman provides an agile and flexible approach to enterprise architecture, TOGAF (The Open Group Architecture Framework) is considered the de facto industry standard framework. This framework offers a methodological approach to EA design and is more popular among architects. 

The TOGAF framework provides a series of actionable steps known as the Architecture Development Method (ADM). The ADM is a generic but adaptable methodology to approach the enterprise architecture process. The TOGAF-ADM framework works in life cycles of interchangeable steps to implement the decision choices and produce the desired models.

Alternative to TOGAF, the Zachman framework is an ontology that uses various enterprise perspectives in order to map, define, and plan complex components throughout an enterprise system.

Your general approach to enterprise architecture will determine whether to use Zachman or TOGAF. However, the two can be used to support each other; with TOGAF describing the detailed process for creating the Enterprise Architecture, and Zachman for categorizing the artifacts.

Zachman certifications

Enterprise architects looking to develop their expertise in EA would benefit from investing in The Zachman Certified - Enterprise Architect Program. This certificate provides the basic understanding and functional application of the Zachman framework to develop the theoretical and technical skills to engineer enterprise implementations.

There are four levels to the Zachman Certified - Enterprise Architecture Program:

• Enterprise Architect Associate (Level 1)
• Enterprise Architect Practitioner (Level 2) 
• Enterprise Architect Professional (Level 3) 
• Enterprise Architect Educator (Level 4)

This certification has many benefits for engineers and enterprise architects. The program is a professionally relevant and recognized certification. It can open up opportunities for career advancement and enhance marketability. Some work opportunities will also require the certification alongside the TOGAF certification or equivalent because it demonstrates an architect's ability to approach the role from varied and dynamic perspectives. 

Conclusion

While the Zachman framework isn’t as popular as it once was, it is still a valuable tool in the enterprise architecture arsenal; one that is useful within modern organizations. Using an ontology to map complex information systems and business processes, the Zachman framework is most effectively used in conjunction with other more popular EA methodologies to categorize artifacts and specify deliverables.

With this, architects can accelerate their approach to enterprise architecture, creating more agile and adaptable methodologies in their approach to discipline.