Kolumne: Knigge für Softwarearchitekten

Der Entscheider

Peter Hruschka, Gernot Starke


Stefan Zörner hat unter [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 EntscheidungenZwischen Alternativen entscheidenEntscheidungen treffen und begründenDer richtige ZeitpunktEntscheidungen „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....

Kolumne: Knigge für Softwarearchitekten

Der Entscheider

Peter Hruschka, Gernot Starke


Stefan Zörner hat unter [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 EntscheidungenZwischen Alternativen entscheidenEntscheidungen treffen und begründenDer richtige ZeitpunktEntscheidungen „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....

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang