Eine neue Definition von Release

Für Service-orientierte Landschaften muss der Begriff Release also neu definiert werden. Basierend auf den vielen externen Abhängigkeiten der Services und Geschäftsprozesse gilt es, weiträumigere Abgrenzungen über Komponentengrenzen hinaus zu schaffen. Hinzu kommt, dass häufig eine Anzahl an Services beziehungsweise Geschäftsprozessen ein technisches Deployment-Paket bildet. Diese Tatsache ist bei der Definition ebenfalls zu berücksichtigen. Alles in allem ist unter einem Release in Service-orientierten Umgebungen folgendes zu verstehen:

Ein Release besteht aus einer Menge von Geschäftsprozessen und Services, die fachlich und/oder technisch miteinander zusammenhängen.

Die strukturelle Ausrichtung im Release-Management muss sich an die Service-orientierte Landschaft anpassen. Der Release-Manager verantwortet jetzt Services und Geschäftsprozesse inklusive der grafischen Frontends. Da die Komplexität zunimmt, steigt unter Umständen auch die Anzahl an Managern pro Releasee.

Im Normalfall zeichnet der Release-Manager für eine bestimmte Menge von Services und/oder Geschäftsprozessen aus einem fachlichen Bereich verantwortlich, die häufig technische Abhängigkeiten auf der Deployment-Ebene aufweisen. Die Herausforderung besteht darin, die Komponenten so effizient zu gliedern, dass es möglichst wenige Überschneidungen im Release-Management-Team gibt. Denn Überlappungen erfordern eine enge Abstimmung innerhalb des Teams.

Frühzeitige Planung und Kommunikation

Für einen reibungslosen Ablauf ist es notwendig, die Release-Termine frühzeitig zu planen. Die steigende Anzahl an Abhängigkeiten und Stakeholdern erschwert die Abstimmung. Folglich sollte der Release-Manager gemeinsam mit seinem Team alle Termine mittels des Time-Boxing-Verfahrens, festlegen - im Idealfall bis zu einem Jahr im Voraus.

In der Praxis haben sich drei bis vier regulär geplante Releases pro Jahr als gangbare Lösung erwiesen; bei geringerer Anzahl steigt die Wahrscheinlichkeit von "Exceptional Releases". Die Planung sollte frühzeitig bekannt gegeben werden, damit die Stakeholder gegebenenfalls von ihrem Veto-Recht Gebrauch machen können. Abhängigkeiten der Komponenten untereinander werden in der Planung berücksichtigt, indem diese zeitgleich in Produktion gehen.

Die Release-Inhalte werden - Itil-V3-konform - zum Zeitpunkt des "Scope Freeze" (Festschreiben der Zielfunktionen) mit dem Change-Manager abgestimmt und von den Stakeholdern in Form eines CAB offiziell abgesegnet. Dummerweise sind nicht immer alle Stakeholder unmittelbar bekannt, was aus Management-Sicht problematisch ist. Also muss das Release-Management beispielsweise gemeinsam mit dem Service-Provider eine für alle zugängliche Webseite anbieten, auf der sich zumindest die unternehmensinternen Stakeholder über den aktuellen Stand informieren können.