On the thinking behind the Zachman Framework (a critique)


This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to avancier.website in whichever social media you use.


This paper comments on the thinking behind the Zachman Framework, highlighting some curiosities and ambiguities.

It questions the assumption that architecting human and computer activity systems should be like architecting hardware objects and machines.


Zachman’s thinking in 2003. 1

Zachman recalling his thinking up to 1987. 2

Zachman’s thinking in 2015. 8

Zachman’s thinking in 2011. 13

References. 14


Zachman’s thinking in 2003

In 2003, Zachman listed ten key points for EA, including the ones below.


“If it gets so complex that you can’t remember everything all at the same time, you have to write it down (Architecture).

Then, if you want to change it (whatever it is), you start with what you wrote down (Architecture), the baseline for managing change.”


“The broader you define the analytical target, the better leverage you are going to get on integration, reusability, interoperability, etc…

If you draw the boundary more narrowly than your jurisdictional control, you will disintegrate your Enterprise, that is, you will build a “legacy.”


“If you are not observing the engineering design principles

…, you are not going to realize the engineering design objectives of alignment, integration, reusability, interoperability, flexibility, reduced time-to-market, etc., etc.

you are never going to appreciably reduce time-to-market until you have something in inventory before you get the order.

If you are not building (and storing, managing and changing) primitive models, you are not doing Architecture. You are doing implementations.”


Fair enough: it seems undeniable that EA tenets include:

·         the target is as broad as possible (cross-organisational)

·         goals include alignment, integration and reuse (again, cross-organisational)

·         the EA is found in documented system descriptions (rather than in operational systems).


Remember these tenets as you read what follows.

Zachman recalling his thinking up to 1987 

Prior to The Open Group’s San Diego 2015 event, The Open Group spoke to Zachman.

Zachman discussed the origins of his framework, the state of Enterprise Architecture and the skills he believes EAs need today.

The resulting Open Group paper is reproduced below – shaded grey.


The Zachman Framework is widely recognized as the foundation and historical basis for Enterprise Architecture.


Many say this; however, the PRISM report of 1986 looks to be a more direct basis for EA frameworks like TOGAF. (Ref. 3)

And general system theory (see later) has always provided an underpinning logic for enterprise architecture documentation.


As a discipline, Enterprise Architecture is still fairly young.

It began getting traction in the mid to late 1980s after John Zachman published an article describing a framework for information systems architectures in the IBM Systems Journal.


In 1986, the PRISM paper divided enterprise-level architecture into business, data, applications and infrastructure technology domains. (Ref. 3)

In 1987, Zachman introduced an enterprise-wide Framework for Information System Architecture. (Ref. 4)

In 1989, the NIST “Enterprise Architecture Model” was a five-layer reference model that related business, information system, and technology domains. (Ref. 5)

The NIST standard for EA seemed to draw more on the 1986 PRISM paper than on the Zachman Framework.


Zachman’s conception was and is of a 6 by 6 taxonomy that maps:

·         “primitive interrogatives” the 6 analysis questions in the column headers below

·         reification - the transformation of an abstract idea into an instantiation” - labeled as in the row headers below.


By the way, the 6 questions do not necessarily lead to a complete description of an activity system.

The questions don’t distinguish human and computer actors, or distinguish active and passive structural elements.

Asking "who does that?" reveals human actors, but not animal or mechanical actors, for which the question "what does that?" should be asked.

To reveal the objects of actions, "to whom or what was it done?" should be asked.

Other W questions that could be asked include whence, whither and whereto.


The upper rows hold 5 successively more abstract system descriptions of the instances in the bottom row

The bottom row is the realisation of the higher level idealised descriptions - as operational system components and processes.




















































Zachman said he lived to regret initially calling his framework “A Framework for Information Systems Architecture,” instead of “Enterprise Architecture”

Because the framework actually has nothing to do with information systems.


The framework has nothing to do with information systems? Or rather, it applies to other kinds of system as well?

Certainly, business processes depend on creating, manipulating and using information.

EA has always largely been about business roles and processes that create and use business data.


Rather, he said, it was “A Framework for Enterprise Architecture.”


In 1992, Sowa and Zachman proposed how to describe “the overall information system and how it relates to the enterprise and its surrounding environment.” (Ref. 6)

