Semantic Layer im KI-Zeitalter: BI-Modell, Plattformfunktion oder Headless-Architektur?

In meinen ersten Projekten vor rund zehn Jahren stand ich vor der Wahl: MicroStrategy oder Tableau. Für mich war die Entscheidung klar, Tableau. Der Grund war das semantische Modell. In Tableau leicht, agil und im Alltag kaum spürbar, in MicroStrategy ausufernd, komplex und für meine Zwecke praktisch unnütz. Offensichtlich ging es nicht nur mir so, MicroStrategy hat als Frontend in vielen Projekten an Bedeutung verloren.

Rückblickend wirkt diese Entscheidung fast ironisch. Das, was damals wie unnötiger Ballast erschien, könnte heute genau das sein, was moderne Datenplattformen brauchen. Visualisierungen lassen sich inzwischen in vielen Tools per Prompt erzeugen, und es ist absehbar, dass sich die Rolle klassischer Frontends weiter reduziert. Was bleibt, sind die semantischen Modelle.

Gerade im Kontext von AI wird ihre Bedeutung deutlich. In einem Experiment mit Microsoft Fabric haben wir untersucht, wie gut ein Data Agent mit Daten arbeitet, einmal auf Basis von reinen SQL-Strukturen, einmal auf Basis eines semantischen Modells mit Measures und Beschreibungen. Der Unterschied war deutlich. Sauber definierte Measures und angereicherte Metadaten haben die Qualität und Stabilität der Antworten massiv verbessert. Die AI konnte sich an klaren Definitionen orientieren, statt rohe Tabellen interpretieren zu müssen. Die vollständigen Ergebnisse werden wir separat veröffentlichen.

Dass das kein neues Problem ist, zeigt auch ein Blick zurück auf die BI-Welt von damals. Semantic Layer waren fast immer Teil des Frontends. Tableau bewusst dünn, Power BI etwas stärker mit Measures und Beziehungen, MicroStrategy als Gegenpol mit einem sehr zentralen, stark modellierten Ansatz. Am Ende ging es immer um Reporting. Semantik war Mittel zum Zweck, um Dashboards konsistent zu halten, nicht als eigenständige Schicht in der Datenarchitektur.

Aktuell verschiebt sich der Semantic Layer sichtbar in Richtung Datenplattform. Microsoft treibt diese Entwicklung mit Fabric konsequent voran. Aus dem klassischen Power BI Semantic Model wird schrittweise eine Ontology, also ein Modell, das nicht nur Kennzahlen und Beziehungen beschreibt, sondern als Grundlage für AI-gestützte Interaktion dient. Auch bei Databricks sieht man eine ähnliche Richtung. Mit Unity Catalog und Metric Views entstehen zentrale Stellen für Definitionen, Metadaten und Governance, die direkt in die Plattform integriert sind und von AI-Systemen genutzt werden können.

Semantik löst sich vom Frontend und wird Teil der Plattform. Definitionen, Beziehungen und Kontext werden zentral gepflegt und von unterschiedlichen Konsumenten genutzt, von BI über Notebooks bis zu AI Agents. Plattformbasierte Semantic Layer reduzieren doppelte Definitionen, stabilisieren Kennzahlen und integrieren Governance direkt in die Datenlogik.

Hinzu kommt eine neue architektonische Anforderung. Wenn Semantik zentral wird, braucht sie auch einen klaren Ort der Pflege. Ohne einen solchen Single Point of Maintenance entsteht schnell wieder Fragmentierung, etwa zwischen Semantic Model und Data Catalog. Die Plattform löst also nicht nur Probleme, sie definiert auch neu, wo und wie semantische Logik überhaupt verwaltet wird. Gleichzeitig verschiebt sich damit auch die Abhängigkeit. Die semantische Logik ist tief in der Plattform verankert, Zugriffsmöglichkeiten sind oft eingeschränkt oder zumindest nicht vollständig offen.

