Architekturoptionen

„Hättet ihr das nicht früher sagen können, dann hätten wir das System anders gebaut!“. Wie seltsam und frustrierend das Leben in der IT manchmal ist, merkt man, wenn spätestens zum dritten Mal Dinge, die “garantiert nie passieren” werden, dann doch passieren. Schade, wenn dann die Aufwände unnötig hoch sind, um unsere Systeme an diese Veränderung anzupassen.

Architekturoptionen können in solchen Situationen Gold wert sein. Dabei investieren wir zu einem früheren Zeitpunkt für einen günstigen Preis (also vergleichsweise wenig Aufwand) in das Bauen einer Architekturoption (z. B. das Einziehen eines Interfaces), die es uns ermöglicht, später zu einem wesentlich günstigeren Preis eine Option zu ziehen (z. B. das Herauslösen eines Moduls als eigener Microservice).

In diesem Talk erkunden wir den schmalen Grat zwischen Overengineering und fahrlässiger Hartcodierung. Ich werde euch die Theorie der Realoptionen vorstellen und zeigen, wie sie euch als Softwarearchitektinnen oder Softwarearchitekten helfen kann, über Projektrisiken nachzudenken und diese gegebenenfalls abzumildern. Anschließend werden wir uns verschiedene Beispiele für Architekturoptionen ansehen und ihr werdet sehen, dass einige dieser Optionen eine Investition sind, die nahezu jedes Softwaresystem eingehen sollte.

Architekturoptionen

TAGS