Business Process Implementation for IT Professionals phần 1 pps

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 -

Life cycle management

Chapter 4 -

Repository utilization

Chapter 5 -

Business rules

Chapter 6 -

Financial management

Chapter 7 -

Planning and strategy

Part II - Automation assets

Chapter 8 -

Process modeling

Chapter 9 -

Scenario modeling

Chapter 10

-

Role modeling

Chapter 11

-

Information modeling

Chapter 12

-

Client/server modeling

Chapter 13

-

Dialog and action modeling

Chapter 14

-

Software component modeling

Chapter 15

-

Workflow modeling

Part III - Automation methodology

Chapter 16

-

Overview of process implementation methodology

Chapter 17

-

Spirals

Chapter 18

-

Step 1: Define/refine process map

Chapter 19

-

Step 2: Identify dialogs

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

Chapter 25

-

Step 7: Assemble and test

Chapter 26

-

Step 8: Deploy and operate

Chapter 27

-

Retrospective

Glossary -

List of Acronyms

Index

List of Figures

List of Tables

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

book may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying, recording, or by any information storage and
retrieval system, without permission in writing from the publisher.
All terms mentioned in this book that are known to be trademarks or service marks have
been appropriately capitalized. Artech House cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the validity of
any trademark or service mark.
International Standard Book Number: 0-89006-480-6
Library of Congress Catalog Card Number: 99-18034
10 9 8 7 6 5 4 3 2 1

This book is dedicated to my colleagues Truman Mila and Mark Feblowitz,
who breathed life into the PRIME methodology through their innovative
application of systems and software engineering.

About the Author
Robert B. Walford received the B.S. degree in Electrical Engineering from the Illinois
Institute of Technology and the M.S. and Ph.D. degrees in Electrical Engineering from
the University of Southern California. He has over 30 years of diverse experience in
engineering, telecommunications, and information processing, including hardware
design, software design, and technical and general management.
He has held engineering and management positions with several commercial
organizations, including the Hughes Aircraft Company, Bell Laboratories, EMI Medical,
Florists’ Transworld Delivery (FTD), GTE Data Services, and GTE Telephone
Operations. He also performed as an independent consultant in factory automation for
General Motors and was the owner of Tri-Ware Digital, Inc., an original equipment
manufacturer (OEM) that developed and marketed a comprehensive minicomputer-
based accounting and management system for small businesses.
Dr. Walford’s current position is Manager of Advanced Information Management
Technology for GTE Telephone Operations. Areas of responsibility include computing

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

I think this book must have been written by a collusion of half a dozen different Robert
Walfords.
One Robert Walford is a subject matter expert (SME) in several areas of expertise,
especially telecommunications-related domains, his broad knowledge being the result of
a long tenure in the industry. As an SME, Bob has been a resource to numerous
business process definition and reengineering projects, providing reliable content to their
documents, models, and decision-making processes. Another Robert Walford, Bob the
methodology practitioner, has been a participant as well as a guide and coach to teams
following various prescribed organizational methodologies.
The lead author of this book is, undoubtedly, Bob the methodologist, whose experience
as a user and a facilitator of several methodologies has been brought to bear on the
design of new methodologies, striving for and encapsulating best practices. This Bob has
reflected on the reasons, both technical and organizational, for successes and failures of
process modeling and implementation projects. He has a compulsion and a passion for
imparting clear concepts and their coherent integration, for separating the generic from
the idiosyncratic, and for culling the essential from the incidental. Bob the methodologist
has worked closely with Dr. Bob, as his colleagues sometimes call him, whose doctorate
in computer science equips him to avoid superficiality and ensure firm theoretical
foundations. Another author, Professor Bob, teacher of information technology and
related subjects at the university, has made the book’s presentation eminently lucid and
digestible.
The approach taken in the book is heavily influenced by Bob the professional engineer,
whose perspective complements those of Dr. Bob and Professor Bob. Engineer Bob is
concerned with the principles and techniques that engineers use to build things that
work. For example, Bob the professional engineer designed and built a front porch onto
his house, which is located in a hurricane-vulnerable area. Not only did he follow current
practices, standards, and codes, but he added his own engineering calculations to
ensure the structural integrity of the product. I am confident that porch will be left
standing after any hurricane, even if the rest of the neighborhood is leveled. Engineer
Bob wants the implemented business processes to get the job done, despite the

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

utilization of a conceptual modeling approach, and justification for the emphasis on an
asset management paradigm.
The preceding paragraph, which essentially summarizes the book in reverse, discloses
that the book goes well beyond the explication of a single methodology. There is ample
discussion of the basic ideas that underlie the methodology—concepts, theories,
rationale, and pragmatics—which apply not only to this particular methodology but also
provide insights into the subject of process-oriented methodology in general.
A number of pertinent topics are woven into various parts of the book and expounded in
a lucid and instructive manner. Take business rules, for example, a subject fairly new but
highly relevant to business process automation. Business rules are characterized as
statements that define or constrain the operation of an enterprise. Business rules are
always present where business processes live, and business rules induce some of the
key requirements on enterprise systems. However, adequate techniques have yet to be
developed for eliciting, acquiring, analyzing, implementing, and monitoring business
rules. Some business rule deployment tools have appeared in the marketplace, but they
are targeted at a narrow set of business rule types. The author clarifies the business rule
concepts, explains the need for a broader definition, and relates business rules to
process-driven methodologies. Business rules are characterized as an asset that must
be managed from process definition to implementation. Through the use of business
rules and business rules technology, the objective is the capability to rapidly deploy or
redeploy the corresponding business logic.
Another example of a well-chosen infusion of significant material is workflow. The
methodology proposes that the implementation of a business process can best be
achieved by mapping processes to workflow systems, based on the details of the
specified tasks, actions, interfaces, and so on. A workflow system is a platform that
performs the work of a business process by providing mechanisms for specifying,
scheduling, coordinating, and monitoring the workflow instances that are created in
response to business events. Making a workflow system part of the architecture for
target implementations reduces the need to reprogram those generic capabilities for
every developed system. Although the state of workflow technology, as for business

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

on telecommunications expertise.
To give credence to that contention, we have to ask: Where will the professionals come
from to carry out the methodologies? Where will they get the training they need? What
knowledge and expertise are needed for success? Some progress is being made by
recent advances in university curricula, in courses on systems analysis, requirements
engineering, and the like. Other skills such as facilitation and project management also
are important and available. Dr. Walford folds such material into this book, demonstrating
a predilection for a multidisciplinary approach, which is precisely what is needed.
In addition to needing a new generation of professionals to carry out the new order of
things, mechanisms for organizational change will be needed. The fact that
methodologies are higher-order processes, that is, processes about processes, makes
them both powerful and paradoxical. From one perspective, a methodology is carried out
by agents who take on an external, apparently dispassionate view of the enterprise, and
they build models from an apparently objective viewpoint; the operations they perform
are on other business processes. On the other hand, the methodology is just another
process (caution is always advised when the word just is used). The process happens to
be performed by agents who often are stakeholders internal to the current or future
configuration of the enterprise. So a participant in a methodology wears two hats: that of
the designer of the new enterprise and the other of a potential occupant of the new
organization. Obviously, there are some natural conflicts between self-interest and
organizational altruism. The fact that a methodology is a higher-order process is
therefore a challenge to overcome. Consider, as well, that the introduction of a new
methodology is an implementation of an even higher order business process. That
infinite regress is, in principle, troublesome, but in practice we have not reached the point
where there are any significant consequences.
One of the main reasons for developing a methodology is to bridge the gap between
business development and information technology. Historically, the relationship between
the two has been ill-defined, not atypical of the nature of relationships between
customers and application vendors. Business involves business judgment and decision
making, for which the most natural forms of communication have been informal media

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

