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
• Architekturbewertung aus der Praxis (2): Dienstleister liefert schlechte Qualität

Situation: Architekturentscheidungen vor Gericht

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 HardCredit) 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	~ 40 – 80 Personentage, eventuell auch mehr
Aufwand für sonstige Beteiligte	Auftraggeber: ~ 20 – 30 Personentage Auftragnehmer: ~ 10 – 25 Personentage

Beispielhafte Situation

Die Situation für diesen Artikel hat viele Überlappungen mit der aus Teil 2 – Dienstleister liefert schlechte Qualität. Deshalb verwende ich hier auch die gleichen Unternehmen, die Situation spitzt sich aber zum Ende schärfer zu und endet vor Gericht.

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. HardCredit 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 HardCredit 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. HardCredit macht aber klar, dass eine Projektfortsetzung nur infrage kommt, wenn SuperSoft kooperativ ist bei der Analyse und Bewertung des aktuellen Stands.

Die Architekturbewertung durch einen neutralen Gutachter zeigt drastische Probleme auf. Die Qualitätsanforderungen wurden nicht systematisch erhoben und verstanden und es gibt keine Architekturkonzeption, die diesen Namen überhaupt verdient hätte. Für zahlreiche im Review präzisierte Qualitätsanforderungen gibt es keine geeigneten Architekturlösungen und die Code-Qualität ist auch schwach.

Nachdem der Gutachter diese Ergebnisse dem Management von Auftraggeber und Auftragnehmer vorgestellt hat, beschließt der Auftraggeber HardCredit, das Entwicklungsprojekt mit SuperSoft zu stoppen. Einerseits weil der zu investierende Aufwand zu groß ist, um überhaupt zu einer funktionierenden Lösung zu kommen. Andererseits, weil jegliches Vertrauen fehlt, dass SuperSoft in der Lage wäre, die Situation in den Griff zu bekommen.

HardCredit hätte gerne einen Großteil der schon gezahlten Summe zurück. SuperSoft hingegen besteht auf der vollständigen Erfüllung des Vertrags und hätte gerne auch noch die Restsumme.

Weil sich die beiden Firmen nicht auf eine gemeinsame Einschätzung und Lösung der Lage einigen können, kommt es zu einem Gerichtsverfahren. Für dieses Gerichtsverfahren möchte HardCredit vom bisherigen Gutachter ein sogenanntes Parteigutachten erstellen lassen, um vor Gericht die Problematik der Situation darzulegen.

Architekturbewertung richtig aufsetzen und durchführen

Initiatoren der ursprünglichen Architekturbewertung ist 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.

Wie diese ursprüngliche Architekturbewertung aufgesetzt werden kann, ist in Architekturbewertung aus der Praxis (2): Dienstleister liefert schlechte Qualität zu lesen.

In unserem speziellen Fall wird nach der Entscheidung, dass eine gerichtliche Klärung notwendig wird, eine weitere Ausarbeitung notwendig, um das Gutachten als Parteigutachten vor Gericht einreichen zu können.

Diese Ausgestaltung ist im Interesse von HardCredit und wird deswegen von HardCredit angestoßen und (vor-)finanziert. An dieser Stelle ändert sich die Interessenslage etwas, weil das ursprünglich möglichst neutral erarbeitete Gutachten jetzt etwas stärker die Interessen von HardCredit unterstützen soll.

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.

Wurde das erste Audit durch einen gemeinsam beauftragten Gutachter erstellt, gibt es möglicherweise einen Interessenskonflikt dieser Person, weil sie für beide Firmen tätig war. Je nach Konstellation ist eventuell ein weiterer Gutachter notwendig, der auf dem ersten Gutachten aufsetzt.

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

Basierend auf dem initialen Gutachten geht es im Parteigutachten, das vor Gericht verwendet werden soll, vor allem um folgende weitere Punkte:

• Darstellung für Außenstehende
  • Einordnung des Gesamtprojekts und seines Schwierigkeitsgrads
  • Skizzierung der Projekthistorie und der zunehmenden Probleme
  • Rollen- und Aufgabenverteilung im Projekt
  • Übersetzung und Interpretation der tiefen IT-technischen Sachverhalte für Nicht-IT-Experten
• Kritikalität der Situation
  • Klare Formulierung der gefundenen Probleme und ihrer Konsequenzen
  • Vergleich mit anderen IT-Vorhaben und dortigen Situationen
• Abweichungen vom Erwartbaren
  • Was kann man von einem IT-Dienstleister erwarten?
  • In Ermangelung von verbindlichen Standards: Was kann man als Best Practice voraussetzen?
  • Darstellung vor dem Hintergrund des geschlossenen Vertrags
• Erläuterungen zu Ursachen
  • 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?
  • Gibt es Hinweise auf mangelnde Sorgfalt oder mangelnde Qualifikation?
• Gründe für den geplanten Projektabbruch
  • Warum ist die Chance einer „Rettung“ zu gering?
  • Warum traut man es den Projektbeteiligten nicht zu, das Projekt zu retten?

Relevante Stakeholder involvieren

