Phasen und Rollen im ­Lebenszyklus SOA-konforme Anwendungssoftware durchläuft unterschiedliche ­Phasen, in denen spezialisierte ­Mitarbeiter gefordert sind.

Eine optimale Anwendungsentwicklung im Rahmen einer serviceorientierten Architektur (SOA) bewegt sich in einem wohldefinierten Lebenszyklus. Der Unterschied zwischen einem SOA Life Cycle (SLC) und einem konventionellen Software Development Life Cycle (SDLC) besteht darin, dass die herkömmliche Entwicklung statischer ist, während eine SOA für Dynamik steht und schnell auf Änderungen reagieren kann. Die Entwicklung SOA-konformer Anwendungen entlang eines SLC benötigt eine Fülle von Werkzeugen, eine unterstützende Infrastruktur (Enterprise Service Bus und Service Orchestration Engine, wie in Teil 2 der Serie beschrieben), ein professionelles Team mit entsprechender Organisationsstruktur und eine spezielle Governance. SOA unterstützt nicht nur die Zusammenarbeit von Fachbereich und IT, sondern benötigt sie auch. Dies ermöglicht eine Service-Architektur, die sich zwischen Fachbereich und IT schiebt und beide miteinander verbindet. Hier wird die Zusammenarbeit zwischen Fachbereich und IT entlang des gesamten SLC definiert. Service-Orientierung ist ein übergreifendes Prinzip und deckt die Bereiche Business-, Service-, Application- sowie Infrastruktur-Architektur ab. Anforderungen an die Informationstechnologie können in der Sprache der kaufmännischen Anwender definiert werden, und Strukturierungs­impulse der Service-Orientierung können ebensfall aus geschäftlicher Sicht er­folgen.

Phasen des Lebenszyklus

Wie in den ersten beiden Teilen dieser Serie dargelegt, liefert SOA einen In­frastruktur-Rahmen, der die Entwicklung von Anwendungssoftware auf der Basis lose gekoppelter Services ermöglicht. Die untenstehende Skizze zeigt die Phasen eines SLC aus der Vogelperspektive. Business-Anayse und -Design (BAD) umfassen Anforderungsanalyse, Definition von Domänen und Voka­bularien, Definition von Regeln und Vorgehensweisen sowie den Entwurf von geschäftlichen Objekten, Diensten und schließlich Prozessen. Geschäftsprozesse werden in einem SLC mit ­Hilfe der Business Process Modeling Notation (BPMN) oder der Unified Modeling Language (UML) spezifiziert. Wichtig ist, dass aus den Geschäfts­objekten, die zwischen Services ausgetauscht werden sollen, kanonische Dokumente erzeugt werden, damit sich die Dienste und Prozesse simulieren und testen lassen.

Entwurf und ­Programme

Fachliche Objekte, Services und Prozesse stehen in den Phasen Design und Implementierung modellhaft zur Verfügung und beschreiben die Artefakte, die nun informationstechnisch entworfen und programmiert werden müssen. Services und IT-Objekte, die den Business-Objekten entsprechen, werden aus vorhandenen Ressourcen erstellt. Ein SOA Management System bietet dabei die Möglichkeit, nach vorhandenen Services und Objekten zu suchen. Wenn ein bestimmter Dienst nicht vorhanden ist, kann dieser programmiert werden. Dabei spielen entsprechend den SOA-Prinzipien weder die Programmiersprache noch die Laufzeitumgebung eine Rolle. Derzeit entsteht die sogenannte Service Component Architecture (SCA) – ein Standard für das Design und die Entwicklung von Component Services, die aus einer Zusammenfassung verschiedener Services und Service-Komponenten bestehen. Dieser Standard ist technologieneutral und ermöglicht die Entwicklung von Systemen, Subsystemen, Modulen und Komponenten. Er bietet eine Anleitung für Aufbau und Zusammensetzung von Teilkomponenten. Für die Realisierung von Geschäftsobjekten wird derzeit an einem Standard namens Service Data Object (SDO) gearbeitet. Die Implementierung der Prozesse sollte automatisch durch Generierung von Code gemäß dem Standard der Business Process Execution Language (BPEL) erfolgen – auf der Grundlage der Geschäftsprozesse aus der BAD-Phase.

Betrieb und Verwaltung

