Worauf es bei Architekturreviews ankommt

Architekturreviews als IT-Managementinstrument

Steffen Fischer, Wilhelm Burtz

© Shutterstock.com/jurgenfr

Architekturreviews sind ein wichtiges Mittel, um Anwendungs-, System- und Integrationsarchitekturen auf den Prüfstand zu setzen. Ihr Ziel besteht darin, eine neutrale und objektive Einschätzung zu erhalten, wie trag- und zukunftsfähig eine Architektur ist und welche Maßnahmen erforderlich sind, eine Architektur auf das Zielbild hin zu entwickeln.

Die Durchführung von Architekturreviews erfordert zum einen Know-how rund um die unterschiedlichen Aspekte von Architekturthemen (z. B. logische und operationale Modelle, Rahmenwerke, Technologiekomponenten). Zum anderen sind aber auch hohe soziale Kompetenzen bei der Durchführung des Reviews vonnöten, um auf die wirklichen Kernprobleme zu stoßen und die Ergebnisse und Handlungsempfehlungen adäquat vermitteln zu können.

Motivation zu Architekturreviews

Jeder guten IT-Lösung liegt eine optimale, tragfähige und stabile Architektur zugrunde, die die fachlichen und nicht

fachlichen (nicht funktionalen) Anforderungen erfüllt. Hierbei fassen die Autoren unter Architektur die gesamte Bandbreite einer IT-Lösung von Fachlichkeit über Anwendungsarchitektur bis hin zur Infrastruktur zusammen. Architekturreviews werden typischerweise aus folgenden Anlässen initiiert:

1. Identifikation von Lücken bei neuen Architekturen
2. Einsparungen an Entwicklungs- und Betriebskosten von IT-Systemen
3. Bewertung der Tragfähigkeit bestehender Architekturen
4. Entscheidungsgrundlage für Investitionsschutz bei Architekturänderungen

Architekturreviews sind im gesamten Lebenszyklus einer IT-Lösung möglich und verfolgen in der Praxis unterschiedliche Zielsetzungen. Im Folgenden gehen die Autoren auf die einzelnen Motivationen zu Architekturreviews detailliert ein.
Kern jedes Architekturreviews ist die Herausarbeitung vor oder zu Beginn des Reviews, welche Frage(n) für wen beantwortet werden muss/müssen, damit das Review fokussiert durchgeführt und letztendlich auf die Zielerreichung hin überprüft werden kann.

1. Identifikation von Lücken bei neuen Architekturen: Zu Beginn eines IT-Projekts wird festgelegt, welche Vorgehensweise respektive Methodik für die Realisierung der Lösung einzusetzen ist. In der Vorgehensweise wiederum sind die technischen Konzepte mit den Architekturartefakten zu finden, die in der recht frühen Designphase eines Projekts zu erstellen sind. Während der Umsetzung/Implementierung müssen diese auf ihre konsequente Einhaltung hin geprüft werden. Die Architekturaspekte werden oft nicht in ausreichender Qualität und in unterschiedlicher Breite und Tiefe beschrieben, nur selten verifiziert oder von technischen Verantwortlichen abgenommen. Dies kann vom Wissensstand und der Erfahrung des beteiligten Architekturteams abhängen, jedoch auch von der Art, wie die eingesetzte Methodik gelebt wird, sowie vom Termindruck im Projekt. Werden Fehler in den technischen Konzepten erst im späten Projektverlauf (z. B. in der Testphase) oder sogar nach Inbetriebnahme eines Systems entdeckt, sind diese nur mit einem hohen Aufwand zu beheben. Diverse Untersuchungen haben gezeigt, dass mit Reviews 85 Prozent der Fehler bei einem 25-prozentigen Gesamtaufwand gefunden werden können. Die Motivation besteht darin, das Risiko von Fehlern in den technischen Konzepten zu minimieren und eventuelle Lücken zu nicht behandelten Architekturaspekten frühzeitig zu identifizieren. Dadurch können nachträgliche Änderungen oder Anpassungen an der Architektur mit weitreichenden Folgen vermieden werden.

2. Einsparungen an Entwicklungs- und Betriebskosten von IT-Systemen: Die traditionellen Phasen einer Software- oder Anwendungsentwicklung bestehen aus Analyse, Spezifikation, Design, Implementierung, Test, Wartung und Betrieb. In der herkömmlichen Entwicklung wird der Fokus erst in der Testphase auf die Fehlerbehebung gelegt. Dadurch, dass die Kosten einer Fehlerbehebung in einer frühen Phase der Entwicklung wesentlich niedriger sind, werden so genannte „frühe“ Architekturreviews auch eingesetzt, um die Entwicklungs- und Betriebskosten in der Gesamtsicht zu senken (siehe dazu folgendes Buch). Die Kosten für Architekturreviews werden von Projektbeteiligten eines zu entwickelnden Systems aus unterschiedlichen Perspektiven betrachtet. So teilen Entwickler die Meinung, dass Architekturreviews nur Zeit und Geld kosten, ohne dabei einen echten Mehrwert zu liefern. Untersuchungen zeigen, dass in einer frühen Projektphase durchgeführte Architekturreviews durchaus zu kosteneffizienten Maßnahmen führen und viel Geld einsparen können. Weitere Auswirkungen sind die Steigerung der Qualität und die Reduzierung von Risiken in den frühen Entwicklungsphasen.

3. Bewertung der Tragfähigkeit bestehender Architekturen: Die Anwendungslandschaft vieler Unternehmen ist über Jahre oder sogar Jahrzehnte hinweg gewachsen. Oft wurden dabei Anforderungen, die es im Rahmen der Weiterentwicklung produktiver Anwendungen umzusetzen galt, nicht unter Einhaltung der Architekturvorgaben realisiert. Die Ursachen dafür können unterschiedlicher Herkunft sein:

• Das Budget für die Realisierung der Anforderungen ist so knapp bemessen, dass nur die fachliche Funktionalität umgesetzt wird und die saubere Einbettung in die bestehende Architektur auf der Strecke bleibt.
• Das Entwicklungsteam wurde während der Weiterentwicklung ausgetauscht und der Wissenstransfer bezüglich der Architektur hat nicht oder nur teilweise stattgefunden.
• Der Termindruck für die Umsetzung neuer Anforderungen war so hoch, dass eher „Balkone“ an eine bestehende Anwendung angebaut wurden, anstatt erforderliche Anpassungen bzw. Erweiterungen der Architektur vorzunehmen.
• Seit der Einführung der Anwendung und deren Weiterentwicklung über viele Jahre hinweg hat kein Re-Engineering der Architektur stattgefunden.

Wenn die Architektur viele Jahre lang vernachlässigt wurde, kommt für jeden IT-Leiter und/oder Systemverantwortlichen der Zeitpunkt, an dem die Stabilität und Tragfähigkeit der Architektur auf den Prüfstand muss. Spätestens wenn sich die Beschwerden der Endbenutzer hinsichtlich Performance, Verfügbarkeit und Zuverlässigkeit einer Anwendung häufen, liegt eine weitere Motivation zum Architekturreview vor.

4. Entscheidungsgrundlage für Investitionsschutz bei Architekturänderungen: Um Synergien in der IT zu schaffen, werden unter anderem gleichartige Anwendungen zusammengelegt. Dies bedeutet, dass Anwendungen komplett oder zumindest in Teilen abgelöst werden und eine bestehende Anwendung diese Funktionalität übernimmt oder eine neue Anwendung hierfür entwickelt wird. Wird eine bestehende Anwendung um Funktionalitäten erweitert, muss diese künftig die Verarbeitung eines höheren Datenaufkommens bewerkstelligen. Deshalb muss vor der Entscheidung eines solchen Vorhabens genau untersucht werden, ob die bestehende Architektur dies auch erfüllen kann. Das Augenmerk ist dabei vor allem auf die Skalierbarkeit der Anwendung zu richten, damit das höhere Datenvolumen in den vorgesehenen Durchlaufzeiten verarbeitet werden kann. Ein Ergebnis kann dabei sein, dass eine Modernisierung der Architektur erforderlich ist, die erhebliche Investitionen voraussetzt. In diesem Fall verbirgt sich hinter der Motivation eines unabhängigen Architekturreviews die Erstellung einer Entscheidungsvorlage für den Investitionsschutz. Die Betonung liegt dabei auf „unabhängig“, um persönliche Interessen einzelner IT-Verantwortlicher zu vermeiden und um ein unternehmensneutrales sowie objektives Ergebnis zu erhalten. Wichtig ist dabei auch die neutrale Einschätzung der Architektur hinsichtlich ihrer Konformität zur strategischen IT-Ausrichtung. So ist es beispielsweise nicht sinnvoll, eine Host-seitige Architektur mit hohem Aufwand zur erweitern, wenn die strategische IT-Ausrichtung eine generelle Ablösung der Host-Anwendungslandschaft vorsieht.

