When people ask me what data management looks like in large organizations, I usually start by reframing the question. Most organizations think about data management as something you build, a capability, a platform, or a set of tools. But I’ve always seen it differently.

To me, a data management process is a discipline, much like finance, operations, or supply chain. 

That distinction matters. If you treat data management like a project, the mindset becomes: build it and move on. There’s a start, a finish, and then you’re done.

But data doesn’t work that way. It’s constantly evolving, being created, consumed, and transformed. If you don’t operationalize how it’s managed, you end up with something fragile, something that degrades the moment the project team walks away. At enterprise scale, that simply doesn’t hold.

So, how to get data management right?

Begin by redefining scale. It is one of those words that gets thrown around a lot, but is rarely defined. For me, operating at scale is about repeatability and sustainability.

You are not solving a problem once; instead, you’re solving it in a way that can be replicated across the organization, consistently and efficiently. 

This is what allows organizations to reduce duplication, accelerate onboarding of new use cases, and maintain consistency across business units without reinventing the same solution repeatedly.

And that requires a combination of three things:

• People with domain expertise
• Well-defined processes and procedures
• Automation that amplifies both

Let’s break that down.

How to build a flexible and accountable data foundation

When you’re building data management practices from scratch, the first decisions you make matter a lot. They set the tone for everything that follows.

One of the earliest and most important guardrails I’ve used is defining data domains. You break the organization’s data into subject areas such as customer, product, finance, and so on, and then identify the critical data elements within each domain.

But the real value comes from assigning owners. We mapped subject matter experts to those domains. This created immediate accountability: every data element had an owner aligned to a domain, not a system. 

That distinction was important because the same data often exists across multiple systems, but it should only belong to one domain to avoid confusion.

If someone believes a data element belongs in their domain, they take ownership. If there’s disagreement, it gets resolved through dialogue, not mandates. 

That flexibility is important because data doesn’t always fit neatly into predefined boxes. You need room for interpretation and adjustment. 

Ownership is based on expertise and consensus, not rigid enforcement. This openness makes the model more practical and sustainable.

Another principle I’ve leaned on heavily is risk-based decision-making.

A lot of organizations chase “best practices,” but that can be a trap. Best practice is often expensive, time-consuming, and sometimes unnecessary. Instead, I ask: What is the risk of not doing this? What is the benefit of doing this?

If the risk is high, we invest accordingly. If it’s low, we may accept it and move on. That approach keeps things pragmatic and aligned with business realities.

And then there’s the idea of a Minimum Viable Product (MVP). You don’t need perfection on day one. You need something that works, something that mitigates risk to an acceptable level and delivers value. From there, you iterate, improve, and evolve.

That combination, flexibility, risk-based thinking, and incremental progress, creates momentum. And momentum is what keeps data governance from becoming a bottleneck.

How to turn data management into a repeatable business process

At enterprise scale, data management must operate as a disciplined, repeatable process. That shift in mindset is critical. 

Most organizations tend to focus on building capabilities, tools, platforms, and solutions, without fully thinking through how those capabilities will be sustained and operationalized over time. The result is often fragmented efforts that deliver short-term value but fail to scale.

In practice, this shows up as conflicting definitions, duplicated pipelines, and teams spending more time reconciling data than using it.

Instead, data management needs to be treated like any other core business function, governed by clearly defined processes, risks, and controls. 

Every process inherently carries risk. In the absence of structure, those risks manifest as confusion, inconsistent data usage, and ultimately flawed decision-making. 

Well-defined processes and procedures act as the control layer, ensuring that data is consistently understood, trusted, and used correctly across the organization.

Take data governance as an example. It is not just a set of tools or committees, but a structured program that outlines how data is defined, where it resides, how its quality is assessed, and how its lineage is traced. 

Without this clarity, organizations cannot reliably audit decisions, explain outcomes, or meet regulatory expectations.

These are not one-time activities; they are ongoing processes that require clarity in execution. People need to understand what needs to be done, why it matters, and how to do it effectively.

This is where procedures become essential. They translate high-level processes into actionable steps: how to define a data element, how to measure its quality, how to track its movement across systems. Without this level of clarity, scaling becomes impossible because execution varies from one team to another.

At the same time, processes alone are not enough. They must be supported by capabilities and automation. Subject matter experts provide context, and judgment, but automation enables consistency and reach. Together, this combination creates a system that is not only scalable but sustainable too.

How to use metadata to improve data quality, context, and trust

If there’s one thing I consider essential to data management at scale, it’s metadata. It defines what the data is, where it resides, how it arrived, its quality, and who owns it. 

In short, metadata provides the context that transforms raw data into something usable. It is what allows organizations to trust what they are seeing, reuse what has already been built, and automate decisions without constant manual intervention.

I often use a simple analogy. Imagine walking into a supermarket where nothing is labeled. No aisle signs, no product names, no expiration dates. You see a white powder on a shelf, what is it? Salt? Sugar? Or rat poison?

That’s what operating without metadata feels like. You might recognize some things by sight, but you don’t know their origin, their quality, or whether they’re safe to use. And at scale, that uncertainty becomes a major risk.

Metadata solves that problem. It provides the labeling, the context and enables automation. When your processes are driven by metadata, rather than hardcoded logic, they become flexible and resilient. If something changes in the environment, the process adapts. It doesn’t break.

But here’s the challenge: many organizations don’t think of metadata as a control. They see it as a nice-to-have or as a standalone project that’s hard to justify. Without a clear articulation of value, such as risk reduction, productivity gains, or revenue opportunities, it becomes difficult to secure buy-in.

