Eine Architektur – mehrere Plattformen

Die Plattform ist eine Umsetzung — nicht die Architektur

Fabric, Snowflake, Databricks oder SQL Server setzen dieselbe logische Warehouse-Architektur um — die Plattform ist Wahl der Umsetzung, nicht der Architektur.

Die Lenkung fragt „Snowflake oder Fabric?“, bevor Verantwortung, erster Vertical Slice und Kennzahlenvertrag klar sind. Monate später gibt es Lizenzen, aber keinen governen Sales-Mart.

Ein modernes Data Warehouse benötigt klare Verantwortlichkeiten:

Quelldaten erfassen
Einen wiederherstellbaren Rohzustand erhalten
Datensätze standardisieren und integrieren
Schlüssel und Historien auflösen
Gemeinsame Geschäftsregeln anwenden
Governte Datenprodukte veröffentlichen
Analytische und operative Consumer versorgen
Sicherheit, Qualität, Lineage und Monitoring über alle Schichten betreiben

Keine dieser Verantwortlichkeiten setzt ein bestimmtes Produkt voraus.

Sie können mit einer vorhandenen SQL-Server-Landschaft, Microsoft Fabric, Snowflake, Databricks, einem anderen relationalen Warehouse oder einer bewusst gewählten hybriden Kombination umgesetzt werden. Die technischen Objekte, Ausführungs-Engines und Betriebsmodelle unterscheiden sich. Die logische Architektur sollte erkennbar gleich bleiben.

Ein Tool-first-Design kehrt diese Reihenfolge um:

„Wir haben Fabric gekauft, deshalb muss jeder Workload Fabric nutzen.“
„Wir nutzen Databricks, deshalb muss jede Transformation zu Spark werden.“
„Wir haben Snowflake gewählt, deshalb muss jede Quelle nach Snowflake kopiert werden.“
„Wir haben bereits Qlik, deshalb bleibt das Qlik-Ladeskript das Warehouse.“
„Wir haben dbt eingeführt, deshalb muss jedes SQL-Objekt in dbt neu gebaut werden.“

Jede Entscheidung kann für einen konkreten Workload sinnvoll sein. Keine davon ist ein Architekturprinzip.

Part 8, Optionen für Datentransformationen, hat gezeigt, dass SQL, Stored Procedures, Notebooks, Dataflows, native Plattformfunktionen und dbt legitime Transformationsmechanismen sein können. Dieser Part ordnet die vollständige Architektur unterschiedlichen Plattformen zu.

Halte die fachlichen Verantwortlichkeiten stabil. Wähle die technische Umsetzung, die am besten zur vorhandenen Landschaft, zum Workload, zum Team und zum Betriebsmodell passt.

Architekturprinzip: Verantwortlichkeiten statt Produktnamen erhalten

Eine portable Referenzarchitektur beschreibt zuerst, was jede Schicht leisten muss, und ordnet erst danach eine Technologie zu.

Bronze, Silver und Gold können sinnvolle Namen für einige physische Schichten sein. Sie ersetzen die genannten Verantwortlichkeiten nicht. Eine Bronze-Tabelle ohne Wiederherstellbarkeit, Verantwortung und Ingestion-Metadaten ist keine vollständige Rohschicht. Eine Gold-Tabelle ohne explizite Granularität, fachliche Definition, Qualitätsstatus und Owner ist nicht automatisch ein Datenprodukt.

Ein hilfreicher Portabilitätstest lautet:

Kann das Team fachliche Granularität, Historie, Qualität, Sicherheit und Veröffentlichungsverhalten erklären, ohne den Plattformnamen zu verwenden?

Lautet die Antwort nein, beschreibt das Design wahrscheinlich noch Produkte statt Architektur.

Die einfachste gültige Umsetzung

Das einfachste sinnvolle Warehouse kann bereits vorhanden sein.

Ein Unternehmen mit SQL Server, einem Scheduler, Qlik, Power BI Report Server und Excel kann eine governte Architektur aufbauen, ohne zuerst eine Cloud-Datenplattform zu beschaffen.

Eine minimale Umsetzung kann folgende Objekte enthalten:

