A canonical model is more than a data harmonisation artefact. It’s the foundation for movement. From Entity change through Canonical event to reaction in a unified way.
Previous Posts in this series
The Static Model Problem
Most canonical models stop at structure. They define the “what ” the entities, attributes, and relationships, but not the “when” or “why“. Effectively they become a reference, a static truth, instead of a living heartbeat across the enterprise.
Yet the business world is anything but static. Customers merge, suppliers get acquired, ownerships shift, opportunities materialise, and compliance rules evolve. Every one of these events is a signal. If your canonical model remains passive, those signals fade before they reach the people and processes that could act on them.
triggering on change, Turning change into Events
Triggering begins when a canonical model starts to emit change. Instead of just storing that “Company A now owns Subsidiary B,” the model announces it: “An ownership relation has changed. This may affect compliance, spend, and account management.”
These signals, or events, become the connective tissue of a responsive enterprise.
When a canonical entity changes, it can trigger:
- A credit re-evaluation in finance
- A supplier re-assessment in procurement
- A new opportunity mapping in sales
- An alert to compliance if the new parent company appears on a sanctions list
Each of these happens not because someone manually checked a report, but because the canonical model published an event describing the change.
Introducing “The Canonical Event Schema”
The need to introduce action based on change, calls for a parallel construct, the canonical event schema. Whats needed to be done here is similar to defining common entities such as Company, Person, and Site, common event types has to be defined:
EntityCreatedEntityMergedEntityOwnershipChangedIdentifierUpdatedEntityDeactivated
Very central to this concept is that every event carries meta data aiming to ensure uniformity, in order to provide insight and liniage to where event originates from. E.g the origin is important if it is SAP, CRM, or a third-party source, every consumer across the organisation can interpret it without translation.
- A unique event ID
- A timestamp
- The canonical entity ID(s) involved
- A payload describing before and after values
- Optional context such as the source system, reason, and affected business domains
A call for an Architectural Shift: From Integration to Publication
Traditional integrations are pull-based where system A asks system B for updates.
In a triggered architecture, the flow is push-based where system B announces a change and subscribers decide how to act. The canonical model has to become the central publisher, not the central database.
This subtle shift reduces dependency coupling and unlocks agility. Instead of hundreds of point-to-point integrations, you establish one publishing layer where canonical events are emitted and multiple consumers subscribe – marketing, finance, compliance, and analytics alike.
The integration no longer happens between systems; it happens through meaning.
Governance in Motion
Triggering does not replace governance, it activates it. When a canonical model emits events, it exposes the quality of your data governance in real time.
If an event triggers unnecessary noise or downstream errors, it is a governance signal. It tells that an entity was not ready, a mapping was unclear, or ownership was unsettled. Good triggering therefore requires strong entity stewardship, clear lifecycle states, and validated identifiers.
The canonical model must know when an entity is safe to announce. Governance defines who decides; triggering ensures the right things happen when they do.
Building the Trigger Layer
The key principle is simple: the canonical model is the authoritative vocabulary, while the trigger layer carries that vocabulary in motion.
Business Examples
- Finance detects that several subsidiaries now roll up under a new global parent. It triggers spend consolidation and risk recalculation.
- Sales sees that a newly merged customer opens cross-selling potential and automatically flags the account manager.
- Compliance receives a “ParentEntityChanged” event that cascades sanction screening across all subsidiaries.
- Procurement is notified when a vendor’s tax identifier changes, automatically queuing a review in the vendor management portal.
These scenarios are all powered by the same simple premise:
“Entity change → Canonical event → Business reaction.”
From Insight to Action, closing thoughts
Once events are flowing, analytics can move from reporting to anticipation. I find it very interesting to correlate which events tend to precede revenue shifts, risk escalations, or operational friction. Perhaps this foundation for automation is something to pickup on in a future blog 🙂
Leave a Reply