Sechs Anwendungsfälle für agile Unternehmensarchitekturen

Sechs agile EA-Anwendungsfälle zeigen, wie ein EA-Team für unterschiedliche Bedingungen entworfen werden kann. Agile Methoden für EA, EA unterstützt die agile Entwicklung und ein agiles Unternehmen.

Diese sind eine Teilmenge des Standards Anwendungsfälle der Unternehmensarchitektur. Die Standard-Use-Cases decken alles ab, von strategischen Veränderungen über Risikominderung und Akquisitionen bis hin zu agiler Entwicklung.

Wir suchen nach einfachen Rahmenmodellen, um unser Denken zu verdeutlichen. Framing-Modelle sollen uns helfen, Bedingungen explizit zu isolieren, in denen wir Konfigurationsentscheidungen treffen müssen.

Sechs Anwendungsfälle für Agile EA Agilität, Enterprise Architecture und agile Softwareentwicklung passen zusammen.

  1. Unternehmensagilität
  2. Agile Softwareentwicklung & Unternehmensarchitektur
  3. Architektur des Unternehmens mit agilen Methoden

Das Isolieren von Bedingungen ermöglicht es Ihnen, Ihr EA-Team mit Zuversicht zu entwerfen. Unsere EA-Funktionsdienste benutze die Navigieren Referenzarchitektur für EA-Funktionen. Hochfunktionierende EA-Teams sind optimal konfiguriert.

Agile und Unternehmensarchitektur passen wunderbar zusammen. Beide lösen unterschiedliche Teile des Problems.

Agile Softwareentwicklung zeichnet sich dadurch aus, etwas zu bauen, das wir noch nie zuvor hatten und nicht wissen, wie. Unternehmensarchitektur glänzt vor Entscheidungen, wenn Sie nicht wissen, was zu tun ist.

Setzen Agile Softwareentwicklung & Unternehmensarchitektur gemeinsam den Wandel optimieren.

Die meisten Architekten machen sich Gedanken darüber, wie Unternehmen und agile Entwicklung zusammenhängen. Wir haben viele Menschen gesehen, die versuchten, zwei völlig unterschiedliche Welten zusammenzufügen, normalerweise ohne anzuhalten, um beides zu verstehen.

Wir optimieren Unternehmensarchitektur und agile Entwicklung, indem wir sie an ihren Stärken ausrichten. Die Kurzform, die wir verwenden, ist, dass die Unternehmensarchitektur sich vor Entscheidungen auszeichnet, wenn Sie nicht verstehen, was zu tun ist. Agile Softwareentwicklung zeichnet sich dadurch aus, etwas zu bauen, das wir noch nie zuvor hatten.

Beide Methoden leiden unter chronischer Fehlanwendung. Trotz des inhärenten Iterationskonzepts von TOGAF halten sich zu viele Architekten an das Kornkreisdiagramm von ADM und sehen den Prozess. Es ist so einfach, einen Wasserfall im ADM-Diagramm zu sehen. Falsch, aber einfach. Ebenso der Desorganisierte Sprung auf die Entdeckungsreise in die agile Entwicklung, um ihre Desorganisation zu verbergen.

Die tatsächliche Welt ist chaotisch. Sofern wir nicht von einem einfachen One-Trick-Pony auf der grünen Wiese sprechen, müssen Softwareprodukte in ein komplexes Ökosystem passen. Bestehende Prozesse, Organisation, Partner und Infrastruktur ermöglichen es dem Unternehmen, Kunden zu bedienen. Das neue Produkt muss das Ökosystem verbessern und sich gleichzeitig einfügen.

Es ist die Komplexität der realen Welt, in der effektive agile Entwicklung und Unternehmensarchitektur glänzen. Spielen Sie ihre Stärken aus. Wir stützen eine starke Praxis der agilen Softwareentwicklung auf die Lösung einer wesentlichen Spannung.

Agile Spannung
Du weißt, wohin du gehst. Sie wissen nicht, wie Sie dorthin gelangen

Leitfaden für Unternehmensarchitekten

Laden Sie die herunter Leitfaden für Unternehmensarchitekten ein Leitfaden der TOGAF-Serie zur Entwicklung nützlicher Unternehmensarchitekturen.

Agile EA-Anwendungsbeispiele

Anwendungsfall 1: Architektur eines agilen Unternehmens

In diesem Anwendungsfall ist der EA-Zweck darauf beschränkt, akzeptable Zielarchitekturen zu fordern, um Agilität zu priorisieren.

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

Wir stützen uns stark auf Supply Chain & Disaster Response als Prüfsteine für hohe Agilität. Wir verwenden 5 Attribute für Agilität (aus Sport- und Militärforschung):

  • Wachsamkeit
  • Barrierefreiheit
  • Entschlossenheit
  • Schnelligkeit
  • Flexibilität

