Lesson 4 — Select for Fit, Then Evolve
Start with the enterprise, not the model
To choose a structure, characterize: - centralized vs decentralized organization; - hierarchical vs flat culture; - how decisions are made and implemented; - how independent divisions or regions are; - organizational and domain complexity; - current maturity; - scalability needs; - high-value business priorities.
The question is not “Which model is most formal?” It is “Which model supplies the accountability and coordination we need without unnecessarily fighting the enterprise's operating reality?”
Design considerations from Chapter 16
A sound DMO design should: - begin from current-state assessment; - align to organization structure; - consider organizational and domain complexity/maturity; - scale as needs grow; - have executive sponsorship; - make leadership forums actual decision bodies; - use pilots/waves when useful; - focus first on high-value, high-impact data domains; - reuse workable structures and people; - reject one-size-fits-all design.
Common evolution pattern
A frequent pattern is:
Grassroots decentralized → add RACI/accountability → Network → identify synergies/economies of scale → Hybrid or Federated
This is an observed evolution pattern, not a rule that every company must follow.
External shocks
New regulation, market pressure, mergers, or similar forces may require faster maturation. When that happens, the organization should make the increased change burden visible and manage it proactively.
Exam traps
- Copying a famous company's structure without comparing culture and decision style.
- Treating centralized as universally superior.
- Treating the evolution path as mandatory.
- Adding layers simply to look mature.
- Ignoring local business-process knowledge when centralizing.
Source anchor: Chapter 16, pp. 527–528.