Chapter 2. Service-Oriented Architecture

A service-oriented architecture (SOA) is a new business design paradigm, a fundamental aspect of the design of an agile enterprise that supports improved speed, cost, and quality. Service units are its building blocks. An SOA does not require electronic technology, but automation, integration, and modeling using electronic technologies are essential to an optimal implementation of SOA. The full implementation of SOA transforms the enterprise from top to bottom. This chapter provides a first step in understanding the fundamental nature of this new business design paradigm. As we move through later chapters, we discuss other aspects of the agile enterprise and examine how they complement or support SOA. In Chapter 9, we see how SOA is driven by and supports agile enterprise governance for more effective leadership and accountability.

SOA enables the sharing of business capabilities where those capabilities may be used in a variety of business contexts. SOA provides the transparency that allows a shared capability to be provided by a service unit within the enterprise or as a service of a different enterprise. This offers the following business benefits:

• Economies of scale are realized through sharing resources and optimizing use of those resources.
• Quality and productivity are improved by enabling the development of special skills and capabilities that would not be justified for multiple, smaller operating activities.
• Improved consistency and control are achieved by placing responsibility for management of a capability in a single organization.
• Distributed operations are enabled through loose coupling and Internet-based communication of interactions between service units.
• Process optimization is enhanced by enabling each service unit to optimize the processes of the services it provides, with minimal impact on other service units.
• Greater assurance of regulatory compliance can be achieved through consolidation of regulated processes and related business functions.
• The enterprise gains the ability to utilize the most effective alternative sources of services such as outsourcing or operations in other countries.

In this chapter we begin to establish how these benefits are realized. This starts by developing an understanding of the nature of business services. Next we discuss the supporting infrastructure that is needed for services to be accessed and shared. Then we describe how services needed in an enterprise are identified and specified. We take an initial look at the relationship between SOA and value chain analysis. Finally, we briefly discuss approaches to enterprise transformation to SOA.

Business Services

Many in the IT industry have viewed services in a SOA as computer applications, components of applications, or technical services that support applications or IT operations. SOA gained popularity as a basis for an enterprise to engage the services of other enterprises over the Internet. The expectation is for a computer application in one enterprise to automatically invoke an automated capability provided by another enterprise through communications over the Internet. This differs from previous systems integration technologies because industry standards now enable the participants to communicate over public facilities, effectively and securely, even though the participants use diverse application technologies and hide their internal operations.

However, this use of services of another organization implies more than just a computer application. It implies the existence of an organization responsible for the application, the existence of a business capability that is offered by a service provider and needed by the service consumer, and a commitment to the exchange of value between the participating organizations. SOA is an architecture for business relationships.

SOA should not be viewed as applicable only to interchanges between enterprises but as an architecture for the composition of an enterprise. The same integration standards that enable integration of services over the Internet also enable organizations within the enterprise to provide and consume services among each other.

In this book we view a service as the delivery of business value through the application of business capabilities. We titled this section “Business Services” to clarify that we are talking about a business perspective and that the services are visible and sharable across organizational boundaries. Throughout this book, when we talk about a service, we are referring to the delivery of business value; when we talk about a service unit, we are referring to an organization that manages a business capability to deliver services, not just an information technology application or component.

So a “service unit” may offer a repair capability (repair services), and the performance of a specific repair is delivered as a “service.” A service unit is not required to use electronic technology, but as a practical matter in most cases it uses electronic communications and computer applications to support the management of its capability and delivery of value.

In this section we explore in greater depth the nature of services and service units as components of the enterprise.

Service Units

A service unit is a sharable capability, as depicted in Figure 2.1. The capability is shared through the exchange of information and value in forms that are understood by the service provider and each service user. We refer to the specification of this interchange as an interface specification. A well-defined interface enables different service users to incorporate the services into their business activities. It also enables the service provider to change the implementation without requiring implementation of changes by service users.

Figure 2.1. Service Unit as a Shared Capability.

The interface may involve the exchange of information and assets. The interface specification may include the forms of data exchanged, an exchange protocol, rules regarding restrictions, and levels of performance and quality. For the most part, electronic technology is expected to provide the medium of exchange of information. However, there are still other forms of media, particularly paper forms and voice communications. Whereas electronic media require technical interface specifications, exchanges using paper forms may rely primarily on the specifications embodied in the paper forms and the mechanisms for transport, security, and accountability traditionally accepted for paper-based business transactions. Protocols and content requirements for voice exchanges may be guided by contracts, documents, or spoken instructions. Voice communications are typically captured on paper or entered into an online system. As with other, nonelectronic forms of exchange, mechanisms are required for transformation between paper and electronic forms for integration of services.

The exchange between a service user and the service provider generally begins with a request from the service user. The request defines the requirements that address the specific needs of the user; it establishes the context for the service delivery. In some cases, such as where a service provider solicits business, the exchange may not be initiated by the service user. The common element is that the service user defines the context in which the service is used. So the response to a solicitation may be a specific request that identifies the application of the service to a specific need.

The service is provided by a business entity that takes responsibility for the result. The capability may involve people, raw materials, facilities, and intellectual property.

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 user, 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 not a concern of the service user, and the implementation is most likely hidden from the users.

The people, materials, facilities, and intellectual property of the service unit are the responsibility of the service unit manager. A service unit is an organizational component that in some cases may be an independent enterprise but in most cases is a team of people within an enterprise, along with the assets and resources they use to fulfill their responsibilities. So a service unit is a business unit that manages a capability to provide one or more services.

A service unit does not necessarily contain all the capabilities required to deliver its results; some parts of its responsibility may be delegated to other service units. Delegation removes control of the delegated operations and associated resources, but it does not relieve a service unit of the responsibility for delivering its value.

Figure 2.2 illustrates a service unit that uses other service units. A request for a service invokes a business process within service unit A. That business process may engage a person, an application, or other service units (B and C) to fulfill its service objective. Business processes play a key role in the operation and integration of service units, as we will explore in detail in the next chapter. Other supporting service units may be used by the primary service unit to contribute their special capabilities to the original request or to maintain or improve the primary service capability as support services.

Figure 2.2. Integration of Service Units.

This use of services within an enterprise is not new. Many formerly paper-based services are still evident in today's organizations and are typically embedded in the computer applications that support them. The paper has been replaced by electronic transactions. This is particularly evident with customer order processing, accounting services, human resource management, and purchasing activities. Unfortunately, many internal services that were automated 50 years ago are locked into the processes that are embedded in enterprise applications used to automate them.

SOA for the Enterprise

So an SOA is not simply an approach to designing computer systems; it is an approach to designing the enterprise. Shared capabilities are utilized in different contexts to achieve economies of scale and consistency of operations or control. The computer systems should be designed to align with the design of the business.

In fact, everything an enterprise does can be structured as a composition of service units. These service units are knit together by business processes. If the service units are defined with appropriate granularity, they can be shared and incorporated into new business endeavors as the business continues to change over time. We discuss an approach to identification of appropriate service units later in this chapter.

The organization of a tool and die shop illustrates how SOA supports agility. The shop uses job routings of work to engage a combination of services and to define the sequence of operations needed to deliver custom products. The shop has a number of specialized tools and machines, along with groups of specialized tool and die makers who operate particular machines and apply their skills. The various specialists provide different services. As a job comes into the shop, a dispatcher prepares a job routing (that is, an ad hoc business process) that defines the sequence of services to be performed. The skills, tools, and machines used in each department remain unchanged, but a wide variety of products are produced. The shop is highly adaptive.

