BI-Architektur für verlässliche, performante und governte Berichte

Positionierung

Eine gute BI-Architektur ist die Brücke zwischen dem Data Warehouse und den Menschen, die mit Daten Entscheidungen treffen. Sie sorgt dafür, dass aus technisch korrekten Daten verständliche, verlässliche und performante Berichte werden – und dass diese Berichte über Jahre hinweg konsistent bleiben, auch wenn neue Kennzahlen, neue Quellen und neue Anwender hinzukommen. Genau diese durchgängige Architektur, vom Datenmodell bis zum Bericht, ist mein Schwerpunkt.

Ich habe Business-Intelligence-Lösungen in zahlreichen Projekten entworfen und umgesetzt – mit Microsoft Power BI, mit SQL Server Analysis Services in der Tabular-Variante, mit SSRS-Berichten und mit Werkzeugen wie Grafana für das technische Monitoring. Dabei reicht die Bandbreite von klassischen, zentral betriebenen Berichtslandschaften bis zu modernen Self-Service-Szenarien, in denen Fachbereiche eigenständig analysieren – innerhalb klar definierter Leitplanken.

In meiner Arbeit verbinde ich die BI-Schicht eng mit dem darunterliegenden Data Warehouse. Eine BI-Lösung steht und fällt mit der Qualität der Daten, die sie auswertet. Deshalb betrachte ich BI nie isoliert, sondern immer als Teil einer durchgängigen Datenstrecke vom Quellsystem über ETL, Data Warehouse und semantische Schicht bis zum Bericht. Dieses Gesamtverständnis erlaubt es mir, Probleme dort zu lösen, wo sie entstehen – und nicht erst im Bericht zu kaschieren, was weiter unten in der Strecke schiefgelaufen ist.

Seit vielen Jahren begleite ich Unternehmen dabei, aus ihren Daten verlässliche Entscheidungsgrundlagen zu machen. Dabei habe ich erlebt, wie sich Business Intelligence von zentralen, IT-getriebenen Berichtssystemen hin zu dezentralen Self-Service-Szenarien gewandelt hat. Beide Welten haben ihre Berechtigung, und die Kunst besteht darin, ihre Stärken zu verbinden: die Konsistenz und Sicherheit zentraler Modelle mit der Flexibilität und Geschwindigkeit des Self-Service. Genau diese Balance entwerfe ich für meine Auftraggeber.

Meine Projekterfahrung reicht von öffentlichen Auftraggebern über Finanzdienstleister und Industrieunternehmen bis zu Logistik- und Handelskonzernen. In diesen sehr unterschiedlichen Umfeldern habe ich gelernt, dass jede Organisation ihre eigene Sprache, ihre eigenen Kennzahlen und ihre eigenen Anforderungen an Sicherheit und Governance mitbringt. Eine BI-Architektur muss deshalb nicht nur technisch sauber, sondern auch auf die jeweilige Organisation zugeschnitten sein. Genau dieses Eingehen auf den fachlichen und organisatorischen Kontext ist ein Kern meiner Arbeit.

Was BI-Architektur umfasst

Business Intelligence wird oft auf bunte Dashboards reduziert. Tatsächlich ist die Visualisierung aber nur die Spitze eines Eisbergs. Eine tragfähige BI-Architektur umfasst weit mehr: das dimensionale Datenmodell, die semantische Schicht mit Kennzahlen und Berechnungen, das Sicherheitskonzept, die Aktualisierungslogik, die Governance und schließlich die Berichte und Dashboards. Wer nur an der Oberfläche arbeitet, baut auf Sand.

Der entscheidende Wert einer durchdachten Architektur liegt in der Konsistenz. Wenn die Kennzahl „Umsatz“ in jedem Bericht dasselbe bedeutet, wenn jeder Anwender genau die Daten sieht, die er sehen darf, und wenn neue Anforderungen sich ergänzen lassen, ohne Bestehendes zu gefährden, dann entsteht Vertrauen in die Zahlen. Dieses Vertrauen ist das eigentliche Produkt von Business Intelligence.

• Datenmodell: dimensionales Star-Schema als Grundlage performanter Auswertung
• Semantische Schicht: eindeutige Kennzahlen, Beziehungen und Hierarchien
• Sicherheit: Row-Level-Security und ein durchdachtes Berechtigungskonzept
• Performance: ein Modell, das auch bei großen Datenmengen schnell antwortet
• Governance: klare Regeln für Self-Service, Freigabe und Lebenszyklus

Diese Bestandteile greifen ineinander wie Zahnräder. Ein hervorragendes Datenmodell nützt wenig, wenn die Sicherheit löchrig ist; eine perfekte Sicherheitslösung hilft nicht, wenn die Berichte langsam sind; und selbst die schnellste Lösung scheitert, wenn niemand den Zahlen vertraut, weil die Governance fehlt. Genau deshalb betrachte ich BI-Architektur immer als Ganzes und nicht als Sammlung einzelner Werkzeuge. Erst das Zusammenspiel aller Schichten ergibt eine Lösung, die im Alltag trägt und mitwächst.

