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 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. Bisher erschienen:

Architekturbewertung aus der Praxis (1): Qualitätsdesaster trotz Neuentwicklung

Situation: Dienstleister liefert schlechte Qualität

Um über die einzelnen Artikel der Serie hinweg die wichtigsten Aspekte auf einen Blick zugänglich zu machen, liefern wir hier eine kurze Übersicht der wichtigsten Charakteristika der Architekturbewertung.

Initiator der Architekturbewertung	Projektleiter und Management der Auftraggeberseite
Benötigte Konfidenz	Besonders hoch
Reviewer	Externe Reviewer (1-2) mit langjähriger Review-Erfahrung
Beteiligte Organisationen	Auftraggeber / Kunde (Bank) und Auftragnehmer / Dienstleister (SuperSoft)
Beteiligte Stakeholder	Auftraggeber: Management, Projektleitung, Stakeholder aus Fachbereichen und Betrieb Auftragnehmer: Management, Projektleitung, Entwicklungsteam
Methoden und Praktiken	Qualitätsanforderungen als Szenarien, Überprüfung der Eignung von Architekturentscheidungen, Analyse von konsistenter Umsetzung im Code, Analyse Code-Qualität, … (Praktiken aus RATE, ATAM, DCAR, … kombinierbar)
Aufwand für Reviewer	~ 25 – 60 Personentage, eventuell auch mehr
Aufwand für sonstige Beteiligte	Auftraggeber: ~ 5 – 15 Personentage Auftragnehmer: ~ 10 – 25 Personentage

Beispielhafte Situation

Die Bank HardCredit braucht ein neues Softwaresystem, das in Zukunft zentrale Prozessbereiche des Unternehmens bedeutend besser unterstützen soll. Es wurde der Dienstleister SuperSoft, ein bekanntes und großes Beratungshaus mit Fokus auf Individualentwicklung, beauftragt, das neue System zu bauen. Auf Seiten von HardCredit, gibt es einen Projektleiter zur Koordination auf Auftraggeberseite und relevante Stakeholder können einbezogen werden für die Anforderungsanalyse. Das eigentliche Entwicklungsprojekt und alle dazugehörigen Aufgaben liegen beim Auftragnehmer SuperSoft. Das Projekt wird von einem Team von 60 Personen durchgeführt. Zusätzlich sind auf Auftraggeberseite ca. 20 fachliche Stakeholder in unterschiedlichen Rollen involviert und ein Kernteam aus dem IT-Betrieb, das zukünftig den Betrieb des Systems auch übernehmen soll

Das Projekt wurde vor 2 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 Kunden und dem dortigen Fachbereich vor, es wurde allerdings noch kein Softwarestand in die produktive Nutzung überführt. Die Fertigstellung ist für in ca. zwei Jahren geplant.

Seit ca. 6 Monaten werden Probleme deutlich: Erstens scheint die Entwicklung immer langsamer zu werden. Zweitens wird seit etlichen Monaten jetzt das System zunehmend unter realen Bedingungen und realer Last getestet, vor allem auch mit Fokus auf Qualitätsattribute, was aufzeigt, dass sowohl Stabilität, Verfügbarkeit als auch Performance große Probleme machen. Außerdem macht sich das kundenseitige Betriebsteam Sorgen, die immer komplexer werdende Technologielandschaft, die dem System zugrunde liegt, zukünftig auch beherrschen zu können.

Die Sprint-Reviews mit dem Kunden werden von Mal zu Mal frustrierender, weil kaum noch Fortschritt gezeigt werden kann und der Kunde mittlerweile die kontinuierliche Vertröstung nicht mehr hören möchte. Der Dienstleister kann die Situation und die Gründe nicht solide erläutern und so erodiert das Vertrauen des Auftraggebers in die Fähigkeiten des Dienstleisters, das Projekt überhaupt noch erfolgreich stemmen zu können. Dem Projektteam und vor alldem dem Projektleiter des Dienstleisters ist die Situation unangenehm, sie möchten allerdings vor allem beim eigenen Management nicht schlecht dastehen und den Kundenauftrag nicht verlieren.

Das genaue Entwicklungsvorgehen im Engineering und entstehende interne Artefakte sind für den Kunden gar nicht sichtbar. Die HardBank besitzt zwar alle Rechte an entstehenden Artefakten inklusive des Codes, sie hat aber im Umfeld des Entwicklungsprojekts keine Personen, die in der Tiefe des Entwicklungsvorhabens drinstecken und die Lage und ihre Ursachen durchleuchten könnten.

Weil der Kunde selbst keinen Hebel findet, die Situation in angemessener Tiefe zu untersuchen und dies nicht dem Dienstleister überlassen möchte, soll eine externe und unbeteiligte Person als neutraler Gutachter hinzugezogen werden. Der kundenseitige Projektleiter berichtet regelmäßig an die Bereichsleitung und den Vorstand der HardBank und so wird gemeinsam beschlossen, ein Analyse- und Bewertungsprojekt in Auftrag zu geben. Im Zentrum des Projekts soll eine Architekturbewertung stehen, allerdings ausgedehnt auf die Betrachtung des Entwicklungsvorgehens und weitere potentielle Ursachen der Probleme.

