SOA facilitates business connections. With business processes packaged as modular, accessible business services, enterprises can connect them where and when they are needed to optimize processes across customers, partners, suppliers, and their own internal applications

SOA enhances business control. Because services model business processes, the flow of data and transactions through service-oriented applications is valuable business data. SOA infrastructure actively manages service flows and can provide flexible and dynamic access to this data, which enterprises can use to analyze and optimize business results and process costs.

As flexible, service-based applications make business change easier and faster, business people will take advantage of their new found agility to drive competitive advantage through a faster cycle of introducing new capabilities and optimizing core processes. To guide this faster optimization cycle and provide data to justify ongoing change, SOA's business process feedback loops provide flexible insight into business processes.

While there is no "one size fits all" approach to SOAs today, there are "platform design centers," or domains for which to plan the integration and coordinated use of multiple products and technologies makes a more cohesive SOA architecture possible than would have been the case with cobbling together disparate and unrelated applications. This concept of the SOA as a design centers provide a framework for organizing and integrating SOA platform choices. The following are identified four major design centers for SOA platforms:

Service life-cycle environment (SLE). The SLE provides tools and development infrastructure for defining, building, and delivering business services and the business processes they serve. As a coordinated set of tools for turning business requirements into business services, the SLE facilitates rapid implementation of business change.

Service delivery network (SDN). The SDN controls application-to-application connections and quality of service across technology, trust, and enterprise boundaries. It is the core messaging infrastructure for an SOA platform, providing both new and existing protocols, such as message-oriented middleware; distributed object protocols, such as Internet Inter-ORB Protocol (IIOP); enterprise services buses; enterprise application integration (EAI); and Web services.

Service command platform (SCP). The SCP provides both it- and business-level management. System monitoring and management are the foundation, but the SCP also provides insight for business management by dynamically tapping into the business data inherent in the flow of messages through the SDN.

Core application platforms. Your core application, data, and integration platforms host the business logic of your business services. As such, it is appropriate and necessary to include them in planning for your SOA platforms.

SOA Case Study: (Flughafen Zurich AG): SOAP-Based Portal

Business drivers for SOA. The firm Unique (pronounced YOU-nick) is the firm that operates Zurich Airport. In its pursuit of more efficient airport operations, Unique built a portal to improve management insight into major operational activities. This required drawing data from multiple core applications, each of which was run by a different outsourced service provider.

Solutions delivered. Unique's challenge in building the portal was that baggage systems, ground radar, and airport operations applications were each outsourced to different providers running on different underlying platforms and operating systems. Web services provided the mechanism to connect across these barriers; SOA provided the design model for interactions between applications.

SOA platform strategy. Uniques' new portal application, called ZEUS, has three major layers: the portal itself, a messaging infrastructure, and the business services provided by the underlying applications. The portal also includes some of its own services, such as a cache of operational data as is shown in Figures 3 and 4. Figure 3 shows the SOA architecture and Figure 4 illustrates the sourcing concept for SOA components.

Figure 3: SOA Architecture for Unique

Figure 4: Sourcing Decisions for Uniques' SOA Efforts

Core application platform. Unique required each external provider to implement custom SOAP interfaces to its applications, making them easily accessible to ZEUS. Unique wrote ZEUS itself on the.NET platform using.NET WinForms in the UI layer and C#.NET Web services in the business services layer.

SLE. Unique developed the portal layer's user interface and business services using Visual Studio.NET, with Visual SourceSafe for software configuration management. The SLE tools that external providers use are transparent to ZEUS.

SDN. Within Unique's SDN, SOAP is the dominant protocol for accessing services. But SOAP by itself does not provide a high quality of service, so Unique controls and consolidates access to service requests through webMethods. In case of a SOAP request failure, webMethods' reliable delivery features ensure that the message is eventually delivered. The external SOAP interfaces are accessed over a private network, and no further security is used for the connection.

