For IBM, services-orientated architecture (SOA) is as much an internal, see-what-works-best effort as it is a way to sell their products and services.
Since about 1997, IBM has been working with early versions of SOA technology to expose many of it’s legacy and partner-facing applications in novel ways that enable the company to improve its business processes and, simultaneously, reduce the number of IT-supported applications by 400%, said Luba Cherbakov, an IBM distinguished engineer and part of the CIO’s SOA transformation team.
“The service is not only the technology, the service is the whole process that supports the technology,” she said. “Our SOA initiatives are focused on business transformation.”
Cherbakov singled out a 25-year-old legacy application to illustrate her point.
In the late 1990s, it became apparent that IBM’s Customer Order Analysis and Tracking System (COATS) was becoming too old and “brittle” to be of value much longer—1.4 million lines of code and multiple programming languages made it very time consuming and cumbersome to adapt COATS to meet new business demands.
“It really became very brittle every time we had to add changes to it,” she said. “So, by early 2000, we had to improve access to its functionality and to (save) really valuable business data that was residing in the legacy system.”
But, they couldn’t afford to rip and replace the application because of cost, disruption to the business (25 partners interacted with COATS 2,500 times per day to process over 10,000 orders). So, to remedy the situation, they began rolling out bits and pieces of the application as services.
The end result is a much more flexible application that processes orders in seconds as compared to minutes and is three-times cheaper to modify than before.
The Process
While the COATS-SOA initiative seemed like a no-brainer to do, the process to decide what applications are reworked and exposed as services takes a little more thought.
To figure out where to apply its resources, IBM developed a methodology called SOMA (services-orientated modeling and architecture) that looks at more than just the applications but the business processes it supports and the affect those processes have on the business. Cherbakov is part of the team that evaluates the results of the SOMA process and then sets a direction for the company’s overall SOA initiatives.
“What we’ve seen with some of our clients is SOA is driven by IT and this, of course, can lead to failure,” she said. “You have to start with the business, you have to understand business’ priorities.”
SOMA starts by deconstructing business processes and identifying the business goals they want to achieve. Based on those business goals they then decide on an executive to be the process owner and which services should be exposed.
They also take a flexible approach. Either working from the top down—developing whole new services based on an SOA approach—or from the bottom up—wrapping existing applications in SOA. In all, the company currently has 92 SOA initiatives in progress and many more on the way.
“I think there are many different definitions of ‘services’ and services orientation and these have changed with the maturity of the industry and SOA processes,” she said. “First of all, what’s a service? Service is a repeatable, logical manifestation of a business process. It’s not about Web services. It’s not about some technology.”
Lessons Learned
Having learned a few things along the way, the company is sharing it’s hard-won knowledge and practices with it’s clients; many of whom are just getting their initiatives off the ground.
Writing for an internal publication, Cherbakov et. al. spelled out the lesson she and her compatriots gleaned from their COATS initiative:
“This initiative helped us to create, implement and harvest methods for incremental transformation of legacy business functions to real-time, agile, SOA-enabled solution. Best practices used and lessons learned are summarized below:
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 in this initiative are being replicated across IBM and with our clients.”