Architekturbewertung schafft Klarheit und Fokus und hilft dabei, Risiken besser einzuschätzen und Entscheidungen abzusichern. Alternativ werden auch gerne die Begriffe Architektur-Review oder Architektur-Evaluation verwendet.

Wer eine Architekturbewertung durchführen möchte, kann zwischen etlichen Methoden wählen, die viele Überlappungen, aber auch einige Spezialisierungen haben. Diese Methoden sind häufig für eine große Bandbreite an Situationen und Herausforderungen geeignet und entsprechend allgemein beschrieben.

In dieser neuen Artikelreihe möchten wir einen Einblick geben in konkrete Situationen aus der Praxis, in denen Architekturbewertung sehr nützlich sein kann. Die konkreten Situationen basieren alle auf realen Projekten und Situationen, die wir erlebt haben, sind aber immer generalisiert und anonymisiert. Pro Artikel beschreiben wir eine Situation und geben für diese Situation konkrete Tipps, wie eine Architekturbewertung durchgeführt werden kann und worauf besonders zu achten ist. In späteren Teilen wird es auch um Situationen wie Streitigkeiten zwischen Auftraggeber und Auftragnehmer, Gerichtsverfahren, Migrationsvorhaben und auch den normalen Entwicklungsalltag gehen.

Situation: Qualitätsdesaster trotz Neuentwicklung und Greenfield

Die beispielhafte Situation

Im Unternehmen Flight Control AG wird ein neues Softwaresystem entwickelt, das in Zukunft zentrale Prozessbereiche des Unternehmens, in der Luftraumüberwachung, bedeutend besser unterstützen soll. Dazu ist der Fachbereich involviert und die interne Entwicklungsorganisation mit ca. 30 Personen.

Das Projekt wurde vor 3,5 Jahren als Greenfield-Projekt gestartet mit Entscheidungsfreiheit, was die Technologien angeht. Das Projekt arbeitet nach agilen Prinzipien, geht in Iterationen vor und stellt regelmäßig einen Zwischenstand der Software dem Fachbereich vor, es wurde allerdings noch kein Softwarestand in die produktive Nutzung überführt. Die Fertigstellung ist für in ca. einem Jahr geplant.

Seit ca. einem Jahr werden aber Probleme deutlich: Erstens scheint die Entwicklung jetzt auf der gefühlten Zielgeraden immer langsamer zu werden. Zweitens treten vermehrt Bugs auf, die länger dauern, bis sie gefixed werden können. Drittens wird jetzt das System zunehmend unter realen Bedingungen und realer Last getestet, was aufzeigt, dass sowohl Stabilität als auch Performance große Probleme machen. Je genauer hingeschaut wird, desto offensichtlicher werden die Probleme und vermeintliche Fixes und Refactorings kosten zwar regelmäßig ganze Sprints, führen aber kaum zu spürbarer Verbesserung bzw. verursachen dann Probleme an anderen Stellen.

Zu Beginn der auftauchenden Probleme wurden diese gerne kleingeredet und mit dem Zwischenstand der Entwicklung erklärt. Es waren einige Abkürzungen genommen worden, um dem Fachbereich neue Funktionalität zu zeigen und dafür auch Kompromisse an Qualität und Qualitätseigenschaften in Kauf genommen worden. Natürlich mit dem festen Versprechen, dass man sich in Kürze darum kümmern würde und dann natürlich wieder alles in geordnete Bahnen zurückgeführt würde.

Lange wurde im Projekt kaum explizite Architekturarbeit gemacht. Die Teams haben sich grobe Ideen überlegt und diese dann umgesetzt. Öfter war es nötig, Lösungen wieder zu überarbeiten, weil sie nur bis zum Ende der nächsten Iteration getragen haben.

Egal an welcher Schraube gedreht wird, die Gesamtqualität scheint sich nicht zu verbessern und so gibt es zunehmend starke Zweifel, ob das Projekt noch „im Plan“ ist und halbwegs pünktlich fertiggestellt werden kann.

Weil es so nicht weitergehen kann, beschließt die Entwicklungsleitung gemeinsam mit dem übergeordneten Management, dass eine externe und neutrale Meinung zum Stand des Systems und insbesondere seiner Architektur eingeholt werden soll. Dazu soll eine Architekturbewertung durchgeführt werden. Damit soll eine bessere Ausgangsbasis für zukünftige Verbesserungen und die Fertigstellung gelegt werden und insbesondere das Big Picture in den Blick genommen werden.

Wie es soweit kommen kann …

