February 29, 2008 11 min to read

On The Zachman Framework

Warning: If you are very fond of the Zachman Framework, you are better off not reading further. The opinions are mine and mine alone of course, like anything else is, in this blog. I attended a Zachman conference recently to know all about the proclaimed Periodic table of Enterprise Architecture. As a practicing enterprise architect (if that is the right way of saying it) , I have always been curious to make my system more accessible to a wider audience. So my expectations were one of the following:

• I should learn some architectural notations that would help in better representing what I do.
• Learn some methodology to design architecture of enterprises.
• Heck.. I may even get lucky and get to see some case studies of enterprise architecture possibly. With all these mixed expectations, I sat there all agog to partake of the pearls of wisdom the maven of enterprise architectural wisdom would bequeath. He soon got going with the necessity of enterprise architecture. No surprises there! Yes, we do recognize that it is important and that is why we are here. Then he unfurled his periodic table of enterprise architecture. He explained how it progressed from one iteration of the framework to another and how it was inspired by companies in the manufacturing sector such as the aircraft building industry. He explained how a grand and conscious design is needed to put together an enterprise, as with anything else, such as a Boeing airplane. Then he explained the rationale of the framework - How it attempts to capture the answers to six questions (Who, What, Where, Why, How and When) and attempts to map these to conceptual, logical and physical perspectives of the system. “All good!”, I was thinking to myself, rubbing my hands together in anticipation of what is next. That expectation was unfortunately, not met. He next went into some kind of what I would call, semantic quibbling, to prove how his six questions and the accompanying perspectives, are necessary and sufficient to capture all the requirements of enterprise architecture. There is no need for anything else since this is the essence of human thinking as it exists for the last few thousands of years and it would be the same for the next thousand years. He said modestly that his diagram IS enterprise architecture. For a second, I was scratching my head in perplexity, wondering whether I had inadvertently stumbled into a religious gathering. Since when did the notation to capture enterprise architecture or anything else for that matter, acquire so much importance, that it became the concept it was capturing itself! (In fact, it did make my ruminations to drift towards religion since I realized that religious books are just representations of the Universal Spirit that we call GOD. All the religious unrest exists in this world because the religious texts have become GOD and the only GOD by themselves. But anyways, this is neither here nor there and is beyond the purview of this post) He called his framework an ontology. The dictionary tells me that ontology is a branch of metaphysics that deals with the nature of being. So for working on enterprise architecture, I have to delve into metaphysics. I got to say at this point that I am very wary of these aphoristic utterances that pose as science but are shrouded in an air of mystery and masked by words (such as ontology for instance), which have the air of the undefinable in them. These are best left to the alchemists and mystics rather than to a materialistic enterprise architect trying to eke out a modest living defining the systems in the enterprise. There were specialists in linguistics who contributed to this framework. For instance, they advised Mr.Zachman against using adjectives. Hence words such as Conceptual, Logical and Physical got replaced by Concept, Logic and Physics. I shook my head in disappointment and walked out of the room. Mr. Zachman might have had more to say on more tangible things. In retrospect, I do think that I was a tad precipitate in walking out so quickly. But really! I was not there to listen to a play of words. I wanted to find out how to do enterprise architecture. I went home and thought about this whole thing. My conclusion was that the Zachman framework can be used to describe any kind of physical entity - not just enterprise architecture. All that has to be done is to customize it with the lingo of the actual thing being described. For instance, replace the words data(what) , function(how), network(where), organization(who), schedule(when) and strategy(why) with cells(what), sense organs(how), position(where),ego(who), age(when) and wisdom(why) and you would probably describe a human being! Probably the analogy is not accurate. But then I don’t have access to a bunch of linguists to describe my framework. By this view, calling the framework as the periodic table for enterprise architecture looks more like a marketing ploy! It could just as well be used as the periodic table of just about anything. In fact, Mr. Zachman admits it so himself because he says that his framework has existed for thousands of years - long before any enterprises came into being. In summary, I think this framework can be used to arrive at a template that can be used to describe enterprise architecture. So it is in a sense a template for a template to describe enterprise architecture. It is not enterprise architecture by itself. After all, to paraphrase Mr. Zachman a template is a template is a template! (Look up his article an enterprise is an enterprise is an enterprise)

Comments

John: That why it is called a “framework”… Your disappointment is a lesson for EAs. You have to clearly understand the semantics of a description/document, etc. If you missed the fact that it is a “framework” or that word didn’t initially hit home - then, you have learned a valuable semantic lesson.

raja: @John Thanks for your comment. My whole point was that the Zachman framework is not a framework for architecture but a framework that can be used to create a template to describe architecture which is a different thing altogether. Calling it as a periodic table for architecture is in my view,exaggerating its importance. A periodic table gives a prescription to a discovered element’s behavior and has predictive abilities for undiscovered elements. I don’t see this framework as anything close to that. Anyways, different pills for different people.

John: I think you are still missing the point. If you research the history of the periodic table, you’ll notice that by organizing elements by their atomic weights Mendeleyev and others could anticipate the future discovery of elements. The framework is just giving you a heads-up on things that you’ll need to discover in the due course of descriptive work around a functioning enterprise. Enterprises tend to pick and choose how they want to approach the development of a functioning system. Most enterprises and most EAs are not interested in making formal descriptions of each cell relative to the functioning system. That’s okay and the framework helps organize what you formally know and don’t know as well as what you informally know and don’t know. That helps you manage risk. But understanding how much risk you are willing to take to you make decisions. The framework doesn’t prescribe to the fact that if you miss something out that the whole world stops. The framework is inert. Therefore, it doesn’t do anything. It is just a guide. And a damn good one at that. I obviously took the “believer” pill !!! The one piece of advice that I would give you is to let it sink in over time. It’s like the game backgammon… it’s very simple to play and to a beginner can seem like a skilless game. But with practice and learning you’ll find there is more to it. One the surface Zachman is a waste of time. But if you have the time… give it time!

raja: John That was a great elucidation. I quite understand why it can be useful. Again, I am going to maintain that if you found the correct way of filling the table, it is a feather in your cap rather than that of the framework. But I do recognize that there is a small value in telling you what to look for. I guess I am more frustrated with the hype attached to what I would call, a paltry template, than anything else. Anyways, great points! I will keep an open mind and look to see how I can fill it. On a side note, it might be a good thing to document what kind of diagrams can be used to fill the table. Diagramming , it looks like, is a lost art. I am an agile practitioner myself but do find some amount of drawings help. After all, the old cliche about a picture speaking a 1000 words still holds. Like the Zachman framework, diagrams are profound truths known to humankind from times immemorial. just kidding :-)

John: You can find metamodels of the diagrams - both primitive and composite - that complete the framework. The framework is not a methodology, so it is indifferent to agile or any other type of approach. So, there’s nothing wrong with following agile disciplines and using the framework. Let’s say you don’t diagram a single model, but you do have discussions around each cell… that’s fine, the framework supports that. The risk element that I spoke of before is that if you do not have a record of the disucssions, is that a problem that could come back and bite you? Not all risks need to be proactively addressed… ultimately, you can decide what’s appropriate for your needs… it’s not a right or wrong. The framework doesn’t care! Something that is inert has no feelings.

Duncan: Interesting discussion. I have always thought there are two types of research work: one to create a table and one to fill the table with details. There is a need to find a tool to better serve the latter purpose in enterprise architecting. In the current project I am involved, I found that the software tool developed and we are using for modelling business process changes and documentation may provide the need and help to extend this framework into a convenient practice for the enterprise. The main features I used from this tool are: Graphic representation of the framework Ability to drill-in the cells Ability to export to web site easily to share the outcome within the corporate Although it is still at WIP, I am pleased with the outcome so far and more than happy to share more on this approach is anyone is interested.

raja shankar kolluru: @Duncan , thanks for the comment. Yes, that is precisely what I was talking about. It is one thing to prescribe a table and quite another thing to fill it with details. Because, the devil is indeed in the details. Unless, you are an established practitioner of enterprise architecture, it is not possible to come up with a prescription of what kind of diagrams you need to fill the table. And as you do get more detailed, you would find that your prescriptions do vary a little bit to better suit the kind of project that you are doing. For instance, what constitutes my “physical model” may be different depending on whether I am writing a web application or designing a database layer. That is the kind of prescription I was looking for. I do admit that there is some value in telling me that there is a table that I need to fill up. But pointing the table out to me alone is not tangible enough for an architect like me with my feet firmly grounded in reality. The software that you are alluding to, looks very interesting. I would definitely love to see it if I can access it somewhere. Thanks