Business Process Implementation for IT Professionals phần 9 doc

The activities in step 4 map the parts of the automated actions to existing or proposed physical components that have the needed functionality.. The definition of external software compo

10 Demonstrate action prototype to stakeholders Arrange a session with

the stakeholders to observe the operation of the initial or revised

prototype and determine the conformity of the prototype operation to the needs of the business and the individual stakeholders At the end of this step, the stakeholders must determine if the action definitions,

functionality, and relative sequences meet the needs of the business

process being implemented That involves comparison of the animation

of the process steps with the animation of the actions Because the

functionality and other specifications of both the process steps and

actions are available, this comparison certainly is possible, although

somewhat subjective at this point If the two are not compatible, the

actions or process steps must be reexamined to determine the cause

Assuming that the comparison produces an agreement between the two, the larger question, which is the same for all prototype uses, must be addressed: Given a feeling for the process implementation that the action prototype

provides, do the associated process steps really meet the underlying

business need? As the prototypes become more sophisticated and closer to the final product, that question becomes easier to answer However, it is

desirable to get an answer at the earliest possible time to reduce rework and save development time Even at this early stage, some feelings for the

implementation can be obtained and the question at least asked, if not

answered If and when the answer to the question is “No,” the process spiral must be reinitiated and the difficulties resolved before continuing

11 Obtain necessary approvals If approvals are needed to continue beyond

step 3, they need to be obtained before proceeding The action

prototype, the opinions of the stakeholders, and the hard deliverables

from this step (action templates, prototype animation results) should be sufficient to demonstrate the suitability of the action definitions and the

ability to proceed

12 Enter new or updated action specifications into the repository All

information obtained as a result of step 3 should be entered into a

repository where it is available for future needs Because maintenance is considered an integral part of the methodology, the information may be needed for a considerable length of time and may be useful to individuals other than those involved in the initial development

20.6 Linkages to other steps

Step 3 must be invoked whenever a change is needed in the set of actions or their specifications Changes in the action set could result from activities in any step of any spiral and consequently cause a direct transition to this step or to other steps that may

be affected (e.g., step 1) before this step is reinvoked The exact transition sequence depends on the circumstances If the changes are relatively small, the time required for a reinvocation of step 3 should also be relatively quick, although all the activities would need to be utilized at least once during invocation of this step

The usual transition to step 3 is directly from step 2, where the dialogs are identified and specified The initial specification or changes to the specification of the dialogs always require an analysis of the needed actions

There are three possible transitions from step 3 upon its completion One is to step 4, where mapping of the actions to available software components is considered The second is to step 5, where the human interfaces are designed and developed The third transition is to step 6, which occurs when the action specifications affect the workflow design All those subsequent steps can be performed in parallel, although changes in any step may require step 3 to be reinvoked with subsequent reinvocations of steps 4, 5, and 6

If step 3 raises questions concerning the process map or dialog definitions, a

noncompletion transition to step 1 must be made and the process spiral reiterated until those questions are resolved A number of reinvocations of step 1 almost certainly will be made from step 3 because the increased level of detail made available through the step activities will uncover process and dialog problems

20.7 Postconditions

Step 3 is complete and may be terminated for a given development when the following information and conditions are present as a result of the current step invocation

§ All step activities have been considered at least once

§ As complete a set of actions as possible with available knowledge has been defined for each dialog

§ A determination of which existing actions can be reused has been made

§ An action prototype is available

§ A completed action template is available for each action The software

component information is not required

§ Appropriate animation of the action prototype has been performed and the

results verifi ed

§ The business and technical stakeholders have been involved as needed and agree with the results of the action animation It is not necessary that the

business-oriented stakeholders review the action definitions (they are

considered part of the detailed design)

§ All relevant action information has been entered into the appropriate

repository and updates verified

§ Any necessary approvals have been obtained

At the conclusion of step 3, all affected stakeholders must agree that the action

animation, as it is currently defined, accurately depicts the intended operation of the process The results of this step may indicate that further refinement of the process is necessary

Chapter 21: Step 4: Map actions

as well as future ones

The activities in step 4 map the parts of the automated actions to existing or proposed physical components that have the needed functionality Transactions are mapped to sharable (external) software components, while support functions are mapped to

software components (internal) that are not shared but that can be reproduced and changed to fit the specific needs of the action

External software components are accessed with request messages and reply with a corresponding response message The message pairs, as well as the software

