Wie Unternehmen Composite Models in Power BI als Game-Changer für Self Service Business Intelligence einsetzen können

Mit Composite Models erweitert Microsoft das Einsatzspektrum von Power BI für Fachabteilungen in Unternehmen maßgeblich. Für die zentralen Business Intelligence- bzw. IT-Abteilungen entsteht gleichzeitig ein sehr starkes Instrument für Self-Service BI, um die Fachabteilungen unter Berücksichtigung ihrer Governance-Richtlinien mit neuen Freiheiten und Fähigkeiten auszustatten. Der Artikel richtet sich somit sowohl an Verantwortliche und fortgeschrittene Anwender von Power BI Desktop im Controlling als auch an Verantwortliche in der zentralen IT bzw. Business Intelligence. Richtig eingesetzt eröffnen Composite Models Unternehmen eine neue Welt für Self-Service BI.

Der Anwendungsfall

Jeder Microsoft Power BI Berichtsentwickler bzw. „Power User“ kennt folgende Situation: Ein neues Power BI Dashboard bzw. Report soll auf Basis eines zentral durch BI- bzw. IT-Abteilungen bereitgestellten Power BI Datasets erstellt werden. Dieses Dataset ist im besten Fall für die vorliegende Fragestellung des Reports schon optimal geeignet und beinhaltet neben den erforderlichen Daten in der geeigneten Granularität auch zentral gesicherte und abgestimmte Logiken für die auszuwertenden Kennzahlen. Trotzdem kommt es oft vor, dass für den angeforderten Report ein paar zusätzliche Informationen im Dataset fehlen. Für solche kleinen Erweiterungen eines zentralen Datasets, die für bestimmte Reports und Ad-hoc Analysen kurzfristig erforderlich und ggf. sogar nur temporär benötigt werden, gibt es viele denkbare Anwendungsfälle:

• Individuelle Gruppierungen von Kunden, Produkten, etc. in Form von kalkulierten Spalten in den entsprechenden Dimensionstabellen des zentralen Modells oder als Erweiterung über zusätzliche Tabellen, die mit bestimmten Schlüsseln einer bestehenden Dimensionstabelle des zentralen Modells in Beziehung gesetzt werden können.
• Plan- und Forecast-Werte aus Planungswerkzeugen sollen importiert und mit den zentralen Dimensionen und damit mit den Ist-Werten aus dem zentralen Modell in Verbindung gebracht werden.
• Benchmark-Werte aus dem Internet, Webservice basierten Quellen, etc.
• Import von individuell erstellten Schwellwerten, die in DAX-Logiken für ABC-, Pareto-Analysen, etc. genutzt werden können.
• …

Als Power User hat man aus Data Governance Aspekten aber keine Berechtigung, das zentrale Dataset zu erweitern. Obwohl die erforderliche Erweiterung ggf. sogar relativ einfach umzusetzen wäre (z.B. als eine simple, zusätzliche kalkulierte Spalte in einer existierenden Tabelle für eine zusätzliche Aggregation oder als zusätzliche Faktentabelle für Benchmarkwerte), wird dies aus bestimmten Gründen nicht (schnell genug) in das zentrale Dataset aufgenommen. Beispiele für solche Gründe sind:

• Kurzfristig haben IT-Mitarbeiter bzw. IT-Spezialisten keine freien Kapazitäten, um das zentrale Dataset zu erweitern.
• Die Erweiterung wäre für die meisten anderen Dataset-Benutzer irrelevant, würde diese nur verwirren und die Akzeptanz des zentralen Datasets gefährden.
• Die Erweiterung ist nur temporär für ein paar Ad-hoc Analysen relevant und nach einiger Zeit wieder obsolet. Sie müsste dann entweder wieder mit zusätzlichem Aufwand entfernt werden oder würde als „Leiche“ im Analysemodell bestehen bleiben.
• Die Erweiterung muss laut der IT-Experten „sauber“ eingebaut werden und das würde inklusive der Arbeiten im zentralen Data Warehouse einige Tage/Wochen dauern. Auch hierbei entsteht wieder ein Konflikt bzgl. Prioritäten und Ressourcenverfügbarkeiten in der zentralen BI-Abteilung.

• …

