Business Process Implementation for IT Professionals
by Robert B. Walford
ISBN: 0890064806

Artech House © 1999 (599 pages)
An all-inclusive roadmap to help you convert business practices into
applications to facilitate those same business practices.
Table of Contents

Business Process Implementation for IT Professionals and Managers

Foreword

Preface

Chapter 1 -

Introduction

Part I - Automation asset management

Chapter 2 -

Automation asset system

Chapter 3 -


-

Role modeling

Chapter 11

-

Information modeling

Chapter 12

-

Client/server modeling

Chapter 13

-

Dialog and action modeling

Chapter 14

-

Software component modeling

Chapter 15


Chapter 20

-

Step 3: Specify actions

Chapter 21

-

Step 4: Map actions

Chapter 22

-

Step 4(a): Provision software components

Chapter 23

-

Step 5: Design human interface

Chapter 24

-

Step 6: Determine workflow

Business Process Implementation for IT
Professionals and Managers
Robert B. Walford
Library of Congress Cataloging-in-Publication Data
Walford, Robert B.
Business process implementation for IT professionals and managers
/ Robert B. Walford.
p. cm. — (Artech House software engineering library)
Includes bibliographical references and index.
ISBN 0-89006-480-6 (alk. paper)
1. Management information systems. I. Title. II. Series.
T58.6.W324 1999
658.4’038—DC21 99-18034
CIP
British Library Cataloguing in Publication Data
Walford, Robert B.
Business process implementation for IT professionals and
managers. — (Artech House software engineering library)
1. Management information systems 2. Data transmission
systems 3. Business — Communication systems
I. Title
658.05’46

ISBN 0-89006-480-6

Cover design by Lynda Fishbourne
© 1999 ARTECH HOUSE, INC.
685 Canton Street
Norwood, MA 02062
All rights reserved. Printed and bound in the United States of America. No part of this

infrastructure specification, application architecture, technology planning, and project
management. Specific technologies of interest are component architectures, knowledge
management, business rules, and decision support.
His academic experience includes the teaching of circuit design and mathematics
courses as an assistant professor of electrical engineering at the University of Southern
California. He was also an adjunct professor in the Computer Science and Engineering
Department of the University of South Florida, teaching graduate and undergraduate
courses in software engineering and data communications. He also served as an
engineering accreditation visitor for the Accreditation Board for Engineering and
Technology (ABET) and was responsible for examining and evaluating the computer
engineering curriculum in a number of universities as part of their periodic accreditation
process.
As a participant in the initial international standards efforts for intelligent networks, Dr.
Walford originated the four-layer reference model, which is at the core of current
intelligent network standards. For that work, he received a Warner Award, the highest
recognition that GTE Corporation gives for technical achievement.
In addition to Business Process Implementation for IT Professionals and Managers, he is
the author of three books on information networks and systems published by Addison-
Wesley in 1990: Information Systems and Business Dynamics, Network System
Architecture, and Information Networks: A Design and Implementation Methodology. He
also has authored and presented numerous talks and articles on management,
telecommunications, and software engineering topics.
Dr. Walford is a registered professional engineer in Florida, Illinois, and California and a
certified public accountant. He is a senior member of the Institute of Electrical and
Electronic Engineers and a member of the National Society of Professional Engineers,
the Florida Engineering Society, and the American Institute of Certified Public
Accountants. Foreword

