Semantic Layers are an important design framework for connecting information across an organization in preparation for Enterprise AI and Knowledge Intelligence. But with every new technology and framework, interest in utilizing the technological advance outpaces experience in effective implementation. As awareness of the importance of a semantic layer grows, and the market is becoming saturated with products, it is crucial to clearly distinguish between what is and is not a semantic layer. This distinction helps identify architectures that provide the full benefits of a semantic layer–such as aggregating structured and unstructured data with business context and understanding–versus more general data fabrics and semantic applications that may only provide some of its benefits.

To draw this distinction, it’s essential to understand the components that make up a semantic layer and how they connect, as well as the core capabilities and design requirements. 

A Semantic Layer is not

• One vendor 
• A metrics layer
• A TMS, LMS, or CMS

No one application is a semantic layer; a semantic layer is a framework for design. This article will focus on summarizing the requirements of the semantic layer framework design. For a deeper exploration of the specific components and how they interact and can be implemented, see “What is a Semantic Layer? (Components and Enterprise Applications)”.

Requirement 1: A Semantic Layer supports more than one consuming application

A Semantic Layer is not equivalent to a model or orchestration layer developed to serve only one data product. While application-specific semantic models and integrations–such as those unifying customer information or tracking specific business health analytics via executive dashboards–can be critical to your business’s tech stack, they are not enough to connect information across the organization. To do this, there must be multiple applications operating within a design framework that enables the sharing of semantic data, such as catalogs, recommendation engines, dashboards, and semantic search engines. A semantic layer-type framework that serves only one downstream application risks becoming too closely tied to one domain and stakeholder group, limiting its broader organizational impact.

Requirement 2: A Semantic Layer connects data/content from more than one source system

Similar to enabling more than one application, a semantic layer should also connect information from multiple source systems. A layer that pulls only from one source is not able to meet modern needs for structured and unstructured data aggregation across silos to generate insights. Without a layer for interconnection, organizations run the risk of creating silos between data sources and applications. Additionally, organizations and semantic layer teams should develop data processing and analytics tools that are reusable across source systems as a part of the semantic layer. Tying a layer to a single downstream application encourages the duplication of work, instead of solution reuse enabled by the semantic layer. One multi-national bank that EK worked with developed a semantic layer to pull together complex risk management information from across multiple sources. The bank ended up cutting down their time spent on what used to be weeks-long efforts to aggregate data for regulators, and made information from siloed process-specific applications available in one central system for easy access and use.

Requirement 3: A Semantic Layer establishes a logical architecture

The semantic layer can serve as a logical connection layer between source systems

What separates a semantic layer from a well-implemented data catalog or data governance tool is its ability to serve as a connection and insight layer between multiple heterogenous sources of information, for multiple downstream data products and applications. To serve sources of information that have different data and content structures, the semantic layer needs to be based on a logical architecture that source models can map to. This logical architecture can be managed as a part of the ontology models if desired, but the important thing is that it serves as a necessary abstraction step so that business stakeholders can move from talking about the specific physical details of databases and documents, to what the data and content is about. Without this, the work required to ensure that the layer is both aggregating and enriching information will fail to scale over multiple domains. Moreso, the layer itself may begin to fracture over time without a logical architecture to unify its approach to disparate applications and data sources.

Requirement 4: A Semantic Layer reflects business stakeholder context and vocabulary

A semantic layer is more than simply a means of mapping data between systems. It serves to capture business knowledge and context so that actionable insights can be pulled from structured and unstructured data. In order to do this, the semantic layer must leverage  terminology that business stakeholders use to describe and categorize information. These vocabularies then serve as a standardized source of metadata to ensure that insights from across the enterprise can be compared, contrasted, and linked for further analysis. Without reflecting the language of business stakeholders and understanding  the context they use it in to describe key information, the semantic layer will not be able to accurately and effectively enrich data with business meaning. The layer may make data more accessible, but it will fail to make that data meaningful.

Requirement 5: A Semantic Layer leverages standards

As a semantic layer evolves, so too does a business’s understanding of what tooling best fits their needs for the layer’s components. Core semantic layer components such as the glossary, graph, and metadata storage should be, based on widely adopted semantic web standards, such as RDF and SKOS, to avoid vendor tool lock in for interchangeability. No one component should become an anchor – instead, each component should function more like lego bricks that may be changed out as an organization’s semantic ecosystem and needs evolve. Additionally, basing a semantic layer on standards opens up a world of already matured libraries, design frameworks, and application integrations that can extend and enhance the functionality of the semantic layer, rather than requiring a development team to re-create the wheel. Without standards-based architecture, organizations risk problems with the long-term scalability and management of their semantic layer.

Conclusion

A Semantic Layer connects information across an organization, by establishing a standards-based logical architecture, informed by business context and vocabulary, that connects two or more source systems to two or more downstream applications. Efforts that do not meet these requirements will fail to realize the benefits of the semantic layer, resulting in incomplete or failed projects. The five key requirements for the semantic layer framework described in this article create a baseline for what a semantic layer implementation should be. While not exhaustive, understanding and following these requirements will help organizations unlock the full benefits of the semantic layer to deliver real business value. These requirements will ensure that your semantic layer is able to capture knowledge and embed business context across your organization to power Enterprise AI and Knowledge Intelligence. If you are interested in learning more about semantic layer development and how EK can help, check out our other blogs on the subject, or reach out to EK if you have specific questions.