business process implementation for it professionals and managers

A systems engineering approach defines customer needs and required functionality early in the development cycle and follows a structured development process in which technology component

Business Process Implementation for IT Professionals

Artech House © 1999 (599 pages)

An all-inclusive roadmap to help you convert business practices into applications to facilitate those same business practices

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

Business Process Implementation for IT

Professionals and Managers

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

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

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

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-t o-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 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

two-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

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 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

command-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

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

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

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 soft ware 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 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

process-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-t o-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

attempts to introduce formal models such as the Unified Modeling Language (UML), which is used to model object classes, have tended to be very low level and specific to given topic areas The lack of general formalisms worked reasonably well in highly structured, top-down organizations but presents problems when applied to the flat, more loosely structured organizations that are currently evolving

The management and automation needs of enterprises adapting these new

organizational structures require that the business operations be defined and analyzed in greater detail than before Through the proper definition and application of models, the complexities and interactions of these new organizations can be better understood and managed It is, therefore, necessary to define and utilize models in a structured and relatively rigorous sense Without modeling, solutions to the complex problems inherent

in the specification of enterprise automation can only be guessed

To effectively use modeling techniques in the enterprise, it is necessary to understand their major types, properties, advantages, and disadvantages, at least at a high level This discussion is designed to provide that overall understanding In addition, this

presentation also provides the detail needed for the specifications of the many models that will be developed in subsequent chapters Without a basic understanding of the necessary modeling techniques, the information in the remainder of this book would be somewhat more difficult to assimilate and utilize effectively

Specifically, this discussion provides an introduction to modeling It is not meant to be an exhaustive treatment of the subject but only to serve to provide the understanding and motivation required to place the discussions of the following chapters in context

1.7.2.1 General principles

This subsection contains a short discussion of general modeling principles The

information is designed to provide the overall context and understanding needed to apply modeling techniques to specific situations Sections 1.7.2.2 and 1.7.2.3 utilize those principles to define the approaches used to develop individual models The discussion should provide readers with some ability to extend the information presented to meet the modeling needs encountered in their individual situations

Unfortunately, the term model has many meanings In the context here, a model is

meant to be a representation of some entity for the purpose of analysis That contrasts with its other meaning as a toy (model train, model plane, model automobile) that is generally a smaller version of the real item Some confusion can arise when the same physical “thing” can be used to perform both functions A model of an airplane can be used in a wind tunnel to determine its aerodynamic characteristics (analysis

representation) It also can be used by a child as a plaything (toy) Another example of how terminology can make for a difficult time

Model positioning In any analytical or synthesis activity, it usually is necessary to

translate the real world (physical or intellectual) into a form that can be conveniently examined and manipulated Once the desired results have been obtained, a reverse translation back to the real world is made This form (or representation as it is sometimes known) is usually called a model Models have some desirable properties when used in the examination of physical or intellectual subjects Two examples are:

§ In the physical world, mechanisms usually are quite complex and

involve many, possibly nonlinear, stochastic interacting forces

§ Intellectual concepts may not have a uniform understanding among

individuals trying to understand or otherwise make use of the concept The uncertainties present in each of those areas can be reduced by the selection of appropriate models

Model usage A model of some aspect of the physical or intellectual world can be

defined by a structure that is suitable for portraying the desired activity Among many possibilities, the structure could be based on mathematics principles, it could be defined

by graphical techniques, it could be embodied in a procedure or an algorithm, and, of course, it could be any combination of formats Different models of the same real world

entity can be developed Each model could address a different area or emphasize a specific feature

Physical models are used for many purposes The reaction of physical models to stimuli

is reproducible The same may not be true in the real world Models can be frozen in time or made to work faster or slower than real time Models can be used to examine the effect of a change in the physical world That is especially useful when an undesirable physical world reaction could be catastrophic or result in the waste of a large amount of resources (including money) Models can be made noise free Random perturbations that occur in the physical world and result in fuzzy observations can be eliminated and only the essential operations preserved