constraints and hazards of the enterprise environment.
A systems engineering approach is therefore advocated. A systems engineering
approach defines customer needs and required functionality early in the development
cycle and follows a structured development process in which technology components are
combined to end up with working systems that meet the requirements. A systems
engineering approach is eclectic in that it integrates several relevant disciplines and
specialty groups into a team effort. Besides expertise embodied in the components, the
structured development process must include provisions to handle, from concept to
production to operation and ultimately replacement or disposal, cost and schedule;
training and support, quality assurance, testing, and performance; and system
integration, deployment, and disposal.
If asked, Dr. Walford might call himself Bob the technologist. He has been an ardent
observer of information technology trends, tracking, assessing, and, when appropriate,
championing adoption of new technologies in the corporation. He writes about some of
those topics in this book. As you will see, Bob the technologist does not believe in silver
bullets, panaceas, or overnight cures. But we can depend on him for insight, prudence,
and commonsense guidance.
It is hoped that understanding where the author is coming from will help readers know
where they are going. But enough about Bob(s)!
A concise statement of the theme of the book is the assertion (in Chapter 1) that
“management by process itself requires a process.” A process for managing processes,
that is, a methodology, has as one of its dimensions a set of coordinated modeling
activities and guidelines (presented in Part III). Another dimension of the methodology is
a conceptual framework for capturing specifications of information systems (Part II). The
products of the methodologists’ labors, primarily the populated models, are viewed as
assets having a life cycle, with the life cycle supported by such things as repository
technology, financial management, and business rules, among other things (Part I).
Preceding the three parts of the book is an introduction that articulates prerequisites,
principles, and perspectives. In particular, there is cogent reflection on the significant
business and technology factors that motivate management by process, rationale for the

rules, is not yet mature, an activity for determining workflow is included in the
methodology as an indication of the trend toward using workflow technology to
implement business processes. In contrast, the systems we have inherited as our legacy
are not built on workflow platforms; it is proposed here that adopting workflow
technologies will reduce some of the problems of creating new systems (our new
legacies) and will facilitate integration and evolution.
Besides business rules and workflow, it is clear that many more concepts and
technologies impinge on process implementation methodology: knowledge management,
document management, and integration architectures, just to mention a few. At several
points in the book, the author appears poised to cover those topics, but there are limits to
what one book can cover. We could not expect more from a single volume.
I believe there is a substantial body of professionals, both technical and nontechnical, as
well as teachers and students, who should read this book to reap the benefits of the
assembled knowledge and views. I see the book as a key resource, inhabiting an
environment where process implementation methodology is a defined area of expertise
and where a group of appropriately trained individuals is a center of excellence to
provide necessary technical and organization skills. Thus, the book contents alone are
not enough. There must also be an explicit intention to act and to back the associated
activities with the necessary resources. There must be a commitment to the belief that
the process implementation methodology is one of the most important business
processes in the organization.
In fact, I would venture to say that the ability of an enterprise to perform the
methodological aspects of its operations will, in the coming years, become more
important than a majority of its other business processes. As technology domains mature
and technology components (e.g., software applications and services provided over
networks) become more specialized and standardized, a primary differentiator between
enterprises may be the quality of the process implementation methodology rather than of
the business processes specific to the domain. That could be considered a somewhat
radical view, namely, that the critical success factor of a telecommunications company,
for example, could depend at least as much on process implementation methodology as

such as conversations, text, and real-world scenes. Implementors use more formal,
rigorous representations as they consider system designs and get closer to procedures
that execute on computers. Business is learning to be more rigorous in its process
descriptions, and IT is learning to reciprocate by utilizing methods that tolerate some
ambiguity and incompleteness (rather than, for example, forcing specifications into molds
for the sake of direct implementation). The progression from the more freeform,
unstructured languages to the more formal, structured ones is one of the obstacles the
methodology is supposed to overcome by gradually transitioning from one to the other.
The methodology in this book addresses that issue (often called the requirements gap)
to a significant degree. It is a prescription for how the two camps can interact on a
constructive basis.
In conclusion, it is an admirable task indeed for the many Robert Walfords to have
assembled and so plainly presented the material in this book, which is both deep in
concept and broad in scope.
Sol Greenspan Preface
The King is dead; long live the King! That famous cry sums up most aspects of modern
business practice. The previously existing competitive environment, scope, internal
structures, and automation support needs of an enterprise have disappeared and been
replaced by other sets of conditions and requirements. In time, those needs, too, will
disappear and be replaced by yet another set and much more quickly than before. The
concept of “Internet years” applies to most aspects of modern life. To stay viable, an
enterprise must learn to live with the new king and begin to prepare itself for the next
one, who inevitably will arrive when least expected.
From an information technology (IT) perspective, we recently have converted from a
centralized mainframe environment to one with a distributed client/server structure. Even
before the latter environment began to stabilize, the rapid emergence of the Internet has
created the need for yet another version with its own needs and constraints. This swift

