Alle paar Jahre kommt in der IT-Industrie das nächste große Ding. Normalerweise eine Technologie, die eine Lösung für dringende Probleme liefert, oder einfach ihrer Zeit voraus ist, wie wir es mit XML beobachten konnten. Wie auch immer diese besagte neue Technologie positioniert ist, es dauert oft Jahre und erfordert viel Geduld, bis sie vollständig in der Industrie akkzeptiert wird. Ein Beispiel dafür ist die Open Source-Welle der letzten Jahre.

Momentan ist SOA, die Service-orientierte Architektur, das große Ding. Nach Jahren der Definitionsfindung scheint endlich der Zeitpunkt gekommen, eine SOA implementieren zu können. Und der Zeitpunkt könne nicht besser sein. Unternehmen suchen bereits seit geraumer Zeit nach Möglichkeiten zur Optimierung ihrer Geschäftsprozesse im Hinblick auf die Integration mit IT-Dienstleistungen und -Architekturen. Die wichtigsten Ziele sind hier natürlich Senkung der Kosten und Erhöhung der Flexibilität.

Da SOA auf offenen Standards und Technologien basiert, hilft SOA effektiv, die IT reaktionsfähiger zu machen, indem echte Geschäftsanforderungen und funktionale Aspekte, wie Wiederverwendbarkeit von Code, Vereinfachung der Verwaltung und Entwicklung, sowie Agilität direkt miteinander verknüpft werden.

Warum brauchen Unternehmen SOA?

Ein großes Unternehmen, evtl. mit Niederlassungen und Partnern im Ausland, hat 20 verschiedene Anwendungen, die alle irgendwelche Steuerberechnungsfunktionen benötigen. Dazu kommt, daß jede Applikation den Code dafür im Bauch hat, jedesmal unterschiedlich realisiert, troztdem bringen sie die gleichen Ergebnisse.

Diese Art der Softwareverteilung läßt sich in vielen Bereichen beobachten. So verwenden viele Firmen innerhalb des Unternehmens unterschiedliche Buchhaltungsprogramme und ERP-Systeme. Nachdem viele Jahre in die Dezentralisierung, aber nur selten in eine gute, ausbaufähige, zukunftssichere IT-Architektur investiert wurde, erkennen Unternehmen nun, daß sie ihren Ansatz neu modellieren müssen, bevor neue Projekte realisiert werden können, die in eine SOA passen.

Neben technischen existieren eine ganze Reihe von disziplinarischen Herausforderungen, denn eine neue Organisationsstruktur muß etabliert werden, um die Innovationen in der Informationstechnologie voll ausschöpfen und in ein Geschäftsmodell integrieren zu können. Besonders in Umfeldern, deren Richtungen und Schwerpunkte sich häufig verändern, ist die Einführung auf Diensten ausgerichteten Architektur sehr attraktiv.

Die beschriebenen Probleme und Herausforderungen haben einiges gemeinsam:

• Es geht um die Integration heterogener IT-Systeme.
• Die Anforderungen an die Prozessintegration steigen rapide.
• Der nahtlose Informationsfluß wird immer wichtiger.

Mitarbeiter, Partner, Prozesse, Channels und Anwendungen miteinander zu verbinden um einen integrierte und konsistenten Zugang zu Geschäftsfeldern zu eröffnen und dazu noch die Kosten zu senken ist das Ziel eines jeden Unternehmens. Zur Erreichung ihrer Ziele, etablieren sie die Grundlagen einer SOA, indem sie:

1. Aufbau einer mehrfach nutzbaren (shared) IT-Infrastruktur zur Eliminierung redundater Dienste.
2. Einführung mehrfach nutzbarer unternehmensweiter Plattformen als Fundament für Interoperabilität und verteilte Applikationen.
3. Entwicklung autonomer, wiederverwendbarer Dienste, um beispielsweise Bereitstellungskosten für Kunden, Mitarbeiter und Partner zu senken.

Eine SOA bietet seinen Nutzern einen Satz definierter Dienste, die sie nutzen und in Geschäftsprozesse integrieren können, ganz wie sie sie benötigen. Sie entwickeln Systeme, die sich den geschäftlichen Veränderungen anpassen können.