The major disadvantage of a physical model is that it does not behave exactly as the physical world entity it represents The difference might be negligibly small or differ in unimportant areas However, the difference can be significant and, in the worst case, cause the model user to make the wrong conclusions concerning the physical entity It is important that the model designer have an excellent understanding of the physical entity being modeled and the use to which the model will be put In most cases, the model should be tested over the range of intended use by comparing its reaction to the reaction

of the physical entity for the same stimulus

As an example, consider a model for the congestion in a network The model is designed

to address only one aspect of a possibly complex entity The network manager uses the model to make a determination as to the best way of reducing congestion during some set of operating conditions If the model represents the network accurately in this limited area, the network will respond according to the predictions of the model and the right decisions can be made If the model is not an accurate reflection of the network, relying

on its predictions may result in the wrong actions being taken These types of models usually are fairly accurate, but conditions can exist for which the models are not reliable The builder or user of the model must be aware of the limitations and act accordingly Models that represent intellectual concepts are used slightly differently They are used mainly to convey definitions and context in a way that promotes understanding of the concept In that regard, models must contain enough structure and detail to make the concept unambiguous and understandable Allowing the understanding of possible interactions with other concept or entity models is also a primary concern of those models The major disadvantage to this type of model is that it might unnecessarily constrain the concept and limit its potential usefulness

Because of the complexity of the concepts involved in software development and the large number of interactions, the only way in which the development methodology can be examined and optimized is through the extensive use of mainly intellectual models Although it is possible to describe a methodology and concurrently define the necessary models, it tends to confuse the flow of the presentation and results in less than optimum knowledge transfer For that reason, the necessary models will be developed separately from the presentation of the methodology design Methodology-specific models are developed in Part II, while methodology design is presented in Part III

Although this organization has a disadvantage in that the model structures must be remembered during the methodology discussions, it is the author’s opinion that the overall result of separating the two presentations results in a better understanding and appreciation for the techniques involved

1.7.2.2 Modeling of concepts and terms

A large number of terms and concepts have been applied to various aspects of the automation environment, and they must be addressed by a software implementation methodology Many terms and concepts have no generally accepted meaning; to

understand the interpretation intended, the exact context must be known, sometimes an impossible task

There are several reasons for the lack of standard industry usage of well-known and frequently utilized terms and concepts:

§ They were invented and promulgated without sufficient analysis and

structure (e.g., business rule)

§ They are being utilized for different purposes than the one for which

they were originally conceived (e.g., scenario)

§ They have acquired different meanings when applied using the context

of technologies other than that in which they were originally utilized

(e.g., process)

§ Their specialized use and definition is confused with that of the

nontechnical general-usage term (e.g., dialog)

Of course, more than one reason can apply to any given term or concept

In spite of those problems, in most cases terms and concepts were given specialized meanings for valid reasons and could have significant value in managing the complexity

of business process implementation, operation, and change Using them to convey and classify the many forms of information that must be analyzed and integrated can greatly simplify the design and utilization of the methodology To adequately serve that purpose, each term and concept must be given a suitable definition and structure The design must be sufficiently detailed to unambiguously convey its purpose and provide enough understanding so it can be utilized in a consistent manner In addition, all the terms and concepts employed in the process asset management must be self-consistent and consistent in definition and structure with each other and with the overall process

implementation methodology

The modeling approach is designed to motivate and provide a detailed definition and structure (model) for the terms and concepts of interest The models are specifically designed to allow the methodology specification to proceed in an orderly fashion In most cases, the difference between the model as defined herein and many of the common uses is simply a matter of additional detail In some cases, however, it is necessary to depart from one or more aspects of common usage and travel in a different direction to keep all the models consistent When that is necessary, the reasons for the departure will be carefully motivated

In addition to those terms and concepts that have received wide usage, a small number

of additional concepts are of use in the methodology specification and are not in general usage They will also be modeled in much the same way as those that are better known Treating all the needed terms and concepts in a similar fashion will improve the

consistency of the presentation and facilitate the detailed specification of the

methodology

1.7.2.3 Model types

In the various discussions presented in this book, models are used for different purposes and for different types of objects Physical and logical entities, concepts, terms, process components, and enterprise forces all need some form of model for them to be

