While a successful SOA implementation can achieve several different business outcomes, there are often one or two key drivers that spark an initiative. It's worth mentioning that while benefits achieved through services reuse leading to reduced development and integration costs are essential in the long run they're secondary to SOA's business transformation value.

The IBM case studies described below had different desired outcomes and business drivers, both internal to the corporation and external, as depicted in Table 2.

Case Study 1: Customer Order Analysis and Tracking System - From Legacy to On-Demand
Business Context
Customer Order Analysis and Tracking System is a shared order entry application for more than 20 IBM manufacturing plants worldwide, each with its own customization needs and access patterns, e.g., High Volume-Low Price versus High Price-Low Volume. With 365 x 24 coverage, COATS fields orders from IBM customers, business partners, and IBM sales professionals for "complex" configured hardware.

Buyers indirectly access COATS to order new machines, upgrades, and customizations, and change existing orders. The application sorts and prioritizes these orders, comparing them against manufacturing rules and the customer's installed hardware base. COATS "translates" customer orders into a bill-of-materials and other instructions, which are then forwarded to the appropriate manufacturing plants. The manufacturing plants fulfill the orders and ship them to customers.

Challenges
The original application, a complex 25-year-old batch system, included 1.4 million lines of code in PL/1, OS/390 Assembler, Java, and other programming languages and was running close to capacity at peak times. Batch bottlenecks and conflicting data delayed orders and shipments.

With its hard-coded business rules, COATS couldn't be adapted easily to address the needs of IBM's business. To handle altered orders, including automatic alterations done by the scheduler system to meet customers' delivery dates, multiple databases had to be updated and queried, depending on geography and other parameters.

To support new product introductions, business opportunities, and outsourcing requirements, IBM frequently updated the application, spending considerable time and money on new functionality development - each version took six months to develop and more than 8,000 developer hours.

By early 2000 we knew we had to improve access to functionality and the valuable business data residing in the legacy system. We also had to be able to access it easily from other systems. Nevertheless, as with many enterprise-critical applications, "big bang" replacement was unaffordable and disruptive.

SOA-based Solution
The ongoing Order Management Component Services project is transforming the overall COATS into a real-time order submission system.

Figure 1 depicts the solution architecture that standardizes the connections between our business processes and IT requirements. In this architecture, the business rules are externalized and legacy system functionality is componentized to promote flexibility, scalability, and reuse.

The development team started with business process modeling using IBM's WebSphere Business Integration (WBI) Modeler. The workflows were enhanced using the WebSphere Application Developer - Integration Edition (WSAD-IE) tool with business objects from Rational XDE and integration of legacy adaptors. We connected legacy systems with business processes through IBM's CICS and MQ technologies.

Business Results
Several incremental releases of our new SOA-based solution resulted in improved business performance and flexibility, as well as reduced development costs and faster development turnaround time. The business benefits included:

• Order transaction processing time fell from four minutes to 10 seconds. When you consider that COATS handles an average of 2,500 transactions a day, this represents a potential daily time savings of more than 150 hours.
• Improved systems integration enabled real-time transactions, reducing discrepancies in delivery scheduling
• The new system eliminates redundancies, allowing IBM to react with more agility to changing order fulfillment requirements. We can now make changes to the runtime workflow on-demand through easily selectable rules.
• We reduced development costs per release by more than 25%.

Best Practices Used and Lessons Learned
This initiative helped us create methods for the incremental transformation of legacy business functions into agile SOA-enabled solutions. Best practices used and lessons learned included:

1. Implement services incrementally to provide early buy-in and a non-disruptive migration path while managing expectations. Co-existence of services with legacy code supports the gradual transition of system functions to the new architecture.
2. Align business/IT architectures through service modeling
3. To develop agile business processes, address the full services lifecycle - from modeling to monitoring - supported by methods and tools
4. Follow an iterative design and incremental development employing modeling, design, and integration patterns
5. Create early BPEL process models that don't include activities details (they should be documented in the use cases). Create a data model at the same time you create the business process model
6. This initiative helped us harden the IBM Service-Oriented Modeling and Architecture (SOMA) method.

We demonstrated incremental transformation through proper use of service modeling, incremental development methods, tools, and middleware components. The process customization, incremental transformation, and legacy integration methods developed on this initiative are being replicated across IBM and with our clients.

To learn more about how to build reusable assets to transform an order processing system, see the IBM developerWorks series On demand business process life cycle.