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