Das beste an einer SOA ist, daß die Idee dahinter nicht neu oder gar radikal ist. Die schlummerte bereits seit langer Zeit in IT-Umgebungen, jedoch meist als propreitäre, untereinander inkompatible Variationen. Mit der Schaffung von Schlüsselstandards, insbesondere im Bereich der Web Services, wird die Einführung einer allgemein gültigen Service-Orientierten Architektur leichter als je zuvor, denn nun können Systeme und Komponenten miteinander kommunizieren, ohne sich zu kennen oder gar von der Existenz des anderen zu wissen. Dieser standardisierte Ansatz zur Service-Architektur hat das Potenzial, bestehende technische und geschäftliche Probleme zu lösen.

Letztendlich soll SOA die Führungsebene der Business- und IT-Abteilungen von eine unflexiblen, inkompatiblen und oft teuren, Ansammlung von IT-Systemen befreien, die viele Unternehmen im Laufe der Zeit angeschafft haben. Die Probleme und Kosten, solche Legacy-Systeme miteinander zu verbinden und dazu noch so zu verändern, daß sie mit aktuellen Veränderungen Schritt halten können, überfordert die meisten Budgets und verhindert Innovationen.

Das Ziel ist ein Abbau der Interoperabilitätsprobleme, indem monolithische und statische Systeme durch modulare und flexible Komponenten ersetzt werden, so daß sich die IT auf die Unterstützung des operativen Geschäfts konzentrieren kann, anstatt Geld und Zeit dafür afzubringen, die antiquierten System und Strukturen immer wieder nachzuziehen.

Im weiteren Verlauf des Artikels sind folgende Definitionen hilfreich:

Service (Dienst)

Ein eigenständiger, wiederholbarer Geschäftsablauf, wie beispielsweise die Berechnung von Steuern, Prüfung der Kreditwürdigkeit eine Kunden, oder die Eröffnung eines Kontos

Service-Orientierung

Integration eines Geschäftsprozesses in eine Kette wiederverwendbarer Dienste. Die Ausgabe, quasi das Ergebnis, dieser Kette ist Teil der Service-Orientierung

Service-orientierte Architektur

Eine IT-Architektur, die eine Service-Orientierung ermöglicht und z.T. implementiert.

Composite Applications

Integrierte Dienste zu Abwicklung von Geschäftsprozessen über unterschiedliche Anwendungen hinweg, die jeweils auf SOA-Prinzipien basieren.

Folgende Abbildung illustriert den Übergang von einer Säulenarchitektur hin zu einem Service-orientierten Modell:

In diesem Kontext werden Applikationen als Dienste betrachet und auch so verwaltet. Zusammen mit Web Services und anderen Anbindungen, ergibt diese Anwendungen Verbindungen, die den Bedürfnissen von Geschäftsprozessen entsprechen. Das Ziel ist die Eliminierung von Rundanzen, sowohl was die intern entwickelten Lösungen als auch die von Drittanbietern bezogenen betrifft, und die Bereitstellung von allgemeingültigen Geschäftsaufgaben (wie biespielsweise Steuerberechnungen). Das Ergebnis ist eine einfachere IT-Umgebung bestehend aus wiederverwendbaren Komponenten, die logisch miteinander verbunden werden können, um einen bestimmten Geschäftsprozess zu implementieren. Ein wichtiger Vorteil ist die Fähigkeit, schneller auf Markbewegungen reagieren und Probleme mit geringerem finanziellen Aufwand bewältigen zu können.

In einer Service-orientierten Struktur sind Applikationen und Geschäftsprozesse Teil einer Ansammlung von standardbasierten Komponenten (oder “Diensten”). Jeder von ihnen verrichtet eine diskrete Funktion. Die eigenständigen Prozesse sind locker gekoppelt (engl. loosely coupled) und so entworfen, daß sie beispielsweise ereignis- oder nachrichtenbezogen funktionieren und nicht mehr über festgeschriebene Funktionen betrieben werden. Die Dienste selbst sind können natürlich neu geschaffen werden oder durch Wrapper in existierende Geschäftsabläufe integriert werden, so daß ihre Funktionen mittels standardisierter Schnitttellen zugänglich gemacht werden.

SOA baut auf den Prinzipien modularer Entwicklung, wie wir es von modernen Fertigungen kennen. Denken sie dabei an die Autoindustrie. Hier wird ein Auto aus einem modularen Satz von Komponenten zusammengesetzt. Das gleiche gilt für die Computerindustrie. Wird ein Produkt (oder auch ein Geschäftsprozess modularisiert), sind Teile des Designkerns eigenständig und können beliebig neu integriert werden, solange eine formale Architektur oder ein formaler Plan berücksichtigt wird.

Aus Sicht eines Ingenieurs hat die Modularisierung eines Designs drei Ziele:

