caffeinating, calculating, computerating

Softwarearchitekten haben viel zu tun. Wenn man nach dem Lehrplan für den Certified Professional for Software Architecture des International Software Architecture Qualification Board geht, brauchen Software-Architekten mindestens die folgenden Fähigkeiten:

  • Anforderungen und Randbedingungen klären, hinterfragen und bei Bedarf verfeinern. Hierzu zählen neben den funktionalen Anforderungen (required features) insbesondere die geforderten Qualitätsmerkmale (required constraints).
  • Strukturentscheidungen hinsichtlich Systemzerlegung und Bausteinstruktur treffen, dabei Abhängigkeiten und Schnittstellen zwischen den Bausteinen festlegen.
  • Übergreifende technische Konzepte entscheiden (beispielsweise Persistenz, Kommunikation, GUI) und bei Bedarf umsetzen.
  • Softwarearchitektur auf Basis von Sichten, Architekturmustern und technischen Konzepten kommunizieren und dokumentieren
  • Umsetzung und Implementierung der Architektur begleiten
  • Rückmeldungen der beteiligten Stakeholder bei Bedarf in die Architektur einarbeiten
  • Konsistenz von Quellcode und Softwarearchitektur prüfen und sicherstellen
  • Softwarearchitektur bewerten, insbesondere hinsichtlich Risiken bezüglich der geforderten Qualitätsmerkmale

Philippe Kruchten hat so seine eigene Liste, was Software-Architekten alles können müssen:

  • Architektur des Systems definieren
  • Integrität der Architektur sicherstellen
  • Technische Risiken erkennen
  • Risikomanagement-Strategien entwickeln
  • An der Projektplanung teilnehmen
  • Reihenfolge und Inhalt von Iterationen vorschlagen
  • Consulting für Design-, Implementierungs- und Integrations-Teams
  • Produktmarketing mit neuen Visionen unterstützen

Entscheidungen treffen Software-Architekten oft im Dunkeln, mit mangelnder Information. Ralph Johnson sagte dazu:

Architektur ist die Menge von Entscheidungen, von denen Sie wünschten, Sie könnten sie früh im Projekt richtig treffen (aber bei denen die Wahrscheinlichkeit, sie richtig zu treffen, nicht notwendigerweise größer ist als bei jeder anderen Entscheidung).

Das ist alles ziemlich viel für eine Person, oder? Wie wäre es, wenn man Softwarearchitektur auf agile Weise durch ein cross functional team finden und bearbeiten ließe? Sozusagen die Architekturlast auf mehrere Schultern verteilte?

Dazu mehr in einem späteren Blogbeitrag.