SH

Sascha Hess

xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

Strategische Wissens-Roadmap 2026

BI & Governance

Datenintegration

Entscheidungshilfe für mittelständische Datenarchitekturen

1

ETL vs. ELT Entscheidungsmatrix

Klare Kriterien - welches Muster wann und warum einsetzen

2

10 Architektur-Fallen

Die häufigsten Fehler bei der Wahl des falschen Musters

3

Praxisbeispiele mit SQL & dbt

Fertige Templates für SQL Server, Azure Synapse & Fabric

4

Governance-Framework

Datenlineage, Qualitätssicherung und Auditing für beide Muster

5

30-Tage-Migrationsplan

Schrittweise vom Legacy-ETL zur modernen ELT-Architektur

WAS SIE IN DIESEM KIT ERWARTEN DÜRFEN

■  Entscheidungsmatrix — 12 gewichtete Kriterien, die in 30 Minuten Klarheit schaffen.

■  10 Architektur-Fallen — Die häufigsten Fehler bei der Musterwahl, mit Gegenmaßnahmen.

■  Praxisbeispiele — Fertige SQL-, SSIS- und dbt-Templates für beide Muster.

■  Governance-Framework — Lineage, Qualitätsprüfung und Auditing für produktionstaugliche Pipelines.

■  30-Tage-Plan — Strukturierte Migration vom Legacy-ETL zur modernen Architektur.

ZIEL DIESES KITS

Nach dem Durcharbeiten dieses Kits treffen Sie begründete Architekturentscheidungen statt Modeentscheidungen — und haben die wichtigsten Muster sofort einsatzbereit als Template in Ihrer Umgebung.

-- Klassisches ETL-Muster: Transformation im Staging-Bereich vor dem Load

-- Schritt 1: Extract in Staging

INSERT INTO Staging.Auftraege_Raw

SELECT * FROM [ERP-Server].dbo.SalesOrders

WHERE ModifiedDate >= @LastExtractDate;

-- Schritt 2: Transform im ETL-Prozess (außerhalb des Ziel-DWH)

INSERT INTO DWH.Fact_Auftraege

SELECT

    s.OrderID,

    dk.KundenKey,

    dd.DatumKey,

    s.Nettobetrag * w.WechselkursEUR AS Betrag_EUR,

    CASE WHEN s.Nettobetrag > 10000 THEN 'GROSS'

         WHEN s.Nettobetrag > 1000  THEN 'MITTEL'

         ELSE 'KLEIN' END AS Groessenklasse

FROM Staging.Auftraege_Raw s

JOIN DWH.Dim_Kunden dk ON s.KundenNr = dk.KundenNr_Src

JOIN DWH.Dim_Datum dd ON CAST(s.OrderDate AS DATE) = dd.Datum

JOIN Staging.Wechselkurse w ON s.Waehrung = w.Waehrung

    AND CAST(s.OrderDate AS DATE) = w.GueltigAm

WHERE s.Status NOT IN ('STORNO', 'ENTWURF');

-- Schritt 3: Staging bereinigen

TRUNCATE TABLE Staging.Auftraege_Raw;

-- ELT-Muster: Rohdaten landen zuerst, Transformation danach im Warehouse

-- Raw-Schicht enthält unveränderte Quelldaten

-- (Beispiel als dbt-Modell in SQL)

-- models/staging/stg_auftraege.sql

SELECT

    OrderID,

    KundenNr,

    CAST(OrderDate AS DATE)         AS order_date,

    Nettobetrag,

    Waehrung,

    Status,

    _loaded_at                      -- Ladezeit-Metadaten

FROM {{ source('erp_raw', 'SalesOrders') }}

WHERE Status NOT IN ('STORNO', 'ENTWURF')

-- models/marts/fact_auftraege.sql

SELECT

    s.OrderID,

    dk.kunden_key,

    dd.datum_key,

    s.Nettobetrag * w.kurs_eur      AS betrag_eur,

    CASE WHEN s.Nettobetrag > 10000 THEN 'GROSS'

         WHEN s.Nettobetrag > 1000  THEN 'MITTEL'

         ELSE 'KLEIN'               END AS groessenklasse

FROM {{ ref('stg_auftraege') }} s

LEFT JOIN {{ ref('dim_kunden') }} dk USING (KundenNr)

LEFT JOIN {{ ref('dim_datum') }} dd ON s.order_date = dd.datum

