Enterprise Architecture Framework

Column 1 is labelled “Data,” which classify Zachman Framework™ as a Framework for Information Systems. Not correct. It’s not the framework for Information Systems.
In fact, in 2004, the term “data” was removed from the framework. Please note that in 2011 version of the framework graphics – The enterprise name for “What” is “Inventory Sets”.
“Data” is the most important aspect of the enterprise as it’s in the first column. “Motivation” is “least” important as it’s in column six Not correct. Order of columns has nothing do to with their relative importance in the context of “Enterprise”.

The order of column just reflect the order in which 6 communication interrogative i.e. what, how, where, who, when, why are being used. “What or earlier data” column being the first column is just reflecting the order in which people (around the world) have been using these 6 interrogative.

The Framework, and Enterprise Architecture for that matter, are an IT issue No.The reality is that the Zachman Framework is Ontology for Enterprise Architecture.
Unfortunately, most people who come from IT today are thinking of building and running systems and not about engineering and manufacturing enterprises.
People’s misperception that working your way down the columns is merely an increase in level of detail The movement down each column has nothing to do with level of detail; it has to do with transformation
Each cell containing composite constructs. Oops! Wrong again. Each cell consists of primitive constructs, not composites.
The Framework is just a matrix The brilliance of this Framework is in the concepts of Integration (across the Rows) and Transformations (down the Columns).

Often, constructs within the “Enterprises” are in “composites” form created by integrating the elements across the cells.This helps in effective diagnosis, better predictability and enhanced traceability for change and complexity management. Once you will use it, you will understand what I am talking about.

The Framework is a checklist. It’s similar to saying “Periodic Table” is a checklist. You can use the framework as a checklist, but it’s oversimplifying the fact.
We know that one can use the periodic table for creating complex compounds with predictive characteristics or behaviour. Similarly, one should use the framework for creating complex enterprise constructs (composites) to meet some defined need.
There is NO indication that INTEGRATION exists between the Columns. In fact, the new framework graphics very clearly represents the “Integration lines” linking elements between the columns. This clearly establishes that integration exists between the Columns as well.

Architects can use the primitive cells of the Framework (Periodic Table) to build the composite implementations (Chemical Engineering) to produce predictable, repeatable results (a science).  The integrations and transformations are like “mortar between the bricks” (the bonds between the chemical elements).

Framework is  enterprise taxonomy It’s understatement.
Framework is “enterprise ontology” and not just taxonomy i.e. complete set of things that makes the enterprise similar to “Periodic Table.”

All the compounds (chemical) which exist on planet earth can be formulated by mixing the primitive elements (of periodic table). Similarly, all the enterprise composites are possible by combining the primitive cells in Zachman framework.

Every human being is different, yet they follow a common body structure. Similarly, every enterprise is different but they follow a common structure i.e. Zachman framework.

Unfortunately, Human body is so complex that medical people still doesn’t have a good ontology.

The Zachman Framework in competition with other  Enterprise Frameworks There are many “Frameworks” in EA and there is significant confusion about what the word “Framework” actually means. The fact is that ALL Enterprise Architecture “Frameworks” in the industry is a methodology or derivative of the Zachman Framework.
The Zachman Framework for Enterprise Architecture is “Enterprise Ontology”.
Most people who misrepresent Zachman Framework as a “waterfall,” think that each Row represents another level of detail, i.e. the highest level of detail at the top of The Framework (Row 1) and the most excruciating level of detail at the bottom of The Framework (Row 5) Grossly misunderstood.
This is not the case at all. The models of each Row TRANSFORM- they do not get more detailed. Level of detail is represented in the height of each cell, i.e. a high level of detail at the top of each cell and an excruciating level of detail at the bottom of each cell
The Framework’s fundamental concept is decomposition, down each column The Framework’s fundamental concept is “transformation”, not “decomposition”, in the reification process down each column.

An idea (or Scope-Row 1) has to go through 6 well-known phases in order to reach reality (Operations-Row 6) such that the reality retains an alignment with the initial idea as it was conceived and designed.

