Next, select your technology set. Many people begin with this step -- at their peril. You can’t select the right SOA technology for the job without a solid understanding of your requirements. To be successful, the marriage of criteria and products often requires a pilot project to prove the technology will work. In fact, the time it takes to select the right technologies may equal the time it takes to develop the SOA. But it’s worth the investment, because a bad choice practically ensures the failure of your SOA.

And finally, test and evaluate. It’s essential to have a step-by-step procedure detailing how the SOA will be tested when complete. A test plan is important because of the difficulty in testing SOA solutions. Service orientation adds dependencies -- and by nature an SOA should be extensible beyond applications you may be able to dream up today. Moreover, in many SOAs, the source and target systems are business-critical and cannot be taken offline. Testing these systems can be a bit tricky, but must be comprehensive nonetheless.

Remember the people

SOAs are built and managed by people, so you need to consider the impact on humans as well as the impact on enterprise architecture. There are two places to focus: the SOA-literacy of the people building the SOA and the skill levels of the people who will be using the services and interfaces of the SOA.

Those tasked with building an SOA need to have a firm grasp of traditional enterprise architecture along with the ideas, approaches, and technology of SOA. For most organizations that’s a tall order. Outside consultants may be needed for mentoring at early stages, and internal training on approaches and tactics should be an ongoing affair.

Without this kind of support, chances are your people -- and the SOA itself -- will fail. Either hire the consultants necessary to seed the organization with knowledge, or, in some cases, hire new people who are suited for the execution of an SOA project. Not an easy decision, but it could save the project.

Finally, consider those who leverage the services, processes, data abstractions, and the resulting new visual applications. How will this change the way they do their jobs? How will you train them? How will you support them? How will you capture their suggestions for improvements? Better to answer these questions sooner rather than later.

Concentrate on the long term

An SOA is a long-term solution. Expect no measurable ROI in the short term. For most enterprises, the value will be understood in years, not months.

This can be a tough sell when you consider that most American businesses operate quarter to quarter, and budgets and objectives change monthly. Long-term projects such as SOA, which are both complex and systemic, are difficult if not impossible to maintain across time in some organizations. If your organization steadfastly resists a long term outlook, an SOA may not be for you.

The best advice is to get investment and commitment from the top of the organization, so you have the political clout to protect projects, and the bully pulpit to convince people of the long-term value and importance of SOA to the enterprise. Anything less will result in failure. If SOA is implemented as just another quick fix, it can layer even more complexity onto the enterprise technology infrastructure. Without a long-term commitment to SOA within the organization, even the simplest SOA project will have a slim chance of success.