adequately defined The model allows them to be examined individually or as an

interoperating set The model formats and characteristics used for each object type vary considerably and are defined in the specific discussion for that object However, some models are similar for a wide variety of objects, and those models are defined as a separate activity in this chapter These common models usually are associated with the physical and logical entities described in Part II

Each addressed entity has two types of models, an entity model and a class model The entity model considers the definition and structure associated with an individual entity The entity class model considers all entities of the same type It provides a structure that organizes the entities in a manner that facilitates the creation, management, and use of the entities All the entities modeled in Part II have both entity models and entity class models defined More detail on the use and structure of class models is provided in

Chapter 2

1.8 Summary

Effectively meeting the changes in the business and technological environment is

causing the enterprise to greatly change the way it is managed and operates

Consequently, those changes are forcing the automation structure of the enterprise to change to provide the required degree of support The resultant automation structure requires new ways of specifying and developing software based on a system

engineering approach with a process and asset orientation that utilizes extensive

modeling support

Selected Bibliography

Andriole, S J., Systems Requirements and Process Reengineering: A Modeling and

Prototyping Guide, New York: McGraw-Hill, 1995

Baum, D., “Legacy Systems Live On,” Information Week, 1996, Issue 573, 10A–14A

Blumenthal, M S., “Unpredictable Uncertainty: The Internet and the Information

Infrastructure,” Computer, Vol 30, No 1, 1997, pp 50–56

Bollig, S., and D Xiao, “Throwing Off the Shackles of a Legacy System,” Computer, Vol 31,

No 6, 1998, pp 104–109

Bork, A., and D R Britton, Jr., “The Web Is Not Yet Suitable for Learning,” Computer, Vol 31,

No 6, 1998, pp 115–116

Born, G., Process Management to Quality Improvement: The Way to Design, Document and

Reengineer Business, New York: John Wiley & Sons, 1994

Cast, J L., Alternate Realities: Mathematical Models of Nature and Man, New York: John

Wiley & Sons, 1989

Chris, W J., “Building a Process-Based Organization,” Proc 51st Annual Quality Congress,

Orlando, FL, May 5–7, 1997, pp 95–102

Coburn, S., and H Grove, “Process Based Management at U S West,” Trans 49th Annual

Quality Congress, Cincinnati, OH, May 1995, pp 667–674

Cole, B., “Holding Code to a Higher Standard,” EETimes, Issue 985, Dec 15, 1997, pp 77,

90, 98

Covell, A., “Digital Convergence: The Water’s Fine,” Network Computing, June 15, 1998, p

32

Davenport, T H., Process Innovation: Reengineering Work Through Information Technology,

Cambridge: Harvard Business School Press, 1992

Dollar, D., and E N Wolff, Competitiveness, Convergence, and International Specialization,

Cambridge: MIT Press, 1993

Feblowitz, M D., and S J Greenspan, “A Scenario-Based Technique for COTS Impact

Analysis,” GTE Laboratories Tech Report, TR-0351-12-96-163, 1997

Flynn, D J., and O F Diaz, Information Modelling: An International Perspective, Englewood

Cliffs, NJ: Prentice Hall, 1996

Hammer, M., Beyond Reengineering: How the Process-Centered Organization Is Changing

Our Work and Our Lives, New York: Harper Business Press, 1997

Lindquist, U., and E Johnson, “A Map of Security Risks Associated With Using COTS,”

Computer, Vol 31, No 6, 1998, pp 60–66

Ljung, L., and T Glad, Modeling of Dynamic Systems, Englewood Cliffs, NJ: Prentice Hall,

1994

Maiden, N A., and C Ncube, “Acquiring COTS Software Selection Requirements,” IEEE

Software, Vol 15, No 2, 1998, pp 46–56

Marshall, K T., and R M Oliver, Decision Making and Forecasting: With Emphasis on Model

Building and Policy Analysis, New York: McGraw-Hill, 1995

McNair, C J., “Implementing Process Management: A Framework for Action,” Hamilton, Ontario, Canada: The Society of Management Accountants of Canada, 1998

