|
|
|
|
|
|
|
|
|
|
THE FRAMEWORK FOR ENTERPRISE ARCHITECTURE: Getting Beyond the "Legacy" by John A. Zachman 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 below.
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. 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. 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
Third, the Enterprise has simply changed around the existing applications and these applications were built under the assumption that nothing would ever change. 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: a. if Rows 1, 2, 3, and 4 models are not being formally defined, b. if steps are not taken to preserve Enterprise-wide integration of Columns 1 and 3 models, and c. 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. References 1. "A Framework for
Information Systems Architecture." John A. Zachman. IBM Systems Journal,
vol. 26, no. 3, 1987. IBM Publication G321-5298. 914-945-3836 or fax:
914-945-2018. 2. "Extending and
Formalizing 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. 1-800-879-2755. © Copyright
1993-1996 Zachman International, Inc. A |
|
||||||||||
|
ABOUT OUR SITE Our web site provides a full description of our quality services, links to employment opportunities, information regarding employment through MTA, and special content reserved for our sub-contracted professionals. We encourage feedback from our readership to further assist in the continued improvement of this site and our services. |
||||||||||
|
|
||||||||||
|
© Copyright 2017 Merritt Technical Associates, Inc. All Rights Reserved. |
