»manage it« als

E-Paper  11-12 2011
E-Paper  9-10 2011
E-Paper  5-6 2011
E-Paper  3-4 2011
E-Paper  1-2 2011
E-Paper  11-12 2010
E-Paper  9-10 2010
E-Paper  7-8 2010
E-Paper  5-6 2010
 

So stellen sich IT-Verantwortliche den Herausforderungen bei Einführung und Betrieb einer SOA

Mit der richtigen Strategie: SOA erfolgreich umsetzen

Wer glaubt, die Implementierung einer serviceorientierten Architektur ausschließlich über neueste Technologien und hoch qualifizierte 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.

in Leitgedanke von SOA besteht darin, Geschäftsprozesse von darunter liegenden Anwendungen zu »befreien«. Der Begriff »befreien« ist bewusst gewählt: Die in den letzten Jahren entstandenen Geschäftsapplikationen unterstützen meist nur einen Teilbereich des Unternehmens und sind nicht für unternehmensweite Prozesse geeignet. Heute wird aber erwartet, dass die IT genau solche übergreifende Prozesse unterstützt. Diese Abläufe umfassen nicht nur das Unternehmen sondern auch die gesamte Wertschöpfungskette inklusive Partner und Endkunden.

Da SOA-Projekte abteilungs- und unternehmensübergreifend hinweg ablaufen sollen, steht die Kommunikation zwischen den Verantwortlichen auf der IT- und auf der Businessseite im Vordergrund. Daher sollten sich SOA-Projektleiter als Leitmotiv ins Pflichtenheft schreiben: »Organisation ist mindestens so wichtig wie Technologie«.

Vor dem Start: Grundlagen schaffen

Die Discovery Phase steht am Anfang eines SOA-Lebenszyklus. Die IT-Verantwortlichen sollten zunächst versuchen, 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.

Ist die Führungsebene überzeugt, gilt es die passenden Mitglieder für das Projekt zu identifizieren. Notwendig sind Mitarbeiter aus den Geschäftsbereichen und der IT-Abteilung, die an bereichsübergreifenden Projekten interessiert sind. Die Gruppenleiter sollten in der Lage sein, interdisziplinär zu agieren und sowohl die Anforderungen der Geschäftseinheiten als auch die Technologien zu verstehen. Falls notwendig übernehmen externe Berater die Funktion eines Mediators, um zwischen den beiden Fachgruppen zu vermitteln.

Services unter der Lupe

Nach dieser initialen Projektphase geht es bei dem SOA Readiness Assessment 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. An dieser Stelle wird häufig auch ein Business Reengineering Projekt mit externen Beratern gestartet. Ideale Voraussetzung hierfür ist eine bereits vorhandene Prozessdokumentation: Diese hilft festzustellen, welche fachlichen Abläufe auf welche IT-Assets und Anwendungen zugreifen.

Die Definition eines Business Service kann unterschiedlich ausfallen. Beispielsweise kann ein solcher Service unternehmensweit Informationen über einen Kunden oder über Kundengruppen zusammenstellen. Dieser Service beantwortet Fragen wie »Wer sind die Kunden, die ein bestimmtes Produkt einsetzen?«, »Welche Produkte haben diese Kunden noch gekauft?« und »Welche Reklamationen sind entstanden?« Auch das Kreditmanagement oder die Risikoabschätzung im Finanzwesen sind Beispiele für unternehmensweite, zentrale Services. Wichtig ist hierbei den Bottom-up-Ansatz zu verfolgen: So kommt das Projektteam rasch zu ersten Erfolgen, da mit vorhandenen IT-Systemen ein konkretes Fachproblem gelöst wird. Ein Business Service ist also so zu definieren, dass dieser alle Funktionen eines in sich abgeschlossenen Prozessschrittes unterstützt.

Als Vorbild dient die Automobilindustrie: Hier hat sich der Plattformgedanke längst durchgesetzt. Die Hersteller haben Komponenten identifiziert, die immer wieder benötigt werden und sich mit wenigen Änderungen in neuen Fahrzeugmodellen verwenden lassen. Ein vergleichbares Ziel verfolgen IT-Abteilungen, die eine SOA implementieren.

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.

Für den ersten Abschnitt im SOA-Lebenszyklus ist folgender Zeitbedarf einzukalkulieren: Das Kick-Off-Meeting mit dem Projektteam kann je nach Komplexität des Projektes zwischen zwei bis vier Tage dauern. Das Assessment von Services kann drei bis vier Wochen umfassen. Am Ende steht eine klare Beschreibung von Diensten und Prozessen, die innerhalb des Unternehmens am meisten genutzt werden.

SOA Lifecycle Services: 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 wieder verwenden lassen, wie es der SOA-Idee entspricht. Die zu diesem Zweck eingesetzten Integrations- und Modernisierungswerkzeuge müssen in der Lage sein, alle im Unternehmen vorhandenen Systeme in eine Services-Welt zu überführen. Andernfalls droht innerhalb der SOA-Welt eine Zweiklassengesellschaft mit angebundenen und isolierten Systemen.

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.