succession is likely to continue into the foreseeable future as technology advances and
customers demand the services and products enabled by the new capabilities. Adding
value in this environment requires that a “stretch view” along with innovative approaches
to enterprise automation be used. That will result in some possibly controversial
directions, but there is no hope of keeping up with the rapid pace without utilizing paths
other than the existing ones.
The basic unit of the enterprise, from an automation perspective, is considered to be a
process rather than a particular function of the enterprise. This approach is taken not
only because a process orientation is being used for much of the current work in
organizational dynamics (e.g., process reengineering) but because it is a more natural
construct for determining and defining automation functionality that meets the needs of
the enterprise.
When we consider a process approach, it rapidly becomes evident that the specification
of a process is just the beginning. A considerable amount of effort must be applied to the
transformation of processes from the business environment in which they are defined to
the technical environment in which they must be implemented and deployed. Different
process models are needed to make the transformation effective. This book specifically
addresses an issue usually missed in the discussion of process engineering and
management: the need for eventual implementation and deployment of the business
processes.
There are many publications concerned with the need for an enterprise to be process
oriented and that provide approaches to the specification of so-called optimum
processes through some type or business reengineering. However, little consideration
has been given to how to actually implement those processes using manual or
automated functions and to successfully deploy them in the enterprise. Thus, many
enterprise process engineering activities have failed.
The central purpose of this book is to fill that void through the specification of a process
implementation methodology. The process orientation of the methodology gives rise to
its name: process implementation methodology (PRIME). Unfortunately, the mere
specification of a series of steps is not enough to provide a workable methodology. If

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

inherently require a long time-to-market cycle for new products; and they produce
products that are difficult to maintain.
The PRIME methodology addresses all those issues and includes their resolution as an
integral part of the methodology activities rather than as an add-on or afterthought. For
that reason, PRIME provides the first fundamental advance in automation software
specification and development methodologies in several years. The term development
as used in connection with the PRIME methodology is intended to cover custom
implementation as well as the selection of already existing software such as commercial
off-the-shelf (COTS) products, legacy systems, or components specifically designed to
be reusable. PRIME can accommodate centralized, client/server, and Internet-based
architectures, either alone or in combination.
The comprehensive scope of this book provides a significant value independent of the
specification of an effective process implementation methodology. It permits
consideration of many needed topics in their appropriate context. That also allows a
presentation based on principles that are relatively independent of specific technologies
and products, thus increasing the effective life of the information in the book. Many of the
presentations touch on issues currently being aggressively debated within the industry.
The models of the components involved constitute a suitable framework through which
the divergent views can be examined and understood.
The information in this book is presented in three parts, with an introductory chapter on
the current business and technical environments and associated drivers with which an
enterprise must deal. Each part constitutes a major aspect of the methodology
specification. This organization is necessary to manage adequately the complexity of the
information and provide a presentation that will serve the needs of many different types
of readers.
Chapter 1, the introductory chapter, is concerned with defining the business and
technical environments in which the automation software must exist and be utilized. It
introduces the major pressures that are forcing the enterprise to change how it conducts
business and, as a result, how support software is obtained and utilized. Without a
minimal understanding of those topics, it is not possible to follow and understand the

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

explicit spirals are defined in the methodology. Implicit spirals also can be defined among
any set of steps as needed during a specific development.
It is important to note that this book is not intended to be a cookbook. Although it does
contain a comprehensive and relatively complete discussion of the principles involved in
process implementation and could be used as described, it commonly will be used as
just a starting point. Every enterprise is different and will need different aspects and
details of the material presented. Certain aspects will be emphasized more than others.
Any of the definitions, models, and procedures contained in this book can be altered to
meet specific requirements. However, the systems engineering and automation asset
perspectives must be maintained so the result preserves the necessary consistency and
focus.
The information presented in this book has been designed to assist software engineering
professionals involved in the implementation of processes. There are more than
sufficient details and explanations to enable readers to (1) understand the underlying
reasons for the design of PRIME and (2) adapt the methodology to their organization
without encountering a large number of unexpected problems. The information
presented will enable individuals involved in any aspect of business process utilization to
understand the consequences of their results and provide for a smooth implementation
path.
Although there are no study questions at the end of the chapters, this book is also
appropriate for classroom use in advanced courses in software engineering or
management information systems. A condensed course could be taught in one
semester, but exploring the technical requirements in depth probably would take a two-
semester sequence. Either way, student assignments would consist of example designs
and investigation of possible alternatives to the suggested activities and steps of the
methodology. As in actual practice, there are few simple answers to most of the
questions that can be formulated. An instructor must, therefore, look to the validity of the
approach and conclusions reached to determine the degree of absorption of the material.
I would like to express great appreciation to Blayne Maring, former GTE assistant vice
president—architecture, and Charlie Troxel, director of enterprise computing strategies

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

