Q U E S T I O N & A NSWER

March 13, 2007

Demystifying EA Programs
by Gene Leganza
with Randy Hener, Jost Hopperman, Mike Gilpin, Henry Peyret, and Megan Daniels

EXECUT I V E S U M MA RY
Enterprise architects must advance a strategic, enterprisewide agenda in the context of siloed interests
and a show me the money attitude toward the business value of projects. The going is never easy, but
leading enterprises build upon executive support with carefully crafted organizations and processes that
nudge the enterprise toward strategic goals, one tactical decision at a time. The key to success is keeping
one eye on the architecture itself and one eye on politics and business goals to ensure that the program
delivers tangible and visible value. When facing such challenges, enterprise architects have a number of
common questions about setting up and managing enterprise architecture (EA) programs, which we
answer herein.

QUESTIO N S
1. Do organizations have several levels of architect positions?

2. What can organizations use to measure the impact of their EA programs?

3. What are best practices regarding EA organizational design?

4. What are some eective ways to nd and interpret business goals for EA strategy?

5. Is certication a major factor in hiring architects?

6. What is the recommended process to develop and manage technical architecture content?

7. What is the best way to segment an enterprise architecture?

8. What are best practices for conducting architecture reviews?

9. What is the appropriate size and composition of an architecture review board?

10. What are the major EA tools vendors?

Headquarters
Forrester Research, Inc., 400 Technology Square, Cambridge, MA 02139 USA
Tel: +1 617/613-6000 Fax: +1 617/613-5000 www.forrester.com
Question & Answer | Demystifying EA Programs 2

TARGET AUDIENCE
Enterprise architecture professional

BEST PRACTICES MAKE EA PROGRAMS PRAGMATIC AND EFFECTIVE

Enterprise architects struggle to make their EA programs eective and perceived as such. They are
often the only individuals chartered with promoting enterprisewide strategic goals almost all
other decision-makers focus on near-term solutions within their operational silos. And architects
do not get to wield a big stick to further their agenda; rather, they inuence via personal credibility,
political savvy, and communication skills. For all that, EA programs can have signicant value for
organizations. Here is Forresters take on some of the most common questions surrounding creating
and managing EA programs that plague chief architects and EA practitioners.

1. Do organizations have several levels of architect positions?

Many organizations do use dierent architect titles to distinguish the dierent architect roles. The
most mature EA programs have created very specic position descriptions for the dierent roles,
complete with the desired knowledge, skills, and traits. While the exact titles and combinations of
roles vary, the typical architect positions are enterprise architect, infrastructure architect, application
architect, solutions (or project-level) architect, data (or information) architect, and business
architect. Enterprise architects maintain a consistent strategic and enterprisewide perspective and
play a coordinating role across the enterprise. Infrastructure, data/information, application, and
business architects regularly oscillate between strategic and tactical roles, but they are expected
to pull the areas they work with toward strategic solutions within their operational and tactical
contexts. Solutions architects are typically experienced technicians responsible for solution design
for individual projects.

2. What can organizations use to measure the impact of their EA programs?

Most organizations that Forrester works with are in the early stages of metrics development for
their EA programs and have mostly developed measurements relating to the activity of the EA
team. Generic EA metrics (for example, the number of EA artifacts created, the number of projects
reviewed, etc.) do not show the impact to the organization. Measuring EAs impact requires clearly
stating the value proposition of your specic EA program and relating EA activity to business and
IT goals. Using a process called goal-tree analysis, architects can dene action-oriented goals and
link them to the goals articulated by the business and IT.1 Then, using the goal-question-metric
(GQM) approach, the EA team should ask: What would accomplishing our goals look like? What
would change?2 Match metrics to the answers to those questions for each action-oriented EA goal,
and you will have quantied measures of the impact of the EA program.3

March 13, 2007 2007, Forrester Research, Inc. Reproduction Prohibited

Question & Answer | Demystifying EA Programs 3

In addition to measuring the impact of specic EA program goals, it is important to track the
business benet of initiatives for which architects involvement was key to success. Track the ROI
or other quantication of value used in your environment published in the initiatives business
cases, and be sure to market EAs contribution to notable successes.

3. What are best practices regarding EA organizational design?

