Ausbaufähige Fundamente

Business-Manager interessieren sich nicht für SOA. Ihr Fokus liegt vielmehr auf den Geschäftsprozessen und -modellen. Wie sich durch eine prozesszentrierte Organisation die Leistungsbilanzen einzelner Fachbereiche verbessern lassen, wurde in den letzten Jahren unter verschiedenen Begriffen diskutiert und zum Teil auch erfolgreich umgesetzt. Business Process Re-Engineering, Lean Production oder die Konzentration auf Kernkompetenzen lauten einige der durchaus konstruktiven Rezepte. In anderen Fällen hat sich jedoch keine dauerhafte Verbesserung eingestellt.


Seit einiger Zeit wurde die Diskussion um die Optimierung und Steuerung von Businessprozessen um einen weiteren Ansatz bereichert: die Service-orientierte Architektur. Das Bemerkenswerte daran ist, dass sich die grundlegenden Konstrukte von SOA sowohl in der IT-Welt als auch in der Welt der Fachabteilungen nützlich einsetzen lassen. Dazu zählen beispielsweise wiederverwendbare IT- oder Business-Services, die eigenständig genutzt, aber auch in Kombination mit anderen zu neuen Prozessen zusammengesetzt werden können. Eine gute Analogie dazu sind die Fertigungsprinzipien in der Automobilbranche, die wesentlich von der System- und Modulbildung geprägt sind.

Ohne eine gemeinsame methodische Basis, die Brücken zwischen den bislang getrennten Lagern der IT und den Fachabteilungen baut, geht es jedoch nicht. Das Verbindungsglied zwischen IT und Business sind die Geschäftsprozesse oder genauer: das Business Process Management (BPM). Voraussetzung dafür sind BPM-Werkzeuge, bei denen sich die IT auf die zugrundeliegende SOA-Infrastruktur konzentriert und die Fachabteilungen ihre Geschäftsprozesse modellieren, steuern und optimieren. Business-Manager können in dieser Konstellation ihre Geschäftsprozesse gestalten, ohne sich um die technischen Details der SOA kümmern zu müssen.

BPM wird zum Treiber für SOA

Von aussen betrachtet, wird damit Business Process Management zum Treiber für SOA. Gleichzeitig jedoch eröffnet eine SOA durch den Komponenten-basierten Ansatz den Fachabteilungen neue Möglichkeiten, flexibler auf geänderte Marktbedingungen oder neue unternehmerische Zielvorgaben zu reagieren. Denn eine Verknüpfung zwischen den fachlichen Anforderungen an das Business Process Management und der IT, welche die technischen Fundamente bereitstellt, bedeutet in der Konsequenz, dass die Erfüllung der geschäftsprozessualen Vorgaben durch eine SOA einfacher wird.


Im optimalen Fall ist die Fachabteilung in der Lage, die Businessprozesse aus einem Art Baukastensystem zu designen. Es werden Abläufe, Zusammenhänge und Abhängigkeiten definiert, wobei es an dem Punkt darauf ankommt, dass die Fachabteilung und die IT die gleiche Sprache sprechen. Denn die von den Prozessexperten entwickelten Modelle müssen bis in alle technischen Verästelungen von der IT in ihren Infrastrukturen und mit ihren Mitteln umgesetzt werden.

An dieser Stelle jedoch traten in der Praxis immer wieder mehr oder minder gravierende Abstimmungsprobleme auf. Denn die von der Fachabteilung erstellten Prozessmodelle liessen sich nur unter grössten Mühen an die IT-Abteilung transferieren und weiterverwenden. Bevor diese Designs in die technischen Infrastrukturen umgesetzt werden konnten, war in der Regel eine aufwendige Nachbearbeitung erforderlich. Erst in jüngster Zeit gibt es Ansätze, diese technologische Lücke zwischen Fachabteilungen und IT zu schliessen: Statt mit unterschiedlichen Werkzeugen arbeiten beide mit denselben Tools und einem einheitlichen Datenbestand.


Die Aktivitäten rund ums Business Process Management verlagern sich damit von einer Technikfixierung auf die Ebene der fachlichen Gestaltung von Abläufen. Geschäftsprozesse werden dann zunächst einmal dort entworfen, getestet und modifiziert, wo ihre Auswirkungen unmittelbar zu spüren sind. Da Business-Verantwortliche und die IT gemeinsam, aber in unterschiedlichen Rollen, in einer Web-basierten Entwicklungsumgebung modellieren und die Prozesse wo nötig an neue Gegebenheiten und Bedingungen anpassen, verkürzen sich so auch die Zyklen bei der Erstellung neuer und der Anpassung vorhandener Geschäftsprozesse.

Schlüsselrolle der Fachabteilung

Statt Aufträge an die IT zu vergeben, um Änderungen in den technischen Systemen vorzunehmen, gibt die Fachabteilung nun die Richtung vor. Beim Design, der Steuerung und dem Monitoring der Geschäftsprozesse ist man nicht mehr auf die Kapazitäten der IT angewiesen. Eine Anpassung in den Modellen und Abläufen kann innerhalb weniger Tage statt erst nach mehreren Wochen vorgenommen werden. Die Voraussetzung für ein derartiges Business Process Management ist eine einheitliche Modellier- und Runtime-Umgebung.


Nur in einer idealen Welt laufen die Geschäftsprozesse völlig störungsfrei. Im richtigen Leben kommt es immer wieder zu Abweichungen, Ausnahmefällen und unerwarteten Ereignissen. Bekanntlich gibt es sehr unterschiedliche Strategien, um mit solchen Situationen umzugehen. Die meisten laufen allerdings darauf hinaus, dass einzelne Mitarbeiter dazu ausersehen sind, für Abhilfe zu sorgen. Möglicherweise gibt es auch interne Vorschriften, wie in solchen Fällen vorzugehen ist. Dennoch werden solche Situationen eher intuitiv abgehandelt und einer Lösung zugeführt.