the operation of our large enterprises. There are still many project failures and expensive
overruns. The cost and the time required for development and testing keep increasing,
as does the backlog of new software projects. Viable future directions that could remedy
the problem seem uncertain and distant.
This chapter examines the current conditions under which large (and not so large)
enterprises must operate. It presents the basis on which a partial resolution to the
software development difficulties that pervade modern business can be found. As such,
it provides the high-level justification and context for the use of a process-oriented
approach to business automation.
The discussion is at a relatively high level but contains sufficient detail to show the
interrelationships among a large number of complex business, social, and technical
issues. It is those interrelationships that provide the clue to the software difficulties of the
enterprise as well as the direction for their solution.


1.1 Environment
“It was the best of times; it was the worst of times.” That, of course, is the opening from A
Tale of Two Cities, the classic novel by Charles Dickens that is set in the late eighteenth
century. Why is the quote appropriate for a technical book set in the late twentieth
century? Dickens lived in a time of great social upheaval and wanted to explore the
effects of that condition on the citizens and institutions of his country. His stage was the
novel, a story of fiction. We also live in a time of great social change, compounded by the
modern addition of business and technical change. We also need to explore the effects
of that change on ourselves and on the enterprises in which we work. The stage is a
nonfiction technical presentation—this book. Regardless of the vehicle, the need to
explore and understand our environment and come to a reasonable accommodation with
it remains the same.
Throughout this presentation, the underlying theme is change and how best to react to it.
If we react well and take advantage of the opportunities, it will indeed be “the best of
times.” If we react poorly, it will be “the worst of times.” Unfortunately, like the characters

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.

On the basis of that information, Part I defines the asset management system, Part II
identifies and models the automation assets, and Part III provides the overall
specification of an automation methodology that transforms the assets into elements of
the enterprise automation environment. The methodology design is directly dependent
on the automation requirements and principles, automation assets, and the enterprise
automation environment architecture.


1.3 Business requirements and drivers
In essence, only four high-level business requirements apply to the development of any
product—software, hardware, text, graphics, or combinations thereof—in the current
environment:
§ Decreased time to market;
§ Decreased resources expended (financial, personnel, equipment);
§ Increased quality;
§ Increased value to the customer (functionality, ease of use).
Every other need is in support of those four. Of course, in providing that support, a fair
number of details must be considered and appropriate decisions made. It is the details
that make these simple requirements so hard to achieve in practice. Examples of the
types of decisions that must be made are:
§ Do the requirements apply to each product individually, to an average across
all offerings, or some combination?
§ How are specific conflicts between the requirements resolved?
Those and other questions and their resolution, which generally requires some form of
compromise, do not invalidate the requirements. They only serve to illustrate the types of
considerations that must be addressed in translating them into realistic procedures.
In addition to the four general product requirements, some requirements resulting from
general enterprise philosophy usually must also be considered (e.g., premature
obsolescence of previously implemented software products should be avoided) in the
determination of an automation methodology. These are usually presented in the form or

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.

Figure 1.2: Vertical silos of automation.
The hierarchical organization and its silo-based, centralized automation support began to
change because of numerous technical and social pressures.
§ Relatively inexpensive desktop computers, which could store large quantities
of information and perform tracking and scheduling tasks with ease,
became widely available. Desktop computers made it possible for one
person to manage a much larger number of subordinates and functions
than could be performed using manual techniques. The need for middle
layers (management) in the hierarchical structure was greatly reduced.
§ The onset of true global competition, with subsequent pressure on the cost
and quality per unit of produced goods and services, made it necessary for
the enterprise to become much more efficient in terms of its cost of
producing a unit of output.
§ The cost of a full-time employee was rapidly escalating, not because of large
increases in remuneration but because of the cost of the benefit programs
(mostly health care), which were rising much faster than the rate of
inflation.
§ Due to new laws and other legal considerations, it was becoming increasingly
difficult and expensive to eliminate full-time workers either permanently or
temporarily during cycles of decreased activity.
§ Companies were becoming global with locations throughout the world. That
required an effective method of interaction between many geographical
diverse locations with differing customs and business practices.
All those factors made it imperative that large enterprises reinvent themselves to become
competitive on a global basis. It was either that or simply go out of business.
The reinvention of large (and many medium-size) businesses is still proceeding and
probably will not reach some sort of new equilibrium until well into the twenty-first
century. Enough change has occurred, however, that we can discuss the major trends
that are occurring in three broad areas: the organizational (management) structure of the

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

