An Interview with John A. Zachman: Celebrating 30 Years of the Zachman Framework

by Charles Roe

In15 BCE, the distinguished Roman architect Vitruvius wrote his grand 10-volume treatise in honor of his patron Caesar Augustus, simply titled De Architectura (or On Architecture). Considered the first great written work of architecture, the history of the art and science that combines designing, planning and constructing of systems goes back to the beginnings of humanity. Architecture has come a long way since 15 BCE, and has moved into every area of human life. It still encompasses the creation of modern day construction masterpieces like the Sky Tower in Abu Dhabi or 1WTC in New York City, but also is an inherent facet of computer programming, political campaigns, advertising, manufacturing, information management, medicine and virtually any discipline that deals with the creation and management of systems.

30 years ago John A. Zachman began his groundbreaking work on Enterprise Architecture, with the first creation of what is called the Zachman Framework. On a practical level, the Framework was developed to enable enterprises to manage the ever greater magnitudes of complexity and change that are inherent characteristics of the Information Age. Yet, at its core the Framework is architecture as Vitruvius would have imagined it, for it really is “the intersection between two historical classifications that have been in use for literally thousands of years.”  DATAVERSITY™ recently interviewed Mr. Zachman to gain a deeper insight into its history and conception:

 

DV:  What was your original inspiration behind creating the Zachman Framework?

JZ:  I was just trying to solve a problem.  By the late ‘60’s, early 70’s timeframe, we had figured out methodologically how to transcribe the Enterprise Strategy in such a fashion that we could do some “engineering” work with it … but we did not know how to get the strategy transformed into implementations while at the same time, holding the “alignment” with the strategy.  We knew that “architecture” had something to do with the logic structure that connected the strategy to the implementation, but we didn’t know what Enterprise Architecture was.  My idea was to find out what people who do architecture work for other things like buildings, or airplanes, or computers, or whatever thing architecture is relative to whatever they are creating.  I looked at buildings, airplanes, automobiles, computers, ships … and it turns out that Architecture is Architecture is Architecture.  It is all the same.  There is a structured pattern for the set of descriptive representations for describing anything.  I simply put Enterprise names on the same pattern of descriptive representations relevant for describing anything.  When I started working with the pattern, I discovered that we (DP, IT, the people who build systems) already were reinventing some of the same descriptive representations that had already been invented by the older disciplines of Engineering and Manufacturing, Architecture and Construction, etc.  It was relatively easy to put Enterprise names on the structural pattern based on the logic of the structure itself.  So …the Zachman Framework.  I usually say, I did not “invent” the Zachman Framework.  It just fell on my desk one day!

 

DV:  What were some of the early hurdles to creating the Framework?  And over the years?

JZ:  The current hurdles and the early hurdles are the same hurdles.  For about 75 years, those of us who work with information technologies have perceived our role as building and running systems … basically using machines to perform processes (automated systems) rather than people to perform the processes (manual systems) because machines are better, faster and cheaper than people.  They are better because they do it the same way every time whereas people make mistakes; faster because machines run at electrical cycle speeds and people run at people cycle speeds (machines can do a LOT more work than people); and cheaper because in most cases, machines are cheaper than labor.  There is overwhelming incentive to get the systems implemented as quickly as possible to start saving money, dong more work and costing less than labor … improving Enterprise productivity.

Enterprise Architecture is different from building and running systems.  The idea is to engineer the ENTERPRISE, not simply to build and run systems and improve productivity.  If you could shift the focus from one implementation to THE ENTERPRISE, you could engineer the Enterprise components to be reused in more than one, actually ANY, implementation … saving a LOT more money.  You could build up an inventory of component parts to have on hand before you ever get an order for implementation.  You could combine reusable components in various combinations and only bind them together at execute time (late-binding). This would reduce the “time-to-market” (time-to-implementation) to just the time it takes to ASSEMBLE the implementation to order.  That is, you could reduce the time to implementation to just the time it takes to click your mouse.  This would be “Mass-Customization,” assembling the finished good (Enterprise) from the inventory of PARTS (primitive components), cleverly engineered to be assembled into more than one thing.  The key is to engineer the PARTS so they could be assembled into more than one “Enterprise.”  (As 75 years have conclusively proved, you don’t get reusability by accident … it has to be ENGINEERED!)

