IT-Evolution

So wird SOA was

21.09.2008
Vier typische Entwicklungsschritte charakterisieren die Serviceorientierte Architektur im Unternehmen. Viele Firmen stehen bei dieser Evolution erst am Anfang. Das muss aber nicht so bleiben.

Die Welt der Informationstechnologie bewegt sich ständig vorwärts. Viele CIOs befinden sich bei dieser Vorwärtsbewegung in einem Dilemma: Zahlreiche ihrer Altsysteme entstanden, als Programmierer die Prozessautomatisierung des Arbeitsplatzes mit jetzt längst in die Jahre gekommenen Technologien und
Werkzeugen lösten.

Heutzutage werden mehr als 80 Prozent des IT-Budgets darauf verwandt, diese geschäftskritischen Systeme zu erhalten und zu verwalten. Und – was nicht weiter verwundert: Die Kosten dafür werden in den nächsten Jahren noch steigen.

Dies lässt nicht viel finanziellen Spielraum für Neuentwicklungen zur notwendigen IT-Transformation, die die Vorteile offener Systeme, Service-orientierter Architekturen und prozessgetriebener Workflow-Systeme
konsequent ausnutzen.

Offene Standards, Internet-Computing-Modelle und die Herausforderung, SOA einführen zu müssen – oder
gar zu wollen –, ist aber die Chance, die bis dahin fest verwurzelten Systeme zu entkoppeln, die enthaltenen
Funktionen vertikaler Silos miteinander zu verbinden, als Services zu neuen Prozessketten zu verknüpfen und damit die IT neu zu positionieren.

Stillstand ist keine Option; der steigende Wettbewerbsdruck fordert äußerst agile und kosteneffektive IT-Architekturen, um das sogenannte Business Execution Gap, die immer größer werdende Schere zwischen der Forderung aus der Geschäftsstrategie nach schnellerer und flexiblerer Produkteinführung und den durch vertikale Altsysteme höheren Reaktions- und Implementierungszeiten, zu schließen.

Auf dem Sprung zu Einsparungen

Höhere Investitionen bei steigender Bindung der Mittel und wachsendem Einspardruck, Innovationsdruck bei gleichzeitigem Erhalt der Altsysteme: Ist das ein Dilemma für den CIO, dem er nicht entrinnen kann?

Ein evolutionäres Vier-Phasen-Modell zur Infrastruktur-Governance kann Abhilfe schaffen. Jede Phase des Modells zeichnet sich dadurch aus, dass sie ohne Vorgänger oder Nachfolger ablaufen kann und sich selbst amortisiert. Ein Einstieg ist in jeder Phase möglich, sofern die notwendigen Einstiegsbedingungen erfüllt sind. Eine Rückwärtsintegration ist nicht zwingend. Phasen können nur Teilbereiche des Unternehmens betreffen und in verschiedenen Organisationseinheiten parallel in verschiedenen Stufen ablaufen. Nicht jedes Unternehmen muss in der letzten Phase enden, sofern das beschriebene Geschäftsziel vorher erreicht wird.

Und so sehen die vier Phasen bis zur Einführung Service-orientierter Architekturen beispielhaft aus:

Phase I: IT-Modernisierung

In einer ersten Phase geht es um die Modernisierung der vorhandenen IT – unabhängig vom strategischen Ziel. Hard- und Software müssen für künftige Aufgaben fit gemacht werden: durch Skalierung der Systeme und Datenbanken, durch geeignete Maßnahmen, um dramatisch erhöhten Datentransfer sowie drohende Performanz- und Speicherprobleme in den Griff zu bekommen, und durch erste Schritte zur lokalen Systemintegration und zum Abbau von Redundanzen.

Erst Standards machen flexibel

Organisationen transferieren Geschäftsoperationen in flexiblere und beweglichere IT-Umgebungen; diesen Prozess nennen wir IT-Modernisierung. Bei der Transformation erhalten sie ihre bestehenden Applikationen, während sie diese in moderne Sprachen, Datenbanksysteme und SOA-Services umsetzen.

Der wichtigste Teil ist dabei der Erhalt der Geschäftsinhalte in der neuen Umgebung, speziell dann, wenn das darin enthaltene Wissen und das Wissen um die darzustellenden Funktionen außerhalb der Applikation gar nicht oder nur teilweise vorhanden sind.

