Value Chain Basis

Fig. 3.2A illustrates a conventional form of a hypothetical value chain used in strategic planning for an established, made-to-order product. This value chain depicts broad capabilities and an implied transition through those capabilities to deliver customer value. Each of the high-level capabilities is broken into supporting capabilities.

A value chain analysis focuses on the contributions of value for the end customer. This example business begins with sales and proceeds through product production, distribution, and support. The customer support capability functions somewhat independently, occurring when there is a reason for some action in the field. Consequently, it is appropriate to model this as a separate value stream. The value chain decomposition is sometimes described as a process model, but it is at most a high-level abstraction of the processes that actually deliver customer value. A value chain is not intended to be a process model but rather an abstraction of the flow of value contributions. Nevertheless, at times it is helpful to think in terms of a process breakdown to help identify the required capabilities.

It may be useful to use alternative forms for the value chain decomposition. The conventional value chain model is equivalent to a work breakdown structure, as depicted in Fig. 3.2B. Fig. 3.2C illustrates the same model in the form of an outline. The outline form is often a more convenient way to capture additional levels of detail, since it is easier to expand multiple levels. Regardless of the form, a conventional value chain model, if available, is a useful starting point for analysis.

The decomposition of the value chain identifies potential capabilities that may be implemented as sharable services. On further analysis, we may find that there are additional capabilities at each level that are less crucial but nevertheless necessary. The addition of deliverable flows will help identify the need for additional capabilities.

Starting from a value chain perspective helps focus on what the product line does rather than who does it. This helps ensure that the definition of capabilities is driven by the business of the enterprise and avoids repackaging the same old way of doing business. As capabilities are identified, they should be defined in the VDML capability library. As the number of capabilities increases, it is useful to start using the capability categories to group similar or related capabilities together and to start identifying capabilities that could be consolidated.

Industry Frameworks

Industry frameworks provide another approach to top-down analysis. Industry frameworks provide prototypical designs of enterprises in a particular industry, based on a consensus of industry representatives. The frameworks tend to define characteristic breakdowns of functionality and business processes that may align with capabilities. They may provide more detail and objectivity than a business-specific value chain. Of course, each enterprise may be different due to individual circumstances or manner of doing business, and these differences may be a basis for achieving competitive advantage in certain markets.

One advantage of an industry framework is that the capabilities will tend to align with implementations of capabilities in commercial enterprise applications and outsourcing services. Use of an industry framework does not mean that a well-defined conventional value chain should be abandoned; instead, together they define more insight for the definition of shared capabilities.

An industry framework may include an enterprise data model. The role of a consistent, enterprise logical data model is discussed in Chapter 6. Use of a framework data model should be strongly considered early in the development of a CBA for a particular enterprise, for two reasons. First, development of a good enterprise logical data model is a very large and time-consuming undertaking that will delay the CBA transformation and exceed the cost of acquiring a model. Second, the framework data model is more likely to be consistent with commercial software systems and outsourcing services as well as industry standards, so data exchanged between services have fewer data transformation problems.

The enhanced Telecom Operations Map (eTOM, http://www.tmforum.org/browse.aspx?catID=1648) from the Tele Management Forum (TMF), illustrated in Fig. 3.3, is one widely recognized industry framework. It is described as a business process framework but is similar to a capability map. It represents the processes of a typical telecommunications service provider. The TMF has defined a companion enterprise data model called shared information and data (SID, https://www.tmforum.org/information-framework-sid/) that supports the enterprise logical data model requirement discussed in Chapter 6.

Fig. 3.3 illustrates the eTOM framework at the enterprise level. There are three major process categories: (1) operations; (2) strategy, infrastructure, and product; and (3) enterprise management. These are described as level-zero processes.

The operations category reflects the primary business operations. The strategy, infrastructure, and product segment defines processes for changes to the business; that aspect of agile enterprise architecture is addressed in Chapter 9. The processes in enterprise management are typically viewed as support services—those processes that are part of managing the enterprise, such as finance and human resources, but are not a direct part of delivering customer value.

The operations and the strategy, infrastructure, and product categories of Fig. 3.3 are each divided by vertical and horizontal partitions described as level 1 processes. The vertical partitions reflect functional capabilities. The horizontal partitions reflect primary enterprise objectives that cut across the functional capabilities. For example, customer relationship management (CRM) is an enterprise objective that requires participation and support from each of the functional capabilities. These objectives are optimized operationally in the operations segment and optimized from a business change perspective in the strategy, infrastructure, and product segment.

Fig. 3.4 shows more detail for the operations processes. These level 2 processes are shown at the intersections of the vertical and horizontal level 1 processes; each is in both a horizontal and a vertical level 1 process within the eTOM specification. Each of these level 2 processes is further detailed in subprocesses. Note that some level 2 processes span level 1 processes; these are effectively shared capabilities that may represent either shared work management service units or capabilities that can be further broken down to define shared operational capability units. A similar breakdown is defined for the strategy, infrastructure, and product level 1 processes. More detailed breakdowns also exist for the enterprise management processes. eTOM process models provide additional insights on capability requirements and the contexts in which they are used.

Value Stream Decomposition

As a first step in developing the detail of a value stream, a delegation tree should be developed based on the value chain and/or industry framework. Each node in the delegation tree is a potential capability method containing an activity network where certain activities delegate to the next lower level of capability methods.

Fig. 3.5 illustrates a delegation tree in which the solid-line arrows represent the request-response relationships from capability methods requesting services to those providing services. The dotted line represents the value stream—the sequence of execution of the capability methods as they contribute value toward the end product. This is a simplified portrayal, since a value stream usually will have branches that are executed concurrently, like tributaries to a river.

Note that some of the capability methods are engaged more than once in the same value stream. The context in which they are engaged will likely affect the measurements of values contributed. If the value stream activities are sequential, then the time from the request to the delivery of customer value is the sum of the times it takes each capability method to contribute its value. The cost of the product or service will be the sum of the costs of executing each capability method.

It is useful to develop a delegation tree in an outline form as suggested by Fig. 3.2C. Text can be added below each of the capability name headings to describe the capability, along with the required input deliverable(s) and expected output deliverable(s).

The next step is to develop activity networks for the capability methods. This is detail that would be difficult to manage in the outline form of the delegation tree, so, at this point, we should start building the value stream model in VDML.

It is useful but not essential that the capability definitions in the value stream outline be transferred to the VDML capability library. An initial taxonomy should be developed using capability categories. This will help identify potentially shared capabilities which can then be identified by the same name in the different contexts in which they are used. The capabilities of capability methods must be leaves in the taxonomy tree. If convenient, related capability method definitions can be grouped under capability unit definitions. Note that the capability taxonomy is not the same as the delegation hierarchy.

Initial detail of the activity network for each capability method can then be developed based on the deliverables. Starting with the output deliverable of the value stream, work backward to identify the last activity of the top-level capability method that produces the end product. That activity must either be performed by a person or application/machine, or it must delegate to a supporting capability method. The output of a delegating activity becomes the output of the engaged capability method, and the input to the delegating activity must be the input to the engaged capability method.

Note that the name of a delegating activity depicts what is done from the perspective of the containing capability method. This may or may not be the name of the capability method that is engaged by that activity.

As deliverable flows are identified, the business items that flow as deliverables can be identified and posted in the VDML business item library. Note that a sequence of activities that incrementally add value to a business item can be represented as having the same business item as inputs and outputs rather than creating unique names for the business item in each deliverable flow. Sometimes it will be necessary to add an activity to create a deliverable that is needed as input to another activity.

An activity can only be performed by an individual performer or collaboration. If the activity requires multiple people, then the activity must engage a separate capability method with roles for the multiple participants.

Activity Data Capture

An analyst will start at the end of a process and trace the deliverable flows back through the string of activities and deliverable flows that produce the end product. The analyst should consider the purpose of the model and decide which inputs are of interest in a management-level model of the value stream. Then the analyst must determine if any alternative output deliverable flows are of interest and, if so, trace the output deliverable flows forward to develop the full activity network. Fig. 3.6 illustrates a resulting activity network segment arranged in approximate chronological sequence. Full chronological sequence is not useful where there are concurrent flows. It is most useful to keep together activities that occur in sequence.

Note that a value stream in the VDML model does not represent the flow of individual units of production but represents the paths of deliverables as fractions of production. As a result, gateways in an operational process will be represented as the flows of percentages of production in VDML. In VDML, variations in production rates are buffered by stores, and repeated execution (iteration) will be represented either as a capability method engaged for each iteration or activity value contributions that represent repeated performance of the activity (or group of activities). We will illustrate the analysis with a hypothetical process in which table legs are assembled to table tops and some defective tables are repaired.

In the spreadsheet of Fig. 3.6, the first group of columns identifies role names that are associated with activities. The role of each activity is indicated by an “X” in the intersection of the role column and the activity row. Note that role names need only be unique within a process/capability method. Some roles may be identified as appropriate in multiple methods and should be given the same names. It will likely be necessary to consider the general issue of role names later in the VDML role definition library or an equivalent table may be developed in a spreadsheet, organized in a taxonomy.

The second major column is for method/process names. At this stage of analysis, there is only a segment of one process being considered. Some rows will be added in the next step of analysis.

The third major group of two columns has “Activity” overlapping with “Submethod.” At this stage only the activity caption is relevant. Each of the detail rows contains an activity or store name.

The fourth major group of columns is labeled “Deliverable Flows.” The name in each column is the name of a business item that flows from a source to a destination activity. There may be multiple deliverable flow columns with the same name indicating a flow of the same business item. The source activity is designated by an “O” for output, and the destination activity is designated by an “I” for input. So in one deliverable flow column, the source and destination activities are designated as output and input. The last column is for comments.

In the detail of the example, the first two activities are identified as shared stores. This means that the inputs to these stores come from other processes, presumably owned and operated by other organizations. Where inputs are directed to these stores, the stores appear as virtual stores because the actual stores are in the process we are analyzing. Stores are usually owned by the recipient as an input buffer.

Note that the activities in rows 6–8 deal with repairs, and row 11 deals with the tables that are scrapped. The good table output of row 5 is an assembled table that goes directly to “Package for shipment” in row 9. The defective tables (second output) go to the activity of row 6, which is a store, holding defective tables for repair. A store is appropriate since the production rate for good tables is much higher than the repair rate, and defective tables will occur at random times.

The final outputs of this process also go to stores: the tables for shipment and the tables for scrap disposition. Note that these are designated as virtual stores. This means that they represent stores that exist elsewhere, presumably owned by the organizations responsible for processing shipments and disposition of scrap.

Process Transformation

Fig. 3.7 illustrates the above example, transformed to create a repair service as a potentially sharable capability method. Rows 6–8 have been moved to the bottom of the spreadsheet, separated by a double line and given a method name of “Repair Service.” In their place (between rows 5 and 9) is a submethod call to “Repair Service.” The call has input designated “D1” for “delegation,” and outputs designated “R1” and “R2” for the results for the repaired and scrapped tables.

In the Repair Service method, line 6 has an input of “I1” to correspond to the delegated input, “D1,” and lines 7 and 8 have outputs O2 and O1, respectively, corresponding to the results of R2 and R1 of the above call.

The numbering of inputs and outputs is necessary so that the Repair method can be called by other processes without the deliverable flow columns of the call being aligned with the input and output columns of the Repair method. Each caller will refer to the input “D1” and the outputs “R1” and “R2.” In this way sharable capabilities can be pulled out of larger processes and engaged in multiple contexts.

Each major process can be modeled with a spreadsheet. As subsequent processes are analyzed, opportunities may be recognized for using some of the already-defined sharable methods. Note that there can be additional levels of delegation, for example, if the Repair method was substantial, it might have sharable submethods pulled out as well.

This approach separates the activities and shared methods from the responsible organizations. This can be important for taking internal politics out of the restructuring analysis. Later, the organization structure for management of shared capabilities can be considered with a better understanding of the scope of sharing and the similarities of sharable capabilities.

Production Planning Percentages

When a capability method has more than one output, a planning percentage must be assigned to each output. If they are alternative outputs, then the percentages should add to 100%. If they are concurrent outputs, then both percentages should be 100%. In rare cases, the outputs may be alternatives part of the time and concurrent part of the time, resulting in a total greater than 100%. These percentages may be different in different scenarios when they depend on product mix or random occurrences such as defects.

The statistical measurements associated with elements of a collaboration method are based on a single unit of production, and the cumulative value measurements can be affected by these percentages. In particular, planning percentages are a concern when deliverable flows branch or merge. For example, when flows have a concurrent branch, the cumulative cost of production should be allocated to the branches. When alternative flows are merged, the cumulative cost should be the weighted average share of the cumulative costs based on the planning percentages of the incoming flows.

At this stage, values can be assigned for testing purposes and to indicate the relationships between multiple outputs.

Synchronous Exchange

At this stage of analysis, most of the links between capability methods have defaulted to synchronous delegations.

A synchronous exchange is a simple request-response. The requester's action is suspended pending a response from the recipient. In VDML, this is represented as delegation by an activity to engage a capability method as a service. Only capability methods can be engaged in this mode.

Fig. 3.8A depicts a synchronous flow (for illustration only). The dashed boxes depict capability methods. Activity A engages capability method N. In capability method N, activities B and C are performed and a result is returned to activity A.

Delegation enables the capability method to be engaged in different contexts with different inputs where the activity network does not depend on the source of the request. The measurements of the capability method will be dependent on the input and thus the context in which it is engaged. These measurements will be reflected in the value contributions associated with the response. The measurements of an engaged capability method are based on a unit of production of the engaged method. The measurements returned from the delegation are then adjusted by the calling activity to reflect the share of production of that context that is delegated to the engaged method.

Asynchronous Exchange

Not all interactions are synchronous. An asynchronous exchange occurs when a source activity sends a deliverable but does not wait for a response.

In VDML, a virtual store in the sending collaboration receives the deliverable flow, and the corresponding, shared (real) store in the receiving collaboration provides the deliverable to a receiving activity. The effects of this deliverable flow may be realized in a result received by the sender at a later time. This mode can be applied by any collaboration, not just a capability method.

The value measurements associated with a deliverable in a store must be factored into the measurements for the receiving collaboration. Essentially, each business item in the store can be viewed as a unit of production from the source collaboration, so the adjustment to measurements will be based on the number of business items from the store that represent a unit of production in the receiving collaboration. For example, tires may be delivered to a store to supply an automobile production line. Each tire is a source unit of production. However, since four tires are required for each automobile, four tires are a unit of production of the receiving collaboration. This will require adjustment of incoming value measurements.

An asynchronous exchange is depicted in Fig. 3.8B. Activity A in capability method M sends a deliverable to the virtual representation of store X. The deliverable is received by the shared (real) store X in capability method N where it can be accepted by activity B at a later time. The result may or may not be returned to method M or some other method later in the value stream via a similar link with another store.

A deliverable may be sent to and received by a store because (1) it is assumed that the receiver may not take immediate action and may be receiving similar deliverables from other sources, (2) the production rates of the source and recipient are different, (3) there are multiple sources or multiple consumers of the deliverables, or (4) the receiver should be free to determine and change how it will process the deliverable, and a shared store is a way of isolating the sender process(es) from the receiver process(es).

Generally, the shared store will be owned by the receiver. However, a shared store can receive deliverables from multiple sources and supply deliverables on demand to multiple recipients. The store should be owned by a common parent organization in the receiving management hierarchy.

A difference in production rate may also occur when the sender or receiver (or both) is operating in a batch mode. It may also occur when multiple units being received are used for each unit of the receiver's production, or only some of the units received are used by the receiver's production.

A service can be engaged asynchronously for a request-response exchange by agreement between the requester and provider. A deliverable can be sent to the provider's input store, and the provider later sends a response to the requestor's input store. However, at an operational level, this requires that the request carries the identity of the request and requester and the identity of the input store for the requester's response. In VDML, individual requests are not tracked, so it is sufficient for the production rate of the requests to equal the production rate of the responses.

A common application of an asynchronous deliverable flow (to a store) is to deliver exceptions for processing by another collaboration, for example, handling of scrap or rejection of a customer order. This has been regarded as a “side effect” flow since it initiates action not included in the response to a delegation.

Process Optimization

There are various techniques to achieve process optimization that may have implications to the value stream beyond the implementation of individual capability methods. The following are examples.

• Building to forecast vs building to order should reduce customer time to delivery

• Batch production, balancing setup costs against timeliness, and inventory costs

• Sequencing of requests as for an automobile production line, to avoid bursts of high work content at individual stations

• Sharing resources across capability methods

• Selection of operating location for utilization of special facilities or product distribution

• Sequencing work to manage priorities

• Managing rework

These factors should be considered as part of value stream design. Since they will likely impact the design of individual capability methods, they may indirectly impact other value streams or they may impact the ability to share certain capability methods. Since these factors can affect the success of multiple value streams, they should be considered from an enterprise perspective.

Identify Customer Values

Development of the value contribution network should start with a value proposition. For each value proposition, the value types of interest to the recipient/customer must be identified. This is the minimal set of values to be measured in the network.

Update Values Library

The value types of interest should be added to the values library if not already there. For each value type, the unit of measure must be defined. Value categories should be added to include new values in the taxonomy.

Attach Value Adds to Activities

Each activity in the value stream must be considered in order to attach value add elements for those value types of interest that are relevant to the work of that activity.

The value measurements of each capability method may be specified directly if more detail (an activity network) is not available, but in a more complete model, these measurements will be derived from the contributions of the activities within the capability method.

Insert Value Add Elements Into the Value Network

Each value add element must be linked into the value network for its value type. The value network generally parallels the activity network deliverable flows.

Assign Tentative Measures

It is useful to assign value measurements to each of the value add elements for testing purposes. These may be defined for a test scenario.

Define Value Aggregation Formulas

The formulas for aggregation of value measurements will depend on the nature of the value type and the associated share of production associated with the value add (the planning percentage of the associated output deliverable). Value measurements returned from delegation must be adjusted to reflect the share of production addressed by the requesting activity.

Refine Value Proposition

Each value proposition must be linked to the value aggregations for each value type of interest to the recipient. Note that there may be a different value proposition, with different values of interest for different market segments.

Define Satisfaction Computations

The aggregated value measurement for each value type must be translated to a customer satisfaction measurement in the value proposition. This formula will depend on the relationship between the value measurement and the satisfaction scale as well as the upper and lower bounds of satisfaction. Some value measurements may have a linear relationship to satisfaction while others may best be described by a curve. This formula is important so that changes to the model that affect value measurements will be properly expressed as customer satisfaction.

Define Weights

Weights must be assigned to each value type in a value proposition to reflect the level of interest the customer has for that value type. The default is to use the weights to compute a weighted average for overall customer satisfaction. These weights could also be computed with a formula for a nonlinear impact. For example, an “unsatisfactory” satisfaction level for a value type could be very important while a “good” satisfaction level might be of less concern.

Interactive Business Relationships

Asynchronous exchanges are the normal mode for a business network exchange because the exchanges with customers, suppliers, or other business partners are not tightly coupled. The parties in a business network (collaboration) send and receive deliverables asynchronously and a party may be involved in exchanges with many different business networks (other parties). In the business network, there are not shared stores, but it is expected that the receiving activity of each party will deliver input deliverables to a receiver's internal store for processing.

In general, electronic commerce between enterprises can be viewed as a loosely coupled integration of services in much the same way that services are used within the enterprise. Suppliers in a supply chain are providing the service of delivering products to the production process and the recipient later returns payment. Banks provide a service for accepting and cashing a check, and the check submitter receives credit for the payment. Transportation carriers provide services for pickup and later delivery of packages. The primary difference between internal services and electronic commerce involves concerns about security, trust, and autonomy.

In some cases, the information exchanged might not be private and the interaction may be trivial, such as in a request for a stock quote. The service provider may not be particularly concerned about the identity of the service user, but the service user is dependent on the identity and integrity of the provider for an accurate and timely stock quote. In other cases, such as the transfer of funds, identities of the service user and service provider are both critical and the information content is highly confidential. Security considerations are discussed in Chapter 7.

Trust requires a business relationship beyond technical compatibility. Each party must be assured that the other party will fulfill its obligations. Reputation may be a factor in determining the quality and reliability of the service. This assurance still requires human participation in the establishment of business relationships. In some cases, this will be established by consortia or other general affiliations that screen members and provide assurance of good faith relationships among them. A discussion of establishing trust is beyond the scope of CBA and the scope of this book, but electronic signatures that establish legal obligations are addressed in Chapter 7.

Business Networks

VDML models business network collaborations between the enterprise and its customers, its suppliers, and its other business partners. Two different views are defined for business network exchanges: (1) value proposition exchange and (2) deliverable exchange. Note that the other parties in a business network exchange are often typical participants such as a customer of a market segment represented as a member of a community.

In a value proposition exchange, each party is the sender and recipient of value propositions from other party(s). Each party must perceive a net gain from the exchanges in order for the collaboration to be viable. This is useful when considering a new business model, particularly where there are multiple parties involved. For example, a blog publisher, depicted in Fig. 3.9, must ensure that bloggers, advertisers, and readers each realize some benefit from participating.

In a deliverable exchange, the focus is on the flow of deliverables. One party may deliver a product and a recipient delivers payment. However, this exchange may be more complex if it includes related deliverables such as a proposal or quote and response, a shipping notice, an invoice, and a payment. The modeler must determine the level of detail that is needed to support the business design. Note that greater detail of exchanges may be deferred to the technical, operational design of service units.

It is important to link a deliverable exchange to its supporting value stream. The end product of a value stream may be delivered by an activity of the selling party to an activity of the customer party and another activity of the selling party receives payment which is delivered to a store for processing.

The operational exchange, the next level of design detail, is usually more complex, and different activities of a party may send and receive deliverables such as changes, cancellations, status reports, quotes, and other documents.

Service Interfaces

The service interfaces on the top of the diagram are the interfaces for engaging the services defined by associated capability methods along with related services that are required for a full, operational capability. These are synchronous requests. Multiple services will require multiple processes that may all require consideration if the service implementation changes, although this will be easier to coordinate within one responsible service unit organization. It is also likely that specialized services will result in tighter coupling with users, in turn resulting in propagation of effects to users when the service unit makes internal changes. Each service unit should be designed to accommodate service parameters and specifications that enable a generic service to meet a range of user requirements.

There are also possible, asynchronous inputs and outputs—exchanges through stores. These must also be specified in the interface and performance specifications.

Note that though the focus is on service units that are electronically integrated and rely on automated business processes and applications, equivalent mechanisms must be considered where there are other manual exchanges based on paper or voice communications.

Supporting Applications

Most of the services managed by a service unit will involve some automated record-keeping or computations. These applications or tools are the responsibility of the service unit organization. The service unit must also take responsibility for the design of automated business processes.

Some services, such as a tax computation, for example, may be fully automated and on the surface involve only a computer application. However, there is an organization responsible for the computer application and for ensuring its accuracy and reliability. Though people might not be directly involved in the operation, people maintain the tax rates and computations. This may involve other people or other services to identify changes to tax rates and regulations. There may be still other people involved in technical maintenance such as adapting the computation to new information technology. All these capabilities and associated responsibilities are part of delivering a tax computation service. To the typical user, and from an executive management perspective, the tax computation service provides tax computations in response to requests.

The implementation of the service obviously involves much more, including the use of other services. These implementation considerations are the responsibility of the service unit organization.

Changes

Fig. 3.10 shows a variety of inputs as changes. These are not part of the normal operation of the services and are therefore not modeled in the capability methods. However, these inputs suggest that some action is required by the service unit organization to modify the services.

In the case of the service specifications and service level agreements, these will be the result of some collaboration involving representatives of the service unit, consumers of services, and enterprise leadership to ensure that they are appropriate from an enterprise perspective. A service unit is required to comply with its service interface specifications and its service level agreements. These specifications are effectively contracts with the rest of the enterprise. They may be changed as a result of new requirements or improvements in the service unit implementation, but they cannot be changed unilaterally. Performance metrics are based on performance against these specifications, and users of the services, as well as potential future users, rely on conformance to the specifications.

Reporting

Fig. 3.10 also shows outputs for reporting on the right side of the diagram. Performance measurements and opportunity/threat identification are for consideration of higher management and may support investments or other action for adaptation or improvement of the service implementations. The cost of services supports billing for services as discussed later. These are related but not the same as the statistical costs in the VDML model. The value measurements are actual measurements that may be used to investigate problems or compute the averages that are needed to support analysis in the VDML model.

Support Services

The other services indicated with dashed arrows at the bottom of the diagram include supporting capability methods engaged through delegation, and administrative support services that are necessary for the service unit to maintain its capability, but they do not contribute directly to the value of each unit of production. These support services—accounting services, IT services, HR services, and procurement services—have their own value streams that deliver value for the management of the enterprise and the business operations they support.

Service Unit Management

Service unit management involves the work of administration, problem solving, and dealing with changes as well as other factors that affect the appropriate application of the general capability and the specific services that are offered.

In addition, the service unit is responsible for the internal operation of the service unit such as

• Management of resources within the service unit. This involves ensuring the availability of resources

• Workload balancing for optimal utilization of personnel and facilities across multiple capability methods and potentially with related service units under shared management

• Batch processing or other methods for optimization of cost (such as setup and maintenance) versus timeliness of operations

• Process improvement

• Personnel training and supervision

• Design and improvements of computer applications

• Implementation of business rules

• Maintenance of facilities

• Data management, including the security, integrity, and accessibility of associated master data (see Chapter 6) and data that support the service unit operation and reporting

• Risk analysis and mitigation

• Business continuity preparedness

Legacy System Service Unit

A legacy application may be “wrapped” in a service unit with interfaces appropriate to the capabilities it supports. It is important that the interfaces conform to the logical data model discussed in Chapter 6 and that they reflect industry standards if possible. The legacy application may then function somewhat like an outsourced capability where there is little control over the implementation.

Reliable Messaging

Communications between service units are primarily through message exchange over the intranet (internal internet technology). Internet technology and middleware support the rapid, ad hoc exchange of messages between many sources and many recipients.

Messages must be communicated with reliable messaging. This means that the messaging system ensures that each message is delivered to a recipient once and only once. In a paper-based world, reliable messaging is accomplished with the use of original documents (so, there is only one) and transaction numbers such as an order number or invoice number.

In an SOA, requests for services and the interactions between requester and provider are communicated as messages. The communications are usually in a store-and-forward mode so that a message can be sent by one participant but held until the recipient is ready to receive and process it. A participant may send a message and continue to do other work rather than suspend activities until the recipient responds. This is described as loose coupling (more specifically, temporal loose coupling) because receivers need not be immediately available to receive messages.

Although these messages are communicated asynchronously from a technical perspective, from a business services perspective, the communications are very fast and support synchronous delegations and deliverable flows as well as asynchronous deliverable flows between collaborations as modeled in VDML.

Message Transformation

Message transformation is required to convert the sender's format of message content (if necessary) to a shared, exchanged form and then transformed to a recipient's form (if necessary). Fig. 3.11 depicts a message transformation capability at the interface to each of the service units. This anticipates that at various times, at a minimum, as new versions of services are implemented, there may be a need for transformation if only on a transitional basis.

Optimization of enterprise operation requires the ability to integrate and exchange data from multiple sources in the enterprise to support operations, analysis, planning, and decision-making. The diversity of sources and uses requires the ability to transform messages to correspond to the requirements of senders and receivers. The preferred approach is to exchange all messages in a consistent, neutral form, and transform a message specific to a sender or a receiver.

In the long term, transformations should be minimal, but transformations will continue to be required for interfaces to legacy systems and for transitions when business changes require changes to message content.

Differences in format, terms, and units of measure cause incompatibility that is relatively easy to correct. For example, dates may be expressed in different forms, such as dd/mm/yyyy, mm/dd/yyyy, ddd/yyyy (Julian), or other variations. Different terms might be used, for example, to describe employee status, such as temporary, part-time, salaried, and so forth, where they might be expressed in different languages but have the same meanings. Units of measure might be feet and pounds or meters and kilograms. Again, these are relatively straightforward but necessary conversions. Recipients of XML (http://www.w3.org/XML/) messages can allow for unexpected elements that are added for a new version, but more complex changes may require transformation.

For example, the same business entities may be represented, but with different identifiers for individual entities. Then there must be a cross-reference source to support a conversion.

Application adapters provided by integration middleware should provide for transformation between the application internal representation of data and an appropriate XML exchange representation.

Some messages may contain encrypted or signed content. This content must be retained by the creator or initial recipient of the document to preserve its validity. A working document, with encryption removed and signatures validated, may be shared for internal processing. However, the decryption and signature validation should be done by the master owner, not by the middleware transformation facility. This transformation might be performed by a shared security service unit that applies the appropriate keys for encryption and signatures or decryption and signature validation. Signed documents must be preserved in their original form for enforcement/accountability/nonrepudiation. Encryption and signatures are discussed in more detail in Chapter 7.

XML Data Exchange

The messages exchanges are in XML (eXtensible Markup Language) format. XML has been widely recognized as the preferred format standard for exchange of data between information systems that may involve different supporting technologies.

XML was recognized fairly early in the 1990s as a useful form of data interchange. It has several important characteristics:

• XML documents (ie, records) are somewhat self-documenting. Each element is tagged with a descriptive name.

• The fields are variable in length, with special characters designating the beginning and ending so that the format remains valid, even if the length of a field changes and text fields can take whatever space is required.

• A receiving program can select fields of interest based on the tags and ignore any other fields that may have been added by the sender, so the receiver can continue to use documents that have been expanded for other purposes.

• XML is used to specify the structure of XML documents (using XML Schema) so that shared specifications can be used for computational validation.

• XML is also used to express the transformation of XML documents by using Extensible Stylesheet Language Transformations (XSLT) so that there is a standard, computer-interpreted language for document transformation.

• XML is independent of the computing platform and computer languages used to send or receive it, so there is compatibility between diverse sending and receiving technologies.

• XML can be exchanged using HTTP and HTTPS, protocols of the World Wide Web, so that existing ports are compatible and the data can pass through existing firewalls.

• The widely accepted standard for electronic signatures is based on XML. Standards for encryption and signatures for XML documents are discussed in Chapter 7.

XML, along with XML Schema (http://www.w3.org/XML/Schema), XSLT, HTTP, and related standards, has been developed by the World Wide Web Consortium (W3C). Though other forms such as electronic data interchange (EDI) are still widely used, XML has emerged as the preferred form for exchanging electronic documents between systems and enterprises. The verbosity of XML that increases communication overhead is a trade-off for flexibility.

An example use of XML follows. This XML document is structured to contain a collection of customer orders—in the example, there is only one order with two line items:

<?xml version="1.0" encoding="utf-8" ?>
< Orders >
 < Order orderID="103">
 < Customer customerID="1234"/>
 < OrderItems >
 < Item >
 < Product productNo="223445"/>
 < Description >
 100-watt speaker, Mahogany case
 </Description >
 < Quantity > 2 </Quantity >
 < UnitPrice > 235.95 </UnitPrice >
 </Item >
 < Item >
 < Product productNo="234523"/>
 < Description >
 CD Player, Mahogany case
 </Description >
 < Quantity > 1 </Quantity >
 < UnitPrice > 167.95 </UnitPrice >
 </Item >
 </OrderItems >
 </Order >
</Orders >

The XML expressions are indented for readability. Each expression begins with < name > to identify the data element (where name is the name of the data element) and ends with </name > (a slash prefix) to specify the end of the data element. An element may contain a primitive value (ie, a data type that is not defined in terms of other data types), another element, or multiple elements. A primitive element may be expressed with both a name and value together, for example, the Product element in the example, by ending the value segment with />, and other attributes can be expressed with the name such as at the beginning of the Order element in the example. < Orders > could contain multiple orders, but in this case, only one order is shown, which starts with < Order > and ends with </Order >. Within the Order are elements for Customer and Order Items. The Customer element only specifies the customer ID. There are then two order items, each containing several order-item attributes. XML structures are specified with a specialized XML language called XML Schema, so the format can be validated by a generalized computer program.

In many cases, these XML documents capture work products and decisions for which people or organizations should be held accountable, and some of these represent legal records or agreements that require encryption and electronic signatures.

Portal Support

Services are not only used by other service units but by humans as well. Even where a service is always invoked by an automated system, there likely is a need for human access to obtain information about the status of a request or associated data. The human users may come from across and outside the enterprise and include employees, investors, business partners, and customers. They need a way to find the appropriate services and to submit requests. This need for visibility of services to human users should be addressed by appropriate portals—a web site for each community of interest.

Generally, a portal is designed for use by a particular stakeholder community, and a community portal provides access to a variety of services of potential interest in that community. There may be multiple portals for participants in different collaborations where work is supported by specialized smart phone or tablet applications. Each portal should be owned by a service unit that manages the interactions with the associated community.

The design of a portal should address the particular needs of the stakeholder community, should have a consistent look and feel, at least for each community, and may include personalization features. Some portals will need to support internationalization. In addition, the service unit can address the need to translate the form of expression of requests and responses between the stakeholders’ point of view and the internal services that respond to their requests. The infrastructure should support the necessary portal technology.

Performance Monitoring

Effective management of a CBA requires that performance data be captured and made available for monitoring and analysis. This should include evaluation of performance measurements against level of service agreements. It should be possible to obtain current performance data on any service. These measurements should be accessible in the context of a current VDM model of the business and viewed through a management dashboard as discussed in Chapter 6.

Billing for Services

Though costing is primarily a financial responsibility, the IT infrastructure must provide the mechanisms by which service uses are tracked and charges are computed and billed. A billing infrastructure may not be essential in the early stages of transformation to CBA, but it must be part of the strategic infrastructure design.

Billing requirements and cost allocation have been discussed earlier in this chapter as a service unit design requirement.