In 1993, Spewak defined a data-centric “EA planning” process “defining architectures for the use of information in support of the business and the plan for implementing those architectures”. (Ref 7.)

Again, Spewak seemed to draw more on the 1986 PRISM paper than on the Zachman Framework.


It was years before Zachman renamed his Information System framework as an EA framework.

Version 3 (below) attaches multiple meanings to both rows and columns.

It appears that row 6 instantiates the higher level descriptive artefacts in operational system instances.

Zachman Framework v3









Stakeholder perspective

Inventory sets

Process flows

Distribution networks

Responsibility assignments

Timing cycles

Motivation intentions

Scope Contexts


List inventory types

List process types

List distribution types

List responsibility types

List timing types

List motivation types

Business Concepts

Business management

Business entities & relationships

Business & input output

Business location & connection

Business role & work product

Business interval & moment

Business ends & means

System Logic


System entities & relationships

System & input output

System location & connection

System role & work product

System interval & moment

System ends & means

Technology Physics


Technology entities & relationships

Technology input & output

Technology & location connection

Technology role & work product

Technology interval & moment

Technology ends & means

Tool components


Tool entities & relationships

Tool input & output

Tool location & connection

Tool role & work product

Tool interval & moment

Tool ends & means

Operations Instance classes


Operations entities & relationships

Operations entities & relationships

Operations entities & relationships

Operations entities & relationships

Operations entities & relationships

Operations entities & relationships


But at the time of publication [the 1987 paper], the idea of Enterprise Architecture was such a foreign concept, Zachman said, that people didn’t understand what it was.

Even so, the origins of his ontological framework were already almost 20 years old by the time he first published them.

In the late 1960s, Zachman was working as an account executive in the Marketing Division of IBM.

His account responsibility was working with the Atlantic Richfield Company (better known as ARCO).

In 1969, ARCO had just been newly formed out of the merger of three separate companies,

Atlantic Refining out of Philadelphia and Richfield in California, which merged and then bought Sinclair Oil in New York in 1969.

“It was the biggest corporate merger in history at the time where they tried to integrate three separate companies into one company.

They were trying to deal with an enterprise integration issue, although they wouldn’t have called it that at the time,” Zachman said.

With three large companies to merge, ARCO needed help in figuring out how to do the integration.


Integration depends on standardising and exchanging business data – and is therefore dependent on information systems.


When the client asked Zachman how they should handle such a daunting task, he said he’d try to get some help.

So he turned to a group within IBM called the Information Systems Control and Planning Group and the group’s Director of Architecture, Dewey Walker, for guidance.

Historically, when computers were first used in commercial applications, there already were significant “Methods and Procedures” systems communities in most large organizations whose job was to formalize many manual systems in order to manage the organization, Zachman said.


Yes. I recall this meeting this community in the form of what we called the Operational Research (OR) department.


When computers came on the scene, they were used to improve organizational productivity by replacing the people performing the organizations’ processes.


Yes. Initially, computers digitised business data processing that had been done by people.

Software replaced purely clerical roles, in accounting, billing, payment processing, and business record keeping of all kinds.


However, because manual systems defined and codified organizational responsibilities, when management made changes within an organization, as they often did, it would render the computer systems obsolete, which required major redevelopment.


I suppose this did happen; though I don’t recall accounting, billing, payment and record keeping systems being so vulnerable to management restructuring.


Zachman recalled Walker’s observation that “organizational responsibilities” and “processes” were two different things.

As such, he believed systems should be designed to automate the process, not to encode the organizational responsibilities, because the process and the organization changed independently from one another.

By separating these two independent variables, management could change organizational responsibilities without affecting or changing existing systems or the organization.

Many years later, Jim Champy and Mike Hammer popularized this notion in their widely read 1991 book, “Reengineering the Corporation,” Zachman said.

According to Zachman, Walker created a methodology for defining processes as separate entities from the organizational structure.


In the 1950s and 60s, general system theory focused attention on the holistic processes of a system rather than its components.

In the 1970s and 80s, structured analysis methods separated business process flows from the functional and organisation hierarchies.


Walker came out to Los Angeles, where Zachman and ARCO were based, to help provide guidance on the merger.

