Microsoft Fabric: Vision und Realität

Microsoft Fabric ist eines dieser Themen, bei denen man schnell merkt: Hier geht es längst nicht mehr nur um ein neues Produkt. Fabric steht für eine Idee, die viele Unternehmen sofort anspricht. Endlich weniger Brüche zwischen Datenintegration, Speicherung, Analyse und Power BI. Endlich nicht mehr für jeden Schritt ein anderes Werkzeug, ein anderes Team und ein anderes Verantwortungsmodell. Auf dem Papier klingt das fast wie die lang ersehnte Antwort auf viele alte Probleme.

Und genau deshalb wird so heftig darüber diskutiert. Nicht, weil Fabric belanglos wäre, sondern weil es einen wunden Punkt trifft. Viele Unternehmen hängen irgendwo zwischen Excel-Realität, Power-BI-Self-Service und dem Wunsch nach einer sauberen Datenplattform. Fabric setzt genau dort an. Und damit landet es automatisch mitten in einer Grundsatzfrage: Wie viel Ordnung braucht Datenarbeit wirklich – und wie viel Pragmatismus muss man zulassen, damit überhaupt etwas vorangeht?

https://www.youtube.com/watch?v=mTVeZzshLzE

Die eigentliche Frage lautet nicht: Ist Fabric gut?

Im Gespräch mit Martin Bubenheimer war deshalb ziemlich schnell klar, dass die spannende Frage nicht „Ist Fabric gut oder schlecht?“ ist. Die interessantere Frage ist: Für wen ist Fabric in der Form, in der es heute existiert, eigentlich wirklich gemacht? Die Idee dahinter ist nachvollziehbar. Eine breite Plattform, mehrere Technologien nebeneinander, unterschiedliche Einstiege für unterschiedliche Skill-Level. Klingt erstmal vernünftig. Vielleicht sogar überfällig.

Die Kritik beginnt aber an dem Punkt, an dem aus einer guten Idee Alltag werden muss. Martin hat es im Podcast ziemlich klar formuliert: Fabric ist aktuell zu unausgereift für genau die Zielgruppe, die es eigentlich adressieren soll.

Typische Probleme sind dabei zum Beispiel:

• inkonsistente Features, etwa beim Deployment-Verhalten je nach Asset-Typ

• fehlende oder eingeschränkte Orchestrierung

• technische Bugs statt klassischer Userfehler

• viele notwendige Workarounds

Das führt zu einem zentralen Problem: Nutzer bauen Lösungen nicht entlang eines sauberen Konzepts, sondern entlang dessen, was gerade irgendwie funktioniert. Und genau das widerspricht eigentlich dem Anspruch einer Plattform für Self-Service.

Das Problem liegt tiefer als bei Governance

Das ist ein wichtiger Unterschied. Denn viele Diskussionen über Self-Service BI drehen sich sehr schnell um Governance. Zu viele Insellösungen. Zu wenig Standards. Zu viel Wildwuchs. Zu viel Abhängigkeit von einzelnen Personen. Das alles kennt man. Aus Excel. Aus Access. Aus lokalen Power-BI-Dateien. Aus Fachbereichslösungen, die irgendwie laufen, aber niemand so richtig betreuen will.

Der Punkt im Podcast war aber ein anderer. Die Kritik an Fabric zielt nicht nur auf fehlende Regeln oder zu viel Freiheit. Sie zielt auf technische Reibung, die direkt aus der Plattform kommt. Wenn etwas nicht deshalb schwierig wird, weil Menschen chaotisch arbeiten, sondern weil das Produkt selbst inkonsistent wirkt, dann reden wir nicht mehr nur über Governance. Dann reden wir über Reifegrad. Und das ist ein Unterschied, den man nicht kleinreden sollte.

Warum damit noch nicht die ganze Geschichte erzählt ist

So berechtigt diese Einwände sind: Sie erklären eben nicht die ganze Realität. Denn in vielen Unternehmen ist die Alternative nicht irgendeine perfekt organisierte Plattformwelt mit klaren Rollen, sauberem Backlog und sofort verfügbaren Experten. Die echte Alternative ist oft viel weniger glamourös.

