Seven years ago, I wrote the foreword to the first version of this book and, actually, I haven’t changed my mind appreciably since that time. I was tempted simply to reproduce that earlier foreword with a few adjustments and submit it to Prakash, Ann, and Beryl. They are probably so stressed out trying to get the book completed that they may not have even noticed!

But I do have some observations I would share with you about how significant this book really is. I do not think many people have any idea the profound implications of Enterprise Architecture. My opinion is, this is not simply an Enterprise issue. I believe it has everything to do with the destiny of humanity for the foreseeable future.

The game has CHANGED! We no longer are in the Industrial Age, although many people, notably Information people, are still walking around with Industrial Age glasses on. Those of us who come from the Information Community tend to interpret everything we see in the context of the Industrial Age, where we have lived for the last 60 or 70 years, the total history of the stored programming computing technologies.

Peter Drucker, in a Forbes periodical, ASAP, on August 24, 1998, said, “The next information revolution is well underway. But it is not happening where information scientists, information executives, and the information industry in general are looking for it. It is not a revolution in technology, machinery, techniques, software or speed. It is a revolution in CONCEPTS.”

Those of us from the Information community are well-conversant with the technology, machinery, techniques, software, and speed; however, Drucker continues to observe that in the Information Age, it is the “I” in IT that becomes dominant. It is the CONTENT owners that prevail. In the previous three Information Revolutions (Papyrus, Scrolls, Gutenberg Press), initially, the technologists were hailed by kings and princes. However, within 50 years or so, the technologists (the “T” in IT) became common laborers. The content owners, in our case, the Enterprise, is now the focus of power and authority.

Ask a building architect what he does for a living, and his response will be, “We design buildings.”

Ask an aeronautical engineer what she does for a living, and she will say, “We design airplanes.”

If you ask systems engineers or people from IT what they do for a living, you will typically hear something like, “We build and run systems.” That would be a manufacturing idea. You never hear anyone say, “We design enterprises.” In contrast, designing enterprises would be an engineering idea.

Fred Brooks, the author of the seminal work, The Mythical Man Month (Addison Wesley, 1975), is attributed to the saying, “Programming is manufacturing, not engineering.”

But, “the systems ARE the Enterprise!” People used to get frustrated with me when I would say that! Typically, people would respond, “Oh, no! The systems are NOT the Enterprise. The systems … aahhh, eerrrrraahhh, hmmmm, aaaahh … the systems SUPPORT the Enterprise.” When I hear that, I usually say, “You have been replacing the people of the Enterprise with systems for the last 60 or so years. What were those people doing? Weren’t they the Enterprise? If they weren’t the Enterprise, you shouldn’t have bothered replacing them with systems! No—you made the systems the Enterprise instead of the people. If there is any question in your mind as to whether the systems are the Enterprise or not, turn the systems off for 15 or 20 minutes!! The Enterprise will come to a screeching halt!! Everybody will be sitting on their hands waiting for the systems to come back up!”

Therefore, IT has been “manufacturing” the (your) Enterprise for the last 60 or so years.

BUT the Enterprise was never designed!! The Enterprise happens—little by little, iteratively and incrementally, as it grows in complexity. And, by the way, it doesn’t have to get very big to get very complex.

Therefore, actually, IT hasn’t been manufacturing the Enterprise; they have been manufacturing PARTS of the Enterprise—and the parts don’t fit together!

If you were building airplanes (or buildings, or locomotives, or computers, or whatever) and you built a bunch of parts that didn’t fit together, what do you do with them?

SCRAP AND REWORK!!

Nobody wants to hear that, but if you want the parts to fit together, you have to engineer the parts to fit together BEFORE you manufacture them. If you manufacture them and THEN try to fit them together, you can’t get there from here! Oh, in some cases, if the clearances are not too great, you can stick shims in to make them fit, but that destabilizes the product and inhibits change and it costs more for maintenance, and so on.

In a speech at Seville University in 1998, Jay Forrester, the author of Industrial Dynamics (Pegasus Communications, 1999), said, “Organizations built by committee and intuition perform no better than an airplane built by the same methods.… As in bad airplane design, which no pilot can fly successfully, such badly designed corporations lie beyond the ability of real-life managers.… A fundamental difference exists between an enterprise operator and an enterprise designer. A manager runs an organization just as a pilot runs an airplane. Success of a pilot depends on an aircraft designer who created a successful airplane.… Who designed the corporation that a manager runs?”

That’s the point: nobody.

There is a plethora of business books and research that observe that the characteristics of the Information Age that we presently understand are twofold: complexity and change. In fact, Alvin Toffler’s books on change (Future Shock, The Third Wave, and Powershift) provide theoretical explanations of why both complexity and the rate of change are dramatically and continuously escalating.

