Fabric Workspaces als atomare Bausteine

Microsoft Fabric ist eine integrierte Analyseplattform — und ihr kleinster adressierbarer Baustein ist der Workspace. Wer Fabric einführt, trifft früh eine Entscheidung, die sich später nur mit erheblichem Aufwand korrigieren lässt: Wie viele Workspaces brauchen wir, und wie schneiden wir sie zu?

Die Frage klingt technisch, ist aber fundamental organisatorisch. Ein Workspace ist nicht nur ein Ordner für Artefakte. Er ist gleichzeitig eine Capacity-Zuteilung, eine Deployment-Einheit und eine Sicherheitsgrenze. Diese drei Dimensionen hängen zusammen — und aus ihrer Überlagerung entsteht die Topologie einer Fabric-Datenplattform.

Dieser Beitrag ordnet die Dimensionen systematisch ein, leitet daraus Entscheidungsregeln ab und zeigt, wie eine typische Workspace-Topologie für ein verteiltes Datenprodukt-Team aussieht. Am Ende steht eine Beobachtung, die über Fabric hinausgeht: das Verhältnis von Workspace-Struktur und Organisationsstruktur — Conways Law in der Datenplattform.

Was ein Workspace ist — und was er nicht ist

Im einfachsten Fall ist ein Fabric Workspace eine Arbeitsumgebung, in der ein Team gemeinsam an einem Datenprodukt oder einer Datenproduktfamilie arbeitet. Er enthält alle zugehörigen Artefakte: Lakehouses und Warehouses für die Datenhaltung, Dataflows und Notebooks für die Transformation, Semantic Models für die Semantik und Reports sowie Dashboards für die Präsentation.

Theoretisch kann man eine vollständige Datenlösung — von der Rohdatenaufnahme bis zum fertigen Dashboard — in einem einzigen Workspace aufbauen. Für Prototypen, Experimente und sehr kleine Teams ist das praktikabel. Für alles, was wächst, in Produktion geht oder mehrere Teams involviert, entstehen schnell Probleme:

Ein einzelner Workspace, der alles enthält, vermischt Lastprofile, Deployment-Zyklen und Berechtigungen. Was einfach beginnt, endet als schwer wartbares Gebilde, in dem niemand genau weiß, was zu welchem Produkt gehört — und in dem jede Änderung alles andere potentiell berührt.

Die Frage ist also nicht, ob eine Aufteilung in mehrere Workspaces sinnvoll ist, sondern wann und nach welcher Logik sie erfolgen sollte. Die Antwort liegt in drei Dimensionen.

Drei Dimensionen, eine Topologie

• Capacity & Last
  Kernfrage: Welche Workloads laufen wann und wie intensiv?
  Typische Entscheidung: Workspaces nach Lastprofil separieren und zuordnen
• Release & Deployment
  Kernfrage: Was wird wann und gemeinsam deployt?
  Typische Entscheidung: Deploymenteinheiten in fokussierte Workspaces fassen
• Security & Rollen
  Kernfrage: Wer darf was sehen, bearbeiten, auslösen?
  Typische Entscheidung: Berechtigungsgrenzen durch Workspace-Trennung ziehen

Diese drei Dimensionen wirken gleichzeitig auf jeden Workspace. Eine Entscheidung, die aus der Capacity-Perspektive sinnvoll ist, kann die Deployment-Logik verkomplizieren. Eine feine Sicherheitstrennung kann die Anzahl der Workspaces exponentiell wachsen lassen. Gutes Workspace-Design findet den Schnitt, der alle drei Dimensionen gleichzeitig adressiert.

Dimension 1: Capacity und Laststeuerung

Jeder Workspace ist einer Fabric Capacity zugeordnet. Alle Workloads, die in diesem Workspace ausgeführt werden — Spark Jobs, Pipeline-Runs, Power BI Queries, KQL-Abfragen — verbrauchen Consumption Units (CU) aus der zugeordneten Capacity. Die Zuordnung eines Workspace zu einer Capacity, bestimmt daher, welches Kostenbudget und welches Lastprofil er mit weiteren Workspaces dieser Capacity teilt.

Das hat unmittelbare Konsequenzen für das Workspace-Design. Wenn intensive Batch-Transformationen und interaktive BI-Queries in einem gemeinsamen Workspace laufen, konkurrieren sie um dieselbe Capacity. Ein nächtlicher Ladelauf, der alle CUs belegt, verzögert am nächsten Morgen die ersten Dashboard-Aufrufe der Nutzer — bis Burst-Schulden abgebaut sind.