Wichtige Untersuchungsdimensionen

Bei der Beauftragung von Architekturreviews haben Auftraggeber oft nur eine unscharfe Vorstellung davon, was genau untersucht werden soll. Ein Architekturreview bietet eine sehr breite Palette an möglichen Untersuchungsdimensionen, die jedoch in dem vorgesehenen Budget und Zeitfenster nicht alle untergebracht werden können. Es müssen also von vornherein die wichtigsten Untersuchungsdimensionen identifiziert und mit den Reviewbeteiligten festgelegt werden. Dabei sind die Dimensionen der Architektur aus einer fachlichen bzw. funktionalen Perspektive zu beurteilen und den nicht funktionalen Anforderungen des zu entwickelnden Systems zuzuordnen. Aber auch der Entwicklungsprozess kann eine bedeutende Rolle einnehmen, vor allem wenn es um die Dokumentation von Architekturartefakten sowie der Einhaltung von Architekturentscheidungen, -prinzipien und -richtlinien geht.

Architekturkomponenten: Design und Modellierung: Beim Review der Architekturkomponenten wird untersucht, in welche Komponenten (Bausteine) ein System unterteilt wurde, um den fachlichen und technischen Anforderungen gerecht zu werden. Die Granularität und die Abhängigkeiten zwischen den einzelnen Komponenten spiegeln die Komplexität und die fachlichen Zusammenhänge des Systems wider. Eine Einbettung der Komponenten in eine Schichtenarchitektur kann die Komplexität der Abhängigkeiten reduzieren.

In einer Schichtenarchitektur bzw. einem Schichtenmodell werden einzelne Aspekte des Softwaresystems konzeptionell einer Schicht zugeordnet. Die erlaubten Abhängigkeitsbeziehungen zwischen den Aspekten werden bei einer Schichtenarchitektur dahin gehend eingeschränkt, dass Aspekte einer „höheren“ Schicht nur solche „tieferer“ Schichten verwenden dürfen. Eine Schichtenarchitektur kann neben den Vorteilen wie der geringeren/loseren Kopplung der Komponenten, der Erhöhung der Systemflexibilität und dem besseren Architekturverständnis auch einige Nachteile zur Folge haben. Ein Beispiel hierfür sind Performanceeinbußen, die bei solchen Schichten entstehen, die in speziellen Fällen nur als „Durchschleuser“ genutzt werden.

Die Einhaltung einer definierten Schichtenarchitektur kann in großen Projekten eine große Herausforderung darstellen, wenn den Entwicklern nicht die erforderlichen Leitfäden mitgegeben und die entsprechenden „Leitplanken“ gesetzt werden. Frameworks, die den Einsatz einer Model-driven Architecture (MDA) unterstützen, sind hierfür bestens geeignet. Die Ergebnisse aus dem Design und der Modellierung von Komponenten werden dabei in feste Zielstrukturen eingebettet und eine übergreifende Einhaltung der Architektur kann ohne nachträgliche, zeitintensive Verifikationen gewährleistet werden. Nicht funktionale Anforderungen eines Systems: Einen besonderen Schwerpunkt bei allen Architekturreviews bildet die Untersuchung der nicht funktionalen Anforderungen. Damit sind diejenigen Qualitätseigenschaften eines Systems gemeint, die sich nicht direkt aus den geschäftlichen bzw. fachlichen Anforderungen ableiten lassen, sondern eine Aussage zum Verhalten des Systems machen. Da die Liste der nicht funktionalen Anforderungen an ein System sehr lang werden kann, werden hier nur einige genannt:

• Antwortzeiten und Performance
• Skalierbarkeit und Ausfallsicherheit
• Releasefähigkeit
• Zukunftsfähigkeit (bzgl. Stabilität, Technologie und Skills)
• Erweiterbarkeit und Flexibilität

Klassische Methoden zur Untersuchung von Softwarearchitekturen