such were the case, many such methodologies probably would be available. An effective
methodology must fit into the current and projected enterprise business and technical
environments. It also must provide a means to solve the four generic business problems:
decrease costs, reduce time to market, increase quality, and provide greater value for
the customer. PRIME provides a way to meet all those requirements while staying
focused on process implementation.
The development of PRIME rests on three supporting concepts: systems engineering,
automation assets, and modeling. A systems engineering approach permits the many
needed technology and business concepts to be considered as an integrated whole
rather than as isolated entities. An automation asset view ensures that the entities
utilized in process specification and implementation are correctly managed and their
inherent value to the enterprise understood. Extensive modeling is used throughout the
presentation to define and structure the discussions and permit a relatively rigorous
examination of the principles, concepts, and entities involved.
In many current instances, the specification of enterprise automation emphasizes
technology and products with only a passing mention of an associated methodology.
Technology and products, no matter how well conceived and designed, cannot be
effectively employed without methodology. Even when methodologies are utilized, they
involve previous methodologies that were developed for centralized computing
architectures and that are no longer appropriate. Many current methodologies are based
on either data or control specifications and were first defined in the mid-1970s, when the
software development and deployment environment was considerably different from
what it is now. Although the existing methodologies have been adapted over the years to
some extent, their basic approach has not changed, and they still are unable to
accommodate the needs of a process orientation efficiently.
In addition, these existing methodologies have a number of other disadvantages when
they are applied to the emerging environment: For example, they do not take advantage
of reuse; they are hard to adapt to a distributed deployment environment (e.g.,
client/server configurations); they do not adequately consider the human interfaces; they
do not involve the stakeholders as an integral part of the development process; they

reasons for—and the details of—the design and construction of the methodology. The
presentation is useful in and of itself as a guide to the confusing set of forces causing the
current upheaval in the business environment. However, the main purpose of Chapter 1
is to motivate the remainder of the discussion.
Part I is concerned with the concept of automation assets and their management. The
concept of automation assets provides the framework for the definition and analysis of
the entities needed in the specification of the methodology. It also allows their
interactions to be defined and considered in a structured and natural way. The asset
management system is modeled using five interacting components: life cycle
management, financial management, business rules, repositories, and the automation
assets themselves. The common characteristics developed in Part I are applied to all
automation assets considered in Part II.
Part II is concerned with the modeling of the automation assets needed for the definition
of PRIME, consistent with the direction and requirements of asset management. A key
presentation is concerned with the reuse of software components. Reuse of the various
elements involved in the specification and development of software has been a constant
focus since early computers. Until now, that has never been successfully accomplished
except for a few isolated and rather specialized instances. An approach to a feasible
method of achieving reuse success is presented in this discussion and incorporated as
an integral part of the PRIME methodology.
Part III contains the design and specification of PRIME using the information developed
in Parts I and II. PRIME is based on an adaptation of the spiral approach to design and
implementation. In that type of approach, the basic steps of a methodology are reinvoked
over and over with an increase in detail and structure after each iteration or spiral. While
it is possible to design a methodology with only one spiral that includes all the
methodology steps, several problems are associated with that approach: The complexity
of its application to a development of significant size is difficult to manage; parallel
activities are not possible; and iteration over a subset of activities is not easily defined.
For those reasons, PRIME utilizes multiple overlapping spiral types within the overall
spiral definition. That allows iteration over all the steps or a subset, as desired. Seven

