Central vs. Decentral: One Size Does Not Fit All

By Greg Briscoe, Senior Solution Architect — Enterprise Data Management

 

The most common mistake in MDM program design is applying a single governance model uniformly across all data types. Customer data and chart of accounts data have almost nothing in common from a governance perspective so why would you govern them the same way?

I watch this mistake play out with disturbing regularity. An organization decides to “centralize master data governance,” stands up a corporate data governance team, and hands them responsibility for everything. The chart of accounts, customer master, product hierarchies, employee data, cost centers, vendor records, all of it. Within months the team is drowning. The chart of accounts governance works beautifully because it’s low-volume, high-control, and naturally centralized. The customer master governance is a disaster because it’s high-volume, distributed, and requires source-system expertise the corporate team doesn’t have.

The answer isn’t to choose between central and decentral. It’s to match the governance model to the data.

 

Different Data, Different Strategies

There are distinct requirements for the various types of master data being managed. Type of data, ownership of the data, and volume of maintenance is different therefore most organizations must engage in multiple strategies to effectively manage their master data.

Consider the differences:

Characteristic	Financial / Structural Data	Operational / Transactional Data
Change Volume	Low hundreds per year	High thousands per day
Ownership	Corporate finance / controllership	Business units / operational teams
Compliance Sensitivity	Very high SOX, statutory, regulatory	Moderate operational accuracy
Cross-System Impact	High structures feed every reporting layer	Moderate primarily source system
Natural Governance Model	Centralized control with limited delegation	Decentralized execution with central standards

 

Governing customer data the way you govern the chart of accounts creates an approval bottleneck that paralyzes sales operations. Governing the chart of accounts the way you govern customer data creates a free-for-all that introduces structural risk into every financial report. Both failures stem from the same mistake, assuming one model fits all data. You just can’t spread governance like peanut butter and expect it to stick.

 

The Operational Data Model

For operational data like customers, vendors, products, and employees, ownership and accountability must reside with the business owners of the source systems. These are high-volume, distributed data domains where the people closest to the data understand it best. A corporate team in headquarters cannot and should not be approving individual customer records created by a sales team in Singapore.

The right model for operational data: decentralized maintenance with central standards. The corporate governance team defines the rules naming conventions, required fields, validation logic, quality thresholds, but the business units execute the maintenance within their domains. Quality is enforced at the source through embedded business rules, not through central review of every record.

Fix at source, not downstream. Proactive versus reactive. These principles apply with particular force to operational data, where the volume makes centralized review impractical and the business context makes local expertise essential.

 

The Financial Data Model

For financial and analytical data chart of accounts, legal entities, consolidation hierarchies, reporting structures the governance model inverts. These are low-volume, high-impact data domains where every structural change affects financial reporting, compliance, and audit.

Corporate-level controls typically govern primary hierarchies like the chart of accounts a small compliance team at the corporate or divisional level owns the structure, approves changes, and ensures statutory and regulatory alignment. This is the data where centralization isn’t just appropriate; it’s mandatory.

But here’s the nuance most organizations miss: even within financial data, not everything should be centrally maintained. Most companies decentralize the maintenance of organization hierarchies due to their size and volume. A global organization with thousands of cost centers across dozens of business units cannot funnel every cost center change through a three-person corporate team. The key insight is that the size of the structure often dictates whether the data should be centrally managed or not.

 

Designing the Hybrid

The practical answer is a hybrid model: central governance for structural integrity combined with decentralized execution for volume and responsiveness. This isn’t a compromise, it’s an architecture. EDM Cloud supports both models within a single platform.

Configurable perspectives allow different teams to see and manage their scope without affecting other domains. Role-based security ensures that decentralized users can maintain their data without touching structures outside their authority. Domain-scoped ownership lets each data steward manage their domain within corporate-defined guardrails.

The result: the chart of accounts team at corporate controls the COA with the rigor that SOX demands, while the business unit teams across the globe maintain their cost center hierarchies with the speed that operations require all within a single governed platform, all with complete audit trails, all enforcing the same quality standards.

 

The governance model should fit the data, not the other way around. A single model for all master data types is a design error and it’s the reason most enterprise MDM programs either paralyze operations or fail to govern what matters most.

 

Next: Why your GL redesign is going to fail and the one thing that can save it.