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.
Contents
Zachman
recalling his thinking up to 1987
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.
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.
|
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.
|
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