Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed


Erecting the Framework, Part II (Continued)

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.

Back to top

Printer-Friendly Version





Java Pro | .NET Magazine | Visual Studio Magazine | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home