In diesem Artikel wird die Bedeutung des Anforderungsmanagement im agilen Data Warehousing beleuchtet. Anforderungsmanagement ist im Kontext Data Warehousing vergleichsweise komplex und aufwändig und sollte daher von einem Product Owner (PO) - Team, bestehend aus Vertretern des Fachbereichs und der IT, geleistet werden. Dieses PO – Team kann Anforderung relativ informal und direkt an die Entwicklung kommunizieren. Die Ergebnisse sollten frühzeitig am Kunden getestet werden. Der frühe Markttest verlangt vor allem vom PO – Team die Kreativität und Findigkeit, Releases möglichst häufig zu ermöglichen, indem es Anforderungen in kleinere sinnvolle Teilschritte zerlegt. Zur systematischen Zerlegung von Anforderungen wird die Definition eines Klassifikationsschemas vorgeschlagen.

Im agilen Manifest wird die Forderung aufgestellt, das „Nicht-Getane“ zu maximieren. Positiv formuliert geht es darum, sich auf das Wesentliche zu konzentrieren. Das klingt zunächst banal, denn selbstverständlich wird die Entwicklung Anforderungen mit hoher Priorität vorrangig behandeln. Was aber, wenn sich die Prioritäten im Verlauf eines Planungszyklus verschieben? Diese Gefahr ist umso größer, je länger der Planungszeitraum ist. Daher werden in der agilen Entwicklung Prioritäten und Funktionalität nur für möglichst kurze Zeiträume, so genannte Sprints, festgesetzt.

Der Product Owner sollte Anwender sein

Der Product Owner (PO), der Anwender sein sollte und möglichst für alle Anwender spricht, spezifiziert und priorisiert die Anforderungen. Er hat gegenüber klassischen Verfahren den Vorteil, Spezifikationen und Prioritäten nur für einen von ihm überschaubaren Zeitraum abliefern zu müssen, mittelfristig kann er seine Meinung ändern. Darüber hinaus sind die formalen Anforderungen an die Spezifikation geringer. Der PO muss die Anforderungen schriftlich nur skizzieren und kann Details im direkten Austausch mit den Entwicklern klären. Dies ist möglich, da man über einen kurzen Zeitraum spricht, wodurch es überflüssig wird,  Informationen vollständig in externen Medien zu speichern.

In psychologischen Untersuchungen wurde nachgewiesen, dass das Aufzeichnen von Informationen in externen Systemen (z.B. Papier, Softwaresysteme) dazu führt, dass die betroffenen Menschen diese Informationen entsprechend nicht oder nur soweit wie wirklich notwendig im Gedächtnis behalten. Dieser verblüffende Zusammenhang lässt sich dadurch erklären, dass Menschen mit ihren Gedächtnis und Lernkapazitäten unbewusst möglichst effizient umgehen [Sal10]. Daraus lässt sich folgern, dass desto umfassender und besser Anforderungen in Systemen dokumentiert werden, sie umso weniger den einzelnen Teammitgliedern tatsächlich im Kopf sind.

Da das PO-Team die Anforderungen primär mündlich konkretisiert, ist er fest in den Entwicklungsprozess mit einzubinden und kann damit die Anforderungen stetig an den aktuellen Stand der Entwicklung anpassen. Anpassungen können erforderlich sein, wenn sich etwas im relevanten Umfeld geändert hat oder wenn der PO in Zusammenarbeit mit dem Entwicklungsteam Zusammenhänge versteht, die bislang nicht berücksichtigt wurden. So kann sich bei Datensichtung der Quelldaten herausstellen, dass es doppelte Datensätze gibt und der PO sich Gedanken machen muss, wie ein eindeutiger Datensatz zu definieren ist. Die Realität in einem komplexen Umfeld wird schrittweise erschlossen und der PO kann die Anforderungen iterativ den geänderten Umständen und Erkenntnissen anpassen.

Langfristige Ziele in Sprint-Zyklen zerlegen

Wie aber erreicht man, dass der „große Dampfer DWH“ dennoch langfristig nicht über den Ozean treibt, sondern einen festen Kurs einhält? Liegt in der Agilität nicht auch die Gefahr, dass sich das agile Team vom momentan Opportunen sehr kurzfristig steuern lässt und das große Ganze aus den Augen verliert? In der agilen Entwicklung liegt die Verantwortung für die Planung der Ziele bzw. Anforderungen beim PO. Dieses Vorgehen erfordert, dass er in der Lage ist, seine langfristigen Ziele in mehrere kurzfristig zu realisierende Anforderungen zu zerlegen, deren Umsetzung er in Sprint-Zyklen überwachen kann.

Der PO sollte dafür sorgen, dass die einzelnen Sprints Mehrwert generieren. Die Zerlegung einer komplexen Anforderung verlangt große Kreativität und Flexibilität vom PO. Er muss entsprechende Teilanforderungen formulieren und damit rechnen, dass sich bei Realisierung seiner Teilziele sein Fernziel verändert. Eventuell werden ursprüngliche Teilziele zum Endziel, wenn z.B. Nutzer merken, dass es ihnen genügt, die angeforderten Werte aus einer Tabelle abfragen zu können und sie kein vorgefertigtes Dashboard zur Anzeige benötigen. Das wäre natürlich ein sehr schönes Ergebnis im Sinne der Maximierung nicht getaner Arbeit.

