Mehr und mehr Unternehmen heben ihre Client-Server-Applikationen schrittweise auf Service-orientierte Umgebungen. Mit der Umstellung der Software ist es allerdings nicht getan. Aus der neuen Architektur entstehen neue Anforderungen, die in die Management-Prozesse einfließen müssen. Dazu zählen die an Itil V3 angelehnten Prozesse aus dem Bereich Service Transition, vor allen in den Disziplinen Change-Management, Release and Deployment Management sowie Service Validation and Testing.
Release-Management-Prozesse sollen im Wesentlichen den Produktiveinsatz qualitätsgesicherter Software-Releases vorbereiten. Damit sind sie eine notwendige Voraussetzung für den stabilen und hochwertigen Betrieb. Das applikationszentrische Release- und Change-Management richtet sich strukturell an der Infrastruktur der Anwendungssoftware aus.
Die zeitliche Planung der Releases lässt sich aufgrund der geringen externen Abhängigkeiten vornehmen, ohne dass das allzu viele Restriktionen erfordern würde. Zudem sind alle Stakeholder einfach zu ermitteln. Die von den Stakeholdern eingereichten Release-Inhalte werden gemeinsam mit dem Change-Manager priorisiert und im Rahmen eines Change Advisory Board (CAB) offiziell abgesegnet.
Applikation versus Prozess
In der Client-Server Welt bildet der Begriff Applikation den Rahmen für die Funktionen, die innerhalb einer Softwarelösung gebündelt sind. Beim Service-orientierten Ansatz verliert dieser Ausdruck an Bedeutung. Die Bezugsgröße bilden nunmehr die Geschäftsprozesse. Sie lassen sich mit Hilfe von Services eins zu eins in der IT abbilden. Daraus resultierenden allerdings ein paar Schwierigkeiten.
Ein und derselbe Service kann von verschiedenen Geschäftsprozessen verwendet werden. Die Services sind ja lose gekoppelt, unabhängig und wiederverwendbar. Daduch entstehen fließende Übergänge zwischen den Geschäftsprozessen und ein engmaschiges Netz aus Verbindungen. Eine Applikation in der SOA-Welt repräsentiert quasi eine beliebige Permutation der Komponenten Frontend, Geschäftsprozess und Service.
Klare Abgrenzungen in einer SOA existieren lediglich auf der Ebene der Services. Auch wenn diese intern weitere Services nutzen können, bieten sie stets klar definierte Funktionen an. Vor allem, wenn Services in externen Umgebungen bereitgestellt werden, ist es wichtig, die Operationen mit ihren definierten Eingabe- und Ausgabe-Parametern zu kennen. Weiterführende Informationen bleiben jedoch häufig verborgen.
Hinsichtlich der Aufstellung des Release-Managements in einer SOA ergeben sich daraus einige Fragen. Beispielsweise ist zu prüfen, ob ein Release im eigentlichen Sinne überhaupt noch existiert. Ist doch ursprünglich ein Software-Release durch eine in sich geschlossene Menge an Quellcode, Dokumentation und Support-Tools gekennzeichnet, und die gibt es in der Service-orientierten Welt nicht mehr.
Teaserbild: Fotolia, A. rodriguez
Eine neue Definition von Release
Foto: Michel Alessandrini
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.
Eine Website für jeden Service
Für externe Stakeholder sollten die Informationen separat bereitgestellt werden. Dafür eignet sich am besten eine Web-Seite, die jeweils einen Service oder Geschäftsprozess präsentiert. Inhalte sind dann die funktionale Beschreibung, die Erläuterung der Schnittstelle, die Nutzungsbedingungen, der URI (Unified Resource Identifier), die Schnittstellenbeschreibung (zum Beispiel eine WSDL), die Release-Notes und eine Traceability-Matrix, welche die Abhängigkeiten verdeutlich. Auch die fix geplanten Änderungen mit ihren Terminen sollten dort aufgeführt und erläutert werden. Zu pflegen sind diese Informationen durch den Release-Manager und den Service-Provider.
Die geplanten Releases müssen eingehalten werdne; kurzfristige Änderungen sollten grundsätzlich nicht möglich sein. Dies widerspricht allerdings dem SOA-Paradigma, weil es eine kurze Time-to-Market verhindert. Deshalb besteht auch weiterhin die Möglichkeit, zusätzlich zu den regulären Ausnahme-Releases aufzusetzen. Sie sollten allerdings tatsächlich die Ausnahme bleiben und nur in wichtigen Fällen - wie kurzfristigen gesetzlichen Änderungen - zum Einsatz kommen. Das Release-Risiko und der organisatorische Aufwand eines Exceptional Realease sind hoch, weshalb der Projekt-Manager die Wirtschaftlichkeit genau betrachten sollte.
Der Release-Manager im Zentrum
Der Release-Manager hat die Aufgabe, Qualität und Stabilität des Release sicherzustellen. Um dieses Ziel zu erreichen, muss er alle relevanten Tätigkeiten überwachen sowie die Verfügbarkeit der Release-Artefakte (zum Beispiel Software- und Dokumentationslieferungen) sicherstellen.
Die hohe Komplexität, die Anzahl der involvierten Services und der Stakeholder, die vielen verschiedenen technischen Plattformen und die unterschiedlichen Programmiersprachen machen oft ein größeres Team erforderlich. Damit rückt der Release-Manager mehr in die Position eines Koordinators und Vermittlers. Er stellt die Kontakte zwischen Stakeholdern her und moderiert bei Konflikten. Soziale Kompetenzen bekommen in dieser Position - neben gesteigerten Projekt-Management-Fähigkeiten - einen hohen Stellenwert.
Erschwerte Risikoanlayse
Foto: Weim, Fotolia.de
Innerhalb der regelmäßigen Status-Meetings gilt es, ein gemeinsames Bild des jeweiligen Release herzustellen und die Risiken sorgfältig zu betrachten. Dass gegebenenfalls nicht alle Stakeholder an Bord sind, erschwert eine ganzheitliche Analyse. Der Release Manager muss deshalb die richtigen Fragen stellen, um potentielle Risiken zu entdecken. Das Resultat hängt dabei stark von der Auskunftsfähigkeit der Stakeholder ab. Defizite sind durch den Release-Manager zu kompensieren.
Der Teilnehmerkreis des CAB muss das Release befürworten, bevor der Release-Manager es freigibt. Änderungen des Scope durch Anfragen der Stakeholder werden im Rahmen der CAB-Meetings erörtert und unter Beachtung der Risiken abgelehnt oder autorisiert.
Nach der Release-Freigabe übernimmt der Deployment-Manager die Installation der Komponenten in die Zielumgebung. Dabei ist es sinnvoll, zwischen Deployment und Aktivierung zu unterschieden. Um das Risiko zu verringern, sollte die Installation deutlich vor der geplanten Aktivierung erfolgen. So lassen sich eventuell auftretende Deployment-Probleme ohne Auswirkungen auf den Betrieb rechtzeitig beheben.
Nach der Aktivierung aller Komponenten gibt es wieder eine kurze Phase, in der "Defects" gemeldet und eventuell kurzfristig behoben werden können. Danach geht die Verantwortung vom Release-Manager auf die einzelnen IT-Operations-Manager über. Ein bis zwei Monate später ruft der Release-Manager alle Stakeholder zu einem "Post Implementation Review" zusammen. Nun stehen erneut potenzielle Prozessverbesserungen im Vordergrund. (qua)