In an earlier piece on the 2026 data mandate, I the EU AI Act, the Cyber Resilience Act, and the Data Act are pushing organizations for structural mandates to transition from reactive compliance towards a systemic Governance-by-Design. However, translating this architectural intent into daily business operations introduces a practical bottleneck: once the governance controls are embedded by design, how does an organization measure their effectiveness?
Having worked in environments where governance operates across dozens of products rather than hundreds, I spent time mapping how the operating model changes as a portfolio grows. The transition is not linear. What works cleanly at small scale starts breaking at mid-scale, and at enterprise scale it fails entirely. The insight that resolved the tension was not about individual products at all. It was about the domain. In business, a domain refers to a specific area of expertise, responsibility, or focus, such as Finance, HR, Procurement, etc. A common failure mode observed across enterprise programs is treating individual products as the primary unit of analysis, rather than the broader domain that encompasses them.
The Default Operating Model: Continuous Triage
A majority of enterprises already operate formal governance programs. Yet structural existence does not guarantee operational health. Gartner research warns that up to 80% of data and analytics governance initiatives are projected to fail, often because they treat governance reactively rather than connecting it to scalable business outcomes.
The execution gap is visible in the tooling. Data from industry assessments published on Talenode confirms that this execution gap traces back to operational bottlenecks, noting that approximately 53% of data governance teams still rely on manual processes like ticketing systems and spreadsheets to handle policy enforcement. The result is a default operating model that follows a recognizable pattern.
Consider a governance team managing 60 data products across five business domains. Each sprint, stewards work through a queue: evaluate a product, check metadata completeness, flag a missing RBAC configuration, log an action item, move to the next. The governance council agenda becomes a running ledger of individual product tickets. The conversation stays reactive: which product is blocked, which is nearly certified, which has stalled across organizational boundaries.
This micro-level activity satisfies a compliance checklist. It does not scale a governance program. The cumulative cost is significant: roughly 45% of data professionals report burnout, with energy consumed by isolated friction rather than structural improvement. At 60 products it is manageable. At 200, it becomes the full-time job. At 500, it stops working entirely. It is triage without a strategy.
Product-Level Isolation vs. Domain-Level Patterns
When governance operates exclusively at the product level, structural patterns within the organisation remain hidden. Product-by-product resolution addresses localised symptoms rather than root architectural causes.
Consider the same problem viewed through two different lenses:
The Product Lens: Five data products across three business domains all present with missing RBAC (Role-Based Access Control) configurations. A product-level view surfaces five independent, isolated failures assigned to five different stewards.
The Domain Lens: Aggregating those views reveals that RBAC deployment is failing uniformly across multiple environments. That is not a stewardship issue. It is an infrastructure failure.
This distinction becomes tangible when governance standards are applied across multiple business functions simultaneously. For example, defining metadata standards across domains will show you something that the product-level review consistently misses: the same gaps appear independently across teams with no shared ownership, no shared tooling, and no awareness of each other’s problems. Missing ownership labels, undocumented access models, inconsistent naming conventions – these surface repeatedly in each function as if they are separate failures. They are not. They are one failure expressed four times.
The domain lens collapses those four separate conversations into one. Fix the standard once, at the right level, and the correction propagates across every function it touches.
For resource allocation decisions, the domain is the correct unit of analysis and not the individual product.
Surfacing Patterns with a Domain Maturity Heatmap
One structured approach for making these architectural dependencies visible is a Domain Maturity Heatmap: a grid mapping business domains (rows) against defined governance pillars (columns), where each cell shows the percentage of products in that domain currently passing a specific compliance gate.
The model avoids composite scores and subjective averages, focusing on binary control validation. Either a domain has a control working, or it does not.
When an enterprise estate is visualised through this grid, two structural realities typically emerge.
Compounding Stability: Mature domains display consistent compliance across columns. Historical investment and explicit ownership have consolidated into repeatable engineering practices. The green cells cluster together because the foundations were built deliberately.
Columnar Clustering: In developing domains, failures rarely occur at random. Non-compliance clusters within specific pillars across entirely separate domains. In the example above, Lineage and RBAC are red for both HR and Procurement simultaneously. These are not HR problems or Procurement problems. They are organisation-wide infrastructure gaps surfacing in two places at once.
That clustering is the primary diagnostic signal. If data lineage is non-compliant across multiple business units at the same time, it points to pipeline design defects, tooling limitations, or systemic policy ambiguity, not to individual steward performance.
Redefining the Governance Resource Allocation Question
Shifting the analytical focus from individual products to domain pillars changes how leadership evaluates where to deploy resources.
If automated lineage tracking is failing across six business units, assigning six stewards to map pipelines manually is an inefficient use of both time and budget. The systemic approach requires engaging the core data platform team to identify why the metadata harvesting tools are failing to produce complete traces. Resolving it at the platform layer corrects compliance status across all dependent domains at once.
Conversely, if a single domain is non-compliant across nearly every pillar, that signals a foundational maturity deficit: ownership is unclear, standards have not been applied, and products in that domain are not close to certification. The required intervention is a dedicated domain uplift program to establish basic data ownership and standards. In practice, it could be something like:
- First – establishing clear data ownership so every product has an accountable human
- Second – applying baseline metadata and documentation standards before any certification gates are enforced
- Third – running a lightweight readiness assessment to understand which controls are genuinely missing versus simply undocumented.
Once the foundation exists, then the product-level certification become a productive exercise.
The Question Worth Asking Before Every Governance Council Meeting
Before reviewing any individual product status or project backlog, there is one question worth asking first:
“Which governance pillars are failing across multiple domains?”
A pillar failing across multiple domains deserves the council’s attention before any individual product does. Prioritising a systemic pillar failure over a product-level backlog ensures that the governance function acts as an infrastructure investment rather than a quality control gate. It shifts the operating model from resolving a reactive queue to establishing the technical conditions under which entire domains can scale and comply organically.
What the Heatmap Does Not Tell You
The domain view identifies where a system is failing. It does not explain why. A domain reporting low compliance on data lineage could be driven by several distinct root causes:
- The automated ingestion tools are disconnected from the domain’s pipelines.
- The underlying data architecture is non-standard, preventing automated metadata harvesting.
- Data ownership roles have not been formally assigned within that business unit.
The percentage looks identical in each scenario. Consider two domains both showing 15% on lineage. In one, the tooling is simply not connected – a one-day fix. In the other, no one has mapped the data flows because ownership was never established – a weeks-long program of work. The Heatmap does not distinguish between them. A specialist needs to.
What it replaces is the subjective agenda. Council meetings where no one agrees on which domain to prioritise, or which controls matter most this quarter. With a domain maturity view, everyone in the room is working from the same objective picture of the enterprise data estate before the first product is even discussed.
Governance as Infrastructure
Product-level governance is necessary. It is not sufficient. The programs that mature and scale fastest under the pressure of modern regulation are not the ones reviewing the highest volume of individual tickets. They are the ones that step back, look at the domain-level patterns, fix the systemic architectural gaps first, and watch product-level metrics improve as a natural consequence.
Before you go…
Follow me so you don’t miss any new posts I write in future; you will find more of my articles on my profile page. You can also connect with me on LinkedIn or X!