Das Thema CI/CD (Continuous Intelligence/Continuous Delivery) hält erst in den letzten Jahren Einzug in die BI Landschaft. Aber warum ist das der Fall? Eignen sich BI Projekte etwa nicht für den Einsatz von CI/CD? Im Folgenden wollen wir die Frage aus verschiedenen Gesichtspunkten betrachten.
- Aus Projektmanagementsicht
- Aus Softwaresicht
- Aus Entwicklersicht
- Im Kontext der IT Landschaft
1. Aus Projektmanagementsicht
BI Projekte zeichnen sich im Normalfall durch einige Merkmale aus, die sie von Projekten der klassischen Applikationsentwicklung abgrenzen. In erster Linie sind BI Projekte zu Beginn der Projektphase vor allem nicht so klar umrissen und abgegrenzt, wie das bei einer Applikation der Fall ist. Damit möchte ich nicht unterstellen, dass in der Applikationsentwicklung keine Änderungen oder Erweiterungen des Projektfokus vorkommen oder sogar an der Tagesordnung sind. Aber die Art und Häufigkeit der Änderungen bei BI Projekten ist doch oftmals anders geartet.
Die grundsätzliche Anforderung ist klar:
- Daten aus einem oder mehreren Quellsystemen sollen gesammelt und zum Zwecke der Auswertung und Visualisierung aufbereitet werden.
Was sind also die Herausforderungen?
- Quellsysteme können sich ändern oder neue Quellsysteme müssen angebunden werden
- Die Technologieauswahl kann sich ändern. Manchmal nicht nur im Laufe des Lebenszyklus, sondern wirklich während der Projektphase.
- Die Auswahl der zu berechnenden Kennzahlen als auch die Definition der Berechnungsgrundlagen kann sich ändern
- Die Zielgruppen innerhalb des Unternehmens, die als Konsumenten des Systems in Frage kommen und damit zur Anforderungsdefinition beitragen, können sich ändern.
Zusammengefasst kann man als bei BI Projekten kurz zusammengefasst sagen:
Die einzige Konstante ist, dass es keine Konstanten gibt. 🙂
2. Aus Softwaresicht
Der Einfachheit halber orientieren wir uns hier an den Microsoft BI Projekttypen. Aus eigener Erfahrung sei zu sagen, dass einige der genannten Besonderheiten mit Sicherheit auch auf andere BI Projekttypen anwendbar ist, den genauen Umfang wollen wir hier aber nicht beleuchten.
Wenn wir über BI Projekte im Microsoft Umfeld sprechen, dann sind damit in erster Linie die „klassischen“ Projekttypen gemeint, die mit dem Visual Studio Ableger SSDT bereitgestellt werden. In der Vergangenheit der SQL Server Versionen war dieser Ableger noch unter dem Namen BIDS (Business Intelligence Development Studio) bekannt oder zwischenzeitlich noch in die Bereiche SSDT (rein Datenbankprojekte) und SSDT BI (restliche BI Projekttypen) unterteilt. Insgesamt umfasst es die folgenden Projekttypen:
- Datenbankprojekte (finden ihren Einsatz auch außerhalb des BI Fokus)
- SSIS (= SQL Server Integration Services) Projekte für Lade- und Transformationsprozesse (ETL, ELT, EL)
- SSAS (= SQL Server Analysis Services) Projekte für die Bereitstellung multidimensionaler Datenbanken. Heutzutage gibt es zwei Varianten:
- SSAS Multidimensional
- Klassische Cubeentwicklung
- Keine Verfügbarkeit als PaaS (Platform as a Service)
- keine signifikante Weiterentwicklung seit SQL Server 2008R2
- SSAS Tabular
- Tabellarische Modelle im In-Memory Modus
- Unter dem Namen Azure Analysis Services auch als PaaS verfügbar
- Seit SQL Server 2012 verfügbar, das aktuelle Objektmodell ist seit SQL Server 2016 verfügbar.
- Wird ständig weiterentwickelt und bildet die Basistechnologie für Power BI
- SSAS Multidimensional
- SSRS (= SQL Server Reporting Services) Projekte für die Visualisierung von Daten
Neben den Visual Studio und damit Entwicklertool-basierten Projekten gilt es im aktuellen Kontext noch Power BI mit zu berücksichtigen. Dieser integrierte Softwareansatz vereint die Komponenten ETL, Modellierung und Visualisierung in einer Software und spiel über den ursprünglich stark in den Vordergrund gestellten Self-Service Ansatz hinaus auch zunehmend in der Unternehmens-IT-Landschaft eine beträchtliche Rolle.
Wie wirken sich jetzt aber die genannten Projekttypen auf die Anwendung von CI/CD Prozessen aus? Speziell bezogen auf die Visual Studio basierten Projekttypen könnte man doch davon ausgehen, dass diese die gleichen Eigenschaften aufweisen wie die Projekttypen für die diversen Programmiersprachen zur Applikationsentwicklung.
Aber weit gefehlt. Die BI Projekttypen zeichnen sich durch eine signifikant andere Struktur aus, die eine entscheidende Rolle spielt.
Microsoft BI Projekte werden übergehend mit Hilfe der visuellen Komponenten und mit Unterstützung von Wizards entwickelt. Als Konsequenz sind im Unterschied zu den klassischen Entwicklungsprojekten die Objekte innerhalb der Projektstruktur überwiegend in einem XML Format abgelegt.
Die einzige Ausnahme bildet hier das SSAS Tabular Projekt, das seit dem Wechsel auf das neue Objektmodell mit SQL Server 2016 JSON basiert daherkommt.
Jeder Entwickler, der sich in der Vergangenheit dem Wagnis gestellt hat, Änderungen direkt im Code vorzunehmen ist sich der Komplexität dieser Modelle bewusst. Nicht nur gilt es die Integrität der XML Strukturen zu berücksichtigen und zu bewahren, darüber hinaus müssen auch noch Abhängigkeiten zwischen den verschiedenen Objekten und Schichten innerhalb der Projektstruktur berücksichtigt werden. Fehlerhafte Änderungen können zu einer Invalidierung des gesamten Projekts führen.
Zurück zu unserem Kernthema CI/CD:
Wie wirken sich diese Besonderheiten der BI Projekte auf den CI/CD Ansatz aus?
Eine der relevanten Aspekte ist das Thema des Zusammenführens diverser Änderungen zu einer gemeinsamen, validen Entwicklungsversion. Dies geschieht in erster Linie durch eine Änderungsanalyse in Kombination mit einer soweit als möglich automatisierten Zusammenführung durch Merge-Algorithmen. Die BI Projektstruktur macht diesen Ansatz beinahe unmöglich und durch die Komplexität der Zusammenführung gibt es innerhalb des Visual Studios noch nicht einmal manuelle Merge-Komponenten. Die Zusammenführung kann hier also nicht gewährleistet werden, ein entscheidender Aspekt des Prozesses wird also nicht unterstützt.
In der Fortsetzung betrachten wir noch die anderen Perspektiven und ziehen ein paar Schlussfolgerungen. 🙂