• Gewadmet für zukünftige Veränderungen zu sein
• Die Integration komplexer Systeme verwaltbar zu machen
• Parallele Evolution, Innovation und Verarbeitung zu ermöglichen

Modularisierung führt aber auch zu gewissen Unsicherheiten, denn Elemente der Architektur können sich ändern, um unvorhergesehenen Anforderungsänderungen gerecht zu werden. Dabei dürfen die Richtlinien der Architektur nicht außer Acht gelassen werden. So kann aber sichergestellt werden, daß eine alte Komponente gegen eine neue ohne großen Aufwand ausgetauscht werden kann.

Etablierung, Einführung und Verwaltung einer SOA

Wie wir aus den vorangegangenen Ausführungen erkennen können, bedarf die Einführung einer SOA mehr als zu Technologie. Sie bedarf einer systematischen Planung und ein starkes Management. Einfach nur Komponenten auf Web Services umzustellen ergibt noch lange keine SOA, obwohl sie ein wichtigen Teil der Implementierung darstellen. Ebenso ist SOA nur der Anfang, unterliegt ständigen Anpassungen und benötigt viel Zeit um erfolgreich eingeführt und in die existieren Unternehmensphilosophie zu werden. Desweiteren werden Tools und Prozesse und, sehr viel wichtiger, oranisatorische Umformungen der Geschäftsabteilungen und der IT benötigt. Für die meisten Unternehmen ist eine Stufenausbau die beste Lösung, da sie schnell Fortschritte messen können und gegebenenfalls früh auf Probleme bei der Implementierung reagieren können.

Einige Hersteller von SOA-Produkten verfolgen eine Strategie, die als “Rip and Replace” (dt. “rausreissen und ersetzen”) bezeichnet wird. Teil der Strategie ist die Identifizierung potentieller Vorteile einer SOA und die anschließende Implementierung einer Gesamtlösung. Damit würden Kunden durch eine schnelle Konsolidierung ihrer Dienste innerhalb des Unternehmens früh die Vorzüge einer SOA kennenlernen und davon profitieren.

Ein gewisser Grad and Konsolidierung spart sicherlich Kosten, jedoch sollte die Integration von Systemen, die Ausarbeitung neuer Dienste und die Errichtung von Composite-Applikationen nicht in einem Schritt vorgenommen werden. Eine so weitreichende Umstrukturieren des Unternehmens ist mit relativ hohem technischen und politischem Risiko verbunden.

Wenn es um die Einführung einer SOA geht, so sollte nicht alles auf einmal gemacht werden. Das wäre so, als würde man in seinem Haus saämtliche Rohre und Leitungen austauschen und während dessen weiter darin leben wollen. Das Leben würde sehr schnell ziemlich kompliziert werden und Küche, Bad und WC könnten nicht richtig verwendet werden solange nicht alles fertig ist. Keine wünschenswerte Situation.

Ein schrittweiser Ansatz ist viel leichter verwaltbar und führt zu kleinen aber unmittelbar spührbaren Ergebnissen. Ein Unternehmen SOA-fähig zu machen ist ein Langzeitvorhaben und wird von den Geschäftsanforderungen angetrieben, nicht von architektonischen Aspekten.

Eine mehrschichtige Herangehensweise vereinfacht den Wechsel, denn Unternehmen können inkrementelle Veränderungen beim Ausbau zu einer ganzheitlichen Lösung vornehmen. Geschäftsmetriken bestimmen letztendlich die Geschwindigkeit des Umstellungsprozesses. Dabei können die Metriken helfe, Bereiche zu identifizieren, die mehr Aufmerksamkeit benötigen und solche die vielleicht unverhältnismäßig stark berücksichigt werden. Gleichzeitig minimiert sich das Risiko und erhöht sich das ROI.

In der Regel basiert eine mehrstufige SOA-Einführung aus mehreren, aber nicht mehr als drei, Phasen.

Phase 1: Analyse

Es gilt zunächst jene Geschäftsbereiche zu identifizieren, die am nötigsten angepaßt werden müssen, aber gleichzeitig den größen Nutzen für das Unternehmen bergen. Dabei wird festgestellt, welche Anwendungen nicht richtig funktionieren und welche Geschäftsfelder es wert sind in sie zu investieren. Sobald die Erkenntnisse gewonnen und priorisiert wurden, können Modelle erstellt werden, ganz ähnlich wie bei der Renovierung eines Hauses. Ein wichtiger Punkt für das Design des Modells ist die Frage, wie viel eines bestimmten Bereichs umgebaut werden soll. Wir können ein Projekt umstellen, eine paar Abteilungen oder das gesamte Unternehmen.

