Designing and Implementing Semantic Data Layers
Aligning meaning across systems is a perennial enterprise problem. Tools get added, systems diverge, abstraction layers are “optimized” for pressing use cases, and shortcuts are taken. And that’s before mergers, market pivots, and shifts in strategy.
The result is a growing collection of what different people and systems mean when they say “customer,” “department,” or “protocol.” David Wells offers a practical, actionable solution using semantic layers: “a systematic, architectural approach to making meaning explicit, consistent and durable” (121).
Key Concepts
- “Trust in data is not a sentiment. It’s a capability, and semantics is how you build it” (12).
- Separation of meaning from structure is crucial for building semantic layers that scale (21).
- Definitions are required: “A model without definitions is only a diagram. A model with definitions is a semantic artifact” (46).
- The hard work of aligning on definitions is organizational and interpersonal. “Getting subject matter experts to agree on a single definition of customer” is challenging, but necessary — and can make the difference between an initiative that succeeds and one that stalls (88).
- “A semantics-based architecture is not a single semantic layer [but rather a] deliberate network of semantic layers, each serving a specific purpose” (96).
- Start small; provide value at each stage: “Incremental delivery is not a compromise. It is the right strategy” (120).
Impressions
This is a brief book (122pp) packed with actionable ideas and strategies. Wells makes a convincing case for why semantic layers are more important now than ever, introduces the core concepts, then gets into the details of five kinds of semantic layers and their respective purposes. He then uses relatable use cases to illustrate how these layers are implemented across typical enterprise data systems.
A running theme is that you don’t create “a” semantic layer; you need an overlapping and interconnected set of layers that are designed and governed to achieve specific outcomes. Wells provides rubrics for choosing which types of layers are best suited for common outcomes.
Wells provides a brief introduction to semantic technology concepts, like RDF triples and ontologies, but if these are new concepts to you a more expansive introduction to the nuts and bolts of knowledge graphs might help you envision the practical applications more concretely. As Wells emphasizes throughout, however, the strategy he describes is “not a technology product. It’s a discipline, practiced through careful modeling, governed through clear ownership, and sustained through organizational commitment” (121).