at GTE, for providing the environment and encouragement that allowed the development
and refinement of this innovative methodology. Girish Pathak, vice president and director
of the operations system laboratory at GTE Laboratories, and Mary Reiner, director of
enterprise systems, are also due a considerable amount of appreciation for their efforts
on my behalf. Thanks and recognition are also richly deserved by the many associates
who worked on the development and validation of the methodology during some aspect
of its development. They include Truman Mila and Mark Feblowitz, to whom this book is
dedicated, as well as Carl Pulvermacher, Nancy Amburgey, Ken Dilbeck, and David
Wang, who participated in the pilot application of the methodology. Thanks are also due
to Mark Lapham and Jeff Gilliam of Anderson Consulting, who contributed to the early
development sessions.
I also would like to thank the many colleagues who participated in the early trials and
initial production use of the methodology. Their patience, humor, and helpful suggestions
for improvement were of invaluable help in making the methodology a success.
Robert B. Walford
April 1999 Chapter 1: Introduction
Overview
Our world has become almost totally dependent on software for its proper functioning.
From the control of airplanes to the control of large enterprises, the need to rapidly
develop and utilize reliable and cost-efficient software is of utmost importance.
The development of software to control devices seems to be progressing at a relatively
steady pace. The new Boeing 777 aircraft, for example, is almost entirely controlled by a
fly-by-wire structure that is enabled through the use of complex distributed software. In
addition, most of the testing of the aircraft was done entirely through computer simulation
techniques that provided significant savings while enabling on-time delivery of a more
thoroughly tested product.
That same level of progress does not seem to apply to the use of software that supports

in Dickens’s novel, we are trying to live and survive in a world where we have only
imperfect knowledge of the dynamics, and it is difficult to know how to identify and take
advantage of the opportunities that occur. An additional complication is that the current
rate of change is far greater than in Dickens’s time. The concept of “Internet years” is
very real. The future cannot be ascertained with any certainty because it is a function of
the unknown dynamics. The temptation is to look for shortcuts, to follow the latest fast-
talking pitch man who promises an easy answer to our problems, and to be satisfied with
a fast small reward rather than working toward large future gains.
The author hopes that this book will be a factor in avoiding those temptations and, by
addressing at least one important area of concern, will aid in coping with the unceasing
change that pervades our profession. The specific subject of interest is the revolution in
need for enterprise automation and the most effective means for providing flexible
workable solutions that will not rapidly become obsolete. 1.2 Discussion organization
The formation of a business automation methodology is approached here through the
use of a system engineering approach to specify the structural elements and their
interrelationships. The overall structure of this book is shown in Figure 1.1.

Figure 1.1: Automation methodology determination structure.
First, the major business drivers and associated requirements are identified and
examined. Second, the major technology drivers that affect the enterprise are defined
and discussed. With those business and technical drivers as a base, a set of automation
requirements and principles are specified. Those requirements are then converted into a
set of automation assets and an associated asset management system. The asset
management system ensures that the proper assets are available when needed. The
automation assets are utilized by the methodology to create specific elements of the
enterprise automation environment. The enterprise automation environment architecture
is based on workflow model.

business rules discussed in Chapter 5.
Although this discussion focuses on the business requirements, a number of business
drivers also greatly affect the operation of the enterprise. They include changes in
regulatory and legal requirements, changes in the competitive landscape (e.g., mergers,
bankruptcies, startups), and changes in executives and other key personnel. As with the
requirements already discussed, the drivers also greatly affect the way in which the
enterprise must operate. 1.4 Business structures
In the classical business structure of the recent past, the organization is hierarchical and
the information processing function based. The hier- archical organization model was
based on the centuries-old military structure that emphasized command and control at
each level of the organization. That type of rigid structure evolved because it was the
only model then known that was suitable for a large organization. Because organizations
tended to grow larger with the advent of industrialization, it was only natural that this type
of structure would dominate.
The evolution of functionality-based information processing also occurred for similar
historical reasons, although, of course, the evolution occurred much later. When
computers were first applied to the hierarchical organization to reduce the amount of
manual information processing, it was only natural that the automated information
processing would mirror the specific functions of its manual predecessor. Thus, the
concept of the information system that performed some specific set of functionality such
as payroll, accounts payable, order entry, and inventory came about. Each of those
systems was independent of the others and was considered to be owned by the
organization that historically performed its function. Because of the way they are
sometimes pictured, those systems are sometimes called vertical silos of automation
(Figure 1.2). In the figure, the line that winds through the silos represents the path
followed to fulfill a customer’s request. The systems generally are utilized on an ad hoc
basis as each organization becomes involved and provides its function.

