Falle #2 macht keine Fortschritte

Es gibt einen offen gesagt alarmierenden Trend in der EA-Branche: kurzlebige EA-Teams.

Hochfunktionale EA-Teams richten ihre Ergebnisse am Geschäftszyklus aus und verwenden ein strukturiertes Repository. Schwach funktionierende EA-Teams stehen auf, scheitern, starten neu. Und das Ganze von vorne.

Crash-and-Burn-Geschichten

Schlecht funktionierende EA-Teams. Ein Antimuster nach dem anderen.

Wenn Sie diese Praktiken beobachten, hören Sie auf! Hören Sie sofort auf!
Werfen Sie aus, solange Sie noch können.

Friedhof der Unternehmensarchitektur

Lernen Sie, welche Fehlermuster Sie vermeiden sollten

Leitfaden für Unternehmensarchitekten

Laden Sie die Leitfaden für Unternehmensarchitekten Ein Leitfaden der TOGAF-Reihe zur Entwicklung nützlicher Unternehmensarchitektur.

Werden Sie ein besserer Architekt

Kostenloser 90-tägiger Personal Enterprise Architect Kickstart, um ein besserer Architekt zu werden.
Wöchentlich aufgezeichnetes Webinar mit Downloads

Starten Sie noch heute

Der durchschnittliche Lebenszyklus eines EA-Teams beträgt zwei Jahre. In den meisten Organisationen gibt es eine lange Geschichte der Gründung, Auflösung, Neugründung und Ausgliederung von EA-Teams. Unsere Praxis, EA-Teams aufzubauen und zu verbessern, erlebt dies häufiger als die meisten anderen.

Wenn wir Führungsteams fragen, was vor unserer Ankunft nicht funktioniert hat, ist die Antwort immer dieselbe: Sie haben nichts Brauchbares geliefert. Schlimmer noch: Die Architektur war für die Verwirklichung der strategischen Ziele irrelevant.

Dies sind klassische Symptome von Falle #2 macht keine Fortschritte. Nichts Verbrauchbares. Keine Ausrichtung auf Verbesserung.

Jeder, der an unserem EA mit TOGAF & Navigate oder TOGAF-Zertifizierung Kurse kennt die Wütende Ente. Ein einfaches Clipart, das eine Ente mit ungeduldig verschränkten Armen und verächtlich gesenkten Augen zeigt. Die Wütende Ente ist eine Erinnerung an alle Architekten, dass trotz des enormen Drucks, nützliche Architektur und Anleitungen zu erstellen, es nie genügend Ressourcen und Informationen gibt, um als Architekt 100% sicher oder vollständig zu sein. Stattdessen müssen wir fertig werden. Wir müssen für den Zweck ausreichend liefern.

Während EA-Teams Nebensächlichkeiten nachjagen oder durch eine weitere Analyserunde gelähmt sind, schreiten Organisationen mit bewussten und zufälligen Veränderungen voran. Eine nützliche Architektur ist ausreichend vollständig, um genügend Vertrauen für die noch nicht getroffene Entscheidung zu schaffen.

Unser Beruf TOGAF-Framework Enthält die Tools zum Erledigen von Aufgaben: Iteration und unterschiedliche Detaillierungsebenen in der Unternehmenslandschaft. Hochfunktionale EA-Teams richten ihre Ergebnisse am Geschäftszyklus aus und verwenden ein strukturiertes Repository.

Entscheidungen, die den Rahmen eines Projekts bilden und die kritischen Spezifikationen genehmigen, die einen messbaren Wert liefern, erfordern in der Regel weniger detaillierte Analysen als die, die erforderlich sind, um ein Änderungsteam bei der Implementierung einer Lösung zu leiten und einzuschränken. Ehrlich gesagt bedeutet „fertig werden“ die Arbeit zu unterbrechen, wenn die aktuelle Iteration das vorliegende Problem lösen kann.

Wir nutzen das agile Backlog-Konzept, um die Arbeit zukünftiger ADM-Iterationen zu speichern. In der Praxis ist es einfach: Die Roadmap identifiziert Initiativen oder Programme, die mehr Arbeit benötigen; Programme enthalten Projekte, die mehr Arbeit erfordern, und Projekte enthalten Lösungen, die mehr Arbeit erfordern. Jede Iteration erweitert die bisherige Arbeit, validiert und verfeinert Spezifikationen und Kontrollen. Die EA-Landschaft wird vervollständigt.

Zielgerichtete Architekturentwicklung fördert die Umsetzung. TOGAFs Konzept eines Architekturprojekts ist eine Karte in unserem Kanban-Backlog. Zu Beginn jedes Predictable EA-Sprints ziehen wir Karten und analysieren, was wir im Repository benötigen und was wir den Konsumenten (Entscheidungsträgern und Stakeholdern) liefern.

Mit einem wachsenden Repository beschleunigt sich die Markteinführungszeit durch wiederverwendbare Arbeit. Nachdem die Portfolioarchitektur die Stakeholder-Analyse durchgeführt und den bevorzugten Ansatz für die Arbeitspakete definiert hat, kennt der Architekt die Prioritäten und weiß, ob die aktuelle Arbeit mit der Annahme von „Rip & Replace“, „Evolution“ oder „Revolution“ beginnen soll. Dies fördert die Konvergenz innerhalb der Stakeholder-Anforderungen. Klarheit der Stakeholder darüber, was sich ändern muss, führt zu einer Konvergenz des strategischen Nutzens.

Plötzlich, ohne Mandat, ohne komplexe Governance-Strukturen und ohne imaginäre Entscheidungsbefugnis, liefert das EA-Team Mehrwert. Richtungsentscheidungen lassen sich sichtbar auf den Nutzen zurückführen. Implementierungsentscheidungen entsprechen Spezifikationen und Kontrollen, die offensichtlich vertretbar sind. Die Organisation verändert sich auf ganzer Linie erfolgreicher und reibungsloser.

Und das alles, weil das EA-Team der Falle entgangen ist, Keine Fortschritte

Nehmen Sie am Enterprise Architecture Kickstart teil

Kostenloses 12-Wochen-Programm, um ein besserer Unternehmensarchitekt zu werden

Nach oben scrollen
Geheime Verbindung