Der Chefinformatiker oder Chief Technology Officer (CTO) erinnert in vielen Unternehmen an einen Jongleur. Er ist dauernd damit beschäftigt, viele Bälle in der Luft respektive Projekte am Laufen zu halten. Praktisch von Projektbeginn an, beginnt die Qualität in fast jedem IT-Projekt zu erodieren. Gleiches gilt für alle eta­blierten Prozesse. Die Ursachen für die Erosionen sind vielfältig. Besonders schlimm ist es, wenn Deadlines nicht ernst genommen, Anforderungen gleich gar nicht gelesen, Algorithmen selber gebastelt, Modelle nicht validiert und verifiziert werden, Code nicht getestet wird – und um­gekehrt irgendwo die Qualität zweckfrei in die Höhe geschraubt wird, Demos immer weiter verbessert werden oder die Release-Geschwindigkeit durch ein Mehr an Kontrollen verlangsamt wird. Aber auch dort, wo einige dieser Sünden strukturell verhindert werden – beispielsweise durch agile Strukturen –, sind die Anti-Patterns im IT-Alltag zahlreich. Viele interne Prozesse besitzen eine ungenügende technische Unterstützung und schaffen deshalb eine mise­rable User Experience für die Ingenieure. Dementsprechend werden sie oft ignoriert.

CTOs können den Kampf gegen diese Erosionskräfte nicht gewinnen, dürfen ihn allerdings auch nicht verlieren. Was tun? Eine Möglichkeit ist, wie beim Computerspiel, den Kampf auf einem höheren Level zu führen. Manche Unternehmen haben schon vor einem Jahrzehnt begonnen, Arbeitsumgebungen für ihre IT zu schaffen, die besonders erosionsfest sind. Sie haben die Bereitstellung von Infrastruktur, das Testen und das Deployment weitgehend oder gänzlich automatisiert und sichergestellt, dass Entwickler mit Echtwelt-Lasten und unterschiedlichen Konfigurationen testen können. Sie sammeln nicht nur ihren gesamten Quellcode in einem Repositorium, sondern ihre Ver­sionsverwaltung stellt zentral alle relevanten Informationen für Entwicklung und Betrieb allen zur Verfügung – inklusive aller Bibliotheken, Skripte, Werkzeuge, Artefakte, Tests und Konfigurationsdateien. Ausserdem erzeugen sie gewohnheitsmässig in allen Bereichen Telemetrie-Daten über Ereignisse und stellen sie visuell aufbereitet allen zur Verfügung, um Probleme zu analysieren und Frühwarnsysteme zu implementieren. Und nicht zuletzt haben sie eine Lernkultur entwickelt, die das Lernen aus dem Scheitern zu einer Selbstverständlichkeit erklärt.

Diese Kombination aus hochentwickelter Automatisierung, Analysewerkzeugen, lernorientierten Prozessen und Systemsteuerungen, sowie ganz vielen Selbstverständlichkeiten, führt dazu, dass es den Unternehmen gelingt, die Erosionsprozesse schrittweise einzudämmen und zu einem Ort zu werden, an dem ingenieursmässig gedacht wird. Ingenieursmässiges Denken beinhaltet die Geschäftsper­spektive, stellt aber die Sache über alles. Sie sucht individuell und im Team nach Erkenntnis, statt nach Macht und Bequemlichkeit. Damit ein Wandel zu einer solchen selbstverständlichen Sachorientierung gelingt, braucht es einen führungsstarken CTO, der eine Balance wahrt zwischen seinem persönlichen Interesse an hoher Engineering-Qualität und pragmatischer Erfolgsorientierung. Gelingt der Wandel aber, so wird aus dem gestressten Jongleur-CTO der Zirkusdirektor im Hintergrund, der mit Genuss und vielleicht auch leichtem Bedauern erlebt, dass er sich selber überflüssig gemacht hat.

