The common perception (or more appropriately, mis-perception) of Enterprise Architecture in the general marketplace today is that it is one of an Information Technology (IT), model-building exercise. There is validity to that perception because, in order to engineer the Enterprise, the engineering design artifacts (the descriptive representations of the Enterprise) have to be created as they are the "raw material" for doing engineering work and the IT community seems to have the skills to produce those engineering design artifacts. 

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day. 

After 30 years of talking about this, I am still shocked at the predominant misconception that the Rows of Zachman Framework define "level of detail," or "waterfall," or "decomposition." This is just not true. The Rows of the Zachman Framework define TRANSFORMATION, NOT decomposition. Level of detail is defined in the HEIGHT of each cell (or Row), NOT the height of the Framework itself. While I originally I called the Rows "Perspectives," the underlying theory that defines the Rows is the philosophical concept of Reification. 

I was asked by a PhD student to fill out a survey for research he was doing about the Enterprise Architecture Frameworks. This is a typical question I get, and it is no wonder because of the confusion about the word "Framework." Just because Enterprise Architect Frameworks have the word "Framework" in their titles, it doesn't mean you can compare the Zachman Framework with them. The Zachman Framework is the ontology. The other frameworks are METHODOLOGICAL frameworks, and the artifacts you create by following those methodologies potentially can be mapped back onto the Zachman Framework Ontology. 

OThe Framework is the OntologyI have no idea where people get the idea that the Zachman Framework requires any documentation at all. The Zachman Framework is an ontology – the theory of the existence of essential components of an enterprise (actually, of anything) that warrant description in order to successfully create it, operate it or change it. Whether any or all of those components are described (documented, made explicit) is a function of a methodology and the choice of the Enterprise… not a requirement of the Framework.

I have been working in the area of Enterprise Architecture for 40 years and people have been telling me (and are still telling me) the reasons why they think it is impossible to do Enterprise Architecture. I think I have distilled these reasons down to five basic objections. Let me enumerate their objections before I explain why these objections exist and why they are completely unfounded. 

Welcome to my blog!I am very excited about the new developments in The Zachman Framework 3.0 and Zachman International! We have spent the last couple years "underground" refining our research, developing several new programs, forging new relationships, developing the community of practice and getting zachman.com ready for prime time! Well, the time is finally here to start rolling these things out!