Jetzt denken sich viele beim Lesen sicherlich: Soweit hätte es doch nicht kommen müssen oder gar dürfen. Mehr Architekturarbeit wäre doch schon früher unabdingbar gewesen und man hört doch immer, dass Architekturbewertungen schon viel früher sinnvoll sind.

„Software-Architektur ist häufig wie ein Gebäude in dichtem Nebel und lässt sich daher Defizite nicht leicht anmerken“

Stimmt alles: Und trotzdem kommt es in der Praxis immer wieder vor. Die Gründe sind vielfältig:

• Es gibt keinen Standard, woran man sich orientieren muss.
• Es wird zu viel der Prozess optimiert und zu wenig auf die Architektur des Systems geachtet.
• Viele Beteiligte in der Software-Entwicklung haben ziemlich unterschiedliche Vorstellungen rund um Software-Architektur. Wann an der Architektur gearbeitet wird? Wie Architektur designt wird. Wie Architektur dokumentiert wird. Wie viel Architektur genug ist.
• Manchmal fehlt auch einfach das Wissen im Team über saubere Architekturarbeit.

Und so bleiben Defizite in der Software-Architektur oft lange unentdeckt. Oder unausgesprochen. Oder sie werden einfach nicht sauber auf den Punkt gebracht, sodass Gegenmaßnahmen direkt möglich wären. Wenn hinreichend Zeit vergangen ist, werden die daraus resultierenden Probleme sichtbar. Das passiert gleichermaßen bei Neuentwicklungen, in der Weiterentwicklung oder bei einer Migration. Die Defizite in der Software-Architektur sind dann aber trotzdem oft noch nicht klar analysiert und als Ursache identifiziert.

Auch wenn es lange versäumt wurde: Jetzt ist der bestmögliche Zeitpunkt (früher geht nicht mehr, später wäre unverantwortlich), die Lage klar zu analysieren und eine Architekturbewertung durchzuführen und daraus dann fundierte Schlüsse zu ziehen.

Architekturbewertung richtig aufsetzen und durchführen

Initiatoren der Architekturbewertung sind die Entwicklungsleitung gemeinsam mit dem übergeordneten Management.

Ziele und Bewertungsfragen klar herausarbeiten

Jede Architekturbewertung sollte damit starten, dass die Ziele und Bewertungsfragen klar herausgearbeitet sind. Im Fall unseres Beispiels könnten das die folgenden sein:

• Klarheit über die aktuelle Architektur schaffen
  • Sind die zu erreichenden Qualitätsziele genau genug bekannt und einheitlich verstanden?
  • Ist die Architektur angemessen für die Anforderungen und Qualitätsziele?
  • Ist die Architektur angemessen dokumentiert, sodass sie auch hinreichend verstanden und umgesetzt werden kann?
  • Ist die intendierte Architektur auch konsistent im Code umgesetzt?
• Gemeinsame Sichtweise zu Situation und Problemen herausarbeiten
  • Wo gibt es gemeinsame und unterschiedliche Sichtweisen?
  • Was sind mögliche Ursachen in der Entstehung der Probleme?
  • Wie wird die Architektur von Organisation und Vorgehensweise beeinflusst?
• Grundlage für weitere Strategie legen
  • Wie schwerwiegend sind die Probleme?
  • Wie viel Überarbeitung in Architekturkonzepten und im Code ist notwendig?
  • Wie stark ist der Einfluss auf die Erreichung der Gesamtziele im Projekt und wie groß ist die Gefahr des Scheiterns?
  • Inwieweit traut man den aktuellen Akteuren zu, die Probleme lösen zu können?

Relevante Stakeholder involvieren

Aufgrund der umfangreichen Problematik zieht das Bewertungsprojekt eine Involvierung zahlreicher Stakeholder nach sich.

Um die zentralen Anforderungen und vor allem Qualitätsanforderungen noch mal fundiert zu hinterlegen, sollten alle Stakeholdergruppen (Nutzer, Betrieb, Entwicklung, Qualitätssicherung, Management, …) punktuell involviert werden, um präzise ihre Sicht auf die Anforderungen einfließen lassen zu können.

Darüber hinaus muss das Management eng involviert werden wegen der potentiellen Einflüsse auf organisatorische, zeitliche und monetäre Planung.

In die eigentliche Bewertung muss vor allem das Entwicklungsteam, voran Entwicklungsleitung, Architekten, Chefentwickler, … involviert werden.

Benötigte Konfidenz und Maßnahmen festlegen

Aufgrund der Kritikalität der Situation, der Größe des Vorhabens und der länger andauernden Problematik ist eine hohe Konfidenz in die erzielten Ergebnisse notwendig und damit eine tiefere Analyse und Belegung der Findings unumgänglich. Deshalb sind die folgenden Maßnahmen empfohlen, um zu einer hohen Konfidenz zu kommen.

