Easwaran G. Nadhan
Principal, EDS
April 2004
Summary: Discusses various approaches to solving the eight key challenges companies face when implementing a service-oriented architecture, and gives examples of EDS' own experience with clients. (16 printed pages)
Introduction
Architectural Components
Challenges
Conclusion
You may well be considering deploying a service-oriented architecture across your enterprise. In any such deployment, there are complex challenges along the way—including ones unique to your industry and company. However, with a flexible road map for the implementation in hand, you're able to act quickly to meet and overcome the challenges as they occur.
Service-oriented architectures are an important new paradigm that supports modularized implementation of solutions within a middle tier. These architectures are particularly applicable when multiple applications running on varied technologies and platforms have to communicate with each other.
However, service-oriented architectures aren't implemented overnight. Companies must first gear up and work towards the progressive construction of the components and services involved. A road map and company-specific standards are key prerequisites—ensuring a systematic implementation of such an architecture enterprise wide.
This article offers different approaches for companies to use to address various implementation-related challenges. Examples are based, when possible, on EDS' real-life experiences with our clients. The article also leverages EDS' experience in building a tool that facilitates the configuration, management, and deployment of Web services within enterprises.
Figure 1 shows the basic components of a service-oriented architecture. The components of a service-oriented architecture include:
Figure 1. Service-oriented architectural components
While implementing a service-oriented architecture, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan:
I'll discuss these challenges in detail and examine the approaches we can use to address them. Representative real-life examples are included, wherever applicable.
Challenge
Properly identifying services and determining corresponding service providers is a critical first step in architecting a service-oriented solution. In today's world, similar business functions could very well be provided by multiple systems within the enterprise.
Approaches
There are two ways to address this challenge; service rationalization and service consolidation. Service rationalization Service rationalization involves a careful analysis of all the systems and applications providing the given business function. Through service rationalization, business functionality supported by the least frequently accessed systems can be implemented within those that are more frequently accessed. By streamlining systems in this way, we can enforce more consistent delivery of services.
Figure 2. Account profile service rationalization
Figure 2 provides an example of service rationalization. The information received through the Account Profile business function is required by multiple front-ending applications such as online banking, CRM and VRU applications. The customer and account repository is the system of record that supports the Account Profile business function. Depending on the nature of the front-end application invoking this business function, different subsets of the account profile are returned.
In this example, the enterprise is increasing online and VRU access for its customers while decreasing use of a CRM application that requires significant human interaction. As customers adapt rapidly to self-service channels, the percentage of access through the CRM application steadily decreases. As part of the service rationalization process, the VRU- and online banking-based Account Profile services are augmented to implement the CRM Account Profile business function, as well. Thus, rationalization eliminates the CRM Account Profile service and the definition of two services supporting it.
Service consolidation
Service consolidation involves the redefinition of all the service instances into a consolidated version that supports the superset of all the interfaces exposed by the individual instances. The redefined and consolidated service is provided by all the individual applications consistently.
Figure 3. Product catalog service consolidation
Figure 3 illustrates a product catalog repository accessed by three separate services. These services are dedicated to retrieving predefined subsets of the information available about a product. After service consolidation, there's a single service that works with the whole product catalog. This service contains all the information segments employed by the individual services prior to consolidation. Service consumers selectively work with the portion of the catalog that's of interest to them. Service consolidation is thus an effective way to streamline multiple services supporting the same business function.
Challenge
Services usually operate on a specific set of business entities that are resident within a given system of record. This system of record is an ideal location for the service to execute. However, distributed architectural solutions can result in business data being spread across multiple applications and can generate multiple instances of the system of record for the same business entity. Data synchronization between the two systems becomes a key requirement. Where would the service be located in such scenarios?
Approaches
There are three ways to solve this challenge; content-based routing, service repository-based routing, and back-end replication.
Content-based routing
This approach routes the incoming request for this service to the appropriate system of record. Such a solution supports location transparency for service consumers: The algorithm that determines where a given service is provided doesn't have to be exposed to service consumers. Both systems of record support an instance of the service and both service instances serve as logical entry points for the given request.
Figure 4. Content-based routing
Figure 4 illustrates an example of content-based routing. In this example, information about customers is segregated by region. Customers belonging to a given region are stored in the repository in the data center located within that region. However, service consumers located within either region may access this information. Upon receiving the incoming request, the Customer Profile service executes a business rule that determines the specific repository where the information about the given customer is available. Then, the Customer Profile service routes the given request to the appropriate region.
Service repository-based routing
A variation of the content-based routing approach described above, the service repository-based routing approach is shown in Figure 5. While the Customer Profile service executes the same business rule it does in the content-based routing approach, it leverages the information in the service repository to direct the request to the appropriate region. This approach makes it easier to change the routing logic, if necessary. Requests can be redirected to a different region simply by updating the information in the service repository—without changing the business rules within the Customer Profile service itself.
Figure 5. Service repository-based routing
Back-end replication
This approach leverages intrinsic inter-application connection capabilities to access the information from the physical repository that contains the required information. Thus, both instances of the system of record function as a logical entry point to access the information distributed across both systems. The service can be executed on either system. The physical location of the data being operated upon is transparent to the service itself. Figure 6 illustrates a scenario for back-end replication. The same Customer Profile service is executed on the instance of the system of record that's closest to the service. In the event that information from the other regional repository is required, the intrinsic data replication capabilities of the technology behind the data repository are employed to fetch the relevant data.
Figure 6. Back-end replication
Challenge
Classifying services into logical domains simplifies the architecture by reducing the number of components to be addressed. Such groupings can be leveraged for multiple architectural reasons such as load balancing, access control, proxy simulation, and vertical or horizontal partitioning of business logic. However, it's often a serious challenge for business units and technology centers within an enterprise to come to a consensus on an appropriate definition of service domains. What would be a good logical grouping of service domains?
Approaches
We can adopt multiple approaches to define service domains. Table 1 shows a sample distribution of the applications and platforms across different business units. This example will be used to define the salient characteristics of each approach discussed in this section.
Table 1. Sample application distribution
| Business Unit | Primary Middle Tier Platform | Application |
|---|---|---|
| Home Loans | UNIX | SAP |
| Online Banking | Windows | Siebel |
| Banking Centers | UNIX | PeopleSoft |
| Insurance Services | Windows | SAP |
| Consumer Loans | Linux | Oracle |
| Corporate Loans | UNIX | IBM DB2 |
Functional domains
Functional domains are based on the business functions being served by a set of services. The business process owners within the enterprise are best placed to define and segregate the business functions and, therefore, the service domains. Through such groupings, business process owners for a given domain can have autonomous control of the services within that domain. As long as business process owners ensure that specified services within their respective domains are provided to the rest of the enterprise, they have complete control over the architecture and implementation of the services.
In the example above, there are three functional service domains: Loans, Banking and Insurance. Services housed within these domains may have to go across multiple platforms and back-end applications to process the incoming requests specific to their domains. However, the business processes served by the services are similar within a given domain, regardless of the application or platform on which the services are executing.
Technology-based domains
Functional service domains that span multiple technology platforms pose the intrinsic challenge of keeping pace with the state of each technology platform at any given time. Vendors tend to interpret industry standards in a way that favors their solution and that forces companies to depend on their architecture, hardware and/or software. Specification of service domains based on technology allows efficient and effective usage of that technology's unique capabilities.
In the example above, service domains may be classified by the UNIX, Linux and Windows platforms. Infrastructure services such as error logging, transaction monitoring and event handling are good candidates for such services. They're dependent on the platform that they're executing on and are typically independent of the business processes that drive the functional service domains.
Application-based domains
The concept of enterprise application integration came about as a way for companies to eliminate the need to replace existing systems. Today, enterprises have many multiple front-ending applications that need to integrate with the same system of record to process, package and present the same information in different ways.
Application-based service domains allow for grouping services provided on a given system. Such an approach eases the administration and maintenance of the services since the underlying system is the same for all the services within the domain.
In the example above, SAP, Siebel, PeopleSoft, IBM DB2 and Oracle are good candidates for application-based service domains. Some of the sample services that may be housed within these domains are listed below.
SAP
PeopleSoft
Oracle
Challenge
In a service-oriented architecture, an enterprise's systems must expose functionality as services. Systems built to facilitate integration can do this more easily; mainframe-based legacy systems have more difficulty. When these systems were built, they served as monolithic applications containing all the business rules and processing logic involved. Such information was distributed across multiple sets of interlinked programs.
A service-oriented architecture encourages the individual services to be self-contained—with no knowledge of the context of the other services. Mainframe programs are deeply intertwined with context-specific knowledge. How are such mainframe programs to be re-packaged into independent, self-contained services?
Approach
We can use a three-step approach to address this challenge. The approach involves defining the logical business areas within the mainframe solution, assigning program sets to these business areas, and then engineering a loosely coupled solution between the program sets. These steps are outlined in more detail below:
Challenge
A given service exists because there's at least one instance of a service consumer initiating the request for that service. In some scenarios, however, a service may have to invoke many other services to fulfill service consumer's original request. Simple scenarios involve a given service extending the original request to one or more services. However, complex scenarios can involve recursive invocation of multiple services and, in some extreme cases, inter-dependent invocation of multiple services—which could result in a deadlock.
Here's an example. For an airline ticket to be purchased, the following services need to be executed:
Get Customer
Get Schedule
Check Availability
Quote Fares
Receive Payment
Building the orchestration intelligence
into each service can result in the rather complex scenario illustrated in
Figure 7.
Figure 7. Service orchestration challenge
How can such composite services be orchestrated?
Business process management approach
This approach keeps the individual service simple: The services don't have the intelligence to orchestrate the procedural invocation of all the other services required to fulfill the request.
Instead, that intelligence is placed within the business process layer. Business processes are responsible for procedurally invoking each constituent service, thereby providing the composite service the service consumer originally requested. The business process becomes a specialized instance of a composite service.
Figure 8. Business process management approach
Figure 8 illustrates the Purchase Ticket business process that contains the procedural logic of the individual steps to be executed. The Purchase Ticket business process discovers the constituent services through a single access to the service repository and subsequently orchestrates the appropriate steps in sequence.
Challenge
Service-oriented architectures must provide location transparency to the service consumers: Service consumers have to be able to send a request for any service located in any service domain. At the same time, accessing the service repository before each invocation of a service can be a timeintensive process. How can these architectures provide location transparency while also ensuring acceptable system performance levels?
Approaches
We can solve the service-routing challenge in two ways.
Intelligent services
Using this approach, we build location information for all services into each individual service. This eliminates some of the hops required but results in an overloaded service. Depending on the frequency at which the services or their locations undergo changes, this approach can be maintenanceintensive. In addition, such an approach isn't in line with the loosely coupled architecture embraced by services. Nevertheless, it supports a highperforming solution.
Routers
The other approach is to move the routing intelligence from the individual services to a routing component. These routing components can be at two levels: service domain and service.
Service domain routers and service routers are more applicable to service domains that contain a significant number of services. When there are only a few services, intelligent services are a viable option.
Figure 9. Service domain routers and service routers
Figure 9 illustrates the concept of service domain routing and service routing within a domain.
Challenge
Regardless of the way service domains are defined within an enterprise, there are various philosophical and technical approaches for creating new services and modifying existing services. Who should monitor, define and authorize the changes to the existing suite of services supported within an enterprise? Who should own the provisioning and maintenance of these services?
Approaches
An enterprise can address the challenge most effectively by establishing an internal governing body. Multiple governance models are possible. These are discussed below.
Central governance
With central governance, the governing body within the enterprise has representation from each service domain as well as from independent parties that don't have direct responsibility for any of the service domains. There must also be representation from the different business units and from subject matter experts who can speak to the key technological components of the solution. The central governing body as a whole reviews addition and deletion of services, as well as changes to existing services, before authorizing their implementation.
Figure 10. Central governance model
As shown Figure 10 above, the central governing body is responsible for establishing and enforcing service-oriented architectural guidelines and standards across the enterprise. The body is also responsible for communicating those standards to the business units, architectural teams and technology teams.
Distributed governance
With distributed governance, each business unit has autonomous control over how it provides the services within its own organization. Distributed governance mandates a functional service domain approach. A service architecture committee can still provide high-level guidelines and standards for implementation of services, but that committee doesn't have to authorize changes to the existing service infrastructure within a business unit. The committee suggests compliance with these guidelines but does not enforce it.
Figure 11. Distributed governance model
In the distributed governance model shown in Figure 11, business units A and B have the freedom to establish their own independent standards. Yet appropriate passive measures (architectural and procedural guidelines) are in place for the units to follow.
Challenge
Messaging standards specific to vertical industries enforce standardization on a set of data elements and message formats. However, at an individual data element level, these standards are flexible enough so that enterprises can tailor them to conform within the enterprise-specific business context. As a result, different business units within the same enterprise can conform to the same standard in multiple ways. Additionally, these standards provide for the creation of custom data elements.
For example, the Interactive Financial Exchange (IFX) standard specifies multiple ways to uniquely identify a customer:
Both fields are unique. Enterprises adopting the IFX standard have to decide when and where to use each field. In some cases like this one, clients have decided to ignore both and create a custom field that adapts better to their enterprise system of record!
How is it possible to enforce the adoption of a single standard across the enterprise?
Metadata governance approach
Metadata repositories within the enterprise support the consistent representation of key business entities. These representations are a superset of the information distributed across multiple enterprise systems. Data dictionaries as well as logical and physical data models are key inputs into the definition and maintenance of the metadata repositories.
The metadata governance team should be a focused group within the central governance model discussed earlier. Metadata governance must be performed at the enterprise level. In other words, even if an enterprise adopts a distributed governance model for the maintenance of services in general, it must adopt a central governance model for metadata.
In the example above, the metadata for the customer would contain a single way of uniquely identifying the customer. In addition, the metadata would ensure a consistent way of representing the authentication information, including login and password. So even if a company had chosen to uniquely identify the customer by using a custom field, the field would be represented as such in the metadata repository.
Service-oriented architectures are rapidly being accepted by the IT world as a sound, modularized approach for building and deploying services across the extended enterprise. However, practical implementation of these architectures requires careful planning. Interested enterprises must first make sure that they're geared up to implement and support them in the long-term.
By developing and following an implementation road map, companies can proactively address a range of challenges that they'll encounter along the way. Each enterprise will face a unique set of challenges; corresponding approaches for solving those challenges will vary, as well. The impact of the challenges—both during and after the implementation—also depends on the context of the given enterprise.
About the author
Easwaran G. Nadhan is a Principal within the Solutions Consulting division of EDS, Plano, Texas. Nadhan has designed and implemented distributed solutions in the software industry for the past 20 years. Recently, Nadhan has leveraged his experience in enterprise application integration to work with enterprises to implement service-oriented architectures. Examples in this document are based on real-life experiences encountered within EDS as well as within organizations that EDS serves. Easwaran Nadhan can be reached by e-mail at easwaran.nadhan@eds.com.