In der Deployment-Phase werden die entwickelten Services und Prozesse den vorhandenen IT-Systemen und der SOA-Laufzeitumgebung eines gewählten Herstellers angepasst. Entsprechende Middleware liefern zum Beispiel IBM, BEA, die Software AG, Microsoft, Oracle und auch SAP. Dabei entstehen auch aus Legacy-Systemen Dienste, die wiederverwendet werden können. Die Management-Phase ist ebenfalls von großer Wichtigkeit. Sollen Anwendungen sich den schnellen Änderungsanforderungen anpassen können, muss eine stetige Versionierung stattfinden. Das Verwalten und Versionieren von zusammengesetzten Services stellt erhebliche Anforderungen an die Verwaltung und die zur Verfügung stehenden Werkzeuge. Zum Beispiel ist es keine einfache Arbeit, die Service Level Agreements (SLAs), Key Performance Indicators (KPIs) und Critical Success Factors (CSFs) von aus Services zusammengesetzten Anwendungen zu berechnen und erforderlichen Prozessveränderungen Rechnung zu tragen.

Rollen im SOA-Team

Das SOA-Team muss so besetzt sein, dass der gesamte SLC fachmännisch abgedeckt werden kann. SOA-Konformität bei Design und Programmierung unterstützt die Zusammenarbeit von Fachbereichen und IT und erfordert sie. Dies hat Auswirkungen auf die Organisation von IT und Fachbereich. Der größte Paradigmenwechsel beim Aufbau eines SOA-Teams ist die Konzentration auf die Lieferung von Services statt von kompletten Anwendungen. Konventionelle Software-Entwickler programmieren normalerweise Module für bestimmte Anwendungen. SOA-Entwickler dagegen erstellen wiederverwendbare Dienste, ohne wissen zu müssen wo, wann und warum sie benutzt werden. Sie interessiert nur, was die Services tun, welche Schnittstellen sie bereitstellen und welche SLAs sie erfüllen müssen. Ein SOA-Team muss die Schlüsselrollen von Architekten, Entwicklern, Business-Analysten und Projekt-Managern beinhalten. Natürlich sind auch andere Rollen erforderlich, etwa für Infrastruktur-Support, SLA Management, Governance, Datenbanken und Sicherheit. In großen Unternehmen gibt es drei Arten von Architekten: Enterprise-Architekt, Information-Architekt und Anwendungs-Architekt. Der Enterprise-Architekt zerlegt die geschäftlichen Anforderungen in Services, sodass die Entwickler diese umsetzen können. Er konzentriert sich auf die Wiederverwendung von existierenden und den Bau neuer Services. Der Information-Architekt ist verantwortlich für das Design von standardisierten Dokumenten-Schemas und für die Definition von Domänen und Vokabularien. Der Anwendungs-Architekt schließlich ist dafür verantwortlich, dass die Anwendungen SOA-konform implementiert werden. Im Zuge dessen entscheidet er auch über die Granularität der Services. Entwickler in einem SOA-Team müssen Geschäftsprozesse verstehen und bauen die Services, die die Aktivitäten in einem Prozess unterstützen. Ein SOA-Prinzip ist die Wiederverwendung. Deshalb müssen SOA Entwickler nicht alles neu erfinden, sondern sie sollen versuchen, möglichst viele vorhandene Programme wiederzuverwenden. Der Business-Analyst hat zwei wesentliche Funktionen. Erstens die Kommunikation mit dem Management und den Benutzern, um neue Business-Anforderungen zu verstehen. Zweitens die Kommunikation mit dem technischen Team, um die Business-Anforderungen in technische Spezifikationen umzusetzen. In einem SOA-Team hat der Business-Analyst zusätzlich die Aufgaben der Anforderungsanalyse und -modellierung. In einer SOA-Umgebung ist es möglich, Dienste und Abläufe flexibel zu gestalten und vor der Realisierung zu simulieren – und auch dazu trägt der Business-Analyst wesentlich bei. Die Rolle des Projekt-Managers ist in einer SOA-Umgebung anders als in einer konventionellen Umgebung, da der Lebenszyklus anders ist. Bei einer SOA muss er für kürzere Zeiten planen und mit dem Fachbereich zusammenarbeiten.

Dr. Peter Eichhorst ist Chef des IT-Dienstleisters Socon in Dresden und San Diego.