Part of the challenge is that metadata itself is often misunderstood. There are three key types: business, technical, and operational.

• Business metadata, things like definitions and terminology, is particularly difficult because it requires organizational alignment. 
• Technical metadata, which describes data structures and systems, is more common but often incomplete. Developers typically don’t prioritize documentation, so definitions can be vague or overly simplistic. This leads to confusion when similar fields exist across systems but mean different things.
• Operational metadata, such as logs and events, is generally more mature due to cybersecurity needs. However, it often exists in isolation and isn’t well-connected to business or technical metadata.

Ultimately, metadata maturity isn’t just about having these elements, but it’s about how well they are integrated. When they are connected, organizations can unlock powerful capabilities like data orchestration, automation, and more effective use of generative AI. That’s where the real opportunity lies.

Using AI for data management

There’s a lot of excitement around AI right now, especially when it comes to data management. And I get it; the promises are compelling. But I think it’s important to ground that promise in reality.

At the end of the day, AI is just another capability. It’s powerful, but it still needs to support a process that delivers value. 

Take something as simple as data definitions. In many organizations, technologists create tables with dozens of columns, but the descriptions are either missing or unhelpful. You end up with field names that don’t really tell you anything.

Could you force people to write better definitions? Maybe. But that’s not always practical. This is where AI can help. Generative AI can take a basic field name like “DOB” and enrich it into something meaningful, “date of birth of the policyholder,” for example. 

It can add context, clarity, and consistency. And when you scale that across thousands of data elements, the impact is significant.

But here’s the catch: AI only works well if the foundational processes are in place. For instance, if your data isn’t defined, if your metadata is incomplete, if your governance processes are weak, AI doesn’t fix that. It amplifies it.

So when vendors promise things like “business users can query data in plain language,” they’re not wrong. That future is achievable. But it depends on having the right groundwork: clear definitions, strong metadata, and robust processes. Without that, the promise falls apart.

Make progress over perfection in data management

If there’s one theme that runs through all of this, it’s the idea of progress over perfection. Data management is not about getting everything right the first time. It’s about building something that works, delivers value, and can be improved over time.

You measure effectiveness: Are you meeting your goals? Are you reducing risk? Are you enabling better decisions?

If the answer is yes, then you’re on the right track. From there, it’s about continuous improvement. It’s about making things more efficient, more scalable, more impactful. It’s not about chasing perfection, but closing the gaps that matter most.

Because at enterprise scale, perfection isn’t just unrealistic, it’s unnecessary. What matters is clarity, consistency, and the ability to adapt.

And when you get that right, you don’t just manage data, you make it work for the business. And that is ultimately the difference between organizations that experiment with data and those that operate with it.

Key takeaways

• Run data management as a process, not a project: Sustainable impact comes from how data is operated day-to-day, not what gets built once.
• Define domains, not systems: Organize data around business domains and assign ownership there to avoid duplication and confusion across systems.
• Assign ownership with context, not control: Let domain experts own data based on understanding, not hierarchy or enforcement.
• Prioritize risk over best practice: Focus effort where the risk is real instead of chasing idealized standards that don’t scale.
• Start with minimum viable controls: Build just enough structure to reduce risk and enable progress, then iterate.
• Standardize processes, then operationalize them: Clear procedures turn governance into repeatable execution, not interpretation.
• Use metadata as the control layer: Context, lineage, and definitions make data usable, trustworthy, and scalable across the enterprise.
• Treat AI as an amplifier, not a fix: Strong processes and metadata make AI valuable; weak foundations make it dangerous at scale.  

About this series

This article is part of a CDO Magazine series co-created with seasoned data leader Justin Heller, exploring how to make the Chief Data Officer role durable, effective, and embedded within the enterprise. The series covers:

• Succeeding as a Long-Term Chief Data Officer: Turning a temporary mandate into an institutional function, building trust across the leadership table, and evolving from transformation leader to operating executive.

• Creating Data Management Processes at Enterprise Scale: Moving from ad hoc fixes to standardized, scalable operating models embedded into business workflows.

• What to Base a Data Governance Program On: Shifting from tool-driven governance to principle-based frameworks grounded in risk, accountability, and decision rights.

• How to Make the Organization Actually Use Your Data Program: Overcoming resistance, aligning incentives, and ensuring governance is both effective and unobtrusive.

• Leading Through Technology Waves: Navigating shifts from big data to cloud to AI while maintaining a consistent operating foundation.

• Becoming and Growing as a Long-Term CDO in an AI-Driven World: Building the skills, mindset, and adaptability required to succeed and stay relevant as the role evolves.

About Justin Heller: 

Justin Heller is a seasoned financial services executive and former, longest tenured Chief Data Officer with more than 30 years of experience helping organizations succeed through data strategy, governance, and risk management. He is widely recognized for guiding institutions in strengthening data governance, advancing AI adoption, and enhancing regulatory, privacy, and risk frameworks, including work with G-SIB, D-SIB, and other systemically important financial institutions.

A respected voice in the industry, Heller has spoken at leading conferences and forums such as FIMA USA, CDAO Financial Services, and CDO Magazine, as well as numerous webinars, addressing topics including data governance, artificial intelligence, risk management, privacy, and data minimization. He also holds multiple patents related to data management and innovation in enterprise data practices.

His areas of expertise include financial services, AI and data strategy, data governance, regulatory compliance, risk management, and privacy.