Business Process Implementation for It Professionals and Managers

Business Process Implementation for IT Professionals by Robert B. Walford

ISBN: 0890064806

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

Table of Contents Business Process Implementation for IT Professionals and Managers Foreword Preface Chapter 1

- Introduction

Part I - Automation asset management

Chapter 2

- Automation asset system

Chapter 3

- Life cycle management

Chapter 4

- Repository utilization

Chapter 5

- Business rules

Chapter 6

- Financial management

Chapter 7

- Planning and strategy

Part II - Automation assets

Chapter 8

- Process modeling

Chapter 9

- Scenario modeling

Chapter 10 - Role modeling Chapter 11 - Information modeling Chapter 12 - Client/server modeling Chapter 13 - Dialog and action modeling Chapter 14 - Software component modeling Chapter 15 - Workflow modeling Part III - Automation methodology

Chapter 16 - Overview of process implementation methodology Chapter 17 - Spirals Chapter 18 - Step 1: Define/refine process map Chapter 19 - Step 2: Identify dialogs Chapter 20 - Step 3: Specify actions Chapter 21 - Step 4: Map actions Chapter 22 - Step 4(a): Provision software components Chapter 23 - Step 5: Design human interface Chapter 24 - Step 6: Determine workflow Chapter 25 - Step 7: Assemble and test Chapter 26 - Step 8: Deploy and operate Chapter 27 - Retrospective Glossary

- List of Acronyms

Index List of Figures List of Tables

Business Process Implementation for IT Professionals and Managers Robert B. Walford Library of Congress Cataloging-in-Publication Data Walford, Robert B. Business process implementation for IT professionals and managers / Robert B. Walford. p. cm. — (Artech House software engineering library) Includes bibliographical references and index. ISBN 0-89006-480-6 (alk. paper) 1. Management information systems. I. Title. II. Series. T58.6.W324 1999 658.4’038—DC21 99-18034 CIP British Library Cataloguing in Publication Data Walford, Robert B. Business process implementation for IT professionals and managers. — (Artech House software engineering library) 1. Management information systems 2. Data transmission systems 3. Business — Communication systems I. Title 658.05’46 ISBN 0-89006-480-6 Cover design by Lynda Fishbourne © 1999 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. International Standard Book Number: 0-89006-480-6 Library of Congress Catalog Card Number: 99-18034 10 9 8 7 6 5 4 3 2 1

This book is dedicated to my colleagues Truman Mila and Mark Feblowitz, who breathed life into the PRIME methodology through their innovative application of systems and software engineering.

About the Author Robert B. Walford received the B.S. degree in Electrical Engineering from the Illinois Institute of Technology and the M.S. and Ph.D. degrees in Electrical Engineering from

the University of Southern California. He has over 30 years of diverse experience in engineering, telecommunications, and information processing, including hardware design, software design, and technical and general management. He has held engineering and management positions with several commercial organizations, including the Hughes Aircraft Company, Bell Laboratories, EMI Medical, Florists’ Transworld Delivery (FTD), GTE Data Services, and GTE Telephone Operations. He also performed as an independent consultant in factory automation for General Motors and was the owner of Tri-Ware Digital, Inc., an original equipment manufacturer (OEM) that developed and marketed a comprehensive minicomputerbased 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 AddisonWesley in 1990: Information Systems and Business Dynamics, Network System Architecture, and Information Networks: A Design and Implementation Methodology. He also has authored and presented numerous talks and articles on management, telecommunications, and software engineering topics. Dr. Walford is a registered professional engineer in Florida, Illinois, and California and a certified public accountant. He is a senior member of the Institute of Electrical and Electronic Engineers and a member of the National Society of Professional Engineers, the Florida Engineering Society, and the American Institute of Certified Public Accountants.

Foreword I think this book must have been written by a collusion of half a dozen different Robert Walfords. One Robert Walford is a subject matter expert (SME) in several areas of expertise, especially telecommunications-related domains, his broad knowledge being the result of a long tenure in the industry. As an SME, Bob has been a resource to numerous business process definition and reengineering projects, providing reliable content to their documents, models, and decision-making processes. Another Robert Walford, Bob the methodology practitioner, has been a participant as well as a guide and coach to teams following various prescribed organizational methodologies.

The lead author of this book is, undoubtedly, Bob the methodologist, whose experience as a user and a facilitator of several methodologies has been brought to bear on the design of new methodologies, striving for and encapsulating best practices. This Bob has reflected on the reasons, both technical and organizational, for successes and failures of process modeling and implementation projects. He has a compulsion and a passion for imparting clear concepts and their coherent integration, for separating the generic from the idiosyncratic, and for culling the essential from the incidental. Bob the methodologist has worked closely with Dr. Bob, as his colleagues sometimes call him, whose doctorate in computer science equips him to avoid superficiality and ensure firm theoretical foundations. Another author, Professor Bob, teacher of information technology and related subjects at the university, has made the book’s presentation eminently lucid and digestible. The approach taken in the book is heavily influenced by Bob the professional engineer, whose perspective complements those of Dr. Bob and Professor Bob. Engineer Bob is concerned with the principles and techniques that engineers use to build things that work. For example, Bob the professional engineer designed and built a front porch onto his house, which is located in a hurricane-vulnerable area. Not only did he follow current practices, standards, and codes, but he added his own engineering calculations to ensure the structural integrity of the product. I am confident that porch will be left standing after any hurricane, even if the rest of the neighborhood is leveled. Engineer Bob wants the implemented business processes to get the job done, despite the constraints and hazards of the enterprise environment. A systems engineering approach is therefore advocated. A systems engineering approach defines customer needs and required functionality early in the development cycle and follows a structured development process in which technology components are combined to end up with working systems that meet the requirements. A systems engineering approach is eclectic in that it integrates several relevant disciplines and specialty groups into a team effort. Besides expertise embodied in the components, the structured development process must include provisions to handle, from concept to production to operation and ultimately replacement or disposal, cost and schedule; training and support, quality assurance, testing, and performance; and system integration, deployment, and disposal. If asked, Dr. Walford might call himself Bob the technologist. He has been an ardent observer of information technology trends, tracking, assessing, and, when appropriate, championing adoption of new technologies in the corporation. He writes about some of those topics in this book. As you will see, Bob the technologist does not believe in silver bullets, panaceas, or overnight cures. But we can depend on him for insight, prudence, and commonsense guidance. It is hoped that understanding where the author is coming from will help readers know where they are going. But enough about Bob(s)! A concise statement of the theme of the book is the assertion (in Chapter 1) that “management by process itself requires a process.” A process for managing processes, that is, a methodology, has as one of its dimensions a set of coordinated modeling activities and guidelines (presented in Part III). Another dimension of the methodology is a conceptual framework for capturing specifications of information systems (Part II). The products of the methodologists’ labors, primarily the populated models, are viewed as assets having a life cycle, with the life cycle supported by such things as repository technology, financial management, and business rules, among other things (Part I). Preceding the three parts of the book is an introduction that articulates prerequisites, principles, and perspectives. In particular, there is cogent reflection on the significant business and technology factors that motivate management by process, rationale for the utilization of a conceptual modeling approach, and justification for the emphasis on an asset management paradigm. The preceding paragraph, which essentially summarizes the book in reverse, discloses that the book goes well beyond the explication of a single methodology. There is ample

discussion of the basic ideas that underlie the methodology—concepts, theories, rationale, and pragmatics—which apply not only to this particular methodology but also provide insights into the subject of process-oriented methodology in general. A number of pertinent topics are woven into various parts of the book and expounded in a lucid and instructive manner. Take business rules, for example, a subject fairly new but highly relevant to business process automation. Business rules are characterized as statements that define or constrain the operation of an enterprise. Business rules are always present where business processes live, and business rules induce some of the key requirements on enterprise systems. However, adequate techniques have yet to be developed for eliciting, acquiring, analyzing, implementing, and monitoring business rules. Some business rule deployment tools have appeared in the marketplace, but they are targeted at a narrow set of business rule types. The author clarifies the business rule concepts, explains the need for a broader definition, and relates business rules to process-driven methodologies. Business rules are characterized as an asset that must be managed from process definition to implementation. Through the use of business rules and business rules technology, the objective is the capability to rapidly deploy or redeploy the corresponding business logic. Another example of a well-chosen infusion of significant material is workflow. The methodology proposes that the implementation of a business process can best be achieved by mapping processes to workflow systems, based on the details of the specified tasks, actions, interfaces, and so on. A workflow system is a platform that performs the work of a business process by providing mechanisms for specifying, scheduling, coordinating, and monitoring the workflow instances that are created in response to business events. Making a workflow system part of the architecture for target implementations reduces the need to reprogram those generic capabilities for every developed system. Although the state of workflow technology, as for business rules, is not yet mature, an activity for determining workflow is included in the methodology as an indication of the trend toward using workflow technology to implement business processes. In contrast, the systems we have inherited as our legacy are not built on workflow platforms; it is proposed here that adopting workflow technologies will reduce some of the problems of creating new systems (our new legacies) and will facilitate integration and evolution. Besides business rules and workflow, it is clear that many more concepts and technologies impinge on process implementation methodology: knowledge management, document management, and integration architectures, just to mention a few. At several points in the book, the author appears poised to cover those topics, but there are limits to what one book can cover. We could not expect more from a single volume. I believe there is a substantial body of professionals, both technical and nontechnical, as well as teachers and students, who should read this book to reap the benefits of the assembled knowledge and views. I see the book as a key resource, inhabiting an environment where process implementation methodology is a defined area of expertise and where a group of appropriately trained individuals is a center of excellence to provide necessary technical and organization skills. Thus, the book contents alone are not enough. There must also be an explicit intention to act and to back the associated activities with the necessary resources. There must be a commitment to the belief that the process implementation methodology is one of the most important business processes in the organization. In fact, I would venture to say that the ability of an enterprise to perform the methodological aspects of its operations will, in the coming years, become more important than a majority of its other business processes. As technology domains mature and technology components (e.g., software applications and services provided over networks) become more specialized and standardized, a primary differentiator between enterprises may be the quality of the process implementation methodology rather than of the business processes specific to the domain. That could be considered a somewhat radical view, namely, that the critical success factor of a telecommunications company,

for example, could depend at least as much on process implementation methodology as on telecommunications expertise. To give credence to that contention, we have to ask: Where will the professionals come from to carry out the methodologies? Where will they get the training they need? What knowledge and expertise are needed for success? Some progress is being made by recent advances in university curricula, in courses on systems analysis, requirements engineering, and the like. Other skills such as facilitation and project management also are important and available. Dr. Walford folds such material into this book, demonstrating a predilection for a multidisciplinary approach, which is precisely what is needed. In addition to needing a new generation of professionals to carry out the new order of things, mechanisms for organizational change will be needed. The fact that methodologies are higher-order processes, that is, processes about processes, makes them both powerful and paradoxical. From one perspective, a methodology is carried out by agents who take on an external, apparently dispassionate view of the enterprise, and they build models from an apparently objective viewpoint; the operations they perform are on other business processes. On the other hand, the methodology is just another process (caution is always advised when the word just is used). The process happens to be performed by agents who often are stakeholders internal to the current or future configuration of the enterprise. So a participant in a methodology wears two hats: that of the designer of the new enterprise and the other of a potential occupant of the new organization. Obviously, there are some natural conflicts between self-interest and organizational altruism. The fact that a methodology is a higher-order process is therefore a challenge to overcome. Consider, as well, that the introduction of a new methodology is an implementation of an even higher order business process. That infinite regress is, in principle, troublesome, but in practice we have not reached the point where there are any significant consequences. One of the main reasons for developing a methodology is to bridge the gap between business development and information technology. Historically, the relationship between the two has been ill-defined, not atypical of the nature of relationships between customers and application vendors. Business involves business judgment and decision making, for which the most natural forms of communication have been informal media such as conversations, text, and real-world scenes. Implementors use more formal, rigorous representations as they consider system designs and get closer to procedures that execute on computers. Business is learning to be more rigorous in its process descriptions, and IT is learning to reciprocate by utilizing methods that tolerate some ambiguity and incompleteness (rather than, for example, forcing specifications into molds for the sake of direct implementation). The progression from the more freeform, unstructured languages to the more formal, structured ones is one of the obstacles the methodology is supposed to overcome by gradually transitioning from one to the other. The methodology in this book addresses that issue (often called the requirements gap) to a significant degree. It is a prescription for how the two camps can interact on a constructive basis. In conclusion, it is an admirable task indeed for the many Robert Walfords to have assembled and so plainly presented the material in this book, which is both deep in concept and broad in scope. Sol Greenspan

Preface The King is dead; long live the King! That famous cry sums up most aspects of modern business practice. The previously existing competitive environment, scope, internal structures, and automation support needs of an enterprise have disappeared and been replaced by other sets of conditions and requirements. In time, those needs, too, will disappear and be replaced by yet another set and much more quickly than before. The concept of “Internet years” applies to most aspects of modern life. To stay viable, an

enterprise must learn to live with the new king and begin to prepare itself for the next one, who inevitably will arrive when least expected. From an information technology (IT) perspective, we recently have converted from a centralized mainframe environment to one with a distributed client/server structure. Even before the latter environment began to stabilize, the rapid emergence of the Internet has created the need for yet another version with its own needs and constraints. This swift succession is likely to continue into the foreseeable future as technology advances and customers demand the services and products enabled by the new capabilities. Adding value in this environment requires that a “stretch view” along with innovative approaches to enterprise automation be used. That will result in some possibly controversial directions, but there is no hope of keeping up with the rapid pace without utilizing paths other than the existing ones. The basic unit of the enterprise, from an automation perspective, is considered to be a process rather than a particular function of the enterprise. This approach is taken not only because a process orientation is being used for much of the current work in organizational dynamics (e.g., process reengineering) but because it is a more natural construct for determining and defining automation functionality that meets the needs of the enterprise. When we consider a process approach, it rapidly becomes evident that the specification of a process is just the beginning. A considerable amount of effort must be applied to the transformation of processes from the business environment in which they are defined to the technical environment in which they must be implemented and deployed. Different process models are needed to make the transformation effective. This book specifically addresses an issue usually missed in the discussion of process engineering and management: the need for eventual implementation and deployment of the business processes. There are many publications concerned with the need for an enterprise to be process oriented and that provide approaches to the specification of so-called optimum processes through some type or business reengineering. However, little consideration has been given to how to actually implement those processes using manual or automated functions and to successfully deploy them in the enterprise. Thus, many enterprise process engineering activities have failed. The central purpose of this book is to fill that void through the specification of a process implementation methodology. The process orientation of the methodology gives rise to its name: process implementation methodology (PRIME). Unfortunately, the mere specification of a series of steps is not enough to provide a workable methodology. If such were the case, many such methodologies probably would be available. An effective methodology must fit into the current and projected enterprise business and technical environments. It also must provide a means to solve the four generic business problems: decrease costs, reduce time to market, increase quality, and provide greater value for the customer. PRIME provides a way to meet all those requirements while staying focused on process implementation. The development of PRIME rests on three supporting concepts: systems engineering, automation assets, and modeling. A systems engineering approach permits the many needed technology and business concepts to be considered as an integrated whole rather than as isolated entities. An automation asset view ensures that the entities utilized in process specification and implementation are correctly managed and their inherent value to the enterprise understood. Extensive modeling is used throughout the presentation to define and structure the discussions and permit a relatively rigorous examination of the principles, concepts, and entities involved. In many current instances, the specification of enterprise automation emphasizes technology and products with only a passing mention of an associated methodology. Technology and products, no matter how well conceived and designed, cannot be effectively employed without methodology. Even when methodologies are utilized, they

involve previous methodologies that were developed for centralized computing architectures and that are no longer appropriate. Many current methodologies are based on either data or control specifications and were first defined in the mid-1970s, when the software development and deployment environment was considerably different from what it is now. Although the existing methodologies have been adapted over the years to some extent, their basic approach has not changed, and they still are unable to accommodate the needs of a process orientation efficiently. In addition, these existing methodologies have a number of other disadvantages when they are applied to the emerging environment: For example, they do not take advantage of reuse; they are hard to adapt to a distributed deployment environment (e.g., client/server configurations); they do not adequately consider the human interfaces; they do not involve the stakeholders as an integral part of the development process; they inherently require a long time-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 twosemester sequence. Either way, student assignments would consist of example designs and investigation of possible alternatives to the suggested activities and steps of the methodology. As in actual practice, there are few simple answers to most of the questions that can be formulated. An instructor must, therefore, look to the validity of the approach and conclusions reached to determine the degree of absorption of the material. I would like to express great appreciation to Blayne Maring, former GTE assistant vice president—architecture, and Charlie Troxel, director of enterprise computing strategies at GTE, for providing the environment and encouragement that allowed the development and refinement of this innovative methodology. Girish Pathak, vice president and director of the operations system laboratory at GTE Laboratories, and Mary Reiner, director of enterprise systems, are also due a considerable amount of appreciation for their efforts on my behalf. Thanks and recognition are also richly deserved by the many associates who worked on the development and validation of the methodology during some aspect of its development. They include Truman Mila and Mark Feblowitz, to whom this book is dedicated, as well as Carl Pulvermacher, Nancy Amburgey, Ken Dilbeck, and David Wang, who participated in the pilot application of the methodology. Thanks are also due to Mark Lapham and Jeff Gilliam of Anderson Consulting, who contributed to the early development sessions.

I also would like to thank the many colleagues who participated in the early trials and initial production use of the methodology. Their patience, humor, and helpful suggestions for improvement were of invaluable help in making the methodology a success. Robert B. Walford April 1999

Chapter 1: Introduction Overview Our world has become almost totally dependent on software for its proper functioning. From the control of airplanes to the control of large enterprises, the need to rapidly develop and utilize reliable and cost-efficient software is of utmost importance. The development of software to control devices seems to be progressing at a relatively steady pace. The new Boeing 777 aircraft, for example, is almost entirely controlled by a fly-by-wire structure that is enabled through the use of complex distributed software. In addition, most of the testing of the aircraft was done entirely through computer simulation techniques that provided significant savings while enabling on-time delivery of a more thoroughly tested product. That same level of progress does not seem to apply to the use of software that supports the operation of our large enterprises. There are still many project failures and expensive overruns. The cost and the time required for development and testing keep increasing, as does the backlog of new software projects. Viable future directions that could remedy the problem seem uncertain and distant. This chapter examines the current conditions under which large (and not so large) enterprises must operate. It presents the basis on which a partial resolution to the software development difficulties that pervade modern business can be found. As such, it provides the high-level justification and context for the use of a process-oriented approach to business automation. The discussion is at a relatively high level but contains sufficient detail to show the interrelationships among a large number of complex business, social, and technical issues. It is those interrelationships that provide the clue to the software difficulties of the enterprise as well as the direction for their solution.

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

advantage of the opportunities that occur. An additional complication is that the current rate of change is far greater than in Dickens’s time. The concept of “Internet years” is very real. The future cannot be ascertained with any certainty because it is a function of the unknown dynamics. The temptation is to look for shortcuts, to follow the latest fasttalking 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 commandand-control structure. The transition is the fundamental business reason that a new approach to automation is required. The reasons for the transition and some of the major consequences are discussed in Section 1.6. The resultant impact on automation needs is presented in Section 1.7. Although management by process is considered by many to be synonymous with process reengineering, it actually is considerably greater in scope. Management by process encompasses a basic philosophy on how to manage the enterprise. Process reengineering is merely the action of trying to determine a more efficient process for performing some aspect of the enterprise operation. Although process reengineering seemingly focuses on process, in many cases it focuses on a single organization or

function within an enterprise (e.g., accounts payable) and, except at a very rudimentary level, does not require much in the way of a process orientation. In this discussion, the emphasis is on the process management philosophy. The determination of suitable processes, while of considerable importance, is relegated to the automation methodology. That ensures that the selected processes can be efficiently incorporated into the enterprise automation system. 1.5.1 Major implications The first part of this discussion has addressed the major forces on the enterprise and some of the actions, including the adoption of a process-oriented management paradigm, that have been taken to respond to those pressures. No significant change is ever undertaken without an associated set of implications, some probably advantageous and some not so advantageous. To determine how the automation needs of the enterprise are affected by a process-oriented approach, it is necessary to examine some of the organization, financial, and software implications of the process paradigm. Although the organizational and financial implications may not immediately seem pertinent, in reality, they have an enormous impact on how the automation needs are defined and obtained. That impact will become clearer as the discussion proceeds.

1.5.1.1 Organization In addition to the changes in organization structure occurring as a result of the enterprise pressures, additional organizational implications occur as a direct result of the utilization of a process-based management approach. In one aspect, processes can be defined independently of the location of the process performers. That allows individual staff members to be geographically distributed. It is no longer necessary for managers to be collocated with their staff, since control of individuals is not the function being optimized in the new approach. Workflow techniques that form an important part of process implementation and facilitate this type of organization are discussed in Chapters 15 and 24.

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

considered assets, the cost of a process over its asset management needs to be ascertained and a determination made as to the propriety of utilizing that process. The accounting function in many enterprises, because of government reporting regulations and organization culture, can prevent many of the financial aspects of the process approach from being effectively implemented. That can be implicitly done in a number of ways: § The need for considerable upfront investment can be frustrated. An emphasis on cost rather than investment can stop the procurement of assets needed to define and implement the processes. § Internal controls can be established that prevent a process from being able to be efficiently implemented. Although many functions of the enterprise can impede the transition to a process paradigm, the accounting function, because of its history and orientation, must be especially considered. This discussion is not meant to disparage the accounting function. It is absolutely necessary for the continued viability of the enterprise. The intent is to point out that all of the enterprise must change for the process orientation to succeed. 1.5.2 The process of process In this type of discussion, it is easy to forget that management by process itself requires a process. The management activities necessary to ensure that the enterprise is functioning correctly and at a high degree of efficiency should also be addressed by an appropriate process. Because the management process is an enterprise process, it is subject to all the characteristics of any process. Although this type of recursion can be conceptually difficult, in practice it offers few problems as long as there is a reasonable separation of functions within the enterprise. The management process must be considered as just another process to be managed, and the same measurements and corrective actions that are defined for any process can be applied. These processes can also make effective use of automation in their implementation.

1.6 Technology requirements and drivers The state of the art is changing so rapidly that any technology presentation will be obsolete almost as soon as it is completed. In the current environment—to put it bluntly—nothing is stable, everything is flexible, the choices are enormous, and few products from different vendors interoperate. In addition, the applications are more complex, and the time-to-market need is more critical. Those conditions are not likely to change in the foreseeable future. Any approach to enterprise automation must directly consider this environment in addition to the classical functionality requirements. The only way to accommodate all those additional pressures and still produce a product that always meets the needs of the customer when it is deployed is to define and utilize anappropriate automation methodology specifically oriented toward process implementation. The required methodology must provide structures and activities that explicitly consider the conditions of the current environment and take advantage of the opportunities they offer while mitigating the difficulties. As would be expected, a considerable number of technologies affect the automation requirements of the enterprise. A comprehensive treatment is far beyond the scope of the current presentation. Many of those technologies are addressed in later chapters, where they are utilized in the formation of an automation methodology. From an overall enterprise perspective, however, it is necessary first to consider the major technologyoriented pressures and constraints under which the enterprise must function: § The Internet (and associated technologies); § Digital convergence; § Commercial off-the-shelf (COTS) products;

§ Legacy systems. This section considers each of those pressures in enough detail to determine its effect on the automation needs of the enterprise. 1.6.1 The Internet There is a temptation to devote a considerable amount of discussion to the Internet because of its large and growing impact on the enterprise from both a business and a technical perspective. That would be a mistake for two reasons. First, the technology is changing so rapidly that little could be said that would remain current for any significant length of time. Second, an abundance of literature is available that addresses almost every aspect of the Internet in far greater detail than could be accommodated in this book. The reader is referred to those sources for further information. This discussion of the Internet is limited to the realization that it represents a source of great impact on the enterprise, and any automation functionality must consider the implications of the technology. In spite of these difficulties, the presentations in the book are relatively independent of whether or not Internet technology is utilized generally or in specific situations, but process, budgets, content management, and IT management are relevant. The technologies presented and the automation methodology that they support are necessary under any condition. From a technical perspective, most of the effect of the Internet is contained in the computing infrastructure. The infrastructure is a complex entity, a thorough discussion of which is beyond the scope of this book. However, appropriate aspects will be addressed as needed for completeness during discussions of specific topics. From a business perspective, the Internet can greatly influence the conduct of the enterprise or even provide the reason that the enterprise exists. Although that will determine the number and the type of processes and associated automation needed, it does not change the need for a process orientation and an associated automation methodology. 1.6.2 Digital convergence Much current and most future product technology is based on a digital format. The common digital representation structure allows computer, television, radio, telephone, and other major technologies to be integrated and viewed in the same uniform way. A bit is a bit is a bit. It can be processed, transmitted, and presented in a consistent manner regardless of the original source or intended use. Although the ubiquity of a bit is the basis for convergence, there can be different requirements for the temporal relationship between bits. For example, real-time transmission may require that the delay for each bit in the transmission be approximately the same, while that may not be necessary for the transmission of non-real-time information. Those requirements usually fall under the heading of quality-of-service (QoS) characteristics. Depending on transmission needs, the QoS specification may vary. The possible need to specify a QoS characteristic does not alter the meaning of an individual bit, so the core aspect of convergence is preserved. The extent to which the digital architecture can blur the separation between products is illustrated by the following examples. A personal computer is fitted with a microphone, speaker, and modem and used to communicate via voice. What is the difference between that computing device and what is usually known as a telephone? If a television is coupled to a settop box connected to a video cable and used to connect to the Internet, what is the difference between that equipment and a personal computer connected to a telephone line? The examples could continue, but those should provide the basic idea. As long as a product has digital underpinnings, it is defined more by what it does than what it looks

like! In many ways, it begins to resemble and behave like an ecosystem rather than an architecturally driven configuration. Digital convergence can also lead to other types of convergence, including that of organizations and even industries. An example would be the possible convergence of the television and personal computer industries. That could occur only in the context of digital convergence. Convergence of organizations leads to the need to integrate their individual automation systems. Anticipation of the continuing convergence of organizations through mergers and consolidations forms another requirement for the design of automation support that can facilitate this type of activity. In addition, the automation impact of digital convergence is the need to allow different areas of an enterprise to interact more closely with each other and to cooperate in the development of new products and services that can use common components and processes. 1.6.3 COTS products The high costs of developing new software and the increasingly large backlog have begun to significantly affect how an enterprise obtains new software. Software procurement directions are becoming increasingly oriented toward the use of software that is available on the general market as a prepackaged system or set of functions instead of the development of custom software. This type of prepackaged software generally is referred to as COTS products. COTS refers to any entity that is purchased as offered, including processes, user interfaces, and textual instructions, but it most often applies to software packages. The software packages can be of any size, and there is conceptually no restriction as to the packaging method. For example, a COTS product does not have to be shrink wrapped, and it can come with support personnel from the vendor. For the most part, this discussion focuses on software products, although the context is expanded, as needed for generality, to include other types of COTS entities. Legacy systems and other existing entities (e.g., reusable components) can be considered a type of COTS product because they are existing, packaged items. Most of the discussion provided for COTS can also be applied to the incorporation of current legacy systems. To strengthen the analogy, many enterprises, to increase their revenue from previous development activities, are selling their internal legacy systems in the open market. The legacy systems of the enterprise then become COTS products to their perspective customers. The use of COTS products to meet an enterprise need has long been the rule rather than the exception for hardware-oriented products such as those from the electronics and equipment industries. For example, COTS products in the electronics industry range from small components, such as individual resistors and capacitors, to large systems, such as computers and radio transmitters. Few users of such components build their own; they almost always purchase what they need. Integrating existing components to perform the desired function has always been the focus of these types of industries. The required infrastructure and product architecture were developed with that specific activity in mind. The engineering procedures and techniques to accomplish the integration are relatively well known but almost always require expert knowledge to produce satisfactory results. Utilizing this approach in other industries, including automation software, has always been a goal, albeit an illusive one. The lack of standards, along with a philosophy that encouraged a construction approach rather than an integration approach, worked against the use of COTS products. That view is rapidly changing, however, because the current economic and competitive pressures are reaching an intensity that almost forces the consideration of a COTS approach before any custom development is undertaken.

The automation impact of using COTS products is that they must be appropriate for the part of the business in which they will be used. That must be enforced by both asset management and the automation methodology. 1.6.4 Legacy systems Although legacy systems are not really a force that impinges on the enterprise, they certainly are a direct result of the enterprise reaction to such forces. In that sense, this topic is appropriate for consideration as a technical driver. In addition, the reaction of different enterprises to the, in many cases, “sudden” appearance of legacy systems has been varied and usually occurs without sufficient analysis and planning. The purpose of this section is to examine the reasons that the so-called legacy systems come into existence, the general properties of such systems, and an analysis of some positive approaches to their utilization instead of the almost universal negative connotation that any discussion of such systems engenders. In fact, use of the term legacy represents an attempt to moderate the effect of the use of some other widely used terms for this type of software, such as old, obsolete, and outdated. In fact, a legacy system may be described by one of those terms, but it is also possible that a legacy system is relatively new, of good design, and useful in the operation of the enterprise. Although it probably was not consciously realized, the use of the term legacy is appropriate for the change process that is taking place. Because of the importance of legacy systems in the enterprise and the general lack of analysis of such systems in the literature, it is useful to develop this topic in some detail. Incorporating legacy systems (at least temporarily) in any automation system is necessary to facilitate an effective migration.

1.6.4.1 The concept of legacy Dictionary definitions of the term legacy include “property left by will; a bequest; something that has been handed down from an ancestor or predecessor.” Going to the dictionary definition for the term is interesting because, in general, the familiar context of a legacy is usually considered something good. Being the recipient of a $1,000,000 bequest from a long-lost relative is the dream of a fair number of people. However, the term also can be used in a negative sense, as in “His behavior left a poor legacy for his family.” In either case, a legacy follows the third definition. It is something that one entity inherits from another. The entity doing the inheriting usually has no control over either the timing or the contents of the inheritance. Indeed, the bequestor also may have little control over the timing, although there usually is some control over the contents. In the context here, that of computer systems and software, the uncertainty properties of a legacy, as well as its usual characteristics, provide the prevailing atmosphere for the attitude held by most workers in the area. The reasons for the almost unanimous negative view are examined here in some detail. As part of the analysis process, a model of legacy software and the associated operational environment is developed. The model is then employed to provide some directions that will enable legacy systems to be used to facilitate the transformation of the enterprise, rather than being considered a major impediment to change. As a quick aside, this discussion is presented from an engineering point of view, not a legal one, although many of the concepts and terms utilized in the discussion originated in the legal sense. In addition, many analogies between the two points of view are drawn to help convey the required information. It is possible that some of the definitions given, statements made, or conclusions drawn by the author are not correct in the legal sense. The potential conflict between engineering and legal concepts is not new and should not present a problem unless the reader is both a lawyer and an engineer.

1.6.4.2 The legacy environment To have a legacy, three things are required: a predecessor, a successor, and something (the legacy) that is going to pass between them. The transfer is considered to be one way, from predecessor to successor. As already stated, the successor usually has no

control over the timing and the contents of the legacy, although, strictly speaking, that is not a required condition to have a legacy. To develop a useful model of the legacy environment, as applied to computer software and systems, it is necessary to consider each of the three components of a legacy as presented in Figure 1.4. The rest of this section examines the definitions and the characteristics of the individual components as well as the overall structure of the mode.

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

There have been many development environments in the history of computers, and many of them continue in some fashion even today. In fact, one of the most popular development environments is of the null environment. No standards are defined and everything is done ad hoc. For purposes of this discussion, it is not necessary to consider all the development environments and transitions that have been utilized in the past. Only the latest set is utilized to illustrate the concepts involved. The most prevalent development environment used, until very recently, was based on the custom development of closed software systems using a centralized mainframe processor. This type of development environment produced software systems and computing platforms with specific characteristics. § Self-contained: Each software system was an entity unto itself. Identifying and obtaining access to the individual functions and components are difficult. § Local service access: The services needed by the software system were available locally, including security, timing, transaction monitors, and data access. There was no need to build in remote-access capability. § Operating system dependent: Although all applications are dependent on the operating system to some extent, most software was completely intertwined with the operating system used, usually the IBM MVS. § Batch oriented: Because of the design philosophy of the operating systems used, application and development architectures were fundamentally batch oriented, even though humans were sitting at terminals trying to direct the operation and at least thinking that they were in charge. § Systems network architecture (SNA) communications protocol: Because of the widespread availability and the use of IBM-compatible platforms and MVS operating systems, this protocol was almost universally used for large systems. § IBM and compatible mainframe computers with 3270 format terminals. As would be expected, there are a large number of other characteristics, but those listed above will suffice for now. Because of the rigid characteristics of this development environment, it could not evolve to meet the new needs of the enterprise. An entirely new development environment was needed. The old development environment died and became the predecessor component of a new legacy environment. The successor component in the new legacy environment is the new development environment structure. Suddenly, the existing systems and their development and operational environments became a legacy. Because the predecessor development environment was now considered old and obsolete, this characterization was instantly transferred, rightly or wrongly, to the legacy software. The practical result was that almost all software developed under the predecessor development environment was looked on with scorn. The successor The successor development environment, as would be expected, consists of the same basic types of activities as those of the predecessor environment, the difference being in their definitions and structural characteristics. The development environment that replaced the predecessor one is based on the utilization of commercial and reused software components in a distributed environment. This type of development environment produces software systems and computing platforms with characteristics very different from those of the predecessor. § It is built from individual functions. The focus is on the implementation of processes built from individual, identifiable commercial or reused components from previous enterprise systems. The concept of a system disappears.

§ § §

§ §

It has remote-service access. The services needed by the software system can be distributed anywhere on the network. The capability must exist to obtain and utilize those services wherever they exist. It is operating system independent. The goal is to define applications that can run on different operating systems, such as UNIX and Microsoft Windows. It is online oriented. Many applications are expected to remain operational 24 hours a day, 7 days a week. That requires major differences in the way software is designed, implemented, operated, and maintained. It has a TCP/IP communications protocol. This protocol is designed for a distributed, transaction-oriented, online application environment. It is a client/server operational environment. Both clients and servers have significant amounts of computing power.

As should be evident from a comparison of the characteristics of a successor development environment with those of a predecessor development environment, they are in many cases exact opposites. That is why a new development environment had to be defined rather than an evolution of the older one utilized. The legacy Remember that the legacy comes from the predecessor and goes to the successor. What is being transferred from the old development environment to the new? The simple answer is the operational software (systems) that existed at the time the new development environment was deployed, hence the term legacy systems. Unfortunately, there is much more to the legacy than the systems themselves, and that is where things begin to get complex. Note from Figure 1.4 that the legacy consists not only of the operational systems but also of all the predecessor elements needed to keep them operational until new software resulting from the successor development environment can be made available to replace them. The entire set of items the legacy comprises is called the automation legacy to indicate that it consists of much more than the software systems. The use of the term legacy is qualified in the remainder of the discussion to refer to only a portion of the whole legacy. Sometimes it is thought that the term legacy means that the included 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 processbased enterprise, the concept of a process must be considered in some detail. Although such an examination could be accomplished in this section, it is easier and more effective to provide the needed discussion in the context of process modeling, presented in Chapter 9. Postponing the detailed discussion allows for more effective integration of the concept of process with the other entities that are closely associated with it, such as scenarios, roles, and dialogs. In addition, the context of asset management, which includes business rules and financial management, is important in the specification of process-based automation and must be included in any detailed discussion. The fundamentals of the asset management approach are presented in Part I. 1.7.1 Process orientation Matching automation software development to the management-by-process paradigm is not just a matter of adapting the correct architecture, infrastructure, and development methodology. In many advertisements and articles in the popular literature, however, that seems to be the message. Even if perfect architectures, infrastructures, methodologies, and supporting tools were available (and we are quite far from that condition), the effort would not succeed without a different attitude toward software development. Supporting processes with automation software requires that the enterprise adapt an integration philosophy instead of a closed-system model. In addition, the manual activities and the automated activities must work in concert to implement the process. From a software perspective, that requires that software be implemented or otherwise obtained in the form of discrete components that are then connected through an appropriate control mechanism with the necessary degree of human input. They may be large COTS products or small individual components. Another important aspect is the use of an infrastructure through which all the components can interoperate with each other as well as with the humans utilizing them. The defining item for the change in software direction is not the size or the construction of the components or the infrastructure. It is the philosophy that the enterprise follows in its software-oriented activities, and that philosophy is supported by the financial and organizational structures of the enterprise. If management still views enterprise automation as individual pieces of standalone software with no need to facilitate the communications between them, management -by-process will never reach the degree of effectiveness of which it is capable. That easily can result in the enterprise being placed in a significant competitive disadvantage. In addition to the need for a different automation approach and an associated software philosophy, there is also a need to consider how to migrate effectively from the old philosophy to the new one without hurting the day-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 Chapter Chapter Chapter Chapter Chapter

2: Automation asset system 3: Life cycle management 4: Repository utilization 5: Business rules 6: Financial management 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 system.

Figure 2.1: Automation asset system.

2.1 Asset management Each part of this book addresses a different aspect of the automation asset system model. Part I considers the management needs of the automation assets. While much of the discussion would be familiar to anyone involved with physical asset management, critical areas are considerably different. Understanding those differences and the 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 implementation. The relationships also change depending on the specific stage of the asset life cycle. Again considering the finance example, the financial aspects of configuration management during the creation of an entity are different from those present during the use or reuse of the entity. Explicit relationships that need to be addressed probably are best discussed either in the presentations of individual management system components 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 selfconsistent manner with an emphasis on their interrelationships. The asset management system presented in this chapter provides an appropriate framework for that 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).

3.1.1 Need recognition There are two ways to determine the need to create an asset with specific functionality or characteristics. The first way is to develop a model of the enterprise that addresses one or more asset types. From that model, appropriate assets are specified. The model is called the class model because it is used to provide the specification for all assets of the same type (or class). The second way to determine asset need is to recognize that some operational aspect of the enterprise cannot be completed or is less efficient than possible because an asset does not exist. The structure of a given asset is called the unit model 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 situationby-situation basis, thus having the unit model as the major source. However, 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.2 Requirements determination Once the need for an asset is recognized, the requirements for that asset must be determined. The complexity of this determination depends on such factors as the business need and the unit model of the asset involved. If, for example, the new asset needed is a process, a unit process model will have a great impact on the requirements for any new process. 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

development resources. Because of the characteristics of automation assets, especially the close relationships between assets and asset classes, many aspects must be considered before the best course of action can be determined. The most cost-effective procurement priority for these assets is generally as follows: 1. Reuse assets the enterprise already has. 2. Modify assets that the enterprise already has. 3. Buy a COTS product. 4. Modify a COTS product. 5. Develop a custom asset inhouse. The weight given to each course of action greatly depends on the asset. For the specification of an enterprise scenario asset, the only procurement methods considered usually would be 1, 2, and 5 because scenarios are enterprise specific. For a software component asset, all the procurement methods would be considered. The analysis necessary to determine the best way to meet the identified needs requires a relatively complex set of activities. Although a comprehensive treatment of this subject is beyond the scope of this presentation, the approach is briefly outlined as follows. Again, it must be noted that not all the considerations addressed are applicable to all assets. They must be determined on a case-by-case basis. 1. Document the requirements and specifications in a standard form. One of the major reasons for modeling an asset is to establish a standard structure or form for the asset. Because each asset class has a known form, comparison between the assets is facilitated. Without a standard form, performing the remainder of the activities needed for procurement analysis would be almost impossible. 2. Determine which set of existing assets, if any, can meet the functionality need. That is accomplished by answering the following questions in order: § Are there any existing assets that match exactly the needed asset functionality? § Are there any existing assets that have a model that exactly contains the needed asset functionality? § Are there any existing assets that have functionality close to the functionality of the needed asset? § Is there a set of assets the union of which exactly contains the functionality of the needed asset? § Is there a set of assets the union of which contains functionality close to the functionality of the needed asset? 3. Determine which, if any, of the assets can most effectively meet the need. That is accomplished by considering the effect of the asset in four areas using a questioning technique: § Business: What amount of the required functionality does the candidate asset have? Is any inherent product process compatible with the process in which it will be used? What are the risks and constraints in using the asset? § Technical: Does the asset interoperate with other needed assets? Is the asset compatible with the infrastructure. Where is the technology that is used for the asset in its life cycle? § Financial: What is the cost of the asset to procure, change if necessary, and operate? Can it also avoid future costs or help generate revenue? § Operational: What is the quality of the asset? How long will it take to put into service? How efficient is it in the use of corporate resources? Are any staff members experienced in its use? How much training will be required?

4.

5.

Determine how the selected asset(s) can most effectively be utilized. The usage modes are given in the following list and some of the consequences are discussed in Section 3.2.1. § Use as a private element with no intent to reuse. This mode should not be used very often, but occasionally it is necessary. § Use in a shared mode. There is one physical copy of the asset, and all users share the embodiment. That is the optimum mode, because changes need to be made only once and they are instantly effective. However, a proposed change to benefit one user must be examined to determine its effect on other users. § Use in a copy mode. There are multiple identical physical copies of the asset. They must be carefully coordinated to ensure that all copies are kept in agreement. § Use in a modify mode. There are multiple physical copies of the asset with each having the possibility of some differences. There may or may not be a master copy of the asset that was the original source for the multiple copies. § Use in a specifications mode. There is one specification for the asset but multiple physical embodiments may be different. Embodiments may also be produced from changes to the basic specification. Develop a new asset if no existing one is suitable. For large assets, this is the least desirable; for small assets, it may be the most effective. The determination greatly depends on the given situation.

The purpose of this discussion is to indicate the differences in addressing the procurement of intangible automation assets from that of physical assets. It only touches on the many types of analysis and reasoning that must accompany any need to obtain a specific asset. Each area could be the subject of a lengthy presentation. 3.1.4 Deployment Once the asset is obtained in a suitable form, it must be made available to potential users, and information concerning its characteristics must be made a part of the repository. Depending on the asset, it may also reside in a repository or in some other type of storage suited to its characteristics. Deployment is the procedure that performs that activity. Once an asset is deployed, its creation stage is complete, and the asset is ready to be advanced to the next life cycle stage. Many areas must be examined to determine the best provisioning approach. Should availability be gradual or immediate? Available to all users or a select few? Should some type of user training be performed prior to availability? What type of backup plan is needed if unforeseen problems arise? Some of those issues are addressed in Section 3.2; others must be left to other sources for the required information.

3.2 Use stage management The use stage requires two distinct types of management activities. The first, called configuration management, manages the change, update activity, and referential integrity for the automation assets and their users. The second, operations management, manages the availability and accessibility of the existing assets. Both types of management are necessary to provide users with asset functionality when it is needed.

3.2.1 Configuration management To facilitate the remainder of the discussion, configuration management is partitioned into four areas: versioning, updates, interoperability, and multiple users. The activities and capabilities of each aspect are presented in sufficient detail for the reader to understand their purpose in the asset life cycle.

3.2.1.1 Versioning Version control consists of the information and functions needed to maintain positive control over the state of each asset that is part of the environment of interest. The purpose of version control is to ensure that all the communicating assets are compatible with each other in those areas necessary for correct operation. It is, of course, possible to define and utilize separate pools of compatible assets, with each pool used for different purposes. Versioning information can be utilized in a number of areas, but its main purposes are for the evaluation of proposed changes to the product and version mix as well as to help determine the cause of any interoperability problems that arise. Versioning also implies the maintenance of a history of changes so that an audit trail is available if problems arise.

3.2.1.2 Updates While the versioning activity tracks the different product versions, the update activity determines: § What products and versions will be deployed; § What schedule will be used for the deployment; § What type of user turnover will be utilized. In short, the update (or release planning) activity is concerned with providing a continuing effective set of products that will meet the automation needs of the enterprise. The products can be either COTS products or proposed or actual custom implementations. It is not unheard of for an organization to develop a custom product at great cost and then, for valid configuration management reasons (e.g., a needed product from an outside supplier does not meet the needed interface requirements), decide not to deploy the product or version or delay it for a significant amount of time. This type of problem usually results from lack of communication among the various enterprise functions, although rapidly shifting enterprise needs can also be a culprit. Determining, in general, what products are to be utilized in the enterprise environment is a complex undertaking well beyond the scope of this discussion. Determining if a new version or replacement of an existing product is to be deployed is somewhat more manageable and is the focus of this presentation. Also, the update decision can have more of an impact on the users than the decision to utilize a new product for which the functionality does not yet exist in the environment. Many questions must be asked and answered. Some of the major questions are: § Does the new version interoperate with the current versions of other deployed products? § Are the new or improved functions really needed by the users? § Are any existing functions eliminated in the new version? § Do any hardware platforms require an upgrade? § What is the total cost for the upgrade (including acquisition, operations, and upgrades)? § When is the next upgrade due and what changes and additions will it have (can one or more versions be leapfrogged)? § What operational considerations need to be addressed (are additional support personnel needed)?

As those questions indicate, both technical and financial aspects must be considered heavily in the decision to deploy or not to deploy a new version of a product. It is tempting to consider the product as utilized in the previous discussion only as a software product. However, it is useful at this point in the discussion to note that configuration management is applied to every asset with a life cycle. Thus, versions and updates of such items as business rules, processes, scenarios, and so on, are also subject to this type of analysis. Although they are not addressed in that particular context in this book, so are enterprise organization charts and personnel assignments. The fact that configuration management applies, in one form or another, to almost all enterprise assets needs to be kept in mind throughout the discussion. When to deploy a new product version can also be a difficult decision requiring considerable analysis. The following factors may be of importance in this consideration, depending on the asset in question: § Volume of use versus time (including day, week, month, holidays, and so on); § Need for new or upgraded features and functions; § Number of other products that have to be deployed simultaneously; § Associated requirements (power shutdown, equipment reconfiguration); § Skill level needed for deployment (clerk, engineer, team of specialists); § Complexity of deployment (testing required, remote or local location, previous experience). When a new product or version is used, there is always an increased possibility of problems. Even though the change may be welcomed and wanted by all concerned, traveling in unfamiliar territory almost always causes difficulties. It is usually wise to assume the worst in that regard and plan the deployment accordingly, regardless of specific answers to the questions.

3.2.1.3 Interoperability In Section 3.2.1.2, the links of interest were those between different versions of the same asset or replacement assets. The link that defines the interoperability between different assets has not yet been considered. That link is the operational link between assets that must exist to meet some enterprise need. The information is of considerable importance in determining the effects of changes to one or more of the assets. Unfortunately, this type of link can be complex. The two kinds of operational links of interest are interoperability and aggregation/decomposition. The interoperability link is one that indicates that two assets must operate together in some fashion to provide the needed results. The concept of interoperability varies depending on the asset involved. For example, interoperability between two processes means that two different processes must be utilized to respond to a business event. Interoperability between two data structures means that the definition and the relative position of each element in the structure must be the same. Interoperability between two roles means that the roles must be defined such that they can cooperate in the handling of a request. Because two assets are capable of interoperating or have interoperated in the past does not mean that they will do so in the current operational environment. For example, assume that an enterprise has a machine repair process and an advertising process. Both processes are implemented using the same unit model and facilities. Should there be a need to interoperate, the two processes probably could. In fact, the configuration management information could show a link between the two processes with the characteristic that they were both compatible in some way. Usually, however, the two processes are different enough that there are no explicit interconnections between them. They do not interoperate in support of the business.

Why is that distinction important? Consider an augmentation of the previous example by the addition of a third process, one that is concerned with accounting. Assume also that the accounting process is also implemented with the same unit process model as the machine repair and advertising processes. They all can interoperate. However, the accounting process currently has explicit interactions with the other two. If the advertising process should be updated, its effect on the accounting process would have to be determined. The machine repair process is not affected and would not have to be examined unless the accounting process changed. A later change may affect the machine repair process, and that would have to be determined. Because assets can be used in multiple ways in different areas of an enterprise, any analysis concerning the effects of a product or version change must be based on the current asset interactions across all enterprise processes or needs. That is another reason for the asset modeling approach presented earlier in this chapter. The second operational relationship of interest is that of aggregation/decomposition. In this relationship, the assets that form parts of other assets must be known. One of the most important of those assets is the tasks that are used to provide the functionality for a process. Because a specific task can be contained in more than one process, determining the effect of a change to that task would require examining the effect on every process of which it is a part. That can be carried one level further. Assume that a task consists of multiple software components. Then the same component could be a part of multiple tasks, each of which is used in multiple processes. A proposed change to a software component could have widespread implications, each of which would have to be examined and the effects determined. Depicting the operational links in a fashion that can facilitate the understanding of the effects of proposed changes is an area of considerable interest. A graphical indication of the existing interactions between assets is a useful representation of that information for some types of assets. Such assets would include processes, software programs, and manual tasks. Figure 3.5 illustrates this type of map for software programs. The map in Figure 3.5 is a type of entity-relationship (E-R) diagram in that it shows specific relationships between connected assets. For clarity, only some sample relationships are provided. Note that the software programs come in different forms. Included are standalone systems, utilities, and tasks that are meant to be used in conjunction with other tasks.

Figure 3.5: Interaction map. Also included are workflows that refer to aggregates of software programs that together implement some enterprise process. For large numbers of programs, this type of map can become convoluted, but the pattern recognition it affords can make it quite useful under certain circumstances. There is no time associated with this type of diagram because the control aspect of the asset relationship is not included. Control generally is not considered under the scope of configuration management because it deals with the dynamic operational relationships among some specific types of assets. Configuration management considerations usually are restricted to static information and relationships. The same type of reasoning also would exclude process operations statistics and other transient data.

For some other assets, such as business rules, a graphical map would not be appropriate because of the large number and small size of the assets involved. For those types of assets, some algorithm that could provide the needed analysis and reasoning can be utilized instead. The responsibilities of configuration management in the decision as to the appropriateness and timing of changes are considerable but, in general, too often ignored, and the concentration is simply on version control. That lack of information can lead to inadequate and inappropriate decisions regarding proposed changes to an asset. Admittedly, the amount of information is large and the functions complex. However, the effort must be made to help ensure suitable control of the asset life cycle.

3.2.1.4 Multiple users An asset can have multiple users. The users can be other assets, humans, or both. Multiple usage of an asset can be manifested in many ways. Multiple users can: § Share the same embodiment; § Use a copy of the embodiment; § Use a derivative of the embodiment; § Use a different embodiment of the same specification; § Use a derivative of the specification; § Use any combination of the above. Each method of multiple usage imposes different requirements on the change analysis function. If, for example, two users share the same embodiment of a function and one of the users proposes a change, the other users must be able to accommodate the change for the change to be made and the same relationship maintained. If the change is absolutely necessary for one user but cannot be tolerated for one or more of the sharing users, the relationship must change for those users. In that case, the relationship probably would change to that of a derivative of the embodiment. There is always a question as to why user information must be maintained for other than shared relationships. The answer is that even in derivative situations, it is good engineering practice to keep all the asset embodiments as close as possible to minimize their proliferation. That in turn reduces maintenance and facilitates the determination as to what changes should be made in any given asset and embodiment. For example, assume that user A uses one embodiment of an asset, while user B uses a derivative of that embodiment because not all the functions of the asset can be accommodated by user B. Further assume that user A finds a problem with the asset and determines what is needed to correct the problem. It is entirely possible that the same problem exists in the asset embodiment used by user B. If the information concerning the derivative use relationship was not kept, there would be no way of determining which asset embodiment should be examined for the effects of proposed changes. Keeping all the user information is a function of configuration management. That represents a considerable administrative burden, but the results usually more than compensate for the resources that are expended in the maintenance of the necessary information. 3.2.2 Operations management The purpose of operations management is to maintain an environment that can effectively support the assets utilized by the enterprise. The environments vary greatly from industry to industry and from enterprise to enterprise within an industry. An environment is defined as that portion of an enterprise concerned with utilizing and maintaining a set of related assets for the economic well-being of the enterprise. Operations management activities usually are partitioned into two basic types: online activities and offline activities. Online activities are those that must take place simultaneously with the operations aspects of the environment and usually involve the

same general time frame. For example, monitoring a communication network for traffic congestion would be an online activity because it is taking place at the same time the network is being used to provide a service. The major online activities are monitoring and problem detection and correction.

3.2.2.1 Online management Monitoring is an activity that is not an end in itself. The result of any monitoring function is to provide data for use in performing some other aspect of operations management or for other automation asset system management functions such as configuration management. Monitoring must be accomplished in such a way that it does not interfere with operations activities. The output of a monitoring function can be stored to be used by an offline activity or sent in real time to another management activity. Problem detection determines if the asset is performing in the way that was intended. That generally is accomplished through the real-time examination of data produced from the monitoring activity. A problem can appear in many forms. Using the network example, a problem could be a broken connection, congestion, or capacity traffic. Once a problem is found, it must be corrected from a service perspective. That does not mean the problem is eliminated (i.e., repaired). It only means that the service expected by a user is restored. In the case of a broken network link, that could involve dynamic rerouting of traffic around the break. In some cases, as will be discussed later, a temporary fix is not possible, and the only way to correct the problem is to effect a repair.

3.2.2.2 Offline management Offline management refers to activities that do not have to occur while the operational activities are taking place or that require a different (usually longer) time period in which to accomplish the function. An example of this type of activity would be preventative maintenance. In fact, preventative maintenance usually is scheduled so it can take place while operational use is absent or at a minimum. The major offline activities are: § Help; § Preventative maintenance; § Repair; § Capacity planning; § Facility expansion.

3.2.2.3 Environments An environment is defined as a set of enterprise assets that must be managed as a unit. The concept of an environment is needed as a framework in which to integrate a set of assets and other components of a business that need to be considered together. Assets can be hardware, software, data, or, in some cases, a combination. The enterprise automation environment (further defined in later chapters) is an environment as specified by the definition. The assets of the environment include the operational software, hardware, and communications networks. The specification of the “best” set of environments depends on the type of business concerned and the pragmatics of the specific enterprise involved. However, because the environment is the basic unit of operations management, some attention needs to be given to the definition of a suitable set of environments. There can be many reasons for the definition of a specific environment: § It utilizes a special or hard-to-obtain type of expertise. § It must be managed as an integrated system. § It accounts for a significant amount of the enterprise assets. § It is crucial to the efficient functioning of the enterprise. § It requires tight security or other form of close control. § It is merely a convenient unit of specialization for the management of complexity.

Except for the last item, the motivation for those reasons is that they require explicit attention. Without that attention, the effectiveness of the environment eventually would be compromised. Although the concept of an enterprise environment would be advantageous as defined, some additional characteristics are useful in ensuring that no significant area is omitted from inclusion in an environment: § Environments are mutually exclusive. An asset can be a member of only one environment (copies of assets are considered separate assets). § Environments are complete. Every asset must be a member of an environment. Operations management is a management activity directed toward ensuring that the assets used in the operations activities of the environment are in a state that provides the maximum effectiveness. A more formal definition of operations management is a set of activities whose purpose is to maintain the assets of an environment such that a set of predetermined characteristics of the assets are preserved. The characteristics in the definition refer to the qualities that the asset must have to be considered in a state appropriate to its use in the operations of the enterprise. In addition to the enterprise automation environment, the asset management system is also an environment. The set of related assets of the automation asset management system are the repository and those assets addressed by the repository. In the case of physical assets and some logical assets such as software products, the repository may contain only information (including metainformation) about the assets. In that case, the repository information is defined as separate, but associated, automation assets. Some assets, such as scenarios and business rules, may exist only in the context of the repository. All other assets of the enterprise are partitioned into other environments as needed. The definition of the automation asset management system as an operational environment can be motivated by examining the reasons that an environment is defined. § It utilizes a special or hard-to-obtain type of expertise. The expertise needed to supply an effective repository function is specialized. Ensuring that effective automation assets are available when needed requires planning expertise, technical skill, and negotiating prowess. § It must be managed as an integrated system. The automation asset management system and the assets that are managed by them must be considered as a tightly coupled aggregate. § It accounts for a significant amount of the enterprise assets. Depending on the specific business involved, that can indeed be the situation. In the case of an information technology–oriented enterprise, that almost certainly would be true. § It is crucial to the efficient functioning of the enterprise. Businesses can and do operate without an emphasis on the management of the automation assets. However, the efficiency of providing a service can be increased considerably by utilization of the concepts of automation asset management as presented herein. § It requires tight security or other form of close control. Automation asset management requires a significant amount of security to ensure the integrity of the information involved. Because of the high degree of the interactions between the assets, any corruption of the information can have far reaching consequences. § It is merely a convenient unit of specialization for the management of complexity. Given the complexity of the automation assets and their management, this is also true but it is probably not the major reason to consider the asset system as an environment.

3.3 Retirement stage management The activities of life cycle management in the retirement part of the life cycle rely heavily on the use of business rules to make the necessary decisions concerning the disposition of an asset. Although business rules certainly could be used in any stage of the life cycle, they are particularly useful in the retirement stage. There are two aspects to the retirement of an asset. The first is the decision to move the asset from the use stage to the retirement stage. That usually occurs when the asset has reached legacy status or a replacement using newer technology has been made available. The second aspect is the actual retirement of the asset. That is usually relatively gradual and may consist of several steps. As an example, the first step may just limit the use of the asset in new situations to a relatively few situations in which it is still attractive. That may be a case where a new function is being developed that has to tie closely to an existing system that uses the asset. The next step may be to not use it in any new development but still maintain it where it is in active use. Finally, it is eliminated from all active use and eventually completely removed from the repository. Gradual retirement is usually necessary to keep a continuity among the assets and preserve the integrity of the many relationships involved.

3.4 Implications Some major implications of life cycle management follow directly from the discussion in this chapter. § The process implementation methodology must explicitly consider the needs of life cycle management. § Assets must be closely monitored and placed in the proper life cycle stage. That prevents the use of inappropriate assets and keeps the number of active assets to a minimum. § Considerable attention must be given to the definition of appropriate asset and asset class models. Those models will, to a great extent, determine the efficiency of defining and utilizing the appropriate assets. § Configuration and operations management are crucial in the use of an assetbased approach. Without an effective program in each of those areas, the suitability and availability of needed assets will be unreliable. § The retirement of an asset requires that a series of explicit decisions be made. Leaving the retirement stage to chance will result in the use of outdated assets. § Effective life cycle management is needed to control the resources needed for the definition and use of automation assets. Selected bibliography Alonso, F., et al., “Software Engineering and Knowledge Engineering: Toward a Common Life Cycle,” J. Systems and Software, Vol. 33, No. 1, 1996, pp. 65–79.

Aquilino, D., P. Asirelli, and P. Malara, “Supporting Reuse and Configuration: A Port-Based Software Configuration Management Model,” Proc. 3rd Internatl. Workshop Software Configuration Management, Trondheim, Norway, June 1991, pp. 62–67. Atria Software, Inc., “Beyond Version Control: Evaluating Software Configuration Management Systems,” Tech. Report, Natick, MA: Atria Software, Inc., 1994. Bersoff, E. H., and A. M. Davis, “Impacts of Life Cycle Models on Software Configuration Management,” Communications of the ACM, Vol. 34, No. 8, 1991, pp. 104–118.

Cohan, D., and D. Gess, “Integrated Life-Cycle Management,” Proc. 1994 IEEE Internatl. Symp. Electronics and the Environment, San Francisco, May 2–4, 1994, pp. 149–154. Feiler, P. H., “Configuration Management Models in Commercial Environments,” Tech. Report CMU/SEI-91-TR-7, Pittsburgh, Carnegie-Mellon University, 1991. Kabjian, M., and A. Veroutis, “An Examination of Alternative Software Technologies That Facilitate Life-Cycle Management,” Proc. 1995 IEEE Internatl. Symp. Electronics and the Environment, Orlando, FL, May 1–3, 1995, pp. 62–67. Krane, S. P., and D. Heimbigner, “Towards a Graph Transform Model for Configuration Management Environments,” Proc. Internatl. Workshop Software Version and Configuration Control, Grassau, Germany, Jan. 1988, pp. 438–443. May, E., “Software Configuration Management for Reuse Projects,” Proc. 4th Internatl. Workshop Software Configuration Management, Baltimore, May 1993, pp. 185–187. Ochuodho, S., and A. W. Brown, “A Process-Oriented Version and Configuration Management Model for Communications Software,” Proc. 3rd Internatl. Workshop Software Configuration Management, Trondheim, Norway, June 1991, pp. 109–120. Plaice, J., and W. W. Wadge, “A New Approach to Version Control,” IEEE Trans. Software Engineering, Vol. 19, No. 3, 1993, pp. 268–276. Rosenquest, C. J., “Entity Life Cycle Models and Their Applicability to Information Systems Development Life Cycles: A Framework for Information Systems Design and Implementation,” Computer J., Vol. 25, No. 3, 1982, pp. 307–315. Ross, R. G., and W. I. Michaels, Resource Life Cycle Analysis: A Business Modeling Technique for IS Planning, Boston: Database Research Group, Inc., 1992. Shimozono, K., et al., “User Management in An Educational Computer System: Personal Information Management,” Proc. 12th Internatl. Conference on Information Networking, Koganei, Tokyo, Jan. 21–23, 1998, pp. 627–632.

Chapter 4: Repository utilization The organization of a discussion of the repository must be carefully crafted because of the complexities involved and the need to ensure that the topic is well understood. Because of its critical importance in automation asset management, the structure, components, and capabilities of the repository must be carefully motivated. To that end, the main discussion is organized around a conceptual model of a repository. This chapter introduces the basic model and examines the individual components in some detail. Then a discussion of repository access follows, including a look at the different types of production users and their needs as well as the administration and operational users of the repository.

4.1 Metamodel Before beginning the discussion of the conceptual model and its layers and components, the concept of a metamodel needs to be well understood. In general usage, the prefix meta has several meanings. As usually applied to situations encountered in enterprise automation, the dictionary definitions of meta of interest are: (1) a more highly organized or specialized form of; (2) more comprehensive, transcending. That translates to the following general definition, which is in a form somewhat more suitable for the current discussion.

A metamodel contains additional information about the asset that is not directly associated with its model or structural definition (e.g., where used, interactions with other assets, statistics, age). The diagram in Figure 4.1 illustrates the relationship of an asset, its model, and the metamodel. The asset is approximated by a model that represents the item. Because the metamodel contains information about the asset that is not a part of the asset model itself, it is shown as orthogonal to both the actual asset and its model.

Figure 4.1: Relationships of asset, model, and metamodel. Although the representation in Figure 4.1 indicates the proper relationships, it is awkward to use in practice, especially when we want to build more complex model structures. For that reason, the depiction of the relationship between the asset model and the associated metamodel is changed to that shown in Figure 4.2. In that representation, the asset model specification is included as an element of the metamodel specification. That makes it possible to reference all the information about an asset simply by referring to the metamodel. This representation will be utilized throughout the remainder of the discussions.

Figure 4,2: Simplified model and metamodel relationship. A metamodel is specified in the repository definition because much more information about an asset needs to be available for effective use of the repository other than just the structure of its model. The information can and is used by both repository and user functions. As an example, the repository must keep information concerning the allowable access for any given asset and user. That is metamodel information. The users need information about how and where the assets are employed so changes can be tracked. That also is metamodel information. After the introduction of the repository conceptual model, the relationships of the specified metamodels and the underlying models are illustrated in graphical form as a means of motivating and understanding the use of the structure. In addition, specific examples of various metamodels and their utilization are provided as the discussion proceeds.

4.2 Conceptual model It would be nice to be able to provide a simple text definition of repository. Unfortunately, that is not possible. Any such limited definition would, of necessity, omit important aspects of the repository function. For that reason, the definition of a repository is in the form of a layered conceptual model. Layered models are frequently used to define communication protocols, but they also are useful in the definition of other complex structures. Figure 4.3 is one possible conceptual model of a repository. Although others could be defined, this is the model that is used in this chapter to describe the services, capabilities, and usage requirements of a robust repository.

Figure 4.3: Conceptual model of a repository. As indicated in Figure 4.3, the conceptual model of a repository contains six layers. Layers usually are numbered starting at the bottom, as indicated in the following list. This is also the order in which they are discussed. § Layer 1, the physical storage layer; § Layer 2, the database management system (DBMS) layer; § Layer 3, the asset metamodel layer; § Layer 4, the asset class metamodel layer; § Layer 5, the asset/class relationship metamodel layer; § Layer 6, the user view (metamodel) layer. In addition to those layers, the model defines three ways of accessing the repository according to the type of user involved. Thus, operational users, administrators (configuration management), and service managers (operations management) have specific functions they must perform and the access model specifically recognizes those types. While all users could have been lumped into one general class, it is more convenient for the purposes of discussion to separate them. Access methods and their specific functions are discussed after the individual layers have been considered. Each layer has a specific purpose in the operation of the repository. As is the case with most layered models, it is necessary to traverse the layers from top to bottom when utilizing the repository. Depending on the specific request of the repository, each layer provides a portion of the processing needed to satisfy the request. That can range from one or more layers providing almost a pass-through operation to a condition in which most of the processing is performed by a single layer. In most cases, however, each layer provides some significant value added in handling the request. To perform its intended purpose, each layer must contain both information appropriate to the layer and functions that manipulate and interpret that information. The functions also must enable the interaction of their layer with the adjacent layers. Some of the functions that directly interact with the layer information and that are needed to explicitly service users of the repository are described here.

In general, this discussion does not include functions that realize the internal operation of the repository, either specific to a given layer or used across layers, because they are dependent on the particular design and implementation of the repository. In general, it is not possible to communicate with or access layer-specific information in any understandable form without going through the layers above it. It is the upper layers that understand the communication formats required by the lower layer. This characteristic is not a disadvantage of the repository even though it sometimes is portrayed as such, especially of the DBMS and physical storage layers. That portrayal generally results from a common data storage characteristic of legacy systems, which, in general, store data in such a way that the data cannot be accessed directly but must be obtained through action of the legacy system. That, of course, makes it difficult to migrate away from the legacy system. The difference between legacy systems and the repository in this area is that the repository is designed to be the common data access mechanism for any application level service that needs the information. It does not make application data specific to and integrated with the application, as is the situation with a number of legacy applications. Migrating from one application development philosophy to another should be facilitated by the ability to tailor the access usage models of the repository while keeping the underlying information intact. In addition, the layer interfaces of any selected repository product should be well defined and standard. That allows the capabilities of any layer to be extended by adding appropriate functions and data structures without disturbing those that already exist. With that necessary topic having been addressed, it should be remembered that, at this time, we are not concerned with the actual implementation of any of the layers. At this point in the discussion, the only concern is with the definition of the capabilities and functionality that must be provided in some manner. In addition, if history is any indication, vendors will invent innovative ways to provide the needed capabilities of the repository. It would be counterproductive to constrain possible implementations to any significant extent. However, some global issues need to be considered in a philosophical sense. 4.2.1 Physical storage layer The bottom layer of most layered models refers to a physical realization or representation of the logical structures of the higher layers. In the repository model, this layer contains the physical storage of all repository information as provided by some persistent media (e.g., tapes, compact discs, cartridges). For current purposes, it is not necessary to decide if the medium is centralized or distributed (or even what those terms mean). It also is not necessary to define what type of medium is available for this function. 4.2.2 DBMS layer The DBMS layer provides the ability to organize the storage of the model and metamodel information defined at the higher layers and to ensure the basic integrity of the stored information. That usually is accomplished through the inherent capabilities of a COTS DBMS product. Most available DBMS products include the ability to back up data, to perform multiphase commits, and to detect some types of errors along with appropriate housekeeping functions. For the purposes of layer 2, the DBMS can use any defined data organization method (or combination of methods), including hierarchical, network, relational, and object formats. While one or more DBMS organization formats may be better suited to the basic purpose of the repository than others, that is a separate topic subject to a great deal of emotion and disagreement (e.g., object versus relational formats). The organization method will not be directly visible to most operational users (administrators probably will need to understand the DBMS formats). The fundamental requirement is simply that the DBMS

layer communicates properly with the asset metamodel layer and other higher layers as necessary. Assuming that has been properly defined and implemented, it is not necessary to go into more detail on DBMS organization. Sometimes the functions of layers 1 and 2 are themselves labeled a repository because of their ability to create, store, retrieve, and delete data, the so-called creation/retrieval/update/deletion (CRUD) functions. In that sense, they do form a primitive type of repository. The format of the DBMS organization determines the structure of the models and metamodels of the upper layers. For example, the structure of a relational DBMS consists of tables and the ability to manipulate their rows and columns in some predefined ways. The specific table structure that is defined provides implicit upper-level models, and the user view must also be consistent with the table format and access mechanism (e.g., Structured Query Language, or SQL). That can be restrictive and generally requires a great deal of detailed knowledge on the part of the user concerning the specific products used to implement layers 1 and 2. Maintenance of the model information in the face of rapidly changing needs also can be a significant problem if only layers 1 and 2 exist, because the models do not exist in explicit form. The major purpose of the explicit models and metamodels in the upper layers (layers 3, 4, 5, and 6) of the conceptual model is to facilitate the use of the repository by: § Providing a higher-level modeling capability suited to the needs of the assets; § The ability to hide the details of the specific mechanism used to store the data. From those considerations, it is evident that layers 1 and 2, while certainly necessary for the repository to function correctly, do not by themselves provide the capabilities needed for the integration and management of the assets. That result is reinforced as the discussion proceeds. 4.2.3 Asset metamodel layer The purpose of layer 3, the asset metamodel layer, is to store, update, and retrieve information about a given asset in the context of the model or metamodel. The asset exists in the repository only in the form of the model. Asset metamodel information about a business rule, for example, is discussed in Chapter 5. Adding a new asset to the repository would require the administrator to develop a template for the model/metamodel and define it to the repository. In a robust repository, the definition would take place at the model layer, and the internal repository functions would ensure that the DBMS layer would be updated with the proper structures to allow the new asset information to be accommodated. Changes to the model/metamodel structure for an existing asset would also be performed at the model layer. Administration of the repository is discussed in additional detail later in Section 4.3.3. 4.2.4 Asset class metamodel layer The asset class metamodel layer contains information about the entire class of each asset represented. This fourth layer has a number of purposes, including the following uses for the model information: § It partitions the class of assets into segments designed for the management of complexity. § It allows a set of assets to be selected and manipulated as a group according to some specified criteria. § It provides the mechanism for the definition and utilization of enterprise (class) models. § It provides a basis for reasoning and analysis about the suitability and effects of individual assets in the class. The purpose of the metamodel for asset classes is similar to that of asset metamodels, and the type of information contained in each would be similar, at least in purpose.

Because the asset metamodel information already has been illustrated, it is not necessary to include here an additional depiction for the class metamodel. Although other aspects of this layer could be defined, the ones presented in this discussion should provide an adequate indication as to the purpose and type of services performed by this layer. 4.2.5 Asset/class interaction metamodel layer In many cases, models are defined that require multiple assets to work together to provide the required structure. The definitions of the required interactions are contained in layer 5, the asset/class interaction layer. This layer can provide interaction definitions of entire asset classes or individual assets, as needed. In a sense, this layer provides for the development of E-R diagrams. However, the classical type of E-R diagram is limited in the types of relationships it can easily illustrate. The types of relationships possible in the interaction layer can be complex and exist in more than two dimensions. This layer also enables the important concept of referential integrity. If a change is proposed for an individual asset or an entire asset class, it is necessary to determine what other assets or classes could be affected by the change. The relationships that would enable that determination would be defined by models in this layer. Whether a given change is acceptable would depend on an analysis that examines the proposed change and the specific assets or classes affected. The questions raised in Chapter 2 concerning the complex interactions of the asset management components would be answered through the structures and functions of this layer. For example, the relationship of business rules with the asset finance component would be defined in this layer. Another example of layer use would be the definition of the interaction of scenarios with processes to produce process map traces. In the latter case, the relationship between scenarios and processes depends on the specific representation of the process employed. In addition, the different scenarioprocess relationships have relationships and interactions among themselves! Without the repository, such complex interactions would be difficult to define and utilize. The repository, however, makes it possible to use model complexities to greatly simplify the activities of the user. That ability is the real strength of the repository concept and the main reason that the repository is placed as the central focus of asset management. That possibly counterintuitive effect of having complex models provide for easier usage is further explored in Section 4.2.6. 4.2.6 Usage metamodel layer The usage metamodel contains information that determines how a given user, for a specific use, will perceive and access the data defined and contained in other layers of the repository. For any particular combination of user and use an associated model will be defined in this layer. This model will define the type, form, and sequence of data access for the purpose of creation, retrieving, updating, and deleting. While these socalled CRUD functions are a part of any data storage mechanism, the ability of the repository, and specifically the usage metamodel layer, to tailor the interaction to the needs of the user and use elevates these functions from one of a low level, data oriented view to one that is at the same level and orientation of the user. In performing this service, the usage model is free to incorporate as much or as little of the structures and relationships defined in the models of the other layers and substitute new relationships as desirable. As an example that will illustrate the value that can be added by the upper four layers, assume that a tool has been designed to determine some quality measure of a project. As a part of that measure, the tool needs to identify the manager of the project and the assigned staff members. Their performance, using some predetermined metrics as measured on previous projects, is then incorporated into the quality model. Further assume that any related projects also have to be taken into account.

Figure 4.4 illustrates the situation from a repository perspective. For clarity, the metamodel information has been omitted, but in an actual situation, that information, as previously defined, would be incorporated as part of the definition for the relevant models in each layer. Two types of assets are involved, employees and projects. The class model for employees is the organization chart, and the class model for projects is the set of related projects. The individual models for each of the assets are not shown but can be considered to contain any information needed to determine the quality contribution.

Figure 4.4: Example of a quality tool usage model. The tool usage model is as follows. For any project of interest as selected by the tool, the manager of the project and assigned staff members are provided by the repository as well as the set of associated projects. The only information that needs to be supplied by the tool is the project of interest. The repository tool view determines what information is to be returned. This model is incorporated into level 6 of the repository. The usage model incorporates layer information in the following manner: § The employee model: quality-related characteristics; § The employee class (organization chart) model: type of employee (manager, staff); § The project model: quality-related characteristics; § The project class model: related projects; § The employee/project interaction model: employees assigned to a given project. Note that the DBMS layer and the physical storage layer are not part of the view because they are considered to provide only internal services to the repository and are not visible to the users. Again, the exception to this statement would be for administrative users who may need to view the models of the two lowest layers. A more complex but probably more realistic example is illustrated next. Because of the complexity involved, only the major points are examined. In this example, the user again is a tool. The tool in this case is designed to select, probably with some human intervention, the most appropriate means of implementing a task for a given process. The required repository models for layers 3 through 5 are illustrated in schematic form in Figure 4.5.

Figure 4.5: Example of task selection. Six types § § § § § §

of assets are involved in this example: Process tasks; Business rules; Scenarios; COTS products; Legacy systems; Reusable components.

The class models for each of those assets also are illustrated but not defined in detail. They can range from very formal and structured, as would be the case for business rules, to very loose and ad hoc, as would ordinarily be the case for legacy systems. The relationships between these assets and their classes can be complex. For example, COTS products and legacy systems must be compatible with the reusable component class model structure, but they also can have class models of their own. As in the quality tool example, the usage model considers only those aspects of the lower layer models specifically needed to provide the needed function. This model, again shown in schematic form, is illustrated in Figure 4.6.

Figure 4.6: Example of task selection usage model.

Note that only certain parts of the asset and class models are used and that their relationships are somewhat redefined to meet the needs of the user. Different parts of the models could be used by other user views. Also, although it is difficult to determine by the illustration, the interactions between the models as defined in the asset/class interaction layer are used as part of the determination as to which assets are presented to the tool for consideration. The ordering of the presentation generally is determined by the usage model.

4.3 Access methods Now that all the layers of the conceptual model have been discussed, it is necessary to determine how the information stored in the repository can be accessed. Three access methods are defined for the repository: one production or operational method and two management methods. Although the access methods are not an inherent part of the repository conceptual model, they are important to an understanding of how the repository is used and managed. To that end, each access method is described briefly in the following sections. 4.3.1 Production method The main access method is the production or operational method. This method is the one employed by production users of the repository, which can be humans, intelligent agents, operational programs, automated tools, or other similar assets that need to utilize repository information in performing their defined functions. The main requirement of the production users is to obtain and utilize the information contained in the repository in the most optimum form for the specific function intended. In addition to classifying production users according to their implementation types, these users also can be classified according to their functions within the enterprise. Some specific production user functions are as follows: § Support of an externally focused enterprise process. This type of process is oriented toward serving a customer need such as order entry or customer service. § Direct support of an internally focused enterprise process. This type of process is oriented toward providing an enabling service such as preventative maintenance or purchasing. § Support of enterprise functions not usually considered to be process driven. These functions include research and development or the establishment of a corporate vision and strategy. § Support of the other components of the asset management system. Repository requirements are specified in the individual discussions of these components. In any of those cases, access is obtained through a usage metamodel defined for the specific production user and one or more of its associated information requirements. Of course, if appropriate, more than one production user can employ the same usage metamodel. In that case, the metamodel information could indicate the priority or other resolution to simultaneous requested updates for the same information. That is always a problem that requires some amount of attention to ensure data integrity. Usually one global solution is implemented for that difficulty, which sometimes can present a problem when there are a large number of types of different users and functions. For the repository model discussed in this chapter, the usage metamodel structure accommodates different update resolution strategies and allows any conflict resolution to reflect the individual needs of the users and their functions. It also should be indicated that production users do not necessarily have to be members of the enterprise that owns and maintains the repository and its contained information. They could be employees of other enterprises that need access to repository data to

provide a service to or receive a service from the enterprise. That type of use certainly would require appropriate security data. However, this type of use could be of significant advantage to both the enterprise and its vendors and customers. 4.3.2 Life cycle management All the considerations presented in the life cycle management discussion in Chapter 3 apply to the automation assets, including the repository itself. Two components of the life cycle, configuration management (administration) and operations management, are discussed briefly in the specific context of the repository. 4.3.3 Configuration management (administration) The content management access method is used by the administrators of the repository to create, update, and delete models but not the individual information about the assets that conform to those models. The creation, retrieval, updating, and deletion of specific asset information is performed by the production access method, discussed in Section 4.3.1. Can new models be created by production users? That is always a key question asked to indicate the flexibility of the repository. The answer to the question must be yes, but with an important caveat. When the production user is performing a model-changing function, it must be through the content management access method. The consistency is required to help ensure that changes are always performed in the same way, using the same repository features regardless of the user class performing them. Although production users should have the ability to perform content management functions, the use of that ability should be carefully controlled. If that is not done, the repository easily can become cluttered with outdated information and require more resources than otherwise would be necessary. In addition, administration of the repository is a skill that needs experience and training to obtain an effective and efficient repository function. The key to successful repository administration is the ability to define the models in terms of the layer that contains the model. For example, if a new asset model is being added to the repository, the model should be able to be defined directly by its structure and attributes. The repository, through an internal function, should then be able to convert that definition into the structures needed by the underlying DBMS storage mechanism. This type of automated functionality allows the administrator to concentrate on the proper definition of the model and not to have to spend a lot of time and energy converting the model to possibly hostile storage constructs. From a practical point of view, however, it is also recognized that this access method may also need access to the DBMS layer to allow the administrator to tune the response time or storage parameters. The goal is to minimize this low-level intervention. 4.3.4 Operations management Because the repository provides a service designed to be employed by multiple users, its operational status is of critical importance. Adequate response time, throughput, error detection and recovery, and so on, must be provided. That requires that the status of the repository be continuously monitored and corrective action taken as required. In addition, security in the form of access restrictions, user verification, and information integrity must be provided. All those activities are performed by means of the operations management access method that utilizes and interacts with an appropriate set of internal functions. In many cases, the major user of the operations management access method is a management application of some sort. That is especially true when the entire suite of applications and support functions, the servers on which they are implemented, and the network that interconnects them are being managed as a unified asset. When the management program detects a problem that could be related to the repository, it may attempt to implement a prepackaged solution or notify a human that a condition exists

that needs investigation. In the latter case, the human then becomes the user of the access method. The information obtained or utilized by the operations management activity should also be modeled and stored in the repository so it can be treated the same as any other repository information. Operations information is not only useful in performing the realtime operations activities, it is also needed for a variety of other purposes such as capacity planning and quality determinations. Because operations management is an important component of asset management, it applies to many assets other than the repository itself. However, as is the case with all the components, the fundamental principles are the same regardless of the asset or assets they are being applied to.

4.4 Implications The major implications of a repository are the need to keep the information current and available and to ensure that its use is not being circumvented. If either of those is not performed adequately, the effectiveness of the entire corporation is compromised because of the central place of the repository in the management of corporate automation assets. Adequate resources must be provided and appropriate processes defined and implemented that can assure users that the repository contains the latest versions of all needed information. Any attempt to circumvent the use of the repository because of efficiency or other arguments should be stopped quickly. If use of the repository is considered an impediment, the reasons need to be investigated and any indicated changes rapidly made. If the information in the repository is robust and current, that should not be a significant problem. As a startup need, to provide the required set of information, some pressure may have to be exerted on the responsible organizations. There is always a tendency to produce local optimizations rather than the global optimization needed by the enterprise as a whole. It is only the repository that can eventually facilitate and support that global optimization. Selected bibliography Davenport, T. H., and L. Prusak, Working Knowledge: How Organizations Manage What They Know, Cambridge: Harvard Business School Press, 1998. Henninger, S., “An Evolutionary Approach to Constructing Effective Software Reuse Repositories,” ACM Trans. Software Engineering and Methodology, Vol. 6, No. 2, 1997, pp. 111–140. Henrich, A., “Document Retrieval Facilities for Repository-Based System Development,” Proc. 19th Ann. Internatl. ACM SIGIR Conf. Research and Development in Information Retrieval, Aug. 18–22, 1966, pp. 101–109. John, H., and G. Spiros-Theodoros, “Reuse Concepts and a Reuse Support Repository,” Proc. IEEE Symp. and Workshop Engineering of Computer-Based Systems, Friedrichshafen, Germany, March 11–15, 1996, pp. 27–34. Petro, J., et al., “Model-Based Reuse Repositories—Concepts and Experience,” Proc. 7th Internatl. Workshop Computer-Aided Software Engineering, Toronto, July 10–14, 1995, pp. 60–69. Taeheun, L., and C. Wu, “A Simple Configuration Management System for a CASE Repository,” Proc. 1995 Asia Pacific Software Engineering Conf., Dec. 6–9, 1995, pp. 439– 446.

Traynor, O., and A. Bloesch, “The Cogito Repository Manager,” Proc. First Asia-Pacific Software Engineering Conf., Tokyo, Dec. 7–9, 1994, pp. 356–365.

Chapter 5: Business rules Overview The term business rule is yet another example of a term that is in common usage but for which no agreed-on context or definition exists. The term is applied in a number of different ways in a wide variety of situations, which makes it almost impossible to understand how the term is being used without a detailed knowledge of the context of the discussion. While this chapter cannot solve that problem, it can provide an overall self-consistent framework through which an examination of the concept can be structured. It will also facilitate specification of the interface and interaction of the business rule concept to other concepts needed in the development of a methodology for process implementation. References to the term business rules in later chapters are assumed to conform to the model defined in this chapter. Before delving into the details of business rules and the development of an appropriate model, it is necessary to determine the general context in which this discussion will occur. The easiest way to accomplish that is to ask and answer four questions: § Why are enterprises interested in the concept of business rules? § What is the general context for the existence of business rules? § What is meant by the term business rule and what does one look like? § How are business rules utilized in the enterprise? Once those questions are answered (at least for the purpose of this presentation), the remainder of the discussion centers on the structure and utilization of business rules. The structure emphasis will be on the asset class model because, as will be shown, the asset model must be very general to accommodate the many possible variations of business rule forms.

5.1 Enterprise interest The interest in business rules results from some promises that, rightly or wrongly, have been associated with such rules. Those promises have been that business rules will: § Enable nontechnical personnel to define the operating principles (e.g., control, algorithms, policies, procedures) utilized in business automation functionality (applications); § Enable the operating principles to be changed quickly without the need for programming or reprogramming applications; § Enable the analysis of the operating principles from a global perspective to determine if they are complete, consistent, and nonconflicting; § Ensure that different applications utilize the same operating principles as needed for the functionality involved; § Ensure that the operating principles are in conformity with the desired way for the enterprise to operate. It has always been difficult to translate business needs into software that can aid in accomplishing the intended function. Historically, a solution to that difficulty has been approached in two entirely different ways: one based on job function and the other based on language. The first approach was to define an organization position specifically intended to provide the translation from business needs to software requirements and specifications, the traditional system analyst position. The individual filling that role was supposed to be proficient in both business functions and software development technology. Unfortunately, most people filling the role were more technically proficient than business oriented, and the translation problem continued to be difficult. Instead of using one person, the system analyst, to provide the translation, most current

requirement generation efforts employ a team approach. That tack works better, but the problems remain. The second approach was the specification of languages, such as Fortran and Cobol, that were intended to be directly used by the individuals needing the software without the need for technical professionals to produce the requirements and eventual implementation of the software. This effort continues to the present and includes fourthgeneration languages and graphical or visual languages, such as Visual Basic. Although this approach is attractive in concept, the realization that “programming is programming” eventually sets in. Although languages may change, the act of programming always requires specialized knowledge if the problem to be solved requires a moderately complex solution. Eventually, software engineers take over the development function. The latest effort in trying to eliminate the business-to-technical translation problem is through the concept of business rules. The idea is to have the business people specify in some manner the basic principles by which they want to operate the business. The principles, or rules, would then be automatically translated into software or operational parameters. The development of business rules would have other advantages to the enterprise. As the business changed, the underlying rules could be changed, in turn changing the supporting software. In addition, the rules would expedite reasoning and analysis about the business and its intended operation. It would make explicit many policies and procedures that were known only implicitly. The business rule approach is a variation on the language-oriented approach and ultimately will have the same problems as all the previous attempts using that approach. In addition, unfortunately, the concept, while clear in purpose, also suffers from many additional problems. The remainder of this discussion is an overview of business rules. It includes the identification of inherent problems and presents approaches to realizing some of the promises of the concept.

5.2 General context To provide a framework for this discussion, an entity called a statement is defined. A statement does not have to be in English (or any other natural language) text. It could be a mathematical expression, a picture, a chart, a diagram, or any other recognizable form of expression. However, for simplicity of presentation, the examples used here are in the form of text sentences. Statements, of whatever form, are used as the vehicle for determining the context and the scope of business rules in the enterprise. A statement can be considered to be an articulated view of some aspect of a business from the enterprise perspective. Among other possibilities: § The view can provide a concise representation of a large complex area of the business. (Example: The manufacturing operation has had no time-off injuries in the last year.) § The view can explicitly articulate an otherwise ill-defined concept. (Example: This company will be the sales leader in its industry in 5 years.) § The view can aggregate a large number of individual items. (Example: Most employees own stock in the corporation.) § The view can examine one component of a larger item. (Example: Joe Smith and Jane Jones have received the yearly achievement award.) § The view can quantify items that are otherwise expressed only on a qualitative basis. (Example: The good health of our employees is responsible for a $100,000 increase in profits last year.) § The view can indicate desired business behavior. (Example: Selling new services should be performed by all employees as the opportunity presents itself.) Enterprises make statements (indicate views) about themselves for many purposes: visions, strategies, goals, milestones, policies, procedures, and so on. The statements are intended to meet a variety of purposes in the enterprise. Statements can be used for planning, for internal and external communications, as status indicators, and to specify

and promulgate guiding principles. Although they are only a small fraction of all the information available about an enterprise, statements are, nevertheless, important in understanding how the enterprise views itself and intends to behave. It also should be evident from this discussion that enterprises are complex organisms and do not just consist of bundles of statements, as some of the literature would lead you to believe.

5.3 Definition Beyond the definition of a statement as an articulated “internal” view of some aspect of the enterprise, statements have few, if any, restrictions. They can be written or oral, formal or informal, widely known or restricted, possible or impossible, true or not true, passive or active, or any condition in between. There is one class of statements, however, that can be further defined and is of considerable interest. This is the class of statements that will be loosely defined as rule statements. Rule statements, or business rules as they are commonly called, are defined as follows: “Business rules are statements that articulate an operating principle by defining or constraining some aspect of the business.” If a statement can be found to have that property, it is a business rule (or rule, for short). Rules do not merely reflect what has already occurred or predict a status at some future time. They indicate some operational aspect of the enterprise. Current popular uses of rules are oriented toward the specification of low-level constraints on software and data such as trigger conditions and E-R cardinality. The pressing need is to develop a comprehensive approach to rules, including the delineation of policy and procedures. Business rules can be used to define the operation of the enterprise at all levels. The simple definition of a rule as a constraining statement does not provide enough structure for determining what constitutes an effective rule and how it should be utilized. Further analysis is required to provide sufficient information for the practical exploitation of rules. Making rule statements without some expectation that they will be effective in some aspect of running the enterprise is not a particularly useful exercise. From a terminology viewpoint, any statement intended to be a rule (e.g., a rule that intends to impose a constraint) is considered to be a rule. However, a distinction must be made between a well-formed rule that can provide a benefit to the enterprise and a rule that is not well formed and cannot serve a useful function. To provide a means of identifying a well-formed rule, a number of characteristics for such a rule have been determined to be required. If a statement conforms to those characteristics, it is well formed. If it fails to meet any one of them, it is not considered to be well formed. The major characteristics of a well-formed rule are listed here, and each is then examined, along with examples that motivate the need for the characteristic in the specification of a well-formed rule. First, a well-formed rule must have the following characteristics: § It must be able to be followed. § It must be consistent. § It must be able to be articulated. § It must be able to have its compliance measured. § It must have constraints. Note that the concept of well formed is not based on the agreement with a specified syntax. It is based only on the potential to serve a purpose in the enterprise. The issue of agreeing or disagreeing with a specified syntax is an implementation problem and is not of immediate concern in this discussion. § A well-formed rule must be able to be followed. If a rule statement can never be realized, it cannot be considered as a well-formed rule even though at first glance it appears to be one. If a proposed rule states that “passengers

§A

§A

§A

§A

on flights between St. Louis and Chicago will not be served meals” and the airline has no flights between St. Louis and Chicago, the rule is not well formed. It has no potential to be of use in the enterprise. Those types of rule problems usually result from rules not being kept current. This subject is discussed in more detail later. Another example is a proposed rule that “any new product developed will not become obsolete for 4 years.” Unless it is a monopoly, an enterprise usually cannot control the length of time a product remains viable. That is determined by the competition and customers. The enterprise cannot apply that statement; therefore, it is not a well-formed rule. well-formed rule must be consistent in its application. Each time a rule is applied under the same circumstances, the same result should occur. Violations of this characteristic usually occur when a statement is not specific enough and other factors cause changes in the outcome of applying the statement. For example, consider the proposed requirement rule that “employees will be given their birthday off in addition to normal time not worked.” If an employee’s birthday does not fall on a normal workday, that is not possible. Some other day (unspecified) must be taken off, or perhaps the employee will not get an additional day off, also violating the rule. Applying the proposed rule to different employees and in different years will produce different results. The statement is not a well-formed rule but could be changed into one by incorporating additional constraints or changing its strength class. well-formed rule must be able to be articulated. A well-formed rule must contain enough explicit detail so it can be understood and applied. It may be written or unwritten, but a general “feeling” or “understanding” is not enough. For example, the proposed guideline rule that “all employees should be happy in their work” does not contain enough detail for one to be able to understand what “being happy” means and, therefore, how to apply it. Although variations of that statement are issued periodically by many organizations with good intentions, they are devoid of useful content from the perspective of a rule and cannot even be considered general guidelines! well-formed rule must be able to have its compliance measured. If a proposed school rule is that “no student will watch over 2 hours of TV a day” and there is no device to monitor TV watching (including willing parents), this is not a rule. Its application cannot be measured. It could be an excellent statement of intention and one worthy of making. It just cannot be considered a well-formed rule. well-formed rule must have constraints. The proposed rule that “this enterprise will do anything it takes to become a leader in its industry” is not a well-formed rule. There are no constraints (directions) on what actions the enterprise is willing to take. There may be nothing wrong with the statement from a motivational point of view, but it is not a well-formed rule.

If a proposed rule fails one of the defining characteristic checks, in many cases it can be rewritten so that it does retain the necessary characteristics. That usually involves one or more of the following: (1) changing the strength class, (2) adding additional constraints, (3) rewriting the rule to obtain agreement with the characteristics. For simplicity in the following discussion, it is assumed that the term rule means a wellformed rule, and rules that are not well formed have been eliminated or changed to become well formed. When a statement is considered to be a rule, the strength of the rule must be determined. The strength of a rule is the rigor with which the rule needs to be followed. In that regard, the following additional questions are of interest. Is a rule something that must always be followed? Are exceptions to rules allowed? Under what conditions? Is it a rule or only a suggestion? Depending on the answers to those questions, rules can be classified into three strength classes:

§ Requirements. A requirement specifies that a condition must be followed with no exceptions. § Standards. A standard specifies a condition that should be followed, but a few exceptions are allowed under controlled circumstances. The conditions that caused the need for the exceptions must be explicitly identified. § Guidelines. A guideline specifies a suggested course that generally should be followed, but other approaches may be used as necessary or desirable. The reasons for not following the guideline should be identified. No matter what strength class a rule is in, to be a well-formed rule, it must conform to the characteristics outlined above. If it does not, it is not a rule that can provide the enterprise with an associated benefit. Before concluding the definition of a rule, an additional aspect of the definition must be considered. Although most of the discussion so far has been on the definition of rules within an enterprise, that usage should be made explicitly to distinguish that use from the use of rules in other venues. Therefore, the following definition is made: A business rule is a rule applied to some aspect of a business enterprise. That is enough to distinguish business rules from personal rules, religious rules, and society rules (all of which can have the same general rule characteristics defined for business rule). It should be evident that the significant difficulty in defining business rules lies not with the word business but with the term rule.

5.4 Utilization The main interest in business rules and the original purpose for defining the concept is the hope that these types of statements can be defined by individuals experienced in the needs of the business and then directly used in the operation of the enterprise without having to be interpreted by some information management organization. It is thought that such direct specification would reduce the possibility of error and misinterpretation while providing faster implementations and changes. However, it must be indicated that rule specification is difficult. § Individual rules need to be potentially useful (i.e., well formed). § Rule sets should be complete, consistent, and nonconflicting (i.e., form an ideal class). § Rules need to be in conformity with the way in which the various stakeholders want the business to function. § Rule capture from legacy systems may yield rules that are not well formed, that are not consistent, or that are not in agreement with the enterprise philosophy because the entire context of the system is not available. § Proposed new rules need to be motivated and understood in the context of the rules already in place. The definition of business rules in Section 5.3 does not constrain their application to any specific aspect of an enterprise or level of detail. As long as the defining characteristics have been met, the statement is a rule. To utilize business rules as an integral part of business operation, some attention needs to be given to those other considerations. Rules that deal with different aspects of the enterprise or are specified at different detail levels may need to be handled in distinct ways. In addition, enough information concerning each rule must be available to allow it to be individually identified and its function and utilization understood. Although the following discussion provides one possible method of specifying, categorizing, and utilizing business rules, undoubtedly there are many others. As long as the basic definitions are followed and the defined structure proves useful to the enterprise for which it is developed, many analysis and synthesis methods can be successfully employed.

5.5 Metamodel structure The business rule metamodel attributes that are utilized as the basis for further discussion are: § Creation date; § Name; § Description; § Purpose; § Source; § Owner; § Category; § Scope; § Detail level; § Strength; § Priority; § Persistence; § Format; § Implementation method; § Compliance monitor; § Domain specific. Other metamodels certainly are possible, but the one utilized here will effectively serve as a vehicle for discovering the opportunities and problems associated with the use of business rules as an integral part of business operation. That structure, along with some refinements discussed later, can be considered as the core of a comprehensive business rule metamodel. 5.5.1 Rule identification The first four attributes of the metamodel structure, creation date, name, description, and purpose, provide a unique identifier for the rule. The meaning and values for each attribute are generally self-explanatory. A separate ID attribute is not specified in this structure but, depending on need, could certainly be added. Using only the values of the four identifier attributes, it should be possible to define a rule with sufficient detail to distinguish it from all other rules. Although additional information is provided by the values of the other attributes, they should not be needed for the identification of a unique rule. The remaining attributes and values can, of course, be used to search for rules with specific characteristics. 5.5.2 Rule advocacy The attributes of source and owner provide an indication as to the original and continuing advocates for keeping the rule. All rules must have a business reason for their creation and continued existence. As part of the life cycle process, that reason must be examined periodically and verified as to its continued validity. As a result of their direct involvement with the rule, the creator and the owner are the primary advocates and must be consulted if any alteration in the rule status is contemplated. The source of the rule and the ownership of the rule must be from a business perspective. The source and the current owner can be the same or they can differ, and the owner can change periodically for many business reasons. The rule administrator is not necessarily the owner, and the administration function is usually considered from a technical perspective. If the source or the owner for a rule is not specified and cannot be easily identified, that rule should be considered a candidate for elimination. All these conditions should be specified as part of the rule life cycle activities.

5.5.3 Rule classification taxonomy In a very real sense, any classification scheme is somewhat arbitrary, even though some means of classification is usually considered necessary to reflect the utilization and implementation of the rule within the enterprise. There is also another major reason for the classification of rules. In any reasonably sized enterprise, there likely are thousands of business rules. The intricacies of effectively creating, maintaining, using, reusing, and discarding the rules require some classification scheme regardless of the configuration management approach used. The purpose of the classification scheme is to reduce the number of rules that would need to be considered at any one time. Many investigators have advanced and defended specific rule taxonomies, resulting in considerable debate and conflict. Most of the taxonomies are specific to the area and emphasis being advanced by the investigator and are usually defined to efficiently accommodate the needs of the proposed approach. Because the set of rules for an enterprise exists independently of any taxonomy, it is possible to define and utilize multiple taxonomies. Each taxonomy could be optimized to serve a specific purpose, such as configuration management or conflict analysis. One taxonomy could be business oriented, while another could be implementation oriented. Specification of a rule taxonomy as a separate degree of freedom governed by needs of the business and independent of the other defining rule characteristics would accomplish the following: § Eliminate the unnecessary conflict over the definition of the ultimate rule taxonomy; § Allow different user groups to optimize their access to and use of the rules. The price that must be paid for that flexibility is, of course, the additional time and effort to place each rule (either automatically or manually) into its proper place in every taxonomy utilized. In addition, as has been previously stated, a robust repository is also necessary for the simultaneous definition of multiple taxonomies. For illustration purposes in this section, some specific taxonomy is necessary. A relatively robust taxonomy that interacts efficiently with the process implementation methodology discussed later is defined and utilized. It is defined in business-oriented terms and is matrix oriented. Although it effectively provides a comprehensive example of the information needed in a taxonomy, it is not intended that this classification scheme be considered as the only appropriate one. Many schemes are possible and may simultaneously coexist with each other and the one presented here. Three structure attributes, category, scope, and detail level, are used in this taxonomy. They provide the basis on which to classify the rule into a suitable category. Figure 5.1 indicates one method of specifying values for the category and scope attributes using a matrix structure. The rows of the matrix represent the specific aspect of the enterprise that the rule addresses. Although the rows may not provide a complete taxonomy, the author has yet to find a case where a proposed rule could not be reasonably placed into one of the rows.

Figure 5.1: Example of business rule taxonomy. The columns of the matrix represent the scope or sphere of influence within the enterprise. Each of the columns and rows can be further decomposed into smaller units as necessary for the understanding of a particular rule. For example, the organization unit row can be divided into the individual organizations of the enterprise. The degree of decomposition determines the detail level of the rule. Although not indicated in the figure, each matrix cell should be decomposed in both category and scope for as many levels as rules are reasonably expected to be defined. Because the amount of detail that can be produced in that manner is quite large, this process will not be explicitly performed in this presentation. 5.5.4 Rule operation The last seven attributes of the rule structure provide the operational conditions for the realization of the rule. Those conditions are specified by the strength, priority, persistence, format, implementation method, compliance monitor, and domain-specific attributes. A brief discussion of each of those attributes follows. The strength attribute was discussed in some detail in Section 5.3, so it is not considered further at this time. The interactions of that attribute with other operational attributes are examined later as necessary. The priority attribute is utilized when there is a rule conflict. Although in theory there should never be a rule conflict with rules covering the same area, in practice that is difficult to control because there usually are a large number of rules with many different originators and owners. The priority attribute indicates the desired outcome in a conflict situation. The simplest priority scheme is probably the values “required,” “where possible,” and “guideline.” Although better than nothing, that priority scheme generally is ineffective in resolving conflicts since the chance of conflicting rules having the same priority is relatively large. That is where reasoning and analysis over a given rule set become necessary. As with any type of attributes, care must be taken to ensure that all rules are not simply given the highest value possible by their originators. That requires good administration and configuration management functions. The persistence attribute indicates the period during which the rule will be effective. There are many possible values for the persistence attribute: § From creation until explicitly deleted. Example: “From now on, all employees will enter the building through the south entrance only.” § From creation until a specific occurrence, date, or time. Example: “Until the renovations are complete, all employees will enter the building through the south entrance only.” § For a certain period. Example: “For a 2-week period starting this Friday, all employees will enter the building through the south entrance only.”

§

During periods indicated by the state of a defined entity. Example: “When the red light is on, all employees will enter the building through the south entrance only.”

In the examples, for better understanding, the period during which the rule is effective is included in the rule statement. That, of course, does not have to be the case. A rule can be stated without any indication as to its period of applicability. In that case, a specific indication as to the effectiveness period must be included as the value of the attribute. If it is unknown, that condition also should be stated. The format attribute provides the style of the business rule. Styles could include: § A rule language; § Structured English (or other natural language) text; § A mathematical expression; § Freeform text; § A table or matrix (including the case of one cell); § Procedural code; § A combination of any of the above. All those styles are useful in expressing business rules. Which form is the most appropriate in a given situation depends on the level and the purpose of the rule and the manner in which it will be used. A single style is not sufficient to represent all the different types of rules that are needed in the enterprise. Because of the desirability to compare and reason about rules of differing styles, some means of translating to a common formalism is desirable. That need is discussed further in Section 5.8, which considers the use of a repository. Each of the styles can provide for parameters whose values can be changed without changing the rule statement itself. In many cases, that parameterization can facilitate rule creation and management. Currently, no standards are available for business rules, and that lack, unfortunately, extends to the definitions of style. Almost anything can be used, as determined by the creator of the rule. The enterprise needs—and should set—some internal standards in this area to be in a better position to effectively manage business rule usage. In many cases, the creator of the rule uses a style that must be converted into one or more other styles before it can be used. Products that can accommodate business rule inputs generally require their own specific style (remember the lack of standards). The use of many different products, each with individual style requirements, can create a difficult problem. Errors can easily be made in translating rules from one style into another. The need for many target styles complicates the testing and identification of error conditions in the application as a whole. With that said, it still is probably better to set a single standard for the creation of business rules and then translate them into the various formats needed rather than create them with different formats. In that way, all the rules have at least the same standard style(s), which facilitates their comparison and reuse. Rule styles other than those listed could also be defined, depending on the particular needs of an enterprise. The more structured the format and the more it is parameterized, the easier it is to automatically utilize the rule in the operation of the enterprise. The implementation method attribute indicates the method(s) by which the rule will be accommodated. This attribute is key to the successful utilization of business rules because it provides for an explicit relationship between the rule statement and the means for realizing it. By examining the proposed linkage, it can be determined if the proposal will provide the most effective method of rule realization and, if not, what the method should become. In many contemporary instances, rules are stated without any indication as to how the rule will be incorporated into the business. Without that explicit linkage, the use of business rules as an integral part of enterprise operation will fail. The major utilization methods include the following:

1.

Specifically including or considering a rule in the development of manual procedures and practices; 2. Considering a rule as the requirements for a software development are being developed; 3. Specifically including a rule in the requirements for a software development; 4. Manually considering or incorporating a rule as part of an application design activity; 5. Entering a rule into a product and interpreting it at compile time; 6. Accessing a rule from a library and interpreting it at compile time; 7. Entering a rule into a product and interpreting it at run time; 8. Accessing a rule from a library and interpreting it at run time. Each implementation method is illustrated as part of an overall rules system, as defined in Section 5.8. In general, the methods become more automatic and less error prone as listed from top to bottom. Depending on the strength of a rule, one implementation method may be more appropriate than the others. For a required rule, the desired method would be the eighth one in the list, directly accessing the rule and utilizing it at run time. If changes are needed, they could be made and the altered rule bound at the desired time. For a guideline rule, methods 1, 2, and 4 are probably most appropriate; the rule does not have to be followed exactly, although some type of fuzzy logic could be used to determine which rule would be utilized. The value of the compliance monitor attribute, which is closely associated with the rule implementation method, explicitly defines how the rule realization is examined to determine if it produces its defined constraints. A good way to start is to associate one or more compliance monitor techniques with each implementation method. Others can be defined if needed. The numbers in the following list correspond with the numbers in the implementation methods list. 1.

Use a design review of draft materials to determine if and to what extent applicable business rules are reflected in the document text.

2,3,4.

Use a design review of requireme nts to determine if and to what extent applicable business rules are

contained in the requireme nts specificati on. Perform complianc e audit of finished software to determine if the software accurately reflects the requireme nts, including those requireme nts associate d with business rules. Test finished system to determine if applicable business rules are being accurately reflected. 5,6.

Test product with suitable environme nt conditions designed to determine if product reacts properly to incorporat ed business rules. Test product integrated with the entire

applicatio n to determine if business rules are being interprete d properly. 7,8.

Test product with suitable environme nt conditions designed to determine if product reacts properly to incorporat ed business rules. Test product integrated with the entire applicatio n to determine if business rules are being interprete d properly. Change business rule parameter value or structure and retest to determine if change is being implement ed correctly.

The domain-specific attribute, the final one in the metamodel, consists of any domain requirements that may arise from regulatory bodies, required standards, or similar sources. Requirements must be considered when the applicable domain is involved. For

example, assume this rule: “Insert the maximum number of ads into the bill envelope without increasing the amount of postage due.” The domain-specific value for that rule could be a reference to the regulation that the post office uses to calculate the amount of postage to be paid. 5.5.5 Examples Two examples of business rules with differing characteristics are shown in Tables 5.1 and 5.2. The rules are designed to illustrate the wide variety of rules that can be accommodated using the metamodel defined at the beginning of this section. Readers are invited to take any business rules with which they are familiar and (1) ensure that it is a well-formed business rule by determining if it has the required characteristics and (2) determine the specific characteristics of the rule by determining values for all the metamodel structure attributes. Table 5.1: Emergency Response Rule Metamodel Creation date:

1/1/95

Name:

Emergency Response Rule

Description:

In the event of an emergency that requires a field response by employees, at least two employees will be dispatched to the trouble location.

Purpose:

The purpose of this rule is to help provide safe working conditions under emergency conditions.

Source:

Safety Department

Owner:

Vice President of Administration

Category:

Operations: function

Scope:

Process

Detail level:

Dispatch function/trouble resolution process

Strength:

Requirement

Priority:

High

Persistence:

Immediately, until rescinded

Format:

Text only

Implementation method:

Included in all software requirements dealing with dispatch functionality

Compliance monitor:

Design review

Domain specific:

None

Table 5.2: Sales Tax Calculation Rule Metamodel Creation date:

6/1/95

Name:

Sales Tax Calculation Rule

Description:

This rule requires that the sales tax be calculated using this formula: ST = (Price * Tax rate) rounded up to next cent if not already at a whole cent.

Purpose:

The purpose of this rule is to provide the rule for calculating the sales tax on products.

Source:

Tax Department

Owner:

Chief Accounting Officer

Category:

Operations: function

Scope:

Transaction

Detail level:

Tax calculation function, tax calculation transaction

Strength:

Requirement

Priority:

High

Persistence:

Immediately, until rescinded

Format:

Mathematical equation

Implementation method:

Business rule library that is accessed by software at run time

Compliance monitor:

Module test and application integration test

Domain specific:

Tax code reference: Sect. 10.556.9 State Code

5.6 Rules versus requirements Although the modeling, implementation, and use of process business rules are not covered until later in this book, one area of potential confusion needs to be addressed early: the relationship between process business rules and the requirements for software products that support a process. In general, the software requirements must be consistent with applicable process business rules (and other types of business rules, for that matter) but they do not necessarily have to contain the rule itself, nor do they have to be rules themselves. In fact, they should, in general, not be business rules. Business rules are oriented toward understanding and defining the operation of the business, while requirements are oriented toward defining the operation of a software product. If a process business rule states that “all preventative maintenance will be performed between midnight and 7:00 A.M. except for weekends, when it can be done anytime,” then a software scheduler that supports the maintenance process could have a requirement that “a means must exist through a GUI interface to specify the time period, based on days of the week during which work can be scheduled.” That example of a requirement is a product requirement or rule that supports the business rule. It clearly is not a business rule in the sense we have been assuming and using business rules. The author refuses to be drawn into a philosophical discussion concerning the definition of a product requirement as a special type of business rule. It is not necessary, or probably even feasible, to provide a definitive answer to that question. In the development of software product requirements, additional business rules may be identified. If a prospective requirement further defines the process that the software will support, it can also be considered a business rule and may or may not be kept as a requirement. As an example, assume a casual customer billing business rule has been specified. A software product that will be used to monitor customer account status could be given a requirement that “if a customer is delinquent in any payment for the last year, that customer will be billed every month instead of every other month.” In that case, the requirement is clearly process related even though it initially was defined as a software product requirement. With that understanding, the requirement should also be considered as a business rule and the needed product requirement reconsidered. In the example, the product requirement could (and probably should) be restated to the following: “The product will be capable of generating a bill at intervals determined by customer status.”

Whether a candidate software requirement is process related must be determined from the individual circumstances. If it is determined to be such, a recast of the requirement and an addition to the business rule set probably is appropriate.

5.7 Rule engine As an aid in the configuration management of business rules and to make the incorporation of business rules into the enterprise more effective, the concept of a rule engine has been advanced. Although not well defined, the implicit purpose of the rule engine is to provide an efficient mechanism for rule administration and use. The functionality of a rule engine can range anywhere between the following two extremes depicted: § The functionality is that of a passive library that is used only to contain rule definitions. The library usually has functions that allow rules to be created, deleted, copied, and manually browsed, but there is little additional functionality. Although better than nothing, this type of rule engine is minimally useful. It is not possible to use this type of engine with implementation methods 5, 6, 7, and 8, as defined in the list in Section 5.5.4. That severely limits the effective use of rules in the operation of the business. § The functionality is that of a full-function repository utilizing an explicit robust rule metamodel. This engine would allow the full range of implementation methods as well as provide for the efficient reuse of rules. Configuration management functions would be enhanced through automatic discovery of rule conflicts, overlaps, and possibly gaps. To achieve the second type of rule engine, a large number of problems must be addressed and solved. Further discussion of what is needed to accomplish the realization of this engine is beyond the scope of this chapter. The main purpose of including the concept of a rule engine is to alert readers that they should be cautious in assuming a specific meaning when they encounter the term. Some types of rule engines being offered are modified inference engines, database constraint checkers, and workflow engines. Those are all legitimate implementations, but each has a relatively narrow focus. Examples of uses of these types of engines are given in Section 5.8.

5.8 Rule system An illustration of the architecture for a complete business rule system as utilized in the implementation of a process is presented in Figure 5.2; the discussion given in this section is based on the diagram in the figure. In addition to the end user, five different human-oriented roles are shown: administrator, owner or agent, analyst, software developer, and data modeler. Those roles could be performed by five different staff members, or they could be combined as warranted. In addition, some parts of the roles may be automated through the use of expert systems or similar approaches. For the purpose of this discussion, however, it is assumed that the roles are performed by individual staff members. Because Figure 5.2 is designed to show a systems approach to the operational environment for business rules, it must incorporate many interrelated functions and entities necessary to the implementation of a process. If the reader is unfamiliar with some of them, the terms and functions presented in the figure are discussed in other areas of the book.

Figure 5.2: Rule system architecture. The administrator assigns the proper characteristics, such as a specific implementation type, and places it in the repository. If new functionality is needed to accommodate the implementation type, it must be acquired and provisioned by the enterprise organizations responsible for that type of activity before creation is considered complete. Before being made generally available, the new business rule (or set of business rules) should be simulated to determine possible effects on the enterprise. Some activities to determine potential significant overlaps, gaps, inconsistencies, and conflicts with existing rules should be performed through a reasoning and analysis process. That may require simulation and other forms of testing using the experience and knowledge of staff members along with an automated tool assist. As an example of the reasoning and analysis required, consider the following two rules concerning business travel: 1. “All travelers on company business will fly at the lowest available airfare.” 2. “No employee traveling on company business will be compelled to stay over a weekend unless the business purpose spans the weekend.” In many cases, the two rules will conflict because the lowest airline fare will require a weekend stay. It would be useful to analyze rule sets to determine where conflicts of this type exist. The rules could then be adjusted to remove the problems. As an example, the following rule contains the essence of the two travel rules while removing the conflict: “All travelers on company business will fly at the lowest available airfare that does not require a weekend stay unless the business purpose also requires a weekend stay.” This rule system is based on a single repository for all rules but allows the utilization of multiple rule engines for different rule implementation types. The repository itself can, of course, also be considered to be a type of rule engine and used directly as indicated. That direct use may or may not be practical, but it needs to be considered for completeness. The use of the single repository permits an effective simulation function and the ability to reason about the effect and purpose of each individual rule or multiple rules in combination. This type of analysis is critical in ensuring that each rule or set of rules correctly fulfills its intended purpose, regardless of how they are implemented. In addition, the single repository facilitates the life cycle management of the rule base. Because of its central position in the analysis and management of the rule base, the format of the rules in the repository is generally suited to these purposes. Many rule formats will be required for the effective use of the rules under different circumstances and environments. It will be necessary to convert the repository rule form to multiple representations, depending on the desired characteristics of the rule under operational conditions.

The design of the repository business rule metamodel, including the necessary classification taxonomies, is also of critical importance. This class model serves as the main mechanism for ensuring the integrity of the rule base and preventing undue proliferation of rules. Although it generally will not be used as part of the real-time operational environment, it is central to its proper functioning. Figure 5.2 depicts many of the implementation types discussed in previous sections. Although not theoretically necessary, each type usually involves a format change. The diagram illustrates how the same task can make use of rules with different implementation types. That is the usual situation in software development and shows the importance of determining the effect and compatibility of the different rules as a separate step in the development process. For example, Task 1 uses two business rules in two different ways. First, it uses rules that have been compiled from the repository into a run-time library. The rules are not incorporated into the task but, in effect, constitute a type of database and are accessed in much the same way. The characteristics of the rules are that they are changed frequently and also need to be accessed on a frequent basis. The compile function places the rules in a format that facilitates their access by the task. The complexity of the rule format is borne by the compiler, not by the task. An autocompile function is shown as the compile mechanism in the diagram. That means that whenever an appropriate rule is changed in the repository, it is automatically compiled and placed in the run-time library. A manual compile also could have been used, but if there is a significant amount of change, the autocompile probably is better. A manual compile function is shown later to depict the concept separately. The characteristics of rules with this implementation type are that they change frequently and need to be accessed at a moderate rate. In addition to the use of a run-time library, Task 1 uses some business rules directly from the repository. The characteristics of the rules are that they are changed frequently but are accessed only rarely. The format complexity must be borne by the task, because there is no conversion from the representation used in the repository to one better suited to the operational task. It is possible, however, to provide a real-time translation function or interpreter to change the format. That would be a reasonable approach if there were several tasks that could use the same interpreter. If the interpreter would be used by only a single task, there would be no reason not to make it a component of the task and not keep it as a separate entity. In general, unless the change rate of the rules is much greater than their access rate, this type of implementation should not be used. If at all possible, the repository should not be an integral part of the real-time software operations environment. It is much better suited to a non-real-time role. In addition, the characteristics that would make this type of implementation desirable do not seem to represent a practical situation. In the diagram, a workflow manager is used as the control mechanism for the tasks. The manager depends on business rules to determine the execution conditions for the tasks and to monitor their operational performance. The rules are present in the repository but must be translated to the form needed by the workflow manager. After translation, the rules become resident in the workflow manager, becoming a replicated copy of the original rules. The characteristics of these rules are that they are changed relatively infrequently and the input format required by the manager is fixed and not under control of the enterprise. Although not made a part of the diagram to manage its complexity, many other software components can require business rules in a manner similar to that of the workflow manager. They need business rules to be entered in a fixed prespecified format (probably different for each package). These components could exist in either the infrastructure (e.g., security packages) or application (e.g., accounting packages) domain.

Task 2 uses rules that must be interpreted by the software designer and then implemented as an integral part of the final software product. This is the situation found in most previous and current software implementations. The business rules are utilized by incorporation as part of the source code and in many instances have difficult-tounderstand representations. In addition, past and current software practice does not use an explicit form of the incorporated rule, as is indicated by the repository. The rules exist only in the software code form. There are legitimate reasons for using this type of rule implementation as long as the rule is also replicated in the repository. Efficiency considerations in the form of response time or throughput requirements may mandate this implementation approach. However, because this approach is prone to significant error in the translation, comprehensive testing and simulation probably would be necessary to ensure that the rule implementation conforms to the original. Characteristics of business rules with this implementation type are very infrequent changes and high access rates. Task 3 uses two different rule implementation types. The first is a variation of the type used by Task 2. It also involves a manual translation of the business rule, as depicted in the repository, into actual software code. The difference is that the code that represents the business rules is isolated into a separate part of the task. The method is about as efficient as the Task 2 method and is less prone to errors because of the separation from the other components of the task. However, because changes will force a recompilation, the time to make a change will be significant. Rule characteristics for this implementation are the same as those for Task 2: very infrequent changes and high access rates. The second type of rule implementation used by Task 3 is an autocompile from the repository, which is similar to the first implementation type used in Task 1. The difference is that the compiled rule is part of the task and not part of a separate run-time library. That may also indicate a format difference between the two because the results of the compilations do not have to be the same. The characteristics of rules with this implementation type are that they change frequently and need to be accessed at a moderate rate. In addition to using business rules to direct software functionality, they also can be used to format or change the data used by the software programs. That is illustrated in Figure 5.2 using a direct translation from the repository to the database. It also could be done on a manual or automated basis, depending on the anticipated frequency of change. Finally, the business rules can be used to produce printed materials that direct the manual tasks performed by the end users. In general, any process implementation requires both manual and automated tasks. Those tasks must be coordinated and interoperate with each other. Using the same set of business rules as the source for both types of tasks helps ensure the needed interaction.

5.9 Summary Business rules are used throughout the enterprise, usually on an informal and unstructured basis. That prevents achievement of most of the advantages that the rules can provide. By considering business rules as a fundamental asset of the enterprise and performing the needed modeling, rules can be utilized to considerable advantage. Selected bibliography Herbst, H., “A Meta-Model for Business Rules in Systems Analysis,” Proc. 7th Conf. Advanced Information Systems Engineering, Berlin, Springer-Verlag, 1995, pp. 186–199.

Herbst, H., Business Rule-Oriented Conceptual Modeling (Contributions to Management Science), New York: Springer-Verlag, 1997.

Katsouli, E., and P. Loucopoulos, “Business Rules in Information System Development,” Proc. 2nd Workshop Next Generation of CASE Tools, University of Jyvaskyla, Finland, 1991, pp. 481–503. Lang, P., W. Obermair, and M. Schrefl, “Modeling Business Rules With Situation/Activation Diagrams,” Proc. 13th Internatl. Conf. Data Engineering, Birmingham, UK, Apr. 7–11, 1997, pp. 455–464. Rosca, D., et al., “A Decision Making Methodology in Support of the Business Rule Lifecycle,” Proc. 3rd IEEE Internatl. Symp. Requirements Engineering, Annapolis, MD, Jan. 6–10, 1997, pp. 236–246. Ross, R. G., The Business Rule Book: Classifying, Defining and Modeling Rules, Version 4.0, Boston: Database Research Group, 1997. Soper, P., Managing Business Rules, Englewood Cliffs, NJ: Prentice Hall, 1997.

Chapter 6: Financial management Economics—more specifically, financial considerations—are at the core of any enterprise. Bluntly stated, any profit-making enterprise exists so that the amount of money it takes in from customers is greater than the amount that goes out in expenses; the more the better. While that is a relatively easy statement to make, in actual practice, there are enough nuances to keep armies of people busy trying to define exactly what the statement means and how best to achieve that desirable condition. A strong indication of that problem becomes evident as this chapter unfolds.

6.1 The basics Almost every decision and every action taken or not taken in an enterprise generally are motivated or justified on the basis of one or more financial metrics whose values are measured, calculated, or estimated. Unfortunately, depending on which organization or individuals are involved and the specific procedures and metrics utilized, many of those references are based on incomplete information and do not always adequately reflect the true values. The goal of this chapter is to motivate and define an enterprise financial model that can be used to provide a financial analysis of any proposed enterprise activity. The availability of this model is especially important in analyzing decisions concerning the automation assets. Many of the advantages of those assets as well as the overall assetbased approach are susceptible to challenge on traditional accounting grounds. To determine their actual contribution to the enterprise, the financial model and associated analysis mechanisms must be able to effectively consider all the factors that affect the automation assets. The financial model derived here is not perfect. There is still plenty of room for controversy and differences of opinion. The value of the model is that it forces explicit consideration of all issues that have a possible impact on the decision as to whether or not a proposed action (or group of related actions) concerning the automation assets should be undertaken. The emphasis of the discussion is on financial philosophy rather than detailed accounting procedures. However, to provide an embodiment of the philosophy and give enough detail for suitable examples, some reliance on accounting terms and principles is necessary. Those terms and principles are explained as necessary, so a detailed knowledge of accounting is not required.

The points raised here are not meant to always apply to each and every aspect of the enterprise. It is necessary, as in the case of any proposed analysis or activity, to evaluate the advantages and disadvantages before deciding that a proposed procedure or technique is appropriate and necessary. A decision also must be made as to whether to utilize informal or formal approaches to meet the needs of a particular situation. Formal approaches using explicit models and procedures usually provide better results but at a cost that may or may not be worth the improvement. In addition to presenting the financial needs of the automation assets and the reasons that a conventional financial and accounting approach generally will not provide the desired results, the discussions in this chapter are designed to provide a better understanding of some of the more pervasive financial and accounting criteria and the inherent limitations of their use. 6.1.1 Basic equations The financial or accounting aspects of the enterprise are summarized by two equations: assets − liabilities = equity (evaluated at a specific point in time) equity + (revenue − expenses ) = revised equity (evaluated over a specified time period) where assets are items that can be used for the production of revenue; liabilities are items that reduce the future capability to create revenue; equity is a measure of the worth of the enterprise; revenues are items that increase equity; and expenses are items that decrease equity. The equations also incorporate some inherent assumptions that are addressed in the discussions that follow. For ease in use, the five variables in the equations hereafter are known as the financial categories of the enterprise. While the equations must always hold for a given enterprise, they cannot indicate the many underlying aspects that are necessary for the successful operation and continued existence of an enterprise. The equations can only represent static conditions, while an enterprise is fundamentally a dynamic asset. Thus, the dynamic (process) aspects also must be considered to provide a complete characterization of the financial aspects of the enterprise. Those aspects are addressed shortly. The terms expense and cost are used here somewhat interchangeably, as common usage dictates. Although they are intended to signify different meanings, it is not useful for current purposes to be rigorous in that respect. 6.1.2 Asset transformations This section is concerned with the dynamic aspects of the enterprise. Enterprise dynamics can—and usually do—consist of a large number of complex interactions.

However, there are some simple ways in which the basic enterprise dynamics can be defined and described in the same terms used for the basic financial equations. The resultant structures and processes can then be utilized in the construction of the desired financial model. The fundamental dynamic of the enterprise is to transform assets into revenue, as illustrated in Figure 6.1. Figure 6.1(a) depicts the basic asset cycle. Depending on the business of the enterprise and the assets involved, that can be accomplished in a variety of ways. Physical assets can be sold, leased, or used to provide a service (e.g., house washing with a pressure washer). Intangible assets (e.g., skills) can be used to provide a service (e.g., building design). Sometimes assets need to be converted before they can realize revenue (e.g., beads and string converted into necklaces, which are then sold). Assets that support the enterprise but that are not in the direct conversion chain also are considered to contribute to the generation of revenue (e.g., equipment, lights, personnel skills, automation assets).

Figure 6.1: Basic asset transformation process. The dynamic model also contains a feedback path, such that the revenue generated can be used to obtain more assets, which then can be used to generate additional revenue. That classic case of positive feedback loop would allow uncontrolled growth and prosperity for the enterprise as long as other activities that tend to inhibit the main process do not exist. The major inhibiting activity is that associated with incurred expense. Expense is the utilization of assets for non-revenue-producing functions. Expense is incurred to pay employees, provide office space and utilities, and so on. Adding this process to the main process results in the diagram Figure 6.1(b). As long as the values of expenses and revenue are such that revenue does not suffer a continuous decrease, the enterprise will remain viable. In Figure 6.1 and the others in this chapter, expense is shown as the diversion of revenue. Such diversion reduces the amount of revenue available to obtain assets. By considering revenue as a monetary equivalent asset, it is reasonable for the schematic format shown to show expense as a reduction in that asset. In reality, however, expense can reduce any monetary equivalent asset. So far, liabilities and equity have not been accounted for in the dynamics. Liabilities are merely a mechanism for delaying the actual payment of an expense to keep current revenue-producing assets at a maximum. For example, if a building is purchased and a mortgage is obtained for the purchase, the mortgage represents the liability. However, the whole building asset can be immediately used by the enterprise. Liabilities can be considered by incorporating the concept in the dynamic process model shown in Figure 6.1(c). Assuming that equity remains constant, incurring a liability

increases assets by the same amount, while reducing a liability requires an equivalent amount of asset value. The first basic financial equation presented in Section 6.1.1 contains only two independent variables; the third variable is dependent on the values of the other two. Assets and liabilities usually are assumed to be the independent variables, so equity is merely the difference between them. If there are no liabilities, then equity is equivalent to the assets. For that reason, there is no real reason to include equity in the dynamic model. It can be calculated at any time a value is desired. The next addition to the dynamic model is the inclusion of internal transformations. Internal transformations are transformations that are utilized in the enterprise to produce the financial items needed in the operation of the enterprise. The most frequent occurrence of such transformations is the conversion of one or more assets into another asset that is needed by the enterprise. Exchanging cash for buildings, equipment, or raw materials is a frequent type of asset transformation. Cons equently, converting raw materials and equipment use into a product suitable for sale is another type of transformation. The transformation chain can contain as many steps as needed. An example of an asset conversion chain is shown in Figure 6.2.

Figure 6.2: Asset conversion chain. Although not as frequent, liabilities also can be converted from one form to another (e.g., unsecured loan to secured mortgage). Although revenues and expenses also can assume different forms, their value is the overriding aspect of interest so that the different forms usually are not considered explicitly except when the associated risk is materially different. For simplicity, the remainder of this discussion considers only asset transformations. The dynamic model developed so far does not include the concept of intangibles. Intangibles can easily be added to the model, as shown in Figure 6.3. The major difference between the effect of the intangible assets and liabilities and the tangible categories is that the intangibles have a direct effect on the ability of the enterprise to convert assets into revenue. As a part of the asset conversion chain, an intangible asset enhances the conversion, while an intangible liability inhibits it because the assets are used to service the liability instead of being used to produce revenue.

Figure 6.3: Transformation process and intangibles.

6.2 Initial financial model The financial operations of the enterprise have now been defined through a static model (the basic equations) and a dynamic model, as defined in Figure 6.1(c). The combination of the two models forms the initial financial model of the enterprise as illustrated by Figure 6.4. This initial model lacks some constructs that are needed to fully understand the financial implications. The major missing aspects of the initial model are the drivers that cause each of the models to change state and explicit consideration of the automation assets. Those concepts are introduced as the discussion continues and are used to complete the model.

Figure 6.4: Initial enterprise financial model.

6.3 Financial events Any driver that causes the values of the categories of the financial model to be changed is called a financial event. A financial event is any action or activity on behalf of the enterprise that causes one or more financial categories (assets, liabilities, equity, revenue, expense) to change value and thereby change the financial state of the enterprise. Financial events can result from internal or external occurrences. From a financial perspective, the enterprise consists of the totality of the effect of all financial events. This discussion provides more detail concerning the definition and characteristics of financial events and continues the process of developing an appropriate financial model. Initially, we examine financial events that result from internal enterprise activity. Financial events that originate outside the enterprise are then considered and the combination of the two used to create the completed model. Financial events can be of any size and may be an aggregate of other financial events. A simple financial event cannot be subdivided into simpler acts, while a compound financial event consists of an aggregate of simpler events. Because the effect of a financial event will, in general, be nonlinear, the financial consequences of a compound financial event usually will not be a simple linear addition of the results of all the component financial events. It may be a relatively involved (and possibly unknown) function of the component financial events. That effect is one of the major difficulties that limits the application of synthesis techniques to the characterization of the enterprise financial environment and necessitates the use of measurement and analysis techniques instead. A financial event can have long-term or short-term effects. Buying paper for the copy machine usually results in a one-time expense per purchase (financial event). However, purchasing some form of investment security is a financial event that may realize expense or revenue over an extended period of time. Each event has unique characteristics and needs to be considered separately to accommodate those differences.

6.4 Financial event model An enterprise financial event (simple or compound) will be modeled by defining all the effects that can occur as a result of the event. From the definition of a financial event, those effects consist of changes in one or more financial categories. Each category can increase or decrease depending on the specifics of the financial event. It is useful to further decompose some of the categories to provide enough detail to develop the different perspectives utilized later in the discussion. In addition, the possibilities of intangible categories are allowed. That is necessary to partially accommodate financial implications not captured by the conventional approach to financial analysis.

The resultant model is illustrated by Figure 6.5. For that model, 11 categories have been defined that need to be examined individually for each financial event. Although most of the categories are well known, some are not usually stated or examined explicitly. That lack of consid- eration is one of the main reasons that a financial analysis using a partial model may give misleading or even wrong results. The major character- istics of all the categories are discussed briefly, and, as a part of this discussion, their applications to the automation assets are considered.

Figure 6.5: Financial event model. Although each model category is discussed separately, they are closely interrelated. For example, performing a purchase financial event can result in a direct cost, an allocated cost, an opportunity cost, and an asset transfer. All of them happen simultaneously, and both their individual values and the aggregate result are important for a variety of analysis purposes. In addition to each of the categories being a part of the financial event model, they also must be used to augment the static and dynamic categories of the initial model. To avoid undue complexity, that is not explicitly performed during the course of this discussion. The items are made a part of the completed model produced after the discussion of all the financial event model categories. 6.4.1 Cost categories As will be evident from the following sections dealing with costs associated with the automation assets, costs result from two sources: that associated with the creation and continuing existence of the assets and that associated with the use of the assets in the operation of the business. With some few exceptions, the costs associated with the use of the assets is far greater than the costs needed to define and implement them. That is a unique aspect of the automation assets. In most normal costing environments, the cost to provide an asset is the dominant one. Because of the shift in emphasis for the automation assets, intangible costs become much more important to consider, and sufficient means to estimate them must be defined and utilized. Continuing measurements to determine the accuracy of the measurements also must be utilized. Following the normal procedure results in the costs assigned to the automation assets to be understated by a considerable amount.

6.4.1.1 Allocated cost An allocated (indirect) cost is a cost that is incurred in support of a large number of enterprise financial events; as a consequence, the contribution associated with any given financial event cannot be known exactly. The amount to be allocated is fixed, and an algorithm determines the amount assigned. Although the allocated cost often is not directly controllable, it usually is included in the measurements of accountability. An

allocated cost can be tangible or intangible but should be reasonably matched in time with the service it represents. Consider a business rule automation asset. Are there costs that should be allocated to a business rule? If so, what does this allocation represent? Certainly the costs of operating the repository as well as those incurred by performing the activities of the other automation asset management components should be allocated. Those costs, however, represent a minor effect. The major effect comes from the intangible costs resulting from the enterprise using the rule to constrain the operation of the business. Assume the following business rules: (1) “No sales will be made to any customer 60 days or more behind in payments for previous orders” and (2) “No sales will be made to any customer owing more than $10,000.” Customers denied goods or services because they fall under the effect of both rules may get mad and give all future orders to a competitor. Part of the cost of the bad-will and lost orders should be allocated to each of these rules. The allocation may be uniform or based on the percentage of other companies that come under only one of the rules. Portions of the estimated intangible cost also may be allocated to other rules or assets that are found to contribute to the cost. The total intangible cost could be estimated by considering the number of customers that fall under those rules every year, their average yearly orders for past years, and the percentage that do not place another order within a 1-year period. The fact that there is an operational cost allocated to the rules does not mean they are bad rules. The amount saved in bad debts because of either rule may be much larger than the cost they cause. (The cost avoidance effect is discussed in Section 6.4.2.3.)

6.4.1.2 Direct cost Direct costs are costs that can be reasonably associated with a specific enterprise financial event. As with allocated or indirect costs, direct costs can be tangible or intangible. Using the previous example of business rule assets, direct costs that could be associated with the rules are those costs that are unique to the rule. If customers are denied goods or services because they fall under the effect of one of the rules, then that cost is a direct cost of the rule because it can be reasonably associated with the use of the rule. Direct costs are sometimes referred to as variable costs; they exist only because of the financial event to which they are attached. If the financial event had not occurred, the cost would not exist. If one of the rules cited in Section 6.4.1.1 did not exist, then the cost currently attributed to it also would no longer exist.

6.4.1.3 Opportunity cost An opportunity cost is a cost that is incurred because the occurrence of a specific financial event prevented another financial event from being performed, and the absence of that financial event resulted in some cost (or lost revenue) to the enterprise. The most common example usually is stated in terms of lost interest on money that is spent to purchase equipment for a specific purpose. The revenue that is lost because the money was not available for investment is an opportunity cost. The rule of thumb is that the revenue realized from a financial event should at least be greater than the associated opportunity cost. Of course, the money also could have been used to purchase other equipment to produce a different product. The potential revenue from that alternative use also would be considered an opportunity cost. The opportunity cost associated with the creation phase of an automation asset is the revenue generated from the direct cost of developing and placing the asset in the repository. While that could be substantial for assets such as processes, the opportunity cost associated with the use of the asset is usually far greater. The cost of utilizing a given process in labor costs and computer costs is large; therefore, so are the opportunity costs.

6.4.2 Revenue categories Unlike costs, revenue usually is associated only with the use of an asset and not with its mere existence. The use of the asset may be to convert other assets, to transfer ownership to someone else (e.g., a sale), or to retain ownership and charge for its continuing usage (e.g., a lease, a license, or a service). That is in keeping with the more traditional approach to revenue accounting. However, other unique aspects to the revenue aspects of the asset management system must be considered. One of those aspects is the concept of allocated revenue. Why that concept is useful in the asset management system and the major considerations involved are discussed next.

6.4.2.1 Allocated revenue In most revenue generation situations, the cause of the revenue can be readily determined. In the case of the automation assets, that is not the usual condition because of the number of assets that may be involved and the implicit, rather than explicit, contribution to the revenue. Consider, for example, a scenario that is used to develop and test a process representation. The process is used as the basis for a workflow, and the workflow is used to provide a service that generates revenue. The scenario certainly contributed to the realization of revenue. Why and how much of this revenue should be allocated to the scenario? This discussion provides a partial answer. The automation assets need to have revenue allocated to them to indicate their value to the enterprise. In far too many cases, the concept of cost centers is utilized as one type of component of the enterprise. Cost centers, as their name implies, are considered to be pure cost and, by implication, a bad thing to have. Management is always trying to reduce the cost associated with a cost center. Cost centers are always contrasted with profit centers, which, again by implication, are considered good things to have. After all, who does not want profit? In reality, there is no such thing as a cost center. It is a fiction of accounting, defined for convenience. From the perspective of the dynamic model, all costs contribute to the generation of revenue, and all revenue is the ultimate result of incurring cost. If there are costs that do not contribute to some aspect of the generation of revenue, they easily can be eliminated, and the profit of the enterprise will increase by the same amount. By allocating revenue to the financial events that resulted in costs of some type (whether they occurred in a cost center or a profit center), the true contribution of the financial events to the effective functioning of the enterprise can be determined. It easily could be true that increasing the cost incurred by a cost center would provide an even greater increase in revenue to the enterprise. Activity-based costing, which is designed to determine the relative contribution to cost of the activities in a process, provides only half the needed information. The other half is activity-based revenue, which provides an allocation of revenue to each of the same process activities. If the allocated cost is greater than the allocated revenue, that indicates that the process activity is badly designed and needs to be changed or that the allocation algorithm requires adjusting. Now that the “why” part of the revenue allocation has been considered, the remaining need is to discuss how the allocation should be made, specifically in the case of the automation assets. Because of the number of assets involved, the allocation probably should be made on the basis of an entire asset class or a major subclass. If desired, another allocation based on some type of averaging could be made to the individual assets. The allocation algorithm probably will be structured around the use of an “elimination” technique. That is accomplished by asking the following questions: What would be the effect on revenue if the asset class did not exist? Would it be reduced by 0.1%, 5%, or 75%? Would the revenue be increased by some amount? While the last question may

seem strange, consider the business rule example used previously. If it was decided to eliminate the restriction placed on customer orders imposed by the rules, the total revenue of the enterprise conceivably could increase. However, so would the risk factor associated with that revenue, resulting in a cost associated with unrealized revenue or simply bad debts. In fact, it would be hoped that the cost avoidance allocation (see the discussion in Section 6.4.2.3) would be greater than the negative revenue (cost) allocation. The effect on revenue can be difficult to determine, but if the enterprise is to understand the causes and effects of its individual and compound financial events, an approach to providing that type of information needs to be developed and actively utilized in the decision-making process. Returning to the example of the scenario asset, the prior discussion indicates that the allocation of revenue could be accomplished as follows. Assume that the scenarios did not exist, resulting in processes that had to be tested and verified another way, possibly on “live” customers. If that approach resulted in a longer time to reach operational status and, based on historical data, resulted in 5% fewer customers, then the lost revenue due to late process availability and the reduction in customers would be partially allocated to the scenario assets involved in the process. Remember that the revenue reduction assumption is only an estimation procedure used by the analysis process to determine the contribution of the scenarios to the overall revenue and thus indicate their contribution to the enterprise revenue.

6.4.2.2 Direct revenue As opposed to allocated revenue, revenue that can be identified as a direct result of a given asset should be entirely associated with that asset. Unlike costs, there are few instances in which revenue can be considered as only being associated with a single asset or other enterprise financial event. The generation of revenue is almost always the result of the interaction and contribution of many enterprise activities. One exception might be a sole practitioner providing medical or legal advice for a fee. Even then, there probably are other associated financial events that would have part of the resultant revenue allocated to it. In spite of the view expressed in the preceding paragraph, most revenue realized by an enterprise is assumed to be the result of a single financial event. That is because the allocation activity is not performed and there is a need to associate revenue with some enterprise financial event. The revenue resulting from a sale is attached to the asset or service sold. The contribution of other enterprise financial events to the realization of the revenue is not considered. To restate the point, this method of associating revenue is what makes it so hard to justify individual components of the enterprise that are important, but for which only a cost category is identified.

6.4.2.3 Cost avoidance Cost avoidance is the result of an enterprise financial event that negates the need to incur a cost. Cost avoidance is a type of revenue because it increases the ultimate amount of funds available to an enterprise over that which would be available had not the financial event been performed. However, that aspect must be viewed with extreme caution, as the following discussion indicates. Two types of cost avoidance, each with somewhat different characteristics, are defined. For convenience, they are labeled weak avoidance and strong avoidance. The first type, weak avoidance, is similar to that realized by buying an item on sale. If the usual price is $10.00, but the item is purchased on sale for $8.00, then a cost of $2.00 has been avoided by meeting the terms of the sale. The reason that financial event is termed a weak avoidance is that, had the item not been purchased, there would have been no obligation to pay the $2.00. The existence of the cost that is avoided is created by the very financial event that avoids it. It easily can be argued that this is not a cost

avoidance financial event at all but merely presents a different decision cost for an item that may or may not be purchased. The strong type of avoidance is much more powerful in its effects. In this case, the cost still exists even if the financial event that could avoid it does not occur. An example is the receipt of an invoice that is due in 30 days. The terms of the invoice state that if it is paid in 10 days, only 98% of the total amount needs to be paid. That is the usual commercial practice of “two 10, net 30” payment terms. By paying the invoice within the 10-day period, a cost of 2% of the invoice is avoided. If the payment is not made in the 10-day period, the entire amount must be paid. A real savings can result from strong avoidance. Another example of strong cost avoidance results from the potential reuse of an automation asset (e.g., software component). If the asset is reused, the need to incur cost to provide a new asset is avoided. If it is not reused, the cost for the asset still exists. Cost avoidance is one of the major contributions of the automation assets. 6.4.3 Asset and liability categories Not all financial implications occur from revenue and expense con- siderations. Changes in asset values and liability values also are important aspects of enterprise financial events. The major difference from the model categories defined in this section and those used in the usual accounting sense are again associated with intangibles, specifically the concept of intangible liabilities. As will be pointed out, neglecting the explicit effect of intangibles can cause the enterprise to fail. It is interesting to note that the intangible aspects, while not considered part of the conventional accounting treatment of an enterprise, probably are one of the most important considerations of the stock price of a public company. Companies do react to that by engaging in public relation campaigns and so-called institutional advertising, which are designed to make people feel good about the company and its brands. In a real sense these costs are not expenses but an asset conversion from a monetary asset to the intangible asset of positive consumer perception. However, by not reflecting the financial effects of these intangibles down deep into the enterprise, the best opportunities to reinforce the good actions and correct the bad actions are lost.

6.4.3.1 Tangible assets Many financial events result in an exchange of one asset type for another. The sale of an inventory item realizes revenue and results in a reduction in the value of the inventory asset and an increase in the cash asset. The purchase of office supplies results in an expense, an increase in the office supplies asset, and a decrease in the cash asset. In addition, a financial event can cause the value of an asset to change without resulting in a transformation, the realization of revenue, or the incurring of a liability. Those changes may or may not be associated with a revenue or expense component. An example is the reduction in price of certain inventory items to sell them more quickly. Outside financial events also can result in asset value changes. For example, a competitor bringing out a new line of merchandise can cause the inventory value to decrease considerably. The valuation of enterprise assets is open to some interpretation. If a tangible asset is purchased for some amount of money, it usually (but not always) can be assumed that the value of the asset, at the time of purchase, is the amount paid. After that period, asset value can increase, decrease, or remain the same. Although usually expressed in dollars, it is difficult to determine against what measure value should be determined. As a simple example, assume that the intrinsic, or absolute, worth of some asset remains constant throughout its life. If it was purchased for $10.00, then, depending on inflation, it will be worth more after some amount of time. The dollar value increases, but the absolute value does not. Because of that difficulty in measuring the intrinsic worth of an asset, standard accounting practices do not consider those types of changes unless

they are realized by an explicit financial event, such as the sale of the asset. If the asset in this example were sold for $13.00, the gain in the dollar value of the asset would be recognized. At any given time, using only standard accounting information, it is difficult to determine the financial eventual value of the tangible assets. The intangible assets are even harder to value, as discussed in Section 6.4.3.2. From an asset management system perspective, the expenditure of resources is the financial consequence of creating an automation asset. The difficulty lies in the determination of the value of the automation asset. Is it the cost of creating the asset, the projected cost avoidance obtained from the reuse of the asset, the amount of future revenue that can be realized from the asset, or some combination thereof? Although a great deal of attention is not given to the valuation of the automation assets, it is important to obtain some degree of comprehension as to the value of the assets. That is measured in dollars because it is the only real comparison available to the enterprise.

6.4.3.2 Intangible assets Consider the development of a software component asset. How should the value of the component be determined so that any project using the component could be charged appropriately? In this case, the value probably should be determined by utilizing the development costs as a base. That is in contrast to most attempts at evaluating this type of asset, which use as an estimate the number of times the asset is expected to be used. That type of estimate is relatively unreliable because usage is difficult to predict. Even if the asset is used in a project, its worth would stay the same if the asset is still considered to be viable. The value obtained through use could be thought of as a cost avoidance revenue. Methods of valuing software components as one specific case of great interest are discussed in Chapter 14. As difficult as it is to estimate the worth of a software component, it is more difficult to estimate the worth of other automation assets, such as a business rule. The cost to develop a specific business rule is usually quite low, while the effects of the rule can be quite large, as indicated in previous examples. Because of the difficulty, the temptation would be to forego a valuation. However, some value must be placed on the asset if it is to be treated with the respect accorded the other enterprise assets and show that it is part of the asset conversion chain that ultimately results in revenue. Simply expensing the cost of creating the business rules is an informal indication that they have no continuing value and are, in a sense, throwaway items. The easiest approach to the valuation problem in this instance is probably the same as utilized for tangible assets. Assign the class of business rules a value consistent with the cost of creating them. While that probably understates their real value to a considerable extent, the major goal is to treat them as assets, not necessarily to provide as accurate a valuation as possible. An absolute valuation of asset worth probably is not a reasonable goal to pursue anyway. The importance of assigning a value to the automation assets is to treat them in the same way as the other assets of the enterprise. At a minimum, the costs associated with their creation should be capitalized and not treated as an immediate expense. When that is not done, there is an increased tendency to view the assets as having little intrinsic value because no other effective way exists to estimate their continuing contribution to the operation of the enterprise. Even if financial accounting rules do not allow capitalization of those assets, this should be done from a management accounting perspective.

6.4.3.3 Tangible liabilities As with assets, an enterprise can change its liabilities by performing an appropriate enterprise financial event. The major difference is that the valuation of tangible liabilities usually is not difficult. The liability almost always is the amount owed in dollars. The connection with the automation assets usually is indirect because there is no concept of liability, per se, in the asset management system. Assume that a decision is made to

procure a certain software component and make it an automation asset. If the purchase price is borrowed, then a liability is created that is associated with the asset. The association is relatively unimportant, however, since the key is the availability of the asset itself, not the means by which it was financed.

6.4.3.4 Intangible liabilities In many cases, intangibles are more important than the tangible financial categories. The same is true for the liability aspects of the asset management system. One of the most important intangible liabilities is negative customer perception of the enterprise or its products. If the perception is large enough, it can easily overwhelm the assets of the enterprise and cause an effect that is the same as if the tangible liabilities were much greater than the assets. It can throw the enterprise into bankruptcy. The relatively recent near-bankruptcy experiences of Ford Motor Company and Chrysler Corporation can easily attest to that fact. What does the asset management system have to do with the intangible liabilities? The answer is that, properly considered and utilized, it can go a long way toward preventing the occurrence of this type of liability. One of the main purposes of the asset management system and associated assets is to allow the enterprise to standardize and measure the effectiveness of its operations and thereby improve the service to its customers. The asset management system, or lack thereof, directly affects the existence of any intangible liability. 6.4.4 Equity categories Because equity is merely assets less liabilities, there is no need to treat equity as a separate topic, especially as it relates to the asset management system. Although an enterprise spends a significant amount of time raising equity through stock sales or other activities, the goal is not really to increase equity, it is to increase the assets available to the enterprise without increasing liability. By focusing on the increase in assets, the equity is carried along. Because intangible assets and liabilities have been defined as possible categories of both the static and dynamic enterprise models, the concept of intangible equity also must be defined. In the same manner as that defined for the tangible categories, this type of equity is merely the difference between the intangible assets and the intangible liabilities.

6.5 External financial events External financial events are occurrences that: § Originate from outside the enterprise; § Are not controllable by the enterprise; § Change the value of at least one of the 11 financial categories of the financial event model. External financial events represent the randomness of the enterprise environment and the need for the enterprise to operate in such a manner as to reduce the effect of those events to a minimum. From a financial perspective, that means the definition and utilization of internal financial events in such a way that the enterprise is least vulnerable to outside forces. This is a type of risk management that should be explicitly utilized in any type of financial and operational planning for the enterprise. By adding a representation for external financial events to the enterprise dynamic model, the dynamic model is completed. That model, along with the augmented static model developed previously, now can be used to structure the evaluation of any proposed financial event.

Although in theory external financial events can change any of the categories of the mode, they most frequently induce changes in the intangible assets and liabilities. However, tangible assets and liabilities also can be affected by some classes of external financial events. For example, when they reflect changes in the competitive environment, external events can affect the valuation of inventory or other assets. The value of a liability also can vary if it is dependent on foreign currency values and an external event causes those to change.

6.6 Complete model Figure 6.6 shows the completed financial model. The model contains three parts, the augmented equations of the static model, the augmented dynamic model, and the financial event model. The purpose of the model is to be able to consider the static and dynamic effects of a proposed or completed enterprise financial event.

Figure 6.6: Complete financial model. The model does not provide information as to how the value of each of the financial categories will change as a result of a specific financial event. Also, it does not specify what procedures are to be followed to obtain that type of valuation information. Definitions of those procedures are highly situational and depend on the specific structure and business of the enterprise. Although it is a difficult and probably resourceintensive exercise, performing the necessary activities to be able to estimate all the categories for proposed or completed financial events will provide a great deal of the information needed for the effective and cost-efficient operation of the enterprise.

6.7 Implications The implications of the discussions in this chapter on the asset man- agement system are many. Overall, they advise caution in utilizing a financial argument to justify a proposed enterprise activity. From the perspective of the asset management system, which is the major focus of this chapter, they reinforce the need to consider the asset management system assets as true contributors to the health of the enterprise and the need to expend the necessary resources to operate it effectively. In effect, the automation assets are the raw material needed to construct parts of the enterprise automation environment asset. That asset, in its support of enterprise operations is used to realize revenue. If the raw materials are lacking or faulty in some respect for the use that will be made of them, the assets built from them may require more resources and time than otherwise would be necessary. In addition, the resultant assets may not provide the customers with the expected results. The resulting effect on the tangible and intangible financial categories of the enterprise can be quite negative

and far greater than would be expected from considering only the value of the assets themselves. The major points of this chapter can be summarized as follows: § The financial model employed in evaluating courses of action is of crucial importance in obtaining suitable results. § The dynamic model dimension of enterprise financial condition is as least as important as the static model component in determining the effects of an activity. § The intangible financial categories are important in evaluating the effects of any proposed or completed enterprise activity, and, in fact, their effect may be much greater than that of the tangible categories. § Financial events cannot be considered in isolation but must be examined as part of an overall environment. If that is not done, the combined effect of the individual events will not produce as effective a result as one that accommodates more global considerations. § Allocation of revenue to financial events is as important as the allocation of costs. That type of allocation reduces the tendency to think only in terms of expense and produces a more balanced outlook as to the necessity of the event being considered. § Using financial arguments to support the desirability of taking some enterprise action should require an analysis of the possible effect on all the financial categories of the model, including the intangible ones. § Automation assets are the raw material of the enterprise and, as such, influence the effectiveness of the revenue-producing assets and the financial health of the enterprise that usually is far greater than their assigned value. Selected bibliography Alfredson, F. K., “Defining and Recognising Revenues,” New Accountant, Vol. 5, No. 7, 1992, p. 3.

Brockington, R., Accounting for Intangible Assets: A New Perspective on the True and Fair View, London: Longman Group, 1995. Cheng, C. S. A., and R. P. Manes, “The Marginal Approach to Joint Cost Allocation: A Model for Practical Application,” J. Management Accounting Research, Vol. 4, 1992, pp. 44–63. Chenhall, R., and D. Morris, “The Effect of Cognitive Style and Sponsorship Bias on the Treatment of Opportunity Costs in Resource Allocation Decisions,” Accounting, Organizations & Society, Vol. 16, No. 1, 1991, pp. 27–46. Egginton, D. A., “Towards Some Principles for Intangible Asset Accounting,” Accounting and Business Research, Vol. 20, No. 79, 1990, pp. 193–205. Guilding, C., and R. Pike, “Intangible Marketing Assets: A Managerial Accounting Perspective,” Accounting and Business Research, Vol. 21, No. 81, 1991, pp. 41–49. Hibbard, J., “Software Gains Capital Treatment,” Information Week , Issue 664, 1998, pp. 18– 20. Hodgson, A., et al., “Accounting for Intangibles—A Theoretical Perspective,” Accounting and Business Research, Vol. 23, No. 90, 1993, pp. 138–150. Lee, T. A., “Cash Flow Accounting and the Allocation Problem,” J. Business Finance and Accounting, Vol. 9, 1982, pp. 341–352.

Parker, C., “A Fundamental Reassessment of What is Understood by ‘Assets,’” New Accountant, Vol. 5, No. 7, 1992, pp. 2–3. Reilly, K., “Equity and the Asset-Liability Equation,” New Accountant, Vol. 5, No. 7, 1992, p. 2. Ristelhueber, R., “Toxic Accounting,” Electronic Business, Vol. 24, No. 3, 1998, pp. 66–70. Shank, J. K., and V. Govindarajan, “Strategic Cost Management: The Value Chain Perspective,” J. Management Accounting Research, Vol. 4, 1992, pp. 190–196. Soh, D., “Concepts That Will Shake the Profession,” New Accountant, Vol. 5, No. 7, 1992, p. 1. Stewart, T., Intellectual Capital: The New Wealth of Organizations, New York: Doubleday, 1997. Sveiby, K. E., The New Organizational Wealth: Managing & Measuring Knowledge-Based Assets, San Francisco: Berrett-Koehler Publishers, 1997. Thomas, A. L., “The Allocation Problem in Financial Accounting: The Nature of the Problem,” in Contemporary Accounting Theory, ed. by E. S. Hendriksen and B. P. Budge, New York: American Accounting Association, 1974, pp. 180–185. Walker, B., “Intangible Assets and Other Real Things,” New Accountant, Vol. 5, No. 12, 1992, p. 9.

Chapter 7: Planning and strategy 7.1 Explicit asset recognition The explicit recognition of the intangible automation assets as “real” enterprise assets is fundamental to providing a flexible auto- mation environment that can accommodate continuous change in the enterprise. Without that recognition, a significant amount of the accumulated wealth of the enterprise cannot be utilized, and additional resources must be spent to provide the needed automation support. Unfortunately, the operation and behavior of the enterprise must change for automation assets to be utilized in a manner similar to that of the physical assets. This type of change is difficult and is one of the major reasons that an asset-based approach has not been widely adopted for automation development. An explicit management system that can address the major requirements of these assets can help the enterprise determine the way to utilize those assets and the type of changes that have to be put in place to make their use effective. Such a management system has been specified and the components of the system have been discussed in enough detail to provide a basic understanding of the principles involved. The management system may seem too complex to be effectively utilized, require technology that does not yet exist, or absorb too many scarce resources to sustain its operation. These criticisms can certainly be valid if a rigid dogmatic approach is adopted. That was not the intent of the presentations. Not every aspect of the management system must be present, and those that are utilized do not necessarily need to be perfect. With an understanding of the purpose and utilization of the entire management structure, especially the interactions between the various components, the environment can be tailored to the needs of a specific enterprise. When problems occur, the required changes can be made based on knowledge of the dynamics of the environment.

A popular saying states, “The devil is in the details.” That means high-level generalized approaches can always be made to sound good, but the details necessary for implementation can easily cause them to fail. Like all good sayings, there is a measure of truth to what is said. There is another popular saying that “if you don’t know which way you want to go, any road will get you there.” That means, of course, that before beginning anything and worrying about the details, it is useful to have a general understanding as to what is to be done. Obviously there is truth to the second statement also. Both those directions can be summarized by a statement attributed to General George Patton: “Planning is invaluable, a plan is useless.” The interpretation is that knowledge of what can be done and at what cost is required to understand the environment. Selection of a specific plan thought to be suitable for the environment, while necessary, is always subject to attack and subsequent revision. Knowledge of the details of the environment makes meaningful revision possible. That is the reconciliation to the first two slogans. Understanding the overall environment is necessary, and the selection of a general direction based on that knowledge will start the actions required to reach the intended goal. As the details unfold, the willingness to admit problems, reevaluate directions, and change accordingly is absolutely vital if forward progress is to continue. Why go through this discussion? Because automation asset management, to produce the results expected, requires exactly this type of approach. Planning is necessary to understand and effectively utilize the entire management system. The details are subject to change as the implementation and utilization proceed. Combine operations management and configuration management? If the circumstances dictate, why not! Consider a less than perfect repository? Some capabilities are better than none! Identify a repository that accommodates the most needed functions. Create the wrong type of asset or asset class? Replace it! There is no way to know in advance all the variables and conditions that will be encountered, even if the personnel involved are experienced in the activity. If the automation assets are considered to be the raw materials of an enterprise asset chain as discussed in Chapter 6, there will always be “spoilage and scrap,” to use a manufacturing analogy. That is to be expected and, as long as it does not exceed a predetermined level, is a normal part of the automation asset system. The cost of being perfect usually is much too high and usually can never be achieved, even if attempted. That merely underscores the fact that keeping asset management running properly requires constant attention. These types of evolutionary changes do not indicate a faulty approach. On the contrary, they indicate a healthy willingness to discover and adapt to new information. The automation methodology, discussed in Part III, is based on this type of adaptive change, and the approach will be on a more structured basis than can be done in the current discussion.

7.2 Wasted efforts Most attempts to use a managed automation asset approach start off with a great deal of enthusiasm and energy. Whether the enterprise initiates an asset system because of the desire to reuse software components, go to a management-by-process structure, or utilize object-oriented approaches, some expenditure of resources and changes in operation are usually considered necessary. As time passes and the constraints required by automation asset management begin to chafe and the resources utilized in its operation are coveted by other operational groups, the initial resolve can weaken greatly. Unless the enterprise has a good understanding as to why the management system was started and the advantages that can be obtained, the initial enthusiasm and energy will disappear.

The worst thing that can happen to the management system and its associated assets is that they become neglected. Although the effects of neglect can vary, the ultimate result is that the automation assets do not contribute to the good of the enterprise, no matter how well the assets are specified and designed. In that condition, frustration and a feeling of helplessness become the overriding conditions. Neglect begins when there is a general feeling on the part of the enterprise that managing the assets is an unnecessary expense and what is being accomplished is really not necessary or can be performed more cost effectively when distributed to other enterprise areas. Without a financial model and management accounting system that would indicate the real value provided, this type of attitude is hard to refute. A robust management system that is adequately supported and utilized as the foundation for all automation and software activities contributes greatly to the success of the enterprise. However, if that is not the case, and the management activities are merely going through the motions, there is no reason to continue to waste the resources used in a meaningless exercise. As competitive pressures increase, a meaningful asset management system almost certainly will return. In the meantime, the saved resources can be used to stave off bankruptcy for a little while.

7.3 Technology evolution As indicated in Chapter 1, all the technologies involved in enterprise automation are changing at a rapid pace. The ones in use at any given time ultimately will be replaced by others with different characteristics and utilization needs. Unless there is an excellent understanding of the underlying engineering principles and a structure or model on which possible changes can be evaluated, it will not be possible to evolve and change the approaches to automation in a timely and effective manner. In many cases, unless it is corrected, that lack of technology responsiveness will cause the enterprise to begin a slow and possibly painful decline. While business needs should always drive the utilization of technology, if there is none to be driven, the result will be equally as unsatisfactory. Automation asset management can form an important component of the structure necessary to evaluate the introduction and utilization of technology. As it is used in enterprise operation, much will also be learned about what works, what does not work, and what is missing in the specific environment involved, from both a technology and a business perspective. That is a continuing process and must exist throughout all aspects of the management and its associated assets. What did not work in the past may now be enabled through technology. What worked previously may be superseded. Entirely new approaches may become feasible. A knowledge of the underlying principles is again the main enabler for the analysis of the information obtained and for the definition and implementation of the necessary changes.

Part II: Automation assets The automation assets presented in Part II are those that are utilized in implementing the enterprise automation environment as part of the design, part of the operational environment, or both. As discussed in Chapter 1, the needs of the enterprise in the current business and technical climate indicate that a process-based approach be adopted. That means the automation methodology must be able to efficiently convert a business process specification into a workflow structure that is utilized by the enterprise automation environment. The implemented business process should be compatible with the computing infrastructure and other business process implementations that are part of the automation environment. The definition and modeling of the needed assets could be accomplished concurrently with the specification of the methodology design. Having had experience with both types

of presentation methods, the author feels that it is better to present the automation assets separately from the methodology for two reasons: § First, each automation asset is of interest in areas outside its specific use in the methodology. Independent consideration can include interesting aspects of the other uses. § Second, the flow of the methodology discussion would be too fragmented with the frequent stops that would be necessary to develop the needed asset models. The major disadvantage to separating the models from the methodology discussion is that it can be difficult to describe exactly why a specific concept or approach was selected. In addition, it probably will be necessary to refer to the presentations in Part II as the methodology construction proceeds. Three types of assets are considered: those used as part of the business process representations, those that provide the implemented process representation, and those that have aspects of both representation types. The business process representation assets are processes, scenarios, and roles. The client/server structure, software components, and workflow assets are part of the implemented process representation. The data, dialog, and action assets are considered to be part of both types of representations. The order of discussion of the assets is approximately that which will be needed in the methodology discussion. Although there are significant interrelationships between the assets, they are considered only as needed to fully explain the model or utilization of an asset. That usually occurs when one asset is used as a component of another. Many of the other relationships are examined as a consequence of their use in the process implementation methodology.

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

Chapter 8: Process modeling The need for a transition to a process management approach was well documented in Chapter 1, and a process approach to enterprise automation is assumed. This chapter concentrates on developing unit and class asset models for business processes in sufficient detail to serve as the starting point for the process implementation methodology in Part III. Although there is only one class model, there are multiple unit models because of the different purposes for which they must be used. Before proceeding, it is necessary to discuss the use of the term process and the terminology in general. The term process is commonly used to refer to (1) a process component at any level of the class model, (2) the parts of its eventual representation in a graphical form, and (3) a deployed implementation of a process. That causes considerable confusion and difficulty in determining the proper context of any given use of the word. To partially alleviate that problem, if the context is not clear from the discussion herein, the word process is qualified to indicate the particular context in which it is being used. Those qualifications will be introduced as required. In addition, process, for the remainder of the discussion, refers to a business process (i.e., one used to support the operation of the enterprise).

8.1 Process implementation To be useful in the day-t o-day functioning of the enterprise, the process model must be implemented in some form. One failing of many process reengineering and management-by-process efforts is that the entire focus is on process definition and very little attention is paid to the process implementation needs and the associated life cycle management requirements. Process implementation requires design, fabrication (build), and operate activities as well as an oversight function to determine the effectiveness of the implementation. Those activities are the same as the ones necessary in the production and utilization of any asset. Although used informally here, those activities are defined in additional detail in this and other chapters. Although it is important for any automation asset, life cycle management is particularly important for processes, and considerable attention will be given to that aspect. One approach to defining and utilizing a complete process life cycle is discussed in Section 8.2. It is concerned not only with process definition but also with implementation and the changes that occur in the normal course of business. Because of the importance of process as the unit of enterprise automation, a concerted effort is made to differentiate a process implementation from a traditional functional system implementation. Even though it sometimes leads to awkward sentence structure, the term process implementation is used to refer to an implemented process along with all the necessary support software. The term system is not used. Where the context is reasonably clear, the word workflow occasionally is used to indicate a process implementation.

8.2 Process life cycle model To be useful, the process life cycle model must address all the aspects of the life cycle discussed in Chapter 3. In addition, it must serve as a unifying structure on which all the diverse terminology and concepts that are applied to business processes can be placed. Such a model is presented in Figure 8.1, which is used as the basis for the remainder of the discussion of management by process. It is a form of E-R diagram, although there is no attempt to show all the possible relationships. That would make an already complex chart impossible to understand and would certainly defeat its purpose.

Figure 8.1: Process life cycle model. Although the model itself has some process-like characteristics, it is not discussed in that context. The process qualities are not complete and would only add confusion at this time. The discussion of the implementation methodology in Part III that enables that view of the life cycle focuses on the process view. The notion of a process life cycle is separate and distinct from the notion of a software life cycle, although they interact closely. The two life cycles are sometimes confused because software frequently is the mechanism used to support process implementations. To illustrate that important point, remember that a process could be implemented completely by human effort. Such a process certainly would have a life cycle, depending

on the needs of the business, but it would not require any software support. In a process that requires software support because of advancing technology, several generations of software, each with its own life cycle, could be employed without changing the process. Alternatively, for competitive reasons, a process could undergo considerable change during its life with corresponding implications on the software that supports it. In fact, one of the goals of the new view of process support software is to allow a process to undergo considerable change without the need to greatly change the underlying support software, which is designed to be process independent. Techniques for realizing that goal are examined in the discussion of software components in Chapter 14 as well as in Part III. The model defines four main subcycles of the overall process life cycle: plan, design, operate, and manage. The plan cycle is further divided into two additional subcycles: the business events plan and the business structure plan. Cycles are called cycles because they may be visited over and over during the lifetime of the process. They are not considered phases in the sense that, once a phase has been completed, it is never again invoked for the same development instance. In the methodology discussion, the term spiral is used to indicate a repeatable set of activities. That is in keeping with generally used methodology terminology. Using two different terms also helps differentiate between the life cycle model and the methodology that enables it. Each subcycle is discussed briefly to ensure that the definitions of all the assets in the subcycle, their major relationships, and their place in the overall enterprise process context are well understood. Details of most of the assets of interest are contained in other chapters. The purpose in this discussion is to understand the life cycle and its components as a whole. 8.2.1 Plan cycle The plan cycle is where the enterprise defines the business it is in and how it intends to support that business. In many, if not most, businesses, the definition is informal and has grown and changed throughout the life of the enterprise with little or no attention. Even businesses that devote a considerable amount of their resources to a planning function of some type do not have a model for describing and quantifying their expected interactions with customers or the structure by which they intend to meet the requests of those customers. Most businesses have been quite successful over a long period of time without a defined approach. That was possible because of the inherent constraints imposed by the hierarchical organization and function-based automation support. Those conditions, to a great extent, mitigated the lack of formalized models. With the change to a relatively flat, process-based organization and client/server distributed automation support, the lack of a planning model puts any enterprise at a considerable disadvantage. That disadvantage is external with respect to competitors who are able to model and understand their business. The disadvantage is also internal, in that the efficiency of operation will be far less than it could or should be with a wellthought-out model. For the remainder of this discussion, it is assumed that the enterprise has a formal planning structure of the type described here. Although other approaches to the plan cycle can be defined and successfully utilized, a discussion of their structure and characteristics and how they would fit into the other subcycles is beyond the scope of this presentation. The plan cycle is used to determine the definitions of the relevant business events and the enterprise operations processes. It contains two basic types of structures: (1) those devoted to understanding what the customer intends to request of the enterprise and expect in return and (2) those devoted to how the enterprise intends to respond to those requests. It would be expected that the two types of structures would be closely interwoven and their specifications performed in concert. In practice, that is not the normal situation. Both types of plan structures usually are defined and specified independently. The customer interaction definitions are provided by front-line or first-line supervisory personnel, who are intimately involved with the

customers and understand their needs and expectations. The business structures, including high-level process definitions, generally are provided by executive personnel, who are far removed from “real” customers, and result from history, internal politics, and in many cases a lack of understanding of how the needs of the customers are being met. Considerable friction results from those two parts of the planning function being independent degrees of freedom. What should be a smooth response to a customer request or other business event becomes difficult when it is handled by a business structure not designed to accommodate it. Process reengineering was supposed to fix that problem, but the existing organization structure proved to be extremely resistant to change. The organization can remove layers, it can downsize, it can change technology, it can emphasize process over function, but it usually retains the old organizational structure boundaries. The engineering organization remains the engineering organization; the sales organization remains the sales organization; and the manufacturing organization remains the manufacturing organization. Whether one organization or another is the best one to meet the needs of the customer is relegated to secondary importance. There is turf to protect, careers to consider, and a general fear of the unknown. When everything around you is changing, there is usually something that is made to be stable. That “thing” in current enterprises is the existing organizational structure. Because the disconnection between defining customer needs and structuring the enterprise to provide for those needs is unlikely to change, the best approach is to develop frameworks and procedures designed to accommodate the two different views and mitigate any resultant friction and conflict. That is the approach taken in this presentation and in the methodology presentation in Part III. Experience has shown that such harmonization has worked well when put into practice. Sections 8.2.1.1 and 8.2.1.2 discuss the plan cycle areas and their major interrelationships.

8.2.1.1 Business events Business events are occurrences that elicit some type of response from the enterprise. The purpose of predefining expected events is to determine how to produce an effective response. An effective response is one that satisfies the requester (if the event is a request), is cost effective for the enterprise, and is consistent with the enterprise view of its purpose. Business events can be external or internal. They can be caused by customers, suppliers, employees, or other individuals associated in some way with the enterprise (including those with criminal intent). Business events also can arise from nonhuman sources, such as storms and earthquakes. To illustrate the usefulness of explicitly defining business events, consider the following example. An enterprise is in the retail shoe business and a customer requests the custom manufacture of a shoe. This event could be handled by the enterprise in a variety of ways: § The request could be rejected outright if the enterprise does not want to be in the custom shoe business and has no knowledge of organizations that perform that type of work. § As a service to the customer, the requester could be referred to another enterprise that manufactures custom shoes with no further involvement on the part of the retail establishment. § The order could be taken by the retail shoe business, sent to another enterprise for manufacture, and returned to the retail business, which would then deliver it to the customer. § The retail shoe business could manufacture the shoe itself using its own facilities and resources. The possible responses to the same business event are listed in the order of the business’s increasing involvement in the event. There is no right or wrong response to this event. Each response is possible depending on what business the enterprise believes it is in, what its resources are, and how it presumes its customers should be

treated. However, if there is no attempt to predefine expected business events, the business will not have the opportunity to make this type decision explicitly. That could result in, among other problems, lost revenue opportunities, inefficient use of resources, and unhappy customers. The major automation asset used in the plan cycle is the scenario. Scenarios represent detailed business events that the enterprise expects to occur in the course of business and that it wants to be able to effectively and efficiently address. Scenarios provide a framework on which to model and examine the definitions and consequences of business events that the enterprise is prepared to handle. Scenarios are described in detail in Chapter 9. In addition to providing a structure on which to model business events, scenarios are also useful to distinguish planned business events from those that actually occur during the operation of the business. As would be expected, planned business events are referred to as scenarios, while actual ones are referred to as business events. Although that may seem a small point, considerable confusion occurs when the same term is used in the planning sense and in the operational sense. Scenarios are grouped by “story,” and many scenarios can have the same story. Individual scenarios are differentiated by the context, or specific set of circumstances associated with the scenario. The context for each scenario in a story group must be different. As an example, several scenarios can have the story “a customer places an order.” Individual scenarios with that story have different contexts. For example, the context could be formed by attributes that indicate the customer’s size, credit rating, frequency of ordering, and size of order. Each unique set of values for those attributes would be a different context and hence a different scenario. Depending on the specific need, scenario story groups or individual scenarios could be used in the individual subcycles of the process life cycle.

8.2.1.2 Business structure This cycle contains assets related to the structure of the enterprise and includes process definitions as well as the specification of the organizational units and their responsibilities. Ideally, these assets should be contained in a comprehensive business model along with the enterprise view of other models of critical importance, such as a data model and network model as appropriate for the business. This business model could be used in a number of different ways, including comparison of the business to competitors, determination of the validity of software product requirements, and measurement of the internal efficiency of the business. Unfortunately, in most cases, a formal business model does not exist, or it is at such a high level that no real use can be derived from it. In that case, the necessary models still can be defined, but they may not be as tightly coupled as would be desirable. Process class model If a business model does not exist or does not contain a process class model, a process class model must be created. That is accomplished by defining the overall business operations process and then decomposing it into subprocesses. The decomposition continues until processes are obtained that can be implemented through manual and automated operations and deployed so that individuals can utilize them in performing their job assignments. Such a procedure is illustrated in Figure 8.2. The root process is decomposed into branch processes, which are then further decomposed as necessary until the leaf processes are reached. The leaf processes eventually are implemented and deployed. The root process and the branch processes are utilized only to arrive at the implementable leaf processes. The resultant structure defines part of the class model. The remaining part of the class model is determined by the relationships among the leaf processes.

Figure 8.2: Decomposition of the business process. The definition of the leaf processes that will best support the business is one of the two most important activities in a management-by-process approach. The other activity is implementation of those leaf processes. When all is said and done, specification and implementation of the leaf processes are the heart and soul of process engineering. With any decomposition procedure, there is always a question as to how many levels are needed and what the termination criteria should be. In the case of business processes, it is strictly an issue of management of complexity and resources. Process decomposition should continue until the leaf processes are of such a number and complexity that the enterprise feels comfortable about its ability to define each of the processes in detail. Another important question in process decomposition is the information that should be included in the initial definition of each process. At a minimum, the name; description; relevant business events, products, and services; business rules; and resources utilized should be included in this high-level model. For example, consider a leaf process defined to satisfy some maintenance business events. The process initially could be documented as shown in Table 8.1. Eventually, as detail is added in Chapters 13 and 15 and Part III, other models of the leaf process are specified and introduced during the appropriate discussions. Table 8.1: Example of Leaf Process Documentation Name

Maintenance Process

Description:

The purpose of the maintenance process is to keep the equipment in good operating order and to minimize the time a given piece of equipment is unavailable. The maintenance process must also provide for the timely repair and testing of

Table 8.1: Example of Leaf Process Documentation Name

Maintenance Process inoperable equipment.

Resources:

The maintenance process utilizes dedicated resources (people and facilities). It has a fixed yearly budget for all aspects.

Business rules:

The maintenance process is not responsible for repair in the aftermath of a disaster, such as a fire or flood. The maintenance process is responsible for initial setup and certification of new equipment. Except in emergencies, it cannot completely shut down another process or result in a significant increase in manufacturin g costs.

Business events:

Report of inoperable equipment Arrival of new equipment Time for equipment maintenance

Products and services delivered:

Equipment

Table 8.1: Example of Leaf Process Documentation Name

Maintenance Process repair New equipment certification Scheduled equipment maintenance

Organization charts The most often created model of an enterprise is not the process model but the organization chart. Almost every business with more than a few employees has one. An organization chart defines the partitions of the business (usually called organizations), the responsibilities (usually called functions) of the organizations, and the reporting relationships of the organizations. The organization chart is a static model that is suited to the hierarchical structures of the past. It cannot show how the enterprise organizations would respond to a business event. Usually, responses to business events generally were documented informally or through written practices or procedures. Usually, the process by which an event was handled was “just known.” For example, “First the order goes to the order department, then it goes to the engineering department, then it goes to the manufacturing department, and finally it goes to the shipping department.” Other departments may be involved for billing, purchasing, and so on, and their roles in responding to the order usually are defined in the same informal way. Those major partitions of an enterprise probably are not going to change significantly. Almost always, too much history and politics are involved. How, then, is the enterprise going to formally model its response to expected business events without eliminating the organization chart? The current and most obvious answer is to define each major partition as a process. The billing organization gives rise to the billing process, the shipping organization defines a shipping process, and so on. This type of partitioning occurs quite often, even if the enterprise pretends that it is entirely process based and defines and decomposes high-level processes in the manner presented in Figure 8.2. Decomposing those high-level processes seems to result in a one-to-one relationship between a leaf process and an organizational unit. The major problem with that one-to-one relationship is that an organization-based process may not be the most appropriate one to handle a set of expected business events. That is especially true for those events that need more than one organization to be involved in the response (the usual case). It is also possible, even with the best of intentions, to arrive at leaf processes that are inappropriate for the set of business events that must be serviced. That can result from inexperienced staff performing the decomposition or from lack of knowledge concerning the vision and the goals of the enterprise. What happens in that case is that the vertical automation silos (discussed in Chapter 1) resulting from the traditional organization- or function-based approach are replaced with horizontal silos based on an organization approach to process definition. The horizontal silos are, in essence, the vertical silos rotated 90 degrees. Figure 8.3 illustrates this rotation for the vertical silos of Figure 1.2. In either case, because of the lack of integration, the silos inhibit the development of the needed end-to-end processes. Fortunately, there is a relatively easy method of mitigating problems with leaf process definitions, regardless of how they occurred. That method is discussed in Part III.

Figure 8.3: Horizontal silos of automation. Business rules The general definition and structure for business rules were described in Chapter 5. Business rules as applied to processes are of particular interest in the context of the process life cycle. In that context, business rules are defined to be constraints on the enterprise processes or their relationships. Business rules can be defined that apply to all enterprise business processes, a set of processes, or only one process. Business rules can be defined at any level of process decomposition or specification, including implementation. Business rules can assume different forms and contain different information, depending on the level at which they are defined and the particular process(es) to which they are applied. Business rules also can be applied to different aspects of a process and its implementation, including the flow control of the process, the functionality required by the process, the data used in the process, and the assignment of human performers to the process. Process maps Once the leaf processes have been defined, considerable detail must be added to their specification to allow for their eventual implementation. A model that can accommodate that detail in a structured way and serve as a framework for the necessary analysis and testing must be defined. Because of the difficulty in working with the strictly text-based representation model utilized in the decomposition procedure, the new leaf process model is usually a combination of graphical, text, and data formats in a welldefined configuration. For simplicity, at the risk of introducing some confusion, this discussion of process representation and analysis utilizes the word process to mean a leaf process. Because only leaf processes are implemented, that should not cause undue confusion. Detail is added to the process specification in several ways throughout the implementation period, which starts with the availability of the leaf process(es) definitions and ends with product deployment and operation. Because the detail-adding activities are under control of the implementation methodology, most of this discussion is given as a part of the methodology presentation. Only enough of the procedures are covered to provide an understanding and motivation for the overall life cycle and its individual components. The detail that is added to the process specification during the business structure cycle is designed to accomplish two basic results: The first is to determine and specify, at a relatively high level, the functions, information flows, and skill definitions necessary to implement the process. The second is to determine if any of the automation assets have been previously defined so they can be reused. The structure and detail level of the process model must be such that reuse of any previously defined functions, information flows, and skill definitions is facilitated. There are guidelines for determining the proper size and complexity of those assets so that reuse is maximized. The guidelines are discussed during the methodology discussion. The ability to reuse assets specified at the process level can result in significant savings in implementation and deployment costs. One representation model that seems to allow processes to be detailed and examined effectively from the business perspective is the process map. The format of the graphical portion of a process map is shown in Figure 8.4. It consists of process steps arranged

according to their assigned roles and precedence order. If desired, organization information also can be included, although it is not strictly required.

Figure 8.4: Example of a process map. Process steps can be either functions or decisions. Process steps can occur in parallel, although the map usually tends to be highly sequential for two reasons: § Business function subject matter experts (SMEs), using explicit or implicit scenarios, tend to think in a sequential manner when determining the functions and decisions that can be utilized to realize a specific process. § The sequential format simplifies the use of the map in determining if the map assets can support the handling of associated business events as defined in appropriate scenario groups and individual scenarios. Although the process map realization has certain characteristics that are not an inherent property of the process it represents (e.g., very sequential functionality), those artifacts do not matter as long as the map is successful in showing that the scenarios are capable of being satisfied through the defined functionality. The representation artifacts can be removed later during the design/build activities. Roles are shown as horizontal segments on the process map. The purpose of roles is to define the skill sets necessary for performing a given part of an implemented process. The definition and utilization of roles are examined in Chapter 10. Optionally, organization units that contain those roles also may be incorporated in the same format as the roles. Incorporating organizations does provide an additional comfort level to many SMEs and their management, but it is not necessary and, indeed, may prove to be an unwanted distraction. The process map framework requires that additional information be specified for each process step, including the following: § A comprehensive description of the process step (function or decision) in addition to a descriptive name of some sort; § Specification of any particular approach or algorithm that must be used in an implementation; § The information needed by the process step; § The information produced by the process step; § Operational data as known (e.g., throughput, number of performers, physical locations). The additional specifications generally are documented in a separate text format so that the graphical map format does not become too cluttered. How the two formats are related and utilized is a tool implementation issue and is not discussed further at this time. The difference between information and data as specified in the process map is discussed in Chapter 11. Connections between process maps During the development of a given process map, the determination of the relationships that need to be established between its process steps and the process steps of other maps needs to be made. That usually is performed at two levels, depending on the amount of information available concerning other maps. Level 1 simply specifies that there is a relationship between a process step (input or output) and another process. The existence of a relationship should be communicated to the developers of the other map involved (if they are a different set of

individuals), but detailed coordination is not necessary at this level. The communication also should be made to any stakeholders (concerned individuals) of both maps. Level 2 requires identification of the specific process step in the related process map and the exact nature of the relation (e.g., precedence order of the two steps). This requires agreement from the developers of the related map who must reflect the same relationship in their map. Eventually, all process step relationships must be defined on a process step–to–process step basis, whether the two process steps are in the same map or in different maps. During the initial development of the process map, the scenarios that form the scenario group specific to that map (e.g., billing scenarios for a billing process) are used as an aid to ensure that the map can accommodate those scenarios effectively. Without the availability of the scenarios, it would be much more difficult to determine if the map assets were capable of providing the response to the business events that the process was defined to handle. After the basic map has been developed, scenarios that require multiple processes for resolution can be used as an aid in determining the needs for specific process relationships. Process relationships are further refined as multiple processes are tested together. Process understanding While the development of the process map is oriented toward arriving at a representation of the process that can serve as the basis for an implementation, there is another important consequence of the map specification activities. That consequence is the fostering of a much improved understanding (from what is usually available when a process is first defined) of the function and the purpose of the process as well as its projected use in the enterprise. Although it is an implicit byproduct of the map specification, this improved understanding probably has as much (if not more) impact on the final implementation of the process as the map structure itself. During the design/build cycle, it is relatively easy to find and correct any structural problems with the map (e.g., steps that should be decomposed or missing information flow). It generally is much harder to find and correct fundamental misunderstandings concerning the function and the use of the process in the enterprise (e.g., because of some natural affinity, parts of the process should be placed in other processes). Detection of such later types of problems is best accomplished during the development of the process map representation, hence the emphasis on process understanding during development of the map. Process prototypes Construction of the process map is extremely useful in producing a greater understanding of the use and the context of the process and determining the process requirements for function, information, and skills. However, to be useful as an implementation vehicle, the process map must be tested as rigorously as resources permit to determine if it is constructed in accordance with the definition and the purpose of the original process. The testing is accomplished by utilizing all the scenarios that in any fashion require the functionality of the process map under test. If possible, for scenarios requiring multiple processes, it is also desirable to test the process in the context of the other processes so that the connections between them also can be tested. That does not have to be done at the time of initial process map testing, but it does have to be performed at some time before the completion of the design/build cycle. Before testing starts, the process map is converted into a process prototype. If tool support is not available, that simply means that a wall-size copy of the process map is printed and declared to be the prototype. The process prototype engine in that case is human. (The author has been an engine of this sort many times and frankly enjoys the experience.) If tool support is available, the process map definition is made available to the tool that contains the process prototype engine. The specific mechanism used depends on the tool and the environment being used. The process prototype is one of a number of prototypes that are defined and used throughout the life cycle of the process. Each prototype is used to test a different aspect or level of a process representation. It is only through the prototypes that the detail

required for process implementation can be tested for compliance with the definition of the original process and its associated business events. Testing is initiated by selecting a scenario that is of critical importance. Using either a human or an automated prototype engine, the sequence of process steps that result from applying the conditions of the scenario to the process map is identified. There can be several possible outcomes from that activity. Some of those outcomes are outlined in the following list, along with an indication of the action that needs to be taken. In actual practice, there are many possible results and even more actions that can be taken, depending on the specifics of the problem and the process. § Result: A sequence of process steps occurs, ending with a normal termination point, that provides the desired outcome. Action: None required. The scenario test has been successful. § Result: A sequence of process steps occurs, ending with a normal termination point, that does not provide the desired outcome. Action: Change the process map so the desired outcome occurs. That may involve changing the definition of a process step, adding process steps, or changing the relationships between process steps. § Result: A sequence of process steps occurs, ending with an internal process step for which there is no reasonable successor. Action: Change the process map so the desired outcome occurs. That may involve changing the definition of the terminating process step or previous process steps, adding process steps, or changing the relationships between process steps. § Result: The scenario is not detailed enough to be able to identify the path that should be taken for at least one decision point. Action: Change the scenario so that the decision point is explicitly defined. This will also usually involve the creation of another scenario that will indicate that the opposite decision point should be taken. Once the scenario run is successful, the next most critical scenario is selected and the procedure repeated. That continues until several of the most important scenarios run successfully. The actual number of possible scenarios is extremely large, and only a fraction can be utilized in this procedure. The main purpose of the process prototype testing is not to test the process exhaustively (not a tractable activity) but only to obtain confidence that the process representation is reasonable. Achieving such confidence does not mean the process map will not change in the future (it undoubtedly will) due to many other possible factors. Successful runs of a number of critical scenarios at this stage of definition mean only that the process has been successfully represented in a form that can be communicated to all enterprise personnel who need a working knowledge of how the implemented process will function. That can be demonstrated through the use of the map and scenarios of interest. The scenarios used in the testing of the process map are saved and will be used again when other representations of the process are defined during the design/build and operate cycles of the process life cycle. By using the same scenarios, the reactions of the process representations can be compared. That greatly assists in the determination of the correctness of a representation. Additional scenarios can, of course, be added to the test suite at any time during the implementation. Regardless of how it is accomplished, the result of a scenario run against the process map is a process step sequence called a process scenario trace. Examples of scenario traces for the process map in Figure 8.4 are shown in Figures 8.5 and 8.6. Exactly how the sequence is identified, displayed, and documented is a function of the tool or human procedures utilized. The exact formats are not critical but need to be defined, with an efficient transfer of information as the main goal.

Figure 8.5: First example of process trace.

Figure 8.6: Second example of process trace. When it is successful, the process trace produced by the scenario becomes part of the definition of the scenario. (That is explained further in Chapter 9.) Process scenario traces can be used in a number of different ways in addition to the determination of the success or failure of the application of the scenario, including initial cost estimates, initial performance estimates, and initial resource estimates for handling the business event represented by the scenario. Statistics for a scenario group also can be obtained. The information may show a need to modify the process map if the statistics indicate an unfavorable result (e.g., too expensive for the expected return). 8.2.2 Design/build cycle The purpose of the design/build cycle is to translate the process map and associated information, as described in the plan cycle, into a product that can be deployed and used to handle business events. That involves changing the process representation format from that of the process map, which emphasizes the business needs of the process, to other formats that are more technically (implementation) oriented. The latter representations are intended to accommodate the detailed technical information necessary for eventual implementation in the enterprise environment. As initially specified in the process map, there is no guarantee that the process is implementable. Environment, technology, and financial constraints may not allow the process to be effectively implemented without changes to the process map or the original process specification. Implementation-oriented process representations, which are defined during the design/build cycle, can more effectively indicate when the process cannot be effectively implemented and determine how the process map or specification should be altered. Because the process map format looks similar to a process implementation (build) representation—a workflow diagram—there can be a great temptation to truncate or eliminate the design portion of the design/build cycle and implement the process map directly as a workflow. For the purpose of this immediate discussion, a workflow can be viewed as an implementation of a process that utilizes a set of tasks that are sequenced and scheduled by a manager programmed with the appropriate commands. (A more comprehensive treatment is presented in Chapters 15 and 24.) A workflow is typically depicted by a diagram showing tasks interconnected with arrows. Who wouldn’t want to skip the cost and time consumed in the design activity? Encouragement to perform the direct conversion from process map to implemented workflow comes not only from cost conscious management but also from tool vendors who claim that their products are capable of making the conversion effortless.

As tempting as it might appear, the direct conversion almost always fails for a number of reasons related to the fact that the process map is not a workflow diagram, although the two graphs appear similar superficially. § The process map format lacks information essential to designing a workflow (e.g., detailed functionality, data, and workforce descriptions). § The purpose of the process map format is to gain a business-oriented understanding of the process and the functions, information, and skills involved. It is not intended to be directly implemented. o The process steps are significantly more sequential than necessary. Implementing them this way will reduce efficiency considerably. o The process steps generally are at the wrong level for implementation as workflow services or tasks. o The process steps generally are at the wrong level to determine if human or automated implementation is appropriate. o The process steps generally are at the wrong level to achieve significant function (software) reuse. The activities defined for the design/build cycle are always necessary to achieve an effective process implementation. If they are not accomplished explicitly and efficiently as part of the cycle, they will be performed inefficiently as part of some other activity or cycle. To paraphrase a familiar saying, “The work that needs to be done is the work that needs to be done.”

8.2.2.1 Logical design The process map serves as a vehicle to capture, explore, analyze, and specify the needs of a process from a business point of view. To translate that information into a form more suited as the basis for eventual implementation, a more technically oriented representation of the process must be created and utilized. The initial representation is called the logical design. The logical design comprises different parts, each emphasizing a different aspect of the information needed by the implementors. It is not necessary for the purposes of this discussion to define the logical design in detail. That will be left to the methodology design chapters in Part III. In general, there is no deterministic way to convert from a process map representation of the process to a logical design representation. The logical design results from a true design effort. Design requires a knowledge of the relevant design principles, a detailed understanding of the methodology involved, an awareness of the specific requirements of the process, and experience developing logical designs. Although the development of the logical design requires knowledgeable human intelligence, a number of guidelines and rules of thumb can facilitate the process. The logical design representation uses a different model structure and is more detailed than the process map representation. Therefore, in many instances it is difficult to show an explicit relationship between process map elements and logical design elements. That can cause some concern to staff involved in the development who are familiar only with decomposition techniques for adding detail. With decomposition, there is always an explicit relationship between the elements at one level and the elements at a more detailed level. The lack of an explicit relationship also causes concern to management personnel who want to ensure that if a change is necessary to a logical design element it is also reflected in the process map. If that consistency is not maintained, the businessoriented staff and the technically oriented staff will not have similar views of the underlying process. That causes great difficulties for process-based enterprise management and must be avoided at all costs. However, the fact that there may be no explicit relationship between elements of the process map and those of the logical design does not mean that consistency between the two cannot be maintained. It does mean that some attention must be placed on maintaining referential integrity between elements of the two representations. Maintaining referential integrity, in general, requires the use of a repository and

associated tools. A repository is necessary for a number of other reasons, as explained in Chapter 4, so that is not an unreasonable requirement. In addition, management controls must be in place to require, if necessary, a reexamination and update of the relevant portions of a process map when the logical design with which it is associated changes. Of course, the same is true for a process map change. The logical design associated with the area of change also must be examined and modified as appropriate. It is possible for the process map to change without affecting the logical design and for the logical design to change without affecting the process map. Although such an occurrence does not appear likely, it does happen in practice because of the rather loose coupling between the two representations. It is that loose coupling that provides a number of significant advantages over the usual decomposition techniques. The logical design has five major purposes: 1. To incorporate information that is not available as part of the process map, for example, a user interface (UI) design; 2. To add additional detail to the information contained in the map, including further specification of the control, data, and functionality required; 3. To represent the process in a format that will provide a more efficient implementation than the process map format will permit; 4. To allow previously defined and implemented functionality to be reused in realizing the process, greatly increasing the implementation productivity; 5. To factor technical and financial influences into the implementations, which will affect the functions defined to be automated and those that will be accomplished by humans. As a process representation, the logical design must be tested through the use of the scenarios using a procedure similar to that described for testing process maps. Because the development of the logical design is not deterministic, that is the only way to ensure that the logical design is a valid representation of the process.

8.2.2.2 Physical design Once the logical design has been developed and tested, an implementable form of the design must be developed. That is generally referred to as the physical design. The physical design must accommodate the enterprise technical and business environment and specific computing architecture. In addition, the physical design also must be able to be directly transformed into an efficient and effective product resident in the enterprise computing environment. To provide for those two needs, the structure of the physical design representation of the process must be somewhat different from the structure of the logical design representation. That should not be surprising, given the discussion of the differences between the process map and the logical design representations. To maximize flexibility and reuse of existing functionality, the physical design architecture considered is based on workflow technology. The physical design architecture is considered in two parts: one that is process independent and one that is process dependent. The process-dependent part is known as a workflow, while the processindependent part consists of software components. A workflow implementation utilizes functionality units called tasks. A task consists of one or more reusable software components and provides a part of the functionality needed for completion of the application. An example for an invoicing application would be a function to determine tax amount. The individual tasks necessary to respond to a given business event are sequenced, scheduled, and then routed (assigned) to a specific task performer by a workflow manager or, alternatively, a workflow engine. The workflow engine uses data defined during the logical and physical design process to determine how to reach the desired response to an individual business event. Much of that information is contained in a workflow map, which is a representation of the business process. By changing the map

and other input data to the workflow engine, the response to a specific type of business event can be altered without necessarily changing the operation of any task. The workflow engine programming is designed to emulate the process. As in the case of the process map and logical design, the physical design also is a representation of the process. As such, the physical design must be tested by using the scenarios in a fashion similar to that described for process maps and the logical design. 8.2.3 Operate cycle The operational process implementation is the representation of the process that is used to respond to real-life business events. As a process representation, it also should be tested through the use of scenarios before being placed in an operational status, although a separate prototype obviously does not have to be defined on which to perform the tests. The implementation representation structure is based on the physical design representation discussed in Section 8.2.2.2. The implementation format must allow a great degree of flexibility. With that flexibility, process updates required by the changing business climate can be made quickly and accurately. In addition, of course, the implementation must be an accurate reflection of the intent of the process. The implementation consists of five major parts: tasks, workflow manager or engine, workflow definition, workflow instance, and operational statistics. When a business event occurs, a workflow instance is created. The purpose of the instance is to contain the status and instance-specific data that will be associated with the handling of that business event. Initially, the workflow instance contains little information. As the solution to the business event progresses, additional information is added. A workflow instance exists until the final response to the defining event is provided. At that time, the characterization of the workflow is complete and can be used for statistical purposes in the management of the process. The tasks necessary for a specific workflow instance are sequenced, scheduled, routed, and monitored by a workflow engine. That engine is a software product capable of interpreting workflow business rules that specify how the available tasks are to be utilized in responding to a particular business event. When a workflow instance requires a service or task to perform a function, an instance of that service or task is formed that is then associated with that workflow instance. In that way, all the work necessary to respond to a given business event can be connected with that particular business event, even if the same task functionality is needed for many different business events or multiple occurrences of the same business event. As part of its function, the workflow engine collects statistics on the defined metrics of the workflow instances, including the associated service or task instances. The statistics are used in the manage cycle to determine how effectively the process implementation is functioning and what, if any, changes should be considered. 8.2.4 Manage cycle Once the workflow (process implementation) has been deployed and becomes operational, it must be continuously examined and adjusted to ensure that the current workflow representation continues to represent the intent of the process properly. Statistical data produced by the workflow engine are analyzed along with information produced by other means, including customer comments or complaints, employee observations, operational expenses, and equipment costs. The analysis usually is performed by the same SMEs (or others with similar knowledge if the original individuals are not available) who helped formulate the various process representations during the first development cycle. If the analysis indicates that changes should be made, the proper subcycle is invoked and a determination as to how the

representation(s) of that subcycle should be altered to meet the new needs. The change process then proceeds in the same way as the original design effort. The management of an operational process implementation as part of a comprehensive implementation methodology is presented in Chapter 26, which discusses the analysis and other activities that ensure that the process remains effective.

8.3 Quality considerations Current industry-accepted approaches to ensuring that a quality product or service is delivered to the customer all revolve around a process-based paradigm. Because of past problems in trying to define quality (which is more or less an impossible task), the currently accepted approach is to examine the process that produces the product or service and determine if it is defined, consistent, and effective. Each of the three major approaches to making that determination utilizes somewhat different criteria and emphasizes different areas, but they probably have more similarities than differences. Although an indication of the role of process in current approaches to quality is appropriate to the scope of this discussion, a detailed examination of individual quality approaches would not add a great deal to the presentation. Comprehensive examinations of each of those approaches can be obtained through other publications (see the bibliography at the end of this chapter). Only those characteristics and definitions of the major process-oriented quality methods that are necessary to indicate how process is considered are listed. Table 8.2 contains brief descriptions of the three major approaches: ISO9000, Malcolm Baldridge, and the Software Maturity Model. The first two methods are intended to examine general enterprise processes, while the third is specifically intended for the software development process. Table 8.2: Major Process-Based Quality Approaches Approach

Purpose

Developer

Overall Structure

ISO9000

Certification

International Standards Organizatio n (ISO)

Relies on a series of detailed audits to determine if the processes utilized in a number of specified enterprise areas, including the production of products and services, are documente d; perform in the way the documenta tion indicates; are effectively monitored so that

Table 8.2: Major Process-Based Quality Approaches Approach

Purpose

Developer

Overall Structure problems are detected; and have a mechanism for change.

Malcolm Baldridge

Award

U.S. Department of Commerce

Similar to ISO9000 except that more emphasis is placed on the compariso n of different organizatio ns rather than compliance to a standardiz ed checklist. The compariso n emphasis is necessary to select the winners.

Software Maturity Model

Selfassessment

Software Engineering Institute

Utilizes a five-layer model that indicates how sophisticat ed the software developme nt process of an enterprise is. The layers are in the order of increasing maturity and are defined as follows. Layer 1, ad

Table 8.2: Major Process-Based Quality Approaches Approach

Purpose

Developer

Overall Structure

hoc; layer 2, repeatable; layer 3, defined; layer 4, managed; layer 5, continuous improveme nt. Will adherence to any of the approaches in Table 8.2 guarantee commercial success? Unfortunately, no. Can a successful quality product be produced without adhering to any of those methods? Fortunately, yes. The approaches assist the generation of a quality product; following them does not automatically generate a commercial success or even a quality product. Many other aspects of running a successful business and developing a product are required. However, the process-based quality approaches do provide a structure and evaluation framework that is helpful in examining the processes of the enterprise. That is probably their most useful purpose.

8.4 Management of expectations Changing from management by organization to management by process in an enterprise is not a panacea. By itself, such a change will produce little in the way of positive results and may instead be harmful to the enterprise. Unless there is total commitment to the change and a willingness to alter the basic fabric of the enterprise, a change of that magnitude should not be attempted. If the business remains organizationally bound and attempts to use a management-by-process paradigm, the result will be confusion and possibly chaos. Saying the right words will not work. They must be followed by the right actions. Even with the required commitment, change will be slow and sometimes painful. Staff will be in the wrong positions. The role and development of software must change dramatically. Organizational boundaries will begin to dissolve. Management’s focus will change from subordinate control to activity coordination. And all of that must happen without a significant disruption in providing service to the customers —quite a feat for any enterprise. The reason for all those cautions is to counteract the popular notions of what can be expected by a stated shift to management by process. Like any other major enterprise activity, there is no magic, only a lot of hard work. Having said all that, is the shift worthwhile? The answer is a resounding yes! Without a real shift to the management-byprocess paradigm, an enterprise will find itself at an increasing competitive disadvantage. The change must be made, but it must be made with an understanding of the difficulties that will be encountered and a willingness to solve the difficult problems as they occur. Selected bibliography Bickeboller, M., D. F. Kocaoglu, and T. R. Anderson, “Business Concepts Analysis Process,” Proc. Portland Internatl. Conf. Management and Technology, Portland, OR,July 27–31, 1997, pp. 803–806.

Bohrer, K., et al., “Business Process Components for Distributed Object Applications,” Communications of the ACM, Vol. 41, No. 6, 1998, pp. 43–48. Briccarello, P., G. Bruno, and E. Ronco, “REBUS: An Object-Oriented Simulator for Business Processes,” Proc. 28th Ann. Simulation Symp., Phoenix, Apr. 9–13, 1995, pp. 269–277. Chung, L., and B. A. Nixon, “Dealing With Non-Functional Requirements: Three Experimental Studies of a Process Oriented Approach,” Proc. 17th Internatl. Conf. Software Engineering, Seattle, Apr. 23–30, 1995, pp. 25–37. Cook, J. E., and A. L. Wolf, “Automating Process Discovery Through Event -Data Analysis,” Proc. 17th Internatl. Conf. Software Engineering, Seattle, Apr. 23–30, 1995, pp. 73–82. Dion, R., “Process Improvement and the Corporate Balance Sheet,” IEEE Software, Vol. 10, No. 4, July 1993, p. 28. Ferscha, A., “Optimistic Distributed Execution of Business Process Models,” Proc. 31st Hawaii Internatl. Conf. System Sciences, Wailea, HI, Jan. 6–9, 1998, pp. 723–732. Hedberg, S. R., “AI Tools for Business-Process Modeling,” IEEE Expert, Vol. 11,No. 4, pp. 13–15. Huyink, D. S., and C. Westover, ISO 9000: Motivating the People, Mastering the Process, Achieving Registration, Burr Ridge, IL: Irwin, 1994. Kirchmer, M., Business Process Oriented Implementation of Standard Software: How to Achieve Competitive Advantage Quickly and Efficiently, New York: Springer-Verlag, 1998. Mayer, J. H., “Avoiding a Fool’s Mission” Software Mag., Feb. 1998, pp. 43–48. Pennell, J., J. Stepper, and D. Petrozzo, “Concurrent Engineering of a Service Order Process,” Proc. 46th Ann. Quality Cong., Nashville, May 1992, pp. 634–641. Profozich, D., Managing Change With Business Process Simulation, Englewood Cliffs, NJ: Prentice-Hall, 1997. Sheer, A.-W., Business Process Engineering: Reference Models for Industrial Enterprises, 2nd ed., Berlin: Springer-Verlag, 1994. Sundstrom, G. A., “Business Process Modeling and Process Management: Concepts and Examples,” Proc. IEEE Internatl. Conf. Systems, Man, and Cybernetics, Oct. 12–15, 1997, pp. 227–231. Yu, E. S. K., and J. Mylopoulos, “Using Goals, Rules, and Methods to Support Reasoning in Business Process Reengineering,” Proc. 27th Hawaii Internatl. Conf. System Sciences, Wailea, HI, Jan. 4–7, 1994, pp. 234–243.

Chapter 9: Scenario modeling Overview Chapter 8 introduced the concept and major characteristics of a business event as a fundamental input to the enterprise. The utilization of scenarios to model an individual or related group of business events also was examined. The details of scenarios as

automation assets were not presented because the emphasis of Chapter 8 was on the concept of process life cycle. It is necessary to comprehend the genesis, definition, and application of the concept of scenarios as an important component in the overall understanding of the operation of the enterprise and its determination of automation support. As an integral part of this discussion, a detailed model of a scenario must be developed. The definition of and motivation for such a model are the focus of this chapter. Two types of scenarios are discussed. Although their models are similar, they differ in some important ways and must be discussed individually. In many cases, scenarios can be used informally without directly utilizing the structure provided by the models. In fact, such use is included in several chapters in this book when a more formal approach is not warranted. However, when scenarios are used in process implementation, experience has shown that the number of scenarios and the multiple times they are used require that the models be closely followed.

9.1 Business events Business events can be used for many purposes in operating and managing the enterprise, including the following: § To define the orientation and the scope of the enterprise; § To determine the amount of resources that would be needed to handle a new set of events; § To compare the enterprise with others in the industry; § To define the processes needed in the enterprise. For business events to be utilized effectively, they must be structured and modeled. Such models are called scenarios.

9.2 Scenarios Because a business event can exist independently of the structure of an enterprise as well as the process used to accommodate it, the same is true of a scenario. Scenarios can be used in a number of different areas in the enterprise, and it is important to define them as independent entities. Three aspects of scenarios need to be defined and discussed in some detail: § The structures of the two basic types of scenarios; § The relationships between scenarios; § The unique identification of a scenario. Those aspects are defined and discussed in the order listed. In addition, a brief discussion of the types of analysis that can be profitably performed on the defined scenarios also is provided. 9.2.1 Structure The structure of a scenario must enable all the relevant information that can be associated with a business event to be captured and utilized as needed. In addition, the structure must allow the scenarios to be managed as automation assets. Scenarios are classified as either unit or compound. A unit scenario is atomic in the sense that it cannot decompose into component scenarios. A compound scenario is a concatenation of other scenarios, simple or compound. Compound scenarios facilitate the construction of complex scenarios from simpler scenarios that cover a smaller scope. Examples of each type are provided later in the discussion.

9.2.1.1 Unit scenario The overall structure of a unit scenario consists of six major sections, as shown in Figure 9.1. Most of the sections are divided into subsections that contain additional detail about

the business event being modeled. The scenario identification method presented later depends on the scenario structure and relationships. Thus, the scenario structure is presented first, and the method of uniquely identifying each scenario is discussed later. As an aid to understanding, a continuing example is used throughout the discussion to illustrate the concepts involved.

Figure 9.1: Construction of a unit scenario. Story se ction In common usage, a story usually is thought of as an explanation or a representation of the circumstances involved in some event(s) of interest. The purpose may be to entertain, educate, or arouse some emotion. In any event, the story is intended to give life and meaning to the event(s) it represents. The purpose of the story section is exactly the same as that of the classical story. It provides an explanation of the specific circumstances surrounding the business event so that the event can be considered and utilized by the enterprise. The story section consists of three subsections, which are always the same for a given story: name, narrative, and attribute. The name briefly identifies the purpose of the scenario. As will become clearer during the discussion, many scenarios may utilize the same story; therefore, the contents of the subsections of the story are not unique. The means to uniquely identify a scenario is accomplished by the inclusion of an explicit ID section in the structure. The structure of the ID is considered later. The continuing example used here as an illustration is that of a customer placing an order by telephone. The name for a scenario with that purpose could then be defined as “Customer Places Telephone Order.” The narrative subsection is an elaboration of the scenario’s purpose and contains more detailed information than can be conveyed by the name alone. All scenarios with the same name contain the same narrative. A narrative for a telephone order scenario might be as follows: A customer places a telephone order by calling a specified number. The call is answered by a service representative, who asks a series of questions designed to obtain the information needed to satisfy the request in a timely and efficient manner. If the order is accepted, the customer is given an order number and the order is placed in an active status. The attribute subsection describes the relevant variables in the story. In some market testing, a movie may have multiple endings. The version that is finally released depends on how the test audience reacted to each ending. Whether that is a good technique is irrelevant to this discussion. The important aspect is that the same story can be given a completely different ending (or beginning or middle) by changing some of the variables of the story: The car crashes or it doesn’t crash. An individual’s disease is cured or it isn’t.

The daughter inherits nothing, or $10,000, or $10,000,000. The variables of the story are subject to manipulation by the filmmaker. In a movie or a book, only one set of possibilities is usually desired. That need for uniqueness is not carried over to the use of scenarios. Because a given scenario story will be utilized many times, the circumstances surrounding each occurrence may be different, and it is necessary to understand what variability is possible so that proper responses can be determined. The attribute specification subsection contains information as to how the circumstances can vary in a given story. It does that by explicitly identifying attributes associated with the story and the values that those attributes can assume. Using the telephone order example, the attribute subsection might be as shown in Table 9.1. Table 9.1: Example of Attribute Subsection Attribute

Values

Customer credit rating

High, medium , low

Usual order size of customer

Small, medium , large

Language spoken by customer

English, French, other

Geographical location of customer

U.S., Canada , Asia, Europe, other

Celebrity status of customer

Is one, is not one

An infinite number of attributes probably could be defined for any story. There will be some attributes for which different values are not important, while the values of others are of considerable interest. For example, the credit rating of a potential customer usually is of great interest to an enterprise. Different actions probably would be taken in response to a telephone order event, depending on the value of the credit attribute: The order would be accepted; the order would be denied; or the order would be kept below a predefined dollar limit. In contrast, most companies do not care about the celebrity status of a customer placing an order, so that attribute need not be explicitly identified since it is not relevant to this particular story. If celebrity status is of interest for some reason (e.g., the company is a Hollywood clothing store that caters to movie and TV stars), then it must be explicitly considered. The exercise of determining the attributes of interest is of considerable value in understanding the scenario story and how the enterprise intends to respond to it. The definition of a process to handle the scenario story is considerably easier if the identification of relevant attributes is accomplished with some care. The same attribute could be used in scenarios with different stories. To maintain the necessary consistency across the different stories, it is necessary to define and maintain a global attribute data model. Using that model along with the set of attributes and values used in the different stories, conflicts, overlaps, and gaps in the attributes can be identified. For example, if the attribute credit rating in one story is given the values “high, medium, and low” while in another story it is given the values “good and bad,” there

could be some difficulties if the two stories are required to work together in some fashion. The attribute data model helps avoid that situation a priori, but if, for some reason, it does occur, it can be detected and corrected. Maintaining and using a global sequence of all attributes as part of the data model would help with the definition of compound scenarios as well as scenario analysis because it would allow the same relative attribute sequence to be used in all stories. Because of the large number of possible attributes and their potential volatility, that activity probably is not practical. However, it might be possible for a given analysis to recast the attributes of the stories of interest into a common sequence to facilitate the examination. Context section Scenarios with the same story are differentiated by information contained in the context section. The context section identifies the unique circumstances that can influence the way a request is satisfied. In effect, different contexts result in different versions of the same basic story. Scenarios with the same story that have different contexts are different scenarios, although they are closely related. The context section defines a specific value for each attribute in the attribute subsection. Different attribute values result in different scenarios. Using the telephone order example, one context might be as shown in Table 9.2. Table 9.2: First Example of Context Section Attribute

Values

Customer credit rating

Low

Usual order size of customer

Large

Language spoken by customer

French

Geographical location of customer

Not of interest

Celebrity status of customer

Not of interest Creating a different context involves giving a different value to at least one of the attributes. For example, it the geographical location of the customer becomes of interest in a different scenario, its context would be that shown in Table 9.3. Table 9.3: Second Example of Context Section Attribute

Values

Customer credit rating

Low

Usual order size of customer

Large

Language spoken by customer

French

Geographical location of customer

Asia

Celebrity status of customer

Not of interest A different scenario could have all the attribute values changed as illustrated in Table 9.4. Table 9.4: Third Example of Context Section Attribute

Values

Customer credit rating

High

Usual order size of customer

Medium

Language spoken by customer

English

Geographical location of customer

U.S.

Table 9.4: Third Example of Context Section Attribute

Values

Celebrity status of customer

Movie star

Although the name, narrative, and attribute set are the same, each context results in a different story version because the circumstances differ. It should be evident that many individual scenarios can be considered for each scenario story. The level of detail that needs to be present depends on the attributes the enterprise considers important and wants to consider when formulating a response to the business event. Changes to the attribute set for a given story can always be made if experience dictates changes. The number of scenarios also depends on the values of attributes that preclude the need to consider other attributes. Business rule section The business rule section contains (usually by reference) the business rules that have some effect on how the business event is addressed. Some business rules for the telephone order example might be as follows: § The minimum order is $1,000. § No customer can owe more than $100,000 at any given time. § Certain products cannot be shipped to foreign countries. § Large customers have a specifically assigned service representative. § Orders are accepted in only English, French, and German. Those business rules may affect other scenario types, such as those concerned with customer service, shipping, and accounting. View section Each business event must be addressed by some set of activities of the enterprise. The view of the event as seen by the enterprise structures provided to accommodate the event is depicted in the view section. The enterprise structures can be at different levels of abstraction, and there is no specific limit to the number that can be considered. The three enterprise structures usually needed are the process utilized in addressing the event, the logical specification of the automation system functionality used in the implementation of the process, and finally the workflow that controls the overall implementation of the process. Other view subsections, such as the human interface, can be added to produce additional detail. Another example could be an organizational view that indicated the departments involved in resolving the event. From a strict definition perspective, the view section is not needed to fully model a business event. The information depends on the interpretation provided by a given enterprise. However, it is useful in giving an understanding as to how the event will be addressed by the enterprise. Characteristics section The characteristics section contains infor- mation about the business event that is not process or organization oriented. It provides detail as to the relative frequency of occurrence of the business event, the importance or priority of the event, and any information as to the timeliness of resolving the event. Because many events compete for the same enterprise resources, the information in the characteristics section is useful in determining how the resources should be deployed if some type of rationing must be utilized. Three of the useful pieces of information are shown in the model here (others can be added as desired). For the example, this information might contain the following information: § Each day, 10,000 instances of these scenarios occur. § The importance of handling the scenarios correctly is very high. § The representatives involved with the scenarios must be highly trained. Comments section Unstructured comments that provide information relative to the scenario are placed in the comments section. An example of the information that might be useful is some type of history or change record of the scenario, for example:

This scenario was added in 1995 because it was decided to classify customers by the dollar amount of orders placed each year. This was a new classification and an associated attribute was needed to consider it. The values of that attribute had to be reflected in a set of scenarios (this being one) to ensure that the different classifications were being handled according to company policy.

9.2.1.2 Compound scenario A compound scenario models a business event that requires a wide scope with multiple types of activities to provide a suitable resolution. One important class of this type of scenario is a customer request and the subsequent satisfaction of that request. Unit scenarios generally address only scopes with a single type of activity. In the continuing example, the business event of entering an order was modeled by a unit scenario. Assume that the business event being modeled was defined to be the resolution of a customer telephone order. The resolution would not include only entering the order (the continuing example) but also filling the order from inventory, shipping the order, billing the order, and payment for the order. It also could include a survey of customer satisfaction. As defined earlier, each of those separate activities could be considered the result of an internal business event, and the overall effect of all of them, acting at an appropriate time, would be the same as the single “order resolution” business event. The overall structure of a compound scenario is shown in Figure 9.2. In addition to a unique identifier, the compound scenario also has six major sections, all but one of which contain the same type of information as those found in the unit scenario structure. In a compound scenario, a component section replaces the view section of the unit scenario. The reasons for that difference, as well as some differences in the orientation of the other compound scenario sections, are discussed as each section is examined in detail.

Figure 9.2: Construction of a compound scenario. Story section The story section in the compound scenario has the same purpose as the story section in the unit scenario, contains the same three subsections, and describes the business event that is to be modeled. The major difference is that in the compound scenario the story section describes a business event whose state change spans one or more state changes from simpler business event definitions. The narrative may be somewhat more complex than that found in a unit scenario. The attributes utilized are not independently specified but are derived from the scenarios that make up the compound scenario. The compound scenario example addressing the resolution of a customer telephone order is used as an illustration. The name for this scenario could then be defined as “Resolution of a Customer Telephone Order.” The narrative subsection might then be as follows:

A customer places a telephone order by calling a specified number. The call is answered by a service representative, who asks a series of questions designed to obtain the information needed to satisfy the request in a timely and efficient manner. If the order is accepted, the customer is given an order number and the order is placed in an active status. When resources are available, the order is assembled from inventory and shipped, and at the next billing cycle a bill is sent to the customer. Payment for the order is credited to the customer’s account and satisfaction with the order is determined. If the order is not satisfactory, any necessary corrections are made. The attribute subsection contains the union of all attributes from each component scenario. The order of the attributes in the compound scenario is arbitrary and can differ from that of one or all of the component scenarios. However, if a global order has been defined for all attributes, that is the one that would be used to order the set of the compound scenario. An advantage to the global order is that the order would also agree with the attribute order of all the components and make analysis somewhat easier. Context section As in the case of unit scenarios, all compound scenarios with a common story have the same name, narrative, and attribute specifications. Scenarios with the same story are differentiated by information contained in the context section in the same way unit scenarios with the same story are differentiated. The compound scenario context must be compatible with the contexts of each component scenario in the sense that any attribute value in a component context is the same as the attribute value of the compound scenario. One of the checks that must be performed in the definition of a compound scenario is that an attribute used in one or more component scenarios must have the same value in all the component scenarios. The “not used” value can be considered to have any other defined value (it is equivalent to a “don’t care” value) for the sake of this discussion. If the attribute values differ, the component scenario is impossible and cannot be defined. For example, if the credit rating of a customer in one of the component scenarios is “high” and in another scenario it is “low,” then there is a fundamental conflict. One of the scenarios would have to be replaced with another that contains the same value of the attribute in question (e.g., both with a “high” value or both with a “low” value). If the credit rating in one component scenario is “high” and in the other scenario it is “not used,” then the “not used” value could be considered to be “high” and the two scenarios would be compatible. Business rule section The business rule section, as in the case of the unit scenario, contains (usually by reference) the business rules that have some effect on how the business event is addressed. In the case of the compound scenario, however, the business rules usually have an effect over the entire scope of the scenario. In the example, some possible business rules could be as follows: § The resolution of an order should be completed in 2 months. § If the resolution for an order takes over 6 months, the vice president of marketing shall perform an investigation. § The customer shall be notified every 2 weeks during the resolution period as to the status of the order. The business rules in this section are in addition to any business rules that have been specified as part of the individual component scenarios. In addition, the business rules for the component scenarios and the compound scenario should be checked for consistency in the same way that the attribute values were checked. Conflicts and other problems need to be corrected or substitute component scenarios used before the compound scenario is usable. Component section The component section consists of the less complex scenarios that form the compound scenario. These less complex scenarios, in the sense that their scope encompasses fewer activities than the scenario of interest, may be either unit scenarios or other compound scenarios. From a practical standpoint, it is usually wise to limit the definition of a compound scenario to one that contains only unit scenarios. That helps limit the complexity of the overall scenario structure. Unfortunately, any enterprise

of reasonable size will have a relatively complex scenario structure because of the large number of scenarios needed and the diverse set of information that each contains. There is no need to have a view section because the compound scenario view is formed from the individual views of its components. For example, assume that the two unit scenarios “Enter Telephone Order” and “Fill Order” are used to form the compound scenario “Fill Order.” Further, let us assume that the view sections of the unit scenarios contain a process view. Then, as illustrated in Figure 9.3, the process views of the two unit component scenarios form the compound scenario process view by concatenating the processes. The order of concatenation usually is taken to be the order of the component scenarios as contained in the component section of the compound scenario.

Figure 9.3: Construction of compound scenario view. In general, the component views can be concatenated only in a linear construction. If a more complex relationship is required, such as looping between processes or interaction between internal steps the processes, the compound scenario is not the proper vehicle on which to define the relationship. Characteristics section As in a unit scenario, the characteristics section contains information about the business event that is not process or organization oriented. The parts of this section are essentially the same as those for a unit scenario. The characteristics section is needed because the compound scenario might have characteristics that are different from any of its components. For example, the frequency of the scenario could be low, while the frequency of its components could be high because they are utilized as parts of multiple compound scenarios. Comments section Again, as in the definition of the unit scenario, unstructured comments that provide information relative to the scenario can be placed in this section.

9.2.2 Relationships As is evident from the previous discussion, scenarios can be thought of as being related in one of two ways: (1) by a common story or (2) as components of the same compound scenario. Of course, one scenario can be a component of multiple compound scenarios, resulting in some rather complex relationships. That type of relationship also includes the relationship of a component with the compound scenario to which it belongs. Those relationships are exploited throughout the remainder of the book. Although scenarios with different stories can have some of the same attributes and values, if they are not used together in a compound scenario, they are not related in the sense of this discussion. The existence of common attributes is considered to be too weak for an explicit relationship to be defined. Some types of analysis might need to determine all the stories that contain a specific attribute. That is certainly a reasonable activity, but the result, except for the purposes of the specific analysis undertaken, is not considered a relationship. That seemingly esoteric distinction needs to be made because scenarios are uniquely identified and classified using the scenario relationships that have been defined. When a large number of scenarios have been defined and are in use, the classification method becomes important in analyzing the scenarios and determining whether gaps, overlaps, inconsistencies, or conflicts exist or will be created by adding, removing, or changing scenarios. 9.2.3 Identifiers Although a completely arbitrary scenario identification scheme could be utilized, one that is derived in some fashion from the information contained in the scenario usually is easier to use and understand. Undoubtedly many such schemes could be defined. The one offered in this section seems to provide some useful characteristics (e.g., explicitly indicating the relationships defined for the scenarios) while minimizing the complexity of determining and utilizing the resultant ID. In many situations, the scenario ID serves as shorthand for the scenario itself. Because of this type of usage, the justification and definition of an identification scheme for scenarios are addressed in the following sections.

9.2.3.1 Unit scenarios Assume that a story contains the “Telephone Order” attribute subsection shown in Table 9.1. The ID for any scenario with this story is determined by a double ordering technique. The order number of the value for each attribute is placed in the same order as the attributes and preceded by the story ID. The syntax of the story ID is not important and is left to the enterprise to define, based on their individual needs. Any reasonable definition for the story ID will work. The “not used” attribute value is always given order number 0. The result of this construct is the ID for the scenario. IDs formed by using this technique are illustrated by using the contexts in Tables 9.2 through 9.4 and are presented in Tables 9.5 through 9.7. It should be noted that the IDs for all scenarios with the same story have the same size. Scenarios with different stories may have different ID sizes. Table 9.5: First Example of Context Section Attribute

Values

Customer credit rating

Low

Usual order size of customer

Large

Language spoken by customer

French

ID

Table 9.5: First Example of Context Section Attribute

Values

Geographical location of customer

Not of interest

Celebrity status of customer

Not of interest

ID

Story ID,3,3,2 ,0,0 Table 9.6: Second Example of Context Section Attribute

Values

Customer credit rating

Low

Usual order size of customer

Large

Language spoken by customer

French

Geographical location of customer

Asi

Celebrity status of customer

Not of interest

ID

Story ID,3,3,2 ,3,0 Table 9.7: Third Example of Context Section Attribute

Values

Customer credit rating

High

Usual order size of customer

Medium

Language spoken by customer

English

Geographical location of customer

U.S.

Celebrity status of customer

Movie star

ID

Story ID,1,2,1 ,1,1 Although the IDs of different scenarios with the same story can be analyzed through differential techniques to determine some of the characteristics of the set of scenarios, the story attribute subsection must be used to fully determine the meaning of an individual ID. From the scenario ID itself, it is impossible to know what the attribute and value a specific number in the ID represents. Although other ID schemes utilizing the given scenario structure certainly are possible to define, the utilization of this method is based on three major considerations: § It is efficient in representation size. § It is oriented toward comparing and analyzing scenarios with the same story. § Patterns can be observed by either human or machine intelligence.

Experience has shown that most interest and activity occur for scenarios containing a given story. This is because the set of scenarios with the same story indicates how the process will respond to different contexts, which is important in process design and analysis. That observation is true for both unit and compound scenarios. With some knowledge of the underlying story, humans can effectively differentiate and use different scenarios simply by examining the ID. The ID structure also lends itself to machine analysis. Those considerations carry over to the IDs defined for compound scenarios.

9.2.3.2 Compound scenarios Most of the story and context sections of a compound scenario are derived from the corresponding sections of the scenarios incorporated in the components section. Likewise, the ID of a compound scenario is based on the IDs of the component scenarios. Although some of the constructs needed to arrive at those results may seem complex, in reality they are only a simple extension of the concepts discussed for unit scenarios. The discussion here proceeds step by step through the procedure. It assumes that a global attribute order has not been developed but that a correct and comprehensive attribute data model has been defined. The discussion is based on a common example. The example is relatively abstract so the various nuances of the procedure can be easily illustrated. Table 9.8 contains a representation of the attribute subsection for three different scenario stories that are used as components of a compound scenario. The order of the scenarios is the order given in the table. The values for each attribute are represented by the name of the attribute and a number that indicates its position in the attribute definition. That would be one of the relationships specified by the attribute data model. For purposes of illustration, some of the stories contain different numbers of attributes and attribute values. For example, story S1 contains four attributes, while story S2 contains five attributes. Table 9.8: Component Scenario Attribute Subsections Story

Attribute

Values

S1

A B C D

A0, A1, A2, A3 B0, B1, B2, B3 C0, C1, C2 D0, D1, D2, D3, D4

S2

E F C D G

E0 , E1, E2 F0, F1, F2, F3 C0, C1, C2 D0, D1, D2, D3, D4 G0, G1, G2, G3

Table 9.8: Component Scenario Attribute Subsections Story

Attribute

Values

S3

E H J D

E0 , E1, E2 H0, H1, H2, H3 J0, J1, J2, J3 D0, D1, D2, D3, D4

In several instances, the same attribute is contained in multiple stories. In that case, the value set of the attribute must be the same, although that does not imply that all the values are utilized in any of the scenarios of a given story. Examples of such multiple use are as follows: Attribute C is contained in stories S1 and S2, and attribute D is contained in all three stories. As required, all attributes have at least three values, including the 0 value, which indicates a “not used” or “not needed” condition. The attribute set of the compound scenario is formed by the union of the attributes of the component stories, as illustrated in Table 9.9. The order of the compound attribute set can differ from that of any of the components and is somewhat arbitrary, although the general considerations of unit scenario attribute ordering, discussed previously, does apply. In the specific case shown in Table 9.9, the order of the attributes of story S2 is utilized. Table 9.9: Compound Scenario Attribute Subsection Attribute

Values

E

E0, E1, E2

F C D G A B H J

F0, F1, F2, F3 C0, C1, C2 D0, D1, D2, D3, D4 G0, G1, G2, G3 A0, A1, A2, A3 B0, B1, B2, B3 H0, H1, H2, H3

J0, J1, J2, J3 The next step is to utilize the context for each component scenario to form the context for the compound scenario. That is illustrated in Table 9.10. Note that the values of the attributes used in multiple scenarios are the same for each scenario. Each specific

attribute value is contained in the context section of the compound scenario C1 in the same order as previously defined for the compound scenario attributes. The ID for each component scenario is also shown in Table 9.10. The IDs are derived using the same approach as that defined previously. The attribute portion of the ID of the compound scenario is determined exactly the same was as was specified for the unit scenarios. The compound scenario story ID is formed by concatenating the story IDs for each component. The resultant ID for the compound scenario is also presented in Table 9.10. Table 9.10: Compound Scenario ID Derived From Component IDs Story

Attribute

Values

IDs

S1

A B C D

A1 B0 C2 D3

S1ID,1,0,2,3

S2

E F C D G

E2 F1 C2 D3, G1

S2ID,2,1,2,3,1

S3

E H J D

E2 H3 J0 D0

S3ID,2,3,0,0

Compound

E F C D G A B H J

E2 F1 C2 D3 G1 A1 B0 H1 J3

S1ID,S2ID,S3ID,2,1,2,3,1,1,0,1,3

9.3 Analysis The effective development and utilization of scenarios in support of a business event or group of business events depend on the enterprise’s ability to analyze the set of scenarios as to their completeness and correctness. It must be possible to determine gaps, overlaps, conflicts, and information accuracy of the scenarios so that needed corrections can be identified and made. Needed changes to the scenarios also are identified as they are employed in various uses throughout the enterprise. This source of information is complementary to the type of analysis discussed in this section. Both sources are needed for a useful set of scenarios to be initially specified and maintained. While the number of different analyses that can be defined and performed is large, the following examples illustrate the motivation for and the type of information that can be obtained. Assume that a set of unit scenarios is to be developed with the same story. Once an initial set of scenarios has been developed based on business needs as determined by the individuals involved in handling the associated business events, the result needs to be examined for completeness and accuracy. The set of all attributes may not be complete when considered as a whole. Needed values for individual attributes may be

missing. The set of scenario contexts may lack one or more contexts that are significant in some sense. All the previous analyses are concerned with the examination of the entire set of scenarios and their components. Only by analyzing the set of scenarios as a whole can judgments be made concerning the suitability of the results. Assume that a set of compound scenarios with the same story is to be developed from the scenarios available for the component stories. Before beginning the construction process, it would be useful to examine the component stories for the following: § For each value of each attribute, determination of the component scenarios that contain them as part of the context; § Determination as to which attributes are not used in all stories; § Determination of all scenario sequences that could be used to create a valid scenario for the compound story; § Identification of the context for each possible compound scenario. Once that information is available, it can be determined if the set of possible compound scenarios is sufficient for the intended purpose or if changes and additions must be made to the set of scenarios for one or more of the component stories. It is assumed that analyses of this type will utilize a repository of the type discussed in Chapter 5. Because scenarios are defined to be automation assets, all the asset management functions defined also apply to scenarios. Selected bibliography Anton, A. I., W. M. McCracken, and C. Potts, “Goal Decomposition and Scenario Analysis in Business Process Reengineering,” Proc. 6th Conf. Advanced Information Systems Engineering, Utrecht, The Netherlands, 1994, pp. 94–104.

Carroll, J. M. (ed.), Scenario-Based Design: Envisioning Work and Technology in System Development, New York: John Wiley & Sons, 1995. Chin, G., Jr., M. B. Rosson, and J. M. Carroll, “Participatory Analysis: Shared Development of Requirements From Scenarios,” Proc. Conf. Human Factors in Computing Systems, Atlanta, Mar. 22–27, 1997, pp. 162–169. Desharnais, J., et al., “Integration of Sequential Scenarios,” IEEE Trans. Software Engineering, Vol. 24, No. 9, 1998, pp. 695–708. Hsia, P., et al., “Formal Approach to Scenario Analysis,” IEEE Software, Vol. 11, No. 2, 1994, pp. 33–41. Jacobson, I., et al., Object-Oriented Software Engineering: A Use Case Driven Approach, Reading, MA: Addison-Wesley, 1992. Kaindl, H., “An Integration of Scenarios With Their Purposes in Task Modeling,” Proc. Conf. Designing Interactive Systems: Processes, Practices, Methods, & Techniques, 1995, pp. 227–235. Lam, W., “Scenario Reuse: A Technique for Complementing Scenario-Based Requirements Engineering Approaches,” Proc. Internatl. Computer Science Conf., Dec. 2–5, 1997, pp. 332– 341. Potts, C., “Using Schematic Scenarios to Understand User Needs,” Proc. Conf. Designing Interactive Systems: Processes, Practices, Methods, & Techniques, 1995, pp. 247–256.

Weidenhaupt, K., et al., “Scenarios in System Development: Current Practice,” IEEE Software, Vol. 15, No. 2, 1998, pp. 34–45.

Chapter 10: Role modeling Overview The concept of roles is utilized, either explicitly or implicitly, in various areas related to the specification of enterprise automation needs. Unfortunately, there is no general agreement as to the definition or characteristics of a role. That ambiguity results in considerable confusion as to how to specify and use roles effectively, especially in the development of process maps. The purpose of this chapter is to present a comprehensive discussion of roles and their use in the enterprise. Because of the close identification of the term role with stage plays and movies, the tendency is to transfer that association to the understanding of roles in the enterprise. While the analogy is close, there are some subtle differences that, if not recognized and accounted for, can greatly confuse the concept and hinder the acceptance of roles as a useful entity. For that reason, all the terms used here are carefully motivated and defined. That allows deviation, as needed, from the popular notion of the term. In addition, questions that arise from the current confusion in using roles (e.g., is “customer” a role?) are addressed and answered. Roles are automation assets, and as such all the concepts developed in Part I apply. This chapter explicitly addresses many of those considerations. However, even if a specific aspect is not explicitly addressed in this discussion, it still is important in a design and development situation to explicitly consider all the management system functions.

10.1 Basic definitions Because a role must exist in an environment that utilizes other ambiguous terms, it is necessary to define a number of those terms for an understanding of the overall environment involved. Because there is a close analogy to the stage and movies, examples are used that exploit that association as long as the analogy does not become unduly strained. To successfully make that connection, it is necessary to define some stage and movie terms in addition to those needed for enterprise auto- mation. The relationships between the terms are described after the definitions. 10.1.1 Role Appropriately, the first definition is that of role: A role is an unordered set of cohesive activities. By that definition, a role is passive. It is defined by the collection activities assigned to it. How those activities are defined and assigned becomes the crucial element in role definition. Most of the confusion in the specification and use of roles occurs because the set of activities involved is not well understood. That problem, as well as a partial solution, will become clearer as the discussion proceeds. The word cohesive is intended to indicate that the activities defining a role must have some discernible relationship. The relationship can take many forms, but it must be able to be explicitly identified. If there are activities assigned to a role for which the cohesive property does not apply, those activities should be considered to be part of another role. The activities that form a role are not in any predefined order. Order implies process, and roles are independent of process. The same activity can be incorporated into multiple roles. That, unfortunately, permits a greater degree of freedom in the specification of roles than would be desirable. However, making the roles completely and mutually exclusive in terms of their defined activities would result in an artificial model for a real enterprise. Careful specification of the set of enterprise roles can minimize the inherent confusion of overlapping activities. The specification of a set of roles for the enterprise is investigated in more detail later in the discussion.

As entities, roles can have attributes, and the values of those attributes determine the type of the role and its characteristics. Several types of roles are considered and discussed in detail. 10.1.2 Activity For the purposes of this discussion, the term activity generally is considered in its commonly accepted usage. However, the formal definition also must consider the purpose of the activity in relation to the enterprise: An activity is any work the primary purpose of which is to change the state of the enterprise. Note that there is no indication as to the characteristics of the work or how it is performed. That allows the definition of many types of roles. Work that is not primarily intended to change the state of the enterprise in some manner is considered to be outside the scope of the enterprise, and the associated activity cannot be used as part of a defined role. As one interesting result of that definition, we can answer the question of whether customer is an enterprise role. Unfortunately, as might be expected, the answer is maybe! If the customer’s work efforts are not primarily intended to change the state of the enterprise, even though eventually the result will be used in some fashion by the enterprise, the customer is not performing an activity from the perspective of the enterprise. Because the customer is not performing an activity, there is no customer role. If, however, the customer is interacting with enterprise resources in a way that is intended to directly change the state of the enterprise, then the customer is performing an enterprise activity and, hence, an enterprise role. The role may be that of customer, or it may be another defined enterprise role with a performer of “customer,” as discussed in Section 10.1.3. The discussion concerning the role of customer extends to any other prospective role that is to be filled by individuals who are not employees of the enterprise. That would include suppliers, consultants, government regulators, and service providers of various types. The determination depends on the degree of planned interaction with enterprise personnel in the fulfillment of an enterprise process. 10.1.3 Performer Because role is defined to be passive, there must be some mechanism for the animation of a role. In this case, animation means causing the activities defining a role to occur. The mechanism for animation is through the use of a role performer. A role performer (or performer for short) is some entity that animates a role by causing one or more of the activities that define the role to be accomplished. When a role is animated by a performer, an instance of the role is said to have been created. A role is passive, but a role instance is dynamic. Depending on the number of performers capable of performing the role, there may be many instances of the role in existence at any given time. Although a performer animates a role by performing some role activities, common usage is to say that the performer performs (or “acts out,” in stage terminology) the role. Since it engenders no confusion, that terminology is used because continued reference to “animating a role” would be somewhat awkward. A performer can be human or it can be a machine. The main concept is that the performer is separate from the role. A performer may perform multiple roles, although usually not at the same time. However, a role may be performed by many performers simultaneously Multiple types of roles can be defined. The type of role determines the needed characteristics of the role performer. The reverse is not true. The performer does not change the role (i.e., the activities to be performed). However, specific performers may, if allowed by the control mechanism, perform the role in different ways (e.g., the sequence of activities).

10.1.4 Control Control of which role activities a performer is to perform is achieved through one of two entities. In a play or a movie, the mechanism is a script. The script defines which roles are needed and tells the performer of each role what lines to say when, in what manner to say them, and how to behave as they are being said. In the enterprise environment, the control mechanism is a process specification. The process defines which roles are needed and guides the performer of each role as to how, when, and in what manner to perform the defined activities of the role. In that sense, a process can be considered to be an activity script. There is a difference between a script and a process that needs to be understood so there is no confusion in the utilization of the analogy. A script contains the instructions that enable performers to elucidate a story by animating the roles. Only one context (set of story attributes) is utilized. A process contains the instructions that enable performers to elucidate a story using many different contexts. The specific context utilized for any given instance of the story is provided by the scenario. In a play, there usually are multiple roles. The focus (control) of the play is passed from one role to another as orchestrated by the script. Likewise, in the enterprise there are multiple roles. Control is passed from one role to another as directed by the process. The role that is in control gives the performer of the role the ability to accomplish the specified activities of the role. Some processes allow control to be shared by multiple roles. That enables the roles to simultaneously have their activities accomplished by the assigned performers. The concept of passing control from one role to another is important in differentiating a role from a resource. It is possible for a given performer to perform more than one role. That in no way compromises the independence of the roles or diminishes their individuality. The choice of performers for each role is a completely separate occurrence from the definition of the individual roles. 10.1.5 Resource Except for the most elementary set of activities, for a performer to perform a role, some set of resources is needed. The resources can be in many forms. In a play, they are the props, the set, or the costumes the performers wear. Those resources are not usually considered to play a role. For example, if a performer, as part of the role being performed, uses a knife in some fashion, one does not normally say that the knife is performing a knife role. The knife is referred to as a prop. In general, in a play, humans perform roles and inanimate objects are resources of some sort. Likewise, if a role in an enterprise process requires that a performer utilize a resource as part of the performance of the role, the resource is not performing a role. Unfortunately, in this situation, the differentiation can be somewhat less clear than it is in the case of a play. That results in considerable confusion as to what is a resource and what is a performer performing a role. As a quick aside, it must be admitted that at some level all entities involved in elucidating a story can be considered resources, resulting in three potential types of resources: entities not performing a role, entities performing a role, and data. As an aid to understanding, it is useful to distinguish between those different types of entities from a resource perspective. Toward that end, role performers are not referred to as resources. Non-role-performer entities are considered role resources, and data also are considered a separate type of resource. With this interpretation, the discussion can continue. If a performer of a role uses a calculator to total some numbers in performing an activity, it probably is evident that the calculator is a resource and that it is not performing a (calculator) role. Now assume that, instead of adding the numbers as part of the role activity, the performer of the role gives the list of numbers to another individual who totals the numbers and gives the result back to the performer of the original role. The performer then uses the total as needed in a subsequent activity. Is the individual who

totals the numbers a resource in the same way as the calculator, or is that person a performer of the “number adder” role? Now again change the example slightly. Assume that a performer is performing the same role activity, but instead of either using a calculator or having another person perform the number addition, an automated function or application is employed. The computer application also can be viewed as a resource used to help the performer perform the activity and a role activity being performed by an automated performer. Some means of determining a uniform response to those situations from a “role” perspective is necessary to provide a firm foundation for the specification of enterprise roles. The following three principles allow a deterministic answer to the role-versusresource questions. § Principle 1: All inanimate objects (no intelligence) provide only a resource and do not perform a role. In that sense, data are always a resource because they have no inherent intelligence of their own. § Principle 2: All humans perform a role rather than merely provide a resource. It is dehumanizing for a person to have only the status of a resource. § Principle 3: Entities that contain machine intelligence (computers) and provide an automated function perform an automated role when they function independently of the role that initiates their operation. The concept of independence is defined next. If an automated function has at least one of the following characteristics, it is considered independent of the initiating role and is defined to be an automated role. If it has none of these characteristics, it is not independent of the initiating role and is considered a resource of the initiating role. § The automated function provides some information to a role other than the one that initiated it. Storing data in a shared database is not considered to be providing information to another role unless database interaction is the primary purpose of the function. § The automated function is able to complete its operation after the initiating role terminates its normal activity. The initiating role does not expect a direct response from the automated function. § The automated function is capable of independently deciding which of multiple activities it should perform in response to a request. Given those principles, the answers to the role-versus-resource questions would be determined as follows: § The calculator is a resource. It has no inherent intelligence. § The number adder person is a role performer. He or she is human. § The number adder computer application can be either a resource or a role. It depends on which of the characteristics in the preceding list are involved. With the specific circumstances of the question as originally stated, the automated application is a resource because it has none of the defining characteristics of an automated role. Although not explicitly defined, an automated role can utilize other automated functions that may themselves be resources or other automated roles. The application of these principles provides that determination in the same way as for human role performers. It should be admitted at this point that the principles utilized to differentiate between a role and a resource are somewhat pragmatic. They seem to follow the practice of many organizations, but exceptions almost always seem to exist. However, the author has not found any situations that cannot be resolved by applying the defined principles in a reasonable fashion. For the remainder of this chapter and the rest of this book, the determination of the existence of an automated role or the explicit definition of one is consistent with the defined principles.

10.2 Role relationships Figure 10.1 utilizes a modified E-R diagram to structure the relationships of the various terms needed to place roles in their proper context. Such a representation inherently presents a passive view of the structure. A dynamic aspect, associated with the development and usage of the relationship structure, also needs to be presented. Providing such a dynamic representation in a diagram format is difficult. However, by stepping through the structure in the sequence that a process implementation and operation would require, the use of the structure can be illustrated, although somewhat imperfectly at this point. Later chapters provide a great deal more insight into the dynamics of the structure.

Figure 10.1: Structure of role relationships. Assume that a set of enterprise roles has been defined by specifying the activities each contain. The dynamic properties of the relationship structure are then illustrated by the following: § A script/process elucidates a story/scenario by specifying the particular roles involved and then controlling the performers as to how they perform their respective roles. § The control mechanism guides the performers as to when and in what manner they perform the specific role activities required by the given story/scenario. § The performance of an activity can, as necessary, employ resources or the direct CRUD of data. A resource can also directly access data and utilize the CRUD functions, if appropriate to the resource.

10.3 Enterprise role specification The determination of an effective set of enterprise roles is a difficult undertaking and one for which few guidelines exist. Usually many different sets of roles could serve the enterprise reasonably well, but the identification of even one of those sets is nebulous enough that it almost never is attempted in practice. Roles generally are determined on a process-specific basis. The problem with that approach is the usual one that occurs when independent efforts define different elements of the same set: § The same role has different names. § Different roles have the same name. § Roles that should be mutually exclusive are not. § Roles that are needed for required functions do not exist and that lack is not detected. § Many more roles than really needed are defined because possible reuse is not obtained.

It is possible to develop guidelines for the process-independent specification of enterprise roles so that the majority of those problems can be avoided. In addition, guidelines address the need to ensure that the set of roles conforms to enterprise management and operational philosophy. This section motivates and articulates those guidelines. Although developing roles from an enterprise perspective is useful, it is not possible to determine all the roles that the enterprise will need in that manner. There will always be a need to define new roles from a process perspective. Because of the large number of roles usually found in an enterprise and the inability for humans to deal effectively with that complexity, the need for additional roles will arise as processes are defined in enough detail to be implemented. Such exception-based specification is preferable to trying to determine all the enterprise roles from only a process-by -process examination. 10.3.1 Role orientation The first step in the determination of a set of roles for the enterprise is to determine possible role orientations. Although orientation is only one of the role attributes that need to be discussed, it is introduced at this time because of its importance in determining an effective role structure. The other role attributes are considered in Section 10.4. Actual roles can consist of a single orientation, or they can combine multiple orientations. Possible role orientations along with some examples of each are defined in the following list: § Organization unit: Warehouse worker, marketing department member, finance department member, manufacturing depart- ment member; § Position title/description: Member of staff, strategic planner, janitor, secretary, bookkeeper; § Management level: Foreman, supervisor, manager, department head, director, officer; § Salary level: Nonexempt, exempt band 1, exempt band 2; § Degree/professional designation: Engineer, accountant, physician, attorney; § Enumerated activities: “Makes copies, clears machine when it jams, calls service when service light comes on”; “Bolts on steering wheel, mounts dashboard, attaches radio antenna”; § Service provider: Travel agent, workstation repairer, help desk representative; § Process step(s) performer: Bill producer, accounts payable check writer, order taker, customer complaint handler. Examples § § §

of roles that combine orientations are as follows: Engineer; manager; exempt band 2; Member of staff, finance department member, strategic planner; Assembly line worker, nonexempt, “bolts on steering wheel, mounts dashboard, attaches radio antenna.”

The exact titles of the roles are not really important, nor are the orientations used to define them. Roles with various orientations can be mixed and matched as desired, as later examples illustrate. The most important criterion is that every enterprise activity needed for its operation is defined as part of at least one role. Although not quite as important, the number of activities placed in multiple roles should be kept to a minimum, to maintain consistency in role utilization. There is one important exception to that criterion. It may be necessary for some activities to be part of many roles (e.g., filling out a time card). That activity could be required by human resources for all employees and would implicitly be a part of all roles. An efficient way of handling such a case from the human resources perspective is through a general role class. The activities that belong to a specific role usually are not explicitly defined except for roles that have a job description that enumerates them. (Hence this often related story:

When asked to do something a little different, the employee says, “I didn’t know that was part of my job description.”) Admittedly, having roles with implied activities can and does lead to some confusion. However, it provides the necessary flexibility to handle new activities and situations without the need to continuously create new roles or update the definitions of current ones. For example, the role of “design engineer” may not have an explicit set of activities associated with it. However, there generally is enough innate understanding of this role so it can be reasonably determined if a given activity is contained in the role. That common association of activities may not be true of an “administrative assistant” role. Common sense must prevail in determining the degree of definition necessary for a role. Although it has been stated that the names and orientations of roles are not really important, it is also recognized that, from a practical perspective, the naming and definition of roles is of considerable interest to the individuals who are expected to perform them. Also, the enterprise usually is very interested in the defined set of roles to maintain some agreement with the desired operational characteristics of the business. To meet those needs, some general principles can be used in the definition of a set of enterprise roles. These guidelines are to be viewed as general because in any given enterprise the principles will, at times, conflict with each other. The importance and priority of each must be evaluated as role definition proceeds. § Roles should reflect the management style of the enterprise. If the enterprise is managed by organization entity, the role definitions should maintain an organization orientation. If the enterprise is managed by process, the roles should have a process orientation. § Roles should reflect any enterprise philosophy on the scope of individual job assignments. If it is expected that an individual must be able to perform a number of different activities, that should be reflected in role definitions that contain several activities. If the enterprise believes individuals should be limited to only a few activities, the role definitions should reflect that philosophy. § Roles that are more clerical in nature should have the activities defined in more detail than the activities of knowledge workers. Likewise, the activities of knowledge worker roles should be defined in more detail than those of executive roles. § Roles should reflect the characteristics of the enterprise. An enterprise in a stable, slow-moving industry (e.g., paper towel manufacturing) needs roles with activities defined in greater detail than the roles in an unstable, fast-moving industry (e.g., Internet software development). § Roles should reflect those areas that the enterprise wants to emphasize or deemphasize. If an enterprise needs to emphasize a certain area of its operation, roles should be defined that specifically address that area. If product A is the most important area of the enterprise, roles should be defined to specifically address product A (e.g., product A program manager, product A marketing manager). Conversely, if product A is to be deemphasized, roles directly involving products would be defined generically and not refer to product A specifically. It is not necessary to keep roles static once they are defined. There are many reasons that any current set of roles will have to be changed in some fashion. Because of the use of role definitions in process specifications and other enterprise uses, referential integrity is important. When the role set changes, any uses of the roles that change must be identified and examined for any possible consequence. That requires that good configuration management must be maintained, which requires the use of repository techniques as part of the management process. Any enterprise of significant size will have a large number of roles. A structured approach to the specification of those roles that meets the needs articulated earlier is required to manage the inherent complexity involved. Such an approach is outlined in

this discussion. It is presented only as a representation of the type of analysis needed to obtain a comprehensive enterprise role set. For convenience, object-oriented notation and concepts are used as a basis for representation of the ideas involved. 10.3.2 Role class structure For the purpose of facilitating the introduction of the role structure, only the roles with an association value of employee are initially addressed. In addition, consideration of general role classes is deferred to Section 10.4.8. Assume that an enterprise has a traditional philosophy of management and the highlevel organization chart depicted in Figure 10.2. In this case, most of the roles are going to be organizationally oriented, and a portion of an associated role class structure might take the form presented in Figure 10.3. Because of the complexity that would result if complete structures were shown, for the purposes of this and the following sections, only that portion of each structure necessary to illustrate the salient points being discussed is provided. It is relatively easy to extend the diagrams to any degree of detail; if readers are so inclined, it may be useful to model their own enterprise structures using the described principles.

Figure 10.2: An enterprise organization chart.

Figure 10.3: An organization-oriented role class structure. Note that the first level of the class hierarchy contains broadly defined roles similar to the major organizations of the enterprise. Subsequent partitions of the roles can represent smaller organizational units; finally, position descriptions generally are required (e.g., engineer, technician). It also is necessary to add other role orientations such as management level (e.g., foreman, manager) and enumerated activities that further define a role (e.g., television assembly worker, radio assembly worker). Now assume that an enterprise has a philosophy of management by process and utilizes the set of leaf processes depicted in Figure 10.4. In this case, most of the roles are going to be process oriented and a portion of a role class hierarchy might take the form presented in Figure 10.5.

Figure 10.4: Enterprise process definitions.

Figure 10.5: A process-oriented role class structure. There is a considerable difference in the orientation of these role specifications from those defined from an organizational perspective. As might be expected, each type of orientation has advantages and disadvantages. The organization orientation makes it relatively easy to specify a wide range of activities (usually implicitly) in a given role and keep the number of roles somewhat low. The disadvantage is that the activities included in the role are not easily specified, and a noncohesive activity set can easily result. The process orientation results in an intuitive understanding of the activities included in a role. The disadvantage is that the roles easily can become fragmented, and a large number of roles with few activities can result. Although not explicitly shown in the figures, the two role orientations can easily be mixed, depending on the needs of the enterprise. For example, instead of the manager role (that probably is somewhat nebulous from a process perspective) included in the process orientation role structure in Figure 10.5, it might be more appropriate to substitute the executive staff or the administration staff role from the organization orientation role structure in Figure 10.4. As long as all the enterprise activities are included in at least one role, the roles can be defined in any way that makes sense for the business.

10.4 Role attributes In addition to role orientation, a number of other role attributes are needed to adequately define the characteristics of individual roles. A useful set of role attributes and associated values are provided in Table 10.1. Table 10.1: Role Attributes and Values Attribute

Value Set

Orientation

Organization unit, position title/description, management level, salary level, degree/professi onal designation, enumerated activities, process step(s) performer

Association

Internal, external

Performer type

Human, automated,

Table 10.1: Role Attributes and Values Attribute

Value Set institution

Performer standing

Internal, external

Cardinality

Singular, multiple

Totality

Whole, part

Persistence

Permanent, temporary

Node

Branch, leaf

Dependence

Primary, shadow, tandem

10.4.1 Orientation The orientation characteristics were discussed in Section 10.3.1; the reader is referred to that discussion for examination of each of the possible values. 10.4.2 Association Enterprise roles usually are considered to be internal to the enterprise. However, as has been discussed, roles can be defined that are external to the enterprise (e.g., customer). External roles must be used with extreme caution because the degree of control over the performers is considerably less than that usually assumed for internal roles. 10.4.3 Performer type Human and automated performers were discussed in Section 10.1.3. There can also be institution performers that always have a standing (see Section 10.4.4) external to the enterprise. Those performers usually are known as service providers. For example, assume that a needed activity in an order-handling process is to determine a prospective customer’s credit rating. That activi ty could be assigned to a role identified as some type of institution such as a credit bureau. All that would be known about the activity is that it will be performed by the assigned institution, hence the designation. 10.4.4 Performer standing A performer can be located internal or external to the enterprise. An external role always implies an external performer. Internal roles, however, may be performed by external performers. There are two aspects to the use of external performers for internal roles. The first is the use of consultants and contractors who are utilized to perform internal roles frequently. However, from an economic point of view, they are the same as employees since their services must be compensated. Another desirable aspect occurs when it is possible to get cus- tomers and suppliers to perform internal roles. In the discussion in Section 10.1.2 of the definition of the term activity, it was noted that an internal role can be performed by a customer under the appropriate circumstances. From the enterprise view, these types of external performers essentially are providing “free” work. As part of the ongoing analysis that should be performed as part of role life cycle management, there should be an examination of the possibility of customers and suppliers performing internal roles.

10.4.5 Cardinality The cardinality of a role indicates the number of human performers that must closely cooperate to perform the role activities effectively. That number usually is one, meaning that a single individual performs the activities of a given role instance. There is a growing tendency, however, to use a team approach in the performance of certain activities. For example, assume that an activity is to “plan next year’s capital budget.” That probably would be performed by multiple individuals acting together, and the role containing the activity could be known as the “capital budget team.” That would be a role with a cardinality greater than one. 10.4.6 Totality When the cardinality of a role is greater than one, another aspect of the role must be considered. For example, in the capital budget team role, each team member (role performer) also has an individual role associated with the team role. That role could be as simple as “capital budget team member” or the somewhat more complex “capital budget team trend analysis member.” In any event, the collective (cardinality greater than one) role would have a totality value of “whole” because it consists of all of the activities assigned to the role. The individual roles would have a totality of “part” because they would reflect only part of the activities of the entire role. The totality attribute should not be confused with the node attribute (discussed in Section 10.4.8). Totality is defined only in conjunction with a role of cardinality greater than one. The node attribute is defined for all roles. 10.4.7 Persistence The persistence of a role indicates whether the role is temporary or permanent. A permanent role is created with no identified time for elimination. It is to exist as long as it is useful for the business. A temporary role is created for a specific purpose and time period. It will then disappear. Most roles are permanent but in certain circumstances, temporary roles are quite useful. The activities in a temporary role may themselves be transient, or they may be permanent and only temporarily assigned to the role. For example, assume an enterprise purchases another company and it is necessary to merge the operations of the two organizations. Temporary roles could be created to accommodate the temporary activities needed. Both are temporary because after the organizations merge, neither the roles nor their activities will be needed. In another example, assume that a permanent activity to “analyze competitor products” is assigned to a role with a cardinality of one. Now assume that a significant change occurs in the industry and that to “rebase” future analyses, a team of experts in different areas is needed to perform the activity for a given period of time. After the rebasing takes place, the team is no longer needed, and the activity can revert to its original role. In this case, the activity did not change. However, the role necessary for performing the activity did change on a temporary basis. 10.4.8 Node In the role hierarchies illustrated in Figures 10.3 and 10.5, the roles are either branch nodes or leaf nodes. The branch nodes have child nodes, while the leaf nodes do not. In general, leaf nodes are the only ones used as operational roles by the enterprise. That includes the use of roles as part of the process definition. The main purpose of the branch nodes is to serve as a vehicle for the eventual definition of the leaf nodes. However, they are also useful, in some situations, as a means to indicate a general role class. An example of the use of a general role class is the definition of a role called “employee.” This role can stand for all employees when necessary. A process that puts new employees on the payroll could use a general role such as this to avoid having to enumerate all the different employee roles involved. Roles of this type could be included

in the role hierarchy shown in Figure 10.6. The employee role would then become the root branch role for the hierarchies shown in Figures 10.3 and 10.5.

Figure 10.6: Addition of general roles to the class hierarchy. It can be argued, with some justification, that the branch nodes do not need to be characterized, and that, therefore, this attribute is not needed. However, there is some use for branch nodes in the general characterization of certain role classes and for containing activities common to large numbers of roles. Also, characterization of the leaf nodes can be made easier through standard class inheritance techniques. This attribute will be retained and the branch nodes characterized as needed. 10.4.9 Dependence Roles can depend on other roles in addition to the dependency defined implicitly through their use in a process. Roles that have no dependencies except as obtained through use in the same process are called primary roles. Shadow roles are roles that depend on one or more primary roles and are used to perform activities that closely interact with those of the primary roles. The usual example is that of a management role. For example, assume a role of “customer bill checker.” Assume further that a management oversight role of “customer billing manager” also has been defined. If an error is found by the bill checker role performer, the relevant information is sent to the manager role. Other primary roles in the billing process also could utilize the same customer billing manager role for errors, approvals, and other management functions. The customer billing manager role is a shadow role, because it does not exist independently of the primary roles that elucidate the customer billing process. Almost all management roles are shadow roles because they cannot exist independently of the roles they manage. The role being managed can, however, exist without the management role. Another type of shadow role would be a support role that provides additional information to the primary role being supported. A popular example would be a sales support role that contains research activities designed to help the sales role provide needed information to prospective customers. The sales support role cannot exist independently of the sales role, but the reverse is not true. Definition as a shadow role does not reduce the importance of the role to the enterprise in any way. It is simply a way of characterizing role dependencies. Tandem roles are roles that require each other and must be defined together. Although the term tandem implies two, any number of roles could be defined as part of a group being utilized simultaneously. An example of tandem roles would be a trainee (student) role and a trainer (teacher) role. It would be difficult to separate the two roles. Although each could be used in some situations without the other, neither makes sense unless the other role is associated with it.

10.5 Role utilization The main reason to define roles in the enterprise is to provide a useful mechanism for ensuring that the enterprise is operating efficiently and effectively. That is accomplished using both construction and analysis techniques. Without the use of role definition, there is no easy means to determine how well employees and their automated tools (automated functionality) are being used in performing the activities of the enterprise.

Although automated roles have been defined for convenience, the main focus of roles is toward the humans in the enterprise. That focus is evident in the following discussion. In current organizations, especially those involved in high-technology industries, human capital can be significantly more important than financial capital in ensuring future success, although both certainly are necessary for survival. Human capital is really a shorthand way of referring to the collective experience and abilities of the employees of an enterprise. Roles represent an important tool for determining if (1) the human capital is utilized wisely and (2) individuals are comfortable and reasonably happy with their assigned activities. The discipline of explicit role definitions also provides a mechanism for determining how the enterprise should respond to changing business and technology pressures from the human capital perspective. The explicit use of role specifications allows an enterprise to determine, for a specific point in time, the characteristics and numbers of employees that are needed to effectively and efficiently operate the enterprise or, conversely, how to best apply the talents and experience of individuals that are already available. Job descriptions, which are a form of role definition, historically have been used in the enterprise to help define individual positions and the desired characteristics of the employees who fill the positions. That, however, is a narrow utilization of the role concept and does not easily permit any analysis as to the overall effectiveness of the positions as defined. In addition, not all (or even a majority) of positions in an organization may have job descriptions. In that case, because the definition of roles is not pervasive in the enterprise, their usefulness as an analysis tool is further diminished. Selected bibliography Lupu, E., and M. Sloman, “A Policy-Based Role Object Model,” Proc. 1st Internatl. Enterprise Distributed Object Computing Workshop, Gold Coast, Australia, Oct. 24–26, 1997, pp. 36–47.

Plaisant, C., and B. Shneiderman, “Organization Overviews and Role Manage- ment: Inspiration for Future Desktop Environments,” Proc. 4th Workshop Enabling Technologies: Infrastructure for Collaborative Enterprises, Morgantown, WV, Apr. 20–22, 1995, pp. 14–22.

Chapter 11: Information modeling Effective management and utilization of information are required for an enterprise to obtain and maintain a competitive advantage. Executive decisions, marketing strategies, process improvement, and personnel motivation, along with many other crucial activities, all depend on having the right information at the right time in the right format. With the glut of information currently available, there is a growing need to identify and make effective use of the specific sets of information that will enhance the operation of the enterprise. An emerging technology known as knowledge management is attempting to deal with the general problem of information overload. Although a general discussion of that technology is well beyond the scope of this presentation, there are some similarities with the discussion in this chapter, including a need to utilize a higher level of abstraction than data, extensive modeling techniques, and the use of repository technology. Modeling allows a consistent approach to the identification, control, and utilization of information. Although information modeling (or data modeling, as it historically has been called) has been in use since the beginning of computer applications, there is a growing need for more extensive models than the relatively restrictive ones used in the past. The purpose of this chapter is to motivate and develop a comprehensive information model suitable for the fast-changing automation environment of the enterprise. To keep with historical precedent, the term data modeling is used throughout this discussion, except when it is necessary to differentiate between the concepts of data and information.

11.1 Background Historically, the modeling of data has used several different formats. From the earliest beginnings of general computer usage and data processing, data have been modeled using the constructs of programming languages and still are for local data that will not be shared between software programs. Fortran and Cobol, along with most other languages, let programmers determine the layout, names, and characteristics of the data (data model) needed by a program. Initially, the data were unique to the program in which the data were defined. Shared data were later in coming and required that the model (e.g., Fortran Common) be copied in all programs that needed it. The purpose of those primitive data models was simply to allow the programmer to easily couple the program logic with the data it required. Those models could be considered logical models, because the programmer usually was not concerned with how the data were actually stored in memory (the physical model). Some programmers, however, did understand how the compiler directed the data to be stored and were able to circumvent the model by directly accessing physical storage. (It should be noted that the problem of circumventing models of various types continues to this day, usually with unanticipated and unfortunate results.) The need to define data models as an independent (from software development) activity resulted from the development of mass storage devices. That need did motivate some additional modeling concepts. File structures had to be defined with some thought toward the most efficient way to access and utilize the sequential data format. From that need comes the concept of the master file and transaction files. That operational data model is still in use today, although some of the forms have changed to keep pace with storage technology. In addition to the modeling needed for efficient file design and utilization, another modeling concept became popular. It resulted from the need for a procedure to determine: § What specific data were needed for the individual automated functions; § The detailed characteristics of the data so they could be specified to the software applications. The result is the E-R model, which is usually depicted in diagrammatic form. That model, or E-R diagram, the name by which it was usually known, was quickly adopted because the number of functions being automated was increasing rapidly, as was the amount of data that needed to be accommodated. An example of an E-R diagram is shown in Figure 11.1.

Figure 11.1: An example of an E-R diagram.

In concept, an E-R diagram is relatively simple. The entities are represented by the nodes (circles) of the diagram, and the relationships are represented by the lines. Both entities and relationships can have attributes, illustrated by annotations in the figure, the values of which determine their characteristics. Some additional, more complex constructs are needed for practical modeling situations. For the purposes of this discussion, however, it is not necessary to go further into the details of E-R model notation. Because of the power of the E-R model to identify problems with a data specification, it was applied to the modeling of the entire enterprise. It is possible although somewhat difficult, as these efforts indicated, to develop an E-R diagram for an entire enterprise. Whether or not that was a useful activity depended heavily on the intended use of the model. If the purpose was to identify and understand enterprise data, then it could have been a useful exercise. If the purpose was to use the model as the basis for software development, then the inherent structural complexity could—and usually did—greatly hinder the us e of the model. In many cases, that resulted in the development ignoring the data model and using no model at all. E-R modeling fell on hard times. The development and use of DBMSs have given rise to the new specialty of database administrator (DBA), who was responsible for: § Mapping the enterprise data into the structure of the DBMS being used (logical model); § Ensuring that the DBMS was efficiently used (physical model). Software that used DBMS resident data had to understand the logical model of the data to navigate through the DBMS structures to locate the desired data. Providing for efficient response times usually was met by tuning the parameters that determined how the DBMS stored the data on the bulk storage media being used. With the advent of relational DBMS structures, data modeling took a somewhat different path. Considerable emphasis, from a modeling perspective, was placed on data normalization. The original purpose of normalization was to minimize the need to store a given data item multiple times and thereby improve storage efficiency and integrity. That is accomplished by defining data units that contain a cohesive set of data elements and, with the exception of links between units, allow a data element to reside in only one unit. In a relational model, those units are structured as tables. While normalization is an excellent concept for a physical data model, there was an unforeseen effect. The logical data models used for coupling with the software were also being subject to normalization. That type of design made it difficult to find the data contained in an intermediate data structure (e.g., purchase order). Link after link would have to be followed, sometimes through three and four levels, before individual data elements of interest could be found. Normalized data models, much like the E-R models, were not well suited to the needs of software development. The latest evolution of DBMS formats is based on objects, a format that has considerable appeal for use with software based on object-oriented designs and implementations. It also is considered useful for storing data that contain information such as video, audio, text, and graphics. Data models for object DBMSs result from the specification of the attributes for the object classes of interest. This area is of great general interest, but the state of the art has not advanced to the point where it would affect the discussions in this chapter. Although several aspects of data models (physical, logical, operational) appeared at various times in the evolution of data modeling, the focus of the models almost always was on the following three concerns: § The specification and relationships of individual data elements; § The physical storage format of the data at the data element level; § An efficient means of handling the traffic load on the data storage mechanism. The use of data models to facilitate the specification and utilization of automation functionality generally were not considered. One of the few exceptions was the development of the master and transaction file data

model, which was designed to ease the software design and operation problem inherent in the use of the sequential files. While the data-centric concerns are still quite valid, maintaining the data modeling focus on them exclusively is no longer sufficient. Data models must also support the efficient specification and utilization of automation functionality in the enterprise. Inclusion of that view requires consideration of the information aspects of the enterprise as well as a more effective way of incorporating that level of abstraction into the specification and implementation of automation functionality. To some extent, incorporation of both views requires shifting the overall focus of data modeling to the information level abstraction rather than the data level, although both must be included in the resultant model. Section 11.2 contains models designed to provide the broader modeling scope and the shift of emphasis needed to address both the information and data levels of abstraction. For the purposes of the discussions in this book, information is considered to be data with a usage context. For example, “customer name” is data because there is no indication as to how it will be used. “Customer name” in a pending-order structure is information, because “pending order” indicates how the customer name is to be used. In general, information utilizes a higher abstraction level than the data it contains. That differentiation will become clearer as the discussion proceeds.

11.2 Data modeling system The purpose of the data modeling system as defined in this section is to provide a comprehensive, unified structure that facilitates the efficient specification and utilization of information and data in the automated operations of the enterprise. The system is designed to meet the following needs (both old and new): § The determination of the data elements needed in the enterprise; § The use of the data elements to provide an effective physical implementation of the data; § The ability to specify the data needs of the automation functionality at the information level; § The ability to specify, access, and use the physical data elements at the information level; § The ability to ensure that changes in any one area are reflected in all other affected areas of the modeling system. Those needs all must be met without incurring significant overhead costs to use the data or requiring an excessive amount of administration and management effort. That necessitates an approach that incorporates a method for self-definition of the data and that uses a repository as an integral part of the model structure. 11.2.1 Modeling system dynamics Figure 11.2 illustrates a data modeling system. Four component models must interact to provide the overall system model. Each model has a specific purpose in the management of the data specification. In addition, the DBMS may have its own internal model. However, discussion of DBMS internal construction is well beyond the scope of this presentation. The global aspects of the data modeling system are considered first to determine the purpose and usage of each of the individual models. Once those requirements have been established, the structure of each of the individual models can be defined and discussed in additional detail.

Figure 11.2: Structure of a data modeling system. In addition to the model components, a repository component is also included in the system diagram. The repository indicates the requirement for saving all of the model information as well as the ability to examine the modeling system for specification problems or improvement opportunities. Maintenance of the referential integrity of the model also requires repository services. As the discussion continues, it should be kept in mind that many of the requirements placed on the models and their relationships are dependent on use of a repository. The modeling system is dynamic, although the diagram is not able to depict that aspect very well. To convey an understanding of the model dynamics, a description of a typical sequence of events is utilized, along with a description of the major characteristics of each component model as it is invoked in response to the data system operation. The first activity is the development of an enterprise logical data model. The purpose of that model is to determine the data needs of the enterprise as a whole. As discussed previously, any attempt to develop an enterprisewide definition of any type is fraught with difficulty. That certainly does not mean it is not a useful effort, however. It can serve as an excellent starting point to which additional items can be added as normal operations necessitate. Once the logical model has been defined, it is used for two entirely different purposes. The first—and probably the most important—purpose is to provide the structural basis for defining the physical model. The physical model is used to partition the data such that they can be efficiently accessed by the operational software. The characteristics of the DBMS product being utilized as well as the platform on which it resides are also major inputs to the physical data model. The physical data model must meet the intent of the logical model, but it is not required to mirror the logical model in every aspect. In fact, in most cases it will not be able to do so and maintain adequate access characteristics. Because the logical model defines the set of enterprise data elements and their associated characteristics, it also forms a natural repository of data elements for other models that need that information. Although the structure of the data elements used in the logical model usually is not appropriate for incorporation into the other models, the ability to provide a common set of data element names and associated characteristics is important in maintaining consistency throughout the entire modeling system.

The information model provides the mechanism for defining and utilizing data as part of the process specification. It is defined independently of the logical data model, and its constructs are specifically designed to complement and integrate effectively with those used to define the automation functionality. Because the components of the information model eventually must be defined down to the data element level, the use of the available element definitions from the logical model simplifies that aspect of model development. In addition, given that the information model is designed to elicit all the data element needs for a specific process implementation, it readily can be determined if there is a gap in the definitions of the logical model for the process of interest. The purpose of the operational model is to efficiently couple the data accessed through the DBMS with the automation software. As such, it is not unlike the purpose of the original data models specified through the use of programming language constructs or the master/transaction file model. This completes the dynamic description of the data modeling system. It should be noted that each component model is defined from needs imposed from outside the data system as well as needs that result from adjacent system components. The operation of the system is continuous because it must respond rapidly to any changes in the needs of the enterprise. The decoupling of the component models and their close integration with the development phase with which they are associated make that kind of response possible. As the components targeted to the specification and execution of automation software, the information model and the operational data model specifically are used as integral parts of the process implementation methodology and are covered in detail in the following sections. 11.2.2 Information model The information model structure and specification procedure are illustrated in Figure 11.3. This discussion proceeds in the context of a business process specification, which is the preferable approach to the development of automation functionality.

Figure 11.3: Information model.

11.2.2.1 Information flows The first activity is the definition of information flows for each step of the business process. The initial definition of an information flow consists of a name and a businessoriented description of its purpose and contents. The flows depict the logical types of information needed for the successful execution of the process step. Information as it is used in this discussion is merely a context specification at a relatively high level of abstraction presented in terms understandable by business-oriented personnel. The specification format would also be of interest to any technical personnel who are not familiar with the specifics of traditional data modeling. Examples of

information flows would be: “customer profile repair ticket,” “items purchased,” and “credit rating.” The information flows should be defined independently of any current source of data (e.g., database, legacy system). The goal is to identify the inherent information needs of the process and not to determine how to get at the physical data the information represents. The link between the physical data and the automation functionality are specified by other components of the data modeling system. It should be noted that it may be difficult for the participants in this information identification effort to divorce themselves from their knowledge of the current locations of the information. However, that must be accomplished if the information flow specifications are to accomplish their purpose. The intention of this type of specification is to separate the identification of information need from the details of how the data elements are specified in the logical data model. As has been stated, the logical data model is not in a form that can be easily adapted to procedures for information determination. Although the term flow is included because of its historical use, a dataflow diagram in the classical sense is not required. A listing of the information flows for each process step and their major characteristics (e.g., input, output, description, timeliness) is sufficient. The specification of the information flows at this time serves two basic purposes: § It provides an indication as to the complexity of the process step. § It allows the business SMEs to provide advice and counsel on the information requirements of the process in addition to the functionality aspects. The specification of the logical sources and sinks of the flows is not immediately necessary and probably premature. However, that identification must be accomplished before the information flow specification is completed.

11.2.2.2 Information structures After the information flows are specified, the information structures derived from the information flows must be identified. As indicated in Figure 11.3, an information flow can consist of an entire information structure, or there can be several information flows defined within a structure. The information structure serves as the authoritative source for the information in the flow. Because a basic philosophy of the modeling approach presented here is that the same information can be replicated in many places, it is necessary to identify a means of obtaining the “official” copy of the information contents. By convention, the specific information structure defined for an information flow contains the official copy of the information in that flow. As an example, assume that a needed information flow is “customer contact information.” The official source of the information could be a set of data called “customer profile” that would contain the information for customer contact as well as a significant amount of other potential information about the customer (e.g., credit history). “Customer profile” would then be identified as the information structure that contains the customer contact information. Note that all of “customer profile” will be a single information flow under some circumstances such as initial creation of a profile or a general update of the information contained in the structure. Generally, every information structure will also be defined as an information flow. Because an information structure is also an information flow, it does not have to have a different degree of definition than its component flows to be identified as an information structure. In addition, the following discussion of selecting data elements for each flow also applies to information structures. If possible, the data elements for the information structure should be selected first. That makes it easier to select those for the other information flows it contains. In many cases, however, the data element population proceeds in an opposite sequence. The data elements for the component flows are selected first, and the union of those are used to populate the information structure. Either way works, as does a combination approach. In any case, the data elements of

each information flow must be consistent with the data elements contained in its defining structure.

11.2.2.3 Data element specification After the information structures are identified, it is necessary to determine which specific data elements will constitute each information flow. The basic approach is to use the description of the flow to examine data elements: § As defined in any of the structures of the logical data model; § As contained in the defining information structure of the flow. A determination then can be made as to which elements would be appropriate for inclusion in the definition of the flow. The elements selected are examined to determine what gaps, overlaps, conflicts, or inconsistencies may exist. Those problems are resolved by going back to the logical data model for new or replacement elements and eliminating currently specified ones. This is an iterative procedure and must be repeated several times before an acceptable information fl ow specification at the element level can be achieved. The need for data elements that have not been specified in the logical data model is also quite likely. In that case, they must be added to the logical model as well as the information flow. When a set of data elements has been identified for an information flow, the elements must also be examined in light of the functionality for the process steps in which they are used. That analysis may show the need for additional data elements or the inclusion of inappropriate ones. The process always remains the base specification against which all modeling constructs must be validated. The same data element may appear in multiple flows. Elements are not normalized across flows. Remember that the purpose of the information flow is to facilitate the specification of the data needed for a process step. Molding it into an artificial construct that will obscure the purpose of the information must be avoided. A convenient method of managing such replication through naming conventions is discussed in Section 11.2.2.5. Continuing with the “customer profile” example, assume that in addition to a “customer contact” information flow, a “customer type” flow is defined for use in selling new products. The latter flow indicates the level of services needed by the customer. Some of the elements included in the “customer contact” flow might be: § Name; § Street address; § City; § County; § State; § Zip code; § Main telephone number; § E-mail address; § Fax number. Some of the § § § § § § § §

elements included in the “customer type” flow might be: Name; Main telephone number; Customer size; Mobile phone number; Other phone numbers; Pager number; E-mail address; Fax number.

As stated, the purpose of those elements is to indicate the level of services utilized by the customer. Note that some of the same elements are used in each flow since the

desire is to have each flow as a complete entity. Even though an element appears in multiple flows, it would appear only once in the information structure itself. For the above assumptions, the elements in the “customer profile” structure would be (in no particular order): § Name; § Street address; § City; § County; § State; § Zip code; § Main telephone number; § E-mail address; § Fax number; § Customer size; § Mobile phone number; § Other phone numbers; § Pager number. Additional information flows defined for this structure could add more elements, or they could use those elements already defined for the structure.

11.2.2.4 Datastores Once the data elements of an information flow have been determined, a source or a sink of the flow must be identified. The source or a sink of an information flow is called a datastore. The base location of an information structure is also in a datastore. An individual datastore may be a source of information, a sink for information, or both. Datastores may have a considerable amount of implied intelligence, although they can always be reformulated (at a cost) as containing no intelligence. That aspect is illustrated in Figure 11.4. Requesting information from a datastore is accomplished through a key mechanism. The request key can be complex or simple; an example that uses a complex key is given later. The datastore structure is compatible with the models developed in the following chapters.

Figure 11.4: Datastore configurations. As an example, assume that a datastore is defined that serves as a source of equipment costs. The input (or key) to obtain cost information from the datastore is a specific equipment configuration. The output is the cost of the configuration. The datastore could be organized as a table that contains entries for each possible type of configuration and the cost associated with each configuration. With a large number of possible combinations that may be undergoing considerable change, this approach easily could be impractical. Another approach is to create a program that calculates the cost based on the configuration presented and a set of business rules that contain the costing policy. From a user perspective, there is no difference between these two implementations (except possibly the response time). The datastore is specified only on the basis of the information desired (configuration cost) and not on how it is obtained (e.g., table or program logic). If a datastore consists of more than static data, it sometimes is referred

to as an intelligent datastore. The same discussion can be utilized for the other CRUD operations. The user view remains the same, but the implementation may vary considerably. More information on the use of datastores is given in Chapter 13, which discusses the structure and use of functionality elements called actions. Actions interact with datastores to access the data needed to perform the indicated function. Actions assume that all functionality is provided by intelligent datastores regardless of actual implementation. If existing datastore definitions are available from the previous implementation of other processes, it would be useful to examine their definition and data elements to determine if they would be suitable for the current process. That is the data equivalent of reusing process activities and associated functionality. The determination as to the suitability of a previously defined datastore can be accomplished only through a detailed knowledge of the process being implemented and the definition of the existing datastore. Because an existing datastore contains a relatively rich set of data as needed by the previous process implementation, its use would be advantageous later in the design. However, the use of an existing datastore should not be forced, because it may compromise the design if a good fit does not exist. Seasoned engineering judgment is needed in the effort as well as excellent documentation. It is not necessary to assume that an information flow will use one and only one datastore and is probably counterproductive. Continuing with the example, again consider a “customer contact” information flow as defined earlier. A source for this information could be a datastore called “customer information,” which contains basic information on all customers. There could be multiple sinks for the customer contact information, including a “customer contact” datastore, which contains a record of all customer contacts; a “pending order” datastore, which contains a record on all pending service orders; and others depending on the process being implemented. Those datastores could, in turn, serve as a source for the information as needed in subsequent process steps. Because each datastore has a different logical purpose, it is conceptually easier to keep all the information needed for each logical purpose together even if some of the information is duplicated (e.g., customer contact). Initially thinking in terms of the purpose of the information rather than its content results in more efficient automation design and development.

11.2.2.5 Naming convention A naming convention is an effective means to keep the replication of data elements under control. In addition, it provides for the self-definition of the data when used under operational conditions. Although many formats could be utilized, the naming convention that will be utilized for the data elements is as follows: datastore name.information structure name.information flow name.data element name (value) or DS.IS.IF.DE (value) for short. Minus the value, this format is referred to as the fully qualified name for a data element; alternatively, it is called a data item. The data element name portion of a data item can also have components of its own, depending on how the data elements are specified in the logical data model. Each unique fully qualified name can have a different value for the data element in the same invocation instance. Although that will be relatively infrequent, there are conditions under which it is a useful feature. One of the most compelling conditions is utilization of legacy or COTS systems that have their own inherent element or value structures that must be accommodated. The operational aspects of this naming convention are considered in detail in Section 11.2.3.

11.2.3 Operational model The purpose of the operational model is twofold. The first is to provide a structure through which the physical data elements can be accessed by the automation software at the information level. That allows the software developer to work with data at a level higher than data elements when appropriate but still have access to the individual elements as needed for the functionality to be implemented. While the specification of data at the information level probably is not that unusual an idea, the access and control of data at the information level certainly are. However, this aspect is needed to facilitate the specification and development of automation functionality. The second aspect of the operational data model is to allow for effective use of the selfdefining aspects of the data. The metadata inherent in the fully qualified name provides the self-defining feature. Self-defining data provide a significant number of advantages during the operational phase of automation software. Some of the major advantages are the following: § The operational model need not be statically defined. Data needed during any given invocation of the software may vary depending on the path taken through the process being followed. § The presence or absence of a given data item, regardless of value, can easily be detected. § The same data item can be given multiple values by changing its fully qualified name (e.g., utilizing a different datastore name). § The elements in an information structure or information flow can be changed to accommodate new applications without the need to change existing software. § New datastores, information flows, and information structures can be defined without the need to change existing software. § The needs of transient software components, such as Java Beans, can be easily accommodated. As an example of direct utilization of the information level, consider a customer verification activity from an order entry process. Assume that there are two information flows of interest: “customer profile” and “customer-provided information.” To provide verification as to the identity of the individual placing the order, the information provided by the customer must match the information in the customer profile. That certainly can be accomplished at an element level, but it is far more efficient and meaningful to do it at the information level. In high-level pseudo-code: Get customer profile Get customer provided information If customer provided information [elements given] = customer profile [associated elements] continue else go to terminate order activity What that indicates is that all the elements obtained from the customer must match the same elements in the customer profile for the order to be processed. It should not be necessary to determine in advance which elements are to be compared or even what elements are in the customer profile information flow. Although there will have to be a fragment of infrastructure code that actually compares the data items, their self-defining feature makes the development of that type of generic functionality very efficient. The operational model provides the concepts, structures, and overall framework to accommodate that type of information use. An illustration of one design for an operational model is shown in Figure 11.5. The DBMS structure, although not a direct part of the model, is included in the diagram for completeness of the illustration. The concept of a cluster store, discussed in Section 11.2.3.1, is central to the model structure. The reason for this particular terminology will be evident in the presentation of the process implementation methodology.

Figure 11.5: Operational model. Note that both logical and physical data paths are shown. The logical path indicates the relationship or mapping between the datastore and the physical storage for a specific information flow. The physical path is more representative of how the data transfer would be controlled and transported in an actual implementation. For that reason, the scenario examples, which are utilized to indicate the dynamics of the model, will use the physical path as an explicit part of the specification.

11.2.3.1 Cluster store The cluster store contains all the data items needed by the software functions for a specific task. At that point, the cluster store can be thought of as local data, although, as is explained in Chapter 13, the concept is much more powerful than that. The concept and definition of a task are contained in the discussion presented in the workflow discussion in Chapter 15. Required data from persistent storage must be explicitly obtained. For the immediate purpose of this discussion, a task may be considered as all activities of a single role that are performed by a given role performer in a continuous time interval. Thus, all the data considered during that time interval are available to any activity during the same interval. The great power of this construct will become evident during the implementation methodology discussion. All the data in the cluster store are formatted according to the DS.IS.IF.DE (value) format presented in Section 11.2.2.5. Data can be accessed and utilized at any level in the name (e.g., by information structure name). The types of operations that can be performed on the cluster store data are defined and discussed in detail in Chapter 13. Although this postponement probably is not very satisfying to the reader, because of the uniqueness of the approach, it is necessary to develop a large number of basic concepts and models before they can be brought together into an integrated structure that achieves the desired results.

11.2.3.2 Dynamics The overall dynamics of the operational data model are considered through the use of high-level scenario stories. Only a few are considered, but that should be enough to provide the necessary understanding for later discussions that incorporate this concept.

Scenario 1: Retrieval of information from a datastore 1. 2.

3.

Function 1 requests the “customer contact” information flow from the “customer information” datastore. The request is given to the cluster store control by way of the function execution environment. (This environment provides a standard means of communication between the individual functions and the cluster store and cluster store control.) The cluster store control queries the location map to determine which DBMS contains the “customer contact” information flow

4. 5.

6.

7.

from the “customer profile” datastore. (Logically, this map would be in the repository.) The request is then sent to the physical data control that locates and accesses the desired data from the identified database. The physical data control sends the data through the network connection to the cluster store under control of the cluster store control. When the “customer contact” information flow is available in the cluster store, the cluster store control notifies the function execution environment, which then notifies function 1. A subset of the data in the cluster store is now as follows: § customer information.customer profile.customer contact.name § customer information.customer profile.customer contact.street address § customer information.customer profile.customer contact.city § customer information.customer profile.customer contact.county § customer information.customer profile.customer contact.state § customer information.customer profile.customer contact.zip code § customer information.customer profile.customer contact.main telephone number § customer information.customer profile.customer contact.e-mail address § customer information.customer profile.customer contact.fax number

Scenario 2: Copy of an information flow Function 2 requests the “customer contact” information flow from the “customer information” datastore be copied as the “customer contact” information flow for the “repair ticket” datastore. 1. The request is given to the cluster store control by way of the function execution environment. 2. The cluster store control locates all data items of the form (xx means “don’t care”): customer information.customer profile.customer contact.xx. 3. For each item located, it forms a new data item of the form: repair ticket.customer profile.customer contact.xx. 4. The “don’t care” levels are copied without change. 5. A subset of the data in the cluster store is now as follows: § customer information.customer profile.customer contact.name § customer information.customer profile.customer contact.street address § customer information.customer profile.customer contact.city § customer information.customer profile.customer contact.county § customer information.customer profile.customer contact.state § customer information.customer profile.customer contact.zip code § customer information.customer profile.customer contact.main telephone number § customer information.customer profile.customer contact.e-mail address

§ § § § § § § § § §

customer information.customer profile.customer contact.fax number repair ticket.customer profile.customer contact.name repair ticket.customer profile.customer contact.street address repair ticket.customer profile.customer contact.city repair ticket.customer profile.customer contact.county repair ticket.customer profile.customer contact.state repair ticket.customer profile.customer contact.zip code repair ticket.customer profile.customer contact.main telephone number repair ticket.customer profile.customer contact.email address repair ticket.customer profile.customer contact.fax number

Scenario 3: Update of information in a datastore 1.

2. 3. 4.

5.

6.

Function 3 requests the “customer contact” information flow from the “repair ticket” datastore be used to update the datastore information. The request is given to the cluster store control by way of the function execution environment. The cluster store control queries the location map to determine which DBMS contains the “repair ticket” datastore. The request is then sent to the physical data control that determines where the data will be stored in the identified database. 5.The cluster store control sends the data through the network connection to the physical data control under control of the cluster store control. 6.The physical data control causes the data to be stored in the proper location.

Using the operational datastore model greatly simplifies the handling of data as well as the automation software that operates on them. For explanation purposes, the discussion has been greatly simplified from what is required in an actual system.

11.3 Summary The data modeling perspective presented in this chapter is considerably different from that utilized under current practice. While conventional data modeling, which generally consists only of the logical and physical data models, is included in the perspectives presented in this chapter, it forms only a part of the overall data model. Those models are still needed to define the enterprise need for data and to ensure that physical storage and access to the data are efficient and cost effective. The nontraditional model components, the information and operational models, serve as the bridge between the physical data elements and their utilization by the automation software at the information level. Those models are concerned with increasing the effectiveness and efficiency of software specification, procurement, and deployment. Although the logical and physical models are an integral part of the overall data modeling structure, the emphasis in this chapter and future chapters is on the information and

operational models because it is those models that greatly facilitate the development and deployment of process implementations. Selected bibliography Gonzalez, R., “Hypermedia Data Modeling, Coding, and Semiotics,” Proc. IEEE, Vol. 85, No. 7, 1997, pp. 1111–1140.

Johannesson, P., “A Method for Transforming Relational Schemas into Conceptual Schemas,” Proc. 10th Internatl. Conf. Data Engineering, Houston, Feb. 14–18, 1994, pp. 190–201. Kevin, H. X., et al, “An Introduction to Enterprise-Participant Data Model,” Proc. 7th Internatl. Conf. Database and Expert Systems Applications, Zurich, Sept. 9–13, 1996, pp. 419–417. Levene, M., and G. Loizou, “A Graph-Based Data Model and Its Ramifications,” IEEE Trans. Knowledge and Data Engineering, Vol. 7, No. 5, 1995, pp. 809–823. Ozaki, K., and Y. Yano, “The 3-tuple Data Modeling,” Proc. IEEE Internatl. Conf. Systems, Man and Cybernetics, Vol. 3, 1996, pp. 2149–2164. Parsons, J., “A Graphical Technique for Modeling Multi-User Data Requirements,” Proc. 28th Hawaii Internatl. Conf. System Sciences, Vol. IV, Wailea, HI, Jan. 1995, pp. 273–282. Peters, P., “Business Process Oriented Information Management: Conceptual Models at Work,” Proc. Conf. Organizational Computing Systems, 1995, pp. 216–225. Reingruber, M., and W. W. Gregory, The Data Modeling Handbook: A Best-Practice Approach to Building Quality Data Models, New York: John Wiley & Sons, 1994. Schloss, G. A., and M. J. Wynblatt, “Using a Layered Paradigm to Model Multimedia,” Proc. 28th Hawaii Internatl. Conf. System Sciences, Vol. V, Wailea, HI, Jan. 1995, pp. 777–786. Spaccapietra, P., and C. Parent, “View Integration: A Step Forward in Solving Structural Conflicts,” IEEE Trans. Knowledge and Data Engineering, Vol. 6, No. 2, 1994, pp. 258–274.

Chapter 12: Client/server modeling Overview The concept of client/server (C/S) structures has been in place since the earliest computers were developed. Although it was not recognized as such at the time, many of the characteristics associated with contemporary C/S architectures were embodied by those early systems. That lack of understanding carries over to current meanings and understanding of the terminology. Inconsistencies and confusion as to what constitutes a C/S approach remain common among both vendors and their customers. To effectively use the rather powerful concepts of the C/S paradigm, it is necessary to provide some structure and associated definitions. To provide a comprehensive discussion of the C/S approach would take multiple volumes. Such depth clearly is beyond the scope of the information that can be provided in this chapter. The presentations are limited to providing only the information that is needed to (1) ensure a consistent approach in using the C/S paradigm and (2) provide a sufficient base for specifying a process-oriented software development methodology.

The discussion starts with a simple C/S model and progresses to more complicated structures. Unfortunately, no organization of the material could separate all the elements into a nice linear progression. That means some material has to be referenced before it can be discussed in detail. When that occurs, an explicit indication of the situation is given.

12.1 Simple C/S systems C/S systems, by their very name, must involve at least two distinct parts, the client and the server. The simplest structure, using one client and one server, is depicted by the model in Figure 12.1(a). In addition to showing the client and server entities, it also defines the elementary relationship between them. The client requests services from the server, and the server provides services to the client. A slightly more complex system is shown in Figure 12.1(b). It is still a relatively simple system but has enough structure to allow an examination of the many diverse characteristics of C/S systems.

Figure 12.1: Simple C/S specification. Figure 12.1 is useful in establishing the basic relationships between the components of a C/S system and in determining an initial set of issues that need to be addressed. However, from a modeling perspective, the structure is not adequate. Therefore, most of this C/S discussion uses a timing diagram format to illustrate the specific configuration involved. This type of diagram can show graphically the dynamics of client and sever operation with respect to the client service requests and the server responses. The basic format of the diagram is shown in Figure 12.2 for a single client and server. Configuration diagrams for several multiple server configurations are considered in Section 12.2.1.

Figure 12.2: C/S configuration diagram. Given the depiction of a simple C/S system, a number of issues immediately come to mind. Some of those issues may be more applicable to C/S systems that have additional components, but they are listed here for completeness. 1. Do the services that the client requests have to be delivered to the client, or can they be delivered elsewhere (i.e., another client or server)? 2. Can services be delivered to the client without being asked for by the client? 3. Can the client have multiple simultaneous requests outstanding? 4. Can the client become a server and the server become a client? 5. Can the server request from other servers the services needed to fulfill a request? 6. Can the client or the server be logical, physical, human, automated, or a combination? 7. Do the client and the server maintain persistent state information across requests? 8. What is the mechanism to request and deliver services? Depending on the specific set of answers to those questions, C/S systems with distinct characteristics result. Although they are all C/S systems according to the simple system definition, they differ considerably in structure, capabilities, complexity, and, in many cases, the nomenclature used to describe them. The latter problem causes most of the difficulty in describing and understanding the different incarnations of C/S systems. To provide some organization to the rather complex set of possibilities posed by the questions, the approach here is to partition the problem into four parts: § The equipment configuration; § The functional (software) configuration; § The human interface configuration; § The communications configuration. 12.1.1 Equipment configuration The first serious problem in nomenclature results from equipment designations by the vendors of computing equipment. They sell either servers or some form of personal computing devices (personal computers, workstations, or more recently, network computers). No vendor (at least to the author’s knowledge) sells a “client” computer. The equipment terminology is not so much attuned to the C/S model as it is to whether it is oriented toward direct human interaction with the computing device. The fact that a

computer not designed for direct human interaction is called a “server” causes extensive trouble when we consider a C/S model. To alleviate that problem, the following assumptions are made: § The C/S model is not based on hardware configurations. § All computers on a network have connectivity with each other and can send information to each other as necessary. Thus, whether or not a specific computer is designated as a server is immaterial to the rest of the discussion. (Perhaps it should be called a “hands-off computer”!) Because equipment is not part of the C/S definition, there is no need to address any question in the list except number 6 (Can the client or the server be logical, physical, human, automated, or a combination?). One component of the answer is that the client and/or the server of a C/S model cannot be defined as a piece of physical equipment (hardware). 12.1.2 Functional configuration The C/S nature of a system is determined only by the configuration of its component software functions and their interaction. From a design perspective, that configuration is also called the logical configuration. The latter term is used here to refer to the construction of a C/S system as a whole. In reference to component functions, it is assumed that in a C/S system the functions are separate and not integrated. In any computing system, all the functions required to perform the desired operations must be present in some form. The C/S designation requires that the individual functions are separated into individual identifiable units. In a non-C/S system, that may not be true.

12.1.2.1 Client characteristics A client is defined to be that functionality of a C/S computing system designed to interface with a human being or an agent (software) of a human being. Although that definition is close to conventional usage, it does not permit a server to have client characteristics when it is requesting services from another server. The latter usage is permitted by common practice. As will be indicated, the term requester is substituted for client when a server requests services from another server. The questions can now be answered with respect to the client. Questions that are not client related are addressed later in the discussion. Question 1: Do the services that the client requests have to be delivered to the client, or can they be delivered elsewhere? The client can request services on the client’s behalf or on behalf of another client or server. If the client is restricted to asking only for services that will be provided back to the client, that is called a paired client. The client is “paired” with the server for the purpose of service delivery. That does not imply that a client can request services from only one server; when services are requested from any server, they must be delivered on behalf of the requesting client. A client for an e-mail system usually is not considered to be paired because the service (e.g., delivery of an e-mail message) is performed on behalf of a client other than the requesting one. A client for an inventory analysis system probably would be considered as paired because the results would be returned to the requesting client. In practice, most clients can make both types of service requests. Question 2: Can services be delivered to the client without being asked for by the client? If the answer is yes, the system has push capabilities (also known as publish/subscribe or event registration). Those capabilities allow the server to send information to the client without having a specific request for each response. If the answer is no, it is a pull-only system. In a pull system, each server response must be preceded by a specific request. Question 3: Can the client have multiple simultaneous requests outstanding?

If the answer is no, it is almost always a synchronous system. That means the client functionality must be synchronized with the delivered service. Client processing is suspended until the server notifies the client that the request has been satisfied. This type of system is usually implemented via remote procedure calls (RPCs). If the answer is yes, it is an asynchronous system. In an asynchronous system, the requested service is not synchronized with the client processing. The client can continue processing after a service request has been issued because the provided service does not have to be synchronized with the client functionality. That, in turn, permits the client to have multiple requests outstanding; furthermore, the responses do not have to be in the same order as the requests. Some means must be defined to match responses with requests. From the comparison, it would be expected that asynchronous systems are somewhat more complicated to design and implement. However, the additional flexibility and throughput possible with these types of systems usually compensate for the increased complexity. Figure 12.3 is a configuration diagram for an asynchronous system using one client and one server.

Figure 12.3: Asynchronous system configuration diagram. Question 4: Can the client become a server and the server become a client? Given the previous discussion, the client, by definition, cannot assume server capabilities. Likewise, by definition, a server cannot assume client capabilities. Question 5: Can the server request from other servers the services needed to fulfill a request? This question is discussed in Section 12.1.2.2. Question 6: Can the client or the server be logical, physical, human, automated, or a combination? A client is not defined as a piece of equipment and therefore cannot be a physical entity. Given the definition of a client as part of a C/S system, the question becomes one of whether or not a C/S system includes a human user of the system. That question has been debated endlessly from psychological, technical, and other viewpoints. Although a case could be made for either assumption, the usual condition for the type of business automation under discussion is that the human is not a part of the system. If the automation inherent in an airplane control system were being considered, this assumption might be different. Given that a human user is outside the C/S system, the client cannot be human by definition. That leaves the client as an automated entity with human interface functionality defined on a logical basis. The server characteristics in this area are discussed Section 12.1.2.2. Question 7: Do the client and the server maintain persistent state information across requests?

The client maintains state information from request to request because it is the entity responsible for using the services of the server to perform some function needed by the human it serves as interface. In other words, the client is in control. The server answer is provided in Section 12.1.2.2. Question 8: What is the mechanism to request and deliver services? This question is answered in Section 12.3, which discusses the infrastructure.

12.1.2.2 Server characteristics A server is defined as that functionality of a C/S computing system that provides services to clients or other servers. Given that definition, those questions relevant to the server are considered in this subsection. Question 5: Can the server request from other servers the services needed to fulfill a request? As stated in Section 12.1.2.1, a server cannot assume client characteristics. However, servers must be able to request services from other servers in more complex C/S systems with multiple servers. In those cases, there must be a mechanism similar to that of a client for a server to request services in the same manner as a client. That function is called a requester function. A requester performs the same functions on behalf of a server as a client does on behalf of a human. It can have different characteristics, however, because the target for the services may have different characteristics. Question 6: Can the client or the server be logical, physical, human, automated, or a combination? Again, because a server in a C/S system cannot be defined as a piece of equipment, a server is not physical. Remember that the physical equipment called a server is not a server in the same sense as a C/S server. Also, a human is not considered as part of a C/S system; therefore, a server cannot be a human for the same reasons that a client cannot. That results in a server being defined in a logical sense as the provider of some set of services. Question 7: Do the client and the server maintain persistent state information across requests? The server may or may not maintain state information between server requests depending on the characteristics of the service provided. For example, most services provided by servers responding to client HTML queries over the Internet do not keep state information between requests. However, most servers utilized in the enterprise automation environment have services that do keep state information between requests. Whether state information is kept is not usually a server function but is determined on a service-by-service basis. As is evident from this discussion, servers can assume many different characteristics and still retain their identity as servers in a C/S system. As with clients, it is important to understand the context in which the C/S system is defined and operated. 12.1.3 Human interface configuration The client provides the interface between the C/S system and the human user. An important part of the client functionality is the mechanism for providing information to a human user and obtaining information from the user. That could be through a number of devices, including display screen, keyboard, cursor positioning devices (mouse, track ball, joystick), or audio speakers and microphones. More recent devices for virtual reality interfaces include hand and body position locators, tactile pressure transducers, and three-dimensional visual displays. Fingerprint readers and retina pattern readers also fall into the human interface category. The important human interface characteristic for a C/S system is not the specific devices used but the restriction they are intended for use by the client.

12.1.4 Logical connectivity There are two basic means of obtaining logical connectivity between client and server. One is direct program-to-program procedure (or subroutine) calls as defined through the programming language being used. That requires that both client and server be defined on the same computing platform and linked in some manner. This mechanism was first used to provide program-to-program communication, but it cannot be used when client and server are on different physical platforms. The second type of communication is the message, which must be used between a client and server on different platforms and which can be used if they are on the same platform. Messages are simply a string of formatted data that identify the source and the destination address of the information being communicated, the information itself, and some check or control characters that indicate whether the message arrived intact. Because most C/S systems are defined such that they can run on different physical platforms, the use of messages to provide communications is assumed for the remainder of this discussion.

12.2 Compound C/S systems There are three basic differences between simple C/S systems and the more complex compound C/S systems. In general: § Compound C/S systems utilize an infrastructure to provi de common services to the process-specific C/S clients and servers. The infrastructure is considered in Section 12.4. § Compound C/S systems utilize a large number of intercommunicating servers, both those that are process specific and those that provide infrastructure services. § Compound C/S systems utilize multiple clients that transfer information between them. As with simple systems, each server in a compound system can provide multiple services. It is also possible for different infrastructure servers to incorporate and offer the same service. In that case, the process implementer needs to specify the server that is going to provide a specific service. The server utilized also might change under different sets of circumstances. 12.2.1 Multiple servers Several different multiple-server C/S configurations are discussed in this section: singleserver types, multiple-server types, synchronous and asynchronous communications, and push and pull interactions. For systems with a single-server type, an illustration of the structure is shown in the configuration diagrams in Figure 12.4 for synchronous messaging and Figure 12.5 for asynchronous messaging.

Figure 12.4: Multiple-server, synchronous communication configuration.

Figure 12.5: Multiple-server, asynchronous communication configuration. The next extension permits servers to request services from other servers to complete the initial client-requested service. The extension is illustrated by the configuration diagram in Figure 12.6. The illustration assumes synchronous communication, but the concept is easily extended to the asynchronous communication format. When a server requests services from another server, the mechanism is that of a server requester, not a client.

Figure 12.6: Multiple-server, requester function configuration. Figures 12.4–12.6 have all been for services performed as the result of a pull or direct request on the part of the client. In these cases, there is a pairing of the service request and response. For every request, there is an associated response. As mentioned in Section 12.1.2.1, push services also can be defined. Push services are services delivered to the client from a server but not always as a response to a direct request from the client. Usually there are several responses to one request, and those responses are asynchronous with respect to the client processing. That possibility is illustrated in Figure 12.7. In general, there is an initiating request, such as client request a to server C in the figure. There are multiple responses back to the client from server C in response to the request, also labeled a in the figure. For example, say the request is to return a specialized version of a newspaper from a newspaper server (server C) every day. Then each day the requested information would be returned (pushed) to the client from server C with no further request by the client.

Figure 12.7: Multiple-server, push services configuration.

Other requests and responses also could be occurring asynchronously from the original request. Extend the example by allowing server C to send, via a request, the address of the client and type of information the client is interested in to another server (server A) that contains advertising for a given manufacturer’s products. If there is a match, then server A sends an unsolicited advertisement for one or more products (response a from server A to the client). That push can be considered to be another response to the original request. Note that there is no direct response to the request from server C to server A. That also is allowed with this type of C/S system. However, there is no guarantee that the request was ever processed by server A. The client also could have requested the same product information directly from server A, as indicated by the request and the initial response labeled b. Additional responses b could be the result of the server also sending information on pending sales or special deals involving the product of interest. These systems can get arbitrarily complex and involve a large number of servers over a period of time. That is both the strength and the weakness of this type of C/S system. 12.2.2 Multiple clients The tendency is to provide a client for any significant type of automation functionality. Some of the more widely used standard clients, in addition to clients defined for specific enterprise automation functionality, are as follows: § E-mail clients; § Workflow clients; § Web browsers; § Office services clients. Multiple clients, in the context of this discussion, means that they are being utilized as the interface to the same person in the performance of some enterprise activity. Each person utilizing the C/S system would have his or her own instance of the clients. The main requirement when multiple clients are involved in an overall C/S system is the ability to transfer information from client to client in a relatively easy way. That usually is accomplished through the resident infrastructure services of the platform on which the clients reside (e.g., drag and drop from one client window to another). Another method is to design the clients so they can interact directly with each other. That requires that the appropriate standards be available. It usually is assumed that all the clients will reside on the same platform because they all must be accessible by the person with whom they are interfacing. If a client is moved to a platform where it is accessed by means of another client on a different platform, for example, a Web browser accessing a workflow client, then the workflow client loses its client identity and logically becomes a server. The functionality may remain approximately the same, but because it no longer is the direct interface to a human, it cannot remain a client. The Web browser becomes the new client. This terminology has not been universally adopted, and in many situations the original client still is referred to as the client and the Web browser retains its identity as an interface device. Readers should be aware of this confusing situation when it occurs. While some of these points may seem minor, they are the source of considerable confusion in discussions of C/S systems. It is hoped that by explicitly addressing the issues there will be an increased understanding as to how to classify and discuss the structure and components of a specific C/S system. It should be noted that a given C/S system can behave in multiple ways. For some functions, it can be a single-server, synchronous system, while for other functions it can be a multiple-server (including infrastructure), asynchronous system with push features.

12.3 Infrastructure Implementing an automation system generally involves two types of functions and entities: those that contribute directly to the problem being addressed and those that perform a support role. In general, support functions and entities are common to a large number of process-specific functions. Support components usually are grouped under the heading of infrastructure. The infrastructure provides the environment that facilitates the use of the C/S system in providing the automation functions needed for the enterprise. A simple diagram of a C/S system that explicitly incorporates the infrastructure is of use in understanding the basic relationships. Such a diagram is shown in Figure 12.8.

Figure 12.8: Infrastructure relationships. The infrastructure in a C/S system consists of servers and associated services that can be used in support of process-specific clients and servers. A more familiar depiction of a C/S system using an explicit infrastructure is shown by the configuration diagram in Figure 12.9. In most cases, as shown in the figure, the client communicates directly with the infrastructure servers and only indirectly with the application servers. That occurs because of the fundamental nature of the infrastructure services as conduits and qualifiers for the application servers.

Figure 12.9: Infrastructure-oriented configuration diagram. The decoupling of an automation client from the automation server through the use of infrastructure servers has some desirable side effects. The service functionality resident in the application servers can be structured in such a way that many different automation clients, which may implement different enterprise processes, can utilize the same service components without change. Means to define and implement components with functions that can facilitate component reuse are discussed in Chapter 13. Although reuse can be achieved using other approaches, the C/S structure is a definite help. The process implementation methodology also takes advantage of the C/S approach to facilitate reuse in addition to providing other advantages to conventional techniques of automation specification and use.

Decoupling also can facilitate the use of legacy systems in new automation functionality. Legacy systems can be considered to be large, complex application servers. By isolating this functionality, it can be utilized in any fashion needed by a specific client. If some specialized access conditions are needed, they can be placed into an infrastructure server and possibly utilized for multiple legacy systems. That is not to minimize the considerable problems in the use of legacy system functionality. However, if the advantages of utilizing legacy system functionality outweigh the disadvantages of obtaining replacement functionality, than the C/S approach using a robust infrastructure can be of considerable value. The architecture and specification of the infrastructure and its services are a significant and separate subject. Although some later chapters briefly address specific aspects of the infrastructure, a more detailed consideration of the infrastructure is well beyond the scope of this book.

12.4 Summary Enterprise automation environments based on a C/S approach, along with a comprehensive infrastructure, can provide a flexible and powerful means of implementing business processes. With the increasing utilization of the Internet and its variations (intranet, extranet) as a communications and delivery vehicle for automation functionality, the C/S approach is a natural fit. However, the complexity of such systems demands that a systems engineering approach to their development and specification be utilized. Enterprise mission-critical C/S systems cannot be structured from the bottom up. Selected bibliography Adler, R. M., “Distributed Coordination Models for Client/Server Computing,” Computer, Vol. 28, No. 4, 1995, pp. 14–22.

Baker, J., et al., “The Role of Client/Server Computing Technology in the Management of Global Enterprises,” Proc. Portland Internatl. Conf. Management and Technology, Portland, OR, 1997, July 27–31, 1997, pp. 739. Drakopoulos, E., “Design Issues in Client/Server Systems,” Proc. IEEE 14th Ann. Internatl. Phoenix Conf. Computers and Communications, Phoenix, Mar. 28–31, 1995, pp. 487–493. Graham, W. C., and S. Majumdar, “The Performance of Multithreading and Scheduling on Client -Server Systems,” IEEE Internatl. Performance, Computing, and Communications Conf. 1997, Phoenix/Tempe, Feb. 5–7, 1997, pp. 87–93. Kanitkar, V., and A. Delis, “Real-Time Client-Server Push Strategies: Specification and Evaluation,” Proc. IEEE 4th Real-Time Technology and Applications Symp.,June 3–5, 1998, pp. 179–188. Savino, S. P., and S. M. Queroli, “Impact of Client/Server Computing on the Telecommunications Industry,” Proc. Internatl. Conf. Engineering and Technology Management, Vancouver, BC, Aug. 18–20, 1996, pp. 605–610. Zhang, T., and J. R. Hayes, “Client/Server Architectures Over Wide Area Networks,” 1997 IEEE Internatl. Conf. Communications, Montreal, June 8–12, 1997, Vol. 2, pp. 580–584.

Chapter 13: Dialog and action modeling

Overview Sufficient modeling has now been accomplished to allow the development of two closely related automation assets: dialogs and actions. The models of those two assets provide the mechanism through which process definitions are changed into functional specifications. Because actions are used as part of the definition of a dialog, dialogs are discussed first. That order allows the most natural progression from process definition to implementation. In addition, it is not necessary to understand the detailed action model to utilize the concept as part of the dialog model specification. The construction of the dialog and action models is designed to take into account the requirements of automation development in the emerging environment: § Direct process implementation; § Rapid implementation and change; § Reusable components at several levels; § Isolation of change propagation; § Flexibility; § Explicit utilization of business rules; § Utilization of a C/S approach; § Accommodation of an information model; § Compatibility with push and pull technology; § Compatibility with Internet standards; § Compatibility with component-based architectures. The structure of the dialog and action model assumes a robust infrastructure exists that can provide the common services as discussed in this and previous chapters.

13.1 Dialog context A dialog serves as a bridge between the business requirements as embodied in the process perspective, the technical specifications needed for design, and the deployed software of the enterprise automation environment. As such, a dialog must be in a form that can be used as the basis for custom product development, COTS product selection, or the incorporation of a legacy system functionality. Dialogs provide the continuity needed to allow a smooth transition from business requirements to implementation, as illustrated in Figure 13.1.

Figure 13.1: Bridging aspects of dialogs. This chapter specifically addresses the dialog model utilized by the technical specification anchor of the “bridge.” Other chapters are devoted to the other bridge anchors. However, to provide continuity in this presentation, a brief definition of a dialog in the business requirements anchor and the automation environment anchor also is

presented. Although the three definitions involved will seem quite different, they each describe a different view of the same entity. From the business requirements perspective, a dialog is a portion of a process (process fragment) with activities that can be performed by a single role performer without transferring control to another role performer. Using that definition, a dialog has no specific size and can be as small as a single process step or as large as an entire process. A dialog gets its name from the fact that it also can be considered a conversation (or dialog) between the user and the process automation functionality. From the automation environment perspective, one or more related dialogs define a workflow task that is implemented using reusable components and a suitable control mechanism. From the technical specification perspective, a dialog consists of a set of self-contained atomic actions that provide the functionality specification for the dialog and a cluster store that defines and contains the dynamic data utilized by the actions. The relationship between the automation assets that make up the three perspectives of a dialog is shown in Figure 13.2.

Figure 13.2: The dialog and action environment. In the following discussion, to ensure that the proper view is being addressed, the term dialog is used to imply the technical specification (design) perspective; process fragment and task imply the business and operational perspectives, respectively.

13.2 Dialog model Dialogs are the fundamental unit of process implementation. Dialogs can be implemented individually or in related groups without compromising the implementation. Multiple dialogs usually are required to implement a given process fragment. Some are derived from the business process and others because of technical and implementationspecific requirements. In addition, business processes may need associated management, administrative, and support processes. Dialogs resulting from all those sources may need to be executed as a part of the same task, as illustrated in Figure 13.3.

Figure 13.3: Multiple-dialog utilization. The same dialog also can be utilized in the design of process fragments from different processes. That latter ability provides for reuse at the process level. For example, a dialog that implements a process fragment that determines a customer’s credit rating could be part of a marketing process, a late payment treatment process, and an ordering process. The assumption, as should be the case, is that all the processes use the same set of steps to perform the procedure. 13.2.1 Clusters Dialogs that are simultaneously executing on a given workstation are called a cluster, and they usually are loosely coupled through the use of a common cluster store. A specific instance of a dialog must be able to be initiated and terminated, be able to be suspended, and be able to interact with a human or automaton user. That requires that a suitable set of states that can be assumed by the dialog must be defined. Those states are defined as follows: § An active dialog is a dialog that has been initiated and not explicitly suspended or terminated. § An open dialog is an active dialog that has the current capability to output information and receives information from a human interface. § A closed dialog is an active dialog that does not have the current capability to output information and receive information from a human interface. It may, however, initiate and complete actions based on information in the cluster store that does not involve the human interface. § A suspended dialog is a dialog that currently is not performing any processing and that cannot by itself initiate processing. § A terminated dialog is a dialog that has been removed from the cluster. Any outstanding transactions are lost. The states are controlled by the cluster control interacting with the human or automaton role performer instance. The cluster control is an infrastructure function that determines the states of those dialogs that are part of the operational cluster. Many dialogs can be active, but only one can be open at any given time. A cluster is an operational entity because it is defined only at run time. As discussed in Chapter 11, the information in a cluster store is intended to be self-defining and is available to all dialogs in the cluster on an equal basis. The set of tasks that implement an entire process is controlled through workflow techniques, as discussed in Chapter 15. Examples of dialogs that could be part of a cluster in the design of one or more business process would be as follows. § Business process fragment 1 advances the process through the business process fragment implemented (e.g., order entry). § Business process fragment 2 advances the process through a different business process fragment (e.g., previous order status). All information obtained as a result of either process is available to both processes because of the common self-defining cluster store.

§

Management process dialog allows a supervisor or other manager to take over an interaction with a customer and have all current information available. § Support process dialog provides information to the operator about any of the available functions. § Administration dialog terminates the process for any reason (e.g., customer hangs up). All dialogs have the same framework, as illustrated in Figure 13.4. The framework consists of a set of nine interrelated action categories and a cluster store that provides the mechanism for dynamic data storage. The action categories include those needed to provide the administrative functions of the dialog as well as the business-related functions required by the specification of the business process fragment. It is expected that the majority of the actions having an administrative category are common to almost all dialogs and, therefore, are highly reusable.

Figure 13.4: Dialog model framework. 13.2.2 Cluster store Actions of all dialogs in a cluster utilize a common cluster store for dynamic data. Although a cluster store is shown as part of a dialog framework and the dialog actions use the cluster store, it is not defined on a dialog basis. The cluster store has a separate definition that is tied to the existence of a continuing role performer instance. A role performer instance starts when the initial business process dialog is initiated by the role performer. It continues until the role performer terminates the original dialog and all associated dialogs that were initiated and required the same dynamic data as the first dialog. As long as the role performer instance is not terminated, no matter how many dialogs are initiated and terminated during the instance period, the cluster store stays in existence. That allows the utilization of instance information by any active dialog during the time the role performer instance exists. This aspect of the cluster store is illustrated in Figure 13.5. The up arrows indicate when a dialog is initiated and the down arrows when it is terminated.

Figure 13.5: Cluster store instance. For example, assume a customer calls to place an order. A role performer instance is created to perform the activities of the task dialogs that implement, in part, the order process (dialogs 1, 4, and 5 in Figure 13.5). While the order is being taken, the customer

asks the status of a previous order. That is a task (dialogs 3 and 6) in another process, but because of the circumstances, it is performed by the same role performer instance as used in the order dialog because it uses the same set of dynamic data. As shown, the two tasks are processed in parallel. Although the process and associated dialog have changed, the role performer instance has not; because of that, the cluster store remains intact. That allows the customer information obtained because of the order dialog to be immediately used for the status inquiry. Keeping the cluster store intact throughout a continuing role performer instance also makes the specification of the user interface easier. Because the same role performer instance also would necessitate some reasonable continuity in the user interface, the user interface can be defined on the basis of the cluster store rather than a dialog. Thus, no matter how many dialogs are inserted into and removed from the cluster, the user interface remains continuous as long as the cluster store is not terminated. That aspect is also illustrated in Figure 13.5. This type of operation requires the role performer to have the ability to initiate any workflows (processes) that may be needed as an adjunct to the handling of other processes. The use of scenarios is crucial to the design and specification effort. 13.2.3 Functional categoriesand phases An action is a specification for a specific type of operation to be performed during the invocation of a dialog. Each action in a dialog belongs to one of the following functional categories: § Initialization; § Instance data verification and validation; § Business process; § Instance data assembly; § Cleanup; § Termination; § Exception handling; § Control; § Help/tutorial. Regardless of which category an action is in, it will have the model framework as presented in the following section. Although the definitions of the action categories and some general usage examples are presented in the following discussion, it is not possible to provide an appreciation of the power of the categories until the methodology discussion in Part III. As will be evident from the following discussion, most of the actions in categories other than business process and help/tutorial are common to all dialogs. That is one powerful example of the reuse capabilities of this type of structure. Actions in the initialization category are utilized to place the dialog in a state suitable for execution. Such actions could include the retrieval and setting of appropriate parameters; the initialization of data in cluster store; and the updating of statistics, logging, and other administrative data. The actions do not necessarily result from the business requirements of the process steps but may be developed from the technical requirements of the dialog. Usually, a set of initialization actions common to all dialogs are developed and documented, in addition to the initialization actions specific to a given dialog. Actions in the instance data verification and validation category are utilized to ensure that data presented to the dialog via a workflow system are available and correct. Actions could include the examination of data for proper identification and to verify the availability of the needed data in the cluster store. These actions do not include any validation and verification that is associated with data retrieved from datastores. Actions in the business process category are the implementations of specific business functions. Such actions are directly dependent on the function of each dialog and therefore must be specified on a dialog-by-dialog basis. However, the number of possible actions in this category is limited to a relatively small number to facilitate their standardization and reuse in multiple dialogs.

Actions in the instance data assembly category are utilized in a manner similar to the instance data verification and validation actions. They are used to assemble the “folder” data necessary for the utilization of a workflow system. Actions in the cleanup category are utilized to place the dialog in a consistent state before terminating. That usually involves the update of persistent storage as nec essary and the performance of any necessary administrative operations (e.g., providing statistical information). A set of cleanup actions common to all dialogs usually is developed and documented. The common actions are in addition to the ones specific to a given dialog. Actions in the termination category are utilized to determine the type of termination the dialog will have. Some termination types are normal termination, forced termination, and error termination. The next step in the implemented process may depend on the type of termination. Actions in the exception-handling category are utilized to provide a consistent approach to error processing. These actions do not result from the functional requirements of the process steps but are developed from the technical requirements of the dialog. A set of exception-handling actions common to all dialogs usually is developed and documented. The common actions are in addition to the ones specific to a given dialog. Actions in the control category are utilized to interact with the infrastructure to provide the proper environment for the execution of the dialog. These actions do not necessarily result from the business requirements of the process steps but are developed from the technical requirements of the dialog. Control actions could include the obtaining of needed network resources (e.g., bandwidth) and the setting of appropriate timers. Actions in the help/tutorial category are utilized to provide a user-friendly environment for the human role instances (operators) that interface and interact with a dialog. These actions provide additional information concerning screen entities and generally are utilized for training or abnormal conditions. These actions can also be defined and utilized for other human interface types such as voice and video. 13.2.4 Dialog utilization The definition and the structure of dialogs provide several advantages: § They allow an effective and efficient transition from the business environment to the technical environment without the necessity of making sometimes arbitrary decisions. § They allow the implementation process to proceed in parallel, using wellsized units. § They provide for the maximum amount of common functionality that has to be specified, designed, and implemented only once. § They enable a similar approach to the validation and verification of the design of individual dialogs or combinations thereof with the intent of the originating business processes. Clusters encapsulate the control and local storage functionality needed by a human or automated user. Such encapsulation provides the framework for ensuring that the comprehensive specifications needed for this type of functionality are explicitly considered and stated. In addition, the framework enables changes and additions to be made in a cost-effective manner because the resultant effects are localized. Once the dialog actions have been defined, they can be used in two different ways. If a COTS or legacy system implementation for the dialog is being considered, the action specification provides a means of determining its suitability. If a custom development is indicated, the actions can be further defined and used as the specification for reusable components that would form the functionality needed. This analysis requires a significant amount of analysis and must be considered beyond the scope of this presentation. The following discussion, therefore, assumes a custom development using reusable components. The business processing actions are always preceded by the initialization and the source data verification and validation actions and succeeded by the recipient data transfer,

cleanup, and termination actions. Because of the well-defined progression of those action categories, the dialog is partitioned into phases, with each phase containing only one action category. Action usage in each phase must be completed before the actions in the next phase can be launched. The phase progression is the same as the category sequencing. Partitioning helps in the control of the dialog and also makes the search for actions that can be launched more efficient. Actions in the exception-handling, control, and help/tutorial categories can be invoked during any of the dialog phases, as needed. In addition to the designated actions, a dialog is also associated with a cluster store. There is one cluster store serving all tasks in the cluster. It is used to contain any data produced as a consequence of the actions executed in any dialog of the cluster. In addition, the cluster store contains a set of common information, such as the date, time, operator profile. A cluster store is a special case of a datastore or information structure, as defined in Chapter 11. It can serve as the source or sink of information as well as an authoritative source for the information. Although it is defined on a temporary basis, it is useful for consistency to define a cluster store in the same way as a persistent datastore or information structure.

13.3 Action model Chapter 12 discussed the concept of C/S systems. In most cases, the communications required by such systems consists of response/request pairs. In the case in which a unit of work is involved, a message/response pair is called a transaction. For convenience, in this chapter, a C/S communication that consists of a message/response pair is called a transaction even though there is no state change in the server (e.g., retrieval of data from a datastore). This use of the terminology makes the subsequent discussion somewhat easier to structure and follow. From the client perspective, each transaction must involve four supporting functions or components. § The determination of when to initiate a transaction (launch condition); § The formulation of the request; § The validation and verification of the response; § The analysis and dissemination of the result information. Those components, along with the transaction itself, constitute an action. The action model framework is shown in Figure 13.6. Actions consist of the transaction functionality along with all the support needed for the client to effectively utilize the transaction. Support functions have access to the cluster store and can manipulate any of its data as determined by the specific specification of the support function.

Figure 13.6: Action model framework. The relationship between actions and the cluster store is strong. By definition, action request and launch data must come from the cluster store, and action response data can be entered only into the cluster store. That restriction provides a mechanism for close

control over action specification. Of course, any persistent data that the server needs or produces in processing a client request can utilize any available datastore. An action is closed or self-contained in the sense that it encapsulates all the support functions with the transaction itself. In fact, a group of actions, with the proper platform infrastructure, constitute a reasonable segment of automation functionality without the need for any additional software. By their very nature, actions implement an asynchronous messaging structure, because the launch of any action does not prevent the launch of any other action. That can be circumvented, but it is difficult. Matching responses to requests also is rather easy, because responses can carry a common identification based on the identification of the action involved. One significant advantage of utilizing a closed structure is that any of the components of a given action can be changed without directly affecting any of the other actions. The change could result from many directions and include a need to change the launch condition, the destination of the transaction, or the determination of what constitutes an acceptable response. Isolation of changes is a distinct advantage to this type of structure. There can, however, be indirect consequences of changes to individual actions because of alterations to the data available in cluster store. For example, if an action is changed such that the data needed to launch another action are delayed or not obtained at all, the second action would never be launched. That might be a correct result of the change or an artifact indicating that further changes are necessary. Although action changes are localized, there can be consequences that must be evaluated and corrections made as needed to ensure the integrity of the dialog functionality. In practice, actions closely resemble the production rules in a classic knowledge-based system. The infrastructure required to utilize a dialog-and action-based structure operates in a manner similar to that of an inference engine with forward chaining. Although the resemblance is useful for comparison, there are some significant differences. Actions are production rules only in the sense of the launch criteria. Once launched, actions are active until a response is received. That can be a considerable length of time and requires that the infrastructure engine also consider the condition in which actions are still outstanding before assuming that the rule set (actions) have become quiescent. An entire action can be reused, as can any component or set of components of an action. The usual condition is the one in which all the components of an action are reused except the launch condition. The launch condition varies according to the specific circumstances of use. Because actions and their individual components are considered to be automation assets, the administration and management of action reuse can be handled through a repository function. It will be shown in the methodology presentation given later in this book that the structure of the action framework model is specifically designed to support and encourage software component reuse. The information contained in any of these components can be considered to be in the form of business rules. The business rules are explicit statements of how the actions, and hence the dialog, will operate. It is possible to put all the rules in a repository using an appropriate syntax and taxonomy. An examination of the rule set as a whole can then be undertaken to determine such aspects as consistency. 13.3.1 Launch condition In procedural software, the launch condition, that is, the decision to send a transaction, is determined by reaching that point in the code where the transaction sending procedure resides. There is no separate determination of whether or not to send a transaction other than that programmed into the software.

The launch condition support function includes all the work necessary to determine when the conditions for launching the action transaction have been met. Actions have a launch condition that is directly attached to the action. Those conditions can be of three kinds: data, state, and time. An example of a data condition is the availability or unavailability of specified data in the cluster store. An example of a state condition is the previous execution or nonexecution of another transaction. An example of a time condition is the attainment of 2:00 P.M. Because all the data are placed in cluster store in some form, the launch condition essentially is determined by the state of the data in cluster store and is defined by the “true” or “false” evaluation of a predicate expression that contains the data elements of interest. For example, assume that an action function is to retrieve customer contact information from the customer profile datastore and put it into the cluster store. Further, assume that the action is not needed unless the customer is calling for a legitimate purpose as determined by the value of the call_purpose data element. That element has cluster store as its information structure (authoritative source). Cluster store is also the primary—but not the only—source and sink for this data element. The launch condition of the retrieve customer contact information action might be expressed as follows: call_purpose = order, call_purpose = inquiry, or call_purpose = complaint. Anytime the call_purpose data element exists in cluster store and has a value of order, inquiry, or complaint, and the task in which this action resides is active, the action will be launched. Exactly when the launch occurs is a function of the infrastructure that supports this component. Once launched, the other components of the action become operational. The transaction message is formulated and sent, and the response is validated and disseminated as determined by the action definition. If the purpose is not one of those values, the action is never launched. Note that no explicit decision point is required to make that determination. The launch condition for every action in the dialog is evaluated whenever cluster store changes. A number of other implicit conditions are attached to launch conditions, such as “an action can be launched only once in a task unless its launch state is explicitly reset.” 13.3.2 Request formulation Transactions are implemented via a request/response message pair. It is, therefore, necessary to compose the message and set its operational characteristics as determined by the action definition. Some of the characteristics that may need to be considered explicitly are as follows: § Logical destination address; § Message format identification; § Action identification; § Request data required (must be in cluster store); § Cluster store data element value to be set on error condition; § Timeout parameters; § Infrastructure information: security parameters, data type of expected response (e.g., streaming audio or video, text, image, multimedia), special handling, accounting information. There are several advantages to attaching the message formulation function to the action. Different actions having the same transaction could utilize different characteristics depending on the context in which they are used; those changes could be made without having to consider the effect on other actions. Because all the data for the request message must reside in cluster store, it is relatively easy to determine (1) if an error condition exists (data not present) and (2) the proper recovery procedure.

13.3.3 Response validation and verification As a part of the infrastructure supporting the use of the action model, the identification of a message as a response to a request, a push message, or an unidentifiable message is made. A response message also could be generated by the infrastructure timing mechanism in response to a timeout condition as specified by the request formulation support function. If it is identified as a response, the message is associated with the correct action and the attached response validation and verification support function is invoked. That support function contains the information needed for it to determine if the action response message indicates successful completion of a transaction or that some problem has occurred (e.g., definition of expected condition codes and their meaning). If a problem has occurred, the determination as to what corrective procedures should be taken also is contained as a part of the specification of this support function. This support function is not intended to determine if any of the data returned are valid. It is meant only to determine if and how the transaction completed. The validity of the operational data must be determined by other actions. Messages are identified by the infrastructure as push messages by using information in a nonshared datastore that results from the operation of previous actions designed to provide that information. Push messages also put their information into cluster store, but there is no equivalent to the response validation and verification support function for those types of messages. 13.3.4 Analysis and dissemination of results Assuming that the response validation and verification function has determined that the response is valid, the analysis and dissemination of results support function examines the operational data returned to decide how the data should be processed. In most cases, the data simply are placed in cluster store. However, there may be conditions when some or all of the returned data will not be placed in cluster store. Another possibility would be to rename the data elements before they are placed in cluster store. One situation in which that could occur is when the same data element is already in cluster store. The default generally would be to not replace that element with the current one. However, the information given to this support function could indicate a variety of conditions and responses. If the data element already appears in cluster store: § Discard the data element; § Replace the element with the current value; § Rename the response data element and place it in cluster store; § Rename the cluster store data element and place the response element in cluster store; § Add the response element value to the cluster store data element through the use of a multivalued construct. If elements are renamed, other actions must be defined that are aware of the potential name change and can accommodate the newly named element. By associating the analysis and dissemination support function with each action, a different determination can be made for each action without directly affecting any other action. This again serves to localize changes. 13.3.5 Action types In addition to having the same framework, actions are closely constrained as to the definition of their functionality to promote their use in multiple processes and dialogs. Those constraints consist of two forms. The first limits the actions to a small number of types. The second requires all actions to obtain or place data in cluster store, depending on type. An action in any dialog category can consist of any of the defined types. Action constraints are illustrated in Figure 13.7.

Figure 13.7: Action data transfer dynamics. The definition of each action type is based on the specifics of the work performed by the contained transaction: § Shared (by multiple clients) data CRUD; § Nonshared data CRUD; § Human interface data CRUD; § Resource status request (retrieval or update); § Data transformation; § Enable push transfer. Although those definitions of action types may seem that they are limited to database access only, that is not the case. They can accommodate any functionality required by the process being implemented using the concept of intelligent datastores defined in Chapter 11. The types are defined as they are to keep the number needed to a minimum. As an example, consider the following: The defined purpose of an action is to obtain the cost of a specific equipment configuration and update a statistics database that accumulates the configurations utilized in all costing inquiries. The transaction request contains a specific equipment configuration. The transaction response to the action is the cost of the configuration. The server functional component that calculates the cost based on the equipment configuration also updates the configuration statistics. As far as the action is concerned, the transaction request and response are in the same form as a standard database retrieve. The key is the configuration, and the returned data are the cost, hence the type definition of this action as a shared data retrieve. It is shared because of the assumption that dialogs other than the one utilizing the action can request the same functionality. The actual effect expected must be part of the specification of the transaction (and the action by association). The specification can be as complex as necessary, but because access to the functionality of the server is always through the use of a request/response pair, the action, regardless of definition, can always be characterized as a data CRUD type of activity. Although the possible complexity is arbitrary, in actual practice action complexity usually is quite small. That occurs because it generally is easier to define several actions, each with limited functionality, than one action with a large number of operations. Some rules of thumb that can be used to indicate the proper amount of functionality defined for an action are discussed in the methodology presentation in Part III.

This limitation to a small number of action types is necessary to maximize the potential reuse of previously implemented actions. Defining actions with a relatively small amount of functionality also helps in that regard. Any available actions from prior dialog decompositions also are limited to these types. This restriction greatly enhances the probability of obtaining a match between actions resulting from the current dialog decomposition and those defined during previous or future executions of the methodology. Detailed definitions of each of the six action types follow. The shared data (CRUD) action type is used to move data between shared (multiple clients) logical datastores (persistent storage) and cluster store. Shared datastores are utilized by multiple dialogs. The datastores can have any degree of intelligence associated with them. Examples of these types of actions would include the retrieval and update of customer contact information, the update of a switch routing table, the determination as to whether a specific telephone was active, and the retrieval of a telephone number for a new customer. The last retrieval action would require a datastore with some intelligence since a considerable amount of processing might be needed to determine the retrieved information and update the necessary inventory information. The nonshared data (CRUD) action type is used to move data between nonshared persistent logical datastores and cluster store. Nonshared datastores are not utilized by other clients and are therefore client specific. Nonshared datastores are used to keep information concerning the client that must be used by all tasks executed by the client. Nonshared datastores can be used to keep security, processing characteristics, allowable push messages, and other client-based data. The human interface data (CRUD) action type is used to move data between the human interface devices, both input and output, and cluster store. The human interface can be considered to be a specialized type of datastore where the information can be created (e.g., new window displayed), retrieved (e.g., information entered by an individual using a keyboard), updated (e.g., the information displayed in a given window is changed), and deleted (e.g., a window is removed from the display). The human provides the intelligence for this type of datastore. The human interface functionality and the action implementation can be on the same or different platforms. That allows dialog containing these actions to be on the client or a server while the human interface functional components accessed by these actions reside on the client. The state retrieve and update action type is used to move state information between logical entities represented by state machines and cluster store. As with datastores, the state machines can have any degree of intelligence associated with them. Examples of these transactions would include the retrieval of the operational state of a switch and the availability of an operator. It is not possible to create or delete states using this action type because that would alter the state machine itself. The data transformation action type is used to transform data in the cluster datastore. Cluster datastore is used for both the input and the output of this action type. An example of a data transformation transaction is an algebraic manipulation of cluster datastore to produce the data needed for a retrieval request. The enable push transfer action type is used to allow messages to be accepted and their data placed in cluster store without an associated request message. By utilizing an action to determine when and which messages will be accepted, the occurrence of unsolicited messages can be managed. The data from this action are placed in a nonshared datastore, where it will be used by the infrastructure. Because it interacts with a nonshared datastore, it could be included in the definition of the nonshared CRUD datastore action. However, this type of action is of such importance that it was given its own type. Although action typing does not change the format or operation of the action, it does provide three important functions: § The facilitation of the identification of similar actions that already have been defined and implemented. These candidate actions can then be used in whole or in part in the implementation of the current action. § A target set of actions for the specification of process functionality. This aids in performing the constrained decomposition procedure. § A means to analyze the operation of the process fragment using a standard approach. This allows the identification of gaps, overlaps,

conflicts, and inconsistencies in the process specification that cannot be easily identified at the process level. Experience has shown that this type of analysis frequently shows a need for changes at the process level. These action types have resulted from experience with using the action type concept for the technical specification of process fragments. Further analysis and research may indicate the need for a different number of types or a different definition for the ones presented in this section. Because of the way that actions are defined, that easily could be accomplished. However, to this point, there has been no indication that such changes are needed.

13.4 Action dynamics Without using an automated simulation tool, it is difficult to provide an adequate feeling and understanding of action dynamics. However, to complete this discussion, it is necessary to provide at least a rudimentary indication as to how an action system operates. Figure 13.8 depicts a simple dialog that has a system of five actions and a cluster store. The launch criteria and the response variables and values are shown for each action. For the current purpose, it is not necessary to define the detailed operation of the actions. In an actual implementation, all the action data would have to be specified. It also is assumed for this simple system that each action completes successfully.

Figure 13.8: Action dynamics case 1. At the start of the dialog, it is assumed that cluster store contains two variables and associated values, V1 = A and V8 = H. The launch criterion for each action is examined at the start of the dialog and every time cluster store changes in some way. The time periods represent the time between cluster store changes. The elapsed time represented by a time period is not fixed. It depends on when cluster store changes. Because the actions are asynchronous, that period can vary considerably, depending on how long server processing takes for a given action. Thus, the elapsed real times for the time periods may be different. At every vertical line between time periods, the cluster store changes in some way, and the launch criteria for all actions that have not yet been launched are examined. Remember that only data in cluster store are considered when launch criteria are evaluated. If the launch criterion evaluates to “true,” the action is launched. Multiple actions can be launched at the start of any time period. If no action is launched and there are no outstanding transactions, the dialog is completed and terminates. If there are

outstanding transactions, they must be completed before the dialog terminates, since their response variables may cause additional actions to launch. At the start time line, the only action with a launch criterion that is true is action 1, and it is launched at the beginning of time period 1. It completes at the end of the time period, and the response data are added to cluster store. The action launch criterion is then evaluated and becomes true for both action 2 and action 3, and they both are launched at the beginning of time period 2. Action 3 completes at the end of time period 2, and its response data are placed in cluster store except for the value of variable V8. Note that variable V8 is already in cluster store with a value of H. In this case, the response analysis and dissemination support function for action 3 has instructions not to replace the values of response variables already in cluster store. As discussed earlier, other instructions also could have been provided. The transaction of action 2 is still outstanding at the end of time period 2 and does not contribute to any changes in cluster store. The launch criterion again is examined, and action 4 launches. Action 2 completes at the end of time period 3, and its response data are added to the cluster store. No new actions are launched at the beginning of time period 4, but the transaction of action 4 is still outstanding, so the dialog continues. Action 4 completes at the end of time period 4. No new actions are launched and no transactions are outstanding, so the dialog completes. Note that for this task, action 5 did not launch because its launch criterion was never true. It is not necessary for all actions in a dialog to launch. In fact, in most cases, the majority of the actions in a dialog will not launch for any given task. For different tasks, the actions that launch and those that do not will be different. It all depends on the specific conditions present for the dialog, depending on the scenario that is being followed. As an example, the specific operational conditions of the dialog will be altered (e.g., the scenario being followed is different) by changing the initialization cluster store variables and values. The definitions of the dialog and actions are the same as in the previous case. In this situation, different actions will launch and not launch; those that do may launch at a different time. That is illustrated in Figure 13.9. Note that actions 1 and 4 do not launch, while action 5 does launch. Actions 2 and 3 launch as they did in the previous example, but they now launch at the beginning of time period 1 rather than time period 2.

Figure 13.9: Action dynamics case 2. To begin the dialog, some designers use initialization category actions with launch criteria that always evaluate to “true” regardless of cluster store data. That is easily accomplished by using a launch criterion of “1.” Other designers prefer to have initial variables and values placed into cluster store by action of the infrastructure prior to

dialog start if the infrastructure allows that procedure. Both methods work well, and it is simply a matter of preference. Somewhat more complex examples of dialog and action designs are given in the methodology presentation. Although it may seem more complex than procedural programming, there is actually more control over the operation of the dialog using the nonprocedural approach. The artificial sequencing of operations required by conventional coding does not get in the way of explicitly specifying the conditions needed to perform each action. By using suitable simulation techniques along with the defined scenarios, the operation of the actions in the dialog can be examined and changes made as appropriate.

13.5 Consequences Direct process implementation and the use of nonprocedural programming techniques require a somewhat different orientation. That includes the personnel responsible for requirements determination and the software designers who will design and implement the functionality and data models needed. The individuals involved will require a significant amount of training and technology transfer, and the enterprise must allocate the time and resources needed. The structure of the dialog and action models require that a number of difficult issues and decisions be considered for every dialog and action in a dialog. That makes it difficult to “forget” to specify or implement a necessary piece of functionality, with its attendant negative impact on quality, resources, and customer satisfaction. That information is useful if a COTS product or a legacy system is considered or if a custom implementation using the structure specified in this chapter is indicated. The dialog and action frameworks also enable the reuse of a significant amount of functionality, either through the utilization of the common functions needed for dialog implementation or the use of available business-oriented software components. Although a large amount of information is generated in the action specification process, its regular structure makes it possible (though difficult) to handle, even without automated assistance. Because of the amount of initial information needed, this specification activity is definitely a front-loaded effort. That is somewhat in conflict with current approaches of building something quick and then modifying it until it works or seems to fit the requirements of the users. While such an evolutionary approach certainly provides the instant gratification that seems to be a need for contemporary activity, it cannot provide the product quality level and future change flexibility that also are needed. The middle ground is to use the front-loaded analysis for quality but do it in a timely fashion. Because dialogs can be designed and implemented in parallel, multiple teams can be used. As a dialog is designed, it can be implemented either through the reuse of previously developed functions or by the development or purchase of commercially available ones. The ability to overlap the development of individual dialogs and reuse previously developed components can greatly improve the speed at which a process implementation can take place without sacrificing the quality of the resultant product. Use of Internet techniques, standards, and products as the underlying mechanism for implementing business processes does not reduce or eliminate the need for careful analysis of the functionality required, as outlined in this chapter. For example, by considering actions as Java applets and their infrastructure support, including the cluster store, as part of the Java machine definition, the dialog-and-action structure meshes quite well with an Internet-based solution. The key is that an Internet-based approach may facilitate implementation but it cannot replace the need for careful analysis. Selected bibliography

Davidson, D., “The Logical Form of Action Sequences,” Essays on Actions and Events, Oxford: Clarendon Press, 1980, pp. 105–148.

Krishnamurthy, B., and D. S. Rosenblum, “Yeast: A General Purpose Event-Action System,” IEEE Trans. Software Engineering, Vol. 21, No. 10, 1995, pp. 845–857. de Lemos, R., and A. Romanovsky, “Coordinated Atomic Actions in Modelling Object Cooperation,” Proc. 1st Internatl. Symp. Object-Oriented Real-Time Distributed Computing, Kyoto, Apr. 20–22, 1998, pp. 152–161. Nett, E., and B. Weiler, “Nested Dynamic Actions: How to Solve the Fault Containment Problem in a Cooperative Action Model,” Proc. 13th Symp. Reliable Distributed Systems, St. Augustin, Germany, Oct. 25–27, 1994, pp. 106–115. Santos, F. A. A., et al., “Action Concepts for Describing Organised Interaction,” Proc. 30th Hawaii Internatl. Conf. System Sciences, Wailea, HI, Jan. 7–10, 1997,pp. 373–382.

Chapter 14: Software component modeling Overview The purpose of defining and modeling software components as automation assets is to provide an effective mechanism for obtaining software reuse. This chapter defines a component reuse model and framework that can substantially increase the amount of reuse obtained from process implementation activities. The reuse of software has been a goal of the computer software industry since the time of the earliest commercial machines. The author personally has been involved in various efforts since the late 1960s. Even with that rather lengthy time period, considerable confusion remains as to what exactly is meant by the term software reuse and how it can best be applied in practice. The confusion extends to the definition of the metrics needed to indicate the extent to which reuse is—or is not—being achieved. Some discussion concerning the implications of initiating an extensive reuse program is also provided. The migration to a reuse-oriented approach to software development requires a well-thought-out plan that considers all the many aspects involved. Those aspects include management, social, and financial/accounting considerations, in addition to the purely technical aspects. Also required are the means and the will to carry the plan forward. If any of those is lacking, the attempt to reuse software as a basic business doctrine will be a failure, no matter how well conceived and defined the underlying framework and strategy might be. Unless management fully backs the reuse concept and is prepared to make whatever changes are necessary to the basic functioning of the enterprise, it probably is better that a reuse program not be started.

14.1 Duplication of effort In any enterprise, there are many instances when internal duplication of effort occurs. Unless that is caused by basic business philosophy (e.g., General Motors’ different divisions each trying to sell a car to the same customer or a development organization promoting the development of two or more different approaches to the same problem in order to select the best approach), it usually is caused by structural problems between two or more enterprise organizations. Poor communications, distrust, and arbitrary restrictions are among the many possible causes. Methods of reducing unnecessary duplication of effort are an interesting topic in its general form. However, for the purposes of this discussion, only the potential duplication of effort existing in process implementation and associated software development is of

concern. In the discussion that follows, the terms duplication of effort and duplicate effort are used in that context. Reuse is one type of duplication-of-effort reduction that is usually associated with the software implementation process. Because the focus of this discussion is specifically directed toward implementation activities, it is limited to the reuse aspects. Chapter 13 defined multiple types of reusable software “parts.” However, to keep this discussion relatively generic, the term component is used for any type of software part that is intended to be reused. 14.1.1 Reuse concept What the term of reuse specifically refers to is the intended use of the same software component in multiple products. Such a component can then be considered to be reused. The concept comes from the manufacturing industry, where the reuse of individual components to create customized products is utilized. If, for example, an order is placed for a water pump with specified characteristics, the manufacturer could assemble a suitable pump from an inventory of existing parts. That example also illustrates another major requirement for reuse. The purpose of reusable components is to allow the development of a product by assembly of the components (usually from inventory), rather than to design and implement the product as a custom unit, developing everything from the ground up using only the stated requirements. Thus, while the use of the same functionality in multiple projects is certainly the essence of reuse, it must be done in the context of an assembly methodology. If that definition is not rigorously enforced, reuse retains the hit-or-miss characteristic that it has historically possessed. There is another aspect of reuse that needs to be addressed. What is the status of software that is copied and then altered? Does that constitute reuse? Historically, such cases have been considered as a form of reuse, although there is considerable vagueness concerning how much of the original software would have to be utilized to maintain the definition. In fact, it probably is safe to say that, historically, partial reuse was the dominant form of reuse. To avoid too much conflict with the historical definitions, for the purposes of this discussion, the author also, rather reluctantly, considers partial usage to be a reuse condition (and not just a reduction in possible duplication of effort). 14.1.2 The importance of reuse The importance of reuse lies not so much in the elimination of duplicate coding but in the ancillary functions, such as testing and integration. Coding is a relatively minor part of software development. If all reuse did was eliminate that activity, it probably would not be worth much effort and certainly not the amount of attention that it historically has enjoyed. The major benefit that reuse should provide is a