A company wants Sales, Support, and Finance to use a shared view of customer information. The strategy promises more reliable reporting and less reconciliation. A governance policy names data owners, defines access requirements, and asks teams to maintain quality.
During implementation, Support needs information the approved role cannot access. A pipeline receives records with missing identifiers, and Finance discovers that a new customer-status field means something different from the one it replaces. The policy provides a starting point, but someone still needs to resolve each case.
Data strategy and governance address related work. Strategy identifies the capabilities and priorities worth investing in. Governance establishes how decisions about data are made, who is responsible, and which requirements apply. They become effective when those commitments reach the systems and processes people actually use.
Connecting Controls to the Intended Service
The shared customer view needs a specific purpose and a set of users. Support may need current account status, while Finance needs an auditable history for reconciliation. These uses can require different freshness, access, and quality conditions.
The programme should identify what each consumer needs and which requirements apply across the service. This helps distinguish a necessary control from an approval inherited from an unrelated process. It also makes the cost of operating the proposed arrangement visible.
An enterprise data strategy should include the transition from existing sources. The company needs to know which system controls each fact, how records are matched, and how disagreements are resolved while consumers move.
Governance can support that transition by making responsibility explicit. A data owner needs a route to change definitions, secure remediation capacity, and resolve disputes. Naming the role without those working arrangements leaves important decisions to whoever encounters the problem first.
Making Access Work Within Clear Boundaries
An access policy needs implementation in the systems that store, process, and export the information. The team should establish what each role can do and test whether legitimate users can complete their work within those permissions.
For Support, read access to selected customer fields may be sufficient. Other cases may require temporary access or specialist approval. A read-only copy can reduce the risk of changing production state while still exposing sensitive information, so the copy needs its own controls.
Routine requests may be suitable for automated approval within defined rules. Ambiguous or consequential uses can still require human judgment. The aim is a dependable path for authorised work, including a documented emergency route that records access and supports later review.
The company also needs to verify revocation, changes in role, and the permissions held by services. An approved access design can drift as people move and integrations expand. Logs and periodic checks help establish whether actual use remains within the intended boundary.
Deciding What Happens When Quality Checks Fail
Validation should follow the consequences of the data’s use. A missing identifier might prevent a reliable customer match and require quarantine before publication. An optional descriptive field might justify a warning while the rest of the record remains usable.
Rejecting every imperfect record can interrupt an important service. Accepting every record without qualification can expose consumers to misleading results. The pipeline needs an agreed response for relevant failures, with an owner for remediation and a way to communicate limitations.
The Government Data Quality Framework emphasises data that is fit for its purpose. A schema check contributes to that assessment without establishing that every business fact is correct. A valid date can still be the wrong date, and a populated identifier can still refer to the wrong customer.
Some checks therefore belong at ingestion, others during transformation or before a dataset is used for a particular decision. The design should make it clear which data is approved for use, which is awaiting investigation, and how corrections reach downstream consumers.
Managing Changes in Structure and Meaning
Schema versioning can help producers and consumers evolve at different times. Compatibility checks can identify certain changes that would prevent one version from reading another, depending on the format and configuration. Confluent’s compatibility guidance explains how those checks depend on the selected mode and version history.
The checks do not settle every business change. A status field can retain its type while changing meaning, and a new identifier may have no reliable mapping to historical records. Translation requires an explicit rule where one is possible, with a plan for cases where information has been lost or interpretation has changed.
For the customer view, Finance should validate the proposed status definition and resulting reports before the old field is removed. The change plan needs consumer owners, an agreed transition period, and evidence that important uses have moved.
Deprecation remains an organisational decision as well as a technical task. A registry cannot authorise a team to stop supporting an interface that another department still requires. Clear decision rights provide a way to resolve that conflict and accept the remaining consequences.
Maintaining Useful Metadata and Lineage
A catalogue can help users find a dataset and understand its purpose, owner, definitions, and limitations. Automated collection can reduce manual work, but its coverage depends on supported sources, permissions, integrations, and scan behaviour.
Microsoft’s documentation on Power BI lineage in Purview describes source-specific collection and limitations. The company should assess what its own tooling captures rather than assuming a technical map represents every spreadsheet, export, or manual step.
Lineage describes how information moves and changes. Access logs provide different evidence about who used it. Both can support an investigation, but neither alone guarantees a complete audit trail or detects every unauthorised use.
Business metadata also needs an accountable maintainer. Permissions may indicate who can access a dataset without identifying who can approve its definition. Users need a way to report stale descriptions and obtain clarification, especially when technical structure remains unchanged while its business interpretation evolves.
Reviewing Whether the Controls Achieve Their Purpose
Governance should be assessed through operating evidence. Can authorised staff obtain the information they need? Are material quality failures detected and resolved? Do schema changes preserve required uses? Can access be removed when it is no longer justified?
Violation counts need context. A rise may reflect improved detection or a larger workload; a low count may reflect missing visibility. Reviews should consider control coverage, testing, severity, response time, and unresolved exceptions alongside the totals.
Some responses may require platform changes, while others need revised policy, clearer ownership, or training. Automation is valuable for repeatable rules, but it depends on people making and maintaining appropriate decisions about those rules.
For this company, governance has reached production when Support can work within defined access, Finance can trust the relevant records, and teams know how to manage a defect or change. The strategy then has an operating foundation that can be checked and revised as the service develops.
