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 READS

79 3,142

3 authors, including:

Frank Armour Stephen Kaisler

American University Washington D.C. George Washington University
35 PUBLICATIONS   916 CITATIONS    89 PUBLICATIONS   905 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Big Data and Analytics View project

Parallel Architectures Workshop View project

All content following this page was uploaded by Stephen Kaisler on 22 July 2016.

The user has requested enhancement of the downloaded file.

 Part 2 of this series shows how
to scope the project, set up the
development team, and form a
target architecture vision.
Frank J. Armour, Stephen H. Kaisler,
and Simon Y. Liu
ARCHITECTUREARCHITECTURE
Building an Enterprise
Architecture
Step by Step
I
n our last article, “A Big Picture Look at
Enterprise Architectures” (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
Inside that people have only a hazy
idea of how to use a systematic
Why Use a Systematic architecting process to achieve
Process? specific goals. The entire idea
of enterprise architecting
How Different Stakeholders seems grand and out of reach,
View the Architecture so they feel more comfortable
What Do We Mean by chipping away at it with
‘Enterprise IT patches. Unfortunately, these
Architecture’? patches evolve to something
only slightly more sophisti-
Resources cated. Some efforts never get
that far. The architects get
1520-9202/99/$10.00 © 1999 IEEE
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-
July ❘ August 1999 IT Pro 49
 ARCHITECTURE

Figure 1. Steps in enterprise architecture development.

Building an enterprise architecture
starts with the particular architectural
1 Initiate the process
2 Characterize the
baseline architecture
framework—either an existing frame-
work or some customization of a
Infrastructure Function framework you’ve created.
• Scope the project view view
The first step is to get organized,
• Build the team which consists of scoping the project,
• Establish a target vision Information Work setting up the development team, and
view view
defining a target vision. The dashed
Validate views arrows represent hazy initial relation-
with user survey ships. You won’t know much about
how to implement the target architec-
ture until you have completed at least
s
op
le in
lo
tip g

one iteration of steps 2 through 5.

ul Be

What you decide about implementa-

m

tion will affect how individual systems

within the architecture are developed,
5 Plan architecture
implementation 3 Develop (update)
target architecture
and certain technology constraints on
individual systems may affect archi-
Define target business view tecture implementation planning.
This is iteration at a high level. But
iteration also occurs within steps.
Define target Steps 2 through 5 each have their own
architecture view loops. (The loops in steps 4 and 5 are
Infrastructure Function not shown because we will cover them
view view in the next article.) Within step 2, for
example, you may go back and forth
Information Work between two views or loop through all
Develop individual view view
systems 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
Development process develop high-level views relatively
planning and administration quickly to provide insight for key deci-
(review boards, conflict
resolution, training,
and so on)
4 Plan architecture
transistion
sion-makers, who can then focus
development on the areas with the
greatest need.

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 Baseline Architecture 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

50 IT Pro July ❘ August 1999

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

July ❘ August 1999 IT Pro 51

 ARCHITECTURE

How Different Stakeholders View the Architecture

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.

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.

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).The ASC is com-
posed of upper-tier managers from the functional areas and
the domain experts.Typically, each organizational area the
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

52 IT Pro July ❘ August 1999

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

July ❘ August 1999 IT Pro 53

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

July ❘ August 1999 IT Pro 55

 ARCHITECTURE

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

56 IT Pro July ❘ August 1999

 Undermining stakeholder consensus. Reaching agreement
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
process so far and brainstorm new development approaches.
View publication stats
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
because all projects must be completed and prioritized (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 of Arms, 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.
July ❘ August 1999 IT Pro 57