One data model, many approaches to integration

The use of a common data model in SOA has been recommended in definitive posts - from the viewpoints of integration and of governance.  The common model architecture facilitates integration by providing a common ground for data transformation, and supports governance by bridging the business and implementation views of enterprise information.  When a common model is properly used, these principles generally apply regardless of the runtime environment.  But a common model supports several quite different styles of integration.  We could look at those integration styles as a kind of spectrum, with extremes at each end and a blend in between.

One end of the integration style spectrum is represented by what I call the common interface style.  OSS/J and MTOSI are examples of this style in the communications sector, and there are comparable examples in other sectors.  The common interface style promotes a universal, standard interface between applications.  It requires that all participating applications use the standard interface, reducing some common integration problems and costs.  The level of adoption of standardized interfaces varies among domains and among application vendors.  A common model can be used to implement adapters over non-compliant applications in order to conform to the standard interface.  Although the common model and its mappings may resemble a hub and spoke model at design time, the runtime view of this style typically requires that the adapters be highly distributed.

In contrast to the common interface style, the other end of the spectrum is what I call the data integration layer style.  Several OSS transformation projects are examples of this style.  It starts with each application as-is, and adapts their existing interfaces to a set of "canonical" interfaces based on a common data model that supports mapping between all participating applications.  It also adapts canonical interfaces back into application-specific ones.  This allows process management infrastructure to intercept and redirect canonical requests, providing access to business process that would otherwise have been hidden in (and locked into) the "wiring" between applications.  For this style, in contrast to the hub and spoke design view, the runtime view depends largely on the location of the mapping services, but it usually inserts process management between requesters and responders.

Other integration projects fall somewhere between the ends of the integration style spectrum, with a mix of adapters, canonical interfaces, and direct translation between applications.  It will be interesting to see how these and other styles evolve, as SOA best practices and SOA-supporting technology improve.