Enterprise Architect  

Erecting the Framework, Part III
John Zachman concludes his discussion of the Zachman Framework for Enterprise Architecture and its impact in an exclusive interview
Interview by Dan Ruby

Posted March 18, 2004

John Zachman, founder of the discipline of enterprise architecture and the Zachman Framework (see Figure 1) is also a lecturer 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. In part II of the interview, Zachman discussed 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. Here, the interview concludes with a discussion of the framework's implementation, its theoretical approach, and real-world enterprise architecture.

Implementing the Framework
EA: An EA Interest Group [EAIG] has recently formed to further advance understanding and usage of your framework. Can you comment on that?

Zachman: Until now, all the work on the Zachman Framework has happened in our spare time. Some of the other frameworks are supported by organizations with people who get paychecks to do that work. In contrast, nobody is paid to do the thinking around the Zachman Framework. The implication of the EAIG is that some people want to drive the state of the art, and make the process of enterprise engineering more of a science. That is the stated intent.

What does that mean? Well, we may want to do some laboratory experiments on the physics. What happens when you change this; how does it affect that? What does a metamodel look like? What are examples of all the cells? How do you rigorously define the graphic models? What kinds of tools are useful? There are a whole bunch of things that can be done, and you can probably speed up the development from what we have been able to do.

EA: So in terms of how enterprises are manufactured to use your term, it is still early on.

Zachman: I think the state of the art has to improve. It is like the Thomas Kuhn theory of the scientific revolution. At the point in time that an invention has to happen, it will probably happen. It is not a function of personality but a function of time. I think enterprise architecture is an idea whose time has come.

We know that we are in trouble on security. There's no way to fix it short of doing architectural work. All we need is a cataclysmic disaster or two; 9/11 got a lot of people's attention.

EA: And that fed interest in enterprise architecture?

Zachman: Look what it meant to the federal government. It made people ask what is in the enterprise and how do we integrate it. To put all these enterprises together [in the Department of Homeland Security], and put one person in charge, that does not fix the integration problem. Nothing magic is going to happen. At some point in time they will come to the stark realization that actual engineering work will have to be done if they want to integrate these things.

EA: One of the big developments in EA is the federal enterprise architecture. What is your take on that approach?

Zachman: I really hope they do well, but once again the attempts are coming from where we have been in the past. They are meant to improve the system development process. So, basically, their classifications are process based. If there are artifacts created, they are related to a process—it is a composite classification.

The mathematics of primitives versus composites is difficult to argue with. If you have one thing, you can get people to agree that is the set of one thing. As soon as you put combinations of things together, the probabilities of getting agreement starts to deteriorate. Put three things together, and you can forget about it.

A big difference is that my framework is recursive. You can use it to analyze anything. You can analyze meta things with the same framework and define meta relationships between frameworks. The other frameworks are one-at-a-time things, a composite instantiation at a point in time. So you can't use them to do other things, whereas the Zachman Framework is totally generic, just a classification of descriptive representations of anything.

Primitives versus Composites
EA: But the overall field of "enterprise architecture" is broader than just your approach. There are many definitions.

Zachman: I'll tell you what. I am John A. Zachman. I am just one person. I don't have an organization. I am not marketing anything. If people want me to talk about the framework and about architecture, I am happy to talk about it. There are very large companies that have created frameworks that come and go, and they perceive that I am competition to them. But I am not doing any marketing.

Most of the frameworks are trying to do a different thing. I was trying to classify descriptive representations, and they were trying to classify something else—processes in most cases. I would observe that the properties of my framework are not going to go away. The others probably go away because they are classifying temporal kinds of things, or composite things.

EA: Your theoretical approach is undoubtedly elegant, but how successful is it at helping people solve their problems?

Zachman: Well, understand that I come at things from the top down. I am not a programmer. And even though I know a lot about models at this point, if you wanted somebody to build a model, you would want someone other than me.

Having said that, there is a lot of successful implementation of models going on. You can do a logical data model and a physical data design and a data definition in such a fashion that your implementation can be reused across the whole scope of the enterprise. We have validated that; it is not an open issue.

We know how to do structured methods. We know how to do structured programming. We know how to do structured design. We know how to do structured analysis. We know how to do structured business modeling.

But if you get up higher, we are not building those models. Over in Column 4, workflow, we don't know a lot about that yet. Same with Columns 5 and 6. Maybe someone knows a lot about these, but not in our discipline—the information systems community.

So if you ask who is successfully implementing the whole framework, the answer is nobody that we know of yet.

EA: So how should organizations go about implementing it? I have heard you say you don't care if it is top down, bottom up, right, left, or inside out. But in practice, how should an organization or company begin to tackle this?

Zachman: Because we deal with composite models in the real world, it always looks too complex fairly quickly. So we tend to throw up our hands and say that it takes too long and costs too much, that we don't want to do it.

No. What you do is sit down and roll up your sleeves. There is nothing to keep you from building out the models. I would say you should do the primitives. Some may have to do composites first to convince management to buy in and let them build the primitives. If you must, you can start with a composite, and later factor out the primitive models.

EA in the Real World
EA: So you would say to start where the pain is?

Zachman: I say, just do it. You know how to do a logical data model. Go build it. You know how to do a semantic model. Go build it. You know how to do a database design. Go build it. What is keeping you from it? Well it takes too long and costs too much. But there are people doing it quite successfully. It is not a framework-related issue. It is a cultural problem.

EA: Since most architects are grounded in the here and now, is it more difficult for them to focus on primitives instead of composite models that reflect their real-world situation?

Zachman: Composite models can be very helpful for doing implementation. But they don't get us to achieving the engineering and design objectives. On the other hand, if you have the framework and you ask, "why can't we get interoperability or reusability, or what's the problem with alignment," you can see where the problem lies. You see that this is related to that, so that if you are not defining this, then you can't get there form here.

The problem with multivariable composite models is that things are hard bound together. We've known this for a long time. In programming we know to separate the data from the instruction because the data changes independently of the instruction. We know to separate the hardware and system software from the process and from the data and from the business rules. If you want to change things with a minimum of time, disruption, and cost, it is critical to separate the independent variable. So the problem is that we have not been building primitives.

EA: Is that because architects live in an implementation world?

Zachman: Most are coming out of the implementation world. They are systems people and they tend to be implementation oriented. The world is that way. Actually, these people are more inclined to think about architecture than the average.

EA: They are, but are their organizations ready for that?

Zachman: That is another issue. Once you begin to understand these basic ideas, it is pretty hard to deny them. Once you understand that the law of gravity is in effect, it is pretty hard to say it is not in effect.

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