Myth-Busting: What Enterprise Architecture Is Not November 3-7 ...

Myth-Busting: What Enterprise Architecture
Is Not
Symposium/ITxpo 2008
November 3-7, 2008
Palais des Festivals
Cannes, France
For more information about our research policies, processes and methodologies,
please visit Gartner Research Methodology on gartner.com.
These materials can be reproduced only with written approval from Gartner.
Such approvals must be requested via e-mail: vendor.relations@gartner.com.
November 3-7, 2008
Cannes, France
Betsy Burton

Myth-Busting: What Enterprise Architecture Is Not
Perceptions of Enterprise
Architecture (EA)
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
"It seems like those architects are
in an ivory tower telling us how to
do our jobs."
"I really don't want to get the
EA team involved."
"Enterprise architecture is
too big and broad."
"I see the output – but not a
lot of business value."
"Our management won't let us
use the words 'enterprise
architecture.'"
Misperceptions regarding the role of EA abound in most organizations, resulting in conflicts, as well as
resentment between the EA team and other groups. These issues are fueled by EA urban legends that have
taken on a life of their own and that continue to be professed as truths by pundits and practitioners. The key is
to increase collaboration between business, IT and architects by clearly communicating what EA is — and
equally what EA is not — and to debunk the common EA urban legends. We have found that, to be effective:
• The EA team must leverage the strategic guidance from a business strategy and the specific tactical
guidance from the business plan to guide their EA efforts overall.
• EA teams should serve as advisors to the IT strategic planning effort, along with the CTO, senior IT staff,
business leaders and users.
• EA teams must participate in performance management efforts relating to critical business processes.
• Enterprise architects do not dictate implementation details for the entire organization or for specific
practice areas.
In a well-architected enterprise, EA is the coordinating process that ensures that the other strategic and
management processes of the enterprise are in sync with respect to the future state.
Betsy Burton
ESC20_666, 11/08, AE
Page 1

Myth-Busting: What Enterprise Architecture Is Not
Key Issues
1. How does Gartner define "enterprise
architecture?"
2. What EA is not. And, how does EA relate to
other IT and business initiatives?
3. How can architects ensure that they deliver the
highest value and impact to business and IT?
Gartner's definition of EA (see "Gartner Defines the Term 'Enterprise Architecture'") reflects the goals and
aspirations of most enterprise architects who are familiar with EA processes, methodologies and artifacts. It
describes EA as an actionable and practical process and approach. EA is a collaborative process that facilitates
discussion and resolution between diverse groups of stakeholders across the enterprise, with the objective of
ensuring a consistent approach to the execution of the business strategy. However, in many organizations, EA
initiatives are often perceived by those outside the practice area as vague, too broad and overlapping other
functions. IT and business people will often express concern that EA is an effort by a group that is divorced
from day-to-day realities to "control" what they do and "impede" their efforts. As a result, their interactions
with enterprise architects is commonly clouded with suspicion, wariness and even disdain.
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Betsy Burton
ESC20_666, 11/08, AE
Page 2

