Manage Learn to apply best practices and optimize your operations.

Steps to implementing an SOA

In this column, Preston Gralla discusses the many steps involved in implementing an SOA.

The Web Services Advisor
(To receive this column in your inbox,
click Edit your Profile and subscribe.)

Continued from Part One

Service-oriented architectures (SOAs) hold potentially sizable benefits to enterprises. In an SOA, software components can be exposed as services on the network and can be reused often for different applications and purposes. In an SOA, developing new applications can be a matter of mix-and-match: Decide on the application you need, find out the existing components that can help build that application, glue them all together and you're done.

But it's one thing to know that SOAs can offer enterprises enormous benefits and it's another thing entirely to implement them. Implementing an SOA involves many steps.

Build a team
Before beginning, recognize that building an SOA can require an enormous amount of time and effort. While you should build a timetable and try as hard as you can to keep to it, make sure that you give yourself enough time to do it right. On the other hand, if you set up an open-ended schedule without deadlines along the way, there's a chance it'll never get done.

Once you set your timetable, spend the time to put the right team together, said Jason Bloomberg, senior analyst with ZapThink, a marketing intelligence firm that specializes in Web services and SOA consulting.

"Buying technology is easy, but putting together teams is hard," he said. "This is where the big effort has to be upfront."

Bloomberg said you need to build a team across all parts of the organization, including business as well as technical staff. An SOA allows you to align IT resources with business needs and then build reusable services and applications that will help further the business. So if you leave out the business side, you're bound to fail.

When determining who should be on the team and how the team should be organized, Bloomberg warns that companies should be careful not to merely mimic the current business structure.

Bloomberg said: "For example, let's say you have an enterprise organized by domains, with the SAP group here, the Windows group there, the database group over there and so on. An SOA may completely change all of that around eventually. So you might need to organize the team by services and business groups, such as purchasing activities in one group, sales in another and so on. Then each of those groups might have someone from databases, someone from Windows and someone from SAP."

A top-down or bottom-up approach?
Bloomberg advised to take both a top-down and bottom-up approach. Omit one or the other, he warns, and there's a much higher possibility of failure.

With a top-down approach, you should look at the overall enterprise infrastructure and architecture from a big-picture view and make sure that your new architecture touches on all parts of the enterprise. By knowing how all the pieces need to fit together, you can then build a system that will work not just for an existing business and IT structure, but for any future ones as well.

With a bottom-up approach, you should examine your existing functionality, the applications and capabilities you now have, and what kind of services, applications and capabilities you'll want in the future.

"You have to look at where your core assets lie," he explained. "But you have to go beyond what you have and build reusable services."

Dealing with semantics, data formats, taxonomy and data integration is also important. Although not a formal part of an SOA, Bloomberg said, it's absolutely vital that these factors are resolved before the SOA is built. The key to SOAs is building reusable services and components, but if those individual components use different data formats or taxonomies, they won't be able to work together and exchange data.

If you're building an SOA for internal use, you can use your company's internal data formats and taxonomies. But if your SOA will be used to deal with other companies, you should use industry-standard data formats and taxonomies. And, of course, make sure that you discuss data formats and taxonomies with business partners before you begin.

He also said you have to consider security and management issues at every step of the process, because it can be difficult, if not impossible, to try and retrofit security and management into an SOA after the fact.

Finally, Bloomberg warned that you shouldn't buy any products until you have the architecture figured out.

"Buying products without an overall architecture can be ineffective," he said. "Only buy products after you really know what you're doing."


Fast, furious Web services spending expected

Enterprises face challenging Web services buying decisions

About the Author

Preston Gralla is an expert on Web services and is the author of more than 20 books, including How the Internet Works. He can be reached at

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.