Für das Parteigutachten muss HardCredit insbesondere sein Management-Team involvieren, inklusive der Vertrags- und Einkaufsabteilung. Außerdem werden eventuell noch mal Detailfragen zu klären sein.

Stakeholder der Gegenseite werden sehr wahrscheinlich nicht zur Verfügung stehen, das heißt, dass der Gutachter eigenständig eine tiefere Untersuchung von Artefakten wie Code und Dokumentation vornehmen muss.

Benötigte Konfidenz und Maßnahmen festlegen

Aufgrund der Kritikalität der Situation, der Größe des Vorhabens, zweier beteiligter Unternehmen und der länger andauernden Problematik ist eine sehr 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)
• Saubere Rekonstruktion des Zustandekommens der Situation
• 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.
• 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.

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. Der Aufwand hier ist für das initiale Audit und den Ausbau zum Parteigutachten zu verstehen.

Für den (bzw. die Reviewer) kann als Größenordnung des Aufwands ein Spektrum von ungefähr 40 – 80 Personentagen angenommen werden, in speziellen Situationen könnte der Aufwand auch noch darüber liegen.

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. Und vor allem nicht des Parteigutachtens.

Reviewer müssen sich intensiv damit beschäftigen, wie die Erkenntnisse zu interpretieren sind und diese dann so aufbereiten, dass sie von außenstehenden und mit den Organisationen, dem Projekt und der Softwareentwicklung weniger vertrauten 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.

Weil 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 Vertrauen in das Entwicklungsteam und seine Fähigkeiten fehlt und es deshalb sehr wahrscheinlich auch mit viel mehr Zeit und Budget die Probleme nicht wird lösen können. 

Bei diesem Schritt hat ein Reviewer im Parteigutachten die Interessen seines Auftraggebers im Blick. Trotzdem ist es stark anzuraten, eine möglichst objektive und stark mit Fakten untermauerte Argumentationslinie zu verfolgen. Eine Gratwanderung entsteht immer dort, wo herausgestellt werden soll, dass man eine Rettung der Situation den jeweiligen Akteuren nicht mehr zutraut. Es ist schwierig, dies losgelöst von Personen zu argumentieren.

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.
• Die Interaktion mit Anwälten des Auftragnehmers einkalkulieren. Je nach Vorgehensweise haben Anwälte bestimmte Vorstellungen von Argumentationslinien, die aber nicht unbedingt fundiert belegt werden können. In diesen Fällen sollten Gutachter immer objektiv bleiben und auf belegbaren Argumentationslinien bestehen. Diese Interaktion kann zu mehreren Schleifen führen und signifikant viel Zeit kosten.
• Mit ambitionierten Zeitplänen rechnen: Oft wurde im Vorhinein recht viel Zeit vergeudet, bis tatsächlich der Entschluss gefasst ist, vor Gericht zu ziehen. Dann soll vieles ganz schnell gehen. Ein Reviewer muss trotzdem auf machbaren Zeitplänen bestehen, um keine kontraproduktiven Kompromisse in der Qualität des Gutachtens einzugehen.
• 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 zu sprechen. Vor allem die Story jenseits der tiefen technischen Analyse muss sehr klar aufgebaut und schlussgefolgert sein.
• Überlegen, wie die Gegenseite argumentieren würde und versuchen, diese Argumente proaktiv aufzugreifen und einzuordnen.

Fazit

Auch SuperSoft könnte natürlich ein Parteigutachten in Auftrag geben. Die Inhalte wären sehr wahrscheinlich an vielen Stellen unterschiedlich, vor allem in der Darstellung der Kritikalität und der Ursachen. Vor allem würde sich SuperSoft möglicherweise sehr stark auf mangelnde Inputs bei den Anforderungen stürzen und versuchen zu argumentieren, warum es gar nicht besser gegangen wäre. In der Praxis ist es häufig so, dass die Fehler nicht ausschließlich auf einer Seite liegen, auch wenn es schon oft deutliche Ungleichgewichte darin gibt, welche Seite wie viel zu den Problemen beigetragen hat. Dann hängt es auch am Berufsethos des Gutachters, inwieweit er die Situation sehr einseitig zugunsten seines Mandanten darstellen möchte. Da IT-Experten keine Anwälte sind, sondern eher Ingenieure liegt ihnen eine objektive Darstellung meist sehr stark am Herzen.

Zusätzlich könnte vom Gericht auch ein unabhängiges Gutachten in Auftrag gegeben werden. Dieses Gutachten hat sehr viele Ähnlichkeiten zu der oben beschriebenen Vorgehensweise, im Detail hat der Gutachter aber eine andere Rolle und muss mit der notwendigen Distanz sich alle Fakten für die Analyse und Interpretation besorgen.

„Wir machen ein Architektur-Review“ hört sich nach Standard an, ist es aber nicht. Mit dieser dritten Beispielsituation haben wir einen besonders herausfordernden Fall erläutert, der zeigt, wie eine angepasste Vorgehensweise ist. Richtig aufgesetzt und ehrlich durchgeführt sind Architektur-Reviews ein mächtiges Werkzeug, mit dem auch in kritischsten Projektsituationen dazu beigetragen werden kann, Klarheit zu schaffen.