Machen wir uns nichts vor: Technologie ist cool. Besonders für uns ITler, die wir täglich damit zu tun haben. Wir haben Spaß daran, immer neue Dinge auszuprobieren, vor allem, wenn sie viel besser sind als die alten, langweiligen, die bisher benutzt werden. Gibt es da nicht eine neue Java-basierte Process-Engine, die es uns erlaubt, unsere Java-Services direkt anzubinden, ohne Webservices? Klar, wir müssen alle Prozesse migrieren, aber das ist den Aufwand wert.

Was wir auch nicht mögen, ist Heterogenität. Da sind wir bisweilen ein bisschen zwanghaft. Alle Komponenten sollten am besten gleich gestrickt sein, nach dem gleichen Muster und mit dem gleichen Technologiestack. Gab es da nicht ein neues Logging-Framework, das viel effizienter ist als das alte? Das sollten wir benutzen und nicht nur für neue, sondern am besten auch in allen bestehenden Services.

Und irgendein neues Web-UI-Framework ist auch schon wieder „in“, da dürfen wir auf keinen Fall den Anschluss verlieren, sonst wird der Migrationsaufwand in fünf Jahren astronomisch.

Wie? Neben all dem sollen wir jetzt die Prozesse noch fachlich umgestalten? Das ist jetzt gerade schlecht, so mitten im technologischen Migrationsprojekt. Nächstes Jahr vielleicht. Wobei, da kommt die neue Version des Application-Servers, vielleicht müssen wir da erstmal umstellen. Und so ein Geschäftsprozess ist ja auch stabil, da können wir die Änderung auch noch hinterher machen.

Klingt doch gut! Oder?

Klar, ich habe bisher vielleicht ein bisschen überzeichnet, aber spätestens jetzt müssten sich jedem BPM-affinen Leser die Nackenhaare sträuben. Geschäftsprozesse stabil? Ein fataler Irrtum. Wesentliches Ziel von Prozessmanagement ist es, sich in die Lage zu versetzen, Prozesse an Veränderungen anpassen zu können. Veränderungen im Geschäftsmodell. Veränderungen in den Märkten. Und eben diese sind heutzutage von zunehmender Dynamik geprägt. Schnelle Anpassungsfähigkeit wird zum kritischen Erfolgsfaktor. Ordnet man fachliche Anforderungen stets technologischen Bedürfnissen unter, manövriert man sich bald ins Abseits, weil die Konkurrenz schneller (re-)agiert.

Wie immer im Leben gibt es aber auch dabei nicht nur Schwarz und Weiß. Natürlich müssen notwendige technologische Arbeiten erledigt werden. Läuft ein eingesetztes strategisches Tool beispielsweise aus der Wartung, sollte es ersetzt werden, bevor es zu Problemen kommt. Ist ein Framework im Einsatz, das nicht ideal auf die Anforderungen passt, so dass mehr und mehr Workarounds implementiert werden müssen und gegebenenfalls technische Schulden entstehen, so sollte man rechtzeitig tätig werden. Andernfalls steigen langfristig die Kosten für fachliche Erweiterungen.

Glücklicherweise befreien uns Serviceorientierte Architekturen davon, technologische Änderungen in einem großen Projekt durch das ganze System zu ziehen. Durch Prinzipien wie lose Kopplung oder open/closed principle haben wir die Möglichkeit, Services einzeln und ohne große Nebenwirkungen zu renovieren. Folgen wir dem Microservice-Gedanken, können einzelne Services sogar auf komplett unterschiedlichen Technologiestacks aufbauen. Technologische Gleichartigkeit oder sogar Gleichheit rückt dabei in den Hintergrund.

Managed Evolution als Hilfsmittel

Langer Rede kurzer Sinn: Es geht darum, einen sinnvollen Mittelweg zu finden. Klingt einleuchtend und beinahe trivial. Selbstverständlich ist es aber dennoch nicht und die Folgen bei Missachtung können verheerend sein.

Wird zu viel in technologische Verbesserung investiert und werden fachliche Anforderungen über lange Zeit ignoriert, ist das Produkt über kurz oder lang zwar technologisch in hervorragendem Zustand, aber faktisch tot, da es Anforderungen bedient, die im schlimmsten Fall gar nicht mehr existieren. Oder im allerschlimmsten Fall werden neue Anforderungen gar nicht erst eingebaut.

Auf der anderen Seite ist auch ständige fachliche Verbesserung bei gleichzeitigem Ignorieren technologischer Belange gefährlich: steigt doch die Gefahr, dass technologische Veränderungen, wenn sie dann nötig werden, nur unter großen Anstrengungen und hohen Kosten vorgenommen werden können.

Managed Evolution ist ein Ansatz, der dabei hilft, eine Ausgewogenheit zwischen Investitionen in fachliche Anforderungen und technologische Verbesserungen herzustellen. Es gibt also einen Ausgewogenheitskorridor, in dem sich die Evolution eines Produkts bewegen sollte.

Managed Evolution definiert drei Grundsätze:

• Es sollte eine Balance zwischen Investitionen in fachliche Erweiterungen und technologische Verbesserungen bestehen
• Evolution sollte in beherrschbaren Schritten vonstattengehen
• Fortschritt sollte mit geeigneten Metriken überwacht werden

Der erste Punkt ist dabei der Leitgedanke. Die letzten beiden Grundsätze machen die Einhaltung des ersten aber erst möglich. Dabei passen sie gut zum modernen Verständnis von (agilem) Prozessmanagement. Dort ist die ständige, inkrementelle Überwachung und Verbesserung der Prozesse wesentlicher Bestandteil. Methoden zur Quantifizierung gibt es genügend, im Prozessbereich kann man sich beispielsweise von Six Sigma inspirieren lassen. Dort wird die Streuung bestimmter Qualitätsmerkmale statistisch gemessen, um Optimierungspotential abzuleiten. In jedem Falle hilft die Erhebung geeigneter Prozesskennzahlen (Durchlaufzeiten, Liegezeiten, Automatisierungsquote etc.), um einen Eindruck über die Qualität der Prozesse und die Auswirkung von Verbesserungen zu gewinnen.

Auf Technologieebene helfen regelmäßige Architekturreviews mit gängigen Methoden wie der Architecture Tradeoff Analysis Method^SM (ATAM). Dabei wird die Architektur eines Systems gegen die wesentlichen Qualitätsziele (Wartbarkeit, Skalierbarkeit etc.) gehalten, um technologische Defizite und Verbesserungsbedarf zu identifizieren.

Oft reicht aber im Sinne der Managed Evolution schon die bewusste Diskussion über potentielle Maßnahmen.

Denkt denn keiner an Business-IT-Alignment?

Apropros Diskussion: Ein weiterer wesentlicher Aspekt bei Prozessmanagement und damit verbundenen BPM-Projekten ist das Business-IT-Alignment. Der gute Austausch und eine enge Zusammenarbeit zwischen Fachbereichen und IT ist nicht nur gewünscht, sondern zur erfolgreichen Bewältigung solcher Projekte essentiell. Versucht die IT nun wiederholt, technologische Maßnahmen auf Kosten wichtiger fachlicher Veränderungen durchzusetzen, kann ein mühsam aufgebautes, gutes Verhältnis zum Fachbereich dadurch nachhaltig gestört werden.

Was lernen wir daraus? Wie im wirklichen Leben geht es um den passenden Kompromiss. Es geht darum, die richtigen Dinge zum richtigen Zeitpunkt zu tun. Weder Fachlichkeit noch Technologie dürfen zu lange ignoriert werden, sonst leidet das Produkt ebenso wie die Beziehung zwischen den beteiligten Parteien. Was nötig ist, muss natürlich getan werden, das gilt sowohl für fachliche als auch technologische Verbesserungen gleichermaßen. Wichtig ist, Entscheidungen bewusst und im Dialog zu treffen und nach der Umsetzung ihren Erfolg zu verifizieren. Dann klappt es auch mit der evolutionären Entwicklung. Managed eben. Klingt einfach. Man muss es nur tun.