enterprise, the operational structure of the enterprise, and the application of technology
(automation) to the operation of the business. While the last trend is of most importance
to the thrust of this presentation, it is necessary to place it in the context of the other two
to fully understand the consequences and opportunities that are beginning to arise.
The organization of the enterprise is changing in three basic ways. The first change, as
mentioned previously, is that the number of layers in the organization is being greatly
reduced. This “flat” organization requires methods of both informal and formal
communications as well as automated support that is different from that of organizations
with a hierarchical structure.
The second change, which follows directly from the first, is that the number of employees
is also being greatly reduced. More, in fact, than the workload would ordinarily allow.
That is being mitigated by the formation of self-directed and other types of work teams
that perform a large number of management and administrative tasks formerly performed
by the displaced middle managers in addition to the work performed for the benefit of the
customer. The availability of automation to assist individual team members as well as the
team as a whole has contributed significantly to the ability of the team to provide the
required productivity. Because of the closeness of the team to the customer and work
performed, there probably is some improvement in overall efficiency, although the final
verdict on this type of structure is still a long way off.
The second and by far the most important mitigation for a reduced work force is the use
of consultants and outsourcers to perform work previously accomplished by employees.
Although their cost may be initially greater than before, exposure to increasing benefits
cost is avoided along with social and regulatory restrictions on reducing the work force
when necessary.
Those changes in organizational structure and staffing require a corresponding change
in the way the enterprise must operate. The reduction in the number of hierarchical
levels and employees can no longer support functional partitioning with the large number
of interfaces that must be managed and maintained. Reducing the number of interfaces
requires that cross-functional views of the organization be taken.
That leads to the third fundamental enterprise change. The operational emphasis of the

reengineering is merely the action of trying to determine a more efficient process for
performing some aspect of the enterprise operation. Although process reengineering
seemingly focuses on process, in many cases it focuses on a single organization or
function within an enterprise (e.g., accounts payable) and, except at a very rudimentary
level, does not require much in the way of a process orientation.
In this discussion, the emphasis is on the process management philosophy. The
determination of suitable processes, while of considerable importance, is relegated to the
automation methodology. That ensures that the selected processes can be efficiently
incorporated into the enterprise automation system.
1.5.1 Major implications
The first part of this discussion has addressed the major forces on the enterprise and
some of the actions, including the adoption of a process-oriented management
paradigm, that have been taken to respond to those pressures. No significant change is
ever undertaken without an associated set of implications, some probably advantageous
and some not so advantageous. To determine how the automation needs of the
enterprise are affected by a process-oriented approach, it is necessary to examine some
of the organization, financial, and software implications of the process paradigm.
Although the organizational and financial implications may not immediately seem
pertinent, in reality, they have an enormous impact on how the automation needs are
defined and obtained. That impact will become clearer as the discussion proceeds.
1.5.1.1 Organization
In addition to the changes in organization structure occurring as a result of the enterprise
pressures, additional organizational implications occur as a direct result of the utilization
of a process-based management approach. In one aspect, processes can be defined
independently of the location of the process performers. That allows individual staff
members to be geographically distributed. It is no longer necessary for managers to be
collocated with their staff, since control of individuals is not the function being optimized
in the new approach. Workflow techniques that form an important part of process
implementation and facilitate this type of organization are discussed in Chapters 15 and
24.

