Figure 1 – Complex and brittle point to point integration
[source: Steve Nimmons]
This is a real ‘bread and butter’ Anti Pattern and has largely been resolved through evolutions of hub and spoke integration architectures (Figure 2), the Enterprise Service Bus, SOA and RESTful architecture. When connections between applications are ‘point to point’, integration is brittle and difficult to modify. Changes to an application have significant downstream impact on applications/systems with which it is integrated.
Figure 2 – Hub and Spoke Integration Architecture
[source: Steve Nimmons]
The Anti Pattern Codified
Anti Pattern Name [Point to Point / Tightly Coupled Integration.]
Type: [Technical / Integration.]
Problem: [Legacy application integration made significant use of the point-to-point Anti Pattern, largely due to the lack of maturity or availability of alternative integration technologies. As depicted in Figure 1, this integration style creates a mesh which is brittle and complex. Applications and systems are also tightly coupled in terms of awareness of integrated applications, and familiarity with integrated application APIs and data models.]
Context: [Legacy integration.]
Forces: [Lack of integration tooling (historical), cost of implementing hub and spoke integration architectures with high-end broker solutions (historical), failure to appreciate the downsides of point-to-point integration (largely historical).]
Resulting Context: [High cost of change, invasive integration, limited or no abstraction, applications responsible for translating data from other applications, no central audit or security functions, difficult systems to manage, monitor, scale, secure and troubleshoot.]
Solution(s): [Hub and spoke patterns, latterly the Enterprise Service Bus pattern (solving the integration mesh problem) and the Canonical Model pattern (solving the application data translation problem).]
This post uses the Anti Pattern template (with some modifications) from c2.com as its structural basis.
Recent Comments