EA Articles / Reference

With that, there is a question I am frequently asked at Zachman International and at the FEAC Institute by Enterprise Architects who are trying to determine their best course of occupational and personal advancement and who are often charged by their organizations to become experts in the EA discipline. This article is my attempt to answer that question, which is: "I'm looking at getting an EA certification. Can you tell me whether I should get Zachman Certified… or FEAF… or DoDAF… or TOGAF®. What’s the difference?”

You can interpret this article as more marketing, or interpret it as additional hype; the bottom line is, however you interpret this, there is a critical difference in the certifications available.

Ontology vs Methodology

Most people are under the impression that the EA Certifications available are in direct competition with each other; much like the bitter Coke vs. Pepsi battle for market share. In my travels, it is amazing to see the vehement discussions in loyalty to one particular “framework,” or methodology, or practice or whatever. While this issue of competition is true in most cases, the Zachman Certified™ program DOES NOT compete with the other certifications that are available. That’s right, it does not compete.

Our intent is not to go head-to-head with other programs, attempting to dissuade people from obtaining certifications such as TOGAF, or FEAC’s® DoDAF or FEAF certifications or whatever. In fact, we actually encourage obtaining those certifications because they only strengthen EA understanding in terms of how to actually implement architecture.

How is this possible? In order to understand the difference between Zachman® and the others, you have to be able to understand a critical, defining differentiation between an ontology and a methodology.

When I tell people this, I usually get the same reaction: “I’m pretty sure I know what a methodology is, but what the heck is an ontology?”

Let me help:

Main Entry: on·tol·o·gy
Pronunciation: \än-ˈtä-lə-jē\
Function: noun
Etymology: New Latin ontologia, from ont- + -logia -logy
Date: circa 1721
1 : a branch of metaphysics concerned with the nature and relations of being
2 : a particular theory about the nature of being or the kinds of things that have existence

Main Entry: meth·od·ol·o·gy
Pronunciation: \ˌme-thə-ˈdä-lə-jē\
Function: noun
Inflected Form(s): plural meth·od·ol·o·gies
Etymology: New Latin methodologia, from Latin methodus + -logia -logy
Date: 1800
1 : a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures
2 : the analysis of the principles or procedures of inquiry in a particular field

There happens to be a distinct difference in Enterprise Architecture between the ontology and various methodologies. In fact, there happens to be a distinct difference in all scientific disciplines between the ontology and various methodologies. The difference seems fairly obvious, but in an emerging field it is probably no wonder that there is some confusion. The best place to start is with the Merriam-Webster definitions (2009) above.

Webster defines an ontology as “a particular theory about the nature of being or the kinds of things that have existence.” In contrast, a methodology is “a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures,” or “the analysis of the principles or procedures of inquiry in a particular field.”

This is a very critical difference. With regard to EA, this is the difference between a set of standards about what exists in an Enterprise (ontology) and a set practices (methodology) for building implementations. Methodologies potentially could employ the ontology making the implementations of the methodology architected; however many practitioners who are marketing EA certification programs are posing an issue that there is no set of standards and that you should just “use their method.” I propose to you that there is a set of standards, or ontology: The Zachman Framework™.

The Standard Exists - The Zachman Ontology™

The above may sound like a bold statement, however the more research we do, the more we realize that the reason The Zachman Framework has stood the test of time and has continued to define the Enterprise Architecture space is because The Zachman Framework is NOT a methodology (a particular practice or procedure) rather it is the ontology (the complete set of what exists) of an Enterprise and therefore is of grave significance to Enterprise Architecture because it is the basis for classification.

The Zachman Framework has provided the baseline for numerous methodologies and elaborations over the years. A quick look at Jaap Schekkerman’s (2004) “Enterprise Architecture Frameworks History Overview” (p. 89) defines this most clearly:

The Enterprise Architecture Frameworks History Overview

Exhibit 1

An ontology tells you what is there, and a methodology tells you how to use what is there. Methodologies ARE NOT the ontology (or the standard). Methodologies BASED on the ontology (or standard) produce results that potentially are architected and predictable. Conversely, methodologies that are not based on the ontology simply produce results (good or bad- there’s no way to tell ahead of time).

Chemistry and EA

Let’s look at the discipline of chemistry. It is worth taking a closer look at a metaphor to help bridge the gap between these two concepts. The Periodic Table of Elements is the chemical ontology published by Mendeleev in 1869. It tells chemists what’s there - what exists in nature, how to classify things. Not how to use all the pieces, but what actually exists. The Periodic Table is not “implementable.” The Zachman Framework is the Enterprise Ontology. It too tells enterprise architects what’s there - what exists, how to classify things. Not how to use all the pieces, but what exists in the Enterprise.