Dieser Anwendungsfall ist eine Übung Navigate Agile Enterprise Atlas von Conexiam. Es optimiert die Architekturentwicklung für Agilität durch eine spezialisierte Sichtweisenbibliothek, Stakeholder-Engagement und Bedenken.

Ganz offen gesagt ist dieser Anwendungsfall gefährlich, wenn er nicht mit den wahren Präferenzen der mächtigen Stakeholder einer Organisation übereinstimmt.

Bezüglich TOGAF, konzentriert sich dieser Anwendungsfall am meisten auf die TOGAF-ADM Wertrealisierungsaktivität in Phase G und Phase 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

Agile und Unternehmensarchitektur-Arbeitsprodukt In diesem Anwendungsfall wird die Unternehmensarchitektur verwendet, um zu strukturieren, wie das Unternehmen Änderungen durchführt. Produkte, Sprint-Teamstruktur, Geschwindigkeit, Ausrichtung mit allen Änderungsansätzen werden durchgeführt.

Dabei geht es um die Fragen, welche Veränderung, welche Entwicklung welchem Ansatz folgen soll. Bei agilen Methoden werden Fragen wie Product, Sprint Teamstruktur, Velocity beantwortet.

Dieser Use Case übt weitgehend die TOGAF-ADM Phase F, G & H basierend auf einer Strategie- oder Portfolioarchitektur.

Anwendungsfall 3: Verwenden Sie EA, um die Backlog- und Sprint-Planung zu steuern

Aus der Perspektive von Enterprise Architecture & TOGAF, Alle Implementierungs-, Prototyping-, Pilot-, Projekt- und Agile-Sprints erfolgen in Phase G. Best-Practice EA wird eine Unternehmensarchitektur erstellen, die mit einem Notizbuch für die Lösungsbereitstellung, einer Lücke, einer Kontrolle, einer Architekturspezifikation und einem Arbeitspaket ausgestattet ist. Dieses Material muss in Begriffen beschrieben werden, die für das Backlog geeignet sind: Epic, User Story und Architecture Runway.

Die Unternehmensarchitektur wird eine Reihe von Lücken, Arbeitspakete zum Füllen dieser Lücken und Einschränkungen der Kreativität der Implementierungsteams bei der Durchführung der Änderung enthalten. Es umfasst die Rückverfolgbarkeit zu Treibern, Zielen und Prioritäten außerhalb des Zuständigkeitsbereichs des Produktmanagers und des Kunden.

Im klassischen Agile füllen die kundengetriebenen Epics und Users Stories den Backlog. Der Kunde gibt Priorisierungskriterien vor. Das selbstorganisierende agile Team priorisiert die Arbeit.

Dieser Anwendungsfall verwendet die Unternehmensarchitektur, um nicht kundenbasiertes Backlog bereitzustellen und die Priorisierung bei der Sprintplanung zu steuern.

Verwenden Sie dabei Gap Epics und User Stories, die aus Gaps und Arbeitspaketen abgeleitet sind. Externe Abhängigkeit schränkt Priorisierung, Akzeptanzkriterien und Ausstiegskriterien ein. Übergeordnete Prioritäten können bereitgestellt werden.

Dieser Anwendungsfall übt meistens die TOGAF-ADM Phase G, Implementierungs-Governance: In Phase G wird ein Implementierungsteam im Klartext über die auszuführenden Arbeiten und externe Beschränkungen seiner Arbeitsfreiheit informiert. Wie das EA-Team kommuniziert, hängt von der Organisation des Implementierungsteams ab.

Das entscheidende Element ist die Ausrichtung der EA-Governance-Aktivität am agilen Änderungsmodell. Der Schwung des Sprintteams 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.

Folgend Best-Practice-EA-Governance die wesentliche frage ist:

Hat das agile Team die dokumentierten Leitlinien und Einschränkungen der Zielarchitektur angemessen interpretiert?

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

Dies ist ein wichtiger Punkt. Eine gute Architektur kann mehrere Implementierungsmöglichkeiten haben, und das agile Team muss sich nicht an Meinungen halten. Wenn die Wahl der Implementierung eine vernünftige Interpretation ist, sollte sie als konform beurteilt werden. Wenn etwas in der Architekturspezifikation ausgelassen wurde, ist das nicht das Problem des agilen Teams. Es ist das Problem des EA-Teams, sie brauchen eine Änderung an der genehmigten Architektur.

Das kritische Element ist die Ausrichtung EA-Governance Aktivität mit agilem Change-Modell. Der Schwung des Sprintteams darf nicht beeinträchtigt werden.

