All the Reasons Why You Can't Do Architecture
or ("We Has Met the Enemy and He Is Us")
by John A. Zachman, July 2000
I recently received a note from a friend of mine who was valiantly trying to initiate
some architectural activity in a very large enterprise within a very important industry
sector here in the U.S. The note outlined all of the objections to doing architecture
that my friend was encountering.
The note is not significant because of one particular enterprise, nor of one particular
industry. The note is significant because these are the kind of objections I hear
day after day from many enterprises in many industries and the objections are coming
from IT, not the Enterprise! I have copied the objections almost verbatim
Here is his intro:
"Dear John - By the way - I am getting some pretty significant pushback from
the IT leaders. They do not want to do architecture (i.e. create models) for
|Objection 1: "Let's just use architecture principles instead of building
any models. We can figure out what we need in IT (without any business involvement)
and the business is going to pay for it anyway. We don't need any models."
Response 1: First, regarding "principles" -- I think "principles"
are a great idea, but when people say "architecture principles" these days,
they tend to have in mind simply principles related to hardware and systems software
and overlook principles that relate to the systems (logical) architecture or to the
business, itself. I would suggest that the hardware and systems software are merely
the "container." The business (and therefore the applications systems that
derive from the business) are the "CONTENTS."
It is the CONTENTS that the enterprise really cares about. How do you figure out
what the "container" has to look like until you understand what you are
going to put into it, that is, the CONTENTS, the ENTERPRISE? If you define the container
first, you are bound to constrain the contents, that is, you are bound to constrain
I grant you, there is one hardware and systems software principle that I can think
of that doesn't require any understanding of the business and that is, "REDUCE
DIVERSITY." Having one of every kind of mainframe, server, workstation, operating
system, DASD, database management system, network, network operating system, programming
language, middleware, etc., etc. known to mankind is a luxury beyond most enterprises'
ability to fund, not to mention change!
Interfacing hardware and systems software (with "middleware," for example)
-- or "interfacing" anything, for that matter -- quickly gets out of control
because the number of connections (interfaces) between "n" points is "n
squared minus n over 2." As the number of points increases, the number of interfaces
If that isn't enough, if you add enough interfaces, the technology ultimately
will atrophy. It will become impossible to change anything because all the points
are hard bound together with customized, unique "interfaces!" That's one
of the principal problems we have with the "legacy" today!
Next, assuming that "Reducing Diversity" is a good
Technology Architecture (Col. 3, Row 4 )
principle, along with whatever other good Information Technology principles you want
to define, the question then becomes: without some business involvement in producing
some business models (i.e. Rows 1 and 2 models), coupled with the other Enterprise
Architecture models (i.e. Row 3 and the other Row 4 models), how are you going to
decide what specific hardware and specific systems software to put in what specific
location? How do you draw any supportable, logical conclusions about the technology
without any architectural models?
Assuming for a moment you can somehow figure out (without any business models)
what technology to put in what location, after you get a few thousand nodes in the
network, and you have no record (that is, no models, no Architecture) of what hardware
is in what location, with what configuration, running what systems software with
what configuration and what version, performing what application functions in what
languages using what data in what format in what database management system, and
so on, and so on Ö and somebody wants to change something Ö by anytime
tomorrow morning?!! Now what do you do? Go out and start taking a physical inventory
of all the technology (containers and contents) from scratch?!! Good luck!
I would argue, "principles" are nice Ö but there is no substitute
for architecture (actual models) when things get complicated and start to change.
One comment regarding "the business is going to pay for it anyway!!!"
-- what is the logic here?? Has someone lost sight of who is the customer and who
is the supplier? Does the business exist to support I/S? Or, does I/S exist to support
I would argue that until we know what the business is and what its values and
intentions are, (that is, until we have some Rows 1 and 2 Business Models), we can
only make assumptions about the technology requirements -- and then the question
is going to be, how good are our assumptions? How good have our technology assumptions
been over the last 50 years? Is everybody happy? Is the business happy? Are we happy?
Is anybody happy?
Last Ö You NEED models Ö and the business truly WILL BE HAPPY to pay
for them, especially when they find out models are 20 to 30 times CHEAPER AND FASTER
than you can deliver implementations without models, like you are trying to do today
(see Response 5 to Objection 5, below).
|Objection 2: "The business thinks we have been trying to serve their
needs all along. We better not show up now and suggest we don't know how the business
works and therefore, need to build models. It will create one heck of a problem for
us in IT! The users don't want to build models anyway! They want action! We better
just pick an implementation project and work on that."
Response 2: Good night!!! This is the ostrich approach. We'll just bury
our head in the sand and hope the problem goes away before somebody blows off our
tail feathers! I would suggest that we would be far better off to be the ones that
identify the problem and advance OUR solution rather than risking somebody else deciding
that WE are the problem and advancing THEIR solution!
For example, if the enterprise does not feel that whatever we are implementing
is aligned with their needs, and they are not getting value for the money spent on
IT Ö how else do you intend to get our implementations aligned with what the
enterprise needs, short of defining what the enterprise needs (that is, short of
building the Rows 1 and 2 models) and then deriving our implementations (Rows 3,
4, and 5 models) directly from their own specification of the enterprise needs (Rows
1 and 2 models)? We are a lot better off surfacing the issue by actually solving
the problem architecturally than getting our tail feathers out-sourced out of frustration.
Another observation Ö if the users are registering a little frustration with
us and they are getting testy about building models or they are demanding some action,
then I would argue that redoubling our efforts to write more code is not going to
fix the problem. One definition of insanity I have heard is "continuing to do
the same thing and expecting different results." We have been knocking our brains
out writing code for 50 years Ö and if, after all this time and all this code,
the users are still unhappy, I would suggest something has to change.
People ask me all the time, "Well, WHO has successfully implemented Architecture?!!"
MY reaction to that one is, "Well WHO has successfully implemented the 'you
start writing the code and I'll go find out what the users have in mind' approach?!!"
In every enterprise I have seen where the users have become involved in building
the Rows 1 and 2 models, their reaction tends to be, "Well, that makes sense!"
Or, "Well Ö this is the first time I really understood how this business
On the other hand, they do get a little testy about models when we are trying
to get them to define Rows 4 or 5 models. Their reaction in that case tends to be,
"Look! I hired YOU to be the IT person! I am a BUSINESS person!!" I would
argue, the users are not interested in becoming programmers or database administrators,
but they have no problem building business models that serve their own business purposes.
|Objection 3: "We are going to buy some packages over the next several
months, therefore we don't need to do architecture. The packages are our architecture."
Response 3: You are absolutely RIGHT!! I have made the assertion time and
time again that "the system IS the Enterprise" and if you are buying packages,
you are buying SOMEONE ELSE'S design (architecture) for YOUR enterprise.
(I wrote a whole article, "Packages Don't Let You Off the Hook" for
a previous issue of the Newsletter and I won't attempt to reiterate all the points
I made in that article here.)
I will raise one question, "how are you going to decide which package you
are going to buy, that upon installation will BECOME YOUR ENTERPRISE?" Guess?
If you don't have any models, guessing is the only option. And, the last time I implemented
some packages, I seem to remember, "the devil is in the details!" Guessing
is HIGH RISK!!
Here's another question, when you buy the package, are you buying an ARCHITECTED
package? Ö or, are you buying a bunch more spaghetti code? If you are buying
a bunch of spaghetti code, you don't have to buy that from somebody else, you already
have a bunch of that in the legacy!
On the other hand, if you are buying an ARCHITECTED package, have you actually
SEEN the architecture (that is, the models)? And, oh, by the way, how do those models
compare with your enterprises' models? (Of course, that is the way to select the
package Ö based on the fit between the package architecture and your Enterprise
Architecture.) And, oh, one more question, how will the new package architecture
"integrate" with all the other applications that presently constitute your
"legacy?" Or, maybe you just don't want to be bothered about integration
as you are just trying to add some more applications (packages) and increase the
size and unmanageability of the legacy!! (Read irony here.)
I would suggest, these are the kind of questions that someone, hopefully somebody
from IT, should ask BEFORE you actually get money invested in the package and
somebody else, like the Enterprise, starts getting frustrated!
|Objection 4: "We need the system (technology) architecture in 3 months.
We don't have time to build a bunch of models."
Response 4: Oh Ö 3 months Ö hmmmmm Ö that's a little short!
Here's an idea Ö why don't you just use the architecture you have now?? You
could do that in ZERO months!
Oh, you say Ö you are not happy with, or there is something the matter with
your current architecture? If you are going to build your new architecture in 3 months
Ö and not build any models Ö what is your logic for why you are going to
be happier with (or why your new architecture is going to be any better than) your
Oh, you say, your current architecture is not really architecture because it just
happened Ö you never Ö you never "engineered" it, that is, you
never actually built any Ö models Ö Hmmmmm, tell me again -- if you don't
have time to build any models, why will your new architecture without models be any
more "architecture" than your current lack of architecture without models?
If you want Architecture then, by definition, you are going to have to architect
|Objection 5: "When it comes to the application functions that we need,
we don't have time to build them anymore, we have to buy them. They are too big and
too complex to build with the few good programmers and technical types that we have.
All we have to do is make them [the purchased functions] work together."
Response 5: Clearly, we are running out of time -- but banking on buying
functions, particularly big and complex functions may not be the solution to the
First, buying off-the-shelf, big and complex functions is the equivalent of buying
off-the-shelf applications packages, and you are buying someone else's design for
your business (see response 3 to the application package objection above). The question
in this case is going to be: how do you select the functions that fit your business?
The answer is: you compare the application's architecture with your enterprise
architecture. But that presumes that both the commercial off-the-shelf product has
architecture (models) and your enterprise also has architecture (models).
Second, if it was easy to make pre-manufactured functions work together, you wouldn't
have to buy the functions to begin with! You could just make the pre-manufactured
functions you already have installed (your legacy) work together. That is, if it
was so easy to post-integrate things, you wouldn't have a legacy problem to begin
with. The assumption that you can buy application functions and "just"
make them work together is simply not a reasonable assumption to make!
The only reasonable strategy to reduce "time-to-market" for Information
Technology implementations is to take Enterprise Architecture-based approaches in
which reusability is the engineering design objective for the architectural components
that comprise the Enterprise Architecture. You have to have the Enterprise "architected"
with standard interchangeable components long before you get an order for a new application
implementation. Early numbers are indicating that, even with limited industry experience,
twenty to thirty TIMES reduction in TIME and COST are easily achievable using top-down,
model-driven, architecture-based approaches.
Once again, buying functions off the shelf is not a substitute for architecture.
In fact, successful implementation of off-the-shelf functions is dependent upon architecture.
Furthermore, building your own Enterprise Architecture may well be a lot cheaper
and faster and require fewer competent technical types and programmers than trying
to buy functions and fit them together, after the fact.
Finally, here is the best objection of all!! FROM THE CIO him (or her) self no
|Objection 6: "I believe we need to be 'done' on explaining what we
will do and start actually doing it. I think my 'direct reports' understand this
to a degree and don't want to hear anymore about planning."
Response 6: People just don't seem to get this!! The REAL value that IT
provides to the Enterprise is the models of the Enterprise, that is, Enterprise Architecture.
Why? Because Enterprise Architecture constitutes the total KNOWLEDGE BASE for the
Enterprise -- everything anyone wants to know about the Enterprise or how to change
the Enterprise. In the Information Age (or, maybe it should be called the "Knowledge
Age") it is the Enterprise that has first knowledge and can change the fastest
that wins the game.
Modeling is NOT planning!!!!!!! MODELING IS ACTUAL WORK, vital work -- that is,
VITAL, if you think knowledge and change are important to the Enterprise!
Anybody who thinks that actual work is not being done until code is produced is
missing the point! The code is merely an interesting by-product of the modeling.
Automation is not the end game. Knowledge and change are the end game of the Information
Age. Automation was the end game in the INDUSTRIAL Age (which is now officially OVER).
If you think that work is only comprised of code (that is, implementations), you
are going to count lines of code produced as a measure of progress. Then, you are
going to get more lines of code. Whatever you measure, that is what you are going
to get! Your strategy clearly is "you start writing the code and I'll go find
out what the users have in mind" to the nth degree because that's the best way
to meet the measurements. You will be so far out on the short term end of the spectrum
you may never be able to recover, and when you get the "pay me now or pay me
later" bill, you are not likely to be able to pay it!
We (IT) have been taking the short-term option for the last 50 years. That is
what the problem with the legacy is today, as well as the reason why we are unable
to respond to short-term demand with quick implementations Ö NO ARCHITECTURE,
we only do code!
I remind you that the kinds of objections discussed above are coming from the
Information Technology Management community!! We are our own worst enemy!!
Until WE start believing that Enterprise Architecture holds some promise for bringing
our enterprises into the Information Age, the high probability is we will only continue
to aggravate the problem. Redoubling our efforts to write code with better tools
and technology only recreates all the same problems we have today, only bigger and
Enterprise Architecture doesn't happen in a moment, but it does hold the potential
for setting us on the new course our enterprises need to navigate in order to survive
the business challenges of the new millennium.
1. Walt Kelly Pogo cartoon of many years ago.
2. The references to Rows and Columns or Cells (models) in this
article refer to the Framework for Enterprise Architecture which has been amply described
in previous Newsletter articles.
©2000, Zachman International