By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Most people don't know that IBM's SOA test bed has been IBM itself. To date, IBM has deployed more than 50 services that have sped our transformation to on demand business. As a result, clients often ask us to share our experience with them. In this article I provide details of four IBM initiatives that represent a wide range of business challenges solved by SOA-enabled solution.
Case studies include:
- Customer Order Analysis and Tracking System [COATS]
- Microelectronics "factory in a box" [Microelectronics]
- IBM Intranet Password [IIP]
- Export Validation [Export]
Some of these case studies represent common problems facing many industries, (e.g. case IIP), while others are industry specific problems, with typical challenges that can be successfully addressed by SOA (e.g. Microelectronics).
Readers, who are asking why they should consider SOA or want to create a business case for its adoption, may find the Table 1 Business value propositions for SOA adoption below and the detailed descriptions of business drivers for each initiative helpful.
In addition to business context, each case study describes the challenges that the initiative had to overcome, an architectural overview of the SOA solution, and details on the resulting business benefits. In addition, I described best practices, and "lessons learned" that IBM is replicating now across our company and with our clients. Specifically these projects map to the five entry points that IBM has identified for SOA:
- People—projects that improve productivity by facilitating access to data.
- Process—projects that improve processes starting at the department level, and then rolling out enterprise-wide.
- Information—projects that integrate information through federated views of data.
- Connectivity—projects that speed messaging among heterogeneous systems while ensuring quality of service.
- Reusability—projects that encourage and reward service reuse.
SOA value propositions
During the last few years, my colleagues and I have worked with hundreds of clients to implement SOA-based solutions to various business problems. While everyone is talking about business flexibility and agility, initiatives are usually driven by a concrete business value proposition. Desired outcomes can fall into several categories described in the Table 1 below.
Table 1 Business value propositions for SOA adoption
|Business value proposition||Business drivers|
|Ease of systems integration||
|Business process flexibility||
|External processes cost and cycle times reduction||
|Risk and exposure reduction||
While a successful SOA implementation can achieve several different business outcomes, often there are 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 are 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 below.
Table 2 Business outcome summary for cases studies
|Business process/model flexibility||x||x|
|External processes cost and cycle times reduction||x||x|
|Risk and exposure reduction||x||x|
|Ease of systems integration||x||x||x||x|
Case Study 1: Customer Order Analysis and Tracking System - from legacy to on demand
Customer Order Analysis and Tracking System is a shared order entry application for more than twenty IBM manufacturing plants worldwide, each with its own customization needs and access patterns, e.g. 'High Volume-Low Price' vs. '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, 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 appropriate manufacturing plants. The manufacturing plants fulfill the orders and ship them to customers.
The original application, a complex 25-year old batch system, included 1.4M lines-of-code of 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 could not be easily adapted to address the needs of our business. To handle alterations to orders, including automatic alterations performed 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
On-going Order Management Component Services project is transforming the overall COATS to 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.
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 turn-around time. Business benefits included the following:
- Order transaction processing time fell from 4 minutes to just 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 run time workflow on demand, through easily selectable rules.
- We reduced development costs per release by more than 25 percent.
Best practices used and lessons learned
This initiative helped us create methods for incremental transformation of legacy business functions to agile, SOA-enabled solutions. Best practices used and lessons learned included:
- 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.
- Align business/IT architectures through service modeling.
- To develop agile business processes, address the full services life-cycle – from modeling to monitoring – supported by methods and tools.
- Follow an iterative design and incremental development employing modeling, design and integration patterns.
- Create early BPEL process models that do not include activities detail (they should be documented in use cases). Create a data model at the same time you create the business process model.
- This initiative helped us to 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.
Case Study 2: Microelectronics "factory in a box"
Like most companies, IBM is no longer operating under the assumption that we will perform all business functions in-house. We rely on an ecosystem of companies that help us focus on our core business competencies by assuming responsibility for some of our non-core tasks.
Our microelectronics business, for example, is moving from vertical integration to a global participant network. In 2003 IBM Microelectronics recognized the need for more flexibility in being able to react to the changing manufacturing requirements associated with wafer and module manufacturing across multiple sites and vendors.
IBM Microelectronics experienced challenges similar to the rest of the industry players:
- Technology cost and complexity continue to rise as does the demand for custom solutions (as opposed to standard products), while product unit costs fall.
- Demand volatility drives expense and investment volatility.
- Pressures to fuse advanced technology with business design to create an integrated, more flexible and responsive manufacturing environment.
- To achieve flexibility with multiple manufacturing sites need to eliminate duplicate systems, build once and leverage, and improve time to market.
- Requirements for consolidation of financial management by integrating historically separate systems.
To address these challenges, IBM developed a solution based on modularized architecture that allows efficient outsourcing by installing a "factory-in-a-box" on partner premises (depicted in Figure 2). One of the primary enablers of this virtual manufacturing is the Multi-Source Data Integrator (MDI), an IBM server containing a standardized suite of services that will exist at any manufacturing location to be integrated into the virtual manufacturing environment. The architectural solution is using industry standards and integrates business partner's manufacturing processes with those of IBM, thus enabling the seamless outsourcing of bond, assembly and test.
MDI is built on a foundation of proven IBM middleware: DB2, WebSphere Application Server, MQSeries, WBI, WBI Connect, TCI (includes wafer map management, data transport/translation and tester support) and TCIServices (includes composite rules, auto-setup and disposition).
B2B messages trigger actions and logic with the MDI in real time. MDI internal message formats are patterned after RosettaNet standards. After WBI-C receives and delivers messages to MDI processes at receiving location, they are the same Extensible Markup Language (XML) format as messages sent directly by the sending location.
This solution created "virtual" manufacturing for microelectronics – a "factory in a box" enabled via SOA:
- Multiple, interchangeable, integrated partners
- Routine upgrades to deployed software are seamless (i.e., no down-time, no negative impact to production).
As an example of business situation, an IBM Singapore facility was sold to Amkor Technologies. The facility was disconnected in IBM and reconnected in Amkor in just 4 hours – this was a process that could have taken as long as three days before the implementation of the new SOA enabled architecture. IBM rules were updated, IBM manufacturing went down and Amkor manufacturing came up.
Best practices used and lessons learned
Virtualization and isolation of business domains with related processes and data created "isolation framework" between domains that enabled "Virtual Factories".
Reuse of SOA reference architecture and best practices, harvested from earlier SOA enterprise initiative (COATS redesign), significantly reduced project time.