Enterprise Architect  

Erecting the Framework, Part II
John Zachman continues discussing his Zachman Framework for Enterprise Architecture in an exclusive interview.
by Dan Ruby

Posted March 4, 2004

John Zachman, the retired IBM executive whose groundbreaking 1987 and 1993 articles are credited with founding the discipline of enterprise architecture, continues to lecture on advanced topics such as metaframeworks and federated architectures on behalf of his Zachman Institute for Framework Advancement (ZIFA)—see the sidebar, "What Is the Zachman Framework for Enterprise Architecture?" Zachman was interviewed recently by Dan Ruby, FTP's Enterprise Group editorial director. In part I of the wide-ranging interview Zachman discussed the roots of enterprise architecture, the birth of the framework, and its evolution after his retirement. Here, Zachman discusses his influences for developing the framework, how the framework compares with Mendeleev's periodic table of the elements, and his feelings about the framework's implementation in today's technologies.

Change and Stability
EA: Around then, other things are happening. What influences did you feel?

Zachman: Well, the world wasn't ready to deal with architecture yet. Anything that would help write code more quickly was what the world was looking for. Those of us doing architecture were trying to engineer things that could be used in many implementations. But most people just wanted to get the code out the door. So we were swimming against the current.

EA: What about Hammer and Reengineering the Corporation?

Zachman: That was a 1993 book about business processing reengineering [see Resources online at www.enterprise-architect.net]. Actually, it was Mike Hammer and Jim Champy in that book that popularized the term business process. If you look at my first paper, I wrote about what I called functional flow diagrams because we didn't have a name for them.

I had a friend on the National Transportation Safety Board who was a risk management consultant. He would look at grain elevator explosions, oil platform disasters, airplane accidents, and so on, and he would build what he called a functional flow diagram with input processes and output processes. I realized that was what my framework called for in Column 2, Row 2, so I used his word.

Now when Hammer and Champy popularized the business process model and that term came into modern usage, I changed my terminology. I will change things to accommodate general usage. But the framework itself hasn't changed.

EA: Even though there are a lot of developments that have happened in recent years that one might imagine would impact the framework?

Zachman: The framework has not changed. What, how, where, who, when, why has been around for thousands of years. It is going to be around for a few thousand more. Requirements, engineering, manufacturing or conceptual, logical, physical has been around for thousands of years and will be around for a few thousand more. The logic structure of the classification, the schema, hasn't changed.

Now common usage—names—do change. And I have changed some names. Sometimes I've lived to regret it, as I did with business model and enterprise model. I wish I had just left it alone. So I am very careful to change things. I don't want to give people the impression that the framework is changing. It isn't.

EA: Others have picked up on your work and have modified it. What's your opinion about some of the other frameworks that people use?

Zachman: People come up all the time and say, "John, the framework is really nice but you forgot a column." I'll say that it is not me who forgot it. Humanity for the last 7,000 years has been able to work with what, how, who, where, when, and why. But if you have discovered something, that must be profoundly significant.

I'm being facetious, of course. The classification scheme is fixed—it is not negotiable. When people want to add other rows or columns to the framework, I say that there are other ways to handle that issue. There may be a good reason they want to add a row or column, but there are better ways to handle it. You can't argue with Mendeleev that he forgot a column in the periodic table.

EA as a Science
EA: That is an interesting analogy. Since you make a comparison of your framework for enterprise architecture to the periodic table of the elements, do you see EA as a science?

Zachman: I wasn't conscious of it at the time I developed the framework, but I think what I ended up doing was defining a periodic table for descriptive representations of the enterprise. It is a two-dimensional classification system, a schema. It is exactly like the periodic table of the elements. You classify elements in terms of the number of neutrons and protons in a nucleus by the number of electron rings. [See Figure 1.]

Now I'm sure that Medeleev knew what he was doing when he was trying to define the periodic table. In contrast, I didn't know what I was trying to figure out. I was just trying to solve a problem. But years later, when somebody said it was like the periodic table, I said, "my gosh, that's right." It is a normalized schema just like the periodic table. Gold goes in one particular cell and not in any other cell. Logical entities go in one cell and not in any other cell. Application functionality goes in one cell and not in any other cell.

