Canonical Data Model

22.04.2015

Often, people from various business units have different terms or abbreviations for the same concept, which may lead to an error while 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).

p2p

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.

cdm-shift1

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 plugable modules that are applicable to various source or target systems that can be switched easily when ever 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 

Topics

ESB Mule ESB SOA

Recent Posts