A framework for information systems architecture by J.docx

A framework for information
systems architecture
by J. A. Zachman
With increasing size and complexity of the implementa-
tions of information systems, it is necessary to use
some logical construct (or architecture) for defining
and controlling the interfaces and the integration of all
of the components of the system. This paper defines
information systems architecture by creating a d e
scriptive framework from disciplines quite independent
of information systems, then by analogy specifies in-
formation systems architecture based upon the neu-
tral, objective framework. Also, some preliminary
conclusions about the implications of the resultant
descriptive framework are drawn. The discussion is
limited to architecture and does not include a strategic
planning methodology.
T he subject of information systems architecture is beginning to
receive considerable attention.
The increased scope of design and levels of complex-
ity of information systems implementations are forc-
ing the use of some logical construct (or architecture)
for defining and controlling the interfaces and the
integration of all of the components of the system.
Thirty years ago this issue was not at all significant
because the technology itself did not provide for
either breadth in scope or depth in complexity in
information systems. The inherent limitations of the
then-available 4K machines, for example, con-

strained design and necessitated suboptimal ap-
proaches for automating a business.
Current technology is rapidly removing both concep-
tual and financial constraints. It is not hard to spec-
ulate about, if not realize, very large, very complex
systems implementations, extending in scope and
complexity to encompass an entire enterprise. One
can readily delineate the merits of the large, complex,
enterprise-oriented approaches. Such systems allow
flexibility in managing business changes and coher-
ency in the management of business resources. How-
ever, there also is merit in the more traditional,
smaller, suboptimal systems design approach. Such
systems are relatively economical, quickly imple-
mented, and easier to design and manage.
In either case, since the technology permits “distrib-
uting” large amounts of computing facilities in small
packages to remote locations, some kind of structure
(or architecture) is imperative because decentraliza-
tion without structure is chaos. Therefore, to keep
the business from disintegrating, the concept of in-
formation systems architecture is becoming less an
option and more a necessity for establishing some
order and control in the investment of information
systems resources. The cost involved and the success
of the business depending increasingly on its infor-
mation systems require a disciplined approach to the
management of those systems.
On the assumption that an understanding of infor-
mation systems architecture is important to the de-
velopment of a disciplined approach, the question
that naturally arises is “What, in fact, is information

Copyright 1987 by International Business Machines
Corporation.
Copying in printed form for private use is permitted without
payment of royalty provided that ( 1 ) each reproduction is
done
without alteration and ( 2 ) the Journal reference and IBM
copyright
notice are included on the first page. The title and abstract,
but no
other portions, of this paper may be copied or distributed
royalty
free without further permission by computer-based and other
information-service systems. Permission to republish any other
portion of this paper must be obtained from the Editor.
276 ZACHMAN IBM SYSTEMS JOURNAL, VOL 26. NO 3,
1987
systems architecture?” Unfortunately, among the
proponents of information systems architecture,
there seems to be little consistency in concepts or in
specifications of “architecture,” to the extent that the
words “information systems architecture” are al-
ready losing their meaning! Furthermore, it probably
is not reasonable to expect reconciliation or com-
monality of definition to emerge from the profes-
sional data processing community itself. The emo-
tional commitment associated with vested interests
almost demands a neutral, unbiased, independent
source as a prerequisite for any acceptable work in
this area.
In any event, it likely will be necessary to develop

some kind of framework for rationalizing the various
architectural concepts and specifications in order to
provide for clarity of professional communication,
to allow for improving and integrating development
methodologies and tools, and to establish credibility
and confidence in the investment of systems re-
sources.
Although information systems architecture is related
to strategy, both information strategy and business
strategy, this paper deliberately limits itself to archi-
tecture and should not be construed as presenting a
strategic planning methodology. The development
of a business strategy and its linkage to information
systems strategies, which ultimately manifest them-
selves in architectural expression, is an important
subject to pursue; but it is quite independent of the
subject of this work, which is defining a framework
for information systems architecture.
Derivation of the architectural concept
In searching for an objective, independent basis upon
which to develop a framework for information sys-
tems architecture, it seems only logical to look to the
field of classical architecture itself. In so doing, it is
possible to learn from the thousand or so years of
experience that have been accumulated in that field.
Definition of the deliverables, i.e., the work product,
of a classical architect can lead to the specification
of analogous information systems architectural prod-
ucts and, in so doing, can help to classify our con-
cepts and specifications.
With this objective in mind, that is, discovering the
analogous information systems architectural repre-

sentations, the following is an examination of the
classical architect’s deliverables produced in the
process of constructing a building.’
IBM SYSTEMS JOURNAL, VOL 26 NO 3 1987
Bubble charts. The first architectural deliverable cre-
ated by the architect is a conceptual representation,
a “bubble chart,” which depicts, in gross terms, the
size, shape, spatial relationships, and basic intent of
the final structure. This bubble chart results from
the initial conversations between the architect and
prospective owner. A sample of such an initial con-
versation follows:
“I’d like to build a building.”
“What kind of building do you have in mind?
Do you plan to sleep in it? Eat in it? Work in
it?”
“Well, I’d like to sleep in it.”
“Oh, you want to build a house?”
“Yes, I’d like a house.”
“How large a house do you have in mind?”
“Well, my lot size is 100 feet by 300 feet.”
“Then you want a house about 50 feet by 100
“Yes, that’s about right.”
“How many bedrooms do you need?”
“Well, I have two children, so I’d like three
feet?”
bedrooms.”

Note that each question serves to pose a constraint
(the lot size) or identify a requirement (the number
of bedrooms) in order to establish the “ballpark,” or
approximate conditions, within which any design
The architect’s drawings are a
transcription of the owner’s
perceptual requirements.
will take place. From the above dialogue, the archi-
tect can depict what the owner has in mind in the
form of a series of “bubbles,” each bubble represent-
ing a room, its gross size, shape, spatial relationship,
etc. (See Figure 1 .)
The architect prepares this bubble chart for two
reasons. First, the prospective owner must express
what he or she has in mind that will serve as a
foundation or basis for the architect’s actual design
278
work. Second, the architect must convince the owner
that the owner’s desires are understood well enough
so that the owner will p a y for the creative work to
follow, and in effect, initiate the project.
Having established a basic understanding with the
prospective owner, the architect produces the next
set of architectural deliverables, which are called
architect’s drawings.
Architect’s drawings. The architect’s drawings are a
transcription of the owner’s perceptual require-

ments, a depiction of the final product from the
owner’s perspective.
The drawings include horizontal sections (floor
plans), vertical sections (cutaways), and pictorial rep-
resentations depicting the artistic motif of the final
structure. The purpose of these drawings is to enable
the owner to relate to them and to agree or disagree:
“That is exactly what I had in mind!” or “Make the
following modifications.”
The drawings can be very detailed; however, they
are normally developed only to the level of detail
required for the prospective owner to understand
and approve the design.
Once the owner agrees that the architect has captured
what he or she has in mind, and further agrees to
pay the price for continuing the project, the architect
produces the next set of architectural deliverables,
which are called the architect’s plans.
Architect’s plans. The architect’s plans are the trans-
lation of the owner’s perceptions/requirements into
a product. The plans are a designer’s representation
of the final product (as opposed to an owner’s rep-
resentation, which is embodied in the drawings).
The designer’s representation (plans) puts an explicit
specification around the material composition of the
final product.
The plans are composed of 16 categories of detailed
representations, including site-work, electrical sys-
tem, masonry, wood structure, etc. They describe
material relationships in the form of diagrams (draw-
ings) as well as bills-of-materials. These plans are the

final deliverables prepared by the architect and ulti-
mately become the official “record” of the finished
structure.
The architect’s plans are prepared to serve as a basis
for negotiation with a general contractor. The owner
ZACHMAN
279
takes the plans to a contractor and says, “Build me
one of these.” If the contractor builds “one of these,”
which is represented in the architect’s plans, the
owner knows that there is a high probability of
getting the desired product, as depicted in the archi-
tect’s drawings.
As a result of the negotiations between the owner
and general contractor, the plans may be modified
because of cost/price and other considerations, but
they finally serve to represent what is committed to
construction.
Contractor’s plans. At this point, the contractor re-
draws the architect’s plans to produce the contrac-
tor’s plans representing the builder’s perspective.
Such plans are prepared because complex engineer-
ing products are not normally built in a day. Some
phased approach is required which, in the case of a
building, may comprise first some site work; next
the foundation; then the first floor, and so on, until

the building is completed. Furthermore, the contrac-
tor may have technology constraints. Either the tool
technology or the process technology may constrain
his ability to produce precisely what the architect has
designed. In either case, the contractor will have to
design a reasonable facsimile which can be produced
and yet satisfies the requirements. These technology
constraints, plus the natural constraints requiring
phased construction, are reflected in the contractor’s
plans, which serve to direct the actual construction
activity.
Shop plans. Other representations, short of the final
structure itself, are prepared by subcontractors.
These representations are called shop plans and are
drawings of parts or subsections which are an out-of-
context specification of what actually will be fabri-
cated or assembled. The drawings, architect’s plans,
and contractor’s plans are in-context because the
owner, architect, and contractor are all concerned
with the entirety of the structure, whereas the sub-
contractors’ representations are concerned with
components or parts of the total structure. These
shop plans might even serve as patterns for a quantity
of identical parts to be fabricated for the project.
The building. In the case of producing a building,
the final representation is the physical building itself.
In summary, there is a set of “architectural” repre-
sentations that are produced during the process of
constructing a building. The set is given in Table 1.
280 ZACHMAN
A generic set of architectural representations