Service Unit Template

Figure 2.3 depicts the general characteristics of a service unit. The service unit contains the business processes, applications, rules, resources, and assets to achieve the desired capability. Usually there will be a primary service and ancillary services such as to cancel, change, or request status of a service previously requested. There might also be a request for a quote to establish the charge for a service, given certain parameters, before the actual service request is submitted. The arrows indicate the direction of initiation of an exchange: from the service user to the service provider.

Figure 2.3. A Service Unit Template.

A service unit uses input materials and produces a work product that contributes business value. These materials may be supplied with a request, and the work product may be returned to the requester. However, often the service unit acquires materials in other ways, and the result may be delivered to a consumer other than the service requester. The arrows for materials and work products depict the flow of value consumed and value produced.

For example, in a manufacturing department, a production schedule may direct the manufacturing department to produce batches of certain parts and deliver them to another department. The schedule may also direct source departments to supply batches of materials used to produce the parts. Consequently, the flow of material from source departments and resulting parts to consuming departments is distinct from the flow of control exercised by the scheduling system. This value flow is important when discussing value chains and will be visited again later.

A service unit provides a capability, not necessarily just a single service, so a service unit may offer a variety of services to address the different needs of users (usually through different request types defined for the same interface). At the same time, if there are too many different services to access the same capability, the implementation of the service unit may become more complex and less flexible. Multiple services will require multiple processes that will all require consideration if the service implementation changes. 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. The service unit should be designed to accommodate a variety of service parameters and specifications that enable a generic service to meet a range of user requirements.

Note that billing for services is not explicit in the diagram, but it is an essential aspect of any service. Each service unit must recover its costs, and the cost of each service must include the costs of services it uses. This is essential for effective motivation and governance and will be discussed more extensively in Chapters 7 and 9. The cost of services internal to the enterprise is determined by financial cost analysts, whereas the cost of external services is determined by negotiation of service prices with external providers. Billing is typically incorporated in accounting services, but a statement of charges may be incorporated in the response to a request, particularly if the charges vary depending on the specifics of the request. The behavior of service consumers is influenced by the cost of services, and information on the cost of individual requests may drive cost improvements. Where there is a choice of alternative provider, a quote request may provide the basis for selection.

The service unit may not directly perform all aspects of the service itself. Thus there are requests to other services depicted at the bottom of the diagram. These are other shared capabilities that either do not fit well with the capability of this service unit or are shared by yet another community of users. A requester of this service should not be aware or concerned that other services are invoked to fulfill part of its request.

The Value Chain Services arrow represents the use of services that contribute direct value to the units of production. For example, a product sales service may incorporate an order fulfillment service, and the order fulfillment service may incorporate a stock picking service, a packaging service, and a shipping service. These are all value chain services that contribute directly to the delivery of value to the end customer.

The other services indicated with dashed arrows at the bottom of the diagram are 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 chains that deliver value for the management of the enterprise and the individual services they support. These support services also have value chains that are the focus of analysis in considering the design and performance of support services.

Service Ownership

From an organizational perspective, a service unit, or more specifically, the service unit manager, owns (has financial responsibility for) the service capability. The manager that “owns” the service unit is responsible for the efficiency, reliability, quality, and responsiveness of the services. The service unit employs skilled people and technology to achieve its objectives. It must manage its resources to achieve appropriate business value.

The manager is responsible for maintaining and improving the service capability and for managing the performance of services that meet the specifications of the service unit interface. The manager is responsible for ensuring that delegated services meet the needs of the service unit even though the manager does not have control of the capabilities for the delegated services.

Responsibility also includes the functionality of computer applications used by the service unit, even though technical development, support and execution of the applications generally is delegated to information technology services. The manager may be more directly involved in the specification of automated business processes, depending on the usability of available business process management tools.

The IT organization is one of the service providers that enable other service units to fulfill their responsibilities. From the viewpoint of the requesting service units, the services of the IT organization are business services as well. Managers of IT services have responsibility for effective use of the technology and must manage their services to minimize technical diversity for economies of scale, quality, and responsive support. IT may employ a variety of shared services not visible to the users of IT services.

The interface to a service unit, the specification by which services are requested and delivered, should be well defined and, at the same time, appropriate to utilization of the service in a variety of contexts. Though the service unit owner cannot unilaterally change the interface, it should be possible to change and improve the internal implementation of a service unit with minimal effect on the users of the services or other services it uses. We examine the organizational implications of the service unit in greater detail in Chapter 7, as well as the implications to governance, enterprise optimization, and agility in Chapter 9.

The carving up of the enterprise into well-defined service units assigns responsibility based on the nature of the work. The separation of service use from service implementation enables management to empower service unit managers to take the initiative to improve their operations. It enables management to identify specific service units to resolve problems and to be accountable for results. In Chapters 7 and 9 we will discuss the design of organization structure and governance to drive improvements.

Service Groups

Sometimes services are bundled into a service group that is managed by a single organization. The service group represents a composite capability that exposes interfaces to distinct services but may or may not be organized, internally, as a collection of service units. A complex capability that supports a number of interdependent services may be managed in this way for consistency and economies of scale.

The IT organization or the application development and data processing operations segments should be organized as service groups. An outsourcing service provider may be viewed in this way where the provider offers interfaces to various services but does not expose the internal design of its operations. A legacy enterprise application may be “wrapped” (hidden behind a technically compatible interface) to provide services but may not be easily partitioned to support separate service units, so it can be viewed as a service group. A service group may also be used as a phase of transformation where a composite capability is consolidated and later partitioned into separately managed and more independently sharable services.

Services in Electronic Commerce

In general, electronic commerce between enterprises can be viewed as an 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. Banks provide services for accepting and distributing funds, and transportation carriers provide services for pickup and delivery of packages. The primary difference between internal services and electronic commerce involves concerns about security and trust.

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 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 for SOA are discussed in Chapter 6.

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 this book, but electronic signatures that establish legal obligations are addressed in Chapter 6.

Services in a Value Chain

A service delivers value to a service user. If the service unit uses other services to produce its value, we can view the linking of services-using-services as a chain of value contributions—a value chain. Because each service unit contributes in response to a request, the relationships form a tree structure. For a made-to-order product or service, there is a value chain that starts with the service that accepts the customer order and directly or indirectly links to all the services required to produce the customer value.

Figure 2.4 illustrates a service request tree in which the solid-line arrows represent the request-response relationships from services requesting value to services providing value. The dotted line arrows represent value contributions—the value chain. This is a simplified portrayal, since value contributions may not be aligned with the request-response paths, but they can be transfers directly to service units that require them as inputs. Nevertheless, the customer value is a composite of the value contributions of each service unit. If the chain is sequential, the time from the request to the delivery of customer value is the sum of the times it takes each service to contribute its value. The quality of the product or service is dependent on the quality of the contributions.

Figure 2.4. A Service-Oriented Value Chain.

This value chain concept is fundamental to the management of the agile enterprise. Customer value is delivered by management of the production value chain. There are other value chains internal to the enterprise, such as the value delivered to internal customers by accounting or information systems. The cost, quality, and timeliness of future products can be analyzed by consideration of a new product value chain. Analysis of value chains provides insights and priorities for improvement of performance and analysis of feasibility and risk associated with new products.