Zachman recalls Walker telling him that the key to defining the systems for Enterprise purposes was in the data, not necessarily the process itself.

In other words, the data across the company needed to be normalized so that they could maintain visibility into the assets and structure of the enterprise.

“The secret to this whole thing lies in the coding and the classification of the data,” Zachman recalled Walker saying.


How to square this data-oriented approach with saying “The framework has nothing to do with information systems.”?


Walker’s methodology, he said, began by classifying data by its existence not by its use.

Since all of this was happening well before anyone came up with the concept of data modeling, there were no data models from which to design their system.

“Data-oriented words were not yet in anyone’s vocabulary,” Zachman said.

Walker had difficulty articulating his concepts because the words he had at his disposal were inadequate, Zachman said.


The primacy of data structures over process structures was a common theme in 1970s and 1980s structured analysis and design.

It is widely accepted today.


Walker understood that to have structural control over the enterprise, they needed to look at both processes and data as independent variables, Zachman said.

That would provide the flexibility and knowledge base to accommodate escalating change.

This was critical, he said, because the system is the enterprise.


Remember that phrase: “The system is the enterprise”.


Therefore, creating an integrated structure of independent variables and maintaining visibility into that structure are crucial if you want to be able to manage and change it.

Otherwise, he says, the enterprise “disintegrates.”


Again, integration depends on sharing and exchanging business data, and is therefore dependent on information systems.


Although Zachman says Walker was “onto this stuff early on,” Walker eventually left IBM, leaving Zachman with the methodology Walker had named “Business Systems Planning.”

(Zachman said Walker knew that it wasn’t just about the information systems, but about the business systems.)

According to Zachman, he inherited Walker’s methodology because he’d been working closely with Walker.

“I was the only person that had any idea what Dewey [Walker] was doing,” he said.

What he was left with, Zachman says, was what today he would call a “Row 1 methodology”—or the “Executive Perspective” and the “Scope Contexts” in what would eventually become his ontology.

According to Zachman, Walker had figured out how to transcribe enterprise strategy in such a fashion that engineering work could be derived from it.

“What we didn’t know how to do,” Zachman said, “was to transform the strategy (Zachman Framework Row 1), which tends to be described at a somewhat abstract level of definition into the operating Enterprise (Row 6), which was comprised of very precise instructions (explicit or implicit) for behavior of people and/or machines.”


That is curious on two counts, first the implication of a top-down process from strategy in row 1 to operations in row 6.

Zachman has long said there is no process or sequence in his framework; it is only a classification scheme for descriptive representations of business systems.


The second is the ambiguity of Zachman’s definitions of what row 6 contains. Is row 6 the operational system or a description of it?

Is it the “operating enterprise”?  That is to say, the instantiation (concretion, realisation or reification) of the activity systems described in row 5?

Is it the “precise instructions” for that operational behaviour? That is to say, the fullest and most elaborate description of the operating enterprise?


Zachman said that they knew that “Architecture” had something to do with the Strategy to Instantiation transformation logic but they didn’t know what architecture for enterprises was in those days.

His radical idea was to ask someone who did architecture for things like buildings, airplanes, locomotives, computers or battleships.

What the architecture was for those Industrial Age products.


That was to pursue what many consider to be a flawed idea, which surfaces in various assumptions such as:

·         the Information Revolution will or should follow the manufacturing principles of the Industrial Revolution

·         software engineering will or should be a branch of hardware, electrical or electronic engineering (as the IEEE assumed in the 1960s).

·         designing an activity system is or should be like designing hardware object or machine.


Zachman believed if he could find out what they thought architecture was for those products, he might be able to figure out what architecture was for enterprises

and thereby figure out how to transform the strategy into the operating enterprise to align the enterprise implementation with the strategy.

With this in mind, Zachman began reaching out to people in other disciplines to see how they put together things like buildings or airplanes.

He spoke to an architect friend and also to some of the aircraft manufacturers that were based in Southern California at the time.

He began gathering different engineering specs and studying them.

One day while he was sitting at his desk, Zachman said, he began sorting the design artifacts he’d collected for buildings and airplanes into piles.

Suddenly he noticed there was something similar in how the design patterns were described.

“Guess what?” he said “The way you describe buildings is identical to the way you describe airplanes, which turns out to be identical to the way you describe locomotives, which is identical to the way you describe computers…


