While it's not often brought up (especially by vendors!) one of the advantages of SOA and Web services is that this allows enterprises to avoid vendor lock-in and control switching costs. This is the nature of widely adopted communication standards (look at what TCP/IP did to Novell even though, at the time, Novell had a far more complete solution) - the value of being able to grow the network effectively is far more valuable than any (temporary) technology advantage.
Given this, it surprises me how often I see organizations, without realizing it, giving up the benefit of the network effect by choosing proprietary technologies and platforms as the basis for an SOA strategy.
Most of the time, I find, people don't do this knowingly. They listen to the story of the vendor peppered with all the right words about the benefits of a single platform, how they are 100% standards compliant FINE PRINT: We're 100% standards compliant unless you actually use any of the important features of our solution, then you' must use our proprietary protocols. This is usually how it goes.
Why is this the case? Well, there are a lot of reasons:
It's easier for the vendor
It's cheaper for the vendor
It's quicker for the vendor
It provides more revenue for the vendor (by locking you in)
I'm not going to debate the merits of choosing best of breed products versus a complete suite from a single vendor - there are good and bad reasons either way. But, it's important to call out that there's a big difference between choosing a single vendor solution, and choosing a proprietary solution. While the switching costs of something like an app server platform are high, the effect is isolated. You don't need to rewrite your existing apps just to use a new app server for new apps. In contrast, proprietary SOA solutions (which are really just a form of middleware in this case) have much higher switching costs because they tightly couple consumers to providers. That is, if you wanted to switch your SOA solution provider you wouldn't be able to easily (or reliably, or securely, or at low cost) connect your new applications to your old ones. Such is the nature of a proprietary middleware solution. There's a reason Novell didn't beat TCP/IP, even though their complete solution was much stronger.
So, how do you make sure you don't get caught when selecting vendors - whether you go the single-vendor route or the best-of-breed route? Here's how to weed out issues during the evaluation process:
When looking at best-of-breed solutions, don't try and integrate them yourself. That's the job of the vendors - if the different vendors don't have integrations, make them commit to packaging and shipping an integration (not just a one-off for you). Note that many of the vendors already have prebuilt integrations. It's important that you actually evaluate this - have the vendors come in together and do their proof of concept together. Not only will you see how the products work together, but you will see how the teams work together. Also, don't assume that because the vendors are different companies that you need to do two contracts or have two support agreements. Many of the vendors are able to provide you with a single way to buy all the software together and a single point of support.
When you are looking at a single-vendor solution, here's the way you can determine if the solution is open or proprietary: As part of the evaluation of the solution require the vendor to swap out parts of their suite for those of other vendors to prove their standards compliance and openness. You want to test this in four ways:
Test with a consume that has none of their code on it
Test with a provider that has none of their code on it
If the vendor provides a central registry (such as UDDI) test with a different vendor's registry
If the vendor requires a central server in their architecture, test where the consumer and provider are connected to different central servers that, themselves, are not connected.
Doing these tests will expose the risks you face, the impact or cost of switching, or even the impact of bringing in a new platform or application that the vendor may not support (e.g. bringing in SAP NetWeaver).