Architektur des Unternehmens

Komponente 4: Methodik der Unternehmensarchitektur

Eine Unternehmensarchitektur-Methodik muss sich mindestens mit der Entwicklung und Aufrechterhaltung einer Unternehmensarchitektur befassen. Eine vollständige Methode umfasst Planung der Umsetzung der Änderungen und Steuerung aller Implementierungsprojekte. Eine umfassende Methodik umfasst Anleitungen zum Arbeitsmanagement.

Komponente 4: Unternehmensarchitektur-Methodik umfasst:

• Architekturentwicklungsmethodik
• Integration planen
• Governance-Rahmen
• Arbeitsmanagement

Architekturentwicklungsmethodik

Der TOGAF-Architekturentwicklungsmethode bietet die branchenübliche Methode zur Entwicklung und Aufrechterhaltung einer Unternehmensarchitektur. Der TOGAF-ADM für den Kern der TOGAF-Standard.

Im Kern verwendet das TOGAF ADM ein Informationsflussmodell. Jede Phase im ADM dient dazu, die Erstellung von Informationen aufrechtzuerhalten. Die klassische TOGAF ADM-Grafik ist eine vereinfachte Darstellung wesentlicher Informationsflüsse.

Als Informationsfluss ist das ADM von Natur aus inkrementell und iterativ. Sie müssen den Informationsfluss in ein Prozessmodell umwandeln. Testen Sie Ihren Prozess, wenn Sie über ausreichende Kenntnisse verfügen. Wenn ja, nutzen Sie diese. Wenn nicht, produzieren Sie es. Das TOGAF ADM ist keine Aktivitätssequenz. Viel zu viele Menschen betrachten die TOGAF ADM-Grafik und missverstehen sie als lineares Wasserfall-Prozessmodell.

Jedes Mal, wenn das EA-Team irgendeine Aktivität unternimmt, um die Informationen zu entwickeln, die aus einer ADM-Phase stammen, führt es eine Phase aus. Ein Unternehmensarchitekt muss immer die obligatorischen Inputs verbrauchen und die obligatorischen Outputs produzieren. Dies gilt für alle ADM-Phasen.

Die Verwendung des TOGAF ADM als Informationsmodell hilft dem Unternehmensarchitekten, maximale Effizienz und Produktivität zu erreichen.

Jede Phase im TOGAF ADM ist darauf ausgelegt, die notwendigen Informationen zu erstellen

Phase A: Architekturvision definieren

Seien Sie nicht überrascht, wenn Sie mehr als einen haben Architekturalternative ausgedrückt als unterschiedliche Architekturvisionen. Sie haben selten genug Informationen, um in Phase A den besten Weg auszuwählen.

Ergebnisse der Phase A stellen die Grundlage dar Steuerung der Architekturentwicklung.

Phase B: Entwicklung der Geschäftsarchitektur

Das Ergebnis von Phase B ist die Geschäftsarchitektur des Kandidaten.

Tabelle ab TOGAF 10 Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen

Der Domäne der Geschäftsarchitektur beschreibt die angestrebte Unternehmensstruktur. Es enthält normalerweise Elemente wie Geschäftsfähigkeit, Organisationsdesign, Prozesse und Informationsflüsse. Dabei geht es häufig um Motivationen wie Strategie, Ziele und Vorgaben. Diese Komponenten werden als Dokumente vorliegen Geschäftsarchitekturmodelle.

Laden Sie eine kostenlose herunter Leitfaden zur Bewertung der Geschäftsarchitekturfähigkeiten.

Phase C: Entwicklung der Informationssystemarchitektur

Architektur von Informationssystemen umfasst sowohl die Anwendungsarchitekturdomäne und das Domäne der Datenarchitektur.

Das Ergebnis der Phase C ist die Kandidaten-Anwendungsarchitektur und die Kandidaten-Datenarchitektur. Zusammen bilden diese die Architektur des Kandidaten-Informationssystems.

Tabelle ab TOGAF 10 Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen

Die Anwendungsarchitektur hilft bei der Beantwortung der folgenden Fragen:

• Wie das Anwendungsportfolio die Wertschöpfung ermöglicht – Anwendungsentwicklungsmodell
• Wo Kosten in das IT-Portfolio einfließen - Funktionsmodell
• Wo Steifheit in das IT-Portfolio eingeführt wird - Integrationsmodell
• So läuft das Unternehmen – Systemmodell
• Systeme, die zur Bereitstellung des Produkts oder der Dienstleistung erforderlich sind – Produktmodell
• Die Dinge, die eine Organisation können muss - Funktionsmodell
• Der Informationsfluss, der erforderlich ist, um die Aktivitäten eines Unternehmens durchzuführen - Integrationsmodell
• Die vollständigen Aktivitäten, die ein Unternehmen durchführt, normalerweise gruppiert, um ihre Beziehung zueinander darzustellen – Servicemodell
• Was das Software-Portfolio ist – Physikalisches Softwaremodell