Durch diese Situation entsteht ein großes Dilemma für den Power User. Eine mögliche Lösung des Problems wäre es, sich mit dem Anforderer des Berichts auf einen eingeschränkteren Scope/Inhalt ohne die nötige Erweiterung zu einigen. Wenn das – was die Regel ist – keine echte Option ist, muss sich der Power User selbst im Self-Service mit Power BI Desktop eine eigene Datenbasis schaffen, indem er Daten aus dem zentralen Dataset extrahiert bzw. in ein eigenes Modell importiert und diese dort mit den erforderlichen, zusätzlichen Informationen in Verbindung bringt. Dieses Vorgehen hat neben einem deutlich höheren Aufwand viele weitere gravierende Nachteile. Alle denkbaren Aspekte bzgl. Data Governance, Sicherheit, Datenschutz, IT-Alignment, Flexibilität, etc. sprächen eigentlich deutlich für eine temporäre Erweiterung des zentralen Modells – im Gegensatz zu dem nun erforderlichen Self-Service BI Vorgehen unter Verwendung von Export/Import-Mechanismen in Power BI Desktop oder anderen Tools. Insbesondere wenn dafür im schlimmsten Fall auch noch Excel, Access, etc. zum Einsatz kommen, floriert anstelle der angestrebten, möglichst integrierten Self Service Business Intelligence schnell eine Schatten-IT in den Fachabteilungen. Einem verantwortungsbewussten Power User ist das durchaus bewusst, aber in diesem Fall gibt es keine andere Wahl, oder? Doch! Mit Composite Models für Microsoft Power BI existiert eine elegante Lösung für dieses Dilemma…

Was sind Composite Models?

Seit Dezember 2020 ist unter dem offiziellen Namen „Direct Query for Power BI Datasets und Analysis Services“ (vgl. Microsoft Dokumentation) für Microsoft Power BI ein mächtiges Feature verfügbar, mit dem in Unternehmen eine noch nie da gewesene Ebene im Self-Service BI erreicht werden kann. Diese Funktionalität ist bereits in Power BI Pro enthalten, also kein(!) ausschließliches Power BI Premium Feature. Alberto Ferrari und Marco Russo von sqlbi bezeichnen die Einführung dieser Funktionalität als „Milestone in Business Intelligence“ und sprechen anstelle des etwas sperrigem, offiziellem Namen einfach von „(new) Composite Models“ (vgl. sqlbi Artikel). Wir bei noventum wollen uns der griffigeren Bezeichnung von sqlbi anschließen, obwohl Microsoft offiziell mit diesem Begriff eigentlich Modelle beschreibt, in denen Import und Direct Query Datenquellen miteinander kombiniert werden (vgl. Microsoft Dokumentation). Wenn wir also im Folgenden von „Composite Models“ sprechen, meinen wir damit das von Microsoft offiziell als „Direct Query for Power BI Datasets und Analysis Services“ bezeichnete Feature.

Genug zur verwirrenden Begriffserklärung… Was genau sind diese Composite Models? Kurz gesagt, ermöglichen sie es, existierende Power BI Datasets und (Azure) Analysis Services Datenbanken (also „tabulare Modelle“ auf Basis der In-Memory Engine Vertipaq. vgl. Microsoft Dokumentation) zu erweitern. Das hört sich zunächst sehr einfach an. Wenn man allerdings genauer darüber nachdenkt, stellt man fest, dass es sich um ein sehr mächtiges Werkzeug handelt, bei dem im Hintergrund komplexe Logiken wirken müssen. Erweiterungen existierender Analysemodelle kennen wir sonst nur auf einer dediziert formulierten Aggregationsebene – z.B. Import von DAX-Abfragen (s.o.) oder vergleichbare Mechanismen in anderen Tools. Composite Models ermöglichen aber im Vergleich dazu eine Erweiterung des gesamten (komplexen) Analysemodells mit all seinen Tabellen, Spalten, Aggregationsvorschriften, etc. auf Basis der darin enthaltenen Datengranularität aus dem Data Warehouse. Genau dieser Sachverhalt macht dieses Feature aus unserer Sicht zu einem echten Game-Changer für Self Service Business Intelligence!

Typischerweise wird Microsoft Power BI Desktop bei der Nutzung einer Live Connection zu einem tabularen Modell (Power BI Dataset oder Analysis Services Datenbank) zu einem reinen Werkzeug für die Berichtserstellung. Jegliche Möglichkeit bzgl. der Modellierung, Anbindung weiterer Datenquellen über „Get Data“ und die Tabellenansicht werden bei der Verwendung einer Live Connection ausgegraut bzw. deaktiviert. Lediglich die Anlage neuer, lokaler DAX-Measures ist möglich. Mit dem neuen Feature verhält sich dies nun für Live Connections zu Power BI Datasets, Azure Analysis Services (AAS) und SQL Server Analysis Services (SSAS) ab der Version SQL Server 2022 endlich anders.

