Thinking / System design· Part 6 of 10 in The assurance layer
Shared meaning matters more than a shared database
Independent systems can cooperate without sharing tables if they agree on identity, semantics and authority.
- Canonical Models
- Databases
- Integration
- System Design
17 August 2026
On this page
When several applications need to cooperate, a shared database can look like the simplest solution.
Put the common tables in one place.
Let every application read them.
The problem is that shared storage often becomes shared ownership.
And shared ownership can become no ownership at all.
Internal IDs are local facts
Suppose Programme Assurance contains:
ExplorationProject.id = 7
while Licence Management contains:
ExplorationProject.id = 23
There is no problem.
Those identifiers are implementation details inside separate databases.
The meaningful identifier is something like:
projectCode = RRC-01
Likewise:
tenementCode = EPM-10001
or:
targetCode = TGT-NORTH
Those are business identities.
They can cross application boundaries without requiring the databases to share internal keys.
Canonical does not have to mean centralised
The word “canonical” sometimes suggests one enormous master schema.
That is not necessary.
A canonical model can be much smaller.
It can simply define:
- what the entity means,
- which business key identifies it,
- which system owns particular attributes,
- and what minimum representation is exchanged.
For example:
Tenement
Canonical key:
tenementCode
Authoritative owner for:
- licence status,
- expiry date,
- compliance status:
Licence Management
Programme Assurance may keep a local copy of those fields because it needs them for risk and investor reporting.
But it should treat them as replicated information, not as its own authoritative record.
Local models should remain useful locally
This is why a shared physical Tenement table can become problematic.
Licence Management may need dozens of fields related to statutory obligations, renewals, conditions and approvals.
Programme Assurance may only need:
- tenement code,
- licence status,
- expiry date,
- compliance status.
Investment Screening may need:
- tenure availability,
- tenure risk,
- competitive status,
- area.
A single shared table becomes the union of every application’s concerns.
A better design is often:
shared identity, local representation.
Ownership matters more than replication
Data replication is not inherently a problem.
The problem is uncertainty about who is allowed to change what.
If Licence Management is the authority for complianceStatus, then Programme Assurance can safely carry a local copy as long as the ownership rule is clear.
This also creates a useful governance test:
Does the replicated value still agree with the authoritative value?
That question becomes important because events and integrations can fail silently.
APIs preserve application boundaries
If one application needs another application’s information, it should normally ask the application rather than reaching directly into its database.
That allows the owning system to preserve:
- validation,
- business rules,
- audit,
- permissions,
- schema versioning,
- and event generation.
It also means the underlying storage can change.
One application may use SQLite today and PostgreSQL tomorrow without forcing every consumer to change.
The contract is the interface, not the table.
Shared meaning enables mixed environments
This approach matters particularly in real operational environments because not every system will be generated by the same framework.
A suite may include:
- a new domain application,
- an existing ERP,
- a GIS platform,
- a laboratory system,
- a legacy database,
- spreadsheets,
- external web services.
Those systems will never share one schema.
They can still share a business vocabulary.
The next problem is movement
Once identity and ownership are explicit, the architecture becomes much cleaner.
But another question appears:
How does information move between the systems, and who checks that the movement produced the expected result?
Direct application-to-application links can work for a small number of systems.
As the number of systems grows, those links become harder to govern.
That is where an orchestrator begins to make sense.
Not because every system needs another layer of technology, but because some responsibilities belong neither inside one application nor inside another.
They belong in the relationship between them.