Abstract: SOA – service-oriented architecture – is one of the most talked about and least understood topics in IT today. From ROI to security, from network performance to Microsoft, this article examines six burning questions IT organizations face when they choose SOA.
SOA – service-oriented architecture – is one of the most talked about and least understood topics in IT today. It even has its own “Dummies” book. As an approach to building IT systems, SOA connects applications across a network via a common communications protocol, allowing organizations to reuse old software, often with the help of Web services. Saugatuck Technology predicts that up to two-thirds of IT departments will have a limited or full SOA production environment by next year. Here we examine six burning questions IT organizations face when they choose SOA.
1. Is anyone saving (or making money) using SOA?
Ashok Kumar of Avis Budget Group says he is. Avis began using SOA about two years ago in portions of the company to open new channels with travel partners. “They can now do direct business with us without having to go through a middleman. So it’s saved them a couple bucks, saved us a couple of bucks,” says Kumar, who is based in New Jersey and is director of services architecture information technology. “The cost of bringing on new partners is down to nothing now because of SOA.”
Avis Budget can now bring on a new partner in a day instead of a month, he says, because with SOA it is just a matter of configuring a service rather than making large application changes. “When we started that the cost of bringing on a new partner was anywhere from $40,000 to $50,000, now it’s down to $3,000 or $4,000,” he says.
Any company will face up-front costs associated with implementing SOA, but many IT experts say it can lower expenses in the long run. You can’t look at SOA in terms of short-term return on investment, says industry analyst Judith Hurwitz, lead author of Service Oriented Architecture for Dummies.
“It’s the type of technology that your real goal is reuse and the ability to loosely couple components together,” Hurwitz says. “You can’t look at this for short-term benefit because in fact the real gain happens when change happens.”
Traditional approaches to building software assume you start from scratch and develop something designed to solve a specific problem, Hurwitz notes. SOA allows businesses to be flexible and seamlessly react to major changes. A business might not see much benefit from SOA for months after deployment, but if it is suddenly involved in an acquisition “there’s a major change in their ability to cope with that change and react and then provide the software,” Hurwitz says.
A related question people ask is how much money do organizations spend on SOA, says Forrester senior analyst Larry Fulton.
“It’s a very difficult question to answer because, if five years ago I was going to build a new ERP system and today I’m going to build a new ERP system and I’m going to use SOA to do it, and I still spend $5 million on the project in software and what have you, is it really $5 million spent on SOA?” Fulton says. “It’s not. It’s $5 million spent on a business solution.”
There are two kinds of payback with SOA, says Mike West of Saugatuck Technology. The first comes when IT can reduce the amount of money it spends providing services. West believes SOA adoption is still in its early stages, and that perhaps only 10% to 15% of businesses are using SOA and doing it in such a way to save money.
An even smaller percentage of companies are using SOA in such a way that they are improving earnings, he says.
The world is full of projects that can be done quickly and cheaply and offer no long-term benefit, West notes. SOA is a radically different approach to building and managing systems that create a foundation for rapid change, he says.
“The real money gets saved or gets made when you have this flexible business foundation so your business can be more profitable on a top-line basis – not just IT savings being subtracted so the top line is smaller,” West says.
The eBay-owned PayPal might be one of those businesses. Matthew Mengerink, vice president of core technologies, says PayPal uses SOA to provide outside developers the tools they need to link online retailers to PayPal’s system for exchanging money among buyers and sellers. There are about 16 APIs that PayPal provides a community of 240,000 developers.
“We use it to allow others to build on top of PayPal,” he says. “We spend money to provide it but you make a lot. If you’re providing it for nuts and bolts, you have a lot more customers.”
2. Why is it so hard to find employees with SOA expertise?
Fulton says he’s never met a client who said “oh yeah, we’ve got all the architects we need.” One client told him the best method for identifying architects is to put a group of 10 developers to work, monitor them for 10 years and then decide who the architect is.
The task of finding SOA experts is complicated by the fact that people in the IT world simply don’t agree on what SOA means, Mengerink says.
“You get one person coming in and saying ‘that means it’s a Microsoft service interface.’ Another guy comes in and says ‘no it’s an Apple widget.’ Well, which one is right? If you’re hiring and you say ‘I want an engineer, you could get anything,’” he says.
The best approach is to train your own people, Mengerink argues, because the concepts and technology that underlie SOA aren’t that complicated. Of course, this is easier if you happen to be implementing SOA at a large organization such as PayPal. “If you take a really large company, they’re sort of defining what SOA is,” Mengerink says. “Somebody who has the resources is the one who’s going to say to the world what it is.”
SOA requires a different mind-set than traditional approaches to building an IT infrastructure, Kumar says. Many people can program in Java and understand how to make a single Web service, but putting it all together in a services-oriented architecture is difficult, he notes. “A lot of people have a hard time making that leap, and that’s why we tend to go to outside service providers,” he says. “Even then, I think good talent is just hard to find.”
Even if you hire employees well-versed in SOA, you might find they try to do too much, too fast. Enthusiastic workers sometimes want to “act heroically,” Hurwitz writes in SOA for Dummies.
“A young development team might decide to break the rules and start coding on their own, creating a new set of facilities ahead of what anyone else has done in competing organizations,” she writes. “Indeed, this type of innovation can be very important in establishing market leadership. But, you need to remember a caveat – innovation and creativity always require a leash.”
3. Has Microsoft gotten a clue about SOA?
“I’d say in fairness, Microsoft is getting a clue about SOA,” Fulton says. “Right now, their SOA strategy per se is a little mysterious; it’s a little harder to tease out. I think they have recognized it’s a significant force in the market.”
Vendors who are serious about SOA these days are expected to provide a robust enterprise service bus (ESB). Hurwitz describes the ESB as the “communications nerve center” for services in an SOA, acting as the intermediary between SOA components, infrastructure services and business processes. ESBs should be versatile, Hurwitz writes in SOA for Dummies, connecting to various types of middleware, repositories of metadata definitions, registries and service interfaces. Unlike IBM and BEA, Microsoft’s take on provisioning an ESB is less than straightforward, according to Fulton.
“Microsoft’s current story on ESB isn’t ‘hey, here’s out ESB product,’ but ‘you [the customer] can build an ESB … and you can use these products to do it.' They even talked about having accelerator packs that make it easier to build them on top of things like BizTalk.” Fulton says.
That would be Microsoft’s BizTalk Server, a business process management server that has tools to design, develop, deploy and manage a company’s business processes. Hurwitz describes the integration technologies in BizTalk as Microsoft’s “alternative’” to an enterprise service bus.
In SOA for Dummies, Hurwitz and co-authors list seven other Microsoft products that support SOA. They include Microsoft Windows Server, an infrastructure platform for connecting applications, networks and Web services; Microsoft.NET, a development framework for building applications and Web services; and the Windows Communication Foundation, a set of messaging technologies that let SOA components talk to each other and simplify how systems are developed and run.
Microsoft seems to be on board with supporting Web services and service interfaces in general, Fulton says.
West is less complimentary when asked if Microsoft has a clue about SOA. “Not really,” he responds. “It doesn’t go with what they’re doing. … SOA has open standards that you build to so that you can use these vendor products more or less interchangeably. Microsoft has a more Microsoft-centric approach toward Web services.”
Hurwitz, in a phone interview, says Microsoft is “SOA-aware at this stage.” The company is thinking about things like an “Internet service bus,” which would externalize a service bus to address the needs of partners outside the corporate firewall, she says.
Microsoft has failed to adequately address a number of issues, such as governance and giving customers a mechanism for locating individual services, according to Hurwitz.
“They’re doing interesting thinking and interesting planning around this,” she says. “I don’t think they’ve totally thought it through yet.”
4. How does SOA affect network performance and management?
For all its benefits, you can bet SOA will saddle your network with increased requirements and complicate network management and operations, consultant David Jacobs writes in a paper for IT professionals.
Since each application in a SOA is composed of many individual software components, a failure anywhere in the network can bring down an application, he notes. Your own performance in monitoring the network and immediately responding to problems is thus even more important after an SOA is deployed.
The way you measure network performance may also change, according to Jacobs. A metric like throughput is misleading because each process generates many interactions among application components. Since each one of these interactions involves little data by itself, the important things to measure are the overall transaction rate and responsiveness.
“Productivity is measured by how rapidly user transactions are completed,” Jacobs notes. “Data rates and the time required for each interchange between components are a factor in transaction rate -- but only one factor. Management software must be able to detect problems at the application level and then be able to drill down to find the root of the problem.”
At Avis Budget, overseeing network performance and management is one of the obstacles IT executives face as they attempt to roll out SOA into more of the organization.
“A lot of our users are distributed in small places where there’s not a lot of bandwidth,” Kumar says. “If we’re going to start rolling out a lot of this SOA functionality that we’re building, the network bandwidth will be a bottleneck.”
Avis Budget is using SOA for customer services, including reservations, checkout and sending receipts. Bandwidth availability is fine for internal corporate users, but Kumar says they have trouble providing enough bandwidth to remote users.
Hurwitz notes that SOA brings scalability concerns depending on how far one reaches outside a company’s firewall and into the systems of customers, suppliers and partners. But “I don’t think the impact on the network is really any different than when you’re doing any sort of distributed application where you need communications abilities,” she says. An enterprise service bus will help facilitate the communication among components and services, she adds.
“The SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads,” Linthicum writes. “SOA implementers were happy to get their solutions up and running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology.”
Linthicum recommends performance modeling and testing of real-life scenarios before putting a SOA into production. “You won’t know how it will behave until you put it through its paces,” he writes.
Linthicum also recommends improving performance by adding processing power at the origin of each SOA service.
There is always room for “more network,” Fulton notes.