5000 Euro für Koks und Nutten

9. Februar 2023 IT Management

Eigentlich ist der Job des Kassenwarts eines großen Sportvereins nicht vergnügungssteuerpflichtig. Zu Beginn jeden Jahres muss ich den Haushaltsentwurf vorlegen, und die Kollegen interessieren sich nur am Rande für die Details dessen, was ich da schreibe. Aber ich kann mir ja mal einen Spaß erlauben: Ich stelle mir vor, wie es wär, wenn ich einfach mal einen Posten wie in der Überschrift irgendwo auf Seite 17 verstecke. Würde man mich erwischen?

Die Chance steht nämlich gar nicht schlecht, dass das unbemerkt bleibt und der Vorstand (und auch die zumeist ebenso unkritische Jahreshauptversammlung) meinen Entwurf abnickt. Aber bevor ich mich das wirklich traue: Es illustriert zudem ein Problem, mit dem wir auch in der IT tatsächlich ständig zu tun haben: Welche Änderungen akzeptieren wir eigentlich, und warum?

Unbemerkte Änderungen sind das Problem

Wenn man will, ist so ein Haushaltsentwurf als Dokument auch nichts anderes als Quelltext. Tatsächlich ist unsere Software zumeist sogar weit umfangreicher — in einem aktuellen eher mittelgroßen Projekt habe ich gerade gezählt und bin auf knapp 125.000 Zeilen Code gekommen. Tendenz stark wachsend. Und weil Software einfach so viel mehr Text ist (der zudem deutlich sensibler auf Rechtschreibfehler reagiert als mein Haushalt) ist es nochmal viel entscheidender zu wissen, was da genau drin steckt.

In der Softwaretechnik begegnen wir der Masse an Quelltext mit Versionierung.¹ Als Entwickler wissen wir längst, dass 125.000 Zeilen Code jeden Sinn verlieren können, nur weil an ausreichender Stelle ein Komma zu viel oder zu wenig steht. Was ist aber mit den Leuten, die keine Entwickler sind? Die Qualität beurteilen sollen, bevor etwas benutzt wird - weil Fehler später hässlich auf einen zurückfallen?

Kooperative QA ist wie kooperatives Multitasking

Traditionelle Qualitätssicherungs-Prozesse sind in meinen Augen kooperativ, weil sie darauf bauen, dass die Beteiligten zusammenarbeiten und einander korrekte Informationen liefern. Mein Lieblingsbeispiel sind Change Advisory Boards (CAB), ein Bestandteil aus dem in ITIL definierten Change Management Prozess. Die Idee: Wenn Änderungen an Systemen einem Komitee rechtzeitig vor Durchführung der Änderung gemeldet werden, dann hat das Komitee Aufgabe und Möglichkeit, diese Änderungen auf ihr Risiko hin zu bewerten, zu verwalten und bei Bedarf zu verhindern. Mit dem Ziel, Schaden von der Organisation abzuwenden, der durch die Änderung verursacht werden könnte.

Wer jemals in nach ITIL verwalteten IT-Organisation gearbeitet hat, weiss, wie erfolgreich das zumeist ist: Gar nicht.

Warum? Das Komitee hat schlicht keine Chance, dieses Ziel zu erreichen. Wie der Vereinsvorstand im Beispiel meines Haushaltsplans muss es sich darauf verlassen, was zum Change beschrieben ist. Diese Beschreibung kann! vollständig und korrekt sein - aber darf man sich darauf verlassen? Und selbst wenn ein Change an einem Onlinesystem beschreibt, dass zB ab sofort nur noch Verschlüsselung nach TLS 1.2 erlaubt ist — wer will denn beurteilen, welche Auswirkungen das hat? Nicht zu vergessen: Das Komitee ist eine Managementfunktion und überwiegend mit Managern besetzt. Im Falle von Unsicherheit werden Probleme in der Hierarchie nach oben eskaliert, weil eine inhaltliche Betrachtung durch diese Menschen überhaupt nicht zu leisten ist. Nach dem Cover-your-ass-Prinzip geht es nur darum, sich bescheinigen zu lassen, dass sicher nichts passieren wird, und wenn doch, dass man nicht dafür verantwortlich gemacht wird. Nicht darum, das Ausbleiben von Effekten auch wirklich zu garantieren.

Und nicht vergessen: Das war der Fall der vollständigen und korrekten Beschreibung des Changes. Was ist mit Nachlässigkeit, menschlichen Fehlern oder aber auch absichtlicher Manipulation und Täuschung? Spätestens jetzt ist das CAB ein Muster ohne Wert, weil unbekannte Änderungen von fachfremden Menschen in keinem Fall angemessen beurteilt werden können. Management hin oder her. ²

Keine Kontrolle ohne Garantie - und Automatisierung

Kooperative Steuerung funktioniert halt nur, wenn alle kooperieren — das sagt ja schon der Name. Wer sich an alte Betriebssysteme erinnert, die diese Methode verwendet haben³, der erinnert sich an Abstürze. Irgendwas hat immer mal blockiert. Aus dem Grund hat man damals pre-emptives Multitasking entwickelt, eine Methode, die strukturell garantiert, dass es zu keiner Überschreitung kommen kann. Dies ist seitdem der Standard.

Übertragen auf unsere Qualitätssicherung in der Software bedeutet das, dass kooperativ erstellte Change Dokumente und deren Prüfung im Komitee nicht aussagekräftig genug sind, nicht funktionieren können. Sondern vielmehr technische Verfahren auf der Basis von Versionierung, die garantieren, dass keine Änderungen unbemerkt bleiben. Und automatisierte Tests, die bei jeder Änderung jeden nur denkbaren Aspekt eines Softwaresystems testen — ein Aufwand, der manuell überhaupt nicht leistbar wäre.

Oder einfacher: In der Idee der Wasserfall-Methode verhaftete IT-Organisationen und ihre Prozesse sind der Komplexität heutiger Softwaresysteme nicht mehr gewachsen und müssen sich neu aufstellen.⁴ Herkömmliche Test- und Releaseverfahren mit manuellen Prozessschritten und ITIL-basiertem Change Management sind ungeeignet, die Beschaffenheit eines komplexen Systems zu garantieren. Ausschließlich technologische Verfahren sind noch in der Lage, auf der Basis von Versionierung (derzeit mit git) und kontinuierlicher Automatisierung von Test und Deployment (CI/CD) überhaupt die Chance zu geben, die Komplexität in den Griff zu bekommen.

Oder noch einfacher: Alles außer DevOps hat keine Zukunft.