EA – FT | MOD10: DEVELOPING AN ENTERPRISE ARCHITECTURE MANAGEMENT PLAN

10.0 | OVERVIEW

• This chapter discusses the development of an EA Management Plan, which is the document that describes how
an enterprise will manage the transition of its current processes and resources to those which will be needed in the
future.
• This transition from the current EA to the future EA is an ongoing activity, as new resources are implemented and
therefore become part of the current EA.
• The purpose of configuration management and version control are also discussed, along with the need to provide a
sequence for implementation projects.

10.1 | INTRODUCTION

• The EA Management Plan documents the enterprise's performance gaps, resource requirements, planned solutions,
a sequencing plan, and a summary of the current and future architecture.
• The Plan also describes the EA governance process, the implementation methodology, and the documentation
framework.
• It is a living document that is updated at regular intervals (e.g., annually) to provide clear version control for
changes in current and future views of EA components and artifacts throughout the framework.
• The EA Management Plan should be archived in the on-line EA repository to support easy access to the
information and to promote the linkage of EA to other IT management processes.

10.2 | DISCUSSION

• The enterprise's EA is in continual transition as IT implementation and upgrade projects are completed. Large
and mid-size enterprises often have many IT projects underway at any given time, which requires an overarching
level of coordination, prioritization, and oversight.
• As is shown in Figure 9-1, the EA Management Plan provides this coordination and supports oversight for changes
to the enterprise's EA, between the current and future views.

Home Architecture Analogy

• The EA Management Plan is like the architect's project plan, which summarizes the work and shows the design,
approach, timeframe, and sequencing of work for the remodeling of a home.

10.3 | ENTERPRISE ARCHITECTURE MANAGEMENT PLAN

Part 1. EA Program Management Part 2. EA Current Architecture Summary

1.1 Governance and Principles 2.1 Strategic Goals and Initiatives

1.2 Support for Strategy and Business 2.2 Business services and Information Flows

1.3 EA Roles and Responsibilities 2.3 Systems and applications

1.4 EA Program Budget 2.4 Technology Infrastructure

1.5 EA Program Performance Measures 2.5 IT Security

2.6 EA Standards

2.7 Workforce Requirements

1
Part 3. EA Future Architecture Summary

3.1 Future Operating Scenarios

3.2 Planning Assumptions

3.3 Updating Current & Future Views

3.4 Sequencing Plan

3.5 Configuration Management

Part 4. EA Glossary and References

10.4 | PART 1: EA PROGRAM MANAGEMENT

1.1. GOVERNANCE AND PRINCIPLES

• This section documents the way that policy and decision-making will occur within the EA program.
• It is also where the underlying principles of the EA program are articulated.
• EA governance is perhaps best described through a narrative that provides EA program policy and an
accompanying flow chart that shows how and when decisions are made on EA issues such as IT investment
proposals, project reviews, document approvals, and standards adoption/waivers.
• EA principles articulate the enterprise's values as they relate to the EA. These principles then guide the EA
program's establishment and management.
• Examples of EA principle are
(1) the degree to which the enterprise promotes the open sharing of information,
(2) an emphasis on stakeholder participation,
(3) the recognition that IT is normally a means and not an end in itself,
(4) an emphasis on using commercial products that are based on open standards, and
(5) a recognition that EA adds value for planning, decision-making, and communication.
Note:

• Narrative and flow chart describe the governance of an EA program through a narrative so it outlines policies governing the
program and is often complimented by a flow chart since it’s the visual representation of how and when the decisions will be
made.
• EA principles are the foundational beliefs that guides EA program establishment and management

1.2. SUPPORT FOR STRATEGY AND BUSINESS

• This section emphasizes that one of the main purposes of the EA program is to support and improve the
enterprise's strategic and business planning, as well as to identify performance gaps that EA components can
help close.
• By showing how EA components are being currently used, and identifying useful new processes and technologies
at each level of the framework, improvements in performance can occur that are captured in the future EA views.
• For EA components to be viewed as a strategic asset and EA be viewed as part of the strategic planning process,
business executives must see the value of the EA program in supporting the outcomes that matter to them.
• It is therefore important to show the linkage of the EA program to the accomplishment of the enterprise's strategic
goals, as well as to clearly show how EA components support line of business activities.

2
Note:

• In here, it underscores the role of enterprise architecture program in enhancing the enterprise strategic and business planning.
• It is also analyze here the performance gaps.
• EA Components promote identification of new process and technologies at each level with the intent of capturing improvements
on future EA views.
• Strategic asset and planning integration recognized that assets are aligned.
• EA Components needs to be demonstrated to support the lines of business activities reinforcing the relevance all over the
business strategy. It emphasizes the importance of demonstrating the tangible value of the EA Program.

1.3 | EA ROLES AND RESPONSIBILITIES

• This section documents the roles that stakeholders in the EA program will play, and what the responsibilities
associated with those roles will be.
• This is where the players on the EA team are also identified. A table format is an effective way to show roles and
responsibilities

1.4 | EA PROGRAM BUDGET

• This section documents the budget for the EA program by fiscal year and over the total lifecycle, so that the
total cost of ownership (TCO) is identified.
• In general, the costs to be included are those for EA program start-up and operation, salaries and work facilities for
the EA team, the initial documentation of the EA, periodic updates to the EA, development of the EA Management
Plan, EA tool purchase and support, and EA repository development and maintenance.
• The initial estimate of these costs represents the "baseline" for EA program funding. Spending during the lifecycle
should be tracked against this baseline to promote effective management of the EA program. If changes in the scope
of the EA program occur, a corresponding change in the funding baseline should also be made.

Note:

• It provides the comprehensive view of the budget for the EA program for transparency and accountability.

3
1.5 | EA PROGRAM PERFORMANCE MEASURES

• This section documents how the effectiveness and efficiency of the EA program will be measured.
• As was described in previous Chapters, there are two types of measures: outcome and output.
• Outcome measures identify progress being made toward some new end-state, such as better EA component
integration, increased application end- user satisfaction, or more effective IT investment decision-making.
• Output measures provide data on activities and things, such as how many databases exist, how many e-mail are
sent each day, or how closely an IT project is meeting baseline estimates for cost/schedule/performance
• Outcome measures often have both quantitative and qualitative elements to them, while output measures are
usually quantitative in nature.
• While output measures are important for indicating progress in an initiative area, it is the attainment of outcomes
that correlates to goal attainment, which is the most important thing to an enterprise. It is important to be able to
measure the attainment of outcomes, so that the positive effects (added value) of the EA program can be identified.

Sample Performance Measures

10.5 | PART 2: SUMMARY OF CURRENT ARCHITECTURE

• One of the purposes of the EA Management Plan is to show an overview of the linkage between current EA
components and products at each level of the EA3 Cube Framework.
• In this way, the present role of IT within the enterprise is better understood and can be further analyzed from either
a top-down, or bottom-up perspective.
• The objective of this part of the EA Management Plan is not to duplicate the extensive documentation described
in Chapters 4 and 5, but to provide an integrated view of how the components and artifacts work in support of
each other. This also sets the stage for Part 3 of the EA Management Plan, which discusses future changes in
EA components and artifacts to achieve improved performance and/or efficiency.
• The following are examples of how current EA components and artifacts can be described at each level of the EA3
Cube Framework.

Note:
Examples at each level in an EA3 Cube Framework

1) Operational Level – current operational processes, systems and applications. For example, current order fulfillment.
2) System Level – summary of existing IT systems and their interconnections. For example, ERP system.
3) Technical Level – insights of underlying technical infrastructure that supports IT system. For example, server architecture.
4) Data Level – overview of the organization data assets and management. For example, data governance framework.
5) Security Level – summary of current cyber security measures and policies. For example, encryption.

4
2.1. STRATEGIC GOALS AND INITIATIVES

• This section identifies how the EA program and specific EA components support the attainment of the
enterprise's strategic goals and initiatives.
• It builds upon comments provided in the Strategic Plan, and is included to more clearly show which EA components
and strategic initiatives are involved in each strategic goal area.
• A general description is then provided of how IT components support each goal and initiative at the Strategic
Initiatives level of the EA3 Cube Framework. Figure 9-4 provides an example format for an artifact that maps EA
components to the enterprise's strategic goals and initiatives.

Note:

• Where information gets extended to provide clear connections between EA components, strategic initiatives, and
overall goals.
• Focus how IT components supports each goals and initiatives.
1) Identification of supports – identifies how an EA program and a specific component contribute to the realization
of strategic goals and initiatives. It provides more detailed insights.
2) Clear illustration map shet dko magets

