On Zachman's framework for documenting enterprise systems

"Great read"

A comprehensive architecture framework gives advice on processes, products and people. This article is a systems thinkers' view of Zachman's framework, which is a classification system for products - not a process or method. It is a two-dimensional classification framework for organizing and pigeon-holing artifacts that describe an enterprise's business activity systems.

Evolution

After Duane Walker left IBM in the 1970s, John Zachman worked for a while with Walker's BSP method for enteprise-wide analysis of data processing. In 1982, Zachman published an article on his own framework.

In 1982, in "Business systems planning and business information control study" (IBM Systems Journal Vol 21, Issue 1) Zachman encouraged "managing data" at the "enterprise level". He wrote:

• ".as the technology continues to mature and as industry evolves to later stages of learning with regard to managing data, the demand for greater levels of sophistication in enterprise analysis will increase".

In 1982, 84 and 87, Zachman developed his Information System Architecture Framework in IBM articles, including "A framework for information systems architecture" (IBM Systems Journal, Vol 26 Iss 3), These articles featured a grid with

• columns for What (mapped to Data), How (mapped to Processes) and Where, and
• proposed three more for Who, When, and Why.

Zachman conceived of

• “system implementations, extending in scope and complexity to encompass an entire enterprise.”

In 1992, Zachman and Sowa wrote: "Extending and formalizing the framework for information systems architecture" (IBM Systems Journal ( Vol 31, Issuw 3), which starts:

• "John Zachman introduced a framework for information systems architecture that has been widely adopted by systems analysts and database designers."

In the period from 1989 to 1996, other approaches to enterprise architecture (the NIST EA model, Spewak's EA Planning method, and others) were developed by people wanting to improve enterprise-level analysis of business data processing systems, and planning of changes to them.

In 1997, Zachman renamed his Information System Architecture Framework as an EA framework. The framework had evolved into 6 by 6 grid of 36 cells in which you may lodge artifacts that describe an enterprise's business activiy systems.

The six columns/questions

Zachman presents the 6 columns as answers to 6 questions. Here is a simple list I drew up years ago

1. What - data flows, data stores, data entities, material objects.
2. How - activities, services, processes, functions, capabilities.
3. Where - locations, nodes.
4. Who - actors, organization units, other active components.
5. When - time events, schedules.
6. Why - aims, goals, objectives, requirements.

The six questions are those Kipling asked in his famous poem. Research tells me the five most commonly used interrogatives: who, whom, whose, what, and which. Others include: how, when, where, whither and whence.

The mapping of questions to answers (system elements) is not obvious, and some system elements might appear in answers to more than one question.

1. What? Inventory: All assets? Or only those sold? Individual things or types of them?
2. How? Process: Value streams, processes, use cases, and user stories. Functional decomposition?
3. Where? Distribution: Locations. Nodes in a network that distributes materials or information?
4. Who? Responsibilities: All entities responsible for performing processes or managing resources?
5. When? Timing: Calendars and schedules. Events the trigger processes?
6. Why? Motivations: Whose motivations (managers, employees, customers, architects, builders, other)? How to reconcile conflicting motivations? Drivers as well as goals?

Thoughts

Such classifications are appealing but simplistic. The columns must make sense not only on their own, but critically, in relation to each other. The distinction between why, what and how is not as obvious as you might think.

The Q & A can be in 1-1 correspondence.

• Why are you going to the shop? To buy a radio.
• What will you do ? Buy a radio.
• How will you do it? Buy a radio.

And can be arranged in a why-what-how hierarchy

• Why: increase income
• ---- What: increase prices
• ---- What: sell overseas
• -------- How: find overseas partners
• -------- How: open overseas outlets.

The 6 rows/levels of idealization

The rows are intended to be a reifiication (ideal to real) hierarchy. But are widely misinterpreted as a decomposition hierarchy.

The rows are also awkward kludge between:

• reification levels: conceptual, logical, physical
• architecture domains: business, applications, platform technologies
• stakeholder auhority levels: manager, architect, engineer

The Stakeholder/Domain/Realization rows are

1. Executive/Scope/Context: Lists and names of actors, activities, resources and aims, or rather, types of them.
2. Managers/Business/Concepts: Managers aren't interested logical, physical and real views?
3. Architect/System/Logic: Mechanical system? Human activity system? Application? Operating system? The enterprise as a system? Don't architects take conceptual, logical and physical views?
4. Engineer/Technology/Physics:
5. Technician/Tool/Components: “Component” suggests decomposition rather than realization. One person’s component (say, application) is another person’s system.
6. Enterprise/Operations/Instances: Is this real word business and IT operations? Or descriptions of them, as in a CMDB of the production environment?

Thoughts

Three abstraction scales are often used in Enterprise and Business Architecture.

High-level composition to low-level decomposition: Zachman has said the rows are not levels of detail. Nevertheless, it is very common for people to decompose

• Why (aims) in a goal/objective hierarchy.
• What (actors and comonents) in an organization chart or product break down structure.
• How (activities) in a functional decomposition, work break down structure or process flow decomposition.

High-level idealization to low-level realization: Zachman has said the rows are levels of realization. By comparison, TOGAF's Enterprise Continuuum has 3 levels of idealization from real systems, much ike this this classic hierarchy:

• Conceptual
• Logical (architecture building blocks in TOGAF),
• Physical (solution building blocks in TOGAF), and
• Real (operational, systems in production).

Hierarchical client-server layering : Zachman appears to suggest the ideaization/realization scale at levels 2, 3 and 4 matches the client-server hierarchy of business, applications and technology domains you can see in the TOGAF and ArchiMate and standards.

Remarks

The 2024 version of the Wikipedia article on framework report these criticisms.

• Kim and Everest "creating comprehensive descriptions of enterprises is unrealistic."
• In 2004 Zachman admitted "nobody that we know of " has successfully implemented the ZF.
• Stanley Gaver: "the analogy to classical architecture is faulty and incomplete".
• Jason Bloomberg: "enterprise is not like a machine or a building, and can't be architected or engineered as such".

Zachman often drew analogies with the architecture of a building or airplane. But all analogies fall short in some ways, and enterprises do not document human and computer activity systems in "excruciating detail" down to 3D drawings of every nut and bolt.

System theorists tend to gloss over differences between material and information processing, between hardware and software engineering. In my experience, even enterprise architects who work for manufacturers are more interested in the information created and needed by manufacturing processes, than the engineering of production lines.

It is impractical to document business activity systems (in excruciating detail, John used to say) at 5 levels of abstraction (by idealization) from reality. The time, effort and skill needed to do that, then update and maintain relationships between the descriptive artefacts, is way beyond what enterprises can do.

In short, the framework has stimulated a lot of thought about how to document business actvity systems but it is questionable in theory and impractical in practice. Today we have more multi-dimensional views of enterprise systems. Try this article on EA vision and reality.

Further reading

This article is included with 12 others in “A Systems Thinker’s View of Enterprise Architecture”, a book made available to community-tier members of Cyb3rSyn Labs.? You can subscribe here: www.cyb3rsyn.com.