Marco Loprete arbeitet als Technical Account Manager bei der Software AG in der Schweiz.

Ein Leitgedanke von serviceorientierten Architekturen (SOA) ist die Befreiung der Geschäftsprozesse von darunter liegenden Anwendungen. Das bedeutet, dass die in der Vergangenheit in einem Unternehmen entstandenen Applikationen - welche meist nur einen Teilbereich der Firma unterstützen und nicht für unternehmensweite Prozesse geeignet sind - IT-mässig neu aufgegleist werden müssen. Und zwar so, dass sie zu übergreifenden Prozessen werden und Partner sowie Kunden in die Betriebsabläufe integrieren. Zur SOA-Umsetzung ist daher ein ganzheitlicher Ansatz gefordert. Deshalb lautet die zentrale Frage an den Verantwortlichen solch eines Projektes: «Wie lassen sich vorhandene IT-Systeme und IT-Daten einsetzen, um bestehende Geschäftsprozesse zu optimieren und neue zu unterstützen?»

Am Anfang des SOA-Lebenszyklus steht die Discovery-Phase: Die IT-Verantwortlichen zeigen - gemeinsam mit den Fachabteilungen - anhand ausgewählter Geschäftsabläufe auf, wie Prozesse künftig effizienter ablaufen können.

Hierbei identifiziert das Projektteam innerhalb des Unternehmens die wichtigsten zentral nutzbaren fachlichen Funktionen und legt gemeinsam mit dem Management die Projektziele fest.

Nach dieser Initialphase geht es bei dem sogenannten SOA-Readiness-Assessment um die Ermittlung konkreter Services, die über eine SOA angeboten werden sollen. Das Projektteam stellt für ausgewählte Geschäftsprozesse zusammen, welche fachlichen Funktionen die Abläufe umfassen. Hierbei konzentriert sich das SOA-Team jedoch nicht nur auf die Architektur und die darunter liegende Technik. Weitaus wichtiger ist es, zunächst zu evaluieren, welche Funktionen das Unternehmen tatsächlich benötigt. Denn spätere ROI-Berechnungen (Return on Investment) fallen leichter, wenn der Bedarf an Einsatzmöglichkeiten bekannt ist und sich der daraus resultierende konkrete Nutzen aufzeigen lässt.

Im nächsten Schritt werden aus den IT-Systemen und Geschäftsabläufen mehrfach verwendbare Services entwickelt. Denn in aller Regel ist ein zentraler Geschäftsprozess über mehrere bestehende Anwendungen und Systeme verteilt. Daher ist es wichtig, sich auf eine einheitliche Schnittstellen-Technik zu einigen, die von allen Systemen genutzt werden kann. Ideal ist die Verwendung von Web-Services, da nur offene und Hersteller-neutrale Standards wie XML zum Einsatz kommen.

Werkzeuge zur Integration von Legacy-Systemen sollten es ermöglichen, dass die Bestandsanwendungen aktiv auf Services der SOA-Plattform zugreifen können. Hierfür ist eine Integrationslösung notwendig, die den bidirektionalen Datenaustausch unterstützt. Zudem sind bei der Mainframe-Integration unter Umständen unterschiedliche Security-Systeme zu verbinden. Das erste Ziel muss dabei immer die SSO-Einbindung (Single Sign On) des Users sein. Das Ergebnis der bisherigen Projektphasen ist eine Vielzahl feingranularer Komponenten. Als nächstes müssen diese ganzen Services mit Hilfe einer Kompositions- und Orchestrierungsschicht zusammengefügt werden.

Damit ein Mitarbeiter alle IT-Funktionen, die er für einen fachlichen Ablauf nutzt, über die SOA-Plattform erhält, komponiert der Systemarchitekt mit Hilfe eines ESB (Enterprise Service Bus) technische Services zu einer neuen, vollständigen Business Applikation. Diese sorgt dann beispielsweise dafür, dass der Anwender seine Daten nicht mehr auf verschiedenen Bestandssystemen oder Bildschirmmasken zusammensuchen muss, sondern nur das Komplett-Ergebnis seiner Anfrage präsentiert erhält.