The BIG problem is, the kind of models you need to engineer reusability, flexibility, integration, alignment, and so on are ARCHITECTURE models, ENGINEERING Models, SINGLE-variable models, “Primitive” models, which are different  from the models we have been employing for the last 75 years, the Implementation Models, Manufacturing Models, MULTI-variable models, “Composite” models, models used to build and run systems.

Experience establishes that you don’t even need to have very many SINGLE-variable models in inventory to begin having major impacts on the Enterprise … specifically, only a sufficient number to address General Management, CXO business problems and lay the foundation for adding to the inventory iteratively and incrementally over time.

The BIG hurdle is the “paradigm” shift from building systems to engineering Enterprises.

My opinion is, this paradigm shift is NOT optional!  The Information Age paradigm is the Enterprise Architecture paradigm whereas the Industrial Age paradigm was the System Implementation paradigm.  I wrote an article in 1999, “Enterprise Architecture: The Issue of the Century” in which I argued that the Enterprise that can accommodate the concept of Enterprise Architecture will have the OPPORTUNITY to stay in the game in the Information Age … and the Enterprise that cannot accommodate the concepts of Enterprise Architecture is not going to be in the game.  Read the newspaper these days!  End of story.

 

DV:  What are some of your greatest surprises with the Framework over the last 30 years?

JZ:  I suppose the greatest surprise for me was the realization that my Framework is actually an ONTOLOGY.

I knew from the beginning that my Framework was NOT a methodology.  The Framework is inert … it implies nothing about how you might use it to do architecture work, that is to build the models, the formalisms that constitute Enterprise Architecture.  It does not prescribe top-down, bottom-up, left-to-right, right-to-left, where to start … it does not even prescribe how many of the models you might formalize or how many you might choose to leave implicit (any model that is not explicit is implicit)..  All of these are methodological choices … all of these have significant implications … but all of these are quite independent of the Framework.

I have known all along that the Framework is a schema … not a methodology … a TWO-dimensional schema.  If you want to normalize anything, to do Engineering work, you have to have a TWO-dimensional schema, one fact in one place.  A ONE-dimensional classification, a hierarchy, a taxonomy, a decomposition is good for manufacturing, for building and running systems.  The idea of a hierarchy or decomposition is to break the systems down into smaller and smaller pieces so you can get them implemented faster and cheaper.  The ENGINERING problem with a one-dimensional classification is, the same components can show up in different nodes in the decomposition tree.  That is, you can classify the same thing in more than one category.  That is, you can’t normalize a one-dimensional classification.  It is good for Manufacturing, not Engineering.  It is good for building and running systems, NOT for engineering Enterprises.

The Zachman Framework is an “ONTOLOGY.” I didn’t even know what an ontology was until very recently when one day I woke up and discovered that my Framework actually was one!

Here is my layman’s definition of an “Ontology,” a two-dimensional classification.  The Zachman Framework technically is an ontology, a theory of existence (ontologies have to do with what exists) of a structured set (that is, a classification, a structured classification, not an arbitrary classification) of essential components (those things that not only exist, but are essential for existence) of an object (any object) for which explicit expression is necessary (in fact, I think it is mandatory) for designing, operating and changing the object (the object being an Enterprise, a department, a value chain, a solution, a project, an airplane, a building, a bathtub or whatever or whatever).

I think there is an ontology at the heart of every discipline because until someone discovers the natural laws of classification relative to any subject or object, nothing is repeatable and nothing is predictable.  For example, until Mendeleyev observed the natural classification of the chemical elements, the Periodic Table, there was no Chemistry.  There were chemists, actually alchemists, but nothing was repeatable and nothing was predictable.  Everything was based on experience, “best practices.”  Within 50 years of the publication of the periodic table, the chemists and physicists were splitting atoms!  Now there is a Chemistry discipline: research, theoretical postulations and experiments for validation.  Discipline requires order, natural laws, ontologies.

