CIOREVIEW >> Enterprise Architecture >>

Architecture Is Architecture Is Architecture

John A. Zachman, Founder and President, Zachman International
John A. Zachman, Founder and President, Zachman International

John A. Zachman, Founder and President, Zachman International

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!”

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.” 

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, “Ya 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 four 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!

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

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 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!

Read Also

The Intelligent Legal Department

The Intelligent Legal Department

Mick Sheehy, Partner, PwC NewLaw
Data Protection Trends - GDPR as a forthcoming global privacy benchmark

Data Protection Trends - GDPR as a forthcoming global privacy benchmark

Jiri Cerny, Legal & Corporate Affairs Director, Microsoft
Technology as a Tool to Aid the Legal Function

Technology as a Tool to Aid the Legal Function

Surabhi Madan, Senior Global Legal Counsel, ASM Front-End Mfg (S) Pte Ltd
Building On Your Legal Tech Journey

Building On Your Legal Tech Journey

Neil Blum, National IT Manager, Barry.Nilsson
Enhancing Productivity of Lawyers with Technology

Enhancing Productivity of Lawyers with Technology

Vimaljit Kaur, Senior Legal Counsel, Sembcorp Industries