Canonical Data Model

Often, people from various business units have different terms or abbreviations for the same concept, which may lead to an error during interpretation.

For example, the purchase order number can be denoted in several ways with different parameters and is also based on departments in the organization. Probably, they would be using codes like  PO No, PO ID, PO Code, etc.

This leads to multiple custom versions of “enterprise-wide” data models such as Product, Customer, Supplier etc. All models have redundant custom versions of “enterprise-wide” services and business vocabulary, which in turn leads to Point-to-Point connections that are calculated by n * (n-1).

Sometimes, these service contracts may express similar capabilities in different ways, leading to inconsistency and might result in misinterpretation.

An ideal solution for this problem is to have service contracts that are standardized with naming conventions. Naming conventions are applied to service contracts as part of formal analysis and design processes. The use of global naming conventions introduces enterprise-wide standards that need to be consistently used and enforced.

The Canonical Expression pattern, using Canonical Data Model (CDM) solves all the related problems.

The name CANON comes from a Greek and Latin meaning 'a rule' or 'standard'.

Canonical Data Model defines common architecture for messages exchanged between applications or components. The CDM defines business entities, attributes, associations and semantics relevant to specific domain.

"Canonical Data Model" is application independent.

Examples of some CDM's are: OAGIS, ACCORD, HL7, HR-XML.

The CDM shift simplifies the design as shown in the diagram below.

Benefits of the CDM shift are:

• Improve Business Communication through standardization
• Increase re-use of Software Components
• No. of possible connections is (n * 2) against n (n-1).
• Reduce transformations
• Reduce Integration Time and Cost

Few downsides while using CDM are

• CDM's are too generic (BIG in size) (Light versions might release in order to solve this problem)
• CDM usage might impact run-time performance
• In general, CDM's  do not contain business validations

By following CDM,  it allows us to design and implement reliable messaging patterns as well as to keep the modules related to the source system decoupled from the target system. By decoupling the module it enables us to create pluggable modules that are applicable to various source or target systems that can be switched easily whenever required.

MuleSoft ESB, as a decoupling middleware platform helps us leverage reliable messaging to make otherwise transient, fatal errors in a non-reliable transport recoverable. Mule is agnostic to the payload of message and the architecture of integration applications, that makes it easy to implement patterns like the canonical data model and decoupling middleware.

If you would like to find out more about how APIs could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com

Other useful links:

Coforge Systems Integration

API Recipes with MuleSoft Anypoint Platform

Case studies