This document describes the steps involved in building an enterprise architecture. It begins by emphasizing the importance of scoping the project appropriately and getting the right team organized. This includes defining the vision and goals for the architecture upfront. The first step is to scope the project by focusing on critical and achievable parts of the architecture that can be defined within 3-6 months. A core development team of 4-6 people should then be established, led by a chief architect. An Architecture Steering Committee representing key stakeholders should also be formed to establish a shared target vision. The document outlines questions to address when forming this vision, such as key stakeholders, priority problems to solve, documentation standards, and tools to use. Getting

1. See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/3426367
Building an Enterprise Architecture Step-by-Step
Article in IT Professional · August 1999
DOI: 10.1109/6294.781623 · Source: IEEE Xplore
CITATIONS
110
READS
21,934
3 authors, including:
Some of the authors of this publication are also working on these related projects:
Geopolitical Simulation and Analysis View project
HICSS Big Data Minitrack View project
Frank Armour
American University Washington D.C.
44 PUBLICATIONS 1,573 CITATIONS
SEE PROFILE
Stephen H. Kaisler
George Washington University
106 PUBLICATIONS 1,589 CITATIONS
SEE PROFILE
All content following this page was uploaded by Stephen H. Kaisler on 22 July 2016.
The user has requested enhancement of the downloaded file.

2. July ❘ August 1999 IT Pro 49
1520-9202/99/$10.00 © 1999 IEEE
A R C H I T E C T U R E A R C H I T E C T U R E
Building an Enterprise
Architecture
Step by Step
Frank J. Armour, Stephen H. Kaisler,
and Simon Y. Liu
I
n our last article, “A Big Picture Look at
EnterpriseArchitectures”(IT Pro Jan/Feb.
1999, pp. 35-42), we made a case for estab-
lishing an architecting roadmap and urged
organizations to look at building an enterprise
architecture from a very high level perspective.
None of this is natural or easy.In fact,once you’ve
had a high-level look,the tendency is to close your
eyes and climb back down the ladder.The scenery
can overwhelm you.
When architects are at high levels, they see
more things—and everything they see they
model. This big bang approach to information
engineering is one of the main reasons many
efforts fail. If everything is important enough to
model at once,where do you begin?What’s really
the priority?
In fact, for most organizations, getting started
may be the hardest part of building an enterprise
information technology archi-
tecture (EITA). One reason is
that people have only a hazy
idea of how to use a systematic
architecting process to achieve
specific goals. The entire idea
of enterprise architecting
seems grand and out of reach,
so they feel more comfortable
chipping away at it with
patches. Unfortunately, these
patches evolve to something
only slightly more sophisti-
cated. Some efforts never get
that far. The architects get
caught in a never-ending series of analyses—
“analysis paralysis”—and end up with nothing
but a long to-do list just as the money runs out
and the CEO expects to start seeing a return on
investment.
Analysis paralysis is caused partly by not know-
ing how to scope the architecting effort.Once you
understand what you want, the process itself is
straightforward.In this article,we take you from
the start of a project to designing the target archi-
tecture. In the next article, we describe how to
plan the transition,implement and refine the new
systems,and set up an effective maintenance and
evolution strategy.
SYSTEM OF SYSTEMS DEVELOPMENT
People often ask us, “How does building an
enterprise architecture differ from building an
individual information system?”Perhaps the best
way to explain the difference is that that the
enterprise architecture is the big picture—how
major information systems across the entire
organization work together.
In that view,an enterprise architecture is a sys-
tem of systems. Each system has its own envi-
ronment of people,subsystems,and data—plus it
must work with other systems to support busi-
ness operations. This means that in addition to
traditional software development concerns,
EITA builders must define the scope and bound-
aries of each individual system, including its
major application areas and user groups.
Architects must determine what is needed for the
systems to interoperate smoothly, define infor-
Part 2 of this series shows how
to scope the project, set up the
development team, and form a
target architecture vision.
Why Use a Systematic
Process?
How Different Stakeholders
View the Architecture
What DoWe Mean by
‘Enterprise IT
Architecture’?
Resources
Inside

