Reports

Architekturreviews als wesentliches IT-Managementinstrument

Lesezeit: ca. Artikel drucken
Zurück

Architekturreviews sind ein wichtiges Instrument, um die Qualität von Anwendungs-, System- und Integrationsarchitekturen kritisch zu bewerten. 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, die bestehende Anwendungs- und Systemlandschaft auf ein Zielbild hin zu entwickeln.

Der Kunde

Unser Kunde ist eine große deutsche Kapitalanlagegesellschaft mit 4,5 Millionen Kunden, rd. 1.200 Fonds und über 3.000 Mitarbeitern.

Ausgangslage

Seit 5 Jahren setzte die Fondgesellschaft die Vorgaben des Schreibens 239 des Baseler Ausschusses für Bankenaufsicht (BCBS 239) um. Dies erfolgte durch die Einführung einer zentralen Datenverarbeitung und Konsolidierung der Daten aus unterschiedlichen Datenquellen und mit der Einführung eines neuen DQM-Systems zur Qualitätssicherung der Daten vor dem Versand an die konsolidierende Mutter. Das Hauptaugenmerk lag dabei auf der Einhaltung der Konzernvorgaben zur Umsetzung von BCBS 239. Diese Vorgaben schnürten in der gebotenen Eile ein relativ enges Korsett und eröffneten der Fondgesellschaft zu wenig Freiraum für die individuell notwendigen Architekturfragestellungen.

Um dieser Anforderung gerecht zu werden, wurde der Architekturreview im Rahmen der BCBS 239 Umsetzung initiiert.

Projektleistung

Der Architekturreview wurde kurz vor Ende des BCBS 239 Projekts initiiert. Ziel des Reviews war es, einerseits die durch die neu implementierte IT-Lösung entstandenen Lücken zu identifizieren und andererseits die Tragfähigkeit der neu aus dem Projekt resultierenden Integrationsarchitektur zu bewerten. Ein weiterer Untersuchungsschwerpunkt lag in der Verankerung von IT-Strukturen und Prozesse in der Linienorganisation.

Abbildung 1: Vorgehensmodell zur Architekturbewertung (ATAM)

Der Review umfasste vier Kernthemen, die bewertet werden sollten:
Als Grundlage für den Review wurde der Architekturstandard arc42 verwendet. Die Durchführung des Reviews erfolgte in Anlehnung an das Vorgehensmodell des Software Engineering Institutes Architecture Tradeoff Analysis Method (ATAM) vgl. Abbildung 1.

  • ITSM-Prozesse
  • Systemlandschaft & Tools
  • Design Pattern

Die Herausforderung in der Praxis besteht insbesondere darin, nach einem Quality Driven Design Ansatz, Unterschiede in der Bewertung architektureller Qualitätsziele zu identifizieren.

Hierzu wurden aus den ISO-Softwarequalitätskriterien der sogenannte „Qualitätsbaum“ extrahiert, in dem jeder Stakeholder für sich eine Rangfolge („Qualitätshitparade“) festlegt, die dann im Kick Off auf eine gemeinsame Top 5 konsolidiert wurde. Hiervon abgeleitet entstand dann die Bewertungsmethode, bestehend aus Qualitätszielen und Qualitätskriterien.

In Form von Workshops wurden dann die verschiedenen Architektursichten auf die festgelegten Bewertungskriterien hin untersucht und bewertet. Ergebnis sind Maßnahmenvorschläge zur Erreichung von Qualitätsszenarien, d.h. basierend auf diesen Schlussfolgerungen und Befunden wurden entsprechende Empfehlungen und Vorschläge ausgesprochen, um die aktuelle Situation zu verbessern.

Abbildung 2: Der Weg vom Reviewscope zu Maßnahmenemfehlungen

Diese Maßnahmen wurden in einem nächsten Schritt, gemeinsam mit den Architekten und Fachbereichen, priorisiert, um zum einen die Dringlichkeit der einzelnen Maßnahmen anzuzeigen und zum anderen einen Zeitrahmen zur Umsetzung vorzugeben. Jeder Maßnahme wurde eine dedizierte Person zugewiesen und in einen Maßnahmenbehandlungsplan überführt.

Fazit

Voraussetzung für ein erfolgreiches Architektur-Review ist die Besetzung eines kompetenten Bewertungsteams, das auch über die nötigen Soft Skills verfügt die unterschiedlichen Meinungen innerhalb der Kundenorganisation zusammenzuführen und die Analyse zu orchestrieren.

Die Umsetzung erster Sofort-Maßnahmen aus dem Maßnahmenbehandlungsplan, im Rahmen des Reviews hat zu bemerkenswerten Ergebnissen geführt. Wesentliche Lücken in der Architektur konnten noch vor dem BCBS 239 Projektende behoben werden. Defizite bei der Betriebsübergabe und im laufenden Betrieb, die nach Projektende aufgetreten wären, wurden rechtzeitig identifiziert und behoben.

Relevante Architekturleitplanken (u. a. arc42 als Dokumentationsvorgabe) und wichtige Projektziele (u. a. Erstellung der Hitparade der Qualitätsanforderungen am Anfang jedes Projektes) wurden zusätzlich unternehmensweit definiert und verankert.

Als Lessons Learned wurde für alle künftigen Projekte und bei Veränderungen von Betriebsprozessen vereinbart, die Architekten frühzeitig, bestenfalls von Anfang an, entsprechend einzubinden.

tomoro Taskforce Ansprechpartner