The Zachman Framework for Enterprise Architecture
Draft 1999.01.31 Andrew Faulkner

The BC Government provided an interesting training opportunity for almost 50 information systems employees by bringing John Zachman to Victoria to lead off a three day methodology course. The Zachman Framework for Enterprise Architecture, draws upon the discipline of classical architecture/construction and engineering/manufacturing to establish a common vocabulary and set of perspectives—a framework—for defining and describing today's complex enterprise systems. It is a logical structure for classifying and organizing those elements of an enterprise that are significant to both the management of the enterprise and the development of its information systems. This report will not dwell to heavily on exactly what the framework is, instead I refer you to the resources found at the Zachman Institute for Framework Advancement web site (http://www.zifa.com/articles.htm). The focus will be on the performance by our profession as system developers and some of the extrapolations that John Zachman challenges us with.

Many of Zachman's prognostications come from the belief that the enterprise is the system. Your business is defined by the processes in it and many of them are now automated and managed by those of us who are members of the information systems community.

John Zachman says, "To keep the business from disintegrating, the concept of information systems architecture is becoming less of an option and more of a necessity for establishing some order and control in the investment of information system resources." This is vital in the private sector to prevent a dysfunctional organization which would inevitably go out of business. It is imperative in the public sector where a dysfunctional government may lead to a break down in civil society with the outcome being shooting in the streets!

Information professionals now work in enterprises that are information dominant and highly dynamic. Many IS groups have lost their credibility to deliver on time, on budget, systems that meet the business requirement. Some sources claim that only 15% of projects succeed when measured against this criterion. Some organizations have gone as far as "firing" their IS shops and outsourcing the work in hopes that this will fix the problem. There are two difficulties with outsourcing your architecture development and management. Firstly, you loose the ability to define who you are as a company. You have lost control of your organization. Secondly, you will lack the ability to rapidly accommodate change. Ability to accommodate change will differentiate the successful enterprise from the failures. It is vital for an organization to clearly articulate its strategy and then successfully translate that into an architecture and an implementation. We've heard it before: Plan, Design, and Build.

Following the first day of introduction to the framework Ron Ross and Gladys Lam of Business Rules Solutions, Inc (http://www.brsolutions.com/) provided a two day training and workshop on their rules based methodology. Through a strong business focus and an adherence to the Zachman framework they provide a compelling approach to making sure that IS development effort "gets it right" and has concrete relevance to the enterprise. The whole three day course was made possible by the sponsorship of the Data Administrators Forum in the BC Government and in particular the efforts of Rick Robertson and Jeremey Janzen I.S.P.

What the Zachman framework contributes to the IS development problem is clarity of thought. It provides a map that covers the complete terrain from strategy to implementation. Zachman's work provides reassurance that at each of the six audience levels (planner, owner, designer, developer, translator, and worker) as long as we satisfy the basic six interrogative questions about the system (what, how, where, who, when, and why), and have traceability between the audiences and across the questions, then we have done a good architectural job. What has disappointed some framework critics is that no specific path is provided. You have a framework but no step-by-step methodology that can be followed. This is true but what the framework does provide an ability to evaluate a given methodology to see what it does cover and what it is missing. Our challenge is to fill in the gaps and ward against the misinterpretation and misplacing of knowledge that leads to tragic failures of implementation and disrepute of the IS profession.

About the Author:
Andrew Faulkner (afaulkner@datagruven.com) is the Data Warehouse Technical Architect at the Ministry of Environment, Lands, & Parks. He is also the administrator of the BC Public Service Information Systems Employee web forum (http://members.home.net/bcpsise/)

<Home>