"Unified data model" is used by data warehouses, customer data platforms, and master data management tools to describe three different architectures. All three are real improvements over disconnected systems. Only one of them removes the separate copies instead of reconciling them, and that distinction is what actually determines whether your CRM and your finance system can disagree with each other.
Three things people mean by "unified"
Unified for reporting
A data warehouse pulls records out of every source system into one place you can query together. This is genuinely useful for analytics, and it changes nothing about how the source systems operate day to day. CRM, finance, and HR still keep independent copies, and the warehouse is a read-only snapshot that goes stale between syncs.
Unified after reconciliation
Master data management tools build a "golden record" by comparing copies from multiple systems and resolving conflicts. This is closer to operational, since the golden record can feed back into source systems, but the source systems still each hold their own copy, and the reconciliation process is still catching drift after it happens rather than preventing it.
Unified at the operating layer
The third architecture removes the separate copies. CRM, finance, HR, payroll, and workflow read and write the same business entities directly, so there is no export, no sync job, and no reconciliation step between them, because there was never a second copy to reconcile against.
Key takeaway: The question that actually distinguishes these three approaches is how many places the same fact can be written. A warehouse and an MDM tool both still have more than one. An operating platform has exactly one.
What this looks like in practice
Infrakinetic's architecture rests on three decisions that build the third kind of unification specifically. Commercial, Finance, HR, Payroll, Documents, and Workflow operate on shared business entities instead of maintaining synchronized copies, so there is nothing to keep in sync. Catalogued business events, a deal won, an invoice paid, a candidate hired, trigger workflows and automations across engine boundaries directly, so a cross-team handoff is a subscription to an event, not an integration project. Operations that must succeed or fail together execute as one transaction: a won opportunity creates its deal, project, and order together, or none of them, rather than three separate writes that can partially fail and leave the record set inconsistent.
None of this makes the warehouse or MDM approach wrong. Both solve a real problem for teams that already have five separate systems and need to make them agree. The operating-layer approach solves a different problem: not making five systems agree, but not having five systems to begin with.
"Shared data model" and "shared database schema" are easy to conflate. See transactional integrity and tenant isolation, explained for how unifying data across engines and isolating data across tenants are enforced independently.