• Einbeziehung von vielen Personen und ihren Sichtweisen
• Sammlung von Fakten und Sichtung von jeglicher verfügbaren Dokumentation (oft muss man nicht alles lesen, man muss aber wissen, was es alles gibt)
• Sichtung des Codes, sowohl stichprobenartig manuell als auch mit Codequalitätstooling als auch Check der Konsistenz von intendierter Architektur und implementierter Architektur
• Abgleich aller verfügbarer Fakten und Zusammensetzung eines Gesamtbilds (Big Picture)
• Ausführliche Diskussion mit Gesprächspartnern
• Einbeziehung von einschlägigen Erfahrungen mit ähnlichen Sachverhalten aus anderen Projekten
• Saubere Dokumentation der Review-Ergebnisse, so dass sie von möglichst vielen Stakeholdern verstanden werden können

Passenden Reviewer auswählen

In dieser kritischen Situation ist ein Reviewer zu empfehlen, der nicht Teil des Entwicklungsteams ist. Das Architektur-Review muss mit möglichst großer Neutralität und Professionalität durchgeführt werden und das ist nur möglich mit der nötigen Distanz. Deshalb sollte eine Person ausgewählt werden, die auch keine enge Bindung zum Projekt hat, eventuell sogar komplett aus einer externen Organisation.

Wegen der Kritikalität sollte der Reviewer umfangreiche Erfahrung mit Architektur-Reviews haben, idealerweise in zahlreichen Unternehmen. Erfahrungen in der konkreten Branche spielen weniger eine Rolle, aber Erfahrungen in der grundsätzlichen Art von Systemen sind hilfreich.

Geeignete Praktiken und Methoden einsetzen

Wegen der umfänglichen Problemlage muss auch die Analyse umfangreicher angelegt werden, weil es meist keine isolierten Probleme und Ursachen gibt, sondern viele Einflussfaktoren und Effekte.

Die tatsächliche Methodik ist aus unserer Erfahrung eher nebensächlich. In der Praxis kombiniert man sowieso Praktiken und Aspekte aus verschiedenen Methoden und fügt sie zu einem sinnvollen Projektvorgehen zusammen, das stark auf die vorliegende Situation zugeschnitten ist.

Deshalb sind hier nur einige Eckpfeiler genannt, die enthalten sein sollten im Architektur-Review

• Konsolidierung und Konsistenzprüfung der Qualitätsanforderungen
  • Gerade bei Projekten, die schon länger laufen und in Qualitätsproblemen stecken, sind häufig die Qualitätsanforderungen viel zu wenig herausgearbeitet, konsolidiert, priorisiert und einheitlich abgestimmt.
  • Als Grundlage einer sauberen Bewertung der Architektur muss diese Basis erst geschaffen werden.
• Analyse der Eignung der Architektur für Anforderungen
  • Gezielte Durchsprache der intendierten Architektur und ihrer Eignung zur Erfüllung der Anforderungen, vor allem der Qualitätsanforderungen
  • Identifikation von bewussten Architekturentscheidungen und Tradeoffs
• Analyse der Architekturdokumentation
  • Sammlung und Durchsicht aller verfügbarer ArchitekturdokumentationPrüfung der Dokumentation hinsichtlich Eignung für das aktuelle Vorhaben
  • Prüfung der Vollständigkeit, Konsistenz, Aktualität, Lesbarkeit, Relevanz der Dokumentation
• Analyse der Konsistenz von Architektur und Code
  • Abgleich, ob die im Code umgesetzte Architektur zur intendierte Architektur passt
  • Analyse des Grads und der Schwere von potentiellen Abweichungen
• Analyse der Code-Qualität
  • Grober manueller und Tool-gestützter Check der Code-Qualität (z.B. Einhaltung von Konventionen, Einheitlichkeit, Lesbarkeit, …)
• Analyse im Big Picture
  • Betrachtung von Organisation und Vorgehensweisen
  • Übergeordnete Betrachtung und Analyse aller betrachteten Aspekte, ihrer Querbeziehungen und möglicher Einflussfaktoren

Je nach ganz konkreter Situation und Findings können auch noch weitere Analysen ergänzt werden.

Aufwand realistisch einplanen

Wegen der Größe des Systems, der Kritikalität der Situation, der Menge einzubeziehender Stakeholder und der benötigten Konfidenz wird ein eher höherer Aufwand für das Review einzuplanen sein.