Melan, E M., and E H Melan, Process Management: Methods for Improving Products and

Service, New York: McGraw-Hill, 1992

Mende, M W., L Brecht, and H Österle, “Evaluating Existing Information Systems From a

Business Process Perspective,” Proc 1994 Computer Personnel Research Conf on

Reinventing IS: Managing Information Technology in Changing Organizations,” 1994, pp

289–296

Mesterton-Gibbons, M., A Concrete Approach to Mathematical Modelling, New York: John

Wiley & Sons, 1995

Moore, G E., “Cramming More Components Onto Integrated Circuits,” Electronics Mag., Vol

38, No 8, 1965, pp 114–117

Sarna, D E., and G J Febish, “Don’t Squander Your Legacy,” Datamation, Vol 42, No 7,

1996, pp 28–29

Scacchi, W., and J Noll, “Process-Driven Intranets—Life Cycle Support for Process

Reengineering,” IEEE Internet Computing, Vol 1, No 5, 1997, pp 42–51

Schaller, R R., “Moore’s Law: Past, Present, and Future,” IEEE Spectrum, Vol 34, No 6,

1997, pp 53–59

Talbert, N., “The Cost of COTS,” Computer, Vol 31, No 6, 1998, pp 46–52

Thompson, J R., Empirical Model Building, New York: John Wiley & Sons, 1989

Voas, J M., “The Challenges of Using COTS Software in Component-Based Development,”

Computer, Vol 31, No 6, 1998, pp 44–45

Walford, R B., Information Systems and Business Dynamics, Reading, MA: Addison-Wesley,

1990

Yoffie, D B., ed., Competing in the Age of Digital Convergence, Cambridge: Harvard

Business School Press, 1997

Young, L H., “The Process is the Thing,” Electronic Business, Vol 24, No 2, 1998, pp 75–

78

Part I: Automation asset management

Chapter 1 provided an overview of the business and technical environment in which the enterprise must operate and outlined some associated requirements for enterprise automation The task for the remainder of this book is to present an approach to

developing an effective enterprise automation environment consistent with those

requirements as well as other technical and operational considerations

There are many ways to structure the specification and development of an enterprise automation environment The framework that seems to provide the most effective

structure is based on the concept of automation assets An enterprise functions by utilizing assets to create products or services for sale Assets provide the foundation for enterprise operations and are thus a familiar concept to most business and technical personnel

Although assets are basic concepts to the enterprise, many of the assets of the

automation environment are intangible and have characteristics considerably different from the physical assets of the enterprise (e.g., manufacturing equipment) Of course, the automation environment contains some physical assets, such as computers and communications facilities Those assets usually are treated the same as any other physical asset and do not pose a significant problem For convenience, the intangible assets utilized in the specification, development, and deployment of the enterprise

automation environment are called automation assets

Intangible automation assets need management characteristics different from those of the physical assets of the enterprise For example, a physical asset requires some assigned factory or office space in which to function, while an automation asset requires

a repository, which, except for the computer in which it resides, has no physical

embodiment

Unfortunately, the automation assets used in the enterprise usually are not considered to

be “real” assets and are therefore not treated with the same degree of care that the physical assets enjoy That can—and often does—result in incorrect decisions

concerning those assets Part of the problem may be that the proper method of handling the assets is not understood or that the consequences of incorrectly handling them is not fully appreciated

This presentation is organized into three parts Part I outlines the overall asset structure and discusses the management needs for the automation assets so they can be

considered as real enterprise assets Part II discusses the definition and models for the individual automation assets Part III defines the automation methodology that converts the automation assets into the enterprise automation environment For our immediate purposes, the automation environment can be considered to be all the hardware,

software, policies, and procedures needed to provide automation support to the

enterprise A more formal definition is provided later Note that human operators are not considered to be part of the environment Although that is somewhat arbitrary, it results

in a somewhat cleaner definition and presentation does than the opposite assumption

Chapter List

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

Chapter 2: Automation asset system

Overview

