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.

Relevant when

The board gets different figures for the same thing from two departments and has no way of knowing which to trust
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

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

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.

Does this sound familiar?

Where do things stand for you? The first conversation costs nothing and usually leaves the question clearer, whether or not it leads to a project.

Get in touch