Die Übernahme der Rolle eines Enterprise-Architecture-Leiters erfordert eine Veränderung des Denkens von taktischer Umsetzung hin zu strategischer Überwachung. Innerhalb des TOGAF-Rahmens bietet die Architektur-Entwicklungsmethode (ADM) einen strukturierten Ansatz, doch die Phase der Anforderungsanalyse wird oft zu einer Herausforderung für Anfänger in der Disziplin. Die Anforderungsanalyse geht nicht nur darum, eine Liste von Bedürfnissen zu sammeln; vielmehr geht es darum, eine klare, nachvollziehbare Verbindung zwischen Geschäftszielen und technischen Fähigkeiten herzustellen. Wenn diese Verbindung schwach ist, droht die gesamte Architekturinitiative, sich vom organisatorischen Wert zu entfernen.
Diese Anleitung behandelt die häufigen Fehler, die bei der Anforderungsanalyse nach TOGAF auftreten. Durch das Verständnis dieser Fallstricke können neue Leiter den Komplexitäten des ADM-Zyklus präziser begegnen. Der Fokus liegt hier auf der praktischen Anwendung, der Einbindung von Stakeholdern und der strukturellen Integrität des Architektur-Repositories.
🔍 Die Grundlage der Anforderungsanalyse in TOGAF
Die Anforderungsanalyse innerhalb TOGAF erstreckt sich über mehrere Phasen, vor allem Phase A (Architekturvision), Phase B (Geschäftsarchitektur), Phase C (Informationssystemarchitekturen) und Phase D (Technologiearchitektur). Jede Phase bringt spezifische Anforderungstypen hervor, die erfasst, validiert und aufrechterhalten werden müssen.
Eine wirksame Analyse beruht auf drei zentralen Säulen:
- Geschäftsanforderungen: Hochrangige Ziele und Beschränkungen, die durch die Strategie der Organisation definiert werden.
- Anliegen der Stakeholder: Spezifische Interessen von Einzelpersonen oder Gruppen, die die Architektur beeinflussen.
- Nicht-funktionale Anforderungen: Qualitätsmerkmale wie Leistungsfähigkeit, Sicherheit und Zuverlässigkeit.
Die Unfähigkeit, zwischen diesen Kategorien zu unterscheiden, führt oft zu Umfangsausweitungen und architektonischem Abweichen. Neue Leiter müssen sicherstellen, dass das Anforderungs-Repository korrekt gefüllt ist, bevor sie in die Entwurfsphasen übergehen.
❌ Fehler 1: Ignorieren des Stakeholder-Kontexts und der Machtverhältnisse
Ein häufiger Fehler besteht darin, alle Stakeholder im Prozess der Anforderungserhebung als gleichwertig zu behandeln. In Wirklichkeit variieren Einfluss und Interesse innerhalb einer Organisation erheblich. Ein Leiter könnte Stunden damit verbringen, einen mittleren Manager zu befragen, während ein entscheidender Entscheidungsträger schweigt.
Die Auswirkung
Wenn wichtige Stakeholder nicht früh identifiziert werden, werden ihre Anliegen oft erst spät im Projekt übersehen. Dies führt zu Nacharbeit, da die Architektur angepasst werden muss, um Anforderungen zu berücksichtigen, die zuvor ungesagt blieben. Zudem kann dies zu einem Mangel an Förderung der Architekturinitiative führen, was dazu führt, dass Ressourcen zurückgezogen werden.
Korrekturmaßnahme
Um dies zu vermeiden, erstellen Sie zu Beginn der Phase der Architekturvision eine umfassende Stakeholder-Karte. Diese Karte sollte die Stakeholder anhand ihres Einflusses und ihres Interesses einteilen.
- Hoher Einfluss, hohes Interesse:Engagieren Sie sich intensiv und verwalten Sie Erwartungen streng.
- Hoher Einfluss, geringes Interesse:Halten Sie sie zufrieden, indem Sie hochrangige Updates bereitstellen.
- Geringer Einfluss, hohes Interesse:Halten Sie sie informiert, um Fehlinformationen zu vermeiden.
- Geringer Einfluss, geringes Interesse:Überwachen Sie mit minimalem Aufwand.
Gehen Sie nicht davon aus, dass der Titel einer Rolle deren Einfluss widerspiegelt. In einigen Organisationen kann ein technischer Leiter mehr Einfluss auf die Umsetzung haben als ein nomineller Abteilungsleiter. Die Interviews müssen strukturiert sein, um diese versteckten Dynamiken aufzudecken.
❌ Fehler 2: Verwechseln von Anforderungen mit Lösungen
Neue Leiter geraten oft in die Falle, Lösungen als Anforderungen zu dokumentieren. Zum Beispiel könnte ein Stakeholder sagen: „Wir brauchen ein neues Datenbanksystem.“ Wenn der Architekt dies als Anforderung protokolliert, wird die Analyse bereits vor der eigentlichen Bedarfserfassung zugunsten dieser spezifischen Technologie beeinflusst.
Die Auswirkung
Diese vorzeitige Verpflichtung begrenzt den Lösungsraum. Die Architektur könnte eine Technologie festlegen, die nicht mehr tragfähig ist, oder eine, die die zugrundeliegenden geschäftlichen Anforderungen nicht erfüllt. Sie verursacht außerdem technische Schulden, da die Architektur gezwungen ist, ein bestimmtes Werkzeug zu unterstützen, anstatt eine funktionale Fähigkeit.
Beseitigungsstrategie
Wenden Sie die „Warum“-Methode an. Fragen Sie jedes Mal, wenn eine Lösung vorgeschlagen wird, warum diese Lösung notwendig ist.
- Interessent: „Wir benötigen eine Cloud-Speicherlösung.“
- Architekt: „Welche geschäftliche Fähigkeit wird damit unterstützt?“
- Interessent: „Wir müssen große Dateien sicher mit Partnern teilen.“
- Architekt: „Also ist die Anforderung sichere Dateiübertragung, nicht speziell Cloud-Speicherung.“
Dokumentieren Sie die zugrundeliegende Fähigkeit (sichere Dateiübertragung) anstelle des vorgeschlagenen Werkzeugs. Dadurch bleibt Flexibilität beim Auswahl des besten Technologie-Tools in den späteren Phasen des ADM-Zyklus erhalten.
❌ Fehler 3: Vernachlässigung von Nicht-Funktionalen Anforderungen (NFRs)
Funktionalen Anforderungen beschreiben, was das System tut. Nicht-funktionale Anforderungen beschreiben, wie das System funktioniert. Neue Leiter setzen oft den Fokus auf das „Was“ und ignorieren das „Wie“, wobei sie davon ausgehen, dass Leistung und Sicherheit vom Implementierungsteam übernommen werden.
Die Auswirkung
Architekturen, die ohne definierte NFRs erstellt wurden, scheitern oft unter Last oder werden anfällig für Sicherheitsverletzungen. Compliance-Anforderungen wie Datennachweis oder Audit-Trails sind ebenfalls NFRs. Werden diese in der Analysephase übersehen, kann die Architektur später nicht von Rechts- oder Compliance-Gremien genehmigt werden.
Beseitigungsstrategie
Legen Sie einen standardisierten Satz von NFR-Kategorien fest, die bei jedem Architekturprojekt berücksichtigt werden müssen. Häufige Kategorien sind:
- Leistung: Antwortzeiten, Durchsatz und Latenz.
- Sicherheit: Authentifizierungs-, Autorisierungs- und Verschlüsselungsstandards.
- Zuverlässigkeit: Verfügbarkeitsziele und Fähigkeiten zur Katastrophenwiederherstellung.
- Skalierbarkeit: Die Fähigkeit, Wachstum in Daten oder Nutzern zu bewältigen.
- Wartbarkeit: Einfachheit von Aktualisierungen und Patches.
Diese sollten, wo möglich, quantifiziert werden. Statt „schnelle Leistung“ anzugeben, sollte festgelegt werden: „95 % der Transaktionen müssen innerhalb von 200 Millisekunden abgeschlossen werden.“ Die Quantifizierung beseitigt Mehrdeutigkeiten und ermöglicht eine objektive Prüfung später.
❌ Fehler 4: Schwache Rückverfolgbarkeit zwischen Anforderungen
Die Rückverfolgbarkeit bezieht sich auf die Fähigkeit, eine Anforderung zurück zum Ursprung und vorwärts zu den Gestaltungselementen zu verknüpfen, die sie erfüllen. Ohne diese Verknüpfung ist es unmöglich festzustellen, ob eine bestimmte Gestaltungsentscheidung tatsächlich einem Geschäftsbedarf entspricht.
Die Auswirkung
Wenn die Rückverfolgbarkeit verloren geht, wird die Architektur zu einer schwarzen Box. Prüfer können die Einhaltung von Vorgaben nicht überprüfen. Änderungsmanager können die Auswirkungen einer Änderung nicht bewerten, da sie nicht wissen, welche Anforderungen betroffen sind. Dies führt zu einer „Schattenarchitektur“, in der dokumentationslose Workarounds zunehmen.
Korrekturmaßnahme
Implementieren Sie eine Anforderungsdatenbank. Dies ist ein strukturiertes Datenbanksystem oder Dokumentenmanagementsystem, in dem jeder Anforderung eine eindeutige Kennung (z. B. REQ-BUS-001) zugewiesen wird.
Für jede Anforderung halten Sie die folgenden Verknüpfungen aufrecht:
- Quelle: Welcher Beteiligte oder Geschäftsziel hat dies initiiert?
- Abhängigkeit: Welche anderen Anforderungen müssen zuerst erfüllt werden?
- Erfüllung: Welches Architekturbaukastenelement oder Gestaltungselement erfüllt dies?
- Status: Ist die Anforderung akzeptiert, abgelehnt oder hinausgeschoben?
Überprüfen Sie diese Datenbank regelmäßig im Verlauf des ADM-Zyklus. Wenn eine Anforderung nicht mit einem Gestaltungselement verknüpft ist, sollte sie als nicht erfüllt markiert werden. Wenn ein Gestaltungselement nicht mit einer Anforderung verknüpft ist, ist es ein Kandidat für die Entfernung, um die Komplexität zu reduzieren.
❌ Fehler 5: Überspringen der Baseline-Analyse
Die Baseline stellt den aktuellen Zustand der Architektur der Organisation dar. Viele Leiter eilen dazu, den Zielzustand zu definieren, ohne die bestehenden Fähigkeiten, Lücken und technischen Schulden ausreichend zu dokumentieren.
Die Auswirkung
Ohne eine Baseline ist es unmöglich, Fortschritte zu messen. Migrationsstrategien werden zu Ratespielen. Sie könnten versehentlich einen Zielzustand entwerfen, der auf Fähigkeiten angewiesen ist, die nicht mehr existieren oder abgeschaltet werden. Dies führt zu einem gescheiterten Migrationsplan.
Korrekturmaßnahme
Führen Sie eine gründliche Bestandsaufnahme der aktuellen Umgebung durch. Dazu ist keine vollständige Prüfung jedes Servers erforderlich, aber es ist ein Überblick auf hoher Ebene erforderlich über:
- Anwendungen: Welche Systeme werden derzeit genutzt?
- Infrastruktur: Welche Hardware- oder Cloud-Ressourcen unterstützen sie?
- Prozesse: Wie wird die Arbeit heute tatsächlich erledigt?
- Daten: Wo befinden sich kritische Informationen?
Dokumentieren Sie die bekannten Einschränkungen und Schwachstellen. Diese werden zu Treibern für die neue Architektur. Wenn ein aktuelles System langsam ist, muss die neue Architektur explizit die Leistungsengpässe ansprechen. Wenn ein Prozess manuell ist, sollte die neue Architektur darauf abzielen, ihn zu automatisieren.
📊 Vergleich von häufigen Fehlern gegenüber Best Practices
Um die Unterschiede zwischen ineffektiver Analyse und robuster Architekturplanung zu veranschaulichen, betrachten Sie die folgende Vergleichstabelle.
| Bereich | Häufiger Fehler | Beste Praxis |
|---|---|---|
| Interessenten | Gleiches Interviewen aller Personen | Abbildung von Macht und Interesse; zuerst Schlüsselentscheider einbinden |
| Anforderungen | Dokumentieren vorgeschlagener Lösungen | Dokumentieren der zugrundeliegenden geschäftlichen Anforderungen und Fähigkeiten |
| Qualitätsmerkmale | Ignorieren von Leistungsfähigkeit und Sicherheit | Frühzeitige Definition messbarer nicht-funktionaler Anforderungen |
| Nachvollziehbarkeit | Nicht verknüpfte Anforderungen und Entwürfe | Verwenden einer Datenbank mit eindeutigen IDs und bidirektionalen Verknüpfungen |
| Aktueller Zustand | Eilends zum Zielzustand übergehen | Dokumentieren der Basislage zur Identifizierung von Lücken und Migrationsschritten |
| Dokumentation | Verwenden von informellen Notizen | Pflegen einer formalen Architekturdatenbank |
🔗 Integration der Analyse in den ADM-Zyklus
Die Anforderungsanalyse ist kein einmaliger Vorgang. Es ist ein iterativer Prozess, der sich über den gesamten ADM-Zyklus erstreckt. Während sich die Architektur weiterentwickelt, können neue Anforderungen auftreten und alte können obsolet werden.
Phase A: Architekturvision
Hier liegt der Schwerpunkt auf hochwertigen geschäftlichen Anforderungen und Anliegen der Interessenten. Ziel ist es, den Umfang des Projekts und die Prinzipien zu definieren, die die Architektur leiten werden.
Phase B & C: Geschäft und Informationssysteme
Hier werden detaillierte geschäftliche Anforderungen gesammelt. Funktionale Anforderungen für Daten und Anwendungen werden definiert. Hier wird der Unterschied zwischen geschäftlicher Fähigkeit und IT-Fähigkeit entscheidend.
Phase D: Technologiestruktur
Technische Anforderungen werden verfeinert. Nicht-funktionale Anforderungen werden detailliert festgelegt. Der Basistechnologie-Stack wird analysiert, um festzustellen, was wiederverwendet werden kann.
Phasen E bis H: Umsetzung und Governance
Anforderungen werden anhand der umgesetzten Lösung überprüft. Lücken werden identifiziert, und Änderungsanträge werden verwaltet. Die Anforderungsdatenbank wird aktualisiert, um den tatsächlich realisierten Zustand widerzuspiegeln.
🛠️ Kommunikationsprotokolle für neue Leiter
Technische Genauigkeit ist nur die Hälfte des Kampfes. Die Kommunikation stellt sicher, dass die Analyse innerhalb der gesamten Organisation verstanden und akzeptiert wird.
- Verwenden Sie visuelle Modelle:Diagramme sind oft effektiver als Text. Verwenden Sie Ablaufdiagramme oder Fähigkeitskarten, um Anforderungen darzustellen.
- Definieren Sie die Begrifflichkeiten:Stellen Sie sicher, dass alle Stakeholder sich auf die Bedeutung der Schlüsselbegriffe einigen. „Verfügbarkeit“ bedeutet für IT und Betrieb etwas anderes.
- Regelmäßige Überprüfungen:Planen Sie regelmäßige Sitzungen zur Überprüfung der Anforderungen. Warten Sie nicht bis zum Ende des Projekts, um die Liste zu validieren.
- Feedback-Schleifen:Schaffen Sie eine Möglichkeit, dass Stakeholder Änderungen an Anforderungen vornehmen können, ohne den gesamten Prozess zu stören.
🚦 Mit Vertrauen vorwärts gehen
Der Weg zu einer effektiven Architektur ist mit klaren Anforderungen gepflastert. Indem man die häufigen Fallen wie Lösungspräferenz, schlechte Stakeholder-Zuordnung und vernachlässigte Rückverfolgbarkeit vermeidet, können neue Leiter Architekturen aufbauen, die widerstandsfähig und mit der Geschäftsstrategie ausgerichtet sind. Das TOGAF-Rahmenwerk bietet die Struktur, aber die Disziplin des Analysten schafft den Wert.
Konzentrieren Sie sich auf die geschäftlichen Ergebnisse statt auf die Technologie. Stellen Sie sicher, dass jede Anforderung einen Zweck hat und mit einem Gestaltungselement verknüpft ist. Pflegen Sie die Datenbank mit Sorgfalt. Diese Praktiken werden eine Grundlage des Vertrauens zwischen der Architektur-Abteilung und dem Rest der Organisation schaffen.
Denken Sie daran, dass Architektur eine Reise ist, kein Ziel. Die Phase der Anforderungsanalyse legt die Richtung fest. Wenn die Richtung klar ist, wird die Reise reibungsloser verlaufen. Wenn die Richtung unklar ist, wird das Team abirren. Investieren Sie die Zeit, um es von Anfang an richtig zu machen.