Mapping EA Components to Strategic Goals/Initiatives

2.2. BUSINESS SERVICES AND INFORMATION FLOWS

• This section identifies and emphasizes the role that EA plays in supporting business processes analysis and
improvement, as well as identifying and optimizing information flows within and between these processes.
• It also re-affirms the EA principle that EA components are a means to enable effective business services, and
should not be procured unless there is a strong business case that supports investment.
• Within this section, the enterprise's main LOBs should be listed along with the key business services and associated
information flows in each LOB. A general description is then provided of how IT components support each key
business process at the Business services level of the EA3 framework.

Note:

• So all in all, this is where optimization or seamless communication or information flow that supports our business
services.

5
 Mapping EA Components, Lines of Business, and Information Flows

2.3. SYSTEMS AND APPLICATIONS

• This section identifies how current EA components and artifacts at the Systems and applications level of the
EA3 Cube Framework support the information flows that are required for LOBs throughout the enterprise.
• The discussion should summarize how well this "suite" of commercial and custom developed IT systems and
front/back office services provide the functionality the enterprise needs for LOB operations and office automation.
• This can range from large scale, multi-module ERP solutions, to commercial applications and databases, to small
custom-developed websites. Comments should focus on degree of integration, potential scalability, user
satisfaction, and any reliance on proprietary solutions.

2.4. TECHNOLOGY INFRASTRUCTURE

• This section discusses the voice, data, and video EA components and artifacts that make up the Technology
Infrastructure level of the EA3 Cube Framework. The discussion should focus on how well these internal
and external networks, systems, and cable plants integrate to create a "seamless" infrastructure.
• Comment should also be made on how well the infrastructure currently handles the transport of voice, data, video,
and mobile information, in terms of reliability, scalability, and cost-efficiency.

2.5. IT SECURITY

• This section discusses the general approach to IT security at all levels of the EA framework.
• IT security should be part of any strategic goal or initiative that depends on accurate, properly authenticated
information.
• High-level descriptions are provided on how security is built into business services and the control of information
flows, as well as the design and operation of systems, services, and networks. Specific IT security information
should not be part of the EA Management Plan because it could reveal vulnerabilities.

6
2.6. EA STANDARDS

• The standards section documents the Technical Standards Reference Model (TSRM), which provides EA standards
for voice, data, video, and IT security that are used during EA component development.

Note:

• ISO (International Organization for Standardization)

• CEN (European Committee for Standardization)
• IEEE (Institute of Electrical and Electronics Engineers)
• NIST (National Institute of Standards and Technology)

SI MAAM NAGSABI NITO

ISO/CEN
Standards Area IEEE Standard NIST Standard Local Standard Products
Standard
standards that are developing standards
Develop standards
related to voice provide mandatory specific to the region
for voice
communication in guidelines and ensuring we comply
communication,
ensuring standards related to with the local
Voice interoperability and
technologies and
voice recognition and regulations and
protocols such as
quality of voice authentication and requirements for
VoIP or Voice Over
services on a global technologies, voice
Internet Protocol.
or regional scale. communication.
There is a wide range
of data
data management and communication development Code addressing data
interoperability and technologies standards for data protection laws and
Data security on an including network encryption, integrity regulations to a
international or protocol, data and confidentiality specific or particular
European level formats and data for secure handling. jurisdiction.
transmission
methods.
for a global original specific region so it
related for video provide standard for
application so video includes regulation
coding, streaming video analytics,
Video can cover
and communication forensic and security
and video content
compression, broadcasting or
protocols aspects.
transmit and quality. surveillance.
This includes your it's known for the encompass detailed
related information
various security cyber security regulation to a
security and cyber
protocols for network framework and specific region
Security security covering a
wireless guidelines for addressing your
broad spectrum of
communication, HD securing of cyber security and
security aspects.
device security. information system data protection law.

2.7. WORKFORCE SKILL REQUIREMENTS

• This section describes the approach to IT workforce planning and training that the enterprise uses in human
capital management.
• People are often the most valuable resource an enterprise has, and IT workforce plans should detail training
requirements for EA component operations support and new development projects at all levels of the framework.

Note: Integration, adaptability, and flexibility.

7
10.6 | PART 3: SUMMARY OF FUTURE ARCHITECTURE

3.1. FUTURE OPERATING SCENARIOS