At the same time, each value chain is a use case of the services it uses. Different lines of business use some of the same service units, with somewhat different requirements, to deliver their value. A goal of the agile enterprise is to define service units that can be incorporated in different value chains with little or no change to the service units.

We will return to further discussion of value chains later in this chapter.

The Organizational Dimension

The service request tree is not an organizational hierarchy. The service unit request tree and the value chain both cross organizational boundaries and engage service units managed by different organizations. Figure 2.5 depicts the relationship between a hypothetical value chain for delivering customer value and the various organizations that contribute value.

Figure 2.5. Service Units in an Organization Structure.

The dotted-line boxes represent organizations and the smaller boxes represent service units in those organizations. Though some service units invoke other services within the same organization, the service units are most likely peers within the organization structure. The Process Order service unit manages the customer order from start to end and invokes other services to achieve the desired result.

In contrast, in a traditional enterprise, the left-to-right order of the organization boxes might also be the process flow, starting with the receipt of the order and finishing with the receipt of payment. Each of the departmental systems would complete its responsibility and pass control to the next department. However, such a process flow is very inflexible, and nobody is accountable for the overall result. Each department must know where the order goes next. If a different product line is introduced, each department must change its processes to add, modify, or bypass functionality for the new product line and properly direct the result to the next department.

For example, suppose the enterprise decides to sell some products for delivery direct from the manufacturer instead of from a warehouse. There would be no warehouse activities, back orders, or shipment activity for those products. The Process Order service might simply request shipment of the product by the manufacturer and track the shipment once the product was shipped. In the service-oriented value chain, the change would be accomplished by modification of the business process for the Process Order service unit for the new delivery model.

However, it is important to note that material flow does not necessarily follow the service request paths. In Figure 2.5 the products would likely flow from Pick Order to Pack Order and to Ship Goods. The material flow generally aligns with the value chain dependencies that we will explore later. The material flow recipients may be designated with a parameter in the associated service request.

In Chapter 7 we explore in greater detail the relationships between service units and the organization structure.

Service Unit Management

Service unit management can be viewed from two perspectives: management controls, which govern how the service unit participates in enterprise endeavors, and management of the service unit implementation and operation, which determines how the service unit produces business value.

Management Controls

Figure 2.6 extends the earlier service unit template with management inputs and outputs. The left side of the diagram depicts inputs that affect the operation of the service as a result of disruptive events, shifts in workloads, changes to requirements from service users, investment for changes, or business rules reflecting changes in policies or regulations. On the right side are outputs required from the service unit to support accountability through cost and performance reporting as well as escalation of opportunities and threats that cannot be addressed effectively by the service unit alone.

Figure 2.6. Addition of Service Management Interfaces.

A service unit is required to comply with its service interface specifications. These specifications are effectively a contract 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.

Note that the cost of services reported on the right of the diagram includes both the total cost of the service unit and the cost that is billed for individual units of service. The overall service unit cost is a more accurate specification of cost elements and reflects the cost of the service unit during a particular time period with a particular volume and product mix. The cost that is billed is based on a cost analysis that determines the direct costs plus an allocation of overhead costs for each unit of value produced. The requirements of cost accounting are discussed further in Chapter 9. Ideally, for a particular time period, the total computed for production unit costs and the total cost of the service unit are close to the same.

Service Implementation Management

Internally, the manager of a service unit and his or her management chain have responsibility for operational management and change management. Service unit management may have considerable discretion in how the services are performed, as long as they comply with the service interface specification. From a business perspective, the service interface specification includes specifications for the form and content of the request, the specification of interactions, and the level-of-service specifications.

A primary role of the manager and the employees is to optimize operation of the service unit. In a sense, the manager is responsible for an internal enterprise, and the manager and his or her team must work together for the success of their enterprise. In many cases this requires collaboration with related service units to resolve problems and refine interface specifications.

Managers must also respect enterprise rules and standards. Rules include government regulations and constraints that mediate risks. Standards ensure effective integration as well as optimization of other enterprise operations such as consistent use of information technology to achieve IT economies of scale.

A service unit manager is expected to operate the service unit reliably and at minimal cost. At the same time, a service unit manager is expected to continuously improve service unit operations, respond to threats or opportunities within his or her discretion, and adapt to new enterprise requirements that affect how the service unit capability is applied. From an enterprise perspective, service unit performance must be considered in the context of the value chains to which it contributes, and an appropriate balance must be achieved among cost, quality, timeliness, and risk while meeting regulatory and policy requirements. Some changes are strictly within the discretion of the service unit manager, but others, such as investment in new tools or technology changes, may require approval at an enterprise level to ensure enterprise optimization. In Chapter 8 we discuss further the role of the service unit manager in response to disruptive events.

SOA Electronic Infrastructure

SOA for business does not mean that all services are accessed electronically nor that all services use computer applications in their implementation. However, in today's world, the normal case is that integration and implementation are supported by electronic technology. Manually performed services with paper or voice interfaces are the exception. Even those are likely to require some form of integration through the electronic infrastructure.

Therefore, an electronic infrastructure—computing, communications, and associated software and supporting resources—are essential to SOA and the agile enterprise. The infrastructure must support standards and consistent implementation to minimize cost and complexity, to enable sharing and flexibility, and to enhance speed, reliability, and economies of scale.

This infrastructure, along with adaptation of existing systems, requires an up-front investment that increases the costs of early SOA projects but provides significant benefit and lower costs in the long term.

There are several fundamental components that must be part of the enterprise electronic infrastructure to support the integration and operation of service units. Figure 2.7 depicts the key infrastructure components discussed in the following sections.

Figure 2.7. SOA Electronic Infrastructure.

Reliable Messaging

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 senders don't need to wait for receivers to be ready or respond, and receivers don't need to take immediate action.

An integration component (including messaging, transformation, and access control) is associated with each of the services in Figure 2.7 (the gray areas). Each service unit is capable of exchanging messages with any other service unit, and these exchanges could extend outside the enterprise.

Generally, messages are 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 some business environments, it is necessary for service units to be more tightly coupled to meet performance objectives. These environments may use synchronous messaging technology whereby requests are communicated immediately and the requester waits for a response. The disadvantage of such tight coupling is that when one of the participants fails, everything stops. There is also less flexibility in the integration of different application technologies, and loose-coupling technology enables easier integration of diverse technologies. Tight coupling is acceptable for applications within the responsibility of a single organization but should be avoided, if possible, when crossing significant organizational boundaries.

Security

The infrastructure must provide appropriate protection for the communications between service users and service providers using encryption as required. It must provide the means for determining the identity of participants (called authentication) and for determining whether participants are permitted to make certain requests or receive certain information (called authorization). These access control mechanisms must be complemented with logging and audit support, to ensure accountability and expose inappropriate accesses.

Each service unit in Figure 2.7 has an access control component that uses the security service. The security service unit includes identification, authentication, and authorization services.

In an SOA, many users are expected to directly or indirectly access many systems. This is partly because optimization of operations requires cross-enterprise access to data and because shared services may be used in a number of contexts. Users should be able to sign on once and then be able to access a number of systems for which they have authorization; this is called single sign-on. In addition, this authentication should be supported with a Public Key Infrastructure (PKI) that provides management of identifiers and keys for encryption and electronic signatures. Auditing also becomes more complex because the behavior of many users, potentially in many different locations and organizations, must be assessed to identify security risks and violations. Security issues for SOA and the agile enterprise are discussed in Chapter 6.