LEFT JOIN {{ ref('stg_wechselkurse') }} w

    ON s.Waehrung = w.waehrung AND s.order_date = w.gueltig_am

Wo wird transformiert?

ETL-Server / Middleware

Im Ziel-Warehouse selbst

Rohdaten im Warehouse?

Nein — nur Endergebnis

Ja — vollständig vorhanden

Skalierung

ETL-Server ist Flaschenhals

Warehouse skaliert mit

Kosten bei großen Volumen

Günstiger (weniger Storage)

Kann teuer werden (Compute)

Nachvollziehbarkeit

Begrenzt (Black Box)

Sehr gut (alle Schichten sichtbar)

Tooling

SSIS, Talend, Informatica

dbt, Spark SQL, Fabric Notebooks

Einstiegshürde

Hoch (grafische Tools)

Mittel (SQL + Git)

Re-Transformation möglich?

Aufwendig

Jederzeit ohne Reload

1

Quelldaten enthalten sensible/personenbezogene Daten, die vor dem Speichern anonymisiert werden müssen

3

0

2

Ziel-Warehouse hat begrenzte Compute-Kapazität oder hohe Kosten pro Query

3

0

3

Datenvolumen < 50 GB pro Tag

2

1

4

Team hat starke SSIS/SQL-Agent-Kompetenz, keine dbt-Erfahrung

3

0

5

Quelldaten sind stark unstrukturiert oder kommen aus Legacy-Systemen mit proprietären Formaten

2

1

6

Compliance erfordert, dass Rohdaten das Unternehmen nie verlassen dürfen

3

0

7

Datenvolumen > 1 TB pro Tag oder starkes Wachstum erwartet

0

3

8

Cloud-Warehouse (Synapse, Fabric, Snowflake) bereits vorhanden oder geplant

0

3

9

Transformationslogik ändert sich häufig — Re-Transformation ohne Reload gewünscht

0

3

10

Data Lineage und Dokumentation sind geschäftskritisch

1

3

11

Team will moderne Tools (dbt, Git, CI/CD) einsetzen

0

3

12

Bestehende ETL-Infrastruktur ist bereits amortisiert und stabil

3

0

AUSWERTUNG

■  ETL-Score > ELT-Score um mehr als 6 Punkte → ETL klar vorteilhaft.

■  ELT-Score > ETL-Score um mehr als 6 Punkte → ELT klar vorteilhaft.

■  Scores liegen nahe beieinander (< 6 Punkte Abstand) → Hybride Architektur prüfen (Kapitel 8).

■  Beide Scores unter 10 → Architekturanforderungen klären, bevor entschieden wird.

-- ELT direkt in SQL Server: Raw-Schicht via Linked Server oder BULK INSERT

CREATE SCHEMA raw;   -- Rohdaten-Schicht

CREATE SCHEMA stg;   -- Staging / Bereinigung

CREATE SCHEMA dwh;   -- Fertiges Data Warehouse

CREATE SCHEMA rpt;   -- Reporting Views für Power BI

-- Raw-Tabelle: unveränderte Quelldaten mit Ladezeit

CREATE TABLE raw.SalesOrders (

    _src_id        INT,

    _loaded_at     DATETIME2 DEFAULT SYSUTCDATETIME(),

    _src_system    NVARCHAR(50) DEFAULT 'ERP',

    OrderID        INT,

    KundenNr       NVARCHAR(20),

    OrderDate      NVARCHAR(30),  -- bewusst als String — keine Transformation hier

    Nettobetrag    NVARCHAR(30),  -- bewusst als String

    Waehrung       NVARCHAR(10),

    Status         NVARCHAR(20)

);

-- Lineage-Tabelle für ETL-Prozesse

CREATE TABLE dbo.ETL_Lineage (

    LineageID      INT IDENTITY PRIMARY KEY,

    ProzessName    NVARCHAR(200),

    QuelleServer   NVARCHAR(100),

    QuelleDatenbank NVARCHAR(100),

    QuelleObjekt   NVARCHAR(200),

    ZielObjekt     NVARCHAR(200),

    TransformRegel NVARCHAR(MAX),

    LetzteAenderung DATETIME2,

    Verantwortlich NVARCHAR(100)

);

-- Unveränderliche Raw-Schicht: nur INSERT, kein UPDATE/DELETE

-- Trigger verhindert ungewollte Änderungen