Aus der Erfahrung vieler Projekte hat sich gezeigt, dass die meisten BI-Probleme nicht an der Oberfläche entstehen, sondern in den unteren Schichten. Widersprüchliche Zahlen, unklare Definitionen und schleppende Berichte lassen sich fast immer auf ein unsauberes Datenmodell oder eine fehlende semantische Schicht zurückführen. Investitionen in das Fundament zahlen sich daher weit stärker aus als kosmetische Verbesserungen an einzelnen Dashboards – ein Grundsatz, der meine Herangehensweise an jedes BI-Projekt prägt.

Die Schichten einer BI-Architektur

Eine BI-Architektur lässt sich am besten als Abfolge klar getrennter Schichten verstehen. Jede Schicht hat eine definierte Aufgabe, und der Datenfluss verläuft von der Quelle bis zum Bericht in nachvollziehbaren Schritten. Diese Trennung ist die Grundlage für Wartbarkeit und Erweiterbarkeit.

Überblick einer BI-Architektur: Data Warehouse, semantische Schicht (Tabular/Power BI), Sicherheits- und Governance-Schicht sowie die Berichts- und Self-Service-Ebene.

Am Anfang steht das Data Warehouse mit seinen auswertungsoptimierten Strukturen. Darauf setzt die semantische Schicht auf – ein Tabular-Modell oder ein Power-BI-Datensatz, das die fachliche Logik kapselt: Kennzahlen, Beziehungen, Hierarchien und Berechtigungen. Erst darüber liegen die eigentlichen Berichte und Dashboards. Quer dazu verlaufen Sicherheit und Governance, die festlegen, wer was sehen und tun darf.

Diese Schichtung bringt einen weiteren, oft unterschätzten Vorteil: Sie macht Verantwortlichkeiten klar. Das Data Warehouse verantwortet die korrekte, historisierte Datenbasis. Die semantische Schicht verantwortet die fachliche Definition der Kennzahlen und die Sicherheit. Die Berichtsebene verantwortet die ansprechende, zielgruppengerechte Darstellung. Wenn diese Verantwortungen sauber getrennt sind, lässt sich jede Schicht unabhängig weiterentwickeln, und Fehler lassen sich eindeutig zuordnen. Vermischen sich die Schichten dagegen – etwa, wenn Geschäftslogik in einzelne Berichte wandert –, entsteht ein schwer wartbares Geflecht.

Ein praktischer Hinweis: Je weiter unten in der Architektur eine Logik angesiedelt ist, desto breiter wirkt sie. Eine Kennzahl, die einmal zentral in der semantischen Schicht definiert wird, steht allen Berichten konsistent zur Verfügung. Dieselbe Kennzahl in jedem Bericht einzeln zu pflegen, ist nicht nur Mehraufwand, sondern eine Garantie für Abweichungen. Mein Leitsatz lautet deshalb: Logik so weit unten wie möglich, so weit oben wie nötig.

In der Praxis lässt sich diese Schichtung an einem konkreten Projekt gut nachvollziehen. Bei einem öffentlichen Auftraggeber etwa habe ich aus einer historisierten Data-Vault-Schicht auswertungsoptimierte Kimball-Strukturen abgeleitet und darauf ein zentrales semantisches Modell aufgesetzt. Die Fachbereiche griffen ausschließlich über dieses Modell auf die Daten zu, sodass jede Kennzahl – von der Anzahl bearbeiteter Vorgänge bis zu komplexen Quoten – über alle Berichte hinweg dieselbe Definition besaß. Änderungen an einer Kennzahl mussten nur an einer einzigen Stelle gepflegt werden und wirkten sofort konsistent in allen Auswertungen.

Eine sauber geschnittene Schichtung erleichtert auch die Skalierung des Teams. Spezialisten für das Data Warehouse, für die Modellierung der semantischen Schicht und für die Gestaltung der Berichte können weitgehend unabhängig voneinander arbeiten, solange die Schnittstellen zwischen den Schichten klar definiert sind. Genau diese Klarheit reduziert Reibungsverluste und Abstimmungsaufwand – ein Effekt, der mit der Größe einer Organisation immer wichtiger wird.

Das dimensionale Datenmodell

Das Fundament jeder performanten BI-Lösung ist ein sauberes dimensionales Datenmodell, meist als Star-Schema. Eine zentrale Faktentabelle hält die messbaren Werte – etwa Umsatz, Menge oder Anzahl –, umgeben von Dimensionstabellen, die den Kontext liefern: Zeit, Kunde, Produkt, Region. Diese Struktur ist nicht nur intuitiv verständlich, sondern auch genau die Form, mit der Analyse-Engines wie VertiPaq am effizientesten arbeiten.