In der Literatur findet man Informationen zu zahlreichen Methoden, die bei Untersuchungen und Bewertungen von Softwarearchitekturen eingesetzt werden. Bei den meisten dieser Methoden wird zwischen szenariobasierten und metrikorientierten Methoden unterschieden. Die szenariobasierten Methoden nähern sich der Aufgabe der Bewertung einer Softwarearchitektur meist auf einer gröberen Detailebene als Architekturmetriken. Bei metrikorientierten Methoden wird die Softwarearchitektur auf feingranularer Ebene untersucht.

Szenariobasierte Bewertungsverfahren beschreiben die Schritte, über die man zu einer Architekturbewertung gelangt und liefern eine Rechenmethodik oder Messanweisungen. Sie setzen Szenarien ein, um genau zu spezifizieren, was die Projektbeteiligten unter Qualitätsmerkmalen wie z. B. „Änderbarkeit“ verstehen. Dieses Vorgehen ermöglicht es, Qualitätsattribute zu operationalisieren, die in Anforderungsdokumenten oft nur vage und unterschiedlich interpretierbar spezifiziert sind. Demnach lassen sich Szenarien den verschiedenen Qualitätsmerkmalen zuordnen, die sie spezifizieren.

Eine der ersten Verfahren zur szenariobasierten Architekturbewertung ist die von Rick Kazman, Gregory Abowd, Len Bass und Paul Clements entwickelte Methode namens „Software Architecture Analysis Method“ (SAAM). Bei dieser Methode erfolgt eine Klassifikation in direkte und indirekte Szenarien. Die direkten Szenarien lassen sich im System mit der aktuellen Architektur ohne Änderungen durchführen. Szenarien, die das System erst nach Änderungen an der Architektur durchführen kann, werden als indirekte Szenarien betrachtet. Ausgehend von SAAM wurden weitere Methoden mit speziellen Schwerpunkten entwickelt:

• SAAM: Software Architecture Analysis Method
• ESAAMI: Extended Software Architecture Analysis Method by Integration into Domains
• SAAMCS: SAAM Founded on Complex Scenarios
• SAAMER: Software Architecture Analysis Method for Evolution and Reusability

Weitere nennenswerte Methoden, die im Rahmen von Architekturreviews eingesetzt werden, sind:

• ATAM: Architecture Tradeoff Analysis Method
• ARID: Active Reviews for Intermediate Design
• ALMA: Architecture-Level Modifiability Analysis
• QUASAR: Quality Assessment of System Architectures
• SACAM: Software Architecture Comparison Analysis Method

Die Untersuchung von Architekturen anhand von Softwaremetriken erstreckt sich von der Beurteilung der Entwicklungsphasen über die der Phasenergebnisse bis hin zur Beurteilung der eingesetzten Technologien. Von einer neu entwickelten Software werden neben den fachlichen Funktionen auch nicht funktionale Anforderungen wie Wartbarkeit, Erweiterbarkeit oder Verständlichkeit gefordert. Softwaremetriken können dabei keine korrekte Umsetzung der Funktionen bewerten, sondern allenfalls vorherbestimmen, welchen Aufwand die Erstellung der Software in etwa bereiten wird und wie viele Fehler auftreten werden. Der Einsatz von Metriken in der Softwareentwicklung zielt überwiegend auf die Fehlerprognose und die Aufwandschätzung ab. Einfache Metriken zeigen den Umfang des Quellcodes in Zeilen oder Zeichen auf, komplexere Metriken versuchen, die Verständlichkeit des Quellcodes zu beurteilen. Mit einer geeigneten Zahl verschiedener Metriken kann z. B. beurteilt werden, wie aufwändig die Wartung, Weiterentwicklung und anschließende Tests der Software werden.

Eine bewährte Vorgehensweise: IBM Issue Based Consulting

Ein Vorgehensweise für erfolgreiche Architekturreviews stützt sich auf die IBM-Methodik „Issue Based Consulting“. Dieses Vorgehen beinhaltet einen problemorientierten Ansatz für komplexe Beratungsprojekte. Das Ziel liegt darin, den Kunden bei der Problemanalyse zu unterstützen, um die tatsächlichen Ursachen zu identifizieren. Basierend auf den Befunden werden passende und adäquate Empfehlungen ausgearbeitet, aus denen letztendlich kurz- bzw. mittelfristige Maßnahmen abgeleitet werden. Diese Methodik wird in fünf Phasen strukturiert: Definition, Analyse, Bewertung, Empfehlung und Abschluss (Abb. 1). Jede Phase beinhaltet eine detaillierte Planung und Umsetzung der erforderlichen Aufgaben, die zu diesem Zeitpunkt des Architekturreviews durchzuführen sind, und den am Ende der Phase zu erwartenden Ergebnistypen.