enterprise becomes one of process rather than organization. The emphasis on
organization produced processes that were implicitly defined and functionality that
mirrored the organization partitions. An emphasis on process requires that the
functionality be defined to support the process. In fact, the current emphasis on process
reengineering does not result from a desire to take the current processes and make
them better, as would be expected from the name. Process reengineering is, in reality, a
way to make a transition from an organization- or function-based view of the enterprise
to a process-based view. It is more enterprise reengineering than process reengineering.
In a process approach, the satisfaction of the customer request, is obtained through the
use of a process specifically defined to handle that type of request (and perhaps others
of the same general type). The process approach to handling customer requests is
illustrated in Figure 1.3. Notice that the process is a continuous end-to-end definition of
the required activities needed to handle the request. That is significantly different from
the functional organization that has a discontinuity at every function boundary. The
effectiveness of the process view is enforced by the managed entity being the process
rather than the individual organization function.

Figure 1.3: Process approach to request satisfaction.


1.5 Management by process
The impact on the enterprise considering the need for a process approach is a transition
to a management-by-process philosophy instead of the classical hierarchical command-
and-control structure. The transition is the fundamental business reason that a new
approach to automation is required. The reasons for the transition and some of the major
consequences are discussed in Section 1.6. The resultant impact on automation needs
is presented in Section 1.7.
Although management by process is considered by many to be synonymous with
process reengineering, it actually is considerably greater in scope. Management by
process encompasses a basic philosophy on how to manage the enterprise. Process

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.

1.5.1.2 Financial
Although the discussion thus far has referred to some underlying financial pressures,
there is a need to address additional financial considerations related to the changes
themselves. The financial aspects are divided into two parts: those dealing with the
effects that result from any change and those dealing with the effects of a specific shift to
a process paradigm. Additional financial implications of the process approach are
examined in Chapter 6.
The major financial result of any radical change is the premature obsolescence of those
assets that supported the old paradigm and the corresponding need to obtain assets that
support the new way of operating. The enterprise must be prepared to write off a
significant amount of assets and commit the resources necessary to obtain new assets.
The assets can exist in many parts of the organization and include such diverse items as
buildings, equipment, office supplies, forms, intellectual property, and support software.
Although all costs of change must be considered, it is the last item, software, that is of
particular significance in this discussion. As discussed previously, software that does not
fit the new enterprise directions usually is referred to as a legacy system, and its
disposition as well as the acquisition of replacement software can be quite costly to the
enterprise.
The financial aspects of changing specifically to a process orientation are associated
mostly with the determination of the total cost of ownership of an asset used in the
implementation of a process. That requires that the cost of the asset over its entire life
cycle, including acquisition, operations, and disposal be estimated a priori. The financial
and accounting structures of the enterprise must accommodate that approach, which can
be complicated by the projected use of the asset in multiple processes and involve both
capital and expense components. In addition, because processes themselves can be
considered assets, the cost of a process over its asset management needs to be
ascertained and a determination made as to the propriety of utilizing that process.
The accounting function in many enterprises, because of government reporting
regulations and organization culture, can prevent many of the financial aspects of the
process approach from being effectively implemented. That can be implicitly done in a

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

