27. August 2026 von Stefan Rahlf
Von der Toolbox zur Datenlandschaft
Wer in den letzten Jahren eine Datenplattform aufgebaut hat, kennt das Ritual: Man beginnt mit einer Toolauswahl. Welche Datenbank für das zentrale Warehouse? Welches ETL-Werkzeug für die Pipelines? Welche Visualisierungslösung für die Berichte? Die ersten Wochen sind geprägt von Evaluierungen, Lizenzverhandlungen und Architekturzeichnungen — noch bevor ein einziger Datensatz geflossen ist.
Diese Herangehensweise hat eine eigene Logik. Sie ist vertraut, sie gibt Struktur, und sie produziert früh ein greifbares Ergebnis: einen Technologie-Stack.
Aber sie hat auch einen fundamentalen Denkfehler eingebaut. Durch den technologischen Fokus bleibt die Datennutzung mit hoher Wahrscheinlichkeit ein „IT-Thema“. Die Fragen nach dem Nutzen für die Businessprozesse und den Beiträgen zur Unternehmensstrategie müssen später geklärt werden – die Use Cases, die dann oft für die neue Datenplattform erst „gesucht“ werden.
Wir haben wochenlang das perfekte ETL-Tool evaluiert — und kaum darüber nachgedacht, wer eigentlich die Daten braucht und wozu.
Das Problem mit dem Tool-First-Ansatz
Ein zentrales Data Warehouse, eine einheitliche ETL-Plattform, ein gemeinsames BI-Layer — das klingt nach Ordnung. In der Praxis entsteht daraus oft etwas anderes: ein monolithischer Engpass, der von einem kleinen Zentralteam verwaltet wird, das dann für alle Datenbedarfe im Unternehmen zuständig ist („das Silo“). Marketing wartet auf das Analytics-Team. Das Analytics-Team wartet auf die IT. Die IT wartet auf Kapazität und muss Priorisieren.
Das Modell skaliert nicht — weder organisatorisch noch technisch. Und es ignoriert eine entscheidende Frage: Wer kennt die Daten eigentlich am besten?
In den meisten Unternehmen sind das die Fachbereiche selbst. Das Vertriebsteam versteht die Semantik der CRM-Daten. Das Logistikteam weiß, was eine "abgeschlossene Lieferung" wirklich bedeutet. Das zentrale Data-Team weiß es meistens nicht.
Dazu kommt noch, dass sich eine neue Kohorte an „unerfahrenen Mitarbeitern“ mit der „agentic workforce“ bereit macht und mehr qualitativ hochwertige Daten im Zugriff benötigt aber wenig Erfahrung hat Datenfehler zu erkennen.
Paradigmenwechsel im Plattformbau
- Bisher: Technologieauswahl als erster Schritt
Heute: Datendomänen und Teams als Ausgangspunkt - Bisher: Zentrales DWH-Team als Engpass
Heute: Verteilte Ownership, dezentrale Verantwortung - Bisher: Einheitliches ETL für alle Domänen
Heute: Jede Domäne liefert ihr Datenprodukt - Bisher: Fachbereich als Datenkonsument
Heute: Fachbereich als Datenbesitzer - Bisher: Plattform als Technologie-Stack
Heute: Plattform befähigt die Organisation
Data Mesh - das Konzept hinter dem Wandel
Der Begriff "Data Mesh", geprägt von Zhamak Dehghani, fasst diesen Wandel konzeptionell zusammen. Statt Daten zentral zu sammeln und zu verwalten, organisiert man Daten entlang von Fachdomänen. Jede Domäne besitzt ihre Daten, pflegt sie und stellt sie als Datenprodukt bereit — mit klaren Schnittstellen, definierten Qualitätsstandards und einem Team, das Verantwortung trägt.
Das klingt überzeugend. Die Umsetzung war bislang das Problem. Denn das Modell stellt hohe Anforderungen: Jede Domäne braucht eigene Infrastruktur. Governance wird komplex. Die zentrale Plattform muss gleichzeitig befähigen und Leitplanken bieten. Ohne die richtigen Werkzeuge endet Data Mesh als organisatorische Idee ohne technische Heimat.
Data Mesh ist keine Technologie — aber es braucht eine Plattform, die das Konzept lebt.
Microsoft Fabric - Plattform als Betriebssystem
Genau hier setzt Microsoft Fabric an. Fabric ist keine Toolsammlung, die man zusammen lizenziert. Es ist eine integrierte Analyseplattform, die alle Kapazitäten — von der Datenaufnahme über Transformation und Speicherung bis hin zu Visualisierung und KI — unter einem gemeinsamen Dach vereint. Der entscheidende Unterschied: Alle erforderlichen Technologien stehen den Data Teams zur Verfügung und können im definierten Governance Rahmen genutzt werden. Man muss sie nicht beschaffen, nicht integrieren, nicht separat warten.
Das verändert die Ausgangsfrage grundlegend. Statt "Welches Tool nehmen wir für X?" lautet die Frage "Welche Domänen haben wir, wer sind ihre Kunden, und was brauchen sie?".
Microsoft Fabric — SaaS Plattform mit allen Werkzeugen die ein Daten Team benötigt – Datenakquise, -speicherung, -aufbereitung, -modellierung, -konsum und ML/AI Nutzung
Was sich mit Fabric praktisch verändert
In einer Fabric-Umgebung arbeitet zum Beispiel das Vertriebs-Datenteam in einem eigenen Workspace. Es modelliert seine Daten im Lakehouse, transformiert sie mit Dataflows oder Spark-Notebooks und veröffentlicht ein kuratiertes semantisches Modell — das Datenprodukt — für die Kunden im Unternehmen. Das Marketing-Team konsumiert dieses Produkt, kombiniert es mit eigenen Kampagnendaten und liefert seinerseits Insights an die Geschäftsführung.
Kein Team muss dabei auf ein zentrales Infrastrukturteam warten, um ein neues Schema anzulegen oder eine Pipeline zu starten. Kein Architekturboard muss entscheiden, ob man für den neuen Use Case ein weiteres Tool einführt. Die Möglichkeiten sind einfach zu nutzen — Governance, Sicherheit und Compliance sind über Microsoft Purview zentral und konsistent geregelt, während die operative Verantwortung dezentral liegt.
Das ist das Organisationsprinzip einer flexiblen föderalen Datenplattform.
Teams denken anders, wenn die Frage anders lautet
Wenn ein Domänenteam weiß, dass es die Infrastruktur nicht selbst beschaffen muss, ändert sich die Diskussion in den ersten Projektwochen fundamental. Man spricht nicht mehr über Technologien und versucht Anforderungen in die bestehenden Werkezuge zu bringen, sondern über die Datenkunden: Wer braucht was? Wie oft? In welcher Qualität? Welche Entscheidungen sollen die Daten ermöglichen?
Diese Fragen führen zu besseren Datenprodukten — weil sie von fachlichen Anforderungen zu einer geeigneten Implementierung gedacht sind. Vom fachlichen Bedarf her, nicht vom technischen Werkzeug. Und die einfach gegebenen Möglichkeiten in der Plattform führen zu schnelleren Ergebnissen. Architekturentscheidungen dauern nicht mehr Wochen, sondern nur Stunden.
Wir haben aufgehört, Technologien zu evaluieren. Wir haben angefangen, unsere Kunden zu verstehen. Drei Wochen später hatten wir unser erstes Datenprodukt live.
Governance ohne Zentralisierung
Ein berechtigter Einwand: Wenn jede Domäne ihre eigenen Daten verwaltet, droht Chaos. Unterschiedliche Definitionen, inkompatible Modelle, unkontrollierter Datenzugang.
Microsoft Fabric adressiert das mit einem Konzept, das man als "Federated Governance" beschreiben kann. Zentrale Richtlinien — Datenzugriffskontrollen, Klassifikationen, Compliance-Regeln — werden einmal definiert und gelten plattformweit. Innerhalb dieses Rahmens hat jede Domäne operative Freiheit. Die Zentralfunktion gibt den Rahmen vor; die Teams arbeiten darin autonom aber für die gemeinsame Governance transparent.
Der OneLake-Ansatz in Fabric stellt außerdem sicher, dass Daten physisch nicht unkontrolliert repliziert werden. Es gibt eine logische Persistenz Schicht — mit domänenspezifischen Bereichen, aber gemeinsamer Grundstruktur und gemeinsamer Auffindbarkeit. Da die Daten immer nur im Kontext eines Workspaces durch dessen Team und die dort verwendeten Tools verwaltet wird gibt es keine Daten ohne einen Besitzer.
Fabric bildet eine „Daten-Nutzungsschicht“ im Unternehmen, die einen zentralen Anlaufpunkt bildet, aber nicht erzwingt, dass alle bestehenden etablierten Lösungen und Datenpools zwingend migriert werden müssen. Stattdessen können über sogenannte „shortcuts“ Daten direkt aus ihren bereits existierenden Speichern „eingeblendet“ werden und „mirror“ erlauben eine „zero ETL“ Koppelung mit einem automatisch verwalteten Replikat in Fabric für Datenbanken.
Die eigentliche Transformation
Es wäre zu kurz gedacht, Microsoft Fabric als "das Tool, das Data Mesh ermöglicht" zu beschreiben. Die eigentliche Transformation ist organisatorischer Natur. Fabric schafft die technischen Voraussetzungen, damit Unternehmen anfangen können, in Domänen und Produkten zu denken — statt in Tools und Projekten.
Das bedeutet Datenteams, die bisher reaktiv auf Anfragen gewartet haben, werden zu Produzenten fachlicher Datenprodukte. Fachbereiche, die Daten als IT-Thema delegiert haben, übernehmen Verantwortung. Und die Plattform selbst hört auf, ein Engpass zu sein — weil sie groß genug ist, viele Teams gleichzeitig zu tragen.
Der Einstieg in eine Datenplattform verändert sich dadurch grundlegend. Anstatt "Welche Technologie wählen wir?" liegt der Fokus auf "Welche Domänen haben wir, welche Teams befähigen wir zuerst, und welche Datenprodukte bringen den größten Mehrwert für ihre Kunden?".
Das ist eine bessere erste Frage. Und sie führt zu besseren Plattformen.
Und damit beginnt die grundlegende Diskussion um eine Datenstrategie zu entwickeln die auf die Unternehmensstrategie einzahlt – der Weg zum datenzentrierten Unternehmen!
Kostenplanung: von Lizenz-Tetris zu einem einzigen Budget
Ein oft unterschätzter Aspekt des klassischen Tool-First-Ansatzes ist seine Kostenkomplexität. Eine moderne Datenplattform, die aus Einzelkomponenten zusammengesetzt ist, bedeutet in der Praxis: unterschiedliche Lizenzmodelle für jedes Werkzeug, separate Cloud-Infrastrukturkosten für Compute und Storage, Betriebskosten für Monitoring, Patching und Skalierung — und das alles für eine Landschaft, die ständig wächst und deren Nutzung sich schwer vorhersagen lässt. Das Finance-Team fragt nach dem Budget für das nächste Jahr; die Antwort ist bestenfalls eine Schätzung mit großem Unsicherheitskorridor.
Dazu kommt das Skalierungsproblem: Wenn eine neue Domäne eingeführt wird, braucht sie eigene Infrastruktur. Wenn ein Projekt in die Pilotphase geht und das Datenvolumen plötzlich steigt, wird nachgeordert — mit Lieferzeiten, Genehmigungsrunden und oft ungeplantem Mehraufwand. Wenn ein Projekt endet oder ein Team kleiner wird, bleiben Lizenzkosten trotzdem stehen, weil Verträge laufen.
Wir hatten fünf verschiedene Rechnungen für unsere Datenplattform — und keiner wusste genau, was davon wirklich genutzt wurde.
Microsoft Fabric kehrt dieses Modell um. Als SaaS-Plattform sind Cloud-Infrastruktur und Betrieb bereits im Preis enthalten — kein separates Azure-Infrastruktur-Budget, keine DevOps-Kosten für Plattformwartung, keine Überraschungen in den Abrechnungen durch unkontrollierte Ressourcennutzung. Was bleibt, ist eine einzige Steuerungsgröße: die Fabric Capacities.
Das Capacity-Modell funktioniert dabei nicht starr. Fabric bietet das Konzept von Burst und Smoothing um kurzfristige Lastspitzen — etwa wenn ein Domänenteam einen großen Ladejob startet oder das Reporting am Monatsende Hochbetrieb hat —durch temporär höhere Compute-Nutzung abzufedern, ohne dass sofort mehr Capacity gebucht werden muss.
Die Plattform glättet die Nutzung über die Zeit. Das Ergebnis ist ein festes, planbares Budget, das trotzdem flexible und variierende Nutzungsmuster erlaubt, anstatt für jede Spitzenlast dauerhaft überdimensionierte Kapazität vorzuhalten.
Für die Budgetplanung bedeutet das eine fundamentale Vereinfachung da die Frage nicht mehr lautet „Wie viele Lizenzen für welches Tool in welchem Tier?“, sondern „Welche Capacity-Größe brauchen wir für unser Nutzungsprofil?“. Neue Domänen onboarden, ohne neue Verträge zu schließen. Projekte starten und beenden, ohne Lizenzreste zu verwalten. Und wenn die Plattform tatsächlich wächst, gibt es einen einzigen Hebel — mehr Capacity — statt eines Puzzles aus Einzelentscheidungen.
Kostenstruktur im Vergleich
- Klassische Datenplattform: Separate Lizenzen pro Tool & Vendor
Microsoft Fabric (SaaS): Eine Capacity-Einheit deckt alle Workloads ab - Klassische Datenplattform: Cloud-Infrastruktur & Betrieb zusätzlich
Microsoft Fabric (SaaS): Plattformbetrieb im SaaS-Preis enthalten - Klassische Datenplattform: Wachstum = neue Verträge & Verhandlungen
Microsoft Fabric (SaaS): Neue Domänen nutzen vorhandene Capacity - Klassische Datenplattform: Schwer planbare Spitzenlasten & Idle-Kosten
Microsoft Fabric (SaaS): Burst & Smoothing: Spitzen werden gepuffert - Klassische Datenplattform: Budget mit großem Unsicherheitspuffer
Microsoft Fabric (SaaS): Festes, planbares Budget — flexible Nutzung
Fazit
Microsoft Fabric markiert einen echten Paradigmenwechsel im Aufbau von Datenplattformen — und dieser Wandel vollzieht sich auf zwei Ebenen gleichzeitig. Auf der fachlichen Ebene ersetzt das Domain-First-Prinzip die klassische Tool-Orientierung: Nicht mehr die Technologie bestimmt die Struktur der Plattform, sondern die Fachdomänen, ihre Teams und ihre Datenprodukte. Auf der wirtschaftlichen Ebene löst das Capacity-Modell das Lizenz- und Infrastrukturkostengeflecht durch eine einzige, planbare Steuerungsgröße ab.
Beide Veränderungen hängen zusammen. Eine Domänenlandschaft, die wächst und sich verändert, braucht eine Kostenstruktur, die mitwächst — ohne bei jeder neuen Domäne neue Verträge, neue Infrastruktur und neue Betriebsaufwände zu erzeugen. Genau das leistet Fabric: Die Plattform skaliert organisatorisch und technisch, weil beides auf demselben Fundament steht.
Das bedeutet nicht, dass alle bisherigen Herausforderungen verschwinden. Datenqualität, Governance und die Befähigung von Teams sind keine Plattformprobleme — sie bleiben organisatorische Aufgaben. Was Fabric nimmt, ist die Notwendigkeit, diese Aufgaben unter dem zusätzlichen Gewicht einer fragmentierten Toollandschaft und einer unplanbaren Kostenstruktur zu bewältigen.
Die entscheidende Frage beim Einstieg in Fabric ist deshalb keine technische: Sie ist organisatorisch. Welche Domänen haben wir? Wer trägt Verantwortung für welche Daten? Welche Datenprodukte bringen welchen Kunden welchen Mehrwert? Wer diese Fragen beantworten kann, hat alles, was er braucht, um mit Fabric zu starten. Die Plattform ist bereit — die eigentliche Arbeit beginnt im Whiteboard-Raum, nicht im Tool-Evaluierungsgespräch.
Fabric löst kein Organisationsproblem — aber es ermöglicht zum ersten Mal eine Plattform, die zur Organisation passt, statt gegen sie zu arbeiten.