Message Transformation

Message transformation is required to convert the format of message content to be consistent with an enterprise logical data model for exchange or to convert the format of a message being sent to meet the requirements of a receiving service or application. Initial service implementations must be integrated with existing systems, so message transformation is required.

Since commercial software products (e.g., enterprise applications) are unlikely to conform to the logical data model of the particular enterprise, transformation is probably required on messages exchanged with these applications. In the long term, there may be less need for transformation, but when there is a change to meet new requirements, message transformation may be required for the transition until all senders or receivers of a message type have been upgraded.

Figure 2.7 depicts a transformation capability at the interface to each of the service units. This anticipates that at various times, as new versions of services are implemented, there will be a need for transformation, if only on a transitional basis.

Registry Services

Registry services maintain current information about available services. At a minimum, a registry should provide links to available services so that users of a service can refer to a logical name of the service and be directed to the appropriate network address that may change over time.

In addition, the registry should identify different versions of service interfaces so that either a compatible version can be located or the interactions can be properly adapted or transformed. The registry should provide criteria for the selection of a service from among similar services. Within an enterprise, there is typically only one appropriate service for a shared capability, but that is not always the case. For example, there could be services based in different time zones or different countries, specialized for different product lines, or located in different physical facilities. The registry might also be extended for identification of approved external services such as supplier services, including, for example, suppliers that might be eligible to bid on a particular class of purchase request.

It may be useful to include additional information on each service for general reference, business management, system configuration, and change control purposes. The registry services should complement or extend the configuration management database (CMDB) of IT operations that supports management of applications and IT infrastructure.

It is necessary for data processing operations people to have access to information about the interoperation of service units, to understand the implications of system failures and to plan for disaster recovery contingencies.

Business Process Management System

Automation of business processes should be an integral part of an SOA implementation. A business process management system (BPMS) is a set of applications used to define business processes, execute them as automated processes, and analyze them for process improvement. Though an enterprise may have multiple BPMS software products, a preferred BPMS should be available for automation of business processes anywhere in the enterprise so that it is readily available as new processes are defined and deployed. Use of a single BPMS reduces licensing costs, eliminates incompatibilities, and enables everyone to use the same tools and representation in designing business processes.

In general, the scope of business processes should align to service unit boundaries, and BPMS products should be integrated through exchanges of messages between processes in different service units using the SOA infrastructure.

In Figure 2.7 the BPMS is depicted as a component of the service units. This is to indicate that the business processes executed by the BPMS are components of the service units, but they may, in fact, be executed by one or more shared BPMS products.

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.

Generally, each 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. Community portals should provide Web pages that link users to services of interest. 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 may need to support internationalization and access with mobile devices. 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.

Service Performance Monitoring

Effective management of the service-oriented enterprise requires that performance data be captured and made available for monitoring and analysis. It should be possible to obtain current performance data on any service unit and aggregate service data to assess performance for a value chain. The nature and implications of value chain analysis are discussed further later in this chapter and in Chapter 9 on governance.

Performance monitoring is depicted as a service unit in Figure 2.7. The service unit may accumulate and report performance data, but the BPMS associated with each service unit being monitored should provide the raw performance data for business activity monitoring (BAM).

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 SOA, but it should be part of the strategic infrastructure design.

Each service unit must include in its billing both the costs of its operation and materials and the costs of services it uses, and it must recover its costs from its consumers. Thus a billing represents the full cost of the value delivered by each service, regardless of whether the service unit uses other services to achieve its results or performs all the activities itself. For internal services, these costs do not include any profit margin; for external services the cost is the price charged by the service provider and can be expected to include profit.

As with performance monitoring, the business processes in each service unit must provide billing data to the billing service unit for services rendered.

These charges propagate up the value chains to reflect the current production cost of products and services. This, in turn, supports process improvement planning, pricing, and profitability analysis. Cost accounting is discussed in greater detail in Chapter 9.

Defining Service Units

How big is a service? From a service user's perspective, services come in all sizes. A tool crib activity is a service. A payroll processing activity is a service. An auto repair shop is a service. A transportation carrier is a service. A Web search engine (such as Google) is a service. A travel reservation system is a service. Manufacture of a jumbo jet can be viewed as a service. What do these services have in common? They apply business capabilities to deliver value in response to requests from a variety of service users.

The value delivered by these services ranges from application of a specific capability to integration of contributions of multiple capabilities. Whereas a complex service can be delivered by a single service unit, the result may be achieved by engaging other service units that may, in turn, engage still other service units. Delivery of a complex product may engage, directly or indirectly, most of the service units of a large enterprise and potentially some outside the enterprise.

The question is not how big is a service but how big is a service unit. Service units should be relatively small so that they focus on the application of a distinct business capability. The size should represent an appropriate balance between a focused capability and economies of scale. In our examples, the tool crib may be a simple service unit, while a travel reservation system may have a service unit that interacts with the customer but then engages other services to arrange for hotel reservations, rental cars, and airline reservations. The jumbo jet manufacturer may involve multiple service units just to capture and validate an order, and then many services are engaged, directly and indirectly, to build and deliver the jumbo jet.

In this section we describe the process of identifying service units that are the building blocks of an agile enterprise architecture. This is a top-down analysis based on value chains. It identifies service units of a strategic architecture as a basis for understanding business transformation requirements and development of a transformation roadmap. Most enterprises are not ready to undertake such an analysis until they are ready to move to level 3 in the SOA Maturity Model.

Service-Oriented Analysis

This analysis starts with a conventional value chain model. As we have discussed earlier, the enterprise has multiple value chains. Generally, analysis for an enterprise starts with the primary value chain(s) that delivers end-customer value. As the enterprise matures, the scope of analysis expands to include product life-cycle value chains (including product development) and value chains for supporting services.

The ideal approach to identification of services is analysis of the enterprise from the top down. This ensures that the definition of services is driven by the business of the enterprise and avoids repackaging the same old way of doing business. It also provides the greatest opportunity to identify sharable capabilities and to understand how the same capabilities may be used in different contexts. At the same time, it requires a substantial investment in analysis, planning, and design.

Note that the goal of service-oriented analysis is to break out the various business capabilities such that, as much as possible, individual service units experience little or no need for change as the enterprise pursues new business opportunities and goes through substantial transformations. The expectation is that the line-of-business processes may change, and some of the detail of tasks may change, but the service interfaces and their fundamental capabilities persist.

Value Chain Analysis

Figure 2.8 illustrates a conventional value chain model used in strategic planning for a made-to-order product. This value chain depicts broad areas of responsibility and a general transition through those responsibilities to deliver customer value. We refer to each of these responsibilities as a role. The figure represents the role of the associated capability in producing value for the end customer. Each of the high-level roles is broken into supporting roles.

Figure 2.8. Conventional Value Chain Models.

We distinguish this conventional value chain from a robust value chain (RVC), which is a dependency network defining the contributions of value to the customer result. The conventional value chain represents the common approach used by most enterprises and is sufficient for service-oriented analysis at the lower levels of the SOA Maturity Model. The RVC model is important for achieving the benefits of maturity levels 4 and 5. We will discuss the RVC model in greater detail later in this chapter.

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 Figure 2.8b. Figure 2.8c 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, but it might not be convenient for capture of the requirements of the specific roles. Regardless of the form, a conventional value chain model is a useful starting point for analysis.

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.

We refer to these capability requirements as roles because they define the need for a capability to produce a particular result. A role defines a use of a capability. Therefore, the work breakdown structure becomes a hierarchy or tree structure of roles. Using the concept of roles, we focus on what needs to be done rather than who will do it, thus separating the structure of the analysis from the existing organization structure. We'll expand on the concept of role in a moment.

The enterprise may have several lines of business with different kinds of products and services. Each of these has a value chain. If they all require generally the same roles, the analysis can proceed with the simplifying assumption of a single value chain. However, as the level of detail increases, it is likely that a need for different roles will emerge. The objective is to identify the various roles that must be filled to meet the needs of all products, since all such roles must be filled to support all product lines. We discuss mechanisms for addressing the requirements of various products in Chapter 3 as an aspect of managing process variations.

A value chain should be viewed as a use case of enterprise capabilities. The variations in uses of similar capabilities provide the basis for defining the capabilities of shared service units. The roles define the contexts and associated requirements for which the service units will be used. More value chains and thus more use cases help define more robust and reusable service units.

Not every role defined in this decomposition will be filled by a service unit. The goal of this analysis is to break down the roles to a level of granularity that requires a distinct capability that either is appropriate for assignment to a single team or member of a team that does a type of work or is a capability that is provided by an external organization. So the important roles are the leaves of the tree where actual work gets done.

It is important to note that a level in this hierarchy does not establish a degree of complexity or magnitude of the underlying capability. For example, in a manufacturing hierarchy, “ship the product” might be a simple action at the end of the value chain, but it can invoke a variety of processes involving many facilities and personnel of external organizations to get the product delivered to the customer. The manufacturer views this as the use of an abstract capability that results in the customer receiving the product.

Each role is broken down into subordinate roles that would need to be performed to fulfill the requirement, and the capabilities needed to satisfy each of those roles must be considered. If a subordinate role capability requirement is reasonably consistent with the parent role requirement, it may be performed within the same service unit, but if it is a distinct capability, particularly if it requires different resources, disciplines, or independent control, it should be identified as a role for another service unit.

The size of an organization providing the capability is a factor to consider. A larger organization provides more opportunity to specialize and thus may be further segmented into different service units.

For example, in the job shop we described the routing of a job to different types of tool-and-die operations. In a small shop, all the tool-and-die makers and their machines would be in a single service unit because some would operate multiple machines and perform different tasks, depending on the workload. In a large shop with maybe hundreds of machines and personnel, service units might be defined for each type of operation, such as milling, grinding, shapers, lathes, fabrication, assembly, and so on. Service unit managers would then focus on the specialized skills and performance of their workers and the supports needed to achieve high levels of efficiency and quality. The enterprise might also offer specific tool-and-die services to outside customers.

Roles

A role defines a need for a capability. It defines what needs to be done and the context in which it is to be done. At an operational level, the context is specified in a request to a service unit. A participant in a role may be a service unit, a person or persons, or a machine (e.g., a computer application). Fundamental capabilities are satisfied by people or machines. That is where work actually gets done. The analysis proceeds iteratively to break down roles, to define supporting roles until fundamental capability needs are identified.

As the analysis proceeds, the following characteristics are captured for each role:

• An objective to be satisfied, or, in other words, the value to be produced
• The context in which its objective is to be accomplished, including relevant specifications and parameters
• An output that defines the resulting work product and the value produced
• A description of the capability needed to fill the role
• Input material used to produce the output; the material is often a work product of another service unit or business entity
• Qualifications, selection criteria, that characterize the needed capability; qualifications might include a person's job code and required credentials

The participant in a role may be required to have some or all the following types of capabilities to fulfill the role and achieve the objective:

• Intellectual capital
• Tools and facilities
• Raw materials or work product components
• Information resources
• Personnel with particular skills
• Proximity to related resources or business activities

Service Unit Consolidation

Roles that call for similar capabilities represent the potential for the needs of these roles to be met by the same service unit, i.e., a shared capability. Some roles may call for a similar capability, but the context and result are sufficiently different that they could not be satisfied by the same service (yet possibly by the same service unit). These similarities should be noted, but consolidation should be deferred to ensure that the implications of each of the services are considered in the further breakdown. Once the breakdown is complete, services that require similar capabilities can be consolidated into service units representing shared capabilities that may provide multiple services. When this consolidation is applied, the relationships of services are no longer a tree but a network where some branches are joined together to use a shared service unit.

The consolidated service units need not come from the same level in the hierarchy; in fact, there could be recursion where a higher-level service unit uses other service units and one or more of those uses the higher-level service unit again in its context.

This consolidation achieves two important objectives: (1) it identifies multiple contexts in which a shared service unit can be applied, and (2) it reduces the explosion of detail, since the detail of a consolidated service unit need be expanded only once.

It may be necessary to modify the definition of some roles to fulfill them with shared services. In some cases, a parent and peer nodes may need to be modified to provide a more appropriate scope or objective for a role and thus the shared service it uses. In other words, the groupings of what needs to be done are modified to achieve consistency of shared services.

When a role has no similar role, an associated service unit may not be shared. We might not define an associated service unit but instead include it within the service unit supporting its parent role. It may then be viewed as a subprocess within the parent role's service unit, but such subprocesses are not intended to be shared outside the service unit. They are essentially more detailed specifications of the way a capability may be applied. This could be fine if the required capability is similar. However, it may still be appropriate to support the role with a distinct service unit if (1) the responsibilities or capabilities of the host node or peer nodes are quite different from the target node, (2) the capability is such that it may be shared in future business activities, or (3) the capability should be managed independently for accountability, optimization, or control.

Services that require similar capabilities but are expected to require different processes should be reviewed for potential consolidation. Consolidation depends on the similarity of the capability and the work to be done. The service requirements should be compared to determine whether they can be reconciled to a single service request type, potentially with different request options, or whether distinct service request types are needed. If there is an opportunity for economies of scale, consolidation is more desirable. Consolidation also should be considered in the context of organizational design criteria, discussed in Chapter 7.

Work Management Service Units

Each service unit should have the business processes to manage its work. The design of the business process is often a major factor in the performance of the service unit, and the service unit manager should have as much discretion as possible to make internal improvements to service unit operations.

However, there is a need for some service units to manage work across other service units. At the enterprise level, this takes the form of customer order management. For major enterprise undertakings, there may be a program management office.

There also may be needs for intermediate work management service units. These work management service units coordinate and control the work of multiple service units to achieve optimization that cannot be achieved within the individual service units. The following are examples of factors to be considered for consolidated work management:

• Batch production, balancing setup costs against responsiveness 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 service units
• Selecting operating location for utilization of special machines or product distribution
• Designing a solution and selecting contributing services
• Sequencing work to manage priorities
• Managing change and rework

Generally, the work management service unit will be in the same organization as the service units for which work is managed so that a single manager is responsible for achieving the appropriate balance between service unit optimization and customer service. Placement of work management service units in the organization must be considered in the organization design discussed in Chapter 7.

