Enterprise Architecting: Critical

Problems

Abstract
An enterprise architecture (EA) identifies the main
components of the organization, its information
systems, the ways in which these components work
together in order to achieve defined business
objectives, and the way in which the information
systems support the business processes of the
organization. The components include staff, business
processes, technology, information, financial and other
resources, etc. Enterprise architecting is the set of
processes, tools, and structures necessary to implement
an enterprise-wide coherent and consistent IT
architecture for supporting the enterprises business
operations. It takes a holistic view of the enterprises
IT resources rather than an application-by-application
view. Given the size and still immature nature of many
enterprise architecture efforts, a number of critical
challenges and problem continue to exist. This paper
surveys a number of these challenges and problems in
an attempt to provide a platform for a discussion on
enterprise architecture problems and possible solutions.

1. Introduction
In previous papers (Armour 1999a, Armour 1999b,
Armour 2001), we described a framework and a
methodology for enterprise architecting based on work
we performed for the Department of the Treasury. In
(Armour 2003, Kaisler 2003 and Valivullah 2003) we
described how this methodology was applied to a small
organization the U.S. Capitol Police (USCP). It has
also been applied to the Architect of the Capitol (AOC)
and the U.S. Senate.
The Office of Management and Budget (OMB), in
Circular A-130, asserts: An enterprise architecture is
the explicit description and documentation of the
current and desired relationships among business and
management processes and information technology.
We see enterprise architecting as the scaling of system
architecting to the enterprise - to a system of systems.
The benefits of enterprise architecting have begun to
prove themselves: faster, better, and cheaper. But, these

benefits come at a price. The organizational, cultural,

and technical infrastructure require investment to
support the architecting processes. Based on our
experience, and discussions with other enterprise
system architects, we have identified a set of
challenges that every system architect and organization
developing an enterprise architecture is likely to face.
These challenges are rarely technical, but arise from
political, project management, and organizational
issues and weaknesses.
Note on convention: The use of the term enterprise
architecture has been taken to mean both the
descriptive documents and the actual implementation.
In order to minimize confusion, we will use the term
enterprise architecture to refer to the documentation
and the word architecture to refer to its
implementation.
2. Motivation
There are three areas where critical problems arise in
the process of enterprise architecting: modeling,
managing, and maintaining EAs.
Modeling is essential to describing and understanding
an EA. There are three reasons to model: (1) to
visualize the EA, its evolution, and its generational
impact on the existing architecture; (2) to depict to
stakeholders the control and data flow through the
architecture; and (3) to conduct end-to-end
performance analyses. We found that selecting an
appropriate framework and choosing a model to be the
most difficult, but critical, tasks. It required significant
time and effort to choose a suitable model. Because an
enterprise architecture is strategic in nature, once a
model has been chosen and developed, it will be a
difficult to change it in the middle of implementation.
Management is essential to developing and deploying
an EA. Typically, large organizations will have
multiple ongoing projects that are remediating,
renovation, or replacing information systems as well as
developing new systems. Many of these projects are
conducted on varying schedules. The challenge to the
system architect is multifold: (1) coordinating
schedules to ensure interdependencies mesh; (2)
ensuring intersystem constraints at the interfaces are
resolved; and (3) ensuring interoperability at the
syntactic and semantic interactions between
information systems.
Maintenance is essential to an EA because operational
consistency must be preserved while the organization
continues to evolve the architecture. Deploying
enhanced or new systems should not impact day-to-day

operations, so careful scheduling and integration of

changes to the architecture is required.
The next three sections of this paper identify some of
the critical issues in enterprise architecting that must be
addressed through both research and practice.
3. Modeling Enterprise Architectures
EAs need to be modeled at two levels. First, they must
be described in a way that provides a clear, coherent,
concise picture of what the EA is and is to be, e.g.,
both the baseline and the target need to be modeled.
Second, at the enterprise level, stakeholders need to
understand the data and control flow issues and the
decisions that will impact end-to-end performance.
Arguments regarding over which model is right,
which notation is right, and which paradigm is
right are relatively meaningless if the model cannot be
understood by the stakeholders. A system architect can
create a perfect EA model but it doesnt matter if
project teams cant or wont take advantage of it. The
EA must be good enough, but does not need to be
perfect. During project development, it is likely
incremental changes to the EA will occur as the project
teams design, develop, and implement systems and
applications.
3.1 Business View Representation and Alignment
The business view of an EA is a non-IT description of
the business operations, processes, and data required to
operate the business. Business modeling requires two
elements: business events and business processes.

Business events act as triggers to initiate business

processes. Business processes must be modeled across
the organization. Depending on the degree of modeling
desired, the following are some of the key questions
that need to be answered by the business model:

We refer to this activity as architecting at the

boundaries. The interface between the end user and
the enterprises information systems is just as
important as the network protocols that transfer the
data from location to location. The environment
presented to the end user, whether static or dynamically
modifiable, is critical to the end users performance of
tasks in support of the business operations.
3.2 Limited Modeling Tools
The ability to model and align business operations and
processes is lacking. Business processes drive
architectural decisions and weave a thread through the
architectural views. Business process owners need to
see how their requirements are met across multiple
information systems.

Figure 1. Business Process Thread

Business processes must be modeled and aligned
across functions, data and information systems that will
implement the processes. And, ultimately, must be
mapped to the underlying infrastructure where the
rubber meets the road. Alignment

Encompasses the organizations

mission, vision, business drivers,
strategic goals, strategic business

What are the key business operations for the

organization?
What organizational units are responsible for
those business operations?
Who (role or organizational unit) performs a
business process?
What business processes comprise a business
operation?
Where, geographically, are organizational
units located?

objectives, information needs, IT

vision, IT mission, IT objectives, and
guiding architectural principles.
Ensures that the mission, business
processes and priorities drive system
development.
Maps IT development to stakeholder
needs and target business processes.
Ensures the business vision provides
the basis/foundation for the entire
enterprise architecture.

Requires the business view, which

used as a guidance tool, remains
relatively stable over time.

Figure 2 below highlights some of the critical entities

that need to be aligned throughout the enterprise
architecture development. Currently, there is minimum
tool support to track and maintain this diverse
collection of entities.

Strategic
Goals and
Objectives

Office and
Bureau Goals
and Objectives

IT Goals and
Objectives

Stakeholders

Data

Business
Process and
Use Case
Models

Interfaces

Security

Performance Measures

Business
Process
Descriptions

specific databases, while a sales executive may be

focused on the location and movement of data through
multiple information systems. Business executives are
often more interested in seeing how information flows
through the organization and which high-level
information systems and applications support the
business operations.
An EA needs to be simple enough for everybody to
understand and get the gist of which system connects to
which system, where applications reside, and how data
and control flow through the system. Complex
diagrams should be relegated to individual projects.
Simple diagrams are easier to change. During the
enterprise architecting process, changes and updates
are likely to occur quickly until the EA is stabilized for
a particular iteration. If decisions about components
and their interrelationships are uncoordinated, ad hoc
or localized, the result is likely to be duplication of
effort and resources, poor coordination and control,
problems with management and business performance,
inability to share important resources such as
information, and inefficiencies in operation.

Applications

Technology Infrastructure and Services

Figure 2: EA Alignment Map

When defining the alignment map, care should be
taken to:

Define the entities to align

Define the attributes of entities
Define the alignment links
Reference the appropriate documents that
contain the specific entities

Many current modeling tools, such as Rational Rose,

are oriented to modeling software architectures. In
Armour et al (Armour 2003), we showed how to begin
to adapt UML to model EAs. Because EAs are systems
of systems, there is an emphasis on a higher level of
conceptual modeling. Additionally, business operations
and processes must be integrated into the model. While
there are a number of tools such as Metis, Popkins SA,
Troux, Orbus, and Casewise Corporate Modeler, etc.
that are beginning to address these issues, a wellintegrated solution is not available at this time.
3.3 Stakeholders Perspectives
Different stakeholders require different perspectives
through the EA views. A database administrator, for
example, may focus on the structure and location of

Stakeholders may be other Federal agencies as well.

The Office of Management and Budget (OMB) has
developed the Federal Enterprise Architecture (FEA)
as a business-based framework for the federal
government. The FEA goal is to facilitate interagency
analysis, identify duplicate investments, gaps and
provide opportunities for collaboration within and
across federal agencies. The FEA models enterprise
architecture as 1. Performance Reference Model, 2.
Business Reference Model, 3. Service Component
Reference Model, 4. Data and Information Reference
Model and 5. Technical Reference Model.
3.4 Representing Dynamics
A major weakness of many current modeling tools is
representing system dynamics. Yet, this is essential for
estimating the end-to-end performance of an
architecture for different business processes. At the EA
level, such estimates must necessarily be coarse, but
system architects need to know the order of magnitude
of the processing time for different business processes
to both establish and verify performance requirements,
but also to assess how architectural changes affect the
EA. A mechanism is needed for calculating and/or
associating performance data with EA elements.
Major research questions include:

What is the best mechanism for representing

system dynamics in an enterprise architecturemodeling tool?
What constructs or artifacts should be
modeled in evaluating the dynamics of an
enterprise architecture?

4. Managing Enterprise Architectures

Implementing an EA requires strong program and
project management expertise along with an IT
portfolio management process, while maintaining the
architecture requires a robust change management
process and procedures. Additionally, EA management
requires emphasis on the ilities of system
engineering.
4.1 Managing the Integrated Enterprise Life Cycle
Most enterprise architectures are built on top of legacy
systems, e.g., there are no green fields. Once the
enterprise architecture is specified by the system
architect, individual components of the EA that are to
be remediated, renovated, or replaced, or developed
anew are often turned over to one or more project
managers. Typically, these project managers do not
report to the system architect. Two key issues arise:
(1) what oversight authority does the system architect
have over system development projects, and (2) how
are project management decisions assessed against the
enterprise architecture. Enterprise architecture is
ss
B usine s
Need

The
Enterprise
Life Cycle

Capital
Planning
Investment
Control

Systems Migration
Enterprise
Architecture

Modernization

Operations & Maintenance

H
Ca uma
pi n
ta
l

Enterprise
Engineering
&
Program
Management

ity
ur
Sec & cy
a
iv
Pr

closely linked to other major disciplines in what we

refer to as the enterprise management lifecycle, as
depicted in figure 3.
Figure 3: The Integrated Enterprise Life Cycle
Lets address issue 2 first. Decisions regarding the
ownership of enterprise IT resources and the

responsibility for managing and integrating new

resources into the enterprise architecture are an issue of
IT Governance. IT Governance must have the support
and authority of the organizations executive
management if it is to succeed. Most organizations will
create a cross-organization architecture board,
representative of all stakeholders, whose purpose is to
oversee the implementation of the EA according to the
established architectural principles.
Issue 1 derives from issue 2. In many organizations, the
system architect reports to the architecture board and
may be an ex officio member. The system architect
operates with the authority of the architecture board in
most day-to-day decision-making. He must possess the
political and business acumen necessary to know when
to promote issues for the architecture boards
consideration.
Together, the architecture board and the system
architect establish the architecture compliance process.
The system architect analyzes, designs, reviews,
assesses, and proposes EA changes to the architecture
board, which must approve them. Architecture
compliance involves having the authority to ensure that
individual projects hew to the EA and the established
architectural principles.
4.2 Assess Technical Architecture Maturity
The foundation for an enterprise architecture is its
technical infrastructure. During the architecture
transition planning phase, the system architect must
assess the maturity of the technical infrastructure to
determine whether it can support the proposed
enhancements to the enterprise architecture. Several
models have been proposed for assessing technical
architecture maturity. Gartners (James 2002) model
proposes five levels of maturity: chaotic, reactive,
proactive, service, and value with associated
descriptions.
Some key questions that need to be answered here
include:

What elements should a canonical maturity

model encompass?
What figure of merit should be used for
assessing overall technical maturity as a
composite of the maturity of individual
elements of the technical architecture?
How can/will the technical architecture
maturity model be used in evaluating the EA
maturity model?

