Enterprise Architecture Planning

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]

Levels of Enterprise Architecture Planning.

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." 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 (BSP)
approach developed by John Zachman, EAP takes a data-centric approach to architecture

1
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

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 topic

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 (or steps) 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:
o Business process modeling, the compilation of a knowledge base about the
business functions and the information used in conducting and supporting the
various business processes, and

2
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

o 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:
o Data Architecture - Definition of the major kinds of data needed to support the
business.
o Applications Architecture - Definition of the major kinds of applications needed to
manage that data and support the business functions.
o 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 (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. 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).

Criticism

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

3
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

• Business Systems Planning (BSP), the conceptual predecessor of EAP, did not work
successfully: "Given their great expense and time consumption, [...] findings seriously
challenge the utility of the [BSP and similar] planning methodologies".
• Federal Enterprise Architecture (FEA) 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 (1992) admit that "the vast majority of enterprises that
undertake Enterprise Architecture Planning are not successful" (page 19).
• 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.

Enterprise architecture framework

An enterprise architecture framework (EA 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.

4
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

NIST Enterprise Architecture Model initiated in 1989, one of the earliest frameworks for enterprise architecture.

Architecture domain

Layers of the enterprise architecture.

Since Stephen Spewak's Enterprise Architecture Planning (EAP) in 1993, and perhaps
before then, it has been normal to divide enterprises architecture into four architecture
domains.
• Business architecture,
• Data architecture, • Applications architecture,
• Technology architecture.

5
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

Note that the applications architecture is about the choice of and relationships between
applications in the enterprise's application portfolio, not about the internal architecture
of a single application (which is often called application architecture).

Many EA frameworks combine data and application domains into a single (digitized)
information system layer, sitting below the business (usually a human activity system)
and above the technology (the platform IT infrastructure).

Layers of the enterprise architecture

Example of the federal enterprise architecture , which has defined five architectural layers.

For many years, it has been common to regard the architecture domains as layers, with
the idea that each layer contains components that execute processes and offer services
to the layer above. This way of looking at the architecture domains was evident in
TOGAF v1 (1996), which encapsulated the technology component layer behind the
platform services defined in the "Technical Reference Model" - very much according to
the philosophy of TAFIM and POSIX.

The view of architecture domains as layers can be presented thus:

• Environment (the external entities and activities monitored, supported or directed by the
business).

• Business Layer (business functions offering services to each other and to external entities).

• Data Layer (Business information and other valuable stored data)

• Information System Layer (business applications offering information services to each other
and to business functions)

6
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

• Technology Layer (generic hardware, network and platform applications offering platform
services to each other and to business applications).

Each layer delegates work to the layer below. In each layer, the components, the
processes and the services can be defined at a coarse-grained level and decomposed
into finer-grained components, processes and services. The graphic shows a variation on
this theme.

Components of enterprise architecture framework

In addition to three major framework components discussed above.

1. Description advice: some kind of Architecture Artifacts Map or Viewpoint Library

2. Process advice: some kind of Architecture Development Method, with supporting guidance.

3. Organization advice: including an EA Governance Model

An ideal EA framework should feature:

1. Business value measurement metrics

2. EA initiative model

3. EA maturity model

4. Enterprise communication model

Most modern EA frameworks (e.g. TOGAF, ASSIMPLER, EAF) include most of the above.
Zachman has always focused on architecture description advice.

7
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

Enterprise architecture domains and subdomains

Enterprise architecture reference architecture with sub domains

The application and technology domains (not to be confused with business domains) are
characterized by domain capabilities and domain services. The capabilities are supported
by the services. The application services are also referred to in service-oriented
architecture (SOA). The technical services are typically supported by software products.
The data view starts with the data classes which can be decomposed into data subjects
which can be further decomposed into data entities. The basic data model type which is
most commonly used is called merda (master entity relationship diagrams assessment,
see entity-relationship model). The Class, subject and entity forms a hierarchical view of
data. Enterprises may have millions of instances of data entities.

The Enterprise Architecture Reference Traditional Model offers a clear distinction between
the architecture domains (business, information/data, application/integration and
technical/infrastructure). These domains can be further divided into Sub domain
disciplines. An example of the EA domain and subdomains is in the image on the right.

Many enterprise architecture teams consist of Individuals with Skills aligned with the
Enterprise Architecture Domains and sub-domain disciplines. Here are some examples:
enterprise business architect, enterprise documentational architect, enterprise application
architect, enterprise infrastructure architect, enterprise information architect, etc.
An example of the list of reference architecture patterns in the application and information
architecture domains are available at Architectural pattern (computer science).
8
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering
Enterprise Architecture Planning

9
GREEN COMPUTING BTL POLYTECHNIC COMPUTER SCIENCE AND engineering