In looking at the source and target systems that make up the application integration problem domain, you should always consider an integration alternative that, generally, comes down to one of two choices – coupling or cohesion.

As I'm exposed more to integration projects, I'm seeing two patterns of failure. First, the ability to recognize the problem itself and thus understand the solution, and selecting the improper enabling technology and products. In other words, people are leveraging services as a point of integration where information is the proper choice, or leveraging information exchange when services interfaces are indicated.

Understanding these concepts is becoming more important as we move into more service-oriented solutions, including SOAs. It boils down to savvy architects who are able to analyze the problem domains and apply the proper solution patterns, and the appropriate enabling technology.

While many believe this is more art than science, I have to disagree. It's really a matter of understanding the requirements and applying the logical solution.

Coupling

Coupling, in the context of application integration, is the binding of applications together in such a way that they are dependent on each other, sharing the same methods, interfaces, and perhaps data. This is the core notion of service-oriented application integration, where the applications are bound by shared services, versus the simple exchange of information.

At first glance, coupling may seem like the perfect idea. However, you should not lose sight of what it really requires – the tight binding of one application domain to the next. As a consequence of this requirement, all coupled source and target systems will have to be extensively changed to couple them (in most cases).

Further, as events and circumstances evolve over time, any change to any source or target system demands a corresponding change to the coupled systems as well. Coupling creates one system out of many, with each tightly dependent upon the other. Service-oriented application integration clearly leverages coupling in how applications are bound together.

Of course, the degree of coupling that occurs is really dependent on the SOA architect, and how he or she binds source and target systems together. In some instances, systems are tightly coupled, meaning they are dependent on each other. In other instance, they are loosely coupled, meaning that they are more independent. It matters not if you're doing this through Web services or other mechanisms, you're typically going to have to make these architectural tradeoffs within the notion of coupling.