EA: But when you are describing nature, it is more concrete as to what it really is.

Zachman: Well, we don't think about it that way, but when you get down to it the enterprise is as tangible as anything else. I argue that the system is the enterprise, and you can have manual systems and automated systems. With an automated system, management may not think of it as tangible. You can't reach in and grab a handful of bits, rip them out, change the configuration, and cram them back in. Electrons are small enough that they don't appear to be tangible, but I guarantee they are.

EA: So when you use scientific terminology—entropy or other physics concepts—you take that literally?

Zachman: I do. Nothing happens by accident. If someone says this is not physics, I say, "Okay, then explain to me why it works this way. Explain the occurrences you can observe in the enterprise. Explain why you can't get integration. Explain why you can't get alignment. Explain why management is so frustrated." If you can't explain it, then it is something magic that happens—and I don't believe that.

EA: If it is science, you should be able to do experiments on it.

Zachman: Sure. It has already been experimented with. You can either make the model explicit or leave it implicit. If it is implicit, you are making assumptions about it. Okay, then conduct an experiment, and you can make the model explicit. Then you get agreement.

We have empirically validated that you can engineer data models so they can be reused in many applications. That is established. It is not an open issue. I'll tell you what is not so clear. It isn't clear you can write code that can be used in multiple applications. You can reuse hardware and system software in many applications—that is clear. But with applications, one size doesn't fit all. We can't get reusable code.

EA: Even though we have object models?

Zachman: Well, show me some. Objects are a pretty good idea from an implementation standpoint, but do you get reusability with objects? That was the whole idea, but I'm not too sure you get reusability with objects.

Relation to Technologies
EA: That brings up the whole subject of technologies. What is your position on the relation of the framework to the implementation of it?

Zachman: I try to maintain neutrality. I had a sense early on that there was not one way to do this—not a single tool or methodology. So, therefore, I did not want to associate the framework with a tool or a method because as soon as you do that it becomes viewed that way. The periodic table is not owned by Dow Chemical. It belongs to the world.

So I deliberately try to maintain neutrality. I don't use the tools every day, so I don't have a lot of experience with them. If some manufacturer asks for help in mapping my metamodel against their tool, I will help. But I won't say this is the only tool to do it.

EA: Besides tools for implementing the framework, what about more general technologies that would seem to have some relation? I am thinking about UML, for example.

Zachman: The framework is totally independent of technology. If you are using pencils and paper and file cabinets, or if you are using supercomputers or whatever, the framework is the framework. Technology is a constraint that shows up as an instantiation in Row 4 and Row 5. But the framework has nothing to do with technology.

Now, when a new tech idea comes along—UML, for example—the question is, what is it producing, composites or primitives? That would tell you if it is designed to do implementation or to do architecture. If it's implementation, there's nothing the matter with that. It just means that it isn't designed to do architecture.

If the engineer understands the difference between doing implementation and doing architecture, they can use any tool or any notation, such as UML, to do whatever they need to do. But the magic is in the engineering, not the language of the graphic notation.

EA: What about services-oriented architecture and Web services? If utopia is having everything in just the right place, here is a technology that allows you to piece together systems.

Zachman: Again, you have to show me. It is probably a good idea, but somebody needs to define the Web service. Are there things in there: data, process, hardware and system software concepts, presentation, business rules? What's in there? The more things you put in there, the less likely it will be reusable in the next implementation.

Now, if you say we can create the Web service from the primitive structures, then I can see that Web services would be a really interesting idea for doing implementation work. On the other hand, if you are packaging up composites, the track record in reusing composites is not very high.

You can tell me that Web services is the answer, but I have heard that about 1,000 times before. Get this CASE tool, they said, and you will never have to work or think again, and you can get rid of all the programmers. I heard that for objects. You'll never have to think or work again, and you can get rid of all the programmers. Now, it's the same time for Web services. It may be really great technology, but it probably will not solve the enterprise architecture problem.

EA: See Part III where Zachman comments on the EA Insterest Group, recent developments of the federal enterprise architecture, and enterprise architecture in today's real world.

About the Author
Dan Ruby is editorial director of the Enterprise Group at Fawcette Technical Publications. Contact Dan at [email protected].