The usual model of the manufacturing function of an enterprise is simple Raw materials are acquired and converted into finished goods through the use of some type of labor and equipment utilized in a manufacturing process The finished goods are then offered for sale or consumed in the enterprise The raw materials, equipment, and finished goods are considered to be assets that must be managed in some fashion to ensure that the enterprise obtains maximum value from their use

The creation of an enterprise automation environment that provides automation support for the business can follow much the same model, although it is rarely thought of in that manner The automation environment can be considered to be a finished good, one that consists of a set of automation assets, some of which are used only in the conversion phase (equipment) while others become part of the operational environment (raw

material) The assets are converted through the use of a development methodology (manufacturing process) This manufacturing model applied to enterprise automation is depicted in Figure 2.1 and for identification purposes is called the automation asset

implications for the enterprise makes the difference between a successful enterprise automation program and one that either fails outright or falls far short of its potential Toward that goal, automation asset management is defined and modeled as an overall system Each component of the system is discussed in sufficient detail to provide an appreciation of the significance and utilization of the asset management system and its application to the automation assets It should be noted that the components of the asset management system are themselves automation assets because they exist as an explicit model Although that type of recursion may seem to complicate the discussion, as a practical matter it does not

The components of the automation asset management system are shown in Figure 2.2

Figure 2.2: Automation asset management model

2.2 Managed assets

Central to the system is the automation asset being managed Such assets exist only as data organized according to the specified model or as software Because they are intangible, the assets have properties somewhat different from those of physical assets For example, a physical raw material asset can become part of only one finished good asset An automation raw material asset (e.g., software component), however, can exist

as part of many automation finished goods (e.g., workflows) That ability to easily

reproduce automation assets is one of the characteristics that produces the need to manage those assets somewhat differently than physical assets

Every asset has a life cycle: it is acquired, it is used and possibly reused, and it is eventually replaced when it wears out or becomes obsolete The life cycle must be explicitly maintained and customized for each asset type For automation assets, the life cycle must be considered somewhat differently than physical assets because the

number of individual assets is usually quite large, the rate of change of the assets is high, and there are many interrelationships among different types of assets Information about all these assets must be maintained to ensure that they are being applied in the most appropriate manner

Every asset affects enterprise financial resources throughout its life cycle Funds must

be used to provide the asset Funds must be used to maintain or utilize the asset When the asset is removed from service, it may be sold and thus create revenue or it may be scrapped and thus require additional funds Automation assets generally are not

addressed by the financial system the same way as physical assets because of the limited nature of generally accepted accounting principles To realize the benefit of the automation assets, the management accounting system, as opposed to the financial accounting system, needs to consider automation assets as “real” enterprise assets from

a financial perspective

Every asset needs a location where it can be utilized Physical assets need a physical location Automation assets also need a place to exist and to be used: some type of information storage and access mechanism Automation assets generally require a great deal of information to be available about each asset That usually is much more than a

physical asset requires The asset information is usually called metadata and is resident

in a logical construction called a repository The automation asset itself may also be

stored in a repository or in a separate database Repositories also can store information about physical assets, although that is not their primary purpose

Finally, every enterprise needs rules that govern asset management The rules

determine how and when assets are procured, maintained, used, and disposed of They determine who can make use of the assets and the manner in which the assets will be

used They usually are called business rules and should be explicitly stated Business

rules have a much broader application in the enterprise than just addressing the

automation assets Because of that, the discussion of business rules considers

enterprise areas other than the automation assets

Figure 2.2 also shows some of the relationships between the asset management system components The relationships are only broadly indicated and not specifically identified

as they would be in an entity-relationship type of diagram The relationships are complex and difficult to depict in a two-dimensional diagram without obscuring the intent of the components In addition, each managed asset has its own unique relationships with the management system

For example, in a general sense, business rules constrain how other management

system components perform their functions However, the business rules that govern how the implementation of a process asset is financed differ considerably from those concerned with financing of the software component assets used in the process

or during the individual asset presentations, depending on the specifics of the

relationship

The remaining chapters of Part I each address one of the automation asset management model components The specific assets that are managed are determined by the needs

of the automation methodology and the architecture of the enterprise automation

environment Those automation assets are defined and discussed in Part II

2.3 Asset model