3. 50 IT Pro July ❘ August 1999
A R C H I T E C T U R E
mation exchange protocols, and specify any global con-
straints (the desired global level of performance or secu-
rity,for example) on the information system architecture.
This sounds like more than any one development
process can handle.And in a sense,that’s true.The process
must be flexible on many levels—flexible enough to
accommodate a range of architectures and function areas.
It must also be robust enough to handle as many itera-
tions as needed to refine activities.
The development process we created for the US
Department of the Treasury (see Figure 1), since cus-
tomized for the US Senate and the US Census Bureau,
initially handled 10 to 20 systems. But it is equally suitable
for smaller,more focused efforts such as integrating a sup-
ply chain or larger efforts such as integrating 30 to 40 sys-
tems over five years. Loops within each main activity
provide flexibility on multiple levels. For example, within
the Characterize the BaselineArchitecture step,you may
move back and forth between architectural views or tra-
verse through all the views more than once.
STEP 1: GET ORGANIZED
An EITA must accommodate both legacy and new sys-
tems. Just thinking about how to box and label all the
Characterize the
baseline architecture
Validate views
with user survey
2
Infrastructure
view
Information
view
Function
view
Work
view
Develop (update)
target architecture
3
Define target business view
Development process
planning and administration
(review boards, conflict
resolution, training,
and so on)
Define target
architecture view
Infrastructure
view
Information
view
Function
view
Work
view
Plan architecture
transistion
4
Develop individual
systems
B
e
g
i
n
m
u
l
t
i
p
l
e
l
o
o
p
s
Plan architecture
implementation
5
Initiate the process
• Scope the project
• Build the team
• Establish a target vision
1
Figure 1. Steps in enterprise architecture development.
Building an enterprise architecture
starts with the particular architectural
framework—either an existing frame-
work or some customization of a
framework you’ve created.
The first step is to get organized,
which consists of scoping the project,
setting up the development team, and
defining a target vision. The dashed
arrows represent hazy initial relation-
ships. You won’t know much about
how to implement the target architec-
ture until you have completed at least
one iteration of steps 2 through 5.
What you decide about implementa-
tion will affect how individual systems
within the architecture are developed,
and certain technology constraints on
individual systems may affect archi-
tecture implementation planning.
This is iteration at a high level. But
iteration also occurs within steps.
Steps 2 through 5 each have their own
loops. (The loops in steps 4 and 5 are
not shown because we will cover them
in the next article.) Within step 2, for
example, you may go back and forth
between two views or loop through all
the views more than once.
Through all the steps,you’ll be plan-
ning and refining the development
process, using mechanisms like archi-
tecture steering committees. You can
develop high-level views relatively
quickly to provide insight for key deci-
sion-makers, who can then focus
development on the areas with the
greatest need.

4. July ❘ August 1999 IT Pro 51
required functions can be painful.Many organizations get
mired at this stage. To avoid becoming overwhelmed,
quickly decide what you want and how much time you
have to do it. Then select people who can do just those
tasks in the time allotted.Establish a formal target vision.
Remember, the EITA demands continual refinement, so
plan to police the architecture once it’s established.
Scope the project
Always start with the doable and the critical.Aim to get
a target architecture definition in three to six months.You
can get a good idea of what parts of the architecture to
concentrate on from the results of business process reengi-
neering (BPR) and from strategic IT plans.
Look for processes that are not working well or that must
be upgraded to meet a critical business need.If a retail dis-
count store must upgrade its supply chain or develop an
Internet-based procurement solution in six
months, its focus becomes obvious. In this case,
time to market is driving the architecture defi-
nition, and this project does not need to tie up
the company’s rearchitecting specialists.
On the other hand,if you are describing a new
EITA to support the long-term growth of your
business in new geographic markets, obviously
you should spend more time on architecture
planning.
Of course, these descriptions are a little sim-
plistic. There really is no one-size-fits-all
approach to scoping an EITA project.The target
architectures differ too widely, as do the func-
tional capabilities that must be
modeled. It helps to remember
that every EITA effort has two
dimensions—depth and breadth.
If you must span a large organiza-
tion,you aren’t going to have time
to go terribly deep in specifying
your architecture. But if you only
need to revamp your e-mail and
intranet, you can go into much
more detail.
Architecting is defining what to do,not how to
do it.The how details are more of a concern when
you design the individual systems that will meet
the target vision.
Build a team
The core members of the development
team—we recommend four to six minimum—
should work on this project and nothing else.
The leader is the chief system architect. Look
for a proven leader who can overcome unfore-
seen problems and provide strong,focused guid-
ance.One of the chief architect’s most important
jobs is to help determine how the enterprise views its infor-
mation technology.Establishing this vision is key because
the rest of the team must communicate it to everyone else
in the enterprise.
In addition to system architects,the team should include
experts in the functional areas that will be affected by the
architecture. These domain experts bring specialized
knowledge to the team.With a mature application domain
or for small projects, you might need only one or two
experts.If you’re restructuring the human resources man-
agement system of a large distributed company, you need
at least four to six. For a project with 50 to 100 systems,
we’ve seen a nine-month effort involve 50 to 100 people.
Functional experts will be on the project part-time.
Establish a formal target vision
A target vision puts everyone on the same page and
Many regard building an enterprise architecture as a five-year
project, which is why commercial organizations often avoid a
systematic approach—and why frameworks and development
processes are received with more than a little skepticism. A
company may want an integrated supply chain in six months.
The architects look at the enterprise architecture framework
and development process and say,“Forget it.We don’t have time
for this.”
The truth is that, once you understand some basic activities,
a development process can be as long or short as
you want. Don’t avoid it simply because it has
steps.The existence of steps should be comfort-
ing, not intimidating.
Chances are that you’ve already built some-
thing according to a process;you just can’t define
it.You performed some set of activities, and you
got some outcome.You might have made it up as
you went along, but so what? It worked, and it
worked quickly. That’s the nature of undefined
processes; they’re great short-term fixes. But in a
few years,this ad hoc fix is going to cost your organization more
than the time it would have taken you to use a defined process.
Software developers eventually learn the folly of compro-
mising the development process after they build one too many
“perfect” systems that no one will use.And we’ve seen enough
false starts in enterprise architecting to realize that the same
rules apply to information systems: No one can build a suc-
cessful enterprise information technology architecture (EITA)
without a defined development process. There is little chance
of getting consistent results or being able to monitor progress.
And forget about improving the process itself, because, well,
how do you improve something you can’t see?
Why Use a Systematic Process?