Myth-Busting: What Enterprise Architecture Is Not
Key Issue: How does Gartner define "enterprise architecture?"
Gartner 2006 Definition of
Enterprise Architecture
• Enterprise architecture is…
… the process (it's a process AND a thing)…
… of translating business vision and strategy…
… into effective enterprise change (if no change is needed, then no architecture is
needed)…
… by creating, communicating and improving the key requirements, principles and models
that describe the enterprise's future state and that enable its evolution
(architecture produces the creative constraints that bound implementation decisions).
• The scope of the enterprise architecture includes…
… the people, processes, information and technology of the enterprise,
(architecture is NOT just about technology)…
… and their relationships to one another and to the external environment.
• Enterprise architects compose…
… holistic solutions…
… that address the business challenges of the enterprise…
… and support the governance needed to implement them.
Enterprise architecture means architecting the enterprise
to enable change.
Enterprises undertake the process of enterprise architecture for a variety of reasons. Some want to reduce
technology diversity. Others want to simplify a complex application landscape. Others want to improve time to
market for new products, or take a more-strategic approach to a transformation initiative. Whatever the reason
for initiating an enterprise architecture program, there is one common objective: change.
In May 2006, Gartner ratified a standard definition of EA. This definition represents the consensus opinion of
the entire Gartner EA research community on the scope and purpose of EA. EA has always been focused on
enhancing enterprise agility. We have long stated that EA must facilitate change. The key is to create, not the
perfect or elegant architecture for the moment, but the most adaptable architecture for the future. EA is a
challenging discipline, made more so by its potential scope and reach. Careful attention to the basics can mean
the difference between success and failure.
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Betsy Burton
ESC20_666, 11/08, AE
Page 3

Myth-Busting: What Enterprise Architecture Is Not
The Gartner EA Process
Organize Architecture Effort
Environmental Trends
Develop
Requirements
Architecting
Develop
Principles
Future-State Architecture
Governing and Managing
Current-State Architecture
Documenting
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Business Strategy
Develop
Models
Betsy Burton
ESC20_666, 11/08, AE
Closing
the Gap
Key Issue: How does Gartner define "enterprise architecture?"
EA is an iterative process that produces four major deliverables: 1) a future-state architecture, which supports
the requirements of the business strategy and external environmental factors expressed in the business context;
2) documentation of the current-state architecture (to the minimal level of detail required); 3) a gap analysis
that identifies the shortfalls of the current state in terms of its ability to support the strategies of the enterprise;
and 4) a road map defining the steps that should be taken to evolve the current state into the future state.
Control of the execution of the road map — decisions with respect to the allocation of funds and resources —
are not made within the architecture itself, but are the function of other management disciplines that are related
to, but not part of, the architecture.
A future-state architectural vision is developed through a process of defining requirements, developing
principles and building models at various levels of abstraction. This is followed by documentation of the
current state (to the minimum level of detail required). Finally, a road map is developed, which defines how
the enterprise will evolve from the current-state to the future-state architecture, and the evolution is achieved
through a governance process and structure, which ensures that the decisions of the EA are acted on as new
capabilities are built and new investments are made in technology.
Page 4

Myth-Busting: What Enterprise Architecture Is Not
The Gartner EA Framework
Solution
Architecture
Key Issue: How does Gartner define "enterprise architecture?"
As we indicated previously, the EA is overlaid by the business context, which is derived from the business
strategy and the external factors that affect the enterprise. Within the EA, Gartner has adopted an "aspect
oriented" approach, similar to the approach espoused in the IEEE's "Recommended Practice for Architectural
Description of Software-Intensive Systems" (IEEE 1471-2000), which proposes that the architecture is a
collection of "viewpoints" — architectural descriptions that satisfy the perspectives of each individual
stakeholder. In Gartner's approach, an EA has a minimum of three viewpoints: 1) a business viewpoint, which
is concerned with functional, process and organizational views of the enterprise; 2) an information viewpoint,
which is concerned with the information required to run the enterprise, the logic that manipulates the
information and the mechanisms that allow for integration of that information across diverse processes; and 3)
a technology viewpoint, which is concerned with the infrastructural components, both hardware and software,
that support the enterprise. These viewpoints are derived from the business context and should demonstrate
clear traceability of architectural decisions to the elements of the business strategy. The crux of the framework
is the "solutions architecture," which represents the intersection of the business, information and technology
viewpoints. Here, we find the architectural guidance required to build solutions, where the relationships
between components in different viewpoints are needed (for example, the application partition model, which
shows how the business functions of the enterprise are supported by the application portfolio).
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Betsy Burton
ESC20_666, 11/08, AE
Page 5

Myth-Busting: What Enterprise Architecture Is Not
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Strategic Planning Guideline: EA supports the development of a business strategy. However,
the ultimate decision rights on the business strategy and business plans are with business
leaders and senior executives, not the EA team.
EA Supports the Development of a
Business Strategy
Strategic target
Industrywidemultisegment
Particular
segment
Differentiation
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Strategic advantage
Uniqueness
perceived by
the customer
Focus
Low-cost
position
Overall cost
leadership
source: Source: Porter, competitive strategy
EA is not a business strategy.
A business strategy is defined by business leaders and senior executives, and it articulates the business goals
and directions of the organization overall, along with the strategic directions the business will pursue. The
business plan turns strategies into specific tactical plans designed to achieve the strategic goals. The EA team
must leverage the strategic guidance from the business strategy and specific tactical guidance from the
business plans to guide their EA efforts overall. Gartner refers to this activity as "creating the business context
for the architecture," and a critical deliverable of this effort is the common requirements vision (CRV — see
"Advancing the Common Requirements Vision Deliverable"). This document can be leveraged by the business
strategy and planning efforts, because it clearly identifies the changes required in the enterprise to support the
strategy. This information is invaluable when evaluating what business options are achievable and determining
how to change/evolve the business.
The challenge is that many organizations struggle with defining a clear and focused business strategy (see
"Findings: EA Should Be Driven by Business Objectives"). In such cases, the architecture team needs to work
with business and senior executives to help them articulate the strategy in an actionable way. Business and
senior executives should take the lead, but EA must support and help these efforts.
Betsy Burton
ESC20_666, 11/08, AE
Page 6