Es entsteht damit eine neue Form von Lock-in. Während sich viele Datenplattformen in den letzten Jahren bewusst in Richtung offener Standards entwickelt haben, etwa mit Spark, Delta oder Iceberg, verlagert sich die Abhängigkeit zunehmend auf die semantische Schicht. Definitionen von Kennzahlen, Beziehungen und Geschäftslogik sind eng an die jeweilige Plattform gebunden und lassen sich nur mit erheblichem Aufwand übertragen. Plattformbasierte Semantic Layer funktionieren gut innerhalb ihrer eigenen Welt, verlieren aber an Wirkung, sobald mehrere Systeme ins Spiel kommen. Das betrifft weniger theoretische Multicloud-Szenarien als vielmehr die Realität gewachsener Landschaften mit Legacy-Systemen, zusätzlichen Datenquellen oder spezialisierten Plattformen für einzelne Anwendungsfälle.

Hinzu kommt eine eingeschränkte Offenheit nach außen. Viele dieser Ansätze sind primär für die Nutzung innerhalb des eigenen Ökosystems optimiert. BI funktioniert gut, ebenso erste AI-Funktionen innerhalb der Plattform. Schwieriger wird es, wenn externe Anwendungen, eigene Services oder Agenten-Systeme angebunden werden sollen. Schnittstellen sind vorhanden, aber oft nicht so konsistent oder flexibel, dass sich semantische Logik wirklich bruchlos weiterverwenden lässt. Plattform-APIs geben oft Rohdaten frei, aber die mit ihnen verknüpften Metadaten, Measures und Geschäftslogik bleiben proprietär oder nur eingeschränkt zugänglich. Semantik wird damit zum integralen Bestandteil der Plattform, aber eben auch zu einem begrenzenden Faktor über ihre Grenzen hinaus.

Headless Semantic Layer ist das Architekturprinzip, das Semantik aus Tools und Plattformen löst und zentral verfügbar macht. Metriken, Dimensionen, Beziehungen und fachliche Beschreibungen werden zentral gepflegt. Das reduziert widersprüchliche Definitionen und schafft einen klaren Bezugspunkt für alle Anwendungen.

Im Kern erfüllt ein solcher Layer zwei Funktionen. Die erste ist die Definition und Verwaltung von Semantik. Dazu gehören technische Metadaten wie Tabellen und Spalten, fachliche Metadaten wie Kennzahlen und Beschreibungen sowie Governance-Aspekte wie Berechtigungen, Klassifizierungen oder Compliance-Regeln. Diese Informationen gehen deutlich über ein klassisches Data Dictionary oder Business Glossary hinaus, weil sie nicht nur beschreiben, sondern aktiv steuern, wie Daten interpretiert und verwendet werden. Der Semantic Layer geht über einen klassischen Data Catalog hinaus. Während der Catalog beschreibt, definiert der Semantic Layer aktiv Logik. Ohne klare Abstimmung entstehen schnell doppelte Kennzahlen und widersprüchliche Definitionen.

Die zweite Funktion ist das Serving. Ein Headless Semantic Layer übersetzt Metriken und Beziehungen in ausführbare Abfragen und stellt sie über SQL, APIs oder kompatible Schnittstellen bereit. Typische Zugänge sind SQL-Endpunkte, APIs oder kompatible Schnittstellen für bestehende Frontends, etwa DAX für Power BI oder andere Abfragesprachen. Der eigentliche Compute kann dabei in den zugrunde liegenden Plattformen bleiben, der Semantic Layer orchestriert ihn und sorgt für konsistente Ergebnisse. Für Konsumenten bedeutet das einen einheitlichen Zugriff, unabhängig davon, ob sie aus einem BI-Tool, einer Anwendung oder einem eigenen Service heraus arbeiten.

Wie lässt sich so ein Headless Semantic Layer konkret umsetzen? Das aktuelle Tooling folgt keinem einheitlichen Zielbild. Stattdessen existieren unterschiedliche Ansätze mit klaren Trade-offs. Plattform-native Lösungen wie Fabric oder Databricks, eigenständige Headless-Tools wie Cube oder Mosaic und Bausteine wie dbt, die Teile der Funktionalität abdecken. Gerade dbt wird häufig nicht als fertiger Semantic Layer eingesetzt, sondern als Grundlage, auf der eigene, projektspezifische Lösungen entstehen. Die eigentliche Entscheidung liegt nicht im Tool selbst, sondern in der Rolle, die Semantik in der eigenen Architektur einnehmen soll.