complex, and the time-to-market need is more critical. Those conditions are not likely to
change in the foreseeable future. Any approach to enterprise automation must directly
consider this environment in addition to the classical functionality requirements. The only
way to accommodate all those additional pressures and still produce a product that
always meets the needs of the customer when it is deployed is to define and utilize
anappropriate automation methodology specifically oriented toward process
implementation. The required methodology must provide structures and activities that
explicitly consider the conditions of the current environment and take advantage of the
opportunities they offer while mitigating the difficulties.
As would be expected, a considerable number of technologies affect the automation
requirements of the enterprise. A comprehensive treatment is far beyond the scope of
the current presentation. Many of those technologies are addressed in later chapters,
where they are utilized in the formation of an automation methodology. From an overall
enterprise perspective, however, it is necessary first to consider the major technology-
oriented pressures and constraints under which the enterprise must function:
§ The Internet (and associated technologies);
§ Digital convergence;
§ Commercial off-the-shelf (COTS) products;
§ Legacy systems.
This section considers each of those pressures in enough detail to determine its effect
on the automation needs of the enterprise.
1.6.1 The Internet
There is a temptation to devote a considerable amount of discussion to the Internet
because of its large and growing impact on the enterprise from both a business and a
technical perspective. That would be a mistake for two reasons. First, the technology is
changing so rapidly that little could be said that would remain current for any significant
length of time. Second, an abundance of literature is available that addresses almost
every aspect of the Internet in far greater detail than could be accommodated in this
book. The reader is referred to those sources for further information. This discussion of
the Internet is limited to the realization that it represents a source of great impact on the

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.

The extent to which the digital architecture can blur the separation between products is
illustrated by the following examples. A personal computer is fitted with a microphone,
speaker, and modem and used to communicate via voice. What is the difference
between that computing device and what is usually known as a telephone? If a television
is coupled to a settop box connected to a video cable and used to connect to the
Internet, what is the difference between that equipment and a personal computer
connected to a telephone line?
The examples could continue, but those should provide the basic idea. As long as a
product has digital underpinnings, it is defined more by what it does than what it looks
like! In many ways, it begins to resemble and behave like an ecosystem rather than an
architecturally driven configuration.
Digital convergence can also lead to other types of convergence, including that of
organizations and even industries. An example would be the possible convergence of
the television and personal computer industries. That could occur only in the context of
digital convergence. Convergence of organizations leads to the need to integrate their
individual automation systems. Anticipation of the continuing convergence of
organizations through mergers and consolidations forms another requirement for the
design of automation support that can facilitate this type of activity.
In addition, the automation impact of digital convergence is the need to allow different
areas of an enterprise to interact more closely with each other and to cooperate in the
development of new products and services that can use common components and
processes.
1.6.3 COTS products
The high costs of developing new software and the increasingly large backlog have
begun to significantly affect how an enterprise obtains new software. Software
procurement directions are becoming increasingly oriented toward the use of software
that is available on the general market as a prepackaged system or set of functions
instead of the development of custom software. This type of prepackaged software
generally is referred to as COTS products.
COTS refers to any entity that is purchased as offered, including processes, user

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.

The automation impact of using COTS products is that they must be appropriate for the
part of the business in which they will be used. That must be enforced by both asset
management and the automation methodology.
1.6.4 Legacy systems
Although legacy systems are not really a force that impinges on the enterprise, they
certainly are a direct result of the enterprise reaction to such forces. In that sense, this
topic is appropriate for consideration as a technical driver. In addition, the reaction of
different enterprises to the, in many cases, “sudden” appearance of legacy systems has
been varied and usually occurs without sufficient analysis and planning. The purpose of
this section is to examine the reasons that the so-called legacy systems come into
existence, the general properties of such systems, and an analysis of some positive
approaches to their utilization instead of the almost universal negative connotation that
any discussion of such systems engenders.
In fact, use of the term legacy represents an attempt to moderate the effect of the use of
some other widely used terms for this type of software, such as old, obsolete, and
outdated. In fact, a legacy system may be described by one of those terms, but it is also
possible that a legacy system is relatively new, of good design, and useful in the
operation of the enterprise. Although it probably was not consciously realized, the use of
the term legacy is appropriate for the change process that is taking place.
Because of the importance of legacy systems in the enterprise and the general lack of
analysis of such systems in the literature, it is useful to develop this topic in some detail.
Incorporating legacy systems (at least temporarily) in any automation system is
necessary to facilitate an effective migration.
1.6.4.1 The concept of legacy
Dictionary definitions of the term legacy include “property left by will; a bequest;
something that has been handed down from an ancestor or predecessor.” Going to the
dictionary definition for the term is interesting because, in general, the familiar context of
a legacy is usually considered something good. Being the recipient of a $1,000,000
bequest from a long-lost relative is the dream of a fair number of people. However, the
term also can be used in a negative sense, as in “His behavior left a poor legacy for his

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.

