Sechs Anwendungsfälle für agile Unternehmensarchitektur

Agile EA-Anwendungsfallbeispiele

Anwendungsfall 1: Architektur eines agilen Unternehmens

In diesem Anwendungsfall ist der EA-Zweck darauf beschränkt, akzeptable Zielarchitekturen zu erfordern, um der Agilität Priorität einzuräumen.

Ehrlich gesagt hat es nichts mit agilen Methoden zu tun. Viele agile Organisationen, mit denen wir zusammengearbeitet haben, verwenden keine agilen Änderungsmethoden.

Wir nutzen Supply Chain und Disaster Response als Prüfsteine für hohe Agilität. Wir verwenden 5 Attribute für Agilität (aus der Sport- und Militärforschung):

• Wachsamkeit
• Zugänglichkeit
• Entschlossenheit
• Schnelligkeit
• Flexibilität

Dieser Anwendungsfall übt Navigate Agile Enterprise Atlas von Conexiam. Es optimiert die Architekturentwicklung für mehr Agilität durch eine spezialisierte Sichtweisenbibliothek, die Einbindung und Belange der Stakeholder.

Offen gesagt ist dieser Anwendungsfall gefährlich, wenn er nicht mit den wahren Präferenzen der einflussreichen Stakeholder einer Organisation übereinstimmt.

Bezüglich TOGAF, Dieser Anwendungsfall konzentriert sich vor allem auf die TOGAF ADM Wertrealisierungsaktivität der Phasen G und H, bei der die Veränderung auf die Schaffung und Aufrechterhaltung eines agilen Unternehmens ausgerichtet sein muss.

Anwendungsfall 2: Verwenden Sie EA, um einen agilen Ansatz für Änderungen zu definieren

In diesem Anwendungsfall wird die Unternehmensarchitektur verwendet, um zu strukturieren, wie das Unternehmen Änderungen durchführt. Produkte, Sprint-Teamstruktur, Geschwindigkeit und Ausrichtung auf alle Änderungsansätze werden berücksichtigt.

Es geht um die Fragen, welche Veränderung, welche Entwicklung mit welchem Ansatz erfolgen soll. Bei agilen Methoden werden Fragen wie Produkt, Sprint-Teamstruktur, Velocity beantwortet.

Dieser Anwendungsfall übt weitgehend die TOGAF ADM Phase F, G und H basieren auf einer strategischen oder Portfolioarchitektur.

Anwendungsfall 3: Verwenden Sie EA zur Steuerung der Backlog- und Sprintplanung

Aus der Perspektive von Enterprise Architecture & TOGAF, Alle Implementierungen, Prototyping-, Pilot-, Projekt- und agilen Sprints finden in Phase G statt. Best-Practice-EA erstellt eine Unternehmensarchitektur mit einem Lösungsbereitstellungs-Notebook, Lücken, Kontrolle, Architekturspezifikation und Arbeitspaket. Dieses Material muss in für den Backlog passenden Begriffen beschrieben werden: Epic, User Story und Architecture Runway.

Die Unternehmensarchitektur weist eine Reihe von Lücken, Arbeitspakete zum Schließen dieser Lücken und Einschränkungen der Kreativität der Implementierungsteams bei der Durchführung der Änderungen auf. Sie umfasst die Rückverfolgbarkeit zu Treibern, Zielen und Prioritäten außerhalb des Zuständigkeitsbereichs des Produktmanagers und des Kunden.

Im klassischen Agile-Ansatz füllen die kundenorientierten Epics und User Stories den Backlog. Der Kunde gibt die Priorisierungskriterien vor. Das selbstorganisierende Agile-Team priorisiert die Arbeit.

Dieser Anwendungsfall nutzt die Unternehmensarchitektur, um einen nicht kundenbasierten Rückstand bereitzustellen und die Priorisierung bei der Sprintplanung zu steuern.

Verwenden Sie hierfür Gap Epics und User Stories, die aus Gaps und Arbeitspaketen abgeleitet wurden. Externe Abhängigkeiten schränken Priorisierung, Akzeptanzkriterien und Exit-Kriterien ein. Übergeordnete Prioritäten können angegeben werden.

Dieser Anwendungsfall übt hauptsächlich die TOGAF ADM Phase G, Implementierungs-Governance: In Phase G wird das Implementierungsteam über die zu erledigenden Aufgaben und die externen Einschränkungen seiner Handlungsfreiheit informiert. Die Art und Weise der Kommunikation des EA-Teams wird durch die Organisation des Implementierungsteams bestimmt.

Das entscheidende Element ist die Ausrichtung der EA-Governance-Aktivitäten auf das agile Änderungsmodell. Die Dynamik des Sprint-Teams darf nicht beeinträchtigt werden.