The fact is: designing humans or computer activity systems is not like designing airplanes, locomotives and computers.

There is a huge difference between physical material systems and activity systems, especially human activity systems.


…Which is identical to the way you describe anything else that humanity has ever described.”


Hmm… general system theory suggests a different universal pattern for describing a business system.

It is a collection of actors that play roles in event-triggered processes to achieve desired effects by maintaining system state and/or producing outputs from inputs.

How to map system theory to the framework is unclear; but here is an attempt.


The Zachman framework questions

What and Who

When and How



General system theory elements

Actors, Roles and State

Events, Processes, Inputs and Outputs

Desired effects

Component and State Locations


Zachman says he really just “stumbled across” the way to describe the enterprise and attributes his discovery to providence, a miracle!

Despite having kick-started the discipline of Enterprise Architecture with this recognition, Zachman claims he’s “actually not very innovative,” he said.

“I just saw the pattern and put enterprise names on it,” he said.

Once he understood that Architectural design descriptions all used the same categories and patterns, he knew that he could also define Architecture for Enterprises.

All it would take would be to apply the enterprise vocabulary to the same pattern and structure of the descriptive representations of everything else.

“All I did was, I saw the pattern of the structure of the descriptive representations for airplanes, buildings, locomotives and computers, and I put enterprise names on the same patterns,” he says.

“Now you have the Zachman Framework, which basically is Architecture for Enterprises.

It is Architecture for every other object known to human kind.” Thus the Zachman Framework was born.

Zachman’s thinking in 2015 


Ontology vs. Methodology

According to Zachman, what his Framework is ultimately intended for is describing a complex object, an Enterprise.

In that sense, the Zachman Framework is the ontology for Enterprise Architecture, he says.

What it doesn’t do, is tell you how to do Enterprise Architecture.

“Architecture is architecture is architecture.

My framework is just the definition and structure of the descriptive representation for enterprises,” he said.


Which is to say the architecture is what is described in documented artefacts.

The framework has no process for “strategy to instantiation transformation logic”.


That’s where methodologies, such as TOGAF®, DoDAF or other methodological frameworks come in.

To create and execute an Architecture, practitioners need both the ontology—to help them define, translate and place structure around the enterprise descriptive representations

And they need a methodology to populate and implement it.

Both are needed—it’s an AND situation, not an OR, he said.

The methodology simply needs to use (or reuse) the ontological constructs in creating the implementation instantiations in order for the enterprise to be “architected.”


Yes, a comprehensive architecture framework needs both processes and products that are consistent with each other (implying an ontology or meta model).

But TOGAF has its own (different) ontology in the form of its Content Framework.

And TOGAF’s own architecture description framework is the Enterprise Continuum, which maps 4 levels of idealisation to 4 degrees of generalisation.





Common Systems

(Fairly generic)


(Fairly specific)


(Uniquely configured)

Requirements and Context





Architecture Continuum (Logical Models)

Foundation Architecture

Common System Architecture

Industry Architecture

Organisation Architecture

Solution Continuum (Physical Models)

Foundation Solutions

Common System Solutions

Industry Solutions

Organisation Solutions

Deployed solutions






The Need for Architecture

Unfortunately, Zachman says, there are still a lot of companies today that don’t understand the need to architect their enterprise.

Enterprise Architecture is simply not on the radar of general management in most places.

“It’s not readily acknowledged on the general management agenda,” Zachman said.

Instead, he says, most companies focus their efforts on building and running systems, not engineering the enterprise as a holistic unit.


In 2006, Ross, Weill and Robertson interpreted findings from MIT’s Center for Information System Research thus

"companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (“EA as Strategy” Ref. 13.)

However, not all enterprise executives want their enterprise to be a unified holistic system.


EA is very much about cross-organisational standardisation and integration of business processes.

But that is not the answer to every CEO’s problems. (See “What is EA not?” on the “EA roles and realities” page at avancier.website).


“We haven’t awakened to the concept of Enterprise Architecture,” he says.

“The fundamental reason why is [that] people think it takes too long and it costs too much.

That is a shibboleth – it doesn’t take too long or cost too much if you know what you’re doing and have an ontological construct.”