component functionality, must conform to the requirements of the action Unless

specifically stated, the message pair specification is considered part of the software

component it accesses Internal software components are accessed through any

mechanism that is supported by the action execution environment (e.g., sub-routine calls)

Existing components are analyzed to determine how much of the functionality needed by the action specifications can be met through their use The definition of external software components includes available COTS products and legacy systems as well as

functionality developed specifically for the process implementation New or augmented software components are then proposed to provide required transaction functionality not covered by existing ones A similar procedure is utilized to obtain the functionality required by the support functions The provisioning of any proposed internal or external software component is subject to management approval, and their availability depends

on the resources allocated

In a similar fashion, other activities in this step map the human action(s) to existing instructional publications (policies, practices, and procedures) In essence, they are a form of the business rules utilized by the enterprise Existing publications are analyzed to determine how much of the functionality of new human actions can be met by existing policies, practices, and procedures New or augmented publications are then proposed for functionality not covered by existing policies, practices, and procedures

21.2 Preconditions

The following conditions must exist before work on the activities of this step can be initiated It also is assumed that, in addition to the items explicitly listed in this section, any result from an earlier step or spiral can be used to provide guidance or background information

§ Filled-in action specification form for each action Because the software

component information is added in this step, this information does not have

to be included in the form, although it may be available when this step is

reinvoked

§ Existing external software component documentation from the repository

§ Existing internal software component documentation from the repository

§ Existing business rule (policy, practice, and procedure) documentation from the repository

§ Existing enterprise standards documentation from the repository

§ Infrastructure architecture specification and as-built configuration from the

repository

§ The list of all actions that have been previously considered during the

examination of other dialogs and that are already mapped to software

components These do not have to be remapped but can be utilized as

defined This information is in the repository

§ Any information that would significantly affect the implementation or use of

proposed components This type of information could include possible

relationships, restrictions, and operational needs This information is

obtained, but not utilized, from previous steps and is documented in the

repository

21.3 Description

Step 4 has three fundamental aspects related to the mapping function The first is to provide the initial mapping between the actions that form the logical design of the dialog and the physical components (automated or manual) that will be used for its

implementation The mapping may be to existing components or to proposed

components when there is no suitable existing component

The second aspect is to analyze the proposed set of action mappings over all the

available process dialogs This analysis is designed to ensure that a consistent set of

mappings is obtained for the process Because it is possible that different development personnel will be performing this step for different dialogs, this analysis is necessary to ensure that the overall results are compatible As this step is revisited for each dialog in the process, the number of available dialogs increases until the entire process can be considered

The third aspect of step 4 is provision of information to the associated project

management methodology by identifying (1) any functionality that is needed but that does not yet exist and (2) any opportunities to provide a more cost-effective

implementation by changing the definition or provisioning of existing external software components This type of proposal needs careful attention to the configuration

management aspects of the components The latter result is one mechanism through which component provisioning can change without altering the design or implementation

of the process The mapping of the automated actions is discussed first, followed by a discussion of the human actions Although there are some similarities between the two, each needs to be discussed in its own context

21.3.1 Initial mapping

Mapping of the automated actions is performed on an action-by-action basis using the specifications for each action that were developed in step 3 (Specify actions) For every part of an action, existing or proposed software components with the same functionality are identified and then used in implementation of the process

It should be noted that the use of the term physical component implies only that such

functionality has been developed and provisioned or is proposed to be developed and provisioned It does not necessarily imply a specific deployment configuration For example, the provisioned functionality for a given action transaction could actually be implemented on multiple platforms The actual platform employed in a specific use of the transaction might depend on a large number of operational characteristics, such as load, time of day, and platform operational status Such a deployment structure does not affect the mapping process

To provide an effective mapping between the components of the actions and the

available physical components, it may be necessary to manipulate the actions in two different ways

§ Decompose an action into multiple actions so that a mapping can be

made to existing components that have only a part of the functionality or data of the original action

§ Combine actions to utilize a legacy system or COTS product external

component Although that somewhat compromises the underlying

concept of an action, it does permit the use of large functional

components when necessary In the extreme, all the actions in a dialog could be combined, and the legacy system or COTS product could

become the implementation of the entire dialog