Ein kurzer Rückblick: Kurz nach der Geburtsstunde von Microsoft Power BI in 2015 wurde mit der Einführung von SQL Server 2016 die tabulare In-Memory Engine für Analysis Services (Vertipaq) auch für die Standard Edition des SQL Servers verfügbar gemacht – war damit also nicht mehr ein teures Enterprise Edition Feature. Schon in unseren ersten Projekten mit der tabularen SSAS-Version ab SQL Server 2016 und Power BI als Berichtswerkzeug kam jedes Mal nach dem Herstellen der Live Connection zu einem zentralen SSAS-Modell folgende Frage auf: „Das ist super. Jetzt kann ich einfach Berichte auf dem zentralen SSAS-Analysemodell erstellen. Kann ich das jetzt trotzdem noch im Self-Service mit Power BI Funktionalität um Daten aus einer lokalen Datei, etc. erweitern? Kann ich noch eine kalkulierte Spalte o.ä. hinzufügen?“ Unsere Antwort darauf lautete dann immer etwas kleinlaut: „Leider ist in diesem Fall nur die Anlage neuer, lokaler DAX-Measures möglich. Aber wir sind überzeugt davon, dass die Entwicklungen bei Microsoft in die Richtung gehen werden, so dass solche Erweiterungen (schon bald) möglich sein sollten.“ Seit Dezember 2020 können wir nun stolz behaupten, dass wir damals nicht gelogen haben. Wir haben zwar gehofft, dass wir nicht so lange warten müssen. Aber besser spät als nie.

Wie funktionieren Composite Models?

Für die Nutzung dieser Funktionalität sind bestimmt Einstellungen im Power BI Service erforderlich (XMLA Endpoints and Analyze in Excel, Live Connection, Direct Query for Datasets, XMLA Endpoints in Premium – vgl. Microsoft Dokumentation im Abschnitt „Managing this feature“).

Wenn man nun eine Live Connection zu einem existierenden Power BI Dataset in der Cloud (oder einer Analysis Services Datenbank in der Cloud und/oder On-Premise) öffnet, erkennt das geschulte Auge direkt, dass der „Get Data“ Knopf nicht mehr ausgegraut ist und im Tab für die Modellierung und in der Statusleiste (unten rechts) wird die Option angeboten, Änderungen an diesem gerade per Live Connection verbundenen Analysemodell vorzunehmen. Es folgt dann noch die Bestätigung, dass durch diesen Vorgang ein lokales Modell erstellt wird, in dem die Live Connection durch eine Direct Query Connection ersetzt wird (dieser Vorgang kann nachher für die PBIX-Datei nicht rückgängig gemacht werden!) und danach trifft man eine Auswahl der einzubindenden Tabellen des ausgewählten tabularen Modells.

„Make changes to this model“ ist allerdings eine sehr irreführende Bezeichnung. Das zuvor per Live Connection eingebundene tabulare Modell – das so genannte „Remote Model“ – wird im Folgenden überhaupt nicht verändert. Es bleibt im Hintergrund unverändert bestehen und wird lediglich in das gerade erstellte lokale Modell – das so genannte „Local Model“ – eingebunden bzw. verlinkt. Auch die Daten des Remote Models sind nicht im Local Model enthalten, sondern befinden sich ausschließlich physisch im Remote Model – z.B. sieht man in der Datenansicht für die Tabellen des Remote Models nur den Text „This table uses Direct Query and cannot be shown“. Im Folgenden nimmt man also lediglich Änderungen am gerade erstellten Local Model vor.

Wenn man das Local Model in den Service publiziert, sieht man in der Herkunftsansicht, die Abhängigkeit zum Remote Model:

Im Local Model kann man zwar bestimmte Eigenschaften von Objekten des Remote Models verändern (z.B. Umbenennung, Sichtbarkeit, etc.), aber hierbei handelt es sich nur um „kosmetische“ Korrekturen, die lediglich die eingebundenen Objekte im Local Model betreffen und nicht das Remote Model verändern. Wirklich inhaltliche Veränderungen am Remote Model sind nicht möglich. Z.B. können keine Beziehungen im Remote Model gelöscht oder verändert werden, es können keine neuen Beziehungen zwischen Remote Model Tabellen erstellt werden, es können keine DAX-Definitionen von Measures des Remote Model geändert werden, etc.