CREATE TRIGGER raw.TR_SalesOrders_NoUpdate

ON raw.SalesOrders

INSTEAD OF UPDATE, DELETE

AS

BEGIN

    RAISERROR('Raw-Schicht ist unveränderlich. Kein UPDATE oder DELETE erlaubt.', 16, 1);

    ROLLBACK;

END

-- Inkrementales Laden mit Wasserzeichen

DECLARE @LastLoadTime DATETIME2;

SELECT @LastLoadTime = MAX(ExtractDatum) FROM dbo.ETL_Protokoll

WHERE ProzessName = 'Auftraege_Load' AND Status = 'ERFOLG';

INSERT INTO raw.SalesOrders

SELECT *, SYSUTCDATETIME() AS _loaded_at

FROM [ERP].dbo.SalesOrders

WHERE ModifiedDate > ISNULL(@LastLoadTime, '1900-01-01');

-- Soft Deletes erkennen: im Quellsystem weggefallene Sätze

UPDATE dwh.Fact_Auftraege SET IsDeleted = 1, DeletedAt = SYSUTCDATETIME()

WHERE OrderID NOT IN (SELECT OrderID FROM [ERP].dbo.SalesOrders)

  AND IsDeleted = 0;

-- Reconciliation: DWH vs. ERP Umsatz-Abgleich

SELECT

    'ERP'  AS Quelle, SUM(Nettobetrag) AS Umsatz_EUR, COUNT(*) AS Zeilen

FROM [ERP].dbo.SalesOrders

WHERE YEAR(OrderDate) = YEAR(GETDATE())

  AND Status NOT IN ('STORNO', 'ENTWURF')

UNION ALL

SELECT

    'DWH', SUM(betrag_eur), COUNT(*)

FROM dwh.Fact_Auftraege

WHERE YEAR(order_date) = YEAR(GETDATE());

-- Abweichung > 0,1% → Alert auslösen

-- Schema-Monitoring: Spaltenstruktur täglich protokollieren

INSERT INTO dbo.Schema_Snapshots (Datum, Tabelle, Spaltenanzahl, SpaltenHash)

SELECT

    CAST(GETDATE() AS DATE),

    TABLE_SCHEMA + '.' + TABLE_NAME,

    COUNT(*),

    HASHBYTES('SHA2_256',

        STRING_AGG(COLUMN_NAME + ':' + DATA_TYPE, '|' ORDER BY ORDINAL_POSITION))

FROM INFORMATION_SCHEMA.COLUMNS

WHERE TABLE_CATALOG = 'ERP_Datenbank'

GROUP BY TABLE_SCHEMA, TABLE_NAME;

-- Alert bei Schema-Änderung

SELECT s1.Tabelle, s1.SpaltenHash AS Gestern, s2.SpaltenHash AS Heute

FROM dbo.Schema_Snapshots s1

JOIN dbo.Schema_Snapshots s2 ON s1.Tabelle = s2.Tabelle

WHERE s1.Datum = CAST(GETDATE()-1 AS DATE)

  AND s2.Datum = CAST(GETDATE() AS DATE)

  AND s1.SpaltenHash <> s2.SpaltenHash;

-- Freshness-SLA-Monitoring

SELECT

    ProzessName,

    MAX(ExtractEnde) AS LetzterErfolg,

    DATEDIFF(MINUTE, MAX(ExtractEnde), GETDATE()) AS MinutenZurück,

    SLA_MaxMinuten,

    CASE WHEN DATEDIFF(MINUTE, MAX(ExtractEnde), GETDATE()) > SLA_MaxMinuten

         THEN 'SLA VERLETZT' ELSE 'OK' END AS SLA_Status

FROM dbo.ETL_Protokoll p

JOIN dbo.ETL_SLA s ON p.ProzessName = s.ProzessName

WHERE Status = 'ERFOLG'

GROUP BY p.ProzessName, s.SLA_MaxMinuten

HAVING MAX(ExtractEnde) < DATEADD(HOUR, -8, GETDATE())

    OR DATEDIFF(MINUTE, MAX(ExtractEnde), GETDATE()) > s.SLA_MaxMinuten;

-- Empfohlene Datenbankstruktur für ETL-Projekte

-- Alle Schichten in einer Datenbank, getrennt durch Schemas

CREATE SCHEMA stg;   -- Staging: rohe Quelldaten, temporär