Die auszuarbeitenden Pläne müssen berücksichtigen, daß der umzuformende Teil und andere periphäre Teile des Unternehmens während der Remodellierungsphase weiter arbeiten müssen. Für Führungskräfte bedeutet das, sie müssen Regeln, Auflagen, Managementpläne und andere Bestimmungen, so daß die beteiligten Personen, Abteilungen und Prozesse entsprechend geführt und koordiniert werden können. Desweiteren reduzieren sie das Risiko, die Kosten und den Aufwand kanz erheblich, denn selbst wenn ein Teilproblem auftritt, wird nicht der gesamte Prozess aufgehalten.

Phase 2: Rationalisierung

In der nächsten und längsten Phase werden die existierenden Strukturen überprüft und überarbeitet um sie auf die SOA-Umstellung vorzubereiten. Alle Änderungen, die an bestehenden Systemen gemacht werden müssen, sind in dieser Phase vorzunehmen. Dienste und Software werden entwickelt, implementiert und getestet. Anschließend wird ein Sicherheitskonzept auf die Komponenten übertragen. Gleichermaßen müssen die beteiligten Personen, Prozesse und Abteilungen in das Sicherheitskonzept einbezogen werden.

Phase 3: Transformation

Die letzte Phase besteht aus der Verwaltung und Wartung unseres neuen Gebäudes. Es wird nun kontinuierlich durch ein effektives System gestützt und verwaltet. Hochqualifizierte Mitarbeiter und detailliert ausgearbeitete Prozesse erlauben ständige Anpassungen der Geschäftsmodelle innerhalb der SOA. Der Erfolg einer SOA-Implementierung ist gekennzeichnet von der Fähigkeit, Geschäftsprozesse einfach zu implementieren, aber dennoch maximale Wirkung im Hinblick auf Agilität, Leistungsfähigkeit und Risikominimierung zu entfalten.

Ein solches Leitungs- und Entwicklungsmodell liefert die besten Ergebnisse mit den geringsten Beeinträchtigungen für das operative Geschäft.

Während des 3-Phasenprozesses ist es sehr hilfreich, Methoden zu entwickeln, die den Fortschritt über alle Abteilungen und Organisationsstrukturen des Unternehmens hinweg visualisieren. Ein Anwendungsbereich kann sich recht früh in der SOA-Landschaft positionieren, seine volle Wirkung kann er jedoch erst entfalten, wenn mehrere Domänen von diesem Gebrauch machen. Erinnern wir uns an das Beispiel mit der Berechnung von Steuern. Zuvor gab es eine Reihe von Modulen, die alle das gleiche getan haben, jetzt können alle das gleiche Modul (nach SOA-Manier als “Dienst” bezeichnet) nutzen, was eine deutliche Reduzierung des Verwaltungsaufwands bedeutet und gleiche Ergebnisse in allen Anwendungsdomänen liefert.

Eine SOA zu errichten, erfordert ein Verständnis der Verbindungen zwischen den Schlüsseldimensionen der Unternehmensstrategie, der Prozesse, der Anwendungen und der Infrastruktur. Um dieses Verständnis zu erlangen, müssen Organisationen innerhalb des Unternehmens weitreichende Einblicke in die Strukturen erhalten, was bedeutet, daß Unternehmen mit geringer Transparenz wenig Chancen haben, eine SOA erfolgreich zu etablieren. Nur so ist die Akzeptanz der eingeschlagenen Strategie zu vermitteln und die Kooperation der Belegschaft zu gewinnen.

Für SOA planen

Die Evolution in eine SOA müssen Unternehmen vorrausschauend planen. Das ist typisch für jede Revision einer größeren Architektur oder eines Projekts. Die folgenden Punkte sollen helfen, die richtigen Entscheidungen bei der Planung für eine SOA zu treffen. Anschließend betrachten wir eine Roadmap zur Ausrollung der Architektur.

Das wichtigste Element bei der Einführung einer SOA ist die Führung. Es liegt in der Verantwortung eines Teams oder einer Führungspersönlichkeit folgende Aufgaben zu bewältigen:

• Auswahl geeigneter Technologien für die Architektur
• Auswahl der Projekte und Prozesse, die unbedingt angegangen und welche nicht angerührt werden sollen
• Entwicklung einer geeigneten Ausbaustrategie
• Messung des Fortschrittes und der Vorteile gegenüber des herkömmlichen Modells

