Ein modernes Data Warehouse aufbauen – von der ersten Quelle zu governten Datenprodukten

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

ze/Silver/Gold.

KMU/SMB — ein vertikales Produkt (Entscheidung, KPI, Grain, minimale Quellen) auf dem Stack, den ihr schon betreibt. Mid-Market — ein Domain-Produkt mit shared Layers und thin Consumers. Enterprise — Produktportfolio mit Plattform-Ops, Retirement und Cross-Tool-Verträgen.

Das Team kauft Fabric und lädt Salesforce breit. Zwölf Wochen später gibt es Schichten und Pipelines, aber keine freigegebene Antwort auf „offene Pipeline nach Stage und Owner“.

Die Architektur folgt der Entscheidung: KPI, Grain, Quellen, Qualität und Verantwortung zuerst; Tools danach.

Die Serie Ein modernes Data Warehouse aufbauen gibt dir den Einstieg und den roten Faden für die folgenden Teile.

Ausgangslage

Moderne Data Warehouses aus Entscheidungen — Grain, Quellen, Schichten und BI.

Was diese Serie klärt

• Orientierung: Bevor die erste Tabelle entsteht
• Vertiefung: Mehr als Bronze, Silver und Gold
• Abschluss mit betreibbaren Next Steps über Vom Stakeholder-Interview zum Tabellenmodell

Begriffe und Kürzel vor dem Lesen

• BI — Business Intelligence: Reporting- und Analyseflächen, die governte Kennzahlen und Datenprodukte nutzen.
• verantwortliche Person — Person oder Rolle mit der Pflicht, Bedeutung, Nutzung, Risiko und Freigabe für ein Datenprodukt oder eine Kennzahl zu entscheiden.
• Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Aktualität, Qualität, Klassifikation, Lineage, Status.
• Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien — eine Anwendung von Metadata, nicht Metadata selbst.
• Nachweis — Nachweis, dass Kontrolle, Entscheidung oder Test stattfand — Zeitstempel, verantwortliche Person, prüfbare Artefakte.
• Data Vereinbarung — Vereinbarung zwischen Anbieter und Nutzer: Felder, Bedeutung, Qualität, Aktualität, Änderungsvorlauf, Kontakte.

Lesepfad

1. Bevor die erste Tabelle entsteht
2. Mehr als Bronze, Silver und Gold
3. Die einfachste tragfähige Architektur auswählen
4. Ein Warehouse von Grund auf aufbauen
5. Ein bestehendes Warehouse modernisieren
6. Fachliche Logik außerhalb der BI-Apps halten
7. Ein Datenprodukt, mehrere Consumer
8. Optionen für Datentransformationen
9. Eine Architektur – mehrere Plattformen
10. Die Datenplattform betreiben und steuern
11. Vom Stakeholder-Interview zum Tabellenmodell

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.

Warum Architektur Klarheit braucht

Typische Warehouse-Initiativen beginnen mit Fragen wie:

• Welche Cloud-Plattform sollen wir nutzen?
• Benötigen wir Bronze, Silver und Gold?
• Welches Ingestion-Tool soll die Quellsysteme laden?
• Brauchen wir ein Lakehouse, ein Warehouse oder beides?
• Welches BI-Tool soll zum Standard werden?

Diese Fragen sind berechtigt, aber sie sind nicht die ersten Fragen.

Bevor eine Plattform bewertet werden kann, muss das Team verstehen, welches Ergebnis die Lösung liefern soll. Andernfalls wird die Architektur für ein noch nicht definiertes Problem optimiert. Daraus entstehen häufig vorhersehbare Folgen:

• Zu viele Quellen werden geladen, bevor ihr Zweck bekannt ist.
• Pipelines werden für Daten gebaut, die kein Nutzer benötigt.
• Fachlogik wird in Qlik-Skripten, Power-BI-Modellen, Excel-Dateien, SQL-Views und Notebooks dupliziert.
• Ähnliche Tabellen werden für unterschiedliche Reports mehrfach erzeugt.
• Datenqualität wird erst geprüft, nachdem Nutzer Fehler gefunden haben.
• Niemand ist eindeutig für den KPI oder das Datenprodukt verantwortlich.
• Die Plattform wächst in die Breite, während das Vertrauen niedrig bleibt.

Architekturprinzip: Entscheidungen zuerst, Umsetzung zuletzt

Die architektonische Reihenfolge sollte lauten:

1. Business-Entscheidung definieren.
2. KPI und fachliche Bedeutung definieren.
3. Granularität festlegen.
4. Nur die benötigten Quellen und Felder identifizieren.
5. Aktualität und Historisierung festlegen.
6. Qualität, Sicherheit und Verantwortung definieren.
7. Das kleinste vollständige Datenprodukt bauen.
8. Die Umsetzung anhand des tatsächlichen Bedarfs auswählen oder erweitern.

Technologie ist dabei nicht unwichtig. Sie wird später ausgewählt, weil ihre Eignung erst anhand klarer Anforderungen sinnvoll beurteilt werden kann.

Ein Datenprodukt für die tägliche Vertriebssteuerung benötigt vielleicht eine tägliche Aktualisierung, moderate Datenmengen und eine governte SQL-Tabelle. Ein operativer Near-Real-Time-Anwendungsfall kann dagegen Streaming, Event-Verarbeitung und andere Service Levels erfordern. Die Architektur folgt dem Entscheidungskontext.

Mit einem vertikalen Datenprodukt starten

Die erste sinnvolle Lieferung sollte vertikal statt breit sein.

Ein vertikales Datenprodukt verbindet eine Business-Frage mit allen technischen Schritten, die für ihre Beantwortung erforderlich sind:

Dieser vollständige Pfad ist wertvoller als eine breite, aber unfertige Plattform. Er beweist, dass das Team Daten von der Quelle bis zur Entscheidung liefern kann – einschließlich Verantwortung, Qualität und Nutzung.

Das Ziel ist nicht das kleinstmögliche technische Objekt. Das Ziel ist der kleinste sinnvolle, vertrauenswürdige und wiederverwendbare Umfang.

Ein Minimum Viable Data Product sollte daher:

• auf eine konkrete Entscheidung fokussiert sein;
• ausschließlich die benötigten Daten verwenden;
• von Beginn an governte Strukturen besitzen;
• möglichst von mehreren Consumern wiederverwendbar sein;
• nicht von einer einzelnen BI-Anwendung abhängig sein;
• bei einem realen Bedarf erweiterbar bleiben.

Konkretes Beispiel: tägliche Vertriebssteuerung

Angenommen, das Business möchte folgende Frage beantworten:

Wie entwickelt sich der tägliche Nettoumsatz nach Kunde, Produkt und Land unter Berücksichtigung von Stornierungen und nachträglichen Änderungen?

Bevor die erste Tabelle erzeugt wird, müssen die folgenden Entscheidungen getroffen werden.

Diese Entscheidungen bestimmen das technische Modell.

Ein erstes praktisches Datenprodukt könnte folgende Felder enthalten:

Die zentrale Fachregel könnte einmalig in SQL umgesetzt werden:

select
    cast(order_date as date) as business_date,
    order_id,
    order_line_id,
    customer_id,
    product_id,
    country_code,
    gross_revenue,
    cancellation_flag,
    case
        when cancellation_flag = 1 then 0
        else gross_revenue
    end as net_revenue,
    changed_at
from standardized_order_lines;

Die konkrete Syntax ist nicht der architektonisch entscheidende Punkt. Relevant ist, dass die Nettoumsatz-Regel zentral definiert und von allen Consumern wiederverwendet wird.

Wo die Logik liegen sollte

Nicht jede Transformation gehört in dieselbe Schicht. Die folgende Zuordnung hält die Lösung nachvollziehbar.

Die Kernregel ist einfach: Logik, die die Bedeutung gemeinsam genutzter Daten definiert, darf nicht versteckt in einem einzelnen Report oder einer einzelnen Anwendung liegen.

Die einfachste tragfähige Umsetzung

Eine moderne Architektur benötigt nicht automatisch eine große Tool-Landschaft.

Für einen kleinen oder frühen Anwendungsfall kann folgende Kombination bereits ausreichen:

• eine vorhandene SQL-Datenbank;
• ein geplanter Ladeprozess oder ein bestehendes ETL-Verfahren;
• eine standardisierte Quelltabelle oder View;
• ein kuratiertes Vertriebsdatenprodukt;
• wenige automatisierte Qualitätsprüfungen;
• Qlik, Power BI oder Excel als Nutzer desselben govern­ten Ergebnisses.

Beispiel:

Diese Lösung ist ausreichend, wenn Datenvolumen, Teamgröße, Betriebsrisiko und Änderungsrate beherrschbar bleiben. Eine Plattform sollte erst erweitert werden, wenn die aktuelle Umsetzung eine reale Grenze erreicht.

Umsetzungsalternativen nach vorhandener Umgebung

Es stehen nur Qlik und SQL Server zur Verfügung

SQL Server übernimmt wiederverwendbare Transformationen, KPI-Regeln, Historisierung und Qualitätsergebnistabellen. Qlik lädt das vorbereitete Datenprodukt und enthält nur Qlik-spezifische Logik, die upstream nicht sinnvoller umgesetzt werden kann.

Ein bewusst dünner Qlik-Load könnte so aussehen:

SalesDaily:
LOAD
    business_date,
    order_id,
    order_line_id,
    customer_id,
    product_id,
    country_code,
    net_revenue,
    quality_status
FROM [lib://GovernedData/sales_daily.qvd] (qvd);

Die Qlik-App ist damit Consumer und nicht der versteckte Owner der unternehmensweiten KPI-Definition.

Microsoft Fabric mit Qlik oder Power BI

Die vorhandenen Fabric-Komponenten können Ingestion, Standardisierung, Tests und Veröffentlichung des Vertriebsdatenprodukts übernehmen. Qlik und Power BI konsumieren dasselbe kuratierte Ergebnis. Die architektonische Anforderung bleibt gleich: KPI-Definition und gemeinsam genutzte Transformationslogik dürfen nicht unabhängig in jedem Report neu aufgebaut werden.

Snowflake ist bereits vorhanden

Snowflake kann als zentrale Ausführungs- und Speicherplattform für das benötigte Datenprodukt dienen. Zu Beginn werden nur die Schemas und Transformationen umgesetzt, die der Vertriebsanwendungsfall tatsächlich benötigt. dbt wird erst ergänzt, wenn modulare Modelle, Tests, Dokumentation, Abhängigkeitsmanagement oder Zusammenarbeit ein konkretes Problem besser lösen als der vorhandene Ansatz.

Databricks ist bereits vorhanden

Databricks kann Ingestion, Standardisierung, Transformation und Qualitätsprüfungen übernehmen, wenn es bereits die etablierte Plattform ist. Eine Lakehouse-Struktur kann das Datenprodukt unterstützen. Das Projekt beginnt dennoch mit Entscheidung, Granularität, KPI und Verantwortung und nicht automatisch mit breiten Bronze-, Silver- und Gold-Schichten für jede Quelle.

Ein klassisches On-Premises-Warehouse ist vorhanden

Das bestehende Warehouse wird um einen fokussierten Vertriebsfakt und die benötigten konformen Dimensionen erweitert. Vorhandene Scheduler, SQL-Prozeduren, Views oder ETL-Tools können vollständig ausreichen. Eine Cloud-Migration ist keine Voraussetzung für ein governtes Datenprodukt.

Greenfield und Brownfield benötigen unterschiedliche Startmaßnahmen

Greenfield

In einer Greenfield-Umgebung besteht das Risiko im Over-Engineering. Das Team versucht möglicherweise, die vollständige zukünftige Plattform zu entwerfen, bevor ein erstes Ergebnis geliefert wird.

Der bessere Ansatz:

• einen wertvollen Anwendungsfall auswählen;
• die kleinste durchgängige Architektur definieren;
• Konventionen für Benennung, Verantwortung, Tests und Dokumentation festlegen;
• das Muster nachweisen;
• erst nach einem funktionierenden ersten Produkt erweitern.

Brownfield

In einer Brownfield-Umgebung besteht das Risiko in unkontrollierter Duplizierung. Vorhandene Reports und Skripte enthalten häufig widersprüchliche Versionen desselben KPI.

Der bessere Ansatz:

• vorhandene Reports und Logik für die Business-Frage identifizieren;
• Definitionen vergleichen und Unterschiede dokumentieren;
• eine verbindliche Definition und einen verantwortliche Person bestimmen;
• wiederverwendbare Logik in ein zentrales Modell überführen;
• Nutzer schrittweise migrieren;
• duplizierte Logik nach erfolgreicher Validierung stilllegen.

Brownfield-Modernisierung bedeutet nicht, alles gleichzeitig zu ersetzen. Sie bedeutet, einen vertrauenswürdigen Pfad zu etablieren und Abweichungen schrittweise zu reduzieren.

Typische Anti-Patterns

Alle Quellen laden, bevor der Anwendungsfall definiert ist

Dadurch entsteht Datenverfügbarkeit ohne Entscheidungswert. Geladen wird nur, was das erste Produkt benötigt. Die Architektur bleibt dennoch für spätere Quellen offen.

Bronze, Silver und Gold als vollständige Business-Architektur behandeln

Diese Schichten können die technische Verarbeitung strukturieren. Sie definieren jedoch weder KPI-Bedeutung noch Verantwortung, Consumer, Sicherheit oder Serviceerwartungen.

Fachlogik unabhängig in jedem BI-Tool entwickeln

Dieselbe Stornoregel darf nicht getrennt in Qlik, Power BI, Excel und SQL implementiert werden. Gemeinsame Bedeutung gehört in eine gemeinsame Schicht.

Auf die perfekte Zielarchitektur warten

Ein vollständiges Enterprise-Zielbild kann die Richtung vorgeben, darf aber ein sinnvolles erstes Produkt nicht blockieren. Das erste Muster muss zur Zielrichtung passen und erweiterbar sein.

dbt, Snowflake, Databricks oder Fabric ohne definierten Bedarf einführen

Jede dieser Plattformen kann wertvoll sein. Keine sollte nur deshalb ergänzt werden, weil sie als modern gilt. Neue Komponenten müssen ein identifiziertes Problem bei Skalierung, Wartbarkeit, Governance, Zusammenarbeit oder Performance lösen.

Verantwortung erst nach der Lieferung klären

Ohne Verantwortliche bleiben KPI-Konflikte und Qualitätsfehler ungelöst. Verantwortung ist Bestandteil der Produktdefinition und kein nachgelagerter Verwaltungsprozess.

Die Entscheidungen vor der ersten Pipeline

Die erste Pipeline sollte erst entworfen werden, nachdem fachliche, technische und organisatorische Entscheidungen explizit getroffen wurden.

Diese Entscheidungen benötigen keine monatelange Dokumentation. Für das erste Datenprodukt reicht ein kompakter Entscheidungsnachweis, wenn er eindeutig, freigegeben und gepflegt ist.

Das praktische Minimum enthält:

• Business-Frage und primären Nutzer;
• KPI-Definition und Ausschlüsse;
• Granularität und Umfang;
• benötigte Quellen und führendes System;
• Aktualität und Historisierung;
• verpflichtende Qualitätsregeln und Schwellwerte;
• Sicherheitsklassifikation und Zugriff;
• Data Owner (Alias Business Owner);
• Lieferziel und erwartetes Service Level.

Entscheidungshilfe

Verwende die einfachste Architektur, die die expliziten Anforderungen erfüllt.

Das entscheidende Kriterium ist nicht das Prestige einer Plattform. Entscheidend ist, ob die Umsetzung mit vertretbarem Aufwand, Risiko und Wartungsbedarf eine vertrauenswürdige Antwort liefert.

Wichtigste Empfehlungen

1. Mit einer Business-Entscheidung starten, nicht mit einer Plattform.
2. KPI und Granularität vor dem Tabellenentwurf definieren.
3. Nur die Quellen und Felder laden, die für das erste Produkt benötigt werden.
4. Aktualität, Historisierung, Qualität, Sicherheit und Verantwortung vor der Umsetzung klären.
5. Gemeinsam genutzte Fachlogik außerhalb einzelner BI-Anwendungen platzieren.
6. Qlik-Skripte und reportspezifische Transformationen so dünn wie sinnvoll halten.
7. Vorhandene Tools nutzen, bis eine konkrete Grenze eine Erweiterung rechtfertigt.
8. Ein vollständiges vertikales Datenprodukt liefern, bevor die Plattform verbreitert wird.
9. Governance als Bestandteil des ersten Releases behandeln und nicht als spätere Phase.
10. Über bewährte Produkte erweitern statt über spekulativ aufgebaute Infrastruktur.

Übergang zum nächsten Part

Dieser Part hat geklärt, welche Entscheidungen getroffen werden müssen, bevor die erste Tabelle oder Pipeline entsteht. Grain und Keys so wählen, dass die nächste Domain joinen kann — Korridor für Folgeprojekte. Im nächsten Schritt werden diese Entscheidungen in eine konkrete Source-to-Product-Architektur übersetzt.

Ein nützliches Muster ist noch keine vollständige Architektur

Bronze / Silver / Gold (Medallion) benennt grobe Reifestufen — es ersetzt keine Warehouse-Architektur mit klaren Verantwortlichkeiten für Rohzustand, Integration, Kennzahlen und Consumer-Verträge.

Das Team labelt alles „Gold“, was im Dashboard landet. Nettoumsatz und Roh-Opportunity sitzen in derselben Schicht; Verantwortung und Tests fehlen. Das Muster klingt fertig, die Architektur nicht.

Bronze, Silver und Gold sind nützliche Bezeichnungen. Das Muster vermittelt eine Entwicklung:

Bronze steht meist für quellnahe Daten. Silver bezeichnet üblicherweise bereinigte oder transformierte Daten. Gold beschreibt Daten, die für die fachliche Nutzung vorbereitet sind.

Das ist ein praktikabler Einstieg, beantwortet aber nicht präzise genug die Architekturfragen, die darüber entscheiden, ob ein Warehouse verständlich, wiederverwendbar und governbar bleibt.

Unter der Bezeichnung Gold können mehrere grundsätzlich verschiedene Themen liegen:

• integrierte Unternehmensdaten;
• historisierte fachliche Entitäten;
• konforme Fakten und Dimensionen;
• KPI-fähige Datensätze;
• fachbereichsspezifische Marts;
• für Qlik optimierte Views;
• Power-BI-Semantikmodelle;
• Excel-Reporting-Views;
• Extrakte für einen einzelnen Bericht oder eine einzelne Anwendung.

Diese Objekte besitzen nicht denselben Zweck, dieselbe Granularität, dieselbe Verantwortung, denselben Lebenszyklus oder dasselbe Wiederverwendungspotenzial. Werden sie gemeinsam in einer groben Gold-Schicht abgelegt, bleiben Entscheidungen verborgen, die explizit sein sollten.

Bronze, Silver und Gold sind nützliche technische Kategorien. Für die logische Architektur eines echten Warehouses reichen sie nicht aus.

Part 1 dieser Serie, Bevor die erste Tabelle entsteht, hat festgelegt, dass die Architektur mit Business-Entscheidung, KPI, Granularität, Quellen, Qualitätsanforderungen und Verantwortung beginnt. Dieser Part überführt diese Entscheidungen in einen präziseren Lebenszyklus von der Quelle bis zur Nutzung.

Architekturprinzip: Verantwortlichkeiten statt Werkzeuge trennen

Eine logische Schicht sollte eine stabile Verantwortung im Datenlebenszyklus beschreiben. Sie sollte nicht lediglich den Namen eines Produkts, einer Engine oder einer Speichertechnologie wiederholen.

Ein praktikabler Warehouse-Lebenszyklus lässt sich so ausdrücken:

Die Grenzen sind relevant, weil jede Schicht eine andere Frage beantwortet.

Diese Struktur ist logisch und nicht vorschreibend. Eine kleine Umsetzung kann mehrere Verantwortlichkeiten in einer Datenbank realisieren. Eine große Umsetzung kann getrennte Schemas, Speicherzonen, Compute Engines oder Deployment-Pipelines verwenden.

Das Ziel ist nicht die maximal mögliche Anzahl physischer Schichten. Das Ziel besteht darin, Verantwortlichkeiten so klar zu machen, dass Logik bewusst platziert wird.

Der vollständige Warehouse-Lebenszyklus

Ein modernes Warehouse besteht nicht nur aus einer Folge von Speicherbereichen. Datenqualität, Governance, Sicherheit, Lineage, Observability und Delivery-Praktiken gelten über den gesamten Lebenszyklus.

Quellsysteme

Quellsysteme bleiben für operative Prozesse wie Kundenpflege, Auftragserfassung, Fakturierung, Produktverwaltung oder Ereigniserzeugung verantwortlich.

Sie sind keine Warehouse-Schichten. Sie sind die Systeme, aus denen der analytische Lebenszyklus Daten erhält.

Typische Quellen sind:

• ERP- und CRM-Systeme;
• operative Datenbanken;
• Dateien und Tabellenkalkulationen;
• APIs;
• Event Streams;
• externe Referenzdaten;
• manuell gepflegte Klassifikationen.

Das Warehouse sollte führendes System, Extraktionsmechanismus, Quellzeitstempel, Quellschlüssel und erwartetes Lieferverhalten dokumentieren.

Landing / Raw

Die Landing- oder Raw-Schicht bewahrt die von der Quelle empfangenen Daten mit möglichst geringen semantischen Änderungen.

Typische Verantwortlichkeiten sind:

• unveränderte oder nur minimal veränderte Übernahme;
• Quell- und Ladezeitstempel;
• Batch-, Datei- oder Event-Kennungen;
• Quellmetadaten;
• Nachvollziehbarkeit bis zum empfangenen Payload;
• kontrollierte Aufbewahrung oder Wiederholbarkeit;
• technische Quarantäne nicht lesbarer Eingaben.

Diese Schicht ist nicht der Ort für einen Golden Customer, eine Net-Revenue-KPI oder eine fachliche Hierarchie. Ihr Zweck sind Nachweisbarkeit und Wiederherstellbarkeit.

Eine Raw-Schicht erfordert nicht zwingend einen Data Lake. Sie kann mit Datenbanktabellen, Dateien, Object Storage, Delta-Tabellen oder einem anderen kontrollierten Landing-Mechanismus umgesetzt werden.

Standardisiert / Validiert

Die standardisierte oder validierte Schicht überführt quellspezifische Strukturen in technisch konsistente Daten.

Typische Verantwortlichkeiten sind:

• Konvertierung von Datentypen;
• Normalisierung von Datums-, Zahlen- und Zeichencodierungen;
• Harmonisierung von Spaltennamen und Strukturen;
• Prüfung verpflichtender Felder;
• Domain- und Referenzvalidierung;
• Standardisierung von Länder- oder Währungscodes;
• Erkennung möglicher Dubletten;
• Validierungskennzeichen und Ablehnungsgründe.

Diese Schicht beantwortet, ob Daten konsistent verarbeitet werden können. Sie entscheidet noch nicht, ob zwei Quelldatensätze denselben realen Kunden repräsentieren oder welche historische Kundenversion zu einem Verkauf gehört.

Integrierter Kern

Der integrierte Kern bildet gemeinsam genutzte fachliche Entitäten und Beziehungen über mehrere Quellen ab.

Typische Verantwortlichkeiten sind:

• unternehmensweite Business Keys;
• Zuordnung von Quell- zu Unternehmensschlüsseln;
• Golden Records;
• Konsolidierung von Stammdaten;
• Historisierung und Slowly Changing Dimensions;
• gültig-von-/gültig-bis-Beziehungen;
• konforme Kunden-, Produkt- und Organisationsstrukturen;
• integrierte Fakten mit stabiler Granularität;
• wiederverwendbare Regeln zur Definition gemeinsamer fachlicher Bedeutung.

Im integrierten Kern können ein CRM-Kunde und ein ERP-Kunde zu einer govern­ten Kundenidentität zusammengeführt werden. Dort werden auch historische Zuordnungen erhalten, wenn Berichte eine As-was-Sicht benötigen.

Diese Schicht sollte unabhängig von einem einzelnen Dashboard bleiben. Ihre Objekte sind wiederverwendbare Bausteine.

Fachliche Datenprodukte / Marts

Ein fachliches Datenprodukt bündelt governte Daten für einen definierten Business-Zweck.

Typische Verantwortlichkeiten sind:

• Fakten und Dimensionen für einen Themenbereich;
• explizite Granularität;
• KPI-Basisspalten;
• kuratierte Attribute;
• dokumentierte Filter und Ausschlüsse;
• Qualitätsstatus;
• Business Owner und technischer Betreiber;
• Aktualitäts- und Service-Erwartungen;
• stabile Schnittstellen für nachgelagerte Nutzer.

Beispiele sind:

• Täglicher Vertrieb;
• Customer 360;
• Produktrentabilität;
• Vertragsportfolio;
• Data-Quality-Ergebnisse.

Ein Datenprodukt ist nicht lediglich der Name eines Schemas. Es verbindet Daten, Semantik, Verantwortung, Qualität und einen definierten Nutzungsvertrag.

Nutzungsverträge / Semantikmodelle

Die Nutzungsschicht passt governte Datenprodukte an die Zugriffsmuster konkreter Werkzeuge und Nutzergruppen an.

Typische Verantwortlichkeiten sind:

• für Qlik optimierte Präsentations-Views oder governte QVD-Extrakte;
• Power-BI-Semantikmodelle und Präsentations-Measures;
• Excel-Reporting-Views;
• governte Spaltennamen und Beschreibungen;
• zeilen- oder objektbasierte Zugriffssteuerung, falls erforderlich;
• stabile Schnittstellen und Kompatibilitätszusagen;
• Last-Mile-Berechnungen, die tatsächlich consumerspezifisch sind.

Die zentrale KPI-Bedeutung sollte bereits vorgelagert existieren. Ein Semantikmodell kann Formatierung, Berechnungsgruppen, Anzeigehierarchien oder interaktionsspezifische Measures ergänzen, sollte aber nicht unbemerkt die Unternehmens-KPI neu definieren.

Gemeinsame Bedeutung gehört so weit nach links wie sinnvoll. Werkzeugspezifisches Verhalten gehört nur so weit nach rechts wie nötig.

Was gehört in welche Schicht?

Die Zuordnung wird klarer, wenn ein durchgängiges Kunden- und Vertriebsbeispiel betrachtet wird.

Konkretes Kunden- und Vertriebsbeispiel

Angenommen, das Unternehmen erhält Kundendaten aus einem CRM-System und Verkaufsaufträge aus einem ERP-System.

Das Business möchte analysieren:

Nettoumsatz nach Kunde, Land und Monat unter Verwendung der Kundenmerkmale, die zum Zeitpunkt des Auftrags gültig waren.

Die benötigte Logik umfasst:

• eine gültige Customer ID;
• standardisierte Länder;
• Dublettenerkennung;
• einen Golden Customer;
• historische Kundenattribute;
• einen Umsatz-Fact auf Auftragszeilenebene;
• eine zentral definierte Nettoumsatzbasis;
• Qlik, Power BI und Excel als mögliche Nutzer.

Quellsysteme

Das CRM liefert Kundendatensätze:

Das ERP liefert Auftragszeilen:

In den Quellsystemen sollte keine Warehouse-Logik ergänzt werden, nur damit ein einzelner Bericht funktioniert.

Landing / Raw

Die empfangenen Zeilen werden mit technischen Metadaten gespeichert:

source_system
source_object
source_file_or_batch_id
ingested_at
source_changed_at
raw_payload_or_source_columns

Die Länderwerte bleiben exakt wie geliefert: DE, Germany, NL.

Auch die beiden Datensätze zu Alpha Systems bleiben getrennt. Raw bewahrt den Nachweis und entscheidet nicht, ob es sich um Dubletten handelt.

Standardisiert / Validiert

Das standardisierte Kundenmodell kann:

• crm_customer_id in einen einheitlichen Textdatentyp überführen;
• Namen trimmen und normalisieren;
• DE und Germany auf den ISO-Ländercode DE abbilden;
• prüfen, ob die Customer ID vorhanden ist;
• einen Schlüssel für mögliche Dubletten erzeugen;
• Validierungskennzeichen vergeben.

Eine vereinfachte SQL-View kann so aussehen:

select
    trim(cast(crm_customer_id as varchar(50))) as customer_id,
    trim(customer_name) as customer_name,
    case
        when upper(trim(country)) in ('DE', 'GERMANY', 'DEUTSCHLAND') then 'DE'
        when upper(trim(country)) in ('NL', 'NETHERLANDS', 'NIEDERLANDE') then 'NL'
        else null
    end as country_code,
    trim(segment) as segment,
    changed_at,
    case
        when crm_customer_id is null then 'INVALID_CUSTOMER_ID'
        when country is null then 'INVALID_COUNTRY'
        else 'VALID'
    end as validation_status
from raw_crm_customer;

Die genaue SQL-Syntax kann sich je Plattform unterscheiden. Der architektonische Punkt ist, dass technische Standardisierung wiederverwendbar und sichtbar erfolgt.

Integrierter Kern

Der integrierte Kern löst Identität und Historie auf.

Beispiel:

C-100 und C-101 werden nach einer govern­ten Matching-Entscheidung demselben Golden Customer EC-001 zugeordnet.

Die historische Kundendimension kann enthalten:

Hier wird die historische Beziehung explizit. Ein Verkauf am 18.03.2026 verwendet Kundenversion 1001; ein späterer Verkauf nach dem 01.04.2026 verwendet 1002.

Fachliches Datenprodukt / Mart

Das Vertriebsdatenprodukt stellt eine Zeile je Auftragsposition mit govern­ten Schlüsseln und KPI-Basen bereit.

select
    s.order_id,
    s.line_id,
    s.order_date,
    c.customer_sk,
    c.enterprise_customer_id,
    c.country_code,
    c.segment,
    s.amount as gross_revenue,
    s.cancellation_flag,
    case
        when s.cancellation_flag = 1 then 0
        else s.amount
    end as net_revenue,
    s.quality_status
from standardized_sales_line s
join customer_key_map m
  on m.source_system = s.source_system
 and m.source_customer_id = s.customer_id
join dim_customer_history c
  on c.enterprise_customer_id = m.enterprise_customer_id
 and s.order_date >= c.valid_from
 and s.order_date < c.valid_to;

Das Datenprodukt definiert:

Granularität: eine ERP-Auftragszeile
Data Owner (Alias Business Owner): Vertriebscontrolling, Scope Kunden- und Vertriebsdomäne
Aktualisierung: täglich vor 07:00 Uhr
Verpflichtende Qualität: gültiger Auftrag, Kunde, Land, Betrag und Änderungszeitstempel
Consumer: Qlik, Power BI, Excel und freigegebene operative Extrakte

Die Basis net_revenue wird damit nicht unabhängig in jeder BI-Anwendung neu erstellt.

Nutzungsverträge

Die consumerspezifische Schicht kann bereitstellen:

• eine Qlik-View oder ein governtes QVD mit stabilen Feldnamen und optimierten Assoziationen;
• ein Power-BI-Semantikmodell mit Beziehungen, Formatierung und Präsentations-Measures;
• eine Excel-View mit fachlich verständlichen Spalten und eingeschränktem Detailzugriff.

Ein bewusst schlanker Qlik-Load kann so aussehen:

Sales:
LOAD
    order_id,
    line_id,
    order_date,
    customer_sk,
    enterprise_customer_id,
    country_code,
    segment,
    gross_revenue,
    cancellation_flag,
    net_revenue,
    quality_status
FROM [lib://GovernedData/sales_data_product.qvd] (qvd);

Qlik darf weiterhin Qlik-spezifische Logik enthalten, wenn sie erforderlich ist, etwa anwendungsspezifische Assoziationen, die Integration von Section Access oder tatsächlich interaktive Berechnungen. Qlik sollte jedoch nicht zum versteckten Ablageort für gemeinsam genutztes Kunden-Matching, Historisierung oder KPI-Definitionen werden.

Ein Power-BI-Semantikmodell kann dieselben govern­ten Fakten und Dimensionen verwenden. Excel kann eine kontrollierte Reporting-View nutzen. Unterschiedliche Consumer benötigen keine unterschiedlichen fachlichen Wahrheiten.

Die einfachste tragfähige Umsetzung

Eine präzise logische Architektur erfordert weder sechs unterschiedliche Technologien noch sechs Datenbanken.

Für ein kleines Team mit vorhandener SQL-Datenbank kann der gesamte Lebenszyklus mit Schemas und Views umgesetzt werden:

Quellreferenzen
Raw-Tabellen
standardisierte Views
Core-Tabellen
Mart-Tabellen oder -Views
Consumer-Views

Eine minimale physische Struktur kann so aussehen:

raw.crm_customer
raw.erp_sales_line

standardized.customer
standardized.sales_line

core.customer_key_map
core.dim_customer_history

mart.fact_sales
mart.dim_customer

consumption.qlik_sales
consumption.powerbi_sales
consumption.excel_sales

Dieselbe Datenbank kann alle Objekte enthalten. Getrennte Schemas und Namenskonventionen können ausreichen, um die logischen Grenzen zu erhalten.

Zum Minimum gehören außerdem Querschnittskontrollen:

• Protokollierung von Lade- und Transformationsläufen;
• eine kleine Menge automatisierter Qualitätsprüfungen;
• Verantwortung-Metadaten;
• Zugriffssteuerung;
• versionierte Skripte;
• ausreichende Lineage-Dokumentation, um eine KPI bis zu ihren Quellen zurückzuverfolgen.

Diese Architektur ist modern, weil Verantwortlichkeiten explizit und wiederverwendbar sind — nicht weil sie ein bestimmtes Cloud-Produkt enthält.

Alternative Umsetzungen nach vorhandener Plattform

Die logische Architektur bleibt stabil, während sich die physische Umsetzung ändert.

Das sind Beispiele und keine vorgeschriebenen Stack-Designs.

Klassisches SQL-Warehouse oder On-Premises

Vorhandene relationale Tabellen, Views, Prozeduren, Scheduler und ETL-Werkzeuge können weiterverwendet werden, wenn sie die Anforderungen erfüllen. Eine logische Trennung über Schemas, Benennung und Deployment-Konventionen kann ausreichen.

Ein Plattformwechsel ist nicht erforderlich, nur um über Bronze, Silver und Gold hinauszugehen.

Microsoft Fabric

Ist Fabric bereits die ausgewählte Umgebung, werden dieselben Verantwortlichkeiten auf die vorhandenen Speicher-, Transformations- und Bereitstellungskomponenten abgebildet. Es muss nicht automatisch für jede Quelle eine umfangreiche Drei-Zonen-Struktur entstehen, bevor ein fachliches Datenprodukt geliefert werden kann.

Qlik, Power BI und Excel können dasselbe kuratierte Produkt konsumieren, wenn dies betrieblich sinnvoll ist.

Snowflake

Ist Snowflake bereits vorhanden, können Schemas, Tabellen, Views und die bestehende Orchestrierungs- oder Transformationslösung die logischen Grenzen abbilden. dbt kann ergänzt werden, wenn modulare SQL-Modelle, Tests, Dokumentation und Abhängigkeitsmanagement ein konkretes Teamproblem besser lösen. dbt ist nicht allein deshalb erforderlich, weil Snowflake eingesetzt wird.

Databricks

Ist Databricks bereits etabliert, kann die Medallion-Terminologie für die technische Verarbeitung weiterhin nützlich sein. Die logische Architektur sollte trotzdem Standardisierung, unternehmensweite Integration, fachliche Datenprodukte und semantische Nutzung unterscheiden, statt alle kuratierten Objekte in einer undifferenzierten Gold-Zone zusammenzufassen.

dbt

dbt ist eine mögliche Transformationsmanagement-Schicht für geeignete SQL-Plattformen. Abhängigkeiten zwischen Modellen, Tests, Dokumentation und Deployment-Praktiken können dadurch expliziter werden.

dbt ersetzt die Architekturentscheidungen nicht. Auch ein dbt-Projekt kann Raw-Bereinigung, Identitätsauflösung, KPI-Logik und reportspezifische Modelle vermischen, wenn die logischen Grenzen nicht bewusst entworfen werden.

Qlik als stärkste vorhandene Fähigkeit

In einer Brownfield-Umgebung kann ein erheblicher Teil der Transformationen derzeit in Qlik-Skripten und QVD-Schichten liegen.

Das praktische Ziel muss nicht zwingend eine sofortige Neuentwicklung sein. Eine kontrollierte Migration kann:

1. die aktuelle Qlik-Logik dokumentieren;
2. gemeinsam genutzte fachliche Regeln identifizieren;
3. wiederverwendbare Standardisierung, Integration und KPI-Logik in SQL oder eine andere gemeinsame Transformationsschicht verschieben;
4. governte QVDs oder Views veröffentlichen;
5. nur Qlik-spezifische Logik in der Anwendung behalten;
6. doppelte Skriptlogik nach der Abstimmung stilllegen.

Die Schichten zeigen, wo Logik zusammengeführt werden sollte. Sie verlangen keinen disruptiven Austausch in einem Schritt.

Querschnittsfunktionen sind keine zusätzliche Endschicht

Datenqualität, Governance, Sicherheit, Lineage, Observability und CI/CD dürfen nicht als Aktivitäten behandelt werden, die erst beginnen, nachdem Gold-Daten existieren.

Datenqualität

Qualitätsregeln treten in unterschiedlichen Schichten auf:

• Raw: Datei empfangen, Zeilenanzahl, Schema lesbar;
• Standardisiert: Pflichtfelder, Datentypen, erlaubte Wertebereiche;
• Integrierter Kern: Schlüsselzuordnung, Dublettenauflösung, zeitliche Konsistenz;
• Datenprodukt: Granularität, referenzielle Integrität, KPI-Plausibilität, Vollständigkeit;
• Nutzung: Vertragskompatibilität und consumerspezifische Validierung.

Governance

Governance definiert:

• fachliche Verantwortung und technischer Betreiber-Verantwortung;
• freigegebene Definitionen;
• Datenklassifikation;
• Änderungsfreigaben;
• Aufbewahrung;
• Service-Erwartungen;
• Ablösung und Stilllegung.

Sicherheit

Sicherheit muss den Daten durch den gesamten Lebenszyklus folgen. Personenbezogene Rohdaten können strengeren Zugriff benötigen als aggregierte Datenprodukte. Consumer-Modelle dürfen nicht zu unkontrollierten Kopien werden, die den govern­ten Zugriffspfad umgehen.

Lineage

Lineage sollte Folgendes verbinden:

Quellfeld
→ Raw-Feld
→ standardisiertes Feld
→ integriertes fachliches Objekt
→ Datenproduktfeld oder KPI-Basis
→ semantisches Measure oder Bericht

Das Ziel sind Auswirkungsanalyse und Verantwortlichkeit — nicht nur ein Diagramm von Tabellenabhängigkeiten.

Observability

Observability umfasst:

• Pipeline-Ausführungen;
• Aktualität;
• Volumenanomalien;
• Schemaänderungen;
• Qualitätsfehler;
• Verletzungen von Service Levels;
• Incidents mit Auswirkungen auf Nutzer.

CI/CD

Versionierung und Deployment-Praktiken gelten für:

• Ingestion-Definitionen;
• SQL, Notebooks oder Transformationsmodelle;
• Qualitätsregeln;
• Schemaänderungen;
• Semantikmodelle;
• Qlik-Load-Skripte, soweit sie erforderlich bleiben;
• Dokumentation und Verträge.

Typische Anti-Patterns

Zonen umbenennen, ohne Verantwortlichkeiten zu klären

Die Umbenennung von Bronze, Silver und Gold in Raw, Core und Mart verbessert nichts, wenn dieselbe vermischte Logik darin verborgen bleibt.

Gold als alles behandeln, was das Business verwendet

Dadurch werden wiederverwendbare Unternehmensstrukturen, fachliche Marts, KPI-Logik und werkzeugspezifische Modelle zusammengeführt. Verantwortung und Auswirkungen von Änderungen werden unklar.

Für jede logische Verantwortung eine physische Plattformschicht erzeugen

Eine logische Grenze benötigt nicht automatisch eine eigene Datenbank, Engine oder ein zusätzliches Werkzeug. Übertriebene physische Trennung erhöht die Betriebskomplexität, ohne Governance automatisch zu verbessern.

Identitätsauflösung in jedem Bericht durchführen

Kunden-Matching und Golden-Record-Logik sollten nicht unabhängig in Qlik, Power BI und Excel implementiert werden. Die Ergebnisse würden sich je Consumer unterscheiden und wären schwer auditierbar.

KPI-Logik in Semantikmodellen neu aufbauen

Semantikmodelle dürfen präsentationsspezifische Measures enthalten. Die gemeinsame KPI-Basis sollte jedoch vorgelagert govern­t sein. Andernfalls wird dieselbe KPI von der eingesetzten Berichtstechnologie abhängig.

Raw-Daten so stark bereinigen, dass der Quellnachweis verschwindet

Werden Werte in Raw unbemerkt überschrieben, werden Quellnachvollziehbarkeit und Wiederholbarkeit unzuverlässig. Standardisierung sollte eine neue kontrollierte Darstellung erzeugen, statt die empfangene Darstellung zu zerstören.

Eine Schicht mit einem Speicherformat gleichsetzen

Logische Architektur und physische Speicherung sind getrennte Entscheidungen. Raw kann aus Dateien oder Tabellen bestehen. Ein Datenprodukt kann Tabelle, View oder governtes Extrakt sein. Die richtige Form hängt von den Anforderungen ab.

Eine weitere Plattform einführen, damit das Schaubild modern aussieht

Fabric, Snowflake, Databricks und dbt können jeweils reale Probleme lösen. Keines dieser Werkzeuge ist automatisch für präzise Schichten erforderlich. Eine Komponente sollte nur ergänzt werden, wenn sie Skalierung, Zusammenarbeit, Tests, Governance, Performance oder Betrieb ausreichend verbessert, um Aufwand und Komplexität zu rechtfertigen.

Entscheidungshilfe: Wie viele physische Schichten sind erforderlich?

Verwende das logische Modell als Checkliste und fasse physische Schichten dort zusammen, wo die Verantwortlichkeiten trotzdem klar und sicher bleiben.

Eine Schicht ist gerechtfertigt, wenn sie eine relevante Grenze für Verantwortung, Wiederverwendung, Kontrolle, Lebenszyklus oder Performance schafft. Sie ist nicht gerechtfertigt, nur weil eine Referenzarchitektur ein weiteres Kästchen enthält.

Wichtigste Empfehlungen

1. Bronze, Silver und Gold können als technische Kurzform verwendet werden, dürfen aber keine logische Warehouse-Architektur ersetzen.
2. Unveränderte Übernahme, technische Standardisierung, fachliche Integration, Datenprodukte und consumerspezifische Bereitstellung sollten klar getrennt werden.
3. Raw sollte als nachvollziehbarer Quellnachweis erhalten bleiben.
4. Business Keys, Golden Records und Historie sollten zentral aufgelöst werden.
5. Fakten, Dimensionen und KPI-Basen gehören in governte Datenprodukte.
6. Gemeinsam genutzte Fachlogik sollte außerhalb einzelner Qlik-Apps, Power-BI-Berichte und Excel-Arbeitsmappen liegen.
7. Consumerspezifische Logik sollte nur dort entstehen, wo der jeweilige Consumer sie tatsächlich benötigt.
8. Datenqualität, Governance, Sicherheit, Lineage, Observability und CI/CD wirken über alle Schichten.
9. Die logischen Grenzen sollten zunächst mit den vorhandenen Werkzeugen umgesetzt werden, bevor eine weitere Plattform ergänzt wird.
10. Verwende die kleinste physische Architektur, die Verantwortlichkeiten explizit und wartbar hält.

Übergang zum nächsten Part

Präzise Schichten klären, was zwischen einer Quelle und einem vertrauenswürdigen Datenprodukt geschehen muss. Sie legen noch nicht fest, wie viele Werkzeuge, Engines oder physische Plattformen erforderlich sind.

Der nächste Part, Die einfachste tragfähige Architektur auswählen, leitet aus Anforderungen wie Datenvolumen, Aktualität, Transformationskomplexität, Teamgröße, Governance und Consumer-Bedarf die einfachste Architektur ab, die funktionieren kann.

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 Business-Fragen 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. Der erste Part definierte die Entscheidungen, die vor der Umsetzung getroffen werden müssen. Der zweite Part trennte die logischen Verantwortlichkeiten zwischen Quelle, Raw, Standardisierung, Integration, Datenprodukten und Nutzung. Dieser Part 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 Part umsetzen, ohne für jede Verantwortung ein separates Produkt einzuführen.

Für einen überschaubaren Batch-orientierten Use Case 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 Consumer. Es muss nicht zur versteckten Integrations- und KPI-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-Lifecycle 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 Recovery;
• 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 Anti-Patterns

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 KPI-Logik und alte Consumer-Extrakte bestehen bleiben, erzeugt eine zusätzliche Plattform statt einer einfacheren Architektur.

Dieselbe Fachregel in jedem Consumer 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.

Übergang zum nächsten Part

Dieser Part hat gezeigt, wie aus expliziten Anforderungen eine angemessene physische Architektur ausgewählt wird. Die nächste Herausforderung besteht darin, die erste Warehouse-Fähigkeit aufzubauen, ohne sofort die gesamte Unternehmensplattform implementieren zu wollen.

Der nächste Part, Ein Warehouse von Grund auf aufbauen, beginnt mit einem vertikalen Datenprodukt und entwickelt den ersten Use Case zu einem wiederverwendbaren Plattformmuster.

Greenfield-Freiheit kann die falsche Komplexität erzeugen

Ein Warehouse von Grund auf aufzubauen wirkt einfacher, als ein bestehendes Warehouse zu modernisieren. Es gibt keine Legacy-Schemas, die erhalten werden müssen, keine gewachsenen Ladeketten, die entwirrt werden müssen, und keine alten Berichte, die weiterhin funktionieren müssen.

Diese Freiheit ist nützlich. Sie erzeugt aber auch ein häufiges Fehlermuster: Das Team versucht, die vollständige Plattform zu bauen, bevor es eine einzige vertrauenswürdige Antwort geliefert hat.

Typische Greenfield-Pläne beginnen mit breiter technischer Arbeit:

Alle Quellen anbinden
Die gesamte verfügbare Historie laden
Alle technischen Schichten aufbauen
Alle wichtigen fachlichen Entitäten modellieren
Jedes künftig denkbare Tool auswählen
Eine unternehmensweite Plattform definieren
Das Business nach seinen Anforderungen fragen

Diese Reihenfolge erzeugt Aktivität, ohne Nutzen zu beweisen. Pipelines, Schemas und Umgebungen wachsen, während das Team noch keine konkrete Business-Frage beantworten kann. Die Architektur wird dadurch für Annahmen optimiert und nicht für beobachtete Anforderungen.

Part 1, Bevor die erste Tabelle entsteht, hat die Entscheidungen definiert, die vor der Umsetzung getroffen werden müssen. Part 2, Mehr als Bronze, Silver und Gold, hat die logischen Verantwortlichkeiten von der Quelle bis zur governten Nutzung getrennt. Part 3, Die einfachste tragfähige Architektur auswählen, hat gezeigt, wie nur die tatsächlich benötigten physischen Fähigkeiten ausgewählt werden.

Dieser Part wendet diese Prinzipien auf eine Greenfield-Umsetzung an.

Baue das Warehouse nicht zuerst horizontal auf. Bringe zunächst einen vollständigen vertikalen Pfad von der Business-Frage bis zur Nutzung zum Laufen, lerne daraus und verwende das bewährte Muster erneut.

Der falsche Start

Der falsche Start wird nicht durch ein bestimmtes Tool definiert. Entscheidend ist die Reihenfolge der Entscheidungen.

Das Anti-Pattern folgt meist vier Annahmen:

1. Mehr geladene Daten schaffen mehr zukünftige Flexibilität.
2. Generische Schichten können vor dem ersten realen Use Case gestaltet werden.
3. Fachliche Definitionen können später ergänzt werden.
4. Das Reporting-Tool wird zeigen, welche Fragen wichtig sind.

Jede Annahme enthält einen wahren Kern. Zusammen kehren sie jedoch die korrekte Abhängigkeit um.

Ein Warehouse ist wertvoll, weil es verlässliche Informationen für definierte Entscheidungen liefert. Die benötigten Quellen, die Historie, die Integrationslogik, die Qualitätskontrollen und die Service Levels können erst dann korrekt ausgewählt werden, wenn dieser Zweck verstanden ist.

Wer zuerst alle Quellen lädt, erzeugt außerdem ein Verantwortung-Problem. Ein technisches Team wird für Datensätze verantwortlich, deren fachliche Bedeutung, Kritikalität und erwartete Qualität noch nicht abgestimmt sind. Die Plattform enthält dann Daten, aber noch keine governbaren Produkte.

Architekturprinzip: rückwärts entwerfen, vorwärts bauen

Ein Greenfield-Warehouse sollte vom benötigten Ergebnis rückwärts entworfen und anschließend durch einen kontrollierten Datenpfad vorwärts implementiert werden.

Die Entwurfsreihenfolge lautet:

Die Umsetzungsreihenfolge lautet:

Beide Reihenfolgen treffen sich in der Mitte. Das Zielmodell zeigt, was geladen werden muss. Die Quellenanalyse zeigt, was tatsächlich geliefert werden kann und wo Annahmen angepasst werden müssen.

Dieser Ansatz vermeidet zwei Extreme:

• quellengetriebene Übernahme ohne Ziel, bei der alles geladen wird, ohne einen definierten Zweck zu besitzen;
• lokale reportgetriebene Modellierung, bei der eine Antwort schnell in einer BI-Anwendung entsteht, aber nicht wiederverwendbar ist.

Das Ziel ist ein vollständiger, schmaler und governbarer Pfad.

Der Vertical-Slice-Ansatz

Ein Vertical Slice enthält genügend Bestandteile jeder erforderlichen Fähigkeit, um ein vertrauenswürdiges Ergebnis zu produzieren. Sein Umfang ist bewusst schmal, seine Verantwortlichkeiten sind jedoch vollständig.

Ein geeigneter erster Slice sollte:

• wertvoll genug sein, dass das Business ihn tatsächlich nutzt;
• klein genug sein, um ihn in einem begrenzten Lieferzyklus abzuschließen;
• repräsentativ genug sein, um zentrale Plattformfähigkeiten zu erproben;
• explizit genug sein, um Verantwortung-, Qualitäts- und Security-Fragen sichtbar zu machen;
• wiederverwendbar genug sein, um Muster für spätere Arbeit zu erzeugen.

Er sollte kein Wegwerfprototyp sein. Der Umfang ist minimal, die Umsetzung aber produktionsorientiert.

Konkretes Beispiel: das Sales Daily Data Product

Angenommen, die erste Warehouse-Anforderung ist die tägliche Vertriebssteuerung.

Die Business-Frage lautet:

Welchen Nettoumsatz haben wir nach Business-Datum, Kunde, Produkt und Land erzielt, und welche Aufträge wurden seit dem vorherigen Ladevorgang geändert oder storniert?

Die ersten Entscheidungen sind:

Diese Tabelle ist wichtiger als die erste Pipeline-Definition. Sie bestimmt, was die Pipeline nachweisen muss.

Mit dem Zielvertrag beginnen

Das erste Ziel ist kein Dashboard. Es ist ein governter Datenproduktvertrag.

Ein praktikabler Vertrag für sales_daily könnte folgende Felder enthalten:

Der Vertrag sollte zusätzlich dokumentieren:

• die Granularität;
• zulässige Nullwerte;
• erlaubte Domains;
• fachliche Filter;
• Historienverhalten;
• Aktualitätserwartung;
• verantwortliche Person;
• Sicherheitsklassifikation;
• Kompatibilitätserwartungen für Nutzer.

Der Zielvertrag verhindert, dass Qlik, Power BI und Excel leicht unterschiedliche Interpretationen desselben fachlichen Konzepts erhalten.

Das Zielmodell ableiten, bevor jede Quelltabelle untersucht wird

Fakt und Dimensionen können nun auf logischer Ebene definiert werden.

fact_sales_order_line
dim_customer
dim_product
dim_country
dim_order_status
mart.sales_daily

Der erste Slice benötigt weder ein vollständiges Customer 360 noch eine vollständige Produktdomäne oder jede denkbare Vertriebskennzahl. Er benötigt nur die Attribute, die zur korrekten Beantwortung der freigegebenen Frage erforderlich sind.

Beispielsweise:

• dim_customer benötigt Kundenidentität, Land und die für den Verkauf relevante Historie;
• dim_product benötigt Produktidentität und die Reporting-Attribute der ersten Analyse;
• fact_sales_order_line benötigt Auftragszeilengranularität, Datumsfelder, Status und Umsatzfelder;
• mart.sales_daily stellt den stabilen Nutzungsvertrag bereit.

Weitere Attribute werden erst ergänzt, wenn ein konkreter Use Case sie verlangt oder ihre Aufnahme nahezu kostenfrei und eindeutig governt ist.

Die minimal benötigten Quellen bestimmen

Der Zielvertrag bestimmt den Quellumfang.

Die Quellenanalyse sollte folgende Fragen beantworten:

• Welches System ist für jedes Feld führend?
• Können Änderungen zuverlässig erkannt werden?
• Werden Löschungen dargestellt?
• Ist Historie vorhanden oder muss sie ab künftigen Ladevorgängen aufgebaut werden?
• Können Datensätze wiederholbar extrahiert werden, ohne Dubletten zu erzeugen?
• Welche Schlüssel verbinden die Quellen?
• Welche Felder enthalten sensible Daten?
• Was geschieht bei verspäteter Lieferung einer Quelle?

Nur die für den Slice benötigten Quellobjekte und Spalten werden in den ersten Ingestion-Umfang aufgenommen.

Die kleinste produktionsfähige Umsetzung bauen

Eine minimale SQL-native Umsetzung kann eine vorhandene Datenbank und einen Scheduler verwenden.

Die logischen Verantwortlichkeiten bleiben getrennt, auch wenn sie dieselbe Datenbank verwenden.

Eine praktikable Namensstruktur könnte so aussehen:

raw.erp_order_line
raw.crm_customer
raw.product_master
raw.country_reference

stg.erp_order_line
stg.crm_customer
stg.product_master

core.customer_history
core.product_history
core.sales_order_line

mart.sales_daily

quality.test_run
quality.test_result

Diese Umsetzung bietet bereits die wesentliche Architektur:

• nachvollziehbare Ingestion;
• standardisierte Datentypen und Domains;
• governte Schlüssel und Historie;
• eine stabile Faktgranularität;
• ein wiederverwendbares Datenprodukt;
• persistente Qualitätsergebnisse;
• kontrollierten Nutzer-Zugriff.

Sie benötigt weder ein Lakehouse noch ein Transformationsframework oder mehrere Compute Engines, solange die Anforderungen diese Komponenten nicht rechtfertigen.

Nur das laden, was der Slice benötigt

Der Ingestion-Prozess sollte wiederholbar, beobachtbar und sicher erneut ausführbar sein.

Für jedes Quellobjekt sollten mindestens folgende Informationen erfasst werden:

source_system
source_object
source_record_key
source_changed_at
extract_batch_id
ingested_at
source_file_or_request_id

Der erste Lauf kann vollständig oder inkrementell sein. Die Architektur sollte dennoch definieren, wie spätere Änderungen behandelt werden.

Ein kontrolliertes inkrementelles Muster kann verwenden:

• Source CDC;
• einen verlässlichen changed_at-Zeitstempel;
• einen monoton steigenden Schlüssel;
• Dateimanifeste;
• Prüfsummen oder Snapshot-Vergleiche, wenn kein Änderungsmarker vorhanden ist.

Die konkrete Methode hängt von der Quelle ab. Das Prinzip bleibt stabil:

Inkrementelle Extraktion ist nicht dasselbe wie fachliche Historie.

Ein Quelländerungszeitstempel zeigt der Pipeline, welche Datensätze geändert wurden. Er bewahrt nicht automatisch die historisch gültige Kunden- oder Produktversion, die das Reporting benötigt.

Vor der Integration standardisieren

Die Standardisierung macht Quelldaten technisch konsistent.

Typische Regeln für das Beispiel sind:

• Auftragskennungen trimmen und typisieren;
• Datums- und Zeitstempelformate normalisieren;
• Länderwerte auf einen freigegebenen Code abbilden;
• Quellstatus auf eine kontrollierte Domain mappen;
• verpflichtende Schlüssel prüfen;
• nicht lesbare Beträge ablehnen oder in Quarantäne verschieben;
• ursprüngliche Quellwerte für die Nachvollziehbarkeit erhalten;
• Validierungsergebnisse am Datensatz oder Batch dokumentieren.

Eine vereinfachte standardisierte View für Auftragspositionen könnte so aussehen:

select
    trim(cast(order_id as varchar(100))) as order_id,
    trim(cast(order_line_id as varchar(100))) as order_line_id,
    cast(order_date as date) as business_date,
    trim(cast(customer_id as varchar(100))) as customer_id,
    trim(cast(product_id as varchar(100))) as product_id,
    upper(trim(order_status)) as source_order_status,
    cast(gross_amount as decimal(18, 2)) as gross_revenue,
    cast(changed_at as timestamp) as source_changed_at,
    extract_batch_id,
    ingested_at
from raw.erp_order_line;

Die genaue Syntax unterscheidet sich je Plattform. Entscheidend ist die Platzierung der Verantwortung.

Schlüssel, Domains und Historie zentral integrieren

Die Integration übersetzt Quelldatensätze in gemeinsame fachliche Bedeutung.

Für den ersten Slice umfasst dies:

• Zuordnung von Quell-Kundenkennungen zu governten Kundenschlüsseln;
• Zuordnung von Produktkennungen zu governten Produktschlüsseln;
• Auswahl der Kunden- und Produktversion, die am Auftragsdatum gültig war;
• Zuordnung von Quellstatus zur freigegebenen Auftragsstatus-Domain;
• Anwendung der gemeinsamen Stornoregel;
• Erhalt nicht zuordenbarer oder ungültiger Datensätze für die Qualitätsanalyse.

Eine vereinfachte zentrale Mart-Transformation könnte so aussehen:

select
    o.business_date,
    o.order_id,
    o.order_line_id,
    c.customer_key,
    p.product_key,
    c.country_code,
    s.order_status,
    o.gross_revenue,
    case
        when s.is_cancelled = 1 then cast(0 as decimal(18, 2))
        else o.gross_revenue
    end as net_revenue,
    o.source_changed_at,
    current_timestamp as loaded_at
from core.sales_order_line o
join core.customer_history c
  on o.customer_id = c.customer_id
 and o.business_date >= c.valid_from
 and o.business_date < coalesce(c.valid_to, date '9999-12-31')
join core.product_history p
  on o.product_id = p.product_id
 and o.business_date >= p.valid_from
 and o.business_date < coalesce(p.valid_to, date '9999-12-31')
join core.order_status s
  on o.source_order_status = s.source_order_status;

Die Regel ist nun vom Consumer unabhängig.

Qualitätsergebnisse als eigenes Produkt behandeln

Qualitätstests sollten nicht in Pipeline-Logs verborgen sein. Sie sollten persistente, abfragbare Ergebnisse erzeugen.

Ein minimales Modell für Qualitätsergebnisse kann folgende Felder enthalten:

Beispielregeln sind:

DQ-SALES-001: order_id darf nicht null sein
DQ-SALES-002: order_line_id muss innerhalb eines Auftrags eindeutig sein
DQ-SALES-003: customer_key muss aufgelöst werden
DQ-SALES-004: product_key muss aufgelöst werden
DQ-SALES-005: country_code muss zur freigegebenen Domain gehören
DQ-SALES-006: source_changed_at muss vorhanden sein
DQ-SALES-007: net_revenue muss der Stornoregel entsprechen
DQ-SALES-008: Der Ladevorgang muss das vereinbarte Aktualitätsziel erfüllen

Eine blockierende Regel kann die Veröffentlichung von mart.sales_daily verhindern. Eine Warnung kann das Produkt mit sichtbarem Status veröffentlichen. Diese Entscheidung gehört in den Produktvertrag.

Consumer schlank halten

Sobald das Datenprodukt existiert, sollte jeder Consumer dieselbe governte Basis erhalten.

Ein bewusst schlankes Qlik-Load-Skript kann so aussehen:

SalesDaily:
SQL SELECT
    business_date,
    order_id,
    order_line_id,
    customer_key,
    product_key,
    country_code,
    order_status,
    gross_revenue,
    net_revenue,
    source_changed_at,
    loaded_at,
    quality_status
FROM mart.sales_daily;

Qlik-spezifische Assoziationen, Section Access oder Präsentationsfelder können in Qlik verbleiben, wenn sie tatsächlich erforderlich sind. Kundenintegration, Status-Mapping, historische Zuordnung und KPI-Definition sollten dort nicht erneut aufgebaut werden.

Power BI kann ein Semantikmodell über denselben governten Fakten und Dimensionen verwenden. Präsentations-Measures, Formatierung und Berichtsinteraktionen bleiben consumerspezifisch, während Nettoumsatzbasis und fachliche Granularität gemeinsam bleiben.

Excel kann eine governte Reporting-View, eine PivotTable-Verbindung oder einen kontrollierten Extrakt verwenden. Es sollte keinen unkontrollierten Raw-Export erhalten, der dieselben Definitionen und das Security-Modell umgeht.

Vom ersten Use Case zum Plattformmuster

Das erste Datenprodukt ist nicht nur ein Lieferobjekt. Es ist ein Architekturexperiment, das sichtbar macht, welche Standards tatsächlich erforderlich sind.

Das Team sollte Entscheidungen erst dann als wiederverwendbare Muster festhalten, nachdem sie im Slice praktisch erprobt wurden.

Das zweite Datenprodukt sollte diese Muster wiederverwenden und sie dort infrage stellen, wo es notwendig ist. Ein Muster wird zum Plattformstandard, wenn mehrere Use Cases zeigen, dass es stabil, verständlich und wirtschaftlich ist.

Das Ziel besteht nicht darin, den ersten Entwurf dauerhaft einzufrieren. Das Ziel besteht darin, sich aus Evidenz statt aus Spekulation weiterzuentwickeln.

Greenfield-Optionen nach vorhandenem Stack

Der logische Slice bleibt plattformübergreifend gleich. Die Umsetzung sollte vorhandene Fähigkeiten nutzen und eine weitere Komponente nur dann ergänzen, wenn sie ein konkretes Problem löst.

Das Schaubild zeigt breite Startpositionen. Dieselbe logische Architektur lässt sich vier verbreiteten produktiven Umsetzungsmustern zuordnen.

SQL-native

Eine SQL-native Umsetzung ist für relationale tägliche Batch-Workloads häufig die einfachste produktive Option.

Diese Variante kann auf einer On-Premises-Datenbank oder einer gemanagten Cloud-Datenbank laufen. Die Architektur wird durch Verantwortlichkeiten definiert und nicht durch den Standort.

Microsoft-Fabric-native

Eine Fabric-Umsetzung kann denselben vertikalen Slice in einer integrierten Microsoft-Umgebung realisieren.

Eine mögliche Zuordnung ist:

• Data-Factory-Pipelines, Copy-Aktivitäten oder Dataflows für die Ingestion;
• ein Lakehouse oder Warehouse für gemanagten analytischen Speicher;
• SQL, Notebooks oder Dataflows für Standardisierung und Integration;
• kuratierte Tabellen für das Sales-Daily-Datenprodukt;
• persistente Qualitätsergebnistabellen;
• Power-BI-Semantikmodelle für die native Nutzung;
• Qlik oder Excel über unterstützte SQL- oder Datenschnittstellen auf governte Ergebnisse;
• Deployment- und Monitoring-Fähigkeiten, sobald das Plattformmuster reift.

Fabric ist keine Voraussetzung für den Use Case. Es ist angemessen, wenn das Unternehmen bereits das Microsoft-Ökosystem nutzt und die integrierte Plattform Übergaben und Betriebsaufwand reduziert.

dbt bleibt optional. Es ist nur dann sinnvoll, wenn der gewählte Fabric-Workflow und das Teammodell von modularer SQL-Entwicklung, Tests und Deployment-Praktiken im dbt-Stil profitieren.

Snowflake-native

Eine Snowflake-Umsetzung kann verwenden:

• Batch- oder kontinuierliches Laden über den verfügbaren Ingestion-Mechanismus;
• Raw- und standardisierte Tabellen in getrennten Schemas;
• SQL-Transformationen, geplante Tasks oder Dynamic-Table-Muster, wo sie angemessen sind;
• dbt als optionales Transformations- und Testframework;
• integrierte Fakten, Dimensionen und das sales_daily-Auswertungstabelle;
• Qualitätsergebnistabellen und Veröffentlichungskontrollen;
• governte Views für Qlik, Power BI und Excel.

Snowflake wird zur logischen Grundlage, wenn ein gemanagtes Cloud Data Warehouse bereits die strategische Plattform ist oder sein Betriebsmodell eine konkrete Anforderung löst. Es sollte nicht allein deshalb eingeführt werden, weil das Projekt Greenfield ist.

Databricks-native

Eine Databricks-Umsetzung kann verwenden:

• Batch-Ingestion oder Auto Loader für Dateien in Cloud Object Storage;
• Delta-Tabellen für kontrollierte Datenzustände;
• SQL, Spark oder gemanagte Pipeline-Fähigkeiten für Transformationen;
• Workflows für die Orchestrierung;
• Qualitätsregeln und persistente Fehlerergebnisse;
• kuratierte Delta-Tabellen oder Views für das Sales-Daily-Produkt;
• governte SQL-Schnittstellen für Qlik, Power BI und Excel;
• dbt als optionalen SQL-Entwicklungspfad.

Databricks ist insbesondere relevant, wenn der Use Case voraussichtlich zu hohen Volumina, vielfältigen Daten, Streaming, Data Science oder ML-Workloads wächst. Ein kleiner relationaler täglicher Batch benötigt nicht allein deshalb verteilte Verarbeitung, weil die Plattform verfügbar ist.

Dateien, Excel oder noch keine Plattform

Ein sehr kleiner kontrollierter Prototyp kann mit Dateien, Excel und Power Query beginnen, wenn zunächst Business-Frage und Zielvertrag validiert werden sollen.

Dieser Start ist nur dann geeignet, wenn:

• der Umfang sehr klein ist;
• Zugriffe kontrolliert sind;
• die Quelle reproduziert werden kann;
• Transformationen dokumentiert sind;
• das Ergebnis eindeutig als Validierungsstufe gekennzeichnet ist;
• vor geschäftskritischer Nutzung ein Übergang in ein Produktionsmuster geplant wird.

Der Prototyp darf nicht unbemerkt zum dauerhaften Enterprise-Warehouse werden.

Wie dbt hineinpasst, ohne verpflichtend zu werden

dbt kann SQL-basierten Transformationen ergänzt werden, wenn es das Entwicklungs- und Betriebsmodell verbessert.

Es ist besonders nützlich, wenn:

• viele Modelle voneinander abhängen;
• mehrere Entwickler zusammenarbeiten;
• Pull Requests und Code Reviews erforderlich sind;
• Tests gemeinsam mit den Modellen definiert werden sollen;
• Dokumentation und Lineage eine einheitliche Struktur benötigen;
• Deployments zwischen Umgebungen wiederholbar werden sollen.

Es kann wenig Mehrwert liefern, wenn ein Entwickler eine kleine Anzahl verständlicher SQL-Transformationen in einem bereits kontrollierten Deployment-Prozess pflegt.

Die Entscheidung lautet deshalb nicht:

Ist dbt eine moderne Best Practice?

Sondern:

Löst dbt in dieser Umsetzung ein Problem bei Zusammenarbeit, Abhängigkeiten, Testing oder Deployment?

Typische Anti-Patterns

Alle Quellen laden, bevor ein Produkt definiert ist

Dadurch entstehen Speicher- und Pipeline-Verpflichtungen ohne vereinbarten Business-Nutzen, Qualität oder Verantwortung.

Das unternehmensweite kanonische Modell im ersten Sprint entwerfen

Ein vollständiges Enterprise-Modell kann nicht von einem Team validiert werden, bevor konkrete Use Cases seine Annahmen praktisch erproben. Beginne mit den wiederverwendbaren Konzepten, die der erste Slice benötigt, und erweitere bewusst.

Den ersten Slice als Wegwerfprodukt behandeln

Ein Proof of Concept mit hartcodierten Pfaden, manuellen Schritten und versteckter Logik beweist nicht, dass die Architektur betrieben werden kann. Der Slice sollte im Umfang minimal, im Betrieb aber produktionsorientiert sein.

Den KPI im Dashboard aufbauen

Wird der Nettoumsatz unabhängig in Qlik, Power BI und Excel definiert, enthält das erste Datenprodukt bereits drei konkurrierende Verträge.

Qlik als verstecktes Warehouse verwenden

Qlik kann anspruchsvolle Transformations- und Assoziationslogik ausführen. Gemeinsame Integration, Historie, Status-Mapping und KPI-Basen sollten dennoch vorgelagert werden, sobald mehrere Produkte oder Consumer sie benötigen.

Bronze, Silver und Gold ohne explizite Verantwortlichkeiten erzeugen

Schichtnamen definieren weder Verantwortung noch Qualität, Historie oder Nutzungsverträge. Der erste Slice muss diese Verantwortlichkeiten sichtbar machen.

Fabric, Snowflake, Databricks und dbt gleichzeitig einführen

Jedes Produkt kann nützlich sein. Werden alle eingeführt, bevor der Workload einen Bedarf beweist, entstehen mehrere Betriebsmodelle, Security-Grenzen und Fehlerpunkte.

Jeden zukünftigen Use Case aus dem ersten standardisieren

Der erste Slice sollte Kandidaten für Standards erzeugen. Ein Muster wird erst dann verpflichtend, wenn seine Wiederverwendung zeigt, dass es weiterhin angemessen ist.

Den Betrieb bis zum zweiten Produkt ignorieren

Wiederanlauf, Monitoring, fehlerhafte Datensätze, Deployment und Support gehören zum ersten produktiven Slice. Sie sind keine nachgelagerte Plattformarbeit.

Daten in jedes BI-Tool kopieren

Unkontrollierte QVDs, Semantikmodell-Kopien und Excel-Exporte können den Vertrag fragmentieren. Consumerspezifische Bereitstellung ist zulässig, muss aber auf das governte Produkt zurückverfolgbar bleiben.

Entscheidungshilfe

Wichtigste Empfehlungen

1. Beginne mit einer Business-Entscheidung und nicht mit dem Plattforminventar.
2. Definiere KPI, Granularität, Owner, Qualität und Nutzungsvertrag vor der Ingestion.
3. Entwirf rückwärts vom Zieldatenprodukt und baue vorwärts aus den benötigten Quellen.
4. Lade nur die Quellobjekte und Felder, die der erste Slice benötigt.
5. Bewahre nachvollziehbare Raw-Daten und unterscheide Extraktionsänderungen von fachlicher Historie.
6. Standardisiere technische Formate, bevor gemeinsame fachliche Integration erfolgt.
7. Löse Schlüssel, Historie, Domains und gemeinsame KPI-Logik zentral.
8. Persistiere Qualitätsergebnisse und definiere das Veröffentlichungsverhalten explizit.
9. Halte Qlik, Power BI und Excel als Consumer desselben governten Produkts schlank.
10. Nutze vorhandene SQL-, Fabric-, Snowflake- oder Databricks-Fähigkeiten, bevor eine weitere Plattform ergänzt wird.
11. Behandle dbt als optionales Entwicklungsframework und nicht als Warehouse-Voraussetzung.
12. Halte den ersten Slice im Umfang minimal, im Betrieb aber produktionsfähig.
13. Überführe bewährte Entscheidungen in wiederverwendbare Muster für Naming, Orchestrierung, Testing, Security, Deployment und Monitoring.
14. Validiere Standards mit dem zweiten und dritten Datenprodukt, bevor sie als universell gelten.
15. Erweitere das Warehouse jeweils um einen governten vertikalen Slice.

Übergang zum nächsten Part

Ein Greenfield-Warehouse kann aus einem vertikalen Slice zu einem wiederverwendbaren Plattformmuster wachsen. Bestehende Warehouses benötigen einen anderen Einstiegspunkt, weil Quellen, Modelle, Berichte und duplizierte Fachlogik bereits vorhanden sind.

Der nächste Part, Ein bestehendes Warehouse modernisieren, wendet dieselben Architekturprinzipien auf eine Brownfield-Umgebung an, ohne einen vollständigen Neubau vorauszusetzen.

Brownfield-Modernisierung beginnt mit einem anderen Problem

Ein Greenfield-Warehouse beginnt mit einer leeren Plattform. Ein Brownfield-Warehouse beginnt mit fachlichen Abhängigkeiten.

Die bestehende Umgebung kann Folgendes enthalten:

• QVD-Generatoren, die mehrere Generationen von Qlik-Anwendungen versorgen;
• umfangreiche Qlik-Ladeskripte mit Extraktion, Joins, Mappings, Historie und KPI-Logik;
• Stored Procedures, in denen sich über Jahre fachliche Regeln angesammelt haben;
• SSIS-Pakete mit verborgenen Abhängigkeiten und operativen Workarounds;
• SQL-Tabellen, die technisch aktiv sind, aber fachlich nicht mehr verstanden werden;
• Power-BI-Semantikmodelle, die bereits an anderer Stelle vorhandene Transformationen wiederholen;
• Excel-Exporte, die zu informellen Schnittstellen für kritische Prozesse geworden sind;
• Berichte, deren Nutzung, Verantwortung und Ablösungsrisiko unbekannt sind.

Diese Umgebung kann veraltet wirken. Teile davon sind jedoch häufig zuverlässig, operativ erprobt und tief in fachliche Abläufe eingebettet. Alles gleichzeitig zu ersetzen, bündelt deshalb mehrere Risiken:

Unbekannte Abhängigkeiten
Undokumentierte fachliche Regeln
Verändertes Verhalten der Quellen
Verhalten einer neuen Plattform
Neue Betriebsprozesse
Neue Consumer-Schnittstellen
Eine gemeinsame Umschaltung

Die Aufgabe besteht nicht nur darin, einen moderneren Stack aufzubauen. Die Aufgabe besteht darin, strukturelles Risiko zu reduzieren, ohne vertrauenswürdige fachliche Ergebnisse zu unterbrechen.

Die Parts 1 bis 4 dieser Serie haben Entscheidungen, logische Schichten, die einfachste tragfähige Architektur und den Greenfield-Ansatz über einen vertikalen Slice definiert. Die Brownfield-Modernisierung wendet dieselben Prinzipien unter einer zusätzlichen Bedingung an: Das aktuelle Ergebnis muss weiter funktionieren, bis sein Ersatz nachweislich tragfähig ist.

Modernisierung sollte Risiken schrittweise ersetzen. Sie sollte nicht jede bestehende Komponente nur deshalb austauschen, weil sie alt ist.

Nicht alles auf einmal neu aufbauen

Ein Big-Bang-Neuaufbau geht davon aus, dass die bestehende Umgebung vollständig verstanden, reproduziert und in einem koordinierten Programm ersetzt werden kann. Bei gewachsenen Warehouses ist diese Annahme meistens falsch.

Ein vollständiger Neuaufbau erzeugt einen langen Zeitraum, in dem die Organisation investiert, ohne eine produktive Verbesserung zu erhalten. Auch das Lernen wird verzögert. Falsche Annahmen über Historie, Status-Mappings, Ausnahmebehandlung oder Berichtsnutzung werden möglicherweise erst bei der abschließenden Umschaltung sichtbar.

Ein inkrementeller Ansatz liefert früher Evidenz. Jede migrierte Domäne zeigt:

• welche Legacy-Komponenten tatsächlich erforderlich sind;
• welche fachlichen Regeln dupliziert oder widersprüchlich sind;
• welche Nutzer welche Ergebnisse verwenden;
• welche Datenqualitätsprobleme aus der Quelle und welche aus der Transformationslogik stammen;
• welche Teile vorübergehend oder dauerhaft bestehen bleiben können;
• welche Plattformfähigkeiten einen messbaren Nutzen erzeugen.

Die Modernisierungseinheit sollte deshalb eine klar begrenzte fachliche Fähigkeit oder ein Datenprodukt sein und nicht das vollständige Warehouse.

Beispiele sind:

Täglicher Vertrieb
Customer 360
Lagerbestand
Offene Aufträge
Service-Performance
Finanz-Istwerte

Jede Einheit erhält einen eigenen Scope, Owner, Zielvertrag, Validierungsplan, eine Consumer-Migration und eine Stilllegungsentscheidung.

Architekturprinzip: umschließen, ersetzen und stilllegen

Das Strangler Pattern für Warehouses hält die bestehende Umgebung aktiv, während ein neuer governter Pfad jeweils eine Domäne übernimmt.

Ein praktikabler Zyklus enthält sieben Schritte:

1. Inventarisieren

Erstelle eine evidenzbasierte Sicht auf die bestehende Landschaft. Die Inventarisierung sollte mehr als Objektnamen enthalten.

Ein Katalog kann unterstützen. Für den Start reicht jedoch auch eine Tabelle in Excel oder SQL. Entscheidend ist, Nutzung und Abhängigkeiten zu erfassen, statt auf eine perfekte Metadatenplattform zu warten.

2. Priorisieren

Die Priorisierung sollte Business-Nutzen, Migrationsfähigkeit und operatives Risiko kombinieren.

Ein nützliches Bewertungsmodell ist:

Der erste Ausschnitt sollte relevant genug sein, um Nutzen zu erzeugen, aber klein genug, um abgeschlossen zu werden. Die komplexeste Finanzkonsolidierung oder der am wenigsten genutzte Bericht ist selten der beste Startpunkt.

3. Einen begrenzten Ausschnitt neu aufbauen

Der neue Ausschnitt sollte den vollständigen Pfad für ein governtes Ergebnis umsetzen:

Die neue Lösung kann die bestehende Datenbank, eine neue Plattform oder eine hybride Variante verwenden. Die architektonische Anforderung ist keine Produktentscheidung. Sie besteht in der Trennung gemeinsamer fachlicher Logik von Consumer-spezifischer Darstellung.

4. Parallel betreiben

Der alte und der neue Pfad erhalten vergleichbare Quellzeiträume und liefern Ergebnisse auf derselben Granularität. Keines der beiden Ergebnisse gilt automatisch als richtig, nur weil es alt oder neu ist.

5. Validieren und Abweichungen erklären

Die Validierung muss Daten, Definitionen, Timing, Historie und Consumer-Verhalten vergleichen. Eine Abweichung ist ein Untersuchungsnachweis und nicht automatisch ein Fehler des neuen Systems.

6. Consumer migrieren

Consumer werden erst umgestellt, wenn Verantwortung, Akzeptanzkriterien, Security, Aktualisierungsverhalten und Rollback geklärt sind. Qlik, Power BI und Excel können zu unterschiedlichen Zeitpunkten wechseln, wenn ihre Verträge voneinander abweichen.

7. Stilllegen

Ein migrierter Pfad ist nicht abgeschlossen, solange doppelte Generatoren, Pakete, Tabellen und Exporte dauerhaft weiterlaufen. Die Stilllegung entfernt Zeitpläne, Zugriffspfade, Speicher, Monitoring, Supportpflichten und Dokumentation der alten Komponente.

Die einfachste sinnvolle Brownfield-Umsetzung

Modernisierung erfordert am ersten Tag keine neue Plattform.

Eine minimale Umsetzung kann die bestehende Datenbank, den vorhandenen Scheduler und die vorhandene BI-Landschaft verwenden:

Eine bestehende SQL-Server-Umgebung könnte beispielsweise wenige explizite Schemas einführen:

raw       empfangene Quelldaten
stg       technisch standardisierte Daten
core      integrierte fachliche Entitäten und Historie
mart      governte Fakten, Dimensionen und Datenprodukte
quality   Test- und Abstimmungsergebnisse
control   Lade-, Abhängigkeits- und Migrationsmetadaten

Bestehende SSIS-Pakete oder Datenbank-Jobs können die Ingestion zunächst weiter übernehmen. Neue Transformationen können mit vorhandenen SQL-Views oder Stored Procedures umgesetzt werden, wenn dies für das Team die wartbarste Variante ist.

Der Modernisierungsnutzen entsteht durch klarere Verantwortlichkeiten, zentrale Regeln, persistente Qualitätsnachweise und kontrollierte Schnittstellen. Er hängt nicht davon ab, Scheduler, Datenbank und BI-Tools gleichzeitig zu ersetzen.

Konkretes Beispiel: Modernisierung einer Vertriebslandschaft

Angenommen, die bestehende Vertriebslandschaft enthält:

• drei Qlik-Anwendungen mit ähnlicher Kunden- und Umsatzlogik;
• zwei QVD-Generatoranwendungen;
• eine SSIS-Extraktionskette aus ERP und CRM;
• Stored Procedures für monatliche Reportingtabellen;
• ein Power-BI-Modell, das Status- und Länder-Mappings wiederholt;
• wöchentliche Excel-Dateien für regionale Verantwortliche;
• unterschiedliche Definitionen des Nettoumsatzes.

Das Ziel ist ein governtes Vertriebsdatenprodukt mit:

Schritt 1: die aktuelle Regel nachverfolgen

Das Team kann feststellen, dass der Nettoumsatz derzeit an mehreren Stellen berechnet wird:

QVD-Generator A       schließt Status 90 aus
Qlik-App B            schließt Status 90 und 95 aus
Power-BI-Measure      zieht Stornos nach Belegart ab
Excel-Arbeitsmappe    entfernt negative Werte manuell
Stored Procedure      verwendet ein Stornokennzeichen aus dem ERP

Die Migration sollte nicht alle Varianten in die neue Plattform kopieren. Sie sollte den Konflikt sichtbar machen, eine freigegebene Definition einholen und die Legacy-Varianten nur für die Abstimmung erhalten.

Schritt 2: ein zentrales Zielmodell aufbauen

Eine vereinfachte plattformneutrale Transformation könnte so aussehen:

select
    o.business_date,
    o.order_id,
    o.order_line_id,
    c.customer_key,
    p.product_key,
    c.country_code,
    s.order_status,
    o.gross_revenue,
    case
        when s.is_cancelled = 1 then cast(0 as decimal(18, 2))
        else o.gross_revenue
    end as net_revenue,
    o.source_changed_at,
    current_timestamp as loaded_at
from core.sales_order_line o
left join core.customer_history c
  on o.customer_id = c.customer_id
 and o.business_date >= c.valid_from
 and o.business_date < coalesce(c.valid_to, date '9999-12-31')
left join core.product_history p
  on o.product_id = p.product_id
 and o.business_date >= p.valid_from
 and o.business_date < coalesce(p.valid_to, date '9999-12-31')
left join core.order_status s
  on o.source_order_status = s.source_order_status;

Die genaue Syntax unterscheidet sich je Datenbank. Entscheidend ist, dass Status-Mapping, Historienzuordnung und die gemeinsame Umsatzbasis nun außerhalb einer einzelnen BI-Anwendung liegen.

Schritt 3: Consumer-Schnittstellen bewusst dünn halten

Eine Qlik-Anwendung kann das governte Produkt direkt laden:

Sales:
SQL SELECT
    business_date,
    order_id,
    order_line_id,
    customer_key,
    product_key,
    country_code,
    order_status,
    gross_revenue,
    net_revenue,
    source_changed_at,
    loaded_at
FROM mart.fact_sales;

Qlik-spezifische Assoziationen, Section Access, Alternate States oder Präsentationsfelder können in Qlik verbleiben, wenn sie tatsächlich erforderlich sind. Gemeinsames Kunden-Matching, Status-Mapping, historische Zuordnung und Nettoumsatzlogik sollten nicht in jeder App erneut aufgebaut werden.

Power BI kann dieselbe governte Faktentabelle und dieselben Dimensionen über sein Semantikmodell verwenden. Berichtsinteraktionen, Formatierung und tatsächlich darstellungsspezifische Measures bleiben lokal; die gemeinsame fachliche Bedeutung bleibt zentral.

Excel kann eine governte Reporting-View oder einen kontrollierten Extrakt auf der benötigten Granularität erhalten. Manuelle Arbeitsmappen sollten nicht zu einer alternativen Transformationsschicht werden, die den KPI stillschweigend neu definiert.

Vom QVD-zentrierten zum plattformzentrierten Ansatz

QVDs sind für Qlik-Performance, Wiederverwendung und Entkopplung nützlich. Das Problem ist nicht das Dateiformat. Das Problem entsteht, wenn die QVD-Landschaft zur einzigen Integrationsarchitektur wird und das vollständige fachliche Modell in undurchsichtigen Ketten von Anwendungsskripten umgesetzt ist.

Eine praktikable Zielzuordnung ist:

Die optionale zentrale QVD-Schicht kann ein wirksamer Übergangsmechanismus sein:

Damit können Qlik-Consumer migriert werden, bevor jede Anwendung direkt auf die Plattform zugreifen kann. Gleichzeitig bleiben operativ wertvolle Eigenschaften erhalten. Die QVD-Schicht wird zu einer kontrollierten Schnittstelle und nicht zu dem Ort, an dem das vollständige Warehouse definiert wird.

Parallele Validierung vor der Umschaltung

Ein neues Modell sollte ein gewachsenes Ergebnis nicht allein aufgrund eines erfolgreichen technischen Ladevorgangs ersetzen. Der alte und der neue Pfad benötigen einen repräsentativen Parallelzeitraum und explizite Akzeptanzkriterien.

Auf mehreren Ebenen validieren

Jede Abweichung klassifizieren

Eine nützliche Abstimmungstabelle speichert nicht nur die Differenz. Sie dokumentiert auch, warum sie existiert.

DEFINITION   Alte und neue Regeln unterscheiden sich
TIMING       Quell-Cutoffs oder Verarbeitungszeiten unterscheiden sich
HISTORIE     Unterschiedliche zeitgültige Datensätze werden ausgewählt
QUALITÄT     Das alte Ergebnis enthält Dubletten, Nullwerte oder ungültige Mappings
SCOPE        Consumer verwenden unterschiedliche Grundmengen oder Filter
FEHLER_ALT   Das Legacy-Ergebnis ist falsch
FEHLER_NEU   Das neue Ergebnis ist falsch
ERWARTET     Freigegebene und dokumentierte Abweichung
UNGEKLÄRT    Untersuchung noch erforderlich

Beispielhafte Felder einer Validierungsergebnistabelle:

Akzeptanz vor dem Vergleich definieren

Die Akzeptanz sollte vor der finalen Umschaltungsdiskussion vereinbart werden.

Beispiele:

• alle erforderlichen Business Keys sind vorhanden;
• keine blockierende Qualitätsregel schlägt fehl;
• tägliche Zeilenanzahlen stimmen innerhalb einer freigegebenen Toleranz überein;
• der Nettoumsatz stimmt nach dokumentierten Definitionsänderungen überein;
• alle historischen Abweichungen werden durch zeitgültige Regeln erklärt;
• kritische Qlik- und Power-BI-Ergebnisse sind durch benannte Business Owner freigegeben;
• Excel-Empfänger haben die Ersatzschnittstelle und Anweisungen erhalten;
• der neue Pfad erfüllt das vereinbarte Aktualitätsfenster;
• der Rückbau wurde getestet;
• für den alten Pfad existiert ein terminierter Stilllegungsplan.

Perfekte Gleichheit ist nicht immer das Ziel. Ein neues System kann Legacy-Fehler bewusst korrigieren. Entscheidend ist, dass jede wesentliche Abweichung verstanden, zugeordnet und akzeptiert ist.

Plattformoptionen für den Zielzustand

Das Strangler Pattern ist unabhängig von der Zielplattform. Dieselbe logische Migration kann mit den bereits verfügbaren Fähigkeiten umgesetzt werden.

Der optionale Einsatz von dbt kann sinnvoll werden, wenn modulare SQL-Entwicklung, Abhängigkeitsmanagement, Testing, Dokumentation oder Teamzusammenarbeit genügend Nutzen für den zusätzlichen Workflow erzeugen. Für die Migrationsmethode ist dbt keine Voraussetzung.

Die Plattformentscheidung sollte den Kriterien aus Die einfachste tragfähige Architektur auswählen folgen: Volumen, Aktualität, Transformationstyp, Teammodell, Governance, Consumer, Verfügbarkeit, vorhandene Fähigkeiten und gesamte Betriebskosten.

Typische Anti-Patterns

Objekte statt Ergebnisse migrieren

Wer jede Tabelle, jedes QVD und jedes Paket nachbaut, erhält die alte Architektur an einem neuen Ort. Die Migrationseinheit sollte ein governtes fachliches Ergebnis mit explizitem Consumer-Vertrag sein.

Legacy-Logik kopieren, ohne Konflikte zu lösen

Eine Regel ist nicht automatisch korrekt, nur weil sie in fünf Anwendungen existiert. Doppelte Definitionen müssen verglichen, zugeordnet und freigegeben werden, bevor sie zentral werden.

Einen Plattformwechsel als Modernisierungsstrategie bezeichnen

Dieselben undurchsichtigen Procedures und App-Logiken auf eine andere Engine zu verschieben, verändert die Infrastruktur und nicht die Architektur.

Den neuen Pfad ohne Nutzungsnachweise bauen

Ungenutzte Berichte, doppelte Exporte und aufgegebene QVDs sollten nicht allein deshalb migriert werden, weil sie existieren.

Alt und Neu dauerhaft parallel betreiben

Der Parallelbetrieb ist eine Validierungsphase und kein dauerhaftes Betriebsmodell. Jeder Ausschnitt benötigt Ausstiegskriterien und ein Stilllegungsdatum.

Nur Summen validieren

Ein passender Gesamtumsatz kann fehlende Kunden, duplizierte Positionen, andere Historie, verschobene Datumswerte oder sich ausgleichende Fehler verbergen. Die Validierung muss Granularität, Schlüssel, Verteilungen und fachliche Regeln einschließen.

Sämtliche BI-Logik zentralisieren

Gemeinsame Definitionen gehören in die zentrale Plattform. Consumer-spezifische Interaktion, Visualisierung und Tool-Verhalten können in Qlik, Power BI oder Excel verbleiben. Zentralisierung soll Wiederverwendung erhöhen und nicht legitime Consumer-Verantwortung entfernen.

QVDs nur als Modernisierungsbeweis entfernen

Eine governte QVD-Bereitstellungsschicht kann weiterhin sinnvoll sein. Das Ziel sind dünne und kontrollierte Qlik-Consumer und nicht die symbolische Abschaffung eines Dateiformats.

Im ersten Ausschnitt mehrere neue Tools gleichzeitig einführen

Eine erste Migration, die gleichzeitig Ingestion, Speicher, Transformationsframework, Scheduler, Katalog, BI-Schnittstelle und Betriebsmodell verändert, erschwert die Ursachenanalyse. Verändere nur das, was der begrenzte Ausschnitt tatsächlich benötigt.

Entscheidungshilfe: Was sollte zuerst migriert werden?

Wichtigste Empfehlungen

1. Modernisiere jeweils ein klar begrenztes Datenprodukt.
2. Inventarisiere Nutzung, Abhängigkeiten, Owner, fachliche Regeln und Betriebsverhalten vor dem Neuaufbau.
3. Priorisiere nach Business-Nutzen, Schmerz, Wiederverwendung, Umsetzbarkeit und Stilllegungspotenzial.
4. Halte den aktuellen Pfad aktiv, bis sein Ersatz validiert ist.
5. Behandle Legacy- und neue Ergebnisse als zu vergleichende Hypothesen und nicht als automatische Wahrheit.
6. Klassifiziere Abweichungen nach Definition, Timing, Historie, Scope und Datenqualität.
7. Verlage gemeinsame Identität, Historie, Mappings, Faktgranularität und KPI-Grundlagen aus einzelnen BI-Anwendungen.
8. Halte Qlik-Skripte dünn und belasse nur tatsächlich Qlik-spezifische Logik in der App.
9. Nutze eine zentrale QVD-Schicht, wenn sie eine kontrollierte und praktikable Übergangsschnittstelle bietet.
10. Lasse Power BI und Excel dasselbe governte Datenprodukt verwenden, ohne seine gemeinsamen Regeln neu zu definieren.
11. Beginne mit vorhandenen SQL-, Scheduling- und BI-Fähigkeiten, wenn sie den Ausschnitt zuverlässig tragen können.
12. Ergänze Fabric, Snowflake, Databricks oder dbt nur, wenn eine konkrete Anforderung sie rechtfertigt.
13. Definiere Akzeptanzkriterien, fachliche Freigabe, Rollback und Kommunikation vor der Umschaltung.
14. Lege nach der Migration Zeitpläne, Speicher, Zugriffspfade und Supportpflichten still.
15. Nutze jeden abgeschlossenen Ausschnitt, um das Muster für die nächste Migration zu verbessern.

Übergang zum nächsten Part

Brownfield-Modernisierung gelingt, wenn wiederverwendbare fachliche Logik aus fragmentierten Procedures, QVD-Ketten, Qlik-Anwendungen, Power-BI-Modellen und Excel-Arbeitsmappen in governte Plattformverantwortlichkeiten verlagert wird.

Diese Grenze verdient eine genauere Betrachtung. Der nächste Part, Fachliche Logik außerhalb der BI-Apps halten, definiert, welche Logik zentral gehört, welche Consumer-spezifisch bleiben darf und wie dünne Qlik-, Power-BI- und Excel-Schichten dieselben governten Datenprodukte verwenden können.

Die BI-App darf nicht selbst zum Warehouse werden

Gemeinsame Fachlogik (Bereinigung, Integration, KPI-Grundlagen) gehört in governte Modelle außerhalb einzelner BI-Apps — sonst wird jede App zum Mini-Warehouse.

Qlik, Power BI und Excel berechnen jeweils „Umsatz“ mit anderer Storno-Logik. Das Lenkungsmeeting sieht drei Nettoumsatz-Zahlen für dieselbe Woche.

Eine BI-Anwendung ist oft der schnellste Ort für ein Problem. Das strukturelle Risiko entsteht, sobald dieselbe fachliche Bedeutung unabhängig in mehreren Consumer-Artefakten landet.

Eine typische Landschaft enthält dann beispielsweise:

Qlik-App A       Umsatz schließt Stornostatus 90 aus
Qlik-App B       Umsatz schließt Status 90 und 95 aus
Power-BI-Modell  Umsatz zieht Stornodokumente ab
Excel-Datei      Umsatz entfernt negative Werte manuell
SQL-Export       Umsatz verwendet das Stornokennzeichen der Quelle

Alle fünf Ergebnisse können Umsatz heißen. Sie bilden trotzdem nicht dieselbe Kennzahl ab.

Das Problem besteht nicht darin, dass Qlik-Skripte, DAX oder Excel-Formeln verwendet werden. Diese Fähigkeiten sind am richtigen Ort unverzichtbar. Problematisch wird es, wenn ein Consumer-Tool der einzige Ort ist, an dem gemeinsame Bereinigung, Integration, Historisierung und KPI-Regeln verstanden werden.

Daraus entstehen mehrere Folgen:

• Jeder neue Bericht implementiert vorhandene Logik erneut.
• Korrekturen müssen mehrfach ausgerollt werden.
• Datenqualität wird unterschiedlich oder überhaupt nicht geprüft.
• Lineage endet in schwer nachvollziehbarem Anwendungscode.
• Eine Anwendung kann einen anderen Nutzer nicht sicher versorgen.
• Fachliche Definitionen hängen von einzelnen Entwicklern ab.
• Migrationen werden schwierig, weil Logik und Darstellung untrennbar verbunden sind.

Part 5, Ein bestehendes Warehouse modernisieren, hat gezeigt, wie duplizierte QVD-, SQL-, Qlik-, Power-BI- und Excel-Logik schrittweise ersetzt werden kann. Dieser Part definiert das Zielprinzip für die daraus entstehende Architektur.

Definiere gemeinsame fachliche Bedeutung einmal in einer governten Datenschicht. Qlik, Power BI und Excel konsumieren diese Bedeutung und ergänzen nur die Logik, die für ihr jeweiliges Analyseerlebnis spezifisch ist.

Architekturprinzip: zentrale Wahrheit, schlanke Consumer

Die Zielarchitektur trennt zwei unterschiedliche Verantwortlichkeiten.

Die governte Datenplattform verantwortet wiederverwendbare fachliche Wahrheit:

Bereinigung
Standardisierung
Quellenintegration
Business Keys
Referenzzuordnungen
Historisierung
KPI-Grundregeln
Währungsbehandlung
Stornologik
Datenqualitätsregeln
Veröffentlichungsverträge

Die BI-Consumer verantworten Tool-spezifisches Analyseverhalten:

Assoziative Exploration
Filterkontext
Visuelle Berechnungen
Interaktive Zeitvergleiche
Darstellung
Navigation
Kommentare
Kontrollierte manuelle Eingaben

Diese Trennung ist präziser als die Aussage „Alle Logik muss außerhalb der Apps liegen“. Bestimmte Logik besitzt nur innerhalb des Consumers eine sinnvolle Bedeutung.

Eine Qlik-Link-Table existiert wegen des assoziativen Modells. Section Access steuert den Zugriff in einer Qlik-Anwendung. Set Analysis kann einen benutzerbezogenen Vergleich innerhalb des aktuellen Selektionszustands ausdrücken. DAX wertet Measures im Filterkontext des semantischen Modells aus. Excel ermöglicht Layouts, Kommentare und kontrollierte Szenarien, die nicht zwingend in eine Warehouse-Tabelle gehören.

Das sind legitime Ausnahmen.

Die leitende Regel lautet deshalb:

Gemeinsame fachliche Wahrheit gehört außerhalb einzelner Apps. Tool-spezifische Semantik darf im Tool verbleiben, wenn sie einen klaren analytischen oder operativen Mehrwert erzeugt und explizit dokumentiert ist.

Die schlanke Qlik-Anwendung

Eine umfangreiche Qlik-Anwendung übernimmt mehrere Architekturaufgaben gleichzeitig:

Eine schlanke Qlik-Anwendung beginnt wesentlich später im Lebenszyklus.

Eine praktikable schlanke Qlik-Anwendung kann weiterhin enthalten:

• Verbindungs- und Ladeanweisungen;
• Feldauswahl und technische Umbenennungen für das lokale Modell;
• für das Analyseerlebnis erforderliche Assoziationen;
• eine Link Table oder kanonische Datumsstruktur, sofern fachlich und technisch begründet;
• Section Access, wenn die Zugriffsdurchsetzung auf Anwendungsebene erforderlich ist;
• gezielte Performance-Optimierungen;
• Master-Elemente und visuelle Ausdrücke;
• Set Analysis für interaktive Analysekontexte.

Sie sollte normalerweise nicht enthalten:

• wiederholte Joins zwischen Quellsystemen;
• die einzige Implementierung der Stornoregel;
• unabhängige Länder- oder Statuszuordnungen;
• lokale Rekonstruktion der Kundenhistorie;
• eigene Regeln für die Währungsumrechnung;
• duplizierte Datenqualitätsentscheidungen;
• eine abweichende Definition des unternehmensweiten Umsatz-KPI.

Der Begriff schlanke App bedeutet nicht „kein Skript“. Er bedeutet, dass das Skript auf Konsum, Qlik-spezifische Modellierung und begründete Optimierung beschränkt bleibt.

Was gehört wohin?

Der richtige Ort einer Logik hängt davon ab, ob sie wiederverwendbare fachliche Wahrheit oder Consumer-spezifisches Analyseverhalten darstellt.

Eine praktikable Zuordnung lautet:

Der Ort kann geteilt werden, wenn unterschiedliche Verantwortlichkeiten bestehen. Beispielsweise kann die Zugriffsberechtigung zentral erzeugt werden, während Section Access sie innerhalb von Qlik durchsetzt. Die zentrale Schicht definiert, welcher Nutzer für welche Vertriebsregion berechtigt ist. Die Qlik-App konsumiert diese Berechtigungstabelle und wendet sie an.

Mit der einfachsten sinnvollen Umsetzung beginnen

Fachliche Logik außerhalb von BI-Anwendungen zu halten, erfordert weder eine neue Cloud-Plattform noch ein zusätzliches Transformationsprodukt.

Die kleinste sinnvolle Umsetzung kann so aussehen:

Angenommen, ein Unternehmen verwendet bereits SQL Server, PostgreSQL, Oracle oder eine andere relationale Datenbank. Es kann eine kleine Zahl klarer Verantwortungsbereiche einführen:

stg       technisch standardisierte Quelldaten
core      integrierte Entitäten, Schlüssel und Historie
mart      governte Fakten, Dimensionen und Reporting Views
quality   Testläufe und Regelergebnisse
control   Lade-, Versions- und Veröffentlichungsmetadaten

Das erste Ziel ist nicht, sofort einen theoretisch perfekten Semantic Layer zu schaffen. Zunächst wird eine duplizierte Regel an einen governten Ort verschoben.

Beispiel:

create view mart.sales_consumption as
select
    s.business_date,
    s.order_id,
    s.order_line_id,
    s.customer_key,
    s.product_key,
    s.country_code,
    s.currency_code,
    s.gross_revenue_amount,
    case
        when s.is_cancelled = 1 then 0
        else s.revenue_amount_in_reporting_currency
    end as net_revenue_amount,
    s.quality_status
from core.sales_order_line s
where s.publication_status = 'PUBLISHED';

Diese View ist bewusst einfach. Die eigentliche Komplexität sollte bereits in kontrollierten vorgelagerten Schritten aufgelöst worden sein:

• is_cancelled folgt einer freigegebenen Status- und Dokumentregel;
• revenue_amount_in_reporting_currency verwendet ein freigegebenes Wechselkursdatum;
• customer_key löst Kundenidentität und Historie auf;
• country_code folgt einer governten Zuordnung;
• publication_status berücksichtigt persistente Qualitätsprüfungen.

Qlik, Power BI und Excel erhalten nun dieselbe faktische Grundlage.

Konkretes KPI-Beispiel: Nettoumsatz

Betrachten wir den KPI Nettoumsatz.

Seine gemeinsame fachliche Definition benötigt Entscheidungen in fünf Bereichen:

Diese Entscheidungen gehören in den governten Datenpfad, weil jeder Consumer sie identisch anwenden muss.

Die Plattform kann folgende Felder veröffentlichen:

gross_revenue_amount
net_revenue_amount
reporting_currency
business_date
customer_key
product_key
country_code
quality_status

Die Consumer ergänzen anschließend Kontext, ohne die Kennzahl neu zu definieren.

Qlik

Das Basis-Measure kann sehr klein bleiben:

Sum([Nettoumsatz Amount])

Set Analysis kann einen analytischen Vergleich ergänzen:

Sum({
    <BusinessYear = {"$(=Max(BusinessYear)-1)"}>
} [Nettoumsatz Amount])

Der Set-Analysis-Ausdruck steuert den Vergleichskontext. Er berechnet Stornos, Währung oder Kundenhistorie nicht erneut.

Power BI

Das Basis-Measure kann denselben veröffentlichten Betrag verwenden:

Nettoumsatz :=
SUM ( SalesConsumption[NetRevenueAmount] )

Ein Zeitvergleich kann im semantischen Modell verbleiben:

Nettoumsatz Previous Year :=
CALCULATE (
    [Nettoumsatz],
    DATEADD ( 'Date'[Date], -1, YEAR )
)

DAX liefert den Modellspezifischen Analysekontext. Die zugrunde liegende Umsatzregel wird nicht neu aufgebaut.

Excel

Excel sollte vorzugsweise mit der zertifizierten Reporting View oder dem semantischen Modell verbunden werden und Folgendes verwenden:

• eine PivotTable;
• eine kontrollierte Abfrage;
• eine aktualisierbare Tabelle;
• freigegebene Szenariospalten, die klar von Ist-Daten getrennt sind.

Die Arbeitsmappe sollte keine versteckte Formel wie diese enthalten:

IF(amount < 0, 0, amount)

und das Ergebnis Nettoumsatz nennen. Dadurch entstünde eine neue lokale fachliche Definition.

Fachliche Logik außerhalb der Apps

Sobald gemeinsame Logik externalisiert ist, kann ein governter Kern mehrere Consumer bedienen, ohne sie auf dieselbe Oberfläche oder Berechnungssprache festzulegen.

Die zentrale Schicht muss kein einzelnes physisches Produkt sein. Sie kann ein logischer Vertrag sein, der über folgende Komponenten umgesetzt wird:

• SQL-Tabellen und Views;
• Warehouse-Schemas;
• Lakehouse-Tabellen;
• governte Dateien;
• semantische Modelle;
• APIs;
• eine optionale QVD-Verteilungsschicht;
• eine Kombination dieser Komponenten.

Die architektonische Anforderung lautet, dass die maßgebliche Regel eindeutig identifizierbar, wiederverwendbar und testbar ist.

Ein geeigneter Datenproduktvertrag sollte Folgendes festhalten:

Dieser Vertrag ist wichtiger als das physische Tool, mit dem er erzeugt wird.

Optionale zentrale QVD-Schicht

Eine zentrale QVD-Schicht kann insbesondere in einer bestehenden Qlik-Landschaft eine gültige Umsetzungsoption sein.

Beispiel:

Die QVD-Schicht kann folgende Vorteile bieten:

• effiziente Qlik-optimierte Verteilung;
• Entkopplung von der Verfügbarkeit der Quellen;
• Wiederverwendung über mehrere Qlik-Anwendungen;
• kontrollierte inkrementelle Ladevorgänge;
• einen Migrationsschritt weg von App-lokaler Quellenextraktion.

Sie sollte jedoch nicht automatisch zum Ort der gesamten unternehmensweiten fachlichen Wahrheit werden.

Eine governte QVD-Schicht ist geeignet, wenn:

• Qlik der dominante oder einzige Nutzer ist;
• das Team die QVD-Erzeugung zentral betreiben und testen kann;
• Datenverträge, Verantwortung und Lineage explizit sind;
• Power BI und Excel keine ausschließlich in QVDs vorhandene Logik zurückentwickeln müssen;
• die Schicht Duplizierung reduziert, statt eine zusätzliche Kopie zu schaffen.

Wenn mehrere Consumer-Technologien dasselbe Produkt benötigen, ist eine plattformneutrale Tabelle, View oder API in der Regel der bessere führende Vertrag. QVDs können daraus weiterhin als Qlik-spezifisches Verteilungsformat erzeugt werden.

Die Entscheidung lautet deshalb nicht „QVD oder Warehouse“. Ein sinnvolles Muster kann so aussehen:

Governte Warehouse-Modelle
        ↓
Optionaler governter QVD-Cache
        ↓
Schlanke Qlik-Apps

Umsetzungsoptionen nach vorhandener Plattform

Das logische Prinzip bleibt über Plattformen hinweg identisch.

Vorhandenes relationales Warehouse

Nutze Schemas, Views, Tabellen, Stored Procedures und den vorhandenen Scheduler. Ergänze persistente Qualitäts- und Kontrolltabellen. Das ist häufig die einfachste tragfähige Variante.

Microsoft-orientierte Umgebung

Nutze die vorhandene Microsoft-Datenplattform, um governte Warehouse- oder Lakehouse-Tabellen und Consumer Views zu veröffentlichen. Ergänze separate semantische Measures nur dort, wo Power-BI-spezifischer Filterkontext erforderlich ist. Verschiebe gemeinsame Regeln nicht in jeden Bericht, nur weil die Plattform lokale Modellierung komfortabel macht.

Snowflake-orientierte Umgebung

Veröffentliche governte Tabellen oder kontrollierte Consumption Views. Nutze zunächst SQL-Transformationen und die vorhandene Orchestrierung. Ergänze dbt, wenn modulare Modellabhängigkeiten, Tests, Dokumentation und Team-Deployment-Workflows ein reales Zusammenarbeitsproblem lösen.

Databricks-orientierte Umgebung

Veröffentliche governte Delta- oder SQL-Consumption-Tabellen aus kontrollierten Transformationsschichten. Nutze Spark-spezifische Verarbeitung dort, wo Skalierung, Streaming oder Engineering-Anforderungen sie rechtfertigen. Eine kleine relationale KPI-Regel wird nicht automatisch besser, nur weil sie in verteiltem Code ausgeführt wird.

Umgebung mit dbt

Nutze dbt als optionales Engineering-Framework für versionierte Modelle, Abhängigkeiten und Tests. dbt kann die Umsetzungsdisziplin verbessern, ist aber nicht selbst die fachliche Architektur. Vertrag, Verantwortung und Consumer-Grenzen müssen weiterhin gestaltet werden.

Qlik-zentrierte Umgebung ohne Warehouse

Baue einen zentral betriebenen Qlik-Transformations- oder QVD-Erzeugungspfad als Zwischenarchitektur auf. Verschiebe Quellen-Joins, Bereinigung, Historisierung und gemeinsame KPI-Grundlagen aus einzelnen Apps. Dokumentiere den Pfad als governtes Datenprodukt und behalte nur Qlik-spezifische Logik in den konsumierenden Anwendungen.

Datei-basierte oder kleine Umgebung

Ein kontrollierter Satz aus CSV-, Parquet- oder tabellenbasierten Ausgaben kann für einen kleinen Umfang ausreichen, sofern Erzeugung, Schema, Qualität, Verantwortung und Aktualisierung kontrolliert sind. Das Fehlen einer großen Plattform rechtfertigt keine unkontrollierten lokalen Definitionen.

Notwendige Tool-spezifische Ausnahmen

Bestimmte Logik sollte im Consumer verbleiben, weil ihre Verlagerung Funktionalität entfernen, die Nutzbarkeit verschlechtern oder eine künstliche Abstraktion erzeugen würde.

Qlik-Ausnahmen

Gültige Qlik-spezifische Logik kann Folgendes umfassen:

• Link Tables, um mehrere Fakten und gemeinsame Dimensionen im assoziativen Modell zu verwalten;
• kanonische Datumsmodelle, um mehrere fachliche Datumsrollen über einen Kalender zu analysieren;
• Section Access für Reduktion auf Anwendungsebene;
• gezielte Set Analysis für selektionsabhängige Vergleiche;
• Alternate States für kontrollierte Vergleichsanalysen;
• lokale Assoziationsbehandlung, wenn das Consumption Model sie benötigt;
• Performance-orientierte Feldaufbereitung, wenn sie das Anwendungsverhalten wesentlich verbessert.

Diese Ausnahmen dürfen nicht als Begründung dienen, Quellenbereinigung und unternehmensweite KPI-Definitionen wieder in die App zu verschieben.

Power-BI-Ausnahmen

Gültige Power-BI-spezifische Logik kann Folgendes umfassen:

• Measures im semantischen Modell;
• DAX-Zeitintelligenz;
• Calculation Groups;
• Row-Level Security, wenn sie durch das semantische Modell durchgesetzt wird;
• Display Folders und Modellmetadaten;
• Darstellungsberechnungen, die vom Filterkontext abhängen;
• What-if-Parameter für kontrollierte Szenarioanalysen.

Die zugrunde liegenden Fakten, Mappings, Stornoregeln und historischen Zuordnungen sollten außerhalb des Berichts wiederverwendbar bleiben.

Excel-Ausnahmen

Gültige Excel-spezifische Logik kann Folgendes umfassen:

• Berichtslayout;
• Kommentare und Annotationen;
• kontrollierte Szenarioannahmen;
• manuell eingegebene Planwerte;
• Arbeitsmappen-spezifische Darstellungsformeln;
• lokale Pivot-Auswertungen und Diagramme;
• Abstimmungen als sichtbare temporäre Kontrolle.

Manuelle Eingaben sollten klar von governten Ist-Daten getrennt werden. Werden Eingaben operativ wichtig, benötigen sie Owner, Validierung, Versionierung und einen kontrollierten Rückführungspfad in die Plattform.

Jede Ausnahme dokumentieren

Eine Ausnahme sollte in einem Architekturregister sichtbar sein und nicht in einem Skript oder einer Arbeitsmappe verborgen bleiben.

Ein vergleichbarer Eintrag kann ein DAX-Measure oder eine kontrollierte Excel-Eingabe dokumentieren.

Das Register beantwortet fünf Fragen:

1. Warum existiert die Logik im Tool?
2. Welche gemeinsame Definition konsumiert sie?
3. Verändert sie fachliche Wahrheit oder nur den Analysekontext?
4. Wer verantwortet und testet sie?
5. Unter welcher Bedingung wird sie verschoben, wiederverwendet oder entfernt?

Datenqualität muss außerhalb der Visualisierung bleiben

Ein Bericht kann Qualitätsergebnisse darstellen. Er sollte jedoch nicht der einzige Ort sein, an dem Qualität ausgewertet wird.

Persistente Qualitätsausführung sollte mindestens Folgendes erfassen:

test_run_id
data_product
rule_id
severity
object_name
record_key
expected_value
actual_value
result_status
executed_at
owner

Für das Umsatzbeispiel können Regeln enthalten:

• Kennung der Auftragsposition ist vorhanden;
• Kundenschlüssel wurde aufgelöst;
• Produktschlüssel wurde aufgelöst;
• Business-Datum ist gültig;
• Wechselkurs ist verfügbar;
• Stornostatus ist bekannt;
• Nettoumsatz entspricht der freigegebenen Regel;
• Veröffentlichung ist vor dem vereinbarten Zeitpunkt vollständig.

Qlik und Power BI können Fehlerrate, Entwicklung und betroffene Datensätze visualisieren. Excel kann eine kontrollierte Bearbeitung unterstützen. Regelausführung und Ergebnishistorie bleiben unabhängig von allen drei Consumern.

Zugriffslogik kann ohne Duplizierung geteilt werden

Security erstreckt sich häufig über Plattform und Consumer.

Ein sinnvolles Muster lautet:

Die Plattform kann folgende Felder veröffentlichen:

user_id
region_key
product_scope
valid_from
valid_to
access_status

Qlik kann diese Tabelle in Section Access verwenden. Power BI kann dieselbe Berechtigung in seinem Security Model einsetzen. Excel erhält ausschließlich eine freigegebene View oder einen kontrollierten Extrakt.

Die Berechtigungsregel ist zentral. Der Mechanismus zur Durchsetzung ist Tool-spezifisch.

Typische Anti-Patterns

Das Warehouse in jeder Qlik-App neu aufbauen

Quellen-Joins, Mappings, Historisierung und KPI-Berechnungen werden in mehrere Reload-Skripte kopiert. Jede App wird zu einer eigenen Warehouse-Implementierung.

Eine gemeinsame Qlik-Include-Datei mit vollständiger Governance verwechseln

Eine Include-Datei reduziert kopierten Code. Sie liefert jedoch nicht automatisch Verantwortung, Testing, versionierte Datenverträge, Qualitätsevidenz oder plattformneutrale Wiederverwendung.

Sämtliche Logik in eine riesige SQL-View verschieben

Zentralisierung allein schafft keine Wartbarkeit. Eine einzelne undurchsichtige View kann genauso schwer governbar werden wie ein großes Qlik-Skript. Verantwortlichkeiten müssen getrennt und Zwischenergebnisse bei Bedarf persistiert werden.

Denselben KPI in DAX erneut implementieren

Jeder Power-BI-Bericht erzeugt seine eigene Variante von Nettoumsatz, Deckungsbeitrag oder aktivem Kunden. Ein gemeinsames semantisches Modell hilft. Wiederverwendbare faktische Regeln sollten bei Bedarf trotzdem außerhalb einer einzelnen Berichtstechnologie verfügbar sein.

Excel als unsichtbare Korrekturschicht verwenden

Nutzer korrigieren Ländercodes, entfernen Stornos oder ergänzen fehlende Mappings manuell. Die Arbeitsmappe wird operativ kritisch, ohne Verantwortung oder Nachvollziehbarkeit zu besitzen.

Jede Analyseberechnung in die Plattform zwingen

Wer jeden Vergleich, jedes Ranking und jeden selektionsabhängigen Ausdruck in Warehouse-Spalten verschiebt, erzeugt viele kontextspezifische Felder und reduziert die analytische Flexibilität.

Jede Tool-spezifische Logik zur Ausnahme erklären

Eine Ausnahme wird durch den Ausführungskontext des Tools begründet. „Es war lokal schneller umzusetzen“ ist keine belastbare Architekturbegründung.

Eine weitere zentrale Kopie erstellen, ohne lokale Logik stillzulegen

Ein neuer governter Mart wird veröffentlicht, alte Qlik-Skripte, Power-Query-Schritte und Excel-Formeln bleiben jedoch aktiv. Die Architektur gewinnt eine zusätzliche Schicht, ohne Inkonsistenz zu reduzieren.

dbt, Fabric, Snowflake oder Databricks verpflichtend machen

Das Prinzip kann mit vorhandenem SQL, governten QVDs oder kontrollierten Dateien umgesetzt werden. Ein neues Produkt ist nur gerechtfertigt, wenn es ein identifiziertes Problem bei Lieferung, Skalierung, Zusammenarbeit oder Betrieb löst.

Entscheidungshilfe

Verwende für jedes Stück Logik folgende Fragen:

Eine kompakte Regel lautet:

Gemeinsame Bedeutung       → zentral
Wiederverwendbare Logik    → zentral
Qualität und Historie      → zentral
Tool-Ausführungskontext    → lokal und dokumentiert
Darstellung                → lokal
Temporäre Exploration      → lokal, mit Pfad zur Überführung

Wichtigste Empfehlungen

1. Behandle Qlik, Power BI und Excel als Consumer governten Datenprodukte und nicht als unabhängige Warehouses.
2. Verschiebe gemeinsame Bereinigung, Integration, Schlüsselauflösung, Historisierung, KPI-Grundlagen und Datenqualitätsregeln aus einzelnen BI-Artefakten.
3. Beginne mit einer duplizierten, fachlich wertvollen Regel, statt alle Anwendungen gleichzeitig neu zu gestalten.
4. Halte Qlik-Skripte so schlank wie praktisch möglich und behalte nur Verbindung, Laden, Assoziationen, Zugriff, Performance und begründete analytische Logik.
5. Nutze Set Analysis für Qlik-spezifischen Analysekontext und nicht zur erneuten Umsetzung gemeinsamer Storno-, Währungs- oder Historienregeln.
6. Nutze DAX für semantisches Modell- und Filterkontextverhalten und nicht als einzige Implementierung wiederverwendbarer fachlicher Wahrheit.
7. Verbinde Excel mit zertifizierten Views oder governten Modellen und trenne kontrollierte Annahmen von Ist-Daten.
8. Veröffentliche einen stabilen Consumer-Vertrag mit Granularität, Definitionen, Owner, Aktualisierung, Qualität, Security und Änderungsrichtlinie.
9. Persistiere Datenqualitätsergebnisse außerhalb von Berichten und definiere das Veröffentlichungsverhalten explizit.
10. Zentralisiere die Zugriffsberechtigung und verwende in jedem Consumer den passenden Mechanismus zur Durchsetzung.
11. Erlaube Tool-spezifische Ausnahmen nur, wenn der Ausführungskontext einen realen Mehrwert erzeugt.
12. Dokumentiere jede Ausnahme mit Zweck, Owner, betroffener Definition, Test und Bedingung zur Entfernung.
13. Nutze eine zentrale QVD-Schicht, wenn sie Qlik-Duplizierung reduziert, verwende QVD-only-Logik jedoch nicht als Standardvertrag für Consumer außerhalb von Qlik.
14. Nutze vorhandene relationale Datenbanken, Scheduler und BI-Landschaften, bevor eine weitere Plattform ergänzt wird.
15. Behandle Fabric, Snowflake, Databricks und dbt als Umsetzungsoptionen und nicht als Voraussetzungen.
16. Entferne alte lokale Definitionen, nachdem der governte Ersatz validiert wurde.
17. Messe Erfolg an weniger widersprüchlichen Definitionen, schlankeren Consumer-Artefakten, schnelleren Änderungen und besserer Nachvollziehbarkeit.

Übergang zum nächsten Part

Sobald fachliche Logik außerhalb einzelner BI-Anwendungen definiert ist, kann dasselbe governte Datenprodukt mehrere Consumer bedienen, ohne sie auf eine gemeinsame Oberfläche festzulegen.

Der nächste Part, Ein Datenprodukt, mehrere Consumer, zeigt, wie ein governter Vertrag Qlik, Power BI, Excel und weitere Bereitstellungskanäle unterstützen kann und gleichzeitig die jeweiligen Consumer-Stärken erhält.

Eine fachliche Wahrheit darf nicht an ein einziges Consumer-Tool gebunden sein

Ein governed Data Product liefert dieselbe fachliche Wahrheit an Qlik, Power BI, Excel und APIs — ohne die Logik in jedes Tool zu kopieren.

Der Sales-Mart ist freigegeben. Die Qlik-App baut Kundenlogik neu; Power BI und Excel folgen. Drei Consumer, drei Interpretationen von Pipeline und Nettoumsatz.

Dieselben Vertriebsdaten können für sehr unterschiedliche Ergebnisse benötigt werden:

• Qlik-Nutzer explorieren Kunden-, Produkt-, Regions- und Zeitbeziehungen interaktiv;
• das Management erhält ein kontrolliertes Power-BI-Dashboard;
• der Vertriebsinnendienst arbeitet jeden Morgen mit einer aktualisierbaren Excel-Liste;
• eine operative Anwendung fragt aktuelle Vertriebsinformationen über eine API ab;
• ein KI-Assistent verwendet freigegebene Fakten und Definitionen für eine Management-Zusammenfassung.

Diese Consumer benötigen nicht dieselbe Schnittstelle, dieselbe Modellform oder dasselbe Interaktionsmuster. Sie benötigen jedoch dieselbe zugrunde liegende fachliche Wahrheit.

Ohne eine explizite Consumption-Architektur entwickelt jedes Tool schrittweise eine eigene Interpretation:

Qlik-App             Baut Kunden- und Umsatzlogik im Ladeskript erneut auf
Power-BI-Modell      Wiederholt Status-Mappings und KPI-Regeln in Power Query und DAX
Excel-Arbeitsmappe   Ergänzt lokale Korrekturen, Formeln und manuelle Kategorien
API-Service          Implementiert eine eigene Abfrage und Feldbenennung
KI-Kontextstrecke    Extrahiert eine undokumentierte Teilmenge ohne Qualität und Verantwortung

Das Unternehmen besitzt anschließend fünf Implementierungen statt fünf Nutzungswege.

Das Problem ist nicht die Anzahl der Tools. Qlik, Power BI, Excel, APIs und KI lösen unterschiedliche Aufgaben und können jeweils angemessen sein. Problematisch wird es, wenn jeder Consumer zu einer eigenständigen Quelle fachlicher Bedeutung wird.

Part 6, Fachliche Logik außerhalb der BI-Apps halten, hat das Prinzip etabliert, dass gemeinsame Bereinigung, Integration, Historisierung, KPI-Grundlagen und Qualitätsregeln außerhalb einzelner BI-Artefakte liegen sollten. Dieser Part erweitert dieses Prinzip auf die gesamte Consumption-Schicht.

Baue einen governten faktischen Kern. Veröffentliche ihn über stabile Verträge. Erlaube jedem Consumer nur die Semantik und Interaktion zu ergänzen, die für seinen Zweck spezifisch ist.

Architekturprinzip: ein governierter Kern, mehrere Nutzungswege

Ein Datenprodukt sollte als governte fachliche Fähigkeit verstanden werden und nicht als eine Tabelle für einen Bericht.

Das Produkt verantwortet die wiederverwendbaren Elemente, die jeder Consumer konsistent interpretieren muss:

Fachlicher Umfang
Granularität
Business Keys
Gemeinsame Dimensionen
Freigegebene faktische Beträge
KPI-Grunddefinitionen
Historische Interpretation
Qualitätsstatus
Sicherheitsattribute
Aktualisierungsverhalten
Verantwortung
Version und Änderungsrichtlinie

Consumer erhalten diesen Kern über Schnittstellen, die zu ihren technischen und operativen Anforderungen passen.

Mögliche Nutzungswege sind:

Diese Architektur setzt nicht voraus, dass ein einziges physisches semantisches Modell jedes Tool versorgt. Ein assoziatives Qlik-Modell und ein semantisches Power-BI-Modell dürfen unterschiedlich sein, weil sich ihre Engines und Interaktionsmuster unterscheiden. Entscheidend ist, dass beide Modelle aus demselben governten faktischen Vertrag abgeleitet werden.

Gemeinsame Daten bedeuten nicht identische Consumer-Modelle

Der Begriff Single Source of Truth wird häufig als „ein Datenbankobjekt, das jedes Tool direkt verwenden muss“ interpretiert. Das kann unnötig einschränkend werden.

Eine praktikable Architektur trennt drei Konzepte:

1. Autoritative fachliche Wahrheit — die governte faktische und dimensionale Grundlage.
2. Nutzungsvertrag — die stabile Schnittstelle und die Serviceerwartungen für eine Consumer-Klasse.
3. Consumer-Modell — die Tool-spezifische Darstellung für Analyse oder operative Nutzung.

Für ein Sales-Datenprodukt kann die gemeinsame Grundlage folgende Felder veröffentlichen:

business_date
order_id
order_line_id
customer_key
product_key
sales_region_key
quantity
net_revenue_amount
reporting_currency
quality_status
publication_timestamp

Qlik kann diese Felder in ein assoziatives Modell mit kanonischem Kalender und dokumentierter Link Table laden. Power BI kann ein Sternschema mit Datumsdimension und DAX-Zeitintelligenz verwenden. Excel kann eine denormalisierte Daily-Sales-View erhalten. Eine API kann nur die für einen operativen Prozess erforderlichen Felder ausgeben. KI kann eine eingeschränkte Context View mit freigegebenen Beschreibungen und Quellenhinweisen erhalten.

Das sind unterschiedliche Modelle desselben Produkts und keine unterschiedlichen Definitionen von Sales.

Eine hilfreiche Governance-Frage lautet:

Würde eine Änderung die fachliche Antwort für mehrere Consumer verändern?

Wenn ja, gehört die Änderung in das governte Datenprodukt oder seinen gemeinsamen Vertrag. Verändert sie ausschließlich Filterung, Darstellung, Navigation oder Interaktion eines einzelnen Tools bei unveränderten Fakten, darf sie im Consumer-Modell liegen.

Die einfachste sinnvolle Umsetzung

Mehrere Consumer zu unterstützen, erfordert weder Fabric noch Snowflake, Databricks, dbt oder ein neues Semantic-Layer-Produkt.

Ein kleineres Unternehmen kann mit vorhandenen Mitteln beginnen:

Eine minimale relationale Umsetzung kann folgende Objekte enthalten:

core.fact_sales
core.dim_customer
core.dim_product
core.dim_date
mart.sales_analysis
mart.sales_daily_excel
service.sales_api_v1
quality.sales_rule_result
control.data_product_publication

Die Objekte müssen am ersten Tag nicht physisch getrennt sein. Die Namen verdeutlichen unterschiedliche Verantwortlichkeiten.

Eine einfache Analyse-View kann so aussehen:

create view mart.sales_analysis as
select
    s.business_date,
    s.order_id,
    s.order_line_id,
    s.customer_key,
    c.customer_name,
    c.country_code,
    s.product_key,
    p.product_group,
    s.sales_region_key,
    s.quantity,
    s.net_revenue_amount,
    s.reporting_currency,
    s.quality_status,
    s.publication_timestamp
from core.fact_sales s
join core.dim_customer c
  on s.customer_key = c.customer_key
join core.dim_product p
  on s.product_key = p.product_key
where s.publication_status = 'PUBLISHED';

Die View ist nur dann sinnvoll, wenn die vorgelagerten Definitionen kontrolliert sind:

• net_revenue_amount folgt den freigegebenen Storno- und Währungsregeln;
• Kunden- und Produktschlüssel lösen die korrekten historischen Versionen auf;
• abgewiesene Datensätze werden nicht ohne Nachweis stillschweigend entfernt;
• publication_status berücksichtigt vereinbarte Qualitäts-Gates;
• Owner und Aktualisierungserwartung sind bekannt.

Qlik und Power BI können eine dimensionale Variante des Produkts verwenden. Excel erhält möglicherweise eine schmalere denormalisierte View. Eine API kann eine Service-spezifische View mit stabilen Feldnamen nutzen. Das Unternehmen besitzt weiterhin eine fachliche Definition.

Excel ist ein Consumer und kein Schatten-Data-Warehouse

Excel wird häufig als Problem behandelt, weil Tabellenkalkulationen duplizierte Daten, versteckte Formeln und unkontrollierte Kopien enthalten können. Diese Diagnose ist unvollständig.

Excel ist oft die effizienteste Oberfläche für:

• tägliche operative Listen;
• Ad-hoc-Analysen;
• PivotTables;
• Planung und Budgetierung;
• Was-wäre-wenn-Szenarien;
• Kommentare und Review-Workflows;
• kontrollierten Datenaustausch mit Fachanwendern.

Der Architekturfehler besteht nicht in der Nutzung von Excel. Er entsteht, wenn Anwender fehlende Datenprodukt-Fähigkeiten innerhalb von Excel neu aufbauen müssen.

Das Schatten-Data-Warehouse-Muster

Ein typischer unkontrollierter Prozess sieht so aus:

Die Arbeitsmappe verantwortet nun fachliche Logik, die gemeinsam bereitgestellt werden müsste:

Status 95 wird als storniert interpretiert
Fehlendes Land wird durch Deutschland ersetzt
Negative Beträge werden auf null gesetzt
Kundenduplikate werden manuell entfernt
Wechselkurs wird aus einer anderen Datei kopiert

Keine dieser Regeln ist automatisch falsch. Problematisch ist, dass sie lokal, schwach getestet, schwer auffindbar und für andere Consumer nicht verfügbar sind.

Das governte Excel-Muster

Ein kontrollierter Pfad kann wesentlich einfacher sein:

Sofern Microsoft-Umgebung, Tenant-Konfiguration und Lizenzierung es unterstützen, kann Excel ein freigegebenes semantisches Power-BI-Modell konsumieren. In einer einfacheren oder nicht auf Microsoft ausgerichteten Umgebung kann Power Query eine zertifizierte SQL View verwenden. Alternativ veröffentlicht die Plattform eine kontrollierte Datei mit Version, Aktualisierungszeitpunkt und Qualitätsstatus.

Eine governte Excel-Arbeitsmappe sollte die Grenze explizit machen:

Die Arbeitsmappe kann weiterhin operativ wichtig sein. Deshalb benötigt auch sie einen Owner, einen definierten Zweck, eine unterstützte Datenquelle sowie einen Änderungs- und Ablöseprozess.

Datenprodukt, semantisches Modell und Visualisierung sind unterschiedliche Schichten

Ein wiederkehrender Designfehler besteht darin, Datenprodukt, semantisches Modell und Bericht als ein Objekt zu behandeln.

Sie lösen unterschiedliche Aufgaben.

Schicht 1: governtes Datenprodukt

Das Datenprodukt verantwortet dauerhafte fachliche Bedeutung:

• integrierte Fakten und Dimensionen;
• freigegebene Granularität und Schlüssel;
• historische Interpretation;
• wiederverwendbare Basis-Measures und Beträge;
• Datenqualitätsregeln und Ergebnisstatus;
• Sicherheitsattribute;
• Verantwortung, Aktualisierung und Serviceerwartungen;
• versioniertes Schema und Änderungsrichtlinie.

Diese Schicht sollte unabhängig von einer einzelnen Berichtstechnologie nutzbar bleiben.

Schicht 2: Consumer-spezifisches semantisches Modell

Das semantische Modell übersetzt governte Daten in die Sprache einer bestimmten Analyse-Engine.

Für Qlik kann dies umfassen:

• assoziative Beziehungen;
• eine Link Table oder kanonische Datumsstrukturen, sofern begründet;
• Master Dimensions und Master Measures;
• Section Access mit governten Berechtigungsdaten;
• Set Analysis für selektionsabhängige Vergleiche.

Für Power BI kann dies umfassen:

• Sternschema-Beziehungen;
• Calculation Groups oder wiederverwendbare DAX-Measures, sofern sinnvoll;
• Row-Level Security auf Basis governter Berechtigungen;
• Anzeigeordner, Hierarchien und fachlich verständliche Namen;
• Zeitintelligenz-Measures im Filterkontext des Modells.

Für Excel kann die semantische Schicht leichter ausfallen:

• eine zertifizierte denormalisierte View;
• ein freigegebenes semantisches Modell für PivotTables;
• eine kontrollierte Power-Query-Transformation, die ausschließlich die Ausgabe formt;
• benannte Tabellen und dokumentierte lokale Berechnungen.

Ein semantisches Modell darf die zentrale faktische Regel nicht stillschweigend neu definieren. Es ergänzt analytischen Kontext.

Schicht 3: Visualisierung und Interaktion

Die letzte Schicht beantwortet Fragen wie:

• Welche Selektionen und Explorationspfade soll Qlik bereitstellen?
• Welche Management-Narrative und Drill-Pfade gehören in Power BI?
• Welche operativen Spalten, Kommentare und Filter benötigt Excel?
• Welche Felder und Statuscodes soll eine API zurückgeben?
• Welche Fakten, Definitionen und Quellenhinweise darf ein KI-Assistent verwenden?

Eine Visualisierung ist bewusst zweckgebunden. Wiederverwendung bedeutet nicht, dass jeder Nutzer dasselbe Dashboard sehen muss.

Konkretes Beispiel: ein Sales-Datenprodukt, fünf Consumer

Angenommen, das Unternehmen veröffentlicht ein governtes Sales-Datenprodukt mit folgendem Vertrag:

Qlik: explorative Analyse

Qlik erhält die governten Fakten und Dimensionen und baut ein assoziatives Consumption-Modell.

Das Basis-Measure bleibt einfach:

Sum([Nettoumsatz Amount])

Ein Tool-spezifischer Vergleich kann Set Analysis verwenden:

Sum({
    <BusinessYear = {"$(=Max(BusinessYear)-1)"}>
} [Nettoumsatz Amount])

Qlik ergänzt assoziative Exploration, Selektionen und Vergleichsverhalten. Stornierung, Währungsumrechnung oder historische Kundenzuordnung werden nicht erneut berechnet.

Power BI: Management-Dashboard

Power BI verwendet denselben faktischen Betrag in einem semantischen Modell:

Nettoumsatz :=
SUM ( Sales[NetRevenueAmount] )

Ein modellspezifischer Vergleich kann in DAX definiert werden:

Nettoumsatz Previous Year :=
CALCULATE (
    [Nettoumsatz],
    DATEADD ( 'Date'[Date], -1, YEAR )
)

Power BI ergänzt Berichtsstruktur, Filterkontext, Management-Navigation und Microsoft-orientierte Verteilung. Es entsteht keine separate Umsatzdefinition.

Excel: tägliche Vertriebsliste

Excel erhält eine für die operative Nutzung entworfene View:

business_date
order_number
customer_number
customer_name
sales_region
product_number
product_description
quantity
net_revenue_amount
quality_status
publication_timestamp

Die Arbeitsmappe kann bereitstellen:

• Filter und Sortierung;
• PivotTables;
• Kommentare;
• lokalen Nachverfolgungsstatus;
• klar getrennte Planungs- oder Forecast-Spalten.

Die Excel-spezifische View darf aus Gründen der Nutzbarkeit denormalisiert sein. Sie bleibt über dieselben Produktschlüssel und Definitionen nachvollziehbar.

API: operative Integration

Eine Anwendung benötigt möglicherweise einen stabilen Endpoint wie:

GET /api/v1/sales/orders/{orderId}

Der API-Vertrag kann folgende Antwort enthalten:

{
  "orderId": "4711",
  "businessDate": "2026-07-18",
  "customerId": "C-10042",
  "currency": "EUR",
  "netRevenue": 1250.00,
  "qualityStatus": "PASSED",
  "dataProductVersion": "sales-consumption-v1"
}

Die API ergänzt Service-spezifisches Verhalten wie Antwortcodes, Pagination, Request Limits und Endpoint-Versionierung. Der faktische Betrag stammt weiterhin aus dem governten Sales-Produkt.

KI: kontrollierte Management-Zusammenfassung

Ein KI-Assistent sollte keinen beliebigen Datenbank-Dump erhalten. Er verwendet einen freigegebenen Kontextvertrag, der beispielsweise folgende Inhalte enthält:

• aggregierte Sales-Fakten;
• freigegebene KPI-Namen und Beschreibungen;
• Perioden- und Währungskontext;
• Datenqualitäts- und Aktualisierungsstatus;
• zulässige Dimensionen;
• Quellkennungen oder Links;
• zugriffsgefilterte Datensätze.

Das Modell darf Fakten zusammenfassen oder erklären. Es darf keine neue Definition von Nettoumsatz erfinden und die Zugriffsregeln des Produkts nicht umgehen.

Ein geeigneter KI-Antwortkontext kann so aussehen:

Kennzahl: Nettoumsatz
Periode: 01.07.2026 bis 18.07.2026
Wert: 12,4 Millionen EUR
Vorjahresvergleich: +4,2 %
Qualitätsstatus: Bestanden, 0,3 % der Datensätze isoliert
Quellprodukt: sales-consumption-v1
Veröffentlichungszeitpunkt: 19.07.2026 05:42 CET

Der gemeinsame Kern macht die KI-Antwort reproduzierbarer, weil faktische Eingaben, Definitionen und Veröffentlichungsstatus explizit sind.

Der Nutzungsvertrag

Ein Consumer benötigt mehr als einen Tabellennamen. Er braucht eine verlässliche Vereinbarung darüber, was das Produkt bereitstellt und wie es sich verhält.

Ein sinnvoller Vertrag enthält mindestens folgende Elemente:

Der Vertrag kann in Markdown, YAML, einem Katalog, einer Datenbanktabelle oder einem dedizierten Datenprodukt-Tool gespeichert werden. Das Format ist zweitrangig. Die Vereinbarung muss sichtbar, versioniert und operativ durchgesetzt sein.

Schemastabilität allein reicht nicht aus

Eine Tabelle kann dieselben Spalten behalten und trotzdem ihre Bedeutung verändern.

Beispiele:

• Der Stornostatus wechselt von einem Codesatz zu einem anderen.
• Das Business-Datum ändert sich vom Auftragsdatum zum Buchungsdatum.
• Die Währungsumrechnung wechselt von täglichen auf monatliche Kurse.
• Das Kundenland wird nicht mehr historisch zum Transaktionszeitpunkt, sondern aus aktuellen Stammdaten ermittelt.
• Qualitätsfehler werden stillschweigend ausgeschlossen statt markiert.

Das sind semantische Vertragsänderungen, auch wenn keine Spalte ergänzt oder entfernt wird.

Eine Kompatibilitätsbewertung muss deshalb Folgendes berücksichtigen:

Schema
Bedeutung
Granularität
Historie
Timing
Qualitätsverhalten
Sicherheitsverhalten
Operative Verfügbarkeit

Consumer-Verträge dürfen sich unterscheiden, ohne die Wahrheit zu fragmentieren

Ein Sales-Datenprodukt kann mehrere legitime Verträge veröffentlichen:

sales_analytics_v1      Dimensionales Modell für Qlik und Power BI
sales_daily_excel_v1    Denormalisierte operative Liste für Excel
sales_api_v1            Schmaler Servicevertrag für Anwendungen
sales_ai_context_v1     Zugriffsgefilterter Kontext mit Definitionen und Quellenhinweisen

Das erzeugt nicht zwingend fachliche Duplikation. Die Verträge können aus demselben governten Kern generiert und gegen dieselben Regeln validiert werden.

Die Gefahr beginnt, sobald jeder Vertrag eine unabhängige fachliche Bedeutung entwickelt.

Eine hilfreiche Kontrolle besteht darin, gemeinsame und bewusst spezifische Bestandteile zu kennzeichnen:

Alternative Umsetzungen nach vorhandener Plattform

Das Architekturprinzip bleibt über Plattformen hinweg gleich. Die einfachste Umsetzung verwendet zunächst die Fähigkeiten, die bereits zuverlässig betrieben werden.

Bestehendes relationales Warehouse

Nutze:

• SQL-Tabellen und Views für Fakten, Dimensionen und Nutzer-Verträge;
• Datenbankrollen oder gefilterte Views für Zugriff;
• geplante Prozeduren oder vorhandenes ETL für die Veröffentlichung;
• persistente Qualitäts- und Kontrollregel-Tabellen;
• direkte Verbindungen für Qlik, Power BI und Excel, sofern geeignet.

Das reicht häufig aus.

Bestehende Qlik-orientierte Umgebung

Eine governte QVD-Schicht kann Qlik effizient temporär oder dauerhaft versorgen. Wenn mehrere Consumer ein erklärtes Ziel sind, sollte die autoritative Logik zusätzlich über einen plattformneutralen Pfad wie SQL-Tabellen, governte Dateien oder eine API verfügbar sein.

Power BI, Excel, APIs und KI sollten kein ausschließlich für Qlik optimiertes Modell rückwärts analysieren müssen, wenn breite Wiederverwendung beabsichtigt ist.

Bestehende Microsoft-Fabric-Umgebung

Fabric kann Warehouse- oder Lakehouse-Daten und semantische Power-BI-Modelle bereitstellen. Excel kann freigegebene Microsoft-Semantikmodelle konsumieren, sofern Konfiguration und Lizenzierung der Organisation dies zulassen. Qlik und andere Consumer verwenden geeignete SQL-, Datei- oder Service-Schnittstellen.

Die Microsoft-Integration kann den Betriebsaufwand senken. Sie ersetzt jedoch nicht die explizite Definition von Granularität, Qualität, Verantwortung und Änderungsverträgen.

Bestehende Snowflake-Umgebung

Snowflake-Tabellen, Views, Secure Views und Service-Schnittstellen können dieselben logischen Verträge umsetzen. dbt kann modulare SQL-Entwicklung, Tests, Dokumentation und Model Contracts ergänzen, wenn diese Fähigkeiten ein konkretes Teamproblem lösen.

Weder Snowflake noch dbt sind Voraussetzung für das Architekturprinzip.

Bestehende Databricks-Umgebung

Delta-Tabellen, SQL Views, governte Katalogobjekte oder Sharing-Schnittstellen können die Verträge veröffentlichen. Verteilte Verarbeitung und Sharing-Fähigkeiten werden dort eingesetzt, wo Workload, Skalierung oder plattformübergreifende Verteilung sie rechtfertigen.

Für ein kleines relationales Reporting-Problem sollte keine Spark-orientierte Komplexität eingeführt werden, wenn die vorhandene Datenbank es bereits zuverlässig löst.

On-Premises oder Hybrid

Nutze vorhandene SQL-Datenbanken, governte Dateien, QVDs, geplante Exporte und APIs. Ein hybrider Vertrag kann sensible Verarbeitung On-Premises halten und nur freigegebene Aggregate oder Service-Ausgaben an Cloud-Consumer veröffentlichen.

Der Cloud-Standort entscheidet nicht darüber, ob ein Produkt governt ist. Entscheidend sind Verantwortung, Definitionen, Kontrollen und Änderungsverhalten.

Typische Anti-Patterns

Ein Datenprodukt je Bericht bauen

Jedes Dashboard erhält einen separaten Extrakt und ein lokales Modell. Wiederverwendung bleibt gering, und jeder neue Consumer wiederholt dieselbe Integrationsarbeit.

Jeden Consumer zu derselben physischen Tabelle zwingen

Ein einziges Objekt wird breit, mehrdeutig und schwer zu optimieren. Qlik, Power BI, Excel und APIs dürfen legitimerweise unterschiedliche Formen benötigen.

Ein semantisches Power-BI-Modell als einzige Unternehmenswahrheit behandeln

Ein semantisches Modell kann eine wertvolle governte Consumption-Schicht sein. APIs, Qlik und nicht auf Microsoft ausgerichtete Workloads benötigen möglicherweise weiterhin plattformneutrale Fakten und Definitionen.

QVD-Verteilung automatisch als plattformneutral ansehen

QVDs sind für Qlik-Workloads effizient. Sie sind nicht automatisch der beste Vertrag für Power BI, Excel, APIs oder KI.

Excel verbieten, statt es zu governieren

Anwender erstellen weiterhin inoffizielle Exporte, weil die Plattform keinen nutzbaren operativen Vertrag anbietet. Der Schattenprozess wird weniger sichtbar, aber nicht weniger relevant.

Raw-Tabellen veröffentlichen und sie Datenprodukt nennen

Raw-Zugriff ohne Granularität, fachliche Bedeutung, Qualität, Owner, Sicherheit und Änderungsrichtlinie ist eine technische Schnittstelle und kein verlässliches Produkt.

Denselben KPI in Qlik, DAX, Excel und API-Code kopieren

Das Unternehmen erhält mehrere syntaktisch unterschiedliche Versionen derselben fachlichen Regel.

Jede Berechnung in eine gemeinsame semantische Schicht zwingen

Selektionsabhängige Analyse, berichtsspezifische Quoten, lokale Szenarien und Antwortlogik einer Anwendung gehören nicht alle in den gemeinsamen Kern.

Änderungen ohne Schemaänderung ignorieren

KPI-Bedeutung oder Historieregel ändern sich ohne neue Spalte. Consumer laufen technisch weiter, liefern aber eine andere fachliche Antwort.

KI direkten Zugriff auf uneingeschränkte Warehouse-Daten geben

Das Modell erhält Felder ohne freigegebene Definitionen, Zugriffsfilter, Aktualitätsinformation oder Qualitätsstatus. Eine technisch erfolgreiche Antwort kann fachlich trotzdem unsicher sein.

Neue Verträge veröffentlichen, ohne alte Pfade abzuschalten

Zertifizierte Views werden bereitgestellt, während manuelle Exporte, alte QVD-Generatoren und kopierte Arbeitsmappen unbegrenzt aktiv bleiben. Die Komplexität steigt, statt zu sinken.

Entscheidungshilfe

Nutze bei der Gestaltung eines Nutzungswegs folgende Fragen:

Wichtigste Empfehlungen

1. Entwirf das Datenprodukt um eine fachliche Fähigkeit und nicht um einen einzelnen Bericht.
2. Definiere Granularität, Schlüssel, KPI-Grundlagen, Historie, Qualität, Sicherheit und Verantwortung vor der Veröffentlichung von Schnittstellen.
3. Halte gemeinsame fachliche Bedeutung in einem governten Kern.
4. Erlaube getrennte Qlik-, Power-BI-, Excel-, API- und KI-Modelle, wenn sich ihre Zwecke unterscheiden.
5. Mache Consumer-spezifische Logik explizit und dokumentiere, warum sie in das Tool gehört.
6. Behandle Excel als unterstützten Consumer, wenn der Fachprozess es tatsächlich benötigt.
7. Trenne Ist-Daten von lokalen Planungsannahmen und manuellen Eingaben.
8. Veröffentliche Qualitätsstatus und Aktualitätsinformation gemeinsam mit den Daten.
9. Versioniere semantische Änderungen und nicht nur Schemaänderungen.
10. Verwende stabile Nutzungsverträge mit Ownern, Support-Pfaden und Abkündigungsregeln.
11. Nutze vorhandene SQL-, Datei-, QVD- oder Plattformfähigkeiten, bevor ein weiteres Produkt ergänzt wird.
12. Setze Fabric, Snowflake, Databricks oder dbt nur ein, wenn sie ein konkretes Integrations-, Skalierungs-, Kollaborations- oder Betriebsproblem lösen.
13. Halte Qlik- und Power-BI-Modelle so schlank, dass die zentrale fachliche Regel wiederverwendbar bleibt.
14. Gib APIs und KI dedizierte Verträge statt unkontrolliertem Direktzugriff.
15. Schalte alte Exporte, kopierte Formeln und redundante Pipelines nach der Consumer-Migration ab.

Übergang zum nächsten Part

Ein governtes Datenprodukt kann mehrere Consumer nur dann versorgen, wenn seine gemeinsamen Regeln über einen wartbaren Transformationspfad umgesetzt werden.

Der nächste Part, Transformationsoptionen, vergleicht, wo diese Transformationen ausgeführt werden können — in vorhandenem SQL, Warehouse-Prozeduren, Qlik-orientierten Schichten, dbt, Fabric, Snowflake, Databricks oder hybriden Kombinationen — und wie die einfachste Option gewählt wird, die den Produktvertrag zuverlässig erhält.

Die Transformationstechnologie ist eine Designentscheidung und nicht die Architektur

Transformation (SQL, dbt, Notebook, Dataflow) setzt Geschäftsregeln um — die Wahl des Werkzeugs ist Design, nicht die Architektur selbst.

Zwei Teams bauen dieselbe Storno-Regel: eines in dbt, eines in einem Spark-Notebook. Beide liefern abweichende Nettoumsatz-Zahlen, weil Verantwortung und Vertrag nie festgelegt wurden.

Jede Plattform braucht Transformationen. Keine Verantwortlichkeit legt automatisch fest, ob SQL, Stored Procedure, Notebook, Dataflow, native Funktion, ETL oder dbt nötig ist.

Dieselbe gültige Geschäftsregel kann auf mehreren technisch tragfähigen Wegen umgesetzt werden:

SQL View
Geplanter Tabellenaufbau
Stored Procedure
Low-Code-Dataflow
Python- oder Spark-Notebook
Native deklarative Pipeline
Klassisches ETL-Mapping
dbt-Modell und Datentest

Die Architektur wird fragil, wenn das Unternehmen mit dem Tool statt mit der Verantwortung beginnt.

Eine typische Tool-first-Diskussion klingt so:

„Wir haben Fabric, deshalb gehört jede Transformation in ein Notebook.“
„Wir nutzen Snowflake, deshalb muss jede Pipeline eine Dynamic Table sein.“
„Wir haben dbt eingeführt, deshalb muss jedes SQL migriert werden.“
„Das Qlik-Skript funktioniert bereits, deshalb bleibt es die führende Implementierung.“
„Der Fachanwender bevorzugt einen Dataflow, deshalb gehört die Regel dauerhaft dorthin.“

Jede Aussage kann für einen konkreten Workload sinnvoll sein. Keine davon ist eine allgemeine Architekturregel.

Part 7, Ein Datenprodukt, mehrere Consumer, hat gezeigt, dass Qlik, Power BI, Excel, APIs und KI dieselbe governte fachliche Wahrheit über unterschiedliche Verträge konsumieren können. Dieser Part beantwortet die nächste Frage: Wo soll die Transformation ausgeführt werden, die diese Wahrheit erzeugt?

Wähle den einfachsten Transformationsmechanismus, der die Anforderungen von Workload, Team und Governance erfüllt. Gib jeder gemeinsamen Geschäftsregel eine führende Implementierung und einen verantwortlichen Owner.

Architekturprinzip: eine Transformationsverantwortung, eine führende Implementierung

Eine Transformationsarchitektur sollte zuerst Verantwortlichkeiten definieren und erst danach Technologien zuordnen.

Die zentralen Fragen lauten:

Welche fachliche Bedeutung wird erzeugt?
Mit welcher Granularität wird das Ergebnis veröffentlicht?
Welche Quellabhängigkeiten bestehen?
Wer verantwortet die Korrektheit?
Wie wird die Regel getestet?
Wie wird die Implementierung geprüft und versioniert?
Wie wird sie geplant und überwacht?
Welche Consumer hängen von ihr ab?
Wie werden Breaking Changes kommuniziert?
Wo werden fehlerhafte Datensätze und Qualitätsnachweise gespeichert?

Eine hilfreiche Einordnung ist:

Diese Trennung verhindert zwei gegensätzliche Fehler.

Der erste Fehler besteht darin, alles zu zentralisieren, auch Logik, die nur innerhalb einer bestimmten Analyse-Engine sinnvoll ist. Der zweite besteht darin, jedem Tool eine eigene Version gemeinsamer fachlicher Bedeutung zu erlauben.

Viele gültige Wege für Datentransformationen

Die wichtigsten Transformationsoptionen überschneiden sich. Sie schließen sich nicht gegenseitig aus, und die meisten realen Plattformen verwenden mehr als eine davon.

SQL-Skripte, Views und materialisierte Tabellen

SQL ist häufig der einfachste Ausgangspunkt, wenn sich die Daten bereits in einer relationalen Datenbank, einem Warehouse oder einem per SQL zugänglichen Lakehouse befinden.

Geeignete Einsatzfelder sind:

• Joins, Filter und Aggregationen;
• dimensionale Modelle und Reporting Views;
• deterministische Geschäftsregeln;
• Datenbereinigung und Standardisierung;
• materialisierte Tabellen für reproduzierbare Performance;
• inkrementelle Verarbeitung, sofern die Plattform passende Muster unterstützt;
• Veröffentlichung stabiler Nutzer-Verträge.

Vorteile:

• verbreitetes Skillset;
• Ausführung in der Nähe der Daten;
• transparente Abfragelogik;
• geringe zusätzliche Toolkosten;
• einfache Integration mit Schedulern und BI-Consumern.

Risiken:

• unkontrollierte Ketten von Views;
• dupliziertes SQL in mehreren Jobs;
• schwache Deployment-Disziplin;
• verborgene Abhängigkeiten, wenn Objektreferenzen nicht katalogisiert werden;
• plattformspezifische Syntax, die spätere Migrationen erschwert.

Eine SQL-Implementierung ist nicht automatisch primitiv. Eine kleine, getestete Menge aus Views und geplanten Tabellen kann wartbarer sein als eine anspruchsvolle Toolchain, die das Team nicht zuverlässig betreiben kann.

Stored Procedures und Funktionen

Stored Procedures sind sinnvoll, wenn die Transformation kontrollierte prozedurale Ausführung, Transaktionsbehandlung, Verzweigungen, wiederverwendbare Datenbankroutinen oder eine explizite Schrittfolge benötigt.

Geeignete Einsatzfelder sind:

• komplexes Merge-Verhalten;
• Batch-Steuerungslogik;
• parametrisierte Verarbeitung;
• operative Fehlerbehandlung;
• datenbanknative Performanceoptimierung;
• kontrollierte Veröffentlichungsprozeduren.

Das Hauptrisiko ist fehlende Transparenz. Eine große Stored Procedure kann zu einer monolithischen Anwendung innerhalb der Datenbank werden. Werden Prozeduren eingesetzt, müssen sie weiterhin versioniert, geprüft, getestet, dokumentiert und mit sichtbaren Laufmetadaten verbunden werden.

Native Plattformfunktionen

Moderne Plattformen stellen integrierte Transformations- und Orchestrierungsfunktionen bereit. Beispiele sind Warehouse SQL, geplante Jobs, Tasks, deklarative Tabellen, Pipelines, materialisierte Views, native Quality Expectations und Plattformmonitoring.

Native Funktionen sind häufig die beste Option, wenn sie:

• die Anforderung bereits erfüllen;
• vom Betriebsteam verstanden werden;
• in Sicherheit, Zeitplanung und Monitoring integriert sind;
• externe Infrastruktur reduzieren;
• die erforderliche Performance und Zuverlässigkeit liefern.

Native-first bedeutet nicht native-only. Eine native Funktion sollte nur so lange die führende Implementierung bleiben, wie sie die fachlichen und Governance-Anforderungen weiterhin erfüllt.

Dataflows und klassische ETL-Werkzeuge

Low-Code-Dataflows und etablierte ETL-Werkzeuge bleiben gültige Transformationsmechanismen.

Sie sind besonders geeignet für:

• breite Connector-Abdeckung;
• visuelle Source-to-Target-Mappings;
• standardisierte operative Integration;
• Teams mit starken ETL- oder Power-Query-Kenntnissen;
• kontrollierte Datei- und API-Ingestion;
• Workflows, die Datenbewegung, Transformation und Orchestrierung verbinden.

Die Architekturanforderung ist dieselbe wie bei Code: Mappings benötigen Verantwortung, Versionierung, Reviews, Tests, Deployment-Disziplin und sichtbare Abhängigkeiten.

Eine visuelle Oberfläche dokumentiert sich nicht automatisch selbst. Komplexe Dataflows können ohne Konventionen und klare Komponentengrenzen genauso schwer verständlich werden wie komplexer Code.

Notebooks, Python und Spark

Notebooks sind wertvoll für Transformationen, die Python, Spark, erweiterte Bibliotheken, komplexe Datenstrukturen, Machine-Learning-Vorbereitung oder explorative Entwicklung benötigen.

Sie eignen sich für:

• umfangreiche verteilte Transformationen;
• Verarbeitung semistrukturierter Daten;
• Feature Engineering;
• fortgeschrittene Algorithmen;
• wiederverwendbare Python-Bibliotheken;
• Batch- und Streaming-Workloads;
• Untersuchungen, bevor eine stabile produktive Implementierung ausgewählt wird.

Ein Notebook wird riskant, wenn seine interaktive Form mit einem Betriebsmodell verwechselt wird. Produktive Notebooks benötigen Parameter, modularen Code, Dependency Management, automatisierte Tests, kontrollierte Umgebungen, Zeitplanung, Monitoring und einen klaren Owner.

dbt

Ein dbt-Modell ist primär ein Transformationsmodell, das in der Zieldatenplattform ausgeführt wird. dbt ergänzt SQL und abhängig von der Plattformunterstützung Python um ein strukturiertes Projektmodell: Abhängigkeiten, Umgebungen, Materialisierungen, Tests, Dokumentation, Metadaten und Deployment-Workflows.

dbt kann deutlichen Mehrwert schaffen, wenn das Team Folgendes benötigt:

• viele voneinander abhängige SQL-Modelle;
• einheitliche Projektkonventionen;
• Git-basierte Zusammenarbeit und Reviews;
• automatisierte Datentests;
• generierte Dokumentation und Lineage-Metadaten;
• reproduzierbare Entwicklungs- und Produktionsumgebungen;
• modularen Wiedergebrauch über Referenzen und Macros;
• CI/CD für Analytics Engineering.

dbt liefert weniger Mehrwert, wenn:

• nur wenige stabile SQL Views existieren;
• das Team keine Kapazität für eine weitere Betrieb und ein weiteres Repository besitzt;
• die native Plattformentwicklung bereits ausreichende Reviews, Tests und Deployments ermöglicht;
• der größte Teil der Transformationen Python, Spark, Streaming oder operative Integration statt SQL-zentrierter Modellierung ist;
• dbt eine bestehende führende Implementierung duplizieren würde.

Die richtige Frage lautet nicht „Nutzen wir dbt?“, sondern „Welche konkreten Probleme würde dbt besser lösen als die aktuelle Methode?“

Die einfachste sinnvolle Umsetzung

Eine governte Transformationsschicht benötigt weder eine neue Cloud-Plattform noch ein neues Transformationsprodukt.

Eine minimale Umsetzung kann Folgendes verwenden:

Für ein Customer-Datenprodukt kann die erste Version folgende Objekte enthalten:

staging.customer_source
core.customer
quality.customer_rule_result
control.customer_publication

Die Transformation kann zunächst eine View sein:

create view core.customer as
select
    trim(customer_id) as customer_id,
    upper(trim(country_code)) as country_code,
    cast(updated_at as timestamp) as updated_at,
    case when active_flag = 'Y' then 1 else 0 end as is_active,
    source_system,
    ingestion_timestamp
from staging.customer_source;

Ein separater Qualitätsschritt bewertet die Veröffentlichungsregel:

select
    customer_id,
    'ACTIVE_CUSTOMER_REQUIRED_FIELDS' as rule_id,
    case
        when customer_id is null then 'MISSING_CUSTOMER_ID'
        when country_code is null then 'MISSING_COUNTRY'
        when updated_at is null then 'MISSING_UPDATED_AT'
        when updated_at < current_timestamp - interval '30' day then 'STALE_UPDATED_AT'
        else 'PASSED'
    end as rule_result
from core.customer
where is_active = 1;

Die konkrete Datumsarithmetik und die Datentypen unterscheiden sich je nach SQL-Dialekt. Das Architekturmuster bleibt gleich:

1. Quelle in eine kontrollierte Kundenstruktur transformieren;
2. Geschäftsregel explizit auswerten;
3. Fehler und Ausführungsmetadaten persistieren;
4. nur entsprechend einer vereinbarten Qualitätsrichtlinie veröffentlichen;
5. Ergebnis über einen stabilen Vertrag für Consumer bereitstellen.

Diese Implementierung kann jahrelang ausreichen. Weitere Tools sollten nur eingeführt werden, wenn Skalierung, Zusammenarbeit, Tests, Lineage, Sprache oder Betriebsanforderungen sie rechtfertigen.

Nach Workload und Team entscheiden

Keine Transformationsmethode ist für jeden Workload die beste.

Die Entscheidung sollte mindestens acht Dimensionen berücksichtigen.

1. SQL-Anteil

Sind die meisten Transformationen relational, mengenorientiert und werden bereits in einem Warehouse ausgeführt, sind SQL Views, geplante Tabellen, native SQL-Jobs oder dbt natürliche Kandidaten.

Ein hoher SQL-Anteil rechtfertigt dbt nicht automatisch. Entscheidend sind die Anzahl der Modelle, die Komplexität der Abhängigkeiten, der Entwicklungsworkflow und die Governance-Anforderungen.

2. Python- oder Spark-Anteil

Wenn Transformationen stark von Python-Bibliotheken, verteilter Verarbeitung, unstrukturierten Daten oder fortgeschrittenen Algorithmen abhängen, können Notebooks oder native Python-/Spark-Pipelines die klarere führende Implementierung sein.

dbt kann parallel dazu SQL-zentrierte nachgelagerte Modelle übernehmen. Es sollte nicht gezwungen werden, Workloads zu verantworten, für die eine andere Engine und ein anderes Entwicklungsmodell besser geeignet sind.

3. Teamgröße und Verantwortung-Modell

Ein kleines Team mit zehn stabilen Transformationen kann mit SQL und einem vorhandenen Scheduler gut bedient sein.

Ein größeres Team mit Hunderten Modellen, mehreren Domänen und häufigen parallelen Änderungen benötigt stärkere Konventionen, isolierte Entwicklungsumgebungen, Code Reviews, automatisierte Tests und sichtbare Abhängigkeiten. dbt oder ein ausgereiftes natives Entwicklungsframework kann dann wesentlichen Mehrwert bieten.

4. Anforderungen an Git, Reviews und CI/CD

Transformationscode sollte unabhängig von der Technologie versioniert werden.

Die eigentliche Frage lautet, wie umfangreich der Entwicklungsworkflow sein muss:

• individuelle Versionshistorie;
• Pull Requests und Peer Reviews;
• automatisierte Kompilierung und Tests;
• Produktfreigabe zwischen Umgebungen;
• Rückbau;
• Deployment-Nachweise;
• Trennung von Entwicklungs- und Produktionszugängen.

Unterstützt die native Plattform diese Anforderungen ausreichend, kann eine weitere Schicht unnötig sein. Tut sie es nicht, kann dbt oder ein externer Engineering-Workflow eine wichtige Lücke schließen.

5. Low-Code-Anteil

Dataflows sind geeignet, wenn Business Technologists oder ETL-Spezialisten eine visuelle Entwicklungsoberfläche benötigen und die Transformationen in dieser Form verständlich bleiben.

Low-Code darf nicht Low-Governance bedeuten. Das Unternehmen benötigt weiterhin Namenskonventionen, wiederverwendbare Komponenten, Reviews, Deployments, Laufhistorie und Verantwortung.

6. Batch, Near-Real-Time und Streaming

Ein täglicher Dimensionsaufbau hat andere Anforderungen als ein kontinuierlicher Stream.

• Batch-Workloads können Views, geplantes SQL, Prozeduren, dbt oder ETL-Jobs verwenden;
• Near-Real-Time-Workloads können inkrementelle Jobs, Plattform-Tasks oder deklarative Tabellen einsetzen;
• Streaming-Workloads benötigen in der Regel natives Streaming oder Spark-basierte Verarbeitung;
• ereignisgetriebene operative Logik kann Streams, Trigger, Queues oder spezialisierte Services erfordern.

Ein batchorientiertes Transformationsframework sollte nicht zur einzigen Antwort auf eine Streaming-Anforderung gemacht werden.

7. Anforderungen an Tests und Dokumentation

Alle Ansätze können getestet werden. Aufwand und integrierte Unterstützung unterscheiden sich.

Eine kleine SQL-Implementierung kann eigene Assertions und eine Ergebnistabelle verwenden. dbt stellt ein standardisiertes Modell für Datentests und Dokumentation bereit. Native Plattformen können Quality Expectations, Monitoring und Lineage liefern. ETL-Werkzeuge können Validierungskomponenten und Laufmetadaten anbieten.

Der korrekte Vergleich lautet nicht, ob Tests theoretisch möglich sind. Entscheidend ist, ob das Team den erforderlichen Nachweis konsequent implementieren und betreiben kann.

8. Betriebsaufwand und Kosten

Jedes zusätzliche Framework erzeugt Betriebsverantwortung:

Betrieb
Credentials
Repositories
Paket- und Adapterversionen
Deployment-Pipelines
Jobplanung
Monitoring
Incident Handling
Training
Hersteller- oder Community-Support

Ein Tool, das die Entwicklung verbessert, aber einen nicht unterstützten Betriebsaufwand erzeugt, ist keine nachhaltige Architektur.

Ein kompakter Vergleich ist:

Eine Transformation, ein Owner

Das schädlichste Transformationsproblem ist meist nicht das falsche Tool, sondern duplizierte Verantwortung.

Ein verbreitetes Anti-Pattern sieht so aus:

Dataflow         Ersetzt fehlendes Land durch „DE“
Notebook         Ersetzt fehlendes Land durch den Standard des Quellsystems
Stored Procedure Lehnt den Datensatz ab
Qlik-Skript      Mappt fehlendes Land auf „Unknown“
dbt-Modell       Nutzt das Rechnungsland als Fallback

Alle fünf Implementierungen können technisch sinnvoll sein. Gemeinsam erzeugen sie fünf verschiedene Customer-Definitionen.

Eine führende Implementierung sollte Folgendes definieren:

„Ein Owner“ bedeutet nicht, dass nur eine Person die Transformation bearbeiten darf. Es bedeutet, dass es ein eindeutiges Verantwortungsmodell und eine Implementierung gibt, die für die gemeinsame Regel autoritativ ist.

Migration aus duplizierten Implementierungen

Ein sicheres Konsolidierungsmuster ist:

Alte Qlik-Mappings, Notebook-Zellen oder Excel-Formeln sollten nach Abnahme des governten Ersatzes nicht „zur Sicherheit“ bestehen bleiben. Ruhende Duplikate werden beim nächsten Incident oder bei einer dringenden Änderung häufig wieder aktiviert.

Native zuerst oder dbt?

Native-first und dbt-gestützte Transformation sind beide gültige Strategien.

Native-first ist eine starke Wahl, wenn

• die Plattform bereits geeignetes SQL, Tabellen, Pipelines und Zeitplanung bereitstellt;
• die Transformationsmenge klein oder mittelkomplex ist;
• das Team das native Betriebsmodell versteht;
• Sicherheit und Monitoring bereits integriert sind;
• die Deployment-Anforderungen ausreichend abgedeckt sind;
• die meiste Logik plattformspezifisch oder eng mit nativem Streaming und Processing verbunden ist;
• eine weitere Betrieb Qualität oder Liefergeschwindigkeit nicht wesentlich verbessern würde.

Beispiele sind:

• ein bestehendes SQL-Server-Warehouse mit Views, Prozeduren und SQL Agent oder einem anderen Scheduler;
• Fabric Warehouse SQL in Verbindung mit Pipelines, Dataflow Gen2 oder Notebooks, wo erforderlich;
• Snowflake SQL mit Dynamic Tables oder Streams und Tasks für geeignete Workloads;
• Databricks SQL oder Python mit nativen Jobs und Lakeflow Pipelines;
• eine klassische ETL-Plattform, die vom Team bereits zuverlässig betrieben wird.

dbt schafft klaren Mehrwert, wenn

• die Transformationsschicht überwiegend SQL-zentriert ist;
• die Anzahl der Modelle und Abhängigkeiten wächst;
• mehrere Engineers dasselbe Projekt ändern;
• Pull Requests und automatisierte Prüfungen erforderlich sind;
• Tests und Dokumentation gemeinsamen Konventionen folgen sollen;
• Entwicklungs-, Test- und Produktionsumgebungen reproduzierbar sein müssen;
• Lineage und Modellmetadaten über einen großen Transformationsgraphen benötigt werden;
• modulare Referenzen und Macros wiederholtes SQL reduzieren;
• das Team dbt als Produkt betreiben kann und es nicht nur installiert.

dbt entfernt keine Plattformverantwortung

Die Zieldatenplattform führt die Berechnung weiterhin aus. Das Team muss weiterhin Folgendes verstehen:

• Warehouse-Größe und Kosten;
• SQL-Dialekt der Plattform;
• physisches Design und Performance;
• Zugriffskontrolle;
• Zeitplanung und Jobzuverlässigkeit;
• Quell-Ingestion;
• Streaming und operative Integration;
• Incident Management;
• Veröffentlichung von Datenprodukten.

Auch Portabilität muss präzise betrachtet werden. dbt kann Kopplung reduzieren, weil Projektstruktur und Abhängigkeitslogik von der DDL-Orchestrierung getrennt werden. SQL-Funktionen, Datentypen, inkrementelle Strategien und Performanceeinstellungen unterscheiden sich jedoch weiterhin zwischen Plattformen. Eine Migration wird meist einfacher, aber nicht automatisch.

Das Anti-Pattern der halben Migration vermeiden

Ein häufiger Fehler ist die Einführung von dbt, ohne festzulegen, was dbt verantwortet:

Einige Modelle liegen in dbt
Andere werden weiterhin durch Prozeduren erzeugt
Ein Notebook überschreibt ein dbt-Ziel
Ein Dataflow ergänzt eine weitere Korrektur
Qlik wiederholt die abschließende Geschäftsregel
Keine Komponente ist eindeutig autoritativ

Eine dbt-Einführung sollte explizite Grenzen definieren:

dbt verantwortet              SQL-zentrierte kuratierte Modelle und Datenproduktmodelle
dbt verantwortet nicht        Quell-Ingestion, Streaming oder Python-intensive Verarbeitung, sofern nicht explizit vorgesehen
native Plattform verantwortet Compute, Storage, Sicherheit, Scheduling-Integration und Plattformbetrieb
Consumer-Tools verantworten   ausschließlich Tool-spezifische Semantik und Darstellung

Die Grenze kann anders gewählt werden. Sie darf nicht implizit bleiben.

Konkretes Beispiel: Jeder aktive Kunde muss veröffentlichungsfähig sein

Angenommen, das Unternehmen definiert folgende Regel:

Jeder aktive Kunde benötigt eine Customer ID, ein Land und einen Änderungszeitpunkt innerhalb des vereinbarten Aktualitätsfensters.

Für das Beispiel beträgt das Aktualitätsfenster 30 Tage. In einem realen Datenprodukt sollte der Grenzwert konfigurierbar und vom Customer Data Owner freigegeben sein.

Fachlicher Vertrag

Die Implementierungstechnologie darf variieren. Die Bedeutung des Ergebnisses muss identisch bleiben.

Option 1: SQL View und geplante Qualitätstabelle

Die Transformations-View standardisiert die Felder:

create view curated.customer as
select
    nullif(trim(customer_id), '') as customer_id,
    upper(nullif(trim(country_code), '')) as country_code,
    cast(updated_at as timestamp) as updated_at,
    case when active_flag = 'Y' then 1 else 0 end as is_active,
    source_system,
    source_record_id,
    ingestion_timestamp
from staging.customer_source;

Ein geplantes Statement persistiert Fehler:

insert into quality.customer_rule_result (
    execution_id,
    rule_id,
    source_system,
    source_record_id,
    customer_id,
    failure_reason,
    evaluated_at
)
select
    :execution_id,
    'ACTIVE_CUSTOMER_REQUIRED_FIELDS',
    source_system,
    source_record_id,
    customer_id,
    case
        when customer_id is null then 'MISSING_CUSTOMER_ID'
        when country_code is null then 'MISSING_COUNTRY'
        when updated_at is null then 'MISSING_UPDATED_AT'
        when updated_at < current_timestamp - interval '30' day then 'STALE_UPDATED_AT'
    end,
    current_timestamp
from curated.customer
where is_active = 1
  and (
      customer_id is null
      or country_code is null
      or updated_at is null
      or updated_at < current_timestamp - interval '30' day
  );

Dies ist eine gültige Implementierung, wenn vorhandene Datenbank, Scheduler und Monitoring ausreichen.

Option 2: Microsoft Fabric

Mehrere Fabric-Implementierungen können gültig sein:

Ein minimales Warehouse-SQL-Muster kann dieselbe View- und Qualitätstabellenlogik wie das generische SQL-Beispiel verwenden, angepasst an die unterstützte T-SQL-Syntax.

Eine Dataflow-Gen2-Implementierung kann customer_id, country_code und updated_at standardisieren, gültige Datensätze an das kuratierte Ziel weiterleiten und abgewiesene Datensätze in einem Qualitätsziel persistieren. Ein Notebook ist geeignet, wenn die Regel Teil einer größeren Spark-Transformation ist oder Python-Bibliotheken benötigt.

Die Architekturkontrolle ist nicht der Typ des Fabric-Items. Entscheidend ist, dass ein Item als autoritativ festgelegt wird, Code oder Definition versioniert sind, das Qualitätsergebnis persistiert wird und Qlik oder Power BI die Regel nicht wiederholen.

Option 3: Snowflake

Snowflake kann die Regel mit gewöhnlichen SQL Views und Tabellen, einer Dynamic Table für deklaratives Refresh-Verhalten oder Streams und Tasks für explizites CDC und prozedurale Kontrolle implementieren.

Eine konzeptionelle Dynamic-Table-Implementierung ist:

create or replace dynamic table curated.active_customer
    target_lag = '30 minutes'
    warehouse = transform_wh
as
select
    nullif(trim(customer_id), '') as customer_id,
    upper(nullif(trim(country_code), '')) as country_code,
    updated_at,
    source_system,
    source_record_id,
    case
        when customer_id is null then 'MISSING_CUSTOMER_ID'
        when country_code is null then 'MISSING_COUNTRY'
        when updated_at is null then 'MISSING_UPDATED_AT'
        when updated_at < dateadd(day, -30, current_timestamp()) then 'STALE_UPDATED_AT'
        else 'PASSED'
    end as quality_status
from staging.customer_source
where active_flag = 'Y';

Ein separater Qualitätsschritt kann fehlerhafte Datensätze mit den für das Governance-Modell erforderlichen Ausführungs- und Regelmetadaten persistieren.

Dynamic Tables sind für deklarative Tabellenpipelines attraktiv. Streams und Tasks bleiben sinnvoll, wenn der Prozess explizite Änderungsverfolgung, getriggerte Verarbeitung, Task-Graphen oder eigene prozedurale Schritte benötigt. Die Auswahl sollte dem Workload folgen und kein plattformweites Mandat sein.

Option 4: Databricks

Databricks kann die Regel in SQL, Python oder einer deklarativen Lakeflow-Pipeline implementieren.

Eine SQL-Implementierung kann eine kuratierte Tabelle oder materialisierte View erzeugen. Eine PySpark-Implementierung ist sinnvoll, wenn die Customer-Transformation Teil einer größeren verteilten Pipeline ist:

from pyspark.sql import functions as F

customer = (
    spark.table("staging.customer_source")
    .select(
        F.when(F.trim("customer_id") == "", None)
         .otherwise(F.trim("customer_id"))
         .alias("customer_id"),
        F.upper(F.when(F.trim("country_code") == "", None)
         .otherwise(F.trim("country_code")))
         .alias("country_code"),
        F.col("updated_at").cast("timestamp").alias("updated_at"),
        (F.col("active_flag") == "Y").alias("is_active"),
        "source_system",
        "source_record_id"
    )
)

Der Qualitätsstatus kann anschließend in SQL oder Python abgeleitet und in eine Delta-Tabelle wie quality.customer_rule_result geschrieben werden.

Deklarative Lakeflow-Pipelines sind geeignet, wenn das Unternehmen ein verwaltetes deklaratives Framework für Batch- oder Streaming-Tabellen und Flows in SQL oder Python benötigt. Ein normales Notebook oder ein geplanter Job kann für einen kleinen stabilen Workload weiterhin einfacher sein.

Option 5: dbt-Modell und Tests

Eine dbt-Implementierung kann die Transformation in einem SQL-Modell ablegen:

-- models/curated/customer.sql

select
    nullif(trim(customer_id), '') as customer_id,
    upper(nullif(trim(country_code), '')) as country_code,
    cast(updated_at as timestamp) as updated_at,
    case when active_flag = 'Y' then true else false end as is_active,
    source_system,
    source_record_id,
    ingestion_timestamp
from {{ source('staging', 'customer_source') }}

Standardtests können strukturelle Erwartungen validieren:

version: 2

models:
  - name: customer
    columns:
      - name: customer_id
        data_tests:
          - not_null:
              config:
                where: "is_active = true"
      - name: country_code
        data_tests:
          - not_null:
              config:
                where: "is_active = true"
      - name: updated_at
        data_tests:
          - not_null:
              config:
                where: "is_active = true"

Ein einzelner Datentest kann die vollständige Aktualitätsregel ausdrücken:

-- tests/active_customer_required_fields.sql

select *
from {{ ref('customer') }}
where is_active = true
  and (
      customer_id is null
      or country_code is null
      or updated_at is null
      or updated_at < current_timestamp - interval '30' day
  )

Da ein fehlgeschlagener Test allein nicht immer als operativer Nachweis ausreicht, kann ein separates Audit-Modell fehlerhafte Datensätze im governten Qualitätsschema persistieren:

-- models/quality/customer_rule_result.sql

select
    'ACTIVE_CUSTOMER_REQUIRED_FIELDS' as rule_id,
    source_system,
    source_record_id,
    customer_id,
    current_timestamp as evaluated_at
from {{ ref('customer') }}
where is_active = true
  and (
      customer_id is null
      or country_code is null
      or updated_at is null
      or updated_at < current_timestamp - interval '30' day
  )

Das genaue SQL bleibt adapter- und plattformabhängig. dbt ergänzt Abhängigkeitsmanagement, Testkonventionen, Dokumentation und Deployment-Workflow. Die fachliche Definition ändert sich nicht.

Option 6: Dataflow oder klassisches ETL-Mapping

Dieselbe Regel kann visuell ausgedrückt werden:

Dies ist vollständig gültig, wenn das Mapping versioniert, geprüft, getestet, überwacht und verantwortet wird. Auf die visuelle Implementierung darf keine weitere undokumentierte Korrektur in einem Notebook oder Qlik-Skript folgen.

Ein Ergebnis über alle Implementierungen

Unabhängig von der Technologie sollte der veröffentlichte Vertrag vergleichbar sein:

customer_id
country_code
updated_at
is_active
quality_status
quality_rule_id
source_system
source_record_id
publication_timestamp

Für denselben Eingabedatensatz muss jede gültige Implementierung dasselbe Ergebnis erzeugen.

Beispiel:

Eingabe
customer_id       = C-10042
country_code      = null
updated_at        = 2026-07-10 09:30:00
active_flag       = Y

Erwartetes Ergebnis
quality_status    = FAILED
quality_rule_id   = ACTIVE_CUSTOMER_REQUIRED_FIELDS
failure_reason    = MISSING_COUNTRY
publication       = entsprechend der vereinbarten Schweregradrichtlinie

Der parallele Vergleich der Ergebnisse ist die zuverlässigste Methode beim Wechsel der Implementierungstechnologie.

Plattformmuster ohne verpflichtenden Stack

Die vorhandene Plattform sollte die Implementierung beeinflussen, aber nicht die Architektur neu definieren.

Keine Zeile dieser Tabelle beschreibt einen verpflichtenden Ziel-Stack.

Qlik, Power BI und Excel bleiben Consumer

Dieser Part behandelt Transformations-Verantwortung und verbietet keine Transformationsfunktionen innerhalb von BI-Tools.

Eine schlanke Qlik-App kann weiterhin:

• das veröffentlichte Customer-Datenprodukt laden;
• erforderliche Assoziationen erzeugen;
• Section Access mit governten Berechtigungsdaten implementieren;
• Set Analysis für selektionsabhängige Vergleiche verwenden;
• Felder für das assoziative Modell optimieren.

Ein semantisches Power-BI-Modell kann weiterhin:

• Beziehungen und Hierarchien definieren;
• DAX-Measures ergänzen, die vom Filterkontext abhängen;
• Row-Level Security anwenden;
• berichtsspezifische Zeitintelligenz bereitstellen.

Eine Excel-Arbeitsmappe kann weiterhin:

• eine kontrollierte Ausgabe für die Nutzbarkeit formen;
• PivotTables, Formatierung und Kommentare bereitstellen;
• klar getrennte Planungsannahmen verwalten.

Keiner dieser Consumer sollte unabhängig entscheiden, dass ein aktiver Kunde ohne Land zulässig ist oder ein anderes Aktualitätsfenster verwenden darf.

Typische Anti-Patterns

Tool-first-Architektur

Das Team wählt das Transformationswerkzeug, bevor es Workload, Verantwortung, Qualität und Betriebsanforderungen versteht.

Dieselbe Regel in mehreren Tools

Ein Dataflow, Notebook, eine Prozedur, ein dbt-Modell und ein Qlik-Skript implementieren jeweils eine Variante derselben Customer- oder Umsatzregel.

Notebook als undokumentierte Produktionsanwendung

Ein exploratives Notebook wird unverändert geplant, hängt von verborgenem Zustand ab und besitzt weder Tests, Paketkontrolle noch Owner.

Endlose View-Ketten

Views rufen Views auf, die weitere Views aufrufen, bis Lineage und Performance nicht mehr nachvollziehbar sind.

Monolithische Stored Procedure

Eine Prozedur übernimmt Ingestion, Bereinigung, Historisierung, Qualität, Veröffentlichung und Consumer-spezifische Ausgabe ohne modulare Grenzen.

Low-Code ohne Engineering-Disziplin

Ein visueller Prozess gilt als selbstdokumentierend und wird ohne Review oder Deployment-Kontrolle direkt in Produktion geändert.

dbt als Richtlinie statt als Lösung

Jede Transformation wird nach dbt migriert, obwohl native Funktionen, Python oder vorhandenes SQL einfacher und besser unterstützt wären.

dbt plus native Duplizierung

Das dbt-Modell existiert, aber eine native Pipeline erzeugt dieselbe Business-Tabelle erneut, weil Verantwortung nie geklärt wurde.

Tests ausschließlich in Dashboards

Qualität wird als rote Kennzahl in Power BI oder Qlik beobachtet, aber fehlerhafte Datensätze und Regelausführungen werden nicht zentral persistiert.

Stilles Verwerfen

Ungültige Datensätze werden ohne Fehlergrund, Regel-ID, Owner oder Wiederherstellungsprozess ausgefiltert.

„Ein Owner“ nur auf dem Papier

Eine Rolle ist dokumentiert, aber kein Team verantwortet Deployment, Monitoring, Incidents und Änderungskommunikation.

Logik läuft in Consumer aus

Eine temporäre Korrektur in Qlik, Power Query oder Excel wird zur dauerhaften Implementierung gemeinsamer fachlicher Bedeutung.

Entscheidungshilfe

Nutze diese Fragen in der angegebenen Reihenfolge:

Eine kompakte Regel lautet:

Vorhandene Fähigkeit löst das Problem          → verwenden
Native Funktion verbessert den Betrieb         → bewusst verwenden
SQL-Modellnetz benötigt Zusammenarbeit         → dbt prüfen
Python/Spark ist Bestandteil des Workloads     → Notebook oder native Pipeline verwenden
Low-Code ist die wartbare Teamoberfläche       → Dataflow oder ETL-Werkzeug verwenden
Gemeinsame Regel existiert bereits             → wiederverwenden, nicht duplizieren
Kein klarer Owner oder Testnachweis             → Architektur ist nicht bereit

Ein praktikabler Einführungspfad

Die Modernisierung von Transformationen sollte nicht mit der Migration jedes Jobs beginnen.

Beginne mit einer Geschäftsregel, die dupliziert, wichtig und messbar ist.

Gute erste Kandidaten sind:

• Zulässigkeit aktiver Kunden;
• Stornobehandlung;
• Währungsnormalisierung;
• Zuordnung von Produkthierarchien;
• Kunden-Länder-Mapping;
• Klassifikation von Rechnungsstatus;
• eine zentrale Basisdefinition für Umsatz.

Das Ziel der ersten Migration besteht nicht darin, die Überlegenheit eines Tools zu beweisen. Es besteht darin zu zeigen, dass eine governte Implementierung mehrere inkonsistente Varianten ersetzen kann.

Wichtigste Empfehlungen

1. Definiere die Transformationsverantwortung, bevor das Tool ausgewählt wird.
2. Gib jeder gemeinsamen Geschäftsregel eine führende Implementierung und einen verantwortlichen Owner.
3. Beginne mit vorhandenem SQL, Scheduling und nativen Plattformfähigkeiten, wenn sie ausreichen.
4. Nutze Views für einfache wiederverwendbare Logik und materialisiere Ergebnisse, wenn Performance, Publikationsstabilität oder Workload dies erfordern.
5. Nutze Stored Procedures für begründetes prozedurales und transaktionales Verhalten und nicht als undokumentierten Plattformmonolithen.
6. Nutze Dataflows und klassische ETL-Werkzeuge, wenn ihre Connector-, Low-Code- und Betriebsstärken zum pflegenden Team passen.
7. Nutze Notebooks, Python und Spark für Workloads, die diese Fähigkeiten tatsächlich benötigen.
8. Überführe Notebooks in einen kontrollierten Produktions-Lifecycle, bevor sie zu kritischen Pipelines werden.
9. Nutze native Fabric-, Snowflake-, Databricks- oder Datenbankfunktionen, wenn Integration und Betriebswert die Plattformkopplung rechtfertigen.
10. Ergänze dbt, wenn modulares SQL, Abhängigkeitsmanagement, Tests, Dokumentation, Reviews und reproduzierbare Umgebungen ein reales Kollaborationsproblem lösen.
11. Führe dbt nicht nur ein, weil es in modernen Data Stacks verbreitet ist.
12. Berücksichtige, dass dbt in der Ziel-Engine ausgeführt wird und SQL-Dialekt- oder Plattformunterschiede nicht beseitigt.
13. Trenne Verantwortungen für Orchestrierung, Transformation, Qualitätsnachweise und Consumption explizit.
14. Persistiere fehlgeschlagene fachliche Regeln, wenn Remediation und Verantwortlichkeit relevant sind.
15. Halte Qlik-Skripte, Power Query und DAX frei von duplizierter gemeinsamer Transformationslogik.
16. Erlaube Qlik-, Power-BI- und Excel-spezifische Logik nur, wenn der jeweilige Consumer-Kontext sie benötigt.
17. Behandle eine governte QVD-Schicht als gültige Brownfield-Option und nicht als verpflichtenden unternehmensweiten Vertrag.
18. Betreibe native und ablösende Implementierungen nach einer Migration nicht dauerhaft als gleichberechtigte Wahrheiten.
19. Entscheide nach Workload, Team und Betriebsmodell statt nach Plattformmode.
20. Miss Erfolg an weniger duplizierten Regeln, schnelleren kontrollierten Änderungen, sichtbarer Qualität und geringerem Betriebsrisiko.

Übergang zum nächsten Part

Eine Transformationsstrategie ist erst vollständig, wenn sie über unterschiedliche Technologielandschaften hinweg verständlich bleibt.

Der nächste Part, Eine Architektur – mehrere Plattformen, ordnet dieselben Architekturverantwortungen Microsoft Fabric, Snowflake, Databricks, klassischen SQL-Warehouses, Qlik-orientierten Umgebungen und hybriden Kombinationen zu, ohne einen Stack als allgemeine Pflicht darzustellen.

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.

Ein Warehouse ist mit dem ersten produktiven Bericht nicht fertig

Ein Warehouse kann am Tag der Veröffentlichung technisch korrekt sein und wenige Monate später trotzdem unzuverlässig werden.

Quellen ändern sich. Fachliche Definitionen entwickeln sich weiter. Pipelines schlagen fehl. Datenmengen wachsen. Kosten verändern sich. Owner wechseln ihre Rolle. Consumer erzeugen Abhängigkeiten, die während des ursprünglichen Projekts nicht sichtbar waren. Alte Views bleiben aktiv, weil niemand weiß, ob sie noch verwendet werden. Ein KPI erhält eine neue Definition, während eine Qlik-Anwendung, ein Power-BI-Modell und mehrere Excel-Arbeitsmappen weiterhin die vorherige Logik verwenden.

Der technische Aufbau ist deshalb nur ein Teil der Architektur.

Part 9, Eine Architektur – mehrere Plattformen, hat gezeigt, dass dieselben logischen Warehouse-Verantwortlichkeiten mit einer vorhandenen SQL-Plattform, Microsoft Fabric, Snowflake, Databricks oder bewusst gewählten Hybridkombinationen umgesetzt werden können. Dieser letzte Part behandelt, was jede Umsetzung nach dem Aufbau benötigt: ein Betriebsmodell.

Eine nachhaltige Datenplattform muss folgende Fragen beantworten können:

Wer verantwortet die fachliche Bedeutung?
Wer betreibt den technischen Service?
Welche Version ist in Produktion?
Welche Tests müssen vor der Veröffentlichung bestehen?
Wie aktuell sind die Daten?
Welche Consumer hängen vom Produkt ab?
Was passiert, wenn ein Lauf fehlschlägt?
Wie wird eine Änderung freigegeben und ausgerollt?
Wie kann ein Release zurückgesetzt oder korrigiert werden?
Was kostet die Plattform?
Wann wird eine alte Schnittstelle abgekündigt und stillgelegt?

Hängen diese Antworten vom Gedächtnis einer einzelnen Person ab, ist die Plattform nicht governt.

Ein Warehouse ist ein Produkt mit Lebenszyklus, Consumern und Serviceerwartungen — kein einmaliges Projekt, das nach dem Go-live endet.

Architekturprinzip: explizite Verträge betreiben

Betrieb und Governance werden häufig als getrennte Disziplinen behandelt.

Betrieb wird mit Zeitplänen, Logs, Alerts und Support verbunden. Governance wird mit Definitionen, Verantwortung, Richtlinien und Freigaben verbunden. In der Praxis treffen sich beide am Datenprodukt.

Ein Produkt kann nicht zuverlässig betrieben werden, wenn seine erwartete Bedeutung und sein Service Level unbekannt sind. Eine Definition kann nicht wirksam governt werden, wenn niemand feststellen kann, ob ihre Implementierung gelaufen ist, die Quality Gates bestanden hat und bei den Consumern angekommen ist.

Ein praktikabler Betriebsvertrag enthält mindestens:

Der Vertrag setzt keine dedizierte Governance-Suite voraus. Ein kleines Team kann ihn in versioniertem Markdown, einem Ticketsystem, einem Katalog, einem Repository und einigen Control-Tabellen pflegen.

Das erforderliche Ergebnis ist kein bestimmtes Tool. Es ist der Nachweis, dass Verantwortlichkeiten und Entscheidungen existieren.

Von der Entwicklung zur Produktion

Eine Produktionsumgebung sollte nicht der Ort sein, an dem eine ungeprüfte Geschäftsregel erstmals getestet wird.

Dev, Test und Produktion sind Verantwortlichkeiten

Umgebungstrennung benötigt nicht immer drei große, vollständig unabhängige Plattformen.

Eine kleine Umsetzung kann Folgendes verwenden:

Einen Datenbankserver
Getrennte DEV-, TEST- und PROD-Datenbanken oder -Schemas
Ein versioniertes Repository
Einen Scheduler mit getrennten Jobs
Eingeschränkte Produktionsberechtigungen
Eine dokumentierte Release-Checkliste

Eine größere Umsetzung kann Folgendes verwenden:

Getrennte Workspaces, Accounts oder Subscriptions
Infrastruktur- und Plattformkonfiguration als Code
Pull Requests und verpflichtende Reviews
Automatisierte Build- und Teststufen
Umgebungsspezifische Parameter und Secrets
Deployment-Freigaben
Validierung nach dem Deployment
Automatisierter Rollback oder kontrollierter Roll-forward

Beides kann valide sein.

Die Mindestanforderung lautet, dass Entwicklungsarbeit Produktion nicht unbemerkt verändern kann und dass ein Release identifiziert, geprüft, reproduziert und unterstützt werden kann.

Ein Release besteht aus mehr als Code

Ein vollständiges Datenprodukt-Release kann enthalten:

• Transformationscode;
• Schema- oder Tabellenänderungen;
• Qualitätsregeln und erwartete Schwellenwerte;
• Pipeline- oder Jobdefinitionen;
• Umgebungsparameter;
• Zugriffsänderungen;
• Änderungen am Semantikmodell;
• notwendige Änderungen an Qlik-, Power-BI- oder Excel-Consumern;
• Dokumentation und Lineage-Metadaten;
• Release Notes;
• Migrationsanweisungen;
• Rückbau- oder Roll-forward-Anweisungen;
• Nutzer-Kommunikation;
• eine Deprecation-Mitteilung für ersetzte Schnittstellen.

Nur SQL oder ein Notebook auszurollen, während Vertrag, Tests und Consumer unverwaltet bleiben, erzeugt unvollständige Releases.

Ein einfacher manueller Release-Pfad

Ein kleines Team kann mit einer disziplinierten Checkliste sicher arbeiten:

Phase A — in DEV nachweisen

Phase B — ausrollen und bestätigen

Der Prozess ist manuell, aber nicht informell.

Ein automatisierter CI/CD-Pfad

Automatisierung wird wertvoll, wenn Änderungen häufig sind, viele Mitwirkende parallel arbeiten oder das Recovery-Risiko hoch ist.

Ein erweiterter Pfad kann enthalten:

Phase A — bauen und testen

Phase B — fördern

Automatisierung sollte wiederholbares Risiko reduzieren. Sie darf Verantwortung nicht verbergen.

Eine grüne Pipeline beweist nicht, dass der geänderte KPI fachlich korrekt ist. Technische Validierung und fachliche Abnahme bleiben unterschiedliche Kontrollen.

Rollback und Roll-forward

Daten-Releases lassen sich schwerer zurücksetzen als Anwendungs-Releases, weil Daten möglicherweise bereits transformiert, veröffentlicht und konsumiert wurden.

Eine Release-Strategie sollte unterscheiden:

Das sicherste Design trennt Build-Status und Veröffentlichungsstatus. Ein abgeschlossener Ladevorgang ist nicht automatisch ein veröffentlichtes Datenprodukt.

Wer verantwortet was?

Governance scheitert, wenn Verantwortung als allgemeine Gruppe statt als konkretes Entscheidungsrecht formuliert wird.

Das Schaubild ist ein Referenzmuster und kein universelles Organigramm.

Ein praktikables Verantwortungsmodell ist:

In einem kleinen Team können mehrere Rollen von derselben Person ausgefüllt werden. Die Entscheidungen entfallen dadurch nicht.

Eine Person kann für ein Produkt Data Architect, Data Engineer und Data Ops sein. Der Sales Director kann Data Owner sein und ein Finance Analyst als Steward agieren. Das Modell bleibt gültig, wenn die Verantwortlichkeiten explizit sind.

Verantwortung ist nicht Aufgabenausführung

Der Data Owner muss keinen SQL-Test schreiben. Der Data Engineer wird nicht zum Owner der fachlichen Definition, nur weil er sie implementiert hat.

Eine hilfreiche Unterscheidung lautet:

Accountable
Verantwortet das Ergebnis und akzeptiert die Entscheidung

Responsible
Führt die Arbeit aus

Consulted
Liefert erforderliche Expertise oder Freigabeinput

Informed
Muss das Ergebnis oder die Änderungsinformation erhalten

Für ein konkretes Ergebnis sollte möglichst nur eine Rolle accountable sein.

„Data Team“ oder „Business“ ist meist zu unpräzise, um betrieblich nützlich zu sein.

Verantwortung muss Abwesenheit und Eskalation einschließen

Ein Betriebsmodell definiert außerdem:

• eine Vertretung oder Supportgruppe;
• den Eskalationspfad;
• die erwartete Reaktionszeit;
• den Entscheider während eines Incidents;
• wer eine Veröffentlichung stoppen darf;
• wer einen Emergency Fix freigeben darf;
• wer Nutzer informiert;
• wer das Issue nach der Validierung schließt.

Verantwortung, die nur während normaler Bürozeiten existiert, reicht für ein Produkt mit strengeren Verfügbarkeitsanforderungen nicht aus.

Qualität, Lineage und Observability

Nur zu überwachen, ob ein Job SUCCESS zurückgibt, erzeugt falsche Sicherheit.

Eine Pipeline kann erfolgreich sein, obwohl sie null Zeilen lädt, die Daten von gestern dupliziert, ein veraltetes Mapping anwendet, eine Quellpartition übersieht oder einen ungültigen KPI veröffentlicht.

Technisches Monitoring

Technische Signale umfassen:

• Pipeline- und Jobstatus;
• Ausführungsdauer;
• Retries und fehlgeschlagene Tasks;
• Quellenkonnektivität;
• Zeilen- und Dateianzahlen;
• Schemaänderungen;
• Datenaktualität;
• Datenvolumen;
• Abfrageperformance;
• Speicherwachstum;
• Compute- oder Capacity-Auslastung;
• Kosten und Ressourcenverbrauch;
• Authentifizierungs- und Autorisierungsfehler.

Diese Signale beantworten, ob das System wie vorgesehen arbeitet.

Fachliches Monitoring und Datenqualität

Fachliche Signale umfassen:

• Vollständigkeit von Pflichtschlüsseln;
• Eindeutigkeit auf der definierten Granularität;
• gültige Referenz- und Dimensionszuordnungen;
• zulässige Wertebereiche;
• Abstimmung mit Quell-Kontrollsummen;
• KPI-Bewegungen außerhalb erwarteter Bereiche;
• fehlerhafte Datensätze nach Regel und Schweregrad;
• Quality Score nach Datenprodukt;
• Verantwortung und Behebungsstatus der Regeln;
• SLA-Erfüllung;
• Veröffentlichungsstatus.

Ein Quality Score kann für Priorisierung nützlich sein, darf die zugrunde liegenden Regeln aber nicht verbergen. Ein Score von 98 Prozent ist bedeutungslos, wenn die fehlgeschlagenen zwei Prozent alle umsatzstarken Kunden oder den vollständigen aktuellen Geschäftstag enthalten.

Lineage

Lineage sollte mindestens folgenden Pfad sichtbar machen:

Quelle
Ingestion
Raw- oder Staging-Objekt
Transformation
Core-Tabelle
Datenprodukt
Semantik- oder Consumer-Modell
Bericht, Anwendung oder Extrakt

Eine minimale Umsetzung kann versionierte Abhängigkeitsdokumentation und generierte Metadaten aus SQL, Skripten oder Pipeline-Definitionen verwenden.

Eine größere Umsetzung kann Tabellen- und Spalten-Lineage automatisiert erfassen, mit einem Katalog kombinieren und für Impact-Analysen nutzen.

Das Ziel ist nicht der komplexeste Graph. Das Ziel ist, folgende Fragen zu beantworten:

Was hat diesen Wert erzeugt?
Welche Quelle und Regel haben dazu beigetragen?
Welche Produkte hängen von diesem Objekt ab?
Welche Consumer werden von einer Änderung betroffen?
Wer verantwortet jede Abhängigkeit?

Observability ohne Aktion ist nur Reporting

Jedes kritische Signal benötigt:

• einen erwarteten Bereich oder ein Serviceziel;
• einen verantwortliche Person;
• einen Schweregrad;
• einen Alert-Pfad;
• ein Runbook;
• eine Reaktionserwartung;
• einen Lösungsnachweis;
• eine Überprüfung wiederkehrender Ursachen.

Ein Dashboard, das drei Wochen rot bleibt, ist kein Betriebsprozess.

Incident Handling

Eine praktikable Incident-Sequenz lautet:

Phase A — eingrenzen

Phase B — wiederherstellen und lernen

Das Team sollte unterscheiden zwischen:

• Plattform-Incident;
• Quellsystem-Incident;
• Datenqualitäts-Incident;
• Semantik- oder Reportingfehler;
• Security Incident;
• erwarteter fachlicher Anomalie.

Reaktion und Owner sind nicht immer identisch.

Konkretes Beispiel: das Sales Data Product betreiben

Angenommen, das governte Produkt bleibt Sales by Customer, das in dieser Serie durchgehend verwendet wurde.

Sein Betriebsvertrag kann so aussehen:

Täglicher Veröffentlichungsablauf

Der Veröffentlichungsschritt sollte Folgendes protokollieren:

product_name
product_version
release_id
business_date
build_started_at
build_completed_at
published_at
source_control_total
product_control_total
critical_rule_status
warning_count
record_count
publication_status
approved_by

Das kann als Control-Tabelle, Katalogeintrag, Release-Datensatz oder gleichwertige Plattformmetadaten umgesetzt werden.

Was passiert, wenn das Produkt fehlschlägt?

Fehlender Wechselkurs

Fehlt für fünf Sales-Positionen der erforderliche EUR-Wechselkurs, darf das Team nicht stillschweigend null veröffentlichen oder einen beliebigen früheren Wert wiederverwenden.

Mögliche Richtlinie:

Kritische Regel schlägt fehl
Betroffene Datensätze werden persistiert
Produktveröffentlichung wird blockiert
Data Steward validiert das Referenzdatenproblem
Finance oder der Referenzdaten-Owner liefert den freigegebenen Kurs
Betroffene Partition wird neu aufgebaut
Abstimmung und Quality Gates laufen erneut
Produkt wird mit dokumentierter Verspätung veröffentlicht
Consumer erhalten einen SLA-Hinweis

Optionales Kundensegment fehlt

Ist das Segment nur beschreibend und für den zentralen Sales-KPI nicht erforderlich, kann das Produkt mit Warnung veröffentlicht werden:

Produkt wird pünktlich veröffentlicht
Betroffene Datensätze erhalten einen expliziten Qualitätsstatus
Steward verantwortet die Behebung
Consumer-Dokumentation zeigt die Einschränkung
Trend und offenes Issue bleiben sichtbar

Der Schweregrad richtet sich nach der fachlichen Auswirkung und nicht nur nach technischer Bequemlichkeit.

Pipeline schlägt nach einer gültigen vorherigen Veröffentlichung fehl

Bleibt die letzte erfolgreiche Version für das vorherige Business-Datum gültig, können Consumer sie mit einer Freshness-Warnung weiterverwenden. Sie durch eine unvollständige aktuelle Version zu ersetzen, würde das Vertrauen verringern.

Der Produktvertrag entscheidet, ob veraltet-aber-gültig besser ist als aktuell-aber-unvollständig.

Einen KPI versionieren, ohne jeden Consumer zu brechen

Angenommen, die vorhandene Definition lautet:

Nettoumsatz v1
Bruttobetrag
abzüglich freigegebenem Positionsrabatt
ohne stornierte Positionen
Umrechnung nach EUR anhand des Business-Datums

Finance genehmigt anschließend eine neue Definition:

Nettoumsatz v2
Nettoumsatz v1
abzüglich zugeordneter nachträglicher Rückvergütung

Die bestehende Spalte über Nacht zu ändern, würde jeden historischen Vergleich unbemerkt verändern.

Eine kontrollierte Änderung kann Folgendes verwenden:

sales_net_revenue_v1
sales_net_revenue_v2
net_revenue_definition_version
valid_from
valid_to
release_id

Der Übergang kann so erfolgen:

1. v2 definieren und freigeben;
2. v2 parallel zu v1 aufbauen;
3. beide Versionen abstimmen und die erwartete Differenz dokumentieren;
4. v2 an Test-Consumer veröffentlichen;
5. Abhängigkeiten in Qlik, Power BI und Excel aktualisieren;
6. beide Versionen für einen vereinbarten Zeitraum parallel betreiben;
7. Deprecation-Datum für v1 kommunizieren;
8. unterstützte Standardverträge auf v2 umstellen;
9. prüfen, dass kein aktiver Consumer noch v1 verwendet;
10. Definition archivieren und alte Schnittstelle stilllegen.

Auswirkungen auf Qlik, Power BI und Excel

Die gemeinsame fachliche Definition darf nicht in jedem Consumer unabhängig neu implementiert werden.

Consumer-Modelle übersetzen das governte Produkt in tool-spezifisches Verhalten. Sie verantworten nicht die autoritative Zuordnung der Rückvergütung.

Eine View oder ein QVD abkündigen

Eine View oder ein QVD sollte nicht unbegrenzt in Produktion bleiben, nur weil seine Entfernung riskant ist.

Ein kontrollierter Stilllegungsprozess lautet:

Phase A — entscheiden und ankündigen

Phase B — migrieren und Abwesenheit nachweisen

Bei einem QVD müssen außerdem geprüft werden:

• Generator-Anwendungen;
• Reload-Ketten;
• Binary- oder Dateiabhängigkeiten;
• nachgelagerte Qlik-Anwendungen;
• extern bereitgestellte Kopien;
• Namenskonventionen, die die tatsächliche Nutzung verbergen;
• Aufbewahrungs- und Backupkopien.

Nur die sichtbare Datei zu löschen, während ein Generator sie erneut erstellt, ist keine Stilllegung.

Der Lebenszyklus des Datenprodukts

Ein Datenprodukt sollte einen definierten Weg von der Idee bis zur Stilllegung besitzen.

Idee und Discovery

Zu klären sind:

• fachliche Entscheidung;
• erwarteter Nutzen;
• Nutzer;
• Datenquellen;
• Granularität;
• Verantwortung;
• Aktualität;
• Qualität;
• Sicherheit;
• Aufbewahrung;
• erwarteter Lebenszyklus.

Eine Idee ohne plausiblen Owner oder Consumer ist nicht bereit für Plattforminvestition.

Design

Zu definieren sind:

• logisches Modell;
• Schlüssel und Historie;
• Produktvertrag;
• Zugriffsmodell;
• Teststrategie;
• Umgebungspfad;
• Release-Methode;
• Monitoring;
• Recovery;
• Kostenerwartung;
• Stilllegungskriterien.

Build und Test

Der einfachste vollständige vertikale Slice umfasst:

• Ingestion;
• Transformation;
• Produktmodell;
• Qualitätsnachweise;
• Metadaten;
• Nutzer-Vertrag;
• Deployment;
• Monitoring.

Release

Ein Release benötigt:

• freigegebene Version;
• bestandene Gates;
• vorbereiteten Zugriff;
• Dokumentation;
• Release Notes;
• Nutzer-Kommunikation;
• Recovery-Plan;
• Veröffentlichungsnachweis.

Betrieb

Zu überwachen sind:

• SLA und Aktualität;
• Fehler;
• Qualität;
• Nutzung;
• Performance;
• Sicherheit;
• Capacity und Kosten;
• Incidents;
• ungelöste Risiken.

Änderung

Änderungen können sein:

Kompatible Erweiterung
Technische Optimierung
Quellenmigration
Änderung einer Qualitätsregel
Sicherheitsänderung
Semantische Änderung
Breaking Contract Change
Consumer-spezifische Änderung

Der Änderungstyp bestimmt Test-, Freigabe- und Versionierungspfad.

Deprecation und Stilllegung

Ein Produkt wird zum Stilllegungskandidaten, wenn:

• kein aktiver Nutzer verbleibt;
• ein Ersatz vollständig übernommen wurde;
• sein fachlicher Zweck entfallen ist;
• Quelle oder Vertrag nicht mehr existieren;
• Kosten im Verhältnis zum Nutzen zu hoch sind;
• Risiko oder Compliance die Entfernung verlangen;
• Verantwortung nicht nachhaltig sichergestellt werden kann.

Stilllegung ist ein geplanter Lebenszyklusstatus und keine ungeplante Löschung.

Den Produktvertrag versionieren

Ein einfaches Versionsmodell kann unterscheiden:

Die genaue Nummerierungskonvention ist weniger wichtig als konsistentes Verhalten.

Eine Version muss Folgendes identifizieren:

Fachliche Definition
Schema oder Schnittstelle
Qualitätsrichtlinie
Release-Artefakt
Gültigkeitsdatum
Consumer-Supportstatus
Deprecation-Status

Ein Git-Tag allein sagt einem fachlichen Consumer nicht, welche KPI-Definition gültig war. Eine Katalogbeschreibung allein reproduziert die ausgerollte Implementierung nicht. Beide Perspektiven werden benötigt. Ein Monitoring-Dashboard zeigt Signale; es ist weder der Katalog noch der Verantwortung-Vertrag.

Technologieoffene Umsetzungsoptionen

Dieselben Betriebsprinzipien können mit unterschiedlichen technischen Mitteln umgesetzt werden.

Keine Zeile dieser Tabelle ist ein Pflicht-Stack.

Ein kleines Team kann SQL-Jobs, Git, Testabfragen, eine Veröffentlichungstabelle und ein Betriebsdashboard kombinieren. Eine große Organisation kann zentrales CI/CD, Katalog, Lineage, Alert-Routing, Kostenkontrollen und Incident-Automatisierung benötigen.

Das Betriebsmodell sollte wachsen, weil Risiko und Skalierung es erfordern und nicht, weil jede Plattformfunktion existiert.

Minimum-Betrieb und erweiterter Betrieb

Betriebliche Reife sollte schrittweise wachsen.

Minimal tragfähiger Betrieb

Ein kleines Team sollte mindestens besitzen:

Benannter Owner und Vertretung
Getrennte Entwicklung und Produktion
Versionierte Transformationen
Dokumentierte Release-Checkliste
Kritische Datenqualitäts-Gates
Persistente Lade- und Veröffentlichungsnachweise
Freshness- und Fehler-Alerts
Consumer-Inventar
Incident-Kontakt und Runbook
Backup- oder Rekonstruktionspfad
Zugriffsreview
Deprecation- und Stilllegungsprozess

Das ist ohne dediziertes Observability-Produkt oder unternehmensweite CI/CD-Plattform möglich.

Erweiterter Betrieb

Erweiterte Fähigkeiten können umfassen:

• automatisierte Bereitstellung von Umgebungen;
• Pull-Request-Validierung;
• temporäre Testumgebungen;
• automatisierte Data-Vereinbarung-Prüfungen;
• Spalten-Lineage;
• Anomalieerkennung;
• zentrales Alert-Routing;
• Service-Level-Objective-Reporting;
• automatisierter Rückbau oder Self-Healing;
• Richtlinie-as-Code;
• kontinuierliche Zugriffsprüfung;
• Capacity Forecasting;
• Chargeback oder Showback;
• automatisierte Stilllegungskandidaten anhand der Nutzung;
• plattformübergreifende Incident-Korrelation.

Jede Fähigkeit bringt eigene Kosten, Konfiguration und Supportanforderungen mit.

Wann schafft mehr Automatisierung Mehrwert?

Das Ziel ist nicht maximale Reife in jeder Kategorie. Das Ziel ist ausreichende Kontrolle für das tatsächliche Risiko.

Typische Anti-Patterns

Eine Umgebung für alles

Entwickler testen direkt auf Produktionsobjekten und deployen durch Überschreiben. Das Team kann den vorherigen Zustand nicht reproduzieren und nicht bestimmen, welche Änderung den Fehler verursacht hat.

Jobstatus als einziges Qualitätssignal

Die Pipeline ist erfolgreich, aber das aktuelle Business-Datum fehlt. Technischer Abschluss wird mit fachlicher Korrektheit des Produkts verwechselt.

Das Dashboard ist die Kontrolle

Ein rotes Dashboard weist keine Verantwortung zu, startet keine Aktion und erhält keinen Nachweis. Monitoring ist sichtbar, aber nichts ändert sich.

Neustarten, bis alles grün ist

Der fehlgeschlagene Job wird wiederholt gestartet, ohne zu verstehen, ob bereits Teildaten geschrieben wurden. Der abschließende grüne Status verbirgt doppelte oder inkonsistente Ergebnisse.

Verantwortung durch Komitee

„Business und IT verantworten es gemeinsam“ lässt niemanden autorisiert zurück, eine Qualitätsausnahme zu akzeptieren, ein Release zu verschieben oder eine Schnittstelle stillzulegen.

Validierung erst in Produktion

Das vollständige Datenvolumen, Berechtigungen und Abhängigkeiten werden erstmals nach dem Deployment geprüft. Test und Release werden zum selben Ereignis.

Statische Lineage ohne Betriebsnutzen

Während des Projekts wird ein Diagramm erstellt und anschließend nie aktualisiert. Bei Modelländerungen kann es keine Impact-Fragen beantworten.

Dauerhafter Parallelbetrieb

Alte und neue Views, QVDs, Modelle und Berichte laufen unbegrenzt parallel. Consumer wählen Versionen unabhängig und Abstimmung wird zur Daueraufgabe.

KPI-Änderung ohne Vertragsversion

Eine Spalte behält denselben Namen, obwohl sich ihre Bedeutung ändert. Historische Vergleiche und Consumer-Verhalten ändern sich unbemerkt.

Tool-spezifische Korrekturen werden gemeinsame Logik

Ein Fehler wird in einem Qlik-Skript, einem DAX-Measure oder einer Excel-Formel korrigiert, während andere Consumer inkonsistent bleiben.

Automatisierung vor dem Betriebsmodell

Das Team baut eine komplexe CI/CD-Strecke ohne definierte Owner, Quality Gates, Release-Entscheidungen oder Supportverantwortung. Der Prozess wird zu automatisierter Unklarheit.

Keine Stilllegung

Ungenutzte Pipelines, Tabellen, Views, QVDs, Semantikmodelle und Berichte verbrauchen weiterhin Geld, Zugriffsrechte und operative Aufmerksamkeit.

Entscheidungshilfe

Verwende folgende Fragen für jedes Datenprodukt.

Kann das Team diese Fragen nicht beantworten, löst ein weiteres Monitoring- oder Governance-Produkt die grundlegende Betriebslücke nicht.

Wichtigste Empfehlungen

1. Behandle jedes produktive Datenprodukt als betriebenen Service mit Owner, Consumern und Serviceerwartungen.
2. Trenne Entwicklung, Validierung und Produktion auch dann als Verantwortlichkeiten, wenn sie Infrastruktur teilen.
3. Versioniere Transformationscode, Produktverträge, Tests und Release-Nachweise gemeinsam.
4. Setze einen erfolgreichen Job nicht mit einem erfolgreich veröffentlichten Datenprodukt gleich.
5. Persistiere Qualitätsergebnisse, Abstimmungsnachweise und Veröffentlichungsstatus.
6. Definiere, welche Qualitätsregeln die Veröffentlichung blockieren und welche Warnungen erzeugen.
7. Gib jedem kritischen Ergebnis einen accountable Owner und einen definierten Eskalationspfad.
8. Überwache technischen Zustand, fachliche Qualität, Freshness, Nutzung und Kosten gemeinsam.
9. Richte Lineage auf Impact-Analyse und Nachvollziehbarkeit statt auf dekorative Diagramme aus.
10. Schütze die letzte gültige Veröffentlichung, wenn ein neuer Build fehlschlägt.
11. Nutze Rollback, wo er sicher ist, und Roll-forward, wo Datenrekonstruktion zuverlässiger ist.
12. Führe KPI- und Schemaänderungen über explizite Produktversionen ein.
13. Betreibe Breaking Versions nur für einen definierten Migrationszeitraum parallel.
14. Kommuniziere Release Notes, Incidents, Deprecations und Stilllegungsdaten an Consumer-Owner.
15. Halte gemeinsame Geschäftsregeln außerhalb einzelner Qlik-, Power-BI- und Excel-Artefakte.
16. Erlaube Consumer-spezifische Logik nur dort, wo sie tatsächlich zur Consumer Experience gehört.
17. Beginne mit Checklisten, Control-Tabellen, Tests und klarer Verantwortung, bevor erweiterte Betriebstechnologie beschafft wird.
18. Ergänze CI/CD, automatisierte Lineage und Observability, wenn Skalierung, Release-Frequenz oder Risiko sie rechtfertigen.
19. Prüfe Zugriffe, Kosten, Capacity, ungelöste Incidents und Nutzung regelmäßig.
20. Lege ungenutzte Pipelines, Views, QVDs, Modelle und Berichte bewusst still.
21. Teste Recovery und Continuity, statt anzunehmen, dass Backups oder Raw-Daten ausreichen.
22. Bewerte das Betriebsmodell neu, wenn das Produkt kritischer wird, weitere Consumer erhält oder sein Service Level verändert wird.

Abschluss der Serie

Diese Serie begann mit Bevor die erste Tabelle entsteht: Ausgangspunkt sind fachliche Entscheidung, KPI, Granularität, Quellen, Qualität und Verantwortung.

Anschließend wurden Verantwortlichkeiten präziser als Bronze, Silver und Gold getrennt, die einfachste tragfähige Architektur ausgewählt, Greenfield- und Brownfield-Umsetzungen behandelt, gemeinsame Geschäftslogik aus BI-Anwendungen herausgeführt, ein governtes Produkt für mehrere Consumer definiert, Transformationsoptionen verglichen und eine Architektur auf mehrere Plattformen abgebildet.

Der letzte Schritt ist der kontinuierliche Betrieb:

Ein modernes Warehouse wird nicht durch die Anzahl der Tools im Stack definiert.

Es wird dadurch definiert, ob die Organisation die Datenprodukte, von denen Entscheidungen abhängen, erklären, reproduzieren, vertrauen, verändern und schließlich stilllegen kann.

Ein Stakeholder-Interview liefert Evidenz, Begriffe, Erwartungen und offene Fragen. Es liefert kein Tabellenmodell. Die Modellierungsarbeit beginnt erst, wenn diese Aussagen in explizite und überprüfbare Entscheidungen zu Geschäftsprozess, Business Event, Grain, Kennzahlen, Dimensionen, Historie, Verantwortung und Scope übersetzt werden.

Herausforderung

Stakeholder formulieren Anforderungen selten in Modellierungsbegriffen. Sie verlangen „Umsatz nach Kunde“, „die aktuelle Pipeline“, „alle Aktivitäten“, „eine Zeile pro Kunde“ oder „dieselben Zahlen wie im Management-Report“. Jede Aussage kann wertvolle Evidenz enthalten, ist aber noch nicht präzise genug, um eine Faktentabelle zu definieren.

Dasselbe Substantiv kann unterschiedliche Analyseobjekte bezeichnen. „Kunde“ kann das vertragliche Konto, den Rechnungsempfänger, eine juristische Einheit, einen Interessenten oder eine Konzernmutter meinen. „Umsatz“ kann gebuchten, fakturierten, realisierten, erwarteten oder wahrscheinlichkeitsgewichteten Umsatz bezeichnen. „Aktuell“ kann den neuesten Quellzustand, den Zustand zum Ausführungszeitpunkt eines Reports oder den Zustand an einem ausgewählten historischen Datum meinen.

Ein Report-Inventar zeigt häufig, dass diese Mehrdeutigkeiten bereits produktiv existieren. Zwei Reports verwenden dieselbe Bezeichnung, aber unterschiedliche Filter. Mehrere Reports berechnen denselben KPI verschieden. Ein Report mischt Transaktionsdaten mit dem neuesten Status, während ein anderer historische Snapshots rekonstruiert. Wer diese Strukturen in einen neuen Mart kopiert, übernimmt den Konflikt, statt ihn zu entscheiden.

Typische Fehlmuster sind vorhersehbar:

• Begriffe aus Interviews werden direkt in Tabellen- und Spaltennamen kopiert.
• Dimensionen werden ausgewählt, bevor der fachliche Ebene feststeht.
• Mehrere Geschäftsprozesse werden in einer Faktentabelle vermischt.
• „Eine Zeile pro Kunde“ wird ohne Zeitsemantik akzeptiert.
• Schwierige Anforderungen verschwinden ohne dokumentierte Entscheidung.
• Das Layout eines bestehenden Reports wird als Zielmodell behandelt.
• KPI-Formeln werden implementiert, bevor Verantwortung und Freigabe geklärt sind.

Das Ergebnis kann technisch vollständig wirken und gleichzeitig semantisch instabil bleiben. Kennzahlen werden mehrdeutig, Historie lässt sich nicht erklären und spätere Änderungen öffnen Entscheidungen erneut, die nie dokumentiert wurden.

Ansatz

Behandle jede Interview-Aussage als Evidenz, die eine kontrollierte Entscheidungskette durchlaufen muss:

Stakeholder-Aussage
→ Klärung
→ Modellierungsentscheidung
→ dokumentierte Evidenz und Freigabe

Die Kernregel ist einfach: Identifiziere zuerst das Business Event und formuliere einen präzisen Grain-Satz, bevor Fakten oder Dimensionen ausgewählt werden.

Ein brauchbarer Grain-Satz nennt das Ereignis, das beteiligte Objekt und die Zeitsemantik. Zum Beispiel:

Eine Zeile pro Opportunity-Position und Snapshot-Datum.

Diese Aussage unterscheidet sich wesentlich von „eine Zeile pro Opportunity“ oder „eine Zeile pro Kunde“. Sie definiert einen periodischen Snapshot auf Positionsebene. Damit bestimmt sie, welche Kennzahlen gemeinsam vorkommen dürfen, welche Dimensionen gültig sind und wie historische Analysen funktionieren.

Aus diesem Grain lassen sich Kandidaten gezielt bewerten:

• Additive Fakten: Menge oder erwarteter Umsatz, sofern die Summierung über die vorgesehenen Dimensionen gültig ist.
• Semi-additive Fakten: Bestände oder Pipeline-Werte, die über einige Dimensionen, aber nicht über die Zeit summiert werden dürfen.
• Statusattribute: Phase, Freigabestatus oder Risikokategorie, wenn sie den Zustand der Zeile statt einer Ereignismenge beschreiben.
• Dimensionen: Account, Opportunity, Produkt, verantwortliche Person, Phase und Datum, wenn sie wiederverwendbaren analytischen Kontext liefern.
• Degenerate Dimensions: Geschäftskennungen wie eine Opportunity-Nummer, die zum Faktenereignis gehören, aber keine eigene beschreibende Dimension benötigen.
• Filter und Regeln: Einschlusskriterien, Statusrestriktionen, Währungsregeln und Zeitfenster-Semantik.
• Explizite Ausschlüsse: Aktivitäten, Freitextnotizen, nicht zugehörige Servicefälle oder andere Daten, die die freigegebene Entscheidung nicht unterstützen.

Transaktions-Grain und Snapshot-Grain dürfen nicht allein deshalb in einer Faktentabelle vermischt werden, weil beide dasselbe Geschäftsobjekt betreffen. Eine Transaktion dokumentiert, dass etwas geschehen ist. Ein Snapshot dokumentiert einen Zustand zu einem definierten Zeitpunkt. Die Vermischung erzeugt Kennzahlen, die nicht mehr konsistent interpretierbar sind.

Evidenz, Interpretation und Entscheidung trennen

Für jede relevante Interview-Aussage werden drei Ebenen getrennt dokumentiert:

1. EvidenIn einem Satz:** Was hat der Stakeholder gesagt, welcher Report wurde gezeigt, welche KPI Card existiert und welches Quellverhalten wurde beobachtet?
2. Interpretation: Was glaubt das Team, dass die Aussage bedeutet, und welche Mehrdeutigkeit besteht weiterhin?
3. Entscheidung: Welcher Geschäftsprozess, welches Business Event, welcher Grain, welche Kennzahl, Dimension, Historienbehandlung oder Scope-Out wurde freigegeben?

Diese Trennung verhindert, dass eine Interpretation als Stakeholder-Fakt dargestellt wird. Sie ermöglicht außerdem eine spätere Überprüfung, wenn ein Report, Owner oder Quellsystem der ursprünglichen Annahme widerspricht.

KPI-Semantik mit dem Ziel-Grain verbinden

Eine KPI Card muss mehr als eine Formel definieren. Sie sollte klären:

• fachliche Bedeutung und unterstützte Entscheidung
• Zähler, Nenner und Aggregationsverhalten
• Filter und Ausschlüsse
• Gültigkeitsdatum und Zeitsemantik
• Währung, Einheit und Umrechnungsregeln
• Ziel-Körnung und erlaubte Drill-Pfade
• Calculation Owner und freigebender Data Owner
• Qualitätserwartungen und bekannte Einschränkungen

Ein KPI kann nur sicher implementiert werden, wenn seine Berechnung mit dem Mart-Grain kompatibel ist. Eine monatliche Conversion Rate, ein Snapshot auf Positionsebene und ein transaktionales Ereignis können getrennte Strukturen benötigen, obwohl sie auf demselben Dashboard erscheinen.

Rollen als Entscheidungsgrenzen nutzen

Stakeholder Matrix und RACI ersetzen die Modellierung nicht. Sie legen fest, wer Evidenz liefern, Terminologie definieren, fachliche Entscheidungen treffen, das Modell entwerfen und das Ergebnis freigeben darf.

• Der Data Owner genehmigt fachliche Bedeutung, erlaubte Nutzung, wesentlichen Umfang und die Akzeptanz verbleibender Risiken.
• Der Data Steward pflegt Terminologie, Definitionen, Klassifikationen und semantische Konsistenz.
• Der Data Architect übersetzt freigegebene Semantik in Entscheidungen zu fachlicher Ebene, Fakten, Dimensionen, Historie und Vereinbarungen.
• Quell- und Plattformverantwortliche bestätigen technische Evidenz, Machbarkeit und operative Einschränkungen.
• Nutzer validieren, dass der resultierende Auswertungstabelle die beabsichtigte Entscheidung unterstützt, ohne jede report-spezifische Präferenz zu übernehmen.

Die detaillierten Rollenmechaniken bleiben in den verlinkten RACI- und Rollen-Playbooks. Diese Story nutzt sie, um die Modellentscheidung überprüfbar zu machen.

Checkliste

Nutze diese Checkliste vor der Freigabe eines Mart-Designs:

Evidenz

• Interview-Aussagen sind getrennt von Interpretationen gespeichert.
• Das Report-Inventar identifiziert doppelte, widersprüchliche und report-spezifische Anforderungen.
• Vorhandene KPI Cards und Definitionen sind verlinkt.
• Quell-Evidenz ist benannt und nachvollziehbar.
• Offene Fragen besitzen einen Owner und ein erforderliches Entscheidungsdatum oder einen Trigger.

Business Event und Grain

• Ein Geschäftsprozess ist benannt.
• Das Business Event ist explizit.
• Der fachliche Ebene ist als ein präziser Satz formuliert.
• Die Zeitsemantik ist explizit: Transaktionszeit, Gültigkeitszeit, Snapshot-Datum oder aktueller Zustand.
• Der fachliche Ebene ist mit den vorgesehenen KPI-Berechnungen kompatibel.
• Transaktions- und Snapshot-Prozesse werden nicht stillschweigend vermischt.

Fakten und Dimensionen

• Jedes Fakt besitzt eine definierte Bedeutung, Einheit und ein Aggregationsverhalten.
• Statusattribute werden nicht fälschlich als additive Kennzahlen behandelt.
• Dimensionen beschreiben den deklarierten fachliche Ebene.
• Conformed Dimensions und Schlüssel sind identifiziert, wenn Auswertungstabelle-übergreifende Wiederverwendung erforderlich ist.
• Degenerate Dimensions werden bewusst für Geschäftskennungen verwendet.
• Das Historienverhalten für Fakten und Dimensionen ist spezifiziert.

Governance und Scope

• Data Owner, Steward, Architect und Freigebende sind benannt.
• personenbezogene Daten-, Zugriffs- und Permitted-Use-Anforderungen sind dokumentiert.
• Qualitätsprüfungen sind mit fachlichen Akzeptanzkriterien verbunden.
• Annahmen sind sichtbar.
• Zurückgestellte und ausgeschlossene Anforderungen enthalten Begründung, Evidenz, Owner und Review-Trigger.
• Keine schwierige Anforderung wurde stillschweigend entfernt.

Artefakt

Das primäre Ergebnis ist ein Mart Design Brief (mart-design-brief.md). Er bildet den überprüfbaren Contract zwischen Interview-Evidenz und physischer Tabellenerstellung. KPI-Karten exportierst du als kpi-cards.csv; den freigegebenen Scope als source-scope.csv.

Ein brauchbarer Mart Design Brief enthält:

mart:
  name: sales_pipeline_snapshot
  purpose: Entscheidungen zu Pipeline-Wert, Coverage und Phasenbewegung unterstützen
  consumers:
    - sales-management
    - account-management

business_process:
  name: opportunity-pipeline-monitoring
  event: opportunity-line-state-at-snapshot
  grain: Eine Zeile pro Opportunity-Position und Snapshot-Datum

facts:
  - name: quantity
    aggregation: additive
    owner: sales-operations
  - name: expected_revenue
    aggregation: additive-within-currency
    owner: finance-and-sales-operations
  - name: probability_weighted_revenue
    aggregation: derived
    calculation_owner: sales-operations

dimensions:
  - account
  - opportunity
  - product
  - owner
  - stage
  - snapshot_date

history:
  pattern: periodic-snapshot
  cadence: daily
  late_arriving_policy: documented-before-build

quality:
  - opportunity_line_identifier_is_present
  - snapshot_date_is_present
  - probability_is_within_valid_range
  - expected_revenue_currency_is_known

security:
  pii: assessed
  access: role-and-region-policy

scope:
  included:
    - opportunity-line-state
    - approved-pipeline-measures
  deferred:
    - activity-engagement-score
  excluded:
    - free-text-notes
    - unrelated-service-cases

assumptions:
  - source-stage-values-use-approved-mapping

approvals:
  data_owner: named-person-or-role
  steward: named-person-or-role
  architect: named-person-or-role

Die konkrete Form kann abweichen, der Brief muss jedoch dieselben Entscheidungsfragen beantworten. Er sollte freigegeben sein, bevor physische Tabellen, Orchestrierung oder Report-Migration beginnen.

Scope-Out als Governance-Entscheidung dokumentieren

Scope-Out ist kein Backlog-Friedhof. Jede angefragte Position gehört in eine von drei Spuren:

• Jetzt bauen: für die erste freigegebene Entscheidung erforderlich, mit dem fachliche Ebene kompatibel, durch bekannte Quelle und verantwortliche Person unterstützt und anhand von Akzeptanzkriterien testbar.
• Zurückstellen: valider Bedarf, dem Quelle, verantwortliche Person, Definition oder unmittelbare Priorität fehlen, mit benanntem Trigger für die erneute Bewertung.
• Ausschließen: nicht unterstützt, doppelt, von geringem Wert, fachliche Ebene-inkompatibel oder im Verhältnis zu personenbezogene Daten, Risiko oder Kosten nicht gerechtfertigt.

Für jede zurückgestellte oder ausgeschlossene Position werden Begründung, Decision Owner, Evidenz, Review-Trigger und betroffene Consumer dokumentiert.

Tools

Nutze die vorhandenen Tools, um Evidenz zu sammeln und zu strukturieren:

• Stakeholder Matrix — identifiziert Evidenzgeber, Decision verantwortliche Person, Reviewer und betroffene Nutzer.
• Report Inventory — vergleicht bestehende Reports, Formeln, Filter, Grains und Widersprüche.
• KPI Requirements Anfrageweg — erfasst KPI-Bedeutung, Filter, Zeitsemantik, Verantwortung und Freigabe.
• Auswertungstabelle Design Brief Generator — überführt freigegebene Entscheidungen in einen überprüfbaren Auswertungstabelle Vereinbarung.

Diese Tools unterstützen den Entscheidungsprozess. Sie ersetzen weder die Freigabe durch den Owner noch das Architektururteil.

Ressourcen

Halte folgende Evidenz am Mart Design Brief verfügbar:

• Interview-Notizen mit Quelle, Datum und Teilnehmerrolle
• verlinkte Report-Beispiele und Screenshots
• Einträge aus dem Report-Inventar mit markierten Berechnungskonflikten
• freigegebene KPI Cards
• Beispiele für Quellfelder und relevante Werteverteilungen
• Terminologieentscheidungen und offene Synonyme
• Annahmen, offene Fragen und Umfang-Out-Register
• Freigabenachweis und Entscheidungshistorie

Ein Model Review sollte jedes wesentliche Feld und jede Berechnung auf Evidenz und eine explizite Entscheidung zurückführen können.

Weiterlesen

• Lade-Entscheidungen
• Unbekannte Quelle — wer hilft, personenbezogene Daten, Qualität