Thinking / System design· Part 5 of 10 in The assurance layer
One application should not have to understand everything
Related business questions do not automatically belong in the same application. Boundaries can improve clarity, ownership and implementation.
- System Design
- Applications
- Architecture
- Exploration
17 August 2026
On this page
A common response to connected business problems is to put them into one system.
There is a certain logic to that.
If projects, tenements, targets, budgets and decisions are related, why not place them in one application and one database?
Sometimes that is the right answer.
Sometimes it creates a system that understands too much.
Three questions, three operating contexts
Consider three exploration questions.
Where should capital go, and why?
That is an investment screening problem.
It requires jurisdiction data, public geological information, opportunity ranking, target hypotheses, information gaps and an initial investment gate.
Is committed capital being used effectively, and what are we learning?
That is a programme assurance problem.
It requires budgets, campaigns, evidence, uncertainty, decision gates, risks and investor visibility.
Are we meeting the obligations required to retain the right to explore?
That is a licence and work programme problem.
It requires tenure, statutory obligations, expenditure commitments, submissions, approvals, variations, renewals and regulator correspondence.
The three contexts share projects and tenements.
They do not necessarily share the same users, workflows, permissions or operating rhythms.
Shared entities do not imply shared applications
A project may appear in all three systems.
That does not mean all three systems should store the same representation of the project.
Investment screening may care about:
- jurisdiction,
- commodity,
- opportunity score,
- information risk,
- cost to reach a drill decision.
Programme assurance may care about:
- approved budget,
- capital spent,
- programme progress,
- confidence,
- next decision gate.
Licence management may care about:
- tenure,
- compliance manager,
- obligations,
- statutory deadlines.
Trying to force every requirement into one shared Project model gradually produces a domain object that belongs to nobody.
Application boundaries create ownership
A useful boundary answers:
Which system is responsible for this question?
For example:
Licence Management owns licence compliance.
Programme Assurance owns programme learning and capital assurance.
Investment Screening owns pre-investment opportunity evaluation.
That ownership helps when data conflicts.
If two systems disagree about complianceStatus, there should be an authoritative source.
Without ownership, integration becomes a negotiation between competing copies.
Smaller applications can also be easier to deploy
Not every customer needs the entire suite.
An exploration fund may care deeply about screening and investor assurance but not want to run statutory tenement administration.
An operator may already have strong tenure systems but want better programme assurance.
A jurisdictional or advisory organisation may use screening without operating the exploration programme itself.
Focused applications make those deployments possible.
They also reduce the pressure to replace established systems simply to obtain one missing capability.
The danger is fragmentation
Splitting applications is not automatically good architecture.
If every function becomes a separate service, the organisation can end up with dozens of small systems connected by brittle integration.
The boundary should therefore follow a coherent business question, not a desire to make everything modular.
Drilling, assay progress, programme risk and decision gates belong naturally together in programme assurance because they collectively answer the same question.
They should not be split merely because they could be.
The real requirement is shared meaning
Once applications are separated, they still need to agree on key concepts.
A tenement in one system must be recognisable as the same tenement in another.
A project should retain the same business identity.
A target carried from screening into programme assurance should preserve its lineage.
This creates a distinction between:
sharing a database
and:
sharing meaning.
The first is an implementation choice.
The second is an architectural requirement.
That distinction becomes important when independent applications need to work together without losing their boundaries.
It leads to the next question:
If each application owns its own data, how do the systems agree on identity and authority without returning to one shared database?