The world is rife with Data Management operating models. With Data Management being a such distinct and unique part of the data execution model, it seems like we are spoiled for choice with structures, interaction models, and consulting partners.

But why?

It’s usually tied to the character of the organization. Character can be simply defined as where the organization is in terms of:

• • Current data strategy
  • Maturity of the data landscape
  • Dependency on the data to make decisions
  • The influence the data has on the organization

This unique set of characteristics allows internal and external data professionals to carefully develop Data Management operating models that complement an organization’s data intent, which ultimately should focus on improving data quality. This is why we are spoiled for choice. There is (and should be!) an ever-growing demand to improve our data quality.

But What exactly is a Data Management operating model?

From my perspective, I would define it as an operational design of how an organization would structure itself around its characteristics in order to improve data quality. By operational, I mean something that works together with something else.

Too much?

Think of it as a blueprint of how you would want to manage your data in your organization.

Here’s a real example from a large corporate entity:

The example above provides some insight into how these Data Management operating models can be structured. The core operational design was to federate as much responsibility to the Business Units (BU), or the Data Domains. It focused on embedding ownership, roles, and responsibilities to the Data Domain owners while partnering with respective Subject Matter Experts (SME) departments during execution.

But this is one unique example. There are many types of Data Management operating models, but I can summarize into three distinct versions:

1. Federated

This empowers each of the BUs to run their own fit-for-purpose Data Management operating model as per the characteristics (requirements) for that BU.

• • The good: Clear accountability in the business, with direct responsivity for data quality
  • The bad: Potential to silo execution, with the risk of overlap/duplication across data domains
  • The ugly: Trying to consolidate data quality scores across data domains

2. Centralized

This is where a central team would run Data Management for the entire organization with size depending on the organizational need, with direct influence in each data domain.

• • The good: A central place to manage execution, increase transparency in delivery, align initiatives, avoid duplication, and optimize budgets
  • The bad: Teams are usually large, expensive and filled with resources that might not understand the business that well – proximity matters in more complicated/ diverse organizations.
  • The ugly: Potential battle of expenditure on budgets and consistent need to validate a Return on Investment (ROI) on a grey impact model of Data Management

3. Hybrid

This is a blended approach between a federated and centralized model that’s unique to the organization.

• • The good: Facilitates finding the mutual ground between the BUs and Data Management team in terms of execution, budget, and deliverables
  • The bad: Possibly a long process to come to an agreement with the various BUs as each will have their own requests
  • The ugly: Data quality will vary as the speed of execution will be determined by each data domain

This is all great, but which one is good for your organization?

If we knew that answer, the data world would be a better place. This is where domain experience, negotiation, and agreements on the operating model all come into place. The key trick from my experience is to get commitment from the top – senior buy-in. Go armed with the three options mentioned above and agree on the fit-for-purpose model for your organization. Clustering senior experience, with clear guidelines on the journey that will need to be followed, will gravitate the decision to the right model – at the end of the day, the entire organization will be part of this journey.

But is there a catch? Well, not really. If it doesn’t work, then make the adjustments, it’s not set in stone. Massage Agile ways of work into the execution and you will allow fast failure and quick adaption. The simple fact is: you will never trust your data if it started out as a lie.

Explore More

• • Modernizing Data Management
  • Data Management: The Loch Ness Monster or The Boogeyman?
  • Creating a Winning Cyberthreat/Ransomware Management Strategy
  • Building Digital Data Strategy, Architecture, and Infrastructure
  • Creating a Winning Data and Analytics Strategy
  • Steps to Making Data Your Greatest Asset
  • Handling Dark Data Perils
  • Have Enterprise Data and Analytics Programs Delivered on the Promise?