number of ways:
§ The need for considerable upfront investment can be frustrated. An
emphasis on cost rather than investment can stop the procurement of
assets needed to define and implement the processes.
§ Internal controls can be established that prevent a process from being
able to be efficiently implemented.
Although many functions of the enterprise can impede the transition to a process
paradigm, the accounting function, because of its history and orientation, must be
especially considered. This discussion is not meant to disparage the accounting function.
It is absolutely necessary for the continued viability of the enterprise. The intent is to
point out that all of the enterprise must change for the process orientation to succeed.
1.5.2 The process of process
In this type of discussion, it is easy to forget that management by process itself requires
a process. The management activities necessary to ensure that the enterprise is
functioning correctly and at a high degree of efficiency should also be addressed by an
appropriate process. Because the management process is an enterprise process, it is
subject to all the characteristics of any process.
Although this type of recursion can be conceptually difficult, in practice it offers few
problems as long as there is a reasonable separation of functions within the enterprise.
The management process must be considered as just another process to be managed,
and the same measurements and corrective actions that are defined for any process can
be applied. These processes can also make effective use of automation in their
implementation. 1.6 Technology requirements and drivers
The state of the art is changing so rapidly that any technology presentation will be
obsolete almost as soon as it is completed. In the current environment—to put it
bluntly—nothing is stable, everything is flexible, the choices are enormous, and few
products from different vendors interoperate. In addition, the applications are more

enterprise, and any automation functionality must consider the implications of the
technology.
In spite of these difficulties, the presentations in the book are relatively independent of
whether or not Internet technology is utilized generally or in specific situations, but
process, budgets, content management, and IT management are relevant. The
technologies presented and the automation methodology that they support are
necessary under any condition. From a technical perspective, most of the effect of the
Internet is contained in the computing infrastructure. The infrastructure is a complex
entity, a thorough discussion of which is beyond the scope of this book. However,
appropriate aspects will be addressed as needed for completeness during discussions of
specific topics.
From a business perspective, the Internet can greatly influence the conduct of the
enterprise or even provide the reason that the enterprise exists. Although that will
determine the number and the type of processes and associated automation needed, it
does not change the need for a process orientation and an associated automation
methodology.
1.6.2 Digital convergence
Much current and most future product technology is based on a digital format. The
common digital representation structure allows computer, television, radio, telephone,
and other major technologies to be integrated and viewed in the same uniform way. A bit
is a bit is a bit. It can be processed, transmitted, and presented in a consistent manner
regardless of the original source or intended use.
Although the ubiquity of a bit is the basis for convergence, there can be different
requirements for the temporal relationship between bits. For example, real-time
transmission may require that the delay for each bit in the transmission be approximately
the same, while that may not be necessary for the transmission of non-real-time
information. Those requirements usually fall under the heading of quality-of-service
(QoS) characteristics. Depending on transmission needs, the QoS specification may
vary. The possible need to specify a QoS characteristic does not alter the meaning of an
individual bit, so the core aspect of convergence is preserved.

interfaces, and textual instructions, but it most often applies to software packages. The
software packages can be of any size, and there is conceptually no restriction as to the
packaging method. For example, a COTS product does not have to be shrink wrapped,
and it can come with support personnel from the vendor. For the most part, this
discussion focuses on software products, although the context is expanded, as needed
for generality, to include other types of COTS entities.
Legacy systems and other existing entities (e.g., reusable components) can be
considered a type of COTS product because they are existing, packaged items. Most of
the discussion provided for COTS can also be applied to the incorporation of current
legacy systems. To strengthen the analogy, many enterprises, to increase their revenue
from previous development activities, are selling their internal legacy systems in the
open market. The legacy systems of the enterprise then become COTS products to their
perspective customers.
The use of COTS products to meet an enterprise need has long been the rule rather
than the exception for hardware-oriented products such as those from the electronics
and equipment industries. For example, COTS products in the electronics industry range
from small components, such as individual resistors and capacitors, to large systems,
such as computers and radio transmitters. Few users of such components build their
own; they almost always purchase what they need.
Integrating existing components to perform the desired function has always been the
focus of these types of industries. The required infrastructure and product architecture
were developed with that specific activity in mind. The engineering procedures and
techniques to accomplish the integration are relatively well known but almost always
require expert knowledge to produce satisfactory results.
Utilizing this approach in other industries, including automation software, has always
been a goal, albeit an illusive one. The lack of standards, along with a philosophy that
encouraged a construction approach rather than an integration approach, worked
against the use of COTS products. That view is rapidly changing, however, because the
current economic and competitive pressures are reaching an intensity that almost forces
the consideration of a COTS approach before any custom development is undertaken.