Spezialisierte Workspaces nach Lastprofil lösen das Problem: ETL-lastige Workspaces auf einer für Hintergrundlast optimierten Capacity, interaktive BI-Workspaces auf einer Capacity, die für schnelle, kurze Queries ausgelegt ist. Und wenn ein Workload-Profil sich ändert — ein Produkt wächst, ein Projekt endet — kann der Workspace einfach einer anderen Capacity zugeordnet werden, ohne Artefakte zu verschieben.

Dimension 2: Releases und Deployment Pipelines

Fabric Deployment Pipelines verbinden Workspaces zu einer Deployment-Kette. Typisch sind drei Stages: Development → Test → Production. Ein Release "zieht" Inhalte im Pull-Verfahren vom Quell- in den Ziel-Workspace. Was dabei transportiert wird, ist — zumindest bisher — der gesamte Workspace-Inhalt: alle Lakehouses, alle Notebooks, alle Semantic Models, alle Reports.

Daraus folgt eine klare Anforderung: Ein Workspace sollte genau das enthalten, was gemeinsam und gleichzeitig deployt werden soll. Wenn ein Team seinen ETL-Code unabhängig von seinen Reports deployen möchte — weil das Reporting bereits in Produktion ist und nicht warten soll, bis der neue Pipeline-Code getestet ist — braucht es separate Workspaces für diese Teile.

Dies gilt unabhängig davon, ob über Deployment Pipelines oder ein mit dem Workspaces verbundenes Git Repository erfolgt.

Faustregel für Deployment: Ein Workspace entspricht einer Deployment-Einheit. Alles, was in einem Workspace zusammenlebt, wird gemeinsam released. Artefakte, die unterschiedliche Release-Zyklen haben, gehören in verschiedene Workspaces.

In der Praxis bedeutet das typischerweise eine Trennung entlang der logischen Schichten eines Datenprodukts: ein Workspace für die Datenspeicherung (Lakehouse, Warehouse), ein Workspace für die Transformationslogik (Notebooks, Pipelines), ein Workspace für die Semantik (Semantic Models, Datamarts) und ein Workspace für die Visualisierung (Reports, Dashboards). Diese Trennung spiegelt auch unterschiedliche fachliche Verantwortlichkeiten wider — was unmittelbar zur dritten Dimension führt.

Dimension 3: Security und Rollen

Das Berechtigungsmodell von Fabric auf Workspace-Ebene ist bewusst einfach gehalten. Es gibt vier Rollen, die auf den gesamten Workspace wirken:

• Admin
  Kann lesen: ✓ · Kann bearbeiten: ✓ · Kann deployen: ✓ · Kann verwalten: ✓
• Member
  Kann lesen: ✓ · Kann bearbeiten: ✓ · Kann deployen: ✓ · Kann verwalten: –
• Contributor
  Kann lesen: ✓ · Kann bearbeiten: ✓ · Kann deployen: – · Kann verwalten: –
• Viewer
  Kann lesen: ✓ · Kann bearbeiten: – · Kann deployen: – · Kann verwalten: –

Diese Einfachheit ist eine Stärke und gleichzeitig eine Einschränkung. Eine granulare Berechtigungssteuerung innerhalb eines Workspace ist nicht vorgesehen. Es ist nicht möglich, einer Nutzergruppe Rechte zum Bearbeiten auf bestimmte Lakehouses zu geben, aber nicht auf andere oder Entwicklern Schreibzugriff auf Notebooks zu erlauben, ohne ihnen gleichzeitig Zugriff auf sensitive Produktionsdaten zu geben.

Wer solche Trennungen braucht, muss über separate Workspaces eine genauere Zuordnung aufsetzen. Typische Szenarien, die eine Sicherheitstrennung erfordern:

• Backend-Entwickler vs. Frontend-Entwickler
  Lösung: Lakehouse/Pipeline-Workspace getrennt von Report-Workspace
• Sensitive Rohdaten nicht für alle Analysten sichtbar
  Lösung: Raw-Ingest-Workspace mit eingeschränktem Zugang, curated Workspace für Analysten
• Produktionsdaten schützen vor Entwicklerzugriffen
  Lösung: Strenge Stage-Trennung: Entwickler haben keinen Prod-Workspace-Zugang
• Externe Partner sollen nur bestimmte Berichte sehen
  Lösung: Dedizierter Freigabe-Workspace mit Viewer-Rolle für externe Accounts

Eine typische Workspace-Topologie

