Architecture Is Architecture Is Architecture

In Business Architecture, Enterprise Architecture, IT Strategy & Management by IRM UK1 Comment

Print Friendly, PDF & Email

In 1980, we were having difficulty transforming the Enterprise Strategy into implemented systems, the instantiated Enterprise, because the strategies tended to be articulated in a somewhat abstract form like “Make Money,” “Reduce Cost,” “Grow,” Optimize,” “Market Share,” “Profitability,” “Stock Price,” etc. In contrast, the instantiated implementations, the “systems” looked like “01AE74 113C7E CA69F2” (if you were using hex) … or “110100 001101 101110” (binary).  It is a LONG way from “Make Money” … to “110100!”

zachman_01

John Zachman, President, Zachman International, jazachman@zachman.com

John will be speaking at IRM UK’s annual Enterprise Architecture Conference Europe 2016, 13-16 June, London and will be presenting his seminar Zachman Enterprise Architecture: Modelling Workshop & Certification, 27-30 September 2016; 28 February-3 March 2017, London

Those of us who cared about this issue knew that even if we could get the strategy formalized in such a fashion that we could do some engineering kind of work with it, it still was a LONG way from Strategy to Implementation. We intuitively felt that “Architecture” had something to do with the logic that bridged the strategy to the implementation but we didn’t know what Architecture was for Enterprises.

We also knew that the CEO’s seemed to care about this issue too since “Alignment” kept showing up in the CEO surveys of the Top 10 Issues that DP (“Data Processing,” now called IT, “Information Technology”) had to address. In fact, “Alignment” STILL tends to show up in the Top Ten IT issues in CEO surveys.

The CEO’s appear to be saying something like, “we are spending a LOT of money down there in IT and I am not sure what is being done with it because it doesn’t seem to be ‘aligned’ with what I think the Enterprise is.” Hmmmmm.

Some people might suggest that nothing has changed … in fact, “Alignment” is still showing up in the top ten issues that CEO’s consider critical for IT to address.

In any case, back in 1980 we had this sense that somehow “architecture” was involved in this issue.

One day, I had a radical idea … I said, “You know what we ought to do? We ought to find someone who does architecture for something else, like a building, or an airplane, or a computer or something and find what what they think architecture is and if we could find out what architecture is for something else, maybe we could figure out what architecture is for Enterprises … and then figure out how to transform the Enterprise strategy into the operating Enterprise.”

I had a personal friend who was an Architect, a building Architect. It was easy for me to visit my friend to determine what architecture is for buildings, for example.

What I discovered was shocking!

I discovered that Architecture is Architecture is Architecture! The structure of the descriptive representations that are used to design and manufacture ANY building, complex or simple, large or small, is identical.

  • EVERY building has a bill of materials.
  • EVERY building has functional specifications.
  • EVERY building has geometry (drawings).
  • EVERY building has operating instructions.
  • EVERY building that has moving parts has timing diagrams.
  • EVERY building has design objectives.

Not coincidently, I am sure, these descriptive variables are completely consistent with the “six primitive interrogatives” that come from the origins of language, WHAT (parts) the building is made of, HOW (function) the building works, WHERE (geometry) the parts fit, WHO (operator) works the building, WHEN (timing) the components are operated and WHY (objectives) the building works as designed … six primitive interrogatives that linguistically and collectively constitute the complete description of any subject or object.

But, there was another startling discovery. Each of the above variables is described from
varying perspectives.

  • EVERY variable is described from the scope, or strategy perspective.
  • EVERY variable’s requirement concepts are described from the Owner ‘s perspective.
  • EVERY variable’s design logic is described from a Designer’s perspective.
  • EVERY variable’s implementation physics is described from the Builder’s perspective.
  • EVERY variable’s construction configuration is described from the worker’s tooling perspective.

Not coincidently, I am sure, these transformations are completely consistent with the philosophy concept of “reification.” Aristotle and Plato and others knew that an idea you have must go through these five transformations (to instantiation) if you want the instantiation to have any relationship with the idea at the conclusion.

If every plumber, every electrician, every back-hoe driver, every sub-contractor, every contractor, every project manager, every building engineer, every architect, every building owner, every building occupant wanted to define Building Architecture the way they wanted to define it, we wouldn’t have hundred story buildings. We wouldn’t even have 4 story buildings … look around the older european cities … or even the older US cities.

No, everybody in the building industry already knows and agrees as to what Building Architecture is. It is not arbitrary and not negotiable … in fact, it is regulated!!!

Once I saw the pattern, all I did was put Enterprise names on the same architectural components that not only exist for buildings but also exist for airplanes, ships, computers, tables, chairs and every other humanly created object. Architecture IS Architecture IS Architecture!

ZachmanFWork

Figure 1: The Zachman Framework IS Enterprise Architecture

This Framework IS Enterprise Architecture. I do not believe Enterprise Architecture is arbitrary and it is not negotiable. If you want the systems to be aligned with what the CEO’s have in mind … and if you want flexibility, integration, interoperability, reusability, security, etc. you are going to have to have Enterprise Architecture. If you do not have Enterprise Architecture, you are not going to have alignment, interoperability, flexibility, integration, reusability, security, etc, etc. End of story.

If every programmer, every database designer, every data architect, every application developer, every project manager, every CDO, every CTO, every CIO, every CEO, every system user wants to define Enterprise Architecture the way they want to define it, we are going to have more of what we already have … LEGACY. Old, existing Enterprises. Look around the world!

Until we, the information industry, agree that this is Enterprise Architecture, since it is architecture for every other known object humanity has ever created, we are only going to create more of what we already have.

The good news for CIO’s is, because the media for the Enterprise descriptive representations is the same as the media of the Enterprise instantiations (the systems), we don’t have to do this all at once! This enables us (IT … somebody) to build this out iteratively and incrementally, little by little, over some long period of time … maybe perpetually … forever. It simply has to be GOVERNED.

In fact, personally, I would start with the CEO’s problem and only populate those portions of those Framework Cells that are required to solve his or her problem. This would kill THREE birds with one stone … first, we solve the CEO’s problem (which makes them happy); second, ensure we will never again be a solution in search of a problem (mis-aligned) and third, formalize Enterprise Architecture little by little, CEO’s problem by CEO’s problem in order to deliver flexibility, integration, interoperability, and so on in the process … the Enterprise Engineering Design Objectives that have been so illusive since the origin of IT!

© 2016 John A. Zachman, Zachman International

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. He is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology as well as to their Executive team planning techniques.

Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is Chief Executive Officer of Zachman International, an Enterprise dedicated to the advancement of the state of the art in Enterprise Architecture in support of Enterprise Engineering and Manufacturing. He has written over 60 major articles on the subject. His website is www.Zachman.com

Comments

  1. John, I couldn’t agree more, and have loved your diagram since seeing it back in the late 1980’s! But I think about building architecture drawings versus the as-built instantiation (and the discrepancies as time moves on) and likewise the current effort involved in linking IT assets/inventories (initial and as they change over time) with their appropriate objects in the Framework and think we still have a long way to go! What are your thoughts on how the IoT might help keep models and their actual representations in sync?

Leave a Comment