Als Karl Kraus einst meinte Im Zweifelsfall entscheide man sich für das Richtige, dachte er dabei sicherlich nicht an Softwarearchitekturen. Die Paradoxie, die diesem Wortspiel innewohnt, ist in der Softwarearchitektur allgegenwärtig und führt nicht selten zu Widersprüchen und Kompromissen. Es gibt eine Reihe von Werkzeugen und Methoden für den Umgang mit Zweifelsfällen in der Softwarearchitektur: Architecture Decision Records (ADR) helfen dabei, Entscheidungen vorzubereiten, und strukturieren den Prozess des Entscheidens, Dokumentationsvorlagen wie arc42 helfen, die Übersicht aller getroffenen Entscheidungen zu bewahren, und Arch-Unit beantwortet die Frage, ob sich die getroffenen Entscheidungen auch korrekt im Code wiederfinden. Alle diese Werkzeuge und Methoden sind wunderbare Helfer, wenn es um die Frage geht, mit bewusst getroffenen Entscheidungen zu arbeiten. Und es steht außer Frage:

Gute Softwarearchitekturen sind so beschaffen, dass sie die getroffenen Entscheidungen einhalten.

Die Abweichler

Nun entstehen Softwarearchitekturen in Organisationen – was in den vorherigen Ausgaben dieser Kolumne ja mehrfach betrachtet wurde – und folgen somit auch den Mustern, nach denen Organisationen funktionieren.

In der Praxis gibt es kaum eine Organisation, in der alle Vorschriften exakt eingehalten werden. Spitze Zungen behaupten gar, das strikte Einhalten aller Regeln – Dienst nach Vorschrift – sei die effektivste Methode des Streiks, weil die Organisation damit zum Stillstand gezwungen wird. Dieses Abweichen von den Regeln, wie es in Organisationen Alltag ist, wird von Organisationswissenschaftlern als Brauchbare Illegalität bezeichnet. Dieses Konzept beschreibt das Phänomen, dass die Mitglieder einer Organisation die Regeln zwar kennen, aber ganz bewusst gegen diese Regeln handeln. Dieses Handeln gegen die Regeln ist dabei im Sinne der Organisation oder des Vorhabens, an dem das Organisationsmitglied arbeitet. Brauchbare Illegalität grenzt sich dabei von Illegalität im rechtlichen Sinne ab. Die brauchbare Illegalität bezieht sich auf die Regeln der Organisation, gegen die verstoßen wird.

Es gibt zwar Fälle, in denen brauchbare Illegalität gleichzeitig auch ein Gesetzesverstoß ist, das ist aber nicht die Regel. Für Softwarearchitektur ist das Konzept brauchbarer Illegalität unter mehreren Perspektiven spannend. Zum einen gibt es den Verstoß gegen Prinzipien und Leitlinien der Architektur, der in jedem Softwareprojekt irgendwo vorkommt. Zum anderen ist Softwarearchitekturarbeit eine Tätigkeit, die brauchbare Illegalität in Organisationen für viele Mitglieder schwieriger macht.

Der programmierte Regelverstoß

Die Gründe, gegen Regeln der Softwarearchitektur zu verstoßen, sind vielfältig:

Diese und noch viele weitere Situationen führen zu einem Regelbruch, der üblicherweise keine ernsthaften Konsequenzen nach sich zieht. Häufig wird selbst nach dem Bekanntwerden des Regelbruchs dieser einfach beibehalten, weil das Ergebnis funktioniert – Karl Kraus würde sich dabei vermutlich auf die normative Kraft des Faktischen berufen.

Softwarearchitektinnen und -architekten müssen mit diesen Regelverstößen klug umgehen. Es gilt die Balance zu wahren zwischen dem Ahnden des Regelbruchs und dem Tolerieren funktionierender Lösungen. Werden funktionierende Lösungen, die gegen Regeln verstoßen, zu häufig sanktioniert, ist Handlungsunfähigkeit die Folge – die Menschen hören auf, kreative Lösungen in herausfordernden Situationen zu suchen, in denen die existierenden Regeln nicht passfähig sind.

Anderseits kann ein zu legerer Umgang mit Regelverstößen dazu führen, dass die Regeln zum zahnlosen Tiger werden und der Regelverstoß die Norm. Dann wird es nahezu unmöglich, Softwarearchitekturen mit langfristiger Perspektive zu erhalten, weil jederzeit und überall ein Regelbruch zu Abweichungen führen kann und der Nutzen von gemeinsamen Regeln nicht mehr existiert. Auch das führt dazu, dass die Menschen aufhören, kreative Lösungen zu suchen – sie werden vielmehr die einfachsten lokalen Lösungen realisieren, ohne über Konsequenzen nachzudenken. Besonders herausfordernd wird der Umgang mit Regelverstößen für Softwarearchitekten, wenn deutlich wird, dass sich gar nicht alles vorab regeln lässt. Da kann es passieren, dass eine neu eingeführte Regel bisher praktizierte Lösungswege illegal werden lässt – nur lassen sich die existierenden Lösungen in der Softwarearchitektur nur unter hohen Kosten verändern. Oder es treten Fälle ein, die in einer Grauzone zwischen dem geregelten und dem nicht geregelten Umgang mit bestimmten Fragestellungen liegen.

