Heute hörte ich von einem Team das jeden Tag eine .csv Datei mittels FTP herunterlädt, drei Zeilen löscht, und sie dann manuell woanders hin hochlädt.

Wieso? Weil eines Tages diese drei Zeilen nicht richtig in eine Datenbank geladen werden konnten, und ihr Workaround war, diese drei Zeilen eben zu löschen.

Und das machen sie nun Tag für Tag… seit 2009.

Teils natürlich auch einfach deshalb, weil sie in einer regulierten Industrie arbeiten, und dieser Prozeß wurde irgendwann mal dokumentiert und somit verpflichtend.

(Er ist dokumentiert als „workaround für Joe’s Problem“. Keiner kann sich erinnern, wer dieser Joe eigentlich war.)

Diese Geschichte ist einerseits amüsant, andererseits aber auch lehrreich.

Ähnliche Vorgänge finden sich in praktisch jeder Organisation. Seltsame Prozesse, die irgendwann von irgendwem eingeführt wurden, und mittlerweile selbst ein Eigenleben entwickelt haben.

Und unser aller Reflex ist vermutlich, kurzerhand den beschriebenen Prozess zu automatisieren. Das ist sicherlich eine gute Idee: die Qualität wird steigen (weil keiner mal versehentlich was verkehrt macht), die Mitarbeiter Zeit und mentale Kapazität zurückgewinnen für wichtigere, wertschöpfendere Dinge.

Andererseits ist das aber vielleicht gar nicht so eine tolle Lösung: einen etwas merkwürdigen Prozeß haben wir jetzt auch noch verewigt!

In der Tat frage ich mich, ob das dem Workaround zugrundeliegende Problem nicht in den letzten 12 Jahren irgendwann den Weg des Dodo ging. Und falls es noch existiert: ob es nicht eine gelungenere Möglichkeit gibt, diesem Problem zu begegnen, z.B. durch geeignete Validierung in der Datenbank, oder was einem auch sonst so einfällt.

Diese Geschichte weist neben der unmittelbaren Moral (automatisiere es!) aber noch eine zweite, etwas indirektere auf: auch eigenwillige Lösungen sind stets Reaktionen auf reale (oder als real empfundene) Probleme, entwickeln dann aber ein Eigenleben abseits dieser Probleme. Und können somit lange weiterexistieren, nachdem das Problem aufhörte, eines zu sein.

Insofern ist der erste Schritt einer Verbesserung durch Automatisierung ein ganz anderer: sich zu überlegen, ob das Problem weiterhin besteht und ob es weiterhin so gelöst werden muß.

Automation kann eben nicht nur segensreich zur Verringerung der Arbeitslast beitragen, sondern manchmal auch Ungünstiges erst recht zementieren.

„Unsere IT-Organisation führt jetzt DevOps ein“: famous last words. DevOps kommt aus der IT-Ecke, benutzt IT-Begriffe und -Denkweisen. Es ist also naheliegend, es als ein IT-Thema anzusehen.

Zugleich ist diese enge Auslegung eines der heikelsten Themen, die uns in unserer Arbeit regelmäßig begegnet.

Sei es in Schulungen oder in er begleitenden Beratung, die größten Schwierigkeiten zeigen sich erstaunlicherweise nicht in jenen Organisationsteilen, in denen DevOps eingeführt wird. Sondern an den Nahtstellen, wo die agile, DevOps einsetzende Organisation auf jene Unternehmensteile trifft, die sich eben nicht (oder noch nicht) umgestellt haben; seien es benachbarte Entwicklungsorganisation, das Controlling, die Unternehmensleitung, die Personalverwaltung oder gar der Kunde.

In einer Umfrage, die wir unter etlichen hundert IT-Verantwortlichen durchgeführt haben, zeigte sich das gleiche Bild: die größte Überraschung, so teilten viele mit, waren die Spannungen, die sich plötzlich außerhalb der IT auftaten.

Das ist ein derart überraschendes Resultat, daß ich es nochmal wiederholen möchte: die größten Schwierigkeiten mit einer DevOps-Transformation zeigen sich oft gar nicht innerhalb der IT-Organisation, sondern außerhalb davon.

