Die einfachste tragfähige Architektur auswählen

Ein moderner Stack ist nicht automatisch die bessere Architektur

Moderne Datenplattformen bieten viele nützliche Funktionen: Pipelines, Dataflows, Warehouses, Lakehouses, Notebooks, Semantikmodelle, Streaming Engines, Kataloge, Test-Frameworks und Deployment-Automatisierung.

Dass diese Funktionen verfügbar sind, bedeutet nicht, dass jedes Warehouse alle davon benötigt.

Eine Architektur ist tragfähig, wenn sie die erforderlichen Geschäftsfragen zuverlässig beantwortet, Qualitäts- und Serviceerwartungen erfüllt, für das Team verständlich bleibt und ohne übermäßiges Risiko weiterentwickelt werden kann. Sie wird nicht allein dadurch besser, dass sie mehr Produkte enthält oder einem Referenzdiagramm eines Herstellers ähnelt.

Der richtige Ausgangspunkt lautet deshalb nicht:

Welche modernen Tools können wir miteinander kombinieren?

Sondern:

Welche ist die kleinste Architektur, die die Anforderung zuverlässig erfüllen kann?

Damit wird die Logik aus Bevor die erste Tabelle entsteht und Mehr als Bronze, Silver und Gold fortgeführt. Das erste Kapitel definierte die Entscheidungen, die vor der Umsetzung getroffen werden müssen. Das zweite Kapitel trennte die logischen Verantwortlichkeiten zwischen Quelle, Raw, Standardisierung, Integration, Datenprodukten und Nutzung. Dieses Kapitel bestimmt, wie viel physische Technologie zur Umsetzung dieser Verantwortlichkeiten tatsächlich erforderlich ist.

Die einfachste tragfähige Architektur ist nicht die Architektur mit den wenigsten Kästchen. Sie ist die Architektur mit der geringsten unnötigen Komplexität, die die Anforderung weiterhin erfüllt.

Architekturprinzip: Anforderungen bestimmen die Komplexität

Architekturkomplexität muss durch messbare Anforderungen begründet sein.

Die wichtigsten Treiber sind:

Diese Faktoren führen nicht automatisch zu einem bestimmten Produkt. Sie bestimmen, welche Fähigkeiten erforderlich sind.

Ein kleines Team mit zehn SQL-Modellen, einem täglichen Ladevorgang und zwei BI-Anwendungen benötigt möglicherweise eine disziplinierte SQL-Datenbank und keine Plattform mit mehreren Engines.

Ein größeres Team mit Hunderten voneinander abhängigen SQL-Modellen kann von modularer Entwicklung, Versionierung, automatisierten Tests und Deployment-Workflows profitieren.

Ein Workload mit hohen Event-Volumen, verteilter Transformation oder Machine Learning kann eine Spark-orientierte Plattform rechtfertigen.

Eine Microsoft-zentrierte Organisation kann mit einer integrierten Fabric-Umsetzung einfacher arbeiten als mit mehreren voneinander unabhängigen Services.

Ein stabiles On-Premises-Warehouse benötigt möglicherweise eine Modernisierung von Testing, Deployment und Schnittstellen statt eines Plattformwechsels.

Die einfachste Umsetzung, die funktionieren kann

Die minimale tragfähige Architektur sollte die logischen Verantwortlichkeiten aus dem vorherigen Kapitel umsetzen, ohne für jede Verantwortung ein separates Produkt einzuführen.

Für einen überschaubaren Batch-orientierten Anwendungsfall kann eine vorhandene SQL-Datenbank genügen:

Mehrere logische Verantwortlichkeiten können dieselbe Datenbank nutzen und dennoch durch Schemas, Namenskonventionen, Verantwortung und Deployment-Regeln klar getrennt bleiben.

Beispielsweise:

raw.order_lines
stg.order_lines
core.customer
core.product
mart.sales_daily
quality.test_results

Dieses Design ist einfach, aber nicht unkontrolliert. Es benötigt weiterhin:

• eine explizite Granularität;
• fachliche Verantwortung und technischer Betreiber-Verantwortung;
• wiederholbare Ladevorgänge;
• stabile Schlüssel;
• dokumentierte Transformationsregeln;
• Qualitätsprüfungen;
• Zugriffskontrolle;
• Ladeüberwachung;
• einen definierten Nutzungsvertrag;
• kontrollierte Änderungen.

Das Fehlen einer zusätzlichen Plattform hebt die Notwendigkeit architektonischer Disziplin nicht auf.

Konkretes Beispiel: tägliche Vertriebssteuerung