Well, it doesn’t take too long or cost too much if you describe business systems a high level of abstraction by idealisation (framework rows 1 and 2).

But it takes a staggering time and effort to describe business systems at a level of precision and detail close to operations (framework rows 4 and 5).


Zachman believes many companies are particularly guilty of this type of thinking, which he attributes to a tendency to think that there isn’t any work being done unless the code is up and running.

Never mind all the work it took to get that code up and running in the first place.


Notice the reference to “code up and running”.

Does Zachman assume the framework is primarily about the digitisation of business processes in software systems?


“Getting the code to run, I’m not arguing against that, but it ought to be in the context of the enterprise design.

If you’re just providing code, you’re going to get exactly what you have right now—code.

What does that have to do with management’s intentions or the Enterprise in its entirety?”


Surely all code is written to reflect those management intentions that have been cascaded down the management hierarchy?

Or else to do what lower level managers are empowered to direct as they see fit?

The point of agile methods like SCRUM isn’t to ignore management intentions – it is to clarify them.

(Agile development gurus treat system engineering as more like biology or sociology rather than hardware engineering, but all these analogies are flawed.)


As such, Zachman compares today’s enterprises to log cabins rather than skyscrapers.

Many organizations have not gotten beyond that “primitive” stage, he says, because they haven’t been engineered to be integrated or changed.


This is to compare the engineering of hardware with the organisation and management of human and computer activity systems.

In reality, most businesses, most of the time, rely on self-aware and motivated humans to respond to events as they see fit

Motivation is a social science topic – not an engineering topic – and is addressed to some extent in agile development methods.

People identify possible courses of action, choose one and perform activities with little or no predefined “code”.


According to Zachman, the perception that Enterprise Architecture is too costly and time consuming must change.

And, people also need to stop thinking that Enterprise Architecture belongs solely under the domain of IT.


We all know EA starts with the business roles and processes the business needs to perform to deliver business processes

It isn’t that we think EA belongs under IT; it is rather that we can’t get people outside IT excited about EA.


“Enterprise Architecture is not about building IT models.

It’s about solving general management problems,” he said.

“If we change that perception, and we start with the problem and we figure out how to solve that problem.

And then, oh by the way we’re doing Architecture, then we’re going to get a lot of Architecture work done.”


Certainly, the elevator pitch for EA should be business-oriented, as distanced from IT as we can make it.

But digitisation of business roles and processes, and exploitation for business information for management purposes, will depend on IT.

And how the enterprise works, its business terms, concepts and rules is indeed documented in data models, domain models and “up and running code”.

(Cf. “Domain-Driven Design” Evans, 2003.)


Zachman believes one way to do this is to build out the Enterprise Architecture iteratively and incrementally.

By tackling one problem at a time, he says, general management may not even need to know whether you’re doing Enterprise Architecture or not, as long as their problem is being solved.

The governance system controls the architectural coherence and integration of the increments.

He expects that EA will trend in that direction over the next few years.


In 2003, Zachman listed key points for EA, emphasising that without a documented architecture, you are implementing, not architecting. (Ref. 11.)

As far as Zachman is concerned, building the enterprise architecture is inseparable from describing it.

If you ain’t building and maintaining architectural models, you ain’t doing architecture.


“We’re learning much better how to derive immediate value without having the whole enterprise engineered.

If we can derive immediate value, that dispels the shibboleth—the misperception that architecture takes too long and costs too much.

That’s the way to eliminate the obstacles for Enterprise Architecture.”


Surely – before and without EA - Solution Architects have been able to deliver immediate value to business system sponsors?

And agile development methods are effective in delivery of silo systems – at least where the preconditions for agility apply (see Avancier’s guidance on this).


As far as the skills needed to do EA into the future, Zachman believes that enterprises will eventually need to have multiple types of architects with different skill sets to make sure everything is aligned.

He speculates that someday, there may need to be specialists for every cell in the framework,

saying that there is potentially room for a lot of specialization and people with different skill sets and a lot of creativity.

Just as aircraft manufacturers need a variety of engineers—from aeronautic to hydraulic and everywhere in between—to get a plane built.

One engineer does not engineer the entire airplane or a hundred-story building or an ocean liner, or, for that matter, a personal computer.

Similarly, increasingly complex enterprises will likely need multiple types of engineering specialties. No one person knows everything.


Yes, EA and SA teams have long been composed from people who are specialise in different architecture domains.


“Enterprises are far more complex than 747s.

In fact, an enterprise doesn’t have to be very big before it gets really complex,” he said.


Yes, human and computer activity systems are more complex than mechanical systems.

A large business is supported and enabled by billions of lines of code, and thousands of human brains – said to be the most complex system of all.


“As enterprise systems increase in size, there is increased potential for failure if they aren’t architected to respond to that growth.


Are there statistics to support this? Small businesses can fail. Well integrated businesses can fail.

Enterprises that grow by acquisition may succeed by not integrating their acquisitions (c.f. Richard Branson’s Virgin?).


And if they fail, the lives and livelihoods of hundreds of thousands of people can be affected, particularly if it’s a public sector Enterprise.”

Zachman believes it may ultimately take a generation or two for companies to understand the need to better architect the way they run.

As things are today, he says, the paradigm of the “system process first” Industrial Age is still too ingrained in how systems are created.

He believes it will be a while before that paradigm shifts to a more Information Age-centric way of thinking…


How to square “Information Age-centric thinking” with “The framework has nothing to do with information systems.”?


…where the enterprise is the object rather than the system.


How to square this with “The system is the enterprise” (above) and “EA regards the enterprise as a system” TOGAF?

I don’t know what Zachman means by system (or indeed by idealisation-reification), but I doubt he has general system theory in mind.


“Although this afternoon is not too early to start working on it, it is likely that it will be the next generation that will make Enterprise Architecture an essential way of life like it is for buildings and airplanes and automobiles and every other complex object,” he said.


Concluding remarks

Architecting human and computer activity systems is not much like architecting hardware objects and machines.

The former are not only more complex and more flexible, but different in nature and fundamentally dependent on information flows.

General system theory (which emerged in the 1950s) provides an underpinning logic for the description and design of activity systems.

Zachman’s thinking in 2011

I can’t currently locate where I copied the dozen points below from, but they are direct quotes.


JZ 1 Most people who come from IT today are thinking of building and running systems and not about engineering and manufacturing enterprises.

Most who work in an EA function are very much concerned with how well IT supports and enables business systems.

Zachman’s framework emerged out of “business system planning”; yet he seems to pay no heed to general system theory.


JZ 2 My argument here is that the end objective is to engineer and manufacture the enterprise, not simply to build and run systems

To engineer the enterprise (system) is an end of EA. But sure several other business functions serve the same end?


JZ 3 your typical CEO says, “I have spent a lot of money in IT but I don’t think what you guys are doing with that money is in line with the plans I have for the enterprise.”

The typical CEO may well be concerned about IT cost.

But the industry average IT cost is less than 5% of revenue, with half or more of that spent “keeping the lights on”.


JZ 4 Architecture enables you to accommodate complexity and change. 

If you don’t have EA, your enterprise is not going to be viable in an increasingly complex and changing external environment!

EA tends to centralise control and integrate silo systems. Agility is more usually regarded as implying independence of local units from central command and control.


JZ 5 … if you didn’t understand the EA, then apparently small changes could potentially render the whole enterprise dysfunctional.

Perhaps, but this seems more an article of faith than a demonstrable truth.


JZ 6 We can simulate performances of airplanes in 3D, why can’t we do it with enterprises? 

Because it is one thing to model airplane behaviour in a knowable and reasonably predictable context (moving air).

And quite another to model a business system in an unknowable and unpredictable market place.

This is where we should be heading –where we can actually simulate how certain changes or decisions will affect the enterprise.

We can simulate the performance of processes, but not their effects on external entities.

We can build “system dynamics” models, but they are not reliable predictors, for various reasons, not least the staggering complexity of business systems.

The closest we get to what Zachman wants is customer acceptance testing – which requires a fully coded system.


JZ 7 The problem is that the enterprise strategy is not clearly manifested … there is an inordinate focus on optimizing current performance at the expense of investing in the future.

There will always be a natural and healthy tension between the strategic and the tactical.

Investing in the future implies a level of certainty about the future which is difficult to achieve in a rapidly changing market place.


JZ 8 Zachman Framework, a schematic representation of the various components in an enterprise and their relation with each other - also tells you how a change in any one component or artifact will affect other artifacts related to it.