Myth-Busting: What Enterprise Architecture Is Not
Strategic Planning Guideline: The IT strategic planning team leverages critical architecture
artifacts, including the CRV (to provide overall strategic context for the IT strategy), the
future-state view of the enterprise, and the gap analysis and road map that define the
migration from the current state to the desired future state.
EA Teams Should Serve as Advisors Into
IT Strategic Planning
An IT strategic plan commonly addresses:
• Sourcing options and strategies
• Service delivery plans and service-level agreements (SLAs)
• Vendor management plans
• How resources should be allocated
• IT organizational structure and governance
• IT training, recruiting and mentoring programs
• IT functional plans (integrating new technologies, data formats,
service delivery models, acquisition cycles)
Strategic
Direction
Strategic
Initiatives
Project
Plans
3 to 5 Years 18 Months 1 Year Today
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Benefits
Realization
IT Strategy Evolves From Goals to Results
EA is not IT strategic planning.
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
EA and IT strategic planning are complementary efforts that must be coordinated and integrated, but they are
not the same. IT strategic planning is the vehicle that sets long-term goals for the IT organization; it establishes
the directions and constraints that will guide the tactical achievement of these goals, and it identifies the assets
and capabilities that the IT organization has to acquire, and how, in order to execute the plan. IT strategic
planning integrates the strategic intent of the business with the IT organization's delivery options, capabilities,
priorities and commitments.
Although IT strategic planning is most often led by a CIO, EA teams should serve as advisors into IT strategic
planning, along with the CTO, senior IT staff, and business leaders and users.
Betsy Burton
ESC20_666, 11/08, AE
Page 7