Kann der Stammlieferant, etwa wegen eines Maschinenschadens, die benötigten Vorprodukte nicht in der vereinbarten Menge oder Qualität liefern, muss dafür eine andere Bezugsquelle aktiviert werden. Stellt man Mängel in einem bereits ausgelieferten Produkt fest, kommt es darauf an, möglichst rasch die Ursache zu ermitteln und Vorkehrungen zu treffen, dass dieser Fehler künftig nicht mehr vorkommen kann. Bei einer Maschinensteuerung etwa sind die Fachkenntnisse von Programmierern gefragt. Das Gleiche gilt bei Abläufen wie dem Wertpapierhandel oder generell Finanzdienstleistungen, die ohne IT nicht auskommen. Kommt es zu gravierenden Abweichungen von den erwarteten Ereignissen, ist es Aufgabe der IT, softwaretechnisch für eine Lösung zu sorgen.


Weit einfacher und unter dem Aspekt des Business Process Management auch effizienter wäre es, den Fachabteilungen eine weitgehend automatisierte Behandlung von Ausnahmeerscheinungen und Fehlern in den Geschäftsprozessen zu ermöglichen. Dazu bedarf es lediglich einer Verknüpfung mit der Modellierung der Geschäftsprozesse.


Die Beseitigung von Fehlern und Ausnahmefällen ist oft ein komplexer, mehrstufiger Prozess. Richtig ist, dass einige Anomalien in den Geschäftsprozessen einen direkten Eingriff durch Menschen erfordern. Ziel eines Business Exception Management ist es, dass möglichst viele Abweichungen aufgrund klar definierter Regeln automatisch gelöst werden. Daher bietet es sich an, zunächst einmal die manuellen Problemlösungsstrategien zu strukturieren. Dies ist ein wichtiger Zwischenschritt auf dem Weg zu einer weitgehenden Automatisierung der Fehlerbehebung – unter Kontrolle der Fachabteilung. Das technische Rückgrat dafür liefert eine stetig anwachsende Datenbank mit Regeln, die auf bestimmte, bekannte Situa­tionen angewandt werden können. Dieses Regelwerk lässt sich abhängig von den jeweiligen Geschäftsprozessen und anderen unternehmensspezifischen Gegebenheiten in­di­viduell anpassen und erweitern.


Business Exception Management in dem hier skizzierten Umfeld ermöglicht eine kontinuierliche Überwachung der Geschäftsprozesse aus fachlicher Sicht. Die Prozessverantwortlichen erhalten dadurch einen Überblick über die Problembereiche eines Prozesses. Exception Management filtert innerhalb der Prozessabläufe die Ausnahmen und Abweichungen von üblichen Ereignissen heraus und zeigt ereignisgesteuert, für welche Fälle eine sofortige Einleitung von Gegenmassnahmen notwendig wird. Darüber hinaus kann eine Detailanalyse der identifizierten Ausnahmen, aber auch der Fehler in einem Ablauf, wichtige Anregungen zur weiteren Prozessverbesserung liefern, die dann wiederum als anwendbare Regeln Eingang in die Datenbank finden. Business Process Management und Exception Management sind dabei vollständig in eine Service-orientierte Unternehmensarchitektur integriert.

Exception Management ist Teil der SOA

Dabei lassen sich mehrere Ebenen einer SOA unterscheiden. Auf der Business-Ebene sind Aktivitäten wie Exception Handling oder branchenabhängige Governance-Vorschriften in die Service-orientierte Unternehmensarchitektur eingebunden. Diesem Ansatz zufolge können solche Ser­vices natürlich auch mit Hilfe unternehmensweiter Business-Process-Ma­nage­ment-Funktionen zu neuen, komplexen Geschäftsprozessen zusammengefügt werden.

Unter Business-Aspekten erfolgt dies in den Fachabteilungen. Technisch betrachtet schliesslich werden die Komponenten an einen zentralen Service Bus angebunden, der wiederum die Konnektivität zu anderen, bereits im Unternehmen vorhandenen Applikationen herstellt. Spätestens hier wird deutlich, dass sich das Fehlermanagement nicht auf die fachlichen Aspekte beschränken darf, sondern auch die technische Ebene berücksichtigen muss. Bei allen technischen Problemen in einer komplexen SOA ist weiterhin die IT gefragt. Das Stichwort lautet hier SOA Governance. Entsprechende SOA-Runtime-Governance-Lösungen ermöglichen eine Überwachung des Status und der Einsatzfähigkeit einer SOA. Wichtig ist dabei der Überblick über die Vorgänge in einer SOA, denn nur so lassen sich beispielsweise auch SLAs einhalten.



SOA Governance befasst sich mit der Identifikation, Vermeidung und Beseitigung technischer Probleme in verteilten, komplexen SOA-Systemen. Mit dem Ziel des Business Process Management geht es hier darum, potentielle technische Fehler zu diagnostizieren, zu erkennen und zu beseitigen, bevor sie die Geschäftsprozesse beeinflussen.
Das technische Monitoring im Rahmen der SOA Governance ermöglicht ein durchgängiges End-to-End-Lifecycle-Management, das sowohl die fachlichen als auch die technischen Ausnahmesituationen enthält. Das schafft Transparenz in einer Service-orientierten Unternehmensarchitektur und ermöglicht erst ein ganzheitliches Business Process Management.

Mögliche Exceptions auf unterschiedlichen Ebenen

Der Autor

Thomas Egeling ist Senior Sales Consultant bei Vitria Technology.