The Truth About SOA

We pour some cold water on the hype and answer your questions about why, how and when you should (or should not) start thinking about implementing a service-oriented architecture.

Reader ROI

• Why service-oriented architecture demands a long-term commitment
• How to ensure that a service gets reused
• Why business process complexity is a prerequisite for SOA

CIOs are chasing a distant dot on the horizon called agility (the ability to change IT quickly to fit business needs) and the dot is receding.

Fast.

A recent survey by the Business Performance Management Institute found that only 11 percent of executives say they're able to keep up with business demand to change technology-enabled processes - 40 percent of which, according to the survey, are currently in need of IT attention. Worse, 36 percent report that their company's IT departments are having either "significant difficulties" (27 percent) or "can't keep up at all" (9 percent).

Service-oriented architecture, or SOA, is the latest in a long line of highly hyped strategies designed to bring that disappearing dot back into view. By mirroring in technology important chunks of business processes ("credit check" or "customer record", for example), SOA promises to give companies a portfolio of services that can be mixed quickly and matched expeditiously to create automated business processes, thereby reducing application development time and costs by as much as 50 percent.

From its humble origins in object-oriented design and component-based software development methodologies, SOA has moved into a rarefied realm of expectations. SOA, the story goes, isn't merely designed to remake IT; it's going to be a magic bullet to transform the businesses that IT serves too.

CIOs, usually a sceptical crowd, are helping drive these expectations. According to a recent Forrester Research survey, 46 percent of large-enterprise SOA users (and about 27 percent of SOA users at midsize and smaller enterprises) said they're using SOA to "achieve strategic business transformation". Surveys from other research companies report the same enthusiasm, with "competitive advantage" being the most popular expectation in a Summit Strategies survey, and the ability to "develop new capabilities and products" topping the list for Aberdeen Group's respondents. In a recent US CIO/Computerworld survey, 77 percent of respondents said SOA would result in greater business flexibility.

And it may do all that and more.

Just not yet.

Page Break

Even Harder Than You Think

SOA is far from being a proven concept (only 16 percent of companies in the Aberdeen survey have more than 24 months of experience with SOA technologies), and the companies that have had the most success with it so far are those that always have success with technology: big companies with big IT budgets whose business is technology-based (think telecomms and financial services). They also tend to have supportive, technologically sophisticated business leaders.

For companies without these advantages, SOA may not be the panacea it's being made out to be.

That's because SOA demands a bigger investment and a longer strategic commitment than CIOs may think. The tactical part - service-oriented development - is a surmountable technical challenge. But the strategic part - creating an architecture based on a portfolio of services - asks that CIOs make a compelling case for enterprise architecture, a centralized development methodology and a centralized staff of project managers, architects and developers. It also requires a willing CEO and executive staff to pave the way for IT to dive in to the core business processes of the company. Understanding those processes and getting buy-in on enterprise sharing are the real sine qua nons of SOA-based business transformation.

For companies without technology products, big budgets or business leaders who chant the CIO's name every time he comes into the room, SOA is neither a guaranteed path to business transformation nor, in some cases, even desirable. For smaller companies, for companies that have made big bets on integrated application suites and for companies that already have solid application integration strategies in place, SOA isn't a "when", it's an "if". CIOs need to pursue a SOA strategy carefully because the service development and architecture planning pieces of SOA are distinct but not independent - they need to be considered and executed in parallel. Services built in isolation, without taking into account the architectural and business goals of the company, may have little potential for reuse (one of SOA's most important benefits) or may fail outright. Grand architectural planning exercises may drag on endlessly, without providing any real business benefit.

And that dot on the horizon, agility, is difficult to quantify. "We can't say, Do SOA because it will give you a much more flexible set of systems," says Daniel Sholler, Gartner's vice president of research. "There's no metric that says if I'm more agile I will save X percent. The number-one difficulty with SOA is that it's hard to get the ROI down to the spreadsheet level." Indeed, a survey by integration software maker WebMethods found that the top two inhibitors to SOA were, respectively, a lack of general knowledge and the difficulty of quantifying its ROI.

Indeed, there's no inherent ROI in any technology strategy, cautions David Johns, senior vice president, CIO and chief supply chain officer for Owens Corning, a building materials manufacturer. Therefore, he says, "developing a service-oriented architecture is not our goal. Driving productivity and driving waste out of the supply chain are the goals, and we'll look at technology solutions from that aspect rather than what the industry may say is the latest, greatest thing."