EA organizations are more eective when they report into a C-level executive (CxO), but they can
also be eective at other levels if they are positioned to have broad impact: for example, reporting to
a director of planning or strategy who reports to a CxO.4 As to size, central groups vary depending
on whether the approach is federated or totally centralized (as well as other factors), but 1% to
2% of the size of the IT organization is the norm.5 The bottom line in designing the organization
is to gure out how best to engage the subject matter experts (SMEs) within an organization to
contribute to EA development and maintenance, as well as how best to eect governance. Most
shops have some centralized enterprise architects to act as leaders, evangelists, program managers,
and strategists, and they coordinate the activity of a network of SMEs who have a more operational
focus, such as those in central integration services groups.6 EA leaders should formalize this SME
network by obtaining commitment from their management to participate. An executive body such
as an IT steering committee should approve major EA strategies.

4. What are some eective ways to nd and interpret business goals for EA strategy?

Being unable to nd detailed, concrete business goals that architects can use as a basis for their EA
planning is a common problem.7 Architects can start with formally published strategic plans, but
they should expect to do a lot of legwork to get to something of substance. Within IT, you should
interview heads of application development units and relationship managers, as people in these
roles work closely with business project sponsors and other businesspeople who are in key positions.
Within business units, interview business executives, and get their needs, desires, and plans verbally.
Summarize what you hear, and loop back to management to report your ndings and get their
reaction. Tell them that you will base your EA planning on the assumption that your collected
results represent the goals of the enterprise. Get their edits, and loop back again when you can
show how you have fashioned EA plans around the business goals. Using this approach repeatedly,
architects can train business executives to follow more structured strategic planning processes.8

To discus strategies with the business, architects must do more than simply dropping IT jargon
and using business language. They must learn to think like the businesspeople in fact, they must
become businesspeople rst and technologists second so that business executives will nd it
valuable to interact with them.9

March 13, 2007 2007, Forrester Research, Inc. Reproduction Prohibited

Question & Answer | Demystifying EA Programs 4

5. Is certication a major factor in hiring architects?

There is growing interest in architect certication. While this is a sign of the maturing of EA as a
function, it is not yet a signicant factor in hiring or training architects. Certication can be an
important verication of a job candidates skills and knowledge, but its value depends completely on a
consensus regarding precisely what skills and knowledge are relevant and the qualications of the
certifying organization. With enterprise architect certication now available from Carnegie Mellon
Universitys Institute for Software Research International, along with IT architect certication from
The Open Group and US federal enterprise architecture (FEA) certication available from the FEAC
Institute, the problem is not the certifying organization.10 But most hiring managers are still faced
with a potential mismatch between what they want in an architect and what certication veries.11
Too much ambiguity remains about what an organization needs from its EA program and its
architects for hiring managers to consider certication to be the deciding factor when selecting
candidates. And for enterprise architects, most hiring managers prefer to look for internal candidates
with an existing track record and a high degree of credibility. When forced to look outside due to a
lack of internal candidates, these hiring managers will use certication as just one of many factors.

6. What is the recommended process to develop and manage technical architecture content?

The EA team should create a taxonomy of technical architecture areas, usually referred to as
domains or subdomains, that require development. The central team then creates working groups to
develop the standards, strategic direction, and road map for that area of technology. The central EA
team reviews and coordinates all domain architectures, eventually presenting them to its approval
body, which is often an IT steering committee or similar executive group comprised of business
and IT executives. Maintenance of domain architectures can be done by periodically reviewing the
architecture via the same process but with rotating membership to share the burden.

Key to proper architecture development is the central EA team ensuring that the working groups
develop all domain architectures with an understanding of the business and IT strategy, goals,
drivers, and architecture principles, as well as ensuring that the domains are appropriately integrated
and coordinated.12 It is also important that the central team build the working groups with
consideration not only for the appropriate SMEs for that technology area but also for representation
from political subdivisions of the enterprise. The leading EA organizations obtain a consensus
for the EA strategy that includes all who might object. Inclusiveness breeds a sense of ownership,
ownership breeds buy-in, and technical architecture governance requires buy-in.

7. What is the best way to segment an enterprise architecture?

Standard practice is to segment enterprise architectures into business architecture, information or

data architecture, application architecture, and infrastructure or technical architecture.13 In addition
to these segments, many organizations create virtual architecture domains that cross domain
boundaries, such as integration architectures; development architectures; operation architectures

March 13, 2007 2007, Forrester Research, Inc. Reproduction Prohibited