The asset model component of the asset system is considered an intrinsic part of each

of the assets being discussed, and there is no need to address it in general terms That component, therefore, is not discussed as a separate aspect from the development of the asset models themselves

All the automation asset management components are developed further in the following chapters Most of the components have been individually discussed at considerable length in the popular literature as well as in scholarly publications Unfortunately, those discussions have not always led to a clarification of the topic, and considerable confusion and misunderstanding remains Although there is no intent to produce a definitive

discussion of these topics, there is a need to define and model the components in a consistent manner with an emphasis on their interrelationships The asset management system presented in this chapter provides an appropriate framework for that

self-examination

Selected bibliography

Klinger, C D., and J Solderitsch, “DAGAR: A Process for Domain Architecture Definition and

Asset Implementation,” Proc Conf Disciplined Software Development With Ada, 1996, pp

231–245

Perna, J., “Leveraging the Information Asset,” Proc 1995 ACM SIGMOD Internatl Conf

Management of Data, 1995, pp 451–452

Steyaert, P., et al., “Reuse Contracts: Managing the Evolution of Reusable Assets,” Proc

11th Ann Conf Object-Oriented Programming Systems, Languages, and Applications, San

Jose, CA, Oct 6–10, 1996, pp 268–285

Chapter 3: Life cycle management

Overview

Life cycle management is responsible for all aspects of an asset, from conception to disposal Figure 3.1, using two levels of abstraction, depicts the essence of the life cycle process At the highest level, the life cycle seems deceptively simple An asset is

created; it is used and possibly reused; and finally, after its useful life is over, it is retired The complexity comes about when we examine the next level of detail, as shown by the ovals within the boxes

Figure 3.1: Basic life cycle process stages

Before we examine each life cycle stage, it is necessary to briefly identify the type of assets being considered As discussed in Chapter 2, the automation assets of interest are intangible and exist only as intellectual constructions (models or software) Although the number of different classes of assets is relatively small, the number of individual assets in each class may be quite large Physical assets generally have weak

relationships between assets of the same class and those of different classes

Automation assets, on the other hand usually have relatively strong relationships within and between classes That requires a modeling technique that recognizes those

relationships and can adequately accommodate them In fact, it usually is necessary to model the asset classes as well as individual assets in each class

3.1 Creation stage management

As shown in Figure 3.1, asset creation is the process of recognizing a need for an automation asset, finding a way to meet that need, and obtaining and making the asset available to all users who can make effective use of it The activities in each step are discussed in the following sections A significant amount of information is needed about each asset, including ownership, date created, and scope of use Those types of

metadata are examined in the discussion of the repository (Chapter 4) and business rules (Chapter 5)

of the asset Requirements for missing assets utilize the unit model because such requirements generally are discovered on a singular basis, although one requirement may result in the specification of multiple assets

In general, both models must be used to provide the enterprise with a robust set of assets for any class However, depending on the class, one model is used more than the other For example, in determining the set of scenarios needed (Chapter 9), the class model is the major source because the scenarios are designed to reflect the desired business operation A small number of additional scenarios are defined by applying the unit model because needs are determined from actual operational experience In

contrast, human interface assets (Chapter 23) are, in general, determined on a by-situation basis, thus having the unit model as the major source However,

situation-enterprisewide guidelines usually are used in the development, bringing in the use of the class model as a structuring concept

Whichever model, if any, is dominant, the following must hold for a given asset class:

§ A harmonious relationship exists between the class model and the unit model

§ The final set of assets must be consistent, regardless of the originating method

Maintaining a consistent relationship, starting with the original use of these types of models in data definition, has always been a problem The interaction between the two models is discussed, and some possible harmonizing solutions are presented after the general characteristics and use of each of the individual models have been examined

3.1.1.1 Class models

Viewing the enterprise as a whole has always been difficult to do with any degree of accuracy In addition, using this type of view to determine the characteristics of a class of assets adds additional inaccuracies, and the result may not be useful Because of the perceived problems, the development of class models largely has fallen from popularity However, with the tendency toward management by process and the intensifying focus

