TOGAF ADM Phase F – Erstellung 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 Enterprise Architect in Phase F?
- Welche Rolle spielen Portfolioplaner und Projektplaner in Phase F?
- Werkzeuge und Techniken des Implementierungsplans
- Techniken des Implementierungsplans
- Portfolioplanung
- Programmplanung
- Nutzenrealisierung
- Risikominderung
- Architekturvertrag
- Umsetzungsstrategie
- Verwenden von Architektur-Roadmap-Techniken für die Implementierungsplanung
- Architektur-Roadmap Typ 1: Heatmap
- Architektur-Roadmap Typ 2: Lebenszyklusdiagramme
- Architektur-Roadmap Typ 3: Auswirkung und Abhängigkeit des Arbeitspakets
- Architektur-Roadmap Typ 4: Szenarioanalyse
- Übergangsarchitektur
- Lücke & Lösung
- Techniken des Implementierungsplans, die auf den Zweck der Architektur ausgerichtet sind
- Implementierungsplantechniken für Anwendungsfälle der Unternehmensarchitektur
- Wie passt TOGAF Phase F zur agilen Entwicklung?
- Wie ermöglicht TOGAF Phase F Enterprise Agilität?
- Abschließende Gedanken zu TOGAF ADM Phase F – Erstellung des Implementierungsplans
TOGAF ADM-Übersicht
Der TOGAF ADM setzt die TOGAF-Framework abgesehen von anderen Frameworks für Unternehmensarchitekturen. Es ist das einzige Unternehmensarchitektur-Framework, das alle enthält drei Teile eines Rahmens – wie man eine Architektur dokumentiert, wie man ein Team für Unternehmensarchitektur aufbaut, und wie man eine Architektur entwickelt.
TOGAF ADM entwickelt eine Unternehmensarchitektur
Jeder TOGAF-ADM Phase erläutert die Aktivitäten zur Wissensentwicklung. Jede ADM-Phase entwickelt Wissen über einen Teil der Unternehmensstruktur. Die Interaktionen zwischen den Phasen sind Informationsflüsse. Diese Informationsflüsse vereinen sich zu einigen wichtigen Ergebnissen – eines davon ist der TOGAF ADM Phase F Implementierungsplan.
Was ist TOGAF Phase F?
TOGAF Phase F bietet Unternehmensarchitekten die Schritte und Informationseingaben, um Planer bei der Ausarbeitung eines Implementierungsplans zu unterstützen. Es ist eine klare Best Practice für Unternehmensarchitekten, Planer zu unterstützen. Ihre Rolle 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 Umsetzungsplan. Die Architektur-Roadmap hat bereits schlechte Änderungsmöglichkeiten herausgesiebt. Der Implementierungsplan beschreibt, wie Ihre Organisation Änderungen durchführen und die Übergangszustände erreichen will.
Wenn wir die Unternehmensarchitektur erklären, sprechen wir davon, mögliche Veränderungen in Betracht zu ziehen und Optionen abzuwägen. All das ist Vergangenheit. Die Architektur-Roadmap weist den Weg nach vorn, potenzielle Übergangspunkte. Es ist Zeit für die letzte Auswahl.
Erfolg erfordert:
- Sie entscheiden, wie Sie Änderungen durchführen (Projekte)
- Sie kennen die Ressourcen, die für die Umsetzung der Änderung bereitgestellt werden
- Sie kennen die erforderlichen Vorteile und Einschränkungen (Architekturvertrag)
Interaktion mit TOGAF Phase B, Phase C Phase D, und Phase E
Während Wasserfallansätze keine gute Architektur liefern, sollte es einen scharfen Bruch zwischen einer Architektur-Roadmap und der Erstellung eines Implementierungsplans geben. Das Erkunden und Verwerfen potenzieller Änderungen ist ein wertvolles Ergebnis in der Unternehmensarchitektur. Phase F tritt in eine harte, praktische Welt ein.
Portfolioplaner, Programmmanager und Projektmanager leben nicht in einer Welt voller Möglichkeiten. Sie leben in einer harten Welt der Hinrichtung. Sie sprechen von Dingen wie der eisernes Dreieck. Sie erwarten, das Ziel, die erwarteten Vorteile und Einschränkungen zu erfahren. Sie wollen alle über die Ziellinie ziehen.
Während der TOGAF-Standard besagt, dass Sie die Zielarchitektur nicht vor Phase F fertigstellen werden, wird sich Ihre Architektur nur ändern, wenn Ihre Organisation sich weigert, fortzufahren. Andernfalls ist die Architekturentwicklung abgeschlossen.
Was ist ein Architekturimplementierungsplan?
Ein Implementierungsplan enthält einen Zeitplan der Projekte, mit denen die Zielarchitektur realisiert wird. Die ausführbaren Projekte werden in verwaltete Portfolios und Programme gruppiert. Das Umsetzungsstrategie beschreibt den Ansatz zur Veränderung.
Lassen Sie uns die Definition des Implementierungsplans entpacken. Erstens ist der Implementierungsplan ein Zeitplan. Es verknüpft Projekte zeitlich.
Zweitens basiert es auf einem Projekt. Wir wissen von PMI dass jedes Projekt eine Reihe voneinander abhängiger Aufgaben ist, die ein gemeinsames Ziel haben. Projekteigenschaften:
- Ein klares Start- und Enddatum. Sie haben einen klaren Anfang, ein bestimmtes Ende und einen Überblick darüber, was dazwischen passiert
- Sie schaffen etwas Neues. Sie sind eine einmalige einmalige Aktivität. Es wird nie wieder auf die gleiche Weise wiederholt
- Es hat klare Grenzen. Sie arbeiten innerhalb der Einschränkungen von Zeit, Geld, Qualität und Funktionalität
- Es ist nie Business as usual. Es ändert das Geschäft wie gewohnt
Drittens gruppiert es die Projekte in Portfolios und Programme für die Verwaltung.
Zuletzt wird angegeben, wie der Wandel ablaufen wird. Das Umsetzungsstrategie erfordert eine Änderung:
- Evolutionär
- Revolutionär
- Grüne Wiese
Warum unterscheidet sich ein Implementierungsplan von einer Architektur-Roadmap?
Das TOGAF-Standard-ADM trennt Phase E und Phase F sowie die Architektur-Roadmap vom Implementierungs- und Migrationsplan. Die Trennung basiert auf einer Best-Practice-Planung. Eine Architektur-Roadmap unterstützt bei der Entscheidung über Weg, Ziel und wo noch keine Entscheidungen getroffen wurden. Es unterstützt auch die Identifizierung von ungelösten Gabelungen in der Journey. Der Implementierungs- und Migrationsplan unterstützt nur die Ausführung.
Wir können garantieren, dass Ihre aktuellen Roadmaps eher wie Implementierungspläne als wie Architektur-Roadmaps aussehen. Wir sehen jedoch selten, dass die Arbeit in einzelne Projekte aufgeteilt und die Projekte mit Portfolio und Programm für das Management verknüpft sind. In der Regel handelt es sich um ein einzelnes umfangreiches Projekt. Selten ist die Implementierungsstrategie explizit, was dazu führt, dass das Projekt versucht, innerhalb des Projekts zu entscheiden, was der beste Ansatz ist. Sie entscheiden sich immer für den Weg, der für das Projekt am einfachsten ist.
Die Entwicklung eines echten Implementierungsplans erfolgt mit Stakeholdern, Ressourcenbesitzern und den Planern Ihres Unternehmens. Der Unternehmensarchitekt ist da, um den erwarteten Wert, die Abhängigkeit und die Implementierungsstrategie hervorzuheben. Wir haben den Wert bereits bewertet. Sie haben Übergangsarchitekturen. Dies ist eine Übung in der Planung, das zu liefern, was erwartet wird, nicht herauszufinden, was angemessen ist.
Ergebnisse des Implementierungsplans der Phase F von TOGAF ADM
Die beiden zentralen Ergebnisse von Phase F sind ein Implementierungsplan und ein Architekturvertrag. Dies ist der Aktionsteil der Unternehmensarchitektur.
Wertvollste Verwendung des Implementierungsplans
- Definieren des Änderungsplans. Identifizieren Sie, was sich bis wann ändern wird
- Definition der Art der Änderung durch die Implementierungsstrategie
- Definieren der Steuerung durch Portfolio und Programm
Ein Implementierungsplan hilft bei der Beantwortung der folgenden Fragen:
- Wann es zu Veränderungen kommt – Projekte des Implementierungsplans
- Was sich ändern muss und was nicht – Projekte des Implementierungsplans
- Welche Art von Veränderung wird passieren – Umsetzungsstrategie
- Welche Arbeit konzentriert sich auf bestimmte Ergebnisse – Portfolio des Implementierungsplans
- Welche Arbeiten werden gemeinsam ausgeführt – Das Programm des Implementierungsplans
Ein Architekturvertrag hilft bei der Beantwortung folgender Fragen:
- Welcher materielle und immaterielle Nutzen wird erwartet – Architekturvertrag - Nutzen
- Wenn Zwänge die Freiheit der Implementierer einschränken – Architekturvertrag – Architekturspezifikation
- Umgang mit Risiken und Ungewissheiten – Architekturvertrag - Kontrolle
- Welche Änderung ist zu erwarten – Architekturvertrag – Umsetzungsstrategie
- Welche Änderung ist tabu – Architekturvertrag - Übergang & Nutzen
Ein Implementierungsplan ist ein Werkzeug zur Ausführung von Unternehmensänderungen. Es bringt die Ausführung zusammen und stellt eine Organisation zusammen.
Fertigstellung des Phase-F-Implementierungsplans
Alle TOGAF ADM-Phasen führen Sie dazu, das Wissen zu entwickeln, das Sie benötigen. Das Ergebnis von Phase F ist ein Implementierungsplan und ein unterstützender Architekturvertrag.
Ausgabe & Ergebnis | Wesentliches Wissen |
Eine genehmigte Reihe von Projekten[1], die das Ziel und alle notwendigen Einschränkungen, erforderlichen Ressourcen sowie Start- und Enddaten enthält. | Verfügbare Ressourcen, um die Änderung vorzunehmen.
Wie sich die Priorität und Präferenz von Stakeholdern als Reaktion auf Wert, Aufwand und Änderungsrisiko anpassen. (Stakeholder-Anforderungen) |
Tabelle ab Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen
Phase F nackte Knochen
In Phase F leisten die Änderungsplaner den größten Teil der schweren Arbeit. Umsetzungspläne erfordern eine Verpflichtung zur Arbeit.
Die nackten Knochen von Phase F sind:
- Was ändert sich wann – Projekte des Implementierungsplans
- Welche Art von Veränderung wird passieren – Umsetzungsstrategie
- Wie die Veränderung zu einem Ergebnis geführt wird – Portfolio des Implementierungsplans
- Wie Wandel als Arbeit gemanagt wird – Das Programm des Implementierungsplans
- Welcher Nutzen wird geliefert – Architekturvertrag
- Welche Einschränkungen schränken die Freiheit der Implementierer ein – Architekturvertrag
Wir fühlen uns in Phase F immer befreit. Die breiten Architekturmöglichkeiten verengen sich auf einen einzigen Thread. All die komplexen Kompromisse liegen hinter uns, und wir stehen vor dem harten Aushandeln von Ressourcen und Zeit. 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 ändert sich wann
Arbeitspakete, die Projekten zugeordnet sind. Ein oder mehrere Projekte, die einen Übergangszustand oder das endgültige Ziel erreichen. Was wird sich ändern? Wann wird es passieren?
Sie müssen Übergangszustände erklären. Implementierer sind konkrete Realisten. Sie werden sich mit dem Zielstaat identifizieren und versuchen, dorthin zu fahren. Infolgedessen werden sie einen Übergangszustand überwinden wollen. Sie werden sich bei der Vorstellung sehr unwohl fühlen, dass ein Stakeholder zu einem Wertruhepunkt als Synonym gelangt und eine Ausfahrt ausführt.
Welche Arbeit, welcher Umfang, wann. Es ist alles im Projekte des Implementierungsplans.
- Welche Art von Veränderung wird passieren
Überlassen Sie die Art der Änderung niemals einem Projektteam. Sie haben ein Endziel und werden jede Ecke abschneiden, um den Sieg zu erringen. Daher sind Systeme nicht stillgelegt. Aus diesem Grund Legacy-Prozesse ewig andauern. Wenn Sie Ersatz erwarten, ist es Greenfield. Wenn Sie eine Verbesserung erwarten, ist es evolutionär. Sei klar und dann rein Phase-G-Implementierungs-Governance Prüfung auf Übereinstimmung. Verwenden Sie Ihr Stärkstes Implementierungs-Governance Werkzeuge, die Umsetzungsstrategie.
- Wie die Änderung zu einem Ergebnis geführt wird
Der Beruf des Projektmanagements erfand das Konzept von Portfolio und Programm, um das Problem der Verwaltung einer komplexen Reihe von Projekten zu lösen. Menschen, die die Arbeit erledigen, haben Schwierigkeiten zu erkennen, wie sie zusammenpassen. Sie achten auf eine sehr unmittelbare Belohnung und werden sich auf die konkrete Lieferung am Ende des Projekts konzentrieren. Wenn Ihre Unternehmensarchitektur einen oder mehrere Übergangszustände hat, benötigen Sie zusätzliche Implementierungs-Governance.
Die Gruppierung von Projekten nach Ergebnis und die Benennung eines Verantwortlichen für das Ergebnis vereinfachen die Governance der Implementierung. Best-Practice-Architektur-Governance nutzt natürliche Autoritätsstrukturen. Portfoliomanagement ist eine natürliche Struktur. Helfen Sie Ihren Stakeholdern bei der Erstellung ihrer Portfolio des Implementierungsplans.
- Wie Veränderung als Arbeit gehandhabt wird
Portfolio wird verwendet, um das Ergebnis zu gruppieren. Das Programm wird zum Gruppieren für die Ausführung verwendet. Wenn Sie Projekte nach Ausführung gruppieren, vereinfachen Sie Implementierungs-Governance. Folgen Sie der Portfolio-Gruppierung Best-Practice-Architektur-Governance und eine natürliche Autoritätsstruktur annehmen. Helfen Sie Ihren Stakeholdern bei der Erstellung ihrer Das Programm des Implementierungsplans.
- Welcher Nutzen wird geliefert
Wir haben das Konzept des Architekturvertrags entwickelt, um den Nutzen oder Wert von einer Projektbeschreibung zu trennen. Projektteams blicken auf das Ende des Projekts. Projektteams achten auf die Bedürfnisse ihrer Sponsoren. Sie können davon ausgehen, dass Implementierer Vorteile fallen lassen, die nicht direkt auf ihr Projekt ausgerichtet sind. Sie können davon ausgehen, dass der Rückgang als Risikominderung oder Kostensenkung umrahmt wird.
Um eine klare Richtung und Kontrolle bereitzustellen, verwenden Sie die Architekturvertrag um den Vorteil oder Wert zu haben. Vor allem, wenn Sie bauen Fähigkeit oder Zukunft sichern Unternehmensagilität.
- Welche Beschränkungen begrenzen die Freiheit der Implementierer
Wenn Sie etwas nicht haben muss Kontrolle, 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. Im Navigieren™verwenden wir vier Arten von Architekturspezifikationen:
- Prinzip, wenn allgemeine Entscheidungshilfen angebracht sind
- Muster, bei dem es einen bekannten bevorzugten Ansatz gibt
- Standard, wo es einen bekannten akzeptablen Ansatz gibt
- Regel, bei der alle Auswahlmöglichkeiten entfernt werden müssen
Wir erwarten von unseren Unternehmensarchitekten, dass sie immer einen Standard haben, bevor sie eine Regel erstellen. Testen Sie ihren Standard gegen ein Muster. Stellen Sie sicher, dass das Muster dem Prinzip entspricht. Wir tun dies, um sicherzustellen, dass wir die Freiheitsgrade der Implementierer so wenig wie möglich eingeschränkt haben. Das Schreiben einer Regel ist einfach, aber es erfordert nahezu Allwissenheit. Sie müssen nach vorne schauen und die einzigartigen Umstände und zukünftigen Fähigkeiten kennen. Oder versteh die Regel falsch.
Die drei wichtigsten Punkte für den Abschluss von Phase F:
- Zuerst die Definition of Done. Wann kommen wir in einen Übergangszustand?
- Zweitens, Verantwortlichkeit für Veränderungen. Wer ist für welches Portfolio oder Programm verantwortlich?
- Drittens Straßenverkehrsordnung. Welcher Nutzen wird geliefert? Welche Beschränkung wird auferlegt?
Mit diesen drei Grundvoraussetzungen sind die Beteiligten bereit, einen Umsetzungsplan zu entwickeln. Sie wissen, was sie getan haben wollen. Sie wissen, was sie nicht ändern wollen. Sie wissen, wie sie ihre Implementierer eingeschränkt haben.
TOGAF ADM Phase F – Ergebnisse des Implementierungsplans und Zwecke der Unternehmensarchitektur
Es gibt vier Hauptziele für die Entwicklung einer Unternehmensarchitektur. Entweder unterstützen Sie Strategie, Portfolio, Projekt oder Lösungsbereitstellung. In den meisten Fällen werden Sie keine Architektur-Roadmap entwickeln, wenn Sie nicht Strategie oder Portfolio unterstützen. Die Muster werden im Abschnitt Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen.
Unterschiedliche Leistungen haben für jeden Zweck unterschiedliche Bedeutung.
Architektur zur Unterstützung der Strategie
Wenn Sie die Strategie unterstützen, stellen Sie eine End-to-End-Zielarchitektur bereit und entwickeln Roadmaps für Änderungen. Ihre Architektur identifiziert Änderungsinitiativen und unterstützende Portfolios und Programme. Die Architektur-Roadmap legt Referenzbedingungen fest, identifiziert Synergien und regelt die Ausführung von Portfolios und Programmen.
Architektur zur Unterstützung von Portfolio
Wenn Sie ein Portfolio unterstützen, sprechen Sie normalerweise das einzelne Portfolio an. Ihre Architektur wird Projekte identifizieren und ihre Aufgabenbereiche festlegen, ihre Ansätze ausrichten, Synergien identifizieren und die Ausführung des Projekts steuern.
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 der Phase F: Architekturimplementierungsplan | Wahrscheinlich nicht verwendet | Schlüssel lieferbar
Während der Portfoliobudgetierung Aktualisieren Sie sie nach Bedarf, um Budgetierung und Programmverwaltung zu unterstützen |
Schlüssel lieferbar
Vor Projektstart |
Schlüssel lieferbar
Vor Verlobung und Vertragsabschluss |
Arbeitsergebnis Phase F: Architekturvertrag | Wahrscheinlich nicht verwendet | Eingeschränkte Nutzung | Schlüssel lieferbar
Vor Abschluss der Projektinitiierung |
Schlüssel lieferbar
Vor Verlobung und Vertragsabschluss |
Arbeitsprodukt der Phase F: Zielunternehmensarchitektur | Wichtige Lieferung
Wird für Aufzeichnungen und zukünftige Architekturentwicklungen verwendet |
Wichtige Lieferung
Wird für Aufzeichnungen und zukünftige Architekturentwicklungen verwendet |
Meist überlegene Architektur
Wird für Aufzeichnungen und zukünftige Architekturentwicklungen verwendet |
Überlegene Architektur |
Tabelle ab Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen
Implementierungsplan
Die Struktur Ihres Implementierungsplans ändert sich, unabhängig davon, ob Sie an der Unterstützung von Strategien, Portfolios oder Projekten arbeiten. Umsetzungspläne sind gewohnt Umsetzung regeln.
Architektur zur Unterstützung der Strategie | Architektur zur Unterstützung von Portfolio | Architektur zur Unterstützung des Projekts | Architektur zur Unterstützung der Lösungsbereitstellung | |
Umsetzungsplan-Projekte | Zusammenfassung | Schlüssel lieferbar | Überlegene Architektur | Überlegene Architektur |
Implementierungsplan-Strategie | Passend zum Projekt | Schlüssel lieferbar | Key Deliverable oder überlegene Architektur | Überlegene Architektur |
Implementierungsplan-Portfolio | Schlüssel lieferbar | Schlüssel lieferbar | Überlegene Architektur | Überlegene Architektur |
Implementierungsplan-Programm | Schlüssel lieferbar | Schlüssel lieferbar | Überlegene Architektur | Überlegene Architektur |
Architekturvertrag
Architektur zur Unterstützung der Strategie | Architektur zur Unterstützung von Portfolio | Architektur zur Unterstützung des Projekts | Architektur zur Unterstützung der Lösungsbereitstellung | |
Architekturvertrag - Nutzen | Passend zum Projekt | Schlüssel lieferbar | Schlüssel lieferbar oder überlegene Architektur | Überlegene Architektur |
Architekturvertrag – Architekturspezifikation | Prinzip | Prinzip & Muster | Prinzip, Muster und Standard | Prinzip, Muster, Standard und Regel |
Architekturvertrag - Kontrolle | Passend zum Projekt | Schlüssel lieferbar passend zum Projekt | Schlüssel lieferbar oder überlegene Architektur | Schlüssel lieferbar oder überlegene Architektur |
Architekturvertrag - Umsetzungsplanstrategie | Passend zum Projekt | Schlüssel lieferbar | Schlüssel lieferbar oder überlegene Architektur | Überlegene Architektur |
Architekturvertrag – Übergang | Schlüssel lieferbar | Schlüssel lieferbar oder überlegene Architektur | Schlüssel lieferbar oder überlegene Architektur | Überlegene Architektur |
Zielunternehmensarchitektur
Das Ganze Die Unternehmensarchitektur umfasst die Domänenarchitekturmodelle und die Menge der konsolidierten Lücken. Als Ergebnis aktualisieren Sie die Ziel-Unternehmensarchitektur, um sie in der zukünftigen Architekturentwicklung oder als Referenz in der Implementierungs-Governance der Phase G zu verwenden.
Modelle, aus denen die Target Enterprise Architecture besteht
- >>> 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. Sie müssen die Zielarchitektur und alle Übergänge interpretieren. Am wichtigsten ist, dass sie sicherstellen, dass erwartete Vorteile und Einschränkungen in den Plänen erfasst werden.
Architekten sind es gewohnt, Arbeitsabläufe zu planen, die unerwartete Vorteile bringen. Oder erwarten, dass eine Einschränkung erforderlich ist. Der Unternehmensarchitekt muss Übergangszustände erklären.
Projektplaner haben kurze Zeithorizonte und sind sehr direkte Denker. Sie werden sich unwohl fühlen mit:
- Immaterielle Vorteile
- Aufgeschobene Vorteilsrealisierung
- Einschränkung, die das aktuelle Projekt behindert
Hinsichtlich des Nutzens verwenden wir immer das Beispiel des Brückenbaus. Die Rampe und die Stützen sind notwendig, liefern aber keinen Mehrwert. Außerdem bietet die Brücke keinen realisierbaren Wert, bis Sie das gesamte Straßendeck fertiggestellt haben. Es hilft den Menschen zu verstehen, dass wir möglicherweise viel Arbeit leisten, einfach um mehr Arbeit zu leisten, bevor wir einen signifikanten Nutzen erzielen können.
Wir finden, dass das Sprechen über Autobahnen und Autobahnkreuze ihnen hilft, Einschränkungen zu verstehen, die das aktuelle Projekt behindern. Mit zunehmendem Verkehrsaufkommen steigen die Kosten für den Straßenunterbau und den Asphalt dramatisch an. Bis wir die Brücke bauen, ist das Verkehrsaufkommen gering, sodass die Ausgaben für den Straßenbelag die Kosten des aktuellen Projekts einfach in die Höhe treiben. Wenn die Straße, die Brücke und die Anschlussstelle zusammenkommen, haben Sie ein Verkehrsnetz, das dem Volumen standhalten kann. Einer, der Wert liefert. Eine, die es nicht erfordert, die genutzte Straße aufzureißen und neu zu bauen.
Die wichtigste Rolle des Unternehmensarchitekten ist das Vorausdenken und das Überschreiten von Grenzen. Sie werden verstehen, warum das aktuelle Projekt möglicherweise eingeschränkt ist oder die Erfolgskriterien nicht offensichtlich sind. Sie werden dazu beitragen, die Portfoliobesitzer einzubeziehen, wenn der Projektsponsor die Unternehmensvorteile entfernt.
Zwei zentrale Fakten zu TOGAF Phase F – Umsetzungsplan
Gehen Sie pragmatisch an Aufbau Ihrer Enterprise-Architektur-Teams. Wir stützen unseren pragmatischen Ansatz auf eine unbequeme Tatsache: Wenn normales Denken flexible, effiziente Organisationen hervorbringen würde, gäbe es unseren Beruf nicht. Unternehmensarchitektur erfordert abnormales Denken.
Es gibt zwei zentrale Tatsachen, die wir erzählen Unternehmensarchitekten über TOGAF Phase F – Architektur-Roadmap. Erstens wird außer Ihrem Stakeholder niemand, der an der Implementierungsplanung beteiligt ist, alles glauben, was Sie sagen. Ihre Ideen werden immer zu groß, zu aufgeschoben, zu theoretisch sein. Sie müssen jeden wie eine Falke beobachten, die nach Mäusen Ausschau hält. Sie brauchen eine starke Beziehung zu Ihren Stakeholdern. Sie müssen die Kompromissgespräche nutzen, die Sie bereits geführt haben, um die Architektur-Roadmap zu entwickeln. Tatsächlich können Sie damit rechnen, den Kompromiss mit allen anderen erneut zu argumentieren. Zweitens, wenn Sie keinen dokumentierten Architekturvertrag haben, werden Sie mit der Implementierungs-Governance zu kämpfen haben. Niemand wird sich an den erwarteten Nutzen, die Implementierungsstrategie oder irgendwelche Einschränkungen erinnern. Je. Sie werden während der Projektausführung alles neu erfinden (TOGAF-ADM-Phase G), um das Projekt so einfach wie möglich abzuschließen, um den taktischen Interessen des Projektsponsors zu dienen.
Stakeholder brauchen Unternehmensarchitekten, um den gewünschten Wert zu schützen. Normalerweise kommt der größte Teil der Bewachung vom Projektsponsor und dem Implementierungsteam.
[1] Fixieren Sie sich nicht auf die Definition des Begriffs „Projekt“ oder was ein Projekt ist. Es ist nur eine organisatorische Anstrengung für die Arbeit, um ein verständliches Ergebnis zu erzielen. Die interne Definition eines Projekts in Ihrer Organisation und die verwendete Bezeichnung stimmen wahrscheinlich nicht mit denen anderer überein. Meine Assistentin bezeichnet die Flugbuchung als Projekt.
Implementierungsplanmodelle, Tools und Techniken
Die TOGAF ADM Phase F liefert den Implementierungsplan und den Architekturvertrag. Diese Phase existiert, um Aktionen zu ermöglichen.
Phase F ist eine Umsetzung der Architektur-Roadmap und der Zielarchitektur in die Tat. Es gibt fünf zentrale Techniken zur Erstellung von Implementierungsplänen, die den Beteiligten helfen zu verstehen, wie die Vorteile der Zielarchitektur realisiert werden können.
- Portfolio-Gruppierung
- Programmgruppierung
- Nutzenrealisierung
- Risikominderung
- Architekturvertrag
- Modell der Implementierungsstrategie
- Verwenden von Architektur-Roadmap-Techniken
Techniken des Implementierungsplans
Zusammengenommen werden die Techniken alles hervorheben, was die Unternehmensarchitekten zum Erstellen des Implementierungsplans beitragen müssen. Die Rolle des Unternehmensarchitekten besteht darin, den Wert der Änderung zu schützen.
Portfolioplanung / Portfoliogruppierung
Der Beruf des Projektmanagements verwendet Portfolio und Programm, um die Verwaltung einer komplexen Reihe von Projekten zu ermöglichen. Projektsponsoren und Implementierer sehen sich die expliziten Ergebnisse des Projekts an.
Die Portfolioplanung gruppiert die Projekte nach Ergebnis. Als bestimmtes Portfolio kann jemand für das Ergebnis verantwortlich sein. Dies erhöht die Erfolgschancen und ermöglicht eine Umsetzungssteuerung.
Das Portfolio schafft eine natürliche Autoritätsstruktur. Der Rest der Organisation übernimmt die Autoritätsstruktur und die ergebnisbasierte Berichterstattung.
Programmplanung / Programmgruppierung
Programm gruppiert Projekte zur Ausführung. Genau wie bei Portfolio erreichen Sie eine Person, die für die Verwaltung einer Reihe verwandter Projekte verantwortlich ist. Es entsteht eine umsetzungsorientierte natürliche Autoritätsstruktur. Der Rest der Organisation übernimmt die Autoritätsstruktur und die ausführungsbasierte Berichterstattung.
Nutzenrealisierung
Wir richten die Vorteile der Unternehmensarchitektur immer an den Mängeln aus, die die aktuelle Architekturentwicklung auslösten. Dazu nutzen wir die Architecture Roadmap und die Enterprise Architecture Umsetzung regeln. Dies erfordert die Trennung des erwarteten Nutzens von dem Projekt, von dem erwartet wird, dass er den Nutzen liefert.
In Navigieren Wir richten einen Nutzen an einem Arbeitspaket aus. Wir verknüpfen das Arbeitspaket mit der Lücke, die es füllt, und dem Projekt, das es liefern wird.
Wir stellen routinemäßig fest, dass während der Projektinitiierung und Projektausführung die Arbeit, die einen Nutzen bringt, de-scoped wird, während der Nutzen weiterhin auf den PowerPoint-Folien des Projekts erscheint. Dies gilt insbesondere dann, wenn der Projektsponsor den Vorteil nicht erhält.
Unternehmensarchitektur existiert, um effektive Veränderungen zu steuern. Effektive Veränderung realisiert die Vorteile.
Bei der Erstellung des Implementierungsplans suchen wir nach der Arbeit, die explizit eine Lücke füllt und einen Nutzen bringt. Keine Arbeit, und Sie haben eine ungefüllte Lücke und einen fehlenden Nutzen.
Risikominderung
Wir haben zwei Verwendungen des Begriffs Risiko. Erstens ist es die Auswirkung der Unsicherheit auf das Erreichen Ihres Ziels. Dies ist die Definition, die vom Berufsstand des Risikomanagements verwendet wird. Wir finden, dass es am stärksten mit der Unternehmensarchitektur übereinstimmt. Zweitens ist die normale Verwendung, bei der ein Risiko eine schlechte Sache ist, die passieren kann. Wir stellen fest, dass die meisten Menschen unter Risiko eine Bedrohung oder eine schlechte Sache sehen. Es spielt keine Rolle, wie Sie Risk verwenden. Wir stellen fest, dass Unsicherheit und Bedrohung auf die gleiche Weise angegangen werden. Sie adressieren es mit einer Kontrolle, und diese Kontrolle muss durch ein Arbeitspaket implementiert werden.
Navigieren richtet das Risiko entweder auf einen Vermögenswert oder ein Ziel aus. Eine Kontrolle mindert das Risiko. Ein Arbeitspaket implementiert Kontrollen. Wir verknüpfen das Arbeitspaket mit dem verantwortlichen Projekt.
Ziele sind der Grund, warum wir die Veränderung vornehmen. Fehlend bedeutet, dass die Änderung sinnlos war. Wenn Sie unsicher sind, ob Sie das Ziel erreichen, was tun Sie, um die Unsicherheit zu verringern? Der Umgang mit Unsicherheit ist eine wichtige Implementierungsplanung und Implementierungs-Governance Aktivität.
Auch hier trennen wir Risiko und Kontrolle vom Projekt. Wir verbinden uns durch Arbeit. Dies ermöglicht uns die Planung und Überwachung des De-Scopes.
Wir stellen routinemäßig fest, dass während der Projektinitiierung und Projektdurchführung Ziele und Vermögenswerte, die nicht direkt mit dem Projekt und dem Projektsponsor verbunden sind, de-scoped werden. Dies gilt insbesondere dann, wenn der Projektsponsor das Ziel nicht besitzt.
Wir erwarteten routinemäßig Veränderungsinitiativen, um Fähigkeiten zu entwickeln, Reibungsverluste durch Agilität zu verringern und laufende Betriebskosten zu senken. Trotzdem scheitern sie regelmäßig. Sie scheitern, weil wir Arbeit durch fokussierte Projekte liefern. Jedes fokussierte Projekt ist an das Eiserne Dreieck gebunden und wird aggressiv den Umfang aufheben. Wir haben noch nie erlebt, dass ein Descoping als Bedrohung für ein Unternehmensziel dargestellt wird. Sie präsentieren es immer als Verbesserung des Projekts.
Unternehmensarchitekten müssen die Ungewissheit beim Erreichen von Zielen während der Implementierungsplanung ansprechen. Ohne diese können sie nicht auftreten Implementierungs-Governance Aktivität.
Architekturvertrag
Das Konzept des Architekturvertrags von TOGAF ist unglaublich leistungsfähig. Oft wird es als eine Art dokumentierte Vereinbarung zwischen dem EA-Team und dem Projekt präsentiert. Während die Dokumentation nützlich ist, besteht der Vertrag zwischen dem Stakeholder und dem Projekt. es ist noch nie zwischen dem Projekt und dem EA-Team.
Wenn wir einen Architekturvertrag erstellen, stellen wir sicher, dass er Folgendes beinhaltet:
- Nutzen
Welche Vorteile wird das Projekt durch welche Arbeitspakete liefern?
Dies verschafft den Implementierern, dem Governance-Prozess und den Stakeholdern, die den Nutzen erwarten, wer verantwortlich ist, und was sie tun, um ihrer Verantwortung gerecht zu werden, Transparenz.
- Kontrolle
Welche Kontrollen wird das Projekt durch welche Arbeitspakete liefern? Welche Risiken mindern diese Kontrollen?
Genau wie der Nutzen bietet dies den Implementierern, dem Governance-Prozess und den Stakeholdern, die erwarten, das Ziel zu erreichen, wer verantwortlich ist und was sie tun, um ihre Verantwortlichkeit zu erfüllen, Transparenz.
- Architekturspezifikation
Welche Beschränkungen nehmen den Implementierern die Freiheit?
Dies verdeutlicht, wo ein Projektteam einer Anleitung folgen muss, die der Logik ihres Projekts widerspricht. Wenn die Logik ihres Projekts sie dazu bringt, der Einschränkung zu folgen, brauchen wir die Architekturspezifikation nicht. Wir verwenden die Architekturspezifikation, wenn die Logik des Projekts zu einer schlechten Wahl für das Unternehmen führen würde.
- Implementierungsplan-Strategie
Wie man Veränderungen angeht
Wie muss ein Implementierer, genau wie die Architekturspezifikation, an das Projekt herangehen? Dies gilt insbesondere dann, wenn die Projektlogik sie zu einem anderen Ansatz führt.
- Übergang
Wann hören wir absichtlich auf? Jede Minute der Änderungsarbeit nach einem Übergangspunkt ist wahrscheinlich Verschwendung. Wir machen Übergangspunkte zu Wertruhepunkten. Punkte in der Änderung, an denen die Stakeholder die Richtung verzögern, stoppen oder ändern können. Wir verwenden Übergänge für Implementierungs-Governance. Sie helfen, wenn die Projektlogik oder Präferenzen des Projektsponsors dazu führen, dass ein Projekt weiter geht als erwartet. In der Regel mit Erläuterung der Effizienz. Wenn die Sponsoren jedoch verzögern, anhalten oder die Richtung ändern und der nächste vollständige Value Resting Point nicht erreicht wird, baute das Projekt eine weitere Halbbrücke.
Umsetzungsstrategie
Unabhängig davon, ob Sie die Implementierungsstrategie in den Architekturvertrag aufnehmen, ist die Implementierungsstrategie bei der Erstellung eines Implementierungsplans von entscheidender Bedeutung. Die drei Arten von Änderungen (Evolutionär, Revolutionär und Greenfield) werden das Projektdesign und das Systemdesign vorantreiben.
Wenn Sie beispielsweise bei Null anfangen müssen (Greenfield), erwarten Sie Änderungen in Organisation, Prozessen und Systemen. Sie werfen absichtlich die bestehende Organisation, Prozesse und Systeme weg. Ihr Projekt sollte besser darauf ausgelegt sein, etwas Neues zu schaffen und das Änderungsmanagement durch die Änderung zu führen.
Offen gesagt, veraltete Systeme, schlechte Prozesse und starre Organisationen werden aufrechterhalten, indem eine Änderung auf den einfachen Pfad des Projekts (evolutionär) getippt wird.
Verwenden Architektur-Roadmap-Techniken
Die verschiedenen Techniken zur Entwicklung einer Architektur-Roadmap werden verwendet, um unterschiedliche Anleitungen und Einschränkungen bei der Erstellung des Implementierungsplans bereitzustellen.
Heatmaps bieten Orientierung und Einschränkungen durch Attribute wie Wert, Arbeit, Risiko oder Übergangszustand. Sie treiben das Projektdesign voran.
Lebenszyklusdiagramme bieten Orientierung und Zeitbeschränkungen. Unabhängig davon, ob es sich bei dem Lebenszyklusdiagramm um ein System oder eine Änderung handelt, zeigt es die Grenzen für das Starten und Stoppen auf. Sie sind mächtig, wenn ein Änderungsereignis zu einem bestimmten Zeitpunkt benötigt wird. Es ist erstaunlich, wie oft ein später Wechsel wertlos ist. Wenn Sie das neue System nicht rechtzeitig haben können, verliert ein neues System zu spät seinen Wert.
Abhängigkeitsmodelle bieten Anleitungen und Einschränkungen in Bezug auf Abhängigkeiten. Ob es sich bei der Abhängigkeit um Arbeit, Organisation, Systeme oder Übergangszustände handelt. Ein Abhängigkeitsdiagramm hilft Ihnen oft dabei, Erforderlichkeitsdaten in einem Lebenszyklusdiagramm zu verstehen.
Szenario-Roadmaps sind bei der Entwicklung eines Implementierungsplans selten hilfreich.
Komplexe Visualisierung von Arbeitspaketen, Architekturoptionen oder Übergangszustandsoptionen. Rad-Plots repräsentieren in der Regel Bedenken oder Attribute wie Wert, Arbeit oder Risiko. Punkte auf dem Diagramm stellen normalerweise Architekturoptionen oder Übergangszustandsoptionen dar.
Erfahren Sie mehr über Conexiam Architektur-Roadmap-Workshops
Übergangsarchitektur
Die Übergangsarchitektur bietet Anleitungen und Einschränkungen zu Haltepunkten. Um Werte-Ruhepunkte zu liefern, strukturieren Sie Projekte, um gemeinsam den Übergangszustand zu erreichen. Die wichtigsten Daten in jedem Übergangszustand sind die „Erforderlich bis“- oder „Umfall“-Daten.
Lücke & Lösung
Lücken erklären, welche Mängel behoben werden müssen. Sie helfen einem Projekt, Umfang und Ergebnis zu definieren.
Lösungen vereinfachen das Design. Wenn es eine erwartete Lösung oder Lösungsattribute gibt, vereinfacht dies Umfang und Design. Dies gilt insbesondere dann, wenn Sie sich für eine Greenfield- oder revolutionäre Implementierungsstrategie entschieden haben.
Techniken des Implementierungsplans, die auf den Zweck der Unternehmensarchitektur ausgerichtet sind
Architekturteams unterstützen unterschiedliche Zwecke. Ob Sie Portfolio-Fragen oder Lösungsbereitstellung unterstützen, wird die Art und Weise verändern, wie Sie Architektur-Roadmaps entwickeln und verwenden. Architektur zur Unterstützung der Lösungsbereitstellung verwendet beispielsweise keine Architektur-Roadmap Typ 1: Heatmap, um Entscheidungen zu entwickeln. Wir werden es als überlegene Architektur und als eine Reihe von Einschränkungen für die Architekturentwicklung und jede Implementierung verwenden. Gute Architekten arbeiten immer innerhalb der Grenzen überlegener 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 | Schlüssel lieferbar | Schlüssel lieferbar | Überlegene Architektur | Überlegene Architektur |
Programmplanung | Schlüssel lieferbar | Schlüssel lieferbar | Überlegene Architektur | Überlegene Architektur |
Nutzenrealisierung | Schlüssel lieferbar | Schlüssel lieferbar | Wichtiges Ergebnis und überlegene Architektur | Überlegene Architektur |
Risikominderung | Schlüssel lieferbar | Schlüssel lieferbar | Wichtiges Ergebnis und überlegene Architektur | Überlegene Architektur |
Architekturvertrag | Wichtiger Liefergegenstand | Schlüssel lieferbar | Schlüssel lieferbar & überlegene Architektur | Schlüssel lieferbar & überlegene Architektur |
Umsetzungsstrategie | Ü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 & Lösung | Überlegene Architektur | Überlegene Architektur | Überlegene Architektur |
Implementierungsplantechniken für Anwendungsfälle der Unternehmensarchitektur
Implementierungsplan-Techniken bieten eine bessere Unterstützung für verschiedene Anwendungsfälle der Unternehmensarchitektur. Je nach Anwendungsfall sind Unternehmensarchitekten effizienter darin, ihren Stakeholdern mit unterschiedlichen Techniken zu helfen.
Während es in jedem Anwendungsfall der Unternehmensarchitektur um Änderungen geht, sind die Art der Änderung und die Treiber unterschiedlich.
Strategischer Wandel | Inkrementelle Änderung | Kosten verbessern | Qualität verbessern | Verbessern Sie die Unternehmensagilität | Minderung 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 hilfreich | Nützlich | Nützlich | Kritisch | Sehr hilfreich | Kritisch | Kritisch | Kritisch | Kritisch |
Nutzenrealisierung | Kritisch | Sehr hilfreich | Kritisch | Kritisch | Kritisch | Sehr hilfreich | Sehr hilfreich | Kritisch | Nützlich | Kritisch |
Risikominderung | Kritisch | Sehr hilfreich | Kritisch | Kritisch | Kritisch | Sehr hilfreich | Sehr hilfreich | Kritisch | Nützlich | Kritisch |
Architekturvertrag | Kritisch | Nützlich | Nützlich | Nützlich | Kritisch | Kritisch | Nützlich | Kritisch | Kritisch | Kritisch |
Umsetzungsstrategie | 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 & Lösung | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich | Nützlich |
Anwendung der Prinzipien der Unternehmensarchitektur auf die Entwicklung des Implementierungsplans
Ihre Architekturprinzipien werden Ihren Implementierungsplan vorantreiben und einschränken. Unsere Beratungspraktiken identifiziert 7 Architekturprinzipien, die jeder Unternehmensarchitekt kennen sollte. Die folgende Tabelle enthält ein einfaches Beispiel dafür, wie ein Implementierungsplan durch eine überlegene Architektur eingeschränkt wird.
Jeder Implementierungsplan, der nicht dem Buchstaben und dem Geist einer überlegenen Architektur entspricht, muss aufgefangen werden Unternehmensarchitektur-Governance und überarbeitet.
Implikation des Implementierungsplans | |
Leg dich nicht mit dem Erfolg an | Jede Änderung muss nach der Möglichkeit bewertet werden, dass sie den aktuellen Erfolg beeinträchtigt. Mögliche Verbesserungen müssen begrenzt werden, um sicherzustellen, dass die Basislinie beibehalten wird. |
Fokus auf Exzellenz | Veränderung muss fokussiert werden. Alle Veränderungen ohne direkten Bezug zum Unternehmenswert müssen hinterfragt werden. Verwenden Sie Wertdefinitionen, die Exzellenz unterstützen, um den potenziellen Wert einer Änderung einzuschätzen.
Scheuen Sie sich nicht, Änderungen zu identifizieren, die die Unternehmensexzellenz nicht verbessern, da „wertfrei.' |
Warum nicht eins? | Änderungen, die zu Duplizierungen führen, müssen in Frage gestellt werden, wobei die Wertschöpfung verringert wird.
Bei Änderungen, die Duplikate entfernen, muss die Wertschöpfung erhöht werden. |
Daten sind ein Vermögenswert | Stellen Sie sicher, dass die Kontrolle über das Datenmodell nicht auf eine Weise abgegeben wird, die den Wert der Datenbestände mindert. |
Systeme funktionieren, wo wir arbeiten | Arbeitsort und Arbeitsstil sind grundlegende Wertmaßstäbe. Jede Änderung, die Ort und Stil nicht erfüllen kann, muss die Wertlieferung verringern. |
Schmerzlose Benutzererfahrung | Änderungskosten müssen überprüft werden, um sicherzustellen, dass die Auswirkungen auf die Benutzer richtig bewertet werden. Betrachten Sie sorgfältig die Auswirkungen der Änderung im Vergleich zum potenziellen Nutzen. Sie zahlen immer für die Auswirkungen, während Sie möglicherweise nicht den erwarteten Nutzen erhalten. |
Selbstbedienung | Self-Service ist ein Maß für den Unternehmenswert. Sehen Sie sich die Self-Service-Bereitstellung anhand der Ausgangs-, Übergangs- und Zielzustände an. Passen Sie die Kosten- und Nutzenbewertungen an, um die Bereitstellung von Self-Services zu belohnen und bestehende Self-Services zu benachteiligen und zu schädigen. Sie zahlen immer für Schäden. Möglicherweise erhalten Sie eine Leistung. |
Wie passt TOGAF Phase F zur agilen Entwicklung?
Jeder Implementierungsplan bietet mehrere Einschränkungen und Anleitungen für die agile Entwicklung. Wir sehen Unternehmensarchitektur und agile Entwicklung sich in vier Bereichen kreuzen. Es gibt vier Bereiche, in denen es eine Kreuzung gibt:
- Definieren Sie den agilen Ansatz
- Führen Sie den Rückstand im Sprint
- Auswahlmöglichkeiten innerhalb der Sprints einschränken
- Lösung für Kreuzproduktabhängigkeit
Der Implementierungsplan wird die Definition des agilen Ansatzes maßgeblich beeinflussen. Beispielsweise erzwingt oder verbietet das Implementierungsstrategiemodell die Verwendung einer agilen Entwicklung.
Übergangszustände und erwartete Vorteile werden die Produktentwicklung oder Produktfreigabe informieren, die den Rückstand leiten.
Wie ermöglicht TOGAF Phase F Enterprise Agilität?
Unternehmensagilität ist die Fähigkeit Ihres Unternehmens, auf das Unerwartete zu reagieren. Die Umsetzungspläne entsprechen den Erwartungen. Starke Planungsfähigkeiten helfen Ihnen, auf das Unerwartete zu reagieren. Es gibt eine direkte Korrelation im Enterprise-Agilitätsmodell mit der Fähigkeit, Informationen zu sammeln und eine Lösungsentscheidung zu treffen. Das sind planerische Fähigkeiten.
Enterprise-Agilitätsmodell
- Wachsamkeit – Können Sie Chancen und Risiken erkennen?
- Zugänglichkeit – Können Sie rechtzeitig auf relevante Informationen zugreifen, um zu antworten?
- Entscheidungskraft – Können Sie sich anhand der verfügbaren Informationen entscheiden?
- Schnelligkeit – Können Sie Ihre Entscheidungen in der zur Verfügung stehenden Zeit umsetzen?
- Flexibilität – Was tun Sie, um Handlungshindernisse abzubauen?