Des eigenen Glückes Schmied

Kritische Erfolgsfaktoren: der richtige Zuschnitt der Prozesse und Services

Wesentlich für die Wirtschaftlichkeit einer BPM/SOA-Initiative ist die Möglichkeit der Wiederverwendung möglichst vieler Services und (Teil-)Prozesse. Nur so kann die nötige Flexibilität erreicht werden, neue oder geänderte Geschäftsprozesse durch die Orchestrierung aus bestehenden Services zusammen zu stellen. Es gilt also, eine sinnvolle Granularität der einzelnen Funktionseinheiten zu erreichen. Eine zu grobe Granularität führt meist zu sehr starren Prozessen, da sich große Einheiten nur selten ohne Anpassungen rekombinieren lassen. Eine zu feine Granularität, bestehend aus sehr vielen kleinen Einheiten, ist zwar flexibel, aber durch die Vielzahl an Abhängigkeiten oftmals unübersichtlich und schwer zu handhaben. Interessanterweise wirken sich beide Extreme negativ auf die Wiederverwendung aus: Bei zu grober Schneidung sind die Einheiten in der Regel so prozessspezifisch, dass eine Wiederverwendung für andere Prozesse nicht in Frage kommt. Im Extremfall können dabei so große Konstrukte entstehen, die nicht nur eine übersteigerte Konzentration von Abhängigkeiten nach sich ziehen, sondern auch das Risiko eines Single Point of Failure bergen. Umgekehrt ist eine zu feine Granularität dagegen meist ein Zeichen dafür, dass die Einheiten aus fachlicher Sicht gar nicht erst mit Blick auf eine sinnvolle Wiederverwendung höherwertiger Funktionalitäten konzipiert wurden.

In der Praxis leider immer wieder vorzufinden sind willkürliche, ziellos erscheinende Schneidungen von Subprozessen und Services. Oftmals mangelt es an einer sauberen inhaltlichen Abgrenzung oder die verfügbaren Schnittstellenbeschreibungen und -kontrakte sind unklar oder fehlen gänzlich. Eine mangelnde inhaltliche Abgrenzung macht die Identifikation fachlich Verantwortlicher problematisch und oft verbleibt neben dem reinen Betrieb auch die inhaltliche Verantwortung in der IT-Abteilung. Unklare oder fehlende Schnittstellenkontrakte führen aufgrund von Unkenntnis oder Bedenken fast zwangsläufig zur Entstehung redundanter Funktionalitäten. Die Folgen sind ein geringerer Grad der Wiederverwendung und damit verbunden erhöhte Entwicklungs- und Betriebskosten.

Auch hinsichtlich der Gestaltung der angebotenen Schnittstellen ist die richtige Balance wichtig: Die Verwendung unnötig breiter Schnittstellen für alle Klienten resultiert in erhöhten Anpassungsaufwänden, da potenziell jeder Klient auch von jeder Änderung betroffen ist. Zusätzlich bergen sie im Extremfall ein Risiko, wenn auch sicherheitskritische Operationen, die eigentlich nur für einen gewissen Klientenkreis relevant sind, allen Klienten bekannt gemacht werden. Ein anderer Ansatz sind generische Schnittstellen, hinter denen eine grundsätzlich gute und richtige Absicht steckt: Über Abstraktion soll die Wiederverwendbarkeit erhöht werden. Bis zu einem gewissen Maß ist dies auch sinnvoll. Wenn der Grad der Abstraktion aber dazu führt, dass z. B. der Name einer Operation so allgemeingültig ist, dass der Inhalt unklar wird oder der fachliche Zusammenhang sehr weit hergeholt ist, dann ist man vermutlich über das Ziel hinausgeschossen. Die Verantwortlichkeit und der fachliche Rahmen eines Service, der sowohl Telefonanlagen als auch Atomkraftwerke steuern kann, wären wahrlich schwer zu greifen.

Ein weiterer wichtiger Aspekt im Zusammenhang mit den angebotenen Schnittstellen ist die Frage, welche Menge von Daten zwischen Prozess und den darunter liegenden Services ausgetauscht wird. Welche Daten werden alleine durch die Services verwaltet und welche Daten werden als so genannter Payload durch den Prozess geführt? Dabei spielen der Durchsatz, die Aktualität der Daten und die Anzahl der Serviceaufrufe eine wichtige Rolle. Auch hier gibt es grundsätzlich unterschiedliche Ansätze. Der erste Ansatz basiert darauf, dass einmal im Prozess ermittelte Daten an weitere Schritte weitergereicht und alle Informationen innerhalb des Payloads transportiert werden. In einem technisch unterstützen Prozess kann dies allerdings zu erhöhten Konvertierungsaufwänden führen, wenn die Daten innerhalb der Process Engine in einem anderen Format verarbeitet werden, als in den Services. Werden von den Services möglicherweise sogar zu viele Daten geliefert, die auf Ebene des Prozesses gar nicht wirklich benötigt werden, wirkt sich dies zusätzlich nachteilig auf den Durchsatz aus. Bei langlaufenden Prozessen muss ferner darauf geachtet werden, dass die ermittelten Daten noch aktuell sind und nicht zwischenzeitlich verändert wurden. Der zweite Ansatz umgeht die Konvertierungsaufwände, indem er die Payload auf das nötigste reduziert. So kann z. B. anstelle eines kompletten Datensatzes nur dessen ID durch den Prozess geführt werden und die Manipulation der Daten vollständig auf der Ebene der Services erfolgen. Dies hat einerseits den Vorteil, dass immer auf aktuellen Daten gearbeitet wird, führt aber auf der anderen Seite dazu, dass im Verlauf eines Prozesses unter Umständen sehr viele Service Calls nötig sind und identische Daten wiederholt geladen werden, was sich wiederum negativ auf die Laufzeit auswirken kann. All dies sind Designaspekte, die beim Aufbau einer BPM/SOA-Landschaft genau durchdacht werden wollen. Aber an welchen Kriterien und Best Practices sollte man sich orientieren?

Kommentare

Schreibe einen Kommentar

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