The work breakdown structure should not be confused with the management hierarchy. Though the high-level value chain responsibilities may correspond to major business units, the business unit responsible for a particular service unit in the work breakdown structure may use service units managed in very different parts of the enterprise organization.

The management hierarchy is essentially an aggregation of service units. Service units are brought together to achieve further economies of scale and flexibility based on their similarities and work management requirements. We discuss this aggregation in greater detail in Chapter 7, where we focus on the agile organization structure, and in Chapter 8, where we detail the implications of decision making and agility.

Service Unit Interfaces

The service units are further refined by definition of the service interfaces. This clarifies the nature of the shared capability or the need to define separate service units. This reconciliation of the interface specification may uncover the need for alternative services (i.e., different request types), some differences in the input and output content, or generalization of the objective. A service unit may involve multiple interactions or related requests (e.g., change or cancel). This analysis helps clarify the capability and performance expectations for the service unit. It is preferable for all users of a service unit to invoke the same primary service process, since differences in service processes increase complexity and coupling between the service and its users.

Once service units have been identified, it is useful to look at the existing enterprise activities to identify where the capabilities currently exist. This provides additional context examples as well as more detail for the specification of service unit interfaces. This may also help identify additional capabilities that are needed to fully address business requirements.

Service Unit Specifications

As service units are identified, developed, deployed, and integrated, the specifications must be captured, refined, and maintained in an enterprise repository. We refer to this as the Enterprise Architecture Repository, which is a component of enterprise governance (discussed in Chapter 9) and the Enterprise Business Model (discussed in Chapter 10). This is distinct from the service registry that supports operational selection of services.

Note that though the focus is on service units that are electronically integrated and rely on automated business processes and applications, equivalent information must be included for manual services and exchanges based on paper or voice communications.

The following paragraphs describe key elements of the service unit specifications:

• Service unit name. A unique identifier for the service unit, typically the name of the primary service offered by the service unit or its capability.
• Offering description. This is a description of the capability being offered. It should be sufficient to qualify the service for roles as defined in the service definition analysis previously discussed.
• Interfaces and versions. Every service unit must have one or more service provider interfaces through which services are requested by people, applications, or other service units. An interface includes specifications of service requests and choreography if applicable. A single version of a service unit implementation may have multiple versions of an interface to accommodate the transition of users of the service unit from one version to another. Interface versions should also have effective dates, both when available and when deprecated.
• Versions and life-cycle status. There may be multiple versions of a service unit implementation in different stages of their life cycles: There may be versions under development, multiple current versions during a rollout to multiple sites, or versions that are no longer active but could be restored if a serious problem is encountered with a current version. Distinguishing features should be described. Service unit versions include software, business process specifications, resources, skills, facilities, or other aspects of the service unit that change to achieve a new service unit implementation.
• Billing specifications. This defines the basis for computation of service charges to be billed to service users.
• Level of service specifications. These are the performance targets for the service, primarily response times, scheduled availability, and quality of results that are measurable at the service interface. These are equivalent to level of service agreements; they define the basis for performance measures and should reflect the requirements and expectations of service users.
• Security and business continuity requirements. The level of security and business continuity requirements of the services go beyond the interface and level of service specifications to address implementation considerations involving other forms of exposure or disruptions of service. This includes the security of stored data and the recovery time after a system failure.
• Used interfaces and versions. These are references to the interfaces of other service units used by the specified service unit. Different versions of a service unit may use different versions of interfaces of other services.
• Scalability. Capacity limits or nonlinear impact of changes in volume on cost, timeliness, or quality. Of particular interest is the extent to which the impact of change in volume of production reaches a hard limit or becomes nonlinear so that, for example, a higher volume increases the unit cost.
• Strategic service architecture mapping. The enterprise should have a strategic architecture for the ideal services structure of the enterprise. This structure should specify the way each current service unit maps to that architecture. The strategic architecture is an enterprise-specific framework that may have been developed based on an industry framework (discussed later) or through the service-oriented analysis we discussed earlier.
• Access authorization policy. This is a statement of who qualifies to use the services offered and the process by which authorization is granted.

Development of these specifications should evolve over time but increase in importance as the enterprise becomes increasingly service oriented. These specifications are a component of the Enterprise Business Model (EBM) discussed in Chapter 10. It must be linked to other aspects of the EBM to support effective governance. Agile governance is discussed in Chapter 9.

Outsourcing

Outsourcing is the use of an external entity to provide client services that would otherwise be provided by an internal service unit or service group of the client. The purpose of outsourcing is to realize economies of scale and specialized capabilities that cannot be achieved within the enterprise. As the enterprise organization is transformed, it is important to consider outsourcing as an alternative to the transformation of existing capabilities.

When a group of capabilities are outsourced, their roles in value chains must be examined. Services of an outsourcing provider will typically replace capabilities of the client enterprise. If the client capabilities being replaced were shared among some other client service units that are not outsourced, the implications of losing these capabilities must be resolved. The outsourcing provider can be viewed as a service group with multiple interfaces that may or may not be supported by multiple internal service units. Potentially these interfaces will provide access to the shared capabilities replaced by the outsourcing provider. Of course, it is unlikely that the interfaces of the provider's shared services are compatible with the interfaces of the client's replaced service units, so there will be adaptation requirements.

If outsourcing is already established, it is not useful to expand the detail of capabilities that are expected to be internal to the outsourcing provider unless the provider has defined services that can be shared in other contexts. Generally speaking, the service provider implementation will be a black box, preserving the capability of the service provider to change its implementation to address new business challenges and opportunities. Exposing more shared services will limit this flexibility. At the same time, the services that are offered by the outsourcing provider should be reconciled with the capability requirements of the value chain breakdown.

The enterprise must manage the outsourcing relationship primarily as a service user. Managers within the enterprise do not control the resources or the operations of the outsourced service units. The enterprise must manage the services on the basis of a service contract, costs, and performance metrics, along with assessment of the satisfaction of internal users with the outsourced service.

The service interfaces require close attention. The interfaces are more difficult to change because the same services are being used by other enterprises. In addition, all requirements must be reflected in the interface specification; otherwise, there is no basis for corrective action if the service is not meeting expectations.

The service interfaces should be based on industry standards, if available. The enterprise should be able to switch to an alternative service provider if the current provider is not meeting expectations. Furthermore, the ability to switch to alternative services maintains competition between service providers to drive improvements in cost and performance.

Obviously, if the same services are available to competitors, they cannot be a source of competitive advantage. At best it moves the enterprise to a best-practices level of performance. At the same time, the management of the enterprise does not have the burden of managing the implementation or ongoing operation of the service, although it is important for enterprise management to measure performance and enforce service agreements.

The risks and benefits of outsourcing are outlined in Table 2.1.

Table 2.1. Risks and Benefits of Outsourcing

Risks	Benefits
Inability to take direct corrective action in service operations	Economies of scale across multiple enterprises (cost savings and workload leveling, driven by competition)
Service provider failure could bring the enterprise to a standstill	Service can leverage and retain specialists to ensure quality
No service employee loyalty to the user client enterprise	Service should be able to absorb changes in scale
Burden of contract management—monitoring performance and enforcing service agreement	May enable entry to new markets (e.g., address regulations in another country)
No competitive advantage	Should implement best practices

Role of Industry Frameworks

Industry frameworks provide prototypical designs of enterprises in a particular industry, based on generally accepted approaches and best practices. The frameworks tend to define characteristic breakdowns of functionality and business processes similar to the conventional value chain discussed earlier. The structure and content of an industry framework can be helpful in defining the SOA for a particular enterprise. Note, however, that each enterprise may be different due to individual circumstances or manner of doing business.

Service Units

A primary contribution of industry frameworks is to guide the definition of service units based on industry best practices. These service unit definitions tend to align with implementations of service unit capabilities in commercial enterprise applications and outsourcing services. Though industry frameworks are based on best practices, these practices reflect current approaches to doing business in the particular industry. Frameworks must be considered in the context of the particular enterprise under analysis. Care must be taken to define service units that enable future changes to the business. Use of an industry framework does not mean that a well-defined conventional value chain should be abandoned; instead, together they define more use cases for the definition of service units.

Data Models

An industry framework should include an enterprise data model. The role of a consistent, enterprise logical data model is discussed in Chapter 4. Use of a framework data model should be strongly considered early in the development of an SOA 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 SOA 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.

Processes

An industry framework may include best-practice business processes. These processes should not be assumed to be the best for a particular enterprise but should be considered as a starting point or basis of comparison to current practices. The most important value of these processes is to put the use of service units into context. The design of service units is more robust when a greater variety of usages is considered. The processes may also help identify resource and skill requirements.

Rules

Some frameworks may include business rules, which are discussed in Chapter 4. As with business processes, business rules should be considered points of reference but not necessarily the right rules for a particular enterprise.

Rules expressing government regulations may well be useful as they are. Rules expressing tax computations may be directly applicable. However, regulations, in general, still require interpretation in the context of the particular enterprise.

Framework business rules provide a basis for development of business rules for the particular enterprise, by focusing attention on particular issues and decisions that affect the operation of the business.

A Framework Example

The enhanced Telecom Operations Map (eTOM) from the Tele Management Forum (TMF) is a widely recognized industry framework. It is a business process framework for all processes of a telecommunications service provider. eTOM defines a process hierarchy similar to that previously described for the service-oriented analysis. The TMF has also defined a companion enterprise data model called Shared Information and Data (SID) that supports the Enterprise Logical Data Model requirement discussed in Chapter 5.

Figure 2.9 illustrates the eTOM framework at the enterprise level. It is described as a process framework that defines the business processes of the enterprise in a hierarchy. There are three major process categories: (1) operations, (2) strategy, infrastructure, and product, and (3) enterprise management. These are described as level-zero processes.

Figure 2.9. eTOM Framework.

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 Chapters 8 and 9 of this book. 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 the value chain.

The Operations and the Strategy, Infrastructure, and Product categories of Figure 2.9 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.

Figure 2.10 shows more detail for the Operations process. 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 service units. A similar breakdown is defined for the Strategy, Infrastructure, and Product level 1 process. More detailed breakdowns also exist for the Enterprise Management process. eTOM process models provide additional insights on capability requirements and the contexts in which they are used.

Figure 2.10. eTOM Operations Level 2 Processes.

Robust Value Chain Analysis

SOA brings added importance and rigor to the value chain concept. The general concept is to model the contributions of value toward the delivery of customer value. The value chain models that have been used for many years for enterprise analysis and strategic planning start with this general approach as a high-level abstraction, but as detail is expanded, they become essentially a work breakdown structure of capabilities needed to deliver value, but the chain of dependencies is lost.

We introduce a robust value chain (RVC) to be distinguished from the conventional value chain models and emphasize that it provides more rigorous support for strategic planning for new products as well as for improvement of existing products. It also supports better understanding of the consequences of operational problems. For brevity, we will refer to this dependency network model as a value chain or RVC model through the rest of the book.

Dependency Network

The RVC model is a dependency network of contributions to customer value where the customer may be an end customer of the enterprise or an internal customer. For example, value is provided for an internal customer when IT implements a new application or when human resource management enrolls an employee in a benefits program.

At a detailed level, the RVC is a use case of service units that contribute to the value delivered to the customer. We will refer to the participation of each of the service units as a value chain activity. The value chain is a dependency network because it depicts the dependencies of each activity (the service unit use case) on value provided by preceding activities. This is similar in concept to a PERT diagram of a project plan, where activities are shown as dependent on the work products of preceding activities. Unlike a PERT diagram, however, there may be no single start activity that enables the initial activities of a value chain.

Figure 2.11 depicts a value chain dependency network. The value delivered to the end customer is designated a functional product in the diagram. The product may be maintained in reliable operation through a preventive maintenance program, and it may be repaired based on a warranty. The product, per se, is shipped by a shipping service unit either from a warehouse service unit or from the assembly service unit. The assembly service unit depends on parts manufactured by other service units.

Figure 2.11. Value Chain Dependency Network.

The dependencies represent transfers of value. Examination of dependencies supports analysis of:

• The way capabilities impact customer value
• Significance of risks
• Product delivery weaknesses
• Significant sources of product costs
• Potential sources of identified problems
• Timeliness of customer response

Consequently, an RVC model is a valuable tool for management.

It is useful to develop the value chain starting with the completed value and working backward, just as it is useful to work backward from a completed project to develop a project plan. Generally this is not the way work gets done, although in some cases the dependency could be implemented as a request for the delivery of value and the request-response arrow would be in the opposite direction. For example, referring to Figure 2.11, warranty work generally gets done before the warranty repair organization receives payment. The warranty repair organization may actually request payment from the warranty claims processing organization and receive payment in return.

Abstract Activities

Except for the functional product, each of the activity circles in Figure 2.11 could be a service unit, or it may represent the contributions of several service units that have been aggregated to provide a higher-level abstraction.

We might provide a still higher-level abstraction by aggregating some of these activities, as indicated in Figure 2.12. These abstract activities look similar to the activities in the conventional value chain discussed earlier. It is desirable that these abstract activities correspond to organizational responsibilities so that there is accountability at higher levels as well as in the detail. For example, the Manufacturing organization should be accountable for the Produce Part activities and the Assemble activity. But note that the Manufacturing organization may do other things in other value chains or in the same value chain, so these aggregations are not comprehensive of the responsibility of the associated organization.

Figure 2.12. Value Chain Abstraction.

The objective of a RVC model is to develop the activity detail to the point where each value chain activity corresponds to a use of a service unit. Then, for each of the activities, the service unit should be able to provide a cost and duration for a service unit use case as a basis for product planning or analysis of operational performance for a particular product.

These activity costs and durations can then be aggregated to provide an overall cost and time to deliver the product to the end customer. Note, of course, that some activities occur in parallel, and some activities may occur before a customer submits an order, for example, the parts may be produced in anticipation of orders. Consequently, not all activities are part of the critical path from receipt of order to product delivery.

The example value chain we discussed is a primary value chain—it focuses on the contributions of value for an end customer product. However, there are other value chains that contribute value within the enterprise. These value chains may contribute value for developing or maintaining service unit capabilities, or they may contribute value to the enterprise for effective management and governance.

Hierarchy of Value Chains

As the enterprise achieves higher levels of SOA maturity, the scope of service-oriented analysis and value chain modeling should expand. The models should not only encompass the activities directly involved in customer value creation, they should also address all aspects of the enterprise. Figure 2.13 depicts this “enterprise value chain” perspective.

Figure 2.13. Hierarchy of Value Chains.