Figure 1.4: Legacy model.
In the familiar sense, the predecessor (or bequestor) and the successor are persons. For
computer software and systems, the person is replaced by a rather complex concept,
that of a development environment. The development environment addresses the birth,
life, and death of automation software (and associated hardware) supporting the
operation of the enterprise. Everything needed to perform those activities is included in
the environment.
The predecessor Software developed or otherwise acquired under the current
development (and maintenance) environment can get old and obsolete and be replaced.
As long as the replacement occurs under the same development environment, however,
the old software generally is not considered a legacy even when it has been marked for
elimination or replacement. As long as the enterprise is satisfied that the current
development environment can support the needs of the enterprise, there is no need to
consider another development environment approach. If the pressures impinging on the
enterprise force operational changes that cannot be accommodated by the current
development environment, then changes to the development environment must be made
and the current environment becomes the predecessor of a legacy environment.
An interesting example of this is the so-called year 2000, or Y2K, problem. The problem
arises from the fact that most software prior to the early 1990s was coded such that the
year designation of dates consisted of two numbers representing the last two digits of a
year. Thus, 1993 was coded as 93, with the 19 assumed. That works fine until the year
2000 and beyond. The year 2000 coded by the two-digit method would be 00, which
most software would interpret as 1900. Affected software must be updated to eliminate
the problem, but the need to make the changes does not automatically transfer existing
software to legacy status. If the existing development environment is still considered
adequate, the changes should be handled as any other maintenance change.
However, many companies have taken advantage of the need to make Y2K changes to
also update the current development environment and implement a new one. The new
environment would make the current programs into legacy systems that would be
replaced by Y2K-compliant software developed under the new development

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.

§ Systems network architecture (SNA) communications protocol:
Because of the widespread availability and the use of IBM-compatible
platforms and MVS operating systems, this protocol was almost
universally used for large systems.
§ IBM and compatible mainframe computers with 3270 format terminals.
As would be expected, there are a large number of other characteristics, but those listed
above will suffice for now.
Because of the rigid characteristics of this development environment, it could not evolve
to meet the new needs of the enterprise. An entirely new development environment was
needed. The old development environment died and became the predecessor
component of a new legacy environment. The successor component in the new legacy
environment is the new development environment structure.
Suddenly, the existing systems and their development and operational environments
became a legacy. Because the predecessor development environment was now
considered old and obsolete, this characterization was instantly transferred, rightly or
wrongly, to the legacy software. The practical result was that almost all software
developed under the predecessor development environment was looked on with scorn.
The successor The successor development environment, as would be expected,
consists of the same basic types of activities as those of the predecessor environment,
the difference being in their definitions and structural characteristics.
The development environment that replaced the predecessor one is based on the
utilization of commercial and reused software components in a distributed environment.
This type of development environment produces software systems and computing
platforms with characteristics very different from those of the predecessor.
§ It is built from individual functions. The focus is on the implementation
of processes built from individual, identifiable commercial or reused
components from previous enterprise systems. The concept of a
system disappears.
§ It has remote-service access. The services needed by the software
system can be distributed anywhere on the network. The capability

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