on software reuse, the specification of enterprise-level models is experiencing a

resurgence in popularity The effective use of either of these approaches (management

by process and software reuse) requires a certain amount of enterprise-level modeling

Figure 3.2 shows the position of the class model in the enterprise

Figure 3.2: Position of the class model

The use of object-oriented technology for software development and the implementation for enterprisewide standards are also focusing attention on class models that are useful

in achieving maximum return from the use of those techniques The widespread use of UML, standardized by the object management group (OMG), for modeling of object classes is an indicator of the growing popularity of class-level modeling

Ideal classe s There are two basic reasons for defining and using class models The

first is to structure the entire asset class in some way so that the need for additions or changes in the set of assets can be evaluated using some reasoning or analysis

paradigm The ability to examine the defined class of assets based on the model

structure is of considerable importance

In that regard, the purposes of both reasoning and analysis activities are basically the

same, although they are achieved in somewhat different ways Reasoning refers to the

use of human intelligence to arrive at a conclusion based on the available information,

while analysis utilizes a predefined procedure or approach that could be implemented via

software The commonalty of purpose is the major reason that the two terms usually are considered together In addition, they can be used synergistically to achieve their

common results The purposes of analysis and reasoning are provided in the following list:

§ To increase insight and understanding about the asset class;

§ To perceive new information about the contents of the class;

§ To determine the usefulness of individual assets and groups of assets

in the class;

§ To identify deficiencies in the class;

§ To make decisions about changes to the class

Those purposes are not presented in any particular order All the purposes are

important, and any ordering would depend on the circumstances of a specific situation The ultimate purpose of examining a class model is to achieve an optimum set of

automation asset classes

Because the term optimum implies, in some sense, a lack of defects, the approach is

oriented toward the identification and elimination of deficiencies that can cause a less than optimum condition An ideal asset class is defined to be one that has no defects Although it cannot be proved in the usual sense, the following characteristics of asset

classes are assumed to be optimum for the enterprise The term ideal has the same

meaning as that defined earlier

§ Every asset class is ideal

§ The class of all asset classes is ideal

§ The class of relationships between asset classes is ideal

Those characteristics are easy to state but difficult to determine and accomplish

Deficiencies in nonideal asset classes are the cause of many difficulties in their utilization

in enterprise activities That is a major incentive for spending a significant amount of resources on reasoning and analysis activities dedicated to the automation assets By spending the resources upfront, the need to expend more resources later in fixing problems can be avoided

To be able to refer to all the characteristics as a single item, each of the class types as

presented in the previous list is called a reasoning class That term is used during the

course of the discussion to indicate that any listed class can be included as the object of the discussion

Deficiencies The statement that the characteristics are considered to be optimum for

the enterprise needs a brief explanation First, the three tenets of an ideal reasoning class can be stated in more familiar terms by stating the deficiencies that prevent the ideal from being achieved An ideal class has none of the following:

§ Gaps, which indicate that the understanding of needs and the use of

the class is not sufficient Gaps may require the procurement of

additional elements under conditions not conducive to proper

consideration

§ Overlaps, which indicate poor asset requirements, specifications, or

design They may be benign but are the usual source for conflicts,

inconsistencies, and superfluous elements

§ Conflicts, which indicate that element requirements were missing or

not correctly articulated Conflicts are a major source of bugs and

faulty operation

§ Inconsistencies, which indicate that the provisioning environment was

not adequately characterized They are also a major source of bugs

and faulty operation

§ Superfluous elements, which indicate incomplete or inaccurate

information about existing items They waste resources and can

confuse the provisioning process by offering unnecessary choices

Each reasoning class defined in the repository could be examined individually to show that any deviation from ideal will result in a nonoptimum condition Nonoptimum in this context means that the enterprise will expend more resources than it would if an ideal reasoning class were available The resources can be monetary or nonmonetary in nature This discussion uses a general reasoning class to avoid unnecessary repetition The concepts can be easily applied to any specific class An important point to

remember is that, eventually, each reasoning class must be examined, because any one

of them can contain deficiencies For example, a missing asset, a missing asset class, or

a missing asset class relationship can cause problems as it is utilized