Im Idealfall ist ein Bestandssystem bereits in einzeln aufrufbare Programmfunktionen strukturiert, die sich zur Verwendung als Services in einer SOA-Plattform eignen und nur noch mit den entsprechenden Standardschnittstellen »umhüllt« werden müssen. In der Praxis finden sich jedoch häufig über Jahre gewachsene monolithische Systeme. Ein Reengineering dieser Systeme in modulare Services ist notwendig. Nur Systeme von strategischer Bedeutung und hoher Nutzungsdauer rechtfertigen den Aufwand für diese Vorgehensweise.

Für die Übergangszeit und für weniger strategische Lösungen bietet sich die Simulation eines Benutzerdialogs an, um aus den daraus gewonnenen Daten einen Service zu generieren. Immer dann, wenn der Quellcode nicht angefasst werden soll, ist die Integration über die sogenannte Terminalemulation der einzig mögliche Weg, um Legacy-Systeme in eine SOA-Welt zu integrieren.

Werkzeuge zur Integration von Legacy-Systemen sollten idealerweise alle genannten Ansätze unterstützen, dabei möglichst wenig Mainframekenntnisse erfordern, und darüber hinaus den Bestandssystemen die aktive Nutzung von Services der SOA-Plattform ermöglichen. Hierfür ist eine Integrationslösung notwendig, die auch den bidirektionalen Datenaustausch unterstützt. Bei der Integration von Mainframeanwendungen 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 mithilfe einer Kompositions- und Orchestrierungsschicht zusammenzufügen.

Eine Systemarchitektur entsteht

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.

AJAX und Mashups

Durch den Einsatz der AJAX-Technologie (Asynchronous Java Script and XML) lassen sich browserbasierende Anwendungen schaffen, die über den gleichen Funktionsumfang wie herkömmliche Desktop-Anwendungen verfügen, jedoch komplett im Browser laufen. Das lästige Reload von Webseiten nach einer Änderung entfällt bei AJAX fast vollständig. Werden hierbei auch öffentlich zugängliche Services wie beispielsweise Google Maps oder Amazon in die eigenen Systeme eingebunden, entsteht eine neue Generation von offenen Geschäftsanwendungen: die sogenannten Mashups. Diese Anwendungen sollen ohne Installationsaufwand im Browser ablaufen und sich dennoch interaktiv wie Desktop-Anwendungen verhalten, und zum Beispiel Drag-and-Drop unterstützen. Die AJAX-Technologie eignet sich zur Realisierung solcher Applikationen sehr gut. Entwickler sollten jedoch auf die manuelle AJAX-Programmierung wegen der hohen Komplexität verzichten und auf Frameworks setzen, die auf Basis visueller Modelle AJAX generieren und verwalten.

BPM

Sollen die neuen Applikationen unterschiedliche Benutzerrollen und flexible Prozessschritte unterstützen, eignet sich der Einsatz von Lösungen für Business Process Management (BPM). Fachabteilungen erhalten über ein BPM-System Dienste, die die geschäftliche Sicht wiedergeben. Beispielsweise lassen sich in diesem System alle Aktivitäten modellieren und automatisieren, die zum Beantworten einer Kundenanfrage notwendig sind. Die Verbindung in die IT-Systeme wird dann durch die einfache Verknüpfung der Business Services mit dem BPM-System geschaffen.

BPM steuert und verwaltet also die Geschäftslogik und abstrahiert die darunter liegenden Technologien. Einzelne Prozesse aus einer Fachabteilung sind so schnell in größere und übergreifende Abläufe einbindbar. Da sich die Regeln für die Prozessabläufe getrennt von der Technologie bearbeiten lassen, sind Änderungen vergleichsweise einfach umzusetzen. Haben Unternehmen mit Hilfe von BPM-Werkzeugen erste Arbeitsabläufe integriert, können sie deren Nutzen durch die Integration zusätzliche Informationssysteme weiter erhöhen. Auch hierbei bildet die SOA die notwendige technologische Basis.

Auswahl der Granularität

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 aufwendig 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.

Schwerpunkt Organisation

Bei der weiteren Implementierung gilt es in erster Linie organisatorische, und weniger technologische Hürden zu überwinden. Bei Projekten zeigt es sich immer wieder, dass sich die Fachabteilungen zu wenig Zeit nehmen, um ihre Bedürfnisse zu analysieren und anschließend klar auszudrücken. Auch kommt es in der Kommunikation zwischen der IT-Abteilung und dem Fachbereich immer wieder zu Missverständnissen – ein Mediator kann als Übersetzer zwischen den Fachsprachen weiterhelfen. Auch sollten IT-Verantwortliche große Versprechungen vermeiden und zunächst mit bis zu drei Geschäftsabläufen beginnen, die analysiert und durch eine serviceorientierte Architektur unterstützt werden sollen. Es eignen sich insbesondere prozessgesteuerte Abläufe, an denen mehrere Bearbeiter und Abteilungen beteiligt sind. Später können Prozesse angegangen werden, an denen auch externe Partner und Kunden beteiligt sind.

