ENTERPRISE ARCHITECTURE
AND LEGACY SYSTEMS
Printable
PDF Version
Getting Beyond the "Legacy"
by John A. Zachman, President, Zachman
International
© Copyright 1993-1996 Zachman International, Inc
![[HRule Image]](../~ieinfo/images/div.gif)
 John Zachman - "Enterprise
Architecture and Legacy Systems"
In the early '80's, there was little interest in the idea of
Enterprise Reengineering or Enterprise Modeling and the use of
formalisms and models was generally limited to some aspects of
application development within the Information Systems community.
The subject of "architecture" was acknowledged at that
time, however, there was little definition to support the
concept. This lack of definition precipitated the initial
investigation that ultimately resulted in the "Framework
for Information Systems Architecture." Although from the
outset, it was clear that it should have been referred to as a "Framework
for Enterprise Architecture," that enlarged perspective
could only now begin to be generally understood, as a result of
the relatively recent and increased, world-wide focus on
Enterprise "engineering".
The Framework as it applies to Enterprises is simply a logical
structure for classifying and organizing the descriptive
representations of an Enterprise that are significant to the
management of the Enterprise as well as to the development of the
Enterprise's systems. It was derived from analogous structures
that are found in the older disciplines of
Architecture/Construction and Engineering/Manufacturing that
classify and organize the design artifacts created over the
process of designing and producing complex physical products
(e.g. buildings or airplanes.)
The Framework graphic in its most simplistic form depicts the
design artifacts that constitute the intersection between the
roles in the design process, that is, OWNER, DESIGNER and
BUILDER; and the product abstractions, that is, WHAT (material)
it is made of, HOW (process) it works and WHERE (geometry) the
components are, relative to one another. Empirically, in the
older disciplines, some other "artifacts" were
observable that were being used for scoping and for
implementation purposes. These roles are somewhat arbitrarily
labeled PLANNER and SUB-CONTRACTOR and are included in the
Framework graphic that is commonly exhibited. The Framework, as
it is applied to an Enterprise, depicting Enterprise design
artifacts (models,) using Enterprise terminology appears in
Figure 1.
Figure 1 - The Zachman
Framework for Enterprise Architecture, showing the main three
columns: DATA (What); FUNCTION (How); and NETWORK (Where). Each
row shows models addressing the perspective of the Planner (Row
1), the Owner (Row 2), the Analyst (Row 3), the Programmer (Row
4) and the Maintainer (Row 5).
From the very inception of the Framework, some other product
abstractions were known to exist because it was obvious that in
addition to WHAT, HOW and WHERE, a complete description would
necessarily have to include the remaining primitive
interrogatives: WHO, WHEN and WHY. These three additional
interrogatives would be manifest as three additional columns of
models that, in the case of Enterprises, would depict: WHO does
what work, WHEN do things happen and WHY are various choices
made. The state of the art in terms of modeling formalisms, as
well as the inclination to devote energy to produce these
additional artifacts is still somewhat limited, certainly in the
case of Enterprises. The first three columns of models are quite
adequate to draw some substantive conclusions, and therefore, in
the interest of simplicity, the "other three columns"
are being set aside for purposes of this discussion.
The older disciplines of Architecture and Manufacturing have
accumulated considerable bodies of product knowledge through
disciplined management of the "product definition"
design artifacts. This has enabled enormous increases in product
sophistication and the ability to manage high rates of product
change over time. Similarly, disciplined production and
management of "Enterprise definition" (i.e. the
set of models identified in the Framework for Enterprise
Architecture) should provide for an accumulation of a body of Enterprise
knowledge to facilitate enormous increases in Enterprise
sophistication and accommodation of high rates of Enterprise
change over time.
Although the Framework for Enterprise Architecture is an
application of Framework concepts to Enterprises, the Framework
itself is generic. It is a comprehensive, logical structure for
descriptive representations (i.e. models, or design artifacts) of
any complex object and is neutral with regard to the processes or
tools used for producing the descriptions. For this reason, the
Framework, as applied to Enterprises, is helpful for sorting out
very complex, technology and methodology choices and issues that
are significant both to general management and to technology
management.
For example, out of the context of the Framework, it is
becomes clear why management and the users are in many cases so
frustrated with the current inventory of existing applications,
"the legacy." The frustration clearly is not because
there are too many applications. Or too few. Or because they are
not strategic enough. Or because they are mainframe, or
hierarchical, or COBOL, or whatever. The "legacy" is
not a technology problem. It is an architecture problem.
The "legacy" frustration arises from three
fundamental, architectural deficiencies.
First, in general, Rows 1, 2 and 3 models were seldom built
... and in many cases, Row 4 models were not even built (see
Figure 2). The models which are not explicitly produced are
implicitly assumed by default, and a lot of assumptions were made
which have since proven to be, or have become, erroneous.
Furthermore, the Rows 1 and 2 models can change as fast as
Management can change their minds, whereas the Row 5
implementations are "poured in concrete," resembling
hundred story buildings. There simply is no way to keep the Row 5
reality in synch with the Row 2 perceptions without explicit
formalizations and configuration control of the intermediate Row
models as is done for physical products.
Second, the functional aspect of the systems was optimized at
the expense of the data and the network for implementation
expediency, that is, the data and hardware/systems software were
tailored to the application and therefore disintegrated with
regard to the Enterprise. Semantic and network discontinuities
were created such that now, files can't be related nor nodes
connected and as a result, "maintenance" of the
"legacy" now consumes the "lion's share" of
the I.T. resources. Worse, the energy of the Enterprise is
consumed attempting to reconcile the semantic discontinuities and
overcome communication complexities.
Third, the Enterprise has simply changed around the existing
applications and these applications were built under the
assumption that nothing would ever change. This is clear because
the only application models that are left in many cases are those
that are machine readable ... Row 6. If anything changes in Rows
1, 2, 3, 4, or 5 above, those models in which the change occurs
have to be "reverse engineered" from whatever
information remains in Row 6. Some people liken this process to
Archeology, that is, it is very costly and there is questionable
confidence in its accuracy or even "do-ability."
SOURCES OF "LEGACY" FRUSTRATION
Figure 2 - The Sources
of Legacy Frustration. In past years we did not build Row 1, 2 or
3 models (for the Planner, the Owner or the Analyst)... and
sometimes not even Row 4 models (for the Programmer). We
therefore disintegrated the Enterprise data and network. Today
all we are left with are the machine-readable, legacy systems in
Row 6.
Now, the message to current Enterprise management as well as
application developers is quite poignant out of the context of
the Enterprise Framework. If these architectural issues are
not being explicitly addressed in current Enterprise
engineering and/or systems development projects, that is:
- if Rows 1, 2, 3, and 4 models are not being formally
defined,
- if steps are not taken to preserve Enterprise-wide
integration of Columns 1 and 3 models, and
- if all models produced are not being retained for change
management purposes,
then, we are clearly building more " legacy".
We may well gain some temporary respite from the stress
that is inherent in the existing inventory of systems, but the
frustration and aggravation, not to mention the cost and
complexity of maintaining the "legacy" and the
Enterprise's inflexibility and unresponsiveness to change, is
bound to intensify as the Enterprise presses on into the dynamic,
turbulent, "Information Age." All the innovative
technology "solutions" in the world including very good
things like Data Warehouse, Object-Oriented, Client-Server,
Parallel Processing, etc., etc. serve only to help build more
"legacy" faster. We have to satisfy short term
demand, but at the same time, it becomes obvious from looking at
the "legacy" in the context of the Framework, if we
ever intend to be free from the "legacy" problem, WE
MUST FIRST ADDRESS THE ENTERPRISE ARCHITECTURE ISSUES!!
The Framework for Enterprise Architecture can be employed as a
thinking tool to help understand a variety of complex issues and
to develop deliberate and enduring strategies for creating
flexible and agile, modern-day Enterprises designed to
accommodate the vagaries and capriciousness of the
"post-industrial" society.
Back to Contents.
References
- "A Framework for Information Systems
Architecture", John A. Zachman, IBM Systems
Journal, Vol 26, No 3, 1987. IBM Publication G321-5298
(Phone: +1-914-945-3836 Fax: +1-914-945-2018).
- "Extending and Formalising the Framework for
Information Systems Architecture", J.F. Sowa and
J.A. Zachman, IBM Systems Journal, Vol 31, No 3, 1992.
IBM Publication G321-5488 (Phone USA: +1-800-879-2755).
- "The Challenge is
Change" by John Zachman,
President, Zachman International. Published on IES Web
Site, May 1996.
Back to Contents.
The Author
John Zachman is the
author of the "Framework for Information Systems
Architecture", which has received broad acceptance
throughout the world as an integrative framework for managing
change in Enterprises and in the systems that support them. He is
not only known for this work, but also for his early
contributions to Business Systems Planning, IBM's widely
used information planning methodology in the 1970s, as well as Intensive
Planning, the basis for IBM's executive, team planning
techniques.
Mr Zachman has focused on planning and information strategies,
and on architecture, since 1970 and has written many articles on
these subjects. He travels nationally and internationally,
teaching and consulting, and has facilitated innumerable
executive team planning sessions. He is a popular conference
speaker known for motivating messages on information issues. He
has spoken to thousands of information professionals and business
managers on every continent.
John Zachman is a member of the International Advisory Board
of the Data Administration Management Association, DAMA
International; a member of the International Information Resource
Management Advisory Council of Smithsonian Institution in
Washington DC; and of the Board of Directors of the
Repository/Architecture/Development Users Group.
John A. Zachman
Zachman International
2222 Foothill Blvd. Suite 337
La Canada, Ca. 91011
Int'l Phone: +1-818-244-3763
Int'l Fax: +1-818-244-3763
Back to Contents.
|