If either or both of those changes are utilized, it will be necessary to reiterate the logical design spiral to ensure that the changes have not affected another part of the process functionality and that the new actions have been properly defined and documented The use of physical components that are proposed to be created or changed in some way to provide the required functionality must be referred to the project management methodology The purpose of such referral is to determine the allocation of enterprise resources, both for deployment and to provide new or changed physical components One result of that allocation is that some actions with an automated class may be

changed to a human class on an initial or permanent basis Changes of that sort require that step 3 and the logical design spiral be reinvoked A possible result could be to postpone the implementation of the process until the needed physical components are provisioned That would then suspend the use of the PRIME methodology for the

development of that process until such time as the required physical components have

been provisioned and are available This is another function of the project management methodology

Recommendations to reprovision existing components can result from a number of conditions:

§ A mismatch in the logical specifications for a component, usually an

action transaction, and the properties of the physical component to which

it is mapped Although the functionality of the physical component may

be appropriate, such characteristics as throughput, response time, and

error detection may not be in sufficient agreement with the logical

transaction needs

§ The result of the project management review of the mappings as

specified in this step Criteria such as component maintenance costs,

error rates, and new recommended functionality would enter into this

decision, as would the needs of other processes or dialogs that were

also mapped to this component

§ Replacement of a legacy system with a set of reusable components that would then be available for future projects

For the human actions, mapping again is performed on an action-by-action basis The major difference lies in the physical components used for the mapping In the case of automated actions, the components are software In the case of human actions, the components are textural instructions (either on paper or in machine-readable form)

Again, it should be noted that the use of the term physical component implies only that

such functionality has been developed or is proposed to be developed It does not necessarily imply a specific deployment con- figuration For example, a provisioned transaction could actually be implemented by multiple human performers The actual configuration employed in a specific use of the transaction might depend on a large number of operational characteristics, such as load, time of day, and location operational status That deployment structure does not affect the mapping process

Human actions also require an interface to the automation system to exchange

information with the automated actions The development of that interface is discussed in

Chapter 23 The design of such an interface does not replace the need to map the human actions to appropriate instructional material The material could be made a part of the human interface, if desired, or it could be implemented separately That is the

province of the interface designer

As with the automated actions, to obtain an effective mapping, it may be desirable to decompose an action into multiple actions so a mapping can be made to existing

components If that is done, it is necessary to reiterate over the logical design spiral to ensure that the changes have not affected another part of the process functionality and that the new actions have been properly defined and documented in the repository so they can be utilized by other processes and dialogs

21.3.2 Mapping analysis

Two vehicles are utilized as a framework for analyzing the action mappings The first is a modification of the logical design prototype originally defined for the logical design spiral Each prototype of interest is supplemented by the additional information resulting from the mapping activities of this step That includes information such as timing and other operational characteristics of the physical components Although the prototype is still referred to as the logical design prototype after having been augmented with the

information needed in this step, it contains considerably more information than that required by the logical design spiral One advantage to utilizing the same prototype form for both the logical design spiral and the physical design spiral is the ease of traversing between the spirals as project management decisions are incorporated in the logical design or multiple what-if studies are performed

The second analysis vehicle is, conceptually, a three-dimensional matrix called the

analysis matrix The columns are dialogs, the rows are actions, and the layers are the

attributes of the action parts and mapped physical components Figure 21.1 is an

example of the matrix Any face or other related group of cells can be examined as a unit for the purposes of pattern matching Although use of the matrix can be accomplished manually for relatively small processes, an automated tool assist usually is necessary for practical business processes

Figure 21.1: Analysis matrix structure

The analysis matrix has two basic purposes Its first purpose is to analyze, for each dialog or set of dialogs in a process, the specific external software components utilized

by the individual transactions An examination of that information can determine if the mappings of all the actions are consistent with each other For example, assume one action utilizes an external component that retrieves customer information from database

A Assume that a second action utilizes an external component (most likely in another dialog but possibly in the same dialog) that retrieves the same customer information from database B There may be a good reason why the process requires the same

information from two different physical locations, but that could be a problem if the information in the two components is not concurrent A remapping may be necessary if it

is desired that identical information be obtained from the same source

If multiple sources for the same information are needed, it also may indicate that an explicit process is necessary to keep the two sources concurrent to some specified degree (it will be necessary to investigate that possibility whether or not a remapping is performed) That new process could be defined independently of the current process or incorporated into it The specific disposition depends on the individual circumstances involved and the characteristics of the relevant data

The internal software components used to implement the action support functions are analyzed in the same way to ensure the required degree of consistency for the process

