Risikomanagement in der Enterprise Architektur

 
Abstract

In der modernen Unternehmensarchitektur spielt die Behandlung von Architekturschulden eine zunehmend größere Rolle. Sie beeinträchtigen mittel- bis langfristig die Flexibilität und Skalierbarkeit der IT-Infrastruktur und fördern dabei die meist ohnehin schon hohe Komplexität. Daher ist es essenziell, systematische Ansätze zur Erfassung von Architekturschulden zu entwickeln, um daraus resultierende Risiken nachhaltig zu behandeln.

Inhalt

Architekturschulden

Schaut man in Unternehmen, die eine Abteilung für Enterprise Architektur betreiben, findet man dort häufig auch eine historisch gewachsene IT-Landschaft vor. Oftmals sind die Systeme technologisch veraltet und in ihrer Wartbarkeit auf absehbare Zeit eingeschränkt. Von der Beherrschbarkeit der Komplexität oder gar von Weiterentwicklungen gemäß der Geschäftsstrategien ganz zu schweigen. Schauen wir uns die Gründe dafür an.

Architekturschulden sind Aufwände für nachträgliche Änderungen zur Erreichung der Zielbebauungsplanung. Sie stellen Abweichungen vom Zielzustand gemäß der Unternehmensstrategien dar. Sie entstehen aus kurzfristigem Denken, unzureichender Planung und fehlender strategischer Ausrichtung der IT-Weiterentwicklung.

Projekte dienen in der Regel dazu, in vorgegebener Zeit und definiertem Budget die benötigten Fähigkeiten mit neuen oder angepassten Funktionaliäten auf IT-Seite umzusetzen. Leider ist am Ende des Projektbudgets meist noch etwas nicht umgesetzter Scope übrig, wie zum Beispiel ein nicht erfolgter Rückbau von Bestandssystemen oder eine für die Zielbebauung wichtige Schnittstelle. Oder es wurde eine Lösung umgesetzt, die zwar aus der Sicht des Projekts auf die schnelle Markteinführung einzahlt, aber weder der fachlichen noch technische Zielbebauung dient. Über Jahre hinweg ausgebliebenes Refactoring, veraltete Codebasen, ineffiziente Datenstrukturen oder sich verändernde nichtfunktionale Anforderungen treiben den Schuldenstand in die Höhe. Die Projektgrößen Zeit, Budget und Scope sind also ein geeigneter Nährboden für Architekturschulden.

Architekturschulden können noch so stabile Konstrukte zum Einsturz bringen und erheblichen Schaden anrichten
Architekturschulden können noch so stabile Konstrukte zum Einsturz bringen und erheblichen Schaden anrichten

Änderungen in den Geschäfts- oder IT-Strategien führen gewöhnlich zu fachlichen und technischen Bebauungsplanungen, damit sich die Landschaft gemäß dieser Strategien weiterentwickeln kann. In der Folge müssen Bestandssysteme angepasst, umgebaut, modernisiert oder erneuert werden. Bleiben diese strategiebedingten Umbauten aus oder werden unzureichend umgesetzt, erhält man ebenfalls einen bunten Strauß an Architekturschulden.

Eine der Hauptaufgaben von Enterprise Architekten ist Kommunikation. Aus eigenen Beobachtungen und vielen Gesprächen mit Architekten und Stakeholdern der Architektur ist abzuleiten, dass die Umsetzung einer Bebauungsplanung von der Umsetzungskraft des Architekturmanagements abhängt. Folglich können Projekte nur auf die Planungen und damit die Strategien einzahlen, wenn sie davon Kenntnis erlangen. Auch ist das Zusammenspiel von Enterprise Architekten mit den Unternehmensstrategen unerlässlich, um frühzeitig gegen die Entstehung von Architekturschulden wirken zu können.

