Three Ways to Avoid SOA Snafus

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

Service-oriented architecture is set to surpass a 60% adoption rate among enterprises in North America and the European Union, according to research firm Forrester. But early adopters and experts warn newcomers that SOA is still in its infancy and there are still a lot of mistakes to be made.

“The biggest mistake people make is thinking that SOA is a technology. It’s not. It’s an architecture. And just because you know technology does not mean you know how to design an architecture,” says Forrester analyst Randy Heffner.

SOA is the underlying architecture that supports communications between services. SOA enables companies to weave multiple applications together to enhance process flows and improve user productivity, Heffner notes.

He adds that early adopters have found numerous benefits to SOA, including the ability to reuse applications, extend the life of legacy applications, improve business processes and save time and money on development.

But pioneers like Jeff Gleason, IT strategies director at a large insurance and retirement firm in the Midwest, says that you can quickly negate the pluses of SOA with missteps. Here are a few of the most common snafus that IT groups encounter with SOA.

1. Operating in a vacuum. Gleason, who’s done almost a dozen SOA projects in the past six years, says he realized early on that in order for his projects to be successful, he’d need buy-in from outside of IT.“You have to really get everyone on board — from the programmers to the shareholders to the end users – to be successful with SOA,” he says.

He advises his IT peers to be patient and clearly communicate the goals of their SOA projects with developers and business unit leaders. “You also have to set expectations. For instance, end users have to know that while in the beginning it might take longer for them to do their tasks, it will get faster,” Gleason says.

For instance, he worked with call center users to create a set of services that let them view information held in multiple policies in multiple systems at once – a far cry from them having to access separate networks for each policy.

Archie Roboostoff, director of product management at NetManage, Inc., in Cupertino, Calif., agrees that upfront communication is critical. “A lot of mistakes stem from IT not understanding holistically what the business unit does on a daily basis,” he says.

For instance, he encountered an organization where IT had spent significant time and money developing an SOA for its legacy applications only to find later on that those programs had not been used in three years. “Right there you see a disconnect between what the business is doing and what IT is doing,” he says.

He advises IT groups to sit down with business units to capture what end users do in their day-to-day tasks. “That way you create an SOA with services that accurately reflect what the end user does,” he says.

He adds that it’s just as important to have a feedback cycle that allows developers, programmers, business leaders and end users to comment on services and suggest improvements. “You can’t just deploy your SOA and walk away. It has to evolve,” he says.

2. Not creating a governance framework. Governance is a large part of developing an SOA strategy, according to Jason Bloomberg, senior analyst at the ZapThink advisory firm in Baltimore. He says organizations must decide ahead of time what their reuse and publication policies will be for the services within their architecture. “You have to think through how you’re going to create, communicate and enforce these policies,” he says.

One problem that often arises for companies that fail to think about governance is version management. “You may start to roll out services and everything is fine until you need to change something,” he says. There is a ripple effect from altering services that can extend all the way to customers that could disrupt business. “You have to develop a plan beforehand for updating and changing services,” Bloomberg says.

3. Treating security as an afterthought. Security can be one of the trickiest areas of SOA because organizations are reusing services that might have been created externally. “Before you bring services into your SOA environment, you have to put standards-based interfaces on them. If you don’t take care of security issues, you’ll put a hole in the SOA wall,” Bloomberg says.

Jon Gossels, president and CEO of SystemExperts Corp. in Boston, says that most services, to be made as reusable as possible, have security stripped out of them. “This isn’t good,” he says. To combat this problem, he urges IT groups to add service interfaces that address compliance mandates and cater to the highest level of security each application requires.

In addition, IT groups should carefully plot out their authorization and authentication strategies. “You need to decide who controls the addition of new services and who can change services that are already in use,” Gossel says.

Organizations should also monitor the services that come onto the network. “Otherwise, you could have someone deploy a rogue service and you’d have no way of knowing it,” he says.

Gleason says companies should expect to have some glitches along the way with SOA deployments. To minimize the risk, they should modularize their architecture plans and roll out pieces little by little. “If you start out too big, you’ll run into problems. The first time out can be tough, but it does get better… and you’ll see that SOA does make your life easier,” he says.