21.3.3 Project management methodology information

The second use of the analysis matrix is to enable the estimation of the resources required for the development of the defined process as well as for an initial estimate of the development costs of the software components and other functionality that currently does not exist Although this estimation procedure is performed by the project

management methodology, the source data required are developed in this step

21.4 Prototype

The logical design prototype continues to be utilized in this step It is updated with the operational information obtained from the mapped functionality so the characteristics of the actions as implemented in the prototype can be updated accordingly After the updates have been made, the entire suite of scenarios should again be used to animate the prototype to ensure that the mappings are appropriate to the correct functioning of the dialog as perceived by the business and technical SMEs as well as other

stakeholders of interest

21.5 Activities

The 14 activities in this step are arranged according to the diagram in Figure 21.2 The activities can be performed either manually or with an automated tool as available If automated, the matching processes utilized in this step usually require the use of a knowledge-based approach

Figure 21.2: Diagram of activity sequence

The activities for any specific action can be performed in parallel with those for any other action, depending on the resources available (development personnel and tool support)

1 Augment action specifications with infrastructure information as needed

Augment action specifications (transaction and support functions) with applicable infrastructure information This information is utilized during the matching process to determine the acceptability of the available

physical components in areas other than process functionality An

example would be the database utilized by an external component

2 Determine if an existing software component provides the needed

transaction functionality Using a suitable matching process, determine if

any level of agreement exists between the requirements of the

transaction part of the action and an existing software component (Note: Actions that were identified in methodology step 3 as essentially identical

to existing actions do not have to be considered in this activity; they were mapped previously and the results placed in the repository The previous match does need to be documented in the repository, however If no

match at any level of agreement exists, go to activity 4.)

If a match exists at some level, document the match and its characteristics For, example, it may be determined that an exact functionality match exists but that the operational characteristics are not exact The software component could then be used with some sacrifice in resultant capability If the match is considered close enough, then that fact, along with the discrepancy in

operational needs, should be documented

3 Decompose remaining actions into less complex actions if possible For

an action transaction that does not have a suitable match to an existing external software component, attempt to decompose it into two or more less complex actions to help facilitate a possible mapping Repeat

activities 1 through 3 for the decomposed actions When this activity is

no longer feasible, terminate it and continue step processing A

successful decomposition is not likely, but it does occur often enough to make the attempt worthwhile

4 Determine if the updated action set can utilize existing functionality

Depending on the results of the resource allocation, determine if changes

to the action specifications can result in additional utilization of existing functionality (e.g., legacy system or COTS product) That may involve

changing the operational requirements of the actions or splitting or

combining actions Changes to the process map or dialog definitions also could be a means to achieve additional mappings If there is a possibility that such changes could be effective, then the necessary spirals and steps need to be reinvoked

5 Propose new or augmented external software components as needed

For any action transactions that were neither mapped during activity 2 nor decomposed during activity 3, propose new or augmented software components A specification of the functionality needed along with the necessary access (message pair) specification must be developed Document the mapping that results between the transactions and the proposed new external software component

6 Determine the suitability of existing internal software components Using

a matching process, determine if any level of agreement exists between the requirements of each support function and the physical

characteristics of any internal software components that exist in the repository (Note: Actions that were identified in methodology step 2 as essentially identical to existing actions do not have to be considered in this activity; they were mapped previously and the results placed in the repository.)

If a match exists at some level between an existing internal software

component and the action support function, document the match and its characteristics For example, it may be determined that there is a close but not exact functionality match The component could then be used with some changes Any level agreement along with the needed changes should be documented

For any support functions that do not have a suitable map to an existing software component, attempt to identify fragments of existing components When this activity is no longer feasible, terminate it and continue step

processing

7 Propose new or augmented internal software components as needed

For any support functions that were not mapped at some level to existing components, propose new or augmented components that can be used

to implement the functionality Document the mapping that results between the support functions and the proposed internal software components as well as the specifications of the proposed components

8 Determine if an existing instruction document provides needed

information Examine available instructional material to determine if such

material can be utilized as is or adapted for the needs of the action

9 Propose new or augmented instructional material as needed From the

action specification, determine the characteristics of the needed

instructional material and propose the format and contents of such material

10 Analyze the action set over all available dialogs Populate the analysis

matrix with the data from each available process dialog and its included actions If it is desired to address multiple processes concurrently during this step, the matrix should consist of all the dialogs belonging to the entire set of processes under consideration Examine the analysis matrix

