© Excellent backgrounds/Shutterstock.com
Teil 1: Überblick und Lösungstaktiken

Agiles IT-Architekturmanagement


Viele Unternehmen etablieren IT-Architekturmanagement, um ihren immer schneller wachsenden und komplexer werdenden IT-Landschaften Herr zu werden. Dazu soll das Application Lifecycle Management (ALM) für höhere Flexibilität und Stabilität optimiert werden. Aber das Etablieren von IT-Architekturmanagement ist ein aufwendiges Unterfangen, zumal nicht alle IT-Architekturmanagement-Programme erfolgreich sind. Wir zeigen praxisnahe Alternativen zur Optimierung des ALM.

IT-Landschaften großer Unternehmen und Organisationen wachsen weiterhin schnell. Getrieben von fachlichen, technischen, organisatorischen und wirtschaftlichen Anforderungen entstehen komplexe, heterogene IT-Architekturen. Die zunehmende Komplexität steht im Widerspruch zur gewünschten Flexibilität und Stabilität von Systemen – insbesondere dann, wenn schnelle Weiterentwicklung erfolgt.

Agiles IT-Architekturmanagement adressiert diese Herausforderung und berücksichtigt zusätzlich wichtige Anforderungen agiler Organisationen: Es ist leichtgewichtig, pragmatisch und auf direkte Mehrwerte für die Organisation ausgerichtet, setzt geringe spezifische Kenntnisse voraus, lässt sich auf den individuellen Bedarf anpassen und ist kostengünstig zu realisieren. Dabei versteht sich agiles IT-Architekturmanagement nicht als eigenständiges methodisches Konstrukt, sondern entsteht – agilen Prinzipien folgend – durch die passgenaue Kombination praxisbewährter Bottom-up-Ansätze. Auf diese Weise lassen sich IT-Strategie, Vorgehensmodelle und Technologien in einen nachvollziehbaren Zusammenhang bringen.

Herausforderungen von IT-Architekturmanagement

Nicht jedes IT-Architekturmanagement-Programm ist jedoch erfolgreich [1], [2]. Je nach Umfang und Ausrichtung kann das Etablieren langwierig und teuer sein. Dies fällt umso schwerer ins Gewicht, je höher die technischen Schulden [3] sowie der Innovations- und Lieferdruck eines Unternehmens sind. Ein Fallstrick kann sein, dass das Etablieren von IT-Architekturmanagement teure und zeitaufwendige Weiterbildung bezüglich der Methodik des jeweiligen Frameworks sowie in den entsprechenden Softwarewerkzeugen erfordert. Unnötig abstrakte oder umfangreiche Modellierung reduziert die Praktikabilität der Konzeption [4] und erhöht die Aufwände, diese Modelle aktuell zu halten. Wenn IT-Architekturmanagement nur auf der technischen Ebene ausgerollt wird, ist das Ziel des so genannten Business-IT-Alignments von Beginn an zum Scheitern verurteilt. Diese Punkte können dem IT-Architekturmanagement den Ruf einer Elfenbeinturmdisziplin einhandeln, was die Akzeptanz reduziert. Die gänzlich unterschiedlichen zeitlichen Anforderungen und Ergebnisse (Abb. 1) können dazu führen, dass IT-Architekturmanagement IT-Projekte bremst. Diese und weitere Herausforderungen führen dazu, dass IT-Architekturmanagement selbst zum Auslöser dessen werden kann, was es vermeiden soll:

  • Projektsilos: Die Lieferfrequenz von Softwareprojekten ist häufig höher getaktet, als es umfangreiche Vorgehensmodelle des IT-Architekturmanagements ermöglichen. Damit Liefertermine dennoch gehalten werden können, entstehen Projektsilos.

  • Redundanz und Verschwendung: Projektsilos erkaufen sich diese Flexibilität, indem sie das Rad regelmäßig neu erfinden. Zusätzlich besteht das Risiko, dass das Projektsilo nach Projektabschluss in eine Schatten-IT übergeht.

  • Beschränkter Reifegrad: Nebeneffekte von Projektsilos und Schatten-IT sind Wissenssilos, ineffektives Wissensmanagement, das Vermeiden von Synergie­effekten und das Erhöhen von Risiken infolge falscher Annahmen.

daivandy_schmidt_aam_1.tif_fmt1.jpgAbb. 1: Klassisches IT-Architekturmanagement und IT-Projekte sind unterschiedlich getaktet

