Ein Steckbrief für das Erarbeiten von Fitness-Functions

By 20. März 2020 Inhaltliches

Evolutionäre Architektur ist als Trend schon lange im Gespräch. Konkret finden wir sie zum Beispiel auf dem Technology Radar bei Thoughtworks bereits 2010. Im entsprechenden O’Reilly-Buch von 2017 findet sich diese Definition:

„Eine evolutionäre Architektur unterstützt geleitete, inkrementelle Veränderungen über mehrere Dimensionen hinweg“. (N. Ford, R. Parsons, P. Kua, Patrick: Building Evolutionary Architectures)

Evolutionäre Architektur denkt einige Dinge anders als „klassische“ Softwarearchitektur. So werden dort Architekturentscheidungen nicht als schwer änderbar hingenommen. Stattdessen sind Änderungen in der Architektur aufgrund von Überraschungen willkommen und normal.

Ein Konzept, das eng mit Evolutionärer Architektur verknüpft ist, sind Fitness-Functions. Eine Fitness-Function misst objektiv, wie gut eine Lösung die an sie gesetzten Ziele erreicht. Fitness-Functions unterstützen genau die geleiteten Veränderungen, von denen in der Definition von Evolutionären Architektur die Rede ist. Sind wir mit unserer Lösung (noch) auf dem richtigen Weg? Halten neue Ideen, was sie versprechen? Wie bewerten wir Experimente, zum Beispiel mit neuen Technologien?

SteckbriefIm Rahmen unserer Coaching-Einsätze haben wir einen kleinen Steckbrief (oder „Canvas“) entwickelt, der uns und unsere Kunden bei der Entwicklung von Fitness-Functions unterstützt.

Teilnehmer des Workshops „Die Wirksamkeit Eurer Architektur automatisiert testen“ von Sandra Parsick und mir beim Software Architecture Summit in München dieses Jahr konnten diesen Steckbrief im Rahmen der Übungen für ihre eignen Projekte ausprobieren. Ich möchte dem Wunsch folgen, ihn hier zum Download bereit zu stellen … (Druckvorlage für 3 Steckbriefe inkl. Leitfragen zur Umsetzung).

Wie arbeitet Ihr mit dem Steckbrief? Tatsächlich steht das Erarbeiten und Umsetzen der Fitness Funktion nicht am Anfang. Im Workshop haben wir unser Vorgehen in 6 Schritten skizziert (Details in den Folien, insbesondere auch zu den Kategorien) – zu Beginn stehen die Architekturziele, verfeinert durch Beispielszenarien.

  1. Identifikation der Architekturziele
  2. Ausarbeitung von Beispielszenarien
  3. Auswahl für die Überprüfung
  4. Formulierung der Test-Idee
  5. Umsetzung und Automatisierung der Auswertung
  6. Sichtbarmachen der Resultate

Die Steckbriefe sammeln die Ergebnisse aus den Schritten 1, 2 und 4 im Vorgehen zusammen, und geben Input für 5 und 6. Pro Szenario gibt es dann eine Fitness-Funktion und dafür jeweils einen eigenen Steckbrief. Ausgefüllt sieht das Ganze z.B. so aus:

Fitness-Function Steckbrief, ausgefülltLassen wir uns ein kleines Beispiel durchspielen! Nehmen wir an, Eurer Team entwickelt eine Software, die lange leben soll. Ihr setzt dabei verschiedene Fremdbibliotheken ein. Oft werden diese Abhängigkeiten in Build-Skripten mit einer Version eingepflegt, diese dann aber nie aktualisiert. Was, wenn Ihr auf eine neue Version umsteigen müsst (z.B. weil dort ein Security-Problem gefixt wurde, das für Euch relevant ist …

Wir formulieren daher als Architekturziel zur Kompatibilität:

„Unsere Software läuft mit den aktuellen Versionen der eingesetzten Fremdbibliotheken.“

Das ganze verfeinern wir durch ein Beispielszenario (Über Qualitätsszenarien könnt Ihr z.B. in unserem arc42-Starschnitt nachlesen):

„Ein Open Source Projekt veröffentlicht eine neue Version einer von uns verwendeten Fremdbibliothek. Unsere Software lässt sich ohne Änderungen mit der neuen Version bauen und funktioniert damit einwandfrei.“

Zu diesem Szenario lässt sich eine Fitness Function formulieren, die absichert, dass bei Austausch einer verwendeten Fremdbibliothek x in Version n durch eine neuere Version n+1 die Software weiterhin baut und alle Tests besteht.

Umsetzen und automatisiert Auswerten lässt sich eine entsprechende Test-Idee durch

  1. Online-Überprüfung, ob zu einer Bibliothek eine neue Version verfügbar ist (Scannen der Repos),
  2. gezieltes Update der Bibliothek im Build-File in einem separaten Branch und
  3. Bauen des Branches und Durchlaufen der vorhandenen Tests.

Wenn Bauen und/oder Testen fehlschlagen weiß das Team frühzeitig, dass seine Software mit der neueren Version der Bibliothek nicht ohne Anpassungen funktioniert.

Dependabot bietet die beschriebene Funktion “von Hause aus” an. Wenn Schritt 1 eine neue Version für eine verwendete Abhängigkeit liefert (was Dependabot anhand des Build-Skripts prüft) legt das Werkzeug in GitHub einen eigenen Branch dafür an, modifiziert das Build-Skript, baut und meldet das Ergebnis. Im Erfolgsfall erzeugt es passende Pull-Requests zum Mergen:

Dependabot BeispielDas Team entscheidet, wie es mit dieser Erkenntnis umgeht. Mitunter kann es veraltete Funktionalität (Stichwort “deprecated”) der Fremdbibliothek durch neuere ersetzen, und den Test bestehen, ohne tatsächlich schon ein Update durchzuführen. Oder es stellt das Update als Aktivität unter “technische Schulden beheben” ein.

Bei kontinuierlichem Aktualisieren (oder dem Experimentieren damit) schlummern bei größeren Umbauten (z.B. neue Java-Version) keine unbekannten Risiken, die automatisierte Überprüfung mit Werkzeugen wie Dependabot nimmt dem Team hier Arbeit ab, die sich im Projektgeschäft manuell keiner macht.

Der Steckbrief hilft durch eine Kategorisierung im rechten oberen Bereich, Eure Test-Idee zu schärfen, und zur Umsetzung zu bringen. Die Kategorien sind in den Folien zum Workshop erklärt. Darüber hinaus haben wir ein paar „Leitfragen“ definiert, die Euch bei der Implementierung der Fitness-Funktion helfen. Sie sind auch in der Druckvorlage enthalten.

  • Wann, wie und wo führen wir die Testfunktion aus?
  • Wie kommen wir an die benötigten Daten?
  • Wie werten wir die Daten aus?
  • Was passiert, wenn die Ergebniskontrolle einen Fehler anzeigt?
  • Was passiert, wenn der Test selbst fehlschlägt?
  • Wie kommunizieren wir das Ergebnis ? Wie oft? Und an wen?

Die folgende Abbildung gibt einen Überblick über den Steckbrief und stellt die Bereiche in den Bezug zu den Schritten des Vorgehens oben.

Ausfüllen erklärt

Leave a Reply