Some are even more dubious. "Companies are creating a complex bureaucracy around something that 90 percent of the time is overkill," says Thomas Gagne, CTO of InStream Financial, a software and financial services vendor. "Why are we replacing technology and obsolescing our employees' skills faster than we're realizing the benefits of the previous, now supposedly inadequate technologies?"

That's a difficult question CIOs need to ask themselves before entering SOA's business transformation revival tent. Here are a few more:

Page Break

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."

Page Break

Q: How much reuse can I expect from services? And what does that mean in real dollars?

A: Reuse of services can vary widely and depends on the rigour of the design, which in turn depends on the abilities and experience of the developers and project managers, says Heffner. Reuse also depends on the level of architectural planning that surrounds the specific service. For example, a service has more chance for reuse if it is developed as part of a broad SOA strategy that includes uniform development methodologies, a centralized architecture planning staff and business analysts who can examine processes across the company and incorporate the unique needs of the business units into the design of the service. "If a service isn't designed with knowledge of how other parts of the organization may want to use it, it's unlikely that those groups will adopt it," says Gleason. Worse, designing a one-off service could lead to duplication of effort down the road. "You may need to create a second service to complement it because you don't have time to modify the first, or perhaps you're going to have to rebuild the thing because now it doesn't meet your requirements," says Gleason. "In the long run, there's no hope for business process integration, or business process management, if I don't look at services from an architecture perspective."

But if a service can be reused even once, it can have an exponential effect on savings, according to Heffner. Even though services require more up-front design work, reuse means there will be no costs for design, coding or unit testing the next time around. Together, these steps account for about 40 percent of a software project cost.

Veterans caution that it's difficult to predict the reusability of services. Sizing the services properly (known as granularity) so they don't try to do too much or too little is an art. "We have challenges with granularity," says Howie Miller, VP of integration architecture for IBM's internal IT group. "I'd say 30 percent of our assets drive 90 percent of the return because they are sized better," says Miller. Heffner agrees: "At one auto company I've talked to, they had some services that were used 20 times and others that were used only once."

Q: I need to show value to the business for everything I do. How do I balance the architecture planning with the need to prove value to the business quickly?

A: Architectural planning is time-consuming. Service-oriented development, drawing upon well-known programming principles and widely available technology standards (such as SOAP, HTTP and so on), can happen a lot faster. But the two need to happen in parallel, say experts. "We do development projects as needed and then on the side we have a longer multiyear project of mapping out the processes and building enterprise-level services," says Kurt Wissner, managing director of enterprise architecture and development for American Electric Power (AEP). "People need to see the benefit of SOA pretty quickly. That's why I like the project route, because otherwise you don't have anything tangible to sell to anyone about why you're doing this."

While it would help to have the architectural plan and the process mapping in place before building the services (to improve the chances for reuse), architecture planning has no short-term payback, which can be devastating. "I tried to boil the ocean at another company and I failed," recalls Wissner. "We did a big multimillion-dollar architecture plan that duplicated what we already had. It didn't provide much value over traditional point-to-point integration, and we had nothing to show for our efforts. If you start with the entire enterprise, there are too many risks you might fail."

By taking the enterprise planning in smaller chunks at AEP, Wissner can more easily recover from setbacks. "We've had hiccups but could take corrective action because the issue wasn't that big," he says. "If you break it into simpler pieces, it's more easily digestible."

"Business processes change all the time," adds Praveen Sharabu, director of enterprise architecture and infrastructure for transportation company Con-Way. "Nobody can wait for two years while you document everything, and it will be obsolete by the time you finish."

Q: I can't afford to build a million different services. How do I know which services will provide the most value for my investment?

A: When in doubt, start with processes that involve customers, directly affect revenue and address a specific pain point in the business. A 2006 survey by the Business Performance Management Institute found evolving customer needs and preferences to be the top driver in business process change or the introduction of new applications, followed by competitive threats and new revenue opportunities. (Cost savings was a distant fourth.) "Externally facing applications are the ones that provide the most business value, and they have a good set of change requirements that come up very often," says Gartner's Sholler. "If you can improve those applications by 10 percent, it's better than improving lower-level applications by 50 percent." Of course, adds Sholler, SOA may not provide more value than, say, a good packaged application. "But if it's something you would have to build yourself anyway, you need to do it service-oriented," he says.

Page Break

Q: How will SOA affect my IT group?

A: If you have a decentralized company, be prepared for a struggle. SOA drives centralization. Indeed, it demands it. "You have to have someone heading it up, and you have to have one individual or small team manage the architecture," says Mike Falls, senior system engineer for Fastenal, an industrial and construction supply company. "If each team is left to itself, they may each come up with different ways of building services. You need one group, one set of research and someone to make sure the development groups are sticking to the service development methodology."

