A semantic layer fails the moment somebody renames a department. That is the most uncomfortable observation I have to make to clients who have spent the last year building one. The layer they built is not a semantic layer. It is a SQL aliasing layer that happens to live in a different file. The difference shows up the first time the organisation reorganises.
What the layer is supposed to be
A semantic layer is a stable contract between the data warehouse and everything that consumes it. It defines the business concepts that the organisation cares about. Customer. Order. Active subscription. Trailing twelve months revenue. It defines how each of those concepts is measured. And it does so in a way that survives changes in the underlying tables, in the warehouse vendor, and in the organisational structure of the business that consumes it.
The contract part is the part most teams underbuild. They write a metric definition. They do not write the principles under which the metric will and will not be changed. They do not write the ownership model. They do not write the deprecation procedure. So the metric drifts, and the layer fails its purpose.
The reorg test
The way to test whether your semantic layer is real is to imagine a reorganisation. The marketing team gets renamed to brand and demand. The underwriting team gets split into commercial and personal. Two product lines get merged. Three business units get combined under a new senior vice president.
If your semantic layer breaks under that reorganisation, the layer is not actually semantic. It is structural. It encoded the organisation chart of the day it was built. A reorg exposes that. The metrics that were tied to a department name become wrong. The dashboards built on top of those metrics have to be rebuilt. The trust the layer was supposed to provide collapses.
Designing for survival
The principles I have arrived at, after rebuilding semantic layers in three different organisations, are these.
First, business concepts are defined in terms of business events, not in terms of the team that owns them. An active customer is a customer who has done X in the last Y. It is not a customer in the book of the such-and-such team. The moment you put a team name in a metric definition, you have hard-coded an organisational fact that will change.
Second, the layer carries dimensions for organisational context, but it does not embed organisational context inside the metric. Revenue is revenue. The team that owns the revenue is a dimension. When the team gets renamed or split, the dimension is updated. The metric does not move.
Third, every concept has a single owner whose name is in the file, with a deputy. Ownership transfers when somebody leaves or moves. The layer never has orphan concepts. Orphan concepts are how layers die.
Fourth, the deprecation procedure is documented. A concept is not deleted. It is marked deprecated, with a successor identified, and a window during which both versions are available. Consumers migrate during the window. After the window, the deprecated concept is removed.
The political work
Most of what I have written above is technical. The harder part of building a semantic layer that survives is political. You have to get the senior leaders of the consuming functions to agree, in writing, that the layer is the source of truth. Once that is agreed, dashboards built outside the layer are treated as exploratory and not as canonical. Decisions made on numbers that did not come through the layer are challenged. The layer becomes the standard.
Without that political agreement, the layer becomes another artefact in the organisation, competing with the analyst's ad-hoc query and the executive assistant's spreadsheet. With the political agreement, the layer becomes infrastructure. That distinction is the difference between a semantic layer that delivers what was promised and one that becomes a sunk cost the team is afraid to admit to.