Welcome Guest!
Create Account | Login
Locator+ Code:

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

email article
printer friendly
more resources

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.

Back to top

Printer-Friendly Version

Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTPOnline Home