What’s Wrong With The Zachman Framework?

Introduction

When I first encountered the Zachman Framework around 15 years ago, I was struck by its elegance and generality. In common with the best data models, it provided a new and revealing way of
perceiving information, yet one which seemed so natural that my immediate response was “why hasn’t someone done this before?”

But elegance and generality in a data model should also prompt some critical questions:

1. Are we in danger of mistaking elegance for truth – and hence failing to consider alternatives?
2. What are the limits of the model’s applicability?

In the case of a data model developed for any purpose other than to specify a database, we should also ask: “exactly how is the model to be used?” and “is it fit for that purpose?” Finally, we
need to objectively evaluate the results of using it in practice.

Over the years, the Zachman Framework has become an icon of the data management community (and the North American data management community in particular), to the extent that some of the above
questions have been forgotten or put aside.

Last year, I chose as my topic for a DAMA / Metadata conference address “Thinking outside the Box”, and used the Framework as an example of a box which might limit our thinking if uncritically
accepted. After the presentation, my co-author Graham Witt and I were speaking to a well-known proponent of the Framework, who told us that he had followed my suggestion of stepping outside the box
for a few minutes, but that “the law of gravity hadn’t changed”. Mr Witt, living up to his name, responded “you mean, the law of gravitas…”

In the past 12 months or so, I have taken advantage of my presentations and panels within the DAMA community to take a few pot shots at that gravitas and the assumptions which support it –
assumptions which I believe we need to question from time to time. This is not to say that the Framework is unsound, or not useful. On the contrary, I believe it is a valuable part of the
information systems body of knowledge, and deserves to be in every IS professional’s toolkit, at least as a general idea. It provides a common language for discussing a range of important
concepts, and has arguably been the most successful platform for promoting data management and architecture ideas outside the specialist community. That said, we need to be conscious that most
business and generalist information systems people do not have the detailed “row and column” knowledge that is common amongst data management practitioners. Craft-specific terminology can hinder
rather than facilitate communication and foster stereotypes:

My concern here is not with the Framework per se, but with some important assertions and assumptions which appear routinely in presentations by respected authorities on data management and
architecture – and thus become part of the accepted wisdom in these fields.

The remainder of this article looks briefly at three of these:

1. The “correctness” or “naturalness” of the Framework
2. The use of architecture and building as metaphors
3. The use of plausibility rather than track record in selling the need for enterprise architecture initiatives based on the Framework

I take issue with these matters not only to provoke discussion, but because I have consistently advanced views which are at odds with them. Respectively, I believe that:

1. Data modeling (or, more broadly, categorization) involves choice – and modelers need to actively explore alternative classifications of data.
2. A tactical approach to data management, based on individual high-value initiatives, is likely to be more successful than one centered on an enterprise architecture.
3. As professionals, we need to look objectively at industry experience with particular tools and techniques, and advise our clients accordingly.

1. Six Serving-Men – or Seven?

Advocates of the Framework frequently cite its “naturalness” – in particular that of the six columns, which correspond to the six interrogatives in English, as in Kipling’s well-known poem:

This appeal to something much more fundamental than mere information systems or business concepts is likely to suggest that the Framework was discovered rather than invented, and discourage us from
proposing alternatives, even if the placement of some information systems artifacts (such as object classes) seems to need a bit of shoe-horning. Indeed, it may encourage us to see the Framework as
“the meaning of life” (the analogy with the law of gravity is in keeping with this) and to deploy it for uses well beyond those originally intended.

Anyone who has spent some time working with data models will be aware of the generalization trap: make a model sufficiently general, and it will accommodate anything. Unfortunately, as the level of
generalization is taken higher, the value added by the model decreases (classifying everything as a “thing” tells us nothing).

In this case, however, I think it is more important to recognize that the categories themselves are not as well-grounded and fixed as the “six serving men” argument would suggest. I am indebted
to Canadian consultant Henry Feinman for reminding me that there are (at least) seven single-word interrogatives in French, including combien which translates as “how many” or “how much”. These
interrogatives have quite distinct meanings from the other six, and it seems a little harsh to exclude them only because they require two words in English. If the inventor of the framework had been
Zachhomme, perhaps the framework might have been different.

With my tongue only slightly in my cheek, I propose the addition of seventh and eighth columns to the Framework (to be termed, of course, the Feinman-Simsion Columns), covering the volume and
financial perspectives[1]. At the very least, we should feel comfortable contemplating additions of this kind without being concerned that we are interfering
with the natural order of things. Alternatively, proponents of the existing Framework who cite the “six serving men” argument need to explain why they have excluded these two.

2. Architecture – or Urban Planning