Wenn man alle drei Dimensionen ernst nimmt, entsteht für ein mittelgroßes Datenprodukt-Team schnell eine zweistellige Anzahl von Workspaces. Das klingt nach Verwaltungsaufwand — ist aber der Preis für saubere Grenzen zwischen Lastprofilen, Deployment-Einheiten und Berechtigungsbereichen.

Die folgende Tabelle zeigt eine typische Topologie für ein einzelnes Datenprodukt (hier: Vertriebsdaten) mit zwei Deployment Stages und einem ergänzenden Datenzugriffs-Workspace:

• raw-ingest-dev: Pipelines, Eventstreams, Landing Zone Lakehouse · Stage: DEV · Capacity: F8 Dev
• raw-ingest-prod: Pipelines, Eventstreams, Landing Zone Lakehouse · Stage: PROD · Capacity: F32 Prod
• silver-transform-dev: Notebooks, Spark Jobs, Silver Lakehouse · Stage: DEV · Capacity: F8 Dev
• silver-transform-prod: Notebooks, Spark Jobs, Silver Lakehouse · Stage: PROD · Capacity: F32 Prod
• product-sales-dev: Gold Lakehouse, Semantic Model, Datamarts · Stage: DEV · Capacity: F8 Dev
• product-sales-prod: Gold Lakehouse, Semantic Model, Datamarts · Stage: PROD · Capacity: F32 Prod
• reports-sales-dev: Power BI Reports, Dashboards · Stage: DEV · Capacity: F8 Dev
• reports-sales-prod: Power BI Reports, Dashboards · Stage: PROD · Capacity: F32 Prod
• access-finance: Shortcuts, Row-Level-Security-Modelle, externe Freigaben · Stage: PROD · Capacity: F16 Shared

In der Realität kommen häufig noch weitere Workspaces hinzu: Test-Stage als dritte Deployment-Stage, separate Workspaces für Shared Semantic Models, die von mehreren Produkten genutzt werden, oder Monitoring-Workspaces mit operativen Dashboards. Eine Plattform mit fünf Datenprodukten kann leicht 50–80 Workspaces umfassen — das ist kein Zeichen von Komplexität, sondern von überlegter Struktur.

Shortcuts als Verbindungsebene zwischen Workspaces

Eine häufige Frage beim Entwurf einer Workspace-Topologie: Wenn Daten auf mehrere Workspaces verteilt sind, wie kommt ein Downstream-Workspace an die Daten des Upstream-Workspace? Die Antwort in Fabric ist der Shortcut — ein virtueller Verweis auf einen Datenspeicher in einem anderen Workspace der aber ohne Datenkopie funktioniert.

Shortcuts erlauben es, Workspace-Grenzen zu überbrücken, ohne Daten zu duplizieren. Ein Gold-Lakehouse in einem Produkt-Workspace kann per Shortcut auf Silver-Daten aus dem Transform-Workspace zugreifen. Ein Zugriffs-Workspace für externe Partner zeigt per Shortcut auf ausgewählte Tabellen im Produktions-Workspace — mit eigener Zugriffskontrolle, ohne Kopie.

Workspaces und Conways Law

Melvin Conway formulierte 1967 eine Beobachtung, die heute als Conways Law bekannt ist: Organisationen, die Systeme entwerfen, produzieren Designs, die die Kommunikationsstruktur der Organisation widerspiegeln. Oder umgekehrt: Wer Systeme baut, die eine bestimmte Organisationsstruktur voraussetzen, zwingt die Organisation, sich dieser Struktur anzunähern.

Im Kontext von Microsoft Fabric hat Conways Law eine sehr konkrete Ausprägung. Die Plattform ist konzeptionell auf verteilte, domänenorientierte Teams ausgelegt. Jeder Workspace gehört einem Team. Dieses Team trägt Verantwortung für sein Datenprodukt — von der Aufnahme bis zur Konsumierbarkeit. Die Workspace-Rolle (Admin, Member, Contributor, Viewer) ist die formale Sprache, in der diese Verantwortung ausgedrückt wird.

Das Spannungsfeld: zentrale Organisation, dezentrale Plattform

Viele Unternehmen starten mit einer zentralisierten Data-Organisation: Ein Team ist für alle Daten zuständig. Dieses Team kann in Fabric weiterhin alle Workspaces besitzen — aber es muss dann intern die Rollen so verteilen, dass faktisch verschiedene Subteams für verschiedene Workspaces zuständig sind. Das funktioniert, schafft aber eine strukturelle Spannung: Die formale Organisationsstruktur und die operative Workspace-Struktur decken sich nicht.

Organisationsmodelle und ihre Fabric-Implikationen