Column 3 (Network Nodes- 2004 Version).Enterprise Architects often thought of this as point-to-point nodes and were not building their models correctly. The fact is that the fundamental concept of Column 3 deals with distribution of resources as opposed to node addresses on a network.
The six rows are arbitrary i.e. John has just picked up 6 different perspective (in six rows) and there are more perspective which can be added – that is, more rows can be created. No it’s not arbitrary. John uses the 2000 year old concept of reification i.e. how to transform an abstract idea to reality.Reification consist of 6 phases of transformation i.e.- Identification (mapped to Row 1)- Definition (mapped to Row 2)- Representation (mapped to Row 3)- Specification (mapped to Row 4)- Configuration (mapped to Row 5) and – Instantiation (mapped to Row 6)The models in each row get transformed to the next Row below, and the Row 6 wraps up the 6th phase of reification
“Who”: Column 4 – Organization Groups.
As soon as the Enterprise Architects saw this label, they incorrectly assumed it as: Organization Chart?
This is not so.
This Column is all about “responsibility”. In Zachman Framework v3.0 (2011), meta-model has been changed to form the title “Responsibility Assignments” for Column 4.
Zachman Framework is a “methodology” The Zachman Framework™ is the “Enterprise Ontology” and not “methodology”. It’s a classification theory about the scientific nature of any Enterprise and the kinds of “Things” (entities) that have an existence in that Enterprise. Therefore, The Zachman Framework for Enterprise Architecture is the ENTERPRISE ONTOLOGY. The way the “Periodic Table” is ontology for “Chemistry”; the “Zachman” framework is the ontology for “Enterprise”.

Once you know the “Enterprise Ontology”, you can create /use a methodology of your choice. Using a methodology without ontology is a “trial and error” practise.

Creating the “composite model” is creating the “architecture” No, “composites” are manufacturing constructs. Primitives (single variable models) are Architecture constructs.

Unfortunately, people are building composite models by hard-binding multiple concepts together in their “model” and calling it “Architecture”.

Six columns in Zachman Framework are arbitrary, I can add few more columns on need basis Wrong, the columns are not arbitrary.
The 6 columns represent the universally accepted 6 communications interrogative i.e. what, how, where, who, when and why.
The colours are just a decorative piece; I can use any colour. I don’t see any logic or significance. The colours of the models in each Row are significant.  Here, John used the colour models as a teaching tool to re-enforce the idea that each Row is different and is the result of a transformation, NOT a decomposition of detail.

John used spectrum colours: Red, Orange, Yellow, Green, Blue and Orange.

Why he didn’t round out the spectrum with Purple in Row 6.?

The reason is that, “Row 6 is Orange to match Row 2; because whatever the Owners have in mind (Row 2 – Business Concepts – Orange) should be what is actually instantiated in the Enterprise (Row 6 – THE ENTERPRISE – Orange).”

Enterprise Architecture is only Row1 & Row 2. Enterprise Architecture is comprised of Rows 1-5. The instantiated Enterprise is represented in Row 6
Zachman Framework is complex. The framework is not complex, but the enterprise IS. The Periodic Table has to be complete in order to allow the chemists to be able to analyse, and create compounds with accuracy and repeated predictability. Similarly, Enterprise framework has to be complete to ensure that enterprise architects are able to analyse, and create enterprise constructs quickly and in a repeatable fashion to achieve the results.

The problem lies in basic understanding and application of the framework. A chemist never creates “infinite” number of compounds just because it’s theoretically possible using the Periodic Table. They create the compound based on the need.

Similarly, doctor never creates 1000 x-rays or scans of all parts of the body of a patient and stores it in the repository.

On the similar lines, the idea is not to create infinite number of composites based out of the Zachman framework, rather create those which are needed to address some problem of the Enterprise.

Views in Zachman Framework Scope (Ballpark view): Definition of the enterprise’s direction and business purpose. This is necessary to establish the context for any system development effort.
Model of the business (Owner’s view): This defines — in business terms — the nature of the business, including its structure, functions, organization, and so forth.
Model of the information system (Architect’s view): This defines the business described in step 2, but in more rigorous information terms. Where row two described business functions, for example, as perceived by the people performing them, row three describes them specifically as transformations of data. Where row two described all the things of interest to the enterprise, row three describes those things about which the organization wishes to collect and maintain information, and begins to describe that information.
Technology model (Designer’s view): This describes how technology may be used to address the information processing needs identified in the previous rows. Here relational databases are chosen over network ones (or vice versa), kinds of languages are selected and program structures are defined, user interfaces are described, and so forth.
Detailed representations (Builder’s view): Here a particular language is chosen, and the program listings, database specifications, networks, and so forth are all produced.
Functioning system: Finally, a system is implemented and made part of an organization.