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 self- consistent 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 situation- by-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 classes 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. 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. 5. 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)? [...]... 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... 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... 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... 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... 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... 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... 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... § 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... 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. .. 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 . § 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. 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. 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