Kritische Aspekte in SOA-Projekten

Feature | 6. März 2009 von Gregor Müller 0

Was ist die Service-Oriented Architecture (SOA)? Wie sieht der Bauplan von SAP für die IT-Landschaft der Zukunft aus?

SOA-Projekte haben vielfältige Facetten: Zum einen müssen zunehmend mehr technische Systeme und verteilte Geschäftsprozesse integriert werden. Gleichzeitig sind für Projekte weniger Zeit, Budget und Ressourcen verfügbar. Dadurch, dass Produkte und Dienstleistungen immer schneller marktreif sein müssen, steigen zudem die Erwartungen und Wünsche der Fachabteilungen.

Fachbereichsübergreifende Prozesse sind keine Seltenheit, sodass der Zugriff auf entsprechend viele Backendsysteme nötig wird. Verglichen mit einem klassischen IT-Projekt sind deshalb bereits in den Planungsprozess mehr Wissensträger zu involvieren.

Die Planungsphase eines SOA-Projektes entscheidet über den Erfolg. Besondere Bedeutung hat hier der fachliche und technische Business Blueprint, in dem die Geschäftsanforderungen und deren Umsetzung genau dokumentiert werden. Mit Modellen können diese in anschauliche IT-Darstellungen überführt werden.

Rückkoppelung einplanen

In IT-Projekten lassen sich drei abstrakte Phasen definieren:

  1. Prozessdesign: Aufnahme und Dokumentation des Prozesses, der zu automatisieren und mit seinen Rollen, Prozessschritten, Abhängigkeiten, Entscheidungskriterien und Datenfluss abzubilden ist.
  2. Technischer Business Blueprint: Welche Systeme sind beteiligt? Wie kommunizieren diese miteinander? Wie lässt sich der Geschäftsprozess auf dieses System projizieren? Abbildung von den Funktionalitäten in der Systemlandschaft und mit der Technologie
  3. Implementierung: Programmierung, Einführung eines Produkts, Customizing, notwendige Erweiterungen der Lösung

Während des Prozessdesigns werden die umzusetzenden Prozesse analysiert und das Soll-Verhalten der Lösung beschrieben. Modellierungssprachen wie EPK (Ereignis gesteuerte Prozesskette) oder BPMN (Business Process Modeling Notation) unterstützen bei der Erfassung wichtiger Informationen.

Während des technischen Business Blueprint wird spezifiziert, wie die beschriebenen Prozesse technisch umzusetzen sind. Die Ergebnisse dieser Phase sind die Handlungsanweisungen für die folgende Implementierung. Diese verlaufen jedoch meist nicht linear – Rückkopplungen sind die Regel.

Konkret heißt das: Ändern sich während der Implementierungsphase bestimmte Anforderungen (z.B. andere Prüfschritte, fachliche Verantwortlichkeiten oder Kardinalitäten zwischen Geschäftsobjekten), müssen die Prozesse gegebenenfalls angepasst werden. Das zieht wiederum eine Anpassung des Business Blueprint nach sich.

Je später im Projektverlauf solche Rückkopplungen auftreten, desto teuerer sind sie. Ziel sollte es daher sein, mögliche Probleme vorab zu identifizieren und die damit verbundenen Änderungen bereits auf dem Papier durchzuspielen. Hier hilft es, wenn bereits in der Blueprint-Phase Modelle erzeugt werden, welche die technischen Spezifikationen beschreiben. Sie werden meist auf Basis allgemeiner Prozessbeschreibungen erstellt.

Erzeugung von UI-Modellen

Ein Beispiel:

Soll auf einem Bildschirm eine Liste von Materialien angezeigt werden, wird ein Dienst „Lade Materialien“ benötigt. Kommen die benötigten Informationen für diesen Service aus mehreren Backendsystemen, wird ein Komponentenkommunikationsmodell erstellt. Dieses visualisiert, wie die Komponenten verteilt sind, welche Komponente welche Information liefert und wie diese zu einem Service aggregiert werden können.

Allerdings sind klassische IT-Modellierungen wie die Unified Modeling Language (UML) oder die BPMN für Fachabteilungen wenig aussagekräftig, da diese entsprechendes technisches Verständnis voraussetzen. UML zum Beispiel bietet eine Vielzahl von Modellen wie Sequenz-, Klassen- oder Zustandsdiagramme – während die BPMN auf den Ablauf der Prozesse sowie ausführende Rollen zielt.

So genannte UI-Modelle (Mock-Ups der Bedienoberfläche) sind zur Kommunikation weit anschaulicher. Dabei wird die später zu implementierende Oberfläche mittels entsprechender Vorlagen in Visio oder Power Point visualisiert. Die grafische Aufbereitung zeigt, wie die Bedienung später aussehen kann. Zudem hilft sie den Fachabteilungen, fehlende Elemente zu identifizieren.