At the heart of ANY discipline or profession lies classification- which makes the practice of the discipline predictable and repeatable. Mathematicians have to understand the classification of integers in order to predictably repeat mathematics. Linguists have to classify phonemes and letters and alphabets in order to predictably repeat language. Chemists have to classify primitive elements in order to predictably and repeatably practice chemistry. Likewise, Enterprise Architects have to understand how to classify their artifacts in order to predictably and repeatably be able to “do” Enterprise Architecture and solve Enterprise problems with results that actually matter.

Chemistry became a discipline because of the Periodic Table and it could be decidedly argued that Enterprise Architecture is becoming a discipline because of The Zachman Framework. Both are sciences because of an ontology... a standard... the classification.

Chemical engineering is the development of methodologies for producing compounds, just like most EA certifications are methodologies for creating compound implementations of an Enterprise. These are the things that are “implementable.” Chemical engineering (equivalent to EA methodologies) define procedure or practice for creating compounds - chemicals when referring to chemical engineering and implementations when referring to EA methodologies. Without the ontology (in both cases), the methodology (or procedure) is alchemy: based on personal experience, trial and error, guess-work or even magic. Chemical engineering is predictable and repeatable because of the Periodic Table ontology. Armed with The Periodic Table of Elements, alchemists became chemists and what they did migrated from personal experience to science. They could then predict that every, single time they put two hydrogen atoms together with one oxygen atom, they would get water... every time - and they understood why it worked. It was no longer best practice.

This is precisely the difference in Enterprise Architecture. The Zachman Framework is the scientific ontology - the standard - the classification. It tells architects what’s there, what exists in the Enterprise. It implies nothing about methodology. Other “frameworks” typically are methodologies because they define method for producing “composite” artifacts. They define procedure or practice for creating compound implementations of the enterprise, some of which may be architectural in nature, which actually use the ontology (chemistry), the others simply producing implementations which are results-based and unscientific based on experience (alchemy). The other “frameworks” vying for attention focus on procedure, or how to use the pieces (elements) defined in The Zachman Framework. If one of the myriad of available frameworks have a “start here,” then you know you’re dealing with a methodology and therefore are dealing with some “chemist’s” (or worse, some "alchemist’s") way of viewing Enterprise Architecture (good -scientific- or even bad -unscientific- in some cases).

In the Zachman Certification, we teach about existence, about science, about classification, about the things that exist in the Enterprise, about the ontology. Other certifications are typically about specific practices to employ the “Enterprise Architecture” that you may, or may not, have defined. They are about methods and choices. Every methodology has to contain the pieces of the ontology or else they are just alchemy. In fact, these methodologies could be ways to use The Zachman Framework.

Framework vs. Framework

The word “framework” turns out to be the culprit in most of this confusion. When John published The Zachman Framework in 1987, he meant “structural framework.” The other “frameworks” that have come along since then have used the word “framework” to describe a “methodological framework.” Both are right, but the methodologies that exist (calling themselves “frameworks”) are procedural in nature. There is a significant difference between a structural framework, which specifies distinct, predictable deliverables (The Zachman Framework), and a process framework (others) which specify activities, tasks or methods to be accomplished. Different methodological “frameworks” deliver different results from others. The point is, any one particular method of doing things often can be mapped against The Zachman Framework to understand the underlying assumptions and predict the end-result. In this fashion, a method or a methodological “framework” can be assessed for its appropriateness to an Enterprise. However, the problem becomes that once a methodology is learned, then it can sometimes be limiting as it is just one way to deploy Enterprise Architecture.

Zachman Certified™

So, this turns out to be the hard reason that the EA certifications available and Zachman Certification do not compete. In fact, they are quite complimentary because you could use the base language of The Zachman Framework ontology in what you learn in a methodological framework certification to produce predictable, ARCHITECTED results that are consistent with the needs of your Enterprise.

The casual observer (and sadly to the seasoned professional in some cases) when viewing The Zachman Framework would say that it is a nice Framework but it appears as a bunch of disjointed cells. They haven’t taken the time to understand, or they are so influenced by some methodology which technically doesn’t even compete, that they can’t see that the unique utility of The Framework lies in the integration (across the Rows) and the transformations (down the Columns) of the classes (“primitive” Zachman Framework cells). This is what allows architects to build the composite implementations (chemical engineering) of their Enterprise ontology (Periodic Table) to produce predictable, repeatable results (a science). These integrations and transformations are like “mortar between the bricks.”

