Der SOA-Leitfaden umfasst acht Themenbereiche, zu denen Strategie, Governance, Architektur, Methodik und Entwicklung zählen. Die erste Erkenntnis des Teilnehmerkreises bezüglich der Architektur war, dass es für eine SOA nicht eine einzige, sondern viele Gestaltungsformen gibt - je nach Zielsetzung und Ausgangslage des Unternehmens. Insgesamt können fünf typische Lösungsmuster unterschieden werden:
Expertenforum IT-Architektur:
An den Veranstaltungen des Expertenforums nehmen unter anderem Vertreter folgender Unternehmen teil: Commerzbank, Deutsche Bank, DZ-Bank, Credit Suisse, Provinzial Rheinland Versicherung, Alte Leipziger Versicherung, R+V-Versicherung, Fiducia IT, Sparda-Bank, Deutsche Bank Bauspar, LBS IT, Julius Blum GmbH, Landesbank Hessen-Thüringen, Alice Software, Versicherungskammer Bayern, Hanse-Merkur Versicherung, WWK-Versicherung.
Kontakt: Michael.Bauer@plenum.de
Erstellung von Mehrkanal-Anwendungen: Mehrere unterschiedliche Benutzeroberflächen und -abläufe für die gleiche fachliche Funktionalität
À Modernisierung von Legacy-Anwendungen: Entkopplung der vorhandenen Verarbeitungsfunktionen und Schaffung einer neuen, prozessunterstützenden Benutzeroberfläche
à Verbundanwendungen: Abbildung von Geschäftsprozessen unter Einbeziehung von Anwendungen in unterschiedlichen Technologien (Eigenentwicklung, Kaufsoftware und externen Services)
Õ E-Business-Lösungen: Umbau von Anwendungen für unternehmensübergreifende Prozesse (B2C und B2B)
ΠMigrationsarchitektur: Schrittweiser Austausch von Legacy-Software gegen neue Anwendungsteile im Rahmen einer kontrollierten Koexistenz ("Managed Evolution")
Für diese Typen von SOA-Lösungen wurden entsprechende Referenzarchitekturen entwickelt. Da eine SOA das Ziel hat, Geschäftsprozesse zu automatisieren, bestehen künftige Anwendungen nicht nur aus den Software-Layern "Service-Consumer" und "Service-Provider", sondern auch aus dem Prozess-Layer. Diese drei Softwareschichten können wiederum unterschiedlich über die technischen Plattformen verteilt werden.
Eine SOA führt nicht zwangsläufig zu einer verteilten Verarbeitung. Werden Anwendungen neu entwickelt, so liegen Service-Consumer und -Provider in gleicher Technologie vor und laufen damit innerhalb des gleichen Application-Servers ab.
In der Praxis der meisten Unternehmen aber sind die Anwendungen in unterschiedlichen Technologien realisiert. Diese Heterogenität wird in Zukunft nicht abnehmen. Deshalb werden in dem Leitfaden auch die Lösungen für die Probleme aus verteilter Verarbeitung behandelt wie Performance, Transaktionssicherheit und Zugriffsschutz.
Wiederverwendung kostet zunächst
Das Expertenforum hat eine Grundaussage formuliert: Eine SOA ist nur sinnvoll bei einer substanziellen eigenen Softwareentwicklung. Bei der Neuentwicklung von Anwendungen führt das SOA-Konzept - von Initialaufwendungen abgesehen - nicht zu höheren Kosten. Denn Services sind lediglich eine Zusammenfassung einzelner Komponenten, etwa Enterprise Java Beans (EJBs), zu einer größeren Funktionseinheit. Durch die Bildung von Services steigt die Chance einer Mehrfachverwendung. Die Erfahrungen der Credit Suisse belegen, dass rund 40 Prozent der entwickelten Services wiederverwendet werden - und das bis zu 94-mal. Dies reduziert merklich die Entwicklungs- und Testkosten und mehr noch die Entwicklungsgeschwindigkeit und Einführungzeit ("Time to Market"). Voraussetzung ist aber ein ausreichendes Portfolio an fertigen Services.
Allerdings erzeugen Services, die wiederverwendet werden sollen, einen höheren Aufwand durch:
l saubere und verlässliche Dokumentation
l Qualitätssicherung und Zertifizierung
l Generalisierung von Interface und Funktionalität
Dieser Zusatzaufwand schwankt zwischen 20 und 300 Prozent. Deshalb ist es sinnvoll, die Generalisierung eines Services erst dann anzugehen, wenn ein konkreter Bedarf entsteht oder zumindest absehbar ist. Obwohl die Wiederverwendung die Entwicklungskosten reduziert, ist dies nach Ansicht der Teilnehmer des Expertenforums nicht das eigentliche Argument für eine SOA. Vielmehr können die kürzere "Time to Market" und die verstärkte Prozessunterstützung einem Unternehmen wesentlich mehr Nutzen bringen als ein paar Prozent eingesparte Entwicklungskosten.
Für die meisten der im Expertenforum vertretenen Firmen aber steht nicht Neuentwicklung, sondern die Modernisierung bestehender Anwendungen auf dem Plan. So hatte beispielsweise die Provinzial Rheinland ihren Versicherungsanwendungen auf dem Mainframe eine moderne, prozesssteuernde Mehrkanallösung vorgeschaltet. In einer solchen Situation entfällt ein substanzieller Anteil der Projektkosten auf den Umbau der bestehenden Programme. Da der Aufwand stark von Struktur, Qualität und Dokumentation der alten Anwendungen abhängt, schwankt er zwischen 20 und 60 Prozent der gesamten Projektkosten.
Der Umbau von Legacy-Anwendungen zu Services umfasst folgende Tätigkeiten:
l Isolierung der fachlichen Funktionalität der Programme
l Zusammenfassung mehrerer Programme zu einem Service
l Schaffung von Wrappern zur Umsetzung einer objektorientierten Sicht und XML auf klassische Programmschnittstellen
Paradox erscheint es, dass man stark modularisierte und integrierte Anwendungen zuerst zerlegen muss, um sie überhaupt integrieren zu können. Aber ausgeprägte Unterprogrammtechnik führt zu einer so intensiven Vernetzung der Module, dass erst einmal sinnvolle Funktionsgruppen mit einem eigenen Interface geschaffen werden müssen. Diese können dann von außen aufgerufen und so mit den Service-Consumern integriert werden.
Domänen als Bebauungsplan
Services, die aus älteren Anwendungen entstehen, sind meist nicht methodisch sauber. Auch eine Wiederverwendung ist kaum zu erwarten. Deshalb befassten sich die Experten des Forums mit einer systematischen Service-Entwicklung. Hierzu ist es zunächst nötig, einen Bebauungsplan in Form von Anwendungsdomänen zu schaffen. Eine Anwendungsdomäne gruppiert kohärente Datenbestände zu Kern-Entitäten wie Kunden, Verträge, Produkte, Leistungen oder Buchhaltung. So haben Unternehmen wie Fiducia oder Credit Suisse für sich 20 bis 30 solcher Domänen definiert.
Ziel ist es, überschneidungsfreie Services zu schaffen. Deshalb soll ein Service nur auf Daten innerhalb seiner Domäne zugreifen. Pflegende Services sollen sich auch innerhalb ihrer Anwendungsdomäne nicht überschneiden, während es mehrere lesende Services für gleiche Daten geben darf. Ein Service-Consumer dagegen kann in einem Prozessschritt Operationen über mehrere Domänen veranlassen, indem er mehrere Services aufruft. Allerdings entstehen dadurch Probleme mit einer übergreifenden Transaktionssicherheit. Deshalb enthält der Leitfaden Konzepte für Rücksetz- und Restart-Lösungen.
3000 bis 4000 Services nötig
Keines der Unternehmen hat bisher eine SOA auf gesamter Breite der Anwendungslandschaft umgesetzt. Aufgrund der bisherigen Erfahrungen kann man bei Vollausbau mit 3000 bis 4000 Services für ein Unternehmen rechnen. Dieser Umbauprozess wird gut und gerne zehn Jahre in Anspruch nehmen. Diese Größenordnung macht deutlich, wie wichtig die Verwaltung und Koordinierung der Services ist. Für das Management des Service-Portfolios stehen folgende Aufgaben an:
Festlegung der Anwendungsdomänen
À Richtiger Schnitt der im Rahmen von Projekten benötigten Services
à Sicherstellung einer fachlichen und technischen Beschreibung der Services
Õ Entscheidung bezüglich Weiterentwicklung und Generalisierung der Services
Da Services im Rahmen von Projekten erkannt werden, muss es eine Verzahnung zwischen Portfolio-Management und Anwendungsentwicklung geben. Diese findet bei der Service-Spezifikation und bei der Fertigstellung statt. An diesen beiden Stellen führen IT-Architekten eine Qualitätssicherung durch.
Darüber hinaus sollten die Architekten die Projekte beratend begleiten. Als Faustformel wird der Anteil der Projektunterstützung mit mindestens 25 Prozent - besser aber 50 Prozent - der Arbeitszeit der Architekten empfohlen. Auch sollten sich Aufwand und Umfang der Qualitätsprüfungen an der Bedeutung eines Services orientieren. Praktisch erprobt ist der Ansatz, zwischen internen und öffentlichen Services zu unterscheiden. Ein interner Service wird nur im Rahmen einer Anwendungsdomäne verwendet und bleibt damit innerhalb des gleichen Verantwortungsbereiches. Ein öffentlicher Service kann von allen Projekten - also domänenübergreifend - genutzt werden. Deshalb muss sichergestellt werden, dass er generalisiert genug entworfen wurde und seine Beschreibung zuverlässig ist ("Design by Contract").
Von Prozessen zu Services
Einen wesentlichen Teil des SOA-Leitfadens nehmen methodische Fragen ein. Dabei geht es sowohl um die Vorgehensweise der Service-Entdeckung als auch um das Service-Design. Der Ausgangspunkt für eine SOA ist das Prozessmodell eines neuen oder optimierten Geschäftsprozesses. Hiervon lassen sich die Anwendungsfälle ("Use Cases") ableiten. In einem Use Case wiederum können mehrere Services verwendet werden.
Ein weithin bekanntes Problem ist, wie man einen Service richtig schneidet. Da in der Analysephase zunächst in fachlichen Begriffen gedacht wird, können fachliche Services von recht unterschiedlicher Größe (Granularität) entstehen. In einem Fall ist "Zahlungsverkehr durchführen" ein Service, in einem anderen nur "Lesen Kunde über Nummer". Im SOA-Leitfaden wird empfohlen, zum Service-Design das Konzept der Anwendungsdomänen heranzuziehen. Fachliche Services werden daraufhin untersucht, ob sie nur gegen die Daten einer Domäne operieren; andernfalls werden sie weiter heruntergebrochen. Dadurch lassen sich überschneidende Services und spätere Wartungsprobleme vermeiden.
Im Rahmen der technischen Implementierung wiederum können mehrere feinkörnige fachliche Services wieder in einem Programm zusammengefasst werden. Dies gilt insbesondere für die vielen Varianten lesender Services. Die Praxis zeigt, dass es aus Performance-Gründen auch sinnvoll sein kann, für domänenübergreifende Lesefunktionen einen "Superservice" zu entwickeln.
Das Konzept, Services nach ihrer Datenverantwortung zu schneiden, hat sich als praktikabel erwiesen. Dadurch wird die flexible Komposition zu Prozessen leichter gemacht. Die Abbildung der Prozesse selbst erfolgt mittels Workflow-Definitionen, sodass die Geschäftsregeln außerhalb von Programmen vorliegen und einfacher geändert werden können. Um die Flexibilität zu wahren, müssen Services und ihre Interfaces langfristig stabil bleiben, damit die Änderungen nicht auf eine Vielzahl von Service-Consumer zurückschlagen. Deshalb ist Versionierung ein wesentliches Konzept für eine SOA.
Eine SOA benötigt Governance
Da eine SOA nicht für jedes Projekt erfunden werden kann, sondern ein unternehmensweites Paradigma ist, muss es auch verbindliche Regeln geben, über deren Einhaltung die IT-Architekten wachen sollen. Zu den Regeln und Standards gehören unter anderem Service- und Interface-Definitionen, Namenskonventionen, Nachrichtenaufbau, Qualitätsprüfungen, Entwicklungsrichtlinien und Design Pattern. Zu den weiteren Standards zählt die Infrastruktursoftware. Diese kann Integrations-Middleware, Portal-Server und Workflow-Engines umfassen.
Anwender und IT rücken zusammen
Ein besonders wichtiger Aspekt ist ein gemeinsames Gremium von IT und Auftraggebern. Ein solches "SOA-Board" soll sowohl die Projekte abstimmen als auch die Einhaltung der gemeinsam verabschiedeten Regeln kontrollieren. Damit stellt es eine Eskalationsstufe für den Fall dar, dass es Konflikte zwischen einseitigen Projektwünschen und den unternehmensweiten Anforderungen an eine SOA gibt. Hilfreich ist es weiterhin, Domänenverantwortliche zu etablieren, die die inhaltliche Gestaltung der Anwendungsdomänen und der darauf operierenden Services steuern. Dies ist eher eine fachliche als eine technische Funktion.
Der SOA-Leitfaden, der im Expertenforum von plenum entsteht, ist "noch" nicht fertig. Es handelt sich eher um ein "lebendes Dokument", das aus den Erfahrungen der Praxis weiter wächst und reift.
Michael Bauer ist Geschäftsführer der
Informatik Consulting Bauer GmbH.