The Service Integration Architecture defines business applications as reusable, easily changed components of business functionality, and how these components interrelate. This is the concept of a service-oriented architecture (SOA). While SOA has been considered a best practice for over two decades (see sidebar), until recently, very few companies were interested in them. Now SOA is suddenly a hot topic in IT, and at the center of many initiatives aimed at increasing business agility. At this point, if your company is not at least investigating SOA, it should be.
In a SOA, discrete business functions or processes are created as independent components with standard interfaces which can be accessed by other applications, services, or business processes, regardless of the platform or programming language. These services can be flexibly combined to support different or changing business processes and functions. It supports the creation of composite applications, which can be quickly assembled from existing and new services.
In the past, companies had to bet the business on CORBA, J2EE, or .NET to create a SOA. But most large companies use all of the above. The risks and costs of standardizing on one outweighed the potential benefits of SOA. This accounted for the low adoption rate. But Web services have significantly altered the value equation of SOAs. Web services are the first universally accepted standard because all the major vendors can, in theory, support it. They work with .NET, J2EE, and CORBA (as long as everyone sticks to the same version of the standard). Despite some areas of the standard that are still immature, Web services and XML have significantly removed the risk barriers for adopting SOA, making the benefits far outweigh the risks.
Existing mission critical applications currently on the mainframe and other platforms can be wrapped in Web services interfaces and then accessed from other applications or Web browsers. This enables businesses to create business services out of existing systems, and rapidly implement and integrate new functionality. Using Web services, companies can begin creating an SOA by leveraging existing investments and incrementally adding new functionality. SOA is the architecture that will best enable long-term business agility because it supports reuse, and rapid deployment of new solutions.
Enable business agility. SOA is the best way to enable business agility. It maximizes leverage of existing resources while minimizing the time and cost of deploying new applications. Rather than developing applications from scratch, companies can utilize exiting functionality and create new solutions by assembling component applications from existing and new functionality. This enables rapid deployment of new solutions.
Provide higher return on investment. Companies that define reusable business services and create or wrap business functionality as standard services will maximize their IT investments, through reuse and leveraging existing assets.
Enable IT agility. Standard service definitions can provide a layer of abstraction for business services. A service can run anywhere and be accessed from anywhere. Therefore, a company can easily change location or technology of the underlying code.
Reduce training costs. Business services can be encapsulated and abstracted in a way that makes them easy to utilize and assemble into component applications with minimal programming. Companies can utilize more skilled programmers for creating the underlying functionality and service definitions, which can then be reused by less technical programmers and visual application assembly tools.
Reduce the cost of testing and bug fixing. Each service is like a black box that performs a specific function and has a published interface that accepts defined inputs and produces defined outputs. Each service can be tested individually, then reused over and over again. Interface testing is fairly straightforward, and can be automated using testing tools.
Support multiple client types and platforms. The SOA offers a layer of abstraction from the underlying platforms. This makes it possible for multiple types of end-user devices, including browsers and mobile devices such as pagers, cell phones, PDAs, and other specialized devices to utilize the same business functionality and have information communicated to different devices. This platform independence provides great savings for large companies that have a myriad of technologies in use.
Speed development time through parallel development. Different programmers can independently work on different services because each service is self-contained and does not depend upon the state of another service. As long as the service interfaces are well-defined at the beginning of the project, and programmers know what to expect from other services, they can easily define and create services independently. It used to be said that past a certain point adding more programmers to a project increases development time. This is no longer true with SOAs.
Increase scalability and availability. Because SOA offers location transparency, there is the potential to increase scalability by adding multiple instances of a service. Load-balancing technology would dynamically find and route the request to the appropriate service instance. Likewise, if there are multiple instances of a service on the network, and one becomes available, software can transparently route the request to another instance, thereby providing better availability. This is more the case for new services built on application services, and not legacy functionality that has been wrapped in Web service interfaces.
What makes SOA so compelling is that it can be done on both a large and small scale with the same benefits. Texas A&M University was able to demonstrate these principles in the development of their online class-registration system described in Case Study 7.1 (Software AG n.d.). This application was a small step in the application of SOA with a big impact.
Ultimately, SOAs will become the way most organizations build their IT infrastructures, because it is the best and only proven way to provide long-term agility. However, it will take some time and investment to get there. To date, most of the industry focus has been on solving the considerable technical connectivity problems. However, the larger hurdles to truly enabling business agility through SOA are in defining, building, and managing reusable business services.
To date, the majority of the focus on SOA and Web services has been on the technical details of defining interfaces. While the standard interface definition is the critical enabler of the system, the bottom-up approach has its limitations. If the focus is only on the interface specification, and not on how to define what functionality to expose as a service, companies will not reap the full benefits of an SOA. Increased business agility and decreased costs are dependent upon well-defined, well-managed, reusable services that are fast and easy to connect to. Unfortunately, there is no mathematical theory or methodology that can tell a developer whether the component or service is at the correct level of granularity to maximize reuse. The most commonly used method of creating business services is the trial-and-error approach. This usually means defining services in the context of a particular business process, then revising for reuse in the next solution.
A top-down business approach to defining services will enable companies to better meet the current and future needs of the business. It starts with the business requirements. Each service should provide the functionality to meet one or more business requirements, and the set of functions should be closely related. This is called functional cohesion. However, the services should be loosely coupled. The processing within one service should not be dependent upon the state of processing in another. A service abstracts the functionality from the underlying technology.
In truth, to get the job done, both bottom-up and top-down methods are necessary. The top-down approach yields a level of abstraction that is necessary to create business agility. However, at some point the model needs to meet the technology, and the services need to be implemented as components or collections of components. Companies will continue to build components from the bottom-up to encapsulate business services. The key is to make these components functionally cohesive to avoid overlapping functionality and loosely coupled to enable rapid change and to minimize the impact of change.
In this chapter we offer a top-down event-driven method for defining discrete business services that can be used on a project or enterprise basis. Defining business requirements in terms of business events offers a number of advantages. First, event-driven service-oriented architectures provide the most agile systems. In the ebizQ webinar, “Creating the New Enterprise Agility: Service-Oriented and Event-Driven” (http://www.ebizq.net/expoq/events/event39.html), Roy Schulte, VP Gartner, stated, “agility generally involves event-driven business practices, facilitated by service-oriented architectures.” He used the analogy of trains and trucks to describe the agility of SOA. “Changing a truck's direction is easier than making a train go where the tracks don't. If you want the train to move over one foot, you have to do an immense amount of work tearing up and re-laying tracks,” Schulte said. “On the other hand, all you need to do to turn the more agile truck is move the steering wheel.” SOA is the architecture that provides the wheels for the agile enterprise.
Second, business events are a good way to design services because they are easy for business users to understand, identify, and verify in a design. They represent the essential activities of the business. One of the best ways to ensure maximum reuse of a service is to have an interface design review, so all stakeholders can evaluate whether the service will meet their needs. This is the process used by OASIS to develop standards. When companies adopt this practice, the services are more likely to meet a wider range of needs. Business stakeholders are better able to define and verify business events and required system responses, than technical interfaces. The event responses define the requirements for the interface design.
Finally, defining the business events the system will capture and respond to clearly defines the boundaries of the system. This is essential for ensuring successful and rapid implementations. The event responses are further decomposed into sets of functionally cohesive system responses. These responses may be supplied by exiting systems or new development. The service may be an integrated interface to a set of responses supplied by different systems that need to be coordinated. A service can itself provide different levels of abstraction. The service can also be a single function provided by a component or application. Focusing on business events and required responses provides a business-oriented approach to defining the SOA. This method is described in the Service Integration Specification.
Some have called the process of creating reusable business services similar to cooking waffles. You need to throw the first one out, and it gets better over time. While it is certainly an iterative process, this specification will provide guidelines for creating reusable services. A full copy of the specifications is in Appendix E.
This SOA Specification provides architecture and design guidance for applying a service-oriented architecture approach to integration. This document defines the events, services, and components. It is the design and architecture specification for the development of the services and components.
The scope of this specification is defined by the scope of the project. It documents the architecture and design for an SOA approach to an integrated solution. The scope of this specification should describe the scope of the application or system that is being designed.
This section should define the stakeholders who can verify the business events, services, and interfaces; the development team who will execute the implementation of the design; and the team responsible for the architecture and design. Any other participants or stakeholders should also be identified, including their roles.
The Business Events section defines the business activities that the system must support. A business event is something that
Occurs in the business environment
Occurs at a given point in time
Must be responded to by the system
The Event Table describes the relevant activities that happen in the business and the required system responses. There are two types of events: business events and temporal events. Business events are activities that occur in the business, and are detected by defining each business activity within the scope of the system. Temporal events occur at a predetermined point in time. Temporal events exist because the business policy demands that certain system activities occur at certain times, or because the system produces its outputs on a timed basis. Case Study 7.2 describes how managing business events more efficiently at Delta Airlines can have significant impact on its business (Tillett and Schwartz 2001).
The business requirements are defined in the Statement of Purpose (Chapter 2, page 30). From that list, create a list of business events within the scope of the system, and define the responses to each event (see Figure 7-1, page 126). In the Event Description column, include how the event is initiated, or detected. When defining Responses, give descriptive names that unambiguously define what the system response is, such as “Verify existing customer,” “Enter New Customer,” “Check Credit.”
The system responses defined in the Events Table are used to determine the essential services the system must provide. Some of these services or functions already exist in other systems, and other functionality will be new and must be developed then integrated. The service descriptions define the scope of functionality required to perform a specific business service.
To maximize business agility and IT investment, business services should be defined at the level of granularity that will optimize reuse. Tight cohesion—grouping closely related functions together into business services—and loose coupling between services are the design metrics that will yield more reusable design.
Three parts of the specification fully define each service: the Service Category Table, the Service Definition Table, and the Service Interface Table.
This level of description is sufficient for developing a new Web service or wrapping existing functionality as a business service.
The Service Category Table lists all required responses to business events, and defines whether the function already exists in one or more systems, or if it is new functionality. The table also defines likely services to provide the functionality. The service at this point is a first best guess at a services definition and will be refined further in the next step. When defining services, think of modules within an existing application that may perform the service or likely component modules for development (Figure 7-2, page 128).
The Service Definition Table fully describes each service at a level sufficient for creating Web services or other integration interfaces. Each service should be described in terms of its functions and systems used to create the service. In creating this table, group all functions and responses together that will form a cohesive module. For example, the service should manage a particular set of data, such as customer information, or product information, or should perform a specific service that might be used in other applications, such as credit checking or pricing. There should be loose coupling between services. Each service should interact with any other service through the defined interface. Changes in one service should not impact functioning of other services.
The description defines how the service will be implemented, such as Web service, application adapter, or application module interface (Figure 7-3, page 129). This is the place in the specification that brings the top-down design down to the technology-specification level.
While the Web services standard defines how to specify an interface, it does not define the data and functionality that the interface needs to contain. The Service Interface Specification provides the information necessary for creating Web services or other application or component interfaces. Using the Service Definition Table, list all inputs, outputs, and methods that the interface needs to support, and determine how the interface will be implemented (Figure 7-4).
The goal of defining standard interfaces is to maximize business agility. The standardized interface enables applications and services built on different platforms with different languages and technology to interoperate. It enables services to change internal functionality and rules or underlying technology without impacting other applications or components, as long as the interface remains the same. Therefore, getting the interface right is essential to maximizing reuse and agility. It is highly recommended that companies follow best practices of the standards committees when defining interfaces by having design reviews that include all stakeholders. It is also recommended that you create a glossary of terminology that is meaningful and consistent across all stakeholders. The purpose of the Interface Specification is to enable such design reviews, and to fully describe the interface so it can be implemented correctly and optimally.
A use case diagram can be used to depict the relationships between users, events, and services. It is the final piece of the puzzle for the specification. It integrates all of the information from the previous sections.
Use cases define actors and how they interact with the system services. Actors represent a role, and can be humans, other computers, pieces of hardware, or even other software systems. They must supply stimuli to initiate the event that in turn requires a system response (or service). Use cases describe the behavior of the system when one of these actors sends one particular stimulus. It depicts the business events and system responses in terms of the event stimulus that triggers the use case, the inputs from and outputs to other actors, and the behaviors that convert the inputs to the outputs.
The basic components of use case diagrams are the actor, the use case, and the association (see Figure 7-5). An actor is depicted using a stick figure, and the role of the user is written beneath the icon. Actors can be humans, other computers, pieces of hardware, or even other software systems. A use case is depicted with an ellipse, and the name of the use case is written inside. Associations are lines between actors and use cases, and they indicate that an actor participates in the use case.
To support the analysis of nonfunctional requirements (e.g., reliability, maintainability, and performance), use cases should be created to support scenarios in which these nonfunctional requirements will be tested. Examples include: 1) creating a use case that tests performance across a distributed component interface, and 2) creating a use case that tests the adaptiveness of a component by extending it (i.e., adding classes) and examining it to determine if the architectural design principles still hold. These system-level use cases may be implemented in a stand-alone fashion whereby a part or slice of the architecture is being tested independently from the business domain functionality it will need to support.
To create the use case, first identify the primary actors in the system. Then prioritize the services to be implemented. We recommend creating a use case for each proposed service. As an example, see Figure 7-6 (page 132).
The Use Case Specification contains text that further describes the use case (Figure 7-7). The text specification also usually describes everything that can go wrong during the course of the specified behavior, and what remedial action the system will take. This specification can be customized or expanded to handle particular issues within an implementation or organization.
A successful service-oriented architecture enables companies to rapidly implement new business solutions or change existing ones and can deliver a substantial ROI. However, SOA is not necessarily easy to accomplish. The following best practices will help you reap the full benefits of SOA.
Provide high-level organizational structure and support. Success with SOA requires ongoing enterprise commitment and investment. SOA can not be accomplished with a single project. There needs to be a group of experts, such as the competency center, that focuses on the definition, growth, and reuse of the SOA. There need to be organizational processes and policies governing enterprise integration. As integration crosses organizational boundaries, it can also cause territorial disputes. Companies need processes and policies for managing these disputes (described in more detail in section 4.4, Organizational Structure and Architecture Governance).
Implement standards-based architecture. Standards help ensure both interoperability and portability. They prevent technology lock-in, and help preserve value in IT investments. Web service standards are enabling the widespread adoption of SOA, despite the fact that it has been a known best architectural practice for three decades. XML enabling your systems is one way to provide a standards-based transport, management, and storage format for all structured data and unstructured content within the organization.
Implement a standards-based approach. Follow the example of the standards committees that have long experience with creating processes that are successful in creating interoperable standards. Perform design reviews for service interfaces, and include all stakeholders. Stakeholders can be identified through the use cases.
Think big, start small. When planning for an SOA implementation, consider the enterprise-wide impact in order to maximize reuse and agility. But start with a project that has a limited scope and a high probability of success. Nothing succeeds like success. You will learn a lot from each implementation, so wait until you have a couple of smaller implementations under your belt before tackling the most difficult challenges.
Invest in training. You will have a higher probability of success if your employees know what they're doing. Few designers and programmers have experience with SOAs built on standards such as Web services and XML. It's all too new. All stakeholders, including business and IT managers, architects, designers, programmers, and operational support personnel need to understand the overall concepts of SOA and what their role in the process is. Architects and designers need to understand the design parameters and best practices for creating agile and reusable systems. Programmers need to understand the new technology, and how to implement services and infrastructure components. Operational support personnel need to understand the implications of managing a distributed SOA.
Use tools to save time and money. Don't try to handcraft everything. A wide variety of tools are available that can reduce time and skill sets required to implement the solution. Invest in tools when the advantages clearly outweigh the cost.
The Vanguard Group is an interesting case study where each of these best practices came into play (Case Study 7.3) (Dragoon 2003).
Services are the building blocks for composite applications and process-driven integration. Defining reusable enterprise services, as well as managing and measuring reuse, requires ongoing enterprise commitment and investment. Success with SOA is as much a matter of management as it is technology. Companies interested in long-term business agility will invest in all aspects of the enterprise integration architecture, including information and process integration architectures (Chapter 8 and Chapter 9, respectively). Companies focused on pressing tactical needs, will define only what is absolutely necessary and move on to implementation (Part III). See Figure 7-8.
