One of the earlier professional practitioners in the field of system architecture Steven H. Spewak in 1992 defined Enterprise Architecture Planning as "the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures." Spewak’s approach to EAP is similar to that taken by DOE in that the business mission is the primary driver. That is followed by the data required to satisfy the mission, followed by the applications that are built using that data, and finally by the technology to implement the applications. This hierarchy of activity is represented in the figure above, in which the layers are implemented in order, from top to bottom. Based on the Business Systems Planning approach developed by John Zachman, EAP takes a data-centric approach to architecture planning to provide data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and cost containment. This view counters the more traditional view that applications should be defined before data needs are determined or provided for.
EAP topics
Zachman framework
EAP defines the blueprint for subsequent design and implementation and it places the planning/defining stages into a framework. It does not explain how to define the top two rows of the Zachman Framework in detail but for the sake of the planning exercise, abbreviates the analysis. The Zachman Framework provides the broad context for the description of the architecture layers, while EAP focuses on planning and managing the process of establishing the business alignment of the architectures. EAP is planning that focuses on the development of matrixes for comparing and analyzing data, applications, and technology. Most important, EAP produces an implementation plan. Within the Federal Enterprise Architecture, EAP will be completed segment enterprise by segment enterprise. The results of these efforts may be of Government wide value; therefore, as each segment completes EAP, the results will be published on the ArchitecturePlus web site.
EAP components
Enterprise Architecture Planning model consists of four levels:
Level 1 - getting started : This layer leads to producing an EAP workplan and stresses the necessity of high-level management commitment to support and resource the subsequent six components of the process. It consists of Planning Initiation, which covers in general, decisions on which methodology to use, who should be involved, what other support is required, and what toolset will be used.
Level 2 - where we are today : This layer provides a baseline for defining the eventual architecture and the long-range migration plan. It consists of:
* Current Systems and Technology, the definition of current application systems and supporting technology platforms.
Level 3 - the vision of where we want to be : The arrows delineate the basic definition process flow: data architecture, applications architecture, and technology architecture. It consists of:
* Data Architecture - Definition of the major kinds of data needed to support the business.
* Applications Architecture - Definition of the major kinds of applications needed to manage that data and support the business functions.
* Technology Architecture - Definition of the technology platforms needed to support the applications that manage the data and support the business functions.
Level 4 - how we plan to get there : This consists of the Implementation / Migration Plans - Definition of the sequence for implementing applications, a schedule for implementation, a cost/benefit analysis, and a clear path for migration.
EAP methodology
The Enterprise Architecture Planning methodology is beneficial to understanding the further definition of the Federal Enterprise Architecture Framework at level IV. EAP is a how to approach for creating the top two rows of the Zachman Framework, Planner and Owner. The design of systems begins in the third row, outside the scope of EAP. EAP focuses on defining what data, applications, and technology architectures are appropriate for and support the overall enterprise. Exhibit 6 shows the seven components of EAP for defining these architectures and the related migration plan. The seven components are in the shape of a wedding cake, with each layer representing a different focus of each major task.
Criticism
The effectiveness of the EAP methodology have been questioned in the late 1980s and early 1990s:
Business Systems Planning, the conceptual predecessor of EAP, did not work successfully: "Given their great expense and time consumption, findings seriously challenge the utility of the planning methodologies".
Federal Enterprise Architecture program based on the EAP methodology has largely failed: "Enterprise Architecture within the federal government hasn‘t been working, and far more often than not hasn‘t delivered useful results. Moreover, significant parts of the federal EA program have been complete and utter failures".
Even Steven Spewak and Steven Hill admit that "the vast majority of enterprises that undertake Enterprise Architecture Planning are not successful".
The historical analysis shows that the EAP methodology, as well as all other similar formal, documentation-oriented, step-by-step planning methodologies, never worked successfully in practice.
