Projekt SOA - Mit der richtigen Strategie zum Erfolg

Alleine über die Investition in die neuesten IT-Systeme können Unternehmen heute keinen Wettbewerbsvorteil mehr erzielen. Ein Blick auf die informationstechnische Situation in Unternehmen bestätigt diese Annahme. Dort findet man noch sehr oft isolierte Informationssilos, kaum noch wartbare Legacy-Systeme und untereinander nicht kompatible Anwendungen. Um eine durchgängige IT-Unterstützung für alle Unternehmensprozesse zu erreichen, ist zunächst eine gemeinsame Technologie notwendig sowie ein Verständnis der Anwendungen untereinander, das über die Unternehmensgrenzen hinweg Gültigkeit haben muss. Die Lösung hierfür bietet eine serviceorientierte Architektur (SOA), mit deren Hilfe sich Geschäftsprozesse technisch verpacken lassen.

Wer glaubt, die Implementierung einer serviceorientierten Architektur ausschließlich über neueste Technologien und hochqualifizierte Informatiker realisieren zu können, geht das Thema von der falschen Seite her an. SOA erfordert einen ganzheitlichen Ansatz, denn die zentrale Frage lautet: Wie lassen sich vorhandene IT-Systeme und Daten einsetzen, um bestehende Geschäftsprozesse zu optimieren und neue zu unterstützen? Weiterhin müssen Fachabteilungen unternehmensweit zusammenarbeiten, um ganzheitliche Geschäftsprozesse zu realisieren.

Grundlagen schaffen

Am Anfang eines SOA-Lebenszyklus versuchen die IT-Verantwortlichen in Zusammenarbeit mit den Fachabteilungen an ausgewählten Geschäftsabläufen aufzuzeigen, wie Prozesse effizienter ablaufen könnten. Hierbei identifiziert das Projektteam zunächst innerhalb des Unternehmens die wichtigsten zentral nutzbaren fachlichen Funktionen und legt gemeinsam mit dem Management die Projektziele fest. Daraus lassen sich weitere Argumente ableiten, wie eine SOA künftige Veränderungen im Unternehmen flexibel unterstützt. Denn wie bei jedem größeren Vorhaben gilt auch bei einer SOA-Einführung: Das Management muss hinter dem Projekt stehen.

Nachdem die Verantwortlichen erste Prozesse für SOA identifiziert haben, geht es um die Ermittlung konkreter Services, die sich für SOA-basierende Lösungen eignen. Für ausgewählte Geschäftsprozesse wird erarbeitet, aus welchen fachlichen Funktionen sie zusammengesetzt sind. Ein Business Service ist also so zu definieren, dass dieser alle Funktionen eines in sich abgeschlossenen Prozessschrittes unterstützt. In dieser Phase sollte sich das SOA-Team nicht nur auf die Architektur und die darunter liegende Technologie konzentrieren. Weitaus wichtiger ist zunächst zu evaluieren, welche Funktionen tatsächlich im Unternehmen benötigt werden. ROI-Berechnungen fallen leichter, wenn der Bedarf bekannt ist und sich der konkrete Nutzen aufzeigen lässt.

Aus IT-Systemen entstehen Services

Ein zentraler Geschäftsprozess wird meist über mehrere bestehende Anwendungen und Systeme verteilt sein. Daher ist es wichtig, im Unternehmen eine einheitliche Schnittstellentechnologie einzuführen, die von allen Systemen nutzbar ist. Ideal ist die Verwendung von Web Services, da ausschließlich offene und herstellerneutrale Standards wie XML zum Einsatz kommen. Nur über eine vereinheitlichte Schnittstellentechnologie ist es möglich, dass sich Services in unterschiedlichen Szenarien wiederverwenden lassen, wie es der SOA-Idee entspricht.

Für die Anbindung von Bestandssystemen, die beispielsweise auf Mainframes laufen, gibt es verschiedene Ansätze: Grundsätzlich wird zwischen dem direkten Zugriff auf die Daten und dem indirekten Zugriff über die entsprechenden Anwendungsfunktionen unterschieden. Im SOA-Kontext wird der zweite Ansatz oft bevorzugt, weil sich für die Erstellung der Services die bereits vorhandene Geschäftslogik und die Integritätsregeln verwenden lassen. Diese Wiederverwendung existierender Programme birgt den größten Nutzen und zugleich das geringste Risiko.

Um Bestandssystemen die aktive Nutzung von Services der SOA-Plattform zu ermöglichen, benötigen Unternehmen Werkzeuge zur Verbindung von Legacy-Applikationen mit Web Services. Hierfür ist eine Integrationslösung notwendig, die auch den bidirektionalen Datenaustausch unterstützt. Bei der Integration von Mainframe-Anwendungen sind unter Umständen unterschiedliche Security-Systeme zu verbinden. Ziel muss es sein, ein Single-Sign-On für den Anwender zu erreichen. Auch Transaktionen, die über mehrere Systeme laufen, müssen sicher implementiert werden können. Das Ergebnis der zuvor beschriebenen Schritte ist eine Vielzahl fein granularer Komponenten. Die nächste Phase im Lebenszyklus besteht nun darin, die tatsächlich benötigten Services mit Hilfe einer Kompositions- und Orchestrierungsschicht zusammenzufügen.

Enterprise Service Bus steuert die Komponenten