CREATE SCHEMA ods;   -- Operational Data Store: bereinigt, historisiert

CREATE SCHEMA dwh;   -- Data Warehouse: Dimensions & Facts

CREATE SCHEMA rpt;   -- Reporting: Views und Aggregationen für Power BI

-- ETL-Protokoll für alle Prozesse

CREATE TABLE dbo.ETL_Protokoll (

    ProtokollID    INT IDENTITY PRIMARY KEY,

    ProzessName    NVARCHAR(200),

    ExtractStart   DATETIME2,

    ExtractEnde    DATETIME2,

    ZeilenGelesen  INT,

    ZeilenGeladen  INT,

    ZeilenFehler   INT,

    Status         NVARCHAR(20),  -- LAUFEND / ERFOLG / FEHLER

    Fehlermeldung  NVARCHAR(MAX)

);

-- Template für robuste ETL-Prozedur mit Protokollierung

CREATE OR ALTER PROCEDURE dbo.ETL_Lade_Auftraege

AS

BEGIN

    DECLARE @StartTime DATETIME2 = SYSUTCDATETIME();

    DECLARE @ProtoID INT;

    DECLARE @ZeilenGelesen INT, @ZeilenGeladen INT;

    -- Protokolleintrag öffnen

    INSERT INTO dbo.ETL_Protokoll (ProzessName, ExtractStart, Status)

    VALUES ('ETL_Lade_Auftraege', @StartTime, 'LAUFEND');

    SET @ProtoID = SCOPE_IDENTITY();

    BEGIN TRY

        -- Staging laden

        TRUNCATE TABLE stg.Auftraege;

        INSERT INTO stg.Auftraege

        SELECT * FROM [ERP-Linked].dbo.SalesOrders

        WHERE ModifiedDate > (SELECT ISNULL(MAX(ExtractEnde), '1900-01-01')

            FROM dbo.ETL_Protokoll WHERE ProzessName = 'ETL_Lade_Auftraege'

            AND Status = 'ERFOLG');

        SET @ZeilenGelesen = @@ROWCOUNT;

        -- In DWH übertragen (MERGE für Upsert)

        MERGE dwh.Fact_Auftraege AS ziel

        USING stg.Auftraege AS quelle

            ON ziel.OrderID = quelle.OrderID

        WHEN MATCHED AND ziel.Nettobetrag <> quelle.Nettobetrag THEN

            UPDATE SET ziel.Nettobetrag = quelle.Nettobetrag,

                       ziel.GeaendertAm = SYSUTCDATETIME()

        WHEN NOT MATCHED THEN

            INSERT (OrderID, KundenNr, OrderDate, Nettobetrag)

            VALUES (quelle.OrderID, quelle.KundenNr,

                    quelle.OrderDate, quelle.Nettobetrag);

        SET @ZeilenGeladen = @@ROWCOUNT;

        -- Protokoll schließen

        UPDATE dbo.ETL_Protokoll SET

            ExtractEnde = SYSUTCDATETIME(), Status = 'ERFOLG',

            ZeilenGelesen = @ZeilenGelesen, ZeilenGeladen = @ZeilenGeladen

        WHERE ProtokollID = @ProtoID;

    END TRY

    BEGIN CATCH

        UPDATE dbo.ETL_Protokoll SET

            ExtractEnde = SYSUTCDATETIME(), Status = 'FEHLER',

            Fehlermeldung = ERROR_MESSAGE()

        WHERE ProtokollID = @ProtoID;

        THROW;

    END CATCH

END

-- dbt-Projektstruktur für SQL Server

-- profiles.yml (Verbindung zu SQL Server)

-- my_project:

--   target: dev

--   outputs:

--     dev:

--       type: sqlserver

--       server: MEIN-SERVER

--       database: DWH

--       schema: dbt_dev

--       windows_login: true

-- models/staging/stg_kunden.sql

-- Bereinigung der rohen Kundendaten

SELECT

    KundenNr                                AS kunden_nr,

    TRIM(Name)                              AS name,

    LOWER(TRIM(Email))                      AS email,

    CASE WHEN LEN(PLZ) = 5 AND PLZ NOT LIKE '%[^0-9]%'

         THEN PLZ ELSE NULL END             AS plz,

    Ort,

    AnlageDatum                             AS angelegt_am,

    SYSUTCDATETIME()                        AS _transformiert_am

FROM {{ source('erp_raw', 'Kunden') }}

WHERE Name IS NOT NULL AND Name <> ''

-- schema.yml — Datenqualitätstests direkt im dbt-Modell

-- version: 2

-- models:

--   - name: stg_kunden

--     columns:

--       - name: kunden_nr

--         tests:

--           - unique

--           - not_null

--       - name: email

--         tests:

--           - not_null:

--               severity: warn  -- Warnung, kein Fehler

--       - name: plz

--         tests:

--           - not_null:

--               severity: warn

-- Eigener dbt-Test: Umsatz-Reconciliation

-- tests/assert_dwh_umsatz_stimmt.sql

SELECT COUNT(*) AS fehler_anzahl

FROM (

    SELECT SUM(betrag_eur) AS dwh_umsatz FROM {{ ref('fact_auftraege') }}

    WHERE YEAR(order_date) = YEAR(GETDATE())

) dwh

CROSS JOIN (

    SELECT SUM(Nettobetrag) AS erp_umsatz

    FROM {{ source('erp_raw', 'SalesOrders') }}

    WHERE YEAR(OrderDate) = YEAR(GETDATE())

      AND Status NOT IN ('STORNO', 'ENTWURF')

) erp

WHERE ABS(dwh_umsatz - erp_umsatz) / NULLIF(erp_umsatz, 0) > 0.001

FABRIC VS. ON-PREMISE ENTSCHEIDUNG

Microsoft Fabric lohnt sich ab ca. 100 GB Datenvolumen/Monat oder wenn Power BI Premium bereits lizenziert ist (Fabric ist in P1+ enthalten). Darunter ist SQL Server On-Premise mit dbt oft günstiger und einfacher zu betreiben.

-- Vollständiges Lineage-Modell für ETL und ELT

CREATE TABLE dbo.Lineage_Knoten (

    KnotenID       INT IDENTITY PRIMARY KEY,

    KnotenTyp      NVARCHAR(20),    -- QUELLE / STAGING / ODS / DWH / REPORT

    Schicht        NVARCHAR(50),

    ObjektName     NVARCHAR(200),

    Beschreibung   NVARCHAR(500),

    Verantwortlich NVARCHAR(100),

    LetzteAenderung DATETIME2

);

CREATE TABLE dbo.Lineage_Kanten (

    KanteID        INT IDENTITY PRIMARY KEY,

    VonKnotenID    INT REFERENCES dbo.Lineage_Knoten(KnotenID),

    NachKnotenID   INT REFERENCES dbo.Lineage_Knoten(KnotenID),

    TransformRegel NVARCHAR(MAX),

    ProzessName    NVARCHAR(200),

    AktivSeit      DATETIME2 DEFAULT SYSUTCDATETIME()

);

-- Lineage eines Feldes zurückverfolgen (rekursiv)

WITH Lineage AS (

    SELECT k.KnotenID, k.ObjektName, k.KnotenTyp, 0 AS Tiefe

    FROM dbo.Lineage_Knoten k WHERE k.ObjektName = 'rpt.V_Umsatz_Gesamt'

    UNION ALL

    SELECT vk.KnotenID, vk.ObjektName, vk.KnotenTyp, l.Tiefe + 1

    FROM Lineage l

    JOIN dbo.Lineage_Kanten e ON l.KnotenID = e.NachKnotenID

    JOIN dbo.Lineage_Knoten vk ON e.VonKnotenID = vk.KnotenID

)

SELECT Tiefe, KnotenTyp, ObjektName FROM Lineage ORDER BY Tiefe;

-- Wiederverwendbare Qualitätsprüfungen für alle Pipelines

CREATE TABLE dbo.DQ_Regeln (

    RegelID        INT IDENTITY PRIMARY KEY,

    ObjektName     NVARCHAR(200),

    RegelName      NVARCHAR(100),

    RegelSQL       NVARCHAR(MAX),   -- SQL gibt Anzahl Fehler zurück

    Schweregrad    NVARCHAR(10),    -- KRITISCH / WARNUNG / INFO

    SLA_MaxFehler  INT DEFAULT 0

);

CREATE OR ALTER PROCEDURE dbo.DQ_FuehreAlleRegelnAus AS

