Agile BI Building Blocks 2.0

Es ist schon länger her, dass ich einen Blog zum Thema «Agile BI Maturity Model» publiziert habe. Nun möchte ich den aktuellen Stand dieses Modells aufzeigen.

Als Erstes habe ich das Modell in «Agile BI Building Blocks» umbenannt. Ich mag den Ausdruck «Maturity» nicht mehr, weil er die Art und Weise, wie man etwas macht, bewertet. «Building Blocks» dagegen ist neutraler. Ich möchte eigentlich nur die Aspekte beschreiben, die man beachten muss, wenn man Agile BI nachhaltig einführen will. Die folgende Darstellung zeigt das gegenwärtige Modell:

Was hat sich gegenüber der Version 1 geändert? Werfen wir einen Blick auf die einzelnen Bereiche:

1. «Agile Basics & Mindset». Hier hat sich nichts verändert – aber wichtig bleibt: Man muss mit den agilen Grundlagen und agilen Mindsets beginnen. Dafür ist das «Agile Manifesto» ein guter Ausgangspunkt oder besser noch das neuere «Modern Agile».
2. «Envision Cycle & Inception Phase». Auch hier ändert sich nichts – so viel zur Wichtigkeit der «Inception Phase» im Speziellen für BI-Projekte. Man sollte nicht direkt zur Entwicklung voranschreiten, sondern zumindest eine minimale Vorarbeit leisten, wie etwa die Infrastruktur aufsetzen, einen «high level release scope» definieren oder die Finanzierung sichern.
3. «BI specific User Stories». Erweitern Sie den Begriff «User Stories» mit «BI specific». Leider gelang es mir bislang nicht, einen Blog darüber zu schreiben. Aber in meinen Workshop Materialien findet man einige Ideen dazu.
4. «No / Relative Estimating». Dieser Punkt wurde neben «Relative Estimating» (was sich v.a. auf die «Story Points» bezieht) um «No Estimating» ergänzt. Dabei geht es um die Aspekte, welche insbesondere die #NoEstimates-Bewegung postuliert: Nämlich Schätzungen des Aufwands und der Durchlaufzeit zu minimieren oder ganz wegzulassen. An der TDWI Schweiz 2017 hielt ich dazu einen Vortrag.
5. «(Self Organizing) Teams». Weil dieser Abschnitt generell Teams und Team Rollen behandelt, wurde das «Self Organizing» in Klammern gesetzt.
6. «Workspace & Co-Location». «Workspace» wurde zu diesem Block hinzugefügt, weil es an dieser Stelle nicht nur um co-location geht (obwohl dies generell ein interessanter Aspekt des agilen Workspace ist).
7. «Agile Contracting». Hier wurde nichts verändert. In meinem Vortrag an der TDWI (siehe oben unter 4.) sprach ich über «Agile Contracting» und gab dabei einen Überblick der Idee vom agilen Festpreis (mehr dazu in diesem Buch).
8. Neu: «Data Modeling & Metadata Mgt.». Nicht nur für Agile BI sind der Toolsupport der Datenmodellierung und der Umgang mit Metadaten entscheidend. In Kombination mit DWH-Automation werden diese Elemente noch wichtiger.
9. Neu: «Data Warehouse Automation». Je mehr ich mit DWH-Automatisierungstools wie WhereScape arbeite, desto mehr wundere ich mich, wie wir früher nur ohne arbeiten konnten. Diese Werkzeuge bilden einen wichtigen Baustein auf Ihrer Reise zur noch agileren BI-Umgebung. Einen kleinen Blick erhaschen/ergattern Sie in meinem kürzlich erschienenen TDWI- / BI-Spektrum-Artikel.
10. «Version Control». Keine Änderung. Es ist immer noch eine Schande, dass «Version Control» und Integration in allgemeine Tools (wie etwa Git) in der BI-Welt nicht standardmässig möglich sind.
11. «Test Automation». Trotz keinen Änderungen ein sehr wichtiger Aspekt. Wir sind froh, dass DWH-spezifische Tools (wie etwa BiGeval) endlich auf den Markt gekommen sind.
12. «Lean & Fast processes». Auch hier keine Änderungen. Dieser Teil bezieht sich auf das Einführen von iterativ-inkrementellen Prozessen. Verschiedene Arten von Prozess Frameworks sind bereits verfügbar. Ich persönlich favorisiere Disciplined Agile, welches uns einen zielorientierten Zugang ermöglicht und eine Auswahl von verschiedenen Delivery Lifecycles anbietet.
13. «Identify & Apply Design Patterns». Dies bleibt eigentlich unverändert, ausser dass ich «Development Standards» als eigenständigen Block entfernt habe. Diese Standards sind oft nur Werkzeuge oder Technologien speziell entwickelt aus bestehenden Design Patterns. Solche gängige Design Patterns in der BI-Welt reichen von «requirements modeling patterns» (wie etwa die BEAM Methode von Lawrence Corr oder auch das IBIREF Framework) bis hin zu Datenmodellierungsmuster wie etwa Data Vault oder Dimensional Modeling und Design Muster für Datenvisualisierung wie etwa der IBCS Standard.
14. Neu: «Basic Refactoring». Refactoring ist eine wichtige Fähigkeit, um noch agiler zu werden und fortlaufend bestehende Artefakte verbessern zu können. Grundlegendes Refactoring bedeutet, dass Sie in der Lage sind, innerhalb der gleichen Technologie bzw. desselben Tooltyps ein Refactoring zu realisieren; also z.B. innerhalb einer Datenbank Database refactoring patterns zu verwenden.
15. Neu: «Additive Iterative Data Modeling». Ab einem gewissen Punkt Ihrer Reise in Richtung Agile BI können Sie das vollständige Datenmodell nicht mehr im Voraus aufzeichnen, sondern müssen darum das Modell mehr iterativ gestalten. Ein erster Schritt in diese Richtung ist die additive Art und Weise. Dies bedeutet, dass sie fortlaufend bei jeder Iteration das Datenmodell ergänzen und ausbauen. Aber Sie machen dies so, indem Sie das existierende Modell nicht stark verändern. Hier finden Sie eine gute Quelle zum Thema agiles / iteratives Modellieren.
16. « Test Driven Development / Design (TDD)». Ohne Änderungen. Auf der Ebene des DWHs vereinfachen Tools wie etwa BiGeval die Anwendung dieses Zugangs enorm. Dazu existiert Material online, um mehr über TDD im Datenbank-Kontext zu lernen.
17. «Sandbox Development Infrastructure». Ohne Veränderung aber auch ohne grossen Forschritt seit Version 1. Die meisten BI-Systeme, die ich kenne, arbeiten noch mit einer Systemlandschaft mit drei oder vier Servern und haben damit keine Möglichkeit, jedem Entwickler den eigenen vollständigen Stack zur Verfügung zu stellen.
18. «Datalab Sandboxes». Ebenfalls unverändert. Die Idee hierbei ist, dass jeder Business- bzw. Poweruser eine eigene temporäre DWH-Kopie zur Verfügung hat, um die eigenen Analysen laufen zu lassen und eigene Daten hinzufügen und integrieren zu können. Ich beobachte dies vorerst nur im Kontext der Data Science, wo jeder Data Scientist seine eigene Spielwiese verwendet, um mit unterschiedlichsten Daten experimentieren zu können.
19. «Scriptable BI/DWH toolset». Unverändert gleich aber immer noch ein wichtiger Aspekt. Wenn Sie Ihre Reise nach Agile BI zu dieser dritten Ebene des «Agile Infrastructure & Patterns» führt, welche Themen wie individuelle Entwicklerumgebungen, sowie nachfolgende, fortlaufende Integration beinhaltet, dann ist ein skriptbasierendes BI/DWH-Toolset eine wichtige Voraussetzung. Anderenfalls wird eine Automation äusserst schwierig werden.
20. «Continuous Integration». Unverändert. Ist immer noch Teil meiner Vision, wird aber im BI-Kontext sicher weitere Zeitinvestition benötigen.
21. «Push Button Deployments». Keine Veränderung. Die Werkzeuge für die DWH-Automation (vgl. oben Punkt 9) können an dieser Stelle bereits jetzt viel unterstützen. Aber man braucht immer noch viel manuellen Aufwand im Codieren für die Verbindung mit der Testautomatisierung oder mit koordiniertem Deployment für mehrere Technologien und Tool Layers.
22. Neu: «Multilayer Refactoring». Im Gegensatz zum grundlegenden Refactoring (vgl. oben Punkt 14) ist dies meine Vision zur Strukturverbesserung Ihrer Code-Bestandteile übergreifend über verschiedene Technologien und Werkzeuge.
23. Neu: «Heavy Iterative Data Modeling». Im Gegensatz zum «Additive Iterative Data Modeling» (vgl. Pkt.15) entwickelt man hier das Datenmodell konstant weiter inklusive bestehender Aspekte davon. Um dies zu erreichen, sind die «multilayer refactoring capabilities» eine wichtige Voraussetzung.

Wenn ich meine eigene Reise in Richtung mehr Agilität in BI und DWH Umgebungen betrachte, dann befinde ich mich mitten in der zweiten Phase der grundlegenden Infrastruktur und grundlegender Vorlagen und Standards. Das ergibt einen spannenden Ausblick auf das Jahr 2018. Vielleicht gelingt es uns, den Graben zu überwinden 😉.

Wie sieht Ihre Reise aus? An welcher Stelle befinden Sie sich? Konnten Sie bereits Erfahrungen mit diesen einzelnen Bereichen in der dritten Phase von agiler Infrastruktur & Muster sammeln? Lassen Sie es mich wissen und schreiben Sie einen Kommentar hierzu.

(Dieser Artikel wurde ursprünglich in meinem persönlichen Blog in Englisch publiziert.)