Phase I beginnt mit der Aufnahme des Applikationsaltbestandes, um den Status quo des Zustandes der gegenwärtigen Systeme zu bekommen. Welche Anwendungen sind die Kandidaten für Modernisierung und welche Techniken liefern dafür den größten Ertrag?

Der nächste Schritt überprüft den besten Modernisierungsansatz, denn zum Ziel führen gleich mehrere Wege: automatisierte Migration, Rehosting, Commercial-Off-The-Shelf (COTS) Replacement – ganze Anwendungen werden ausgetauscht, SOA sorgt für Integration und Rearchitecting.

Das Migrationsziel ist, den Funktionslevel der bestehenden Systeme zu erhalten und gleichzeitig neue, flexiblere Softwareplattformen zu übernehmen. Dabei sollte die Migration automatisiert ablaufen. Die Voraussetzungen dafür sind Verständnis für das Mapping zwischen Quelle und Ziel sowie hochwertiger Source-Code, während der Ansatz des Rehosting den Code auf eine moderne unterlagerte Datenbank und Hardwareplattform migriert, dabei aber die Applikationslogik komplett unangetastet lässt. Dies wird durch eine Softwareschicht erreicht, die sich für die Applikationslogik wie die Umgebung des Altsystems darstellt, aber in Wirklichkeit auf einer Open-Systems-Plattform läuft.

Herausforderungen in Hard- und Software, gekoppelt mit Infrastrukturproblemen, machen hin und wieder sogenannte COTS-Replacements nötig. So nennt man den Austausch der kompletten Applikation gegen eine neue und modernere Version – und zwar bei mindestens gleichem Funktionsumfang.

Silo-Applikationen modernisieren

Zur vollen Ausnutzung moderner IT-Architekturen trägt das Rearchitecting der Altsysteme bei. Geschäftsrelevante Prozesse und Softwareanlagevermögen werden dafür aus Altsystemen ausgelöst. Rearchitecting ist immer dann üblich, wenn die nötigen Adaptionen von SOA-Architekturen und anderen modernen Technologiebereichen wie Business Intelligence und Business Rules Engines fundamentale Änderungen verlangen. Das Ende der Phase zeichnet sich durch einen hohen Faktor an SOA-Readiness aus, aber auch durch das Wissen um nicht zu verändernde Silo-Applikationen, die nun aber im modernisierten Zustand der Phase II zugeführt werden können.

Phase II: IT-Harmonisierung

In Phase I wurden die vorhandenen Assets, ihre Aggregatszustände und der Übergang von einem in den anderen Zustand beschrieben. Nun ist es das Ziel, die gekapselten, modernisierten Softwarebestände miteinander zu harmonisieren, zu integrieren, neu zu vernetzen und letztlich zu „SOAfizieren“. Hier geht es nicht darum, bestehende Systeme zu ersetzen, sondern darum, ihre Funktionalität aufzubrechen und sie über Adapter in die SOA Komponenten zu integrieren. So entsteht ein Enterprise-Service-Bus mit Business-Services als Bushaltestellen. Dabei abstrahieren die Business-Services von Implementierungen (von Systemen oder neuer Software), die leicht ausgetauscht werden. Da jedoch nicht alle Maßnahmen nach der Modernisierungphase kosteneffizient über den ESB in das Dienstleistungsnetzwerk integriert werden können, unterstützen weitere Service-Bausteine der nun zentralen Infrastrukturkomponente, der Middleware, den Prozess hin zum föderalen Rechnen im Serviceverbund. Die Einführung von BPM (Business Process Management) erlaubt die Modellierung, Orchestrierung und Optimierung der vorhandenen Dienste in neuer Serialität. Services werden also zu Prozessen und Prozesse zu Prozessketten über die vertikalen Anwendungen verbunden.

Auf zu individuellen Prozessketten

