Des eigenen Glückes Schmied

Der Ruf nach Designrichtlinien

Die zunächst einmal wohl ernüchternde Nachricht vorweg: Die Wahrscheinlichkeit, gleich zu Beginn einer BPM/SOA-Initiative im ersten Wurf Granularität und Schneidung der Prozesse, Services und Schnittstellen so zu treffen, dass diese langfristig Bestand haben, ist eher gering. Die Entwicklung einer BPM/SOA ist ein iterativer Prozess, in dessen Verlauf es getroffene Designentscheidungen auf Basis neuer und erweiterter Anforderungen immer wieder zu überprüfen und anzupassen gilt. Dennoch gibt es eine Reihe von Prinzipien, an denen sich zu orientieren dabei hilft, eine stets gute Ausgangsbasis zu haben.

Der erste Tipp ist weniger eine Designrichtlinie, sondern ist vielmehr organisatorischer Natur: Finden Sie von Anfang an „Eigentümer“ für die zu erstellenden Prozesse und Services, die sich für die fachlichen Inhalte der angebotenen Dienste verantwortlich zeigen! Mitarbeiter aus den Fachabteilungen, die ein Interesse daran haben, ihre eigenen Prozesse zu optimieren und ihre Dienstleistungen anderen Klienten im Unternehmen zur einheitlichen Wiederverwendung zur Verfügung zu stellen. Es liegt in der Natur der Sache, dass diese Process bzw. Service Owner sich im Wesentlichen jeweils auf die Inhalte ihrer eigenen fachlichen Domäne konzentrieren. Dadurch wird das erwähnte mögliche Risiko einer ziellosen Schneidung oder mangelnden inhaltlichen Abgrenzung von vorne herein reduziert. In größeren Unternehmen, die ihre Dienstleistungen auch intern verrechnen, können die Service Owner darüber hinaus auch für den ROI sowie Service Level Agreements (SLA) der von ihnen angebotenen Dienste verantwortlich sein. Umso mehr ist ihnen dann daran gelegen, dass die Schnittstellen ihrer Services klar beschrieben und allgemein bekannt gemacht werden, um so oft wie möglich wiederverwendet zu werden.

Wie eingangs bereits angesprochen, legt die grundlegende technische Architektur einen weiteren Grundstein für eine sinnvolle Granularität und Schneidung der Services. Hier empfiehlt es sich, auf einer unteren Ebene zunächst so genannte Core Services bereitzustellen, die sich im Wesentlichen um die Verwaltung der Geschäftsobjekte und Daten einer fachlichen Domäne kümmern. Dieser Dienste können sich auf einer übergeordneten Ebene dann so genannte Business Services bedienen, um domänenübergreifend höherwertige Dienste bereit zu stellen. Eine derartige Schichtung gibt also bereits zwei grundlegende Abstraktionsebenen hinsichtlich der Granularität der bereitzustellenden Services vor.

Weitere Designrichtlinien, die sich auch auf BPM/SOA übertragen lassen, findet man in den Prinzipien der objektorientierten Softwareentwicklung. So z. B. das Reuse/Release Equivalence Principle, das den Aspekt der Wiederverwendung in Bezug zur Größe der ausgerollten Einheiten setzt. Achten Sie bezüglich der Granularität eines Services oder eines wiederverwendbaren Subprozesses nicht nur allein auf den Funktionsumfang, der angeboten werden soll, sondern bedenken Sie auch, in welchen Einheiten (Deployment Units) Sie diese Funktionalität tatsächlich ausrollen wollen. Eine Komponente, von der zu erwarten ist, dass ein Teil der Funktionalität sich sehr selten ändert, ein anderer Teil aber deutlich häufiger, sollte wahrscheinlich besser in zwei Komponenten aufgeteilt werden, die dann einem unterschiedlichen Release-Zyklus unterliegen können. Auf diese Weise reduzieren Sie Anpassungsaufwände, da Sie nur die Funktionalitäten neu ausrollen, die sich wirklich geändert haben.

In eine ähnliche Kerbe – hinsichtlich der Gestaltung von Schnittstellen – schlägt das Interface Segregation Principle. Es besagt, dass Clients nicht gezwungen werden sollten, von Interfaces abhängig zu sein, die sie eigentlich gar nicht benutzen. Stattet man einen Service mit einem breit angelegten Interface aus, dass von vielen Klienten zu unterschiedlichen Zwecken genutzt wird, so bedeutet jede Änderung, dass die Clients auf das neue Interface angepasst werden müssen, obwohl sie die fragliche Funktionalität gar nicht nutzen. Stattdessen empfiehlt es sich, mehrere schmale Interfaces bereit zu stellen, die jeweils auf die Anforderungen der möglichen Klienten abgestimmt sind. Aber bitte nicht falsch verstehen: Dies ist kein Plädoyer für eine Vielzahl feingranularer Komponenten. Ein und derselbe Service kann sehr wohl mehrere Interfaces bereitstellen. Wird dann eine neue Version einer Komponente ausgerollt, müssen sich nur diejenigen Klienten darauf einstellen, deren Interface von der Änderung tatsächlich betroffen ist.

