Knigge für Softwarearchitekten

Der Entscheider

Peter Hruschka und Gernot Starke

Nachdem wir in der vorigen Folge die Unsitte des Verschätzens angeprangert haben, möchten wir heute das Thema Entscheidungen angehen. Das Entwicklungsteam muss ein GUI-Framework auswählen, mit dem die Benutzeroberfläche zukünftig entwickelt werden soll. Die Manager fragen, welche Hardware sie einkaufen sollen. Die Architekten müssen bestimmen, welches Protokoll zwischen den Serverkomponenten gesprochen werden soll. Schließlich kommt die Konzernsicherheit und verlangt eine Entscheidung zum Thema Authentifizierung mit SAML oder OAuth. Fragen über Fragen, und alle liegen bei den Softwarearchitekten auf dem Tisch.

Stefan Zörner hat in [1] einen pragmatischen Ratgeber für Entscheidungen und deren Dokumentation vorgestellt, auf dem wir hier aufsetzen. Entscheidungen bilden das Grundgerüst aller Entwürfe – sie gehören untrennbar zu Softwarearchitekturen dazu.

Abb. 1: Struktur von Entscheidungen
Was ist das Problem?

Zuerst klären Sie möglichst genau die Fragestellung oder das Problem, zu der/dem etwas entschieden werden muss. Welche Anforderungen gelten? Unter welchen Rahmen- oder Randbedingungen müssen Sie entscheiden? Was sind Ihre Entscheidungskriterien? Schreiben Sie diese Kriterien in eine Tabelle – dann können Sie daneben direkt die Wichtigkeit oder Priorität jedes Kriteriums vermerken.

Der Knigge als Buch

Die beliebte Java-Magazin-Kolumne „Knigge für Software-architekten“ gibt es jetzt auch als praktisches Kompaktbuch bei entwickler.press!

Die Buchversion wurde um zahlreiche Kapitel ergänzt. Zudem wurden die einzelnen Teile deutlich erweitert und enthalten zusätzliche Praxisberichte, Tipps und Ratschläge!

Der ideale Benimm-Ratgeber für Softwarearchitekten und solche, die es werden wollen!

Jetzt bestellen!

Zwischen Alternativen entscheiden

Wir treffen in IT-Projekten in der Regel Entscheidungen zwischen mehreren Alternativen. Wenn Sie sich also für MySQL als Datenbank entscheiden, so entscheiden Sie sich gleichzeitig gegen die Alternativen Postgres und SQLite. Vor jeder Entscheidung sollten Sie daher die möglichen Alternativen aussuchen und einzeln hinsichtlich sämtlicher Entscheidungskriterien bewerten oder einschätzen. Falls Sie dabei Annahmen treffen müssen oder Ihre Einschätzungen für unsicher halten – dann vermerken Sie dies ausdrücklich!

Entscheidungen treffen und begründen

Bisher haben Sie die Entscheidung lediglich vorbereitet – der oder die Entscheider muss bzw. müssen auf Basis der gesammelten Anforderungen und Einschätzungen nun entscheiden. Stellen Sie eine Matrix mit Alternativen und Kriterien auf und diskutieren Sie mit den Stakeholdern über Bewertungen, Einschätzungen, Vor- und Nachteile sowie Risiken. Dadurch können Sie a priori das gemeinsame Verständnis der Alternativen und ihrer Auswirkungen verbessern. So vorbereitet sollten Sie (oder andere Entscheider) nun die eigentliche Entscheidung treffen können. Für jede Entscheidung haben Entscheider immer Gründe – und genau die sollten Sie auch festhalten.

Der richtige Zeitpunkt

Wann sollten Sie Entscheidungen treffen? So früh wie möglich, um weiterarbeiten zu können? So spät wie möglich, um möglichst viele Informationen sammeln zu können? Timeboxed, d. h. zu einem vorher festgelegten Zeitpunkt?

Entscheidungen „so früh wie möglich“ können ein kollektives Gefühl von Fortschritt und Dynamik im Team bewirken. Gerade zu Beginn einer Entwicklung gibt es oft eine Vielzahl offener Punkte, von denen Sie als Softwarearchitekt einige schnell entscheiden können. Nutzen Sie die kollektive Erfahrung des Teams für solche early decisions. Entscheidungen von außergewöhnlicher Tragweite (Kosten, Aufwände, Risiken) sollten Sie mit mehr Zeit treffen: Bei der Entscheidung zum last responsible moment [2] sammeln Sie möglichst viele Informationen und verzögern die Entscheidung, bis Sie das Entscheidungsrisiko für angemessen halten. Außerdem können Sie Entscheidungen zu einem vorab definierten Zeitpunkt treffen, d. h. timeboxed: Alle Beteiligten dürfen Ihnen bis dahin ihre jeweiligen Alternativen, Argumente, Risiken oder Wünsche darstellen. Sie müssen sich bis zum Entscheidungszeitpunkt auf Basis dieser Informationen eine Meinung gebildet haben. Schließlich gibt es noch die Variante Entscheidung endlos verzögern, die manchmal aus politischen Gründen oder aus Unsicherheit zum Tragen kommt – das finden wir persönlich eher zweifelhaft.

Alle Varianten haben ihre Fürsprecher, aber Sie selbst müssen für jede Entscheidung mit Relevanz für die Softwarearchitektur einen angemessenen Zeitpunkt finden – was an sich ja schon eine Entscheidung ist. Welche Entscheidungen sind architekturrelevant? Woran können Sie denn erkennen, welche Entscheidungen große Tragweite besitzen und daher gründlicher vorbereitet werden müssen? Statt einer pauschalen Antwort geben wir Ihnen einige Kriterien an die Hand. Aus unserer Sicht erfüllen architektur- oder systemrelevante Entscheidungen eine oder mehrere der folgenden Bedingungen:

  • Sie kosten viel Geld – sofort oder im weiteren Verlauf des Projekts.
  • Sie betreffen viele Stakeholder, beispielsweise große Teile des Entwicklungsteams, alle Tester, das gesamte Management oder alle Anwender.
  • Sie betreffen die Kernfunktionen des Systems.
  • Sie betreffen die wichtigsten Qualitätsziele des Systems.
  • Sie sind inhärent langfristig und lassen sich nur schwer durch neue Entscheidungen ablösen.
  • Sie haben viele Konsequenzen oder Nebenwirkungen innerhalb des Systems.
  • Sie zeigen Konsequenzen an den Außenschnittstellen des Systems, sodass auch Nachbarsysteme von dieser Entscheidung betroffen sein können.
  • Sie gehen über Ihren Erfahrungshorizont (oder den des Teams) hinaus, d. h. Sie betreten mit dieser Entscheidung Neuland.

Entscheidungen brauchen Mut

Häufig werden Sie unter Unsicherheit entscheiden müssen, weil Sie keine Zeit oder Ressourcen haben, sämtliche Eventualitäten oder mögliche Sonderfälle im Vorfeld gründlich zu prüfen. Für solche Entscheidungen brauchen Sie Mut. Sichern Sie zumindest wichtige oder große Risiken vor der Entscheidung ab – und hüten Sie sich vor waghalsigen Entschlüssen. Ein allgemeines Maß dafür können wir Ihnen leider nicht geben – aber Ihre Erfahrung und Ihr Team sind dabei gute Helfer.

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). Seit Jahresanfang ist Gernot auch innoQ-Fellow.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

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