Die Einstiegshürden
Fortsetzung des Artikels von Teil 1
Die bekannten Probleme
Die Bilanz bereits realisierter SOA-Projekte ist ernüchternd: Nach Untersuchungen des englischen Analystenhauses Lustratus Research verfehlen 50 bis 60 % aller SOA-Vorhaben ihr Ziel. Oft gelingt die Wiederverwertung von Services nicht, da diese Dienste teilweise im Unternehmen unbekannt sind oder die Anforderungen der Nutzer nicht vollständig abdecken. Gravierender ist das Problem, wenn sich die implementierte SOA in puncto Reaktionsgeschwindigkeit als ebenso träge wie die alten Systeme erweist. Dann liegen die Fehler im Design und Zuschnitt der Services oder bei der Auswahl unflexibler Tools.
Die Probleme gehen letztlich auf das realisierte SOA-Konzept zurück. Konkret: Einige Anbieter haben die Prozesse in tausende Einzel-Services gesplittet. Die Modellierung von Geschäftsabläufen wird dadurch ähnlich komplex und unflexibel wie bei den bisherigen Ansätzen.
Die Alternative dazu stellt der Event-getriebene SOA-Ansatz dar, bei dem jedes Unternehmen seinen Geschäftsbetrieb durch Reagieren auf geschäftliche Ereignisse organisiert und abwickelt. Bei diesem Konzept muss in einem Geschäftsprozess vom Auftrags- bis zum Zahlungseingang jede beteiligte Abteilung über sämtliche Statusänderungen (Events) des Auftrags informiert werden. Dies gilt bereits für den ersten Prozess-Schritt – dem Auftragseingang: Die Fertigung erhält für die Produktionsplanung eine Auftragskopie, ebenso Einkauf und Lager für die Beschaffung und Vorhaltung der Materialien. Auch der Versand profitiert von der Benachrichtigung, um entsprechend langfristig planen zu können, und die Finanzabteilung kann präzise Prognosen erstellen. Technisch gesehen, bricht die Event-getriebene SOA mit der Strategie einer vollständigen Geschäftprozess-Ebene. Denn die Anwendungsarchitektur wird in separate, eigenständige Software-Komponenten und -Lösungen aufgeteilt. Auf diese Weise lassen sich die Beziehungen der Unterprozesse innerhalb des kompletten Prozesses entflechten. Kurz: Die Lösungen werden entkoppelt – nicht nur lose gekoppelt wie bei herkömmlichen SOA-Ansätzen.
Bei einem Event-getriebenen SOA-Ansatz sind je nach Unternehmen etwa 500 geschäftliche Ereignisse als Basis für die Steuerung der Software-Komponenten zu betrachten. Änderungen im Prozessablauf können häufig bereits durch Parametrisierung innerhalb der Komponenten erreicht werden. So vermeidet der Ansatz die Komplexität, die sich durch die Vielzahl von Services und der Forderung nach technologischer Standardisierung in der Prozess-Schicht herkömmlicher SOA-Ansätze ergibt. Bei einer ereignisgesteuerten SOA gibt jeder Unterprozess nach seiner Ausführung eine asynchrone Meldung an den nachfolgenden Unterprozess weiter, zum Beispiel über Business-Objects-Documents (BODs) der Open Applications Group Integration Specification (OAGIS). Über diese BODs lassen sich auch Services und SOA-fähige Anwendungen verknüpfen – sofern jeder Beteiligte die offenen Standards implementiert.
Das Argument, eine SOA-Strategie sei zu komplex und zu teuer, sucht der Software-Anbieter Infor mit seiner OAGIS-basierten, Event-getriebenen ERP-Lösung Infor Open SOA, zu entkräften: Mit jedem Software-Release liefert das Unternehmen „SOA-Enabler“ aus und stellt einen Enterprise-Service-Bus kostenlos zur Verfügung.
| Service-orientierte Architektur |
Die Komponenten Eine Service-orientierte Architektur trennt logisch zwischen Präsentations-Ebene, Diensten und deren Verschaltung (Orchestrierung), den Integrationsmechanismen und Applikationen sowie der Infrastruktur. Die Präsentations-Ebene, auch User-Interface genannt, einer mit SOA umgesetzten Anwendung muss sich nicht von herkömmlichen Bedienoberflächen unterscheiden. Mittels Portlets (beliebig kombinierbare Komponenten einer Bedienoberfläche) können weitere Funktionen und Interaktionen abgebildet werden. Ebenso lassen sich individuelle Anforderungen eines Nutzers berücksichtigen und sogenannte Composite Applications realisieren. Die Dienste (Services) stellen die Schnittstellen zu den einzelnen Anwendungen dar. Standardisierte Schnittstellen sind der Dreh- und Angelpunkt in einer SOA: Sie garantieren, dass die Dienste miteinander interagieren und als Basiselement für die Erstellung von Anwendungen genutzt werden können. Proprietäre Schnittstellentechniken schränken die übergreifende Wiederverwendbarkeit der Services stark ein. Auf der Verschaltungs-Ebene (Orchestrierung) wird die Geschäftslogik definiert, das heißt die Regeln, nach denen die einzelnen Services aufgerufen und miteinander verschaltet werden. Daraus resultiert der Datenfluss zwischen den Services. Die Modellierung und Ausführung der Prozesse erfolgt über Tools für Business-Process-Management (BPM) in der XML-basierten Sprache Business-Process-Execution-Language (BPEL). Auf der Integrations-Ebene ist meist, aber nicht zwangsläufig die Middleware angesiedelt, die für die Verknüpfung der Dienste sowie die Verbindung von Services mit den Anwendungen sorgt. Bei umfangreichen Architekturen kommt ein Enterprise Service Bus (ESB) als Integrations-Plattform zum Einsatz, der als Kommunikationszentrale für die Services fungiert: Meldungen werden transformiert, validiert, aggregiert und an den entsprechenden Empfänger weitergeleitet. Zudem kann ein ESB als Adapter für andere Systeme und Überwachungstools dienen. Applikations-/Infrastruktur-Ebene: Wie herkömmliche Architekturansätze benötigen auch Service-orientierte Architekturen eine Basis-Infrastruktur mit ausreichend Rechen- und Speicherkapazität und unter Umständen virtualisierte Netzwerkkomponenten. |
 | Stefan Stille ist Manager Business Consulting bei Infor. |
 | Markus Stahl ist als Manager Global Industry & Product Marketing bei Infor. |
- Die Einstiegshürden
- Die bekannten Probleme