Alle IT-Funktionen, die ein Mitarbeiter für einen fachlichen Ablauf nutzt, soll dieser als Service über die SOA-Plattform erhalten. Über einen Enterprise Service Bus (ESB) lassen sich technische Services zu einem neuen Business Service komponieren - beispielsweise damit der Anwender nicht mehr auf verschiedene Bestandssysteme oder Bildschirmmasken zugreifen muss, sondern nur das Ergebnis seiner Anfrage präsentiert bekommt.

Wie viele Komponenten innerhalb eines Geschäftsprozesses über einen Enterprise Service Bus zu einem fachlichen Service zusammengefasst werden, bestimmt deren Granularität. Die Auswahl der Granularität ist Erfahrungssache - es gibt kein festes Maß, jedoch zwei Randbedingungen, die als Hilfestellung dienen können. Sind die Antwortzeiten einer auf SOA-Komponenten basierenden Anwendung gut, die Wiederverwendbarkeit der Komponenten aber stark eingeschränkt, dann sind die Services zu grob granular. Sind auf der anderen Seite die Services gut wiederverwendbar, stimmt die Performance aber nicht mehr, dann ist das System zu fein granular entworfen. Unterstützung für das Feintuning finden Unternehmen bei Beratern oder Herstellern, die Erfahrung mit der Umsetzung von SOA-Projekten haben.

Ein weiterer wichtiger Aspekt sind die Abhängigkeiten der Services untereinander. Idealerweise arbeiten einzelne Services weitgehend unabhängig voneinander. Sind die Querverbindungen zwischen den Services zu stark ausgeprägt, wird die Wiederverwendbarkeit in anderen Systemen eingeschränkt. Solche Querverbindungen zu vermeiden, ist oft aufwändig und verlängert die Fertigstellung des ersten SOA-Projektes. Die Anfangsinvestition lohnt sich aber, da Änderungen und Anpassungen von Services immer wieder vorkommen werden und möglichst einfaches Change Management zu den Hauptmotivationen für SOA-Projekte gehört.

SOA sicher beherrschen

Meist sehr rasch kommen Unternehmen auch bei übersichtlichen SOA-Projekten an einen Punkt, an dem sich die implementierten Services nicht mehr manuell verwalten lassen. In dieser Phase sind Management und Governance gefragt: Jetzt müssen Unternehmen evaluieren, welche Auswirkungen der Ausfall eines Dienstes auf das laufende Geschäft hat und ob Anwender und Partner die erforderliche Berechtigung haben, um auf einen Service zuzugreifen. Auch die Servicequalität und die Antwortzeiten von Diensten sind zu überwachen. Um eine bestehende SOA-Landschaft am Laufen zu halten, sind also eine Vielzahl von Regeln und Abläufen festzulegen und einzuhalten.

Die entsprechenden Werkzeuge hierfür sind in SOA-Registries und Repositories enthalten. Ein Repository erfasst sämtliche SOA-Komponenten, speichert Prozesse, Regeln, Service Level Agreements, Verfügbarkeiten, Zugriffsrechte und weitere Details der Infrastruktur. Erst mit Hilfe dieser Management-Infrastruktur sind Organisationen in der Lage, den SOA-Lebenszyklus sicher zu beherrschen.

Fazit

Bei der praktischen Umsetzung von SOA sollten IT-Verantwortliche auf Lösungen setzen, die offene und herstellerneutrale Standards unterstützen. Große Einführungsprojekte nach dem Wasserfall-Modell sind zu vermeiden: Wer klein startet und mit Iterationen arbeitet, trägt zur Risikominimierung bei. Auch wird in der Praxis die Frage nach dem Management von SOA-Infrastrukturen gerne verdrängt: Wer sich erst damit beschäftigt, wenn die Komplexität nicht mehr zu beherrschen ist, wird mit Folgekosten bestraft.

Dr. Christoph F. Strnadl, Chief IT Architect Software AG Österreich

---

Nutzen einer SOA berechnen

Organisationen auf der ganzen Welt wollen mit einer serviceorientierten Architektur (SOA), ihre IT stärker an den Geschäftszielen ausrichten. Aber woher wissen Sie, ob SOA der richtige Ansatz für Ihre Organisation ist?

Mit dem SOA Value Assessment können SOA-Architekten und Business-Analysten die Vorteile einer SOA in Zahlen ermitteln: als Kostenreduzierung, Gewinnsteigerung und Zeiteinsparungen. Das Ergebnis des SOA Value Assessments ist ein detaillierter Bericht, der den möglichen Nutzen einer SOA auf betriebswirtschaftlicher Ebene darstellt. Für CIOs ist dieser Bericht eine nützliche Hilfe, um der Management-Ebene die Vorteile einer SOA zu vermitteln.

Das SOA Value Assessment liefert konkrete Entscheidungshilfen, in welchen Bereichen sich weitere Investitionen in die IT rentieren. Dies können Hinweise darüber sein, wie sich die Anwenderproduktivität steigern lässt oder wie das Unternehmen die Prozess-Effizienz verbessert. Auch gibt die Methode Auskunft darüber, an welchen Punkten IT-Verantwortliche die bestehende IT-Infrastruktur weiter verbessern sollten.

Weitere Details sind im Internet abrufbar unter: www.soavalueassessment.de