10 Tips for Getting Started with Service-Oriented Architecture

As service-oriented architecture (SOA) technologies and practices have gained the attention of CIOs and executive teams for showing business value, more and more IT managers are facing the prospect of trying out SOA for the first time. Just last year, SOA expanded  by 100 percent, according to a study released by AMR Research.  Analyst firm Gartner believes that by 2010 more than 80 percent of large, new systems will use SOA in at least some part of their design.

SOA offers distinct advantages to organizations with distributed and dynamic IT environments.

“The reason we use SOA is to allow things to change without causing them to break,” said Ronald Schmelzer, senior analyst and managing partner at ZapThink. “We're trying to introduce this whole variable and flexible approach.”

But SOA can introduce a lot of complexity into an environment and isn’t always as simple to implement as it first seems, said Randy Heffner, an analyst and vice president at Gartner specializing in enterprise architecture. 

“Sometimes people, having heard of SOA, understanding at a high level that it's an important thing to do will begin to think, ok, we've got to launch into this, and so they'll say we're going to plan to do it in the next year, and then they get into it and figure out, well, wait a minute, industry is talking about this in different ways and what does it really mean for us?” Heffner said. “It takes a while to get started on it.”

In order to help those organizations who are thinking about dipping their toes into SOA waters, Baseline asked both Schmelzer and Heffner for tips on how to approach SOA successfully and compiled the following list. 

1. Remember, it’s an architecture.
As the hype heats up, many vendors have jumped in with their spin on SOA. This can often have the unfortunate effect of making people forget the primary trait of SOA—that it is an architecture. The fact of the matter is that architectures like SOA are not dependent on any particular technology or methodology.

“Architectures are not technology specific, they’re just design approaches,” Schmelzer said. “We can implement SOA using a wide variety of techniques and technology, because what makes the architecture SOA are the design principles. Like, how I do abstraction, how I do loose coupling, how I deal with heterogeneity, how I deal with process.”

He believes the most successful implementations of SOA are carried out by organizations who remember this principle before they even start planning their service-oriented projects.

2. Don’t confuse SOA with web services.
This is a corollary to the first point. Many organizations these days seem to be under the mistaken impression that service oriented architecture is all about web services. The thing is, Schmelzer says, is that SOA is for all types of services across the enterprise. Organizations who make this mistake are missing the point of SOAs advantage as a scalable, flexible, enterprise-wide architecture.

“It’s forest and trees here, because you can certainly implement service oriented architecture without using web services and, more importantly, putting a whole bunch of web services together does not make a service oriented architecture,” he said. “It would be like putting a bunch of pieces of wood together and calling it a house.”