In the first article of this series, you learned about the IBM SOA Foundation life cycle (the SOA life cycle) and how you can use IBM tools and technologies to deploy an SOA-based solution and manage the life cycle of services. You learned about the four phases that constitute the IBM SOA life cycle:
Collectively, these phases can be referred to by the acronym MADM.
The SOA life cycle helps you to organize a project plan around the four phases and the activities and tasks that constitute them. However, wouldn't it be nice to come up with common and recurring themes and patterns for application of SOA-based solutions and identify common situations in which SOA is being used today? IBM has come up with eight such SOA common usage patterns. These patterns are collectively called the SOA scenarios.
IBM organizes these scenarios around five distinct yet interrelated entry points that help enterprises get started and succeed with SOA. The entry points are driven by both business and IT needs and are broadly classified based on:
- People -- Enabling human and process interaction
- Process -- Enabling and achieving greater efficiency and effectiveness through business model innovation
- Information -- Delivering trusted information to enable business processes
- Connectivity -- Achieving an on-demand flexibility by connecting software systems and services
- Reuse -- Minimizing complexity of SOA adoption and implementation by fostering reuse of high-value enterprise assets
Each of the entry points includes one or more of the scenarios, which in turn provides a roadmap for implementing the entry points. Each scenario is further broken down into "realizations" which are specific development tasks designed to solve a particular problem. The SOA scenarios represent common situations encountered by IBM services teams when delivering real-world client solutions.
Each scenario communicates specific business values and describes the architecture and a recommendation of a set of IBM open standards-based software that can be used to implement a specific part of an SOA solution. These solutions are designed to help you implement an SOA-based solution incrementally to meet tangible needs rather than all at once. The solutions defined by each scenario are modular in nature and can be built on top of one another; elements of multiple scenarios can be used together to create a composite scenario. The scenarios also provide prescriptive guidance about how to use IBM tools, technologies, and products to map to and realize each of the patterns that may constitute the variations of a given SOA scenario.
The scenarios fall into two categories: functional or supporting. The functional scenarios map directly to one or more SOA entry points; the supporting scenarios cut across all the entry points.
The functional scenarios are the following:
- Service Creation
- Service Connectivity
- Interaction and Collaboration Services
- Business Process Management
- Information as a Service
The supporting and cross-cutting scenarios are the following:
- SOA Design
- SOA Governance
- SOA Security and Management
This is the first of nine articles about the SOA scenarios. In this article you are introduced to each of the eight scenarios, the philosophy behind them, and the broad context in which they can be used. It will also illustrate a methodology for applying a particular SOA scenario to a typical IT project. Each installment focuses on one of the SOA scenarios: defining the scenario, identifying the various patterns that can occur inside the scenario, and then detailing how each of the patterns within the scenario can be realized using IBM technologies and products. (For more information about getting started with SOA, visit the New to SOA page on developerworks.)
Each SOA scenario is a well-documented pattern of usage of SOA based on various project experiences across industry sectors, both vertical and horizontal. A scenario helps you to identify which usage pattern can be used in a particular situation to jumpstart an SOA initiative. A scenario is strongly supported by both business and technical documentation and provides prescriptive guidance on how to realize a specific solution within the scenario using IBM products, tools, and technologies. Think of these scenarios as recipes in a cookbook, a cookbook that provides clear definitions for each step, helping you to choose the proper ingredients, and offers prescriptive guidance on how to implement the recipe.
Let's start with a general definition of each scenario.
Service Creation -- Creating flexible, service-based business applications. A new service-oriented application exposes business behavior as a service and also reuses business logic, which is exposed as a service. The scenario also provides guidelines on how to provision the services as soon as they are created. The identification and realization of services are the first steps in implementing the vision of a set of optimized business processes. Services can be identified essentially from three main sources (note the emphasis on reusing existing assets):
- Existing assets -- Services that are identified from high-value business functions already deployed in existing systems (for example, legacy or packaged applications)
- External service provider -- Services that are provided by an external vendor, most likely a vendor who provides services in a specific area (These services usually encapsulate common and typical tasks and do not always provide strategic differentiating capabilities.)
- New services identified using a "top-down" approach -- Services that are identified through a top-down decomposition technique; that is, process decomposition (These services fill the gaps that are not addressed by the first two sources; they are new services that need to be implemented from scratch.)
Service Connectivity -- Builds on the Service Creation scenario, according to which services have been identified, designed, and built, and focuses on the underlying connectivity used to support a business-centric SOA. This scenario enables users to have the flexibility of independently changing the service consumer or the service consumer in a manner that is nondisruptive to either. The scenario helps in identifying the characteristics (such as, routing, transformation, mediation) of an Enterprise Service Bus (ESB) that may be used to provide decoupled connectivity between service providers and consumers. The scenario also provides guidance on how to create a logical as well as physical realization of a service gateway pattern that provides mediation capabilities to enable transparent interoperations across mismatched and evolving systems, both at the protocol and interface level. The service gateway pattern also provides guidance on how to enforce security on service invocations.
Interaction and Collaboration Services -- Presents a service or set of services to a human user through a browser, PC, mobile device, voice response system, etc. It focuses on usability issues, such as offering single sign-on to multiple systems and providing role-based portals to consolidate access to information and applications within the enterprise and between enterprises. The key drivers for this scenario are improving productivity of the people who use the system and consumability of the applications and content that make up the system. The content can be personalized in the aggregated portal page based on the user role.
Business Process Management -- Assists in the optimization and automation of business processes and aligns an organization's core assets -- people, process, information, and technology -- in order to create a single integrated view, real-time intelligence, and appropriate business and IT metrics that enable operational efficiency. This scenario concentrates mainly on process modeling and simulation, process integration, process monitoring (also called business activity monitoring, or BAM), process-oriented content aggregation, business rules management, and effective collaboration between people, process, and technology. Enterprises that are process-centric can gain from using this scenario in their SOA transformation.
Information as a Service -- Makes information usable in an SOA by expanding the business value of data. This scenario is especially applicable when an enterprise:
- Has too much information but is not sure of its business relevance
- Stores multiple versions of information, making it difficult to determine which information source to use
- Does not rigorously enforce data quality in its store(s) of information
- Maintains disconnected silos of information that may duplicate each other or contain different sets of data that cannot be reconciled
The crux of this scenario is the virtualization and centralization of information to create a set of consistent, reliable data. That virtual single version of data can then be made available as a service to the entire SOA system, which can use it in a standardized way for business process enablement.
SOA Design -- A cross-cutting scenario that focuses on methodologies for modeling, design, and architecture of an SOA-based software development. This scenario aligns the modeling of business design and IT solution design through a set of roles, methods, and artifacts. Once this is accomplished, business processes can be optimized and realized as services so that the services are aligned with the business and offer true business value.
SOA Governance -- A cross-cutting scenario focusing on a decision-making and enforcement process to oversee SOA planning and execution. It is based on a decision rights and management framework that includes the establishment of chains of authority, roles, controls, and so forth, for the four phases of the SOA life cycle. Apart from establishing the decision rights and managing the SOA life cycle, this scenario also focuses on defining high-value business services and measuring their effectiveness at run time.
SOA Security and Management -- A cross-cutting scenario focusing on management of services at run time and ensuring secure external consumer access to high-value business services. The management of services focuses on automating and simplifying IT processes, managing service levels of services and applications, and predicting and managing change across interdependent and composite services. Service security focuses on managing the federated identity and access control across services, securing access to services and applications, and consistently enforcing security policies for services.
The SOA scenarios can be used together and adopted incrementally. Figure 1 illustrates common relationships between the scenarios.
Figure 1. SOA scenarios and their relationships
The Service Creation scenario essentially creates services. The services can be identified from the business process models that are modeled in the Business Process Management scenario. The services identified from both the Information as a Service and the Interaction and Collaboration Service scenario are used in the Service Creation scenario. The Interaction and Collaboration Service scenario that is mainly based on portal-based access to enterprise services can invoke business processes from the Business Process Management scenario; it can also invoke services as defined by the Information as a Service scenario. The services defined by the Interaction and Collaboration Service and the Information as a Service scenario use the Service Connectivity scenario to provide communication between the services. Services created in the Service Creation scenario also use the Service Connectivity scenario to provide connections between the created services so that together they can make up composite services.
The SOA Design, SOA Governance, and SOA Security and Management scenarios are cross-cutting scenarios that are used across the five functional scenarios and have implications for the enactment of each of them.
The relationships depicted may not be the only set of ways in which the scenarios may be interrelated. With more SOA experiences gained, additional well-proven relationships may be added to the ones just defined.
IBM recommends the following process for applying the SOA scenarios to a given problem. This section introduces this process. Figure 2 shows the five broad steps involved.
Figure 2. The IBM recommended process for using the SOA scenarios
Let's look at each of these five steps as they have been applied by IBM services architects when creating actual industry solutions.
- Capture Customer Requirements -- During this step, IBM consultant and architects gather requirements in the form of use cases, obtain an initial business and IT context, and document the customers' vision of the future state of their enterprise.
- Perform Fit-Gap Analysis with Generic Use Cases -- The SOA scenario framework lists generic use cases drawn from experiences analyzing customer requirements across industry sectors. Each customer use case identified in the first step is analyzed against the list of generic use cases to evaluate which generic use case maps closest to the customer use case. The list of generic use cases (referred to as U1, U2, U3, etc.) are shown in Table 1, which also shows which SOA scenario may be used to implement a generic use case.
Table 1. SOA scenario selection criteria
Detailed definitions of each of the generic use cases listed in the preceding table can be found in Section 5.2 of the IBM Redbook Patterns: SOA Foundation Service Creation Scenario. It is important to point out that the three scenarios (SOA Design, SOA Governance, SOA Security and Management) supplement the primary scenarios that are mapped to a given use-case's realization. So, as the last three columns in Table 1 illustrate, the three scenarios are cross cutting and supplemental in nature.
- Select SOA Scenario -- Each generic use case defined as part of the SOA scenario framework, maps to one or more SOA scenario that can be used to implement the use case, as shown in Table 1. This table is used to select the SOA scenario that will be used to realize a use case. This and the previous step are performed for all use cases. SOA scenario-based activities that will be used in a new project initiative may already be underway to solve another problem. In this case, a reverse mapping is performed from the SOA scenario to the customer-defined use cases. You can see this reverse mapping depicted in Figure 2 by the arrow that is directed from the Select SOA Scenario step to the previous step; that is, Perform Fit-Gap Analysis with Generic Use Cases.
- Identify, Reuse, and Apply Patterns to Accelerate Solution Architecture -- This step is performed if the customer wants to leverage existing reusable assets for the architecture and the design phase of the solution. The decision of which assets to reuse is performed in a two-step process:
Familiarize yourself with the IBM Patterns for e-business and then identify which pattern can be used to accelerate the implementation of the solution architecture. Each SOA scenario is described in detail by one or more primary resource, such as "Patterns for e-business SOA architecture and design patterns." Table 2 shows a partial list, for illustration purposes, of reference materials on patterns and how they map to each SOA scenario. (For a detailed list, see the IBM Redbook, SOA Foundation: Service Creation Scenario in Resources.)
Table 2. Patterns reference material for each SOA scenario
Note that each of the reference materials are books from the IBM Redbooks® series (see Resources), unless explicitly mentioned otherwise. The SOA scenario framework is still maturing, and more references to patterns materials will be published in the future.
The second step is to align the pattern assets with a development methodology. Although the two main software development methodologies recommended by IBM are the Rational® Unified Process (RUP) and the IBM Global Service (GS) Method, this step does not restrict the choice to only these two. Regardless of which methodology is chosen for implementation, the main mapping exercise focuses on how the reusable pattern assets can be mapped to each discipline within a methodology and how they relate to the output work products in each discipline. This approach facilitates the creation of the work products by using the reusable pattern assets. Table 3
provides an example of mapping of reusable assets for RUP.
Table 3. Mapping of reusable assets to RUP work products
- Familiarize yourself with the IBM Patterns for e-business and then identify which pattern can be used to accelerate the implementation of the solution architecture. Each SOA scenario is described in detail by one or more primary resource, such as "Patterns for e-business SOA architecture and design patterns." Table 2 shows a partial list, for illustration purposes, of reference materials on patterns and how they map to each SOA scenario. (For a detailed list, see the IBM Redbook, SOA Foundation: Service Creation Scenario in Resources.)
Leverage Implementation Guides -- This is the final step in the recommended IBM process. This step can be reached in either of two ways: after identifying reusable pattern assets or directly after selection of an SOA scenario.
The resources referenced in this section include working examples which demonstrate how to implement a solution for the phases in the SOA MADM life cycle and for a select set of generic use cases in the SOA scenario.
Realizations have been developed that will help you understand how the scenario can be used and how products are selected; a realization is an example business case that describes a real-world industry situation and its solution. There can be multiple realizations for a given scenario. Each scenario includes prescriptive questions that help select between realizations and any decisions that need to be made within the realization. Implementation guides (programming guides, installation and configuration guides, solution patterns, etc.) are available that accelerates the implementation process of a given SOA scenario.
The SOA scenarios represent a set of generic business scenarios in which SOA is being used in typical customer engagements. IBM's wealth of customer-engagement-based experience in SOA implementation has been consolidated into the SOA scenario framework. The SOA scenarios are representative of common scenarios of use of IBM products and solutions that are used in SOA engagements to solve real-world problems.
In this first article of the series on SOA scenarios, you explored a broad overview of the eight scenarios, their relationships and their interdependencies. You also learned the process of how to apply the SOA scenarios in a real-world SOA engagement. This process will be referenced and actually executed in the following articles in this series.
A two-part series, "Toward a pattern language for Service-Oriented Architecture and Integration":
The article on SOA realization provides an excellent introduction to the SOA life cycle.
Refer to the official IBM Patterns for e-business Web site.
The IBM Redbook entitled Patterns: SOA Foundation Service Creation Scenario describes the service creation scenario.
The IBM Redbook entitled Patterns: SOA Foundation Service Connectivity Scenario describes the service connectivity scenario.
Visit developerWorks Architecture to get the resources you need to advance your skills in the architecture
Get products and technologies
- Participate in the discussion forum.
Learn more about the IBM SOA and SOMA methodology.
- Get more information about RUP and IBM Rational Method Composer.
Tilak Mitra works as an executive IT architect in IBM. He specializes in Service-Oriented Architectures (SOAs), helping IBM in its business strategy and direction in SOA. He also works as an SOA subject matter expert, helping clients in their SOA-based business transformation, with a focus on complex and large-scale enterprise architectures. He lives in sunny south Florida, and while not at work, is often engrossed in the games of cricket and table tennis. Tilak was awarded his Bachelor's degree in Physics from Presidency College, Calcutta, India, and then received an Integrated Bachelor's and Master's in Electrical Engineering from Indian Institute of Science, Bangalore, India. You can blog with him, and you can also reach him at firstname.lastname@example.org.