Seven thousand years of known history would suggest that the only device humanity has identified to address complexity and change is ARCHITECTURE!

If it, whatever it is you are creating, gets so complex that you can’t see it at the level of definition required to create it, then you are going to have to formally describe it—that is, Architecture.

And if you ever want to change whatever it is you have created, you have to retain the descriptive representations that were required to create it, to serve as a baseline for changing it—that is, once again, Architecture.

Therefore, in an Enterprise, if you want to accommodate complexity and extreme rates of change, you are going to have to create and retain its ARCHITECTURE.

A few years ago, a friend of mine interviewed 108 CEOs around North America, including Lee Iococca (Chrysler), Sandy Weill (CitiBank), Jack Welch (GE), and others, and I was shocked! Every one of them, to a person, said that the biggest problem facing the Enterprise was CHANGE! I thought I had to explain to the CEOs of the world, “Chief! Change is a BIG problem!” It turns out, they already knew that! They are obviously a lot smarter than I was giving them credit for being.

The question is NOT “Is complexity and the rate of change increasing?” The question IS “What are YOU going to do about the dramatic escalation of complexity and the rate of change?” And the question is NOT a technical question. It is an ENTERPRISE question: “What are you, CHIEF, going to do about the dramatic escalation of complexity and change?”

There is only one possible answer: ENTERPRISE ARCHITECTURE!

I hope this short discussion is sufficient to help you understand why this book is so significant.

No! One more point.

If you build a bunch of parts and the parts don’t fit together, you can try to compensate by inserting “shims” and things to force a fit—if the discontinuity is somewhat limited. In Enterprises, these “shims” are called middleware, or cross-references, or interfaces, or MBAs with Excel spreadsheets running on PCs reconciling discontinuities, and so on. This is ENTROPY—the price you pay just to keep the Enterprise running. It is not contributing to the “bottom line.” It is general and administrative expense.

Management has lamented for decades about the costs of IT. I haven’t seen any numbers lately but, historically, around 80 percent of the IT budget was spent on “maintenance.” And the more lines of code there are, the more dis-integration, the more compensation, the more entropy, the more “maintenance.”

Fred Brooks observed, “All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing the original design flaws and more and more is spent fixing flaws introduced by earlier fixes.… Although in principle [the system is] usable forever, the system has worn out as a base for progress. Furthermore, machines change, configurations change, and user requirements change so the system is not in fact useable forever. A brand new, from-the-ground-up redesign is necessary.”

SCRAP AND REWORK

(e.g., Windows 3, Windows XP, Windows 2000, …Windows 7, 8, 9, …Windows “n”)
(e.g., Version 1.0, v1.2, v1.3, v1.31, v1.32, v1.33, v2.0, v3.0, v4.0, …version “n”)

Notice: The end objective is NOT to get the code to run. That is what we have been doing for the last 60 or so years. The result is what we have: lines of code, LOTS of lines of code, the “legacy,” dis-integration, dis-continuity, entropy.

The end objective IS to design the Enterprise such that there is NO discontinuity, NO disorder, NO dis-integration, NO de-normalization. Its “parts” are “integrated.” That is, ENTERPRISE ARCHITECTURE!

Now we have the Certified Enterprise Architect All-in-One Exam Guide!

I have known the authors of this book for 35 years (Beryl Bellman), 25 years (Prakash Rao), and 15 years (Ann Reedy). They are consummate enterprise architecture practitioners and they have been DOING enterprise architecture for all the years that I have known them. Each of them brings his or her own particular focus and experience: culture change, modeling and repository products, and methodology development, and so on, to give a comprehensive understanding of the Enterprise and its architecture.

They have gathered together in one volume, a comprehensive summary of state-of-the-art practical issues that an enterprise architect has to address, elaborated in a Six-Step methodology derived from the Department of Defense Architecture Framework (DoDAF): 1. Planning, 2. Developing, 3. Disseminating, 4. Sustaining, 5. Governing, and 6. Using … Enterprise Architecture.

All of the authors were extensively involved in developing and teaching DoDAF.

They develop a comprehensive case study employing the DoDAF artifacts to serve as practical illustrations of architectural representations.

Personally, I would pay attention to their “lessons learned,” the first one of which, by the way, is INTEGRATION!

I would make one more foreword point for you:

We do not have 1000 years of accumulation of wisdom around the subject of Enterprise Architecture. We have only a few decades. I have spent 40 or 50 years myself trying to learn as much as I can, and the more I know, the more I don’t know! We have a LOT more to learn.

The authors allude to the next critical (in my estimation) intellectual hurdle: We need a theoretical context to define the physics, the Laws of Nature relative to Enterprises, and in this, I am confident, lies the domain of ontologies.

The authors graciously refer to my Framework in the book and acknowledge that it is an ontology—NOT a methodology. To tell you the truth, I didn’t even know what an ontology was, or even that my Framework was an ontology until just a few years ago!

Actually, I did not even invent my Framework. It kind of fell on my desk one day. I was just trying to figure out how to transform the Enterprise Business Strategy into implementations such that the implementations somewhat resembled the strategies. Those of us who were working together thought that Architecture might have something to do with this, but we had no idea what Architecture looked like for Enterprises.

One day, I had a bright idea. I have an architect friend who designs buildings, and I thought that if he would talk to me about creating a building (like a 100-story building) architecture, maybe I could figure out what Enterprise Architecture might look like.

My friend sketched out a “creating Building Architecture” scenario, and I began to see a pattern. At that time, I was doing some strategy consulting in several airplane manufacturing enterprises, where I could do some research and validation of the pattern I discovered, and voila! The pattern recurs! It is the same! Then we looked at ships, computers, automobiles—whatever we could get access to—and all confirmed the pattern. Subsequently, all I did was put Enterprise names on the same descriptive representations that were created for designing and building Industrial Age, complex engineering products. The result is what you might now know as the “Zachman Framework.”

I appreciate my friends Beryl, Prakash, and Ann. They have taught me invaluable lessons about Enterprise Architecture and helped me refine my understanding of the ontological structure.

At the very beginning of this foreword, I made the observation, “I do not think many people have any idea the profound implications of Enterprise Architecture. My opinion is, this is not simply an enterprise issue. I believe it has everything to do with the destiny of humanity for the foreseeable future.”

I also suggested that the next intellectual barrier to progress in the Enterprise Architecture state of the art lies in the domain of ontologies.

To give you a sense of this significance, I suggest a chemistry metaphor:

For six or seven thousand years, there were chemists, actually alchemists, who were learning how to create chemicals by trial and error, “best (or worst) practices.” They were very creative and very innovative, but it was only after Dmitri Mendeleev published the Periodic Table, an ontology, around 1890, that they began to understand the molecular physics of chemical engineering, REUSING the elements of the Periodic Table to create an infinite variety of compounds. Up until that time, they had created only a relative few chemical compounds by using other chemical compounds they had available. They only had a suspicion that something like atoms existed. But within a mere 50 years or so after the publication of the Periodic Table, they were splitting atoms!

With the advent of an ontology of elements theoretically classified, research was no longer constrained to practice, trial and error. It became scientific, with results being predictable and repeatable. Friction went to zero. Every ALCHEMIST who began to USE the Periodic Table became a CHEMIST.

The Periodic Table is the foundation for understanding the physics of elements. The compounds are specific implementations of combinations of elements to fulfill a specific purpose. There is ONE Periodic Table. There are “n” different compound (implementations) and maybe “n-squared” processes (methodologies) for creating them. The elements (Periodic Table) are timeless. The compounds (implementations) are temporal.

The breakthrough was the acknowledgement of and the employment of the ontology by the practitioners.

I would also suggest that the key to the INDUSTRIAL AGE was ARCHITECTURE, in that case, Industrial Product Architecture.

For example, if someone hadn’t figured out how to describe buildings, we’d be having our meetings in log cabins. If someone hadn’t figured out how to describe airplanes, we’d be traveling in covered wagons. If someone hadn’t figured out how to describe automobiles, we’d be riding horses (et cetera). The key to the Industrial Age was ARCHITECTURE, Product Architecture!!! Learning how to describe (and create) the tangible objects to which we are so accustomed that we tend to take them all for granted.

I submit that the key to the Information Age also is ARCHITECTURE, but ENTERPRISE ARCHITECTURE. Whereas the Industrial Age was focused on tangible PRODUCTS, I believe the Information Age will be characterized by the focus on groups of PEOPLE collaborating in pursuit of a common mission or purpose—that is, on ENTERPRISES!

If we don’t figure out how to describe Enterprises and AGREE to REUSE the ontological structures for architecting them, we are relegated to producing more of what we already have now: legacy, code, and an inability to accommodate the escalation of complexity, and “Future Shock,” the inability to accommodate extreme change—that is, paralysis.

We need the breakthrough of an explosion in the body of knowledge in Enterprise Architecture. We need the release into the molecular physics of Enterprise Design. We need to start thinking about splitting the atoms of Enterprise “primitives” (elements).

In this book, Ann, Beryl, and Prakash introduce us to the domain that opens the door to the future: ontologies.

Thank you, Ann, Beryl, and Prakash!

Keep this book beside your bed! Read some every day!! Do what they say!!! You’ll be happy.

In seven years, I am planning to be around to write the foreword to the THIRD edition, the ontological version of the Certified Enterprise Architect All-in-One Exam Guide!!!

John A. Zachman, CEO
Zachman International
Bakersfield, CA, 2018