The Questions, The Answers

Q: SOA is a technology architecture. How do you make a business case for a new technology architecture?

A: You don't. "Don't talk to the business about SOA because the business doesn't care," says Forrester Research analyst Randy Heffner. The business's interest in SOA extends only as far as it cuts the cost of applications and gets them running faster. But simply rewriting code in the form of a service doesn't deliver those kinds of benefits. To start down the road to building a SOA, there needs to be multiple redundant IT applications that can be consolidated into a single service, or the possibility for multiple areas of the business to use a single service. To speak to the business, quantifying the redundancy helps. "I know for a fact that the same data is being extracted by at least 26 different applications in our environment for different purposes," says Jeff Gleason, director of IT strategies for Transamerica Life Insurance, annuity products and services division. "We're extracting it and paying to store it in all those different places. Just getting rid of those support costs is a big deal."

But there is also a flexibility quotient to SOA that can add value - if it is focused on a critical business process. At ProFlowers.com, for example, there are no redundant applications or multiple business units clamouring for services. But splitting the flower ordering process into discrete services means each component can be isolated and changed as needed to handle the spikes in demand that occur around holidays, according to ProFlowers CIO Kevin Hall. When ProFlowers had a single, monolithic application handling the process, a single change in the process or a growth in transaction volume (on, say, Valentine's Day) meant tearing apart the entire system and rebuilding it.

In the new system, a server farm responds to spikes in activity during each phase of the ordering process by transferring storage capacity to the specific service that needs it most. The system is much more predictable now, and there have been no outages since the service-enabled process was rolled out beginning in 2002, according to Hall. "Because we can scale horizontally [more servers] and vertically [splitting up services], I don't have to buy all the hardware to serve every service at its peak load," he says. "You don't have to be able to eat the elephant in one bite any more."

Q: When is SOA not a good idea?

A: Complexity is the prime prerequisite for SOA. Small companies that are consolidated on a single infrastructure (like Microsoft) and don't have complex application integration requirements are not candidates for SOA. Larger companies whose application infrastructure comes mostly from a single vendor (60 percent or more, according to experts we spoke to) will want to think carefully about whether building their own SOA is necessary or wise.

Then comes speed, and the need for it. If processes don't need to change quickly, then transforming IT in order to be able to change them more quickly is pointless.

At Owens Corning, 75 percent of its software applications come from SAP. Owens Corning's products are manufactured and sold in similar ways around the globe, which means CIO Johns has long driven a strategy of business process integration through SAP's applications. "SAP is the integration strategy," Johns says. His goal is to unify all of the company's worldwide divisions on a single version, or "instance", of SAP running on a single database. He is also monitoring SAP's strategy of service-enabling its applications to create a ready-made SOA for its customers.

Global manufacturer Whirlpool has also placed a big bet on SAP and global process integration, which, to Esat Sezer, the company's corporate VP and CIO, makes more sense than application integration. "I'm not dealing with that any more," he says. "I have outsourced that to SAP. I look forward to SAP handling integration requirements that I used to have to handle myself."

Q: Creating a service requires more planning and design than traditional application development and integration. How much extra does service-enablement cost?

A: Forrester's Heffner estimates that the extra work involved in service-oriented development can range from 30 percent to 100 percent more at the design stage, which makes up 10 percent or less of the overall cost of an application project. The extra effort is necessary to create a service that can be used in many areas of the business, each with their own particular needs. Transamerica's Gleason says that, for example, services that deal with insurance premium payments from customers generally need to accommodate multiple delivery channels - say, a Web site, a bank wire transfer or a call centre - depending on the process for each business unit. Understanding the ways each unit wants to consume the services is part of the design work and is critical to getting units to agree to use the same service.

But businesspeople are often aware of the extra effort required for services and may not want to pay for them. "I've heard this a hundred times," says Gleason. "A business sponsor says: 'Well, if you're going to make me pay for creating this service the first time, you just blew away the cost benefit of my project, and it's not going to get sponsored. And so I want you to go ahead and hard-code the integration because I need that functionality.' But then my job is to help them see how creating that service is not really a project artefact; it is a business architecture artefact. We're creating a piece of our business infrastructure that can be reused and changed. Once you get people to understand the requirement for doing that, then they stop worrying about whether it costs more to create it initially than it would to hard-code the thing."