Abb. 1: Fünf Phasen des „Issue Based Consultings“

Definition: Wird ein externes Unternehmen für die Durchführung eines Architekturreviews beauftragt, so gilt es in der Definitionsphase, alle vorgesehenen Teilnehmer in einer ersten gemeinsamen Besprechung (Kick-off) an einen Tisch zu bringen. Ziel des Kick-offs ist, dass neben dem persönlichen Kennenlernen auch ein gemeinsames Verständnis der Aufgaben und Erwartungshaltungen geschaffen und die Vorgehensweise vorgestellt wird. Bei der Festlegung der Themenschwerpunkte (z. B. Tragfähigkeit, Performance, Wartbarkeit) können die Interessen der Beteiligten eines Auftraggebers stark auseinandergehen. In solchen Fällen ist es wichtig, einen Konsens über die Reihenfolge bzw. Priorisierung der Themen und die Detailebene für die Untersuchung zu erreichen. Von besonderer Bedeutung ist die Schaffung der Verbindlichkeit, sodass alle Beteiligten die erforderlichen Beiträge (zeitlicher, fachlicher und technischer Natur) zum Architekturreview auch leisten. Wenn vom Reviewteam zum Kick-off bereits eine Planung vorgelegt werden kann, wann jeder der Beteiligten wie viel Kapazität einzubringen hat, ist schon ein wichtiger Grundstein für die Verbindlichkeit gelegt. Die Bereitstellung der Informationen (Dokumente, Architekturdiagramme, Systembeschreibungen etc.), die in den Architekturreview einfließen sollen, findet ebenfalls in dieser frühen Phase statt. Für nicht abgedeckte Themen oder Lücken in den bereitgestellten Dokumenten werden Interviews mit den entsprechenden Verantwortlichen der Themengebiete vorgesehen. Die Ergebnisse dieser Phase sind, dass die vereinbarte Vorgehensweise von allen Beteiligten für die Durchführung des Architekturreviews akzeptiert und unterstützt wird und dass die zu untersuchenden Themenschwerpunkte bzw. Untersuchungsdimensionen festgelegt wurden.

Analyse: In dieser zweiten Phase werden die bereitgestellten Informationen auf die vereinbarten Themenschwerpunkte hin analysiert. Die Anforderungen und architekturrelevanten Konzepte für das zu untersuchende System sollten in schriftlicher Form vorliegen. Um einen effizienten Einstieg in komplexere Systeme zu erhalten, sind auch Schulungsunterlagen sehr hilfreich. Sofern die bereitgestellten Informationen die definierten Themen nicht ausreichend abdecken, können neben den Interviews auch Design-Walkthroughs und Codeinspektionen vorgenommen werden. Bei den Design-Walkthroughs werden konkrete vorgegebene Handlungsabläufe basierend auf den Design- und Architekturartefakten durchgespielt. Dabei erklärt ein Architekturverantwortlicher des zu untersuchenden Systems dem Reviewteam, wo und warum das Design die Interaktionen zwischen Benutzer und System beeinträchtigt. So können Differenzen aus Sicht der Walkthrough-Beteiligten in der Bewältigung von Aufgaben entdeckt werden.

Die Codeinspektionen dienen dazu, eine Verifikation auf der Ebene des Sourcecodes vorzunehmen, um die korrekte Umsetzung der Spezifikation zu überprüfen. Die Durchführung von Codeinspektionen ist sehr zeitintensiv und setzt ein detailliertes Verständnis des Gesamtsystems voraus. Deswegen werden im Rahmen von Architekturreviews eher selten Codeinspektionen durchgeführt. Wenn diese stattfinden, dann oft nur punktuell. Der Fokus liegt hierbei meistens auf der Einhaltung der Schichtentrennung/Modularisierung, der richtigen und effizienten Nutzung von Frameworks und der Wartbarkeit des Codes. Alle in der Analysephase gesammelten Erkenntnisse werden vom Reviewteam zusammengefasst und schematisch dargestellt, um das gewonnene Verständnis mit den Reviewbeteiligten abzustimmen und von diesen bestätigen zu lassen. Das erfolgreiche Ergebnis dieser Phase ist eine ausreichende Informationsgrundlage aus den bereitgestellten Dokumenten.