Für den Reviewer kann als Größenordnung des Aufwands ein Spektrum von 15 – 35 Personentagen angenommen werden. Die anderen Beteiligten sind mit geringeren Aufwänden zu involvieren. Stakeholder, die nur Input geben sollen, können jeweils mit 1 bis 3 Stunden veranschlagt werden, die Kernteilnehmer an der Bewertung werden intensiver gebraucht und können jeweils mit 2 bis 4 Personentagen eingeplant werden.

Ergebnisse ehrlich und nützlich interpretieren und aufbereiten

Die Analyse aller notwendigen Aspekte muss sauber durchgeführt werden und führt zu zahlreichen Fakten und Findings. Damit lässt sich aber noch wenig anfangen.

Reviewer müssen sich intensiv damit beschäftigen, wie die Erkenntnisse zu interpretieren sind und diese dann so aufbereiten, dass sie von möglichst vielen Stakeholdern gut nachvollzogen werden können. Dafür ist einiges an Aggregation und Zusammenfassung nötig. Trotzdem muss immer klar nachvollziehbar bleiben, auf welche Erkenntnisse sich bestimmte Schlüsse und Empfehlungen stützen. Diese Art der Aufbereitung braucht signifikant Zeit und sollte auch mit anderen Personen durchgesprochen werden, um die Verständlichkeit und Wirkung sicherzustellen.

Eventuell braucht es auch für unterschiedliche Zielgruppen unterschiedliche Präsentationen mit unterschiedlichem Detailgrad und Schwerpunkt.

Bei diesem Schritt ist die Neutralität von Reviewern noch mal besonders wichtig. Die Ergebnisse müssen klar, neutral und ehrlich präsentiert werden und zugleich muss darauf geachtet werden, dass keine Personen dadurch angegriffen werden. Dies kann zu einer Gratwanderung führen, weil die aktuelle Situation direkt oder indirekt immer von handelnden Personen verursacht oder beeinflusst wurde und erfordert deswegen viel Fingerspitzengefühl.

Spezifische Tipps für die konkrete Architekturbewertung

Basierend auf vielen Bewertungsprojekten in einer ähnlichen Situation nennen wir hier noch einige spezifische Tipps, die über die allgemeine Methodik hinausgehen.

• Sehr klar kommunizieren, warum die Architekturbewertung gemacht wird und wie sie gemacht werden soll, um Befürchtungen und Ängsten entgegenzuwirken.
• Auch wenn bestimmte grundlegende Aspekte nicht wie geplant gemacht werden können (z.B. die Konsolidierung der Qualitätsanforderungen an zu wenig Tiefe scheitert), trotzdem die anderen Analysen zu einem gewissen Grad durchführen, um ein Gesamtbild zeichnen zu können.
• Im Voraus das Vorgehen grob planen, inklusive Stakeholder und Praktiken. Dann aber genügend Spielraum lassen, um auf die gefundenen Erkenntnisse zu reagieren und das Vorgehen anzupassen.
• Darauf gefasst sein, dass manche Stakeholder die Ergebnisse anzweifeln oder in komplett anderer Art interpretieren. Deshalb ist gute Fundierung der Analyse und Interpretation unabdingbar.
• Die Architekturbewertung zielstrebig durchziehen: Wegen der vielen Aktivitäten und beteiligten Leute wird es mindestens ein paar Wochen dauern. Es sollte sich aber nicht ewig hinziehen, weil in dieser Zeit sich die Probleme nur weiter anhäufen und noch nichts dagegen getan wird.
• Dafür sorgen, dass die Ergebnisse und Verbesserungsvorschläge tatsächlich ernstgenommen werden und zeitnah in konkreten Aktionen münden. Ansonsten entsteht viel Frust bei den Beteiligten, die sich engagiert haben, aber keine Veränderungen sehen.
• Bereit sein zu größeren Veränderungen: Wenn die Situation so problematisch ist wie im Beispiel, dann lässt sie sich meistens nicht durch minimale Kurskorrekturen beheben.

Fazit

„Wir machen ein Architektur-Review“ hört sich nach Standard an, ist es aber nicht. Mit dieser ersten Beispielsituation haben wir erläutert, wie wichtig es ist, von einem sauberen Verständnis der Ausgangssituation und der Ziele ausgehend, ein passendes Vorgehen aus Methoden und Praktiken zusammenzustellen. Nur so kann auf der einen Seite die benötigte Konfidenz erreicht werden und auf der anderen Seite die gebotene Effizienz auf die Straße gebracht werden.

Richtig aufgesetzt und ehrlich durchgeführt sind Architektur-Reviews ein mächtiges Werkzeug, mit dem in unterschiedlichsten Projektsituationen Klarheit und eine gute Entscheidungsgrundlage geschaffen werden können. Denn: Es ist nie zu früh, es gleich richtig zu machen. Und selten zu spät.