Myth-Busting: What Enterprise Architecture Is Not
Strategic Planning Guideline: EA provides the future-state road map, and the principles,
standards and guidelines provide the decision criteria that ITG uses to make investment
decisions.
ITG Builds on an Effective EA Initiative
(What Should IT Work On?)
Demand
Governance
Business Management Primary Responsibility
Plan Implement Manage Monitor
Business IT
Strategy
Validation
Business/IT
Operational
Planning
Overall
IT Investment
and Expense
Develop Demand
Governance
Processes
Demand
Governance
Implementation
Councils/
Committees
IT Investment
Portfolios
(PPM)
Investment
Evaluation
Criteria
IT Service
Chargeback
Business Unit
Prioritization
Intra-/Inter-
Enterprise
Prioritization
Issue Escalation/
Resolution
Funding/
Chargeback
Board IT
Governance
Spending/
Project
Oversight
Business Benefits
Realization
IT Value
Assessment
IT Governance
Effectiveness
(Metrics, etc.)
Strategy
IT
Governance
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Security
Corporate
Compliance
Sourcing
Etc.
• Goals
• Domains
• Principles
• Decision Rights
EA is not IT governance.
(How Should IT Do What It Does?)
Supply
Governance
IT Management Primary Responsibility
IT Supply Governance Domains
• Plan
• Implement
• Manage
• Monitor Compliance
• Plan
• Implement
• Manage
• Monitor Compliance
• Plan
• Implement
• Manage
• Monitor Compliance
• Plan
• Implement
• Manage
• Monitor Compliance
Architecture
Project
Management
Procurement
Betsy Burton
ESC20_666, 11/08, AE
• Plan
• Implement
• Manage
• Monitor Compliance
• Plan
• Implement
• Manage
• Monitor Compliance
• Plan
• Implement
• Manage
• Monitor Compliance
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Gartner defines "IT governance" (ITG) as "the processes that ensure the effective and efficient use of IT in
enabling an organization to achieve its goals." ITG is composed of processes with the inputs, outputs, roles and
responsibilities that are inherent in a process definition. One of the models we use to represent ITG is the
Gartner IT Governance Demand/Supply Model (see "Defining IT Governance: The Gartner IT Governance
Demand/Supply Model"), which illustrates the role of an IT governance strategy relative to demand
governance (for example, what the IT organization should work on) and supply governance (for example, how
the IT organization does its work). The IT governance strategy is developed from the articulation of the
business strategy in the CRV, ensuring alignment with strategic goals.
Page 8

Myth-Busting: What Enterprise Architecture Is Not
Tactical Planning Guideline: Part of the discipline of program management is to make sure
that the projects are executed in a way that adheres to the standards, guidelines and
principles that are created as part of the EA effort.
Program Management Ensures That
Projects Follow EA Guidance
Project management
ensures that a
specific project
delivers on time and
on budget.
Program
management is the
art of ensuring that
multiple related
projects deliver a
desired strategic
outcome.
Project
Project
A
A temporary endeavor,
undertaken to create a
unique result
EA is not program management.
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Program
Program X
C
A
E
B
D
Multiple related projects
where the coordinated
outcome is greater than
the sum of the
individual project
outcomes
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Gartner defines program management as the coordinated planning, management and execution of multiple
related projects that are directed toward the same strategic, business or organizational objectives. EA is a
planning discipline, while program management is a discipline of execution. EA is responsible for defining the
future state of the enterprise, analyzing the gaps between the current state and the future state, and developing
the standards and guidelines that support the realization of the future state.
Betsy Burton
ESC20_666, 11/08, AE
Page 9

Myth-Busting: What Enterprise Architecture Is Not
Strategic Planning Guideline: Portfolio management takes its strategic guidelines from the
common vision of the business strategy articulated during the EA process, and it uses the
road map, principles standards and guidelines as part of the criteria for portfolio
decisions, while balancing between strategic and tactical needs.
Portfolio Management Takes Its Strategic
Guidelines From EA
Increasing Value
H
A
Maximize Value and Minimize Risk
G
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
M
J
C
Increasing Risk
As-Is Portfolio
Size of circle = Project cost Color = Project health
F
Increasing Value
EA is not portfolio management.
A
G
M
J
C
Increasing Risk
Betsy Burton
ESC20_666, 11/08, AE
F
Target Portfolio
On target At risk
In trouble
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Portfolio management is the processes, governance and tools used to plan, create, assess, balance and
communicate the execution of the IT portfolio. Portfolio management techniques can be applied to the
application portfolio, the infrastructure portfolio, the project portfolio, the IT investment portfolio or any of
these in combination. Portfolio management is a strategic discipline that ensures a balanced approach (in terms
of risk tolerance, strategic goals, resources and capabilities) to IT investment.
Page 10

Myth-Busting: What Enterprise Architecture Is Not
Strategic Planning Guideline: EA provides the analysis of the strategy, and identifies the
most-critical strategic imperatives and the high-level process topology, as well as the
principles that guide the design and implementation of processes.
EA and BPM Are Synergistic
Process
Catalog
BPM Technology
Selection
Detailed
Process
Designs
Project
Teams
BPM
Metadata
Bridging
Tools
Process
Metrics
Process
Reference
Models
Notation
Standards
Modeling
Tools
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
CRV
Process Design
Principles
Process
Topology
Strategic
Process
Initiatives
Functional
Model
Information
Flows
EA
EA Principles
Organization
Structure
Information
Principles
Technology
Standards
Infrastructure
Services
Betsy Burton
ESC20_666, 11/08, AE
Technical Patterns
Interchange
Financial
Standards
Requirements
Service
Definitions
EA is not business process management.
Service-Level
Requirements
Technical
Topology
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Business process management is a systematic approach to improving the way an enterprise does business by
analyzing the strategic goals of the enterprise, then aligning stakeholders' interest with shared process
performance objectives. As part of the CRV process, EA provides the analysis of the strategy and identifies the
most-critical strategic imperatives. EA also provides the high-level process topology and the principles that
guide the design and implementation of processes. Process improvement is an operational discipline that
manages the design and implementation of new and improved processes in the enterprise.
Page 11

Myth-Busting: What Enterprise Architecture Is Not
Strategic Imperative: Nearly 80% of companies use metrics that bear no relationship to the
business value or operational strategies being pursued.
EA Teams Must Participate in
Performance Management Efforts
Performance management is the
combination of management,
methodologies and metrics, supported
by applications, tools and infrastructure,
that enable users to define, monitor, and
optimize results and outcomes to
achieve personal or departmental
objectives, while enabling alignment with
strategic objectives across multiple
organizational levels (personal, process,
group, departmental, corporate or
business ecosystem).
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Strategic Alignment
EA is not performance management.
Management,
Methodologies and
Metrics
Business Ecosystem
Corporate
Department
Group
Process
Personal
Applications, Tools and
Infrastructure
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Performance management (see "Understand Performance Management to Better Manage Your Business") is
the combination of management methodologies, metrics and IT (applications, tools and infrastructure) that
enable users to define, monitor, and optimize results and outcomes to achieve personal or departmental
objectives, while enabling alignment with strategic objectives across multiple organizational levels (personal,
process, group, departmental, corporate or business ecosystem).
EA teams must participate in performance management efforts relating to critical business processes and
functions. This will allow them to track key business metrics that demonstrate the business value that EA is
delivering. In addition, any efforts to define key performance management metrics should leverage the
artifacts of EA — specifically, any change metrics or any direct metrics associated with EA principles. Finally,
EA should leverage the discipline of performance metrics to define metrics with respect to the business value
and impact of EA efforts and investments.
Betsy Burton
ESC20_666, 11/08, AE
Page 12

Myth-Busting: What Enterprise Architecture Is Not
EA Provides the Foundation for Better
Implementation Decisions
EA provides the foundational principles, guidelines, standards and constraints
that enable implementation teams to make better decisions.
EA is not implementation.
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
AC Water Media
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Enterprise architects do not dictate implementation details for the entire organization or for specific practice
areas. Organizationwide departments, competency centers, project teams and steering groups have deeper
knowledge of the specific requirements, processes, people and technology within a defined practice area. The
representations of the business, processes, information, people and technology that are created by the EA
effort should be used to guide and support the planning and implementation effort across the organization.
Architects should work closely and in collaboration with critical teams. Their joint efforts should be focused
on leveraging artifacts to apply guidelines to a specific practice area and implementation, while enabling the
implementation teams to lead with respect to their specific skills.
Action Item: Enterprise architects must actively engage with implementation teams and focus architecture
efforts not on the creation of yet another standard, but rather on identifying the areas in which the business
strategy demands reuse and interoperability.
Betsy Burton
ESC20_666, 11/08, AE
Page 13

Myth-Busting: What Enterprise Architecture Is Not
Finding: Many EA teams become trapped in a vicious cycle of creating and managing
current-state architecture documentation — so much so that they never effectively focus
on the strategic requirements future-state planning.
EA Is Much More Than Just ETA
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
A common EA pitfall is excessive
documentation of the current-state
architecture.
Best practices for creating currentstate
architecture to document:
1. Remain focused on EA scope
2. Develop in the context of the
future-state architecture
3. Take an iterative approach
EA is not a technology or
application inventory.
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Current-state inventory (as a component of the architecture repository) is updated with each EA iteration through gap
analysis, impact assessment, migration planning and implementation planning. The initial focus of current-state
documentation must be to place basic information about solution attributes in the context of the solution taxonomy (for
example, business organizational units cross-referenced to critical business information flows) developed from the futurestate
exercise. This taxonomy provides the context to place current solutions in the taxonomy for future analysis. Many
EA teams take this explanation to mean that they must inventory every process, data element, application, service and
technology that exists in the organization and take complete responsibility for maintaining that inventory. This
interpretation can lead to never-ending, current-state documentation, with limited time and resources to focus on the
future state. In fact, we recently spoke with a midsize government organization that hired a consultant to "do" its EA, and
the output of this work was an 85-page inventory of technologies, applications and their connecting points.
Although a technology and application inventory may be helpful when defining a current state, this is not an EA. EA is a
much broader process that directly reflects the business vision and strategy, as well as the people, processes, organization,
information and technology (including applications) that are critical to the business strategy. The current-state architecture
should be business as usual for every good manager. Managers should have an accurate picture of the current state of the
domain they manage, and the EA team should be able to leverage this information.
EA provides actionable, prescriptive guidance for project-level decision making, consistent with executing a transition
plan toward a described future-state architecture that aligns with the business strategy.
Betsy Burton
ESC20_666, 11/08, AE
Page 14

Myth-Busting: What Enterprise Architecture Is Not
Strategic Guideline: EA provides the strategic context for the change through the common
requirements vision or some similar vehicle, and it provides the view of the future state from
a process, organization, information and technology perspective.
EA Provides the Strategic Context for
Change Management
Step 1:
Transition Planning
Business Functions and
Subfunctions
People
Financials
Organization
Process
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Step 2:
Transition Execution
EA is not change management.
Step 3:
Transition Completion
EA, and EBA in
particular, provides
guidance and support
necessary to flexibly
evolve and optimize
business dimensions
(the people,
processes, financials
and organizations) to
achieve effective
enterprise change.
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Change management is a structured approach to change that encompasses individuals, teams and
organizations, with the objective of facilitating the human side of change. In most enterprises undergoing
significant change, the change manager is a senior business executive responsible for coordinating all aspects
of the change, including technology, human factors, reorganization and process modifications.
EA provides the strategic context for the change through the common requirements vision or some similar
vehicle, and it provides the view of the future state from a process, organization, information and technology
perspective. This gives everyone a coherent view of the strategic drivers for the change, as well as a clear
picture of the target state.
Betsy Burton
ESC20_666, 11/08, AE
Page 15

Myth-Busting: What Enterprise Architecture Is Not
Tactical Guideline: Focus EA efforts on defining the minimum constraints that are necessary
for interoperability without constraining the ability of the business to grow and change.
EA Must Support a Continuum of
Standards
• Formally defined and approved
• Linked to principles, CRV and
future state
• Focused on reducing complexity,
cost and chaos
• Fairly static
• Exceptions will be reviewed
and approved
EA is not just setting standards.
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
• Neither defined nor approved
• Driven by immediate user needs
and interests
• Focused on supporting users' wants
and needs to explore, innovate,
produce, play and communicate
• Highly dynamic, viral acceptance,
augmentation
• There are no such things as "exceptions"
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Another common mistake by architecture teams, as well as a misunderstanding by IT and business users, is
that EA is focused on "setting standards" (for example, technologies, applications, processes and usage). When
organizations define a future state, the need for standards in specific areas becomes clear at the conceptual
and logical levels. Specification of standards becomes more critical at the implementation levels. However,
these standards are the result of a complete business-driven EA effort, and they are guidelines for reaching the
future state. Any defined standards should evolve with the business strategy and thus the EA. Organizations
should incorporate the process of re-evaluating and updating standards into the EA process.
Betsy Burton
ESC20_666, 11/08, AE
Page 16

Myth-Busting: What Enterprise Architecture Is Not
Finding: The traditional standards process, in which IT dictates solutions and expects full
compliance, no longer works. Standards must be accompanied by choices, and business
users must accept responsibility if their choices yield outcomes that are less optimal than
those provided by IT mandates.
Architects Must Advocate, Evangelize
and Educate
EA is not enforcement.
Key Issue: What EA is not. And, how does EA relate to other IT and business initiatives?
Enterprise architects will not succeed if they are perceived to be solely enforcing rules and policies. They will
also not succeed if they are viewed as controlling the use of technologies and processes. Furthermore, they will
fail if they are viewed as impeding innovation and creativity. Business and IT users will ignore the efforts of
EA and create their own solutions to meet their requirements (see "Recognize the New Stakeholder: The
Individual"). EA and architects must be viewed as helping, supporting, advising and guiding the organization
to achieve its business strategy through a future-state vision. Therefore, it is the responsibility of the enterprise
architect to reach out and work across the organization to educate and encourage the use of the EA (see "Q&A:
Architects Must Advocate, Evangelize and Educate").
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Betsy Burton
ESC20_666, 11/08, AE
Page 17

Myth-Busting: What Enterprise Architecture Is Not
Key Issue: How can architects ensure that they deliver the highest value and impact to
business and IT?
Strategic Imperative: Develop a common, enterprisewide approach to governance and
portfolio management that is not focused on reigning in IT, but on achieving enterprise-level
strategic objectives. Require leadership participation and compliance.
Carry Requirements From Strategy
Through Execution
Enterprise Governance
Compliance
Management
Principles, models,
standards, guidelines
Assessments
Business metrics,
Go pre-/post-mortems
to Slide Master to add
client's name, project #
Project
Management
Design, build, run
Business
Strategy &
Intent
Enterprise
Architecture
Road
Map
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Strategic Response
Functions
Betsy Burton
ESC20_666, 11/08, AE
1 … n
Future-State Requirements
Core Change Assumptions
Current State Assessment
Gap Analysis
Portfolio Management
Alternative Analysis
Proposed Initiatives
It's not enough just to have an integrated strategy. That's just planning. An integrated strategy is important
because it provides the common objective criteria for making decisions. The results, however, will only be
seen in the execution. Effective governance and portfolio management are critical components of an integrated
strategic management process. Unfortunately, most enterprises lack appropriate governance forums, a
consistent initiative evaluation framework and coordinated portfolio management. In many respects, this is a
vestige of a 20th-century management convention that promulgated the notion that lines of business should
function largely independently. The idea of enterprise-level collaboration is a relatively new concept, made
necessary by evolving business strategies that leverage shared processes, information, technology and
relationships. Where do governance and portfolio management fit in this overarching management process
model? Governance provides the forums and rules of engagement by which information will be shared and
conflicts resolved. Portfolio management is a critical capability for resolving the most-common conflicts —
those of resource requirements. The common thread that pulls all these efforts together is the application of a
common set of metrics that are used to identify, build and manage the integrated set of activities needed to
execute a strategic position.
Page 18

Myth-Busting: What Enterprise Architecture Is Not
Recommendations
• Leverage the strategic guidance from a business strategy,
and the specific tactical guidance from the business plan, to
guide EA efforts.
• Become an advisor to the IT strategic planning effort, along
with the CTO, senior IT staff, business leaders and users.
• Participate in performance management efforts relating to
critical business processes.
• Do NOT dictate implementation details for the entire
organization or for specific practice areas.
• Be the coordinating process that ensures that the other
strategic and management processes of the enterprise are in
sync with respect to the future state.
Key Issue: How can architects ensure that they deliver the highest value and impact to
business and IT?
A well-functioning EA program produces a number of artifacts that are used by other teams in the enterprise,
including:
•A common vision of the requirements of the business strategy and the external trends affecting the enterprise.
This provides the strategic imperatives for other initiatives, such as business process management (BPM),
business intelligence competency center (BICC), IT governance, enterprise information management (EIM)
and PPM.
•A unified view of the future state that supports the strategy. This vision is shared across the entire enterprise
and provides other initiatives with a common set of goals.
•An analysis of the gaps between the current and future states, as well as a road map for the evolution of the
enterprise.
•The principles, standards and guidelines that support the realization of the future state as implementation
decisions are made.
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Betsy Burton
ESC20_666, 11/08, AE
Page 19

Myth-Busting: What Enterprise Architecture Is Not
Management Imperatives
• When you return to your desk:
- Revisit how EA is positioned in your organization.
- Clearly define what EA is — and be equally clear about what it is not.
• Short term (within two months):
- Document how EA artifacts support other disciplines.
- Send enterprise architects to facilitation training.
- Assess your EA program's maturity:
• identify the critical constraints that keep you from being more effective
• Long Term (in about a year):
- Assess how EA artifacts are being used.
- Poll your stakeholders to determine their satisfaction with the EA
program.
- Reassess your EA program maturity and continue to improve.
Key Issue: How can architects ensure that they deliver the highest value and impact to
business and IT?
Enterprise architects, who typically drive the EA program, are facilitators and do not have decision rights over
all the critical issues of the enterprise. The participants in the EA process include the business, IT and
operations, and representatives of the competency centers supporting specific disciplines, such as business
intelligence and the various management disciplines of the enterprise (like business strategy and portfolio
management). These participants retain their decision rights, but in an architected enterprise, those decisions
are made in collaboration with other enterprise stakeholders as part of the EA process, rather than being made
in individual functional silos. To have the highest impact on these teams, architects must:
1. Be very clear about what EA is — and be equally clear about what it is not.
2. Clearly document in the EA program charter how EA artifacts support other disciplines, and how the work
of the architecture team can be leveraged.
3. Send enterprise architects to facilitation training to give them the tools they need to work with diverse
groups of stakeholders to coordinate decision making.
This presentation, including any supporting materials, is owned by Gartner, Inc. and/or its affiliates and is for the sole use of the
intended Gartner audience or other authorized recipients. This presentation may contain information that is confidential,
proprietary or otherwise legally protected, and it may not be further copied, distributed or publicly displayed without the express
written permission of Gartner, Inc. or its affiliates. © 2008 Gartner, Inc. and/or its affiliates. All rights reserved.
Betsy Burton
ESC20_666, 11/08, AE
Page 20