We’re about six months into rolling out a semantic layer across finance, marketing, and supply chain after years of inconsistent metrics and everybody building their own definitions in whatever BI tool they prefer. Executive mandate was clear: single source of truth for key metrics like revenue, active customers, and margin. Implementation has been less clear.
The core dilemma we keep hitting is how much to centralize versus how much to federate. Finance wants strict, auditable, locked-down definitions. Marketing wants flexibility to slice customer segments and run experiments without waiting weeks for central approval. Supply chain is somewhere in the middle but keeps extending our shared product taxonomy in ways that break downstream dashboards. We’ve defined about fifteen enterprise-level metrics so far, but every domain team wants to add custom logic or carve out exceptions for their use cases.
Right now we’re treating the semantic layer as enterprise-managed with extensions allowed at the business unit level, but the boundaries are fuzzy and we’re spending a lot of time in meetings debating what belongs in core versus what should be a departmental extension. Curious how others have approached this trade-off – do you lock down the core tightly and push teams to justify exceptions, or do you start loose and tighten over time as patterns emerge? What governance structures actually work without turning into bureaucracy?
From the finance side I’ll say the biggest issue is trust. If marketing can tweak the definition of revenue to make their campaigns look better, then the number stops being useful for us. We’ve pushed hard for immutable core definitions with a formal change request process that requires cross-functional sign-off. Yes it’s slower but we can’t have different departments reporting different numbers to leadership. The compromise we reached was that extensions have to inherit from the core definition – so marketing can add filters or segments but the base calculation stays consistent.
What helped us was making the semantic definitions version-controlled and treating them like code. Every change goes through a pull request with required reviewers from impacted domains. Sounds heavy but it actually sped things up because people could see exactly what was changing and why, and we had an audit trail when discrepancies showed up later. We use dbt for our transformation layer so the semantic models live right next to the data models in the same repo. Finance and marketing still argue but at least the arguments happen in writing with context instead of in endless Zoom calls.
Governance structure matters as much as the technical architecture. We assigned each core metric a specific executive sponsor (CFO owns revenue and margin, CMO owns customer metrics, etc.) and made them accountable for resolving conflicts. When a business unit wants to extend or modify a core definition they have to get approval from the sponsor, not from IT or the data team. Shifted the conversation from technical feasibility to business trade-offs and made decisions happen faster because the sponsors have the authority to just decide and move on.
We’re in a similar spot with product taxonomies. Our issue is that categories that make sense for merchandising don’t align with how supply chain thinks about inventory or how finance rolls up margin by product line. Ended up creating a shared product hierarchy at the top level (enterprise semantic layer) and then allowing each domain to add their own classification dimensions as extensions. So a product has one canonical ID and core attributes, but supply chain can tag it with lead time category and finance can tag it with margin tier without those classifications polluting each other’s views. Not perfect but reduced a lot of the tension.
One thing that’s worked for us is clear SLOs around data quality and freshness for the core enterprise layer versus more relaxed standards for business unit extensions. Core metrics get automated testing, schema validation, and observability monitoring. Departmental stuff can be more experimental but it’s explicitly labeled as non-governed in the catalog and can’t be used in executive reporting. Helps manage expectations – people know what they can rely on versus what’s still being iterated.