The key problem to solve is to make many services, some you own and some perhaps you don’t own, work and play well together. The objective here is to leverage many services, and do so in a manner that makes them appear like a single application. Albeit the services could be running anywhere, in and outside of your organization. In short, making many appear as one.

Okay, now that we know what the problem is, how do we solve it?

You need to remember that this is largely an architectural problem, and not something you can toss products and standards at. Indeed, you need to define the capabilities of your SOA based on the requirements of the domain, and back the appropriate solution set (standards, tools, technologies) into it. For instance, too many fine grained services and all of the technology and standards in the world won’t help you.

What’s key here, at least from an architectural perspective, is that you make the right calls in terms of what services are going to make up your SOA supporting critical business events. This is where most SOAs go off track, typically attempting to bind too many services, and at the wrong granularity. You can consider services that make up your SOA like links in a chain, each defining the reliability and performance.

Having stated that obvious problem, there are techniques, technologies, and standards that you can apply that provide your SOA with better capabilities to manage a loosely coupled and distributed SOA. Although they are just getting off the ground, I believe they are some of the most important emerging capabilities.