Gleichzeitig wird sie Handlungsanweisung für die spätere Implementierung. Ergänzt werden die Mock-Ups durch entsprechende Meta-Informationen wie Feldlängen, Pflichtfelder und Validierungs- bzw. Konsistenzbedingungen. Diese Informationen geben die nötige Detailtiefe für spätere Entwicklungstätigkeiten. Allerdings können UI-Modelle klassische Modellierungsformen nicht ersetzen, sondern diese nur ergänzen.

Die einzelnen Bildschirme (Screens) in ihrem Ablauf aneinandergereiht, ergeben so genannte Screen-Flow-Modelle. Anhand dieser kann der fachliche Bedarf an Diensten (Services) identifiziert werden, der als Ausgangsbasis zur späteren Modellierung von Enterprise Services dient.

Governance-Methodik

Sind alle fachlichen Dienste identifiziert, greift die Governance-Methodik der SAP zur Modellierung und Wiederverwendung von Enterprise Services. Ist ein vorhandener Service anwendbar, wird überprüft, ob alle benötigten Felder vorhanden sind. Aufgrund der losen Kopplung wird eine Servicestabilität gefordert, damit unbekannte Anwendungen weiterhin mit den publizierten Services arbeiten können.

Sollte es noch keinen Service geben, ist dieser entsprechend der Design Governance zu modellieren. Diese Methode beschreibt, wie Services idealerweise modelliert werden, damit sie gefunden und wieder verwendet werden können. SAP stellt hier detaillierte Vorgehensweisen bereit.

Die UI-Modelle werden regelmäßig von den Fachabteilungen validiert. Sie erklären damit ihr Einverständnis, die Anwendung nach diesen Modellen umzusetzen.

Parallel dazu werden identifizierte technische Schwachstellen (Pain Points) erfasst und in einem Prototypen gelöst. Beispiele sind die Einbindung von Nicht-SAP-Anwendungen oder die Konnektivität von speziellen Endgeräten (Zeiterfassung, Produktionsmaschinen, Sensoren).

Zudem findet durch die frühe Einbeziehung der Fachabteilungen, die gleichzeitig Endanwender sind, eine weitere Überprüfung statt. Mittels dieser Kreisläufe wird sichergestellt, dass Änderungen und Anpassungen nur auf dem „Papier“ erfolgen müssen, bevor die endgültige Lösung im System abgebildet wird.

Nutzen

Die dargestellte Vorgehensweise hilft, die kritischen Aspekte in einem SOA-Projekt frühzeitig zu adressieren. Dies beeinflusst dessen Wertschöpfung nachhaltig. Die Methodik kann zwar aufgrund vorgegebener Projekte und Ziele die Komplexität der Aufgaben nicht verringern – sie ermöglicht aber, das Projekt in überschaubare Einheiten zu strukturieren und macht so den gesamten Projektverlauf transparenter.

Die Fachabteilungen werden sehr früh in das Projekt eingebunden. So wird der Nutzen der Applikation früh verifiziert und es wird sichergestellt, dass das Endergebnis der Vorstellung der Fachabteilungen entspricht.

Die jeweiligen Ergebnisdokumente bilden eine logische Kette von Schlussfolgerungen. Probleme und Inkonsistenzen werden früh erkannt, Produktivität und Effizienz des Projektes gesteigert. Notwendige Rückkopplungen können “auf dem Papier” durchgeführt werden.

SOA: flexibel agieren, innovativ reagieren

Mit dem Konzept der serviceorientierten Architektur (SOA) können Unternehmen neue Anwendungen auf Grundlage bestehender Unternehmenslösungen entwickeln, so den Wert ihrer aktuellen Systeme erhöhen und neue Prozesse automatisieren.

SOA setzt auf der Geschäftsprozessplattform (Business Process Platform) auf. Als technologische Basis dient SAP NetWeaver, als funktionaler Kern SAP ERP. Für Unternehmen steht somit ein konkreter Bauplan für eine serviceorientierte IT bereit.

Die technische Umsetzung erfolgt über so genannte Enterprise Services. Enterprise Services entsprechen technisch den Web-Services und werden als Produkt von der SAP ausgeliefert, so dass diese sofort einsatzbereit sind und nicht erst entwickelt werden müssen. Enterprise Services erhöhen die Transparenz für einen Zugriff von außen auf komplexe Softwarebausteine, die über das Internet und andere Datennetze bereitgestellt und aufgerufen werden können.

Über offene, standardisierte Schnittstellen (etwa auf Basis der Metasprache XML) können sie definierte Aufgaben ausführen, Dienste erbringen und anspruchsvolle Geschäftsfunktionalitäten abbilden. Enterprise Services lassen sich je nach Bedarf zu neuen Geschäftsprozessen kombinieren und erweitern.

Darüber hinaus stehen verschiedene Entwicklungswerkzeuge zur Verfügung. Eine besondere Schlüsselfunktion kommt hier dem SAP Composite Application Framework (SAP CAF) und SAP NetWeaver Business Process Management (SAP NetWeaver BPM) zu: Anwendungen müssen nicht mehr komplett neu entwickelt werden, sondern können im Baukastenprinzip aus bestehenden Anwendungen zusammengefügt werden.

Tags:

Leave a Reply