Das Bild vom Jongleur und Zirkusdirektor wird leider in der Praxis oft missverstanden. Das eine Missverständnis meint, dass man ein sehr guter Ingenieur sein muss, um ein guter CTO zu sein. Das klingt vernünftig: Kann nicht jeder Jongleur auch Kunststücke mit einer Keule? Ja, aber man muss nicht Keulen herstellen können, um sie zu jonglieren. Es stimmt zwar: Wer selber professionell programmiert hat, tut sich leichter als Projektmanager. Und wer selber Projekte professionell gemanagt hat, tut sich leichter als CTO. Das eine ist aber weder eine notwendige noch eine hinreichende Voraussetzung für das andere. CTOs sind
Manager.

Das andere Missverständnis meint umgekehrt, dass man als CTO eigentlich nur eine Managementausbildung braucht und auch ohne breite und tiefe IT-Kenntnisse ein guter CTO sein kann: Es komme nur auf die richtigen Prozesse und eine gelassene, in sich selbst ruhende Haltung an, so wird argumentiert. Ein guter Zirkusdirektor müsse die Arbeit der Artisten nicht verstehen, sondern sich um deren Gefühle kümmern. Das nennt sich auch post­heroisches Management, garniert mit Achtsamkeit. Das Ergebnis ist aber fast immer eine Geringschätzung von Ingenieursqualität und in der Folge eine schlechte IT. Wer seinen Informatikern achtsam begegnen will, muss sie als das wertschätzen, was sie sind: Ingenieure!

Vieles hat sich in den letzten Jahren verändert. Es fällt schwer, sich vom Liebgewonnenen zu verabschieden und neue Paradigmen anzunehmen. Aber die Technik interessiert sich für solche Gefühle nicht. Ich persönlich habe Unternehmensarchitekturen immer als Boundary Object gesehen, als Objekt zur Vermittlung zwischen IT und Business. Heute muss ich akzeptieren, dass die grosse Kommunikation nie stattfand und stattdessen es nun die kleine Kommunikation zwischen Business-Abteilung und zugeordnetem Micro-Service-Team gibt. Aber welches Architekturmanagement kümmert sich heute um die Gesamt­architektur? Oder ist Komplexitätsmanagement kein Thema mehr, wenn wir eine qualitativ hochwertige Arbeitsumgebung für Ingenieure haben, wie oben skizziert?

Eine andere Frage ist, ob denn eine sorgfältige Modellierung überhaupt noch relevant ist, wenn Anwendungen nach zwei, drei Jahren ohnehin entsorgt werden. Müssen wir bei Qualitätsfragen einen strategischen Tradeoff im Sinn von Michael Porter oder von Kim/Mauborgne anstreben? Das hiesse, jene Qualität anstreben, die den meisten Mehrwert bietet und die anderen Arten von Qualität dafür einsparen. Ein Lösungsansatz, der eine Antwort auf beide Fragen zu geben versucht, ist das Konzept der Fitness-Funktion für evolutionäre Architekturen von Neal Ford, Rebecca Parsons und Patrick Kua. Das Modell adressiert Micro-Service-Architekturen und geht davon aus, dass wir bewusst entscheiden, welche Qualitätsdimensionen relevant sind und welche nicht. Diese Dimensionen sollen anschliessend gemessen werden, grossteils über das Monitoring einer guten, modernen Arbeitsumgebung für Ingenieure.

Ob Fitness-Funktionen sich durchsetzen werden, who knows! Noch immer ist die Kenntnis sogenannter Patterns und die Vermeidung von Anti-Patterns in der Produktentwicklung auf allen Ebenen hoch relevant. Das grosse Thema Architektur wird aber vom ebenso grossen Thema gute Arbeitsumgebung für Ingenieure und Wiederbelebung der traditionellen Ingenieurskultur derzeit verdrängt. Dazu gibt es mehr denn je eine Zwei-Klassen-Gesellschaft: Hier die «technisch reichen» Unternehmen, die auf Automatisieren, Messen und Lernen setzen – dort die «technisch armen» Unternehmen, die nicht einmal ein bewusstes Schuldenmanagement für ihre technischen Schulden betreiben, weil sie solches schlicht von der Geschäftsleitung nicht bezahlt bekommen. Langfristig werden die reichen Unternehmen die armen vom Markt verdrängen.