Would you change the Zachman Framework?

What do you like about the Zachman Framework? What don't you like? Is there anything that you would change? The Zachman Framework is such a common schema for developing our architectures that it is important to discuss any limitations as well as benefits that it might impose on our work.

John can rightly be called the father of enterprise architecture. But like all things, the Zachman Framework is good for some things, and not for others.

In a previous blog I talked about why I felt the need to create an alternative framework - the Information FrameWork (IFW). The Zachman Framework worked very well in certain contexts, but it didn't work for the situation I was working in.

In creating this alternative framework I realised several things that I think are very important in an architectural framework. If you like, these are principles for a framework:

The axes or dimensions of the framework should be distinct and clearly labelled. You don't need to agree with the labels, but it is important that their intent and meaning is clear.

The values for each axis or dimension should be consistent with each other and form a coherent set. The set does not have to be comprehensive - it can be a partial set.

It should be easy to extend or modify the axes or their values.

The intersection between values of the axes classifies the architectural artefacts or deliverables.

This is not a comprehensive set of principles, but it is sufficient for this discussion.

By applying these principles, we can ask the following questions to validate any framework:

Are the axes or dimensions distinct? Are they clearly labelled?

Are the values for each axis consistent with each other? Do they form a coherent set?

Is it easy to extend or modify the axes? Is it easy to extend or modify the values?

What is the set of artefacts that are classified by the framework? Are these sufficient for your needs? Are there any deliverables that cannot be classified by the schema?

In the Zachman Framework

The five horizontal rows are called "perspectives" and the six vertical columns are known as "focus" areas. The perspectives may not be sufficiently distinct - for example should there be an owner for the detailed representation? To be more distinct, "responsibilities" could be separated from "perspectives".

Values are partial. For some projects the focus areas may not be the most appropriate set.

The axes are rarely modified or changed. The values can be extended or modified, but the framework is often accepted as a given.

The schema doesn't describe all architectural products.

What do you think? I am very interested to read your comments.

Frameworks are very useful - is there a better approach? Instead of starting with a pre-defined framework, try starting by selecting the axes or dimensions that are needed for your architecture. Then decide the required values to populate each one. You will end up with a multi-dimensional framework that is fully customised to your needs.

Popular White Paper On This Topic

1 Comments

UnknownJul 4, 2007

James McGovern, writing in his Enterprise Architecture: Thought Leadership blog is quite clear that he would change the Zachman Framework. He writes: "Emphatically yes. The Zachman framework is only useful to enterprises who believe enterprise architecture is about the savage creation of comprehensive documentation that sits on the shelf. The Federal Government is one example that comes to mind."

Probably the single thing that makes people think that enterprise architecture has little value is unnecessary documentation. The shelf-test is a simple way of showing whether documentation is useful or not!

A key aspect of any framework is that not all parts of the framework have the same importance or relevance. For example, some cells in the Zachman Framework will be useful in one situation but not in another.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.

Only half of IT is about technology, the other half is about information. Architecting Information is about how to use information ...
more

Only half of IT is about technology, the other half is about information. Architecting Information is about how to use information effectively to manage organizational complexity and change, to create a business advantage, and to make a difference in the world. My Technorati Profile.
less

Receive the latest blog posts:

Share Your Perspective

Share your professional knowledge and experience with peers. Start a blog on Toolbox for IT today!

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.