Service Oriented Architecture Modelling:
Eine Methode zum schrittweisen Aufbau einer SOA, die sowohl die Kernprozesse als auch die differenzierenden Geschäftsprozesse unterstützt.
Component Business Modeling (CBM):
Mit dieser Methode können Unternehmen und deren Geschäftsabläufe in einzelne logische Bausteine zer-legt werden. So werden Kernprobleme identifiziert und adressiert.
Component Infrastructure Roadmap (CIR):
Ein Verfahren, mit dessen Hilfe der derzeitige Stand und Reifegrad der IT beurteilt wird, um die Entwicklung hin zu einer Service-orientierten Architektur zu ermöglichen.
Der Ansatz eines SOA-Projektes kann in folgende Schritte strukturiert werden:
Projektdefinition und Projektziele, ggf. Aufteilung des SOA-Projektes in kleine Einheiten
Wahl des Projektansatzes (Top-down, Bottom-up)
Wahl der Technologien
Management und Monitoring der Projektaktivitäten (Projekt-Governance)
Generierung von „quick wins“ durch gezielte Imple-mentierung von Services, die einen ROI liefern
Aufbau und Pflege eines umfassend nutzbaren Ser-vice Repository
Gezieltes Monitoring und Steuerung von KPIs und Services (SOA Governance)
Vorgehensmodell bei der SOA-Einführung
1. Definition der Projektziele und der Vorgehensweise Initialer Startpunkt für eine SOA-Analyse ist der SOA Discovery Workshop. In diesem Rahmen identifizieren Unternehmen die richtigen Geschäftsinitiativen für den SOA-Einstieg.
Warum ein SOA Discovery Workshop?
Um den beteiligten Projektmitgliedern einen schnellen Einstieg ohne Risiko und ohne hohe Kosten zu ermögli-chen. Darüber hinaus wird so vermieden, dass die Diskus-sion über eine zukünftige SOA nicht bei Null beginnt.
Der fachliche Einstieg in ein SOA-Projekt sollte mit der Identifizierung von Prozessen beginnen, die in Services umgewandelt werden können. Die Aufwertung bestehen-der Prozesse durch neue Services hat hier eindeutig Priori-tät vor dem radikalen Vorgehen, alte Prozesse durch neue zu ersetzen. Dies erfordert jedoch ein Umdenken in der
Projektdefinition und im Projektmanagement, sowie eine spezielle Vorgehensweise, die die Wiederverwendung von bestehenden Prozessen favorisiert. Als vorteilhaft hat sich folgendes Konzept erwiesen:
Aufteilung eines großen SOA-Projekts in überschau-bare Unterprojekte, die jeweils ihren eigenen Wert-schöpfungsbeitrag zum Geschäft leisten und die Basis für weitere SOA-Unterprojekte bilden
Erarbeitung der Zielarchitektur gemäß den Geschäfts-zielen und in der Koexistenz der alten und neuen Infrastruktur
Validierung der Zielarchitektur und des Migrations-prozesses durch die schnelle Realisierung eines Proto-typs, welcher die Hauptkomponenten des zukünftigen Systems bereits abbildet. Jede Hauptkomponente besitzt im Prototyp eine begrenzte Funktionalität, ist aber mittels standardisierter Kommunikation kompa-tibel mit den anderen Hauptkomponenten.
Schrittweise Erweiterung des Prototyps durch Hinzu-fügen von definierten Funktionalitäten
Grundsätzlich sollte die Planung eines SOA-Prototyps nur wenige Services beinhalten, um die Komplexität und das Risiko des Projektes nicht zu erhöhen.
2. Bestimmung der geeigneten Technologien Bei diesem Schritt wird auf die Wiederverwendung von bestehenden Technologien („asset reuse“) besonde-rer Wert gelegt. Es sollen so viele bereits existierende
Komponenten wie nur möglich und sinnvoll verwendet werden. Klassische Beispiele sind Server, Datenbanken, Application Server sowie vorhandene Web Services und Protokolle. Müssen Anwendungskomponenten über Web Services und Protokolle vielfältig miteinander kommuni-zieren, empfiehlt sich der Einsatz eines Enterprise Service Bus (ESB).
3. Gezieltes SOA-Know-how aufbauen – beteiligte Gremien und Rollen im SOA-Team
Ein SOA-Projektteam sollte idealerweise so besetzt sein, dass möglichst viele Business- und IT-Infrastruktur-Berei-che abgedeckt werden. In den klassisIT-Infrastruktur-Berei-chen Design-Rollen sind Software-Architekten tätig, zu den „Disziplinen“
zählen Enterprise-Architektur, Informationsarchitektur und Anwendungsintegrationsarchitektur. Der Enterprise-Architekt kombiniert geschäftliche Anforderungen zu Services und setzt diese in Dienste um. Der Informations-Architekt konzentriert sich auf die richtige Einbindung von Daten, Datenstrukturen und Metadaten in die zu erstellenden Dienste. Der Anwendungsintegrationsarchi-tekt ist für die Kommunikation der Dienste untereinander, die technische (Wieder-)Verwendbarkeit von Diensten und die Konformität einer SOA Registry bzw. eines Reposi-tory verantwortlich.
Ein ausgesprochener Zusammenhang der Services untereinander ist für den Softwareentwickler zunächst nicht erkennbar. Er muss wissen, was die jeweiligen Ser-vices leisten sollen, mit wem diese kommunizieren und
Qualifizierte
Workshop-Dauer: 1 – 2 Tage
Grobplan für die Vorgehensweise für die Initiativen und Bestimmung
Abbildung 5: SOA Discovery Workshop – Vorgehensweise
welche SLAs der jeweilige Service erfüllen soll. Aufgrund der vielfältigen Spezialisierungen ist die Teamzusam-menstellung für SOA-Projekte besonders wichtig. Das Projektteam sollte idealerweise aus einer Kombination von IT-fokussierten Rollen wie Entwicklern, Software-Architekten, Projektleitern und businessbezogene Rollen wie Business-Analysten (für die Geschäftsprozess-Model-lierung), Quality-Assurance-Analysten bzw. KPI-Analysten bestehen. Speziell bei der Entwicklung von Services arbeiten Business-Analysten Hand in Hand mit den SOA-Entwicklern („Integration Developer“), die die Geschäfts-prozesse in eine Modellsprache (z. B. BPEL) umsetzen und die Integration bzw. Abläufe der Prozesse in der Prozess-Engine festlegen. In einer SOA werden Dienste und Abläufe flexibel gestaltet. Der Business-Analyst und die SOA-Entwickler haben dabei die Möglichkeit, die Dienste und Abläufe zu simulieren und je nach Anforderung bzw.
Ablauf flexibel zusammenzustellen, um die Qualität der Serviceabläufe bereits in der Integrationsphase zu ver-bessern. Das primäre Ziel sollte in jedem Fall die multiple Wiederverwendung der Services sein.
Wie bereits dargestellt erfordern SOA-Projekte ein breites IT-Wissen in vielen Disziplinen. Neben den klassischen Fachabteilungen müssen insbesondere die vielen IT-Bereiche einbezogen werden. Spezialisten zu Themen wie Portale, Identity/Access Management, Datenintegration/
Datenversorgung und Service Monitoring sind in Projek-ten nach dem Bottom-up-Ansatz inProjek-tensiv beteiligt.
4. Sukzessive Annäherung an die Ziel-Architektur Der am Bottom-up-Modell orientierte Ansatz fordert die Definition und Erstellung von Service-Komponenten bzw.
die sukzessive Erweiterung vorhandener Servicekompo-nenten. Diese Entwicklung bzw. Erweiterung wird aus der IT-Perspektive unter der Berücksichtung der Businessan-forderungen heraus getrieben.
5. Projekt-Governance
Während aller Phasen eines Projektes stellt das SOA-Governance-Team die Abstimmung zwischen den
Projekten und die Einhaltung der in der Planungsphase definierten Standards sicher.
6. Aufbau einer Service Registry und eines Service Repository
Das Service Repository und die Registry sind sehr wichtige Elemente einer SOA.
Das Metadaten-Repository, das das leistungsfähige Framework und die Erweiterbarkeit aufweist, um den individuellen Anforderungen des unterschiedlichen Serviceeinsatzes gerecht zu werden, sollte möglichst früh in einem Projekt aufgesetzt werden.
Das Business Services Repository speichert Metadaten, die zur Erstellung von Business-Services in SOA-Systemen verwendet werden. Die Metadaten beschreiben die Servi-ces, Richtlinien und Beziehungen untereinander sowie die Berechtigungen für Abonnenten. In der Service Registry sind die Process-Services hinterlegt, die Informationen zu den Services enthalten (z. B. zur Serviceschnittstelle, zu deren Prozessen und zu deren Parametern).
Es ist wichtig, in der Service Registry und Repository alle Bereiche einer SOA abzudecken. Dazu gehören Prozess-beschreibungen, Policies, Business-Rules und die Services selbst. Um eine volle Transparenz zu erhalten, muss beschrieben werden, wie die verschiedenen Artefakte einer SOA zusammenhängen. Des Weiteren empfiehlt sich im Rahmen der SOA Governance die Einführung eines Service-Informations-Management (SIM).
Ein Service-Informations-Management ist ein mit Meta-daten angereichertes Informationssystem, welches die Strukturen, Abhängigkeiten und Definitionen von Services aus fachlicher und technischer Sicht zentral zusammen-fasst und modellgestützt für eine erfolgreiche SOA Governance darstellt.
7. SOA Governance und Business Activity Monitoring einführen
Die Abschnitte 3.6 und 5.2 zum Thema SOA Governance beschreibt das entsprechende Vorgehen.
Fazit
Es gibt verschiedene Wege und Szenarien zur Einfüh-rung einer SOA.
In der Praxis hat es sich bewährt, zunächst einige wenige Use Cases (Funktionen) zu verwirklichen und die Gesamtinfrastruktur aufzusetzen
SOA Governance ist eine Projektaufgabe mit höchster Priorität – es muss eine Verbindung zwischen wie-derverwendbaren Services und wiewie-derverwendbaren Fachfunktionen bestehen.
Das notwendige Know-how zur Einführung einer SOA lässt sich gut im Rahmen eines Prototyps sammeln.
SOA-Entwickler müssen sich darauf konzentrieren bestehende Services gezielt wiederzuverwenden.
Die Innovationszyklen müssen auf Anwendungs- und Infrastrukturebene zusammenpassen.
Selbst in SOA-Einstiegsprojekten werden auf der Busi-ness- und der IT-Seite mehrere Rollen und Spezialfä-higkeiten benötigt.