C01-potential-at-work

Can canonical design solve your point-to-point integration complexity?

A hairball of point-to-point integrations isn't just an IT maintenance headache—it's bad for the business. With a canonical approach, enterprise architects can begin untangling the hairball and minimize the impact of change.  

canonical-design-point-to-point-integration_ar_ed1_656x370

By understanding best practices, starting small and taking a disciplined approach, the canonical model is a sound step towards untangling the integration hairball.

Point-to-point integration across applications isn’t necessarily bad. If you have a few applications to integrate, the point-to-point approach is fast, simple and inexpensive. The problem is that enterprises don’t have a few applications. They have hundreds, each with dozens of interfaces.

It amounts to the proverbial hairball that increasingly is the bane of IT and business, driving up project costs by demanding that enterprise architects and developers reinvent the wheel each time with another point-to-point integration. As the hairball becomes more tangled, maintenance costs soar.

Architects generally agree that the hairball is an anti-pattern with many undesirable characteristics, yet it’s prevalent in most corporate IT environments. And, as IT budgets tighten, CIOs look to enterprise architects to reduce complexity and costs and improve business and IT agility.

Many IT organizations are taking the first step in declaring an end to point-to-point integrations in favor of a hub-and-spoke model suited for standardization and reusability based on a canonical data model, a design pattern to communicate between different data formats.

Canonical Best Practices

With a canonical approach, each application translates its data into a common format understandable to all applications; this loosely coupled pattern minimizes the impact of change. In contrast, the point-to-point approach of converting data from the format of one application to another means that a change in one application propagates across others, introducing brittleness and inflexibility.

The canonical approach isn’t new, nor is it a cure-all. Yet by understanding best practices, starting small and taking a disciplined approach, the canonical model is a sound step towards untangling the integration hairball. Enterprise architects need to understand four canonical model techniques and determine which best fits their projects.

Canonical data modeling, for custom-built applications, data warehouses or MDM solutions, eliminates the need to transform data as it moves within the confines of the system because it has the same definition everywhere. For example, the data entity “average account balance” has the same definition in all data warehouse tables using it.

Canonical interchange modeling, a technique for lean and agile data mapping analysis and design, uses a logical data model and business glossary tailored to a specific industry (banking, telecom, insurance) or business domain (finance, HR, manufacturing, sales).

Canonical physical formats, for extreme loose coupling such as in a B2B context. The canonical object is a “message”—often XML, but any standard including flat files will work. The key is that the message definition be relatively stable and include a specific business process context.

Canonical business objects, for passing complex objects in a serialized fashion between applications, such as an invoice object passed across order entry, fulfillment, delivery and invoicing. A modern solution to this is dynamic Data Services as implemented in Informatica’s integration platform.

Want to learn more? Join the discussion on LinkedIn.

Related content

edition-7-arch-architecting-for-big-data-en-656x365_0001.jpg

Architecting for big data

The Internet of Things produces data at rates beyond human comprehension. It may also overwhelm your data environment.

architect-your-way-from-sluggish-to-speed_ar_ed1_656x370.jpg

Can you architect your way from sluggishness to speed?

Infrastructure complexity and poor coordination across teams are slowing some IT functions to a crawl. Enterprise architects should consider Lean Integration as a framework to architect for speed and agility while minimizing waste.

integration-hairball_ar_ed1_656x370.jpg

Whose fault is the integration hairball? Your chance to be a hairball hero

The integration hairball might be no one’s fault in particular—but it’s everybody’s problem. Enterprise architects are in an ideal position to move the enterprise from a mess of point-to-point integrations towards a more strategic architecture.