Der Dienstleister SuperSoft wird darüber informiert und zeigt anfänglich Widerwillen, weil klar ist, dass die eigene Arbeit jetzt auf den Prüfstand kommt und durchleuchtet wird. Die HardBank macht aber klar, dass eine Projektfortsetzung nur infrage kommt, wenn SuperSoft kooperativ ist bei der Analyse und Bewertung des aktuellen Stands. So einigen sich beide Unternehmen, das Bewertungsprojekt so schnell wie möglich zu starten und somit eine Ausgangsbasis für zukünftige Verbesserungen und die Fertigstellung zu legen.

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. Wenn ein Unternehmen sich auf einen Dienstleister verlässt, der Spezialist auf diesem Gebiet ist, dürfen solche Situationen doch gar nicht auftreten oder müssen anders gemanaged werden.

Dieser Satz gilt umso mehr in Konstellationen, in denen ein Dienstleister weitestgehend eigenständig in der Auftragsentwicklung arbeitet. Dann werden auftretende Probleme selten direkt kommuniziert und zu nur kurzfristigen Defiziten erklärt. So können Defizite in der Architektur oder auch in der Architekturarbeit lange verborgen bleiben und kommen erst dann, und oft auch nur scheibchenweise, ans Licht, wenn es unvermeidlich ist und die Auswirkungen schon stark spürbar sind.

Trotzdem kommt es in der Praxis immer wieder vor, auch bei professionellen Dienstleistern. 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.
• Saubere Architekturarbeit wird geopfert zugunsten von scheinbar schnellen Fortschritten zu Beginn.
• Architekturartefakte sind oft nicht Gegenstand von Reviews und Übergaben und deshalb genießen sie deutlich weniger Aufmerksamkeit.
• Manchmal fehlt auch einfach das Wissen im Team über saubere Architekturarbeit. Beim Dienstleister gibt es meist Leute mit dem passenden Wissen, aber oft nicht in ausreichender Anzahl und so sind vielleicht keine oder zu wenige im Projekt im Einsatz.

In Auftraggeber-Auftragnehmer-Konstellationen bleiben Defizite in der Software-Architektur oft lange unentdeckt. Wenn hinreichend Zeit vergangen ist, werden die daraus resultierenden Probleme sichtbar.

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 der verantwortliche Projektleiter auf Auftraggeberseite gemeinsam mit dem übergeordneten Management.

In solch kritischen Situationen wird eine Architekturbewertung öfters auch mit den etwas formelleren Begriffen „Audit“ bzw. „Architekturaudit“ oder „Gutachten“ bzw. „Architekturgutachten“ bezeichnet.

Passenden Reviewer auswählen

In dieser kritischen Situation ist ein erfahrener, externer Reviewer unbedingt notwendig. 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. Selbst wenn es auf Auftraggeberseite in der Organisation erfahrene Architekten oder gar Architektur-Reviewer gäbe, sollten diese nicht zum Einsatz kommen, weil es notwendig ist, potentielle Probleme auf Seiten des Auftraggebers auch zutage zu fördern. Außerdem muss für den Auftragnehmer zugesichert werden, dass das Review neutral durchgeführt wird und keine einseitigen Zuweisungen von Problemursachen zustande kommen.

Idealerweise können sich Auftraggeber und Auftragnehmer auch gemeinsam auf einen Reviewer einigen und diesen auch gemeinsam beauftragen. Dadurch wird das Risiko von unbalancierten Ergebnissen weiter reduziert.

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 sehr hilfreich. Wegen der Kritikalität der Lage ist es eventuell auch anzuraten, ein Team von zwei Reviewern einzusetzen, sodass diese die Möglichkeit haben, noch mehr mitzubekommen und sich im Zuge der Informationssammlung und Analyse auch immer wieder auszutauschen.

Ziele und Bewertungsfragen klar herausarbeiten

Jede Architekturbewertung sollte damit starten, dass die Ziele und Bewertungsfragen klar herausgearbeitet sind. Weil die HardBank nicht über die tiefe Expertise in Softwarearchitektur und Softwareprojekten verfügt, sollte eine saubere Formulierung der Zielsetzung vor allem durch den ausgewählten Reviewer unterstützt werden.

Im Fall unseres Beispiels könnten das die folgenden Zielsetzungen sein:

• Klarheit über die aktuelle Architektur schaffen
  • Sind die zu erreichenden Qualitätsziele und -anforderungen 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?
• Umgebende Einflüsse und Ursachen analysieren
  • Wie wird die Architektur von Organisation und Vorgehensweise beeinflusst?
  • Gibt es Auffälligkeiten in der Vorgehensweise und in anderen Disziplinen, z.B. dem Requirementsengineering oder der Qualitätssicherung?
  • Wie ist die Zusammenarbeit zwischen Auftragnehmer und Auftraggeber organisiert?
  • Was sind mögliche Ursachen in der Entstehung der Probleme?