Phase D: Beschreibung und Entwicklung der Technologiearchitektur

Das Ergebnis von Phase D ist die Entwicklung einer möglichen Technologiearchitektur.

Tabelle ab TOGAF 10 Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen

Am häufigsten sehen wir schwache Technologiearchitekturen, die größtenteils aus physischen Modellen bestehen. Bei den meisten unserer Arbeiten orientieren wir uns an Phase D Cloud-Architektur. Für die anderen Domänen sind Kernarbeitsprodukte wie a Systemmodell und Servicemodell, sind gleich.

Die Technologiearchitektur hilft bei der Beantwortung der folgenden Fragen:

• Wie das Infrastrukturportfolio die Wertschöpfung ermöglicht – Infrastrukturdienstmodell
• Wie die Infrastruktur geliefert wird – Infrastrukturanbietermodell
• Wo Kosten in das IT-Portfolio einfließen - Schnittstellenmodell
• Wo Steifheit in das IT-Portfolio eingeführt wird - Lebenszyklusmodell
• Was eine Infrastruktur können muss – Infrastruktursystemmodell
• Einschränkungen beim Erwerb und der Nutzung von Technologie – Normenkatalog
• Wie man die Infrastruktur nutzt, um die Aktivitäten eines Unternehmens durchzuführen – Schnittstellenmodell
• Die vollständigen Aktivitäten, die eine Infrastruktur ausführt, gruppiert, um zu zeigen, wie sie zueinander in Beziehung stehen – Servicemodell
• Was das Infrastrukturportfolio ist – Physisches Infrastrukturmodell

Phase E: Chancen und Lösungen identifizieren

Das Ziel von Phase E ist es, die zu überwinden vereinfachte Architekturvision. Es wurde nur erwartet, dass es vielversprechend ist. Durch die Entwicklung einer Architektur-Roadmap mit Ihren Stakeholdern identifizieren Sie potenzielle Änderungen, die aufgegeben werden sollten. Tatsächlich sollten die meisten Änderungen aufgegeben werden. Sie werden einen oder mehrere Werttests nicht bestehen:

• Zu viel Arbeit für die Rücksendung
• Für die Rückkehr ist der Erfolg zu ungewiss
• Die Rückgabe ist nur nice to have

Das Ergebnis der Phase E ist ein Iarchitecture-Roadmap und Unterstützung der Unternehmensarchitektur von Kandidaten.

Tabelle ab TOGAF-Framework Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen

Eine Architektur-Roadmap hilft bei der Beantwortung der folgenden Fragen:

• Wann wird der Wert geliefert – Übergangsstaaten
• Welche Änderung ist angesichts unterschiedlicher Kriterien zu verfolgen – Architektur-Roadmap Typ 4: Szenarien
• Welche Arbeit wird einen Wert liefern, und die Kosten und Ungewissheit – Architektur-Roadmap Typ 1: Heatmap
• Wenn Arbeit, Veränderung und Wertschöpfung stattfinden – Architektur-Roadmap Typ 2: Lebenszyklus
• Was ist die Abhängigkeit und Auswirkung von Arbeit und Veränderung – Architektur-Roadmap Typ 3: Auswirkung und Abhängigkeit
• Welche Entscheidungen werden aufgeschoben – Architektur-Roadmap Typ 4: Szenarien
• Welchen Wandel verfolgen wir – Umsetzungsstrategie

Integration planen

Der TOGAF ADM Phase F: Erstellung eines Migrationsplans befasst sich mit der Planungsintegration. Es unterstreicht, dass der Architekturansatz in den Planungsansatz Ihrer Organisation integriert werden muss. Meistens passen Sie in die Standard-Portfolio- und Projektplanung. Wenn Sie jedoch eine Transformation planen, müssen Sie davon ausgehen, dass die Standardplanungsansätze nicht verwendet werden.

Das Ergebnis der Phase F ist ein Umsetzungsplan und ein unterstützender Architekturvertrag.

Tabelle ab TOGAF 10 Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen

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

Governance-Rahmen

Die gesamte Regierungsführung folgt einem Modell der Leitung und Kontrolle. Richtung und Kontrolle bei der Auswahl. Leitung und Kontrolle bei der Umsetzung.

