TOGAF ADM Phase F – Erstellen des Implementierungsplans
Auf einen Blick:
- TOGAF ADM-Übersicht
- Was ist TOGAF Phase F?
- Was ist ein Implementierungsplan?
- Warum unterscheidet sich ein Implementierungsplan von einer Architektur-Roadmap?
- TOGAF ADM Phase F – Ergebnisse
- Welche Rolle spielt der Unternehmensarchitekt in Phase F?
- Welche Rolle spielen Portfolioplaner und Projektplaner in Phase F?
- Tools und Techniken für den Implementierungsplan
- Techniken für den Implementierungsplan
- Portfolioplanung
- Programmplanung
- Nutzenrealisierung
- Risikominderung
- Architekturvertrag
- Implementierungsstrategie
- Verwenden von Architektur-Roadmap-Techniken für die Implementierungsplanung
- Architektur-Roadmap Typ 1: Heatmap
- Architektur-Roadmap Typ 2: Lebenszyklusdiagramme
- Architektur-Roadmap Typ 3: Auswirkungen und Abhängigkeiten der Arbeitspakete
- Architektur-Roadmap Typ 4: Szenarioanalyse
- Übergangsarchitektur
- Lücke und Lösung
- Auf den Architekturzweck abgestimmte Implementierungsplantechniken
- Implementierungsplantechniken für Anwendungsfälle der Unternehmensarchitektur
- Wie passt TOGAF Phase F zur agilen Entwicklung?
- Wie ermöglicht TOGAF Phase F Unternehmensagilität?
- Abschließende Gedanken zu TOGAF ADM Phase F – Erstellen Sie den Implementierungsplan
TOGAF ADM-Übersicht
Das TOGAF ADM legt die TOGAF-Rahmenwerk abgesehen von anderen Unternehmensarchitektur-Frameworks. Es ist das einzige Enterprise-Architektur-Framework, das alle drei Teile eines Rahmens – wie man eine Architektur dokumentiert, So bauen Sie ein Enterprise-Architecture-Team auf, und wie man eine Architektur entwickelt.
TOGAF ADM entwickelt eine Unternehmensarchitektur
Jede TOGAF ADM Phase erläutert die Aktivitäten zur Wissensentwicklung. Jede ADM-Phase entwickelt Wissen über einen Teil der Unternehmensarchitektur. Die Interaktionen zwischen den Phasen sind Informationsflüsse. Diese Informationsflüsse münden in einigen wichtigen Ergebnissen – eines davon ist der Implementierungsplan für Phase F des TOGAF ADM.
Was ist TOGAF Phase F?
TOGAF Phase F bietet Unternehmensarchitekten die nötigen Schritte und Informationen, um Planer bei der Erstellung eines Implementierungsplans zu unterstützen. Es ist eine bewährte Methode, dass Unternehmensarchitekten Planer unterstützen. Ihre Aufgabe besteht darin, sicherzustellen, dass die Entscheidungen der Stakeholder in der Architektur im Plan berücksichtigt werden. Wenn frühere Entscheidungen nicht im Implementierungsplan berücksichtigt werden, muss die Unternehmensarchitektur aktualisiert werden. Erst wenn sich Ihr Unternehmen zu einer Änderung verpflichtet, wird die vorgeschlagene Unternehmensarchitektur endgültig genehmigt.
Was ist das Ziel von TOGAF ADM Phase F?
Das Ziel der Phase F ist der Übergang von der Architektur-Roadmap entwickelt in TOGAF ADM Phase E zu einem Implementierungsplan. Die Architektur-Roadmap hat bereits schlechte Änderungsoptionen aussortiert. Der Implementierungsplan beschreibt, wie Ihr Unternehmen Änderungen umsetzen und die Übergangszustände erreichen will.
Wenn wir Unternehmensarchitektur erklären, sprechen wir davon, mögliche Veränderungen zu berücksichtigen und Optionen abzuwägen. All das gehört der Vergangenheit an. Die Architektur-Roadmap zeigt den Weg nach vorne und mögliche Übergangspunkte. Es ist Zeit für die letzte Auswahl.
Erfolg erfordert:
- Sie entscheiden, wie Veränderungen umgesetzt werden (Projekte)
- Sie kennen die Ressourcen, die für die Umsetzung der Änderung eingesetzt werden
- Sie kennen die erforderlichen Vorteile und die auferlegten Einschränkungen (Architekturvertrag)
Interaktion mit TOGAF Phase B, Phase C Phase D, und Phase E
Wasserfallansätze liefern zwar keine gute Architektur, dennoch sollte zwischen Architektur-Roadmap und Implementierungsplan eine klare Trennung bestehen. Das Ausloten und Verwerfen potenzieller Änderungen ist ein wertvolles Ergebnis der Unternehmensarchitektur. Phase F führt in die harte Praxis.
Portfolioplaner, Programmmanager und Projektmanager leben nicht in einer Welt der Möglichkeiten. Sie leben in einer harten Welt der Umsetzung. Sie sprechen von Dingen wie der Eisendreieck. Sie erwarten, das Ziel, die erwarteten Vorteile und Einschränkungen zu erfahren. Sie beabsichtigen, alle über die Ziellinie zu ziehen.
Der TOGAF-Standard besagt zwar, dass die Zielarchitektur erst in Phase F fertiggestellt wird, Ihre Architektur ändert sich jedoch nur, wenn Ihr Unternehmen sich weigert, fortzufahren. Andernfalls ist die Architekturentwicklung abgeschlossen.
Was ist ein Architekturimplementierungsplan?
Ein Implementierungsplan enthält einen Zeitplan für die Projekte, die die Zielarchitektur realisieren. Die ausführbaren Projekte werden in verwaltete Portfolios und Programme gruppiert. Die Implementierungsstrategie gibt den Ansatz zur Veränderung an.
Lassen Sie uns die Definition des Implementierungsplans näher betrachten. Zunächst ist der Implementierungsplan ein Zeitplan. Er verknüpft Projekte zeitlich.
Zweitens basiert es auf einem Projekt. Wir wissen aus PMI dass jedes Projekt eine Reihe voneinander abhängiger Aufgaben ist, die ein gemeinsames Ziel haben. Projektmerkmale:
- Ein klares Start- und Enddatum. Sie haben einen klaren Anfang, ein klares Ende und einen Überblick darüber, was dazwischen passiert
- Sie schaffen etwas Neues. Sie sind eine einmalige Aktivität. Sie wird nie wieder auf die gleiche Weise wiederholt
- Es gibt klare Grenzen. Sie arbeiten innerhalb der Grenzen von Zeit, Geld, Qualität und Funktionalität
- Es ist nie Business as usual. Es verändert Business as usual
Drittens gruppiert es die Projekte in Portfolios und Programme für das Management.
Schließlich wird dargelegt, wie der Wandel vonstattengehen wird. Implementierungsstrategie erfordert eine Änderung:
- Evolutionär
- Revolutionär
- Greenfield
Warum unterscheidet sich ein Implementierungsplan von einer Architektur-Roadmap?
Der TOGAF-Standard ADM trennt Phase E und Phase F sowie die Architektur-Roadmap vom Implementierungs- und Migrationsplan. Diese Trennung basiert auf Best-Practice-Planung. Eine Architektur-Roadmap unterstützt Sie bei der Festlegung Ihres Pfads, Ihres Ziels und der noch offenen Entscheidungen. Sie hilft auch dabei, ungelöste Weggabelungen zu identifizieren. Der Implementierungs- und Migrationsplan unterstützt lediglich die Ausführung.
Wir garantieren, dass Ihre aktuellen Roadmaps eher Implementierungsplänen als Architektur-Roadmaps ähneln. Allerdings sehen wir selten, dass die Arbeit in einzelne Projekte aufgeteilt und diese für das Management mit Portfolio und Programm verknüpft werden. In der Regel handelt es sich um ein einzelnes, umfangreiches Projekt. Die Implementierungsstrategie ist selten explizit, was dazu führt, dass das Projektteam innerhalb des Projekts entscheiden muss, was der beste Ansatz ist. Es wird immer der Weg gewählt, der für das Projekt am einfachsten ist.
Die eigentliche Entwicklung des Implementierungsplans erfolgt gemeinsam mit Stakeholdern, Ressourcenverantwortlichen und den Planern Ihres Unternehmens. Der Enterprise Architect ist dafür zuständig, den erwarteten Nutzen, die Abhängigkeiten und die Implementierungsstrategie hervorzuheben. Wir haben den Nutzen bereits bewertet. Sie verfügen über Übergangsarchitekturen. Es geht darum, das Erwartete zu liefern, nicht darum, herauszufinden, was sinnvoll ist.
Ergebnisse des Implementierungsplans für Phase F von TOGAF ADM
Die beiden zentralen Ergebnisse der Phase F sind ein Implementierungsplan und ein Architekturvertrag. Dies ist der Aktionsteil der Unternehmensarchitektur.
Wertvollster Nutzen des Implementierungsplans
- Definieren des Änderungsplans. Identifizieren Sie, was sich ändern wird und bis wann
- Definieren der Art der Änderung durch die Implementierungsstrategie
- Definition der Kontrolle durch Portfolio und Programm
Ein Implementierungsplan hilft bei der Beantwortung der folgenden Fragen:
- Wenn sich etwas ändert – Projekte des Umsetzungsplans
- Was sich ändern muss und was nicht – Projekte des Umsetzungsplans
- Welche Art von Veränderung wird stattfinden – Implementierungsstrategie
- Welcher Arbeitsumfang ist auf bestimmte Ergebnisse ausgerichtet – Portfolio des Umsetzungsplans
- Welche Arbeiten werden gemeinsam ausgeführt – Programm des Umsetzungsplans
Ein Architekturvertrag hilft bei der Beantwortung der folgenden Fragen:
- Welcher materielle und immaterielle Nutzen wird erwartet – Architekturvertrag - Nutzen
- Wenn Zwänge die Freiheit der Umsetzer einschränken – Architekturvertrag – Architekturspezifikation
- Wie Risiken und Unsicherheiten angegangen werden – Architekturvertrag - Kontrolle
- Welche Veränderungen werden erwartet – Architekturvertrag – Umsetzungsstrategie
- Welche Veränderung ist tabu – Architekturvertrag - Übergang & Nutzen
Ein Implementierungsplan ist ein Tool zur Umsetzung von Unternehmensänderungen. Er bündelt die Umsetzung und lenkt die Organisation.
Abschluss des Implementierungsplans für Phase F
Alle TOGAF ADM-Phasen führen Sie zum Aufbau des benötigten Wissens. Das Ergebnis von Phase F ist ein Implementierungsplan und ein unterstützender Architekturvertrag.
| Ausgabe und Ergebnis | Grundlegendes Wissen |
| Eine Reihe genehmigter Projekte[1], das das Ziel und alle notwendigen Einschränkungen, die erforderlichen Ressourcen sowie die Start- und Enddaten enthält. | Verfügbare Ressourcen zur Durchführung der Änderung.
Wie sich die Prioritäten und Präferenzen der Stakeholder als Reaktion auf Wert, Aufwand und Risiko von Änderungen anpassen. (Anforderungen der Stakeholder) |
Tabelle von TOGAF-Reihenhandbuch: Leitfaden für Unternehmensarchitekten zur Architekturentwicklung
Phase F Bare Bones
In Phase F übernehmen die Änderungsplaner die meiste Schwerstarbeit. Implementierungspläne erfordern Arbeitseinsatz.
Das Grundgerüst von Phase F ist:
- Was wird sich ändern und wann – Projekte des Umsetzungsplans
- Welche Art von Veränderung wird stattfinden – Implementierungsstrategie
- Wie der Wandel zu einem Ergebnis geführt wird – Portfolio des Umsetzungsplans
- Wie Veränderungen als Arbeit bewältigt werden – Programm des Umsetzungsplans
- Welcher Nutzen wird erzielt – Architekturvertrag
- Welche Einschränkungen schränken die Freiheit der Implementierer ein – Architekturvertrag
In Phase F fühlen wir uns immer freier. Die vielfältigen Architekturmöglichkeiten reduzieren sich auf einen einzigen Thread. Alle komplexen Kompromisse liegen hinter uns, und es stehen uns die harten Verhandlungen über Ressourcen und Zeit bevor. Ehrlich gesagt: Wenn unsere Architektur-Roadmap die Grenzen von Umfang und Qualität nicht im Griff hat, waren wir nicht bereit für die Implementierungsplanung.
- Was wird sich ändern und wann
Den Projekten zugewiesene Arbeitspakete. Ein oder mehrere Projekte erreichen einen Übergangszustand oder das endgültige Ziel. Was wird sich ändern? Wann wird es passieren?
Sie müssen Übergangszustände erklären. Implementierer sind konkrete Realisten. Sie identifizieren sich mit dem Zielzustand und versuchen, diesen zu erreichen. Daher wollen sie einen Übergangszustand überwinden. Ihnen wird der Gedanke, dass ein Stakeholder als Synonym zu einem Value Resting Point gelangt und eine Ausfahrt nutzt, sehr unangenehm sein.
Welche Arbeit, welcher Umfang, wann. Es ist alles in der Projekte des Umsetzungsplans.
- Welche Art von Veränderung wird passieren
Überlassen Sie die Art der Veränderung niemals einem Projektteam. Sie haben ein Endziel und werden jede Ecke abkürzen, um den Sieg zu erringen. Daher sind Systeme nicht stillgelegt. Deshalb sind Legacy-Prozesse hält ewig. Wenn Sie einen Ersatz erwarten, handelt es sich um Greenfield. Wenn Sie eine Verbesserung erwarten, handelt es sich um Evolution. Seien Sie klar und dann in Governance für die Umsetzung von Phase G Testen Sie auf Konformität. Nutzen Sie Ihre leistungsstärkste Umsetzungs-Governance Werkzeuge, die Implementierungsstrategie.
- Wie Veränderungen zu einem Ergebnis geführt werden
Die Projektmanagementbranche hat das Konzept von Portfolio und Programm entwickelt, um das Management komplexer Projekte zu erleichtern. Die Projektverantwortlichen haben Schwierigkeiten, den Zusammenhang zwischen den einzelnen Projekten zu erkennen. Sie streben nach einem unmittelbaren Erfolg und konzentrieren sich auf konkrete Ergebnisse am Ende des Projekts. Wenn Ihre Unternehmensarchitektur einen oder mehrere Übergangszustände aufweist, benötigen Sie zusätzliche Umsetzungs-Governance.
Die Gruppierung von Projekten nach Ergebnis und die Festlegung einer Verantwortlichen für das Ergebnis vereinfacht die Implementierungs-Governance. Best Practice Architecture Governance nutzt natürliche Autoritätsstrukturen. Portfoliomanagement ist eine natürliche Struktur. Unterstützen Sie Ihre Stakeholder bei der Erstellung ihrer Portfolio des Umsetzungsplans.
- Wie Veränderungen als Arbeit bewältigt werden
Portfolio dient zur Gruppierung nach Ergebnis. Programm dient zur Gruppierung nach Ausführung. Wenn Sie Projekte nach Ausführung gruppieren, vereinfachen Sie Umsetzungs-Governance. Wie Portfolio-Gruppierung folgen Best Practice-Architektur-Governance und eine natürliche Autoritätsstruktur zu übernehmen. Helfen Sie Ihren Stakeholdern, ihre Programm des Umsetzungsplans.
- Welchen Nutzen bringt
Wir haben das Konzept des Architekturvertrags entwickelt, um Nutzen bzw. Wert von einer Projektbeschreibung zu trennen. Projektteams blicken auf das Projektende. Projektteams orientieren sich an den Bedürfnissen ihres Sponsors. Es ist zu erwarten, dass Implementierer auf Nutzen verzichten, die nicht direkt mit ihrem Projekt in Einklang stehen. Dieser Verzicht wird als Risikominderung oder Kostensenkung dargestellt.
Um klare Anweisungen und Kontrolle zu geben, verwenden Sie die Architekturvertrag um den Nutzen oder Wert zu haben. Besonders wenn Sie bauen Fähigkeit oder die Sicherung der Zukunft Unternehmensagilität.
- Welche Einschränkungen schränken die Freiheit der Implementierer ein?
Wenn Sie etwas nicht haben, muss Um die Kontrolle zu behalten, müssen Sie sich von Architekturspezifikationen fernhalten. Architekturspezifikationen blockieren immer Innovationen und schränken die Kreativität und das Wissen Ihrer Implementierungsteams ein.
Wenn Sie etwas brauchen, verwenden Sie eine Architekturspezifikation in der Architekturvertrag. In Navigieren™, verwenden wir vier Arten von Architekturspezifikationen:
- Grundsatz, bei dem allgemeine Leitlinien zur Entscheidungsfindung angemessen sind
- Muster, bei denen ein bekannter bevorzugter Ansatz vorliegt
- Standard, wenn ein bekannter akzeptabler Ansatz vorliegt
- Regel, bei der alle Auswahlmöglichkeiten entfernt werden müssen
Wir erwarten von unseren Enterprise-Architekten, dass sie immer einen Standard haben, bevor sie eine Regel formulieren. Testen Sie ihren Standard anhand eines Musters. Stellen Sie sicher, dass das Muster dem Prinzip entspricht. Damit stellen wir sicher, dass wir die Freiheitsgrade der Implementierer so wenig wie möglich einschränken. Das Schreiben einer Regel ist einfach, erfordert aber nahezu Allwissenheit. Sie müssen vorausschauend handeln und die besonderen Umstände und zukünftigen Möglichkeiten kennen. Andernfalls können Sie die Regel falsch anwenden.
Die drei wesentlichen Punkte zur Fertigstellung von Phase F:
- Zunächst die Definition von „erledigt“. Wann erreichen wir einen Übergangszustand?
- Zweitens: Verantwortung für Veränderungen. Wer ist für welches Portfolio oder Programm verantwortlich?
- Drittens: die Verkehrsregeln. Welcher Nutzen wird dadurch erzielt? Welche Einschränkungen werden auferlegt?
Mit diesen drei wesentlichen Punkten sind die Beteiligten bereit, einen Implementierungsplan zu entwickeln. Sie wissen, was sie erreichen wollen. Sie wissen, was nicht geändert werden soll. Sie wissen, wie sie ihre Implementierer eingeschränkt haben.
TOGAF ADM Phase F – Ergebnisse des Implementierungsplans und Ziele der Unternehmensarchitektur
Die Entwicklung einer Unternehmensarchitektur verfolgt vier Hauptziele: Sie unterstützt entweder die Strategie, das Portfolio, das Projekt oder die Lösungsbereitstellung. In den meisten Fällen wird eine Architektur-Roadmap nur entwickelt, wenn sie die Strategie oder das Portfolio unterstützt. Die Muster werden im Folgenden erläutert: Leitfaden für Enterprise-Architekten zur Architekturentwicklung.
Unterschiedliche Ergebnisse haben für jeden Zweck eine unterschiedliche Bedeutung.
Architektur zur Unterstützung der Strategie
Im Rahmen der Strategieunterstützung erstellen Sie eine durchgängige Zielarchitektur und entwickeln Roadmaps für Veränderungen. Ihre Architektur identifiziert Veränderungsinitiativen sowie unterstützende Portfolios und Programme. Die Architektur-Roadmap legt die Rahmenbedingungen fest, identifiziert Synergien und regelt die Umsetzung von Portfolios und Programmen.
Architektur zur Unterstützung des Portfolios
Wenn Sie ein Portfolio unterstützen, befassen Sie sich normalerweise mit dem einzelnen Portfolio. Ihre Architektur identifiziert Projekte, legt deren Aufgabenbereiche fest, stimmt ihre Ansätze aufeinander ab, identifiziert Synergien und steuert die Projektausführung.
| Architektur zur Unterstützung der Strategie | Architektur zur Unterstützung des Portfolios | Architektur zur Unterstützung des Projekts | Architektur zur Unterstützung der Lösungsbereitstellung | |
| Arbeitsprodukt Phase F: Architekturimplementierungsplan | Wahrscheinlich nicht verwendet | Wichtigstes Ergebnis
Während der Portfoliobudgetierung Aktualisieren Sie nach Bedarf, um die Budgetierung und das Programmmanagement zu unterstützen |
Wichtigstes Ergebnis
Vor Projektstart |
Wichtigstes Ergebnis
Vor der Beauftragung und Vertragsvergabe |
| Arbeitsergebnis Phase F: Architekturvertrag | Wahrscheinlich nicht verwendet | Eingeschränkte Nutzung | Wichtigstes Ergebnis
Vor Abschluss der Projektinitiierung |
Wichtigstes Ergebnis
Vor der Beauftragung und Vertragsvergabe |
| Arbeitsprodukt Phase F: Ziel-Unternehmensarchitektur | Wichtiges Ergebnis
Wird zur Aufzeichnung und zukünftigen Architekturentwicklung verwendet |
Wichtiges Ergebnis
Wird zur Aufzeichnung und zukünftigen Architekturentwicklung verwendet |
Meist überlegene Architektur
Wird zur Aufzeichnung und zukünftigen Architekturentwicklung verwendet |
Überlegene Architektur |
Tabelle von TOGAF-Reihenhandbuch: Leitfaden für Unternehmensarchitekten zur Architekturentwicklung
Umsetzungsplan
Die Struktur Ihres Implementierungsplans ändert sich, unabhängig davon, ob Sie an der Unterstützung einer Strategie, eines Portfolios oder eines Projekts arbeiten. Implementierungspläne dienen dazu, Umsetzung regeln.
| Architektur zur Unterstützung der Strategie | Architektur zur Unterstützung des Portfolios | Architektur zur Unterstützung des Projekts | Architektur zur Unterstützung der Lösungsbereitstellung | |
| Umsetzungsplanprojekte | Zusammenfassung | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Strategie für den Implementierungsplan | Passend zum Projekt | Wichtigstes Ergebnis | Wichtigstes Ergebnis oder überlegene Architektur | Überlegene Architektur |
| Umsetzungsplan-Portfolio | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Implementierungsplanprogramm | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
Architekturvertrag
| Architektur zur Unterstützung der Strategie | Architektur zur Unterstützung des Portfolios | Architektur zur Unterstützung des Projekts | Architektur zur Unterstützung der Lösungsbereitstellung | |
| Architekturvertrag - Nutzen | Passend zum Projekt | Wichtigstes Ergebnis | Wichtigstes Ergebnis oder überlegene Architektur | Überlegene Architektur |
| Architekturvertrag – Architekturspezifikation | Prinzip | Prinzip & Muster | Prinzip, Muster und Standard | Prinzip, Muster, Standard und Regel |
| Architekturvertrag - Kontrolle | Passend zum Projekt | Wichtigstes Ergebnis passend zum Projekt | Wichtigstes Ergebnis oder überlegene Architektur | Wichtigstes Ergebnis oder überlegene Architektur |
| Architekturvertrag – Strategie für den Implementierungsplan | Passend zum Projekt | Wichtigstes Ergebnis | Wichtigstes Ergebnis oder überlegene Architektur | Überlegene Architektur |
| Architekturvertrag – Übergang | Wichtigstes Ergebnis | Wichtigstes Ergebnis oder überlegene Architektur | Wichtigstes Ergebnis oder überlegene Architektur | Überlegene Architektur |
Ziel-Unternehmensarchitektur
Die komplette Die Unternehmensarchitektur umfasst die Domänenarchitekturmodelle und die Menge der konsolidierten Lücken. Als Ergebnis aktualisieren Sie die Ziel-Unternehmensarchitektur zur Verwendung in zukünftigen Architekturentwicklungen oder als Referenz in der Implementierungs-Governance von Phase G.
Modelle, aus denen sich die Ziel-Unternehmensarchitektur zusammensetzt
- >>> Geschäftsarchitekturmodelle
- >>> Anwendungsarchitekturmodelle
- >>> Technologiearchitekturmodelle
- >>> Architektur-Roadmap-Techniken
Welche Rolle spielt der Enterprise Architect in Phase F?
In TOGAF Phase F erwarten wir, dass der Enterprise Architect die Planer berät. Er muss die Zielarchitektur und alle Übergänge interpretieren. Vor allem muss er sicherstellen, dass der erwartete Nutzen und die erwarteten Einschränkungen in den Plänen berücksichtigt werden.
Architekten sind es gewohnt, Arbeitsabläufe zu planen, die unerwartete Vorteile bringen. Oder sie erwarten die Notwendigkeit einer Einschränkung. Der Enterprise Architect muss Übergangszustände erklären.
Projektplaner haben einen kurzen Zeithorizont und denken sehr direkt. Sie fühlen sich unwohl mit:
- Immaterielle Vorteile
- Aufgeschobene Realisierung des Nutzens
- Einschränkung, die das aktuelle Projekt behindert
Zum Nutzen verwenden wir immer das Beispiel des Brückenbaus. Die Rampe und die Stützen sind zwar notwendig, bringen aber keinen Mehrwert. Zudem bietet die Brücke erst dann einen realisierbaren Mehrwert, wenn die gesamte Fahrbahn fertiggestellt ist. Das hilft den Leuten zu verstehen, dass wir möglicherweise viel Arbeit investieren, nur um noch mehr Arbeit zu leisten, bevor wir einen signifikanten Nutzen erzielen können.
Wir haben festgestellt, dass Gespräche über Autobahnen und Autobahnkreuze ihnen helfen, die Einschränkungen zu verstehen, die das aktuelle Projekt behindern. Mit zunehmendem Verkehrsaufkommen steigen die Kosten für Fahrbahn und Asphalt dramatisch. Bis wir die Brücke bauen, ist das Verkehrsaufkommen gering, sodass die Ausgaben für den Fahrbahnunterbau die Kosten des aktuellen Projekts nur in die Höhe treiben. Wenn Straße, Brücke und Autobahnkreuz zusammenkommen, entsteht ein Verkehrsnetz, das dem Verkehrsaufkommen standhält. Ein Netz, das Mehrwert schafft. Eines, für das die genutzte Straße nicht aufgerissen und neu gebaut werden muss.
Die wichtigste Aufgabe des Enterprise-Architekten besteht darin, vorausschauend zu denken und Grenzen zu überschreiten. Er versteht, warum das aktuelle Projekt möglicherweise eingeschränkt ist oder die Erfolgskriterien nicht klar erkennbar sind. Er hilft, Portfolioverantwortliche einzubinden, wenn der Projektsponsor den Unternehmensnutzen streicht.
Zwei zentrale Fakten zu TOGAF Phase F – Implementierungsplan
Gehen Sie pragmatisch an die Aufbau Ihrer Enterprise-Architektur-Teams. Unser pragmatischer Ansatz basiert auf einer unbequemen Tatsache: Wenn normales Denken flexible, effiziente Organisationen hervorbringen würde, gäbe es unseren Beruf nicht. Unternehmensarchitektur erfordert abnormales Denken.
Es gibt zwei zentrale Fakten, die wir erzählen Unternehmensarchitekten über TOGAF Phase F – Architektur-Roadmap. Erstens wird außer Ihren Stakeholdern niemand, der an der Implementierungsplanung beteiligt ist, Ihnen glauben. Ihre Ideen werden immer zu groß, zu weit hergeholt, zu theoretisch sein. Sie müssen jeden wie ein Falke auf Mäuse lauern. Sie benötigen eine enge Beziehung zu Ihren Stakeholdern. Sie müssen die Kompromissgespräche, die Sie bereits geführt haben, nutzen, um die Architektur-Roadmap zu entwickeln. Tatsächlich können Sie damit rechnen, den Kompromiss mit allen anderen erneut zu verhandeln. Zweitens werden Sie ohne einen dokumentierten Architekturvertrag mit der Implementierungs-Governance zu kämpfen haben. Niemand wird sich an den erwarteten Nutzen, die Implementierungsstrategie oder irgendwelche Einschränkungen erinnern. Niemals. Sie werden während der Projektausführung alles neu erfinden (TOGAF ADM Phase G), um das Projekt so einfach wie möglich abzuschließen und den taktischen Interessen des Projektsponsors zu dienen.
Stakeholder benötigen Unternehmensarchitekten, um die gewünschten Werte zu schützen. Normalerweise wird dieser Schutz hauptsächlich vom Projektsponsor und dem Implementierungsteam übernommen.
[1] Fixieren Sie sich nicht auf die Definition des Begriffs “Projekt” oder darauf, was ein Projekt ist. Es ist lediglich ein organisatorischer Aufwand, um ein gemeinsames Ergebnis zu erzielen. Die interne Definition eines Projekts in Ihrem Unternehmen und die verwendete Bezeichnung werden wahrscheinlich nicht mit der anderer Unternehmen übereinstimmen. Mein Assistent bezeichnet die Buchung eines Fluges als Projekt.
Modelle, Tools und Techniken für Implementierungspläne
Die TOGAF ADM-Phase F liefert den Implementierungsplan und den Architekturvertrag. Diese Phase dient dazu, Maßnahmen zu ermöglichen.
In Phase F werden die Architektur-Roadmap und die Zielarchitektur in die Tat umgesetzt. Es gibt fünf zentrale Techniken zur Erstellung eines Implementierungsplans, die den Beteiligten helfen, die Vorteile der Zielarchitektur zu nutzen.
- Portfoliogruppierung
- Programmgruppierung
- Nutzenrealisierung
- Risikominderung
- Architekturvertrag
- Implementierungsstrategiemodell
- Verwenden von Architektur-Roadmap-Techniken
Techniken für den Implementierungsplan
Zusammenfassend verdeutlichen die Techniken, was Enterprise-Architekten zur Ausarbeitung des Implementierungsplans beitragen können. Die Rolle des Enterprise-Architekten besteht darin, den Wert der Änderung zu sichern.
Portfolioplanung / Portfoliogruppierung
Im Projektmanagement werden Portfolio und Programm verwendet, um die Verwaltung komplexer Projekte zu ermöglichen. Projektsponsoren und -implementierer prüfen die konkreten Ergebnisse des Projekts.
Die Portfolioplanung gruppiert Projekte nach Ergebnis. Als definiertes Portfolio kann jemand für das Ergebnis verantwortlich sein. Dies erhöht die Erfolgschancen und ermöglicht eine kontrollierte Umsetzung.
Das Portfolio schafft eine natürliche Autoritätsstruktur. Der Rest der Organisation übernimmt diese Autoritätsstruktur und ergebnisorientierte Berichterstattung.
Programmplanung / Programmgruppierung
Das Programm gruppiert Projekte zur Ausführung. Wie beim Portfolio gibt es eine Person, die für die Verwaltung einer Reihe verwandter Projekte verantwortlich ist. Es entsteht eine ausführungsorientierte, natürliche Autoritätsstruktur. Der Rest der Organisation übernimmt die Autoritätsstruktur und das ausführungsbasierte Reporting.
Nutzenrealisierung
Wir gleichen die Vorteile der Unternehmensarchitektur stets mit den Defiziten ab, die die aktuelle Architekturentwicklung ausgelöst haben. Wir nutzen die Architektur-Roadmap und die Unternehmensarchitektur, um Umsetzung regeln. Dies erfordert eine Trennung zwischen dem erwarteten Nutzen und dem Projekt, das den Nutzen voraussichtlich erbringen wird.
In Navigieren Wir richten einen Nutzen auf ein Arbeitspaket aus. Wir verknüpfen das Arbeitspaket mit der Lücke, die es füllt, und dem Projekt, das es liefern wird.
Wir stellen regelmäßig fest, dass während der Projektinitiierung und -ausführung die Arbeit, die einen Nutzen bringt, aus dem Umfang entfernt wird, während der Nutzen weiterhin in den PowerPoint-Folien des Projekts erscheint. Dies gilt insbesondere dann, wenn der Projektsponsor den Nutzen nicht erhält.
Unternehmensarchitektur dient dazu, effektive Veränderungen zu steuern. Effektive Veränderungen realisieren die Vorteile.
Bei der Ausarbeitung des Implementierungsplans suchen wir nach Maßnahmen, die eine Lücke explizit schließen und einen Nutzen bringen. Fehlt die Maßnahme, bleibt eine Lücke ungefüllt und ein Nutzen fehlt.
Risikominderung
Wir haben zwei Verwendungen des Begriffs Risiko. Erstens ist es die Auswirkung von Unsicherheit auf das Erreichen Ihres Ziels. Diese Definition wird im Risikomanagement verwendet. Wir haben festgestellt, dass sie am besten mit der Unternehmensarchitektur übereinstimmt. Zweitens ist der normale Sprachgebrauch, bei dem ein Risiko etwas Schlimmes ist, das passieren kann. Wir haben festgestellt, dass die meisten Menschen Risiko als Bedrohung oder als etwas Schlechtes betrachten. Es spielt keine Rolle, wie Sie Risiko verwenden. Wir haben festgestellt, dass Unsicherheit und Bedrohung auf die gleiche Weise angegangen werden. Sie begegnen ihnen mit einer Kontrolle, und diese Kontrolle muss durch ein Arbeitspaket implementiert werden.
Navigieren richtet das Risiko entweder an einem Vermögenswert oder einem Ziel aus. Eine Kontrolle mindert das Risiko. Ein Arbeitspaket implementiert Kontrollen. Wir verknüpfen das Arbeitspaket mit dem verantwortlichen Projekt.
Ziele sind der Grund für die Veränderung. Verfehlt man sie, war die Veränderung sinnlos. Was tun Sie, um die Unsicherheit zu reduzieren, wenn Sie unsicher sind, ob Sie das Ziel erreichen? Die Bewältigung von Unsicherheit ist entscheidend. Implementierungsplanung und Umsetzungs-Governance Aktivität.
Auch hier trennen wir Risiko und Kontrolle vom Projekt. Wir verknüpfen sie über die Arbeit. Dies ermöglicht uns die Planung und Überwachung der Reduzierung des Umfangs.
Wir stellen regelmäßig fest, dass während der Projektinitiierung und -ausführung Ziele und Vermögenswerte, die nicht direkt mit dem Projekt und dem Projektsponsor verbunden sind, aus dem Geltungsbereich entfernt werden. Dies gilt insbesondere dann, wenn der Projektsponsor nicht Eigentümer der Ziele ist.
Wir erwarten von Veränderungsinitiativen routinemäßig, dass sie Fähigkeiten entwickeln, Agilität raubende Reibungsverluste reduzieren und laufende Betriebskosten senken. Doch sie scheitern regelmäßig. Sie scheitern, weil wir unsere Arbeit durch fokussierte Projekte erledigen. Jedes fokussierte Projekt ist an das Eiserne Dreieck gebunden und wird seinen Umfang drastisch reduzieren. Wir haben noch nie erlebt, dass eine Reduzierung des Umfangs als Bedrohung für ein Unternehmensziel dargestellt wurde. Sie wird immer als Verbesserung des Projekts dargestellt.
Enterprise-Architekten müssen die Unsicherheit hinsichtlich der Zielerreichung während der Implementierungsplanung berücksichtigen. Ohne diese können sie nicht Umsetzungs-Governance Aktivität.
Architekturvertrag
TOGAFs Konzept des Architekturvertrags ist unglaublich wirkungsvoll. Oft wird er als eine Art dokumentierte Vereinbarung zwischen dem EA-Team und dem Projekt präsentiert. Obwohl die Dokumentation nützlich ist, besteht der Vertrag zwischen dem Stakeholder und dem Projekt. Er ist niemals zwischen dem Projekt und dem EA-Team.
Wenn wir einen Architekturvertrag erstellen, stellen wir sicher, dass dieser Folgendes enthält:
- Nutzen
Welche Vorteile bietet das Projekt durch welche Arbeitspakete?
Dies verschafft den Implementierern, dem Governance-Prozess und den Stakeholdern, die den Nutzen erwarten, Transparenz darüber, wer verantwortlich ist und was sie tun, um ihrer Verantwortung nachzukommen.
- Kontrolle
Welche Kontrollen wird das Projekt durch welche Arbeitspakete liefern? Wie mindern diese Kontrollen die Risiken?
Genau wie der Nutzen bietet dies den Umsetzern, dem Governance-Prozess und den Stakeholdern, die das Ziel erreichen möchten, Transparenz darüber, wer verantwortlich ist und was sie tun, um ihrer Verantwortung nachzukommen.
- Architekturspezifikation
Welche Einschränkungen nehmen den Implementierern die Freiheit?
Dies verdeutlicht, wo ein Projektteam Vorgaben befolgen muss, die der Projektlogik widersprechen. Wenn die Projektlogik es dazu zwingt, die Vorgaben zu befolgen, benötigen wir die Architekturspezifikation nicht. Wir verwenden die Architekturspezifikation, wenn die Projektlogik eine ungünstige Entscheidung für das Unternehmen bedeuten würde.
- Strategie für den Implementierungsplan
Wie man Veränderungen angeht
Wie muss ein Implementierer das Projekt angehen, genau wie bei der Architekturspezifikation? Dies gilt insbesondere dann, wenn die Projektlogik ihn zu einem anderen Ansatz führt.
- Übergang
Wann stoppen wir absichtlich? Jede Minute Arbeit an Veränderungen nach einem Übergangspunkt ist wahrscheinlich verschwendet. Wir gestalten Übergangspunkte als Wert-Ruhepunkte. Punkte im Wandel, an denen die Stakeholder verzögern, anhalten oder die Richtung ändern können. Wir nutzen Übergänge für Umsetzungs-Governance. Sie helfen, wenn die Projektlogik oder die Präferenzen des Projektsponsors dazu führen, dass ein Projekt weiter voranschreitet als erwartet. Normalerweise wird die Effizienz erklärt. Wenn der Sponsor jedoch verzögert, stoppt oder die Richtung ändert und der nächste vollständige Wert-Ruhepunkt nicht erreicht wird, baut das Projekt eine weitere Halbbrücke.
Implementierungsstrategie
Unabhängig davon, ob Sie die Implementierungsstrategie in den Architekturvertrag aufnehmen, ist sie für die Erstellung eines Implementierungsplans von entscheidender Bedeutung. Die drei Arten von Änderungen (evolutionär, revolutionär und Greenfield) bestimmen das Projekt- und Systemdesign.
Wenn Sie beispielsweise von Grund auf neu beginnen müssen (Greenfield), erwarten Sie Änderungen an Organisation, Prozessen und Systemen. Sie verwerfen bewusst die bestehende Organisation, Prozesse und Systeme. Ihr Projekt sollte besser darauf ausgerichtet sein, etwas Neues zu schaffen und das Change Management durch den Wandel zu führen.
Ehrlich gesagt werden Altsysteme, schlechte Prozesse und starre Organisationen dadurch aufrechterhalten, dass man den einfachen Weg des Projekts (Evolutionär) ändert.
Verwenden Architektur-Roadmap-Techniken
Die verschiedenen Techniken zur Entwicklung einer Architektur-Roadmap werden verwendet, um bei der Ausarbeitung des Implementierungsplans unterschiedliche Leitlinien und Einschränkungen bereitzustellen.
Heatmaps bieten Orientierung und Einschränkungen anhand von Attributen wie Wert, Arbeit, Risiko oder Übergangszustand. Sie bestimmen das Projektdesign.
Lebenszyklusdiagramme bieten Orientierung und zeitliche Vorgaben. Unabhängig davon, ob es sich um ein System oder eine Änderung handelt, verdeutlicht das Diagramm die Start- und Stoppzeiten. Sie sind besonders hilfreich, wenn eine Änderung zu einem bestimmten Zeitpunkt erforderlich ist. Es ist überraschend, wie oft eine verspätete Änderung wertlos ist. Wenn das neue System nicht rechtzeitig verfügbar ist, verliert ein verspätetes neues System seinen Wert.
Abhängigkeitsmodelle bieten Orientierung und Einschränkungen hinsichtlich der Abhängigkeit. Unabhängig davon, ob es sich um Arbeits-, Organisations-, System- oder Übergangszustände handelt. Ein Abhängigkeitsdiagramm hilft Ihnen häufig dabei, die erforderlichen Daten in einem Lebenszyklusdiagramm zu verstehen.
Szenario-Roadmaps sind bei der Entwicklung eines Implementierungsplans selten hilfreich.
Komplexe Visualisierung von Arbeitspaketen, Architekturoptionen oder Übergangszustandsoptionen. Rad-Plots stellen typischerweise Anliegen oder Attribute wie Wert, Arbeit oder Risiko dar. Punkte auf dem Plot stellen üblicherweise Architekturoptionen oder Übergangszustandsoptionen dar.
Erfahren Sie mehr über Conexiams Architektur-Roadmap-Workshops
Übergangsarchitektur
Die Übergangsarchitektur bietet Orientierung und Einschränkungen hinsichtlich der Haltepunkte. Um einen Wert für die Ruhepunkte zu schaffen, strukturieren Sie Projekte so, dass sie gemeinsam den Übergangszustand erreichen. Die wichtigsten Termine in jedem Übergangszustand sind die ‘Erforderlich bis’- bzw. ‘Ablaufdaten’.
Lücke und Lösung
Lücken verdeutlichen, welche Mängel behoben werden müssen. Sie helfen einem Projekt, Umfang und Ergebnis zu definieren.
Lösungen vereinfachen das Design. Wenn eine erwartete Lösung oder Lösungsattribute vorhanden sind, vereinfacht dies Umfang und Design. Dies gilt insbesondere, wenn Sie eine Greenfield- oder revolutionäre Implementierungsstrategie gewählt haben.
Auf den Zweck der Unternehmensarchitektur abgestimmte Implementierungsplantechniken
Architekturteams unterstützen unterschiedliche Zwecke. Ob Sie Portfoliofragen oder die Lösungsbereitstellung unterstützen, beeinflusst die Art und Weise, wie Sie Architektur-Roadmaps entwickeln und nutzen. Beispielsweise verwendet Architektur zur Unterstützung der Lösungsbereitstellung keine Architektur-Roadmap Typ 1: Heatmap zur Entscheidungsfindung. Wir nutzen sie als übergeordnete Architektur und als eine Reihe von Einschränkungen für die Architekturentwicklung und deren Implementierung. Gute Architekten arbeiten stets innerhalb der Einschränkungen der übergeordneten Architektur.
| Architektur zur Unterstützung der Strategie | Architektur zur Unterstützung des Portfolios | Architektur zur Unterstützung des Projekts | Architektur zur Unterstützung der Lösungsbereitstellung | |
| Portfolioplanung | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Programmplanung | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Nutzenrealisierung | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Wichtiges Ergebnis und überlegene Architektur | Überlegene Architektur |
| Risikominderung | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Wichtiges Ergebnis und überlegene Architektur | Überlegene Architektur |
| Architekturvertrag | Wichtiges Ergebnis | Wichtigstes Ergebnis | Wichtigstes Ergebnis & Überragende Architektur | Wichtigstes Ergebnis & Überragende Architektur |
| Implementierungsstrategie | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur |
| Architektur-Roadmap Typ 1: Heatmap | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur |
| Architektur-Roadmap Typ 2: Lebenszyklusdiagramm | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur |
| Architektur-Roadmap Typ 3: Abhängigkeit | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur |
| Architektur-Roadmap Typ 4: Szenario | Überlegene Architektur | |||
| Übergangsarchitektur | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur |
| Lücke und Lösung | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur |
Implementierungsplantechniken für Anwendungsfälle der Unternehmensarchitektur
Implementierungsplantechniken bieten eine bessere Unterstützung für verschiedene Anwendungsfälle für Unternehmensarchitektur. Je nach Anwendungsfall können Unternehmensarchitekten ihren Stakeholdern mit unterschiedlichen Techniken effizienter helfen.
Zwar geht es bei jedem Anwendungsfall der Unternehmensarchitektur um Veränderungen, doch die Art der Veränderungen und die Treiber sind unterschiedlich.
| Strategischer Wandel | Inkrementelle Änderung | Kosten senken | Qualität verbessern | Verbessern Sie die Unternehmensagilität | Minimierung des Technologierisikos | IT-Modernisierung | Digitale Transformation | Rationalisierung des Anwendungsportfolios | Akquisitionsintegration | |
| Portfolioplanung | Kritisch | Nützlich | Kritisch | Nützlich | Nützlich | Kritisch | Nützlich | Kritisch | ||
| Programmplanung | Kritisch | Sehr nützlich | Nützlich | Nützlich | Kritisch | Sehr nützlich | Kritisch | Kritisch | Kritisch | Kritisch |
| Nutzenrealisierung | Kritisch | Sehr nützlich | Kritisch | Kritisch | Kritisch | Sehr nützlich | Sehr nützlich | Kritisch | Nützlich | Kritisch |
| Risikominderung | Kritisch | Sehr nützlich | Kritisch | Kritisch | Kritisch | Sehr nützlich | Sehr nützlich | Kritisch | Nützlich | Kritisch |
| Architekturvertrag | Kritisch | Nützlich | Nützlich | Nützlich | Kritisch | Kritisch | Nützlich | Kritisch | Kritisch | Kritisch |
| Implementierungsstrategie | Kritisch | Nützlich | Nützlich | Nützlich | Kritisch | Kritisch | Kritisch | Kritisch | Nützlich | Nützlich |
| Architektur-Roadmap Typ 1: Heatmap | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich |
| Architektur-Roadmap Typ 2: Lebenszyklusdiagramm | Kritisch | Kritisch | Nützlich | Nützlich | Kritisch | Nützlich | Nützlich | Kritisch | Nützlich | Kritisch |
| Architektur-Roadmap Typ 3: Abhängigkeit | Kritisch | Kritisch | Nützlich | Nützlich | Kritisch | Nützlich | Nützlich | Kritisch | Nützlich | Kritisch |
| Architektur-Roadmap Typ 4: Szenario | Eingeschränkte Nutzung | Eingeschränkte Nutzung | Eingeschränkte Nutzung | Nützlich | ||||||
| Übergangsarchitektur | Kritisch | Kritisch | Nützlich | Nützlich | Kritisch | Nützlich | Nützlich | Kritisch | Nützlich | Kritisch |
| Lücke und Lösung | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich |
Anwendung von Enterprise-Architecture-Prinzipien auf die Entwicklung von Implementierungsplänen
Ihre Architekturprinzipien bestimmen und begrenzen Ihren Implementierungsplan. Unsere Beratungspraktiken identifizierten 7 Architekturprinzipien, die jeder Unternehmensarchitekt kennen sollte. Die folgende Tabelle bietet ein einfaches Beispiel dafür, wie ein Implementierungsplan durch eine übergeordnete Architektur eingeschränkt wird.
Jeder Implementierungsplan, der nicht dem Wortlaut und Geist einer überlegenen Architektur entspricht, muss erkannt werden durch Unternehmensarchitektur-Governance und überarbeitet.
| Auswirkungen des Implementierungsplans | |
| Spielen Sie nicht mit dem Erfolg | Jede Veränderung muss im Hinblick auf die Möglichkeit bewertet werden, dass sie den aktuellen Erfolg beeinträchtigt. Potenzielle Verbesserungen müssen begrenzt werden, um sicherzustellen, dass die Ausgangsbasis erhalten bleibt. |
| Fokus auf Exzellenz | Veränderungen müssen fokussiert sein. Jede Veränderung ohne direkten Bezug zum Unternehmenswert muss hinterfragt werden. Nutzen Sie Wertdefinitionen, die Exzellenz unterstützen, um den potenziellen Wert einer Veränderung zu bewerten.
Scheuen Sie sich nicht, Änderungen, die die Unternehmensleistung nicht verbessern, als ‘wertfrei.'’ |
| Warum nicht eins? | Änderungen, die zu Doppelarbeit führen, müssen hinterfragt werden, da die Wertschöpfung dadurch verringert wird.
Änderungen, die Duplikate beseitigen, müssen zu einer Steigerung der Wertschöpfung führen. |
| Daten sind ein Vermögenswert | Stellen Sie sicher, dass die Kontrolle über das Datenmodell nicht auf eine Weise aufgegeben wird, die den Wert des Datenbestands mindert. |
| Systeme funktionieren, wo wir arbeiten | Arbeitsort und Arbeitsstil sind grundlegende Wertmaßstäbe. Jede Änderung, die Standort und Stil nicht berücksichtigt, führt zu einer Verringerung der Wertschöpfung. |
| Problemlose Benutzererfahrung | Die Änderungskosten müssen überprüft werden, um sicherzustellen, dass die Auswirkungen auf die Benutzer richtig bewertet werden. Vergleichen Sie die Auswirkungen der Änderung sorgfältig mit dem potenziellen Nutzen. Sie zahlen immer für die Auswirkungen, erhalten aber möglicherweise nicht den erwarteten Nutzen. |
| Selbstbedienung | Self-Service ist ein Maßstab für den Unternehmenswert. Betrachten Sie die Self-Service-Bereitstellung im Ausgangs-, Übergangs- und Zielzustand. Passen Sie Kosten- und Nutzenbewertungen an, um die Bereitstellung von Self-Service zu belohnen und Schäden an bestehendem Self-Service zu bestrafen. Sie zahlen immer für Schäden. Sie könnten einen Vorteil erhalten. |
Wie passt TOGAF Phase F zur agilen Entwicklung?
Jeder Implementierungsplan enthält zahlreiche Einschränkungen und Richtlinien für die agile Entwicklung. Wir sehen Unternehmensarchitektur und agile Entwicklung sich in vier Bereichen überschneiden. Es gibt vier Bereiche, in denen es eine Überschneidung gibt:
- Definieren Sie den agilen Ansatz
- den Rückstand im Sprint steuern
- Auswahlmöglichkeiten innerhalb der Sprints einschränken
- Lösen Sie die produktübergreifende Abhängigkeit
Der Implementierungsplan beeinflusst maßgeblich die Definition des agilen Ansatzes. Beispielsweise erzwingt oder verbietet das Implementierungsstrategiemodell die Verwendung agiler Entwicklung.
Übergangszustände und erwartete Vorteile werden die Produktentwicklung oder Produktfreigabe beeinflussen, die wiederum den Rückstand bestimmen.
Wie ermöglicht TOGAF Phase F Unternehmensagilität?
Unternehmensflexibilität ist die Fähigkeit Ihres Unternehmens, auf Unerwartetes zu reagieren. Implementierungspläne reagieren auf das Erwartete. Gute Planungskompetenz hilft Ihnen, auf Unerwartetes zu reagieren. Im Modell der Unternehmensagilität besteht eine direkte Korrelation mit der Fähigkeit, Informationen zu sammeln und Lösungsentscheidungen zu treffen. Dies sind Planungskompetenzen.
Unternehmensagilitätsmodell
- Wachsamkeit – Können Sie Chancen und Bedrohungen erkennen?
- Zugänglichkeit – Können Sie rechtzeitig auf relevante Informationen zugreifen, um zu antworten?
- Entschlossenheit – Können Sie anhand der verfügbaren Informationen eine Entscheidung treffen?
- Schnelligkeit – Können Sie Ihre Entscheidungen in der verfügbaren Zeit umsetzen?
- Flexibilität – Was tun Sie, um Handlungshürden abzubauen?