BEGIN

    DECLARE @RegelID INT, @ObjektName NVARCHAR(200), @RegelSQL NVARCHAR(MAX);

    DECLARE @FehlerAnzahl INT, @Schweregrad NVARCHAR(10);

    DECLARE regel_cursor CURSOR FOR

        SELECT RegelID, ObjektName, RegelSQL, Schweregrad, SLA_MaxFehler

        FROM dbo.DQ_Regeln WHERE Aktiv = 1;

    OPEN regel_cursor;

    FETCH NEXT FROM regel_cursor INTO @RegelID, @ObjektName,

        @RegelSQL, @Schweregrad, @SLA_MaxFehler;

    WHILE @@FETCH_STATUS = 0

    BEGIN

        EXEC sp_executesql @RegelSQL, N'@n INT OUTPUT', @FehlerAnzahl OUTPUT;

        INSERT INTO dbo.DQ_Ergebnisse

            (RegelID, PruefZeitpunkt, FehlerAnzahl, Status)

        VALUES (@RegelID, SYSUTCDATETIME(), @FehlerAnzahl,

            CASE WHEN @FehlerAnzahl <= @SLA_MaxFehler THEN 'OK' ELSE @Schweregrad END);

        FETCH NEXT FROM regel_cursor INTO @RegelID, @ObjektName,

            @RegelSQL, @Schweregrad, @SLA_MaxFehler;

    END

    CLOSE regel_cursor; DEALLOCATE regel_cursor;

END

Wer hat geladen?

SQL Agent Job Owner in ETL_Protokoll

dbt run --target mit Service Account

Was wurde geladen?

ZeilenGelesen / ZeilenGeladen

dbt run results.json

Wann wurde geladen?

ExtractStart / ExtractEnde

dbt invocation_id + started_at

Warum abgewichen?

Fehlermeldung in ETL_Protokoll

dbt test results mit Fehler-Rows

Rollback möglich?

Raw-Schicht vorhanden?

Raw-Layer in Lakehouse (unveränderlich)

-- Medaillon-Schichten in SQL Server

CREATE SCHEMA bronze;   -- Rohdaten — unveränderlich, kein Transform

CREATE SCHEMA silver;   -- Bereinigt — Typen korrekt, Nulls behandelt

CREATE SCHEMA gold;     -- Business-fertig — KPIs, Aggregationen

-- Bronze → Silber Transformation (ELT innerhalb SQL Server)

CREATE OR ALTER VIEW silver.Auftraege AS

SELECT

    OrderID,

    KundenNr,

    TRY_CAST(OrderDate AS DATE)              AS order_date,

    TRY_CAST(Nettobetrag AS DECIMAL(18,2))   AS nettobetrag,

    UPPER(TRIM(Waehrung))                    AS waehrung,

    CASE WHEN Status IN ('STORNO','ENTWURF') THEN 0 ELSE 1 END AS ist_aktiv,

    _loaded_at

FROM bronze.SalesOrders

WHERE TRY_CAST(OrderDate AS DATE) IS NOT NULL;  -- Zeilen mit ungültigem Datum filtern

-- ETL: Pseudonymisierung vor dem Cloud-Load

INSERT INTO CloudStaging.Kunden_Pseudonymisiert

SELECT

    HASHBYTES('SHA2_256', CAST(KundenNr AS VARBINARY)) AS KundenKey_Pseudo,

    -- KEIN Name, KEIN Email, KEINE direkt identifizierende Information

    LEFT(PLZ, 2) + '000'   AS PLZ_Aggregiert,   -- nur Region, nicht exakte PLZ

    Branche,

    Umsatzklasse,

    AnlageDatum

FROM dbo.Kunden;

-- ELT in Azure Synapse arbeitet nur mit pseudonymisierten Daten

1. Inventar

Alle ETL-Prozesse katalogisieren, Abhängigkeiten kartieren

1–2 Wochen

Kein

2. Stabilisieren

Bestehende Pipelines mit Protokollierung und Tests nachrüsten

2–4 Wochen

Niedrig

3. Raw-Schicht

Unveränderliche Bronze-Schicht als Fundament anlegen

1–2 Wochen

Niedrig

4. Parallelbetrieb

Neue ELT-Pipeline parallel zum bestehenden ETL aufbauen und vergleichen

4–8 Wochen

Mittel

5. Ablösung

ETL-Prozess deaktivieren, sobald ELT Parität erreicht und validiert ist

pro Prozess 1 Woche

Mittel

-- ETL-Inventar: Überblick über alle bestehenden Pipelines

CREATE TABLE dbo.ETL_Inventar (

    InventarID     INT IDENTITY PRIMARY KEY,

    ProzessName    NVARCHAR(200),

    Kategorie      NVARCHAR(50),    -- STAMMDATEN / TRANSAKTION / AGGREGATION

    Quellsystem    NVARCHAR(100),

    Zieltabelle    NVARCHAR(200),

    Lauffrequenz   NVARCHAR(50),    -- TÄGLICH / STÜNDLICH / WÖCHENTLICH

    LetzterLauf    DATETIME2,

    DurchschnittMin DECIMAL(8,2),

    MigrationStatus NVARCHAR(30) DEFAULT 'OFFEN', -- OFFEN / IN_ARBEIT / MIGRIERT / BEHALTEN

    Prioritaet     INT,             -- 1=hoch, 2=mittel, 3=niedrig

    Notizen        NVARCHAR(MAX)

);

-- Migrationsfortschritt abfragen

SELECT

    MigrationStatus,

    COUNT(*) AS Anzahl,

    ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER(), 1) AS Anteil_Pct

FROM dbo.ETL_Inventar

GROUP BY MigrationStatus

ORDER BY Anzahl DESC;

-- Vergleich: Legacy-ETL-Ergebnis vs. neue ELT-Pipeline

-- Beide Pipelines laufen parallel, Ergebnisse werden verglichen

SELECT

    'Zeilenanzahl Abweichung' AS Metrik,

    ABS(etl.Zeilen - elt.Zeilen) AS Differenz,

    CASE WHEN ABS(etl.Zeilen - elt.Zeilen) = 0 THEN 'IDENTISCH'

         WHEN ABS(etl.Zeilen - elt.Zeilen) < 10 THEN 'AKZEPTABEL'

         ELSE 'PRÜFEN' END AS Status

FROM

    (SELECT COUNT(*) AS Zeilen FROM dwh.Fact_Auftraege_Legacy) etl,

    (SELECT COUNT(*) AS Zeilen FROM dwh.Fact_Auftraege_ELT) elt

UNION ALL

SELECT

    'Umsatz Abweichung EUR',

    ABS(etl.Summe - elt.Summe),

    CASE WHEN ABS(etl.Summe - elt.Summe) < 0.01 THEN 'IDENTISCH'

         WHEN ABS(etl.Summe - elt.Summe) / NULLIF(etl.Summe, 0) < 0.001 THEN 'AKZEPTABEL'

         ELSE 'PRÜFEN' END

FROM

    (SELECT SUM(betrag_eur) AS Summe FROM dwh.Fact_Auftraege_Legacy) etl,

    (SELECT SUM(betrag_eur) AS Summe FROM dwh.Fact_Auftraege_ELT) elt;

VOR DEM START

Sichern Sie alle bestehenden ETL-Prozesse (SSIS-Pakete, Stored Procedures, SQL Agent Jobs). Dokumentieren Sie den aktuellen Ist-Zustand mit Laufzeiten und Volumen. Bilden Sie ein kleines Entscheidungsteam: IT-Leitung, ein Data Engineer, ein Business-Vertreter.

ERGEBNIS NACH 30 TAGEN

Ihr Ergebnis nach 30 Tagen: Eine begründete, dokumentierte Architekturentscheidung, mindestens drei modernisierte Pipelines mit Protokollierung und Qualitätssicherung, ein laufendes Governance-Framework und ein Team, das weiß, wie neue Pipelines korrekt gebaut werden.

BI-Architektur-Review

Professionelle Analyse Ihrer Datenpipeline-Architektur — Risikobewertung, ETL/ELT-Entscheidungshilfe und Modernisierungsfahrplan. Scope: 3-5 Tage.

ERP-Einführungsberatung

Begleitung von ERP-Projekten (MACH, Dynamics NAV, APplus) — Datenmigration, Schnittstellenentwicklung, Go-Live-Support.

BI-Dashboard-Aufbau

Power BI / DeltaMaster Dashboards inkl. ETL-Strecken und Data-Warehouse-Aufbau — für KMU ab 1 Woche Projektumfang.

dbt-Einführung & Migration

Hands-on Einführung von dbt auf SQL Server oder Azure — von der Pilotpipeline bis zum Produktivbetrieb.

Interim IT-Management

Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, strategische IT-Ausrichtung.