Ein Star-Schema: eine zentrale Faktentabelle, umgeben von Dimensionen wie Zeit, Kunde, Produkt und Region – die Grundlage für ein performantes, verständliches BI-Modell.

Die Modellierung der Dimensionen verdient besondere Aufmerksamkeit. Eine durchdachte Zeitdimension ist die Voraussetzung für jede Zeitintelligenz – also für Vergleiche zum Vorjahr, kumulierte Werte oder gleitende Durchschnitte. Slowly Changing Dimensions vom Typ 2 erlauben es, Auswertungen auf den jeweils damals gültigen Stand zu beziehen. Diese Strukturen leite ich in vielen Projekten aus dem darunterliegenden Data Warehouse ab – häufig aus einer Data-Vault-Schicht, die Integration und Historisierung übernimmt.

-- Eine schlanke Sicht stellt die Faktentabelle anreicherungsfertig fuer das
-- Tabular-/Power-BI-Modell bereit. Schluessel sind bereits aufgeloest.

CREATE OR ALTER VIEW bi.FactSales AS
SELECT  f.DateKey,
        f.CustomerKey,
        f.ProductKey,
        f.RegionKey,
        f.Amount,
        f.Quantity,
        f.Amount / NULLIF(f.Quantity, 0) AS UnitPrice
FROM    core.FactSales AS f
WHERE   f.IsValid = 1;     -- nur fachlich gueltige Saetze ausliefern

Die BI-Schicht bekommt bewusst nur fachlich gültige, fertig aufbereitete Daten. Logik, die in jedes Modell gehört, wird hier einmal zentral gekapselt statt in jedem Bericht wiederholt.

Ein häufiger Fehler ist die Versuchung, das relationale Modell des Data Warehouse unverändert in die BI-Schicht zu übernehmen. Hochnormalisierte Strukturen mit vielen verknüpften Tabellen sind für die transaktionale Verarbeitung sinnvoll, für die analytische Auswertung in VertiPaq aber eher hinderlich. Ich denormalisiere daher bewusst auf ein Star-Schema: weniger Beziehungen, flachere Dimensionen, klar getrennte Fakten. Diese Form ist nicht nur für die Engine optimal, sondern auch für die Anwender intuitiv verständlich, weil sie der fachlichen Denkweise entspricht.

Besondere Sorgfalt verdienen die Beziehungen zwischen Fakten und Dimensionen. Eindeutige, gerichtete Eins-zu-viele-Beziehungen sind der Normalfall und halten das Modell vorhersehbar. Beidseitig filternde oder mehrdeutige Beziehungen führen dagegen schnell zu schwer nachvollziehbaren Ergebnissen und Performanceeinbußen. Wo mehrere Faktentabellen unterschiedlicher Granularität zusammenkommen, löse ich das über gemeinsame, konforme Dimensionen – so bleiben auch komplexe Modelle beherrschbar und liefern konsistente Zahlen über verschiedene Themengebiete hinweg.

Die semantische Schicht: Tabular und Power BI

Die semantische Schicht übersetzt das technische Datenmodell in eine fachliche Sprache. Hier werden aus Tabellen und Spalten benannte Kennzahlen, verständliche Hierarchien und klare Beziehungen. Im Microsoft-Umfeld setze ich dafür SQL Server Analysis Services in der Tabular-Variante sowie Power-BI-Datensätze ein – beide basieren auf derselben VertiPaq-Engine und derselben Sprache DAX.

Die Wahl zwischen einem zentralen Tabular-Modell und einem Power-BI-Datensatz hängt vom Szenario ab. Ein zentrales, im Analysis Services betriebenes Tabular-Modell eignet sich für große, unternehmensweit genutzte Modelle mit vielen Anwendern und strengen Governance-Anforderungen. Power-BI-Datensätze – insbesondere als gemeinsam genutzte, zertifizierte Datasets – sind ideal für agile, fachbereichsnahe Szenarien. Oft kombiniere ich beides: ein solides zentrales Modell als „Single Source of Truth“ und darauf aufbauende, fachbereichsspezifische Berichte.

Die semantische Schicht ist auch der Ort, an dem aus technischen Spaltennamen verständliche fachliche Begriffe werden. Ein Feld wie „amt_net_eur“ heißt im Modell „Nettoumsatz (EUR)“, eine kryptische Statusziffer wird zu einer sprechenden Bezeichnung. Diese Übersetzung in die Sprache der Fachbereiche ist kein kosmetisches Detail, sondern entscheidet darüber, ob Anwender das Modell eigenständig nutzen können. Hinzu kommen Hierarchien – etwa Jahr, Quartal, Monat, Tag in der Zeitdimension –, die das intuitive Auf- und Zuklappen in Berichten erst ermöglichen.