The production value chain focuses on the services that contribute value to the individual units of production—the primary value chain that is the focus of initial analysis. The product value chain expands the scope to include the product or service life cycle, including one-time efforts to develop the product and the production capabilities. The enterprise value chain encompasses the entire enterprise, including the services that are not directly involved in providing value for a particular product or service but are required for the successful operation and viability of the enterprise.

We will return to discussion of the value chain later in this book, particularly in Chapter 9, where it has a direct impact on strategic planning and governance.

Enterprise Transformation Perspectives

Enterprise transformation requires significant business changes that may be disruptive to current business operations and are likely to involve significant investment in the transformation or development of information systems. This section briefly describes alternative approaches, first from a business perspective and then from an information technology perspective.

Business Perspective

Transformation to an SOA enterprise is a lengthy journey. It must be undertaken a step at a time, with each step along the way providing business value.

The ideal approach to transformation is to perform a top-down, service-oriented architecture analysis with reference to an industry framework, if available, to develop a strategic architecture, and then use the strategic architecture as a basis for defining a roadmap for implementation of service units with high business value. This ensures that all existing contexts for the use of service units are identified so that the definitions of these service units are more robust. It also ensures that full opportunities for economies of scale are realized and that service units are defined for optimization at the enterprise level.

However, a full, top-down analysis is very ambitious, takes considerable time and investment, and may be difficult to justify to managers who are not yet sure what a service-oriented architecture is or are skeptical about the benefits and risks. The SOA Maturity Model, discussed in Chapter 1, suggests that a top-down analysis is appropriate at level 3, where the enterprise has developed a capability, has established an infrastructure, and has realized business value from the implementation of some shared services.

Here we present several strategies for less ambitious efforts to start the transition to SOA. An actual undertaking may combine aspects of more than one of these approaches. All of them should take advantage of an industry framework to provide insight into the appropriate scope and capabilities of candidate services.

Note that any approach has the burden that some SOA infrastructure is needed to support a solution even of small scope, resulting in a higher cost for initial projects. Failure to invest in the strategic infrastructure in the beginning results in greater expense later, when the necessary infrastructure is finally implemented and must be retrofitted. Demonstration of the benefits of SOA to justify infrastructure investment, as well as minimization of retrofitting expense, should be factors considered in the selection and design of initial projects.

Departmental Scope

A top-down analysis may be performed on a division, department, or other segment of the business. Essentially this analysis defines how the department might be restructured to provide shared capabilities in different contexts. Of course, this does not identify other contexts outside the department for use of these services elsewhere in the enterprise. Therefore, the service definitions are likely to be less robust and more vulnerable to need for change as the scope of the SOA is expanded or the business continues to evolve.

Address an Identified Business Need

An identified business need may be associated with a business requirement to improve operations, replace a legacy system, or develop a new business capability. This can be approached from an SOA perspective, designing the solution as a composition of services. Since this is less likely to be within the scope of a single service unit, there may be significant coupling with other systems and business activities. Therefore, the analysis must consider the nature and number of points of integration to systems in other parts of the organization.

Identify an Opportunity for Economy of Scale

Particularly where an enterprise is a product of mergers and acquisitions, it is likely that there are capabilities replicated in the formerly independent companies. These may offer opportunities for significant economies of scale through consolidation. A service unit, or potentially a service group, may be identified as the best solution and adapted to provide appropriate service interfaces to the lines of business derived from the formerly independent companies. Depending on the number of implementations and scope of consolidation, this could demonstrate substantial savings from SOA.

Information Systems Transformations

Existing information systems can be a major barrier to enterprise transformation. Large enterprise applications have business assumptions and processes embedded in them, and it is likely that their scope spans multiple services that would better be defined separately. Most existing systems are not designed to accept electronic messages as requests and return appropriate responses, let alone exchange messages to use other related services. In addition, when a new service is created, other systems for which it accepts input or provides output must be adapted to behave like service users or providers.

Nevertheless, enterprise applications have evolved from traditional organizations that reflect some clustering of similar capabilities. So it may be possible to recognize potential strategic services, even if it is difficult to improve or adapt them independently. Enterprise application vendors have recognized the need to provide finer-grained capabilities to meet more specific customer needs, and the design of these more granular applications provides reasonable services designed for integration and gaining customer acceptance.

The following sections describe some information systems transformation scenarios. As noted, all scenarios require the implementation of an appropriate infrastructure.

New Application

Implementation of a new service unit application can provide the best alignment of the application to the service unit requirements. It can be designed to comply with the SOA infrastructure standards, it can utilize a BPMS for process flexibility, and it can be designed to make appropriate use of other services. However, it also is likely to be the most costly and risky approach.

Regardless of the approach used, a new service unit still requires implementation of adaptors for other systems with which it must communicate, as illustrated in Figure 2.14.

Figure 2.14. New Service Integration.

The new service application does not need to be adapted, but all the related services do. The nature of the legacy applications, the adapter functionality required, and the number of adapters is a significant factor in the cost and risk of the project.

COTS Application

A commercial off-the-shelf (COTS) application could be available to support desired services. This substantially reduces the cost and risk of a new application, and, if it is designed to be service oriented, may provide a service interface that reflects industry best practices. It is important that the COTS application be designed to be driven by a BPMS, to provide maximum process flexibility and the ability to incorporate other services in support of the service unit activities.

Outsourcing

Outsourcing should be considered an option for commodity services—services that do not provide any competitive advantage. To implement outsourced services, the outsourcing service provider takes on most of the technical risk and much of the organizational risk by providing and integrating the needed capabilities as external services. Of course, there are other business factors to be considered when trusting an outsourcing provider to fulfill necessary business responsibilities.

Adapted Legacy Application

The primary reason to adapt a legacy application would be to consolidate operations that currently use different applications to perform the same business functions. This means that there are multiple legacy applications from which to choose. In addition to considering the functionality of the alternatives, the technology and architecture of the systems should be considered for flexibility, maintainability, and the cost of integration.

The legacy system may aggregate capabilities that should be available as separate services. If possible, it is desirable to provide separate service interfaces so that the services are available in different contexts, and users of the services are not affected if and when the legacy application is replaced.

Batch Process Legacy

Some legacy applications may be operating in batch mode rather than processing individual business transactions as they occur. Some applications should continue to operate in batch mode to achieve optimal results. For example, scheduling and distribution applications need to operate on a batch of transactions to optimize the relationships in terms of production sequencing, tooling change-over, vehicle loading, or timely delivery. Analysis and reporting activities generally reflect a point-in-time state of multiple transactions or elements.

For whatever reason, it may be appropriate to adapt batch applications to the service-oriented architecture. This effectively requires buffering. Input messages are held until a particular time or a threshold is reached, and then the batch processing is performed. Output messages go into message queues to be processed one at a time by receiving applications or services.

Rearchitecting

A variation on the adapted legacy application scenario is rearchitecting the legacy application. There are two potential benefits: (1) the application might be partitioned to provide more independent support of more granular service units, and (2) embedded business processes could be extracted and implemented in a BPMS for flexibility as well as service integration. Modernization tools are becoming increasingly powerful for analysis and transformation of applications. This effort could be limited to restructuring the application to provide better alignment with the strategic SOA.

Exposing and documenting business processes is a first step. Aligning business processes to SOA is fundamental to achieving the agile enterprise. In the next chapter we will examine the nature and role of business processes in greater detail.