Angenommen, das Unternehmen benötigt ein governtes Datenprodukt für die tägliche Vertriebssteuerung mit folgenden Anforderungen:

Die minimale Architektur könnte verwenden:

• vorhandene Zeitplanung oder ETL für die Extraktion;
• SQL-Staging-Tabellen für empfangene Daten;
• SQL-Views oder gespeicherte Transformationen für die Standardisierung;
• konforme Kunden- und Produktdimensionen;
• einen Sales Fact auf Auftragszeilenebene;
• ein kuratiertes Datenprodukt sales_daily;
• eine Tabelle data_quality_results;
• einen schlanken Qlik Load;
• ein Power-BI-Semantikmodell oder eine Excel-Reporting-View, wo erforderlich.

Eine vereinfachte zentrale Transformation könnte so aussehen:

create or replace view mart.sales_daily as
select
    cast(o.order_date as date) as business_date,
    o.order_id,
    o.order_line_id,
    c.customer_key,
    p.product_key,
    c.country_code,
    o.gross_amount,
    o.cancellation_flag,
    case
        when o.cancellation_flag = 1 then 0
        else o.gross_amount
    end as net_revenue,
    o.changed_at
from core.order_line o
join core.customer_history c
  on o.customer_id = c.customer_id
 and o.order_date >= c.valid_from
 and o.order_date < coalesce(c.valid_to, date '9999-12-31')
join core.product_history p
  on o.product_id = p.product_id
 and o.order_date >= p.valid_from
 and o.order_date < coalesce(p.valid_to, date '9999-12-31');

Die Syntax muss an die jeweilige Datenbank angepasst werden. Architektonisch entscheidend ist die Platzierung der Regel:

• historische Kunden- und Produktzuordnungen werden zentral aufgelöst;
• die Nettoumsatzbasis wird einmal definiert;
• Qlik, Power BI und Excel erhalten dasselbe governte Ergebnis;
• Qualitätsfehler können vor der Nutzung ausgewertet werden.

Ein bewusst schlankes Qlik-Skript kann sich anschließend auf das Laden des vorbereiteten Produkts und wirklich Qlik-spezifische Benennungs- oder Assoziationslogik beschränken:

SalesDaily:
SQL SELECT
    business_date,
    order_id,
    order_line_id,
    customer_key,
    product_key,
    country_code,
    gross_amount,
    cancellation_flag,
    net_revenue,
    changed_at
FROM mart.sales_daily;

Qlik bleibt ein leistungsfähiger analytischer Nutzer. Es muss nicht zur versteckten Integrations- und Kennzahl-Engine werden, wenn wiederverwendbare Logik vorgelagert gepflegt werden kann.

Fünf gültige Startpunkte

Dieselbe logische Architektur kann mit unterschiedlichen nativen Fähigkeiten umgesetzt werden.

Startpunkt 1: Qlik und eine SQL-Datenbank

Das ist eine gültige Architektur, wenn:

• der Workload überwiegend Batch-orientiert ist;
• Transformationen hauptsächlich relational sind;
• die Anzahl der Modelle und Beteiligten beherrschbar bleibt;
• eine SQL-Datenbank bereits zuverlässig betrieben wird;
• Qlik, Power BI oder Excel vorbereitete Tabellen oder Views nutzen können;
• keine fortgeschrittene verteilte Verarbeitung erforderlich ist.

Eine praktikable Zuordnung ist:

Diese Option sollte nicht als veraltet abgelehnt werden. Sie sollte nur dann verworfen werden, wenn Skalierung, Zusammenarbeit, Betrieb oder Governance wirtschaftlich nicht ausreichend erfüllt werden können.

Startpunkt 2: Microsoft Fabric mit Qlik oder Power BI

Fabric kann die einfachste Option sein, wenn die Organisation überwiegend im Microsoft-Ökosystem arbeitet und von integrierten Funktionen für Ingestion, Transformation, Storage, Engineering und Reporting profitiert.

Mögliche Komponenten sind:

• Data-Factory-Pipelines oder Dataflows für Ingestion und Aufbereitung;
• ein Lakehouse oder Warehouse für verwalteten analytischen Storage;
• SQL oder Notebooks für Transformationen;
• governte Tabellen und Semantikmodelle für die Nutzung;
• Power BI als nativer Nutzer;
• Qlik oder Excel als Nutzer derselben kuratierten Ergebnisse über geeignete Schnittstellen.

Fabric hebt die Notwendigkeit logischer Grenzen nicht auf. Lakehouse, Warehouse und Semantikmodell sollten eingeführt werden, weil sie unterschiedliche Anforderungen erfüllen und nicht allein deshalb, weil sie verfügbar sind.

Eine kleine Fabric-Umsetzung benötigt möglicherweise nur einen Ingestion-Pfad, ein Warehouse oder Lakehouse, wenige Transformationen und ein governtes Datenprodukt. Eine Architektur mit doppelten Pipelines, Notebooks, SQL-Transformationen und semantischer Logik wird nicht allein dadurch einfacher, dass alle Services zu einer Plattform gehören.

Startpunkt 3: Snowflake mit BI-Tools

Snowflake kann geeignet sein, wenn die Hauptanforderung ein verwaltetes Cloud-Warehouse mit unabhängig skalierbarem Compute, SQL-basierter Transformation und governter Datenfreigabe oder Nutzung ist.

Eine minimale Snowflake-orientierte Umsetzung kann verwenden:

• kontrolliertes Laden in Landing- oder Staging-Schemas;
• SQL-Transformationen in Views, Tabellen, Tasks oder einem bereits vorhandenen Orchestrierungsmechanismus;
• Core- und Auswertungstabelle-Schemas;
• getrennte Compute-Konfigurationen für passende Workloads;
• Qlik, Power BI, Excel oder APIs als Nutzer.

dbt kann ergänzt werden, wenn es den Entwicklungsworkflow verbessert. Snowflake setzt dbt nicht voraus, und dbt setzt Snowflake nicht voraus. Die Architekturentscheidung lautet, ob modulare Modellabhängigkeiten, Code Reviews, automatisierte Tests, Dokumentation und teamorientiertes Deployment das zusätzliche Framework rechtfertigen.

Startpunkt 4: Databricks mit BI-Tools

Databricks kann geeignet sein, wenn der Workload tatsächlich von Lakehouse Storage, Spark-basierter verteilter Verarbeitung, Streaming, fortgeschrittenem Engineering oder Machine Learning profitiert.

Eine minimale Databricks-orientierte Umsetzung kann verwenden:

• kontrolliertes Landing von Dateien, Events oder Quellextrakten;
• Delta-Tabellen für verwaltete Datenzustände;
• SQL, Notebooks oder deklarative Pipelines für Transformationen;
• kuratierte Tabellen oder Datenprodukte;
• BI-Zugriff über governte SQL-Schnittstellen;
• ML oder Streaming nur dort, wo es benötigt wird.

Einige Millionen relationale Zeilen, die einmal täglich geladen werden, benötigen nicht automatisch Spark. Databricks schafft Mehrwert, wenn Verarbeitungsmuster, Skalierung, Datenvielfalt oder ML-Lebenszyklus ein Problem lösen, das eine einfachere SQL-Architektur nicht ausreichend bewältigen kann.

Startpunkt 5: ein bestehendes On-Premises-Warehouse

Ein stabiles On-Premises-Warehouse bleibt gültig, wenn es Business-, Sicherheits-, Latenz-, Resilienz- und Kostenanforderungen erfüllt.

Die Modernisierung kann sich konzentrieren auf:

• Verringerung von Logik, die in BI-Anwendungen dupliziert ist;
• versioniertes SQL;
• automatisierte Tests;
• bessere Metadaten und Lineage;
• Trennung von Core-Modellen und consumerspezifischen Views;
• verlässliche Deployment-Pfade;
• governte Schnittstellen für Qlik, Power BI und Excel;
• selektive Ergänzung von Cloud-Funktionen.

Ein Plattformwechsel ist gerechtfertigt, wenn die bestehende Umgebung eine wesentliche Einschränkung verursacht. Er ist nicht allein deshalb gerechtfertigt, weil die aktuelle Plattform nicht als modern bezeichnet wird.

Hybride Szenarien

Hybrid ist häufig kein vorübergehender Fehler. Es kann die einfachste tragfähige Architektur sein, wenn führende Systeme, Sicherheitsanforderungen, Datenresidenz, Latenz oder Migrationsreihenfolge unterschiedliche Standorte erfordern.

Eine kontrollierte Hybridarchitektur muss definieren:

• welches System für welches Objekt führend ist;
• wo Raw-Daten aufbewahrt werden;
• welche Transformationen On-Premises und welche in der Cloud stattfinden;
• wie Schlüssel und Historie konsistent bleiben;
• wie Daten Netzwerk- und Sicherheitsgrenzen überschreiten;
• wo Qualitätsergebnisse und Lineage zusammengeführt werden;
• welche Schnittstellen für Qlik, Power BI, Excel oder APIs stabil sind;
• wie doppelte Transformationslogik verhindert wird.

Hybrid wird problematisch, wenn beide Seiten dieselbe fachliche Bedeutung unabhängig voneinander implementieren. Das Ziel ist eine logische Architektur über mehrere physische Umgebungen und nicht zwei unkontrollierte Warehouses.

Wann ein weiteres Tool Mehrwert schafft

Ein weiteres Tool sollte erst ergänzt werden, wenn drei Fragen beantwortet werden können:

1. Welche konkrete Grenze besteht heute?
2. Welche Fähigkeit fehlt?
3. Löst die vorgeschlagene Komponente diese Grenze besser als eine Verbesserung der vorhandenen Plattform?

dbt wird interessant, wenn SQL-Entwicklung zum Teamproblem wird

dbt kann Mehrwert schaffen, wenn:

• viele SQL-Modelle voneinander abhängen;
• mehrere Entwickler an gemeinsamen Transformationen arbeiten;
• Pull Requests und Code Reviews erforderlich sind;
• wiederholbare Tests an Modelle gebunden werden sollen;
• Dokumentation und Abhängigkeiten konsistent erzeugt werden müssen;
• Deployments zwischen Umgebungen stärker strukturiert werden müssen.

dbt sollte nicht eingeführt werden, um zehn verständliche SQL-Views lediglich durch zehn dbt-Modelle zu ersetzen. Das Framework wird durch das Entwicklungs- und Governance-Problem gerechtfertigt, das es löst.

Fabric wird interessant, wenn Integration den Gesamt-Stack reduziert

Fabric kann Mehrwert schaffen, wenn:

• die Organisation bereits stark von Microsoft-Services abhängt;
• getrennte Services für Ingestion, Storage, Engineering und Reporting vermeidbare Übergaben erzeugen;
• eine governte Plattform Identität, Betrieb und Bereitstellung vereinfachen kann;
• die Power-BI-Integration strategisch wichtig ist;
• das Team die integrierte Plattform wirksamer betreiben kann als mehrere unabhängige Produkte.

Fabric ist nicht automatisch einfacher, wenn alle vorhandenen Services bestehen bleiben und Fabric zusätzlich darübergelegt wird, ohne Duplikate zu entfernen.

Snowflake wird interessant, wenn Cloud-Warehousing die tatsächliche Anforderung ist

Snowflake kann Mehrwert schaffen, wenn:

• elastisches oder isoliertes Warehouse Compute benötigt wird;
• SQL-basierte analytische Workloads eine verwaltete Cloud-Plattform benötigen;
• governte Freigabe und teamübergreifende Nutzung wichtig sind;
• der Betriebsaufwand einer selbst verwalteten Datenbank eine wesentliche Einschränkung darstellt;
• Workload-Trennung und Verbrauchsskalierung die Plattform rechtfertigen.

Snowflake sollte nicht allein deshalb ergänzt werden, weil die vorhandene SQL-Datenbank einen anderen Produktnamen trägt.

Databricks wird interessant, wenn verteilte Verarbeitung erforderlich ist

Databricks kann Mehrwert schaffen, wenn:

• sehr große Datenvolumen verteilte Verarbeitung erfordern;
• hochvolumige Events oder Streaming wesentliche Anforderungen sind;
• komplexe Dateien oder semi-strukturierte Daten den Workload dominieren;
• Data-Engineering- und Machine-Learning-Workflows auf derselben govern­ten Datengrundlage arbeiten sollen;
• Spark-orientierte Fähigkeiten und Betriebspraktiken vorhanden oder begründbar sind.

Eine Spark-Plattform ist kein Erfolgsmaßstab. Sie ist eine Antwort auf einen Workload.

Kein neues Tool ist eine gültige Entscheidung

Die bestehende Architektur beizubehalten kann richtig sein, wenn:

• Service Levels erfüllt werden;
• Kosten kontrolliert sind;
• Qualitäts- und Audit-Anforderungen erfüllt werden;
• das Team die Lösung versteht und warten kann;
• Skalierungserwartungen realistisch sind;
• Fachlogik wiederverwendbar ist und nicht in Reports eingeschlossen bleibt;
• die nächste Grenze noch nicht erreicht ist.

Die Begründungspflicht liegt bei der vorgeschlagenen Ergänzung und nicht bei der vorhandenen Komponente.

Eine praktische Entscheidungsmatrix

Die folgende Matrix übersetzt typische Situationen in angemessene Reaktionen.

Kosten bestehen nicht nur aus Lizenzkosten

Jede zusätzliche Komponente verursacht mehr als eine Subscription.

Die Architektur muss berücksichtigen:

• Plattformadministration;
• Integration von Identität und Zugriff;
• Netzwerke;
• Umgebungen;
• Deployment-Pipelines;
• Monitoring;
• Incident-Bearbeitung;
• Integration von Metadaten und Lineage;
• Backup und Wiederherstellung;
• Spezialkenntnisse;
• Hersteller- und Release-Management;
• duplizierten Storage oder Compute;
• zusätzliche Fehlergrenzen.

Eine Komponente kann sich trotzdem lohnen. Ihr Nutzen muss die vollständigen Lebenszykluskosten übersteigen.

Typische Fehlmuster

Eine Referenzarchitektur ohne deren Anforderungen kopieren

Herstellerdiagramme zeigen Fähigkeiten. Sie sind keine Vorgabe, jeden dargestellten Service einzusetzen.

Ein Tool pro logischer Schicht verwenden

Logische Verantwortlichkeiten benötigen nicht jeweils ein physisches Produkt. Raw, Standardisierung, Integration und Marts können getrennte Schemas in einer Datenbank sein.

dbt ergänzen, bevor Entwicklungskomplexität besteht

dbt kann modulare SQL-Entwicklung, Testing und Dokumentation verbessern. Es kann keinen Mehrwert erzeugen, wenn kein Problem bei Zusammenarbeit, Abhängigkeiten oder Delivery besteht.

Spark für gewöhnliche relationale Batch-Verarbeitung auswählen

Verteilte Verarbeitung führt neue Betriebs- und Entwicklungsmuster ein. Sie sollte für Workloads ausgewählt werden, die diese tatsächlich benötigen.

In die Cloud wechseln, ohne alte Komplexität zu entfernen

Eine Migration, bei der alte Pipelines, alte Kennzahl-Logik und alte Nutzer-Extrakte bestehen bleiben, erzeugt eine zusätzliche Plattform statt einer einfacheren Architektur.

Dieselbe Fachregel in jedem Nutzer neu entwickeln

Nettoumsatz, Kundenidentität, Länderzuordnung und Historie dürfen nicht unabhängig in Qlik, Power BI und Excel implementiert werden.

Integration als Produktfunktion statt als Betriebsmodell behandeln

Auch eine integrierte Plattform kann getrennte Teams, doppelte Pipelines und widersprüchliche Definitionen enthalten. Integration muss sich in Verantwortung, Entwicklung und Betrieb widerspiegeln.

On-Premises automatisch als veraltet ansehen

Ein stabiles On-Premises-Warehouse kann technisch und wirtschaftlich angemessen sein. Seine Schwächen müssen explizit bewertet und dürfen nicht allein aus seinem Standort abgeleitet werden.

Für eine nur angenommene zukünftige Skalierung entwerfen

Die Architektur sollte Wachstum ermöglichen, aber nicht bereits heute für einen Workload bezahlen, der möglicherweise nie entsteht. Skaliert wird, wenn eine glaubwürdige Prognose oder ein gemessener Trend dies begründet.

Wichtigste Empfehlungen

1. Beginne mit Business-Anforderungen und nicht mit Produktkategorien.
2. Trenne logische Architektur und physische Umsetzung.
3. Nutze vorhandene Werkzeuge und Fähigkeiten, wenn sie die Anforderung erfüllen.
4. Halte gemeinsame Fachlogik außerhalb einzelner Qlik-Apps, Power-BI-Reports und Excel-Arbeitsmappen.
5. Halte Qlik-Skripte so schlank wie praktisch möglich; nur tatsächlich notwendige Qlik-spezifische Logik bleibt dort.
6. Behandle SQL als gültige primäre Transformationsoption für relationale Workloads.
7. Ergänze dbt, wenn Modellabhängigkeiten, Testing und Team-Workflows es rechtfertigen.
8. Nutze Fabric, wenn eine integrierte Microsoft-Plattform die Gesamtarchitektur reduziert.
9. Nutze Snowflake, wenn verwaltetes elastisches Cloud-Warehousing eine konkrete Anforderung löst.
10. Nutze Databricks, wenn verteilte Verarbeitung, Streaming oder ML-Workloads es erfordern.
11. Modernisiere ein stabiles On-Premises-Warehouse, bevor du es standardmäßig ersetzt.
12. Bewahre in Hybridumgebungen eine logische Architektur und eine führende Definition fachlicher Bedeutung.
13. Berücksichtige Betrieb, Governance, Fähigkeiten und Lebenszykluskosten bei jeder Toolentscheidung.
14. Akzeptiere „Kein neues Tool erforderlich“ als legitime Architekturentscheidung.
15. Bewerte die Architektur neu, wenn sich Anforderungen ändern und nicht, wenn ein neues Produkt modern erscheint.