Bewertung: Im Anschluss an die bewertungsfreie Analyse folgt in der dritten Phase die Bewertung der Architektur- und Designkonzepte. Diese Phase ist an den Themenschwerpunkten ausgerichtet, unter Berücksichtigung der ursprünglichen und eventuell zwischenzeitlich geänderten Anforderungen an das zu untersuchende System. Der wichtigste Aspekt bei einem Architekturreview ist die Identifikation von möglichen Schwachstellen bzw. Problemfeldern und der Abgleich mit Erfahrungen/Best Practices von ähnlichen Systemlösungen. Spätestens zu diesem Zeitpunkt sollte jedem Beteiligten klar sein, dass die Durchführung von Architekturreviews keineswegs mit dem Abhaken einer Checkliste zu vergleichen ist, sondern ein hohes Maß an Architekturkompetenz und -erfahrung des Reviewer-Teams erfordert.

Für identifizierte Schwachstellen kann in dieser Phase auch eine Detailanalyse durchgeführt werden. Die gefundenen möglichen Problemfelder und Risiken sind anschließend mit den Architekturbeteiligten abzustimmen. Mit viel Fingerspitzengefühl müssen die Problemfelder thematisiert werden, ohne „Schuldige“ für deren Ursachen zu suchen. Gelingt dies nicht, kann der ganze Architekturreview darunter leiden. Insbesondere dann, wenn betroffene Reviewbeteiligte, die das Gefühl haben, mitverantwortlich für eines der Problemfelder zu sein, mit Boykott reagieren. Deswegen ist seitens des Reviewteams viel soziale und kommunikative Kompetenz notwendig, um alle Beteiligten „im Boot“ zu behalten. Die identifizierten Problemfelder und Risiken werden nach der Abstimmung als Befunde dokumentiert, die immer auch eine managementgerechte Erläuterung sowie eine Beschreibung der Auswirkungen beinhalten.
Das Ergebnis der Bewertungsphase besteht aus einer Sammlung von identifizierten Problemfeldern und Risiken der Architektur sowie den daraus abgeleiteten, verdichteten und dokumentierten Befunden.

Empfehlung: Liegen die Befunde vor, ist es an der Zeit, mögliche Lösungen für die Behebung der Probleme und/oder Reduzierung der Eintrittswahrscheinlichkeit von identifizierten Risiken auszuarbeiten. Das Reviewteam leitet nun aus den Befunden so genannte Handlungsempfehlungen ab. Diese werden anhand der Aufwände und Implikationen klassifiziert, um daraus wiederum kurz- oder mittelfristige Maßnahmen definieren zu können. Bei den kurzfristigen Maßnahmen handelt es sich um die notwendigen Vorkehrungen für das Erreichen bzw. Erhalten der Handlungsfähigkeit einer Anwendung oder eines Systems. Es sind die Maßnahmen, bei denen das Reviewteam davon ausgeht, dass sich gute und wertvolle Ergebnisse mit begrenztem Aufwand erzielen lassen. Die mittelfristigen Maßnahmen zielen hingegen auf aufwändige und umfangreiche Eingriffe in das Gesamtsystem ab, um mittelfristig eine System- oder Plattformoptimierung zu erreichen.

Für die Ausarbeitung der Handlungsempfehlungen ist es durchaus von Vorteil, eventuell von der Handlungsempfehlung Betroffene miteinzubinden. So sollte z. B. bei einer Änderung in der Testarchitektur auch der dafür zuständige Betrieb involviert werden.
Wenn der Review von einem externen Team durchgeführt wird, sind in dieser Phase die Ergebnisse wie die Handlungsempfehlungen, Aufwände und deren Implikationen mit den Reviewbeteiligten abzustimmen. Besonders bei den Implikationen kann die Reichweite unterschiedlich wahrgenommen werden. Des Weiteren sollte bei der Berechnung der Aufwände die Schätzmethode des betroffenen Unternehmens auch mitberücksichtigt werden.