Unique uses webMethods' message-flow monitoring as the core of its SCP.
Future platform possibilities. For a while after ZEUS was first delivered, Unique's SOA platform was adequate for current needs. Now, Unique is planning to add business process management (BPM) and workflow capabilities to increase its process flexibility and control. Beyond these, possible future additions include Web services management to report on the operations of both external services (accessed through webMethods) and internal services running on the.NET platform.

SOA Case Study: Charles Schwab: Unified Service Delivery Network

The adoption of SOA in the financial services industry continues to outpace many other service sectors of the global economy. In applying the design center concept to a financial services firm Charles Schwab, the following insights were gained relative to SOA adoption.

Business drivers for SOA. As is typical of many large enterprises, a financial firm had a wide diversity of it projects in progress simultaneously. Some of the firm's specific initiatives included applications for customer information, account inquiry, check imaging, and insurance sales and servicing. Rather than developing separate integration solutions for each project, the firm sought to provide common access architecture to share the business logic of applications that were spread across disparate technology platforms. SOA provided the right design model for reusable business services, and Web services provided an open, standard protocol to connect across platforms.

Solutions delivered. The firm built an infrastructure for service access across all of its major application platforms. The infrastructure was designed for general use across a variety of business solutions and scenarios. So far, the firm's service infrastructure does not support externally accessible services.

SOA platform strategy. Because its starting point was to create a common strategy for cross-application connections, the firm's focus has been on the service delivery network component of its SOA platform see figures 5 and 6:

Figure 5: SOA Architecture for Charles Schwab

Figure 5: Sourcing decisions for Charles Schwab's SOA

Key decisions for its SOA platform were as follows:

Core application platform. The major platforms on which the firm's business logic resides are Java (WebLogic), HP Integrity NonStop, and IMS on an IBM mainframe. In addition, BEA WebLogic Integration provides integration functions for the Java environment. The firm has a mix of custom and packaged applications.

SLE. In addition to the native tools for each of the firm's core application platforms, the development tool suite includes XMLSpy for editing XML specifications. Although the firm has not yet put in place a repository or registry, it uses Contivo's metadata management software to manage its inventory of data and service interface specifications. Contivo documents the meaning and usage of data elements and interfaces and generates XML transformation specifications that are used in request processing.

SDN. The firm's SDN is founded on SOAP interfaces for cross-platform compatibility. To speed up XML parsing and transformation, most of its reusable services are routed through DataPower's XML acceleration product as a single point of control, yielding faster performance, greater scalability, and easier development. The firm uses Systinet's tools and servers to add reliable delivery and failover to the SOAP capabilities of its J2EE infrastructure. It uses both SOAP and WebSphere MQ to access legacy platforms, including IBM's MQ-to-IMS bridge. Behind the initial SOAP-based connection points, any application may connect to downstream applications using native protocols.

As yet, the firm has not found it appropriate to rely on Web services standards for transactions. Where it is necessary to ensure the integrity of its service calls, the firm has implemented compensating transaction logic within both the service requester and the service itself.

SCP. The firm has not yet found it necessary to implement Web services management. Instead, it uses HP OpenView to manage its services by controlling the underlying platforms where the services are running. To accomplish integrated deployment to its SOA platform, the firm uses scripting tools to write custom deployment scripts.

Future platform possibilities. The firm has plans to expand the flexibility and robustness of its SOA applications by adding BPM, event-based processing, and enhanced security and identity management for services to its platform. To get more direct data on the operation of its SOAP interfaces, the company may evaluate Web services management solutions in the future. It may also consider using Web services transaction specifications in place of its custom compensating transaction logic as the specs mature.

Lessons Learned from the Design Center Strategy of SOA Implementation

The strongest results and best practices are emerging for those companies that start with the service delivery network of their it platforms' overlay to business strategies, and then build out their business processes. From these case studies, the major themes and lessons learned are as…