Anwendungsfall 4: Verwenden Sie EA, um Agile Sprints einzuschränken

Dieser Anwendungsfall übt weitgehend die TOGAF ADM-Phase G, Implementierungs-Governance, aus.

Gefolgt Best Practices für Enterprise Architecture Governance Die wesentliche Frage ist:

Hat das agile Team die dokumentierten Richtlinien und Einschränkungen der Zielarchitektur vernünftig interpretiert?

• • Wenn ja, sollte ihre Interpretation als Konformität akzeptiert werden und alle Probleme durch eine Änderung der Architektur behoben werden
  • Wenn nein, entwickeln Sie eine Empfehlung zur Korrektur der Situation.

Dies ist ein wichtiger Punkt. Eine gute Architektur kann mehrere Implementierungsoptionen beinhalten, und das agile Team ist nicht verpflichtet, sich an die jeweilige Meinung zu halten. Wenn die Implementierungsentscheidung eine vernünftige Interpretation darstellt, sollte sie als konform beurteilt werden. Wenn etwas in der Architekturspezifikation fehlt, ist das nicht das Problem des agilen Teams. Es ist das Problem des EA-Teams, das eine Änderung der genehmigten Architektur benötigt.

Das entscheidende Element ist die Ausrichtung Unternehmensarchitektur-Governance Aktivität mit agilem Veränderungsmodell. Die Dynamik des Sprint-Teams darf nicht beeinträchtigt werden.

Lücken, Arbeitspaketstrategie, Kontrollen und Architekturspezifikationen leiten und begrenzen Sprints. Sie müssen in einer für das agile Team verständlichen Sprache verfasst und präsentiert werden. Kontrollen und Architekturspezifikationen dienen typischerweise als Akzeptanz- und Ausstiegskriterien.

Anwendungsfall 5: Verwenden Sie EA, um Abhängigkeiten zu lösen

In diesem Anwendungsfall wird die Unternehmensarchitektur verwendet, um Abhängigkeiten und Auswirkungen zwischen agilen Teams zu berücksichtigen.

Dieser Anwendungsfall unterscheidet sich von Anwendungsfall 4, da er die Art und Weise verändert, wie sich das EA-Team engagiert. Häufig besteht eine Abhängigkeit zwischen verschiedenen Änderungsmethoden (agil und Wasserfall), und Entscheidungen innerhalb eines Sprints können kaskadierende Auswirkungen haben.

Eine Schlüsselrolle bei der Entwicklung Architektur zur Unterstützung der Lösungsbereitstellung besteht darin, diese Abhängigkeiten zu identifizieren und zu beheben, bevor ein agiles Team darüber stolpert.

Im Anwendungsfall 4 besteht eine Erfolgsmessung darin, sicherzustellen, dass die Dynamik nicht beeinträchtigt wird. In diesem Anwendungsfall muss die Dynamik eines Teams gegenüber anderen agilen Teams, operativen Einheiten und Teams, die andere Veränderungsmethoden verwenden, ausgeglichen werden.

Dieser Anwendungsfall übt weitgehend die TOGAF ADM Phase G Governance- und Änderungsauftragsaktivität aus. Ehrlich gesagt, Best Practices für Enterprise Architecture Governance vermeidet die Gewährung von Ausnahmen für teamübergreifende Architekturabhängigkeiten. Nicht identifizierte Herausforderungen sind der häufigste Bereich für Architekturausnahmen.

Abhängigkeitsprobleme sind das Problem des EA-Teams. Es muss Maßnahmen ergreifen, um die Organisation bestmöglich aus diesen Schwierigkeiten zu befreien. Die Lösung dieser Probleme erfordert sorgfältige Beachtung der übergeordneten Architektur, der Kontrollen und der in den Grundsätzen festgelegten Architekturspezifikationen.

Anwendungsfall 6: Agile Methoden zur Entwicklung einer Unternehmensarchitektur nutzen

In diesem Anwendungsfall ist die EA-Funktion so konfiguriert, dass sie agile Methoden zur Entwicklung einer Unternehmensarchitektur verwendet.

Conexiam Predictable EA ist ein Beispiel für diesen Anwendungsfall. Um zu verdeutlichen, dass eine Architektur zur Entscheidungsunterstützung dient, bezeichnen wir das nützliche Arbeitsprodukt routinemäßig als “Advice Binder”. Dieser Ordner ist auf Zweck und Problemstellung optimiert. Er wird auf verschiedene Weise genutzt.

Dieser Anwendungsfall hat große Auswirkungen auf die Ausführung aller ADM-Phasen zur Entwicklung der Architektur. Dieser Anwendungsfall hängt vom Ergebnis der Vorphase sowie der Struktur und Ausführung der EA-Fähigkeit ab.