Data maturity: from intention to evidence.

Capabilities need demonstration

Having a catalogue or lake does not prove maturity by itself. An organisation needs to understand how those capabilities contribute to its work. A useful starting point is to follow a real need from identifying the source to using the data.

Assess the whole journey

Observe how information is prepared, who defines quality, how access is decided and what happens when a version changes. A capability may be established in one team and depend on manual work elsewhere. Reading maturity in context avoids reducing an organisation to a single score.

Choose useful evidence

Products with named owners, reviewed contracts, decided requests and access revoked under agreed conditions are examples of evidence. Consumers matter too: can they find what they need, understand limitations and use the product?

Assess capabilities at the right scope

An organisation may operate a reliable financial product while another domain still depends on informal spreadsheets. A single score hides both the progress and the risk. Define the assessment scope: a domain, product, team or cross-domain journey. Distinguish the presence of a practice from its repeatability and reach. A process demonstrated once in a pilot needs further evidence before it can be described as an organisational capability.

Connect indicators to observable outcomes

Useful indicators might include time from a complete request to usable access, the share of actively used products with a named owner, recovery time after a failed update and preparation effort for a second consumer. Define the numerator, denominator, period and source for each measure. Counts without those definitions are easy to inflate. More catalogue entries may mean useful coverage, duplicate records or an inventory nobody uses.

Use evidence with its limitations attached

An audit trail can show that an approval occurred; it does not prove that the approved purpose was appropriate. A successful backup job does not prove that recovery meets a business need. Pair automated evidence with acceptance tests, consumer feedback and review by accountable people. Record missing or disabled capabilities explicitly. “Not measured” and “not applicable” are more useful than a green indicator whose underlying control never ran.

Create an improvement backlog with acceptance criteria

Choose a small capability gap connected to a priority outcome. Name an owner, define the evidence that would demonstrate improvement and set a review point. For example, the next consumer should be able to find a product, understand its limitations and obtain authorised access through the agreed path. This turns assessment into delivery work. Reassess after operating the improvement, and expand only when the practice can be sustained.

Improve without artificial leaps

Define the next capability and an observable acceptance criterion. Test it with a use case, review the process and expand when appropriate. This article offers an improvement perspective; it does not present a certified scale or replace formal assessment.

Questions to take into your next discussion

• Define the domain or journey being assessed.
• Separate implementation, operation and demonstrated outcomes.
• Document the calculation and limits of each indicator.
• Turn a gap into owned work with observable acceptance.