to determine if any of the following conditions exists:

Multiple transactions that retrieve the same information from different physical components using the same or similar request and response data;

Multiple transactions that perform the same operation but have different request or response data;

Transactions that perform the same operation using the same physical component but differ in the amount of information specified in the request or response

If any of those conditions surfaces, it must be examined and reconciled if necessary The exact procedure for accomplishing that depends on the nature of the problem and cannot be generalized Usually, however, the

resolution requires that a remapping be performed by returning to the

mapping activities of the step It is also possible that it will require a

reinvocation of the logical design spiral and possibly the process spiral

11 Update logical design prototype and animate using scenarios Present

the augmented logical design prototype to the stakeholders in a

facilitated session to determine if the action functionality, characteristics, and sequences still meet the requirements of the business processes

Depending on the results, return to the mapping activities of the step

and, if necessary, revisit the process and or logical design spiral to

resolve any remaining difficulties

12 Convey new or changed functionality needs to the project management methodology The need for new or changed software or instructional

material that results from step 4 must be presented to the management methodology so available resources can be utilized as efficiently and

effectively as possible That may result in the postponement or

elimination of some needed functionality, which in turn may cause any

aspect of the process to change Such changes must be processed

through the appropriate spirals and steps of the methodology The

analysis matrix information can be used by the project management

methodology to provide an initial estimate of the costs involved for any proposed new or changed functionality

13 Obtain necessary approvals If approvals are needed to continue beyond

step 4, they need to be obtained before proceeding The action

prototype, the opinions of the stakeholders, and the hard deliverables

from this step (updated action templates, new functionality specifications, instructional needs specifications) should be sufficient to demonstrate the suitability of the action definitions and the ability to proceed

Approvals also may depend on the availability of sufficient resources to

provide the requested development Conditional or partial approval may

require alterations in the development, including the changing of some action classes from automated to human Other what-if changes also could be

proposed that would require utilizing previous steps to analyze the effect of

such proposed changes Eventually, if the project is to proceed, approval has

to be given using some set of conditions, either the original set or one

containing some alterations based on available resources

14 Enter the updated action specifications (including mapping information) into the repository Identify those actions that were already in the

repository upon entering step 4 Every action in a dialog should now

have its defined functionality (1) mapped to existing or proposed physical components or (2) marked as previously existing and mapped during the consideration of actions in previous process implementations The

information on the action templates should now be complete

21.6 Linkages to other steps

Step 4 must be invoked whenever there is a change in an action other than a deletion Because a deletion does not require a mapping, it is not necessary for this step to consider that event Some changes in needed action characteristics (e.g., response time) can result from the activities in any spiral and consequently cause a direct

transition to this step in addition to other steps that may be affected A change in the automated/human characteristic of an action probably would not cause a direct transition

to this step but require step 3 to be invoked first The usual transition to this step is directly from step 3, where the automated actions are identified Other sequences depend on the specific circumstances involved

The transition from this step to other steps depends on the type of results incurred For those dialogs that have all their actions successfully mapped with no changes to the actions, the transition from this step is directly to step 7, where the integration of all the

implementation components is performed Step 7 is not started, however, until all the necessary components are available (steps 5 and 6 completed normally in addition to step 4)

In addition, although it is not a direct part of the PRIME methodology, a transition to step 4(a) also is made Step 4(a) is concerned with the design and implementation of the software components that were determined to be needed in step 4 Step 4(a) also includes the creation or update of new instructional material

If any actions are changed as a result of the activities in step 4, a transition to step 1 or 3 must be made so the changes can be put into their proper context The specific step to which the transition is made depends on the particular change or set of changes that must be performed

21.7 Postconditions

Step 4 is complete and may be terminated for a given development when the following information and conditions are present as a result of the current step invocation:

§ All step activities have been considered at least once

§ The mapping of all transactions used in an automated action to existing or

proposed external software components has been completed

§ A brief description of each proposed external software component is available

§ The mapping of the support functions required by an action to existing or

proposed internal software components has been completed

§ A brief description of the changes required for the use of an existing

component is available

§ A brief description of each proposed new or augmented internal software

component is available

§ The mapping of all human transactions used in an action to existing or

proposed instructional material has been completed

§ The list of all actions that have been considered previously during the

examination of other dialogs and that are already mapped to existing

components is available Of course, they do not have to be remapped but can be utilized as defined