Question & Answer | Demystifying EA Programs 5

to integrate planning for system management technology; and security architectures to integrate
planning for security across technology, business, and information architectures. Within domains,
organizations categorize business, information, and application architectures by both business
process and internal organizational entity (business unit). The complexity of infrastructure or
technical architectures requires a further categorization scheme employing subdomains.14

8. What are best practices for conducting architecture reviews?

Most organizations implement architecture review boards (ARBs) as their initial foray into
architecture governance. These are groups that meet periodically to review project designs before
construction begins. Organizations that follow the city planning metaphor for EA confer a building
permit on projects approved as being aligned with the architecture. ARBs usually only review
projects that are larger than a certain size criteria or those deemed to have potentially signicant
architecture impact. While this is a very good governance mechanism, its main problem is its timing
at the end of project design: No one wants to go back to the drawing board once the team has made
decisions, and business sponsors usually have the clout to insist that major exceptions be made in
the name of project schedules and budgets. Plus, organizations that move from waterfall to Agile
processes will not have such a clear gating point for large projects.15

Two solutions to this problem are informational reviews and a consulting model. Informational
reviews use ARBs but time them early in the design phase to inform the architecture community
of the general functional requirements of the project and initial design ideas. The consulting
model empowers distributed or central architects to review requirements and designs, and it
works extremely well for positioning architecture governance in the form of design guidance. The
consulting model requires the coordination of consulting architects knowledge and information
regarding their governance decisions, and it distributes authority outside of the central team, which
may not work in all environments. However, many rms experience architecture consulting as the
most eective form of proactive architecture governance.16

9. What is the appropriate size and composition of an architecture review board?

As important architecture governance entities, ARBs must balance technical expertise with political
representation. The board must pass judgment on project architectures, so it must have the best
technical minds available. It must be politically viable, so it must have representation from the
appropriate organizational units. This can lead to unwieldy size. Architecture leaders have gotten the
best results from including formally appointed architects from all parts of the organization to get the
technical expertise of each SME and to make sure that every business unit has representation.

While design discussions with more than 15 people in the room can seem unmanageable, Forrester
has seen instances of extremely eective ARBs with more than 30 people in the meeting room
or conferenced in via telephone. A large board size dictates more formal procedures. Large ARB
meetings are not brainstorming sessions. Rather, they are very structured and include detailed

March 13, 2007 2007, Forrester Research, Inc. Reproduction Prohibited

Question & Answer | Demystifying EA Programs 6

review documents delivered with enough time for thorough premeeting review by board members.
ARB sessions then become an orderly walkthrough accompanied by prepared questions. Issues that
cannot be resolved in brief discussions are tabled for oine resolution. These practices make large
review boards possible and smaller review boards more ecient.

10. What are the major EA tools vendors?

In a recent Forrester survey, nearly half of 196 enterprise architect respondents told us that they
have not yet acquired an EA tool.17 For those that do not yet have a tool, the biggest reason for
waiting was no clear value proposition. The most likely architects in our survey to have adopted
EA tools came from the largest enterprises with more than 5,000 employees: 64% told us that they
have acquired an EA tool. The architects top reasons for their tool choices? Price, ease of use, and
functional completeness topped the list, along with secondary criteria of collaboration features,
integration with Microsoft Oce, and metamodel customization.

Telelogic System Architect was the most commonly used tool, with 13% of respondents using it,
and the next most popular choice was the so-called Microsoft EA suite Microsoft Oce and
Visio which claimed 11% of our architects. Six percent of respondents reported using IDS Scheer
ARIS, and 5% or less of respondents reported using Adaptive, Agilense, AM2 Systems, BEA Systems
AquaLogic Enterprise Repository, Casewise, GoAgile MAP (formerly Ptech), MEGA, Proforma, and
Troux Metis Architect. These vendors represent the EA tool vendor marketplace.

