Die Welt der IT wird zunehmend globaler. Aufgrund verschiedenster Einflüsse wie z.B. Flexibilität, Kostendruck und verfügbare Ressourcen, findet eine Softwareentwicklung nicht mehr nur an einem IT-Standort eines Unternehmens statt.
Selbst mittelständische Unternehmen haben mittlerweile mehrere IT-Standorte an denen gleichzeitig durch mehrere Teams entwickelt wird.
Kann bei der Entwicklung operationaler Systeme hier noch eine funktionale Trennung erfolgen, so dass ein Standort nur an einem System oder einer Komponente entwickelt, so ist dies bei einem „Enterprise Data Warehouse“ Ansatz nicht möglich.
Ein „Enterprise Data Warehouse“ ist dadurch gekennzeichnet dadurch, dass möglichst viele operationale Systeme Daten an dieses liefern und nur dort ein systemübergreifendes Reporting stattfindet. Dazu müssen die entsprechenden Quellsysteme in einer einheitlichen Modellschicht integriert werden. Diese wird häufig Core-, Foundation- oder DWH- Layer genannt. Aus diesem heraus werden dann in der Regel mehrere „Data Marts“ gespeist, die durch entsprechende BI-Tools abgefragt werden. Bei einem derart zentralistischen Ansatz kann eine funktionale Trennung nicht mehr ohne weiteres durchgeführt werden. Es müssen also Techniken und Vorgaben entwickelt werden, die ein gleichzeitiges Entwickeln an mehreren Entwicklungsstandorten an einer zentralisierten BI-Applikation ermöglichen. Hierfür kommen sogenannte BI-Frameworks zum Einsatz.
Jedes funktionierende Framework muss hierzu drei grundlegende Arbeitsbereiche berücksichtigen:
Diese Arbeitsbereiche sind wie folgt gekennzeichnet:
- Entwicklung: Was soll entwickelt werden?
- Prozesse: Wie sieht der Entwicklungsprozess aus?
- Governance: Wer ist für was verantwortlich?
Alle drei Bereiche sind dabei gleich wichtig und stehen in engem Zusammenhang. Beispielsweise macht es keinen Sinn, eine detaillierte Vorgabe für eine fachliche Spezifikation im Entwicklungsbereich vorzugeben, wenn nicht auch auf der Prozessseite klar vorgegeben wird, zu welchem Zeitpunkt im Projekt diese auf welche Art zu erstellen ist und gleichzeitig auch zu bestimmen, wer diese zu entwickeln, zu reviewen und abzunehmen hat. Nur wenn alle drei Bereiche gleichermaßen definiert sind, kann ein derartiges BI-Framework zum Erfolg führen.
Was sind aber nun die eigentlichen Inhalte der oben erwähnten Bereiche?
Entwicklung
Im Bereich der Entwicklung muss vorgegeben werden, nach welchen formalen und inhaltlichen Prinzipien eine BI-Entwicklung zu erfolgen hat. Dieses kann durch eine Reihe von Dokumentenvorgaben z.B. in Form von sogenannten Templates erfolgen. Klassische Templates sind dabei:
- Fachkonzept
- IT-Konzept
- Technische Spezifikation
- Sicherheitskonzept
- Testkonzept
- …
Die Templates alleine sind hierbei aber nicht ausreichend. Gerade bei einer verteilten Entwicklung muss es darüber hinaus noch Vorgaben hinsichtlich Architektur und Konfiguration der einzelnen Systemkomponenten geben. Diese werden in sogenannten Guidelines festgelegt. Beispiele hierfür sind:
- Architektur Guide
- Security Guide
- Test Guide
- Namenskonventionen
- Reportdesign
- …
Die Guidelines sind von der BI-Abteilung, die für die Entwicklung verantwortlich ist, festzulegen. Sie geben dem Entwickler klare Vorgaben, wie ein Problem zu lösen ist und welche Werkzeuge dafür eingesetzt werden sollen. Durch diese Vorgaben wird die Entwicklung in einem Unternehmen standardisiert, so dass nicht jede Entwicklergruppe zu anderen Lösungen kommt. Jedwede erzeugten „BI-Artefakte“ sind damit zwischen den Gruppen vergleichbar und können somit besser gewartet und wiederverwendet werden.
Prozesse
Die Prozessbeschreibungen sollen dafür sorgen, dass in jedem BI-Projekt eine klar ablaufende Kette von Tätigkeiten stattfindet, an deren Ende die erfolgreiche Einführung einer BI-Entwicklung steht. Dabei sind sowohl die ausgefüllten Templates der Entwicklung, als auch der erzeugte Programmcode als sogenannte Deliverables zu betrachten, die in den einzelnen Teilprozessen erzeugt werden.
Hierbei muss sich ein Unternehmen entscheiden, ob es eher klassischen Entwicklungsprozessen folgt z.B. Wasserfallmodellen oder vielmehr auf agile Methoden wie z.B. Scrum setzt. Entsprechend unterschiedlich können dann die Prozesse ausgestaltet sein. Was aber, egal welchen Ansatz man verfolgt, gleich bleibt ist, dass es feste Lieferzeitpunkte geben muss, zu denen die genannten Deliverables fertiggestellt sein müssen.
Innerhalb der Prozesse gibt es daher sogenannte Transition Points an denen Aktionen wie z.B. Abnahmen zu erfolgen haben. Diese können entweder Endpunkte sein, oder Haltepunkte innerhalb eines Prozesses. An diesen Transition Points entscheidet sich jeweils, ob ein bestimmtes Ziel erreicht wurde und wie es nach diesem weitergeht. Häufig sind mit diesen Transition Points „Deliverables“ verknüpft.
Beispiele für Prozesse sind:
- Erstellung Fachkonzept
- Erstellung IT-Konzept
- Erstellung Technische Spezifikation
- Source-Code Erzeugung
- Testen
- Produktivnahme
- Betrieb
- …
Die Prozessbeschreibungen sollen dafür sorgen, dass ein Entwicklungsprozess klar beschrieben ist und damit messbar, vor allem in Hinsicht auf seine Qualität. Jede Entwicklergruppe, egal an welchem Standort, hat somit ein einheitliches Vorgehen.
Governanance
Bei der Governance geht es darum, die Prozesse und die Entwicklung sozusagen zu verheiraten. Dazu ist es notwendig ein transparentes Rollen- und Verantwortlichkeitskonzept zu definieren. Dabei wird zum einen die „Ownership der Deliverables“ festgelegt. D.h. wer hat z.B. das IT-Konzept zu erstellen, wer verantwortet es inhaltlich und wer ist berechtigt, es formal abzunehmen.
Aus der Governance lässt sich eine Aufbaustruktur der Entwicklungsteams und im Extremfall der gesamten BI-Abteilung ableiten. In dieser wird festgelegt wie eine Zusammenarbeit zwischen BI und Fachbereich auszusehen hat, wie die Zusammenarbeit stattfindet und wer zu welchem Zeitpunkt im Lead ist. Die Einführung einer Governance kann zum Teil schwerwiegende Umgestaltungen in den betroffen Entwicklungsabteilungen nach sich ziehen, da Zuständigkeiten und Verantwortlichkeiten gleichförmig über alle Entwicklungsteams geregelt sein müssen.
Fazit
Der Einsatz eines im Detail wie auch immer ausgestalteten BI-Frameworks soll dafür sorgen, dass Abläufe in verschiedenen Entwicklungsteams klar geregelt werden, dass Ansprechpartner und Verantwortliche bekannt sind und dass die Entwicklung nach einheitlichen Vorgehensweisen und Paradigmen ablaufen. Dieses hat den Vorteil, dass man Entwicklungen an einem Enterprise Data Warehouse auf unterschiedliche Teams und Standorte verteilen kann ohne Gefahr zu laufen, aufgrund unterschiedlicher Ansichten oder gar kultureller Unterschiede, nicht kompatible Systemkomponenten zu entwickeln.
Ein BI-Framework ist ein unabdingbares Werkzeug für die in der Lieferverantwortung stehenden Manager, um qualitativ hochwertige BI-Lösungen für Ihr Unternehmen zu produzieren.
Bildnachweise: ©iStock-801051868-scaled.jpg
