Im ersten Teil des CI für BI? Posts haben wir uns bereits mit Anforderungen an CI/CD Prozesse im BI Umfeld aus Sicht des Projektmanagements und aus Softwaresicht befasst. Im zweiten Teil wollen wir das Bild vervollständigen und ein Resümee ziehen.

3. Aus Entwicklersicht

An dieser Stelle ist der Wechsel zur Entwicklersicht nachvollziehbar. Die in der Softwaresicht beschriebene Komplexität der Entwicklung und vor allem die nahezu Unmöglichkeit der Zusammenführung verschiedener Entwicklungsstände hat zu einer anders gearteten Entwicklertätigkeit im Rahmen von BI Projekten geführt, als dies bei Applikationsentwicklung der Fall ist. In der Regel wird ein Projekttyp, wenn nicht sogar das gesamte Projekt, nur von einem Entwickler zur gleichen Zeit bearbeitet. Mit einer gut strukturierten Kommunikationsstruktur ist in einigen Bereichen ein paralleles Bearbeiten eines Projekttyps durch mehrere Entwickler möglich, so lange diese an unterschiedlichen Objekten arbeiten. Dies erfordert aber eine fundierte Kenntnis der projektinternen Abhängigkeiten. Und diese Form parallelen Arbeitens durfte auch nur auf der gleichen Projektinstanz erfolgen. Das übliche Vorgehen in getrennten Entwickler-Branches zu arbeiten und die Resultate zusammenzuführen, kann hier nicht angewendet werden.

4. Im Kontext der IT Landschaft

Eine weitere Besonderheit von BI Projekten ergibt sich aus der Einbettung dieser Projekte in die IT Landschaft des Unternehmens.

Betrachten wir uns zunächst den Aufbau eines klassischen BI Projekts, dann stoßen wir auf einen relativ typischen Aufbau von Datenhaltung (Quellsysteme/Datenbank), Datenzugriff (ETL), Logik (Modellierung) und Visualisierung. Ein klassisches Drei-Schichtenmodell, wie es auch in einem Lehrbuch zur Anwendungsentwicklung stehen könnte.
Was unterscheidet aber die BI Projekte?

1.  (Nahezu) Jede Schicht in der BI Projekt Architektur wird in einer anderen Technologie entwickelt. Dies gilt auch für Power BI Projekte, die intern ja auch verschiedene Technologien kombinieren.
2. Die Daten werden nicht durch die Applikation erfolgt, sondern stammen aus verschiedenen Quellsystemen, die nicht Teil des Projektes sind.
3. Integrationstests im Rahmen eines BI Projekts erfordern die Bereitstellung der gesamten betroffenen IT Landschaft in einem geeigneten Testsystem. BI Projekte können in den seltensten Fällen als eigenständige Komponente ohne Abhängigkeiten von anderen Systemen bewertet werden.

Wir können zusammengefasst bewerten, dass aus allen genannten Gesichtspunkten sich Schwierigkeiten für den Einsatz von CI/CD für BI Projekte ergeben. Unserer Vermutung nach haben diese Erkenntnisse in Summe mit der dadurch geringen Nachfrage zu einem weiteren, aber umso entscheidenderem Problem geführt:

Die mangelnde Unterstützung von CI/CD Prozessen durch Softwarehersteller.

Wir hatten bereits das Fehlen von Merge-Tools in Visual Studio angesprochen. Diese mangelnde Unterstützung findet sich aber auch in weiteren Softwarekomponenten wieder:

1. Build Tools
   Selbst das hauseigene Build Tool msbuild unterstützt BI Projekte nicht von Haus aus. Es gibt mittlerweile für einige Projekte (SSAS Tabular, SSIS) die Möglichkeit, durch Installation zusätzlicher Assemblies diese Unterstützung zu erzielen. Aber ohne zusätzlichen Aufwand funktioniert das nicht.
2. CI/CD Tools
   Grundsätzlich werden BI Projekte unterstützt, wie jeder andere Projekttyp auch. Allerdings wird die Anwendung für viele Projekttypen durch vordefinierte Templates vereinfacht, was vor allem den Einstieg in die Integration von CI/CD deutlich vereinfacht. Für BI Projekte ist das nicht gegeben.
3. Deployment Tools
   Hier gibt es zum Teil Möglichkeiten mit speziellen Tools zu arbeiten (SSIS Deploy Tool, SSAS Deployment Wizard und weitere), aber eine generelle Unterstützung ist auch hier noch nicht in dem Maße gegeben.
4. Testing
   Hier stoßen wir auf die größte Herausforderung. Es gibt für BI Projekte nur eine geringe Anzahl an Software Produkten, die die Erstellung von Unit- und Integrationstests für BI Projekte ermöglichen. Und insbesondere in Anbetracht der genannten Komplexität von BI Projekten in Bezug auf die Integration in die IT Landschaft, als auch durch die Häufigkeit und den möglichen Umfang von Änderungsprozessen in den Projekten ist die Erstellung automatisierter Tests der wichtigste, aber auch der aufwendigste Aspekt von CI/CD für BI Projekte.

Bedeutet das nun, dass CI/CD für BI Projekte nicht geeignet ist?

Ganz im Gegenteil! Aus unserer Erfahrung mit BI Projekten gibt es kaum Projekte, die von einer konsequenten Nutzung von Automatisierung, insbesondere automatisiertem Testen derartig profitieren können, wie dies für BI Projekte der Fall ist.
Dennoch darf man die Augen nicht davor verschließen, dass der Aufwand gerade zu Beginn nicht unterschätzt werden darf. Von daher können wir mit Sicherheit nicht dazu anraten, CI/CD Prozesse in bestehende BI Projekte nachträglich zu integrieren.
Aber mit jedem neuen Projekt, dass ihr beginnt, solltet ihr ernsthaft in Erwägung ziehen, jetzt endlich anzupassen. Der Trend speziell der letzten zwei Jahre spricht auch für eine zunehmend stärkere Unterstützung und Vereinfachung der Integration.

Aber wie sind eure Erfahrungen?
Mit BI Projekten allgemein, mit Herausforderungen für CI/CD in BI Projekten…?

Wir freuen uns über Kommentare, Ergänzungen und Anregungen. 🙂