Unternehmenscockpit
Die Befragten des SOA Check 2008 sind sich sicher: In einer serviceorientierten Architektur lassen sich IT-Anwendungen unterschiedlicher Art zusammenfĂĽhren und Unternehmensprozesse flexibel modellieren. Bei den Steuerungs- und Kontrollmechanismen gibt es jedoch noch einiges zu tun.
- Wolfgang Martin
- Thorsten Schäfer
Der „Rummel um ein Architekturkonzept“ verebbt nicht [1]. IT-Verantwortliche kommen schon länger kaum noch umhin, sich gründlich mit serviceorientierten Architekturen (SOA) zu befassen. Nach einer Hype-Phase, in der manche Protagonisten das Konzept als neuen Wunderweg anpriesen, ist Sachlichkeit eingekehrt. Der SOA Check 2008, durchgeführt von Wolfgang Martin und Nicolas Repp von der TU Darmstadt, zeigt, dass die Unternehmen in ihren diesbezüglichen Projekten deutliche Fortschritte gemacht haben (siehe Kasten „Onlinequellen“ oder iX-Link siehe unten). 84 Prozent der Befragten planen eine SOA oder setzen diese schon ein. Das sind elf Prozent mehr als im Jahr 2007. Über die Hälfte der Befragten misst dem Thema eine große beziehungsweise sehr große Bedeutung zu.
Onlinequellen
Dass eine SOA entscheidende Vorteile für das Geschäft bringt, ist inzwischen unstrittig. Als wichtigstes Einsatzgebiet sehen die Unternehmen entsprechend angelegte Geschäftsprozesse, speziell die kundenbezogenen. Durch die Flexibilität, die Services versprechen, eröffnet sich erhebliches Optimierungspotenzial. Nur ein Fünftel der Untersuchungsteilnehmer betrachtet SOA als rein technisches Thema.
Jedoch zeigt die Studie auch, wo die Herausforderungen zukünftiger SOA-Vorhaben liegen. Gegenüber 2007 liefen die Projekte zwar besser, doch sehen immer noch 47 Prozent der Befragten weniger als 60 Prozent ihrer Ziele erfüllt. Ursache laut SOA Check: Nur jede fünfte Firma hat ein Konzept für die effektive Kontrolle von internen Richtlinien. Festgelegte Dienstgütevereinbarungen (SLAs, Service Level Agreements) zur Qualitätssicherung setzt nur die Hälfte der Beteiligten ein.
Flexibilität durch Baukastenprinzip
Grundsätzlich soll eine SOA die IT-Infrastruktur durch den Einsatz voneinander unabhängiger, lose gekoppelter Dienste flexibilisieren und die Geschäftsprozesse von ihrer technischen Grundlage trennen. Die Services kommunizieren via SOAP, REST oder ähnlichen Protokollen, das Verwalten und Archivieren übernehmen sogenannte Servicekataloge. Fachliche Funktionen, die bislang von Applikationen geliefert wurden, stehen nun als separate Dienste bereit, die sich einzeln aufrufen und beliebig neu kombinieren lassen. Zueinander inkompatible anwendungsübergreifende Geschäftsprozesse sollten somit der Vergangenheit angehören. Inkonsistente und redundante Stammdaten lassen sich zumindest deutlich minimieren, wenn sie in einem zentralen Repository abgelegt sind.
Für die Orchestrierung der Geschäftsprozesse bieten sich Werkzeuge für das Business Process Management an. BPM ist einerseits eine Managementdisziplin, die sich mit dem Verwalten und Verbessern der operativen Geschäftsprozesse beschäftigt. Andererseits führt BPM die Prozesse auf der technischen Ebene aus, beschreibt, steuert und überwacht sie. Als Sprache für eine klare Spezifikation von Geschäftsprozessen eignet sich der BPMN-Standard (Business Process Modelling Notation). Damit modelliert der Anwender menschliche Tätigkeiten ebenso wie automatisierte Systeminteraktionen. BPMN definiert, wie ein Diagramm in die Ausführungssprache BPEL (Business Process Execution Language) zu übersetzen ist, damit ein Programm letztlich die Prozesse ausführen kann. Sowohl Geschäftsprozess- als auch IT-Experten sind in der Lage, BPMN zu verstehen – essenzielle Voraussetzung, um die Geschäftsabläufe an den Vorgaben der Fachabteilungen auszurichten.
Grundsätzlich sollten die Verantwortlichen vor dem Start eines SOA-Projektes klären, wie sie gedenken, die formulierten Ziele zu erreichen. Denn selbst wenn das Unternehmen seine Geschäftsprozesse unkompliziert gestalten und flexibel anpassen kann, garantiert das noch keine messbaren Verbesserungen. Wer in dieser Beziehung tatsächlich etwas erreichen will, braucht ein System zum Überwachen und Steuern der Geschäftsprozesse in Hinblick auf Leistung und Zuverlässigkeit, eine sogenannte SOA-Governance.
Die Strategien (Policies), nach denen die Nutzer Services verwenden, sind hier durch Regeln festgelegt. Nur wenn jeder Baustein klar mit Metadaten beschrieben ist, lässt er sich mit anderen Elementen zu neuen sinnvollen Modellen zusammensetzen. Eindeutige Verantwortlichkeitsbereiche für Servicegeber und -nehmer stellen sicher, dass das Zusammenspiel der SOA-Komponenten nachvollziehbar bleibt.
Kein Erfolg ohne effektive Kontrolle
80 Prozent der Teilnehmer am SOA Check berĂĽcksichtigten diese Prinzipien jedoch nicht. Wer sein Projekt ohne Steuerungsmechanismen angeht, braucht sich ĂĽber mangelnden Erfolg nicht zu wundern. So warnt das britische Analystenhaus Butler Group, dass der erwartete langfristige Nutzen einer SOA ein Wunschtraum bleibt, wenn das Unternehmen nicht ausreichend in Governance-Strukturen investiert. Ein entsprechendes Modell sollte also schon zu Beginn des Projekts auf der Tagesordnung stehen.
Es ist notwendig, festzulegen, welche Services man tatsächlich benötigt und wie lange sie aktiv sein sollen. Weiterhin sollte man Verantwortlichkeiten und Entscheidungsrechte klar abgrenzen und bestimmen, wer welche Dienste wie kontrolliert und misst. Nach Abschluss der Design- und Implementierungsphase des SOA-Projekts muss sich das Governance-Modell in der Praxis bewähren. Das heißt, die Verantwortlichen müssen die wertschöpfenden Prozesse kontinuierlich überwachen und steuern, SOA-Governance ist kein einmaliger Akt, sondern ein kontinuierlicher Prozess.
Eine SOA-Governance bietet verschiedene Mechanismen, die für die Zielerreichung wichtig sind. Dazu zählen Anreizsysteme, Kommunikations- und Dokumentationsrichtlinien sowie Dienstgütevereinbarungen. Die SLAs strukturieren als essenzieller Bestandteil eines Governance-Konzepts die SOA-Projekte und ermöglichen die Überwachung und Erfolgskontrolle von einzelnen Diensten beziehungsweise längeren, daraus zusammengesetzten Prozessketten. SLAs definieren für jeden Service Reaktionszeit, Dauer, Qualität, Leistungsumfang und Kosten.
Anbieter von BPM-Software für ein SOA-Umfeld liefern heute Instrumente mit, die es dem Anwender erleichtern, sich in den Services und Verantwortlichkeiten zurechtzufinden. Mit diesen Programmen kann er schon bei der Modellierung von Prozessen die notwendigen SLAs zuordnen. Festlegungen über Höchstdauer, Qualitätskriterien oder Leistungsdefinitionen bleiben während des gesamten Lebenszyklus eines Services erhalten. Beim Aufruf liefert Letzterer seine Dienstgütevereinbarungen mit, die beispielsweise festschreiben, ab welcher Rechnungssumme die nächsthöhere Entscheidungsinstanz ins Spiel kommt. Schafft es der Service nicht, seine Versprechungen einzuhalten, erhält der Anfrager automatisch eine Rückmeldung, ebenso beim erfolgreichen Abschluss aller Schritte.
Um Serviceorientierung konkret umsetzen zu können, hat sich ein fünfstufiges Vorgehen bewährt, nach dem sich die Prozesse eines Unternehmens gestalten, verbessern und automatisieren lassen: In der ersten Phase sollte man ein Prozessmodell durch sogenannte Swimlanes strukturieren (Abbildung 1). Über diese Prozessvisualisierungsmethode kann der Modellierer die organisatorischen Einheiten und Rollen visualisieren. Letztere bilden zum Beispiel Abteilungen (etwa Kundenservice) oder Personen (etwa Außendienstmitarbeiter) ab und können hierarchisch gegliedert sein (Abteilungsleiter, Mitarbeiter). Jede Rolle bietet bestimmte Leistungen an, die von anderen Rollen in Anspruch genommen werden können. Das Modell zeigt, welche Organisationseinheiten als Servicenehmer oder -geber agieren. Auch abteilungsübergreifende Schnittstellen erschließen sich über diese Darstellung.
In fĂĽnf Stufen zum SOA-Profi
Der Kontrollfluss wird in der zweiten Phase aufgebaut. Er bildet die Verantwortlichkeiten für die Ausführung und die Kontrolle eines Service im Modell ab. Entscheidend dabei ist, dass er die Verantwortung für bestimmte Tätigkeiten in einer Rolle sammelt und dies nicht für abteilungsübergreifende Daten- oder Dokumentenflüsse tut. So bildet der Kontrollfluss nur diejenigen Tätigkeiten ab, die tatsächlich von der jeweils ausführenden Rolle beeinflusst und kontrolliert werden können. Service Level Agreements für jeden Dienst in Bezug auf Qualität, Zeit und Kosten sind Gegenstand der dritten Phase. Im Modell hinterlegen die Planer die SLAs für jeden Serviceaufruf samt Verweis auf ein SLA-Dokument.
In der vierten Phase sollte man die Granularität so einstellen, dass nicht jede Einzelaktivität im Modell erscheint. Der Prozess wird also nicht Schritt für Schritt modelliert, sondern ergebnisbezogen betrachtet. Das bedeutet, dass nicht in der Form „Was passiert dann?“, sondern „Was benötige ich als nächsten Output?“ vorzugehen ist. Schließlich integrieren die Modellierer in der fünften Phase die Unterprozesse. Sie müssen außerdem alle Prozesse dokumentieren, damit Änderungen sich jederzeit nachvollziehen lassen (Abbildung 2).
Dass in der Konzeption der dargestellten fünf Phasen das Erfassen der Geschäftsregeln fehlt, ist beabsichtigt, denn die ändern sich zu häufig, ein entsprechendes Modell hätte keine Stabilität. Zudem kann ein Prozess einerseits mehrere Regeln enthalten, andererseits eine Regel zu verschiedenen Prozessen gehören. Daher ist es sinnvoll, Geschäftsregeln nicht im Modell darzustellen, sondern sie separat zu erfassen und dann den Aktivitäten zuzuordnen.
Technische Voraussetzung dafür ist eine Business Rule Engine (BRE), die Regeln, also fachliche Entscheidungsprinzipien, zum Abruf bereithält. Einige BPM-Systeme liefern eine BRE mit, die entweder Geschäftsregeln als Services bereitstellt oder sie als externe Dienste aufruft. So gestaltet der Prozessdesigner keine komplexen fachlichen Abläufe mit verschachtelten Strukturen (wenn-dann-Muster), sondern ordnet jedem Prozessschritt eine Regel zu. Eine Rule Engine bietet die Möglichkeit, sämtliche Entscheidungswege in einer Tabelle zu erfassen. Wer einzelne Werte ändern will, muss lediglich hier die Daten anpassen, das Prozessmodell bleibt davon unberührt. Die BRE stellt die Regeln bei der Ausführung des Prozesses bereit. Sie kann die Regeln wie erwähnt auch in Form von Services aus dem Web abrufen, etwa für eine tagesaktuelle Währungsumrechnung.
Weniger Chaos durch klare Regeln
BREs bieten einige Vorteile: Ändern sich die Geschäftsvorfälle, zieht das beispielsweise keine Anpassungen von Software nach sich und die Geschäftsabläufe lassen sich auch bei komplexen Entscheidungszusammenhängen automatisieren. Der Fachnutzer kann die Regeln pflegen und revisionssicher speichern. Und da sich die Prozessmodelle einfach darstellen, ist auch der Anwender in der Lage, Verbesserungspotenzial zu erkennen.
Serviceorientierung beschreibt im Grunde genommen ein Kollaborationsmodell, das die Beziehungen zwischen Servicegebern und -nehmern organisiert. Das können verschiedene Abteilungen innerhalb eines Unternehmens oder externe Geschäftspartner sein. Auf fachlicher Ebene regeln SLAs die Zusammenarbeit und sorgen für durchschaubare Geschäftsprozesse. Ein Governance-Konzept inklusive SLAs ist damit eine essenzielle Voraussetzung für das Auslagern von Geschäftsprozessen (Business Process Outsourcing, BPO) beziehungsweise für das Nutzen externer Services. Bei Versicherungen beispielsweise kann es sich dabei um die Abfrage von meteorologischen Daten handeln, die bei der Abwicklung eines Gewährleistungsfalls relevant sind. Ein anderer Anwendungsfall wäre die Integration von Webservices zur automatischen geografischen Suche und Validierung von Adressen.
Beim Abruf entfernter Dienste erfüllt Governance eine weitere wichtige Kontrollfunktion. Denn oftmals verbieten einschlägige Unternehmensrichtlinien bestimmte Angebote von außen. Services, für die Lizenzgebühren anfallen, müssen ebenfalls überwacht werden. Das Regelsystem der Governance verhindert den unautorisierten Abruf und verhindert so, dass sich die Anwender unkontrolliert an solchen Services bedienen.
Nur wenn das Governance-Konzept sicherstellt, dass die Benutzer mit den Services korrekt und sinnvoll umgehen, dürfte das Unternehmen das Potenzial einer serviceorientierten Architektur voll ausschöpfen. In der Kombination mit BPM-Techniken sorgt eine SOA zudem dafür, dass Modellierer die Geschäftsprozesse nach den spezifischen Anforderungen der Fachabteilungen erstellen, anpassen und überwachen. Diese Zusammenhänge haben die für den SOA Check befragten Firmen zwar klar erkannt, an der Umsetzung müssen sie allerdings noch feilen.
Dr. Wolfgang Martin
ist unabhängiger Analyst.
Thorsten Schäfer
ist Vorstandsvorsitzender und Managing Director von Cordys Central Europe.
