SOA Governance –Technologie reicht nicht aus

SERVICE-LEBENSZYKLEN

Ein Ergebnis der Solution-Designs sind neue Services, womit wir zu einem zweiten Hauptprozess von SOA kommen. Diese Services sind Software, die wie jede andere Software auch, einem Lebenszyklus unterliegt. Dieser Lebenszyklus hat allerdings einige Besonderheiten, die vor allem darin begründet sind, dass SOA-Landschaften System-Landschaften sind, die sich ständig weiterentwickeln. Damit treffen Regeln und Prozesse für neue Software auf Regeln und Prozesse für die Wartung und Pflege existierender Software. Schauen wir uns dazu den typischen Lebenszyklus eines Services an.

Es beginnt mit der Identifizierung von Services (etwa wie diskutiert durch ein Solution-Design oder aber auch durch ein Portfolio-Management). Sobald feststeht, dass ein neuer Service benötigt wird, wird er entworfen und dann implementiert. Die Erfahrung zeigt, dass auch für Services die üblichen Anforderungen an Software gelten: Wir machen Fehler und Anforderungen ändern sich. Aus diesem Grund wird es im Rahmen der Realisierung von Services (Implementierung, Integration und Test) auch immer wieder passieren, dass das Design eines Services geändert werden muss. Bemerkenswerterweise handelt es sich bei Services aber um Schnittstellen zwischen verteilten Systemen, die in unterschiedlicher Verantwortung liegen. Und in solchen Fällen neigt man nach wie vor dazu, im Vorfeld Schnittstellen abzusprechen, gegen die dann von beiden Seiten implementiert wird. Ein Szenario, das in der Praxis nicht funktioniert. Auch hier ist also Zusammenarbeit entscheidend, vor allem wenn sich Schnittstellen ändern. Verteilte Entwicklungsprozesse müssen darauf vorbereitet sein (auch wenn ein Teil der Systeme als Werkleistung vergeben ist). Entscheidend ist also ein gut funktionierendes Änderungsmanagement.

Ist ein Service aber erst einmal produktiv, kann er nicht mehr so einfach verändert werden. Hier sieht man, dass aus Software in Entwicklung Software in Wartung und Pflege geworden ist. Entscheidend für die Zuverlässigkeit der Systeme wird nun Stabilität. Rückwärtskompatibilität wird ein entscheidender Faktor. Erlaubt sind in dieser Phase nur noch Fehlerbehebungen. Jede darüber hinausgehende Änderung (sei sie rückwärtskompatibel oder nicht) ist eine neue Version des Services, die aus technischer Sicht einen eigenen Service darstellt und einen neuen Lebenszyklus startet.

Die Tatsache, dass jede Änderung eines in Produktion befindlichen Services faktisch ein neuer Service ist, ist inzwischen allgemein akzeptiert. Die Erfahrung zeigt, dass das Risiko, in Produktion befindliche Services zu erweitern, zu hoch ist, selbst wenn eine Änderung rückwärtskompatibel ist. Neue Versionen haben neue Fehler und nicht selten stellt sich heraus, dass Rückwärtskompatibilität doch nicht vorhanden ist, weil sich zum Beispiel Laufzeiten aufgrund zusätzlich verarbeiteter Daten verschlechtert haben. Erweiterungen als neue Services (bzw. Service-Versionen) explizit einzuführen ermöglicht auch hier eine sanfte Migration.

Der Nachteil ist, dass eine derartige Versionierungspolitik zu vielen Services (bzw. Service-Versionen) führt. Deshalb ist es wichtig, auch hier einen organisatorischen Prozess für die Abkündigung und Außerbetriebnahme von Services zu etablieren.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.