SOA governance takes the wheel for automaker

SOA governance takes the wheel for automaker.

Employing metadata and an enterprise services registry/repository to effectively manage a complex SOA

Introduction
This case study examines an automotive industry leader’s Service Oriented Architecture (SOA) adoption, including its implementation of an enterprise services registry/repository in conjunction with its overall enterprise service bus (ESB) infrastructure. The paper will also explore the company’s use of these technologies to streamline and simplify its complex IT environment, reduce costs, increase agility and improve customer service. Included are the many lessons learned, in particular how the use of an enterprisewide services approach that incorporates federated ESBs, a governance model and disciplined change management can help solve challenging IT problems.

This automaker is one of the leading global automotive manufacturers, rivaling others around the world. But its success poses a challenge for the IT infrastructure that underpins the company’s far-flung operations. In terms of data and information systems, the company has evolved into a complex environment with complicated data flows. Its various business units, widespread dealer networks and large customer base all clamor for information. The IT resources required for simply collecting, accessing, updating and managing this vast amount of information and the systems that support it made the automaker an ideal candidate for implementing SOA.

Business challenges demand a service-oriented approach
The company’s business needs were straightforward. Because it operates in a highly competitive global market, the automaker sought to differentiate itself by focusing on the satisfaction of both its internal customers, represented by the dealer network, and its external customers. In addition to improving customer satisfaction, the company also needed to shorten operations cycle time. Basic applications, such as matching customer names to a particular product, simply took too long. Just as important, the company wanted flexible, agile systems that could adapt quickly to support changing business needs.

One constant running through these business challenges was information management. Getting the right information about customers and products to the right people in a timely way not only would help boost customer satisfaction, but also would help reduce operation cycle times.

Given this business environment and the company’s demand for efficiency, flexibility and agility, the adoption of a services approach clearly made sense. The automaker decided to begin its SOA implementation with a messaging platform based on multiple ESBs that work together in a federated environment to help streamline the connectivity between its many disparate systems.

In addition, SOA would enable the creation and reuse of key business services, which would result in more efficient use of IT resources. To ensure that these services were controlled and accessible throughout the business, the company decided that it would need an enterprise services registry/repository. This registry/repository would be part of the overall governance strategy that was at the core of the SOA strategy.

While the automaker had a good understanding of the technical approach it needed to take, management realized that implementing a solid infrastructure was not enough to guarantee a successful SOA transformation. Although it is only human nature to approach problem-solving and task fulfillment based on previous experiences, SOA turns some of these established methods inside out and upside down.

For example, if each of several developers changes part of a well-tested business service to meet the needs of a particular application without following an established change management process, the quality and reusability of services will deteriorate very quickly. The company therefore established a governance process geared toward fulfilling the following goals and requirements:

~ Eliminating rogue services to help ensure greater control and consistency
~ Monitoring the federated ESBs to help ensure that executions were in the right context
~ Optimizing alignment of service interactions with business processes
~ Understanding when services are changed or when there is a change in service information.

Solution overview: laying the foundation for governance
If services were to be the key to this global transformation, the automaker needed a way to easily locate and track them across the enterprise. More than that, the company needed ways to control the consistency and integrity of new services, both before they were published and afterward, through systematic change management combined with automatic subscription-based notification.

It also needed to create customized information views, protect access to business services and artifacts, and provide support for the runtime lookup of services. Finally, it wanted to provide content-based routing and dynamic endpoint binding, with the latter based on protocol affinity and service governance states.

Given the central, ongoing role governance would play, the automaker recognized it needed an enterprise services registry/repository to handle a variety of essential enabling tasks, including service metadata management and service lifecycle management, and support for overall SOA governance. The company intended the enterprise registry/repository to become the focal point for service metadata in order to maintain control of that data. For overall SOA governance, this enterprise registry/repository approach offered centralized version management, as well as service lifecycle tracking, monitoring and updating. In addition, it met the company management’s requirement for a mechanism that would trigger event notification when service metadata such as communications endpoints were changed.