Die Lücken, Arbeitspaketstrategie, Kontrollen und Architekturspezifikation führen und beschränken Sprints. Sie müssen so geschrieben und präsentiert werden, dass sie vom agilen Team konsumiert werden können. Kontrollen und Architekturspezifikationen werden typischerweise als Akzeptanzkriterien und Beendigungskriterien wiedergegeben.

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

In diesem Anwendungsfall wird die Unternehmensarchitektur verwendet, um Abhängigkeiten und Auswirkungen auf agile Teams zu adressieren.

Dieser Anwendungsfall unterscheidet sich von Anwendungsfall 4, da er die Interaktion des EA-Teams verändert. Wo es Abhängigkeiten gibt, wird es oft zwischen verschiedenen Veränderungsmethoden (agil und Wasserfall) sein und wo Entscheidungen innerhalb eines Sprints kaskadierende Auswirkungen haben können.

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

In Anwendungsfall 4 stellt ein Erfolgsmaß sicher, dass die Dynamik nicht beeinträchtigt wird. In diesem Anwendungsfall muss die Dynamik eines Teams gegen andere agile Teams, operative Einheiten und Teams, die andere Veränderungsmethoden verwenden, ausbalanciert werden.

Dieser Anwendungsfall übt weitgehend die TOGAF ADM Phase G Governance & Change Order-Aktivität aus. Geradeheraus, Best-Practice-EA-Governance vermeidet die Gewährung von Ausnahmen für teamübergreifende Architekturabhängigkeiten. Herausforderungen, die nicht identifiziert wurden, sind der häufigste Bereich für Architekturausnahmen.

Abhängigkeitsprobleme sind das Problem des EA-Teams. Sie werden Arbeit leisten müssen, um die Organisation am effektivsten aus diesen Löchern zu graben. Die Bewältigung dieser Probleme erfordert eine sorgfältige Beachtung überlegener Architektur, Kontrollen und Architekturspezifikationen, die in den Grundsätzen beschrieben werden.

Anwendungsfall 6: Verwenden Sie agile Methoden, um Unternehmensarchitekturen zu entwickeln

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 verstehen, dass eine Architektur zur Unterstützung der Entscheidungsfindung verwendet wird, bezeichnen wir das nützliche Arbeitsprodukt routinemäßig als „Ratgeber“. Dieser Binder ist zweck- und problemoptimiert. Es wird auf verschiedene Arten konsumiert.

Dieser Anwendungsfall wird sich weitgehend auf die Ausführung aller ADM-Phasen zur Entwicklung der Architektur auswirken. Dieser Anwendungsfall hängt vom Ergebnis der Vorphase und der Struktur und Ausführung der EA-Fähigkeit ab.

Praktiker, die an den Extremen der agilen Softwareentwicklung und der Unternehmensarchitektur arbeiten, werden sich wahrscheinlich nie begegnen. Sie erkennen möglicherweise nicht einmal das Arbeitsprodukt des anderen. Die wesentliche Spannung liegt in ihrer Beziehung zueinander.

Wenn Sie innehalten und die Ausrichtung von Best Practice EA und Best Practice Agile Softwareentwicklung für grundlegende Bereiche, in denen sie interagieren, betrachten, wird dies offensichtlich. Praktiker, die entweder an den Extremen der Unternehmensarchitektur oder der agilen Softwareentwicklung arbeiten, wissen möglicherweise nie, was die andere Person für das Unternehmen arbeitet, sie sehen möglicherweise nicht das Arbeitsprodukt des anderen.

Ein EA-Praktiker, der an der Unterstützung der Strategie arbeitet, und ein technischer Leiter in einem agilen Softwareteam arbeiten weit voneinander entfernt. Der technische Leiter durchlebt ein Ausführungsfenster, das in Wochen oder Monaten gemessen wird. Release-Pläne oder Architektur-Laufstege sind langfristiges Denken. Der strategische EA-Praktiker hätte jahrelang an der Roadmap arbeiten können, die die Entwicklung agiler Softwareentwicklungsfähigkeiten darlegt.

Leitfaden für Unternehmensarchitekten

Laden Sie die herunter Leitfaden für Unternehmensarchitekten ein Leitfaden der TOGAF-Serie zur Entwicklung nützlicher Unternehmensarchitekturen.

Zweck der Unternehmensarchitektur

Die Ausrichtung Ihres Unternehmensarchitekturteams auf verschiedene agile Anwendungsfälle hilft dabei, die am besten geeigneten zu identifizieren Anwendungsfälle der Unternehmensarchitektur.

Nehmen Sie am Enterprise Architecture Kickstart teil

Kostenloses 12-wöchiges Programm, um ein besserer Unternehmensarchitekt zu werden

Scrolle nach oben