Wer noch auf der Suche nach einer geeigneten Lösung für die neue Architekturschicht ist, sollte einen Technologielieferanten mit Erfahrung in ganzheitlichen SOA-Projekten wählen. Wichtige Aspekte sind beispielsweise Komposition und Orchestrierung von Services, Business Process Management, Entwicklung von Composite Applications sowie die einheitliche Sicht auf operative Daten in verschiedenen Systemen. Die verwendeten Werkzeuge zur Prozessabbildung müssen modellgestützt sein und rasch Ergebnisse liefern. Fachabteilungen und IT-Verantwortliche können so in regelmäßigen Abständen den Projektfortschritt abgleichen.

Wichtig ist in dieser Phase, dass Projektverantwortliche über den Tellerrand der IT-Implementierung schauen und Erfolge auf der Geschäftsebene messbar machen. Dies kann auf Basis von Service Level Agreements oder tatsächlichen Bearbeitungszeiten erfolgen. Dieser Schritt sollte schon an dieser Stelle fest im Projektplan eingebaut werden. Das Ergebnis dieser Phase sind fachliche Dienste, die aus IT-Services bestehen. Einzelne Geschäftsprozesse können nun auf diese Dienste zugreifen.

Management einer SOA-Architektur

Bei weiter fortgeschrittenen SOA-Projekten kommen Unternehmen an einen Punkt, an dem sich die implementierten Services nicht mehr manuell verwalten lassen. Mit dem Abschnitt SOA Maturity Assessment ist eine weitere Phase im SOA-Lebenszyklus erreicht, in der Management und Governance gefragt sind. Jetzt müssen Unternehmen feststellen, welche Auswirkungen der Ausfall eines Dienstes auf das laufende Geschäft hat. Weiterhin ist zu prüfen, ob Anwender und Partner die erforderlichen Berechtigungen 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, einzuhalten und zu überwachen.

Spätestens in dieser Phase sollte auf der organisatorischen Seite ein SOA-Bibliothekar oder zu neudeutsch Cybrarian – abgeleitet von dem Librarian im Cyberspace – das Projekt unterstützen. Dieser Mitarbeiter kennt, verwaltet und kommuniziert alle Details zu den vorhandenen Systemen und Services. Er erhöht durch sein Engagement die Sichtbarkeit der SOA-Projekte im eigenen Haus und hilft bei der Definition eines Regelwerks. Die Regeln beschreiben beispielsweise, wie das Projektteam neue Services entwickelt. Ähnlich wie in einem Content-Management-System wird festgehalten, wer welche Aufgaben hat, wer Dienste testet und freigibt und wer Systembetreiber über Neuigkeiten und Änderungen an genutzten Diensten informiert.

Die notwendigen Werkzeuge hierfür sind in SOA-Registries und Repositories enthalten. Deren Funktionsumfang geht über ein klassisches UDDI-Verzeichnis weit hinaus: 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 Managementinfrastruktur 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.

Wer einen Prozess optimieren möchte, muss diesen zunächst messbar machen. BPM-Systeme bieten entsprechende Werkzeuge für das Performance Management an. Im einfachsten Fall ermitteln die Anwendungen die Durchlaufzeiten beispielsweise einer Bestellannahme oder einer Reklamation. Da diese Systeme die direkte Messbarkeit von Mitarbeitern ermöglichen, sollten die Arbeitnehmervertreter oder der Betriebsrat mit einbezogen werden. Unter Umständen ist es nicht ausreichend, einen bestehenden Prozess nur zu optimieren. Daher sollten Fachbereiche auch an dieser Stelle nochmals kritisch prüfen, ob ein komplettes Re-Engineering zusätzliche Vorteile bringt. Wichtig ist dabei, dass die Verantwortlichen das hierarchische Abteilungsdenken aufgeben und versuchen, neue Prozessketten bereichsübergreifend zu definieren. Die Fachbereiche leisten so einen wertvollen Beitrag, damit das eigene Unternehmen sich gegen den Wettbewerb behaupten kann.

Resümee

Bei der praktischen Umsetzung sollten IT-Verantwortliche auf Lösungen setzen, die offene und herstellerneutrale Standards unterstützen. Große Einführungsprojekte nach dem Wasserfallmodell 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.

Ivo Totev

___________________________________________________________

Ivo Totev, Vice President Product Marketing crossvision, Software AG

Folgen Sie »manage it« auf Google+

Copyright © 2003-2012  ap Verlag GmbH