Wie viele Komponenten sich über einen ESB zu einem fachlichen Service zusammenfassen lassen, bestimmt die Granularität. Die Auswahl der Granularität ist Erfahrungssache, es gibt kein festes Mass. Jedoch dienen zwei Randbedingungen als Hilfestellung: Sind die Antwortzeiten einer auf SOA-Komponenten basierenden Anwendung gut, die Wiederverwendbarkeit der Komponenten aber stark eingeschränkt, sind die Services zu grob-granular. Sind die Services gut wieder verwendbar, aber die Performance ist zu schwach, ist das System zu fein-granular.

Sollen die neuen Applikationen unterschiedliche Benutzerrollen und flexible Prozessschritte unterstützen, ist der Einsatz einer BPM-Software (Business Process Management) nötig. Fachabteilungen erhalten darüber Dienste, welche die geschäftliche Sicht wiedergeben. So lassen sich etwa in BPM alle Aktivitäten modellieren und automatisieren, die zum Beantworten einer Kundenanfrage nötig sind. BPM steuert und verwaltet also die Geschäftslogik und abstra-hiert die darunter liegenden Techniken. Einzelne Prozesse aus einer Fachabteilung sind so schnell in grössere, übergreifende Abläufe einbindbar. Da sich die Regeln für die Prozessabläufe getrennt von der Technik bearbeiten lassen, sind Änderungen relativ einfach umzusetzen. Haben Unternehmen mit Hilfe von BPM-Werkzeugen erste Arbeitsabläufe integriert, können sie deren Nutzen durch die Integration zusätzlicher Informationssysteme erhöhen. Auch hierbei bildet SOA die notwendige technische Basis.

Bei fortgeschrittenen SOA-Projekten kommen Firmen an einen Punkt, an dem die implementierten Services nicht mehr manuell verwaltbar sind. Dann sind Management und Governance gefragt. Jetzt muss geprüft werden, welche Auswirkungen der Ausfall eines Dienstes auf das laufende Geschäft hat. Zudem sind die Zugangsberechtigungen für die SOA-basierten Dienste genauso zu kontrollieren wie deren Servicequalität und Antwortzeiten.

Um eine bestehende SOA-Landschaft am Laufen zu halten, sind also viele Regeln und Abläufe festzulegen, einzuhalten und zu überwachen. Die notwendigen Werkzeuge hierfür sind in SOA-Registries und Repositories enthalten. Diese erfassen alle SOA-Artefakte, speichern Prozesse, Regeln, Service Level Agreements, Verfügbarkeiten, Zugriffsrechte und weitere Details der Infrastruktur. Erst mit Hilfe dieser Management-Infrastruktur sind Organisationen überhaupt in der Lage, den gesamten SOA-Lebenszyklus zu beherrschen.

In der Optimierungsphase schauen sich Unternehmen die zuvor definierten Geschäftsziele an und erarbeiten Möglichkeiten, die fachlichen Abläufe weiter zu verbessern. In der Praxis werden hier Prozessschritte neu angeordnet, weitere IT-Systeme hinzugeschaltet und die Ressourcen für einzelne Abläufe justiert. So stellen Unternehmen sicher, dass die Anwendungslandschaft dauerhaft optimiert und den aktuellen Anforderungen angepasst wird.

Soa-Masterplan

- Bei der technischen Umsetzung sollten offene und herstellerneutrale Standards unterstützt werden. Das ermöglicht eine Best-of-Breed-Strategie, so dass sich Produkte diverser Hersteller zum Aufbau einer SOA auswählen lassen.

- Grosse Einführungsprojekte nach dem «Wasserfall-Modell» sind zu vermeiden. Wer klein startet und mit Iterationen arbeitet, minimiert das Risiko

- Fragen nach dem Management von SOA-Infrastrukturen darf man nicht verdrängen. Wer sie erst stellt, wenn die Komplexität nicht mehr zu beherrschen ist, wird mit Folgekosten bestraft.

- IT-Verantwortliche sollten sich eine strukturierte Darstellung des SOA-Nutzens erarbeiten.

- Aspekte des Nutzens bei SOA-Projekten betreffen: Innovationen auf Business-Ebene, Prozesseffizienz für die Benutzerproduktivität, Umsetzung neuer IT-Projekte auf SOA-Basis.

www.soavalueassessment.de