What’s New with the Zachman Framework?

Someone asked me a philosophical, yet, appropriate question the other day.

Why do I still continue to use a very simple framework in my coaching and consulting with Enterprise Architecture? I began using something called BAIT (business, application, information and technology), and turned to something else – BOAIT (business, organization, application, information and technology).

I thought for quite a while, and went through what has changed since I started working in the Enterprise Architecture space.

We went from application architecture, through system architecture (which now might be known as technical architecture). I saw Meta put forward a combined application and data layer called solution, and now we’ve hit the peak in the area of solution architecture (whereas no one really speaks of application architecture anymore).

Do we use Zachman, Dodaf, FEAF, or something else? It’s all a matter of classification, and the purpose is communication. The clearest method has to be sufficient. The rest is background noise – it’s about doing and using architecture, not just defining it.

My answer is simple. I started with a very excellent book that was very appropriate in the mid 90′s. It is Steven Spewak’s Enterprise Architecture book. At the end of the day, it all boils down to Applications (solutions if you may), Data and Technology. The business drives all of the other architectures, as they are wound within the strategic plans. None of that can really change – we can add SOA, Security Architecture, or change how we term what goes on in the operations and technical areas and we will still boil it down to all of this.

Our business strategy drives which data we need to collect, process and transmit. The systems/applications and solutions will provide mechanisms to make these transformations, and the technology in the areas of software, hardware, configuration, etc. will physically allow it to be so.

Nothing has really changed my perspective – just some of the details around how and why I would collect, analyze and interpret what I’ve categorized.

What is an IT Architecture Framework

One of the most ambiguous words in the initial understanding of Information Architecture is that of the Framework. The Framework is a generic categorization method for architecture design artifacts. Any good categorization method achieves these EA goals:

1. Simplify information for understanding and communication
2. Clearly focus on independent components for analytical purposes
3. Provide and maintain a disciplined method of depicting relationshipsbetween the domains.

A Framework is a set of approaches, components, configurations,models, services, standards and principles that can guide you in your documentation adventure of a particular view of an architecture.


While there are many benefits in using a framework to guide your development efforts of an architecture, there are two that are moreelementary and prevalent than others: Guidance and Communication.

The framework is a guidance tool which is used to ensure that each architecture domain is adequately reviewed and documented, and canmost easily be compared in context to the other domains or views. It guides both the method and approach to completing an architecture,and enables all stakeholders to see a consistent and complete picture when reviewing an architecture.

The framework can be used as the primary communication vehicle between architects, the project team, stakeholders and IT technical staff. It can be used to show what you’ve planned, and how you will achieve flexibility in the future.

Other benefits that you may expect from using a framework, is the provision of a generic space and structure for a very complex and varying problem. It can include a starter set of principles, issues and concerns. It can provide guidance on which sets of diagrams and models to include.
Think of it as a “placeholders” map to what would make a complete architecture. It is also known as a set of views of an organization and its Business and IT Resources and assets.


There are numerous frameworks available to be used, but they are primarily categorized by domain. They are typically designed for government, or non-government (private organization). Some are strategically oriented and some are focused on organizing the evolution of the architecture.

An organization can choose to adopt an existing architecture framework or to build a custom framework. In either case, it is rarely necessary to start from scratch, and the primary focus should be on the stakeholders and the domains you wish to capture. Try to keep in mind that the primary goal here, is ‘Communicate that architecture!’

If you choose to adopt an architecture, consider visualizing what kind ofdata and models you will use to populate it. Ask yourself ‘what is important to my organization?’, and ‘how have we organized our departments and business in the past?’ Many frameworks are used for a particular type of community, so try to pick the one that is most similar to yours.

Enquire with peer organizations as to which type of framework they have used. There is value in understanding and using more than one, so pick the one that is the closest, and adapt it by selecting one or more components you would need to close the gaps between the one you select and what you need for your organization.

If you choose to build one, please consider finding one or two that have components of what you need and take pieces to build your own. We really don’t need to reinvent the wheel. I prefer the ‘a la carte’ method myself, and have actually trimmed one of the most simple and straight-forward frameworks available, then customized the look, feel and tools as well as the processes for it. Customize it to suit your culture and technical vocabularies for the ultimate in success!


Today’s newsletter won’t attempt to describe the Enterprise ArchitectureProcess, nor the strategy to complete it. What I can do is give you a few hints about your next move after choice. I have spent a great deal of time and effort studying and customizing decision making techniquesfor my consulting engagements, and one of my secret weapons is the’litmus test’.

After a framework has been selected, evaluate it’s use within your business environment. Review the goals and objectives in using such a framework, and see if what you picked will work. After treading througha few examples, list the lessons you may have learned and refine whatyou’ve selected.

So there you have it – my quick thoughts on Frameworks. I have many more, but these are the basics that I might write about without much effort.

Want to learn more about frameworks?  See our member site.