Software Berater Logo Software Berater #neuland seit 1993

As Code!

Digitales Arbeiten

Wo Genauigkeit gefragt ist, da helfen Code-basierte Verfahren. Quelltext kann man versionieren, Änderungen zusammenführen, Qualitätssichern und wenn nötig exakt reproduzieren. Wenn wir weniger Nerv wollen, weniger unnötige Arbeit und mehr Präzision, dann sollten wir uns die Methoden und Werkzeuge anschauen, die unsere Branche dafür in den vergangenen 60 Jahren entwickelt hat: Prozesse und Tools zur Softwareentwicklung lassen sich nicht nur zum Programmieren, sondern auch für andere Arbeiten (nicht nur) in der IT sinnvoll einsetzen.

Infrastruktur as Code ist ein gutes Beispiel. Anstatt Firewalls und Switche, Server und Betriebssysteme oder Storage und Anwendungsdaten von Hand zu konfigurieren, schreibt man Skripte, die das erledigen.

  • Das Skript läuft schneller, als der Mensch klickt
  • Skripte machen keine Flüchtigkeitsfehler
  • Quelltext kann man teilen - et voilà schon können mehrere Menschen die Aktionen genau gleich ausführen lassen
  • Quelltext ist im Zweifel die exakteste Dokumentation

Fun fact: Nur wer nach Zeit und Aufwand bezahlt wird, meidet Automatisierung.

Es gibt so viel “as Code”, dass wir inzwischen schon von everything as code sprechen.

  • Architecture as Code provisioniert Middleware, Standardrollen, Security
  • Build as Code ist überhaupt Bedingung für continous Integration. Nur durch build-Automatisierung kann Software immer wieder vollständig gebaut, getestet und deployed werden. Das gab es natürlich schon mit make, aber verteilte Werkzeuge wie Gitlab, Bamboo oder Drone haben heute größeren Anteil.
  • Dependencies as Code beschreibt Umgebungen, Vagrant oder Docker sind Beispiele
  • Infrastructure as Code konfiguriert Netzwerke, Anwendungsserver und führt Deployments durch. Ansible oder Terraform sind Beispiele.
  • Projects as Code (auch Scaffolding) erstellt Boilerplate Code und reduzieren so die Ramp-Up-Zeit
  • Security as Code prüft Zwischenergebnisse auf Vorgaben, zB mit SonarQube oder Veracode
  • Tests as Code erscheinen trivial, aber wo noch hauptsächlich manuell getestet wird (und das ist häufiger als man denkt!) sind Selenium-Skripte plötzlich ein Gamechanger

Wir wissen, wie es geht

Ist ja schon lustig: Wir wissen eigentlich genau, wie man dezentral und asynchron große Mengen von Informationen in Dateien gemeinsam so bearbeitet, dass am Ende ein genau definierter, qualitätsgesicherter Zustand dabei heraus kommt. Ein lauffähiger Binärcode ist nichts anderes als so ein qualitätsgesicherter Zielzustand, und große Softwareprojekte wie Linux integrieren tausende von Menschen, über lange Zeit und auf der ganzen Welt. Mit Software und Quelltexten als deren Basis machen wir das: Versionierung mit Git, Prozesse wie Gitflow, automatische Verarbeitung durch Continous Integration. Coders will code. Anders wäre die parallele Bearbeitung vieler tausend Einzeldateien zu einem funktionieren Ganzen überhaupt nicht möglich.

Wenn wir aber die Artefakte bearbeiten, die ein wenig abseits der Quelltexte stehen, dann fallen wir wieder in überaus unprofessionelle Weise zurück: Wenn in einer Organisation ein Dutzend Leute an Dokumenten zu Richtlinien herumschreiben sollen, dann wird wieder per Email geschickt. Dann gibt es Powerpoint-Onepager 🤮 und schlampig zusammengestellte Word-Dokumente. Dann findet keiner den letzten Stand (Enterprise Architektur 2020 final.ppt.final2 Überarbeitung Vorstand.pptx… anyone?) Warum ärgere ich mich so über Office-Formate?

Weil die vermeintliche Einfachheit dieser Programme non-IT Volk dazu verleitet zu glauben, die so erzeugte hemdsärmelige Schludrigkeit sei akzeptabel und ausreichend. Weil nach dem Prinzip des schwächsten Glieds einer Kette diejenigen die Prozesse rings um “weiche IT” (also Konzepte, Richtlinien und deren Governance) bestimmen, die am wenigsten zur Durchführung der oben erwähnten “harten IT” in der Lage sind. Wer einen Texteditor für schwarze Magie und Gitflow für einen Duschkopf hält, sollte keine IT-Regeln verfassen. Siehe “Die Baumhaus-Regel”

Make weiche IT professionell again

Ich fordere meine Kollegen und Teams dazu auf, bei der Erstellung solcher weicher IT die gleichen Werte und Prinzipien anzuwenden, die wir bei der Softwareerstellung als Bedingung und Konsens erkennen:

  • Wir verpflichten uns zu Qualität.
  • Nicht auffindbare Information ist nutzlos.
  • Transparenz und Offenheit sind die Basis für Zusammenarbeit. Relevante Dokumentation ist ein Muss.
  • Wir arbeiten asynchron und parallel in stabilen Prozessen.
  • Automatisierbare Tätigkeiten werden automatisiert.
  • Wir sichern Qualität mindestens (aber nicht nur) durch automatische Verfahren.

Wir sind streng bei dem, was wir tun, und offen bei dem, was wir von anderen akzeptieren.

Wenn ein Artefakt also durch viele Bearbeiter und/oder über längere Zeit zusammengestellt werden wird, sorgfältig geprüft und langlebig sein soll, dann bietet es sich an, dieses in einem Prozess analog einer Software zu erstellen:

  1. Als Basis des Dokumentes dient Quelltext. Wir verwenden also zB Markdown, AsciiDoc oder LaTeX als Quelle, nutzen PlantUML oder Graphviz für Schaubilder. Daraus kann man HTML oder PDF erzeugen, oder vieles anderes.
  2. Alle Quelltexte aller Dokumente liegen in einem gemeinsamen git-Repository. Dieses ist für möglichst jeden (in der Organisation) lesbar.
  3. Autoren arbeiten nach Gitflow entweder mit Feature Branches (direkte Schreibrechte) oder Forks (keine Schreibrechte auf dem Primärrepository) und erzeugen dann einen Pull Request.
  4. CI-Tools führen Rechtschreibprüfung durch, prüfen auf erforderliche Metadaten und wandeln in (Entwurfs-) PDF.
  5. Der Pull Request wird geprüft, ggfs diskutiert, ergänzt und am Ende verworfen oder akzeptiert. Alles das ist ohne Mehraufwand lückenlos versioniert und bei Bedarf auch später nachverfolgbar.
  6. Über develop/master Branches und deren Berechtigung kann ein Freigabesystem implementiert werden.
  7. Der aktuelle Produktionsstand liegt stets auf dem Master-Branch und ist für jeden Interessierten lesbar.
  8. Der Master-Branch wird per CI in leicht konsumierbarer Form (zB als PDF) bei jeder Änderung automatisch publiziert: Auf Laufwerke oder Sharepoint, in Wikis (zB Confluence), als Nachricht per Email oder in MS Teams.

Das Verfahren bietet maximale Transparenz und Offenheit. Als Voraussetzung für die Teilnahme benötigt ein Autor nur einen Git-Client und einen beliebigen Text-Editor. Es skaliert von einem einzelnen Teilnehmer bis hin zu tausenden von Autoren.

So möchte ich arbeiten.