Abb. 2: Interface Segregation Principle

Beim Betrieb komponentenorientierter, verteilter Systeme ist das mit Änderungen einhergehende Abhängigkeitsmanagement oft ein kritischer Faktor, ganz besonders in einer serviceorientierten Architektur. Hier hilft es, sich beim Design und der Entwicklung stets an das Open/Closed Principle zu erinnern: Eine Komponente sollte „offen“ für Erweiterungen sein, aber „geschlossen“ gegenüber Änderungen. Gestalten Sie Ihre Services also so, dass Sie diese bei neuen Anforderungen entsprechend erweitern können, um zu vermeiden, dass Sie existierende Funktionalität, die bereits fehlerfrei läuft, dafür modifizieren müssen.

Doch wie sieht es aus mit den Daten, die über die Schnittstellen ausgetauscht werden und als Payload durch den Prozess geführt werden? Die verschiedenen Ansätze hatten wir in ihren Extremformen eingangs schon beschrieben. Am ehesten kann man sich vielleicht an den Grundsatz „so viel wie nötig, so wenig wie möglich“ orientieren. Das Optimum ist aber nicht immer leicht zu ermitteln, insbesondere wenn die gleichen Daten von mehreren Prozessen in unterschiedlichen Formen benötigt werden. Folglich ist es manchmal der bessere Weg, für individuelle Anwendungsfälle spezielle Zugriffsmethoden und Schnittstellen zu schaffen und den Zugriff auf das serverseitige Objektnetz und die Struktur seiner Daten zu beschränken. Für den Datentransport können beispielsweise spezielle DTOs (Data Transfer Objects) zum Einsatz kommen, die die Nutzdaten in geeigneter Form beinhalten. Dies können einerseits konkrete Werte sein, die dann direkt im Prozess verwendet werden können, aber auch Referenzen auf konkrete Objekte innerhalb des Objektnetzes in Form von IDs. Die konkreten Inhalte – Werte, Referenzen oder auch Mischformen – hängen vom jeweiligen Anwendungsfall ab.

Nicht das Design allein …

Gerade Unternehmen und IT-Abteilungen, die sich erstmalig mit dem Thema BPM/SOA befassen, sei mit auf den Weg gegeben, dass der erste umgesetzte Prozess und die daran beteiligten Services sicher kein Volltreffer in Bezug auf die oben genannten Designrichtlinien bzw. erhofften Ziele ist. Dies kann unterschiedliche Ursachen haben: Entweder sind die aufgestellten Designrichtlinien beim Entwurf und der Umsetzung nicht korrekt befolgt worden oder die Designrichtlinien sind nicht optimal auf die gesteckten Ziele angepasst. Möglicherweise gilt es sogar, eine Feinjustierung der Ziele selbst oder deren Priorisierung vorzunehmen, was sich im Umkehrschluss wieder auf die Designrichtlinien und den daran orientierten Prozess- und Serviceentwurf auswirkt. Ein entscheidender Erfolgsfaktor einer BPM/SOA-Initiative ist die Etablierung eines kontinuierlichen Verbesserungsprozesses mit den vom Deming Cycle bekannten Phasen des Planens, Umsetzens, Kontrollierens und Anpassens.

Der gute Entwurf von Prozessen und Services allein ist noch kein Garant für gute Wirtschaftlichkeit oder hohe Flexibilität. Diese Ziele werden erst erreicht, wenn es auch gelingt, bereits bestehende Funktionalität zu identifizieren und erneut einzusetzen. Mit wachsender Anzahl von Prozessen und mitwirkenden Services steigt auch der Bedarf eines gezielten Abhängigkeitsmanagements. Dazu gehört einerseits ein umfassendes Portfoliomanagement der gesamten Prozess- und Servicelandschaft aber auch aussagekräftige Servicekontrakte, die es über ein Verzeichnis (Repository) zu verwalten gilt.

Eine BPM/SOA-Initiative ist also kein einzelnes Entwicklungsprojekt, sondern mittel- und langfristig die gezielte Umstrukturierung der Unternehmens-IT. Dieses Unterfangen ist Herausforderung und Chance zugleich. Gelingt es, eine hohe Qualität der Bausteine, deren zielgerichteten Einsatz sowie die organisatorischen Rahmenbedingung durch einen kontinuierlichen Verbesserungsprozess nachhaltig zu etablieren, so sind Unternehmen bestens gerüstet, mit den immer schneller wechselnden Anforderungen des Marktes mitgehen zu können.

Jo Ehm und Roman Schlömmer sind Senior Consultants bei der Holisticon AG. Sie sind Certified Scrum Master und seit über zehn Jahren als Businessanalysten, Softwarearchitekten, Trainer und Coaches im Bereich objekt-, komponenten- und serviceorientierter Architekturen tätig. Neben verteilten Unternehmensanwendungen und der (Enterprise-)Architekturberatung stellen agile Softwareentwicklungsprozesse einen weiteren Schwerpunkt ihrer Tätigkeit dar.
Kommentare

Schreibe einen Kommentar

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