10 Tips for Getting Started with Service-Oriented Architecture

By Ericka Chickowski  |  Posted 2008-03-25

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

3. Function-first, not product first.
Both Schmelzer and Heffner emphatically agree that one of the easiest ways to kill your SOA hopes is to approach your design phase backwards.

“People are doing it so backwards, they are saying, oh I need SOA, so then let me buy an EMC solution, oh and then let me figure out what services to build and then let me figure out what architecture I need,” Schmelzer said. “Before you even build your services, think about how the services are going to be used, because you can create a service any of two hundred different ways.”

Heffner echoes Schmelzer: “In terms of designing your SOA platform, do it function-first, not product-first,.  Because by examining the functions you'll need, then you can better map those to what capabilities you'll have in your existing products and what you can get in any new products. Start with that.”

4. Don’t try to make everything service-oriented.
Not every  application in the enterprise is suited to a service-oriented architecture, so don’t try to shoe-horn it into everything, Schmelzer says.

“If you apply SOA where things don't change, then all you are doing is introducing variability and inefficiency into the process for no good reason,” he said.

For example, it wouldn’t make sense for an organization to convert a wire transfer process to SOA because it is not going to change and you wouldn’t want to introduce variability into the process, Schmelzer said. In that case, it makes sense to just leave wire transfers as its own service. Schmelzer explains that functions need to be examined first for SOA suitability—another reason to adhere closely to tip number three before delving into an SOA project.

“Ask yourself, is this process going to change? And when it changes, does it cost me a lot in terms of money and complexity?,” Schmelzer said. “If the answer is yes, then that could be service oriented.”

5. Incremental SOA is a good thing.
Organizations who approach SOA incrementally set themselves up for greater successes than those who chose complex, unwieldy implementations with a lot of long-term returns but very few short-term gains.

“Maybe you want everything in your organization that can be service-oriented to be service-oriented , but that doesn't necessarily mean you should do it all at once,” Schmelzer said, “in fact you probably shouldn't because one of the great things about starting small is that the penalty of failure is so low."

It makes more sense to do small, bite-sized projects. It is easier to create miniature business case scenarios for these short projects and their success guarantees future projects.

“Focus on what your immediate needs are for the SOA based solutions you are going to deliver in the near term,” Heffner said. “Because, if you don't deliver in the short term, you won't deliver in the long term because you won’t get the funding for it.” 
6. Think about how near-term returns complement long-term goals.
As you are doing these smaller projects, it is important to think about how they funnel into your long-term SOA goals, of course.

“Put those immediate requirements in the context of your longer-term SOA platform goals so that you can  best balance of near term and long term concerns,” Heffner said. “And also try to find something that you can do and pay for within the current delivery project, because very few people get big buckets of infrastructure money to go on a shopping spree and have fun buying all sorts of new SOA platform products.” 

7. Bake security into the architecture from the start.
One major consequence of transitioning to SOA is that it can create a number of governance and security concerns along the way.

“If you have a bunch of services and anybody can build any service and anybody can compose them together that means that things can be really unpredictable,” Schmelzer said.

The problem is that many SOA architects are failing to bake in security because they are approaching SOA incrementally and don’t think they need security for smaller projects.

“They’ll say, ‘Well, I don’t need governance because I’m only going to have one or two services that are only going to be used in this environment so let me just put them up,” Schmelzer said. “The problem  is that that rationale only works if you're planning on the services not actually being used. And if that's your conclusion then why'd you even go through all of that. If they're not going to be used then just don't build them in the first place."

Putting security and governance into the process is all about avoiding chaos, he says

“If governance is put into place it will make sure people aren't building incompatible services or services that are redundant,” he said. “But more importantly people aren't combining services together that shouldn't be combined because of policy or they're putting  a service into some production environment that s going to dramatically increase its usage above what the infrastructure can support. The governance is like the police."

8. Expect SOA technology to change a lot.
Heffner warns businesses that as early-adopters of SOA, they should expect the technology that supports it to change a lot over the next couple of years. This is partially why incrementalism can be very beneficial.

“When you go to actually make the investments in new products and technologies, view those, first and foremost, as tactical investments that may need to be redone and reworked over the next couple of years as SOA technologies as vendors and vendor landscapes and technologies and standards mature,” Heffner said. “There's so much left to mature in terms of the SOA standards and things will change.”

9. Push vendors for better investment models.
Because that vendor landscape is changing, enterprises can have a positive impact on the technologies that will help them to accomplish their SOA goals. Heffner encourages organizations to push vendors to adjust their technology offerings in ways that make sense for their business workings and return on SOA investment.

“I would push vendors to give you investment models that match the business model that you're going to get out of the platform,” he said. “Talk to vendors and say, ‘Here's how much business value I'm going to get in the short run, I've got to have an investment model that doesn't outrun that or I'm not going to be able to buy anything.’”

10. Find a vendor willing to be a partner.
Similarly, be choosy about who you choose to help you accomplish SOA goals, Heffner said. During negotiation, play vendors off one another for the best deals and also let them know what your short- and long-term goals are. Explain that you don’t want to buy everything all at once.

“Tell them, ‘We are committing to your product in a long-term way but we only want this much right now.  Here's how much we'll pay now. As we expand it, here's how much we'll pay later, and when we expand it to an enterprise thing, here's how much we'll pay,’” Heffner said. “Negotiate all that up front, and the vendor can see the path and then it's incumbent upon the vendor to actually deliver the value so that you buy into those extra levels.  It's a matter of how creative you can be with your negotiation and how you position the vendor's opportunity.”