Service
Data and information architecture
One agreed picture of the organisation's core information, and a route to it that does not require replacing everything.
The problem
The same customer, citizen or asset exists in three systems. Each system is right about something. Nothing says which system is right about what.
When two departments give the board different numbers for the same measure, that is what you are seeing. It is not a reporting error.
The usual response is to buy a platform. Warehouse, lakehouse, fabric or mesh, depending on the year. That solves movement and storage but not agreement, and agreement was the problem. A year later the new platform is in production and the two departments still have their own numbers.
The other reason to fix the vocabulary is newer. An agent works with the terms it is given. Where the same concept is named three ways across three systems, the inconsistency does not produce an error; it produces a guess, and the guess looks like an answer.
How I work this
Domain model in UML
The core entities and their real relationships, set out so that business people and developers read the same thing from the same picture. Conceptual first, logical after.
System of record per entity
Which system is authoritative for which entity, which fields are exceptions, how conflicts resolve and how data flows. This is a decision rather than a discovery, and it needs an owner.
One vocabulary
An agreed definition of core terms, usable by people, by reports and by agents. It is the single cheapest action available for improving the quality of AI answers in the organisation.
Governance inside the architecture
Ownership assigned to a named role, quality expectations stated per entity, lineage that can be shown to a regulator. Not an annexe to a policy document.
The platform last
Once entities, ownership and flow are settled, the platform question becomes answerable and is usually simpler than feared. For European and public sector clients this includes residency, sovereignty and the practical consequences of GDPR.
What you get
- Conceptual and logical domain models in UML, agreed across business units
- Master data strategy: system of record per entity, ownership, survivorship rules and flow
- A single agreed vocabulary for core entities, usable by people, reports and agents
- Integration architecture and patterns to standardise on, with the anti-patterns named
- Data governance operating model: ownership, stewardship, quality measures, lineage
- Assessment of residency, sovereignty and GDPR consequences for the structure
- Platform recommendation with cost and lock-in stated plainly
Get in touch when
- Two departments present different numbers for the same measure
- A data platform has been bought and is not producing the promised unification
- Analytics or AI work is blocked on trust in the underlying data
- Reporting obligations, regulatory or public, are met by manual reconciliation
- A merger or acquisition has left two systems of record for the same entity
Scope
Data estate assessment
Three to six weeks. Which systems hold what, where the conflicts are, what needs deciding.
Domain model and master data strategy
Six to twelve weeks for the organisation's core entities.
Governance and platform selection
Four to eight weeks on top of the domain model.
Related
The vocabulary and ownership established here are a precondition for AI and agent readiness. The entities trace back to the processes in Enterprise architecture and process.
Does this sound familiar?
Tell us briefly where you are. The first conversation costs nothing and usually leaves the question clearer than it was, whether or not this results in a project.
Get in touch