Das Local Model dient also nicht dazu, das eingebundene Remote Model zu verändern, sondern dazu, es zu erweitern! Es können also neben neuen DAX Measures (auch schon vorher möglich) z.B. neue kalkulierte Spalten dem Remote Model Tabellen eingefügt werden. Der wichtigste Punkt für Erweiterungen ist, dass in Power BI nun über den kompletten „Get Data“ Dialog mit allen möglichen Datenquellen vom relationalen SQL Server und Flatfile-Anbindungen über Web Services bis hin individuellen Schnittstellen für SAP, Hadoop, etc., etc. andere Daten in das lokale Modell importiert (bzw. mit Direct Query angebunden) werden können! Diese Informationen lassen sich nun über Beziehungen und in DAX-Logiken mit den Tabellen und Daten des Remote Models kombinieren.

Einsatzgebiete für Composite Models

Die Funktionalität der Composite Models begeistert wohl alle fortgeschrittenen Microsoft Power BI Anwender und es kommen einem direkt eine Vielzahl damit möglich gewordener, interessanter Einsatzgebiete und Anwendungsfälle für Self-Service BI in den Kopf (siehe oben).

Aber Vorsicht! Aus großer Macht folgt große Verantwortung. Es ist wichtig, Composite Models von Beginn an richtig und sinnvoll einzusetzen. Auch Marco Russo von sqlbi warnt trotz seiner euphorischen Ankündigung der Composite Models: „However, an easy prediction is that this feature will also be used in the wrong way. Beware of new architectures based on new composite models. I am already scared of diagrams showing tens of data sources federated into a “virtual” semantic model connected to smaller datasets.“ (vgl. sqlbi Artikel). Je mehr sie folgende Fragen mit „Ja“ beantworten können, desto eher handelt es sich um ein geeignetes Einsatzgebiet für Self-Service BI unter Verwendung von Composite Models. Wenn Sie die folgenden Fragen eher mit „Nein“ beantworten, sind Composite Models tendenziell die falsche Wahl.

• Wollen Sie das zentrale Dataset tatsächlich nur im engeren Sinne „erweitern“ (zusätzliche Spalten, Tabellen, etc.)? Composite Models sind nicht(!) für Veränderungen des Remote Models geeignet. Composite Models sind ebenso kein geeignetes Mittel, um separate Datasets virtuell zu kombinieren.
• Können die zusätzlich eingebundenen Daten relativ einfach – ggf. mit Power Query – in Verbindung zu den Daten/Strukturen des Remote Models in Verbindung gesetzt werden (einheitliche Schlüssel, Granularitäten, etc.)?
• Ist die Erweiterung des zentralen Datasets nur für einige/wenige Benutzer dieses Datasets relevant? Handelt es sich also um eine individuelle Erweiterung, die andere Dataset-Benutzer ggf. sogar irritieren würde?

• Ist die Erweiterung vielleicht sogar nur temporärer Natur? Also z.B. lediglich für einige Wochen für eine kurzfristige, recht operative Fragestellung erforderlich und danach nicht mehr relevant?
• Ist das Datenvolumen der Erweiterungen eher klein? Bzw. anders formuliert: Sind die Kardinalitäten für Beziehungen zwischen den neuen Tabellen des Local Models und bestehenden Tabellen des Remote Models eher klein?

Auch wenn Sie die meisten der obigen Fragen mit „Nein“ beantworten, ist der Einsatz von Composite Models häufig dennoch einer alternativen, individuellen Export/Import-Lösung für Self-Service BI vorzuziehen. Insbesondere wenn die erforderliche Erweiterung tatsächlich am besten direkt im zentral bereitgestellten Dataset aufgehoben wäre, aber aus Zeit- und Ressourcen-Gründen nicht schnell genug von zentralen BI-Abteilungen umgesetzt werden kann. In diesem Fall ist eine Entwicklung mit Composite Models später viel einfacher in das zentrale Modell zu überführen, weil sie in der „gleichen Sprache“ der zentralen BI-Abteilungen erfolgt.

Wenn Sie mehr erfahren wollen, wie Composite Models auch in Ihrem Unternehmen ein Game-Changer für Self-Service BI werden können, sprechen Sie uns einfach an. Wir helfen Ihnen gerne dabei und beraten Sie auch bzgl. der technischen Details, die Composite Models im Hintergrund benutzen, und welche Konsequenzen sich daraus für den Einsatz und eine optimale Einbindung in Ihre zentrale BI-Strategie ergeben.