Abschluss: Die fünfte und letzte Phase eines Architekturreviews nach der Methodik IBM Issue Based Consulting bildet den Abschluss. Dabei geht es darum, die Abschlusspräsentation vorzubereiten und eventuell noch offene Abstimmungen zu den Befunden und Handlungsempfehlungen zu finalisieren. Dies bedeutet, dass die wichtigsten und dringendsten Handlungsempfehlungen mit adäquaten Maßnahmen vorgestellt werden. Selbstverständlich sind alle Ergebnisse so aufzubereiten, dass auf bestimmte Anfragen hin jederzeit Bezug auf die entsprechenden Handlungsempfehlungen genommen werden kann. Die Entscheidung für die nächsten Schritte ist dem Management des Auftraggebers zu überlassen, dennoch gehört ein Vorschlag seitens des Reviewteams zum Abschluss dazu. Das Gremium für die Abschlusspräsentation ist in enger Abstimmung mit dem Auftraggeber festzulegen. Somit wird der Architekturreview mit der Abschlusspräsentation und der Übergabe einer vollständigen Dokumentation der Ergebnisse aller Phasen beendet.

Erfolgsfaktoren

Anforderungen an das Reviewteam: Ernsthafte Architekturreviews sind mit einem kleinen Projekt zu vergleichen. Dieses besteht in der Regel aus den Stakeholdern, einem Reviewteam und den so genannten Reviewbeteiligten. Die Stakeholder sind die Sponsoren aus dem Management, die den Review in Auftrag geben und die Ziele definieren. Das Reviewteam ist für die methodische Durchführung der Untersuchung verantwortlich und die Reviewbeteiligten sind die Vertreter bzw. Ansprechpartner aus den unterschiedlichen Bereichen des Auftraggebers. Bei der Durchführung eines Architekturreviews handelt es sich nicht um die Abarbeitung einer vorgefertigten Checkliste, sondern um das Planen, Organisieren, Koordinieren und Durchführen einer Untersuchung, bei der mehrere Stakeholder und Beteiligte mit unterschiedlichen Interessen vertreten sein können. Somit spielen die Anforderungen an das Reviewteam hinsichtlich der Erfolgsfaktoren eine signifikante Rolle.

Die Architekturkompetenz, gebildet aus Wissen und Erfahrung mit IT-Architekturen, ist die Basis der Anforderungen an das Reviewteam. Für die Durchführung des Reviews sind neben den methodischen und analytischen Kenntnissen auch planerische und organisatorische Fähigkeiten erforderlich. Hinzu kommen die sozialen Kompetenzen sowie die konstruktive Kritikfähigkeit, um alle Reviewbeteiligten stets richtig abzuholen und über den gesamten Zeitraum des Reviews „im Boot“ zu behalten. Da während eines Architekturreviews sowohl mit Fach- und IT-Experten als auch mit den Führungsebenen bis hin zum C-Level-Management Informationen ausgetauscht werden, sind die kommunikativen Fähigkeiten von wesentlicher Bedeutung – spätestens bei der Ausarbeitung und Präsentation der Ergebnisse.

Auswahl der richtigen Reviewbeteiligten: Zu einem Architekturreview gehört neben der Analyse von dokumentierten Informationen auch der Austausch mit Vertretern bzw. Ansprechpartnern der zu untersuchenden Anwendung, des Systems oder der Plattform. Der Aus-tausch erfolgt basierend auf Interviews, um zusätzliche Informationen zu den zu analysierenden Schwerpunkten zu erfragen oder um die identifizierten Problemfelder oder Handlungsempfehlungen abzustimmen. Hier sind Vertreter aus den Fachbereichen sowie der IT (Strategie, Entwicklung und Betrieb) erforderlich, wobei aus beiden Bereichen Experten- und/oder Managementvertreter einzubinden sind. Je kooperativer und je konsequenter die Zusammenarbeit während des Reviews verläuft, desto erfolgversprechender sind auch die Ergebnisse.

Beispiel: Ein Reviewbeteiligter hat die Architektur eines zu untersuchenden Systems federführend mitgestaltet. Obwohl sich die Anforderungen des Systems im Laufe der Zeit geändert haben und die Architektur hierfür nun nicht mehr passt, hält er nach wie vor an ihr fest und kann mit alternativen Lösungsansätzen nicht umgehen. In einem solchen Fall sollte man überlegen, ob er der richtige Ansprechpartner für die Abstimmung der Handlungsempfehlung ist. Es besteht die Gefahr, dass er sich durch die Empfehlung, seine Lösung durch eine alternative zu ersetzen, persönlich angegriffen fühlt. Einen Verantwortlichen mit einer objektiven Haltung zu den Lösungsansätzen zu involvieren, wäre in einer solchen Situation für den Architekturreview sicherlich die bessere Wahl.

