A
Critique of Zachman’s Framework
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.
Contents
The
development of the Zachman Framework.
Zachman
recalling his thinking up to 1987
The
challenge presented by the numbers
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.
A big question facing an enterprise architecture team is: What is the
"right" level of abstraction for an architecture description? The answer
provided by Zachman Framework™ is “every
level”.
The Zachman Framework is a structure for classifying architecture description artefacts.
It was presented in 1987 as an “Information System Architecture Framework, but since the mid 1990s has been called an EA Framework.
At first sight, the Zachman Framework appears easy to understand.
But when I ask people how they use it, it turns out some don’t understand it and few use it as Zachman envisages.
In 2008, the Zachman International web site quoted Zachman as saying:
“The Zachman Framework is a schema - classifications that have been in use for literally thousands of years.
· The first is the fundamentals of communication found in the primitive interrogatives: What, How, When, Who, Where, and Why. It is the integration of answers to these questions that enables the comprehensive, composite description of complex ideas.
· The second is derived from reification, the transformation of an abstract idea into an instantiation that was initially postulated by ancient Greek philosophers and is labeled in The Framework: Identification, Definition, Representation, Specification, Configuration and Instantiation.”
So in its purest form, Zachman’s schema is a taxonomy that maps 5 levels of abstraction by idealisation in system description to six analysis questions (in the columns below).
In this form, the schema can be represented like this.
|
Question Idealisation |
What |
How |
Where |
Who |
When |
Why |
|
Identification |
|
|
|
|
|
|
|
Definition |
|
|
|
|
|
|
|
Representation |
|
|
|
|
|
|
|
Specification |
|
|
|
|
|
|
|
Configuration |
|
|
|
|
|
|
|
Instantiation |
|
|
|
|
|
|
Zachman, along with most enterprise architects, is not so much concerned with operational systems (the bottom level) as with system description and documentation in the levels above.
Zachman presents these two dimensions of system description as fundamental (which is to imply they are more important than the dimensions used in other EA schema).
Remember “The first [classification] is … the primitive interrogatives” This reflects the six questions in the couplet by Rudyard Kipling: “I keep six honest serving-men (They taught me all I knew); their names are What and Why and When And How and Where and Who.”.
Remember “The second [classification] is derived from … the transformation of an abstract idea into an instantiation.” However, this classification has been presented (from Zachman’s initial paper, 1987) as levels of stakeholder.
The framework was for a long time introduced as: “A logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to managers and to developers of Enterprise systems. It uses a grid of 6 basic questions (What, How, Where, Who, When, and Why) asked of 5 stakeholder groups (Planner, Owner, Designer, Builder and Subcontractor).”
This description is represented in the schema below.
|
Question Stakeholder |
What |
How |
Where |
Who |
When |
Why |
|
Planner |
|
|
|
|
|
|
|
Owner |
|
|
|
|
|
|
|
Designer |
|
|
|
|
|
|
|
Builder |
|
|
|
|
|
|
|
Subcontractor |
|
|
|
|
|
|
|
Operations |
|
|
|
|
|
|
The schema below presents the essence of the Zachman Framework version 1.
Notice how Zachman mapped the six questions to architectural elements, and levels of abstraction to stakeholders.
|
Zachman Framework v1 |
|
|
What |
How |
Where |
Who |
When |
Why |
|
Idealisation |
Viewpoint |
Stakeholder |
Data |
Function |
Network |
People |
Time |
Motivation |
|
Contextual |
Scope |
Planner |
|
|
|
|
|
|
|
Conceptual |
Enterprise |
Owner |
|
|
|
|
|
|
|
Logical |
System |
Designer |
|
|
|
|
|
|
|
Physical |
Technology |
Builder |
|
|
|
|
|
|
|
Out of context |
Detailed |
Subcontractor |
|
|
|
|
|
|
|
Functioning enterprise |
Functioning enterprise |
Operations |
|
|
|
|
|
|
Zachman speaks of his framework as reflecting: “…the structure of the descriptive representations of buildings, airplanes and other complex industrial products.” That is, it is not specific to IT.
Zachman expects completion of the cells to determined by users of the schema. “Any appropriate approach, standard, role, method, technique, or tool may be placed in it. The schema can contain global plans as well as technical details, lists, and charts as well as natural language statements.
Although the framework could be used for any kind of system description, Zachman worked for IBM, spoke to an IT audience, and presented information systems architecture as the key to EA. "To keep the business from disintegrating, the concept of information systems architecture is becoming less of an option and more of a necessity. Enterprise Architecture provides the blueprint, or architecture, for the organization's information infrastructure."
Zachman has insisted that the levels are not stages in a process or levels of top-down decomposition: “the schema says nothing about the processes for developing viewpoints or conformant views, or the order in which they should be developed.” Note also that the abstraction from bottom to top is by idealisation, not by composition.
Zachman grew uncomfortable about what he saw as misinterpretations.
E.g. “What” is not only about data. So he changed that to “inventory sets”.
And he saw the levels misinterpreted as decomposition. So the levels were relabelled to show reification.
In 2009, Zachman published version 2 of the framework.
|
Zachman Framework v2 |
|
What |
How |
Where |
Who |
When |
Why |
|
Idealisation |
Stakeholders |
Inventory sets |
Process transformation |
Network nodes |
Organisation groups |
Time periods |
Motivation reasons |
|
Scope Contexts |
Strategists & theorists |
|
|
|
|
|
|
|
Business Concepts |
Enterprise leaders & owners |
|
|
|
|
|
|
|
System Logic |
Architects & designers |
|
|
|
|
|
|
|
Technology Physics |
Engineers & builders |
|
|
|
|
|
|
|
Component assemblies |
Technicians & implementers |
|
|
|
|
|
|
|
Operations - Instance
classes |
Workers & participants |
|
|
|
|
|
|
Zachman has been known to say: “One day you [or your enterprise] will regret not having completed the schema”.
By completed he means that every cell should contain architecture description, every level of architecture description should be completed, and every level should be completed to the lowest possible level of detail.
2011 saw version 3 published.
|
Zachman Framework v3 |
|
What |
How |
Where |
Who |
When |
Why |
|
Idealisation |
Stakeholder perspective |
Inventory sets |
Process flows |
Distribution networks |
Responsibility assignments |
Timing cycles |
Motivation intentions |
|
Scope Contexts |
Executive |
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 |
Architect |
System entities & relationships |
System & input output |
System location & connection |
System role & work product |
System interval & moment |
System ends & means |
|
Technology Physics |
Engineer |
Technology entities & relationships |
Technology input & output |
Technology & location connection |
Technology role & work product |
Technology interval & moment |
Technology ends & means |
|
Tool components |
Technician |
Tool entities & relationships |
Tool input & output |
Tool location & connection |
Tool role & work product |
Tool interval & moment |
Tool ends & means |
|
Operations Instance classes |
Enterprise |
Operations entities & relationships |
Operations entities & relationships |
Operations entities & relationships |
Operations entities & relationships |
Operations entities & relationships |
Operations entities & relationships |
The schema is based on simple ideas.
The apparent simplicity of the schema appeals to a management audience.
And some have used the schema to good effect in exposing the lack of system description in an enterprise.
The schema is today promoted by the Zachman Institute for Framework Advancement, from which full details are available on a commercial basis.
This paper is about the theoretical basis of EA description schema, of which the Zachman Framework is the most famous.
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.
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.
|
Question Idealisation |
What |
How |
Where |
Who |
When |
Why |
|
Identification |
|
|
|
|
|
|
|
Definition |
|
|
|
|
|
|
|
Representation |
|
|
|
|
|
|
|
Specification |
|
|
|
|
|
|
|
Configuration |
|
|
|
|
|
|
|
Instantiation |
|
|
|
|
|
|
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 |
|
What |
How |
Where |
Who |
When |
Why |
|
Idealisation |
Stakeholder perspective |
Inventory sets |
Process flows |
Distribution networks |
Responsibility assignments |
Timing cycles |
Motivation intentions |
|
Scope Contexts |
Executive |
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 |
Architect |
System entities & relationships |
System & input output |
System location & connection |
System role & work product |
System interval & moment |
System ends & means |
|
Technology Physics |
Engineer |
Technology entities & relationships |
Technology input & output |
Technology & location connection |
Technology role & work product |
Technology interval & moment |
Technology ends & means |
|
Tool components |
Technician |
Tool entities & relationships |
Tool input & output |
Tool location & connection |
Tool role & work product |
Tool interval & moment |
Tool ends & means |
|
Operations Instance classes |
Enterprise |
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 |
Why |
Where |
|
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.
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.
|
Generalisation Idealisation |
Foundation (Universal) |
Common Systems (Fairly generic) |
Industry (Fairly specific) |
Organisation (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.
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.
Is the schema the definitive taxonomy? Are the two dimensions of the schema more fundamental or more important than other dimensions of description, other facets of architecture description?
Notice that the columns and levels have acquired two or three labels.
This implies the schema is not normalised.
You might conclude the schema should have a 4 or 5 dimensions, and several hundred cells to be completed with documentation.
The meanings of the levels
The bottom level is operational systems.
The step from level 6 to level 5 is idealisation
from operational system to system description.
The steps from level 5 upwards are increasingly idealised
system description.
Zachman says the kind of description changes at each level.
Well - it might change - but it does not have to.
It is possible to describe physical, logical and conceptual data models
using the same entity-relationship diagram notation.
And equally possible to define a computer program and a business process using the same kind of flow chart.
The levels conflate three concepts.
Why map business, information system and technology to conceptual, logical and physical? Could we not have conceptual, logical and physical descriptions of each (business, information system and technology)?
The stakeholders named in the levels might be the primary stakeholders in one context, but not in others.
And why imply that a stakeholder is interested in only one level of idealisation?
The meanings of the columns
The 6 questions are not as rigorously revealing as you
might hope.
Asking "who performs that activity?" reveals
human actors, but not animal or mechanical actors, for which the question
"what does that?" would be appropriate.
Asking “what exists” question doesn’t distinguish between
active components and passive objects.
To reveal the objects, "to whom or what was it
done?" should be asked.
Other questions that could be asked include whence, whither
and whereto.
The mapping from six questions to six elements is debatable.
Mapping “what” and “how” to structure (inventory) and behaviour (process)
sounds plausible.
However, other structures in the enterprise inventory include human
resources (the answer to who) and networks (the answer to where).
You can reasonably ask most questions (why, what, how…) of
most elements (data, function, network…), and different people will interpret
the questions differently.
One person’s how is answered by another person’s what. And
vice-versa.
A given answer, say a process, could be the answer to a what, how, who or
when question.
The questions who? And what? might
answered by one person with a human actor and another with a mechanical actor.
The question why? is open to conflicting answers
from different stakeholders, and their answers could feature in answers to
other questions.
Other observations
An obvious limitation is that the schema has only two dimensions.
Other dimensions may prove useful.
In practice, the schema is rarely used as a normalised structure.
The 30 cells do not map neatly to 30 distinct entities or 30 specific architecture description deliverables that architects agree are a consistent and comprehensive set.
Some decide to leave some cells empty and to populate other cells with two or three artefacts.
The more people find it desirable and practical to do this, the less convincing is the proposal that the schema is a definitive taxonomy.
Technical infrastructure architects and IT service managers tend to find the schema disappointing.
Zachman doesn't really speak to the infrastructure/technical architect or IT services manager.
Zachman presents a vision - the completed framework – as an ideal we would like to have one day. Is that realistic?
As a rule of thumb, people find it hard to maintain the integrity of a structure with 1,000 elements.
Business architects struggle to maintain an enterprise structural description with 1,000 business functions in it.
Application portfolio managers struggle to maintain an application catalogue with 1,000 applications in it.
Software architects struggle to maintain a single application structure with 1,000 modules (classes) in it.
If our large enterprise has 32 business functions, which each use 32 applications, which each contain 32 components, which each contain 32 modules (classes), which each offer 32 services, then the mathematics suggests there will be over 33 million basic software operations.
The numbers in the table are not beyond the bounds of what you might expect to find in a large enterprise.
Numbers of this magnitude imply a huge documentation and maintenance task.
It seems, in practice, that people are simply not capable of maintaining five levels of system description.
In a large enterprise, various people do maintain catalogues and directories that record diverse structures, separately.
E.g. you can imagine:
|
People in this role |
maintaining |
with
hundreds or thousands of |
|
Business management |
a balanced score card |
objectives. |
|
Estate management |
records of |
workplace locations. |
|
HR |
a directory |
employees. |
|
Business architecture |
a business process catalogue |
processes. |
|
Data architecture |
a data asset register |
databases. |
|
Application architecture |
an application portfolio |
applications. |
|
IT asset management |
an asset register |
mobile devices. |
|
Data centre operations |
a database |
servers and network devices. |
Presumably each structures is useful on its own – to different people working in different domains at different levels of granularity, and with different concerns.
But we know records are usually flawed, and just imagine the number of cross-references that could in theory be maintained.
Consider the labour involved in creating the records, and then in change management processes.
One change can affect artefacts at several levels of documentation in several columns.
Some have regarded populating the schema for an enterprise as an end in itself.
Is that useful? Does an enterprise need to do it?
Zachman frequently referred by way of example to the highly safety-critical and tightly regulated business of aircraft engineering.
It is just about conceivable that Boeing maintain five levels of idealised description - covering each nut, bolt and fastener used in their aeroplanes.
But does Boeing maintain equally detailed 5-level descriptions of their marketing, sales and payroll processes?
Most businesses, especially service industries, are rich, complex human activity systems that depend on human beings continually making judgements about what to do and how to do it.
Many business processes are not predictable or repeatable enough to be documented at all, let alone fully described at several levels of idealisation.
A “comprehensive, composite description of complex ideas” documenting an enterprise from top to bottom and side to side is simply inconceivable.
We are not talking about the architecture of a mechanical structure like the Eiffel tower or a Boeing 747.
We are talking about the architecture of staggeringly complex human and computer activity systems that are in continual flux.
Surely, the weight of change management will always kill any attempt to do this?
The hope of fully populating the Zachman framework probably lies in a) keeping the documentation at a high level (say 3rd or 4th level of business function decomposition) and b) making the enterprise self-documenting in some way (e.g. using server and network management tools for the infrastructure and employees to document their roles and processes);
In short, the main practical problem is that we simply cannot afford to record and maintain specifications of an enterprises’ operational systems at five different levels of abstraction by idealisation.
We do need a filing system for architecture documentation.
In 1987, the Zachman Framework was an innovation, and ahead of the game.
The schema is based on simple ideas.
The apparent simplicity of the schema appeals to a management audience.
Some have used the schema to good effect in exposing the lack of system description in an enterprise.
The schema is today promoted by the Zachman Institute for Framework Advancement, from which full details are available on a commercial basis.
My own view is that the theoretical basis for Zachman’s framework is very weak.
As other frameworks have developed, the premises on which the schema is based look less convincing.
Read “A Critique of Zachman’s Framework”.
Zachman’s top-to-bottom (ideal to real) dimension appears in other EA description frameworks.
There is no shortage of other indexes you can use to organise architecture documentation.
The table below
lists seven dimensions that could be used to classify architecture description
artefacts.
|
Roles |
Enterprise
Architect - Solution Architect - Software Architect - Technical Architect. |
|
Stakeholders |
Owner - Manager
- Buyer - Supplier - Designer - Builder - Tester - User - Operator -
Maintainer. |
|
Timeframe |
Long term or
strategic target - Short term or tactical target - Change to baseline. |
|
Idealisation |
Conceptual model
- Logical model - Physical model - Physical material. |
|
Generalisation |
Universal -
Fairly generic - Fairly specific - Uniquely configured. |
|
Composition |
Coarse-grained composite
- Mid-grained composite - Fine-grained composite - Elementary part. |
|
Omission of
detail |
Nominal -
Sketchy - Elaborate - Complete. |
The practical challenge with all system description is that the level of abstraction must
· high enough to be maintained (in an acceptable time and cost) and
· low enough to get enable change impact analysis.
|
1 |
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. |
|
2 |
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. |
|
3 |
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 |
|
4 |
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. |
|
5 |
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 |
|
6 |
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 |
|
7 |
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. |
|
8 |
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) |
|
8 |
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 |
|
9 |
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 |
|
10 |
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 |
|
11 |
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 |
|
12 |
By 2005, many EA frameworks existed, including
the “Integrated Architecture Framework” (IAF) from Cap Gemini |
???? “Integrated
Architecture Framework” (IAF) Cap Gemini |
|
13 |
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) |
|
14 |
This 2011 source lost |
|
|
15 |
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