Now that we have specified the set of architectural
representations produced during the process of con-
structing a building, it becomes apparent that this
set of “architectures” may be generic to the process
of building any complex engineering product. A
cursory examination of military airframe manufac-
turing appears to validate this hypothesis as follows:
a. Concepts equals “bubble charts” (ballpark view).
The airframe manufacturers begin with some
“concepts,” which are specifications for the “ball-
park” in which they intend to manufacture. For
example, concepts for the final product indicating
that it will fly so high, so fast, so far, for such and
such purpose, with so many people, etc. are for-
mulated to establish its gross size, shape, and
performance.
b. Work breakdown structure equals architect’s
drawings (owner’s view). The work breakdown
IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987
structure is the “owner’s perspective.” The gov-
ernment requires that the manufacturer specify
the work to be accomplished in terms of the
components/systems against which costs are ac-
crued and schedules are managed. In this fashion,
the government controls the manufacturer in the
production of the product.
c. Engineering design equals architect’s plans (de-
signer’s view). Engineering, the designer, trans-

lates the work breakdown structure into a physi-
cal product. The resultant “engineering design” is
composed of drawings and bills-of-material.
d. Manufacturing engineering bill-of-materials
equals contractor’s plans (builder’s view). Manu-
facturing engineering, the builder, applies the laws
of nature and technology constraints to the engi-
neering design to describe how to build the prod-
uct (i.e., inside-out, bottom-up) and to ensure
that everything designed is actually producible.
e. Assembly and fabrication drawings equals shop
plans (detail view). Assembly and fabrication
An analogous set of architectural
representations is likely to be
produced in building any complex
product.
drawings are the instructions to the shop floor
personnel on how they are to assemble/fabricate
the pieces or parts as stand-alone entities.
f. Machine tool representation (machine view). Be-
cause manufacturing uses computer-controlled
equipment to produce some parts, they insert an
additional representation of the final piece or
part, short of the physical part itself. This repre-
sentation is a “program” (i.e., “numerical code
program”) that is a machine language represen-
tation.
g. Airplane equals building (finished product). The
final representation is the actual, physical item

itself.
In any case, there appear to be conceptual equiva-
lents in the manufacturing industry for the architec-
IEM SYSTEMS JOURNAL, VOL 26, NO 3, 1987
tural representations of the construction industry.
This equivalency would strengthen the argument
that an analogous set of architectural representations
is likely to be produced during the process of building
any complex engineering product, including an in-
formation system,
Before identifying the information systems analogs,
it is useful to make some general observations re-
garding architecture.
First, there appear to be three fundamental architec-
tural representations, one for each “player in the
game,” that is, the owner, the designer, and the
builder. The owner has in mind a product that will
serve some purpose. The architect transcribes this
perception of a product into the owner’s perspective.
Next the architect translates this representation into
a physical product, the designer’s perspective. The
builder then applies the constraints of the laws of
nature and available technology to make the product
producible, which is the builder’s perspective.
Preceding these three fundamental representations,
a gross representation of size, shape, and scope is
created to establish the “ballpark” within which all
of the ensuing architectural activities will take place.
Succeeding the three fundamental representations

are the detailed, out-of-context representations
which technically could be considered architectures
because they are representations short of being the
final physical product. However, they are somewhat
less interesting “architecturally,” since they do not
depict the final product in total and are more ori-
ented to the actual implementation activities. None-
theless, they are included in this discussion for the
purpose of ensuring a comprehensive framework.
A significant observation regarding these architec-
tural representations is that each has a different
nature from the others. They are not merely a set of
representations, each of which displays a level of
detail greater than the previous one. Level of detail
is an independent variable, varying within any one
architectural representation. For example, the de-
signer’s representation (i.e., architect’s plans) is not
merely a succeeding, increasing level of detail of the
owner’s representation (i.e., architect’s drawings). It
is different in nature, in content, in semantics, and
so on, representing a different perspective. The level
of detail of the designer’s representation (i.e., plans)
is variable, and quite independent of the level of
detail of the owner’s representation (i.e., drawings).
ZACHMAN 281
Table 2 The architectural representations produced over the
process of building a complex engineering project, along with
analogs in the building, airplane, and information systems
communities
Generic Buildings Airplanes

Owner’s Architect’s Work hmkdown
Designer’s
Builder’s Contractor’s Manu
Out-of-contex t
Machine language - Numerical code
representation drawings
representation
representation
representation
representation
In the same fashion, each of the architectural repre-
sentations differs from the others in essence, not
merely in level of detail.
Given this description of the perspectives (i.e., own-
er’s perspective, designer’s perspective, builder’s per-
spective, etc.) of architectural representation pro-
duced over the process of building a complex engi-
neering product, it is relatively straightforward to
identify the analogs in the information systems area,
since information systems are also “complex engi-
neering products.” Table 2 identifies those informa-
tion systems analogs along with the building and
airplane equivalents.

Different types of descriptions for the same product.
Before the idea regarding the different perspectives
(and therefore the different architectural representa-
tions produced over the process of building complex
engineering products) is developed further, it is nec-
essary to introduce a second, entirely different idea.
Specifically, there exist different types of descriptions
oriented to different aspects of the object being de-
scribed. Table 3 characterizes three such types of
descriptions, one of which is oriented to the material
of the product, another to its function, and the third
to the relative location of its components.
In spite of the fact that each of the descriptions may
be describing the same product, each of them is
unique and stands alone because each serves quite
different purposes. Furthermore, none of the descrip-
tions explicitly says anything about any of the other
descriptions. Only assumptions can be made from
one about the contents of another. For example, a
bill-of-materials exists independently of, and is
clearly different from, functional specifications or
drawings. Looking at a bill-of-materials tells nothing
about functional specifications or drawings (relative
locations of components). Only assumptions can be
made about function or location, depending upon
how descriptively named the parts are in the bill-of-
materials. Similarly, the functional specifications say
nothing explicit about the bill-of-materials or the
drawings, and the drawings say nothing explicit
about the bill-of-materials or functional specifica-
tions.
In short, each of the different descriptions has been
prepared for a different reason, each stands alone,

and each is different from the others, even though
all the descriptions may pertain to the same object
and therefore are inextricably related to one another.
The “description” row of Table 3 suggests that there
likely are additional descriptions not characterized
in the table as the material description addresses
“WHAT,” the functional description addresses
“HOW,” and the location description addresses
“WHERE.” The implications are that there must be
at least “WHO,” “WHEN,” and “WHY” descriptions as
well. Discussion of these additional types of descrip-
tions is reserved for the future, since using only three
different descriptions introduces considerable com-
282 ZACHMAN IBM SYSTEMS JOURNAL, VOL 26, NO 3,
1987
Table 3 Three different types of descriptions of the same
product
Description I Description H Description 111
Orientation Material Function Location
Focus Structure Transform Flow
Description WHATthe thing is made HOWthe thing works
WHERE the flows (connections)
Example Bill-of-materials Functional specifications Drawings
Descriptive model Part-relationshippart Input-process-output
Site-link-site

