Wie geht Release-Management in der SOA? Detail - Computerwelt

Computerwelt: Aktuelle IT-News Österreich


20.12.2011 Dr. Michel Alessandrini*

Wie geht Release-Management in der SOA?

Die Muster aus der applikationszentrierten Welt lassen sich in eine Service-orientierte Umgebung kaum übernehmen - allein schon deshalb, weil es keine Anwendungen im eigentlichen Sinn mehr gibt.

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.

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.

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.

Diesen Artikel

Bewertung:

Übermittlung Ihrer Stimme...
Noch nicht bewertet. Seien Sie der Erste, der diesen Artikel bewertet!
Klicken Sie auf den Bewertungsbalken, um diesen Artikel zu bewerten.
  Sponsored Links:

IT-News täglich per Newsletter

E-Mail:
Weitere CW-Newsletter

CW Premium Zugang

Whitepaper und Printausgabe lesen.  

kostenlos registrieren

Aktuelle Praxisreports

(c) FotoliaHunderte Berichte über IKT Projekte aus Österreich. Suchen Sie nach Unternehmen oder Lösungen.

Zum Thema

  • abaton EDV-Dienstleistungs GmbH

    abaton EDV-Dienstleistungs GmbH VPN, Überwachungssysteme, SPAM-Filter, Notfalls-Rechenzentren, Firewalls, Datensicherung, Backup und Recovery Systeme,... mehr
  • Rittal GmbH

    Rittal GmbH Netzwerk-Management, Netzkomponenten, Zugangs- und Zutrittskontrolle, Unterbrechungsfreie Stromversorgung (USV), Überwachungssysteme, Notfalls-Rechenzentren, Netzwerk- und Systemüberwachung,... mehr
  • SNP AUSTRIA GmbH

    SNP AUSTRIA GmbH Qualitätssicherung, Kaufmännische Software (ERP), Tools, Programmiersprachen, Datenkonvertierung, Übernahme von Softwareprojekten, Systempflege- und Wartung,... mehr
  • Arrow ECS Internet Security AG

    Arrow ECS Internet Security AG WLAN-Systeme, VPN, Netzwerk-Systeme (LAN, MAN, WAN), Netzwerk-Management, Netzwerk-Diagnose-Systeme, Netzwerk-Betriebssysteme, Office Software,... mehr

Hosted by:    Security Monitoring by: