Some thoughts on the Zachman Framework

I have been doing some reading on the Zachman Framework in the context of some work we are doing with the government. The ZF is popular in government circles as an enterprise architecture framework and they routinely ask for experience using it within their RFPs, especially for roles such as technical architect or business analyst. Having had lots of work in the enterprise architecture space but none specifically using the Zachman Framework, I wanted to see for myself what it was about and understand how it could support my own needs in presenting strategic plans to a client.

Having now read a few books and posts on the subject, here is my own reaction to it:

• Written in 1987, it definately has that architectural ivory tower approach that assumes that if we could only document every explicit assumption in our enterprise we would have this perfectly functioning enterprises. Having worked in lots of different enterprises, I don't know any that actually lived up to this ideal and they functioned quite well despite not having every prescribed artifact nailed down.


• I love the simplicity of the model: 6 roles and 6 interogatives. It's the simplicity that makes it "universal" - it's like saying any problem can be solved by combining asking questions and a planning/building life cycle. While I would say this is true, its also quite vague and doesn't provide a lot of specific techniques or approaches to enterprise architecture other than a method of organization.


• I like the approach in that its business centric and quite non-technical. I could quite easily explain the framework to a project manager, a business analyst and an industry stakeholder. You do not need an engineering degree to get the ideas here and the expertise is delegated to filling in the particular models.


• I really like the integrated approach that forces architects to really think about more than just code, servers, and technology. The framework puts a heavy emphasis on logistics, business cases, scheduling, business rules, and people. The "HOW" part of the framework is only 1/6 of the picture which I think is about right.


• The concept of a normalized architecture, e.g. a unique spot for a piece of information is an interesting one but hard to accomplish in practical terms. In my experience, its definitely a good ideal - I have had too many cases where the requirements document, the data model and the network diagram are changed independently and they no longer match.


• One challenge with the organization of models in ZF is that they are very model focused instead of feature focused. In many cases, you want to organize your requirements, code, etc. by feature so that you can take it out - this seems inherently different to do in ZF because your feature is now spread out in 36 different buckets of artifacts. Trying to take a feature out or change it means finding it in your master universal schedule, your master universal network diagram, your master use cases, etc. (Ideally, you could automate the entire repository of requirements so you could slice and dice in multiple dimensions so that you could search your whole picture by "sliver")


• There is a certain religious zeal about this framework from some authors - the fundamentalist belief that if you can complete all the spots on the grid that you now have this nirvana requirements repository and we can all go home until the next change request. In real life of course, the nirvana never happens and you have to cut corners like crazy to get anything out the door. While this is a nice framework, in practice many medium to large organizations could not fill in every bucket down to every explicit assumption and maintain the repository with any execution speed. This is probably why this framework is popular amongst governments, large scale industries (aerospace for example) where you have years to gain value out of your architecture investment but not used by smaller or faster moving organizations.


• There are some ways you can approach the ZF with an agile approach. Scott Ambler has a good article on this here.

In general, for a framework that evolved in the mid 80's, I was pleasantly suprised at how relevant it is in today's context. I could conceivably apply the same principles in some of the enterprise planning work I do today in very different technology contexts than what were around in 1987, e.g. portals, internet, rich client applications, data warehouses, etc. I could also see using it as a basis to analyze and document a very specific domain model instead of an entire enterprise.