As the service portfolio grows, the development process may begin to look like an assembly line. "It becomes a factory," says AEP's Wissner. "You have these different project teams that you funnel work through, and they can grow and shrink as required."

Once the SOA factory gets ramped up, expect to add more project managers, business analysts and architects as the productivity of the developers increases, says ProFlowers' Hall. "Two developers can now do the work of six," he says. "That means the architects and project managers are running to keep up with the output of the engineers. We are probably doing 50 percent more work than we did three years ago."

Those programmers need to understand object-oriented programming and distributed applications - and that means an investment in training. According to the CIO/Computerworld survey, only 25 percent of respondents have the staffs they need for SOA - 49 percent said they are planning or have training programs in place for current staff to bring them up to speed.

If You Can't Beat 'Em, Integrate 'Em

In the new SOA world, enterprise vendors suddenly are eager to make sure their application suites can play well with others.

In the 90s, your integration strategy was simple: Buy as many preintegrated applications from a single vendor as possible. That worked for you, and it worked extremely well for the vendor; integrated application suites fetched a high price and required long-term maintenance and support contracts that promised a steady, predictable stream of revenue from customers.

Even better, CIOs' fear of integration pain gave vendors a built-in sales advantage whenever a company wanted to add a new application to its stack. It was easier for the CIO to pick a preintegrated application from the dominant vendor than to take a risk on a best-of-breed newcomer - even if its application had better functionality - because expensive integration disasters had become the much-publicized bane of the industry. Better to have disappointed users, CIOs reasoned, than headlines in the business press.

But the rise of service-oriented architecture has produced a shift in integration strategy. SOA makes the radical assertion that the enterprise application infrastructure is irrelevant. Technology is constructed according to services specified by the business, not by processes contained within an enterprise application vendor's software box. In this scenario, packaged software is a piece of the service, just another component in a larger business process - such as an insurance claims process that links a jumble of functions and data inside ERP, CRM and old mainframe legacy systems. The application's vendor doesn't matter any more; the linkages between the applications are the important thing.

As a result, the vendors' integration strategies have become more important than the features of their software. (Both dominant enterprise software vendors, Oracle and SAP, have begun offering integration middleware to go along with their software suites, although both are sticking with the big, integrated software suite vision.)

In the brave new world of SOA, the big software vendors have decided to take a page from Microsoft's playbook and duplicate the Windows strategy. With the Windows operating system running on 95 percent of PCs, software developers are eager to create software that works with Windows because it means they can reach the most customers and make the most money. As a result, the thousands of applications available for Windows today ensure its dominance in the operating system market tomorrow. Similarly, the big enterprise software vendors are trying to ensure their futures in a SOA world by assembling ecosystems around their core applications.

Page Break

With CIOs reluctant to upgrade to new versions of enterprise software, the big vendors are saying: "Look, we can't sell with our old value proposition any more", says Gartner's Sholler. "So they're trying to make [their software] the foundation for other solutions in markets they haven't been able to reach."

But this strategy has put the enterprise application companies on a collision course with traditional middleware providers such as BEA, IBM and WebMethods, which are coming to the SOA party from the bottom up, through the integration infrastructure layer. "Everybody is winding up tangled up in the same space," says Sholler.

Although the integration infrastructure companies have much more experience with the foundational elements of SOA, all vendors are looking to build long-term relationships with customers. Consequently, despite the abundance of Web services standards embedded in their products to ease integration headaches, everybody has a proprietary hook somewhere. Oracle's Fusion applications will work only with Oracle's database. SAP's new applications require NetWeaver middleware, according to Gartner and Forrester Research. Even the integration infrastructure companies have enough proprietary elements to make it difficult to swap out their integration software.

The bottom line for CIOs? Beware vendors pledging to build your SOA for you. Unless you're not worried about dependence on your vendor.

But CIOs on the whole fear dependency, especially in the current wave of consolidation, according to a 2005 Accenture survey of CIOs. While 65 percent of CIOs said vendor consolidation makes for a more integrated software infrastructure, and 61 percent believe it will reduce their vendor management burden, 87 percent said vendor consolidation will lead to lock-in, 61 percent believe it will decrease price competition, and 57 percent believe it will reduce pressures for vendors to innovate. Only 35 percent saw vendor consolidation as a good thing.

For SOA believers like Transamerica's Gleason, an independent SOA controlled by the CIO is one of the best protections against lock-in. "No one vendor can be all things to everyone," he says. "There's always going to be somebody out there who will be able to do a piece of your process better than anybody else can. And the first company to adopt that is going to have competitive advantage."