Ratgeber SOA

Wie geht Release-Management in der SOA?

16.12.2011
Von Dr. Michel Alessandrini

Erschwerte Risikoanlayse

Der Release-Manager muss die Risiken geschickt hinterfragen.
Der Release-Manager muss die Risiken geschickt hinterfragen.
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)