Proponents of the Framework, including John Zachman himself, regularly invoke metaphors from building (hence architecture) and manufacturing. We hear of enterprises being constructed and of the
folly of undertaking construction of any kind without a blueprint.

I have no argument with the need for well-documented designs for buildings and manufactured products, and frequently draw on this analogy to advocate high quality database specifications. But
enterprises and their systems are not analogous to manufactured products, buildings, databases or even complete computer applications. In particular, they grow over an extended period of time, in
response to a changing environment and evolving internal plans to deal with that environment. There is no design stage at which the shape of the mature enterprise is laid out on a blank slate; at
best, there is a series of “designs” in which the existing enterprise is a key input or constraint. Nor are most enterprises in a position to dictate systems design at a detailed level:
increasingly, packaged software is likely to form a substantial part of an enterprise’s systems portfolio.

If we want a metaphor for the task of coordinating an enterprise’s systems, urban planning would seem much more appropriate. The urban planner is usually heavily constrained by what is already in
place, relies largely on coordinating initiatives funded by others, and will frequently need to compromise with developers. This is not an original analogy: on the contrary it is widely used by
information systems “architects” to describe their work. Unfortunately, the argument for urban planning is not as fundamental and compelling as the argument for design in manufacturing. The
design is essential to the manufactured product. But towns have grown without urban planners.

There is a downside to using an analogy which exaggerates the importance of one’s discipline. Sooner or later, it will become apparent that the prophets of doom were wrong: organizations have
ignored (or consciously rejected) their advice but have remained competitive.

3. Show me the money

Perhaps my most serious concern with the Framework lies in it being advocated as the basis of an architected approach to enterprise-wide information systems planning and development, on the basis
of plausibility rather than evidence. We are regularly presented with the theoretical arguments for using the Framework, and not uncommonly warned that failure to “get with the program” will
result in business disadvantage and even failure. But remarkably little data is offered in support of this.

Rather, we are offered evidence of adoption – very much a second best option to evidence of success. The use of the Framework within the US public sector, in response to legislation which requires
architectures to be developed, is often cited – but not its track record in producing better outcomes.

In 1989, we could not reasonably have expected more than an argument for plausibility, but 15 years later we should be in a position to take a retrospective look at the track record. The academic
research that has been done on data management in general has not been encouraging – small wonder that it is rarely cited. We cannot expect industry professionals to organize academically-rigorous
evaluations (although the apparent US Government investment in the Framework would suggest that some funding of independent research would be well advised, if it is not already underway), but we
should expect proponents of a well-established and widely-used framework to offer well-analyzed case studies. I am not saying that these examples do not exist or even that they have never been
presented: rather that they are not sufficiently in evidence at forums in which the theory is discussed, and that many proponents do not seem to have them “at their fingertips”.

What we do not want to hear is that “the theory is sound but people aren’t doing it properly” – followed by a reversion to a discussion of theory. Such an approach sustained academic and
practical Marxism for most of the 20th Century (and if we are looking for metaphors for centralized coordination, this one is worth exploring too!).

We do know this: the prophets of doom were wrong. It is now some years since prominent authorities in the field warned that the enterprise which did not adopt the Framework (or, more mildly,
enterprise architecture in some form) faced oblivion. Many organizations have gone to the wall in that time: few, I believe, would attribute their failure to the lack of an enterprise architecture.

This is not to say that the enterprise architectures don’t deliver better business outcomes (although my leaning is towards cynicism on this one, and we do need to keep a sense of perspective as
to the importance of information systems to an enterprise’s success).

But if we are to be persuaded to implement a Framework-based architecture, or to recommend it to our clients, we should now demand arguments based on evidence of success.

Say Something Positive

For more than ten years, I have been a trenchant critic of traditional models of data administration, advocating a focused, project-based approach rather than an enterprise wide program of policies
and procedures. (I spoke on Re-Inventing Data Management at the US DAMA conference in 1999 and on many occasions since; my advocacy of and experience with the approach as a consultant dates from
1990.) Whether or not my views have had an influence, there has been some adoption of this approach, and, it would seem from conference presentations at least, some success stories.

With the advent of XML and message-based approaches to integration, data managers and enterprise architects have a new set of tools in their kit, and we need to reflect again on how we can best
contribute to the success of our enterprises or clients.

And this is the underlying message of this article: though I have chosen the Zachman Framework as a convenient and well-known target, the message applies to all data management and architecture
frameworks, approaches and tools: there is no eternal right answer out there, but rather a need to constantly review the performance of our techniques and adapt them in the light of that knowledge.

[1] I see that Scott Ambler has taken this suggestion seriously (and why not?) and incorporated a “cost” column. See http://www.enterpriseunifiedprocess.com/essays/zachmanFramework.html