Context
In an enterprise data environment shaped over many years, data flows cross several generations of technology and organisational boundaries. Batch processing, integrations, databases, data warehouses and reports operate side by side, often under different development and operational practices.
Individual technical processes may work while the full data journey remains invisible. A concept can carry different meanings in different places, ownership of data-quality problems may be unclear, and incident resolution can depend heavily on personal experience.
In this environment, Data Governance and Data Operations are not separate initiatives. One defines what the data means and who is responsible for it; the other ensures that the processes around it operate predictably.
Governance becomes a real capability when daily operation makes it clear who is responsible, why, and for which state.
The architectural question
The central question was how to embed principles and responsibilities into data operations so that they became an executable and verifiable system rather than a separate body of documentation.
This required shared answers to several questions:
- what constitutes a data flow and where its boundaries lie;
- which business concepts and data products it serves;
- who acts as business owner, data steward and technical operator;
- which quality, freshness and availability expectations apply;
- how origin and lineage can be traced across processing stages;
- what happens in the event of an incident, change or release;
- and how operation can become auditable without creating disproportionate administration.
The result had to support both professional governance and day-to-day technical operation.
Constraints
The operating model had to fit a regulated environment handling personal and business-sensitive data. Several conditions shaped the design:
- continuously operating, business-critical data processing;
- coexistence of legacy and distributed technologies;
- divided responsibilities across multiple internal and external teams;
- data flows with different levels of documentation and maturity;
- strict access, change-management and audit requirements;
- continuity of existing services throughout the transformation;
- and the need to avoid dependency on one large organisational change.
Governance could not add unnecessary operational weight. Only information and controls with a clear purpose and owner belonged in the model.
Approach
The data flow as the shared unit of operation
The first step was to establish a consistent definition of a data flow. A data flow is more than a technical job or interface: it is a process running from source to published data product, with responsibilities and expectations attached.
Each important flow received the same minimum description: business purpose, inputs and outputs, owners, dependencies, processing schedule, quality rules, service expectations, error handling and recovery.
Technical operation, metadata and responsibility could therefore refer to the same object.
Responsibility as a role rather than a person’s name
The duties of business owner, data steward, technical owner and operator were clearly separated. Decision rights, tasks and escalation points were attached to the roles.
Operation no longer depended solely on the implicit knowledge of individuals. The responsibility model remained understandable through organisational or personnel changes.
Shared feedback between governance and operations
Quality rules, freshness expectations and lineage did not exist only in a catalogue. They connected to execution monitoring, incident handling, changes and releases.
An error was therefore more than a technical alert. It became possible to see which business data was affected, who should receive the escalation, which downstream uses were exposed and under what conditions the flow could be considered restored.
The operating model
The model connected governance and operation through four related layers:
- 01Business concepts, owners and expectations
- 02Metadata, lineage and quality rules
- 03Orchestration, observability and runbooks
- 04Incident, change and release management
The business layer defined meaning, value and responsibility. The metadata layer described where data resided, where it came from and which rules applied. The operations layer executed and observed the processes, while service management controlled incidents, changes and releases.
Shared identifiers and states connected the layers. A business term could be traced to the process that produced it, the current state of that process and any related incident or change.
Key decisions
Governance is not a tool implementation
Data catalogues, quality controls and observability are important technical capabilities, but they do not define responsibility or decision rights by themselves. The operating model came first; suitable tools could then be aligned with its roles and processes.
Metadata as a by-product of work
Documentation maintained only by hand quickly diverges from actual operation. Where possible, technical metadata, runtime states and lineage information are generated automatically. Manual maintenance focuses on business meaning, responsibility and rationale.
Business and technical data quality remain separate but connected
The arrival of a file or successful completion of a process does not prove that the data is fit for business use. Technical checks and business rules received distinct ownership while meeting in shared status and escalation.
Rollout driven by risk
Not every data flow requires the same depth of control at the same time. The first scope covered business-critical, audit-sensitive or repeatedly failing flows. The patterns established there could then expand progressively across the environment.
Outcome
The resulting operating model created a shared language for business data owners, developers, operators and service management.
- Data flows received explicit purpose, ownership and technical responsibility.
- Metadata, lineage and quality expectations became part of daily operation.
- The business impact of an incident became traceable alongside its technical processing path.
- Runbooks, escalations and recovery steps reduced dependence on individual knowledge.
- Changes and releases gained a verifiable link to the data flows they affected.
- A phased rollout allowed governance maturity to increase while existing services continued to operate.
The result was not a separate governance layer above operations. Governance became a property of the way operations worked.
Lessons learned
The lasting value of Data Governance is not demonstrated by the number of policies produced or objects held in a catalogue. What matters is whether a data problem quickly reveals what it affects, who can decide, how it can be resolved and when the data can be trusted again.
When concepts, responsibilities, quality rules and operational processes describe the same data journey, governance does not slow operation down. It makes it more understandable, predictable and sustainable.