The biggest mistake people make is thinking that SOA is a technology. Its not. Its 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, whos 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, hed 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 its 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 cant just deploy your SOA and walk away. It has to evolve, he says.