§ Any information that would significantly affect the implementation and use of proposed software components is documented That could include possible relationships, restrictions, and operational needs

§ A completed action specification form is available for each action The

software component information is now required

§ Using the scenarios, animation of the action prototype with the updated

operational information has been performed and the results verified

§ The business and technical stakeholders have been involved as needed and agree with the action mappings as demonstrated through the augmented logical design prototype

§ All relevant action information has been entered into the appropriate

repository and updates verified

Any necessary approvals have been obtained

At the conclusion of step 4, all affected stakeholders must agree that the action

animation, as it is defined using existing components, accurately depicts the intended operation of the process The results of step 4 may indicate that further refinement of the process is necessary It is not necessary that the business-oriented stakeholders review the action mappings because they are considered part of the detailed design

Selected bibliography

Isakowitz, T., and R J Kauffman, “Supporting Search for Reusable Software Objects,” IEEE Trans Software Engineering, Vol 22, No 6, 1996, pp 407–423

Chapter 22: Step 4(a): Provision software

components

22.1 Purpose

Step 4(a) represents the interface between PRIME and the software component

methodology The step itself is a part of the software component methodology because it contains activities needed to obtain and provision software components needed by PRIME However, when a component needed in a process implementation is not

available, the information must be communicated to the software component

methodology so that a component with the required characteristics can be provided Because of that tight coupling, step 4(a) is considered in the context of the PRIME

methodology The timely availability of implemented and provisioned software

components is critical to the proper functioning of PRIME, so a discussion of some of the major aspects of specifying and obtaining those components is of considerable interest Because this step is not in the direct path of PRIME, it is identified as an adjunct to step

4, which is concerned with the mapping of available functionality to the actions

This discussion assumes a C/S architecture (see Chapter 12) and the utilization of

reusable software components (see Chapter 14) In those chapters, the class structure

of software components was not discussed because it would have detracted somewhat from the central purpose of presenting the structures needed for effective software

reuse For the purpose of this discussion, it is useful to be able to refer to a component class structure as well as to the individual components Without a class structure of some type, only an unmanageable sea of components would be available That would partially negate the advantages of employing reusable components for process

implementation Although a component class also could be considered to be a reusable

software component, the use of the term component is restricted to a given instance of

individual functionality To avoid having to rely on a particular architecture for the

component class, a somewhat generic terminology is used

22.2 Component class structure

The external software components are grouped into building blocks Access to the

components is through the use of a messaging structure based on request/response

pairs, or simply message pairs The messaging structure for a given request/response

can be simple or complex, mirroring the C/S structure required to accommodate it The relationships among the building blocks, their included components, and the message pairs used for access form the class structure of the components The organization is designed to provide a significant amount of flexibility while providing a means to quickly identify or obtain components that can be used to implement the transaction part of an action

Obtaining the internal software components that implement the action support tasks also

is performed in step 4(a) Because the internal components generally have much greater commonality, are generally less complex, and not as numerous as the external

components, they are not considered explicitly in this initial discussion, but they are considered in the description of the individual step activities For simplicity, unless

otherwise indicated in the discussion, the term building block when used alone also

implies its included components

Building blocks can be specified through multiple approaches and do not have to have homogeneous characteristics All message pairs, however, should conform to a standard format regardless of the building block or component with which they are associated While it is technically possible to relax that constraint, the resulting implementation would

be far more complex than necessary This step outlines some of the considerations of the design, specification, and provisioning of building blocks and messages

Figure 22.1 depicts a logical model of the class structure that indicates the relationship between the entities of interest For simplicity, except for the control aspects of building blocks, the infrastructure elements needed for an actual implementation are not explicitly shown Building blocks contain a class of functionality An example would be that of an inventory building block that contains all functionality specific to inventory control

Components provide a cohesive set of functionality related to some aspect of the

building block In the case of the inventory building block, examples of components could

be “inventory item reorder analysis” and “items received.” Message pairs provide the means for utilizing the components

Figure 22.1: External component class structure

In an object-oriented system, the building blocks would be object classes, the

components would be objects, and the message pairs would provide the means to execute the methods or specific functionality of the objects and return any appropriate

data Such objects are sometimes referred to as business objects, although use of that

term is not universal Object-oriented terminology generally is not used in the

methodology discussion so that software components not inherently object oriented can

