Kapitel 10. Kollektiv erarbeitete Architekturprinzipien
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Im vorigen Kapitel habe ich dargelegt, dass eine Technologiestrategie zwar für eine wirksame Abstimmung unerlässlich ist, dass sie aber selten spezifisch genug ist, um die tägliche Entscheidungsfindung in Bezug auf die Architektur zu leiten, insbesondere bei der Beantwortung der Frage "Wie werden wir das machen?" Hierfür ist ein höheres Maß an Detailgenauigkeit bei der gemeinsamen Vereinbarung erforderlich.
In diesem Kapitel wird eine Möglichkeit vorgestellt, dieses Detail zu erreichen: die explizite Erfassung von Architekturprinzipien - die Schlüsselverpflichtungen, der dritte Ausrichtungsmechanismus -, die deutlich machen, wie ihr gemeinsam beabsichtigt, eure Softwaresysteme zu konstruieren und zu betreiben. Ich stelle dir vor, wie gute architektonische Prinzipien aussehen, wie sie in den Beratungsprozess passen, wie du sie von den Teams bekommst und wie sie sich im Laufe der Zeit weiterentwickeln.
Das Vorhandensein von architektonischen Grundsätzen mindert die drei Warnzeichen einer fehlenden grundlegenden Einigung: Entscheidungen, die zu einer Verdoppelung von nicht differenzierenden Bemühungen führen, wiederholte Debatten über dieselben grundlegenden Punkte und technische Entscheidungen, die Vorrang vor funktionalen Entscheidungen haben.