Business Process Implementation for IT Professionals phần 2 pot

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 use

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

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

enterprise areas other than the automation assets

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

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

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

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

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

relationship

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

of the automation methodology and the architecture of the enterprise automation

environment Those automation assets are defined and discussed in Part II

2.3 Asset model

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

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

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

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

self-examination

Selected bibliography

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

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

231–245

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

Management of Data, 1995, pp 451–452

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

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

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

Chapter 3: Life cycle management

Overview

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

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

Figure 3.1: Basic life cycle process stages

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

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

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

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

3.1 Creation stage management

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

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

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

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

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

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

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

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

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

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

3.1.1.1 Class models

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

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

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

by process and software reuse) requires a certain amount of enterprise-level modeling Figure 3.2 shows the position of the class model in the enterprise

Figure 3.2: Position of the class model

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

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

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

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

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

structure is of considerable importance

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

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

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

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

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

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

§ To increase insight and understanding about the asset class;

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

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

in the class;

§ To identify deficiencies in the class;

§ To make decisions about changes to the class

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

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

automation asset classes

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

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

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

meaning as that defined earlier

§ Every asset class is ideal

§ The class of all asset classes is ideal

§ The class of relationships between asset classes is ideal

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

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

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

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

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

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

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

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

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

the class is not sufficient Gaps may require the procurement of

additional elements under conditions not conducive to proper

consideration

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

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

inconsistencies, and superfluous elements

§ Conflicts, which indicate that element requirements were missing or

not correctly articulated Conflicts are a major source of bugs and

faulty operation

§ Inconsistencies, which indicate that the provisioning environment was

not adequately characterized They are also a major source of bugs

and faulty operation

§ Superfluous elements, which indicate incomplete or inaccurate

information about existing items They waste resources and can

confuse the provisioning process by offering unnecessary choices

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

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

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

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

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

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

specifications and possibly some associated embodiments The term initial applies not

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

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

3.1.1.2 Unit models

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

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

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

Figure 3.3: Generic unit model

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

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

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

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

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

3.1.1.3 Model integration

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

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

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

becomes extremely difficult

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

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

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

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

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

Figure 3.4: Integration of class and unit models

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

be provided by a new component:

§ In an existing building block;

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

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

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

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

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

3.1.3 Procurement

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

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

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

figuration);

§ 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

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

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