Für eine höchsteffiziente Transformation, empfehle ich folgende Schritte:

Setze Führungsstrukturen ein

Stelle ein Team von Experten zusammen, die abteilungsübergreifende Einführung und Akzeptanz der SOA sicherstellen. Analysiere die Herausforderungen, die eine Entwicklung SOA von der Konzeptionierung bis zu Einführung an Prozesse, Standards und Vorgaben stellen.

Erstelle eine Roadmap

Setze Dich mit den fundamentalen Grundlagen zur Ausarbeitung einer SOA-Strategie auseinander und beginne mit der Ist-Aufnahme der Geschäftsprozesse und erstelle ein Soll-Konzept. Stelle sicher, daß alle Prozesse in allen relevanten organisatorischen Einheiten sichtbar sind. Stichwort: Transparenz.

Versichere Dich der richtigen Ausrichtung der Prozesse, Applikationen und Infrastruktur

Das Ziel ist, die vorhandenen Mittel wie Systeme, Komponenten und Strukturen optimal auszunutzen und sie in neue Strukturen zu integrieren um Kosten zu sparen.

Erstelle einen Businessfall und implementiere ihn in mehreren Phasen

Übersetze die Roadmap die gewonnen Erkenntnisse einen echten ausführbaren Businessfall. Bestimme die Vorteile, welche Du durch Wiederverwendbarkeit von Code, Komponenten, Strukturen und Systemen erreichen kannst. Berücksichtige auch die Vorteile erhöhter Agilität und Transparenz des Unternehmens.

Erstelle eine Kompatibilitäts-Framework für die Integration

Entwickle Guidelines um echte Interoperabilität im gesamten Unternehmen zu gewährleisten.

Sichere die Umgebung

Unternimm praktische Maßnahmen zur Sicherung der Umgebung. Versuche den Zugriff auf Web Services über Identitäten zu regulieren.

Faktoren für die erfolgreiche Einführung einer SOA

Vergessen wir nicht: SOA ist keine Technologie oder ein Produkt. Man sie nicht kaufen oder als Service abonnieren. SOA ist ein architektonisches Konzept, welches sich unabhängig von der Technologie ausprägt. Um eine Unternehmensarchitektur in eine SOA umzuwandeln ist eine systematisch erarbeitete Roadmap unerläßlich.

Stelle das richtige Team zusammen. Wähle die richtigen Leute aus. Unter ihnen sollten Architekten aus allen organisatorischen Einheiten sein. Wähle einen von Ihnen als SOA-Architekt aus, der die richtigen SOA-Standards und -Technologien versteht. Stelle fest, was Du nicht weiß und gehen Kooperationen mit kompetenten Partnern ein, die zum Erfolg beitragen können. Schließlich, komnunizerien, komnunizerien, komnunizerien! Veröffentliche Deine Resultat in regelmäßigen Abständen beispielsweise einmal im Monat und spare nicht mit Grafiken. Sie sagen oft mehr als Worte, besonders in weniger technischen Abteilungen.

Organisiere Erfolg durch Etablierung eines Centers of Excellence in Form einer Expertengruppe. Zentralisiere das Projektmanagement, die Planung, Release-Management und Infrastrukturdienstleistungen. Erdenke Dir ein Auslieferungsmodell, standardisiere es und mach es zum Teil der Gesamtstrategie.

Nutze das vorhandene Wissen der Organisationen und Geschäftspartner. Versuche stets, breite Unterstützung durch die Führungsebene zu erhalten und etabliere Partnerschaften mit Herstellern, die bereits Erfahrung mit SOA und ihren Tools sammeln konnten. Finde ein ausgewogenes Gleichgewicht zwischen den Visionen der Führungsebene und Deinen Visionen, die auch den technischen Aspekt einbeziehen. Konzentriere dich auf kleine Erfolge, die das Management von dem Wert der Aufgabe für das Unternehmen überzeugen.

Bleib flexibel. Entwerfe Deine Strategie nicht zu abitioniert und nicht zu weit vorausschauend. Versuche, Deine Ziele überschaubar zu machen, um leichter auf Veränderungen reagieren zu können. Ein zu hochgegriffenes Ziel kann Dir den Blick für die Details nehmen. Halte die Infrastrukturdienstleistungen leicht und modular. Designkomponenten sollten abstrakt bleiben, um Wiederverwendbarkeit zu garantieren.