Conceptually, the enterprise services registry/repository is a meta-model that enables a central catalog of valid and approved services. The architectural environment for the registry/repository is illustrated in Figure 1 (please refer to the PDF file for graphics). The enterprise service registry/repository includes the following capabilities intended to effectively manage service metadata:

~ Support for design-time discovery and runtime access
~ Storage of artifacts in addition to references to artifacts
~ Support for a service taxonomy to define domains and functional areas
~ Management of the service lifecycle in the context of a shared environment
~ Notification of important events such as changes to service metadata to appropriate parties
~ Secure and policy-based control of service access
~ Management of multiple versions of a service
~ Storage of business policies that need to be enforced by the infrastructure

Creating and managing enterprise service bus services
The automaker selected the IBM WebSphere^® Services Registry and Repository (WSRR) product for the enterprise services registry/repository—which would provide the master metadata service repository for SOA and ESB service interaction endpoint descriptions—and IBM WebSphere Enterprise Service Bus for the ESB itself. The company and IBM worked collaboratively to enhance the capabilities of WebSphere ESB and in developing and shaping requirements for WSRR, which acts as a bridge between the company’s ESB services lifecycle governance processes by establishing touch-points to be managed.

The federated ESBs provide the core connectivity and message transformation. As part of the lifecycle process, the ESB services are established by separating service descriptions from their implementations through the use of appropriate metadata. The metadata captures the technical details of what a service can do, how it can be invoked, or what it expects other services to do, and it is used throughout the lifecycle process for management purposes.

Analysts, architects and developers use service metadata during the inception phase—a software development phase based on the IBM Rational^® Unified Process^®—to locate services for reuse and to evaluate the impact of changes to service configurations. Service metadata is also used by system developers and system administrators for dynamic selection of service endpoints and configuration of the SOA fabric, and during the management phase, service metadata helps support the policy enforcement required by service level agreements and helps provide a more comprehensive view of the managed service environment.

Building governance into the solution
The automaker had straightforward requirements for governance. In addition to tracking services across the enterprise, supporting runtime lookup of services and artifacts, and controlling the consistency and integrity of new services, it wanted to use subscription-based notifications for change management and to create customized information views. On a more technical level, it wanted to provide content-based routing by established relationship type with message content and provide dynamic endpoint binding based on protocol affinity and service governance states.

While ESB governance aims at eliminating and preventing unnecessary service proliferation, SOA governance performs a broader function involving the process of establishing chains of responsibility, authority and communication to empower people. It also provides measurement, policy and control mechanisms to enable people to carry out their roles and responsibilities.

The enterprise services registry/repository supports SOA governance by providing an automated way to manage the ESB services. With the service metadata residing in a single repository, the governance body has direct access to the information necessary to ensure that the definition of new services, their interfaces, runtime deployment and other actions are aligned with the business goals. Additionally, the registry/repository prevents the proliferation of services and promotes the reuse of services and the development of services based on industry standards.

The following service metadata governance enablers are built into the enterprise services registry/repository:

~ Definition and the enforcement of service lifecycle for governed objects
~ Validation and notification of operations and events related to changes and evolution in the service lifecycle or service information model
~ Definition, enforcement and accountability of security policies constraining the visibility of the service information model and the operations performed on it

SOA governance encompasses ESB governance, which includes management of the service states (both business and operational) as they transition from one state to another, such as from design to development to testing. The enterprise services registry/repository supports operational and business states in a single state model, with the business state model describing the various phases of a service within its business lifecycle, ranging from when a service is first planned to when the service is retired. Similarly, the operational model describes the various states that a service goes through within its operational lifecycle, from the time a service is in development to its retirement. The operations states are subsets of the business states.

As shown in Figure 2 (please refer to the PDF file for graphics), SOA governance serves as the control point for the creation, deployment and eventual sunsetting of services gathered under the enterprise services registry/repository umbrella. The enterprise services registry/repository exposes for reuse only those services that have been promoted through the various development phases and approved. After a service has been defined, it must be published to the registry/repository before it can be used. The service provider enters the service metadata and classification details on the user interface, which stores the data in the repository.

Impact analysis, compliance checks, change-policy conformance and scheduling are performed, and once the service is approved, the lifecycle management process drives deployment and production configuration. The service is then promoted to the production environment and assigned an operational state. This governance process ensures that any exposed service is the correct and latest version, and it maintains access control of the registry data as well as centralized version management. At the end of the lifecycle, the service is evaluated for the impact its retirement might have on the production configuration and, following this analysis, is assigned a “retired” state.

To make the enterprise services registry/repository a better enabler of SOA and provide better control of SOA governance, the automaker worked with IBM to incorporate several enhancements to WSRR. For instance, the service registry now provides service lifecycle guards for state transitions, as well as the ability to analyze the impacts of service introduction, deletion or alteration for the purpose of maintaining relationships. In addition, the ability to manage role-based access to services, changes, versioning and service retirement was included.

Optimizing service through loose coupling
One of the important ways that business gains flexibility with SOA is through loose coupling services. Technologically, it is the ESB that makes this approach practical. The ESB becomes the centric point of service invocation. In effect, it hides the service implementation details and, in conjunction with the registry/repository, provides transparency at the endpoints.

The ESB framework consists of messaging, transformation and mediation components. The messaging component provides the infrastructure that enables software applications to interoperate using synchronous and asynchronous messages. The messaging patterns supported by the solution include publish/subscribe, point-to-point messaging, one-to-many messaging and notification. After a service has been defined, it must be published to the enterprise services registry/repository before it can be used. As shown in Figure 3 (please refer to the PDF file for graphics), the service provider enters the service metadata and classification details via the graphical user interface, which stores the data in the repository. If the service is ready for use by consumers, the service state has to be updated to reflect the new state.

The dynamic discovery feature can be used for the retrieval of services, for instance if multiple versions of a service exist, and can be used for non-backward compatible or compatible changes. Dynamic service selection is supported by the IBM WebSphere Message Broker client, which, in combination with IBM WebSphere Integration Developer, also supports dynamic binding of endpoints and provides the required runtime location transparency for a service. Thus, if a service provider should change endpoints, all requests going through the enterprise services registry/repository will understand that change and remain unaffected.

The relationship functionality in an enterprise services registry/repository is used to map consumers to the endpoint of the service’s appropriate version. The enterprise services registry/repository supports relationships within the service metadata that can allow attributes within a request to be mapped to a provider endpoint. This functionality is used to map consumers to a specific endpoint and to track which consumer requests get routed to each service version. This functionality is not directly supported by the registry/repository or the ESB client; it is supported through custom mediation, if needed. When mapping consumers, every consumer who calls the service should be included in the relationship map. The advantage of this approach is that service version access is enforced at the consumer level, providing a great deal of flexibility.

Managing an enterprise services portfolio
As demonstrated in Figure 4 (please refer to the PDF file for graphics), effective governance is essential to documenting and managing an enterprise services portfolio. Without it, it will be difficult to get participants in an enterprisewide SOA initiative to come to agreement on essential details needed to create a core set of reusable services, such as what common set of behavior must be included in a given service. And without a core set of reusable services, it would be impossible to achieve the cost savings, productivity gains, improvements in efficiency, and increases in speed and agility that most organizations want from an enterprise SOA initiative.

Other key elements in the solution rollout were the enterprise SOA enablement team and an enterprise change management effort. The enterprise
SOA enablement team proved instrumental in promoting the acceptance and adoption of the SOA and ESB concepts that provide the technology foundation. The automaker was able to establish early on its vision for SOA and promote the service orientation concept. At the same time, it continuously communicated the benefits of leveraging the ESB and the service registry across the enterprise.

The company based its change management approach on the Japanese concept of developing and communicating any plans or proposals prior to making a final decision. This has to be done in order to gain support and commitment from key stakeholders. This approach calls for an informal process of quietly laying the foundation for a proposed change or project by talking to the people concerned and gathering support and feedback. At the automaker, it is considered an important element in any major change, even before any formal steps are taken. When handled properly, it enables changes to be carried out with the consent of all sides.