staging.sales_order_line
staging.customer
core.fact_sales_order_line
core.dim_customer
core.dim_product
core.dim_date
mart.sales_customer_daily
quality.sales_rule_result
control.data_product_publication

Der technische Ablauf kann so aussehen:

Die erste Version benötigt weder einen separaten Lake noch Spark, dbt, ein Katalogprodukt oder ein neues Semantic-Layer-Tool. Sie benötigt jedoch:

• eine autoritative Sales-Definition;
• eine dokumentierte Granularität;
• stabile Business- und Surrogate Keys;
• explizite Historienregeln;
• persistente Datenqualitätsnachweise;
• kontrollierte Veröffentlichung;
• Zugriffsregeln;
• versionierten Transformationscode;
• Monitoring und einen verantwortlichen verantwortliche Person.

Zusätzliche Technologie sollte nur eingeführt werden, wenn sie eine konkrete Einschränkung bei Integration, Skalierung, Zusammenarbeit, Latenz, Governance oder Betrieb löst.

Ein Sales- und Customer-Beispiel über alle Plattformen

Der Plattformvergleich ist nur sinnvoll, wenn jede Umsetzung dieselbe fachliche Antwort erzeugt.

Angenommen, das governte Produkt heißt Sales by Customer.

Produktvertrag

Ein plattformneutraler Core kann Folgendes bereitstellen:

fact_sales_order_line
  business_date_key
  order_id
  order_line_id
  customer_key
  product_key
  quantity
  gross_amount
  discount_amount
  net_revenue_amount
  reporting_currency
  quality_status
  source_system
  publication_timestamp

dim_customer
  customer_key
  customer_id
  customer_name
  country_code
  segment_code
  valid_from
  valid_to
  is_current

Die wiederverwendbare Regel gehört in die governte Transformations- und Produktschicht:

select
    s.business_date,
    s.order_id,
    s.order_line_id,
    c.customer_key,
    p.product_key,
    s.quantity,
    (s.gross_amount - s.discount_amount) * fx.reporting_rate
        as net_revenue_amount,
    'EUR' as reporting_currency
from standardized.sales_order_line s
join core.dim_customer c
  on s.customer_id = c.customer_id
 and s.business_date >= c.valid_from
 and s.business_date < c.valid_to
join core.dim_product p
  on s.product_id = p.product_id
 and s.business_date >= p.valid_from
 and s.business_date < p.valid_to
join reference.exchange_rate fx
  on s.currency_code = fx.source_currency
 and fx.target_currency = 'EUR'
 and s.business_date = fx.rate_date
where s.standardized_status = 'POSTED';

Die genaue SQL-Syntax, Datumsgrenzen und Materialisierung unterscheiden sich je nach Engine. Die Bedeutung darf sich nicht unterscheiden.

Consumer-spezifisches Verhalten bleibt dort lokal, wo es begründet ist:

Qlik darf Storno, Währungsumrechnung oder historische Kundenzuordnung nicht in jeder App neu berechnen. Power BI darf keine abweichende Nettoumsatzdefinition in DAX erzeugen. Excel darf nicht der einzige Ort werden, an dem fehlende Kundenzuordnungen korrigiert werden.

Microsoft Fabric mit Qlik, Power BI und Excel

Microsoft Fabric ist eine gültige Umsetzung, wenn das Unternehmen von einer gemanagten Microsoft-Analytics-Plattform, OneLake, Fabric Data Factory, Lakehouse- oder Warehouse-Workloads und enger Power-BI-Integration profitiert.

Fabric ist nicht automatisch die beste Wahl, nur weil Microsoft 365, Azure oder Power BI bereits vorhanden sind.

Eine minimale Fabric-Zuordnung

Fabric stellt mehrere gültige Wege bereit. Die Architektur sollte die kleinste Menge auswählen, die das Team zuverlässig betreiben kann.

Lakehouse, Warehouse oder beides

Ein Lakehouse ist sinnvoll, wenn der Workload Dateien, Delta-Tabellen, Spark, Python, semistrukturierte Daten oder Data-Science-Integration benötigt.