My Framework may form the basis for a discipline … maybe it is the discipline of “Enterprise Engineering.”  Or, maybe, as some people postulate, the discipline will be called, “Management Science.”  I have no idea what the discipline might be called, but I am sure it will employ the natural laws of classification of descriptive representations of complex objects, specifically, Enterprises to create them, operate them, manage them and change them.

 

DV:  What do you think were a couple of the biggest changes since the Framework’s original inception?

JZ:  Actually, the Framework itself has never changed.  It is based on two classifications that have been used by humanity for thousands of years.  The vertical dimension of the Framework is based on the six primitive interrogatives.  To have a complete description of anything, you have to answer six questions, What, How, Where, Who, When and Why.  This classification has been well-exercised by humanity and can be traced back to the origins of language.  The horizontal classification is based on reification, the set of transformations an idea has to go through to ensure that the realization of the idea, the instantiation, bears any resemblance to the idea to begin with.  It has to be Identified (or named), Defined (conceptually structured), Represented (logically designed), Specified (technically constrained), Configured (tool prescribed) and Instantiated (ideally realized).  Reification can be traced back to the early Philosophers, Aristotle, Plato and so on.

Therefore, the Framework is simply the intersection of two classifications that have been employed by humanity for literally thousands of years.  The Framework has not changed over time and never will change.  It is the natural classification of the descriptive representations of anything.  I just happened to put Enterprise names on the structural categories and the descriptive logic (the meta-model).    What changes is first, our ability to understand the classification structure, to find better words to express the characteristics of the ontology and second, how to use the ontology to engineer Enterprises, to build an inventory of single-variable, Primitive components that can be used in any implementation and to exploit the concept of Mass-customization in human collaborations, Enterprises.  We are presently learning how to use the Framework to address the urgent Enterprise problems as perceived from the General management perspective.

 

DV:  Where do you want the Framework to go in the future?

JZ:  Actually, I don’t think the Framework is going to go anywhere in the future.  It has been here for thousands of years already (even though we haven’t consciously perceived it) and I am confident it will be here for a few more thousands of years.

We are just beginning to learn some things.  We have a LOT more to learn.  My opinion is, we should forget about arguing about what Enterprise Architecture is … Architecture is Architecture is Architecture.  We ought to accept the definition of Architecture from the older disciplines (the Zachman Framework) and start focusing on using it to learn how to build better and more effective Enterprises that can accommodate the extreme complexities and extreme rates of change that are inherent and increasingly evident in the Information Age.

How do you intend to accommodate a few more orders of magnitude increases in complexity and a few more orders of magnitude increases in the rate of change?  Who is working on this?  Do you think this is not going to happen?

It is happening … the only question is, what are YOU going to do about it?

Seven thousand years of human history suggests that the only known strategy to address complexity and change is … ARCHITECTURE!

MY plan would be to start building out an inventory of architecture models, engineering models, single-variable, “Primitive” models, iteratively and incrementally that constitute Enterprise Architecture as defined by the older disciplines of Architecture and Construction, of Engineering and Manufacturing and as represented in the Zachman Framework, “ENTERPRISE ARCHITECTURE;” using them to address urgent General Management problems as you go, dynamically creating the implementation models, the multi-variable COMPOSITE models, models you need to build systems, do analysis, do any Enterprise work; assembling the Composite implementation models from the inventory of reusable components of the Primitive Models; positioning yourself to be viable in the new paradigm, Information Age environment, mass-customizing the Enterprise on demand.

What would be YOUR plan?

 

The Zachman Framework has come a long way in three decades and so in honor of Mr. Zachman’s work, there is a celebration at the upcoming Enterprise Data World 2012 Conference. Come by and visit with Mr. Zachman, listen and take part in his discussion with Peter Aiken entitled “Zachman Framework Experience – 30 Years of Lessons Learned and Predictions for the Future” and enjoy the rest of the conference.

 

©2012 John A. Zachman, Zachman International

 John A. Zachman

Zachman International

www.Zachman.com

Related Posts Plugin for WordPress, Blogger...

  2 comments for “An Interview with John A. Zachman: Celebrating 30 Years of the Zachman Framework

Leave a Reply

Your email address will not be published. Required fields are marked *

Add video comment