Where SOA Meets Cloud

Loraine Lawson wrote a compelling blog post: "Did SOA Deliver on Integration Promises?"   Great question.

"So did SOA solve integration? No. But then again, no one ever promised you that. As Neil observes, we'll probably never see a 'turnkey enterprise integration solution,' but that's probably a good thing - after all, organizations have different needs, and such a solution would require an Orwellian-level of standardization."

The fact of the matter is that SOA and integration are two different, but interrelated concepts.   SOA is a way of doing architecture, where integration may be a result of that architecture.   SOA does not set out to do integration, but it maybe a byproduct of SOA.   Confused yet?

Truth-be-told integration is a deliberate approach, not a byproduct.   Thus, you need to have an integration strategy and architecture that's a part of your SOA, and not just a desired outcome.     You'll never get there, trust me.  

The issue is that there are two architectural patterns at play here.   

First, is the objective to externalize both behavior and data as sets of services that can be configured and reconfigured into solutions.     That's at the heart of SOA, and the integration typically occurs within the composite applications and processes that are created from the services.

Second, is the objective to replicate information from source to target systems,  making sure that information is shared between disparate applications or complete systems, and that the semantics are managed.   This is the objective of integration, and was at the heart of the architectural pattern of EAI.

Clearly, integration is a deliberate action and thus has to be dealt with within architecture, including SOA.     Thus, SOA won't solve your integration problems; you have to address those directly.