Lessons from an SOA pioneer

Today, SOA (service-oriented architecture) is the undisputed champion of IT trends. But IT professionals have seen other megatrends come and go, some successful, some disastrous. Many companies remain skeptical about SOA, in part because most deployments are recent, leaving any assessment of long-term viability inconclusive.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Yet a handful of deployments that began before the SOA acronym was coined are beginning to suggest how effective the service-based approach to application architecture and business agility can be over the long haul. Among these, Con-Way Transportation Services stands out as an ambitious, successful reinvention of one enterprise's application infrastructure.

Whereas most enterprises in the 1990s were developing or deploying client/server architectures, Con-Way decided to take a more component-based, distributed approach to app dev and delivery. As Con-Way's SOA evolved, it helped insulate the company from the disruptive effects of new technologies, mainly because SOA's basic premise of abstracting services makes it easy to adapt as technologies change.

Con-Way's initiative also demonstrates that the key to successful SOA deployment is to focus on the business processes that are the heart of the services, rather than on specific technology platforms.

Reworking a legacy

In 1997, as a newly spun-off subsidiary of logistics management company CNF, the Con-Way shipping unit relied on corporate systems for inventory management, billing, order tracking, and the like. That limited the organization's flexibility and its responsiveness, recalls Praveen Sharabu, Con-Way's director of enterprise architecture, because CNF's IT group and software development efforts had to balance Con-Way's needs against those of the other units, which at the time included the Emery Worldwide air freight service and the Menlo Logistics warehouse management service.

With an initial IT staff of six, Con-Way's executives decided to keep development in-house rather than rely on the parent company. (The IT staff is now about 100, including developers, architects, and networking administrators.) Con-Way would continue to rely on CNF for its Oracle Financials and PeopleSoft applications and databases for financial reporting and HR functions because all CNF units followed the same standards. But it wanted control of the applications used to run its business: customer tracking, billing, shipment management, and other core functions.

The IT staff calculated that, following a conventional app-dev approach, reworking Cobol applications for shipment management to meet requirements would take five years -- not exactly an agile turnaround. But several new staff members, including Sharabu, had experience with component-based development using Texas Instruments' IEF (Information Engineering Facility) environment from previous jobs. They thought it would make sense to develop their mainframe apps as coarse-grained components, so they could roll them out incrementally, rather than waiting until the complete system was done before seeing any benefits.

They brought in an independent consultant familiar with both component architectures and object-oriented development. He showed them how to develop components that were abstract enough to be reusable, so the IT staff could avoid creating multiple versions of essentially the same code, which would both be a long-term management problem and take more development time in the long run.

The team modeled the shipment functions across the transportation lifecycle -- from pickup request to pickup, intermediate transit and storage, delivery, and finally to billing and payment. "We created our methodology at that time," Sharabu says, by mapping out the business logic and figuring out what software components were needed to support it. "The granularity is very important. There's a tendency to make components too small or too big. The big lesson is that the development team has to be very close to business. They have to know the business processes; the granularity comes from the processes."