All the Reasons Why You Can’t Do Architecture or (“We Has Met the Enemy and He Is Us”)
By John Zachman
I recently received a letter from a friend of mine2who was valiantly trying to initiate some architectural activity in a very large Enterprise within a very important industry sector. 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 objectionsalmostverbatim below.
Here is his intro: “Dear John – By the way – I am getting some pretty significant pushbackfrom the IT leaders. They do not want to do architecture (i.e. create models) for the business!”
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 (logic) architecture or to the business (concept) architecture. I would suggest that the hardware and systems software are merely the “container.” The business (and therefore, the “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 the ENTERPRISE to the container.
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 enterprise’s ability to fund, not to mention change! Interfacing (with “middleware,” for example) hardware and systems software (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 to interface increases, the number of interfaces increases exponentially! 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!” Interface management and change is 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)3principle, 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 “primitive” 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 (containersandcontents) from scratch?!! Good luck!
I would argue, principles are useful … but there is no substitute for architecture (actual “primitive” models) when things get complicated and start to change.
One last 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 the business? 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 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.”
Response2: 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, 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 Enterprise 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?!!”
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 works!” 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.4
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 (i.e. one for which there are “primitive” models)? … 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 Enterprise’s 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 or it costs too much to maintain it or you can’t change it. 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 current architecture? 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 (build “primitive” models!)
Objection 5: “When it comes to the application functions (services??) 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 time to do is to 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 problem.
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 again (see response 3 to the application package objection above). The question, in this case, is going to be, how do you select the functions (services??) 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 (“primitive” models) and your Enterprise also has architecture (“primitive” 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 rational 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 ENTERPRISE engineering design objective for the ENTERPRISE 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, ENTERPRISE-Architecture-based approaches.5
Once again, buying functions (services??) 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.
Now, here is the best objection of all!! FROM THE CIO him (or her) self no less:
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 any more 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 KNOWLEDGEBASE for the Enterprise, that is, everything anyone wants to know about the Enterprise in order to manage it or to change it. 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!”
In summary,
I remind you that these 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 technologies only recreates all the same problems we have today, only bigger and faster!
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.
1Walt Kelly Pogo cartoon of many years ago.
2I actually received this letter from my friend 7 years ago and originally wrote this article at that time. However, the objections to Architecture haven’t changed appreciably … and my responses haven’t changed … only the current set of technological “silver bullets” are different.
3The references to Rows and Columns or Cells (models) in this article refer to the Framework for Enterprise Architecture which has been described in a number of other documents. Seewww.ZachmanInternational.comfor a bibliography of articles and books..
4Iwrote another article, “Packages Don’t Let You Off the Hook” which can be found in an Appendix of my book, “The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing” available throughwww.ZachmanInternational.com. I won’t attempt to reiterate all the points I made in that article here.
5See presentation at the ZIFA Forum, 18 – 20 September, 2000 in Scottsdale, Arizona by S. Mike Hakes and William E. Darlage, Ohio Bureau of Workers Compensation, “Implementing Large Information Systems based on the Zachman Framework for Enterprise Architecture.” (Or, contact Doug Erickson of ENTARCO on 1-614-751-5078 for further information.)
About the Author
John A. Zachman is the originator of the “Framework for Enterprise Architecture” which has received broad acceptance around the world as an integrative framework, or "periodic table" of descriptive representations for Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning). Mr. Zachman retired from IBM in 1990, having served them for 26 years. He presently is Chairman of the Board of Zachman Framework Associates, a worldwide consortium managing conformance to the Zachman Framework principles. He is Chief Executive Officer of the Zachman Institute for Framework Advancement (ZIFA), an organization dedicated to advancing the conceptual and implementation states of the art in Enterprise Architecture. He also operates his own education and consulting business, Zachman International. Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO). He is a Fellow for the College of Business Administration of the University of North Texas. He serves on the Advisory Board for the Data Resource Management Program at the University of Washington and on the Advisory Board of the Data Administration Management Association International (DAMA-I) from whom he was awarded the 2002 Lifetime Achievement Award. He was awarded the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation. Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He is the author of the book, “The Zachman Framework for Enterprise Architecture: A Primer on Enterprise Engineering and Manufacturing.” He has facilitated innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent. In addition to his professional activities, Mr. Zachman serves on the President’s Cabinet of the King’s College and Seminary, the Board of Directors of the Los Angeles Citywide Children’s Christian Choir, the Board of Directors of Native Hope International, a Los Angeles-based ministry to the Native American people and has served on the Elder Council of the Church on the Way (First Foursquare Church of Van Nuys, California) and on the Board of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way. Prior to joining IBM, Mr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U. S. Naval Reserve. He chaired a panel on "Planning, Development and Maintenance Tools and Methods Integration" for the U. S. National Institute of Standards and Technology. He holds a degree in Chemistry from Northwestern University, has taught at Tufts University, has served on the Board of Councilors for the School of Library and Information Management at the University of Southern California, as a Special Advisor to the School of Library and Information Management at Emporia State University, and on the Advisory Council to the School of Library and Information Management at Dominican University. Mr. Zachman can be reached at [email protected]