Inhalt der methodischen Vorgehensweise: Zur Durchführung eines Architekturreviews gehört weit mehr als ein Leitfaden zur methodischen Vorgehensweise. Vorlagen für unterschiedliche zu erstellende Artefakte ermöglichen es dem Reviewteam, sich auf die Kernaufgabe zu konzentrieren und nicht Überlegungen oder Abstimmungen vorzunehmen, wie etwas zu dokumentieren ist. Dies beginnt bei der Vorlage für das Kick-off-Meeting mit den erforderlichen Inhalten eines Architekturreviews und reicht über die nachvollziehbare Dokumentation der Befunde und Handlungsempfehlungen bis hin zum Kriterienkatalog für die Priorisierung aus unterschiedlichen Perspektiven.

Offene Kommunikation: Bevor ein Architekturreview ins Leben gerufen wird, ist dieser von den Stakeholdern in den betroffenen Bereichen anzukündigen. Findet diese Ankündigung nicht statt und/oder sind die Ziele des Reviews nicht bekannt, besteht die Gefahr, dass einige Mitarbeiter den Eindruck erhalten, durch den Review würde die Qualität ihrer Ergebnisse in Frage gestellt. In manchen Fällen können Ergebnisse des Reviews auch Existenzängste bei Mitarbeitern mit „Kopfmonopolen“ auslösen. Letzteres kann der Fall sein, wenn etwa das Ergebnis eines Reviews lautet, eine unflexible Architektur auf einer veralteten Technologie in eine dynamische Architektur auf einer modernen Technologie zu überführen. Bei einer solchen Transformation kann es sein, dass „Kopfmonopole“ ihre Position aufgeben müssen. Für Mitarbeiter, die evtl. nicht umgeschult werden können, stellt sich die Frage, wie ihre Zukunft aussieht, wenn das Wissen zur alten Technologie nicht mehr erforderlich ist. Explizite Hinweise darauf, dass Architekturreviews nicht die persönlichen Leistungen einzelner Mitarbeiter in Frage stellen, sondern sich auf bestimmte geschäftliche, technische oder strategische Ziele konzentrieren, tragen wesentlich zum Erfolg eines Reviews bei.

Zusammenfassung

Architekturreviews sind ein wichtiges IT-Managementinstrument und unterstützen als solches eine Vielzahl von Zielen. Wichtig dabei ist, dass die Zielsetzung des Reviews früh geklärt wird, damit es bei der Durchführung und der Bewertung der Ergebnisse nicht zu Missverständnissen kommt. Aus der Erfahrung der Autoren ist der kritischste Erfolgsfaktor jedoch das eingesetzte Team, das den Review durchführt. Neben der unbestritten wichtigen technischen Kompetenz und einem großen und langjährigen Erfahrungsschatz ist es die soziale Kompetenz, alle Stakeholder des Reviews zu identifizieren und deren Bedürfnisse zu verstehen. Eine gute inhaltliche Methodik bildet die „Karosserie“ des Reviews und leitet das Team effizient durch alle Phasen. Der Philosoph Rousseau formulierte es treffend, ohne dass es zu seiner Zeit schon Architekturreviews gab: „Man muss viel gelernt haben, um über das, was man nicht weiß, fragen zu können“.

Aufmacherbild: Computer Key – Review von Shutterstock.com / Urheberrecht: jurgenfr

Geschrieben von
Steffen Fischer
Steffen Fischer ist IT-Architekt bei der Provinzial Rheinland Versicherung AG. Seine inhaltlichen Schwerpunkte sind im Bereich Enterprise-Architekturen und Architekturmanagement. Er hat langjährige Erfahrung als Chefarchitekt in komplexen IT-Projekten im Finanzdienstleistungssektor und ist zertifiziert als Open Group Certified Distinguished Chief IT Architect.
Wilhelm Burtz
Wilhelm Burtz ist IT-Architekt bei den IBM Global Business Services. Sein Schwerpunkt als Open Group Certified Sernior IT Architect ist die Erstellung von Anwendungs- und Integrationsarchitekturen sowie deren Umsetzung auf Java-/JEE-Technologie. Er verantwortet als Lead-Architect diverse Global-Delivery-Projekte (Off- und Nearshore) in den Sektoren Versicherungen, Handel und Automotive.Mail: wilhelm.burtz@de.ibm.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: