insight 7 Essential Elements of EA

insight
7 Essential Elements of EA
Follow this roadmap to engage your business, manage
complexity, and govern the implementation of your architecture
by David C. Baker and Michael Janiszewski
Enterprise Architecture (EA) can be either a cohesive force that binds
technology and business operations in support of strategic goals or a
misunderstood initiative that undermines the credibility of the entire IT
organization. The difference comes in successfully applying the seven
essential elements of enterprise architecture—proven principles that
should be a part of any EA undertaking.
Mention enterprise architecture (EA) to
many CEOs or CIOs, and you often get a fairly
standard set of responses:
“EA costs too much.”
“EA simply isn’t a practical exercise for us.”
“There doesn’t seem to be much benefit.”
“Our stakeholders wouldn’t use our EA if we
had one.”
Several factors keep many senior executives
from embracing the idea of EA. One reason is
that the management of information is not a
well-understood science. Even at 50 years of
age, EA still is in its infancy, and practitioners
have yet to develop common definitions,
standards, processes, or tools for managing
EA. Another reason is the organizational and
cultural barriers that block the acceptance of
EA. EA is viewed as an ivory-tower playground
for technicians or academics, so organizations
miss the message that it’s the glue that ensures
the alignment of business and technology
within the enterprise. This misconception
often arises from the pains many organizations
experience when embarking on an EA effort:
• Frameworks are often not readily
actionable (that is, they lack architectural
management concepts that are clearly
relevant to architecture delivery).
representation that is traceable, actionable,
and communicable.
• Results of the EA effort are often difficult
to communicate over the range of the
organization’s various constituencies
(for example, CIOs, business staff, and
technical architects).
In this article, we’ll describe the seven
elements that provide a roadmap for
making your EA practice an asset to your
organization. We’ll discuss them within
the context of the architecture lifecycle as
shown in Figure 1. Executed successfully,
these elements empower your architecture
organization to engage the business, manage
the complexity inherent in your information
enterprise, and govern the implementation
activities that follow your architecture effort.
• Enterprise linkages and interactions are
not well understood or documented, making
it difficult to use EA as a business enabler.
Those problems are serious, but not
insurmountable. In fact, we’ve seen numerous
companies extract real value from EA
initiatives. The chances of implementing
a successful EA effort are substantially
increased by managing the seven essential
elements of EA that occur in stages throughout
the architecture lifecycle (see Figure 1).
Managing these elements helps ensure the
organization embraces EA and can answer
the important questions, from “Why are we
building an EA?” to “How will we measure
and control the end result?” These seven
elements are essential in delivering an EA
that provides real business value. It is a
For more information contact:
Dave Baker, Partner &
Chief Architect
david.baker@diamondconsultants.com
2
Figure 1
The seven elements are:
• Set the stage with guiding principles.
• Manage complexity with blueprints.
• Organize for architecture success.
• Integrate through architecture processes.
• Keep on track with architecture
governance.
• Use tools to model, analyze, and
communicate your architecture.
• Measure architecture success with
metrics.
Engaging the
Business
Incomprehensible technical models and
arcane diagrams make it impossible to launch
a meaningful architecture discussion with
business stakeholders. That approach will
simply collapse under the weight of engaging
the business to help create such detailed
models. A better way to introduce a business
audience to EA is to begin collaborating with
business stakeholders to develop a set of
guiding principles, our first element.
Guiding Principles are a collection of
definitive statements that provide guidance
on how the organization should conduct
certain business and technical functions (see
Figure 2). They serve as filters for decision
making, eliminating possible solutions that
are not consistent with the organization’s
goals and objectives. Good guiding principles
are unlikely to change within a short-term
period, and are clear, concise, and supported
by rationale and implications developed
with business and technical staff working
together. Consensus building and alignment
are beneficial by-products of conducting
a series of structured guiding-principle
discussions. In all cases, the results serve as
guideposts for the upcoming decision making
and are a necessary tool to unite business
and technology constituencies.
The second element, blueprinting, is
the art of documenting the EA models
and standards. As in civil architecture, a
good set of blueprints helps manage the
complexity associated with ongoing repairs
and updates to intricate systems. However,
unlike civil architecture, EA does not have
a rigorous blueprinting methodology. You
can use frameworks such as the Zachman
Framework, Steven Spewak’s Enterprise
Architecture Planning, and the Federal
Enterprise Architecture Framework that
identify blueprint contents, but do not address
how to go about developing the blueprints.
Start by engaging the business stakeholders
in the development of business architecture
blueprints. Architects work closely with the
business to document the mission, vision,
goals, objectives, and business capabilities
required to enable the business strategy.
This strategic business architecture work is
led by the enterprise architect, bringing an
engineering rigor to the process. The result is
a set of linked architecture elements clearly
Figure 2
3
showing which capabilities are required to
deliver the business goals and objectives.
Furthermore, business metrics are identified
and associated with each objective,
providing a model that is used to periodically
measure the progress toward attaining the
business vision.
The business architecture also includes
an operational business architecture that
defines the key processes, stakeholders, and
interactions that are needed to implement
the business strategy. Current state and
future state versions of the operational
business architecture allow architects to
assess the impact a new strategy would
have on current operations.
4
Next, engage IT to develop the systems
architecture. The systems architecture
describes, in a platform-independent way,
the high-level applications, information,
infrastructure, and interfaces that enable
the strategic and operational business
architectures. These models are useful
for linking technical elements (such as
applications, information, infrastructure,
and interfaces) to the business capabilities.
This linkage provides a language for
discussing technology with the business—
both in terms of impact (What happens
to my technology when I change a business
goal?) as well as in terms of cost (What
does it cost to implement a particular
business strategy or capability?).
The business and systems architectures
are typically created and updated during
regular IT planning cycles. You use these
architectures to identify the IT initiatives
(and determine the funding) needed to
implement the business vision—expressed
in terms of the business capabilities, which
by now has become the common language
that binds business and IT.
The final level of blueprints is the technical
architecture, which describes the physical
implementation of the applications,
information, infrastructure, and interfaces.
The technical architecture identifies the
specific products, protocols, and wiring
schemas that guide the implementation.
Organizing
for Success
An enterprise architect requires a unique
blend of skills. At various times he or she
needs to employ the characteristics of an
artist, a guru, a coach, and a spy. As an artist,
an enterprise architect needs to be creative
by looking beyond the “right” answers to
uncover new solutions to old problems.
The enterprise architect also needs to be
a guru—someone who understands some
topics in depth, but can address a breadth
of business and technical topics.
As a coach, the enterprise architect must
bridge both business and technology, be able
to find points of influence in both camps,
and ensure that technology stays off the
critical path. Finally, as a spy, the enterprise
architect must be able to work across the
enterprise, see patterns across disparate
business needs, and define solutions that
satisfy multiple business needs. Enterprise
architects grow from within the technical
architecture ranks, learning how to be artists,
gurus, coaches, and spies as they work their
way from being technical specialists, through
application or infrastructure architects,
eventually to enterprise architects.
The third essential element of EA is
organizing for architecture success.
Architect career paths should be nurtured
within an appropriate organizational structure.
An effective architecture organization
ensures appropriate ownership of the
architecture and correct sponsorship of the
work, and provides an efficient structure for
solving problems. The organizational form
typically depends on an organization’s level
of architecture maturity. Organizations just
starting out on the EA path typically have
architects spread across various application
and infrastructure departments, providing
technical architecture services (products,
protocols, wiring diagrams).
The first step is to centralize all those
architects into an organization delivering
EA services—business, systems, and
technical architectures. This organizational
structure establishes a foundation to give
rise to EA capabilities, and allows architect
involvement in enterprise planning activities
such as business strategy development
and investment management. As the
EA organization matures, and individual
architect skills develop, the organization can
swing back to a more distributed structure.
However, this new structure should maintain
a small central group of enterprise architects
to oversee the activities of the distributed
virtual community of architects. This virtual
architecture organization works because of
the EA awareness and skills gained by the
individual architects.
Understanding the need for true architectural
processes is our fourth essential element.
Architecture processes document how
architecture design is performed and
how architecture is communicated and
implemented within an organization. They
provide the groundwork for leveraging
the architecture organization to get work
done in a consistent and effective manner.
Sample processes can include blueprinting,
integration planning, and project architecture
checkpoints and signoff (see “Controlling the
Effort,” page 7).
Architecture processes should be centrally
maintained in an easily communicable format
and accessible location. Clear, traceable
processes provide tremendous benefit to
the organization, reducing time to project
completion and setting better expectations
around what it means for an architecture
effort to be complete. Developing
architecture processes is essential to
enforcing the EA big picture, to create
architecture that concretely provides benefit
to the organization.
Physical creation of an EA requires a lot
of doing. One of the biggest challenges
5
an organization faces with regard to its
EA is writing it down. When assumptions
and tacit knowledge exist around an EA,
its capabilities as a business enabler are
severely diminished. Therefore, it is critical
that the EA is well-documented, current,
and available for use by stakeholders.
The fifth element is that you should use tools
to model, analyze, and communicate your
architecture. Fortunately, the market for EA
tools has been progressively evolving to meet
these challenges and to help the organization
do architecture. Capturing EA requires
an engineer’s rigor with the associated
representations. Many EA tools now possess
the capability not only to record and analyze
disparate information but also to import that
information for storage in a central repository.
6
These tools also provide good versioning
capabilities and recently have had an
enhanced focus on EA presentation—
ameliorating some of the need for taking
EA elements and reformatting them to make
them more consumable. With a solid EA
documented, stored, and updated within
an EA tool, business users should find
straightforward answers to questions such
as “What happens to my business if
I turn off that server right there?” or “If we
decide to expand our marketing efforts into
new territories, what information assets
can be leveraged to reduce risk and cost
while enabling greater impact and speed to
market?” An EA tool allows the stakeholder
to work with the EA in an understandable
format and to realize real benefits from the
effort to create the EA.
It is important to remember, however, that
although tools are an essential element of
EA, content is important as well. Tools are
a means of storing and working with the
artifacts created while working through the
other key elements of the EA. To record EA
information in a tool requires careful analysis
and understanding of the relationships
between the key EA elements. To do this,
the organization requires a level of maturity
regarding its development and use of
architecture before implementing an EA
tool and repository. Using an EA tool without
this maturity provides minimal benefit to
the organization.
Controlling
the Effort
With an EA effort in full swing, it is
critical to maintain alignment between
program execution and the organization’s
EA. This means ensuring that work tracks
are accomplishing what the EA describes
and that feedback loops exist for raising
architecture issues, updating the EA, and
measuring EA program success. Our sixth
and seventh essential EA elements, keeping
on track with architecture governance and
measuring architecture success with metrics,
address this need.
Separate from traditional program
management office responsibilities of
driving and measuring project progress, we
believe that architectural governance
is a key element to ensuring that the EA
vision is maintained across the enterprise.
Architectural governance refers to how an
organization makes decisions, sets priorities,
allocates resources, designates accountability,
and manages its architectural processes. The
governance body is responsible for reviewing
products produced from EA efforts to ensure
that they meet the goals of the EA (for
example, designs meet the to-be depiction
from the enterprise blueprints).
The governance body is also the forum
for raising and resolving issues through
established escalation processes, and for
providing inputs and updates to the EA.
The governance organization should consist
of a mix of subject matter experts and
senior leadership capable of representing
the organization from both business and
technical areas, and have the authority to
make architectural decisions.
Architecture governance ensures organizational
alignment and a place for the EA to remain
a living asset. It is also an ideal place to
implement our final key element—metrics.
Implementing and using architecture metrics
proactively provides the basis for demonstrating
the value of your EA. Metrics associated with
blueprints provide an ideal opportunity to
ensure program success. Good architectural
metrics provide insight into aspects of the
architecture that have meaning to the business.
For example, you can measure the EA for
the percentage of strategic capabilities that
have been realized (capabilities that are
described in the blueprints) and percentage
of existing enterprise architectural assets
reused by a program. Architectural metrics,
used in conjunction with governance, inform
strategic planning and portfolio management
programs, giving quantification to the return
on architecture assets achieved by the
organization. They are critical to articulating
the benefits of your EA effort and provide
the information necessary to help your EA
organization provide guidance to the enterprise.
Once in place, the seven elements establish
EA as a valuable asset for your organization.
Engaging business resources in guiding
principles and blueprinting activities ensures
that the downstream implementation work
delivers the business vision. Building a strong
EA organization and integrating the EA
processes in IT management activities allows
the architecture to guide investment and
implementation activity.
The payoff comes from the clear linkage of
business vision and technical architecture.
That linkage allows EA to govern
implementation activities and provides the
metrics to communicate progress toward
realization of the business goals and
objectives. The seven elements are best
when executed in concert, but do not let
that daunt you. Pick a subset of the business
strategy and get started with guiding
principles or blueprints. You will learn much
and be on the road to achieving EA maturity.
7
About the Firm
Diamond (NASDAQ: DTPI) is a premier global management consulting firm that helps leading
organizations develop and implement growth strategies, improve operations, and capitalize on
technology. Mobilizing multidisciplinary teams from our highly skilled strategy, technology, and
operations professionals worldwide, Diamond works collaboratively with clients, unleashing the
power within their own organizations to achieve sustainable business advantage. Diamond is
headquartered in Chicago, with offices in Washington, D.C., New York, Hartford, London and
Mumbai. To learn more, visit www.diamondconsultants.com.
About the Authors
David Baker is a partner and the chief architect at Diamond. As an EA knowledge leader, Dave
develops business and technical blueprints that govern strategic initiatives. Dave’s specialties
include identifying leading-edge technologies, guiding innovation projects, defining strategies
for applying technology, and leading architecture assessment and implementation efforts.
Dave has over 24 years of design, development, instructional and managerial experience in
key technologies and architectures. His experience includes mobile application architectures,
service-oriented architectures, enterprise application integration, business-to-business and
business-to-consumer e-commerce, community sites and content aggregation. He also has
experience in customer service technologies, wireless operator enterprises, communication
networks and relational databases and is a certified Federal Enterprise Architect.
Michael Janiszewski is a consultant with Diamond. He is experienced in technology-related
strategy creation, EA, architecture assessment, implementation and education, architecture
governance, program planning, and execution. Michael has worked for clients in both the public
and private sector. Michael is a certified Federal Enterprise Architect.
Suite 3000 John Hancock Center
875 North Michigan Ave. Chicago, IL 60611
T (312) 255 5000 F (312) 255 6000
www.diamondconsultants.com
© 2006 Diamond Management & Technology Consultants, Inc. All rights reserved..
Chicago
Hartford
London
Mumbai
NewnYork
Washington, D.C.