Canonical Data Model

  • Written By Govind Mulinti
  • 22/04/2015

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).

Canonical Data Model

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.

Canonical Data Model

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 marketing@whishworks.com

Other useful links:

WHISHWORKS Systems Integration

API Recipes with MuleSoft Anypoint Platform

Case studies 

Latest Insights

Blogs

Salesforce FSC-Customer and Prospect Data

Our new Salesforce Financial Services Cloud article discusses the ingestion of data into your org and the hydration of the platform.

Fintech Digital Transformation
Blogs

Fintechs in the Post-COVID Era

The shift to digital presents an opportunity for Fintechs to grow their portfolio exponentially, but it also comes with key challenges.

MuleSoft new tools and releases
Blogs

MuleSoft tools and releases to innovate faster

A closer look at some of the tools MuleSoft plans to launch to generate real efficiencies while freeing resources so users can innovate faster.