Erweitern Sie einfach das Governance-Framework um Steuerung der sich entwickelnden Architektur und die Umsetzung regeln.

Ihre Architekturentwicklung wird Entscheidungen oder Auswahlen treffen. Ihre Implementierungsprojekte werden eine Auswahl treffen. Sind diese Entscheidungen richtungskonform? Was ist Ihre Kontrolle?

>>> Laden Sie den Enterprise Architecture Governor's Guide herunter

Governance der Architekturentwicklung

Alle Entscheidungsrechte liegen bei Ihren Stakeholdern. Benutze Dein Governance-Board für Unternehmensarchitektur sollte den Prozess verwalten. Es sollte das verwenden Governance-Checklisten für die Architekturentwicklung. Die Checklisten dienen als Kontrolle, um zu zeigen, dass der Architekt den Anweisungen gefolgt ist.

Governance der Architekturimplementierung

Das TOGAF ADM hat eine spezielle Phase, in der es um die Implementierungs-Governance geht: Phase G: Governance-Implementierung. Das Ergebnis der Phase G ist eine erfolgreiche Veränderung.

Tabelle ab TOGAF 10 Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen

Die Rolle des Unternehmensarchitekten besteht darin, den Wert durchgängig zu schützen Implementierungs-Governance. Sie testen die Entscheidungen des Designers und Implementierers, indem Sie sie mit dokumentierten Lücken, Architekturanforderungsspezifikationen und Kontrollen vergleichen. Erfinden Sie während eines Projekts keine neue Architektur.

Die drei wichtigsten Punkte für den Abschluss von Phase G:

• Erstens ein erfolgreiches Implementierungsprojekt, das innerhalb der Einschränkungen der Architektur den erwarteten Wert liefert.
• Zweitens ein abgebrochenes Projekt. Wenn ein Projekt den erwarteten Wert nicht erbringen kann, sollten die knappen Änderungsressourcen eines Unternehmens so schnell wie möglich neu zugewiesen werden.
• Drittens eine Änderung der Zielarchitektur. Erweitern Sie den erwarteten Wert oder ziehen Sie ihn auf das, was wir realisieren können. Einschränkungen lockern oder verschärfen.

Wenn es ein Problem gibt, gibt der Unternehmensarchitekt eine Empfehlung, was der Stakeholder tun sollte. Die Stakeholder haben nur drei Möglichkeiten:

1. 1. Einhaltung der Zielarchitektur durchsetzen
   2. Sorgen Sie für Erleichterung und ermöglichen Sie dem Projekt, die Zielarchitektur zu ignorieren (was normalerweise eine schwache Methode zur Änderung des Ziels ist).
   3. die Zielarchitektur ändern

Erweiterte Governance-Kontrollen über die Wertrealisierung

Das TOGAF ADM bietet erweiterte Kontrollen in Phase H: Architekturänderungsmanagement. Bei dieser erweiterten Wertrealisierungsaktivität handelt es sich um eine Architekturkontrolle.

Sehen TOGAF Phase H – Anwendung von Agile und unser aufgezeichnetes Webinar True Life EA-Webinar: Agile Reaktion auf COVID-19 für die reale Umsetzung von Unternehmensagilität

Arbeitsmanagement

Wenn wir EA-Teams entwickeln Wir legen großen Wert auf Produktivität. Wir konzentrieren uns auf die Anleitung in TOGAF zu grundlegendem Wissen. Um die Produktivität zu verbessern, verwenden wir einen Kanban-Wissensfertigungsansatz.

Wir folgen den Best Practices von Kanban und teilen die Arbeit auf. Für jedes Arbeitsprodukt gibt es eine verantwortliche Ressource und ein Fälligkeitsdatum.

Wir beginnen mit Phase A:

1. Was ist die Frage?
   Frage- oder Problemraum. Was sind die größeren Fragen oder früheren Entscheidungen, die uns einschränken?
2. Wer sind die Beteiligten?
   Wie werden sie die möglichen Veränderungen bewerten? Was sind ihre Sorgen?
3. Welche Informationen benötigen wir?
   Was ist im Repository? Was fehlt? Wie werden wir es sammeln?
4. Welche Analyse brauchen wir?
5. Welche Arbeitsergebnisse werden unseren Stakeholdern helfen, ihre Entscheidungen zu verstehen?
   Architekturansichten

Dann führen wir aus. Bei Kanban haben wir einen Rückstand. Die laufende Arbeit beschränkt sich auf das, was abgeschlossen werden kann.