Erecting the Framework, Part I
John Zachman, the father of enterprise architecture, reflects on the influences and impacts of his "periodic table of the enterprise"
Interview by Dan Ruby

Posted February 19, 2004

"You can engineer the enterprise just like you can engineer anything else." So says John Zachman, the retired IBM executive whose groundbreaking 1987 and 1993 articles are widely credited with founding the discipline of enterprise architecture and led to the development of The Zachman Framework for Enterprise Architecture (see Figure 1). Today the field is taking hold as a strategic function within many corporate and government information systems departments. Zachman, on behalf of his Zachman Institute for Framework Advancement (ZIFA), continues to lecture widely on advanced topics such as metaframeworks and federated architectures (see the sidebar, "What Is the Zachman Framework for Enterprise Architecture?").

Enterprise Architect Online caught up with Zachman at a recent ZIFA Forum for this wide-ranging interview. In this first part Zachman discusses the beginnings of the framework's development, how it was shaped, and how it evolved. In part II of the interview 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. Finally, part III of the interview concludes with a discussion of the framework's implementation, its theoretical approach, and real-world enterprise architecture.

The Roots of Enterprise Architecture
EA: To understand how your thinking about enterprise architecture took shape, how did it evolve from your work at IBM on business systems planning in the 1970s?

Zachman: We were beginning to formalize management systems in the enterprise. My focus was on the strategy process. Remember that management processes were not formalized very long before that. [Peter] Drucker had written the first important book, The Practice of Management [see Resources], only in 1954, so there had not long been even a legitimacy of the discipline of management. Prior to that, the whole concept of formal management processes was a foreign idea.

We began to see the formalization of management in the '60s timeframe. I was at IBM and we were trying to deal with the formalization of the information strategy, which is the logical place to start. By the late '60s we had pretty well figured out how to do it. At least IBM had formalized the methodology it used internally.

Dewey Walker was the manager of architecture at that time within the corporate information systems staff. At that time, IBM had a centralized IS function, and Dewey was one of five guys on the IS control and planning staff. He was responsible for system architecture.

What happened was that the chief of IS retired and the decision was made to decentralize it, putting IS in each individual business unit, and the control and planning staff was going to be sent to the winds. They decided to put Dewey Walker and his architecture work out into large account marketing—to see if any customers cared about this stuff.

So he moved there and set about to document his methodology. He would spend a couple of weeks doing a survey to see if the account had any reason to do this architecture work. That methodology, his two weeks of analysis, is what ultimately became business systems planning, or BSP. Then Dewey left shortly thereafter.

EA: It was a methodology for the sales process?

Zachman: Yes. IBM tried to sell it but couldn't get buyers because they couldn't articulate what it did. They'd say it does architecture, and the customer would say, "Yeah, but what's that?" Ultimately they came to give it away as market support.

People thought it was a self-serving thing to sell hardware, but that wasn't true. Sometimes a hardware order would occur, but that was not what we were trying to do. We were trying to define information systems strategy. I was in the middle of this because I soon became the principle proponent for business systems planning. So people tended to see me as the author of BSP, but I wasn't the author. Dewey Walker was.

Birth of the Framework
EA: What had been your career path until then?

Zachman: I had been the account executive for Atlantic Richfield. We used BSP because we were helping to integrate the merger of Atlantic and Richfield and Sinclair, making three oil companies into one. I had started looking around to see who could help and had found Dewey Walker, and we picked up his methodology. I ended up moving to a staff responsibility for BSP, and that was how I came to get visibility with it. Then we started evolving the methodology, enhancing the formalization.

Then IBM made the decision to choose one methodology they would make the standard IBM methodology, and BSP became the principal candidate. But I said, "Hey, I have only one piece of this puzzle." I was working only in Row 1 [of what would later become the Zachman Framework].

I was working with aerospace companies when I began to put together a view of architecture relative to airplanes. It became obvious to me that there was a set of architectural representations, not one representation but a set of them, and that there was order to the set. I saw that you could classify descriptions based on what it is made out of, how it works, where the components are, who's doing what, when do things happen, and why do they happen. Also, each of those things looked differently depending on the view—whether you were the owner, the designer, or the builder.

EA: So that was how the framework was born?

Zachman: Yes, basically it just fell on my desk. Now, when I published the early work, I wrote only about three of the columns. I wrote the first article in 1982, and it was published internally at IBM in 1984. Then I rewrote it for the IBM Systems Journal, an external refereed publication, in 1987. But the basic work was done by 1982.

The point is that the reason I formalized the structure of the framework was that IBM was trying to make BSP the standard methodology, and I was saying that it was not enough. So I sketched the framework to show that I was only doing Row 1 and that there were a whole bunch of other people that were needed: data people, process people, and others. I was trying to get them to understand that.

EA: You didn't call it enterprise architecture then.

Zachman: No, I called it "the framework for information systems architecture." We didn't think in terms of the enterprise. In those days we were trying to implement systems. All we thought of was the system. We didn't conceive of trying to integrate the enterprise.

First of all, the technology wasn't sophisticated enough. Remember that when I joined IBM in 1964, the 1401 was a 16K box, and that was the big one. You couldn't think of enterprise-wide models. It is like if all you have is an ax and a wedge, you can't think about a 100-story building. All you can think about is a log cabin. But when you get bulldozers and cranes, you can think about a much more complex object.

By the time I published the revised paper in 1987, I began to get the inclination to think enterprisewide. I wrote in that article about the problem of having less than enterprisewide integration, and I talked about the other three columns in an appendix to the article.

A Mistaken Enterprise
EA: When did you begin to use the term enterprise?

Zachman: What happened was that people in the public sector had a problem with the models in Row 2, which I called business models. They would say that since they were not businesses that the row didn't apply to them. Well, no, the idea of conceptual models is generic; it makes no difference if you are public or private. So I changed the name of Row 2 from business models to enterprise models. I tried to find a neutral name so they could accept it.

But that was not the right thing to do because really the whole thing is the enterprise, and I was calling one row the enterprise. So years later I had to get that straightened out because people were misunderstanding it. If you do just Row 2, you don't have an enterprise model but a system model. So I changed it back to models of the business. And by now the public sector was not having a problem. I mean they are outsourcing half the public sector, so now they have no trouble saying this is a model of the business. The problem went away, and I went back to the original naming convention. Any word you pick has baggage to it.

Words aside, it is important to understand the idea of the enterprise. What do you mean when you say enterprise? You could mean one business unit or one profit center, or a cluster of profit centers, or the whole value chain. Or you could mean just one department or one application in the department. It is a question of the granularity of the analysis.

EA: And the framework works for any view?

Zachman: Yes the framework is inert. You define whatever boundary you choose. Then you define who owns that definition of the enterprise, and then determine the designer, the builder, the things, process, location, and everything else. It is totally independent of the boundary. So you can use the framework to analyze anything you want to analyze.

EA: And one framework can be related to another?

Zachman: Yes, if you are going to have more than one framework, more than one enterprise in your bigger enterprise, somebody has to define what is going to be the same. Otherwise there is not going to be any collaboration between the enterprises.

EA: At some point after publishing the second paper, you retired from IBM. And yet you carried on the work.

Zachman: Yes, in 1993 I published the second article in the Systems Journal, along with a coauthor, John Sowa, a really brilliant guy who was an expert in semiotics and ontologies. He was the one that encouraged me to write the second article. This time, I published the six-column framework. The second article was called "Extending and Formalizing the Framework for Information System Architecture."

EA: See Part II where 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.