Ein Fabric Warehouse ist sinnvoll, wenn der Workload stark relational ist und das Team T-SQL, Warehouse-Objekte, dimensionale Modellierung und SQL-orientierte Consumption bevorzugt.

Beides zu verwenden kann sinnvoll sein, wenn die Verantwortlichkeiten explizit getrennt sind:

Lakehouse
  quellnahe Dateien und Delta-Tabellen
  große oder semistrukturierte Transformationen
  Spark- und Python-Workloads

Warehouse
  integrierte Fakten und Dimensionen
  governte relationale Datenprodukte
  stabile SQL-Verträge für BI-Consumer

Beides ohne Verantwortungsgrenze zu verwenden erzeugt duplizierte Speicherung, wiederholte Transformationen und unklare Verantwortung.

Mirroring, Pipelines und Shortcuts sind Optionen

Mirroring kann für unterstützte Quellszenarien den Aufwand eigener Ingestion reduzieren. Data-Factory-Pipelines können mehrstufige Workflows orchestrieren und automatisieren. OneLake Shortcuts können vorhandene Daten ohne direkte Kopie zugänglich machen, wenn Quelle, Sicherheit und Performance-Muster dafür geeignet sind.

Diese Funktionen lösen unterschiedliche Probleme. Sie sollten nicht alle in jeden Flow eingebaut werden.

Eine hilfreiche Auswahlreihenfolge ist:

1. Kann der vorhandene Ingestion-Prozess die benötigten Daten zuverlässig liefern?
2. Liefert Mirroring die erforderliche Quellenunterstützung, Latenz und das passende Betriebsverhalten?
3. Würde eine Pipeline Abhängigkeiten, Zeitplanung und Monitoring klarer machen?
4. Kann ein Shortcut unnötige Kopien vermeiden, ohne Verantwortung oder Sicherheit zu schwächen?
5. Ist physische Materialisierung für Performance, Historie, Qualitätsisolierung oder Vertragsstabilität erforderlich?

Power BI nutzt Fabric-native Stärken

Power BI kann Fabric-Semantikmodelle und Direct Lake verwenden, wenn Modell, Capacity, Sicherheit und Betriebsanforderungen dazu passen.

Das Semantikmodell bleibt eine Consumption-Schicht. Gemeinsame Sales-Regeln gehören weiterhin in governte Datenprodukte, sofern sie nicht tatsächlich Filterkontext- oder Darstellungsverhalten sind.

Geeignete Power-BI-Verantwortlichkeiten sind:

• Beziehungen und Hierarchien;
• DAX-Measures auf freigegebenen Fakten;
• Time-Intelligence-Verhalten;
• Berichtsnavigation;
• Zeilen- oder Objektsicherheit im Modell, wo sie geeignet ist;
• kontrollierte Verteilung und Endorsement.

Qlik bleibt ein schlanker analytischer Consumer

Qlik kann governte Fabric-Daten über einen unterstützten Datenzugriffspfad konsumieren. Die Qlik-Anwendung kann ergänzen:

• ein assoziatives Nutzer-Modell;
• kanonische Kalender;
• Master Dimensions und Master Measures;
• Set Analysis für Qlik-spezifische Vergleiche;
• Section Access oder einen anderen begründeten Durchsetzungsmechanismus;
• App-spezifische Performanceoptimierung.

Das Qlik-Ladeskript sollte nicht zu einer zweiten Fabric-Transformationsplattform werden. Gemeinsame Kundenintegration, Währungsumrechnung, Historie und Qualitätsregeln bleiben vorgelagert.

Excel erhält einen kontrollierten Vertrag

Excel kann abhängig von Anwenderprozess und Lizenzumgebung ein freigegebenes Semantikmodell, eine governte SQL View, eine Power-Query-Verbindung oder eine kontrollierte Ausgabedatei verwenden.

Die Arbeitsmappe darf Folgendes verantworten:

• Pivot-Layout;
• Kommentare und Review-Status;
• kontrollierte Planungsannahmen;
• lokale Formatierung;
• operative Nachverfolgungsspalten.

Sie sollte nicht das autoritative Kunden-Matching, die Stornoregel oder die Nettoumsatzberechnung verantworten.