Das klingt vielleicht wie eine schlechte Nachricht, aber eigentlich ist es ein gutes Zeichen: DevOps wirkt! Es führt zu so tiefgreifenden Änderungen darin, wie die IT-Organisation nach außen wirkt, daß andere Bereiche nicht einfach bei der Tagesordnung bleiben können. Sie müssen sich mit diesem Wandel auseinadersetzen: ein hervorragendes Zeichen dafür, wie groß der Unterschied tatsächlich ist.

Ob das nun heißt, daß Euner Controlling nun ein DevOps-Controlling werden muß, ist vielleicht die falsche Frage. Das Wichtige ist, daß Organisation und Prozesse zu den Veränderungen innerhalb der DevOps-Organisation passen.

Wenn auf der einen Seite die Budgetprozesse weiterhin davon ausgehen, zwei-Jahres-Pläne zu verfassen und diese dann systematisch abzuarbeiten, während auf der anderen Seite eine agile Organisation selbstbewußt darauf pocht, den maximalen Kundennutzen erst unterwegs zu erkennen und ihm Rechnung zu tragen — na dann muß es ja in Streit enden, unabhängig davon, wer überhaupt Recht hat!

Eins der großen Themen von DevOps ist Sichtbarkeit: Sichtbarmachen vorn Arbeit, von Zusammenhängen, von Abläufen.

Das ist sicherlich eine gute Sache, kann aber manchmal einen, sagen wir, beunruhigenden Nebeneffekt haben: DevOps Einführungen machen eben auch Dinge sichtbar, die nicht so schön anzuschauen sind.

Das mag verschiedenste Ebenen betreffen: von verbreiteten Schwächen der Unternehmenskultur bis hin zu unsauberem Handwerk einzelner Entwickler.

Konkret ist mir eine Situation in Erinnerung, in der ein Unternehmen continuous integration einführen wollte. An sich keine allzu große Sache, sollte man meinen. Sicherlich muß man etwas Energie hineinstecken, bis alles rund läuft, aber im Regelfall ist diese Umsetzung eher überschaubar.

Nicht so in einem bestimmten Team: dessen Produkt widersetzte sich standhaft allen Versuchen, die builds zu automatisieren.

Zug um Zug stellte sich nämlich heraus, daß sehr viele implizite Annahmen getroffen wurden: über die Art, builds anzustoßen; über Pfade, Nutzer und Rechte; über die Art, wie Parameter übermittelt wurden (auf der Kommandozeile, in Umgebungsvariablen oder in Dateien). Und nicht nur, daß diese Annahmen implizit waren und nun den Automationsentwicklern ohne Vorwarnung um die Ohren flogen, sondern jeder Entwickler hatte seine eigenen Vorlieben (…die sich bei manchen auch noch über die Zeit änderten).

Bald setzte ein allgemeines Grummeln über DevOps im Allgemeinen und Automation im Speziellen ein: kostet wohl doch mehr als von Automationsverfechtern gern angegeben!

Aber die Kosten entstanden natürlich im Wesentlichen nicht aus den Mühen der Build-Automation: sondern daraus, daß nun die technischen Schulden wieder beglichen wurden, die sich über einenm langen Zeitraum aufgebaut hatten.

(Ich weiß übrigens nicht, wie’s in dieser Geschichte ausgegangen ist — ich schied bald darauf aus dem Projekt aus).

Diese Geschichte ist insofern sehr erzählenswert, als sie einem oft beobachteten Muster folgt: die agilen / DevOpslichen Ansätze führen zu mehr Sichtbarkeit — und nicht alles, was man zu sehen bekommt, gefällt einem auch.

Die technischen Schulden waren natürlich schon vorher da, aber jetzt sind sie sichtbar, fühlbar, und müssen behandelt werden.

Vermutlich bringt jegliche Transformation solche Effekte mit sich, aber Agile mit seinem Fokus auf klare Konturen ist da vielleicht besonders… intensiv; im Guten wie im Schlechten.