The Service Provider Role
Where integration requirements can be supported by COTS services and the applications to be integrated are capable of consuming such services, they should do so. Service-based interfaces are likely to represent the most robust, longest-lived interface approach. The loosely coupled nature of these interfaces will also make integration based on these interfaces more flexible in the face of application upgrades to either the COTS application or the applications to which it is integrated.

Where a COTS application has relevant integration points but does not have a service presentation capability, an ESB may allow a COTS application to still play the role of a service provider. Where a COTS application doesn't have relevant outbound integration points, you must compromise requirements, develop a workaround, or take on the unsavory task of modifying the COTS code. This last option can be realized in-house, by the vendor, or even a third party, but it defeats some of the advantages of a COTS strategy and many IT organizations are therefore reticent to pursue it.

The Service Consumer Role
The consumption of services by a COTS application will hinge primarily on two factors. First, does the vendor provide the capability to exercise services at the required integration points? Second, do these services exist in the applications to which the COTS application needs to integrate? As in the service provider scenario, where these stars align, a services-based approach is a good strategy. Moreover, to the extent that these integration requirements are present and the COTS applications can consume services, this can actually drive build requirements for new development or legacy modifications. That is, if you are going to build or modify an interface anyway, you might as well present it as a service when the calling application can consume it as such.

When the COTS application has a relevant integration point but does not have a service consumption capability, you can consider an ESB service consumption strategy. For example, many COTS applications have proprietary inbound interfaces - say, based on interface tables - that can be managed via an external agent such as an ESB.

When a COTS application doesn't have needed inbound integration points, these requirements can be addressed with approaches similar to those employed when a COTS application doesn't have desired outbound integration points.

Legacy Applications - Wrapper's Delight?
The fact of the matter is, it's often not any easier to meet legacy integration requirements with services than it is with any other integration approach. Sometimes we are considering applications whose designers never contemplated such requirements. The fundamental architecture of the application may impose obstacles to integration based on underlying data models or processing assumptions. Or, there can be an impedance mismatch with the typical service-based request-reply integration pattern and the native integration mechanism of the application.
This is why the frequently offered suggestion that you can just "wrap" legacy systems with services and be on your way is a hoax.

The Service Provider Role
For presenting services, you need, first and foremost, to expose the appropriate integration point. To the extent that existing systems have object-oriented foundations or their designers considered similar requirements, you may have an easier time of it; that is, if you happen to have the appropriate interface already exposed in a service-like manner, converting it to conform to Web Service standards may not be too challenging. You can even leverage an ESB to do much of the work. However, where this is not the case, plenty of heavy lifting may be required.

Unlike a COTS scenario though, it's perfectly reasonable to take an invasive approach to add service-based interfaces to legacy applications. That is, modifying the application to provide relevant integration points may be perfectly feasible. It's just important to recognize that building services is a more significant undertaking than simply service-enabling existing outbound interfaces.

The Service Consumer Role
As far as legacy applications invoking services go, there are three considerations. First, this approach is only worth considering where relevant services are present. Then, you need to consider the capability of the legacy application to technically consume these services, again typically Web Services. This capability is often based on the development toolset and/or runtime environment of the legacy application. Finally, you have the same basic application architecture issues involved with presenting services. That is, can you crack open the legacy application in such a manner that it can take advantage of any services that might be available? When relevant legacy consumption integration points exist, an ESB can often be layered on top of them to invoke services where they are present.

If these integration points aren't present, as with service provisioning, you may need to modify the application directly.

New Development - The Final Frontier
While new development may be increasingly rare in many IT shops, when it occurs, you have ultimate control since these applications are effectively "under construction" as requirements are captured.

The Service Provider Role
The recommendation for service presentation would be to take the same approach that most COTS vendors are taking - use Web Services. One caveat though is that while IT professionals are adept at abstracting and generalizing functionality for known requirements, you can't predictably build reuse beyond this point because any additional requirements are, well, unknown. No technology or architecture will address this issue. Technology like those based on Web Services standards will allow for integration to unanticipated platforms, but not in unanticipated patterns or for unanticipated purposes.

The Service Consumer Role
The extent to which new applications can consume Web Services will make them easier to integrate as time marches on. This is because the integration mechanisms of the systems to which these new applications will need to integrate should be moving towards Web Services standards themselves. So where complementary services exist, this should be the integration strategy. Moreover, even if the applications with which you need to integrate use non-service-based approaches, it can still make sense to build service-based interfaces and then implement them using an ESB. That way, you have a migration path towards a future, more fully service-enabled integration world.

Again, this advantage is only at the platform level, not the application behavior level. Still, the good news is that since you're building from scratch, just as with the presentation of services, you can insert the application integration points in the appropriate location and craft them to follow appropriate integration patterns.

Also, while you don't need an ESB to service-enable integration points that you are building as services, you may still want to leverage other useful ESB features such as orchestration or processes monitoring. By the way, this last point applies to COTS and legacy application models as well.

I Hear New Trends a Comin', They're Rollin' Round the Bend
One final note on an ESB is that it also supports a co-existence strategy along the road to full application portfolio service-enablement. That is, you are never going to be able to "flip the switch" on an SOA for all your applications en masse. So you're going to need a way for your new service-enabled applications to co-exist with the traditional integration architectures of applications waiting in the wings for their service-enablement makeover.

Besides, even though this may be a noble goal, it may not be practicable or justified. Therefore a co-existence strategy is going to be a requirement for the foreseeable future, especially because as far as integration innovations go, this is just the latest. As soon as you get close to your SOA utopia, the target will move. Some other clever strategy will be bandied about there promising the next quantum leap in IT effectiveness. An ESB can then provide a bridge between your SOA-based application set and whatever comes next.

Let's Go Servin' Now, Everybody's Learning How
These are the three faces of SOA: COTS, legacy, and new development. By recognizing these faces and the approaches they imply, you can deliver a more effective SOA. You can elevate your SOA from an application construction tactic to an enterprise application integration strategy, with a commensurate elevation in returns. And in the end, that's probably what your CIO wants anyway.