• 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 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 auf beiden Seiten 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, zweiter beteiligter Unternehmen 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ügbaren 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 Interpretation, Dokumentation und Präsentation der Review-Ergebnisse, so dass sie von möglichst vielen Stakeholdern verstanden werden können

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.
  • Eventuell zeigt sich dabei, dass der Auftraggeber seine Qualitätsanforderungen überhaupt nicht klar benennen kann oder dass sich immer wieder fundamentale Änderungen ergeben.
  • Vor allem bezüglich der Anforderungen, sowohl Qualitätsanforderungen als auch funktionale Anforderungen, muss die Zusammenarbeit zwischen Auftragnehmer und Auftraggeber betrachtet werden, weil dort häufig schon zentrale Ursachen der Probleme liegen.
• 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ügbaren Architekturdokumentation
  • Prü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 intendierten 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 Organisationen und Vorgehensweisen, vor allem in der organisationsübergreifenden Zusammenarbeit
  • Ü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. Das klingt nach einer ganzen Menge Holz. Und das ist es auch. Um sich aber einen soliden Überblick zu verschaffen, sind diese Betrachtungen solide zu machen.

Aufwand realistisch einplanen

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

Für den (bzw. die Reviewer) kann als Größenordnung des Aufwands ein Spektrum von ungefähr 25 – 60 Personentagen angenommen werden, in speziellen Situationen könnte der Aufwand auch noch darüber liegen. 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. Das ist aber noch nicht das Ergebnis der Architekturbewertung.

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. So ist zwar nie 100% Objektivität möglich, weil Reviews immer auch auf den Vorerfahrungen der Reviewer basieren. Trotzdem kann durch solide und balancierte Untermauerung mit Fakten ein sehr großer und auch nachvollziehbarer Grad an Objektivität erreicht werden.

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

In dieser kritischen Situation ist vor allem die Kommunikation ans Management auf Auftraggeberseite und Auftragnehmerseite extrem wichtig. Beide Seiten müssen ihre Fragen beantwortet bekommen und müssen eine einheitliche Sichtweise bekommen, die ihnen einen konstruktiven Dialog für die weitere Zusammenarbeit ermöglicht.

Falls die Situation so katastrophal ist, dass eine Lösung nicht mehr realistisch erscheint, muss dies auch klar herausgearbeitet werden. Dass eine Lösung nicht mehr realistisch ist, kann insbesondere daran hängen, dass zur Verfügung stehendes Restbudget und Restzeit viel zu gering sind, weil schon viel zu viel aufgebracht wurde mit nur wenigen und schlechten Ergebnissen. Ein anderer Grund kann sein, dass das Entwicklungsteam einfach nicht die nötigen Fähigkeiten mitbringt und deshalb auch mit viel mehr Zeit und Budget die Probleme nicht wird lösen können. 

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. Und nicht nur einmal: Kommunikation ist über den ganzen Verlauf des Reviews sehr wichtig und so sollte auch jedes Meeting, z.B. um Informationen einzusammeln, noch mal entsprechend sauber eingeordnet werden.
• 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.
• Immer wieder ein paar Schritte zurückgehen und das Gesamtkonstrukt aus Auftraggeber und Auftragnehmer betrachten: Dort können viele Hinweise auf Problematiken in der Vorgehensweise liegen.
• Darauf gefasst sein, dass manche Stakeholder die Ergebnisse anzweifeln oder in komplett anderer Art interpretieren. Deshalb ist gute Fundierung der Analyse und Interpretation unabdingbar.
• Der Interpretation und Aufbereitung der Ergebnisse besonders viel Aufmerksamkeit schenken und passende Runden an Personen auswählen (eher kleine Runden), um intensiv über die Ergebnisse und Handlungsmöglichkeiten zu sprechen.
• 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.
• In solchen Situationen sollten Reviewer auch konkrete Verbesserungsvorschläge und Auswege aufzeigen, weil zumindest die Auftraggeberseite nicht das tiefe Wissen hat, selbst solche Vorschläge zu machen. Die Reviewer sollten auch in die Betrachtung der tieferen Ausgestaltung der Überarbeitung durch den Auftragnehmer eingebunden werden und ihre Einschätzung dazu abgeben, ob die vorgeschlagenen Maßnahmen erfolgversprechend sind.
• 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 zweiten Beispielsituation haben wir erläutert, wie wichtig es ist, eine angepasste Vorgehensweise zu wählen und bei gebotener Kritikalität auch externe Reviewer hinzuzuziehen.

Die besprochene Situation aus diesem Artikel kann auch in vielen Abwandlungen daherkommen: z.B. kommt es öfters vor, dass die Auftraggeberseite auch einige inhaltlich mitarbeitende oder gar steuernde Personen im Projekt hat. Dabei kann es zu den exakt gleichen Symptomen kommen, die Analyse kann allerdings noch komplizierter werden, weil es keine klare Trennung von Verantwortlichkeiten an Organisationsgrenzen mehr gibt. Die reine Betrachtung der Architektur bleibt dann sehr ähnlich, die Erforschung der Ursachen und das Abstellen wird aber unter Umständen schwieriger.

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.