Meeting the client’s requirements with IBM software
Selected as the product base for the enterprise service registry/repository, WebSphere Services Registry and Repository functions include registry, repository, governance, administration, access control and classification. WebSphere Enterprise Service Bus provides the core connectivity and message transformation, which is an integral part of the SOA initiative.

From a technical standpoint, WSRR provides a J2EE^TM application that runs on IBM WebSphere Application Server. This allows it to take advantage of such WebSphere capabilities as role-based access control or connectivity. These capabilities were closely related to WSRR governance capabilities.

WSRR relies on a relational database as a back-end store for service information and metadata persistence. SOA artifacts are maintained as XML documents and, although the WSRR can handle any XML document, it pays special attention to Web Service Definition Language and XML schema documents, which it decomposes into what IBM refers to as a finer-grained information model. It can also handle non-XML documents.

Figure 5 (please refer to the PDF file for graphics) shows how a user can interact with WSRR programmatically or through the user interface to perform basic create, retrieve, update and delete functions on the registry/repository contents and perform queries against the content. Web applications or third-party tools like Eclipse plug-ins can be used with the metadata, and because it allows for annotating registered service declarations and elements with user-defined properties, relationships and classifiers, the enterprise services registry/repository enables rich queries that make use of those annotations when searching for a service endpoint or service interface.

Reaping the benefits of SOA governance and WSRR
The automaker experienced a number of benefits resulting from SOA, its approach to governance and the use of the WSRR-based enterprise services registry/repository. Specifically, it was able to reduce customer data redundancy and was able to provide near real-time access to customer and vehicle information. For example, where it once took four days to match vehicle information with the customer, through SOA this match takes only four hours, which has resulted in improved customer satisfaction

Similarly, the automaker expects to reduce the amount of work required to maintain business functionality. In addition, it expects to reduce its overall application and data portfolio. Already IBM’s SOA/WSRR solution and the resulting shared infrastructure and services has allowed the company to decrease the number of point-to-point interfaces it must maintain for integration and for the reduction of data duplication.

Together, these benefits add up to real hard-dollar savings through lower maintenance expenses. In addition, the automaker feels its systems will be able to respond more quickly to changing business requirements, thereby increasing business agility. Finally, it expects to experience smoother growth as a result of implementing a scalable, reliable infrastructure.

Lessons learned
From its experience with SOA governance and the federated ESB approach, the company has become a believer in the enterprise services business
strategy. The following six tips comprise important lessons on the learning curve to SOA success:

1. Adopt an end-to-end framework to support a long-term approach
toward service orientation

2. Implement a stakeholder management and communication strategy to
foster adoption of ESB and service orientation

3. Communicate clear roles and responsibilities, including job impacts,
at various levels of the organization

4. Establish governance scenarios to promote an enterprise view of
shared services

5. Integrate the services lifecycle into the current systems delivery lifecyle
or systems delivery process

6. Apply lessons learned from other enterprise efforts to build momentum
and gain support from management

SOA is not a magic bullet. As the automaker’s experience demonstrates, however, the use of an enterprisewide services approach that incorporates federated ESBs, a governance model and disciplined change management can help solve challenging IT problems. In the automaker’s case, it provided a way to improve customer satisfaction, increase business agility and streamline a complex IT infrastructure.

About IBM
IBM is a global computer products and services company, with close to US$90 billion in sales, approximately 320,000 employees and operations spanning more than 150 countries and including thousands of clients, Business Partners and suppliers. As one of the world’s largest IT companies, IBM strives to invent, develop and manufacture the industry’s most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics. Its worldwide network of services professionals provides the extensive expertise clients need to create business value using IBM’s leading technological solutions.

For more information
To learn more about the many ways IBM can help you build and manage an SOA-enabled solution for customer data integration, please contact your IBM representative or IBM Business Partner. Or visit us at: ibm.com/soa