This article is the fifth in a series dedicated to the ESB integration architecture. The initial article is located here.

Canonical Models

In a preceding article, I talked about 3 limitations of a traditional integration:

1. Lack of scalability and fault tolerance.
2. There are no economies of scale.
3. Sender and receiver are tied by a contract.

In my previous article, I presented Publish-Subscribe asynchronous messaging as a way to alleviate limitation #2 by leveraging topics mechanisms in which multiple receivers can subscribe for the same message, effectively allowing economies of scale when having to disseminate the same information across different systems.

In this article, I am going to discuss how to untie senders and receivers at the data level (schema and content), through the use of Canonical Models.

Defining canonical models allows enterprises to create business objects that are independent from any specific application or system. The model contains all data points required to holistically describe a business entity (e.g. an order, invoice, order status, etc.) to connect to all systems/partners.

The use of canonical models solves limitation #3 by decoupling senders and receivers at the data level. A translator layer, sometimes referred to as Enterprise Layer, is created to handle the data exchange between systems and partners. In this layer, fields are standardized to match enterprise definitions rather than application-specific definitions.

Advantages

1. The data and data schema are independent from any specific application, facilitating a common understanding throughout the enterprise. For example, an e-Commerce site will have a different way to represent an account (different number, potentially different level of granularity) than an ERP, or a Customer MDM. Materializing the enterprise definition of an account into a canonical model helps alleviate ambiguity, miscommunication and errors of interpretation.
2. The transformation layer is centralized, allowing for better governance of changes. Also, this allows to create a central business rules engine that is application independent.
3. Total Cost of Ownership is reduced. This one could be controversial because another layer is added on top of existing applications, which adds cost. However, in my experience, enterprise systems tend to be COTS products (Commercial Off-The-Shelf, like ERPs for example) for which the cost of customizing can become quite high, especially when these customizations have to be carried through product upgrades. Moving customizations from a commercial product into a custom platform is a huge cost avoidance, in the long run.

Limitations

As an abstracted layer sitting on top of existing interface definitions, the use of canonical models brings additional complexity that may not be justifiable in all circumstances. Additional complexity in governance, architecture, implementation and maintenance. This complexity often translates in additional discussions, time spent and degradation of performance.

1. The use of canonical models require a greater level of coordination between development teams and a greater involvement from all parties involved, especially from enterprise architecture team. Not all IT teams are sized to support that.
2. Because it covers a larger set of requirements versus a data schema for a single interface, a canonical model tends to contain lots of optional attributes. Some of these could even refer to legacy systems that have been decommissioned and are unused.
3. Because of the additional step in mappings (source -> canonical -> destination), expect a slight degradation of performance in processing.

When to use

Canonical models are typically used for data definitions that require an additional level of governance. like customer data for example.

Domain Driven Design (DDD) recommends introducing the concept of bounded context to alleviate canonical model limitations. In a nutshell, and for our purpose, a canonical model is created for a reduced set of attributes that are common among different contexts. I recommend reading Eric Evan’s book Domain-Driven Design: Tackling Complexity in the Heart of Software for more information.

Conclusion

We reached the end of my series of articles dedicated to the ESB integration architecture.

As a conclusion, I would like to highlight that, like in a lot of other disciplines, there is no cookie cutter approach to integration. Every approach has its advantages and limitations. It is the architect’s role to weigh an approach versus another, and be pragmatic in their use, in order to deliver an integration that is optimized for the needs of an organization.

I hope you enjoyed these articles. If have any questions, feel free to leave a comment below or contact us here.