family.” In either case, a legacy follows the third definition. It is something that one entity
inherits from another. The entity doing the inheriting usually has no control over either
the timing or the contents of the inheritance. Indeed, the bequestor also may have little
control over the timing, although there usually is some control over the contents. In the
context here, that of computer systems and software, the uncertainty properties of a
legacy, as well as its usual characteristics, provide the prevailing atmosphere for the
attitude held by most workers in the area.
The reasons for the almost unanimous negative view are examined here in some detail.
As part of the analysis process, a model of legacy software and the associated
operational environment is developed. The model is then employed to provide some
directions that will enable legacy systems to be used to facilitate the transformation of
the enterprise, rather than being considered a major impediment to change.
As a quick aside, this discussion is presented from an engineering point of view, not a
legal one, although many of the concepts and terms utilized in the discussion originated
in the legal sense. In addition, many analogies between the two points of view are drawn
to help convey the required information. It is possible that some of the definitions given,
statements made, or conclusions drawn by the author are not correct in the legal sense.
The potential conflict between engineering and legal concepts is not new and should not
present a problem unless the reader is both a lawyer and an engineer.
1.6.4.2 The legacy environment
To have a legacy, three things are required: a predecessor, a successor, and something
(the legacy) that is going to pass between them. The transfer is considered to be one
way, from predecessor to successor. As already stated, the successor usually has no
control over the timing and the contents of the legacy, although, strictly speaking, that is
not a required condition to have a legacy.
To develop a useful model of the legacy environment, as applied to computer software
and systems, it is necessary to consider each of the three components of a legacy as
presented in Figure 1.4. The rest of this section examines the definitions and the
characteristics of the individual components as well as the overall structure of the mode.


environment. In addition to updating the software, it also would solve the Y2K problem in
existing software. Although the impetus to changing the software development
environment is the Y2K problem, a Y2K problem does not by itself produce legacy
status.
There have been many development environments in the history of computers, and
many of them continue in some fashion even today. In fact, one of the most popular
development environments is of the null environment. No standards are defined and
everything is done ad hoc. For purposes of this discussion, it is not necessary to
consider all the development environments and transitions that have been utilized in the
past. Only the latest set is utilized to illustrate the concepts involved.
The most prevalent development environment used, until very recently, was based on
the custom development of closed software systems using a centralized mainframe
processor. This type of development environment produced software systems and
computing platforms with specific characteristics.
§ Self-contained: Each software system was an entity unto itself.
Identifying and obtaining access to the individual functions and
components are difficult.
§ Local service access: The services needed by the software system
were available locally, including security, timing, transaction monitors,
and data access. There was no need to build in remote-access
capability.
§ Operating system dependent: Although all applications are dependent
on the operating system to some extent, most software was
completely intertwined with the operating system used, usually the
IBM MVS.
§ Batch oriented: Because of the design philosophy of the operating
systems used, application and development architectures were
fundamentally batch oriented, even though humans were sitting at
terminals trying to direct the operation and at least thinking that they
were in charge.

must exist to obtain and utilize those services wherever they exist.
§ It is operating system independent. The goal is to define applications
that can run on different operating systems, such as UNIX and
Microsoft Windows.
§ It is online oriented. Many applications are expected to remain
operational 24 hours a day, 7 days a week. That requires major
differences in the way software is designed, implemented, operated,
and maintained.
§ It has a TCP/IP communications protocol. This protocol is designed for
a distributed, transaction-oriented, online application environment.
§ It is a client/server operational environment. Both clients and servers
have significant amounts of computing power.
As should be evident from a comparison of the characteristics of a successor
development environment with those of a predecessor development environment, they
are in many cases exact opposites. That is why a new development environment had to
be defined rather than an evolution of the older one utilized.
The legacy Remember that the legacy comes from the predecessor and goes to the
successor. What is being transferred from the old development environment to the new?
The simple answer is the operational software (systems) that existed at the time the new
development environment was deployed, hence the term legacy systems. Unfortunately,
there is much more to the legacy than the systems themselves, and that is where things
begin to get complex.
Note from Figure 1.4 that the legacy consists not only of the operational systems but also
of all the predecessor elements needed to keep them operational until new software
resulting from the successor development environment can be made available to replace
them. The entire set of items the legacy comprises is called the automation legacy to
indicate that it consists of much more than the software systems. The use of the term
legacy is qualified in the remainder of the discussion to refer to only a portion of the
whole legacy.
Sometimes it is thought that the term legacy means that the included software will be