The methodology certifications available potentially are ways to USE The Zachman Framework. The Zachman Framework is the common language specified for Enterprise Architecture, the enterprise ontology (standard), or the classification of everything that exists in your enterprise. Getting Zachman Certified is like understanding that two parts hydrogen and one part oxygen will result in water, rather than mixing a little of this, with a little of that and hoping you get water.

Methodology certifications, in most cases, that are not based on an ontological foundation are like getting a certification in alchemy - you get someone's method about how to do things which may, or may not, be helpful in your organization. It's just one way to do things. A Zachman Certification is like getting a certification in chemistry. We teach you to understand the underlying constructs of what is happening and why it is happening so that you can make your own methodological choices - not simply employ someone else's. That’s not to say that methodology certifications are not useful or even necessary, it’s just to say that you are learning to employ a practice rather than the science and that you could be getting ahead of yourself.

We recognize that knowing how to do something is very valuable and is the next logical step after you know why something exists. This is precisely why we own FEAC and offer other methodological framework certifications that are based on the ontology. This is also why the Zachman Certification and other “EA” (methodology) certifications are complimentary. Getting certified in a method is very good and we recommend that architects do that, but if you have certification in the underlying theory of the methodology (Zachman) and then get a methodology certification, this makes you far more valuable because now you are the “chemist.” Not only do you know how to do something, but why you do it and if you should make modifications to it. YOU are deciding what is going to happen because you know the science of why it is happening, not just the prescription of how someone says to do things. Some methodologies tell you to “just do this, and... Presto! You’ve got Enterprise Architecture.” Are you sure? However, if you know the science, then you can use some of this methodology, some of your own, some of any other methodology. The Zachman Framework becomes your personal diagnostic and quality assurance tool for defining the issues that specifically face you.

We would in no way suggest that other EA certifications are not valuable, but we want to teach you why they are valuable and if the one you are considering is right for you. What if the methodology you are certified in doesn’t address the issues in your organization? If you understand the ontology (Zachman), then you define your own methodology, diagnose your organization and implement a strategy for addressing your unique issues. Our recommendation is to get certified in the Enterprise Ontology first, then you will be equipped to know which methodology fits you best.

Conclusion

So you see, the set of standards in EA does exist. We have spent decades defining these standards. I think you’ll find that all the pieces are there and that any scenario you can think of can be mapped against The Zachman Framework - and the certification you already have, or are considering, in some methodology just became way more powerful because you now understand the ontology- the science.

The Zachman Certification is truly geared toward solving General Management problems, not spending months, or even years, building models that no one knows what to do with. We have found that by doing some preliminary work identifying the “primitive” elements defined in the Zachman Enterprise Ontology, takes far less time and the re-use you get from these primitives to address other issues in the organization is extraordinary. These primitive elements allow you to generate massive composite models “on the fly” that typically take 3-4 times longer to generate without them; and the analytical capability is like nothing you’ve seen. This is a new way of thinking, a new “scientific” EA.

Closing Thoughts

With the sheer amount of complexity and change that has defined the present state of our world, it’s no wonder that more executive leaders are turning to Enterprise Architecture as a means to solve their most painful problems, plan a way out of situations, reduce their complexity tax and set themselves up for the future. My intent in this article is to show that there is merit in all certification programs, but those that are derived from The Zachman Framework ontology are especially significant in that they are fundamental contributors to Enterprise Architecture as a science. The Zachman Framework is about solving real, business problems. It is not about building a bunch of models that will sit on a shelf somewhere.

I think a wise man once said that, “it is my opinion that Enterprise Architecture is the determinant of survival in the Information Age.” - John A. Zachman (2008) in “The Concise Definition of The Zachman Framework™.” Hopefully this brings a bit more clarity.


References

• Schekkerman, J. (2004). How to Survive in the Jungle of Enterprise Architecture Frameworks. Victoria, BC: Trafford.
• Zachman, J.A. (2008). John Zachman’s Concise Definition of The Zachman Framework™. Retrieved for this article from the world wide web: https://zachman-feac.com/component/sppagebuilder/page/145
• Retrieved for this article from the world wide web: http://www.merriam-webster.com/
• The Zachman Framework™ graphic is available for no cost with registration at http://www.zachman-feac.com

© 2009 John P. Zachman, Zachman International®, Inc.