Die Überprüfung

Architekturen müssen nach einheitlichen Gesichtspunkten überprüft werden. Wenn dabei niemand an den Pranger gestellt wird, ist eine Voraussetzung für tief schürfende Analysen gegeben. Der Prozess sollte nicht schwerfällig sein (Stunden, nicht Tage) und als Konversation angelegt sein, nicht als Audit. Architekturen werden überprüft, um festzustellen, ob kritische Mängel vorliegen, gegen die etwas unternommen werden muss – oder um festzustellen, ob bestimmte Bereiche nachgebessert werden können. Am Ende der Überprüfung stehen Maßnahmen, die dem Kunden, der mit dem Workload arbeitet, ein angenehmeres Erlebnis ermöglichen.

Wie bereits im Abschnitt "Architektur-Überlegungen" angesprochen, ist es in Ihrem Interesse, dass jedes Teammitglied Verantwortung für die Qualität der Architektur übernimmt. Wir empfehlen, dass die Teammitglieder, die die Architektur entwerfen, mit Hilfe des Well-Architected Framework ihre Architektur fortlaufend überprüfen, anstatt eine formelle Überprüfungsbesprechung anzusetzen. Findet die Überprüfung fortlaufend statt, können Ihre Teammitglieder parallel mit der Entwicklung der Architektur Antworten aktualisieren und mit jeder neuen Funktion die Architektur verbessern.

AWS Well-Architected ist ähnlich aufgebaut wie der interne AWS-Prozess zur Überprüfung von Systemen und Services. Der architektonische Ansatz wird beeinflusst von konzeptionellen Grundsätzen und Fragen, die sicherstellen, dass Bereiche nicht vernachlässigt werden, die häufig in der Ursachenanalyse auftauchen. Tritt an einem internen System, AWS-Service oder bei einem Kunden ein schwerwiegendes Problem auf, untersuchen wir die Ursachenanalyse auf Verbesserungsmöglichkeiten für unsere Überprüfungsprozesse.

Überprüfungen sollten an wichtigen Meilensteinen des Produktlebenszyklus erfolgen – früh in der Entwurfsphase, um einseitige Türen zu vermeiden.« [ Viele Entscheidungen sind rückgängig umkehrbar (zweiseitig öffnende Türen). Für diese Entscheidungen reicht ein schlanker Prozess. Einseitige Türen sind nur schwerlich oder gar nicht umkehrbar und müssen vor dem Einsetzen genauer inspiziert werden. ] »  Insbesondere kurz vor dem Go-Live. Nach dem Go-Live verändert sich Ihr Workload weiter, da neue Funktionen hinzukommen und Sie Technologieimplementierungen anpassen. Die Architektur eines Workloads verändert sich mit der Zeit. Treffen Sie durchdachte Hygienemaßnahmen, um zu verhindern, dass die Qualität seiner architektonischen Merkmale im Zuge der Weiterentwicklung nachlässt. Wenn Sie an der Architektur signifikante Änderungen vornehmen, müssen Sie bestimmte Hygieneprozesse befolgen, z. B. eine Überprüfung nach dem Well-Architected-Prinzip.

Wenn die Überprüfung als einmalige Momentaufnahme oder unabhängige Messung vorgesehen ist, müssen alle wichtigen Beteiligten in die Konversation eingebunden sein. Häufig ist die Überprüfung der Punkt, an dem einem Team das erste Mal richtig klar wird, was es implementiert hat. Wird der Workload eines anderen Teams überprüft, ist es sinnvoll, mehrere informelle Konversationen über seine Architektur einzuplanen. In diesen Gesprächen erhalten Sie Antworten auf die meisten Fragen. Im Anschluss daran können Sie in ein oder zwei Besprechungen Punkte abklären und ausführlich auf Unklarheiten oder eventuelle Risiken eingehen.

Damit Ihre Besprechungen erfolgreich verlaufen, empfehlen wir folgende Ausstattung:

• Besprechungszimmer mit Whiteboards

• Diagramme und Entwurfsnotizen ausgedruckt auf Papier

• Liste der Fragen, die sich nicht mit herkömmlichen Mitteln beantworten lassen (z. B. Werden die Daten verschlüsselt?)

Nach der Überprüfung sollten Sie eine Liste mit Problemen vorliegen haben. Welche Sie priorisieren, hängt vom geschäftlichen Kontext ab. Berücksichtigen Sie auch, wie sich diese Probleme auf die tägliche Arbeit Ihres Teams auswirken. Wenn Sie die Probleme frühzeitig anpacken, gewinnen Sie vielleicht Zeit. Zeit, in der Sie geschäftlichen Mehrwert schaffen können, anstatt sich um wiederkehrende Probleme zu kümmern. Während Sie die Probleme aus der Welt schaffen, können Sie Ihre Überprüfung aktualisieren und so verfolgen, wie sich die Architektur verbessert.

Wie hilfreich eine Überprüfung war, zeigt sich erst danach. Neue Teams widersetzen sich möglicherweise zuerst. Sie können Einwänden der Teams entgegnen, indem Sie sie über die Vorteile einer Überprüfung aufklären:

• Wir sind zu beschäftigt! (Häufig im Vorfeld großer Produktstarts zu hören.)

  • Wenn ihr euch auf einen großen Launch vorbereitet, sollte der möglichst glatt über die Bühne gehen. Die Überprüfung deckt Schwachstellen auf, die ihr vielleicht übersehen habt.

  • Wir empfehlen, dass ihr früh im Produktzyklus Überprüfungen einbaut, um Risiken aufzudecken und einen Auffangplan auszuarbeiten, der auf die Roadmap für die Feature-Bereitstellung abgestimmt ist.

• Wir haben nicht die Zeit, um mit den Ergebnissen etwas anzufangen! (Oft zu hören, wenn ein unverrückbares Ereignis näher rückt (z. B. eine große Sportveranstaltung), auf das alles ausgerichtet ist.)

  • Diese Ereignisse lassen sich nicht verschieben. Wollt ihr da wirklich reingehen, ohne die Risiken eurer Architektur zu kennen? Selbst wenn ihr nicht alle Probleme wegbekommt, könnt ihr euch immer noch mit Playbooks helfen, wenn sie tatsächlich eintreten.

• We don’t want others to know the secrets of our solution implementation!

  • Wenn Sie die Aufmerksamkeit des Teams auf die Fragen im Well-Architected Framework richten, erkennen sie, dass keine der Fragen kommerziell oder technisch sensible Informationen herauszieht.

Wenn Sie mit Teams aus Ihrer Organisation mehrere Überprüfungen durchführen, identifizieren Sie möglicherweise thematische Fragen. So könnte sich beispielsweise herausstellen, dass mehrere Teams in einer bestimmten Säule oder einem bestimmten Themengebiet mehrere zusammenhängende Probleme haben. Werfen Sie einen ganzheitlichen Blick auf all Ihre Überprüfungen und identifizieren Sie Mechanismen, Trainings oder Principal-Engineer-Vorträge, mit deren Hilfe sich diese thematischen Fragen angehen lassen.