deployment of new applications and something that utilizes resources without much
return. It usually is much more enjoyable to create something new than to maintain
existing items, especially when it is assumed that the existing items are eventually
scheduled for replacement. It is also perceived that management is not allocating
enough resources for the new development environment and is too interested in
maintaining the legacy. That may be the perception even though the existence of the
legacy environment is almost always a direct result of positive management action! In
any event, it is the latter view of legacy systems as a hindrance that seems to prevail in
any discussion of legacy systems. We are members of an impatient industry. Out with
the old, in with the new—and the quicker the better! Anything perceived to impede the
changeover must be bad by definition.
1.6.4.3 Using the legacy to advantage
Once established, the legacy environment is likely to exist for a considerable amount of
time. It disappears only when the last of the legacy ceases to exist. Until that time, it is
useful to examine ways in which we can use the legacy to our advantage, instead of
squandering it or wishing it away. There are several techniques through which the legacy
can help facilitate the change to and operation of the new development environment.
The first is to make good use of all the development environment components.
Part of the perception that legacy systems impede the change to a new development
environment is that the legacy is seen only in terms of the operational systems and then
only in terms of replacing them as soon as possible. The automation legacy is much
more robust than that and, if viewed from another perspective, can actually aid in the
development environment transition rather than hinder the change.
Consider, for example, the user practice part of the legacy. User practice is how end
users operate the legacy software and shape their implicit processes to accommodate it.
Understanding those processes and their good points and bad points will help
developers produce software under the successor development environment that
improves the processes and their automation support. Without using that type of
information, which is part of the legacy, the effective development of new software is
made much more difficult. The lack of consideration of prior operations is the real

another legacy situation, the lessons learned from dealing with the first one should
facilitate the handling of the second. In fact, that is just what is happening with the
Internet (see Section 1.6.1). There will be another, although yet unknown, change after
the Internet environment becomes the standard. The need to accommodate change is
endless. 1.7 Automation requirements and principles
The enterprise and its automation system must accommodate the business and
technical requirements and drivers. Two major principles result from consideration of the
drivers as well as other technical and business requirements. The first requirement is
that the automation structure must support the change to the process management
philosophy of the enterprise. A process orientation has significant implications. The
second requirement is that the methodology must be based on an asset and modeling
approach. That is necessary to provide adequate definition of the methodology and its
design elements.
To fully understand the major automation implications behind the shift to a process-
based enterprise, the concept of a process must be considered in some detail. Although
such an examination could be accomplished in this section, it is easier and more
effective to provide the needed discussion in the context of process modeling, presented
in Chapter 9. Postponing the detailed discussion allows for more effective integration of
the concept of process with the other entities that are closely associated with it, such as
scenarios, roles, and dialogs. In addition, the context of asset management, which
includes business rules and financial management, is important in the specification of
process-based automation and must be included in any detailed discussion. The
fundamentals of the asset management approach are presented in Part I.
1.7.1 Process orientation
Matching automation software development to the management-by-process paradigm is
not just a matter of adapting the correct architecture, infrastructure, and development
methodology. In many advertisements and articles in the popular literature, however, that

new approach to development must be substituted and utilized if processes are to
achieve their expected potential as enterprise management units.
1.7.2 Modeling
Obtaining a good understanding of the structure and the operation of any enterprise,
except for the very small organization, depends on the use of many types of modeling
techniques. Unfortunately, the use of models in most enterprises is relatively infrequent.
The models that are used tend to be somewhat informal and depend on the inherent
knowledge of each individual involved for interpretation and utilization. Some recent