Snowflake und Databricks als gleichwertige Alternativen

Snowflake, Databricks und Fabric können dieselbe governed Architektur als Beispiele umsetzen. Sie besitzen unterschiedliche Stärken, Schnittstellen und Betriebsmodelle; keines ist verpflichtendes Premium-Ziel oder gerankter Gewinner.

Snowflake-Umsetzung

Eine SQL-zentrierte Snowflake-Umsetzung kann folgende Schemas verwenden:

RAW
STANDARDIZED
CORE
MART
QUALITY
CONTROL

Das Sales-Beispiel kann so zugeordnet werden:

Dynamic Tables können deklarative SQL-Pipelines vereinfachen, wenn Target Freshness und Dependency Management zur Anforderung passen. Streams und Tasks können explizitere Änderungserfassung und prozedurales Scheduling bereitstellen. Gewöhnliche SQL Views und geplante Tabellenaufbauten bleiben gültig.

Das Team sollte nicht alle drei Muster für dieselbe Regel verwenden.

Ein praktisches Snowflake-Sales-Design kann so aussehen:

RAW.SALES_ORDER_LINE
RAW.CUSTOMER
STANDARDIZED.SALES_ORDER_LINE
STANDARDIZED.CUSTOMER
CORE.FACT_SALES_ORDER_LINE
CORE.DIM_CUSTOMER
MART.SALES_CUSTOMER_DAILY
QUALITY.SALES_RULE_RESULT
CONTROL.SALES_PUBLICATION

Qlik und Power BI können dedizierten BI-Compute oder Workload-Steuerung verwenden, ohne die Produktdefinition zu verändern. Excel kann eine schmalere View oder einen kontrollierten Extrakt erhalten.

Snowflake ist besonders attraktiv, wenn ein Cloud Data Warehouse, SQL-zentrierte Analytics, unabhängige Compute-Skalierung, teamübergreifendes Data Sharing oder Multi-Cloud-Verfügbarkeit ein reales Problem löst. Snowflake ist unnötig, wenn eine vorhandene relationale Plattform den Workload bereits wirtschaftlich und betrieblich erfüllt.

Databricks-Umsetzung

Eine Databricks-Umsetzung ordnet die Architektur häufig governten Delta-Tabellen und einer medallion-artigen Entwicklung zu:

Bronze      Quellnahe Delta-Tabellen
Silver      Bereinigte, standardisierte und integrierte Delta-Tabellen
Gold        Fachlich nutzbare Fakten, Dimensionen, Aggregate und Datenprodukte

Diese Benennung bleibt optional. Die Verantwortlichkeiten sind verpflichtend.

Das Sales-Beispiel kann so zugeordnet werden:

Eine mögliche governte Objektstruktur lautet:

main.raw.sales_order_line
main.raw.customer
main.standardized.sales_order_line
main.standardized.customer
main.core.fact_sales_order_line
main.core.dim_customer
main.product.sales_customer_daily
main.quality.sales_rule_result
main.control.sales_publication

Databricks ist eine starke Option, wenn das Unternehmen eine gemeinsame Umgebung für umfangreiches Engineering, SQL Analytics, Streaming, Python, Spark, Data Science oder Machine Learning benötigt.

Databricks sollte nicht als Open-Source-On-Premises-Produkt beschrieben werden. Delta Lake ist Open Source, die Databricks-Plattform ist jedoch eine gemanagte Cloud-Plattform auf AWS, Azure und Google Cloud. Eine On-Premises-Installation von Apache Spark oder Delta Lake besitzt ein anderes Betriebsmodell und sollte nicht Databricks genannt werden.

Qlik kann über den unterstützten Databricks-Connector und SQL Compute auf governte Databricks-Tabellen zugreifen. Power BI kann einen unterstützten Databricks-Verbindungsweg verwenden. Excel sollte eine freigegebene SQL-nahe View, ein Semantikmodell oder einen kontrollierten Extrakt konsumieren statt beliebige Notebooks oder Bronze-Tabellen direkt zu verwenden.

dbt bleibt auf beiden Plattformen optional

dbt kann Snowflake, Databricks, Fabric oder einer anderen SQL-fähigen Plattform Mehrwert liefern, wenn das Team Folgendes benötigt:

• einen modularen SQL-Modellgraphen;
• Git-basierte Reviews;
• Tests und Dokumentation;
• wiederverwendbare Macros und Konventionen;
• CI/CD für Analytics Engineering;
• einen einheitlichen Entwicklungsworkflow über viele Modelle.

dbt sollte nicht zu einer Pflichtschicht werden, nur weil mehrere Plattformen vorhanden sind.

Eine hilfreiche Regel lautet:

Die native Plattformtransformation ist autoritativ
oder
das dbt-Projekt ist autoritativ

Ein Mischmodell ist nur dann gültig, wenn die Grenze explizit ist, zum Beispiel:

Native Ingestion und Streaming
Native oder Python-basierte Standardisierung
Autoritatives dbt-Projekt für SQL-zentrierten Core und Marts
Plattformnative Planung und Überwachung

Welche Plattform passt zu welchem Kontext?

Die Plattformentscheidung sollte mit der vorhandenen Landschaft und dem dominanten Workload beginnen und nicht mit einem generischen Funktionsvergleich.

Vorhandenes Ökosystem

Nutze die vorhandene Plattform, wenn sie die fachliche Anforderung mit akzeptablem Risiko und Betriebsaufwand erfüllen kann.

Eine ausgereifte SQL-Server-Landschaft mit zuverlässigem Betrieb, starken SQL-Kompetenzen und planbaren Reporting-Workloads kann wertvoller sein als eine überhastete Migration auf eine Cloud-Plattform.

Fabric kann Integrationsaufwand reduzieren, wenn Power BI, Azure Identity, OneLake-orientierte Analytics und Microsoft-Plattformbetrieb strategisch sind.

Snowflake kann zu einem Cloud-Data-Warehouse-Betriebsmodell mit starken SQL-Analytics-, Workload-Isolierungs- und Data-Sharing-Anforderungen passen.

Databricks kann zu einer Engineering- und KI-intensiven Umgebung passen, in der SQL, Spark, Python, Streaming und Machine Learning gemeinsam betrieben werden müssen.

SQL versus Spark und Python

Ein überwiegend relationaler Workload benötigt nicht allein wegen eines großen Datenvolumens Spark.

Wähle SQL-orientierte Verarbeitung, wenn:

• Transformationen mengenorientiert und relational sind;
• dimensionale Modellierung dominiert;
• das Team am stärksten in SQL ist;
• BI-Concurrency und governtes Reporting im Mittelpunkt stehen;
• das aktuelle Warehouse Latenz- und Skalierungsanforderungen erfüllt.

Wähle Spark-/Python-orientierte Verarbeitung, wenn:

• Transformationen verteilten Code oder komplexe Bibliotheken benötigen;
• semistrukturierte oder unstrukturierte Daten zentral sind;
• Streaming und Event-Verarbeitung einen wesentlichen Anteil besitzen;
• Data Science und Feature Engineering echte Kern-Workloads sind;
• wiederverwendbare Software-Engineering-Muster über SQL hinaus erforderlich sind.

Hybride SQL- und Python-Plattformen können beides unterstützen. Die Architektur muss trotzdem festlegen, welche Engine jede Regel verantwortet.

BI-Fokus versus ML und Streaming

Eine Management-Reporting-Plattform und eine ML-Plattform können governte Daten teilen, ohne jede Betrieb zu teilen.

Zwinge den BI-Workload nicht in eine Engineering-Engine, nur weil ML existiert. Zwinge ML-Aufbereitung nicht in BI-orientiertes SQL, wenn Python oder Spark tatsächlich erforderlich ist.

Die gemeinsame Grenze ist das governte Datenprodukt mit seinen Verträgen.

Betriebsmodell

Eine Plattform ist nicht nur eine Entwicklungsoberfläche. Bewerte:

Identity- und Zugriffsadministration
Netzwerk und private Konnektivität
Umgebungstrennung
Source Control und Deployment
Zeitplanung und Dependency Management
Monitoring und Alarmierung
Kosten- und Capacity-Steuerung
Backup, Recovery und Continuity
Incident Verantwortung
Hersteller- und internen Support
Verfügbarkeit von Kompetenzen