& portfolio management, faster time to market

of news services and products, etc.

4.3 Assessing Infrastructure Stress

Every modification to an enterprise architecture
introduces change to the underlying technical
infrastructure, whether new hardware, software, or
telecommunications platforms, or just parametric
changes. Individual project managers may understand
the impact of such changes on local platforms, but
often do not understand the impact of changes on other
platforms. Change induces stress in an architecture.
Some key questions that need to be answered here
include:

What is the measure of stress on the

technical infrastructure?
How do we measure and assess stress on
the infrastructure?
How do we determine if specific changes
will break the architecture?
How does the system architect use this
measure (and others) to predict when
something will break as a result of
changing the technical architecture?

4.5 Virtual Enterprises

Virtual enterprises are dynamic entities that seek to
create transparency of services location and often
involve multiple organizations. Typically, a virtual
enterprise arises from B2B collaboration. Several
issues arise from virtual enterprises that require the
system architect to proactively plan for their
implementation:

Developing
semantic
standards
for
interpreting exchanged information
Establishing security in a multiparticipant
environment
Lack of centralized control

Because virtual enterprises are very dynamic, they are

not easily represented in existing tools. We need to
determine canonical methods and mechanisms for
representing virtual enterprises.

4.4 The System Architects Value Proposition

4.6 Evaluating EA Maturity

Many executives continue to see the system architect

as a non-revenue producing expense. Developing the
value proposition for a system architecture group is
difficult in an organization that is used to making
reactive, rather proactive decisions.

A continuing problem is how to assess an enterprise

architecture: (1) what are the characteristics of a good
EA and (2) how does an organizations EA match those
characteristics. Based on our experience, we suggest
the following:

The Federal Government mandated the need for

enterprise architectures in OMB-97-16, IT Architecture
Guidelines. They asserted that large IT investments
would be evaluated against enterprise-wide IT
architectures. The Clinger-Cohen Act (Information
Technology Management Reform Act of 1996)
mandated the appointed of a Chief Information Officer
(CIO) who will develop an IT strategic plan, develop
measures for assessing performance against that
strategic plan, and report regularly to Congress on IT
performance. The CIO is responsible for the EA. These
documents mandate, but do not justify the role of the
system architect.
Two challenge here are:

How does the system architect contribute to

the bottom line?
How does the system architects activity
reflect itself in improved productivity, better
end-to-end performance, better IT investment

The EAs boundaries are welldefined

EA elements have clearly assigned
responsibilities
Interfaces, formats, and protocols
between EA elements are welldefined; alternatively, every interface
supports only approved formats and
protocols
An external auditor adequately
documents the EA to permit
compliance review and assessment.

The U.S. Government Accounting Office (GAO 2004)

has released a framework for assessing and evaluating
enterprise architectures. A high-level view is depicted
in figure 4.

Irrelevant

Consistent

Figure 4. High-Level of GAOs EAMMF.

Compliant

The EAMMF provides five levels of EA maturity:

1.
2.

3.

4.

5.

Creating EA Awareness: An organization

has no documented EA, no plans to develop
one, and no commitment to the EA process.
Building the EA Management Foundation:
The organization has designed a Chief
Architect, selected a framework, set up a
staff and steering committee, and selected a
process.
Developing EA Products: The organization
has committed to the EA process and begun
developing baseline and target architectural
documents and a transition plan.
Completing EA Products: EA products,
include the baseline and target architectures
are complete and being used to decide IT
investments.
Leveraging the EA To Manage Change: The
EA continually evolves and is used across
the enterprise for IT decision-making.
Metrics are established to assess its
effectiveness

While the EAMMF provides some guidance on how to

assess an EA methodology and framework, we feel
that more detailed procedures must be defined and that
these must be correlated to the domain.
4.7 Assessing the Enterprise Architecture
The previous section identified the stages of EA
process maturity, e.g., how well an organization is
evolving in its pursuit of creating, managing, and
maintaining an EA. The Open Group has developed a
six-level model for assessing how an architecture
conforms to its EA. (Open Group 1999) Table 1
depicts the six levels.
Table 1. Open Group EA Conformance Model
Level

