Enterprise architecture planning

Last updated
Levels of Enterprise Architecture Planning. Levels of Enterprise Architecture Planning.svg
Levels of Enterprise Architecture Planning.

Enterprise architecture planning (EAP) in enterprise architecture is the planning process of defining architectures for the use of information in support of the business and the plan for implementing those architectures. [2]

Contents

Overview

One of the earlier professional practitioners in the field of system architecture Steven H. Spewak in 1992 defined Enterprise Architecture Planning (EAP) as "the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures." [3] 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. [1]

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 (BSP) 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. [1]

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. [2]

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. [2]

EAP components

Enterprise Architecture Planning model consists of four levels:

EAP methodology

The Enterprise Architecture Planning (EAP) 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. [2]

EAP focuses on defining what data, applications, and technology architectures are appropriate for and support the overall enterprise. Exhibit 6 shows the seven components (or steps) 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 (or step). [2]

Criticism

The effectiveness of the EAP methodology have been questioned in the late 1980s and early 1990s:

See also

Related Research Articles

<span class="mw-page-title-main">Zachman Framework</span> Structure for enterprise architecture

The Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: identification, definition, representation, specification, configuration and instantiation.

Enterprise architecture (EA) is a business function concerned with the structures and behaviours of a business, especially business roles and processes that create and use business data. The international definition according to the Federation of Enterprise Architecture Professional Organizations is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

<span class="mw-page-title-main">The Open Group Architecture Framework</span> Reference model for enterprise architecture

The Open Group Architecture Framework (TOGAF) is the most used framework for enterprise architecture as of 2020 that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. TOGAF is a high-level approach to design. It is typically modeled at four levels: Business, Application, Data, and Technology. It relies heavily on modularization, standardization, and already existing, proven technologies and products.

A federal enterprise architecture framework (FEAF) is the U.S. reference enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.

Data architecture consist of models, policies, rules, and standards that govern which data is collected and how it is stored, arranged, integrated, and put to use in data systems and in organizations. Data is usually one of several architecture domains that form the pillars of an enterprise architecture or solution architecture.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

Enterprise information security architecture is the practice of designing, constructing and maintaining information security strategies and policies in enterprise organisations. A subset of enterprise architecture, information security frameworks are often given their own dedicated resources in larger organisations and are therefore significantly more complex and robust than in small and medium-sized enterprises.

<span class="mw-page-title-main">Enterprise modelling</span>

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

<span class="mw-page-title-main">John Zachman</span> American computer scientist

John A. Zachman is an American business and IT consultant, early pioneer of enterprise architecture, chief executive officer of Zachman International, and originator of the Zachman Framework.

In information systems, applications architecture or application architecture is one of several architecture domains that form the pillars of an enterprise architecture (EA).

<span class="mw-page-title-main">Architecture domain</span> Broad view of an enterprise or system

An architecture domain in enterprise architecture is a broad view of an enterprise or system. It is a partial representation of a whole system that addresses several concerns of several stakeholders. It is a description that hides other views or facets of the system described. Business, data, application and technology architectures are recognized as the core domains in the most of proposed concepts concerned with the definition of enterprise architecture.

<span class="mw-page-title-main">Three-schema approach</span> Approach to building information systems

The three-schema approach, or three-schema concept, in software engineering is an approach to building information systems and systems information management that originated in the 1970s. It proposes three different views in systems development, with conceptual modelling being considered the key to achieving data integration.

<span class="mw-page-title-main">Enterprise life cycle</span> Process of changing an enterprise over time

Enterprise life cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance, disposition and disposal of existing elements of the enterprise.

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

Business systems planning (BSP) is a method of analyzing, defining and designing the information architecture of organizations. It was introduced by IBM for internal use only in 1981, although initial work on BSP began during the early 1970s. BSP was later sold to organizations. It is a complex method dealing with interconnected data, processes, strategies, aims and organizational departments.

<span class="mw-page-title-main">Treasury Enterprise Architecture Framework</span>

Treasury Enterprise Architecture Framework (TEAF) was an enterprise architecture framework for treasury, based on the Zachman Framework. It was developed by the US Department of the Treasury and published in July 2000. May 2012 this framework has been subsumed by evolving Federal Enterprise Architecture Policy as documented in "The Common Approach to Federal Enterprise Architecture".

<span class="mw-page-title-main">FDIC Enterprise Architecture Framework</span>

FDIC Enterprise Architecture Framework was the enterprise architecture framework of the United States Federal Deposit Insurance Corporation (FDIC). A lot of the current article is about the enterprise architecture framework developed around 2005, and currently anno 2011 out-of-date.

<span class="mw-page-title-main">TAFIM</span>

Technical Architecture Framework for Information Management (TAFIM) was a 1990s reference model for enterprise architecture by and for the United States Department of Defense (DoD).

<span class="mw-page-title-main">NIST Enterprise Architecture Model</span> Reference model of enterprise architecture

NIST Enterprise Architecture Model is a late-1980s reference model for enterprise architecture. It defines an enterprise architecture by the interrelationship between an enterprise's business, information, and technology environments.

Steven Howard Spewak was an American management consultant, author, and lecturer on enterprise architectures, known for the development of Enterprise Architecture Planning (EAP).

References

  1. 1 2 3 FAA (1998). Federal Information Architecture Initiatives. Federal Aviation Administration, February 1998.
  2. 1 2 3 4 5 6 7 8 9 The Chief Information Officers Council (1999). Federal Enterprise Architecture Framework Version 1.1 Archived 2012-02-13 at the Wayback Machine September 1999.
  3. 1 2 Steven Spewak and S. C. Hill (1992) Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. Boston, QED Pub. Group. p. 1
  4. Lederer, A.L., and Sethi, V. (1988). The Implementation of Strategic Information Systems Planning Methodologies. In: MIS Quarterly, vol. 12, no. 3, pp. 445-461.
  5. Goodhue, D.L., Quillard, J.A., and Rockart, J.F. (1988). Managing the Data Resource: A Contingency Perspective. In: MIS Quarterly, vol. 12, no. 3, pp. 373-392.
  6. Lederer, A.L., and Sethi, V. (1992). Meeting the Challenges of Information Systems Planning. In: Long Range Planning, vol. 25, no. 2, pp. 69-80.
  7. Goodhue, D.L., Kirsch, L.J., Quillard, J.A., and Wybo, M.D. (1992). Strategic Data Planning: Lessons from the Field. In: MIS Quarterly, vol. 16, no. 1, pp. 11-34.
  8. "Why Doesn’t the Federal Enterprise Architecture Work?" Archived 2016-06-11 at the Wayback Machine , Stanley B. Gaver, visited 19 May 2016.
  9. Kotusev, Svyatoslav (2021) The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment (2nd Edition). Melbourne, Australia: SK Publishing.

Further reading