Architekturschulden entstehen also bewusst oder unbewusst auf allen Ebenen. Betroffen sind somit  Business Architektur, Enterprise Architektur,  Lösungsarchitektur, Software- und Betriebsarchitektur. Mit dieser Erkenntnis und dem Bewusstsein über Architekturschulden lassen sich nun Methoden entwickeln, wie damit umzugehen ist.

Unternehmen, die ihre Architekturschulden nicht systematisch behandeln, werden weder den Kampf gegen die Komplexität ihrer IT-Landschaft gewinnen noch eine effiziente, effektive und flexible Landschaft gemäß der Geschäfts- und IT-Strategien bereitstellen können. Reaktionen auf sich verändernde Marktbedingungen sind dann kaum noch wirtschaftlich leistbar.

Wo finden wir Architekturschulden?

Jetzt wissen wir, was Architekturschulden sind und wie sie entstehen. Wir sind uns derer also bewusst. Dies ist eine gute Nachricht, denn wir klettern damit einen wichtigen Schritt in Richtung eines höheren Reifegrads des Architekturmanagements entgegen. Exemplarisch haben ich Orte aufgeführt, an denen üblicherweise die größte Menge an Architekturschulden entdeckt werden kann.

Wie ausgeführt entstehen Architekturschulden häufig in Projekten. Daher ist es sinnvoll Projekte (nachhaltig) anzuweisen für jede getroffene Entscheidung einen sogenannten Architecture Decision Record (ADR) anzulegen und nachvollziehbar die Ableitung der umzusetzenden Lösung zu begründen. Neben den ADRs sind Schulden in Dokumentationen, Projektprotokollen, E-Mails oder gar Team-Chats zu finden.

Enterprise Architekten erarbeiten die Auswirkungen bisher gültiger Geschäfts- und IT-Strategien mit den dort avisierten Änderungen. Bebauungspläne im Ist und Ziel werden auf den Prüfstand gestellt. Idealerweise erkennt man hier bereits frühzeitig entstehende Architekturschulden.

Eine wahre Fundgrube an interessanten Entscheidungen sind auch Protokolle von Lenkungskreisen und Boards. Es sind dort gelegentlich spannende Hinweise auf in Kauf genommene Architekturschulden zu finden.

Nicht zu vernachlässigen bei der Suche nach Architekturschulden sind Kopfmonopole. Mitarbeitende, die jahrelanges Wissen um die Systeme aufgebaut haben und jeden Winkel kennen. Hören Sie genau zu und arbeiten gemeinsam mit ihnen den Schuldenberg auf.

Risikomanagement

Gehen wir davon aus, dass wir eine Liste von Architekturschulden erstellt und deren Auswirkungen auf die Bebauungsplanungen und damit die Strategien bewertet haben. Der nächste Schritt besteht darin, die Tilgung systematisch in die sich verändernde IT-Landschaft einzubringen. Ist das Bewusstsein für Architekturschulden über die Grenzen der Enterprise Architektur hinaus geschaffen (vulgo: Management und Geschäftsbereiche haben erkannt, dass hier Geschäftsrisiken entstanden sind), geht es darum, die Schuldentilgung nachhaltig in der Organisation zu verankern.

Ein aus meiner Sicht passender Prozess zur nachhaltigen Steuerung von Architekturschulden ist ein Risikomanagementprozess. Grund dafür ist, dass in jeder Architekturschuld mindestens eine Abweichung vom Zielzustand zu finden ist. Diese Abweichung ist nichts anderes als ein Risiko für die Geschäftsstrategie.

Risikomanagementprozesse kennen wir bereits aus dem Finanzbereich oder der Informationssicherheit, sind aber in der Enterprise Architektur bislang selten anzutreffen. Gründe dafür können sowohl die personelle Ausstattung der Architekturabteilungen sein, als auch das  heterogene Aufgabenfeld der Enterprise Architekten. Nicht selten ist der Reifegrad der Enterprise Architektur noch nicht erreicht, der eine nachhaltige Behandlung zulassen würde. Der Vorteil eines Risikomanagementprozesses im Architekturmanagement liegt auf der Hand, denn eine der wichtigsten Aufgaben der Unternehmensleitung ist die Risikovorsorge. Und damit liegt ein großer Hebel in den Händen der Architekten.

Der mit Architekturschulden startende Risikomanagementzyklus bringt Transparenz und angemessene Reaktionsmöglichkeiten
Der mit Architekturschulden startende Risikomanagementzyklus bringt Transparenz und angemessene Reaktionsmöglichkeiten

Die typischen Schritte eines Risikomanagementprozesses sind:

  • Risikoidentifikation: Identifizierung von Architekturschulden.
  • Risikoableitung: Ableitung von Architekturrisiken aus den Architekturschulden.
  • Risikobewertung: Analyse und Bewertung der identifizierten Risiken hinsichtlich ihrer Wahrscheinlichkeit und potenziellen Auswirkungen.
  • Risikobehandlung: Entwicklung und Umsetzung von Strategien zur Reduktion, Vermeidung, Übertragung oder Akzeptanz der Risiken.
  • Risikokontrolle: Überwachung der Risiken und der Wirksamkeit der umgesetzten Maßnahmen, inklusive regelmäßiger Überprüfung und Anpassung des Risikomanagementprozesses.
  • Berichterstattung und Dokumentation: Dokumentation aller Schritte des Risikomanagements und regelmäßige Berichterstattung an relevante Stakeholder, um Transparenz und Nachverfolgbarkeit sicherzustellen.

Die ersten Schritte der Identifizierung und Ableitung haben wir schon besprochen.

Bei der Risikobewertung werden relevante Stakeholder einbezogen, idealerweise aus den Geschäftsbereichen, die eine Aussage zum wirtschaftlichen Schadenspotential treffen können. Die Einschätzungen zu Eintrittswahrscheinlichkeiten sind in der Regel eine Gemeinschaftsarbeit zwischen Architektur, Technik und Business. Besonders wichtig ist jedoch der Aspekt, dass die Risikobewertung eine Quantifizierung der Architekturschulden zulässt und damit die finanziellen Auswirkungen deutlich werden! Die Enterprise Architektur wird damit in die Lage versetzt, dem Management sehr klar darlegen zu können, wo die architekturellen Risiken in der Landschaft stecken. Aussagen, die bislang eher nebulöser Natur sind, werden plötzlich in hartem Euro ausgedrückt.

Das von der Enterprise Architektur betriebene Risikomanagement ermöglicht eine Quantifizierung von Architekturschulden und daraus resultierender Risiken.

Die Risikobehandlung versetzt Verantwortliche fachlicher Prozesse und ihre Pendants auf IT-Seite in die Lage, sich “ihrer” Schulden bewusst zu werden, sie angemessen zu behandeln und zu priorisieren, um wieder auf Kurs im Einklang mit der Zielbebauung und den Geschäftsstrategien zu kommen.

Die Risikokontrolle (Risk Controlling) gibt dem Enteprise Architekturmanagement ein Werkzeug zur Ausübung seiner Governance-Funktion an die Hand.

Reporting darf natürlich auch nicht fehlen, denn die zu schaffende Transparenz über die Risikosituation aus architektureller Sicht ist für den Erfolg der Maßnahmen und der Erreichung der Geschäftsstrategien unerlässlich.

Fazit

Eine proaktive Beschäftigung mit Architekturschulden leitet zu einem Risikomanagementprozess über und elaboriert das Enterprise Architekturmanagement im Reifungsprozess. Die Beschäftigung mit und Behandlung von Architekturrisiken flexibilisiert die Landschaft nachhaltig, hält die Komplexität in beherrschbarem Zustand und zahlt letztendlich auf die Geschäftsstrategien ein. Obendrein erhält das Unternehmen eine nie dagewesene Transparenz über die IT-Landschaft und deren Risikosituation.