Description

Conformant

Fully Conformant

NonConformant

The architecture shares no

features in common with the
EA, so assessment is not
possible or feasible
Some features of the
architecture conform to the
EA; some are not implemented
(yet), and the architecture may
have features not specified by
the EA (legacy features, for
example).
Some features are not yet
implemented, but all features
are specified by the EA.
All features specified in the
EA are implemented, but
additional features are present
not specified in the EA.
There is full correspondence
between the architecture and
the EA. No features are
implemented that are not
specified by the EA.
Any of the above in which
some features specified in the
EA are not implemented.

4.8 Scalability
We consider a system to be scalable if there is a
straightforward way to upgrade the system to handle an
increase in interactions while maintaining a
consistently acceptable level of performance. By
straightforward we mean that no architectural changes
are required to scale the system. A nave application of
this concept to an EA would suggest that we just
increase the capabilities of individual systems in the
architecture or increase the number of some types of
systems. For example, to handle more front-end
transaction in a stock-trading system, we should be
able to increase the number of front-end servers
servicing end users.
From
parallel
processing
applications
and
benchmarking studies, we know that throwing more
iron at a problem only works so well. Ultimately, the
complexity of the number of interactions engendered
by the increased platforms obviates most performance
gains.
4.9 Enterprise Architecture Metrics

Currently, there is very little guidance on metrics that

can be captured to help assess the EA. A possible set
of metrics, includes, but is not limited to:

Annual update to Enterprise Architecture

(completed/not completed)
Percent of systems compliant with Enterprise
Architecture
Number of exceptions and variations to
Enterprise Architecture
Number of concepts and business cases
reviewed for EA compliance (including pass,
update and fail discussion)
Number and outcome of EA reviews on
ongoing efforts
Number of changes proposed to EA
Number of changes accepted

We need to extend our collection of best practices with

good examples of where they did/didnt work and why,
and process/procedure descriptions that underlie the
best practices so that they can be reused effectively.
5. Maintaining Enterprise Architectures
Once an enterprise architecture is described and
implemented, the organization faces several problems
in maintaining it. Because most EAs evolve from
existing architectures, these exists a tension between
the continuing operations and the introduction of
enhanced or new systems. Three key principles that can
mitigate some of the risk and difficulty associated with
architecture maintenance are:

4.10 Best Practices

There are many bets practices that have been

enumerated in the technical literature. We need a
method to validate and verify qualitatively, if not
quantitatively that these are best practices.

Some best practices that we find useful, but which we

feel need substantive verification rather than just word
of mouth acclamation include:

Start small and grow the EA slowly.

Train employees or hire contractors to transfer
knowledge.
Provide encouragement and resources.
Have a good change or configuration
management plan in place.
A good capital and investment management
plan and an Investment Review Board (IRB)
that requires compliance with EA are
prerequisites for good EA management
practice.
Use appropriate tools to maintain the EA. The
most expensive is not necessarily the best tool.
Each EA is unique. They all have common
processes and principles. Include entities that
make sense to your business environment.
There is no cookie cutter approach.
Scan the EA of similar organizations like
yours.
Reuse principles, process and
artifacts.
Modify to suit your enterprise.
Do it if it makes sense.
Fancy artifacts (pictures, graphs, documents,
etc.) do not necessarily equate to better EA.

Design and build the architecture to

change, not to last.
Using the 80/20 principle, build only
what you need to.
Be prepared to rapidly change what
you have built in response to changing
business requirements.

Maintaining an EA has been given little attention in the

technical literature. As more EA efforts become fully
engaged, we need to identify best practices in support
of maintaining an deploying EAs.
5.1 Continuing Technical Innovation
Technology continues to evolve at a rapid pace. A key
question for the system architect and for IT operations
is how fast should the organization refresh its hardware
and software platforms. This question cannot be
answered on purely technological grounds as we have
found out in building the Senates Alternate Computing
Facility. Successive generations of servers have
steadily increased their power requirements. This
necessitated redesigning and upgrading the power
backup capabilities of the facility to accommodate the
increased power requirements of new servers.
Technology refreshment is often a resource issue. How
often you refresh may depend on:

The available funds to purchase new machines

and software versions
The time required to update applications to
make use of new features,
The installation/deinstallation costs,

So, some questions to be answered include:

How often should the technical

infrastructure be refreshed (as a best
practice)?
Should
technical
infrastructure
refreshment be treated as a project
within the EA?

Mobility represents a particular challenge to system

architects. As Hayward (Hayward 2002) notes,
Mobility is not an add-on to existing architectures; it
is a profound disruption. As computers (PDAs,
laptops) become more powerful, services become more
mobile. At a minimum, network connectivity is broken
and re-established, especially if it is based on cellular
technology.

5.2 Evolving Business Models

Business models continue to evolve rapidly even as the
dotcom era has come and stabilized. Organizations
continue to develop and deploy web-based portals for
doing business, only smarter. However, the richness of
the Web has yet to be fully exploited and this is leading
to new business models, including virtual enterprises.
These business models have an impact on EAs because
they may require rapid deployment (or redeployment)
of new platforms and services.
The Internet changed the way we communicate, the
way we do business (but, not as much as we originally
thought), and the way we locate and access
information. In many cases, it has effectively washed
away the boundaries of whats inside and outside of a
business. One of the continuing challenges facing
business executives is the movement towards an
eBusiness model while continuing to maintain a brickand-mortar local presence. Successful firms will
balance these two business models. Few companies
will be as successful as Amazon in establishing an
eBusiness presence.
Time to consumer is a critical metric. eBusinesses
must ensure that they can provide the information to
their customer base, but also deliver the goods when
orders are placed. This end-to-end model order to
picking to delivery to billing to receivables is a
primary performance metric for assessing an enterprise
system architecture. Many organizations will form
strategic alliances with new eBusiness service
providers as opposed to building their own eBusiness
IT services. Coordinating multiple e-business
initiatives is extremely complex. The infrastructure
must now support multiple tiers and multiple points of
integration. This requires integrating Internet
applications into an enterprises infrastructure and
implementing advanced functionality into its
applications. As a result, the enterprise system
architecture for eBusiness is much different from that
of five years ago, and must be developed and deployed
while maintaining the existing IT infrastructure.
5.3 Mobility

5.4 Integrity
The integrity of an EA is a measure of compliance with
the EA as information systems are remediated,
renovated, or replaced. Measuring integrity is a
difficult problem. We need to define whether the
measure is discrete or continuous. The integrity of the
architecture fails for a number of reasons, including:

Project teams dont know the EA exists or

dont understand it
Project teams, deliberately or not, dont follow
the EA
Project teams dont coordinate and collaborate
with the system architect
Although EA processes are followed, too
many waivers are granted.

A different type of integrity challenge arises from the

ubiquity of the Web. To many users, their business
environment includes direct access to the Internet.
However, this causes significant problems for system
architects and security personnel alike.
At many organizations, a standard desktop image is
provide each user upon delivery of a new workstation.
This image contains all of the tools and utilities the
organizations feels the user needs to be productive
within the corporate community, to communicate with
others, and to accomplish their jobs. Internet
accessibility poses a direct challenge to the users
environment, including:
1.

2.
3.

a user may download programs from

the Internet that have not been
approved by the central IT
organization
a user may download and install
updates that have not been approved
a user may establish links to other
organizations
that
provide
backchannels and conduits that
enable security attacks

The user may become dependent upon individually