Bei der Wahl des Speichermodus wäge ich zwischen Import und DirectQuery ab. Der Import-Modus lädt die Daten in die komprimierte VertiPaq-Engine und ist meist die schnellste Variante. DirectQuery fragt die Quelle in Echtzeit ab und eignet sich, wenn die Daten zu groß für den Import sind oder taggenaue Aktualität gefordert ist – allerdings auf Kosten der Antwortgeschwindigkeit. Zusammengesetzte Modelle erlauben es, beide Welten gezielt zu kombinieren. Diese Entscheidung treffe ich abhängig von Datenvolumen, Aktualitätsanforderung und verfügbarer Infrastruktur.

Damit die semantische Schicht ihren Zweck erfüllt, lege ich von Beginn an Wert auf Konventionen. Einheitliche Benennungsregeln für Kennzahlen und Spalten, klar gekennzeichnete Hilfsspalten, die in Berichten nicht sichtbar sein sollen, sowie verständliche Beschreibungen zu jeder Kennzahl machen das Modell selbsterklärend. In größeren Modellen gliedere ich Kennzahlen zusätzlich in thematische Anzeigeordner, damit Anwender auch bei hunderten Kennzahlen schnell finden, was sie suchen. Dieser Aufwand zahlt sich vielfach aus, weil er Supportanfragen reduziert und das Vertrauen in die Zahlen stärkt.

Ein wichtiger Aspekt ist die Versionierung und Auslieferung der semantischen Schicht. Ich behandle Tabular-Modelle und Power-BI-Datensätze wie Software: Sie liegen in der Versionsverwaltung, werden über definierte Umgebungen von der Entwicklung bis zur Produktion befördert und automatisiert ausgeliefert. In Projekten mit Azure DevOps oder vergleichbaren Werkzeugen habe ich Pipelines aufgebaut, die Modelländerungen kontrolliert und nachvollziehbar in die Produktion bringen – inklusive automatischer Prüfungen, bevor eine neue Version freigegeben wird.

In größeren Landschaften lohnt es sich, die semantische Schicht zu modularisieren. Statt eines einzigen, alles umfassenden Modells entstehen mehrere thematisch geschnittene Modelle, die über gemeinsame, konforme Dimensionen verbunden sind. Das hält die einzelnen Modelle überschaubar, erleichtert die Pflege und erlaubt es verschiedenen Teams, parallel zu arbeiten. Wichtig ist dabei, dass zentrale Dimensionen und Kerngrößen einheitlich definiert bleiben, damit übergreifende Auswertungen weiterhin konsistente Ergebnisse liefern.

Kennzahlen mit DAX

DAX – Data Analysis Expressions – ist die Sprache, mit der Kennzahlen in Tabular und Power BI definiert werden. Sie ist mächtig, aber auch tückisch: Dieselbe Kennzahl kann je nach Kontext unterschiedliche Werte liefern, und das Verständnis von Filter- und Zeilenkontext ist entscheidend für korrekte Ergebnisse. Saubere, gut dokumentierte DAX-Kennzahlen sind ein Kernbestandteil meiner BI-Arbeit.

Grundlegende Kennzahlen wie Summen sind schnell geschrieben. Der eigentliche Wert entsteht durch abgeleitete Kennzahlen: Vorjahresvergleiche, kumulierte Werte, Anteile am Gesamten oder gleitende Durchschnitte. Das folgende Beispiel zeigt eine Basiskennzahl und darauf aufbauende Zeitintelligenz.

-- Basiskennzahl: Umsatz als Summe ueber die Faktentabelle
Umsatz := SUM ( FactSales[Amount] )

-- Vorjahreswert ueber eine markierte Datumstabelle
Umsatz VJ :=
CALCULATE (
    [Umsatz],
    SAMEPERIODLASTYEAR ( 'Datum'[Datum] )
)

-- Wachstum gegenueber Vorjahr in Prozent
Umsatz Wachstum % :=
VAR Aktuell  = [Umsatz]
VAR Vorjahr  = [Umsatz VJ]
RETURN
    DIVIDE ( Aktuell - Vorjahr, Vorjahr )

DIVIDE statt des Divisionsoperators verhindert Fehler bei Division durch null. Die Zeitintelligenz funktioniert nur mit einer als Datumstabelle markierten, lückenlosen Zeitdimension – ein häufig übersehener Punkt.

Ein weiteres mächtiges Werkzeug ist die kontextsensitive Berechnung über CALCULATE in Verbindung mit Variablen. Variablen machen DAX nicht nur lesbarer, sondern oft auch schneller, weil Zwischenergebnisse nur einmal berechnet werden. Das folgende Beispiel zeigt eine Kennzahl, die den Anteil eines Produkts am Gesamtumsatz berechnet – unabhängig davon, wie der Bericht gefiltert ist.

