Integration glossary
Canonical data model
A canonical data model is one agreed definition of the business data that several systems share, such as a customer, an order or an asset, which each system is mapped to once.
The problem it solves
When systems are connected in pairs, every pair needs its own translation. Five systems can need up to ten of them and ten systems up to forty-five, each with its own idea of what a customer is and each written, tested and maintained separately.
A change in one system then ripples through every translation that touches it. Teams stop changing systems because they cannot predict what will break, and the integration estate becomes the reason a strategy waits.
How it works
The business agrees once what a customer, an order or an asset looks like: the fields, their meaning and how records are identified. Each system is then mapped to that shared definition instead of to every other system.
Adding a system means writing one new mapping. Reports and applications read the shared model, so they keep working when a source system is replaced, because only that system's mapping changes.
Designing a canonical model
A useful model grows from the records the business already argues about, rather than from an attempt to describe everything on day one.
-
Start with the few records that several systems share, usually customers, products and orders.
-
Name fields in business language, so people outside IT can read the model.
-
Record where every value came from, so a disagreement between systems can be traced.
-
Let the model grow as new systems join, instead of trying to finish it first.
The canonical model in STRAX
STRAX holds the agreed company data model at its hub. When you connect a system, the assistant proposes how its tables and fields line up with the model, explains its reasoning, and you decide. Every value in the hub records which system it came from.
The canonical model, in the documentation → How mappings are proposed and approved → The STRAX integration engine →
More terms
Other ideas worth knowing.
Two-way data synchronisation
Keeping the same record current in several systems, so an edit made in any one of them reaches the rest.
Read the definition →Self-hosted integration platform
Integration software that runs on your own servers, so the data moving between your systems stays under your control.
Read the definition →iPaaS (integration platform as a service)
Integration delivered as a cloud service, where the vendor hosts the platform that connects your applications.
Read the definition →See it on your own systems.
A demo takes about an hour and shows these ideas working on systems like yours.