Best Practices für den erfolgreichen Einsatz von BPM/SOA

Des eigenen Glückes Schmied

Jo Ehm und Roman Schlömmer

In immer mehr Unternehmen kommen Business Process Management (BPM) und flankierend dazu auf der IT-Seite serviceorientierte Architekturen (SOA) zum Einsatz – und das aus gutem Grund, sind die vielfach heraufbeschworenen Ziele doch ein echter Gewinn für die eigene Wertschöpfungskette. Um die hochgesteckten Erwartungen aber erfüllen zu können, ist es wichtig, von Anfang an und in einem kontinuierlichen Verbesserungsprozess auf gutes Design und die entsprechenden organisatorischen Rahmenbedingungen zu achten. Diesbezüglich ist jeder selbst seines eigenen Glückes Schmied.

Was Vorstandsmitgliedern und Managern immer ein Lächeln ins Gesicht zaubert, ist die Aussicht auf hohe Wirtschaftlichkeit. Ohne jede Frage ist es erstrebenswert, mit möglichst geringem zeitlichem und finanziellem Aufwand die eigene IT-Landschaft zu betreiben oder diese durch Neuentwicklungen auf den gerade aktuellen Bedarf anzupassen. Und wenn Letzteres auch noch in kurzer Zeit geschieht und sich dadurch eine günstige „Time to Market“ ergibt, dann müsste doch eigentlich klar sein, wohin die Reise gehen sollte.

Wenn wir diese Anforderungen auf den Ansatz BPM/SOA übertragen, bedeutet dies, dass wir die Prozesse und die darunter liegenden Services so gestalten müssen, dass sie einerseits ein hohes Maß an Flexibilität – sprich schnelle Anpassbarkeit und Änderbarkeit – bieten. Zwei wichtige Aspekte hierfür sind Wiederverwendbarkeit und eine an fachlichen Einheiten orientierte Verteilung des Funktionsumfangs auf kleine, allgemeingültige Komponenten. Wiederverwendbarkeit ist einer der Grundpfeiler für Wirtschaftlichkeit. Funktionalität nicht komplett neu entwickeln zu müssen, sondern sich aus einem Fundus bestehender Services und Teilprozesse bedienen zu können, verringert nicht nur die Entwicklungs-, sondern auch die Betriebskosten. Eine Komponente, die nur einmal betrieben werden muss und von vielen Benutzern verwendet werden kann, ist in vielen Fällen günstiger zu betreiben als individuelle Komponenten je Benutzerkreis.

Was es bei den Zielen für den Entwurf der eigenen Prozesse und Services allerdings zu bedenken gilt ist die Tatsache, dass sich diese in bestimmten Konstellationen auch widersprechen können. Beispielsweise kann ein hohes Maß an Wiederverwendung die Flexibilität einschränken, da Änderungen an einer von mehreren Benutzern verwendeten Komponente sich auch auf alle auswirken, was gegebenenfalls nicht erwünscht ist. Dies ist auch ein Grund dafür, dass es nicht die eine SOA gibt, sondern stets eine unternehmensspezifische Bewertung und Priorisierung der gesteckten Ziele erforderlich ist. Erst diese Priorisierung macht es möglich, Designrichtlinien für den Prozess- und Serviceentwurf zu erarbeiten und zu etablieren.

BPM/SOA Schicht für Schicht

Die Regeln und Richtlinien für den Entwurf einer SOA verteilen sich über alle Schichten der Architektur – von der fachlichen Prozessbeschreibung, über deren technische Implementierung sowie die daran beteiligten Services und nicht zuletzt die Geschäftsobjekte, die im Prozess ver- und bearbeitet werden.

Abb. 1: Das BPM/SOA-Schichtenmodell

Die sinnvolle Verteilung der für einen Prozess zu implementierenden Logik auf die zuvor genannten und in Abbildung 1 dargestellten Schichten stellt in der Tat die erste Designrichtlinie dar. Dabei wird die prozessspezifische Ablauflogik auf Ebene der Prozesse und Teilprozesse platziert. Werden Teilprozesse als Subprozesse konzipiert, können sie wiederum als Bestandteile mehrerer übergreifenden Prozesse zum Einsatz kommen. Darunter liegende Services kapseln die prozessunabhängige und damit prozessübergreifende Geschäftslogik. Die Trennung von Ablauflogik und Geschäftslogik ist ein wichtiger Grundstein, um Prozesse auf Basis von wiederverwendbaren Services aufbauen zu können und die heute in der Praxis üblicherweise großen Anteile von redundant implementierter Geschäftslogik zu vermeiden.

Auf Ebene der Services hilft die weitere Untergliederung in Services, die klar einer Domäne zuzuordnen sind und den Zugriff auf einen fachlich abgegrenzten Bereich der Geschäftsobjekte und Daten im Unternehmen ermöglichen (Core Services), und solchen, die übergreifende, höherwertige Funktionalität anbieten (Business Services) – nicht nur dabei, sinnvolle wiederverwendbare Einheiten zu schaffen, sondern auch Verantwortliche in den Fachabteilungen zu identifizieren und zu bestimmen.

Die rein technische Umsetzung einer solchen Architektur alleine ist aber noch keine Erfolgsgarantie. Was muss also sonst noch beachtet werden, damit eine SOA ihren Ansprüchen gerecht wird?

Geschrieben von
Jo Ehm und Roman Schlömmer
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.