around forever. Although it sometimes may seem like forever, there is no set time for the
legacy to remain. It could be very short or agonizingly long. The schedule for the
development of any replacement functionality using the successor development
environment, of course, depends on the business case that can be made for any specific
functionality replacement.
Note that in the definition of a legacy, there is no inherent assumption as to the quality of
the systems it contains or even of the development environment itself. The only known
fact is that the enterprise has determined that the previous development environment
has become inappropriate.
Consider the following example of the decoupling between the legacy status of a product
and its quality or age. Many enterprises continue to successfully market software and
associated support that have been internally labeled with legacy status. Obviously, those
organizations purchasing the products do not consider them to be poor quality, obsolete,
legacy products. They were purchased to fill a need for a reasonably current solution.
Legacy status is enterprise specific and even then remains a situational concept.
The complex automation legacy can be considered either good or bad, depending on
how it is expected to be used by the successor development environment. As a part of
the good view, it can be seen as a valuable help in determining the requirements for
successor development environment products and in keeping the business running after
the transition. Although people always talk in glowing terms about having a clean sheet
to work with, meaning, of course, no constraints, there is also a definite downside to
such freedom.
For example, there is the condition known as the blank-page syndrome, which occurs
when a writer is starting a new book chapter or an article. (This author is very familiar
with the blank page syndrome!) It is difficult to create something out of nothing. It is much
easier when there is something to work with, even if all the existing items eventually will
be replaced. However, the lure of the clean-sheet approach is such that many
enterprises choose that course of action even though a considerable amount of
resources could be saved by using the legacy to advantage.
On the other hand, the automation legacy also can be viewed as a hindrance to the

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

impediment to the transition to the successor development environment.
The second way to use the legacy to advantage is to let it guide the replacement
strategy as software is developed or otherwise procured under the new development
environment. As with any software-oriented entity that has been in existence for a
significant length of time, the original orderly (it is hoped) structure becomes twisted and
bent with unforeseen add-ons, ad hoc extensions, quick fixes, and other unplanned
changes.
One approach to maintaining that requirement is to develop a map of the interactions of
the existing legacy systems. That can be a very intimidating and time-consuming
exercise, because for a large enterprise it usually is discovered that many more systems
exist and are in use than originally thought. Links between systems are undocumented,
system descriptions and documentation are missing, ad hoc modules have become
institutionalized, and so on. The resultant map probably looks like the one depicted in
Figure 1.5.

Figure 1.5: Legacy system operations map.
The value of this aspect of the legacy is that it provides a means for the software to be
acquired under the new development environment to be well structured and conceptually
simpler than that of the legacy. A rule for replacement software acquired under the new
development environment should be that the overall result obtained is easier to
understand and maintain than the older software alone. That should be true for mixed
legacy and replacement software as well as replacement software alone.
From this discussion, it should be evident that the legacy has much to offer the new
development environment. Even though the legacy software systems are not structured
in a way that can support the changing needs of the business and must be replaced, the
legacy as a whole provides necessary continuity. It also can provide the enterprise with a
firm foundation on which to perform some of the analysis necessary to ensure that the
software produced under the new development environment will be as effective and as
efficient as possible.
Should another change take place in the enterprise automation environment, forcing

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

seems to be the message. Even if perfect architectures, infrastructures, methodologies,
and supporting tools were available (and we are quite far from that condition), the effort
would not succeed without a different attitude toward software development.
Supporting processes with automation software requires that the enterprise adapt an
integration philosophy instead of a closed-system model. In addition, the manual
activities and the automated activities must work in concert to implement the process.
From a software perspective, that requires that software be implemented or otherwise
obtained in the form of discrete components that are then connected through an
appropriate control mechanism with the necessary degree of human input. They may be
large COTS products or small individual components. Another important aspect is the
use of an infrastructure through which all the components can interoperate with each
other as well as with the humans utilizing them.
The defining item for the change in software direction is not the size or the construction
of the components or the infrastructure. It is the philosophy that the enterprise follows in
its software-oriented activities, and that philosophy is supported by the financial and
organizational structures of the enterprise. If management still views enterprise
automation as individual pieces of standalone software with no need to facilitate the
communications between them, management-by-process will never reach the degree of
effectiveness of which it is capable. That easily can result in the enterprise being placed
in a significant competitive disadvantage.
In addition to the need for a different automation approach and an associated software
philosophy, there is also a need to consider how to migrate effectively from the old
philosophy to the new one without hurting the day-to-day operations of the enterprise. As
might be expected, the migration can be difficult. With the proper planning and models,
however, it certainly is not impossible.
The need to change how enterprise support software is viewed and the means to effect
that change constitute a large part of the discussion in this book. Although it usually is
not explicitly stated in this context, that aspect of management by process is pervasive.
To put it bluntly, most of what has been taught and learned about automation and
software development for the support of the enterprise must be forgotten. In its place, a

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