5. 52 IT Pro July ❘ August 1999
A R C H I T E C T U R E
architecture crosses should have an ASC representative.
We will address this issue in more detail in a future article.
To form a vision, begin by asking six simple questions:
• Who are the stakeholders? List them by title and func-
tion.Briefly describe how they will use the architecture.
• What problems are to be targeted or solved at the enter-
prise level? Briefly describe the problems’ business areas
and how the solutions will affect the bottom line.Do you
makes it easier to keep the project on track.Although most
teams fully intend to develop a shared vision, they fre-
quently fail to do so—most often because they did not
involve key players.
One way to establish a shared vision is through an
Architecture Steering Committee (ASC).TheASC is com-
posed of upper-tier managers from the functional areas and
the domain experts.Typically,each organizational area the
Stakeholders How Their Views Affect the Development Process
Customers Customers pay for the effort. Their views help determine the scope of the
architecture, serve as a basis for acceptance criteria, and aid in estimating
schedule and budget as well as feasibility and risk. Customers are also interest-
ed in how the architecture will support the enterprise’s growth.
Users Users will use the systems developed from the architecture. They are interested
in how the architecture meets their needs. They help in validating its
performance, reliability, and interoperability.
System Architects create the architectural definition. They need to be able to trace
architects requirements to individual system development. They need information about
the architecture to support the trade-off analyses required to select technology.
Architects help assess the architecture’s correctness, completeness,
consistency, and coherency.
System Developers build the individual systems according to the architectural definition
developers the architects provide. They need a foundation with sufficient detail for system
design. They use the architecture as a reference for selecting and assembling
components and for assessing and maintaining interoperability with existing
systems.
System Maintainers evolve the architecture. They use it to guide system and software
maintainers modification and to assess and maintain interoperability with existing systems.
How Different Stakeholders View the Architecture
Customers,users,architects,developers,and maintainers influence the development team because each sees the
architecture differently. These views also span levels of detail. Customers want to view functions at a high level,
so the architecture must be understandable at that level.Users need only enough detail to see that the system will
work as intended. System designers need enough information to map the architecture to a system design and
implementation. Accommodating all these views often means representing the architecture in multiple ways—
high-level focused models for the customer and user; and more detailed and elaborate descriptions for the sys-
tem architects, developers, and maintainers.