Agile Entwicklungsprozesse

Die Agilität des Entwicklungsprozesses ist im hohen Maße von der Fähigkeit des PO abhängig, Anforderungen sinnvoll in Sprints zusammenzustellen. Dies kann für ihn große Macht aber auch Überforderung bedeuten. Während bislang Anforderungen in einem aufwändigen Prozess mit verteilten Verantwortlichkeiten formuliert wurden, kann nun der PO relativ spontan und selbstverantwortlich Anforderungen mündlich kommunizieren. Einem visionären und kompetenten PO wird damit ein mächtiges Werkzeug der „just-in-time Entwicklung“ an die Hand gegeben, genauso darbt aber ein kompetentes Entwicklungsteam unter einem unsicheren inkompetenten PO. [Pic10]

Während der agile Prozess für die Entwicklung eine gute Anleitung zur Verteilung der Verantwortlichkeiten und Selbstorganisation bietet, wird wenig darüber nachgedacht, wie der PO dabei unterstützt werden kann, sinnvolle Anforderungen zu formulieren. Dieses Manko lässt sich wahrscheinlich damit erklären, dass agile Prozessmodelle aus Entwicklungsteams heraus entstanden sind. Entwickler haben die Erfahrung gemacht, dass Anwender immer genügend wichtige Anforderungen haben und sie sich daher scheinbar keine Gedanken darüber machen müssen, wie diese entstehen und zu priorisieren sind. Aus einer reinen Entwicklungsperspektive ist diese Auffassung sinnvoll und nachvollziehbar, aber gilt dies auch aus einer Unternehmensperspektive und für ein DWH Projekt?

Die Entwicklung von DWH Systemen unterscheidet sich von der Entwicklung transaktions-orientierter Systeme vor allem dadurch, dass die Bedeutung von und der Umgang mit Daten ein anderer ist. Im Kontext transaktionsorientierter Systeme werden Daten in ihrer Funktion als Input- oder Outputwerte eines Prozesses betrachtet, ihre semantische Bedeutung ist im Rahmen des Prozesses klar definiert. Schwierig hingegen ist die Gestaltung der Prozesse, worauf sich die Softwarentwicklungs-Methodik und deren Vorgehensmodelle demnach auch konzentriert haben.

Zusammenarbeit von IT und Fachbereich

Bei der Entwicklung analytischer Systeme spielt das Verständnis und Management von Daten eine außerordentlich wichtige Rolle. Die Herkunft und Semantik der Daten muss aus bestehenden Geschäftsprozessen nachvollzogen werden. Die Arbeit der DWH Entwicklung besteht also nur zu einem relativ geringen Anteil aus dem Schreiben von Programmcode. Der Schwerpunkt der Entwicklungsarbeit liegt darin, die Entstehung und Bedeutung von Daten nachzuvollziehen. Da Daten aus der gesamten Organisation für ein Enterprise DWH zu verstehen und zu integrieren sind, ist diese Aufgabe besonders komplex und anspruchsvoll.

Die DWH – Verantwortlichen müssen sich dazu in die operativen Prozesse der Datenentstehung und –verarbeitung eindenken und ein umfassendes Verständnis der Geschäftsprozesse der Organisation entwickeln. Dafür ist sowohl Fach- als auch IT-Know-how erforderlich. Informationen müssen in Gesprächen mit unterschiedlichen Fach- und IT-Bereichen eingeholt werden. Daher empfiehlt es sich, diese Quelldatenanalyse am besten in Zusammenarbeit von Entwicklung und Fachbereich durchzuführen und deren Kollaboration durch agile Verfahren zu unterstützen. Da die Anforderungsanalyse und –spezifikation in agilen Verfahren Aufgabe des PO ist, liegt es nahe, ein PO-Team zu etablieren, das aus Vertretern des Fachbereichs und der IT besteht und es organisatorisch dem BI Competence Center (BICC) zuzuordnen [zu BICC vgl. GTS10]. Darüber hinaus ist es klar von Vorteil, wenn die Mitarbeiter des PO – Teams sowohl Modellierungserfahrung als auch Kenntnis der bereits bestehenden DWH – Modelle haben, um Modelle entsprechend ihren Anforderungen fertigen zu können. Im Sinne schneller Entscheidungen und klarer Verantwortlichkeiten ist es wichtig, eine Person des PO – Teams als zentralen Ansprechpartner (z.B. als Chief Product Owner) zu bestimmen [Hug08], [NeW11].

Frühzeitig Anwender-Feedback einholen