Wir zeigen, wie man mit ausgewählten Lösungstaktiken das ALM hinsichtlich höherer Flexibilität (Innovationspotenzial, kürzere Time to Market) und der Stabilität (Reduktion von Entwicklungs- und Betriebskosten) optimieren kann. Dabei gelten folgende Regeln:

  • Jede Lösungstaktik trägt zur verbesserten Flexibilität und/oder Stabilität des ALM bei.

  • Sie können inkrementell eingeführt werden: „so viel wie nötig“ anstelle von „so viel wie möglich“.

  • Jede ist kurz- bis mittelfristig umsetzbar und liefert bereits mittelfristig Mehrwerte.

  • Sie sind untereinander kompatibel. Manche verstärken einander sogar.

Technische Schulden managen

Technische Schulden bezeichnen eine Metapher aus der Softwareentwicklung. Gemeint sind damit Entwurfs- und Entwicklungsentscheidungen, die kurzfristig Vorteile bringen, aber dafür sorgen, dass später die gleiche Arbeit teurer wird. Anders als bei der Aufnahme von finanziellen Schulden findet die Aufnahme technischer Schulden nicht zwingend bewusst oder kontrolliert statt. Das heißt, es besteht keine Kenntnis darüber, wie hoch die bestehenden technischen Schulden zum Entscheidungszeitpunkt sind, wie viel Weiterverschuldung maximal tragbar ist und welche Konsequenzen eine Weiterverschuldung überhaupt nach sich ziehen könnte. Geschweige denn, ob im Nachgang Kompensationsmaßnahmen erforderlich werden, welche dies sein werden und wann sie am besten durchgeführt werden sollen. An dieser Stelle hilft das Management technischer Schulden (MTS), das als interdisziplinäres Vorgehensmodell zeitnah Auskunft über das Verhältnis von Features zu technischen Schulden sowie über die Time to Market besagter Features gibt – alles in Abhängigkeit von der Stabilität bzw. Änderbarkeit des Softwareprodukts. Abbildung 2 veranschaulicht diese Zusammenhänge.

daivandy_schmidt_aam_2.tif_fmt1.jpgAbb. 2: Mit zunehmender Stabilität wiegen technische Schulden weniger und es kann mehr in Innovation investiert werden

Diese und weitere Informationen ermöglichen eine nachvollziehbare sowie belastbare Entscheidungsgrundlage für das weitere IT-Investment im ALM. Zusätzlich liefert das MTS Instrumente zur Steuerung von ALM-Dienstleistern und zum Treffen von Make-or-Buy-Entscheidungen. Insgesamt fungiert das MTS also nicht nur als interdisziplinäre ALM-Lupe, sondern als Frühwarnsystem und Grundlage für kalkulierbare Risiken. MTS beantwortet z. B. Fragen wie „Sind kurzfristig erhöhte Refactoring-Aufwände zugunsten langfristiger Produktivität in der Entwicklung indiziert?“ oder „Können wir es uns erlauben, eine reduzierte Time to Market durch Aufnahme technischer Schulden zu erkaufen?“.

MTS ist eine spezielle Mischform aus Risiko- und Problemmanagement, mit der sich technische Schulden systematisch und standardisiert erfassen, messen, steuern und bewerten lassen – als so genannte Technical Backlog Items (TBIs). Abbildung 3 verdeutlicht dies links allgemein und rechts auf Basis von Scrum: die In­stallation des Managements technischer Schulden liefert einen typisierten Katalog technischer Schulden. Dem schließt sich die alltägliche Kurzerfassung ermittelter TBIs an – ebenfalls typisiert (Schritt 1). Zu gegebener Zeit erfolgt die Bewertung (Schritt 2) sowie Einplanung und Bearbeitung (Schritt 3) dieser TBIs. Dabei ist es kritisch, TBIs in einen kausalen und aufwandstechnischen Bezug zu benötigten Features zu setzen. [5] beschreibt diesen Dreischritt und das Gesamtvorgehen ausführlich.

daivandy_schmidt_aam_3.tif_fmt1.jpgAbb. 3: Workflow für das Management technischer Schulden

Jede zur Behandlung einer technischen Schuld beschlossene Maßnahme fällt dabei in eine der folgenden Kategorien:

  • Schuldenfortzahlung: Die technische Schuld wird nicht weiter behandelt. Man lebt mit ihr und erträgt die Schmerzen.

  • Schuldenrückzahlung: Die technische Schuld wird nach Schulbuch gelöst, d. h. es wird die Ideallösung umgesetzt. Das ist aufwendig, dafür verschwindet die technische ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang