Suche

Agilität trotz komplexer Architekturen

Phase C, Information Systems Architecture: Diese Phase erarbeitet die Daten- und die Anwendungsarchitektur. Die Datenarchitektur befasst sich mit der Definition der Geschäftsentitäten, der Erfassung der Datendiversität im Unternehmen und dem daraus sich ergebenden Transformationsbedarf, dem Lebenszyklus der Entitäten, Fragen der Mastership von verwaltenden Informationssystemen und schließlich mit Migrationsstrategien für den Übergang zur Zielarchitektur. Die Anwendungsarchitektur dagegen befasst sich mit Anwendungen im Sinne von Gruppen logischer Funktionen (Capabilities) und hat neben einer modellierenden Perspektive auch eine analytische: Anwendungen werden mit Indikatoren gekennzeichnet, die deren Kosten, Wert- und Strategiebeitrag ausdrücken. Anschließend fährt man Auswertungen über diese Daten, die dann bei der Gestaltung der Zielarchitektur helfen.

Beide Teilbereiche werden in Relation zur Geschäftsarchitektur dargestellt. Zum Beispiel werden Geschäftsprozesse und Organisationseinheiten in Beziehung zu den sie unterstützenden Anwendungen gebracht oder Geschäftsentitäten auf sie autorisierende Rollen und Master-Anwendungen abgebildet. Für beide Bereiche werden eine Ist- und eine Soll-Architektur erarbeitet, und aus der Gap-Analyse ergeben sich wiederum Lösungsbausteine, die in das Backlog aufgenommen werden. Wie schon bei der Geschäftsarchitektur, differenziert sich die Menge der User Stories auch in dieser Phase aus.

Phase D, Technology Architecture: Die Technologiearchitektur befasst sich schließlich mit der technologischen Infrastruktur, den Servern, Netzwerkbausteinen, Plattformen, Produkten etc. Auch diese Phase hat eine analytische Perspektive und versieht ihre Bausteine mit Kennzahlen. Ansonsten folgt sie den Linien, die schon in den vorigen Phasen sichtbar wurden: Ist-/Soll-Architektur, Gap-Analyse, Ausdifferenzierung des Backlogs.

Phase E, Opportunities and Solutions: Das Backlog und die Architekturmodelle sind inzwischen so verfeinert, dass eine weitere Ausdifferenzierung getrost den Sprints der Entwicklung überlassen werden kann. Die Ziele von Phase E sind Folgende:

  1. User Stories auszuwählen, die als Kandidaten für das Release gelten können
  2. Die Komplexität der Stories abzuschätzen. Das geschieht, wie in XP/Scrum üblich, mit allen Stakeholdern im gemeinsamen Planungspoker und in der relativen Währung „Story Point“.

Phase F, Migration Planning: In einer Kosten-/Nutzenanalyse priorisiert man die User Stories, legt den Projektumfang fest und gibt schließlich den Startschuss für die Umsetzung.

Phase G, Implementation Governance: Parallel zu dieser Phase findet die Umsetzung statt. Zu Beginn steht die Kommunikation der erarbeiteten User Stories und der Architektur im Vordergrund. Im Weiteren wählt man Maßnahmen, um die Implementierung in den Leitplanken des Architekturkontraktes und der Qualitätsanforderungen zu halten. Das Spektrum dieser Maßnahmen ist weit und reicht von Service Level Agreements, der Überwachung von KPIs zur Laufzeit, über Entwicklungsstandards bis hin zu den Dokumentationspflichten der Projekte. XP/Scrum steuert hier zum Beispiel die testgetriebene Entwicklung, die Continuous Integration, das Pair Programming, das automatisierte Testen und Rollen wie die des Build-Managers bei.

Phase H, Change Management: Der wesentliche Punkt dieser Phase ist eine Verabredung darüber, unter welchen Umständen ein neuer ADM-Zyklus initiiert werden sollte. Im Agilen ist das vergleichsweise einfach. Solange durch die Umpriorisierung, Änderung oder Hinzunahme einer User Story der Projektumfang im Sinne von Story Points unverändert bleibt und die Architekturblaupause des letzten Zyklus alles abgedeckt, besteht keine Notwendigkeit zu einer Neuauflage des Zyklus. Plankonformität hat im Agilen keinen intrinsischen Wert, und Abweichungen werden nicht durch Change-Request-Turnübungen bestraft.

Kurz und gut

Eine Mikrosicht auf XP/Scrum stellt sich die Freiheit des Product Owners grenzenlos vor. Zu Beginn eines Sprints kann die Betreffende jede beliebige User Story auf den Planungstisch legen und dem Team zur Umsetzung vorgeben. Bei komplexeren Systemen und in einem Unternehmenskontext mit langfristigeren Prozessen geht das so uneingeschränkt nicht. Architektur ist in diesem Kontext ein Knowledge Creator, der längerfristige Prozesse mit Planungssicherheit versieht, und der Entwicklung einen Orientierungsrahmen gibt. Sie mag sich dabei durchaus eines Architekturframeworks wie TOGAF bedienen, denn trotz eines gewissen Wasserfallhabitus gibt es zumindest bei TOGAF keine immanente Unvereinbarkeit mit agilem Projektvorgehen. Essenziell ist, die ADM gemäß der agilen Kultur zu leben, was gerade bei ambitionierten Frameworks helfen kann, Bodenhaftung und Pragmatismus zu bewahren. Eigentlich eine gute Nachricht für jene, die sich mehr Agilität auch in größeren Unternehmenszusammenhängen wünschen.

Dr. Uwe Bombosch ist als Senior Architect für das indische Unternehmen Tata Consultancy Services tätig. Er arbeitet seit vielen Jahren als Architekt, zunächst an der Konzeption komplexer Java-EE-Architekturen des Bereichs Operation Support Systems in der Telekommunikation, dann verstärkt in SOA- und BPM-Projekten der Automobilbranche. Sein Hauptinteresse gilt heute dem Enterprise Architecture Management. Seit 2005 arbeitet er ausschließlich in agilen Projekten unter Verwendung von Scrum und XP.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.