← Back to sections

Data Strategy

How the organisation defines its data strategy and translates strategic enterprise data goals into measurable domain value, priorities, and investment decisions.

STR-01

Alignment of domain priorities to strategic goals

To what extent are the data management priorities in your specific domain (the datasets, quality issues, and access requests you handle) explicitly aligned with the organisation's strategic data goals, rather than driven by ad hoc requests?

Maturity level descriptions
  1. Domain priorities are driven entirely by whoever asks loudest or most recently; no connection to strategic goals. Work is queued and actioned in the order requests arrive, with no prioritisation framework referencing strategic value.
  2. Some informal sense of "important" datasets or issues exists, loosely connected to perceived business importance, but not formally tied to strategy. Data Engineer has an informal mental model of which datasets matter most, based on experience, but no documented prioritisation criteria exist.
  3. A documented prioritisation framework exists for the domain, referencing strategic goals, even if applied inconsistently. A prioritisation matrix, scoring rubric, or similar artefact exists and is used for major decisions, with clear (if not perfectly consistent) linkage to named strategic goals.
  4. Domain priorities are consistently and measurably aligned to strategic goals, with alignment tracked as part of regular reporting. Data Engineer's domain backlog/priority list is reviewed against strategic goals on a defined cadence, with a tracked alignment metric (e.g. % of active work items mapped to a strategic goal).
  5. Domain prioritisation is dynamically optimised against strategic goals, with trade-offs between competing strategic priorities actively and transparently managed at domain level. Data Engineer participates in structured trade-off decisions when strategic goals compete for the same domain resources, with decisions and rationale documented and available for audit.
Current maturity (As-Is)
Target maturity (To-Be)

STR-02

Periodic maturity assessment, target-state documentation, and progress monitoring

How regularly and rigorously does your domain assess its own data maturity, document a target state and the gap to close, and track progress against that gap over time?

Maturity level descriptions
  1. Maturity is never formally assessed; there is no documented target state and no concept of "gap" to close. Any sense of how mature the domain's data practices are is purely anecdotal, based on individual opinion, and never written down or compared against a defined target.
  2. Maturity has been assessed at least once (e.g. a one-off audit or workshop), but it is not repeated, and any target state or gap identified is not actively tracked afterward. Data Engineer recalls a single assessment exercise (internal or external) that produced a snapshot of current-state maturity, but nothing was done with the results afterward.
  3. A defined process exists for periodic assessment (e.g. annual), producing a documented as-is score, a documented target state, and an identified gap for the domain. Data Engineer participates in a scheduled assessment cycle using a consistent method (e.g. DataPulse or an equivalent CMM-based instrument), with results captured in a shared, accessible document.
  4. Assessments are conducted on a regular, enforced cadence; gaps are translated into tracked improvement actions/workstreams with owners and timelines, and progress is reviewed on schedule. Data Engineer's domain has an active improvement plan derived directly from the gap analysis, with named owners, target dates, and a defined review checkpoint (e.g. quarterly) where progress is formally checked against the plan.
  5. Maturity assessment, target-state definition, and progress monitoring form a continuous, embedded cycle; trend data across multiple assessment periods actively informs domain planning and is visible to relevant stakeholders in near real time. Data Engineer's domain maintains a maturity trend view (current vs. prior assessments), uses it proactively to reprioritise work, and assessment/target-state updates happen dynamically as circumstances change rather than only on a fixed calendar.
Current maturity (As-Is)
Target maturity (To-Be)

STR-03

Strategic clarity on AI/GenAI use of domain data

How clearly does your organisation's data strategy define which of your domain's datasets are intended for use in AI/GenAI initiatives, for what purposes, and under what constraints?

Maturity level descriptions
  1. No strategic direction exists on AI/GenAI use of data; datasets get pulled into AI initiatives (including shadow use with public GenAI tools) with no reference to any stated intent or constraint. Data is used in AI experiments or GenAI tools opportunistically, by whoever has access, with no strategic guidance on what is or isn't appropriate.
  2. General awareness exists that "AI is a priority," but no specific guidance connects that intent to which domain datasets are in scope or the constraints that apply. Data Engineer has heard AI/GenAI described as a strategic priority in general terms but has received no dataset-level guidance on use or restrictions.
  3. Strategy documentation identifies, at a domain or dataset-category level, which data is approved for AI/GenAI use and states baseline constraints (e.g. no PII into public tools). Data Engineer has access to a written list or classification indicating which domain datasets are AI/GenAI-approved and what baseline restrictions apply.
  4. Dataset-level AI/GenAI suitability and constraints are formally reviewed and updated on a regular cycle, aligned to specific named AI/GenAI use cases and their risk profiles. Data Engineer participates in a periodic review connecting specific domain datasets to specific approved AI/GenAI use cases, with constraints tailored to each use case's risk level.
  5. AI/GenAI data strategy is dynamic: as new use cases emerge or models/tools change, dataset approval and constraints are reassessed and communicated to Data Engineers proactively and rapidly. Data Engineer is notified of AI/GenAI strategy changes affecting their domain as they happen, with dataset approval status updated in near-real-time rather than on a fixed cycle.
Current maturity (As-Is)
Target maturity (To-Be)

STR-04

Domain data readiness for AI/GenAI consumption

How well does your domain's data currently meet the quality, documentation, labelling, and access-control standards required for responsible use in AI/GenAI systems (training, fine-tuning, retrieval-augmented generation, or prompting)?

Maturity level descriptions
  1. No assessment has been made of whether domain data meets AI/GenAI-specific requirements (quality, lineage, bias, licensing, sensitive-data handling); readiness is unknown. Data is used in AI/GenAI contexts, if at all, without any check against AI-specific readiness criteria such as representativeness, currency, or embedded PII.
  2. Some awareness exists of gaps (e.g. "our data probably isn't clean enough" or "we're not sure about licensing"), but nothing has been formally evaluated or documented. Data Engineer has an informal sense of likely readiness problems but has not conducted or requested a structured evaluation.
  3. A structured readiness check has been performed for at least priority datasets, covering defined criteria (quality, documentation completeness, sensitive-data flags, licensing/provenance). Data Engineer has run, or had run on their behalf, a documented readiness checklist against AI/GenAI-specific criteria for the domain's priority datasets.
  4. Readiness is systematically tracked across the domain's datasets, with identified gaps assigned as remediation actions and progress monitored against defined AI/GenAI data-quality thresholds. Data Engineer maintains or contributes to a tracked register of AI/GenAI readiness status per dataset, with remediation actions owned and progressed against thresholds (e.g. minimum completeness, bias-testing status).
  5. AI/GenAI readiness is continuously monitored and enforced automatically (e.g. data quality gates, automated PII/sensitive-data scanning, licensing checks) before data can flow into AI/GenAI pipelines or tools. Automated controls prevent or flag data that fails AI/GenAI readiness criteria from being used in AI pipelines, RAG systems, or GenAI tool integrations, without relying on manual checks.
Current maturity (As-Is)
Target maturity (To-Be)