The framework alone does not do that

What you need (with or without the framework) is an EA repository that conforms to a known meta model.

A purpose of an EA repository is to facilitate change impact analysis, but using it to predicting change impacts is a step beyond that.


JZ 9 The process of converting an idea into reality needs to go through a set of transformations.

That appears to turn the rows of the ZF into a top down process – which Zachman has always denied as implied by the framework.


JZ 10 That is, you need to go through this process IF you care that the instantiation bears any resemblance to the idea that you had in the first place.

Agilists say the idea you had in the last place is better than the one you had in the first place!


JZ 11 Few enterprises today have descriptive representations that depict how the enterprise works.

Architecture provides the structure to predict the impact of change, reduce the risk and maintain enterprise viability in a changing environment

It is one thing to describe the EA in repository for change impact analysis, another to describe enterprise behaviour so well it can be used to predict the effect of changes.


JZ 12 EA is useful in those areas which minimize general operating costs, change enterprise with minimum time disrupt to cost, and are able to dynamically adapt to demands placed on an enterprise by the external environment.



In 1980: Business System Planning was a methodology used by IBM

1980? “Business Systems Planning” see the Wikipedia entry, and

the web site of Robinson College of Business, Georgia State University.


In 1982, Zachman spoke of the need to raise Business System Planning to the “enterprise level”.

1982 "Business Systems Planning and Business Information Control Study: A comparison"”John Zachman, in IBM Systems Journal 21(1). p32.


In 1986, enterprise-level architecture was divided into business, data, applications and infrastructure technology domains.

1986  Dispersion and Interconnection: Approaches to Distributed Systems Architecture  the PRISM report, from a consortium including IBM, DEC and others


In 1987, Zachman introduced an enterprise-wide Framework for Information System Architecture.

1987 "A Framework for Information Systems Architecture". 

John A. Zachman in IBM Systems Journal, vol 26, no 3. IBM Publication G321-5298.


In 1989, The NIST Enterprise Architecture Model was a five-layer reference model that related business, information system, and technology domains.

1989 “Enterprise Architecture Model” National Institute of Standards and Technology


In 1992, Sowa and Zachman proposed how to describe “the overall information system and how it relates to the enterprise and its surrounding environment.”

1992 “Extending and formalising the information systems architecture framework”.

Sowa and Zachman in IBM Systems Journal, Vol 31, No 3


In 1993, Spewak defined a data-centric planning process “defining architectures for the use of information in support of the business and the plan for implementing those architectures”.

1993 “EA Planning  by Stephen Spewak

See entry in Wikipedia for references.


In 1996, Each federal agency’s CIO was made responsible for “developing, maintaining and facilitating the implementation of a sound and integrated IT architecture for the executive agency.”

1996 “IT Management Reform Act” (Clinger Cohen Act)


Around 1997, Zachman recast his Framework for Information System Architecture as a Framework for Enterprise Architecture

1997? For references to his EA Framework, see Zachman’s entry in Wikipedia


In 1998, FEAF said “The architecture team generates a sequencing plan for the transition of systems, applications, and associated business practices predicated upon a detailed gap analysis [between baseline and target architectures].”

1999 “Federal EA Framework

Federal CIO Council


In 2001, “A practical guide to Federal Enterprise Architecture” started: “An enterprise architecture establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient information technology environment.”

2001 “A practical guide to Federal Enterprise Architecture

Chief CIO council


In 2003, Zachman listed 10 key points for EA, emphasising that without a documented architecture, you are implementing, not architecting.

2003 “The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing.” By John A. Zachman. Zachman International


By 2005, many EA frameworks existed, including the “Integrated Architecture Framework” (IAF) from Cap Gemini

???? “Integrated Architecture Framework” (IAF) Cap Gemini


In 2006, Findings from MIT’s Center for Information System Research were interpreted thus "companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." The business process operating model concept was defined.

2006 “EA as Strategy

Ross, Weill and Robertson (out of MIT CISR)


This 2011 source lost



In 2015, Prior to The Open Group’s San Diego event, The Open Group spoke to Zachman

A paper for The Open Group conference, February 2015


Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0           18/08/2013 11:18

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see  http://creativecommons.org