Umsatzanteil % :=
VAR UmsatzKontext = [Umsatz]
VAR UmsatzGesamt  =
    CALCULATE ( [Umsatz], ALL ( 'Produkt' ) )   -- Produktfilter entfernen
RETURN
    DIVIDE ( UmsatzKontext, UmsatzGesamt )

ALL entfernt gezielt den Filter auf der Produkt-Dimension und liefert so den Gesamtwert als Bezugsgröße. Solche kontextsensitiven Kennzahlen sind das Herzstück anspruchsvoller DAX-Modellierung.

Ein häufiger Stolperstein in DAX ist der Unterschied zwischen Zeilen- und Filterkontext. Eine berechnete Spalte arbeitet zeilenweise und wird beim Datenladen einmal materialisiert; eine Kennzahl dagegen wertet zur Abfragezeit den aktuellen Filterkontext aus. Wer diese beiden Welten verwechselt, erhält scheinbar unerklärliche Ergebnisse. In meiner Arbeit erkläre ich diesen Unterschied bewusst und dokumentiere bei jeder nicht-trivialen Kennzahl, welcher Kontext vorausgesetzt wird. So bleiben Modelle auch für Kolleginnen und Kollegen nachvollziehbar, die später daran weiterarbeiten.

Performance und Korrektheit gehen in DAX Hand in Hand. Iterierende Funktionen über große Tabellen, verschachtelte Filter und unnötig komplexe Ausdrücke können Berichte spürbar verlangsamen. Ich prüfe kritische Kennzahlen daher gezielt mit Werkzeugen wie dem Performance Analyzer und DAX Studio, um die teuersten Abfragen zu identifizieren und gezielt zu optimieren. Häufig lässt sich durch eine geschickte Umformulierung oder durch das Vorberechnen einer Hilfsspalte im Modell ein Vielfaches an Geschwindigkeit gewinnen.

Damit Kennzahlen langfristig wartbar bleiben, lege ich Wert auf einheitliche Muster und gute Dokumentation. Wiederkehrende Bausteine – etwa die Behandlung leerer Werte, der Umgang mit Teilsummen oder die Logik von Vorjahresvergleichen – löse ich nach denselben Konventionen, sodass eine Kennzahl auf einen Blick verständlich ist, sobald man das Muster kennt. Diese Konsistenz ist gerade in gewachsenen Modellen mit vielen Kennzahlen Gold wert: Sie senkt die Einarbeitungszeit neuer Teammitglieder und verhindert subtile Fehler, die entstehen, wenn jede Kennzahl ihren eigenen Sonderweg geht.

Row-Level-Security und Berechtigungen

In den meisten BI-Lösungen darf nicht jeder Anwender alle Daten sehen. Ein Vertriebsmitarbeiter soll seine Region sehen, ein Bereichsleiter seinen Bereich, die Geschäftsführung das Gesamtbild. Diese Einschränkung auf Zeilenebene heißt Row-Level-Security (RLS) und ist ein zentraler Bestandteil jeder professionellen BI-Architektur. Ich habe RLS in mehreren Projekten entworfen und implementiert.

Row-Level-Security: dieselben Berichte, aber jede Rolle sieht nur die für sie freigegebenen Daten – gesteuert über Rollen und dynamische DAX-Filterregeln.

RLS funktioniert über Rollen, denen Filterregeln zugeordnet werden. Eine statische Rolle filtert auf einen festen Wert; deutlich mächtiger ist dynamische RLS, bei der die Filterregel den angemeldeten Benutzer auswertet und über eine Berechtigungstabelle bestimmt, welche Daten sichtbar sind. So genügt eine einzige Rolle für beliebig viele Anwender.

-- Filterregel der Rolle "Vertrieb". USERPRINCIPALNAME() liefert den
-- angemeldeten Benutzer; ueber eine Berechtigungstabelle wird bestimmt,
-- welche Regionen dieser Benutzer sehen darf.

[Region] IN
CALCULATETABLE (
    VALUES ( 'Berechtigung'[Region] ),
    'Berechtigung'[UserPrincipalName] = USERPRINCIPALNAME ()
)

Eine einzige dynamische Rolle ersetzt Dutzende statischer Rollen. Die Pflege erfolgt komfortabel über die Berechtigungstabelle, nicht über das Modell selbst – das reduziert den Wartungsaufwand erheblich.

Bei der Gestaltung der Sicherheit denke ich immer auch an die Performance. Komplexe Filterregeln, die bei jeder Abfrage gegen große Berechtigungstabellen ausgewertet werden, können Berichte spürbar verlangsamen. Ich halte die Filterlogik deshalb so schlank wie möglich, setze auf kompakte Schlüssel und prüfe das Antwortverhalten gezielt unter realistischen Benutzerkontexten. Sicherheit darf nicht zulasten der Geschwindigkeit gehen – beides muss gemeinsam stimmen, damit die Lösung im Alltag akzeptiert wird.

Wichtig ist, RLS gründlich zu testen. Ein Fehler in der Filterregel kann dazu führen, dass Anwender entweder zu wenig oder – kritischer – zu viel sehen. In meinen Projekten gehört das Testen der Sicherheit mit verschiedenen Benutzerkontexten deshalb fest zum Abnahmeprozess.

In größeren Organisationen reicht eine einzelne Berechtigungstabelle oft nicht aus, weil sich Sichtbarkeiten entlang mehrerer Dimensionen überlagern – etwa Region, Geschäftsbereich und Mandant zugleich. In solchen Fällen entwerfe ich ein mehrdimensionales Berechtigungsmodell, das die Zugriffsregeln zentral abbildet und sowohl in der BI-Schicht als auch im darunter liegenden Data Warehouse konsistent durchgesetzt wird. So entsteht ein einheitliches Sicherheitskonzept, das auch bei Prüfungen nachvollziehbar dokumentiert ist.

Ein bewährtes Vorgehen ist, die Berechtigungstabelle aus den führenden Systemen abzuleiten, statt sie manuell zu pflegen. Wenn die Zuordnung von Benutzern zu Regionen oder Bereichen ohnehin im Personal- oder Organisationssystem gepflegt wird, lasse ich diese Information automatisiert in die Berechtigungstabelle fließen. Dadurch bleibt die Sicherheit immer aktuell, und es entstehen keine Abweichungen zwischen Organisationsrealität und Berichtszugriff.

Performance und VertiPaq

Die VertiPaq-Engine, die Tabular und Power BI antreibt, ist eine spaltenorientierte, komprimierte In-Memory-Datenbank. Sie ist extrem schnell – sofern das Modell ihre Funktionsweise berücksichtigt. Performanceprobleme in Power BI entstehen selten durch zu große Datenmengen an sich, sondern durch ungünstige Modellierung und ineffiziente DAX-Kennzahlen.

• Star-Schema statt Snowflake: weniger Beziehungen, bessere Komprimierung
• Spalten mit geringer Kardinalität bevorzugen; unnötige Spalten weglassen
• Hohe-Kardinalität-Spalten (etwa Zeitstempel) in Datum und Zeit trennen
• Berechnungen als Measures statt als berechnete Spalten, wo immer möglich
• Aggregationstabellen für große Faktentabellen einsetzen

Ein häufig unterschätzter Hebel ist die Reduktion der Kardinalität. VertiPaq komprimiert Spalten umso besser, je weniger unterschiedliche Werte sie enthalten. Eine Zeitstempelspalte mit Millisekundengenauigkeit ist Gift für die Komprimierung; getrennt in eine Datums- und eine Zeitspalte komprimiert dieselbe Information dramatisch besser. Solche Eingriffe wirken oft stärker als jede DAX-Optimierung.

Bei sehr großen Faktentabellen setze ich Aggregationstabellen ein. Dabei werden häufig abgefragte Verdichtungen – etwa Umsatz je Monat und Region – vorberechnet und in einer kompakten Tabelle vorgehalten. Die Engine greift dann automatisch auf die Aggregation zu, wenn die Abfrage es erlaubt, und fällt nur für Detailfragen auf die große Faktentabelle zurück. Für die Anwender bleibt dieser Mechanismus unsichtbar, die Berichte werden aber spürbar schneller. In Projekten mit mehreren hundert Millionen Zeilen war dies oft der entscheidende Hebel für akzeptable Antwortzeiten.

Auch das Datenmodell selbst hat großen Einfluss auf die Speichergröße. Ich entferne konsequent Spalten, die fachlich nicht benötigt werden, vermeide hochkardinale Textschlüssel zugunsten kompakter Ganzzahlschlüssel und prüfe, ob lange Dezimalwerte tatsächlich in voller Genauigkeit gebraucht werden. Jede dieser Maßnahmen verkleinert das Modell, beschleunigt die Aktualisierung und senkt den Speicherbedarf – ein Gewinn, der sich im laufenden Betrieb täglich auszahlt.

Governance und Self-Service

Self-Service-BI verspricht, dass Fachbereiche eigenständig analysieren, ohne auf die IT warten zu müssen. Das ist ein großer Gewinn – birgt aber die Gefahr von Wildwuchs: widersprüchliche Kennzahlen, ungesicherte Datenquellen und ein Dickicht aus halbfertigen Berichten. Gute Governance löst diesen Zielkonflikt, indem sie Freiheit innerhalb klarer Leitplanken ermöglicht.

Der Schlüssel ist eine geteilte, zertifizierte semantische Schicht. Fachbereiche bauen ihre eigenen Berichte – aber auf einem zentral gepflegten, geprüften Datenmodell mit verbindlichen Kennzahlen und durchgesetzter Sicherheit. So bleibt die Flexibilität des Self-Service erhalten, ohne die Konsistenz und Sicherheit der Zahlen zu gefährden. Zertifizierte Datasets, klare Namenskonventionen und ein definierter Freigabeprozess sind die Werkzeuge dafür.

• Zentral gepflegte, zertifizierte Datasets als verbindliche Datenbasis
• Klare Trennung von Entwicklung, Test und Produktion
• Namens- und Ablagekonventionen für Arbeitsbereiche und Berichte
• Definierter Freigabe- und Lebenszyklusprozess für Berichte
• Durchgesetzte Sicherheit über RLS statt über manuelle Berichtsfilter

Governance ist nicht in erster Linie eine Frage von Werkzeugen, sondern von vereinbarten Regeln und Rollen. Ich helfe Organisationen, ein tragfähiges Betriebsmodell zu definieren: Wer darf zertifizierte Datasets veröffentlichen, wer pflegt die zentralen Kennzahlen, wie läuft die Freigabe neuer Berichte ab und wann wird ein Bericht wieder außer Betrieb genommen. Diese Rollen sauber zu klären verhindert, dass die BI-Landschaft mit der Zeit unkontrolliert wächst und am Ende niemand mehr weiß, welche Zahl die verbindliche ist.

Gleichzeitig achte ich darauf, Self-Service nicht zu ersticken. Die Leitplanken sollen sicher, aber nicht hinderlich sein. Ein praktikabler Weg ist ein gestuftes Modell: ein kleiner, streng kontrollierter Kern aus zertifizierten Datasets und Kennzahlen, daneben ein Bereich, in dem Fachbereiche frei experimentieren dürfen, und ein klarer Pfad, über den sich bewährte Eigenentwicklungen in den zertifizierten Kern überführen lassen. So bleibt Innovation möglich, ohne die Verlässlichkeit der zentralen Zahlen zu gefährden.

Zur Governance gehört auch ein bewusster Umgang mit dem Datenschutz. Gerade in regulierten Branchen und bei öffentlichen Auftraggebern müssen personenbezogene Daten besonders behandelt werden. Ich plane daher frühzeitig ein, welche Daten überhaupt in die BI-Schicht gelangen dürfen, wo Anonymisierung oder Pseudonymisierung sinnvoll ist und wie der Zugriff revisionssicher protokolliert wird. So entsteht eine Lösung, die nicht nur fachlich überzeugt, sondern auch den rechtlichen und organisatorischen Anforderungen standhält.

Betrieb, Aktualisierung und Monitoring

Eine BI-Lösung ist mit der Auslieferung nicht fertig – sie muss zuverlässig aktualisiert, überwacht und gepflegt werden. Die Datenaktualisierung muss zur Aktualisierung des Data Warehouse passen: Es nützt nichts, wenn ein Power-BI-Datensatz aktualisiert wird, bevor die darunterliegenden Ladeprozesse abgeschlossen sind. Diese Abstimmung von ETL und BI-Aktualisierung plane ich von Anfang an mit ein.

Für das Monitoring nutze ich je nach Umfeld unterschiedliche Mittel. Die Aktualisierungshistorie und Nutzungsstatistiken von Power BI zeigen, ob Aktualisierungen erfolgreich waren und welche Berichte tatsächlich genutzt werden. Für technisches Monitoring habe ich in einem Projekt Grafana eingesetzt, um Läufe und Systemzustände zu visualisieren. Ungenutzte Berichte aufzuspüren ist dabei ebenso wertvoll wie das Überwachen erfolgreicher Läufe: Sie können aufgeräumt werden und entlasten so den Betrieb.

Beim Aktualisierungskonzept unterscheide ich bewusst zwischen vollständiger und inkrementeller Aktualisierung. Kleine Modelle lassen sich problemlos vollständig neu laden. Bei großen Faktentabellen richte ich dagegen eine inkrementelle Aktualisierung ein, bei der nur die jüngsten oder geänderten Zeiträume neu geladen werden, während die historischen Partitionen unberührt bleiben. Das verkürzt die Aktualisierungsdauer drastisch und entlastet sowohl die Quelle als auch die Engine – ein wichtiger Baustein für Modelle, die mehrmals täglich aktuell sein müssen.

Damit Störungen nicht erst von Anwendern bemerkt werden, baue ich, wo möglich, eine aktive Benachrichtigung ein. Schlägt eine Aktualisierung fehl oder überschreitet ein Ladeprozess sein Zeitfenster, wird das Betriebsteam automatisch informiert. So lassen sich Probleme beheben, bevor sie den Berichtsbetrieb sichtbar beeinträchtigen – ein wesentlicher Beitrag zur Verlässlichkeit, die eine BI-Lösung im täglichen Einsatz braucht.

Auch die Kapazitätsplanung gehört zu einem reifen Betrieb. Wenn viele Anwender gleichzeitig auf Berichte zugreifen oder mehrere Modelle parallel aktualisiert werden, kann es zu Engpässen kommen. Ich behalte die Auslastung im Blick, verteile Aktualisierungszeitpunkte sinnvoll über den Tag und sorge dafür, dass besonders gefragte Modelle ausreichend Ressourcen erhalten. So bleibt die Antwortzeit auch in Spitzenzeiten stabil, und die Lösung skaliert mit der wachsenden Zahl an Anwendern und Auswertungen.

Vorgehen in der Zusammenarbeit

Eine BI-Architektur entsteht im engen Austausch mit den Fachbereichen. Bevor ich ein Modell baue, kläre ich, welche Fragen die Berichte beantworten sollen, welche Kennzahlen wirklich gebraucht werden und wie sie fachlich definiert sind. Gerade die fachliche Definition von Kennzahlen ist oft anspruchsvoller als ihre technische Umsetzung – und genau hier entstehen die meisten Missverständnisse, wenn man sie nicht früh klärt.

• Analyse: fachliche Fragen, Kennzahlen und ihre verbindliche Definition klären
• Modellierung: Star-Schema und semantische Schicht entwerfen
• Umsetzung: Kennzahlen in DAX, Sicherheit über RLS, Berichte iterativ entwickeln
• Test und Abnahme: Zahlen und Sicherheit gemeinsam mit den Fachbereichen prüfen
• Betrieb: Aktualisierung, Monitoring, Governance und Dokumentation

In vielen Projekten – etwa in den Bereichen Controlling, Finance, Sales und HR – habe ich Anforderungen direkt mit den Fachabteilungen erarbeitet und in passende BI-Lösungen übersetzt. Dieser direkte Draht zum Fachbereich ist mir wichtig: Eine technisch perfekte Lösung, die an der fachlichen Frage vorbeigeht, hilft niemandem.

Ich arbeite bewusst iterativ. Statt monatelang im Verborgenen ein perfektes Modell zu bauen, liefere ich früh einen lauffähigen ersten Stand und entwickle ihn gemeinsam mit den Anwendern weiter. Ein greifbarer Prototyp deckt Missverständnisse über Kennzahlendefinitionen oder erwartete Auswertungen viel schneller auf als jedes Anforderungsdokument. Diese kurzen Rückkopplungsschleifen senken das Risiko, am Bedarf vorbeizüntwickeln, und sorgen dafür, dass die Fachbereiche sich die Lösung von Beginn an zu eigen machen.

Ein Teil meiner Arbeit ist auch die Befähigung des Teams. Ich übergebe keine Black Box, sondern erkläre die getroffenen Entscheidungen, schule die künftigen Verantwortlichen im Umgang mit dem Modell und den Kennzahlen und hinterlasse eine Dokumentation, die das eigenständige Weiterarbeiten ermöglicht. Mein Ziel ist eine Lösung, die auch ohne mich gut weiterlebt – das ist für mich der Maßstab für nachhaltige BI-Arbeit.

Gerade weil ich die gesamte Datenstrecke kenne – von der Quelle über ETL und Data Warehouse bis zum fertigen Bericht – kann ich an der jeweils richtigen Stelle ansetzen. Manche Probleme, die sich in einem Bericht zeigen, lassen sich am sinnvollsten im Datenmodell oder schon in der Beladung lösen. Dieses durchgängige Verständnis bewahrt davor, Symptome an der Oberfläche zu bekämpfen, und führt zu Lösungen, die an der Ursache ansetzen und deshalb dauerhaft tragen.

Typische Leistungen im BI-Projekt

Rund um die BI-Architektur übernehme ich je nach Projektphase unterschiedliche Aufgaben – von der Konzeption über die Umsetzung bis zum Betrieb.

• Entwurf einer durchgängigen BI-Architektur vom Data Warehouse bis zum Bericht
• Dimensionale Modellierung als Star-Schema, inklusive SCD2 und Zeitdimension
• Aufbau semantischer Schichten in SSAS Tabular und Power BI
• Entwicklung von DAX-Kennzahlen, Time Intelligence und kontextsensitiven Berechnungen
• Konzeption und Implementierung von Row-Level-Security, auch dynamisch
• Performance-Analyse und VertiPaq-Optimierung von Modellen und Berichten
• Governance-Konzepte für Self-Service-BI mit zertifizierten Datasets
• Abstimmung von ETL-Aktualisierung und BI-Refresh
• Monitoring von Aktualisierung, Nutzung und Systemzuständen
• Schulung, Wissenstransfer und technische Dokumentation

Ausgewählte anonymisierte Referenzprojekte

Häufige Fragen zur BI-Architektur