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 organisations 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 are the six burning questions IT organisations 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 US$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 organisations 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 organisation 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 organisations," 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 recognised 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 centre" 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 BEW, 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 externalise 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 organisation.

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

SOA technology vendors have focused more on enhancing features and functions than on enabling scalability, and users are paying the price, argues consultant David Linthicum.

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

"I can always build a system that performs better if I'm willing to send out binary data and not have something that has to be parsed the way XML does," Fulton says. "But can I build it as fast and modify it as quickly? We're always asking the hardware and operating systems and the layers on top to support higher and higher levels of abstraction. ... "Is it more efficient to do it a harder way? But how many CPUs are less than a gigahertz today? Not many. We let the computer do some work for us again and again through the life span of the application just so we can get it built quicker."

5. Do security requirements change when an IT department uses SOA?

At Avis Budget, IT executives thought security was a peripheral concern when SOA efforts began. Now it's become one of the most pressing issues they must address.

Using SOA has opened new channels with business partners, and Avis must make sure sensitive data like driver's license and credit card information is encrypted inside databases and in transit.

"You'll have queues, you'll have databases, you're going to have channels. So we're trying to go for secure all the way through," Kumar says. "You are creating a more distributed environment. From a security point of view, it becomes harder to manage. You have many more components that are part of it, vs. a more centralised mainframe base where you have one place to go."

Identity management is one of the key challenges IT managers have to address with SOA.

"When you have a SOA environment, the same business service may be used in 10 different ways," Hurwitz says. "You have to make sure you have a security structure in place that says who's allowed to access what in what circumstances. ... It becomes more complicated. The risks in some ways get higher because you're reusing a lot of services and you have to make sure you have the right level of security on top of that."

Traditional application security is "ineffective and unwieldy in a SOA" because identity and access rights -- including passwords and privileges -- vary widely among applications, West of Saugatuck Technology writes in a research paper released last year.

Single sign-on has not proved scalable in large organisations and is complicated by privacy and competitive issues when applied to SOA environments that range across business partners, West writes.

Less problematic is a federated identity management approach that works by trusting the source of assertions and uses Security Assertion Markup Language. Requests for access control information can be coded in browser requests or included in Webservices transactions, West writes.

"In this way, an identity management server produces assertions about the identity and rights of users that an application responds to," West writes. "An application, a service or a 'wrapped' services interface wouldn't need to have access to a directory or trust an individual user, because it only needs to know and trust the assertion and the assertion's source."

West portrays the IT perimeter as a "porous membrane" allowing data transport among a wide variety of business partners, customers and non-employees. SOA, he says, carries its own unique vulnerabilities that require adequate management on multiple fronts within the enterprise and in dealings with vendors.

A more optimistic view can be found with Mengerink, who says security actually becomes easier after deploying an SOA. But that's compared to the enormous task PayPal is faced with when securing payments on the Web. PayPal's SOA is provided solely for developers, he notes.

"The number of attack surfaces we have on a Webpage is just enormous," Mengerink says. "Now if you say all you can do is you have to register with us and I have your names, I know who you are and I've got to give you a special token before you're allowed to talk to me, that's a very narrow channel of people. That's a much easier problem for us than everyone on the planet can go to and start attacking."

6. What are SOA's dark sides?

Security is clearly posing a challenge to at least some IT executives deploying SOA, but it's not the only dark side you'll find when building a service-oriented architecture. One of the "dark underbellies" of SOA, according to Fulton, is the challenge of providing a unified view of data and access to data across multiple business services.

Reusing old software for new business processes is great, but it exposes an Achilles heel of most enterprises: their customer data has evolved over time.

Offering an example, Fulton notes that five years ago, cable companies thought of a customer as a person who lives in an apartment or house where they receive a bill. "Today, you probably [say] a customer is someone who receives a bill for multiple premises, potentially. That's a small change, but the old applications can't do that. ... So all building blocks of services can be manipulated to do things quickly, you have to figure out how to unify the data. People are still struggling with that."

There are probably 15 vendors that offer a solid enterprise service bus, but industry efforts in managing data are less mature, Fulton says.

The challenge of securing the cash to fund new SOA projects is another potential dark side. Even though SOA can save businesses money in the long run, Kumar says it is difficult to convince the people who control the purse strings to look to the future.

"You have this whole establishment that's based on project-based funding. Every project has to justify its own ROI," he says. "We are getting traction at it now, but it still is a challenge to teach finance people to look beyond just single projects."

Hurwitz claims the dark sides of SOA are "never about the technology." It's the people developing the technology that cause problems, she says, particularly when they don't collaborate with people on the business side of the house or think about what services the business really needs.

"You go out and create 10,000 business services, well, they're way too granular and it's hard to access them," Hurwitz says. "And it's not going to help you much. The dark side is not doing it right."

Fulton says there are fewer "dark sides" than there are "impacts" with SOA. One impact is the need to buy technology to support SOA, and the confusion that can result when one realises just how many products there are to choose from.

"There's ESBs, there's SOA management products, there's products for managing Webservices, there's hardware acceleration devices for Webservices, there's gateways and you name it," Fulton says. "The question is 'what do I really need?' And of course the true answer is 'it depends.' But a lot of people are saying 'tell me everything I need to buy so I can get SOA off the ground.' Well, that's probably a very bad way to approach it because you can end up spending money for things you're not going to take full advantage of."