Knigge für Software-Architekten

Blick in den Rückspiegel

Peter Hruschka und Gernot Starke

Willkommen in der sechsten Ausgabe unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten.

Fünftes Muster: Blick in den Rückspiegel

Architekten verlassen sich nicht nur auf ihre Erfahrung und ihr Bauchgefühl, sondern nutzen Bewertungsmethoden, um ihre Entwurfsentscheidungen regelmäßig gegen gesetzte Qualitätsziele für die Architektur abzuwägen – und verbessern anhand der Ergebnisse sukzessive ihren Prozess. Als Autofahrer gehört Ihr Blick hauptsächlich nach vorne, in Fahrtrichtung. Trotzdem tun Sie gut daran, immer wieder auch in den Rückspiegel zu schauen. Erstens, um „rundherum“ informiert zu sein und zweitens, um Risiken z. B. beim Überholen oder Abbiegen besser einschätzen zu können. Dieser Blick in den Rückspiegel ist auch für Softwarearchitekten ein essenzielles Erfolgsrezept.

Plan, Do, CHECK, Act

Fragen Sie sich als Softwarearchitekt in regelmäßigen Abständen, ob ihre Entscheidungen und Konzepte die gewünschte Wirkung erzielen. Diese einfache Rückkopplungsschleife bildet die Grundlage der meisten iterativen (neudeutsch: agilen) Prozesse. Der Plan-Do-Check-Act-Kreislauf (PDCA oder Deming, W.E.: „Out of the Crisis“, Massachusetts Institute of Technology, Cambridge 1982) hat den systematischen Rückblick (die Check-Phase) zum System erhoben, aus gutem Grund: Nur Handeln und Entscheiden ohne Reflektion, ohne Rückblick, führt leicht zu Zielverfehlung und Aktionismus. Unser Titel „Rückspiegel“ bezieht sich dabei natürlich auf die Zeitachse Ihrer Projekte, auf der Sie zurückblicken…, aber das haben Sie sich möglicherweise schon gedacht.

Prüfen Sie Ihre Architektur

Bis vor einiger Zeit mussten wir uns den Vorwurf von Tom DeMarco anhören: „Wenn Ihr zwei Architekturen nebeneinanderlegt, wisst Ihr nie, welches die bessere ist!“. Heute haben wir etablierte Methoden, um getroffene Entwurfsentscheidungen und somit den Status Ihrer Architektur zu evaluieren (Clements, P.; Kazman, R; Klein, M.: „Evaluating Software Architectures“, Addison Wesley 2002). Anhand von Qualitätsbäumen – abgeleitet aus den Hauptzielen – bewerten wir systematisch einige Szenarien, die sowohl für den Product Owner wie auch für den Architekten besonders relevant sind. Die Methode ist sehr pragmatisch darauf ausgerichtet, möglichst rasch Chancen und Risiken zu beurteilen. Beim ersten Mal benötigen Sie dazu etwa zwei bis vier Tage. Wenn Sie es zur regelmäßigen Tätigkeit in Ihrem Architekturprozess machen, dann reichen monatlich oder vierteljährlich auch wenige Stunden. Sie prüfen anhand Ihrer Arbeitsergebnisse: Technische Konzepte, Strukturen, Modelle, Dokumentation sowie die darauf basierenden Implementierungen. Erfüllen diese Artefakte Ihre Erwartungen, oder gibt es aus heutiger Sicht noch Verbesserungsbedarf? Mit Verbesserungsbedarf meinen wir sowohl erkannte Fehler, Versäumnisse, Schwachstellen wie auch Risiken.

Beziehen Sie Ihre Stakeholder in diese Rückblicke mit ein: Mindestens das gute alte Vier-Augen-Prinzip sollten Sie beherzigen! Auf Basis erkannter Probleme können Sie nun systematisch Ihre Architektur verbessern. Und wenn Sie keine Probleme finden, können Sie sich immerhin kräftig auf die Schulter klopfen und loben.

Königsdisziplin: Prozessverbesserung

So weit, so gut. Damit erhalten Sie eine zielorientierte Architektur. Aber der Blick in den Rückspiegel leistet noch mehr: Fragen Sie sich für alle erkannten Probleme oder Schwachstellen nach den Gründen, die dazu geführt haben:

  • Sind Sie von nicht zutreffenden Annahmen ausgegangen?
  • Führen die Prozesse in Ihrem Projekt zum gewünschten Ziel?
  • Bereiten die Randbedingungen oder Anforderungen Ihnen ungebührlich viele Probleme?
  • Fehlt Ihnen oder Ihrem Team technisches Know-how?
  • <your-reason-for-specific-problem>

Haben Sie die Gründe für Probleme dank Rückblick erst erkannt, können Sie sich auch hier an die Verbesserung begeben. Dadurch eliminieren Sie ganze Kategorien von Fehlern oder Problemen – viel cooler als immer nur auf Fehler in Produkten zu reagieren!

Wenn Sie als Softwarearchitekt in Ihrer Profession besser werden möchten, wenn Sie mit Ihren Aufgaben wachsen möchten, dann sollten Sie kontinuierlich lernen. Das geht am besten durch systematische Rückblicke (Sie dürfen auch gerne PDCA dazu sagen). Trauen Sie sich, Ihre eigenen suboptimalen Entscheidungen zuzugeben und für die Zukunft daraus zu lernen, bessere Entscheidungen zu treffen. Falls Sie daran Freude gefunden haben, können Sie sich an die ganzheitlichen Retrospektiven wagen, „Agile Retrospectives“ (Derby, Larsen, Pragmatic Bookshelf 2006) ist auch sehr empfehlenswert.

Peter Hruschka und Gernot Starke haben vor einigen Jahren www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse. Mehr finden Sie unter www.systemsguild.com (Peter) und www.gernotstarke.de (Gernot).
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.