Unterstützt durch den Business-Process-Analytics-Einsatz werden die Fachabteilungen befähigt, ihre Anforderungen logisch als Dienste und Prozesse zu beschreiben. Hierbei spielt Roundtrip-Engineering eine wichtige Rolle. Fachliche Anforderungen werden möglichst automatisiert in Implementierungsanweisungen für die IT übersetzt, Änderungen in der technischen Implementierung spiegeln sich umgekehrt im logischen Design wider.

Der Ansatz, Data Services auf der Middleware als Methode für Massendatenoperationen zur Verfügung zu stellen, bringt mit sich, Data Quality und Data Profiling über Datengrenzen hinweg als Dienste einzusetzen. Die neue Verbindung zwischen vertikalen Datencontainern hat zwei Vorteile: BPM und der ESB werden in ihrer Performanz nicht stärker als nötig belastet, und bestehende Expertisen in der Datenbearbeitung werden in Kompetenzen auf der Serviceebene überführt.

Die Visualisierung der im Verbund angebotenen Dienste und Prozesse über Web 2.0 oder Enterprise 2.0 bindet menschliche Interaktion mit ein. Prozesse aus dem Warenkorb und die Möglichkeit, diese über Tools zu verbinden, können über Portale dargestellt werden und fügen dem Begriff „Information Workplace“ die Fähigkeit individueller Prozessketten hinzu.

Folgerichtig kennzeichnet sich Phase II letztlich auch dadurch, dass sie ein für alle im Servicenetzwerk arbeitenden Personen und Funktionen einheitliches Identitäts-Management zur Verfügung stellt.

Phase III: IT-Flexibilisierung

Mathias Kaldenhoff Sales Director Fusion Middleware bei Oracle: "Der steigende Wettbewerbsdruck fordert äußerst agile und kosteneffiziente IT-Archtekturen, um das Business Execution Gap zu schließen."

Mit harmonisierter IT geht es dann in Phase III: Hier stehen die Ausnutzung der in Phase II erworbenen Fähigkeiten und damit die Möglichkeit im Vordergrund, flexibel auf steigende interne wie externe Anforderungen reagieren zu können. Analysen der kritischen Geschäftsprozesse beherrschen die Phase, also die Prozesse, die ein Unternehmen vom Wettbewerb unterscheiden (sollen). Der Analyse des Ist-Zustands folgen eine Projektion auf mögliche Automatisierungen dieser Prozesse und die Formulierung von konkreten Soll-Zielen, die in einer Abbildung dieser Ziele auf Service-Bausteine mündet. Die in Phase II gebildeten Kompetenzen im Betrieb der Middleware-Foundation erlaubt den Organisationen, die Standardmodule bedarfsorientiert und nach dem erforderlichen Diensteportfolio zu akquirieren und einzupassen.

Hierzu zählen unter anderem ECM (Enterprise Content Management), EPM (Enterprise Performance Management), Realtime BI (Business Intelligence) und BAM (Business Activity Monitoring) und, sofern nicht
bereits in Phase II geschehen, das IDM (Identity Management). Sie docken mit ihren Services an die bestehende Foundation an.

Phase IV: Service-Industrialisierung

Die Muster der im Unternehmen dargestellten Prozessketten unabhängig von ihrer bisherigen Implementierung als Referenzmodelle zu beschreiben und sie mit Implementierungsanweisungen für Referenzmodelle zu vergleichen: Das ist Inhalt der Phase IV.

Auf dem SOA-Markt residierende Industriereferenzmodelle liefern die Implementierungen der nötigen Business Objects über die unterstützenden vertikalen Einheiten mit, sodass sich die Vorzeichen umkehren: Strategie treibt Implementierung, nicht der Reifegrad der Infrastruktur bestimmt die Strategie – das Ganze nennt sich dann „prebuilt SOA“.

Fazit

Die ersten drei Phasen zeigen die Entwicklung eines Unternehmens hin zur modernen, Service-orientierten, flexiblen Architektur und die Umsetzung der Geschäftsstrategie – mit dem Ziel, das Business Execution Gap zu verkleinern. Sie beschreiben den Weg der IT zu individuellen Fähigkeiten und Kompetenzen: Wie unterstützt IT die Geschäftsstrategie? Phase IV ist davon nur vermeintlich als Top-down-Strategie abgehoben, denn eine jede Phase folgt einem übergeordneten Prinzip: Agilität und Flexibilität.