Entscheidungen im richtigen Rahmen treffen

By 3. Mai 2016 April 24th, 2017 Inhaltliches

Entscheidungen
„Warum habt ihr das so gemacht?“ – Dies ist so oder abgewandelt die wahrscheinlich häufigste Frage, die rund um Architekturentscheidungen gestellt wird. Natürlich benutze ich sie auch gerne mit als Erstes, wenn ich in ein neues Team komme. Mein Antrieb ist dabei herauszufinden, welche Alternativen betrachtet wurden und welche Rahmenbedingungen und Einflüsse rund um die Entscheidung vorgeherrscht haben. Denn sehr wahrscheinlich sind diese Faktoren auch für zukünftige Entscheidungen wichtig!

In einer idealen Welt dokumentieren Projektteams ihre getroffenen Architekturentscheidungen sorgfältig, so dass jeder bei Bedarf darauf Zugriff hat. Wenn ich als Neuankömmling eine nicht dokumentierte Entscheidung aus der Vergangenheit nachvollziehen möchte, fehlen mir erst einmal wichtige Informationen. Aus dem Code kann ich ablesen, wie die Entscheidung letztendlich ausgefallen ist – vorausgesetzt es gibt eine konsistent durchgehaltene Lösung. Die betrachteten Alternativen finde ich durch Gespräche mit den beteiligten Personen heraus – in den meisten Fällen erfolgreich. Als Letztes stelle ich noch die Frage, warum es genau diese Alternativen waren. Was wurde bewusst ausgeschlossen? Warum wurde Framework XY nicht berücksichtigt? Die Begründung dafür finde ich nur in den Einflussfaktoren für eine Entscheidung:

  • Rahmenbedingungen: Welche Vorgaben müssen eingehalten werden? Z.B.: Steht nur ein kurzer Zeitraum bis zum Zeitpunkt der Entscheidung zur Verfügung? Ist das Budget begrenzt? Welche Technologien dürfen auf keinen Fall eingesetzt werden wegen Vorgaben von außen?
  • Qualitätsziele und -szenarien: Welche Qualitätsziele meiner Software möchte ich mit der Entscheidung erreichen oder unterstützen? Gibt es konkrete Qualitätsszenarien, die ich mit der Entscheidung verknüpfen kann?
  • Risiken: Welchen Risiken möchte ich durch die Entscheidung begegnen?

Diese Fragen helfen mir dabei, die Entscheidungen aus der Vergangenheit richtig zu beurteilen und zu sehen, wo überhaupt Spielräume für Entscheidungen vorhanden waren und was schon von Außen vorgegeben war. Ab und zu stelle ich auch fest, dass eine Entscheidung gar nicht getroffen, sondern tatsächlich vorgegeben wurde.
Ich möchte das anhand der Frage „Welche Programmiersprache wählen wir für unser System ABC?“ verdeutlichen: In einem Projekt auf der „grünen Wiese“ gibt es dafür viele Alternativen: Java, Ruby, C/C++, C#, PHP, JavaScript, etc. Ich bin erst einmal nicht eingeschränkt. Doch die wenigsten Projekte starten auf der grünen Wiese und nach und nach fallen so Alternativen durch äußere Einflüsse weg. Oft sind die Präferenzen und Erfahrungen des Teams für diese Fragestellung entscheidend. Die folgende Abbildung zeigt Einflüsse auf die Entscheidung in Form von Rahmenbedingungen, Qualitätszielen und Risiken.

Einflüsse auf Entscheidungen

Im Extremfall wird meine Entscheidung von außen so stark eingeschränkt, dass sie zur Rahmenbedingung wird. Die Entscheidung wird alternativlos und ist de-facto keine Entscheidung mehr. Wenn ich das in einem Projekt feststelle, begebe ich mich auf die Suche nach weiteren relevanten Fragestellungen. Hier achte ich wieder darauf, dass realistische Alternativen betrachtet werden, die die Qualitäten meines Systems fördern und im durch die Stakeholder vorgegebenen Rahmen liegen.

Zu guter Letzt kümmere ich mich noch um die Dokumentation der nachvollziehbaren Entscheidung, damit der nächste neue Projektmitarbeiter schneller die Antwort findet auf: „Warum habt ihr das so gemacht?“

Leave a Reply