Im Sinne agiler Entwicklung sollten die im Rahmen des DWH Entwicklungsprozesses erzeugten Produkte möglichst frühzeitig und häufig am Kunden, sprich vom Fachbereich, getestet werden. Die Fachbereichsvertreter des PO-Teams selbst können dabei nur bedingt als Referenz für den Kunden gelten, da sie durch die enge Kollaboration mit der Entwicklung deren Sichtweise teilweise übernommen haben. So kann es passieren, dass sie aus Kenntnis technischer Probleme, Implementierungen diskussionslos akzeptieren, die ein „unbedarfter“ Anwender ablehnen würde.

Dieser frühe Test verlangt vor allem vom PO – Team die Kreativität und Findigkeit, Releases möglichst häufig zu ermöglichen, indem Anforderungen in kleine sinnvolle Teilschritte zerlegt werden. Um die Zerlegung einfach und nachvollziehbar zu machen, sollte das PO – Team eine sinnvolle Klassifikation zur Bildung von Teilanforderungen definieren. Die Klassifikation sollte ein Schema bieten, an Hand dessen die Realisierung von Anforderungen in Teilschritte zerlegt werden kann.

Eine Anforderung nach neuen Datenobjekten im DWH kann z.B. anhand der unterschiedlichen Datenlayer des Data Warehouses zerlegt werden. Die Daten können z.B. schrittweise in die verschiedenen Datenlayer übernommen werden, also im ersten Schritt nur in die Staging-Layer und in den folgenden Releases in die Integration- und Presentation-Layer [Vgl. zur Architektur [Hah10]. Des Weiteren können die Daten in verschiedenen Schritten aufbereitet werden. Die Daten könnten zunächst in Form von Rohdaten geladen und in den folgenden Schritten bereinigt, klassifiziert und aggregiert werden.

So kann eine Anforderung nach einem Bericht mit der neuen Kostenarten Transaktionskosten in folgende Teilanforderungen zerlegt werden:

1. Laden der Transaktionskosten in Form von Rohdaten in den Staging Layer.
2. Laden, Zuordnung und Transformation der Transaktionskosten in das bestehende Kostenschema des Integration Layer.
3. Qualitätsprüfung und Bereinigung der Transaktionskosten im Integration Layer.
4. Laden, Klassifikation und Aggregation der Transaktionskosten im Presentation Layer.
5. Anpassen bestehender Berichte durch Integration der Transaktionskosten
6. Entwickeln neuer Berichte, die den Kostenverlauf der Transaktionskosten ausweisen

Ein mögliches Klassifikationsschema stellt Hughes vor, wobei er zu Recht darauf hinweist, dass Klassifikationsschemata am Anwendungsfall auszurichten sind [Hug08]. In dem Bemühen ein geeignetes Klassifikationsschema seiner Anwendung zu definieren, kann das PO –Team erkennen, worauf es bei der Aufteilung seiner Anforderungen zu achten hat.

In diesem Artikel wurde im Hinblick auf die besondere Bedeutung, die Datenverständnis und –management im DWH haben, vorgeschlagen, ein PO-Team bestehend aus Vertretern des Fachbereichs und der IT im BICC einzurichten. Dieses PO – Team kann im agilen Data Warehousing Anforderungen relativ informal und direkt an die Entwicklung kommunizieren. Die hohe Agilität dieses Prozesses legt es nahe, die Ergebnisse möglichst frühzeitig am Kunden zu testen. Um dies zu ermöglichen, muss das PO – Team größere Anforderungen in Teilschritte zerlegen und dazu ein geeignetes Klassifikationsschema definieren. Das Zerlegen von Anforderungen in kleine, leichter zu handhabende Teilanforderungen ist ein schwieriger und gleichzeitig enorm wichtiger Schritt im Rahmen eines agilen DWH Projekts, der mit viel Sorgfalt ausgeführt werden sollte. Die Formulierung größerer Anforderungen zur Realisierung langfristiger Ziele unterstreicht die strategische Ausrichtung des DWH. Durch die Zerlegung in Teilziele wird gewährleistet, dass diese strategische Ausrichtung fortwährend einem Praxischeck unterzogen wird, indem Teilschritte am Kunden validiert werden.

Literatur

[Coh10]: M. Cohn: Succeeding with Agile, Addison-Wesley, 2010
[GTS10]: T. Gansor, A. Totok, S. Stock: Von der Strategie zum Business IntelligenceCompetency Center (BICC), Hanser, 2010
[Hah10]: M. Hahne: Modellieren mehrschichtiger Architekturen, in BISpektrum, Ausgabe 4 / 2010
[Hug08]: R. Hughes: Agile Data Warehousing, iUniverse, 2008
[NeW11]: S. Neus, M. Wrangler: Anforderungs-Management in großen Projekten - mit Scrum, in Computerwoche vom 28.02.2011
[Pic10]: R. Pichler: Agile Product Management with Scrum, Addison-Wesley, 2010
[Sal10]: T. Saum-Aldehoff, in Psychologie Heute, 9/2010
[Sim05]: W. Simon: Grundlagen der Arbeitsorganisation, S. 80 ff