In all diesen Fällen geht es weniger um technologisches Wissen als vielmehr um die Fähigkeit, Paradoxien auszuhalten und für Softwareentwicklungsteams auszubalancieren. Softwarearchitekten müssen hier echte Management- und Kommunikationsfähigkeiten zeigen, um eine konsistente Architektur und gleichzeitig die Handlungsfähigkeit der Entwicklungsteams zu erhalten.

Softwarearchitektur gegen den Regelbruch

Die zweite oben genannte Perspektive auf brauchbare Illegalität, die im Zusammenhang mit Softwarearchitektur relevant ist, resultiert aus der Tatsache, dass das Implementieren von organisationalen Abläufen in Software immer eine Formalisierung dieser Abläufe ist.

Hier prallen zwei ureigene Interessen jeder Organisation aufeinander, zwischen denen sich Software immer für dieselbe Seite entscheiden wird. Organisationen benötigen formale Regeln, um ihren Mitgliedern einen Orientierungsrahmen zu bieten, in dem sie produktiv im Sinne der Organisation handeln können.

Dieser Orientierungsrahmen besteht aus Regeln, die formal festgelegt sind. Das Erreichen dieser Formalisierung ist ein Interesse jeder Organisation. Auf der anderen Seite steht das Bedürfnis nach lokaler Handlungsfähigkeit, die häufig sehr spezifischer Regel bedürfte und mit Situationen umgehen muss, die nicht vorher denkbar sind und zu denen es keine oder unpassende Regeln gibt.

Jede Organisation findet ihren Weg, mit der Balance zwischen Formalisierung und Handlungsfähigkeit sinnvoll umzugehen und produktiv zu sein. Sobald Abläufe der Organisation durch ein Softwareprojekt abgebildet werden sollen, wird das Aufeinanderprallen dieser beiden Interessen deutlich.

Den formalen Teil der Abläufe zu erfahren, ist in der Regel kein Problem. Zwar braucht es Zeit für Business-Analyse oder Requirements Engineering, aber es ist praktisch immer möglich, formale Prozesse zu erfassen und als Vorlage einer Implementierung zu beschreiben.

Schwieriger wird es bei den Abläufen, die gegen die formalen Regeln verstoßen, aber den Prozess am Laufen halten. Ein Beispiel könnte sein, dass zwei Abteilungen in der analogen Welt Informationen auf dem kurzen Dienstweg austauschen und nicht den Weg über die Hauspost nehmen. An anderer Stelle packen die Mitarbeitenden in einem Lager Teile nicht an die vorgeschriebenen Stellen, sondern an andere Orte.

Und während Complianceabteilungen eine wahre Meisterschaft darin entwickelt haben, solche Regelbrüche zu übersehen, sofern sie nicht Arbeitsschutz gefährden oder gegen Gesetze verstoßen, haben Softwareprojekte diese Chance nicht.

Damit die Software funktioniert, muss der Prozess sauber implementiert werden – aber eben der echte Prozess und nicht der, der irgendwo als Regel definiert wurde. Der reale Prozess funktioniert aber nur, weil er nur informell existiert. Zwar wissen nahezu alle davon, aber es wird nicht darüber gesprochen, und deshalb ist der Regelbruch akzeptabel. Die Digitalisierung von Prozessen führt deshalb nicht selten dazu, dass die geregelten Prozesse in Richtung der informellen Abläufe angepasst werden müssen, was in der Regel mit diversen Hürden verbunden ist.

Die Menschen, die kollektiv am Regelbruch mitwirken, fühlen sich zumeist, ohne dass es einer Absprache bedarf, zum ebenso kollektiven Schweigen über diesen Regelbruch verpflichtet. Softwarearchtikten, die solche Projekte verantworten, müssen nicht selten Fähigkeiten von Diplomaten mit denen von Verhörspezialisten verbinden um herauszufinden, wie die Software sinnvollerweise strukturiert sein muss, um Prozesse abzubilden, die nützlich für die Mitarbeitenden sind.

Conclusion

Der Widerstand gegen die Digitalisierung bestimmter Abläufe ist, kennt man das Konzept brauchbarer Illegalität, gut nachvollziehbar. Prozesse, die in Software implementiert sind, lassen sich schwerer umgehen als analoge Prozesse, was den Menschen, die für die Organisation tätig sind, Handlungsmöglichkeiten nimmt. Softwarearchitektinnen und -architekten müssen sich dieser Problematik bewusst sein, um nicht Software für Organisationen zu konstruieren, die der Handlungsfähigkeit dieser Organisationen entgegensteht.

TAGS