ENDNOTES
1
Goal-tree analysis is a simple technique borrowed from quality control, where a hierarchy of goals is
dened, leading to the technical means for accomplishing the goal. See the August 19, 2002, Planning
Assumption Best Practices In Implementing Infrastructure Service-Level Management.
2
The GQM technique helps EA groups establish metrics that relate to business and IT impact. See the
September 30, 2005, Best Practices Metrics Boost EA Eectiveness.
3
The architecture group measures its work in terms of business process improvement and the ability of IT to
react quickly to changing requirements. See the February 21, 2006, Best Practices Architecture Coherence
In Financial Services.
4
The head of EA reporting into the CxO level is one indication of a maturing EA function. See the October
27, 2005, Quick Take The Maturing Of The EA Function.
5
EA group size varies by the structure of the EA eort, the scope of the program, the size of the IT
organization, and the degree to which the business and IT environment is dynamic. See the October 13,
2005, Quick Take How Big Should The Enterprise Architecture Group Be?
6
The task of those groups can be very similar to that of a very specialized, operations-oriented architecture
group. See the October 17, 2003, IdeaByte Central Integration Services Group As A Central Element Of
Integration Initiatives.

March 13, 2007 2007, Forrester Research, Inc. Reproduction Prohibited

Question & Answer | Demystifying EA Programs 7

7
Forrester interviewed several IT strategy consultants about the common CIOs dilemma of being expected
to align with the business without being told what the business strategy is. See the December 5, 2003, Brief
Aligning IT With The Business When The Business Strategy Is MIA.
8
Application strategy must provide an interface between the IT organization and the business side of a
company so that business units can derive current and future implications of the business strategy and
their impact on IT. See the September 25, 2002, Planning Assumption Application Strategy: Planning For
Flexibility.
9
Over the course of three years, architects at The Hartford Financial Services Group went from developing
application blueprints based on scavenged business plans as a hobby to a formal, joint business-IT
development of capability blueprints. The blueprints provide a picture of where the business wants to be
in ve years, and more importantly, the collaborative business-IT dialog ensures that the picture is heavily
inuenced by ITs insights on how technology enables new ways of doing business. See the May 19, 2006,
Best Practices SOA Investment Strategies.
10
For more information on architect certication, see Carnegie Mellons CMU certication Web site (http://
strategic.isri.cmu.edu/v2/EnterpriseArchitecture.jsp), see The Open Groups certication program Web site
(http://www.opengroup.org/itac/cert/), and see the FEAC Institutes home page (http://www.feacinstitute.org/).
11
Architect certication can be relevant, depending on what skills are certied. See the August 1, 2005, Quick
Take The Open Group Certies Architects But Leaves Out EA.
12
This understanding of business and IT strategy is supported by strategic architecture development. See the
March 15, 2006, Best Practices Strategic Architecture Development In An SOA World.
13
The standard domains of business, information, application, and infrastructure can be further subdivided
to itemize overlapping areas. See the November 11, 2002, Planning Assumption The Pillars Of Enterprise
Architecture Terminology.
14
Architects can nd a good example of a technical architecture taxonomy in the various frameworks
available, including the Technical Reference Model of the US FEA. See http://www.whitehouse.gov/omb/
egov/a-6-trm.html. Also, see the March 17, 2004, Best Practices Standards For Enterprise Architecture,
and see the July 26, 2006, Best Practices Enterprise Architecture Frameworks Are Mainstream, But The
Landscape Remains Diverse.
15
Use of Agile development methods continues to grow. See the November 30, 2005, Trends Corporate IT
Leads The Second Wave Of Agile Adoption.
16
Architecture consulting builds architecture compliance in, rather than policing it. See the February 21, 2006,
Best Practices Architecture Coherence In Financial Services.
17
Forrester surveyed 196 enterprise architects about their use of EA modeling tools. See the May 12, 2006,
Best Practices Enterprise Architecture Modeling Tools Not Yet Ready For Prime Time.

Forrester Research (Nasdaq: FORR) is an independent technology and market research company that provides pragmatic and forward-thinking advice about
technologys impact on business and consumers. For 22 years, Forrester has been a thought leader and trusted advisor, helping global clients lead in their markets
through its research, consulting, events, and peer-to-peer executive programs. For more information, visit www.forrester.com.
2007, Forrester Research, Inc. All rights reserved. Forrester, Forrester Wave, RoleView, Technographics, and Total Economic Impact are trademarks of Forrester
Research, Inc. All other trademarks are the property of their respective companies. Forrester clients may make one attributed copy or slide of each gure
contained herein. Additional reproduction is strictly prohibited. For additional reproduction rights and usage information, go to www.forrester.com. Information
is based on best available resources. Opinions reect judgment at the time and are subject to change. To purchase reprints of this document, please email
resourcecenter@forrester.com. 41775