Das Scaled Agile Framework (SAFe) von Dean Leffingwell beschreibt agile Vorgehensmuster und die Organisation von Software-Projekten bei großen Vorhaben. Wir reden hier bspw. von 100 und mehr Beteiligten in sogenannten Programmen. Neben modernen Praktiken (agile Teams, Scrum, Product Backlogs, kurzen Iterationen, Kanban, …) gibt es auch einige Restriktionen, um den Gesamt-Unternehmenserfolg im Auge zu behalten. Ziel ist es, die Vielzahl der beteiligten Menschen zu synchronisieren und möglichst Aufwände aufgrund von Abstimmungsproblemen und dem Leben in einer eigenen Team-Welt zu vermeiden.

Ich möchte hier in erster Linie die Software-Architektur der Systeme und Programme bei SAFe beleuchten, ob und welche Rollen benötigt werden und wie die Verantwortlichkeiten aufgeteilt sind.

Im frühen agilen Zeitalter schien der Architekt als eigenständige Rolle nicht mehr vorzukommen. Selbst Martin Fowler, einer der Mitinitiatoren des agilen Manifests, hat 2003 die Frage gestellt:

Who needs an Architect?

Damit hat er als damaliger CTO (Chef Architekt) bei der Firma ThoughtWorks quasi seine eigene Position in Frage gestellt. Aber natürlich bedeutet das Fehlen einer expliziten Architektenrolle bei Scrum oder Extreme Programming (XP) nicht, dass es keine Architekturarbeit mehr in der Software-Entwicklung gibt. Vielmehr ist die Idee der agilen Bewegung, dass sich die Teams primär um den Entwurf der Anwendungslogik kümmern. Man nennt das implizite Architekturentwicklung, Architektur und Design bilden sich sozusagen „nebenbei“ heraus (emergent design). In selbstorganisierten Teams hat keiner mehr die vereinzelte Rolle des klassischen Architekten inne, vielmehr sind alle Entwickler ein bisschen Architekt und bestimmen gleichberechtigt ab.

Nun ist Software-Architektur kein triviales Thema. Es scheitert schon daran, eine einheitliche und allgemein gültige Definition festzulegen. Wer möchte, findet im Netz eine Vielzahl davon. Ohne den Anspruch auf Vollständigkeit könnten wir folgende Eckpunkte zur Definition von Software-Architektur festhalten. Architektur ist …

  • … das Management von Komplexität und Änderbarkeit bei Erfüllung der geforderten Qualitätsmerkmale
  • Zusammenspiel von Komponenten und ihrer Kommunikation untereinander und nach außen …
  • … sich auf das zu konzentrieren, was man nicht mehr leicht losbekommt (nicht günstig ändern kann) …

In der Realität sehen wir uns konfrontiert mit immer komplexer werdenden IT-Systemen, immer höheren Änderungsraten, kürzeren Zeitstrecken und längeren Betriebs- und Weiterentwicklungsphasen. Über den gesamten Lebenszyklus einer Anwendung betrachtet (Entwicklungs-, Einführungs-, Migrations-, Betriebs-, Wartungs- und Weiterentwicklungskosten), macht die Erstentwicklung gerade einmal 10 bis 20 % des Gesamtaufwandes aus. Deshalb ist es so wichtig, für ein System eine Architektur zu entwerfen, welche die richtigen Qualitätskriterien erfüllt, zusätzlich die Komplexität beherrscht, das System aber auch im passenden Maß auf Änderbar- und Erweiterbarkeit auslegt. Und das alles möglichst realisierbar in einem Zeit- und Kostenrahmen, der akzeptabel ist.

Das Big Upfront Design der Wasserfall-Ära konnte das nicht leisten. Darum schlagen die agilen Methoden das Emergent Design vor, welches im Laufe der Entwicklung je nach Anforderungen und möglichen Änderungen die Architektur des Systems entstehen läßt und vor allem weiterentwickelt. Für überschaubare Vorhaben funktioniert Scrum (ohne explizite Architekten-Rolle) auch hervorragend. Wir sind hier aber im Kontext von großen Vorhaben mit 100 (oder sogar x mal 100) beteiligten IT-Mitarbeitern, die eine Gesamtvision vorantreiben, sich dabei aber möglichst wenig stören und beeinflussen sollen. Und da bei einer solchen Vielzahl von Leuten natürlich nicht direkt alle miteinander zusammenarbeiten können, teilt man sie in Teams und Teams von Teams (Agile Release Train in SAFe genannt) ein, die parallel am selben Vorhaben arbeiten. Diese Teams oder einzelne Mitglieder können schwerlich das Gesamtbild überschauen oder jede Änderung in einem benachbarten Team mitbekommen. Hinzu kommen unvorhersehbare Ereignisse, die ebenfalls auf die Entwicklung der Architektur des Systems haben:

  • Produkt- und Systemangleichungen durch Firmenzusammenschlüsse und Übernahmen
  • Zuständsänderungen im Geschäftslebenszyklus
  • Reife-Phasen von Unternehmen (vom Startup zum soliden Anbieter)
  • Notwendigkeit von höherer Zuverlässigkeit und Stabilität

Das Fazit ist, in solch großen Vorhaben braucht es jemanden, der das große Ganze zusammenhält, agile Scrum Vorschriften hin oder her. SAFe führt solche übergeordneten Rollen ein, welche die agilen Teams in ihrer Arbeit unterstützen und deren Arbeitsweisen selbst an modernen Praktiken wie zum Beispiel Kanban orientiert sind. So gibt es auch bei der Architektur eine übergeordnete Strategie und Lenkung, deren Prinzipien, Rollen und Vorgehensweisen wir in den nächsten Blog-Einträgen detaillierter anschauen wollen. Bis bald.