Ein zentraler Aspekt ist die Ownership der semantischen Logik und damit der organisatorische Fit. Wer definiert die Kennzahlen, wer pflegt sie, wer nutzt sie im Alltag? Engineering-getriebene Ansätze wie dbt setzen auf deklarative Modelle in YAML und eine enge Integration in Entwicklungsprozesse. dbt Semantic Layer sind deklarativ und CI/CD fähig, setzen aber fundierte Data Engineering Skills voraus und sind für Business-User schwer zugänglich. In vielen Fällen wird dieser Ansatz noch erweitert, etwa durch eigene Serving-Layer, APIs oder zusätzliche Metadatenstrukturen. Das schafft maximale Kontrolle und Flexibilität, erhöht aber auch die Komplexität. Für Fachbereiche bleibt dieser Zugang in der Regel schwer zugänglich. Auf der anderen Seite stehen Ansätze wie Mosaic, die stärker auf Business-User ausgerichtet sind und mit AI-Unterstützung arbeiten, um Modellierung zu vereinfachen. In der Praxis wird sich kaum eines dieser Modelle isoliert durchsetzen. Semantik entsteht als kollaborativer Prozess, mit technischen Elementen wie Context- oder Knowledge-Engineering und gleichzeitig der Möglichkeit für Fachbereiche, Logik verständlich zu definieren und zu dokumentieren.

Der Architektur-Fit unabhängiger Headless-Tools zeigt sich vor allem in komplexeren Umgebungen. Mehrere Datenquellen, gewachsene Strukturen oder der Bedarf, eigene Anwendungen und Services anzubinden, sprechen für eine entkoppelte Semantikschicht. Dem gegenüber steht ein höherer Betriebsaufwand: Headless Semantic Layer müssen integriert, betrieben, gesichert und finanziert werden. Ein neues Tool bringt immer auch zusätzliche Komplexität und Kosten. Auch die Einbindung in bestehende Plattformen ist selten nahtlos. Plattform-native Sicherheits- und Governance-Mechanismen, etwa in Fabric oder im Unity Catalog, greifen innerhalb ihres Ökosystems durchgängig. Ein externer Semantic Layer kann diese Logik nicht ohne weiteres übernehmen. Berechtigungen und Regeln müssen abgestimmt, teilweise mehrfach gepflegt werden.

Die Betriebsfähigkeit vieler Ansätze lässt sich aktuell nur eingeschränkt bewerten. Codebasierte Lösungen wie der dbt Semantic Layer fügen sich gut in bestehende Deployment-Prozesse ein und profitieren von etablierten Praktiken aus der Softwareentwicklung. Tools, die stark auf grafische Oberflächen oder AI-gestützte Interfaces setzen, lassen sich schwerer in klassische CI/CD-Strukturen integrieren. Hinzu kommt, dass viele Produkte noch jung sind und sich schnell weiterentwickeln. Welche Muster sich langfristig durchsetzen, ist an vielen Stellen noch offen.

Was sich durch das Tooling zieht, ist für mich keine Toolfrage mehr, sondern eine Verschiebung in der Architektur. Der Semantic Layer rückt aus der BI-Ecke heraus und wird zu einem zentralen Baustein der Datenplattform. Ob plattformgebunden oder headless ist dabei zweitrangig. Entscheidend ist, dass Business-Logik überhaupt bewusst modelliert und bereitgestellt wird.

Mit AI wird diese Lücke sichtbar. Sprachmodelle arbeiten nicht zuverlässig auf Rohdaten. Ohne klare Semantik entstehen plausible, aber falsche Ergebnisse. Erst ein sauber definierter Semantic Layer setzt den Rahmen für stabile Analysen und sinnvolle Interaktion.

Wenn ich auf meine damalige Entscheidung zurückblicke, wirkt sie heute fast widersprüchlich. MicroStrategy war mir zu schwergewichtig, Tableau genau deshalb attraktiv. Heute sehe ich das anders. Nicht die komplexen Modelle waren das Problem, sondern dass sie ihrer Zeit voraus waren. Die einfachen Modelle haben uns schnell gemacht, aber sie stoßen jetzt an ihre Grenzen.