• Zentrales Team, alle Domains
  Ein Team besitzt alle Workspaces. Rollen werden intern verteilt. Führt zu impliziten Abhängigkeiten und breiten Berechtigungen. Domain-Teams, geteilte Plattform
• Domain-Teams, geteilte Plattform
  Jede Domain besitzt ihre Workspaces. Plattform-Team verwaltet Capacity und Governance. Entspricht dem Fabric-Konzept. Hybrid: Zentral + Dezentral
• Hybrid: Zentral + Dezentral
  Zentrales Team für Rohdaten-Layer, Fachteams für Produkt-Workspaces. Pragmatisch, erfordert klare Schnittstellendefinition.

Die Konsequenz in der Praxis: Wer in einer zentralisierten Organisation mit Fabric arbeitet, wird früher oder später feststellen, dass Kolleginnen und Kollegen ständig die Workspace-Rollen wechseln — je nachdem, in welchem Workspace sie gerade arbeiten. Im Vertriebs-Workspace sind sie Contributor, im Marketing-Workspace Viewer, im Plattform-Workspace Admin. Das ist nicht falsch, aber es signalisiert eine tiefergehende Spannung zwischen der formalen Struktur und der operativen Realität.

Fabric belohnt Organisationen, die sich entlang ihrer Datendomänen aufstellen. Das ist keine technische Anforderung — es ist eine organisatorische Einladung. Wer sie annimmt, baut eine Plattform, die mit der Organisation wächst. Wer sie ignoriert, baut eine Plattform, die die Organisation trotz sich wachsen lässt.

Entscheidungshilfe: Wann welcher Workspace-Schnitt?

Es gibt keine universell richtige Workspace-Topologie. Die richtige Topologie hängt von der Teamgröße, dem Reifegrad der Plattform, den Compliance-Anforderungen und der Organisationsstruktur ab. Die folgende Matrix gibt Orientierung für typische Situationen:

• Zwei Teams teilen sich Daten, aber unterschiedliche Berechtigungen
  Empfehlung: Separate Workspaces mit Shortcut-basierten Datenzugriffen
• Frontend- und Backend-Entwickler arbeiten am gleichen Produkt
  Empfehlung: Separate Workspaces für Semantic Models / Reports vs. Lakehouse / Pipelines
• Gleichartige Workloads mit sehr unterschiedlichem Lastprofil
  Empfehlung: Eigener Workspace je Lastprofil, gezielte Capacity-Zuordnung
• Schnelle, unabhängige Releases für verschiedene Produktteile
  Empfehlung: Deployment-Einheiten als eigene Workspaces modellieren
• Kleine Organisation, ein Team, überschaubare Artefaktmenge
  Empfehlung: Ein Workspace pro Stage — Komplexität minimal halten
• Großes Unternehmen, viele Teams, regulierte Datenzugriffe
  Empfehlung: Vollständige Medallion-Topologie je Produkt je Stage + Zugriffs-Workspaces

Ein pragmatischer Startpunkt: Mit zwei bis drei Workspaces pro Datenprodukt und Stage beginnen — einem für Datenspeicher und ETL, einem für Semantic Models, einem für Reports. Das deckt die wesentlichsten Trennlinien ab und lässt sich bei Bedarf erweitern. Eine Überarchitektur von Anfang an lähmt Teams ebenso wie eine Unterarchitektur, die später aufwendig umgebaut werden muss.

Fazit: Topologie als Architekturentscheidung erster Ordnung

Workspaces sind die atomaren Bausteine von Microsoft Fabric — aber ihre Bedeutung reicht über das Technische hinaus. Die Workspace-Topologie einer Fabric-Plattform ist gleichzeitig eine Aussage darüber, wie ein Unternehmen seine Datenarbeit organisiert: wer für was zuständig ist, was unabhängig entwickelt und deployt werden kann, und welche Grenzen zwischen Berechtigungen gelten.

Die drei Dimensionen — Capacity, Deployment und Security — sind keine separaten Fragen, sondern drei Perspektiven auf dieselbe Grundentscheidung: Wo ziehe ich die Grenzen? Wer schaut beim Entwurf nur auf eine Dimension, riskiert Probleme in den anderen. Wer alle drei gleichzeitig im Blick hat, entwickelt eine Topologie, die stabil bleibt, wenn die Plattform und die Organisation wachsen.

Und wer dabei Conways Law ernst nimmt, versteht: Die beste Workspace-Topologie ist die, die die Teamstruktur widerspiegelt, die man sich wünscht — nicht die, die man gerade hat.