of exist
Table 4 Information systems analogs for the different types of
descriptions
Description I Description II Description 111
(material) (funoti) (l-tw
Information systems analog Data model Rocess model Network
model
I/S descriptive model Entity-relationshipentity Input-process-
output Node-line-node
plexity into the subject of information systems ar-
chitecture at this time. Therefore, the remainder of
this paper will be limited to the three types of de-
scriptions contained in Table 3. For future reference,
Appendix A is included and contains a preliminary,
Table 3-like characterization of the additional de-
scriptive types related to people (who), time (when),
and motivation (why).
As was the case with the earlier idea regarding the
different perspectives of the different participants in
the architecture process, once again it is straightfor-
ward to identify the information systems analogs for
the elements of the second idea, that is, the different
types of descriptions for the same object, as follows:
a. Functional description-In information systems
terms this would likely be called a process (or a
functional) model, and the descriptive represen-
tation would be called the same as the general
case, “input-process-output.”

b. Material description-Generally speaking, the
material description describes the “stuff the thing
is made of,” which in the case of information
systems is data. Therefore, in information systems
terms, the analog for the material description
would be a data model, and in the data vernacu-
lar, “part-relationship-part” would become “en-
tity-relationship-entity.’’ The data model is the
equivalent of the bill-of-materials for the infor-
mation systems product.
c. Location description-In information systems,
this would likely be called the network model, in
which the focus is on the flows (connections)
between the various components. In the infor-
mation systems network vernacular, “site-link-
site” would become “node-line-node.”
Therefore, the rows of Table 4, which constitute the
analogs in information systems for the more generic
types of descriptions, could be added to Table 3.
The framework. Two ideas have been discussed thus
far:
a. There is a set of architectural representations
produced over the process of building a complex
engineering product representing the different
perspectives of the different participants.
b. The same product can be described, for different
purposes, in different ways, resulting in different
types of descriptions.

The combination of the two ideas suggests that for
every different type of description, there are different
perspectives (and actually different representations)
for each of the different participants. For example,
for the material (or data) description, there are the
ZACHMAN 283 IBM SYSTEMS JOURNAL, VOL 26 NO 3.
1987
owner’s representation, the designer’s representa-
tion, the builder’s representation, etc. For the func-
tional (or process) description, there are the owner’s
representation, the designer’s representation, the
builder’s representation, etc. For the location (or
geographic) description, there are also the owner’s
representation, the designer’s representation, the
builder’s representation, etc.
Figure 2 illustrates the total set of different perspec-
tives for each type of description. Note that because
the intent is to depict a framework for information
systems architecture, all the information systems
analog names from Tables 2, 3, and 4 have been
used in Figure 2 in place of the more generic man-
ufacturing or construction names. Also, the machine
language perspective in Table 2 has been omitted,
merely because it is not as interesting as the others
from an “architectural” point of view.
The one single factor that makes this framework
extremely interesting is the fact that each element
on either axis of the matrix is explicitly differentiable
from all other elements on that one axis. That is, the
model of the business (owner’s perspective) is differ-

ent from the model of the information system
(designer’s perspective), and so on. (Remember from
earlier discussions that these representations are not
merely successive levels of increasing detail but are
actually diferent representations-different in con-
tent, in meaning, in motivation, in use, etc.) Also,
the data description column (entity-relationship-en-
tity) is different from the process description column
(input-process-output), and so on. Because each of
the elements on either axis is explicitly different from
the others, it is possible to define precisely what
belongs in each cell, and further, each cell in the
matrix will be explicitly different from all the other
cells.
Architectural representations for describing data
To illustrate how each cell differs from all of the
others, examine the data description column of Fig-
ure 2. Even though every cell in the column is
descriptive type I relating to data, and the descriptive
model is “entity-relationship-entity,’’ the meanings
of “entity” and “relationship” change with the dif-
ferent perspectives of the participants in the archi-
tecture process. The only exception is the scope
description (ballpark) cell, in which entity is defined
the same as entity in the model of the business cell.
This ballpark perspective is merely a very high level
of aggregation which is being used like the architect’s
“bubble charts” to establish the gross size and scope
of the data strategy, leading to the decision regarding
investment of data processing resources in managing
data.
Scope/description (ballpark perspective)-data col-

umn. The scope description cell in the data descrip-
tion column of Figure 2 could be expected to be a
list of all the things that are important to the business,
and therefore, that the business manages.*
Table 53 is an example of an architectural represen-
tation in the data description column from the scope
description perspective.
This representation would be a list of things (i.e.,
material-grammatically, nouns) as opposed to a list
of actions (i.e., processes-grammatically, verbs). A
list of actions (verbs) could be expected in the next
column, process description. The list of things (ma-
terial) in the data description column would be called
“entities” in data vernacular.
Since this architectural representation is at the scope
description row, one could also expect that the enti-
ties (things) would likely be entity “classes,” that is,
higher levels of aggregation, because the decision
being made as a result of this representation would
be one of scope, not one of design. A selection would
be being made of the entity class or classes in which
to invest actual information system (I/s) resources
for data “inventory” management purposes.
Further, in this cell, one might not expect to be
definitive about the relationship between entities.
The scope decision would constitute overlaying the
business values on the total range of possibilities to
identify a subset of entity classes for implementation
which is consistent with the resources available for
investing in information systems-specifically, in
this case, the management of the selected class (or
classes) of data. Furthermore, it is useful to start with

the total list of entities because, at times, the entities
that are not selected are as significant as those that
are selected.
The strategy/resource investment decision is made
by understanding the values/strategies of the busi-
ness, which can be done by using various data-
gathering/analytical techniques. The decision is
made by overlaying the analytical conclusions on
the total list of business entities in the scope descrip-
tion cell and thereby selecting the subset of business
entities in which to actually invest data processing
284 ZACHMAN IBM SYSTEMS JOURNAL, VOL 26, NO 3,
1987
Figure 2 Framework for information systems architecture
~~~
IBM SYSTEMS JOURNAL, VOL 26 NO 3 1987 ZACHMAN
285
Table 5 Sample entities-Architectural representation in the
data description column from the scope description
perspective3
Product Policies and procedures
Legal requirements
G/L accounts
Accounts payable
Accounts receivable

Long-term debt
Marketplace
Competitor Promotion
Building and real estate Purchase order
Objectives Customer order
Job Pruduction order
Organization unit Shipment
resources. Since this paper is intended to define
architecture, not to describe strategy methodologies,
nothing further will be said about strategic planning
except to point out that similar kinds of decisions
have to be made relative to every other scope descrip-
tion cell. That is, out of the total list of business
processes, the business likely does not have enough
data processing resources to automate all the pro-
cesses. Therefore, a decision will have to be made to
select a subset in which to invest data processing
resources for actual automation. By the same token,
out of the total list of locations in which the business
operates, it probably does not have enough data
processing resources to put hardware and software
in every location. Again, decisions will have to be
made in selecting a subset of locations in which to
actually install hardware and software.
These are the strategy/resource investment decisions
that are supported by the scope description cells in
the top row of Figure 2. Although they are inextri-
cably related, the probability is that each decision
will have to be addressed independently of the others.
Discussion now continues on the framework, partic-
ularly the data description column of Figure 2.
Model of the business (owner’s perspective)-data

description column. Since this model (or description)
appears in the data description column, the descrip-
tive model will be “entity-relationship-entity,” and
when owners (users) describe the business and say
“entity,” what they have in mind are business enti-
ties?
For example, when owners (users) specify an entity
such as “employee,” what they have in mind would
be real beings, that is, flesh and blood employees
who work for the business. That meaning of “em-
ployee” is entirely different from the one used in an
information systems model (the designer’s perspec-
tive), in which “employee” would refer to a record
on a machine, which also happens to be called
“employee,” however conceptually and entirely dif-
ferent it is. (This data entity, as opposed to business
entity, would be found in the cell directly below.)
Figure 3 is an example of a model of a business,
oriented to data.
Further, when owners, describing a business, specify
a relationship between the entities, what they have
in mind would be the business rule or strategy that
relates one entity to another entity.5 A business rule
or strategy, for example, might be “in this business
we ship this product from that warehouse only.” An
entirely different rule would be “in this business, we
ship this product from any warehouse we have.”
These are business rules and not data relationships
such as would be expected in the model of the
information system (designer’s perspective) in the
cell below the Model of the Business shown in Figure
2.

Finding good “real-life’’ examples which crisply il-
lustrate each of the architectural representations is
difficult. There are two reasons for this difficulty.
First, when the real-life representations were being
developed, no framework existed to clearly define
and differentiate one representation from the others.
Therefore, many real-life illustrations are a mixture
of representations, both conceptually (e.g., business
entities and data entities get mixed together) and
physically (e.g., entities and inputs/outputs, that is,
user views from the process description column of
Figure 2, get mixed together). Second, real-life ex-
amples are hard to understand because it is not
always clear what model, or cell, the author had in
mind when developing the representation.
An illustration of this difficulty is found in Figure 3 .
It is clear that this model is describing data and not
process, but the question is, did the author have in
mind a description of a business or a description of
an information system? In this case, it is likely that
the description is of a business because of the exis-
tence of the “many-to-many’’ relationships. In real
life, there are many “many-to-many’’ relationships,
but the database management concepts that are pop-
ular today require that the “many-to-many’’ relation-
ships be resolved in order to run on a machine.
Therefore, “artificial” entities have to be created to
resolve the “many-to-many’’ relationships, and the
model in Figure 3 would have to be “normalized”
1987

Figure 3 Sample entity relationship model - Model of the
business (owner’s perspective) - Data column3
before it could be a legitimate model of an infor-
mation system. In any case, since the model in Figure
3 is not “normalized,” by today’s standards at least,
it is clearly a model of a business as opposed to a
model of an information system.
Model of an information system (designer’s perspec-
tive)-data description column. Once again, since
the model of the information system is in the data
description column of the framework, the descriptive
model used is “entity-relationship-entity.” But from
the designer’s perspective, the meaning of “entity”
would change to that of a record on a machine, and
relationship would change to that of a data relation-
ship. Clearly, the example in Figure 4 is a model of
an information system and not a model ofa business,
because of the existence of “artificial” entities, spe-
cifically the “DEPTPROJ” entity (resulting from the
concatenation of department and project), which is
not a real-life item, but something in an information
system, created in the process of translating the
business description into an information systems
“product.” In the data design vernacular, this ex-
ample of Figure 4 would likely be called a data
Technology model (builder’s perspective)-data de-
scription column. As in the previously described cells,
the descriptive model in the builder’s cell is “entity-
relationship-entity,’’ and what could be expected is
the physical implementation or data design for the
conceptual model of the information system.

In the technology model, the laws of nature and
technology constraints are being applied. A decision
is made to use Information Management System
(IMS) or I B M Database 2 ( D B ~ ) or XYZ, and depending
on the choice, the meaning of entity and relationship
change. In the case of IMS, entity means “segment”
and relationship means “pointer.” In the case of D B ~ ,
entity means “row” and relationship means “key,”
e t ~ . ~ Figure 5 is an example of an architectural
representation of the technology model (builder’s
perspective) in the data description column of the
framework.
IBM SYSTEMS JOURNAL, VOL 26. NO 3, 1987 ZACHMAN
287
Figure 4 Sample conceptual data model - Model of
the information system (designer’s perspective) -
Data column3
Detailed description (out-of-context perspective)-
data description column. The descriptive model is
“entity-relationship-entity” in the detailed descrip-
tion cell. This cell is analogous to the subcontractors’
out-of-context descriptions. What could be expected
is Data Definition Language. An example might be
a DBDGEN in which the entities are specifications of
the “fields,” and relationships are specifications of
the “addre~ses.”~ An example is shown in Figure 6.
This description is “compiled” to produce the ma-
chine language representation (relative addressing-
not shown in the figure), which is further “link-
edited” to produce the actual physical data (absolute

addressing) residing in the machine.
It is clear that real-life examples can be found to
illustrate all of the architectural representations for
the various viewpoints or perspectives that are cre-
Real-life examples can be found to
illustrate all of the architectural
representations.
ated for the data (or material) description of the
information system.
Although actual samples (figures) for each of the
remaining cells are available, no attempt will be
made to include them in this paper. Let it be suffi-
cient merely to describe how the meanings of the
descriptive model terms change in the remaining two
columns as the representations shift from perspective
to perspective.
Architectural representations for describing the
process
The descriptive model for describing the process is
input-process-output,” and, as in the case of the
data description column, each of the representations
in the different cells in the process description col-
umn of Figure 2 have different meanings associated
with “input,” “process,” and “output.”
“ ’
At the scope description (ballpark perspective) cell,

“process” would mean business process. It would
likely be some process “class,” a relatively high level
of aggregation, as the decision being made from the
scope description cell is the selection of some subset
of the appropriate business processes in which to
invest some finite amount of information systems
resources for actual automation purposes. Further,
in making the scope decision, it is unnecessary to be
definitive about the input and output linkages be-
tween the functions by overlaying the business values
against the total range of automation possibilities.
Therefore, just a list of business processes would
appropriately be expected in this cell representation.
In the model of the business (owner’s perspective) in
the process description column, an example might
1987
Figure 5 Sample DL/I physical model -Technology model
(builder’s perspective) - Data column3
DEPT
T I r - - - A I > I IPHONE /
be a functional flow diagrams.’ in which “process”
would be a business process (not an information
systems process) and inputs and outputs would be
business resources such as people, cash, material,
product, etc.
In the model of the information system (designer’s

perspective) for the process description column, an
example would be a data flow diagram8-’’ in which
processes are information systems (application)
processes (not business processes) and the inputs/
outputs are “user views”-some aggregations of data
elements that flow into and out of the application
processes, connecting them in some sequential fash-
ion. (Note that this does not preclude depicting
manual functions that are introduced as part of the
information system.)
Proceeding to the technology model (builder’s per-
spective)-process description column, we see that
the meaning of “input-process-output’’ changes once
again. In applying the physical constraints of the
technology chosen for implementation, for example,
I B M 3380 Direct Access Storage Devices versus I B M
3480 Magnetic Tape Subsystems (disks), I M S versus
Customer Information Control System (CICS), COBOL
versus FORTRAN; I B M 3270 terminal devices (video
displays) versus I B M Personal Computers, etc., the
builder’s perception of a process becomes a computer
function, and inputs and outputs are device formats.
The predictable example would be a structure
chart l o - ” and screen/device formats.
For the detailed description (out-of-context) cell, the
example is a “program” in which “process” is a
language statement and the inputs and outputs are
control blocks. I ‘ , I 2
The program is compiled to produce object code,
the machine language representation (not shown in
IBM SYSTEMS JOURNAL, VOL 26, NO 3, 1987

Figure 6 Sample detailed description (out-of-context
perspective) Data column
DBDG E N - SAMPLE STATEMENTS
DBD
NAME=STDCDBP,
ACCESS=HDAM,
RMNAME=(DLZHDClO,
3,
100,
600)
DD1 =STDCDBC,
DEVlCE=3340,
DATASET
BLOCK=(2048),
SCAN=2
NAME= STSCCST,
PARENT= 0
SEGM
BYTES=106,
POINTER =TWIN
FIELD
NAME = (STQCCNO,SEQ, U),
BYTES = 6,
START= 1,

TYPE=C
ETC.
DATA BASE DESCRIPTION NAME X
HIERARCHICAL DIRECT X
RANDOMIZING ROUTINE PHASENAME X
ROOT ANCHOR POINTS PER BLOCK X
ROOT ADDR. AREA HI RELATIVE BLK X
INSERT BYTES LIMIT FOR RAA X
FILE NAME X
DISK DEVICE X
VSAM CONTROL INTERVAL SIZE X
# CYLINDERS SCAN FOR ISRT SPACE X
SEGMENT NAME FOR EMP NAME/ADDR X
IT IS A ROOT SEGMENT X
DATA LENGTH X
PHYSICAL TWIN FWD ONLY X
UNIQUE KEY FIELD (EMP #) X
FIELD LENGTH X
WHERE IT STARTS IN SEGMENT X
ALPHAMERIC DATA X
Figure 2) which, in turn, is assembled to produce
running instructions for the actual, physical system.
Again, it is clear that examples can be found for
every descriptive representation for the process de-
scription column, as well as for the data description
column.
Architectural representation describing the
network

The descriptive model for the network set of archi-
tectural representations in the network description
column of Figure 2 is “node-line-node.”
From the scope description (ballpark) perspective,
what could be expected is a list of locations in which
the business operates. Therefore, “node” would
mean business location, likely at a high level of
aggregation, that is, showing little detail about the
“contents” of the location. The locations might even
be arranged on a map, a geographical construct. If
lines were shown, they would probably merely indi-
cate where there are communications or logistics
connections between the locations. The purpose
served, once again, is the strategy/resource invest-
ment decision in which the main decision is to select
the subset of locations in which to actually locate
technology (hardware/software).
The owner, in describing the business, that is, pro-
ducing the model of the business as related to the
network (or the connectivity characteristics of the
business), would perceive the “nodes” to be business
units, an aggregation of business resources (people,
facilities, responsibilities, etc.) at some geographical
location. The lines would represent logistics connec-
tions or flows, probably including communications
IBM SYSTEMS JOURNAL, VOL Z , NO 3, 1987
linkages, but even more basically would represent
the distribution structure or logistics network along

which communications take place.
In the model of the information system (the design-
er’s perspective) for the network description, the
information system designer would perceive the
node to be some 11s function, like a processor, storage
unit, or access point. This would be a conceptual
representation, independent of specific technology
Technology constraints would be
introduced in the technology model.
which would be introduced in the builder’s cell. The
line, from a designer’s standpoint, would be a com-
munication line at the conceptual level, such as a
leased line, dial-up service, U S . mail, etc. This cell
would serve the purpose of making the “distributed
systems” decisions, that is, specifying where the 11s
facilities would be installed, which of them would be
connected, and by what type of connection.
The technology constraints would be introduced in
the technology model (the builder’s perspective).
This cell would depict physical hardware and soft-
ware, for example, an IBM 3090 processor, 3270
display device, Personal Computer, Multiple Virtual
Storage ( MVS) operating system, Advanced Com-
munications Function/Network Control Program
(ACFINCP), etc. at the nodes and Synchronous Data
Link Control (SDLC), bisynchronous communica-
tions, 4800 baud, etc. for the lines.
In the detailed description (out-of-context) cell, the
nodes would be addresses, and the lines would be
protocol^.'^

In summary, although actual pictures have not been
included in the paper, examples could be presented
to illustrate every hypothetical architectural repre-
sentation postulated by the relationship among the
various architectural perspectives and the different
types of descriptions.
IEM SYSTEMS JOURNAL, VOL 26 NO 3, 1987
Table 6 lflthen table depicting different architectural
representations used within different data
processing functions
If you are: Then you probably think
architecture is:
A programmer
The database
An analyst
A planner
administrator
The communications
manager
An operations manager
A network administrator
A program support
representative

A computer designer
The president
A structure chart
Data design
A data flow diagram
Some combination of entity/
relationship diagrams and/
or functional flow diagrams
The business logistics
infrastructure and/or the
distributed systems
architecture
The system architecture
The network architecture
Detailed data and program
descriptions
Machine language (not
represented on the
summary chart, Figure 2)
Entity classes, process classes
and/or a map
Conclusions
When the question is asked, “What is information

systems architecture?” the answer is, “There is not
an information systems architecture, but a set of
them!” Architecture is relative. What you think ar-
chitecture is depends on what you are doing. For an
example, see Table 6.
We are having difficulties communicating with one
another about information systems architecture, be-
cause a set of architectural representations exists,
instead of a single architecture. One is not right and
another wrong. The architectures are different. They
are additive and complementary. There are reasons
for electing to expend the resources for developing
each architectural representation. And there are risks
associated with not developing any one of the archi-
tectural representations.
Research is being done to create more explicit defi-
nitions for each of the architectural representations
in this framework, to understand the design issues,
the reasons for developing each representation, the
risks associated with not developing any one, and
the “tool” implications of each cell.
Summary
Yourdon Press, Inc., New York (1978).
In summary, by studying fields of endeavor external
to the information systems community, specifically ysis,
Yourdon Press, Inc., New York (1984).
those professions involved in producing complex lo. Design A i
d an
185 I , IBM Corporation; i

tion, manufacturing, etc.), it is possible to hypoth-
Programming, Prentice-Hall, Inc., Englewood Cliffs, NJ
esize by analogy a set of architectural representations (1977).
12. H. D. Leeds and G. M.
Fundamentals. McGraw-mi1 BOOK LO., inc., I Y ~ W r orK
(1961).
Manual GC30-3073, IB
IBM branch offices.
8. T. DeMarco, Structured Analyses and System Specifications,
9. S . M. McMenamin and J. F. Palmer, Essential Systems
Anal- I
I
I
engineering products (e-g*, architecture/constmc- 1 1 . J. K.
Hughes and J. I. 1 .._.._____, _ _ ________.I_ - -
for information systems.
The resultant “framework for information systems
architecture” could prove quite valuable for
Improving professional communications within
Understanding the reasons for and risks of not
~ ’ ’ ’ > ~ ~ ~ ~ o , u ~ ’ - - - - - ‘ ’ - ’
developing any one architectural representation. the Business
Systems Plannin
Placing a wide variety Of tools and/or methodol- Mr. Zachman
joined IBM in

Developing improved approaches (including ing One as Account
13, systems Network Archjte-+.,-” Tnnl...;mr A.,n-.;n.r, r.,rtn-r
I the information systems community. . - - -
ogies in relation to one another.
architectural representations, as well as possibly
related positions in Chicago, New York, and Los Angeles,
includ- I
pany. He has bec- :-..-‘..-_I
method
tion in 1973. H~
information systems planning, and has written-a number of
articles
on the subject. His current responsibilities include working both
dressing planning approacher
mation systems. I“- 7n,.h-.
number of years i
Commander in
Reprint Order No. G321-5298.
methodologies and tools) to produce each of the
rethinking the nature of the classic “application
development process” as we know it today.
_ .
Cited references

I . G. D. Larson, private communication, Gaede and Larson,
Architects International Association, Pasadena, CA (1985).
2. Business Systems Planning-Information Systems Planning
Guide, Application Manual GE20-0627, IBM Corporation;
available through IBM branch offices.
3. Business Systems Planning, class material, IBM Corporation,
Information Systems Management Institute, Los Angeles, CA.
4. D. S. Appleton, ‘‘Business rules: The missing link,” Datama-
tion 30, No. 16, 145-150 (October 15, 1984).
5. C. J. Date, An Introduction to Database Systems, Addison-
Wesley Publishing Co., Reading, MA (1981).
Aeronautical Labs, Air Force Systems Command, Wright-
Patterson Air Force Base, OH 45433 (June 1981).
7. P. P. Chen, Entity-Relationship Approach to Systems
Analysis
and Design, University of California at Los Angeles, Los
Angeles, CA (December 1979).
Appendix A: Possible characterization of additional types of
descriptions
I Orientation People Time Purpose
I Focus Responsibility Dynamics Motivation
I Description WHO is doing what WHEN the events take place
WHY choices are made
Example Organization chart Production schedule Objectives
hierarchy

Descriptive Organization-reporting- Event-cycle-event
model organization
Objective-precedent-
objective
1987
www.ids-scheer.com
Why two thirds of Enterprise Architecture
projects fail
An explanation for the limited success of
architecture projects
ARIS Expert Paper
��
��
��
��
��
�
This is the conclusion of a study for the Rotterdam University
carried out by

Jonathan Broer in the summer of 2008, ordered by BPM and EA
software vendor
IDS Scheer. Broer questioned 161 respondents from 89
organizations represent-
ing a range of industries about their vision and implementation
of the enterprise
architecture concept.
A clear majority of respondents – 92 percent – believes that EA
should be deter-
mined by the vision, strategy and objectives of the company.
Yet only 40 percent
of them actually included objectives and policies in their EA
program. The align-
ment of Business and IT is seen as the most important argument
for organiza-
tions to start using EA. At the same time connecting IT
architecture and business
elements, and arriving at important decisions about structure
and layout on that
basis, is found to be one of the biggest problems confronting
businesses. Among
the reasons for the failure of EA programs to fulfill
expectations were a lack of
EA awareness and the fact that it took longer than expected to
set up an archi-
tecture.
Why two thirds of Enterprise Architecture projects fail
An explanation for the limited success of architecture projects
Large and medium-sized organizations regard the alignment of
business and
IT as the most important motive for working on an enterprise
architecture

(EA). Other important reasons for putting EA on the agenda are
support for
change processes and strengthening the flexibility of the
company. In spite
of the huge interest in EA it turns out that 66 percent of
programs did not ful-
fill expectations.
2
ARIS Expert Paper
This ARIS Expert Paper comprises:
� an overview of typical Enterprise Architecture project roles
and
drivers
� main targets of Enterprise Architecture projects and
initiatives
� critical success factors derived out of the survey
About the authors:
Sven Roeleven
is Global
Solution
s Manager at IDS
Scheer. After graduating in Public

Administration from Erasmus
University Rotterdam (the
Netherlands), he went on to spe-
cialize in business process man-
agement within ERP environ-
ments. Since joining IDS Scheer in
2002, Sven has gained extensive
hands-on experience covering all
ARIS platform products through-
out the course of dozens of proj-
ects within medium-sized and
larger organizations across a vari-
ety of industries.
Jonathan Broer
completed his studies in Business
Informatics at the Rotterdam
University in 2008 (with a minor in
BPM). For his practical training in

the final year of his degree, he
carried out a study of enterprise
architecture at IDS Scheer. Since
September 2008 he has been
employed by Capgemini as a con-
sultant in the field of Architecture,
Governance & Infrastructure.
Contact:
[email protected]
Fig. 1: Industries that participated in the study
Drivers for EA
Organizations start using EA for different reasons.
Business and IT streamlining, supporting change
processes and achieving greater flexibility are
the three most important reasons for starting an
EA project. This fits the definition of EA used by
research agency Gartner:

“Enterprise architecture is the process of trans-
lating business vision and strategy into effective
enterprise change [..]”.
The fact that EA is determined by vision, strategy
and objectives is also affirmed by 92 percent of
the organizations taking part in the study. In other
words, organizations have a clear understanding
of the reasons for starting an EA project, and they
know that these drivers are partly determined by
the business strategy. In their vision EA is there-
fore a holistic, business-driven discipline.
Older organizations have higher integration of architectures
Apart from their well-developed vision, organizations have also
come quite far in the implementation of enterprise archi-
tectures. 74 percent already use a framework for EA, and the
majority of those without a framework are in the process of
choosing one. The most commonly used standard frameworks
are TOGAF (The Open Group Architecture Framework) and
ArchiMate (adopted by TOGAF in 2008 as standard modeling
language).

The older organizations (more than 50 years old) are often
further ahead in the integration of domain architectures. In
many cases they have been involved in mergers or takeovers
which necessitate a good integration. The presence of lega-
cy systems also plays an important role. It is important after all
to know what the consequences of phasing out a system
will be for the entire operational management – the
consequences for data exchanged with the system for example,
or
for the infrastructure on which it runs, or for the processes
supported by the system which is about to be phased out.
Large organizations have more EA roles
There is also a connection between the size of
an organization and the presence of EA relat-
ed roles. The larger the organization, the larg-
er the presence of these roles in the EA work
field.
For small organizations the information archi-
tect is used the most. For large organizations it
is the business architect. Respondent com-
ments show that small organizations approach
EA much more from an IT point of view. Larger

organizations which appear to be more mature
in their enterprise architecture have a more
business-oriented approach, and they cite the
business architect as the most common role.
3
ARIS Expert Paper
Fig. 2: Drivers for EA projects
Fig. 3: Presence of EA related roles
Who is responsible for the purchasing of an EA tool?
As regards the responsibility for purchasing an
EA tool, it is notable that the IT manager and
CIO play a far bigger role in the purchase of an
EA tool than in the purchase of an ERP pack-
age for example. When purchasing an ERP
package there is a larger contribution from the
business, whereas EA tooling is primarily
approached from the IT perspective. This is

rather surprising considering that the older,
larger companies tend to approach EA from a
business perspective. One possible explana-
tion for this is that the business reality has
already been reproduced in a process model-
ing tool, and this is the responsibility of the CIO
and the IT manager in most organizations.
Explanations for disappointing results
In spite of the fact that organizations already have a reason-
ably mature vision and implementation, the expected results
are not achieved in 66 percent of the EA projects. The most fre-
quent explanation given for this failure is that connecting EA to
business elements such as strategy and BPM is found to be
difficult in practice.
Other reasons given by many respondents for the failure to meet
expectations were:
� Not enough support from C-level (CIO and CFO for example)
so that EA is not given enough status and expectations
cannot be fulfilled in practice.
� Limited commitment from interested parties so that there is a

return to old habits, and agreements are not complied
with.
� Not enough EA awareness among interested parties inside the
organization. EA not a generally accepted concept
in daily business activities.
� Financial and political issues that thwart EA projects.
� Setting up an architecture takes longer than expected. This
means it takes longer for the results to become visible,
which means there is a considerable risk factor for EA.
Another possible explanation is the discrep-
ancy between initial intentions for EA on the
one hand and the actual realization of the
architectures and degree of compliance with
agreements on the other. For example: 92 per-
cent of the organizations believe that vision,
strategy and objectives are determining fac-
tors for EA, yet only 40 percent incorporated
them in the architecture. On this basis it is of
course impossible to define the direct impact
of strategic choices on the architectural lay-
out. The following histogram provides an

overview of the most frequently recorded
domain architectures, including those for
objective and policies.
4
ARIS Expert Paper
Fig. 4: Responsibility for IT investments
Fig. 5: Most common EA problems
Fig 6: Most commonly recorded domain architectures
The three most frequently recorded architectures are found to be
the application architecture, process architecture and
information architecture.
The recording of domain architectures does not mean there is a
successful enterprise architecture in place however.
Agreements also have to be complied with about the use of one
another’s information, the methods to be used, owner-

ship, and procedures for arriving at innovations. All
this is collectively referred to as EA Governance. In the
following graph, four principles of EA Governance
show that the organizations do not score highly for
maturity. This may help to explain the disappointing
results of EA projects. Even when a big effort has been
made to sort out EA, a lack of (compliance with) agree-
ments leads to relatively low yields.
Since the recorded EA is not an integrated component
of operational management, there is a lack of commit-
ment. This undermines the status of EA inside the
organization. Also, architectures are often constructed
which bear no relation to other architectures inside
the organization. As a result there are no gains from
rapid impact analyses, coordination between domain
owners and integrated project scheduling. Structural monitoring
of compliance with architectural principles can help in
this regard, but this is not sufficiently applied in practice.
How can we ensure the success of an EA project?
The study shows that the following three rules will help to
create the right conditions for making EA successful in an

organization:
1. Set clear, enterprise-wide EA objectives before you start, and
manage expectations inside the organization. The
objectives affect the choice of the EA concept, including the
choice of domain architectures and the degree of inte-
gration between them. With clear objectives it is easier to
manage expectations in relation to EA inside the organi-
zation. In this way disappointment is avoided and the
organization does not have to spend a lot of time and energy
trying to create an architecture which is never realized. By
deploying EA enterprise-wide it is also easier to demon-
strate that a shared approach to EA pays off, in comparison to
the silos of documentation in Excel, Word and niche
tools, with all the duplication and inconsistencies these involve.
Use it to raise the level of commitment and cele-
brate the successes achieved.
2. Set up EA Governance and comply with it. If the methods and
agreements drawn up are not complied with by the EA
roles, the yield from the EA initiative will be inadequate.
Appoint a Chief EA to oversee compliance who also reports
to higher management (C-level). Higher management can in turn
ask for feedback through the Chief EA about the
impact of strategic management choices on operational

management and operational structures. In the context of
EA Governance, it is important to specify in the standard
project approach that it is mandatory to check what infor-
mation has already been recorded on the scope of the project;
this information should be used as a starting point
for the TO-BE situation. It is also important of course that EA
owners validate innovations according to a fixed
release procedure, and for the new AS-IS situation to be
documented in the EA tool before discharging responsibil-
ity for the project.
3. Make sure the business is sufficiently involved in these
initiatives, starting with the choice of the EA tool. Do not
allow EA procedures and tooling to become an IT matter,
otherwise the EA will not serve as driver of business and
IT streamlining. Choose a tool that supports all domain
architectures and is able to connect them in a single repos-
itory. Also make sure the tool can incorporate ownership,
combine the different methods used, and produce flexible
reports. Tools that already provide standard EA frameworks
such as TOGAF, IAF and ArchiMate are preferable in this
regard.
5

ARIS Expert Paper
Fig 7: The way EA is implemented
ARIS Expert Paper
��
��
��
��
��
�
IDS Scheer AG
Headquarters
Altenkesseler Str. 17
66115 Saarbruecken
Phone: +49 681 210-0
Fax: +49 681 210-1000
E-mail: [email protected]

www.ids-scheer.com
© Copyright (C) IDS Scheer AG, 2001 – 2009. All rights
reserved. The contents of this document is subject to copyright
law. Changes, abridgments, extensions and sup-
plements require the prior written consent from IDS Scheer AG,
Saarbrücken, Germany. Reproduction is only permitted provided
that this copyright notice is retained
on the reproduced document. Each publication or translation
requires the prior written consent from IDS Scheer AG,
Saarbrücken, Germany. “ARIS”, “IDS”,
“ProcessWorld”, “PPM”, “MashZone”, ARIS with Platform
symbol and Y symbol are trademarks or registered trademarks
of IDS Scheer AG in Germany and in many
countries all over the world. “SAP NetWeaver” is a trademark
of SAP AG, Walldorf. All other trademarks are the property of
their respective owners.
U.S. pat. D561,778, pat. D561,777, pat. D547,322, pat.
D547,323, pat. D547,324
ID-Number: EP-EA-0609-EN

A Practical Guide
to
Federal Enterprise Architecture
Chief Information Officer Council
Version 1.0
February 2001
iii
February 2001
Preface
An enterprise architecture (EA) establishes the Agency-wide
roadmap to achieve an Agency�s mission
through optimal performance of its core business processes
within an efficient information technology
(IT) environment. Simply stated, enterprise architectures are
�blueprints� for systematically and
completely defining an organization�s current (baseline) or

desired (target) environment. Enterprise
architectures are essential for evolving information systems and
developing new systems that optimize
their mission value. This is accomplished in logical or business
terms (e.g., mission, business functions,
information flows, and systems environments) and technical
terms (e.g., software, hardware,
communications), and includes a Sequencing Plan for
transitioning from the baseline environment to the
target environment.
If defined, maintained, and implemented effectively, these
institutional blueprints assist in optimizing the
interdependencies and interrelationships among an
organization�s business operations and the underlying
IT that support operations. The experience of the Office of
Management and Budget (OMB) and General
Accounting Office (GAO) has shown that without a complete
and enforced EA, federal agencies run the
risk of buying and building systems that are duplicative,
incompatible, and unnecessarily costly to
maintain and integrate.
For EAs to be useful and provide business value, their
development, maintenance, and implementation

should be managed effectively. This step-by-step process guide
is intended to assist agencies in defining,
maintaining, and implementing EAs by providing a disciplined
and rigorous approach to EA life cycle
management. It describes major EA program management
areas, beginning with suggested
organizational structure and management controls, a process for
development of a baseline and target
architecture, and development of a sequencing plan. The guide
also describes EA maintenance and
implementation, as well as oversight and control. Collectively,
these areas provide a recommended
model for effective EA management.
Background
Reflecting the general consensus in industry that large, complex
systems development and acquisition
efforts should be guided by explicit EAs, Congress required
Federal Agency Chief Information Officers
to develop, maintain, and facilitate integrated systems
architectures with the passage of the Clinger-Cohen
Act1in 1996. Additionally, OMB has issued guidance that
requires agency information systems
investments to be consistent with Federal, Agency, and bureau

architectures. Other OMB guidance
provides for the content of Agency enterprise architectures.2
Similarly, the Chief Information Officer
Council, the Department of the Treasury, the National Institute
of Standards Technology (NIST), and
GAO, have developed architecture frameworks or models that
define the content of enterprise
architectures.3
1 Public Law 104-106, section 5125, 110 Stat. 684 (1996).
2 OMB Circular A-130, Management of Federal Information
Resources, November 30, 2000.
3 Federal Enterprise Architecture Framework, Version 1.1,
Federal Chief Information Officers Council, September
1999; Treasury Enterprise Architecture Framework, Version 1,
the Department of the Treasury, July 3, 2000; the
National Institute of Standards and Technology�s Enterprise
Architectural Model, referenced in NIST Special
Publication 500-167, Information Management Directions: the
Integration Challenge; and Strategic Information
Planning: Framework for Designing and Developing System
Architectures (GAO/IMTEC-92-51, June 1992).

A Practical Guide to Federal Enterprise Architecture Preface
iv
February 2001
This guide builds upon, complements, and is directly linked to
the GAO Information Technology
Investment Management (ITIM) framework4 that was developed
to provide a common structure for
discussing and assessing IT capital planning and investment
control (CPIC) practices at Federal Agencies.
ITIM enhances earlier Federal IT investment management
guidance by extending the
Select/Control/Evaluate approach, mandated by the Clinger-
Cohen Act, into a growth and maturity
framework.5 It is also directly linked to the Federal Enterprise
Architecture Framework.
The Need for this Guide
While these frameworks and models provide valuable guidance
on the content of enterprise architectures,
there is literally no ffeeddeerraall guidance how to successfully
manage the process of creating, changing, and

using the enterprise architecture. This guidance is crucially
important. Without it, it is highly unlikely
that an organization can successfully produce a complete and
enforceable EA for optimizing its systems�
business value and mission performance. For example,
effective development of a complete EA needs a
corporate commitment with senior management sponsorship.
The enterprise architecture development
should be managed as a formal project by an organizational
entity that is held accountable for success.
Since the EA facilitates change based upon the changing
business environment of the organization, the
architect is the organization�s primary change agent. Effective
implementation requires establishment of
system compliance with the architecture, as well as continuous
assessment and enforcement of
compliance. Waiver of these requirements may occur only after
careful, thorough, and documented
analysis. Without these commitments, responsibilities, and
tools, the risk is great that new systems will
not meet business needs, will be incompatible, will perform
poorly, and will cost more to develop,
integrate, and maintain than is warranted.
Conclusion

The processes described in this guide represent fundamental
principles of good EA management. Since
the guide is not a one-size-fits-all proposition, Agencies or
organizations should adapt its
recommendations and steps to fit their individual needs. We
encourage you to consider these EA
processes and best practices carefully before pursuing other
approaches.
An electronic version of this guide is available at the following
Internet address: http://www.cio.gov.
If you have questions or comments about this guide, please
contact Rob C. Thomas II at (703) 921-6425,
by email at [email protected], or by mail at:
U.S. Customs Service
7681 Boston Boulevard
Springfield, VA 22153
4 Information Technology Investment Management: A
Framework for Assessing and Improving Process Maturity
(GAO/AIMD-10.1.23, Exposure Draft, 2000).

5 In the Select Phase, the costs and benefits of all available
projects are assessed and the optimal portfolio of projects
is selected. During the Control Phase, the portfolio is
monitored and corrective action is applied where needed. In
the Evaluate Phase, implemented projects are reviewed to
ensure that they are producing the benefits expected and
adjustments are made where appropriate.
mailto:[email protected]
v
February 2001
Credits
This document was produced by the Federal Architecture
Working Group (FAWG) under the strategic
direction of the Enterprise Interoperability and Emerging
Information Technology Committee (EIEITC)
of the Federal Chief Information Officer Council.
The following persons contributed to accomplishing this Guide.

Name Title Agency
Rob C. Thomas, II Dir., Tech. & Arch. Group, Chief Architect
U.S. Customs Service
Randolph C. Hite Dir., Information Technology Systems Issues
General Accounting Office
Ray Beamer Senior Principal Scientist The MITRE Corporation
William H. McVay Senior Policy Analyst Office of Management
and Budget
Elaine Ward Principal Engineer The MITRE Corporation
Keith Rhodes Chief Technologist General Accounting Office
Mary Lou Collins Lead Engineer The MITRE Corporation
George Brundage Chief Architect U.S. Department of the
Treasury
Scott Bernard Management Consultant Booz-Allen & Hamilton,
Inc.
Lester Diamond Assistant Director General Accounting Office
Michael A. Tiemann Dir., Arch. & Stnds. Div., Chief Architect
U.S. Department of Energy
Thomas P. Cullen Policy Analyst U.S. Customs Service
William Lew Technical Assistant Director General Accounting
Office
John Anderson Principal Engineer The MITRE Corporation
Daryl Knuth Information Architect U.S. Customs Service
Barbara Scott Management Analyst U.S. Department of

Education
Paul J. Paradis Management Analyst U.S. Department of Energy
Naba Barkakati Technical Assistant Director General
Accounting Office
Kathy Sowell Lead Engineer The MITRE Corporation
Wayne Shiveley Senior Computer Scientist Federal Bureau of
Investigation
vi
February 2001
vii
February 2001
Table of Contents
Prefaceiii
1.

Introduction............................................................................
............................................................. 1
1.1.
Purpose...................................................................................
..................................................... 1
1.2.
Scope......................................................................................
..................................................... 1
1.3. Audience
...............................................................................................
...................................... 1
1.4. Document Organization
...............................................................................................
............... 2
1.5. How to Use this Guide
...............................................................................................
................. 3
1.6. Related Documents
...............................................................................................

...................... 4
2. Definitions, Drivers, and Principles
...............................................................................................
... 5
2.1. Enterprise Architecture Defined
........................................................................................... ....
.. 5
2.2. The Uses and Benefits of Enterprise Architecture
...................................................................... 5
2.3. Legislation and other Guidance
.................................................................................. .............
... 6
2.4. Architecture
Principles................................................................................
................................ 7
2.5. The Enterprise Life Cycle
...............................................................................................
............ 8

2.6. The Enterprise Architecture Process
........................................................................................... 9
3. Initiate Enterprise Architecture
Program..................................................................................
.... 11
3.1. Obtain Executive Buy-in and Support
...................................................................................... 11
3.1.1. Ensure Agency Head Buy-in and Support
................................................................... 11
3.1.2. Issue an Executive Enterprise Architecture Policy
...................................................... 11
3.1.3. Obtain Support from Senior Executives and Business
Units....................................... 12
3.2. Establish Management Structure and
Control........................................................................... 13
3.2.1. Establish a Technical Review Committee
................................................................... 14
3.2.2. Establish a Capital Investment Council
....................................................................... 14
3.2.3. Establish an EA Executive Steering Committee
.......................................................... 14
3.2.4. Appoint Chief

Architect.................................................................................
.............. 14
3.2.5. Establish an Enterprise Architecture Program
Management Office ............................ 15
3.3. Enterprise Architecture Program Activities and Products
........................................................ 17
3.3.1. Develop an EA Marketing Strategy and Communications
Plan .................................. 17
3.3.2. Develop an EA Program Management Plan
................................................................ 18
3.3.3. Initiate Development of the Enterprise Architecture
................................................... 18
4. Define an Architecture Process and Approach
.............................................................................. 21
4.1. Define the Intended Use of the
Architecture............................................................................
. 22
4.2. Define the Scope of the Architecture
........................................................................................ 22
4.3. Determine the Depth of the Architecture

.................................................................................. 22
4.4. Select Appropriate EA Products
...............................................................................................
23
4.4.1. Select Products that Represent the Business of the
Enterprise .................................... 23
4.4.2. Select Products that Represent Agency Technical Assets
........................................... 24
4.5. Evaluate and Select a Framework
.............................................................................................
24
4.5.1. Federal Enterprise Architecture Framework
................................................................ 25
A Practical Guide to Federal Enterprise Architecture Contents
viii
February 2001
4.5.2. DoD C4ISR Architecture
Framework..........................................................................

27
4.5.3. Treasury Enterprise Architecture
Framework.............................................................. 28
4.6. Select an EA
Toolset....................................................................................
............................. 30
5. Develop the Enterprise Architecture
..............................................................................................
33
5.1. Collect Information
...............................................................................................
.................... 34
5.2. Generate Products and Populate EA
Repository....................................................................... 35
5.2.1. Essentials in Building the Baseline Architecture
......................................................... 36
5.2.2. Essentials in Building the Target Architecture
............................................................ 36
5.2.3. Review, Validate, and Refine Models
......................................................................... 38

5.3. Develop the Sequencing Plan
...............................................................................................
.... 38
5.3.1. Identify
Gaps.......................................................................................
......................... 39
5.3.2. Define and Differentiate Legacy, Migration, and New
Systems ................................. 39
5.3.3. Planning the Migration
...............................................................................................
. 40
5.4. Approve, Publish, and Disseminate the EA Products
............................................................... 41
6. Use the Enterprise Architecture
...............................................................................................
....... 43
6.1. Integrate the EA with CPIC and SLC
Processes....................................................................... 43
6.1.1. Train Personnel
...............................................................................................
............. 45
6.1.2. Establish Enforcement Processes and Procedures

....................................................... 45
6.2. Execute the Integrated Process
...............................................................................................
.. 47
6.2.1. Initiate New and Follow-on Projects
........................................................................... 47
6.2.2. Execute the Projects
...............................................................................................
...... 51
6.2.3. Complete the
Project....................................................................................
................ 52
6.3. Other Uses of the EA
...............................................................................................
................. 54
7. Maintain the Enterprise Architecture
............................................................................................
55
Maintain the Enterprise Architecture as the Enterprise Evolves
........................................................ 55
7.1.1. Reassess the Enterprise Architecture Periodically

....................................................... 55
7.1.2. Manage Products to Reflect
Reality............................................................................. 56
7.2. Continue to Consider Proposals for EA
Modifications............................................................. 57
8. Continuously Control and Oversee the Enterprise
Architecture Program................................. 59
8.1. Ensure Necessary EA Program Management Controls Are
In Place and Functioning............. 59
8.2. Identify Where EA Program Expectations Are Not Being
Met................................................ 59
8.3. Take Appropriate Actions to Address Deviations
.................................................................... 60
8.4. Ensure Continuous
Improvement...........................................................................
................... 60
9. Summary
............................................................................................. ..

............................................ 63
Appendix A: EA Roles and
Responsibilities.......................................................................
.................... 65
Appendix B:
Glossary..................................................................................
............................................. 67
Appendix C: Acronyms
...............................................................................................
............................. 71
Appendix D: Example Architecture
Products..................................................................................
...... 73
D.1. Mission and Vision
Statements...............................................................................
.................. 73
A Practical Guide to Federal Enterprise Architecture Contents

ix
February 2001
D.2. Information Dictionary
...............................................................................................
.............. 73
D.3. Concept of Operations (CONOPS) Graphic
............................................................................. 74
D.4. Activity Models and Trees
...............................................................................................
......... 76
D.5. Business Use Case Model
...............................................................................................
.......... 78
D.6. Class Model
...............................................................................................
............................... 81
D.7. State Model
...............................................................................................

................................ 82
D.8. Node Connectivity
Diagrams.................................................................................
................... 83
D.9. Information Exchange Matrix
...............................................................................................
.... 86
D.10. Organization
Chart......................................................................................
.............................. 87
D.11. Systems Interface Description and Connectivity Diagram
....................................................... 88
D.12. Standards Profile
...............................................................................................
........................ 89
D.13. Technical Reference Model
...............................................................................................
....... 90

Appendix E: Sample Architectural Principles
....................................................................................... 93
Appendix F:
Bibliography...........................................................................
............................................. 97
Appendix G: The Zachman Framework
..............................................................................................
101
x
February 2001
List of Figures
Figure 1. Role of Architecture Principles
...............................................................................................
..... 7
Figure 2. The Enterprise Life
Cycle......................................................................................
....................... 8
Figure 3. The Enterprise Architecture Process

.............................................................................................
9
Figure 4. Notional EA Organization
...............................................................................................
............ 13
Figure 5. Depth and Detail of the
Architecture............................................................................
............... 21
Figure 6. Structure of the FEAF Components
............................................................................................
26
Figure 7. FEAF Architecture
Matrix.....................................................................................
..................... 26
Figure 8. DoD C4ISR Framework
.......................................................................................... .....
.............. 27
Figure 9. DoD C4ISR Products
...............................................................................................
.................. 28
Figure 10. The Treasury Enterprise Architecture Framework
................................................................... 29
Figure 11. TEAF Products
...............................................................................................
.......................... 30

Figure 12. Example Approach for EA
Development...........................................................................
...... 33
Figure 13. Systems Migration Chart
...............................................................................................
........... 40
Figure 14. IMP/Architecture Project Assessment Framework
.................................................................. 44
Figure 15. Architecture Management
...............................................................................................
.......... 45
Figure 16. Define New and Follow-on Programs/Projects
........................................................................ 48
Figure 17. Execute Programs/Projects
...............................................................................................
......... 51
Figure 18. Evaluate Programs/Projects
...............................................................................................
........ 53
Figure 19. Enterprise Architecture Transition
............................................................................................
56
Figure 20. Key Success Factors
...............................................................................................
................... 61

Figure 21. DoD Battlespace Concept of Operations Graphic
..................................................................... 74
Figure 22. U.S. Customs Service Trade Compliance Concept of
Operations Graphic............................... 75
Figure 23. Generic IDEF Activity Model
...............................................................................................
.... 77
Figure 24. U.S. Customs, ACS, Activity Tree
............................................................................................
77
Figure 25. U.S. Customs, Trade Compliance, UML Activity
Model ......................................................... 78
Figure 26. U.S. Customs, Trade Compliance�External, UML
Use Case Diagram .................................. 79
Figure 27. U.S. Customs, Trade Compliance�Internal, UML
Use Case Diagram ................................... 79
Figure 28. U.S. Customs, Trade Compliance, Declare Goods,
UML Use Case Specification ................... 80
Figure 29. U.S. Customs, Trade Compliance, Commercial View,
UML Class Diagram........................... 81
Figure 30. U.S. Customs, Trade Compliance, Carrier, UML
State Diagram ............................................. 82
Figure 31. U.S. Customs, ACS, Customs Systems, Node
Connectivity Diagram ...................................... 84
Figure 32. U.S. Customs, ACS, N2

Chart......................................................................................
.............. 85
Figure 33. U.S. Air Force Node Connectivity Diagram
............................................................................. 86
Figure 34. Generic Organization
Chart......................................................................................
................. 88
Figure 35. Generic System Interface Description Connectivity
Diagram .................................................. 89
Figure 36. Standards Profile Table
...............................................................................................
.............. 90
Figure 37. U.S. Customs Technical Reference
Model................................................................................ 90
Figure 38. Generic TRM Domain and Sub-domain Definitions
and Components ..................................... 91
Figure 39. The Zachman Framework
Matrix.....................................................................................
....... 102
xi
February 2001

List of Tables
Table 1. EAPMO Roles and Responsibilities
.............................................................................................
17
Table 2. Framework Selection Criteria
...............................................................................................
....... 25
Table 3. Tool Selection Criteria
...............................................................................................
.................. 31
Table 4. Baseline and Target Architecture Differentiators
........................................................................ 35
Table 5. EA Review
Goals......................................................................................
.................................... 50
Table 6. Example Logical Information Exchange Matrix
......................................................................... 87
1
February 2001
1. Introduction

1.1. Purpose
The purpose of this document is to provide guidance to Federal
Agencies in initiating,
developing, using, and maintaining an enterprise architecture
(EA). This guide offers an end-to-
end process to initiate, implement, and sustain an EA program,
and describes the necessary roles
and associated responsibilities for a successful EA program.
An EA establishes the Agency-wide roadmap to achieve an
Agency�s mission through optimal
performance of its core business processes within an efficient
information technology (IT)
environment. Simply stated, enterprise architectures are
�blueprints� for systematically and
completely defining an organization�s current (baseline) or
desired (target) environment.
Enterprise architectures are essential for evolving information
systems, developing new systems,
and inserting emerging technologies that optimize their mission
value. While some agencies have
enterprise architectures in place, others do not. For agencies
that already have an EA in place,

this guide should be tailored to fit these Agencies� needs. For
smaller agencies, a streamlined
version of the guide should be created to support the needs of
the Agency.
1.2. Scope
This guide focuses on EA processes, products, and roles and
responsibilities. While this guide
addresses the enterprise life cycle, it describes in detail how the
EA processes relate to enterprise
engineering, program management, and capital planning and
investment control (CPIC)
processes.
The breadth and depth of information presented here should be
tailored to your organization.
Some examples are presented in the appendices, and references
to supplementary material are
included in the text or bibliography. Feel free to individualize
these examples as needed.
1.3. Audience
This guide is intended primarily for Federal Agency architects

tasked with the generation and
institutionalization of EAs. This document provides guidance
to Agencies that currently do not
have EAs and those that can benefit from improvements in their
EA methods for development
and maintenance. For Agencies without an EA, this document
provides useful guidance to the
Agency Head and the Chief Information Officer (CIO) for
educating and obtaining key
stakeholder commitment in establishing an effective EA.
This guide is also aimed at CPIC process participants [e.g.,
investment review boards, and the
Office of Management and Budget (OMB)], as well as
enterprise engineering and program
management process participants (e.g., program/project
managers, systems engineers, application
architects, systems developers, configuration managers, risk
managers, and security engineers).
Although the guide specifically addresses the roles and
responsibilities of major players in the
architecture development process, it is also a handbook for
anyone who needs to know more
about the EA process. Regardless of your role or

responsibility�whether you have sole
responsibility for EA development or are a member of an
architecture team�if you are involved
in the enterprise life cycle, this guide is for you.
A Practical Guide to Federal Enterprise Architecture
Introduction
2
February 2001
1.4. Document Organization
The document is organized as follows:
Section 1: Introduction Defines the purpose, scope, audience,
and
organization of the document.
Section 2: Definitions, Drivers,
and Principles
Presents the context for the EA process, i.e.,

principles and legislative drivers, and defines the
architecture development, implementation, and
maintenance process.
Section 3: Initiate Enterprise
Architecture
Program
Defines EA program procedural steps to initiate the
program, typical EA organization, and products of
the EA.
Section 4: Define an
Architecture Process
and Approach
Defines a process for building an enterprise
architecture and describes federally developed
frameworks.
Section 5: Develop the
Enterprise
Architecture
Provides the procedural steps for developing baseline

and target architectures and a sequencing plan.
Section 6: Use the Enterprise
Architecture
Demonstrates how the EA process interacts with
capital planning and investment control and with the
Systems Life Cycle.
Section 7: Maintain the
Enterprise
Architecture
Discusses processes and procedures to maintain EA
products throughout the life-cycle process.
Section 8: Continuously
Control and Oversee
the EA Program
Section 9: Summary
Provides guidelines to ensure EA processes and
practices are being followed and remedies and
corrective actions applied when warranted.

Presents highlights of the EA guide and provides
final recommendations for the initiation and
implementation of a successful EA program.
Appendix A: EA Roles and
Responsibilities
Provides a concise description of key personnel roles
and responsibilities for EA development,
implementation, and maintenance.
Appendix B: Glossary Provides a definition of terms used
within this
document.
Appendix C: Acronyms Provides a list of all acronyms used
within this
document.
Appendix D: Example
Architecture
Products
Provides sample EA essential and supporting

products.
A Practical Guide to Federal Enterprise Architecture
Introduction
3
February 2001
Appendix E: Sample
Architectural
Principles
Describes samples of the essential architectural
principles that are a starting point in the architecture
process.
Appendix F: Bibliography Provides a list of key documents used
during the
development of this guide and other informative
source documentation.
Appendix G: The Zachman
Framework

Presents a brief background and description of the
Zachman Framework and its application to enterprise
architecture.
1.5. How to Use this Guide
This guide is a �how-to� manual for Federal Agency architects
and stakeholders in the initiation,
development, use, and maintenance of EAs. To find an answer
to your specific need or question,
please consult the following table for frequently asked
questions. These and many other
questions are answered throughout the guide.
Question Section
1. Why develop an EA? 2.0
2. What are the primary benefits of using an EA? 2.0
3. What are the legislative drivers and mandates for using an
EA?
2.0

4. What is the Enterprise Life Cycle? 2.0
5. What is a baseline architecture? 2.0
6. What is a target architecture? 2.0
7. What is a sequencing plan? 2.0
8. How does the EA process relate to the CPIC process? 3.0
9. Who is responsible for architecture policies? 3.0
10. Who is responsible for the EA? 3.0
11. How does one market the selected approach to senior
executives?
3.0
12. What are frameworks and how do I select one? 4.0
13. How do I create a baseline or target architecture? 5.0
14. How do I transition from the baseline to the target? 5.0

15. How is the EA used within the CPIC process to justify
information technology investments?
6.0
16. How do architecture processes relate to other enterprise
engineering activities?
6.0
17. How does a project manager or application architect ensure
alignment to the EA when proposing a new project?
6.0
18. How do I maintain the EA in the midst of evolving systems
and new business requirements?
7.0
19. What are the organizational roles and responsibilities when
Appendix A

A framework for information systems architecture by J.docx

A framework for information systems architecture by J.docx

Recommended

Recommended

More Related Content

Similar to A framework for information systems architecture by J.docx

Similar to A framework for information systems architecture by J.docx (20)

More from evonnehoggarth79783

More from evonnehoggarth79783 (20)

Recently uploaded

Recently uploaded (20)

A framework for information systems architecture by J.docx