6. July ❘ August 1999 IT Pro 53
need to create business processes? Fix broken ones?
Have IT advances (Web-based customer service, for
example) affected existing business processes?
• What priority does each problem have?TheASC should
prioritize problems and commit the necessary resources.
Priorities are driven by business objectives,cost,and per-
sonnel issues, such as retraining.
• What documentation and publishing standards do you
plan to use?This can be a simple list of source documents
that will dictate the common language (terminology,
packaging,and so on) the team will use to communicate
important concepts.
• What tools will you use? Once you identify them, order
them right away.
• Where will the team work? Be sure to specify any needed
training or mentoring.
Things to watch for
Making informed decisions about key issues while you’re
getting organized helps to ensure your project’s success.
Nonexperts developing the architecture. Bad architec-
tural decisions have a far greater impact when they are
made in the context of an enterprise architecture than in
the context of a single system.In the end,it will cost less to
get knowledgeable people who understand how to build an
architecture that will fit the mission.Good consultants can
help you execute the architecture development process,as
well as offer expert advice, facilitate meetings,
and train the team. They also give the project
credibility,particularly if this is a first-time effort.
Failure to establish good communication mech-
anisms. Begin the project with an agreed-on
methodology and standards.People tend to forget
“small”details like this in their hurry to get to the
problem-solving. Midway through the project,
they wonder why no one seems to be communi-
cating. Be open. Don’t hide the
architecture team away or stamp
everything confidential. Invite
participation and circulate drafts
for review and discussion.
Lack of senior management
commitment. We’ve seen ef-
forts succeed or fail on the basis
of this one issue. Architecture
building often crosses organi-
zational boundaries. The team
must be able to capture the
information they need. In a
large, distributed enterprise, this is a tall order.
Your team will need cooperation on many lev-
els, which means they need a strong champion.
If the enterprise’s senior management doesn’t
support the effort, don’t start it.
Overscoping. One of the chief causes of proj-
ect failure is overscoping so that analysis drags on for years.
Adjust the breadth or depth of your architectural effort so
you can produce concrete results in six months.
Devaluing the project. This seems obvious, but we’ve
seen projects fail because key people were put on them
part-time. Good people will always be in demand, but
defining an EITA is a full-time effort.
STEP 2: DESCRIBE WHERE YOU ARE NOW
In this step,you describe the baseline architecture—the
information systems the enterprise uses now.Many teams
try to skip this step. Don’t even think about it. You can’t
implement a new architecture without knowing where you
are now.
People have told us,“We don’t really have an enterprise
architecture.”This is a misconception.If you use informa-
tion systems,you have an enterprise architecture.You just
haven’t taken the time to formally recognize it as such.
Also, keep in mind that “enterprise” may not mean the
entire organization (see “What Do We Mean by ‘Enter-
prise IT Architecture?’”).
As you create a baseline description, you are in essence
creating an inventory of information systems and their
components and evaluating their relationships. You can
use it to identify hidden assets, gaps, and redundancies;
manage business costs; determine who is using what and
why; and classify the business assets related to IT.
We have seen the phrase “enterprise IT architecture” used
in many contexts.It can be the architecture of the entire organ-
ization,encompassing all its systems.But it can also be the archi-
tecture of a specific process or slice through that organization
(for example,a supply chain process or a com-
pany-wide intranet). In both cases, the term
“enterprise IT architecture” is valid, since the
architecture crosses multiple systems, multi-
ple departments, and functional groupings
with the organization.
The confusion comes from the evolving
nature of the term“enterprise.”An enterprise
now frequently includes the suppliers and cus-
tomers, as well as their IT assets.A good defi-
nition of “enterprise” is any entity that has a
bottom line and a set of goals to meet it.In that
sense, an enterprise can be an agency, a division, a marketing
department,or a chain of geographically distant organizations.
Thus, if the goal is to integrate a supply chain, the enterprise is
all the elements of that chain and what they require to be part
of an integrated chain.
What Do We Mean by
‘Enterprise IT Architecture’?

7. Characterize the work view
Begin by characterizing the enterprise in terms of the
products and services it offers (or produces) and receives.
By “characterizing,” we mean describing as succinctly as
possible the current state of automated support for the
enterprise’s business operations. You need only enough
detail to determine what information systems and data you
have so that you can plan what you need.
You should be able to do this in five short steps:
• Identify the relevant products and services produced or
offered within the scope of the business processes you
have defined.
• Identify the customers (clients,stakeholders) who receive
the products and services (customer service reps, the
external customers, and so on).
• Identify providers and their products and services that
are critical to the business.
• Relate customers and providers to major organization
units through their products and services.
• Identify business functions and key processes by noting
their mission and objectives and relating them to major
organizational units.
Possible sources of information are documented busi-
ness processes, department mission statements, organiza-
tion charts, strategic plans, and individual system
documents.
Characterize the function view
Next, analyze current IT applications that support the
business functions.Also, document the data and informa-
tion entities the applications use.Describe applications at
a high level, showing logical dependencies and relation-
ships among functional areas. Include each application’s
scope and interface and identify specific work groups and
application users, their relationships to information, and
their placement or possible distribution across types of
locations and technology platforms.
The result should be a high-level description—not a
specification—that you can correlate to the development
process.If the team members are not functional modeling
experts,train or retrain them in functional modeling meth-
ods, such as structured analysis or use-case modeling.
Characterize the information view
The information view describes relationships among the
information the enterprise uses.It includes all information
forms and notes how their placement and distribution sup-
port users and IT applications.The team is essentially cap-
turing the corporate data model and data dictionary,which
requires some sophistication in data or object modeling
methods, such as entity relationship (ER) or Object
ModelingTechnology (OMT). Again,take the time to train
or retrain the team.
54 IT Pro July ❘ August 1999
A R C H I T E C T U R E
The best approach is to organize information according
to architectural views,such as the ones we described in our
last article:work,function,information,and infrastructure.
(The business view covered in the last article should be
reflected in these four views.) This need not take a lot of
time. We recommend that you try to arrive at an initial
description in less than a month for smaller projects and
in one to two months for larger ones. Plan to refine the
description throughout the project as you begin to get a
clearer idea of your target.
During this step, you will be estimating the difficulty of
getting to the target vision.The results will help you gauge
progress as you transition from the existing environment
to the target architecture.Remember that successive iter-
ations are easier because the information in the baseline
architecture will feed into the new target architecture.
These books are particularly helpful during the ini-
tial development steps. For more general resources,
see our first article,“A Big Picture Look at Enterprise
Architectures,” IT Pro Jan./Feb. 1999, pp. 35-42.
➤ Building Enterprise Information Architectures:
Reengineering Information Systems, M. Cook,
Prentice Hall, Upper Saddle River, N.J., 1996:
Describes, among other things, a process for ap-
plying the Zachman framework.
➤ Constructing Blueprints of Enterprise IT Archi-
tectures, B. Boar, John Wiley & Sons, New York,
1999: Provides guidance on notations and pres-
ents detailed templates for capturing IT architec-
ture descriptions.
➤ Global Software Teams: Collaborating Across
Borders and Time Zones, E. Carmel, Prentice
Hall, Upper Saddle River, N.J., 1999: Guide to
managing and organizing teams across the wide
geographic areas.
Two articles on the Zachman framework are also
good references:
➤ “A Framework for Information Systems Archi-
tecture,” J.Zachman,IBM Systems J.,Vol.26,No.
3,1987,pp.276-292:Seminal article describing and
defining the need for EITA frameworks.
➤ “Enterprise Architecture: The Issue of the
Century,” J. Zachman, Zachman Int’l, 1996,
http://www.zifa.com/zifajz01.htm: Updated de-
scription of why frameworks are important and
their status.
Resources

8. July ❘ August 1999 IT Pro 55
Characterize the infrastructure view
Capture the information in this view by surveying the
information systems in use.The components—hardware,
software, and telecommunications—will provide enough
insight to identify the formal data stores and computer
systems available to the organization. Include current
application support and the potential for process
automation.Assess current systems’ strengths and weak-
nesses and identify the network-
ing infrastructure and topology.
The depth and breadth of the sur-
vey depends on the project scope,
but as a rule, identify and specify
the systems that execute applica-
tions for each functional area.Many
organizations do not know what
information technology they really
have or how it is used. For each
information system, you need to
know the system configuration and
its interfaces (both logical and phys-
ical) to other systems.You must also know the business oper-
ations it supports. To effectively plan the transition of a
system—either by modernizing or replacing it—you will
need to know the resources it requires.
Survey the users
Once you describe the views,you will need some meas-
ure of user satisfaction with the existing system. Review
problem area reports and correlate them with the base-
line description to identify possible focus areas in devel-
oping the target architecture. How close is the technical
quality of existing systems to the quality in the target
vision of the architecture?
Things to watch for
Watch for two common problems when you’re describ-
ing the baseline architecture.
Overuse of detail. Describe only the major functions
and interfaces for systems you anticipate replacing.
Capture detail only about legacy systems that will con-
tinue on. For these, you need enough information about
interoperability, data exchange, and how functions are
invoked to make the new systems compatible. Legacy
systems are likely to evolve with each new EITA gen-
eration, so the work you do now could save you time
later.You will also need more detail on information and
issues that cross system and functional areas.
Overmodeling. Describe current processes, work struc-
ture, information entities, and the state of automation
clearly and precisely.Quickly develop rough models of the
architectural views. Don’t spend a lot of time validating
them because you’ll be seeing them again. Capture just
enough to understand the implications of transitioning to
the target architecture,and no more.Later,when you cre-
ate the target architecture,you will return to capture addi-
tional baseline information you did not know you needed.
For now,ask these questions:Does the baseline specify the
set of functions the enterprise needs to meet its objectives?
Does it allow for the planning and execution of the infor-
mation systems development strategy? Are processes
defined from an enterprise perspective?You can be 80 per-
centaccurateandstillestablishthebaseline’sbasicstructure.
STEP 3: DEVELOP THE TAR-
GET ARCHITECTURE
The target architecture depicts
the vision of an enterprise’s future
information systems. It describes
how the systems will interoperate
to support future business opera-
tions, and it almost always repre-
sents enhancements to an existing
baseline architecture—enhance-
ments that add functions to sup-
port new operations.
To develop the target architecture, use the same archi-
tecture views you used to describe the baseline architecture
(see Figure 1).The difference is that the views should now
reflect where the enterprise wants to be,not where it is now.
The target architecture is driven by evolving business
needsaswellasbyconstraintsonimplementation,resources,
technology,and schedules.The business view becomes a key
driver. For example, the enterprise may now need shorter
business cycles.This translates into the business requirement
“Implement new services more quickly.”The corresponding
target architecture objectives are then “Make the design
modular”and“Emphasize component reusability.”
Technology is also a driver.The enterprise may want to
introduce multiple, heterogeneous solutions. This trans-
lates to the technology requirement “Meet interoperabil-
ity standards,”which produces the architecture objectives
“Use standard interfaces” and “Emphasize integrated
design and implementation.”
In step 3, you will begin to see the iterative nature of the
development process.The target architecture represents a
complex reality that you will seldom define in one pass.As
you refine it,you will see more gaps in the baseline architec-
ture.Go back to step 2 and refine the baseline accordingly.
Define the target business view
The target business view adds structure and detail to the
target vision by defining the business requirements.
However, because business requirements change contin-
ually,you are essentially capturing a snapshot.Don’t worry
about completeness at this point. Capture only as much
detail as you can build into the current iteration of the
EITA development process. Look for major changes in
strategic business objectives, new or updated services to
clients and customers, or business unit reorganization.
For each information
system, you need to
know the system
configuration and
its interfaces to
other systems.

9. requirements analysis?What design issues arose from con-
sidering the constraints on individual information systems?
Target architecture
characteristics
To meet the enterprise’s mission, the target architecture
must be modifiable, keeping pace with changes in business
objectives and operations and with the evolution of infra-
structure components. Develop metrics to monitor its
success,basing them on quality parameters or the achieve-
ment of particular functions.
The target architecture views should also be traceable.
Include a mapping of architecture
views to the business view, the
relationships among work, func-
tion, information, and infrastruc-
ture views, and how critical
business problems, architecture
constraints, and architecture driv-
ers have been ad-dressed. This
helps in explicitly describing the
relationships among components
across the views. For example, for
a location defined in the work view,
what data entities (modeled in the
information view) are used?
What functions (in the function view) are run on what
hardware platforms (in the infrastructure view)? When
developing the views, be sure to cross-reference entities
that depend on entities in another view.
Mark discontinued organizational units and locations,
replaced or eliminated functions, and old information
entities.Don’t delete them.You will need them when you
plan the architecture transition.Also,note the alternative
approaches considered when significant issues were
raised.What decisions were made and why?
Finally,the target architecture must conform to the prin-
ciples and standards defined in the architectural framework.
Things to watch for
Avoiding three common mistakes helps to ensure suc-
cess while you’re developing the target architecture.
Ignoring the business requirements. This is particularly
dangerous when legacy systems are involved (almost
always the case).Legacy systems typically have been built
in a stovepipe manner,with different technologies and spe-
cific purposes. If you create the target architecture on the
basis of these systems, it may not scale to the entire range
of systems the business requirements demand. The busi-
ness requirements drive the rest of the target architectural
views.Without evaluating the architecture relative to a set
of business requirements, you have no basis for deciding
which features in the existing systems you should preserve.
Also, creating a target architecture is a process, not an
event. Update it as business objectives change.
56 IT Pro July ❘ August 1999
You can represent the target business view in business
process models, detailed text descriptions, or BPR results.
ManyorganizationshaveongoingbusinessmodelingorBPR
efforts.Duplicate these results in your target business view.
In one large organization we consulted for,different groups
were running the EITA development effort and BPR simul-
taneously, and the groups did not talk to each other.This is
one way to guarantee that the target architecture will be out
of sync with any new business requirements from the start.
Define the other target architecture views
The target architecture is not just an update of the base-
line architecture. It is more a for-
malization of the target vision
based on the views used to charac-
terize the baseline. Update the
views from the baseline architec-
ture only as appropriate and prac-
tical to reflect the change dictated
by the target business view.
The result should be a document
that includes the architectural
overview, function area descrip-
tions, conceptual data models,
environment description, alterna-
tives, risks, and key assumptions
and rationales. It should also be enough for you to plan
and execute the development of individual information
systems.
Ask the following questions in each view:
• Work: Are there new organizational units and business
locations?Are processes defined from an enterprise per-
spective?
• Function: Does the target view completely specify the
set of functions the enterprise must implement to meet
its objectives? Have the common functions been iden-
tified?
• Information: Are applications to provide needed infor-
mation in place? Are information resources evolved
enough to satisfy the target business view? Have the
common information entities been identified?
• Infrastructure: What existing information systems will
be retained? Eliminated or decommissioned? What
information systems are to be developed? If the busi-
ness objective is to grow 20 percent annually for the next
three years,for example,can the infrastructure keep up?
You may not be able to fully capture the target infra-
structure view because technology and business conditions
change so rapidly.The idea is to present possible solutions
with sufficient clarity to let customers envision the pro-
posed solution. The target infrastructure may require
redesigning the network infrastructure.What interface and
interoperability issues were raised during the business
A R C H I T E C T U R E
The target architecture
usually represents
enhancements to an
existing baseline
architecture that add
functions to support
new operations.

10. July ❘ August 1999 IT Pro 57
Underminingstakeholderconsensus.Reachingagreement
on a target architecture definition in a large,changing,mul-
ticultural organization with competitive groups is difficult.
The larger the organization, the more difficult it will be. Be
sure to have all stakeholders validate the definition. Once
you have consensus, stick with the agreed-on definition.
Institute procedures for changing parts of it in an orderly
fashion.
Rigid representation. Multiple stakeholders must under-
stand each other when talking about architectural concepts.
A modeling approach with a formal notation and a well-
defined syntax can help, but some stakeholders may not
know how to evaluate it.To get the necessary consistency
without sacrificing understandability, use multiple repre-
sentations or relax the formality constraint.We have em-
ployed business use cases and graphical models to represent
major information entities to high-level stakeholders and
more formal object and data models to communicate with
developers.The Zachman framework provides a nice orga-
nizational structure to represent different levels.
TIME OUT
At this point, you should have defined the target archi-
tecture from four views, as well as identified key relation-
ships among those views.Take a breather and do a process
postmortem.We like to gather all key personnel in an all-
day workshop off site to informally provide feedback on the
processsofarandbrainstormnewdevelopmentapproaches.
The next step is to plan the transition from the baseline to
the target. During architecture transition planning,you will
develop a comprehensive set of project initiatives and sort
them by strategic value.The political battle is intense here
becauseallprojectsmustbecompletedandprioritized(which
is why senior management commitment is so important).
The last development step is implementation planning—
the resources you need to make the transition successfully.
But there is more to an EITA than development.Remem-
ber that an enterprise architecture is always evolving. To
keep it close to the business requirements, you will need a
plan to deal with the inevitable changes from technology,
budget, or schedule.
Next issue: How to plan the architecture transition and
implement the new architecture
Frank J.Armour is an associate research professor of infor-
mation technology at George Mason University. Contact
him at farmour@gmu.edu.
Stephen H. Kaisler is the director of systems architecture at
the Office of the Sargeant ofArms,US Senate.Contact him
at Steve_Kaisler@saa.senate.gov.
Simon Y. Liu is an assistant director of information man-
agement and security at the US Department of Justice.Con-
tact him at Simon.Y.Liu@usdoj.gov.
View publication stats
View publication stats