A given reasoning class can contain one or more of those problems and, unfortunately, usually does The total elimination of deficiencies is almost certainly not cost effective However, the considered utilization of reasoning and analysis techniques can provide a means of achieving a set of life cycle asset classes that can provide a significant

improvement over those that can be attained without the use of these techniques The second reason to consider class models is to develop an initial set of asset

specifications and possibly some associated embodiments The term initial applies not

only to the first time the enterprise explicitly uses the defined assets but also to cases when the enterprise evolves, requiring changes to the class model This proactive specification activity eliminates the development time that otherwise would be required once the need for an asset has been determined from operational considerations From

a time-to-market perspective, that can be crucial

3.1.1.2 Unit models

Because a unit model is utilized for determining needs based on enterprise operations, it would be expected that the unit model would be simple compared to the class model An examination of the diagram in Figure 3.3, which shows the fundamental positioning of a

generic unit model in the enterprise, indicates that is not true The major complicating factor for this type of model is the need to ensure that the desired functionality

necessitates creation of a new asset and that it cannot be satisfied by one (or possibly more) currently available

Figure 3.3: Generic unit model

Determination of asset need can be made by any operational enterprise organization if suitable facilities are available It also can be made by the life cycle management

organization In any event, the unit model must be employed before any consideration of

a new asset is allowed As an integral part of utilizing the unit model, it is necessary to ensure that possible candidate assets have the proper characteristics for effective use in the expected operational environment, as discussed in Section 3.2.2.3

Although many, if not most, of the available assets will have been made available

through the definition of a class model, the use of the unit model does not require that the class model exist In this case, all assets are created on a one-by -one basis as the need for them arises In general, relying on the unit model for asset creation is more inefficient and results in a longer time to market than a combination of class and unit models As pointed out, the degree to which the use of one model or another is effective depends to a large extent on which asset is being examined

3.1.1.3 Model integration

Because unforeseen difficulties arise as a result of enterprise operations, every asset class needs some type of unit model (formal or informal) to provide a common model structure for the individual assets that are members of the class If a class model for an asset does not exist, the unit model produces a set of assets that have no organized structure among them For asset sets with a small number of elements in them, that may

or may not result in major inefficiencies For asset sets with large numbers of elements, that lack of organization almost certainly will result in significant problems, since

identification of existing assets that could be used to provide the needed function

becomes extremely difficult

Assuming for the remainder of this discussion that both models are utilized to produce asset specifications, the relationship between the two specification models becomes of interest Sometimes both models are used for an asset, but there is no direct connection between the two In that case, it is possible to get assets that do not conform to the class model Ultimately, the usefulness of the class model is compromised, and it probably will fall into disuse, resulting, by default, in an unintended unit-model-only situation

To provide the maximum benefits of both models, the relationship should be that

indicated by the diagram in Figure 3.4 Each candidate asset specification produced by the unit model needs to be checked for conformity to the class model and placed in its

proper position in the model In many cases, there is more than one possible location for

an asset in the class model, and the most useful one needs to be explicitly determined through the use of appropriate business rules and experience of the involved staff

Figure 3.4: Integration of class and unit models

For example, consider the need for a new software component asset Assume that the class model for software components consists of a building block structure in which each building block contains a cohesive set of individual components The functionality could

be provided by a new component:

§ In an existing building block;

§ In a new building block as part of an existing building block structure (class);

§ In a new building block as part of a new building block class

Which position in the model is selected for the new software component depends on a large number of factors, including how different the new component is from all existing ones, the probability that there will be a large number of similar components that have to

be accommodated (i.e., the enterprise just went into a new line of business), the

business rules governing the addition of new building block classes, hierarchies, and the knowledge of the decision maker as to the usage characteristics of the new component The important consideration about making the decision explicitly is that, regardless of the final placement of the asset in the model, the asset will be in conformity with the class model Except from a historical perspective, there is no difference between those assets defined from the unit model and those defined from the class model

3.1.3 Procurement

Automation asset procurement is much more than the usual consideration of “make versus buy” that rests heavily on financial considerations and the availability of internal