acquired programs and tools that do not have central or
even contracted support. When mission-critical
functions become dependent upon such tools, the
organization risks serious impact to operation and
performance if the tool fails, the vendor goes out of
business, or the user leaves without training another
user. Enterprise system architects must recognize these
challenges, must develop a strategy to accommodate
them (or not), and must ensure throughout that the
integrity of the architecture is maintained.
5.5 Security
Security is a major concern in building an EA. The
system architects need to take into consideration the
Confidentiality, Integrity and Availability (CIA) of the
systems and infrastructure. Information security
architecture is an integral part of EA, providing
security from the perimeter to the core. A defense in
depth strategy works well based on the CIA analysis
of individual systems and general support systems. For
federal agencies, Federal Information Security and
Management Act (FISMA, 2002) mandates
information security. NIST Publications 800 series
(NIST-PUB 800-XX ) provides guidelines on assessing
and implementing information security guidelines.
Based on CIA analysis, systems are classified at three
levels namely high, medium and low security systems.
This classification dictates the minimum required
protection needed for that particular system.
6. Conclusions
We have described a set of problems that affect the
enterprise architecting process based on the lessons we
have learned over the past five years. We feel that these
problems as well as others will need to be identified,
discussed, debated and resolved by both the academic
and practitioner communities in order for the enterprise
architecture discipline to continue to grow and evolve.
This paper is a start in the effort to systematically
identify these issues.
Organizations need to have clear, but concise, strategic
plans for business and IT. The business strategic plan
becomes the driver for the EA. The EA becomes the
DNA or the Rosetta Stone for the organizations
stakeholders and leads to the development of the IT
strategic plan.
Developing an EA should not be done just to meet
government mandates or requirements. Enterprise
architecting should be a part of the enterprise capital
planning process. Enterprise architects need

organizational and executive support and funding to

successfully perform their mission. The executives
should not expect an immediate reward and should
recognize that EA is not an operational initiative, but a
strategic concept.
The challenges we have identified here are largely nontechnical. In part, this is because enterprise architecting
is not overly technical, but conceptual. As a result, it is
much harder to both qualitatively and quantitatively
describe and measure the benefits of enterprise
architecting. We hope that some of the issues raised in
this paper will begin to generate interest in developing
methods and metrics for qualitative and quantitative
measurement.
References:
Armour, F., Kaisler, S., and S. Liu. 1999. A Big
Picture Look at Enterprise Architectures, IEEE IT Pro
1(1): 35-42
Armour, F., Kaisler, S., and S. Liu. 1999. Building an
Enterprise Architecture Step-by-Step, IEEE IT Pro
1(3):49-57
Armour, F. and S. Kaisler. 2001. Enterprise
Architecture: Agile Transition and Implementation,
IEEE IT Pro (3)4
Armour, F, S. Kaisler, et al. 2003. A UML-Driven
Enterprise Architecture for the U.S. Capitol Police,
36th Hawaii International Conference on System
Sciences, Waikolua, HI, January 6-10, 2003
Boar, B. 1998. Constructing Blueprints for Enterprise
IT Architectures, Wiley & Sons, New York
GAO. 2004. A Framework for Assessing and
Improving Enterprise Architecture Management
(Version 1.1). U.S. Government Accounting Office,
Washington, DC
Hayward, S. 2002. The Impact of Mobility on
Enterprise Architectures, Gartner Research Note COM16-7718, July 19, 2002
James, G. 2002. Architectural Maturity: Acting on the
Signs, Gartner Research Note COM-16-8744, July 30,
2002
Lhereux, B. and J. Comport. 2002. Enterprise-toEnterprise Architecture for Virtual Enterprises, Gartner
Research Note COM-17-3617, July 31, 2002

Kaisler, S. and F. Armour. 2003. Enterprise

Architecting Using the Rational Suite. Rational Users
Conference, Orlando, FL
Open Group. 1999. Architecture Compliance.
http://www.opengroup.org/architecture/togaf7doc/arch/p4/comp/comp.htm
Rechtin, E. 1991. Systems Architecting: Creating and
Building Complex Systems. Prentice Hall, Englewood
Cliffs, NJ
Rechtin, E. and M.W. Maier. 1997. The Art of Systems
Architecting. CRC Press, Boca Raton, FL
Valivullah, M., J. Getter, S. Kaisler, and F. Armour.
2003. Management of Enterprise Administrative
Systems Implementation at United States Capitol
Police, INCOSE Conference, Washington, DC