John Zachman has been making an interesting claim in the last few years… he is claiming that the Zachman Framework for Enterprise Architecture, a creation of his that, through many revisions across the years, has formed a cornerstone of Enterprise Architectural practice in many parts of the world, is an ontology.
It is not.
Let’s be clear, first off, about the definition of an ontology. There are two commonly used definitions. In philosophy, an ontology deals with the nature of being. An ontology in philosophy is a statement of “what is real”, a conceptual understanding of something that helps to answer key questions, like “what things exist,” and “how does a thing relate to other things.” Philosophical ontology attempts to answer questions like “does truth exist?” or “does energy exist?”
Not long ago, the term ‘ontology’ took on a new meaning in the context of computer science. In the late 1980s and early 90s, Artificial intelligence was attempting to create large maps of human understanding, and the term “ontology” started to creep into general use in AI circles.
Tom Gruber is widely credited with bringing the term into focus in computer science. In 1993, he wrote a paper titled "Toward Principles for the Design of Ontologies Used for Knowledge Sharing," later published in the International Journal of Human-Computer Studies. The paper can be found here. A more general discussion can be found here.
Gruber’s use of Ontology is fairly clear. In the discussion cited above, he stated:
“In the context of knowledge sharing, I use the term ontology to mean a specification of a conceptualization. That is, an ontology is a description (like a formal specification of a program) of the concepts and relationships that can exist for an agent or a community of agents. This definition is consistent with the usage of ontology as set-of-concept-definitions, but more general. And it is certainly a different sense of the word than its use in philosophy.” (emphasis added).
The goal of ontologies in Gruber’s research was focused on Artificial Intelligence. His challenge was complex: How could he get intelligent agents to converse with one another in a consistent fashion? Ontologies provided that ability, far better than simple definitions would. A concept in an ontology is defined rigorously, and the relationships between terms are specific and declared.
It is important to note that there are no implicit relationships between terms in an ontology. Relationships, where they exist, are explicitly declared, and in many cases, constrained. Relationships are not implied. There is no notion that two terms may be related to one another, or not, as needed.
And here is where we come back around to Zachman. While the Zachman Framework (ZF) defines, in a 6×6 grid. a self-contained set of terms, the ZF does not declare the existence of any relationships between them. In fact, he implies that anything can be related to anything, without constraint. While practitioners can reasonably discuss the composition of primitives into composite objects, the Zachman framework does not describe any composite objects at all.
In defining a “type system” for “things related to enterprise organizations,” the Zachman framework provides a simple set of data types, and little else. It is useful, but insufficient.
Using ZF, I can look at a thing and figure out “where in my taxonomy does this thing belong?” But the type system is too broad to imply many constraints. The Zachman framework is full of generalities. Specific types are not described. This means you can understand a “thing” but not really talk about it at a conceptual level because it is too vaguely defined. Specificity and clarity are required to draw conclusions. That requires a great many more objects, and specific, constrained, declared relationships between them.
Without concrete objects and specified relationships, ZF cannot solve many EA-specific problems. You cannot, using Zachman alone, have two people draw the same conclusions from the data that you collect, because your data is unstructured. Conclusions come from structure and relationships, not definitional types. You need a model that includes relationships to infer a conclusion drawn from the data. EA needs ontologies (metamodels).
An ontology allows inference. The Zachman Framework does not.
The Zachman framework is not an ontology.
I agree: ZF is not an ontology. At best it’s a taxonomy, but it’s so far from comprehensive or complete that it’s not that useful in practice.
Not only not useful, but often seriously misleading. To me the worst problem with Zachman is not the framework itself, but its stated aim as a framework for ‘engineering the enterprise’. Since an enterprise is, by definition (e.g. IEEE-1471), a human construct rather than a technical one, it is by definition not amenable to change via mechanistic approaches such as ‘engineering’. In that sense, Zachman fails in its aim even before it starts.
It’s handy as a checklist, but that’s about all.
(A real pity that the framework isn’t much use, because Zachman himself is one of the nicest people I’ve ever met. 🙂 )
As I struggle to comply with military requirements to define an EA using DoDAF, I’m finding the same kind of problem. Its artifacts are centered on organizational interaction, not business processes and functions. I attributed this orientation to the military’s personnel structure itself. Its not about what you are trying to accomplish, but who told you to do what.
I attended the Enterprise Architecture Planning training in 2002 and was trying to implement EAP in my job with mixed result. The problem is really not the framework (the tool) but the goal and mandate. If the goal is to get better understanding or description of the EA, then Zachman or the Federal framework are OK because it provides some consistency in the taxonomy and classification even if these are vague. However, if architecture decisions are to be made, I found Zachman and its close cousins inedaquate because the large gap between concepts and implementation. I did achieve some success when I could construct alternative visions constructed on top of the framework to analyze the dependency, pro and cons and high level roadmap in a simpler visual representation. That’s pretty much it though. What do you expect from such a high level framework (besides the political agenda behind a lot of such bureaucratic exercise)?
I think it is more of a taxonomy – classification of things. To put it as related to study of existence of things and their relationship paints it a reactive mentality (after the fact problem solving)
I have to say that I do like the Zachman Framework even though I agree with almost all the comments. I agree it is not an ontology. In fact, I attended a good Business Architecture course a couple years ago by Intervista Inst, which used Zachman very effectively by defining the relationships between a subset of cells and showing what that means to the business. I think that confirms your point. We never took Zachman to be "the" EA, but simply used it as a tool to test if we had covered key "topics". It served us well and we never had any intention to fill it all in (such an intention separates it from a value proposition).
I am comfortable with the Zachman Framework being characterized as an ontology. The argument presented by Nick that is isn’t an ontology seems to focus on it having no explicitly declared relationships among its components. In fact, there are two very important categories of relationships in the Zachman Framework: Integration and Transformation.
The components of each cell integrate with each of the components of the other five cells in each row, and they also transform from the components in the cell above them and transform to the components in the cell below them (allowing for Row 1 not having cells above and Row 6 not having cells below, of course.
These relationships are explicitly described in the Framework Standards (https://secure.zachmanframeworkassociates.com/2/production/C4/Login.asp). You’ll need to register (free) to see them if you are visiting for the first time.
Hi Anthony,
The link only appears to work if you get to it from ZachmanInternational.com. I spent some time wandering through the framework standard and I can say that there does appear to be a set of entities defined here that are NOT defined in the framework itself.
That is a good sign. Two problems:
a) Zachman seems intent on defining the framework as a 6×6 matrix. As his framework evolves, this paradigm is clearly inadequate. Unfortunately, his unwillingness to redefine the ZF in light of these learnings creates confusion. He seems intent on burying all learnings below the top-level matrix, which is absurd. I take him at his work that, in Zachman’s opinion, the framework is a 6×6 matrix. As such, it is not an ontology.
b) The entities that are defined in this online resource illustrate more mature thinking than the original matrix. That is good. However, the integrations between the elements, while declared, are not accurately and clearly defined. It is simply not interesting to say that "business entity" integrates with "business end." At a minimum, it is sufficiently interesting to say that a business entity "may have" business ends. That specific declaration of the relationship between these two entities is a minimum requirement for describing a metamodel, and is missing from even this more mature "hidden metamodel" that the ZIFA team is relying on.
Hi Nick –
Sorry about the problem with the URL that I provided. I didn’t realize that it timed out. For anyone else who would like to see what we are talking about, the log-in page is accessed via this link: http://zachmaninternational.com/index.php/home-article/17#maincol .
When we talk about the Zachman Framework, I think we have to keep in mind that it is more than just the poster showing the 6×6 matrix, just as the Periodic Table of Elements is more than the table that we usually see with only the names of the elements in the cells. The matrix diagram is merely a technique for displaying the essence of the Framework, which is the intersection of the two classification schemes that is represents: the answers to the complete set of questions that could be asked about anything, and the stages of “reification” – moving from abstract idea to instantiation. The form used to present the intersections to us helps us to understand it, but I think it is not all that important in helping us conclude whether or not it is an ontology.
I think it is also important to clarify that Zachman does not say that the Framework “is a 6×6 matrix”; rather, he has says that it is typically depicted as such. I think this quote from the article that he wrote in 1992 with John Sowa ("Extending and Formalizing the Framework for Information Systems Architecture", IBM Systems Journal, Vol 31, no.3, 1992. p.590-616) explains it best: “Figure 18 shows the six columns in a hexagon, where each one is related to each other. The traditional tabular order is merely a concession to paper or flat computer displays.”
Regarding your second point about the relationships among the cells of the Framework, I think it is useful to remember that the frameworks that we are looking at (the “normative” Zachman Framework for describing anything, the Zachman Enterprise Framework for describing enterprises, etc.) are very high levels of abstraction. They (not just the 6×6 matrix diagram, but the underlying standards and definitions) will only show that there is a relationship among the cells and will not define the actual relationship in an actual instance of whatever is being described. For example, for any given business process, there has to be an associated location, a motivation for having created it, etc. You would need to define the actual relationship between an actual process and an actual location, etc., in the design of an actual enterprise.
As an aside, ZIFA closed down in December, 2008.