The development of enterprise architecture planning (EAP) takes the Zachman system development framework [1] as its springboard. This framework, which is approaching legendary status, cross-references data, functionality, and the communications network via a variety of viewpoints, including business objectives, business model, information model, technology model, detailed implementation model, and delivered product. Spewak and Hill declare that the business enterprise planning process encompasses defining the first two layers of the Zachman framework (which is explained). Therefore, they are more interested in defining data, applications, and technology architectures than in designing these for particular applications.

The intended audience includes system planners, data administrators, technology-oriented executives, and information resource managers who have as their goal building a computing environment in which integrated shared data is the rule.

The text is a practical, cookbook-style guide to producing the deliverables that constitute EAP. The authors are acutely aware that undertaking planning that is likely to cut across existing departmental boundaries and organizational biases may raise political issues and concerns. A project cannot be successfully developed, however, without incurring these risks. Therefore, “EAP is an exercise in managing interpersonal relationships” (p. 25). How true! The authors tell the truth without being able to prescribe a remedy for the fact that both managers and technicians are territorial and are more easily threatened the more limited their expertise and vision are. The authors realistically state that EAP is better not undertaken unless it can be done right, using staff whose credibility and prestige are high within the organization.

“Planning Initiation” consists of getting “buy in” from key top-level business executives. Getting support from powerful sponsors is as important as (but not a substitute for) adopting and adapting an effective methodology. Chapters 4 and 5, “Preliminary Business Model” and “Enterprise Survey” (also known as the business survey) aim at relating business functions to organizational units. Good use is made of Michael Porter’s “value-added chain” [2] in providing what is basically a functional decomposition of key business activities in which the organization engages.

The major deliverable of the current technology architecture (chapter 6) is the information resource catalog (IRC). This includes, but is not limited to, identifying the technology platforms--mainframes, PCs, midrange computers, networks, and so on--already available within the organization. Among the many benefits of the IRC are the opportunity to attain success quickly at a reasonable cost, and the chance to open eyes and minds to the possibilities of the enterprise-wide deployment of the computing resource.

The main action of EAP is the production and delivery of the data architecture, application architecture, and technology architecture (chapters 7, 8, and 9). The authors focus on managing the process rather than the technical intricacies of data modeling. They almost exclusively employ the entity-relationship model, however, so the enterprise is well positioned to take advantage of relational technologies such as SQL should it choose to do so.

The “Implementation Plan,” “Conclusion,” and “Transition to Implementation” (chapters 10, 11, and 12) make judicious use of the 80/20 principle: mastery of 80 percent of the data, applications, and technology is possible with 20 percent of the resources. Applications that create and capture data have a higher priority, in terms of use or re-engineering, than those that merely reference data. This practical guideline is used as a thread to guide EAP staff through the organizational labyrinth. The authors offer practical suggestions, most of which say, “Network informally to get agreement in advance or all bets are off.”

As is often the case, the book’s strengths are also its weaknesses. The cookbook approach makes for dry, redundant reading. The methods of analysis are restricted almost exclusively to functional decomposition. No reference is made to object-oriented technologies, though they are well suited for engaging complex organizational entities such as enterprises, cooperative processing in distributed networks, and client-server application architectures. On the other hand, the strengths of this text outweigh its weaknesses. Its strengths are its direct treatment of an important part of the information service planning function (enterprise-wide computing architectures), use of a widely accepted and intrinsically interesting framework, and modern (though limited) examples. The authors write well and the text is typeset nicely (although typos occur on pages xxi and 352, and page 236 refers to Appendix H, an example of a technology architecture document, although Appendix H is missing). The text has an excellent bibliography and would be suitable as supplementary reading in a graduate business or MIS course. In spite of my criticisms, the text is worthwhile and rates among the best in its class.