be utilized That makes it easier to incorporate a variety of structures, including legacy systems and COTS products in the implementation of a process Several different building block structures are briefly considered in Section 22.4.1

§ Message format specification;

§ Existing building block relationship structure;

§ Existing building block definitions and included components;

§ Existing component specifications (including message pairs);

§ Descriptions of proposed components

22.4 Description

For the purposes of this discussion, it is assumed that the software component

methodology includes the architectural model(s) for messages, components, and

building blocks as well as the means for obtaining those components Components can

be obtained through a custom development, a COTS product, a legacy system, or a combination thereof

The interchange of information between PRIME and the software component

methodology provides for the specification of components from a process-specific point

of view Information received from step 4 is used to provide the specific functionality requirements of a process that cannot be met by existing components Those

components are those that have been specified from an enterprise view as a part of the overall class definition or components that have been implemented as needed for

previous process implementations

Building blocks, components, and message pairs are closely coupled, but their design and specification are somewhat different That requires that they be considered

independently before being treated as an integrated set The specification of building blocks is examined first, followed by a brief discussion of the message structure Finally, the entire component class structure is presented

22.4.1 Building block specifications

A building block consists of a bundle of one or more related pieces of functionality (components and other building blocks) that can be accessed through a messaging structure The term component signifies that the function is indivisible and is intended to provide only part of the entire set of capabilities needed for a specific process

Building blocks are not designed to be utilized as stand-alone solutions to any business need They are not software systems in the conventional use of the term Building blocks are intended to be utilized in conjunction with a control mechanism and operations infrastructure The control mechanism invokes the appropriate components of the

building block as needed to provide the defined business functionality The operations infrastructure provides the support framework within which the building blocks and control mechanism are managed

Building blocks can be nested A building block can consist of other building blocks along with the necessary control and infrastructure components That allows the specification

of building blocks at a number of different levels and the reuse of them at any level Once they have been specified, building blocks can be procured in several ways That aspect is addressed later in the chapter

Several types of building blocks can be defined As long as they meet the definition, a large number of common software and hardware entities can be utilized as building blocks That aspect of the component structure is important because it indicates how components with different architectural paradigms can be utilized as part of an overall solution It is not necessary—in fact, it probably is counterproductive—to try to maintain a single approach to the specification of the individual building blocks Building block types include the following:

§ General component class;

§ Object class;

§ Module;

Each type of building block has a unique set of characteristics and associated

advantages and disadvantages Although use of a single homogeneous type would simplify the operations, administration, management, and provisioning of the building blocks in the infrastructure, that probably is an unrealistic goal, at least in the short term Although a short discussion of each type of building block is presented here, it is not intended as a tutorial on the underlying technologies If that is desired or necessary, the reader should consult the appropriate literature

22.4.1.1 General component class

A general component class is a building block specifically designed to structure the definition of and access to reusable components Such components have many of the same characteristics of objects, but they are not bound by all the characteristics of objects, such as inheritance In addition, they may be defined to have nonobject

properties such as self-definition of internal functionality and interfaces Currently, several different definitions of these types of component classes have been introduced

by vendors These component classes are flexible and will continue to be defined for various purposes

22.4.1.2 Object class

An object-oriented structure usually contains multiple layers of building blocks A class library contains multiple object classes that contain multiple objects (components) Specification of a class library usually is performed by a top-down procedure and is based on the business functions of one or more aspects of the enterprise It usually is not developed as an aggregate of individual component needs However, the extension

of existing class libraries usually occurs in the latter bottom-up fashion Unfortunately, there is no generally accepted methodology for defining object classes on an

enterprisewide basis That lack requires a cross-functional effort by experts in object technology as well as the various individual aspects of the business

Because of the advantages of object technology, as many components as possible should be specified as objects even though that requires more upfront analysis than some other approaches

22.4.1.3 Module

A module is a building block that has only one component and is the most general type

of building block specification The only requirement is that its outside interactions occur via a messaging structure Because of the generality of the module construct, care must

be taken to ensure that a maintenance problem is not created by defining too many unrelated modules with only a casual relationship between the building blocks

The generality, however, does allow for the rapid creation of components that have a localized sphere of influence and do not have strong relationships with other

components This type of building block also can be utilized as an interim solution while

a more comprehensive structure is being defined and implemented

Modules can interact with other modules through facilities other than messages as long

as the module-to-module interactions form a closed set The set of modules effectively becomes the building block Again, in specifying these types of structures, care must be taken to avoid a maintenance problem They should be used only when the specific