• In this section, the future operating scenarios are presented along with a narrative description of the purpose
of the scenarios and the spectrum of operating environments that the scenarios respond to.
• For example, three scenarios are presented with an opening narrative that explains that they represent:
➢ Scenario 1: Continuing with the status quo.
➢ Scenario 2: An aggressive business strategy in a good market environment.
➢ Scenario 3: A defensive business strategy during a market down-turn.

Note:

1. Scenario 1 envisions visuals as usual approach where the enterprise maintains its current strategies and operations.
The purpose is to assess the impact of maintaining existing course or your existing component without significant
change then our response to our operating environment is suited for stable market conditions when the current
strategies are effective.
2. Scenario 2 is a proactive and ambitious business strategy during a favorable market condition. In here, we are
exploring any opportunities for growth and expansion when the market is conducive. So response to the operating
environment is tailored for times of economic prosperity and positive market rate.
3. Scenario 3 focuses on the defensive approach emphasizing resilience and risk mitigation during challenging market
condition. To prepare in economic downturns and navigate through periods of uncertainty.

3.2. PLANNING ASSUMPTIONS

• The planning assumptions from the scenarios are further discussed in terms of what they mean to the
priorities of the enterprise as it implements the future EA.
• The assumptions identify new capabilities and resources that will be needed if the enterprise is to be successful in
each scenario.
• This section then focuses on the selected scenario and the planning assumptions that will underline that course of
action. Continuing the example from above, if Future Scenario 2 is being pursued, then several new e-commerce
systems may need to be built, and new manufacturing capacity supported.

3.3. UPDATING CURRENT AND FUTURE VIEWS OF THE EA

• Documentation of planned changes in processes and resources is what creates the future views of the EA at
all levels of the framework.
• Using the EA3 framework as an example, these updates should be accomplished in a "top-down" manner, to
preserve the emphasis on strategy and business, and to maintain the logic of the documentation's relationships.
• Therefore, these updates would begin with to the enterprise's strategic goals and initiatives.

Note: This methodological procedure or process ensures documentation reflects in the enterprise evolving landscape in a
way that our strategic is logically connected and responsive to changing business priorities.

8
3.4. EA SEQUENCING PLAN

• The Sequencing Plan section of the EA Management Plan documents the

tasks, milestones, and timeframe for implementing new EA components
and artifacts.
• Large and mid-size enterprises often have many new developments,
upgrades, retirement, or migration projects underway at any given time and
these require coordination to establish the optimal sequencing of activities.

3.5. EA CONFIGURATION MANAGEMENT

• The EA Configuration Management (CM) section of the EA Management

Plan serves to support the sub-process by which changes to the EA are
managed and the standards in the TSRM are applied. Changes to the EA
include the addition, upgrade, retirement of EA components or artifacts.

• CM ensures that
(1) a standardized process is used in reviewing proposed changes,
(2) technical standards for voice, data, and video are followed or waived,
(3) there is a documented waiver process,
(4) waivers have specific time limits, so that EA standards are eventually
realized,
(5) there is enforcement for EA documentation version control.

10.67| PART 4: EA GLOSSARY AND REFERENCES

• This part of the EA Management Plan is where a Glossary of EA terms is provided along with an Acronym
List.
• There should also be a bibliographical list of reference books and articles that might provide additional background
or that help the reader's understanding of the EA Management Plan.
• Because the EA is still an emerging area of professional practice, the Acronym List and Glossary are helpful in
creating a common set of terms and definitions for use throughout the enterprise.

Note:

• This is the comprehensive reference section providing essential resources for a better understanding than adding document.
This includes you adding glossary of terms specific to EA and then acronym list to clarify abbreviations.
• Additionally, there is a bibliographical list of reference books and articles that can offer human additional insights and
background and also support so adding readers comprehensions.
• EA glossary purpose is to define human standardized term unique in our EA, it enhance communication ensuring common
understanding EA terminologies throughout the organization so it promotes consistency in language and interpretation across
different teams and departments.
• Acronym List is a compilation among acronyms while references for clarity, accessibility and ongoing development of
knowledge related to enterprise architecture.
• So, the EA management plan becomes a comprehensive and user friendly resource for individual involved in EA within the
organization.
• So overall, this chapter provides a description of the purpose, format and content is an EA management plan. Plan describes
the EA management process, implementation methodology and documentation framework as well as summaries.