Sie sieht eher so aus:

• Excel-Dateien auf SharePoint

• lokale Power-BI-Modelle

• manuelle Workflows

• Copy-Paste-Prozesse

• Mappings, die nur eine Person wirklich versteht

Wenn du aus so einer Realität kommst, dann bewertest du Fabric automatisch anders. Dann fragst du nicht zuerst, ob alles architektonisch elegant ist. Dann fragst du: Wird hier gerade etwas endlich sichtbarer, zentraler und besser teilbar? Genau an dieser Stelle hat Fabric oft einen echten Hebel. Nicht weil Microsoft Fabric perfekt ist, sondern weil es einen Schritt aus dem Versteckten heraus ermöglicht.

Der eigentliche Gegner heißt oft Excel-Chaos

Das ist vielleicht einer der wichtigsten Gedanken aus der ganzen Debatte. In vielen Diskussionen wird Fabric sofort mit spezialisierten Plattformen verglichen. Mit Snowflake. Mit Databricks. Mit sauberer, codezentrierter Plattformarbeit. Das ist fachlich nicht völlig falsch, aber in der Praxis oft trotzdem am Thema vorbei.

Denn in vielen Fachbereichen ist der eigentliche Gegner nicht die bessere Plattform eines anderen Herstellers. Der eigentliche Gegner ist Chaos. Also eine Datenrealität, die längst existiert, aber nirgends wirklich sichtbar ist. Lokale Dateien. Schattenlogik. Übergänge, die nur funktionieren, weil einzelne Personen sehr viel implizites Wissen mit sich herumtragen. Wenn man das ernst nimmt, verschiebt sich auch der Bewertungsmaßstab. Dann geht es nicht zuerst darum, ob Fabric in jeder Disziplin das stärkste Produkt ist. Dann geht es darum, ob Fabric hilft, aus einer improvisierten Realität einen ersten strukturierten Schritt zu machen.

Weshalb der Einstieg über Microsoft Fabric oft leichter fällt

Ein Grund dafür ist simpel: Fabric fühlt sich für viele Teams nicht wie ein kompletter Neustart an. Power Query ist bekannt. Power BI ist bekannt. Der Microsoft-Kontext ist vertraut. Und daneben entstehen neue Möglichkeiten wie Lakehouse, Warehouse oder Notebooks. Nicht jeder nutzt davon alles. Aber viele trauen sich den ersten Schritt eher in so eine Umgebung als direkt in eine klassische Data-Engineering-Welt.

Das ist nicht nur ein psychologischer Punkt, sondern ein praktischer. In Fachbereichen wird heute schon erstaunlich viel gebaut. Nur eben oft an Stellen, an denen es nicht dauerhaft gut aufgehoben ist. Da werden SAP-Daten mit Forecast-Dateien aus Excel zusammengeführt. Hilfstabellen gepflegt. Logiken in Power Query immer weiter erweitert. Und am Ende landet das Ergebnis trotzdem wieder in einer Tabelle, die irgendwo exportiert wird. Fabric kann genau an dieser Stelle attraktiv sein, weil es diese Arbeit nicht sofort perfekt macht, aber zumindest aus dem Lokalen und Unsichtbaren herausholt.

Wo Fabric heute echten Mehrwert bringt

Auch diese Frage wurde im Gespräch nicht theoretisch, sondern sehr praktisch verhandelt. Für Citizen Developer klingt Fabric erstmal wie ein Versprechen: schneller Einstieg, sichtbare Ergebnisse, mehr Eigenständigkeit. In der Realität stoßen viele aber schneller als gedacht auf technische Eigenheiten, die sie nicht ohne Unterstützung lösen können. Dann kippt Selbstständigkeit schnell in Frust oder in eine neue Abhängigkeit von Experten.

Trotz aller Kritik gibt es aber eben auch eine starke Gegenposition – und die kommt direkt aus der Praxis im Fachbereich. Der zentrale Gedanke dahinter ist einfach: Perfekt ist nicht notwendig, nutzbar ist entscheidend. Genau hier hat Fabric für viele Teams einen echten Vorteil:

• Quick Wins statt Perfektion

  Daten werden überhaupt erst zentral abgelegt, Prozesse werden schneller und Lösungen werden sichtbar und teilbar.

• Niedrigere Einstiegshürde

  Bekannte Werkzeuge wie Power Query bleiben erhalten, während neue Möglichkeiten schrittweise dazukommen.

• Evolution statt Big Bang

  Lösungen wachsen organisch. Governance kann später nachgezogen werden, statt schon vor dem ersten Nutzen alles vollständig durchzuarchitektieren.

Für zentrale IT-Teams sieht das trotzdem anders aus. Dort klingt Fabric zunächst nach mehr Transparenz und mehr Standardisierung. In der Praxis kann es aber auch bedeuten, dass plötzlich mehrere Technologien, Eigenheiten und Sonderfälle parallel unterstützt werden müssen. Und für erfahrene Data Engineers ist Fabric ebenfalls nicht automatisch die erste Wahl. Wer aus stabilen, codezentrierten Umgebungen kommt, empfindet manche Grenzen und Inkonsistenzen eher als Last. Genau deshalb liegt Fabric heute oft in diesem Zwischenraum: nicht ganz Fachbereichstool, nicht ganz Enterprise-Plattform, aber für viele Unternehmen trotzdem relevant.

Hinter Microsoft Fabric steckt ein alter Grundkonflikt

Wenn man das Gespräch auf seinen Kern herunterbricht, geht es eigentlich gar nicht zuerst um Fabric. Es geht um zwei unterschiedliche Haltungen zu Datenprojekten. Die eine sagt: Erst Architektur, dann Umsetzung. Erst Stabilität, dann Geschwindigkeit. Erst sauber, dann skalierbar. Die andere sagt: Erst Problem lösen, dann professionalisieren. Erst Nutzen, dann Ordnung. Erst in Bewegung kommen, dann Standards nachziehen.

Beide Sichtweisen haben gute Gründe. Die klassische IT-Perspektive schützt vor technischer Schuld, Support-Höllen und Lösungen, die später niemand mehr anfassen will. Die fachbereichsnahe Perspektive schützt vor Stillstand, vor jahrelangen Warteschleifen und vor einer Datenorganisation, die auf dem Papier sauber aussieht, aber am Bedarf vorbeiläuft. Fabric versucht, beide Welten zusammenzubringen. Und genau darin liegt die Spannung. Es will Nähe zum Fachbereich und Plattform zugleich sein. Das ist attraktiv – aber eben auch konfliktreich.

Das Problem sind nicht Workarounds, sondern ihre Ursachen

Ein spannender Teil der Diskussion war deshalb die Frage, wie man eigentlich auf Workarounds schauen sollte. Denn natürlich gibt es in Datenprojekten ständig Umwege. Anforderungen ändern sich, Quellen ändern sich, Fachlogik ändert sich. Wer schon ein paar echte Projekte gesehen hat, weiß: Ohne Workarounds läuft es selten.

Die entscheidende Frage ist also nicht, ob es Workarounds gibt. Die entscheidende Frage ist:

• warum sie entstehen

• wie oft sie nötig werden

• wie teuer sie im Betrieb sind

• und ob sie aus der Fachlichkeit kommen oder aus der Plattform selbst

Wenn ein Workaround entsteht, weil ein Forecast kurzfristig anders geliefert wird, ist das etwas anderes, als wenn er entsteht, weil bestimmte Dinge technisch schlicht noch nicht sauber zusammenspielen. Genau da wird aus Pragmatismus schnell Reibung. Und genau deshalb ist der Satz „Workarounds gibt es überall“ zwar nicht falsch, aber auch nicht besonders hilfreich.

Microsoft Fabric wird oft mit dem falschen Maßstab bewertet

Der reflexhafte Vergleich mit Snowflake greift deshalb oft zu kurz. Nicht, weil Snowflake kein sinnvoller Referenzpunkt wäre. Sondern weil beide in vielen Unternehmen gar nicht dieselbe Rolle spielen. Fabric wird oft dort interessant, wo Nähe zu Power BI, bekannte Werkzeuge und eine niedrigere Einstiegsschwelle wichtiger sind als maximale Klarheit, Stabilität und Spezialisierung.

Deshalb bringt auch die Frage „Ist Snowflake stabiler?“ nur begrenzt etwas. Wahrscheinlich ja – in vielen Szenarien. Aber das allein entscheidet noch nicht über den geschäftlichen Nutzen. Die wichtigere Frage ist: Welche Probleme willst du lösen? Wenn du eine hochprofessionelle, stark standardisierte Plattformarbeit brauchst, fällt die Bewertung anders aus als dann, wenn du aus einer Welt kommst, in der Fachbereiche bisher mit Excel, SharePoint und lokalen Modellen improvisieren mussten.

Fabric ist noch nicht fertig – aber längst relevant

Für mich ist genau das die ehrlichste Beschreibung. Fabric ist aktuell weder die perfekte Enterprise-Plattform noch das einfache Self-Service-Werkzeug, als das es manchmal dargestellt wird. Es ist ein Dazwischen. Und dieses Dazwischen ist anstrengend, weil es Reibung erzeugt. Aber es ist eben auch relevant, weil viele Unternehmen genau an dieser Stelle stehen: nicht mehr ganz in der alten Excel-Welt, aber auch noch nicht in einer reifen, zentral organisierten Plattformrealität.

Das macht Fabric schwer einzuordnen. Wer Eindeutigkeit sucht, wird daran nicht viel Freude haben. Wer aber akzeptiert, dass viele Datenorganisationen gerade Übergangszustände managen müssen, kann in Fabric durchaus einen sinnvollen Hebel sehen. Nicht als Endzustand. Nicht als Allheilmittel. Sondern als Plattform, an der sichtbar wird, was schon funktioniert, was noch fehlt und wo ein Unternehmen beim Thema Daten tatsächlich steht.

---

Fazit: Microsoft Fabric ist weniger Lösung als Prüfstein

Ob Fabric für dein Unternehmen sinnvoll ist, entscheidet sich deshalb nicht an einer Featureliste. Entscheidend ist, welche Realität du heute hast und welche Art von Fortschritt du gerade brauchst. Wenn du maximale Stabilität, hohe technische Reife und möglichst wenig Plattformüberraschungen brauchst, wirst du viele Kritikpunkte an Fabric nachvollziehen können. Wenn du dagegen aus einer Welt kommst, in der Datenarbeit zwar längst stattfindet, aber weitgehend lokal, unsichtbar und improvisiert, dann kann Fabric ein ziemlich wirksamer nächster Schritt sein.

Aus Sicht der Daten-WG liegt genau darin die eigentliche Relevanz. Fabric ist weniger die fertige Antwort als der Auslöser der richtigen Debatte. Wie viel Self-Service willst du wirklich zulassen? Wie viel Chaos bist du bereit vorübergehend zu akzeptieren? Wann ist ein Quick Win hilfreich – und wann wird er zur technischen Schuld? Wer diese Fragen ehrlich verhandelt, wird Fabric weder blind feiern noch reflexhaft ablehnen. Genau das ist im Moment wahrscheinlich die sinnvollste Haltung.

---

Der nächste sinnvolle Schritt

Microsoft Fabric entfaltet seinen Nutzen erst dann vollständig, wenn Architektur, Datenflüsse, Verantwortlichkeiten und Betriebsmodell sauber zusammenspielen. Genau diese Grundlagen entscheiden darüber, ob aus ersten Use Cases eine tragfähige Plattform entsteht oder nur die nächste Zwischenlösung..

Wenn du Microsoft Fabric strukturiert einführen oder bestehende Setups gezielt weiterentwickeln willst, unterstützen wir dich mit:

• Fabric Kick Start – für einen praxisnahen Einstieg in Architektur, Zielbild und erste Use Cases

• Data Strategy Check – um eure Daten- und Analytics-Organisation ganzheitlich einzuordnen

• Consulting Abo – für kontinuierliche Unterstützung bei Migration, Betrieb und Governance

So wird aus einer technischen Einführung eine belastbare Plattform, die auch langfristig trägt.