circumstances of the problem make them an effective approach One such instance might be when most or all of the module set already exists and the complexity of the implementation is such that it is economically reasonable to define the set as a building block

22.4.1.4 Specialized function library

Specialized libraries have been around as long as computing and contained subroutines (e.g., math functions) that would perform a number of specialized calculations The functions in the libraries usually were designed to be incorporated in a program using a subroutine call mechanism, not utilized as separate operational entities To utilize the specialized collection as a building block, it would have to be reimplemented using message-based communication

This type of building block usually results from a bottom-up approach Its specification is the result of a general knowledge of the types of functions that any business-oriented processing might require Examples of specialized function libraries that might be useful

in a business context would be a math library, a currency conversion library, a

bill-formatting library, and a pattern recognition library Admittedly, those libraries are all very low level, but they are useful for many types of processes

22.4.1.5 Legacy system

Legacy systems generally have been designed for a specific functional area, designed to operate on a standalone basis and to combine function data and control Turning a legacy system into a building block requires some amount of work and is basically a three-step process First, components must be identified, which requires a thorough knowledge of the individual functions and basic design of the system Use of the action specification for the dialog(s) that will use the system is an excellent starting point for that determination

After the components have been designed, an approach to executing them on an

individual basis must be identified That could be accomplished through screen

emulation, a special-purpose front end to the system (wrapper), or modification of the code in the system Each approach has economic as well as operational consequences, and the particular method(s) chosen would depend on the circumstances involved Finally, a message-based interface to the wrapped or modified system would have to be developed The resultant entity then would have the necessary characteristics of a building block

Because the construction and characteristics of each legacy system are unique, the effort necessary to obtain a form of the system that is consistent with the definition of a building block varies considerably However, because of the immense investment in these systems, it is necessary to utilize them (at least initially) to the maximum extent possible if the benefit of the service approach to realizing business processes is to become economically viable Requiring that all needed functionality be redeveloped is not possible except in the case of startups or other enterprises that have little embedded base

Once a component has been made available as part of a legacy system, the functionality then can be migrated to another building block, depending on the economic and

technical circumstances The ability to migrate individual components is one of the major strengths of the building block approach

relatively small COTS software must be selected carefully to minimize the potential problems

22.4.1.7 External information provider service

The characteristics of EIP service are similar to those of the legacy application The difference is that it usually is more difficult to change the interface to resemble that required of a building block One way to approach that problem is to define a module building block that contains an EIP agent The EIP agent would have a building block–compliant interface to the control and infrastructure entities but would have an

application-specific interface to the EIP service The EIP service itself would be defined

to be a module to be consistent with the approach presented for module building blocks

If desired, this approach could also be applied to legacy applications, although more inefficiencies probably would be introduced

The use of Internet standards and technologies by all parties to the interaction mitigates that problem considerably, but the details still must be examined to ensure that the required interoperability does exist There can be many companies involved in a given supply chain, from raw material supply to manufacturing to end customer, so the

specification of the characteristics of this type of building block can be extremely

important

22.4.1.8 Infrastructure element

In many cases, to satisfy a business need, one or more functions usually associated with

a computing infrastructure are needed Security is an example of this type of function For the purpose of providing a building block type of access, an appropriate interface must be made available Interfaces of one infrastructure element with other infrastructure elements do not necessarily have to follow the building block structure (although it certainly would simplify the understanding and specification of this functionality) but may include other types of structures consistent with network standards and implementation

22.4.1.9 Embedded system

An embedded system is software integrated with a piece of hardware The result is a set

of functionality that utilizes hardware as well as software in its execution Examples are telephone switches and software-driven appliances such as stoves and refrigerators These systems must have building block characteristics to fully participate as process func- tionality If a process requires that a telephone switch state or data be altered, then

it must be accessed as a component in a building block In the architectural definitions of

the intelligent network, building blocks are called service independent building blocks (SIBs), and the components are called functional entity actions (FEAs) As more

equipment becomes software controlled, these types of building blocks will proliferate and be available for innovative solutions to business problems

22.4.2 Message pair specifications

A request message invokes components in one or more building block(s) and causes the return of an appropriate response message The response must be returned from the same building block to which the original request was sent Depending on whether a simple or complex C/S structure is utilized, multiple building blocks and associated message pairs can be used to satisfy an action transaction However, the only message