EA: Bringing Order to Chaos
Which Is Harder: Blueprinting Manhattan or Building an
Enterprise Architecture? Well, It Depends.
By Dennis Broderick
To reinvent themselves, support their missions, and
improve upon day-to-day operations, government organizations
are actively pursuing business transformation. This is no
trivial undertaking for government agencies with complex
enterprises, hundreds of business processes, and thousands
of systems. To ensure compliance with regulations, save
money by avoiding redundant systems, and simplify business
processes, agencies are codifying their enterprise
architecture. This is a difficult, highly dynamic process
that must take into account the scope and complexity of the
organization.
When properly developed and correctly applied, enterprise
architecture provides the means to manage complexity and
unify business operations through disciplined and logical
business change. The General Accountability Office (GAO)
defines enterprise architecture as “an organization’s
operations and systems as a set of blueprints to a
building.” It gives decision makers a single, end-to-end
framework for the business, the information/data required to
support the business, and the technologies employed to
support the organization.
On a small scale, relating an enterprise architecture to
a set of building blueprints is a fair comparison. For
larger scale organizations, however, it is more analogous to
a set of blueprints for a large city composed of many
buildings that are connected by shared infrastructure. The
failure to recognize scope and complexity can result in a
large expenditure of time and resources, producing an
enterprise architecture that has low value relative to
enabling business transformation.
To illustrate the point, consider the first step in
building an enterprise architecture. Step one provides the
“as is” enterprise architecture that baselines the business,
data, application, and technical characteristics of the
current environment. Step two provides the “to be”
enterprise architecture that defines the target environment.
The third and last step uses the enterprise architecture
information from the previous two steps to develop and
implement a transition plan to the target environment.
The following figure shows an example of a basic approach
for business transformation.
From the perspective of a large enterprise, consider the
difficulty of baselining the current environment (step one)
by applying the “as is” criteria used by GAO. To illustrate
the required level of detail needed in an architecture, the
following is one of twenty-nine criteria required for an
enterprise architecture: “a description of the data
management policies, processes, procedures, and tools for
analyzing, designing, building, and maintaining existing
databases.” Developing an “as is” enterprise architecture is
comparable to producing blueprints for each building in a
large city.
While having a set of blueprints for each building in the
city is desirable, producing blueprints for existing
buildings can be an expensive proposition. From a
transformation perspective, the value of blueprints for
buildings that are going to be replaced is significantly
lower than for buildings that are going to be renovated. A
similar value proposition exists for enterprise
architecture. Obtaining detailed information for databases
that are going to be replaced has significantly less value
than databases that are going to be modernized.
The challenge is to formulate a well-thought-out
transformation strategy that provides sufficient focus so
system value can be assessed in light of its transformation
value. Otherwise, the value proposition will be oriented
toward achieving compliance versus evaluating the value of
the system within the organization. An organization will
look good on paper—they’ll have their “blueprint”—but the
exercise won’t have improved the organization’s ability to
function, thereby negating any transformative value.
Cultivating thought leaders capable of discerning the
best path that balances compliance and function requires a
combination of value-based decision making and access to the
appropriate tools on which to base those decisions. Some
organizations have determined that the development of an “as
is” enterprise architecture is too resource intensive, so
they simply decided not do it. Other organizations have
entered into the never-ending task of defining a
comprehensive “as is” enterprise architecture.
Intellectually, “all” or “nothing” decisions are easy to
make but generally inefficient. Strong leaders will be able
to avoid both pitfalls.
While slow evolutionary change can occur bottom-up (e.g.,
technology insertion, process refinement), broad-based
change must occur top-down to ensure appropriate
enterprise-wide coordination. Large scale business
transformation is comparable to the transformation of a
large city. Uncoordinated, broad-based changes in one area
of a city, such as re-routing traffic patterns, can result
in chaos in other areas of the city. Major transformations
will take many years, so long-term thinking is needed. Also,
changes to infrastructure are expensive; long-lead items
that must be handled carefully or business operations can
come to a grinding halt. Consider the impact when a major
road or bridge shuts down without appropriate contingency
planning.
Creating a Blueprint for an Enterprise Architecture
Successful enterprise architectures are created through
careful planning and unflinching focus on the short- and
long-term goals of the project. Inevitably, transformation
needs will exceed available resources, so by following a
realistic blueprint, organizations can obtain high value for
every dollar spent. Funding unfocused projects such as a
comprehensive “as is” enterprise architecture can be
expensive. At the same time, not collecting the information
needed for sound value-based decisions results in poor
decision making. Careful planning and sound decision making
in the face of obstacles exponentially increase the
likelihood of success.
As part of the planning, organizations must clearly
identify the start and end points of the transformation. The
“as is” portion of the top-level architecture provides a
conceptual depiction of the capabilities, constraints, and
deficiencies of the current environment. For example, it
contains a conceptual view of the current data environment
as opposed to a detailed description of each database. This
provides the architect with an understanding of the
available assets, their strengths, and their weaknesses. The
“to be” portion of the enterprise architecture provides a
top-level conceptual depiction of target environment to
include analysis of alternative concepts and their costs.
This provides enterprise architects with a clear
understanding of the direction in which they are heading.
Organizations must formulate the overall transformation
strategy incorporating strategic elements important to
successful transformation. There are many elements to
consider in the journey from the “as is” architecture to the
“to be.” Examples of strategic elements to be considered
are: the priorities for and goals of the transformation; the
governance structure that will be used, including investment
controls and risk management; the management tools and
performance measures; the change management and
communications strategy; the continuity of operations plan;
the acquisition strategy for obtaining resources; and the
transition increments that will be implemented across the
organization.
By incorporating these elements into the planning,
organizations can better ensure that their transformation
strategy will be sufficiently complete and cohesive.
However, this alone cannot guarantee success. Organizations
must also factor in the distributed power base of
organizations.
For example, it’s not uncommon for large, complex
enterprises to have federated governance structure. The
governance structure for the Department of Defense (DoD) is
high federated with the power-base distributed across many
organizations. A strategy within DoD to centralize
architecture would not be cohesive given its federated
governance structure. On the other hand, a strategy to
centralize DoD governance is not grounded in reality, given
that it would be extremely political and literally take an
“act of Congress.”
By factoring in the political environment, the available
tools, and all relevant governance structures, organizations
can avoid many of the problems created when an architect
hands over the blueprint to a contractor for building.
Anyone who has worked in construction laments the disconnect
between the ideas created by an architect and the reality of
construction sites. Some designs simply are not feasible.
Only by closely coordinating the efforts of the architect
and the contractor can a project be completed without
significant delays and increased costs. This scenario holds
true for enterprise architecture initiatives as well.
Building an Enterprise Architecture from the Blueprint
An effective enterprise architecture plan not only
includes the “as is” state and the “to be” state of the
enterprise; it also outlines how to get from beginning to
end through a series of incremental steps.
The transformation strategy defines the logical sequence
of transition increments that will be implemented to
transition to the target environment. Using a large city as
an example, the transition increments specify which parts of
the city are going to be transformed in what sequence.
In implementing an enterprise architecture, each
transition increment brings new capabilities of value,
providing a strong foundation for future increments. It’s
important to be aware, however, that processes often become
destructive when each new increment breaks the capabilities
provided by preceding increments. A well-thought-out
transformation strategy is the insurance policy for ensuring
a constructive incremental process. Organizations need to
fully understand how a new process will impact what is
already installed and working, and if there is a disconnect,
there needs to be a bridging strategy.
In reality, there is always going to be some level of
destruction associated with incremental change. The question
is how much. If you examine the enterprise resource planning
(ERP) solutions being implemented today, they have
destructive tendencies where major version upgrades require
significant rework to the surrounding support environment.
Alternatively, custom solutions have a long history of
delivery slippages and cost overruns. Assume that the path
forward will inevitably involve steps back, but manage them
aggressively.
Prior to implementation, the near-term transition
increments require an additional level of focused planning
and analysis to specify the initiatives that will be
implemented in support of the near-term transition
increments. This involves aligning management, capabilities,
schedules, milestones, dependencies, performance measures,
funding, etc. to ensure complete and coherent
implementation. Sometimes incorporating low risk, quick wins
into the early phases of implementation provides thought
leaders with additional time to more thoroughly define and
vet the transformation strategy and reach agreements on the
initial transition increments. It also increases the
likelihood of organizational buy-in.
Complicated? Yes. Impossible? No.
Enterprise architecture initiatives will help
organizations run more effectively. Streamlining the
architecture, however, is no easy feat. Enterprise
architecture is an important transformation management tool
that can be adapted to fit the size and complexity of an
enterprise. However, doing so requires a well-thought-out
business transformation strategy.
Though it’s tempting to be dragged down by analysis
paralysis, it can be done. No enterprise architecture is
perfect, and improvements can be made over time. In much the
same way a city is built over time yet has to be managed as
a single whole, so must organizations. Though there are
countless factors that weigh into each decision, and
mistakes will be made, by spending the time necessary to
analyze the current situation and to visualize the ideal
state, organizations can make enormous strides forward.
Dennis
Broderick has more than twenty-seven years of
experience providing business transformation, enterprise
architecture, program management, and system engineering
services. He is an executive vice president at EM&I and
performs the role of senior consultant on the DoD
Business Management Modernization Program (BMMP), one of
the largest business transformation initiatives ever
undertaken. His experience includes strategic planning,
organizational transformation, performance measurement,
program control, and architecture development.