Eine funktionsreiche Plattform ohne nachhaltiges Betriebsmodell ist eine schwache Architektur.

Kostenmodell

Vergleiche die vollständigen Betriebskosten statt nur den Listenpreis.

Berücksichtige:

• Lizenzen oder Subscriptions;
• Capacity oder Verbrauch;
• Speicherung und Datentransfer;
• Leerlauf- und Spitzen-Compute;
• Entwicklungs- und Migrationsaufwand;
• Plattformadministration;
• Monitoring- und Sicherheitswerkzeuge;
• Training und Recruiting;
• Support und Incident Recovery;
• Parallelbetrieb während der Migration.

On-Premises ist nicht automatisch günstiger, weil die Hardware bereits vorhanden ist. Cloud ist nicht automatisch günstiger, weil sie verbrauchsabhängig ist. Workload-Profil und Betriebsdisziplin bestimmen das Ergebnis.

Datenresidenz und Konnektivität

Wenn Richtlinien, Regulierung, Verträge oder Konnektivität lokale Verarbeitung erfordern, kann eine On-Premises- oder sorgfältig entworfene Hybridarchitektur das richtige Ziel sein.

Ist Cloud-Nutzung erlaubt, müssen Region, Netzwerk, Identity, Verschlüsselung, Datentransfer und Continuity weiterhin explizit geprüft werden.

Teamkompetenz

Wähle eine Plattform nicht nur deshalb, weil externe Spezialisten sie aufbauen können.

Das interne Team muss in der Lage sein:

• Änderungen zu reviewen;
• Abhängigkeiten zu verstehen;
• Produktion zu betreiben;
• Fehler zu diagnostizieren;
• Kosten zu kontrollieren;
• Sicherheit durchzusetzen;
• das Modell nach Ende des Einführungsprojekts weiterzuentwickeln.

Ein kleineres Design mit vorhandener Kompetenz ist häufig sicherer als eine theoretisch überlegene Plattform, die betrieblich extern bleibt.

On-Premises ist weiterhin eine valide Architektur

On-Premises bedeutet nicht ungovernt, monolithisch oder veraltet.

Dieselben modernen Prinzipien gelten:

Quellnahes Staging
Wiederherstellbare Ingestion
Versionierte Transformationen
Konforme Fakten und Dimensionen
Persistente Qualitätsnachweise
Governte Datenprodukte
Schlanke Consumer-Modelle
Automatisiertes Monitoring und Deployment
Explizite Verantwortung und Lifecycle

Eine praktische On-Premises-Zuordnung

Das Design kann weiterhin Git, automatisierte Deployments, Datentests, Lineage-Extraktion, API-Verträge und Observability umfassen.

Gültige Gründe für On-Premises

• vertragliche oder regulatorische Datenresidenz;
• sensible Workloads mit strenger interner Kontrolle;
• unzuverlässige oder eingeschränkte externe Konnektivität;
• Low-Latency-Integration mit lokalen operativen Systemen;
• große bestehende Investition und ein erfahrenes Betriebsteam;
• planbare Workloads mit wirksamer vorhandener Capacity;
• eine Übergangsstrategie, die das Risiko einer sofortigen Migration nicht rechtfertigt.

On-Premises-Verantwortlichkeiten, die nicht ignoriert werden dürfen

Das Unternehmen verantwortet größere Teile der Plattform selbst:

• Hardware und Virtualisierung;
• Betriebssysteme und Datenbanken;
• Patching und Upgrades;
• Capacity Planning;
• Backup und Disaster Recovery;
• Netzwerk- und Identity-Integration;
• Hochverfügbarkeit;
• Security Monitoring;
• Support und Lifecycle Management.

Dieser Betriebsaufwand muss in die Plattformentscheidung einbezogen werden.

Hybride Kombinationen können bewusst gewählt sein

Hybridarchitektur sollte nicht bedeuten, dass jeder Datensatz auf jede Plattform kopiert wird.

Ein gültiges Hybridmuster kann so aussehen:

On-Premises-Betriebssysteme
Kontrollierte lokale Extraktion oder Replikation
Cloud-Raw- und Transformationsplattform
Governte Cloud-Datenprodukte
Qlik-, Power-BI- und Excel-Consumption entsprechend Netzwerk- und Sicherheitsanforderungen

Ein weiteres gültiges Muster kann so aussehen:

On-Premises-Core-Warehouse bleibt autoritativ
Ausgewähltes Cloud-Datenprodukt wird für Advanced Analytics oder ML veröffentlicht
Ergebnisse kehren über einen kontrollierten Vertrag zurück
Core-BI bleibt auf der vorhandenen Plattform

Ein drittes Muster kann Fabric für Power BI und gemeinsame Microsoft-Consumption nutzen, während eine vorhandene Snowflake- oder Databricks-Plattform für Transformation autoritativ bleibt.

Die Architektur muss Folgendes definieren:

Eine Hybridplattform ohne diese Entscheidungen wird zu einem teuren Synchronisationsproblem.

Plattformspezifische Stärken sollen plattformspezifisch bleiben

Eine technologieoffene Architektur bedeutet nicht, so zu tun, als seien alle Produkte identisch.

Sie bedeutet, Plattformstärken zu verwenden, ohne gemeinsame fachliche Bedeutung in inkompatible lokale Implementierungen zu verschieben.

Beispiele:

Typische Anti-Patterns

Die Produktnamen-Architektur

Quelle → Fabric → Power BI

Dies definiert weder Raw Recovery, Historie, Qualität, Produktverträge, Sicherheit noch Verantwortung.

Bronze, Silver und Gold ohne Verantwortlichkeiten

Drei Ordner oder Schemas erzeugen kein Warehouse. Jede Schicht benötigt einen expliziten Zweck, Owner, Inputs, Outputs und Kontrollen.

Dieselbe Regel je Plattform neu aufbauen

SQL-Server-Nettoumsatz
Fabric-Nettoumsatz
Snowflake-Nettoumsatz
Databricks-Nettoumsatz
Qlik-Nettoumsatz
Power-BI-Nettoumsatz
Excel-Nettoumsatz

Eine Transition kann vorübergehend parallele Implementierungen enthalten. Das Zielbild benötigt eine autoritative Regel je Produktvertrag.

Dauerhafter Parallelbetrieb nach einer Migration

Parallele Validierung ist vor dem Cutover sinnvoll. Dauerhaft gleichberechtigte Verantwortung erzeugt Kosten, Abstimmungsaufwand und Mehrdeutigkeit.

Plattformauswahl anhand maximaler theoretischer Skalierung

Eine Plattform mit extremer Skalierungsfähigkeit ist nicht automatisch die beste Wahl für einen moderaten, stabilen Workload. Komplexität und Betriebsaufwand bleiben real.

Cloud allein als Modernisierung behandeln

Undokumentierte Prozeduren, duplizierte Regeln und unkontrollierte Berichte in einen Cloud-Service zu verschieben erhält das Architekturproblem.

On-Premises automatisch als veraltet behandeln

Ein stabiles, governtes Warehouse ohne fachlichen oder betrieblichen Nutzen zu ersetzen ist keine Modernisierung.

Qlik zur Integrationsplattform machen

Eine gemeinsame Qlik-Extraktions- oder QVD-Schicht kann ein gültiger Brownfield-Schritt sein. Sie sollte nicht der einzige Ort für wiederverwendbare Geschäftsregeln werden, wenn Power BI, Excel, APIs oder andere Consumer dieselbe Wahrheit benötigen.

Databricks als On-Premises-Distribution behandeln

Open-Source-Komponenten wie Delta Lake oder Apache Spark können außerhalb von Databricks betrieben werden. Dadurch wird die resultierende Umgebung nicht zu einer Databricks-Bereitstellung.

dbt ohne Verantwortungsgrenze ergänzen

Wenn dbt und native Transformationen dasselbe Modell bauen, hat das Unternehmen eine weitere Implementierung statt Governance ergänzt.

Direkter Consumer-Zugriff auf Raw-Daten

Qlik-, Power-BI- oder Excel-Anwender sollten nicht Quellcodes, unvollständige Historien und fehlerhafte Datensätze verstehen müssen, um vertrauenswürdiges Reporting zu erstellen.

Entscheidungshilfe

Verwende folgende Reihenfolge, bevor eine Plattform gewählt oder geändert wird.

Ein kompaktes Scoring-Modell kann jeden Kandidaten von 1 bis 5 in folgenden Dimensionen bewerten:

Business Fit
Fit zur vorhandenen Landschaft
SQL-Fit
Python-/Spark-Fit
BI-Integration
Streaming- und ML-Fit
Governance-Fit
Security- und Residency-Fit
Teamkompetenz
Betriebsaufwand
Kostenplanbarkeit
Migrationsaufwand
Exit und Portabilität

Der Score wählt die Plattform nicht automatisch. Er macht Annahmen sichtbar und zwingt dazu, Zielkonflikte zu diskutieren.

Wichtigste Empfehlungen

1. Definiere die logischen Verantwortlichkeiten, bevor eine Plattform benannt wird.
2. Erhalte eine fachliche Granularität, Historienregel, Qualitätsrichtlinie und Verantwortung über alle Umsetzungen.
3. Beginne mit den Fähigkeiten, die bereits vorhanden sind und zuverlässig betrieben werden.
4. Behandle SQL Server und andere On-Premises-Warehouses als valide moderne Optionen, wenn sie zum Kontext passen.
5. Nutze Fabric, wenn OneLake, Data Factory, Warehouse/Lakehouse und Power-BI-Integration konkrete Anforderungen lösen.
6. Entscheide zwischen Fabric Lakehouse, Warehouse oder beidem anhand von Workload-Grenzen statt Plattformmode.
7. Halte Power-BI-Semantiklogik auf Modell- und Filterkontextverhalten fokussiert.
8. Halte Qlik-Skripte schlank und behalte nur begründete Qlik-spezifische Logik.
9. Gib Excel einen kontrollierten Vertrag, statt Anwender in manuelle Schattenprozesse zu zwingen.
10. Nutze Snowflake, wenn Cloud Warehouse, Workload-Isolierung, SQL-Modell und Data Sharing Mehrwert schaffen.
11. Nutze Databricks, wenn SQL, Spark, Python, Streaming, Engineering, Data Science oder ML eine gemeinsam governte Plattform benötigen.
12. Beschreibe Databricks nicht als Open-Source-On-Premises-Produkt.
13. Behandle dbt als optionale Projekt- und Governance-Schicht und nicht als Voraussetzung.
14. Nutze native Plattformfunktionen zuerst, wenn sie die Anforderung erfüllen und das Team sie betreiben kann.
15. Vermeide, dieselbe Geschäftsregel gleichzeitig in nativem SQL, Notebooks, dbt und BI-Tools umzusetzen.
16. Definiere in jeder Hybridarchitektur die autoritative Grenze.
17. Persistiere Qualitätsnachweise und Veröffentlichungsstatus unabhängig von Dashboards.
18. Validiere Migrationen mit abgestimmten fachlichen Ergebnissen und nicht nur mit erfolgreichen Jobs und Zeilenzahlen.
19. Beziehe Identity, Netzwerk, Monitoring, Deployment, Support und Incident Handling in die Plattformentscheidung ein.
20. Vergleiche vollständige Betriebskosten einschließlich Kompetenzen und Migration statt nur Lizenzpreise.
21. Plane die Stilllegung vor dem Cutover, damit parallele Implementierungen nicht dauerhaft bestehen bleiben.
22. Bewerte die Plattform neu, wenn sich Workload oder Betriebsmodell wesentlich ändern — nicht bei jeder neuen Produktfunktion.

Übergang zum nächsten Part

Eine Plattform auszuwählen und die logische Architektur zuzuordnen macht die Plattform nicht automatisch zuverlässig.

Der nächste Part, Plattform betreiben und governieren, behandelt Verantwortung, Deployment, Observability, Datenqualität, Sicherheit, Kostenkontrolle, Incident Handling, Lifecycle und die betrieblichen Kontrollen, die erforderlich sind, um jede dieser Umsetzungen in Produktion vertrauenswürdig zu halten.