Zachman

Anyone considering IT architecture and especially "enterprise architecture" will quickly come to look at the Zachman Framework created by John Zachman (http://www.zifa.com/). This is a framework designed to assist in the development and management of "comprehensive and aligned" enterprise architecture models.

The framework is a grid

• The columns being fundamental aspects or questions: who, what, when, where, why and how.

• The rows being different perspectives or views: the planner, owner, designer, builder, vendor/sub-contractor and the product or enterprise itself.

The idea is that if you have described the details in each cell � you have a complete, comprehensive and aligned description of the enterprise and its IT.

What John Zachman does not explain or endorse is how you might go about completing his framework in a specific case (although he offers a consultancy service which presumably follows a well developed approach to assist the development of architecture). I will explore methodologies in another section in this site.

An important assertion is made, that the framework is complete and sufficient, and does not contain duplication (this last in part supported by a "rule" saying that each cell is unique).

Problems

From my first viewing, I found the descriptions given for some of the cells slightly contrived, and I was not certain (and I am still very uncertain) if this is because of a fundamental flaw in the framework or because of a lack of understanding on my part.

An example of this is the "why" column, motivation. As you go down the column you start with major aims and business plan. This seems sensible. But when you get to system model (designer) and down it talks about rules. I don�t think rules can be motivational; possibly they are constraints (e.g. in the case of regulations) which I suppose can go under the heading of "why". But aren't rules (when you are at the system or technology perspective) like functionality which might be better under a "what" or "how" heading? So, for me anyway, there seems a disconnect

I call the different "columns" aspects and therefore each cell is a different aspect of a particular perspective. A row makes a complete perspective and therefore the aspects for that perspective offer a complete picture. The question for me is why is the Zachman framework a grid? Why in general should any two perspectives have the same aspects? Does therefore the framework miss aspects for some perspectives, and include irrelevant ones for others? Moreover the framework has the concept of recursion where aspects at lower perspectives include constraints from above and this strongly presumes a common set of aspects for each perspective.

The framework does not seem to support business aims or motivations made possible by technology. Rather the IT solution model fully derived from business aims as the motivations etc. flow down the columns. This may depend on how you use the framework, of course. But I believe that the framework would make it much easier to track business change, rather than technology change that fundamentally affects the business model.

The framework does not seem to provide (or perhaps I mean require) any cohesion. For example, the how and why may not match. This criticism may very well be unfair as you can't really blame the framework itself if it is used incompetently. However I think that because the framework splits business processes across aspects it therefore makes it hard to reconstitute the processes themselves and verify the architecture.

Something often pointed out about the Zachman framework is that it is very "large". Is this size essential (by which I mean, if the framework it is not complete then you have missed out some important considerations), or can we define a smaller framework?

Despite these issues, there is tremendous value in the Zachman framework which certainly is much preferable compared to an ad-hoc approach.