TOGAF ADM Phase D – Entwicklung der Technologiearchitektur
Auf einen Blick
- TOGAF ADM-Übersicht
- Was ist TOGAF Phase D?
- Was ist eine Technologiearchitektur?
- Technologiearchitektur vs. Cloud-Architektur
- Nennen wir es Technologiearchitektur, Infrastrukturarchitektur oder IT-Architektur?
- TOGAF ADM Phase D Ergebnisse
- Was ist der Unterschied zwischen einem Unternehmensarchitekten und einem Technologiearchitekten?
- Welche Rolle spielt der Unternehmensarchitekt in Phase D?
- Was ist die Rolle des Technologiearchitekten?
- Modelle, Werkzeuge und Techniken der Technologiearchitektur
- Technologiearchitekturmodelle
- Werkzeuge und Techniken der Technologiearchitektur
- Wie passt Phase D von TOGAF zu Agile?
- Abschließende Gedanken zu TOGAF ADM Phase D – Technologiearchitektur
TOGAF ADM-Übersicht
Verwenden Sie die TOGAF-ADM um das Wissen zu entwickeln, das für die beste Technologiearchitektur erforderlich ist. Jede ADM-Phase bietet die Inputs und Aktivitäten, die erforderlich sind, um Wissen zu einem bestimmten Thema zu entwickeln. Das TOGAF ADM steht im Mittelpunkt des TOGAF-Standards. Es ist die einzige skalierbare universelle Methode, die entwickelt werden kann Unternehmensstruktur. Es ist für jeden Detaillierungsgrad geeignet. Wie alle logischen Modelle muss es erweitert werden, um verschiedene Detailebenen abzudecken – Strategie, Portfolio, Projekt und Lösungsbereitstellung.
Wenn Sie eine brauchen Überblick über das TOGAF ADM, lesen Sie bitte die TOGAF ADM-Phasen erklärt.
Was ist TOGAF Phase D?
In der TOGAF-Phase D, Technologiearchitekten die Entwicklung der Technologiearchitektur leiten. Sie tun dies, indem sie versuchen, die Informationssystemarchitektur zu ermöglichen – nicht indem sie Befehle entgegennehmen und Hoffnungen erfüllen. Technologiearchitekten verstehen, dass eine langlebige Infrastruktur ihre Umgebung liefert. Sie müssen nach vorne schauen und bereit sein. Sie müssen sicherstellen, dass kurzfristige Hoffnungen nicht zu langfristigen Schmerzen führen.
Wenn wir sind Entwicklung von Unternehmensarchitekturteams, verraten wir den Architekten zwei zentrale Fakten zu TOGAF Phase D – Technology Architecture. Erstens, bis Sie eine haben Anwendungsentwicklungsmodell, Sie können nicht fortfahren. Es ist sinnlos, Details Ihrer Infrastruktur zu entwickeln, bevor Sie verstehen, was Ihre Anwendungsarchitektur benötigt. Zweitens, wenn sie eine IT- oder Infrastruktur-Agenda eintauchen, werden sie immer eine minderwertige Technologiearchitektur entwickeln. Die Infrastrukturdesigner und -betreiber sollten sich durch die Technologiearchitektur eingeschränkt fühlen.
In einem modernen digital transformierten Unternehmen interagieren alle Architekturdomänen. Entscheidungen in einer Domäne aktivieren, liefern oder blockieren Ergebnisse in einer anderen Domäne. Die meisten Geschäftsziele hängen davon ab richtige IT-Architektur. Nur mit einer soliden Anwendungsarchitektur können wir die richtige Technologiearchitektur entwickeln.
Die wahre Schwierigkeit der Technologiearchitektur liegt in der Langlebigkeit der Infrastruktur. Ohne eine Technologiearchitektur, die Einschränkungen bietet, führen taktische Infrastrukturentscheidungen immer zu schlechteren Unternehmensergebnissen.
Es gibt eine direkte Ausrichtung zwischen guter Technologiearchitektur und moderner PaaS- oder den meisten Cloud-Architekturen. Beide bezeichnen Infrastrukturdienste. Beide bieten Beschränkungen und ermöglichen Daten- und Anwendungsauswahlmöglichkeiten. Beide isolieren Anwendungen von der zugrunde liegenden Infrastruktur.
Was ist das Ziel von TOGAF ADM Phase D?
Das TOGAF ADM beginnt mit Phase A. Es liefert a vereinfachte Zielarchitektur - die Architekturvision. Die Architekturvision sollte besser Geschäfts-, Anwendungs-, Daten-, und Technologiedomänen. Zu oft sehen wir Menschen, die vorgeben, eine Architekturvision zu entwickeln. Sie tauchen mit einer Geschäftsbetriebsphantasie auf und behandeln Phase D als eine Übung, um Fantasie zu vermitteln. Real Enterprise Architecture hat eine vereinfachte Zielarchitektur entwickelt. Die Aktivität in Phase D entwickelt die Technologiearchitekturdomänen weiter. Erfolg erfordert:
- Sie sprechen das Problem an, dass die aktuelle Infrastruktur nicht den Präferenzen der Stakeholder entspricht
- Sie erfahren, was sich ändern muss, damit die Infrastruktur den Präferenzen der Stakeholder entspricht? (Lücken)
- Sie haben ein ausreichendes Verständnis der Arbeit, die erforderlich ist, um Änderungen zu liefern (Arbeitspaket)
- Sie verstehen die Wechselwirkung zwischen Änderungen und Einschränkungen in anderen Architekturdomänen, um den erwarteten Wert zu schützen (Architecture Requirements Specifications)
Das zentrale Ergebnis von Phase D ist die Kandidatentechnologiearchitektur. Technologiearchitekten arbeiten mit den anderen Domänenarchitekten zusammen. Erwarten Sie, Hoffnungen und Zwänge hin und her zu übergeben. Jede Architekturentwicklung erfordert, die beste Antwort für das Unternehmen zu finden. Die beste Antwort versteht Einschränkungen und funktioniert in allen Bereichen.
Der Zweck des TOGAF ADM besteht darin, mögliche Änderungen zu untersuchen. Änderungen werden in Bezug auf Arbeit, Wert und ausgeglichen Risiko. Änderungen, die ausgewählt oder gelöscht werden. Der Satz von Änderungen erstellt die Zielarchitektur und die Architektur-Roadmap.
Technologiearchitekten arbeiten mit Infrastruktur. Die Infrastruktur ist der am schwierigsten zu ändernde Teil einer Organisation. Technologiearchitekten müssen jede potenzielle Änderung hinterfragen und die Augen offen halten für eine Ausfahrt. Die kostengünstigste Ausfahrt ist während der Architekturentwicklung. Stoppen Sie bald schlechte Ideen. Das Eliminieren schlechter Ideen spart Geld und ermöglicht erfolgreiche Veränderungen. Die Notwendigkeit, die Infrastruktur weiter vorauszudenken, erfordert von den Technologiearchitekten, Infrastrukturdesigner und -implementierer einzuschränken.
Interagieren mit TOGAF-Phase B, Phase C, und Phase E
'Das Geschäft“ ist das Unternehmen. Das war es schon immer. Moderne digitale Unternehmen können nicht auf hart arbeitende Menschen zurückgreifen, um Einschränkungen bei Anwendungen und Infrastruktur zu überwinden. Einschränkungen bei Anwendungen und Infrastruktur beeinträchtigen die Agilität des Unternehmens und beenden die digitale Transformation.
Sie entwarfen das TOGAF ADM rund um die Herausforderung, die Aufarbeitung zu unterbrechen, und die Anforderung, zusammenzuarbeiten. Leider zeigt das klassische TOGAF-ADM-Diagramm den Fluss der notwendigen Informationen. Bitte interpretieren Sie das Diagramm nicht als Wasserfall.
Wer behauptet, dass Unternehmensarchitekturen sequentiell entwickelt werden können, liegt falsch. Jeder, der Ihnen sagt, dass Sie losrennen und das gesamte Unternehmen entwerfen sollen, liegt ebenfalls falsch. Die Komplexität und Kompetenzspezialisierung erfordert Domänen. Ihre Entwicklung beginnt und verläuft gemeinsam. Sie müssen einen agilen Ansatz verfolgen, der gerade ausreicht, um die kaskadierenden Einschränkungen zu testen. TOGAF nennt diese Iteration.
Architektonische Entscheidungen wird mehrere kreuzen Architekturdomänen erfordert die Verwendung architektonische Alternativen.
Was ist Technologiearchitektur?
Technologiearchitektur ist eine der vier grundlegenden Domänen der Unternehmensarchitektur. Eine Technologiearchitektur ist eine Beschreibung Ihres gesamten Infrastrukturportfolios, die Ihnen sagt, wann Sie Infrastruktur kaufen, wann Sie PaaS verwenden und wann Sie Infrastruktur erfinden sollten. Es sagt Ihnen, wo Sie Grenzen zwischen Systemen ziehen müssen. Es sagt Ihnen, wie Sie Ihren Infrastrukturlebenszyklus angehen werden.
Wir können garantieren, dass Ihre aktuelle Technologiearchitektur nicht darauf abgestimmt ist. Wir sind zuversichtlich, dass Sie von einer Position aus starten werden, an der die Infrastrukturplanung keinen festen Platz hatte Anwendungsarchitektur oder Geschäftsarchitektur.
Wenn Sie über eine Technologiearchitektur verfügen, verfügen Sie über den Satz an Infrastrukturdiensten, der von Ihren Anwendungen benötigt wird. Sie haben eine Reihe von Richtlinien und Einschränkungen für die Konzeption und den Betrieb Ihrer Infrastruktur. Sie haben eine Technologie-Roadmap, die Ihr Stakeholder versteht.
Um die Technologiearchitektur, ihre Dienste, Richtlinien und Einschränkungen zu entwickeln, muss der Technologiearchitekt mit seinen Kollegen und den Interessenvertretern zusammenarbeiten. Sie müssen untersuchen, wie unterschiedliche Infrastrukturentscheidungen Geschäfts- und Softwareentscheidungen ermöglichen oder blockieren. Sie müssen herausfinden, wie die Auswahlmöglichkeiten die Ziele der Organisation ermöglichen und einschränken. Lassen Sie potenzielle Änderungen fallen, die zu wenig liefern, zu viel Arbeit erfordern oder zu viele Unsicherheiten aufweisen. Gute Architektur-Roadmaps enthalten notwendige Änderungen und sind risikoreduziert.
Wofür wird eine Technologiearchitektur verwendet?
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
Technologiearchitektur vs. Cloud-Architektur
Wir sehen fast keinen Unterschied zwischen guter PaaS oder guter Private Cloud-Architektur, und gute Technologiearchitektur. Die Kernarbeitsprodukte, a Systemmodell und Servicemodell, sind gleich. Der Unterschied besteht darin, dass Sie sich bei der Verwendung von PaaS oder Public Cloud keine Gedanken über die zugrunde liegende Infrastruktur machen müssen.
Ironischerweise haben Sie, wenn Sie seit TOGAF 8 eine gute Technologiearchitektur betreiben, eine klare Reihe von Infrastrukturdiensten bereitgestellt. Sie haben die Schnittstellen und Standards zu diesen Diensten spezifiziert. Wir vermuten, dass Ihre Arbeit leicht in einen Public Cloud PaaS-Dienstkatalog übertragen werden kann.
TOGAF 8 forderte Technologiedienste, um detaillierte Infrastrukturen zu abstrahieren, um Portabilität zu ermöglichen, die „Ilities“ zu verwalten und Infrastrukturlebenszyklen zu ermöglichen. Aus dem gleichen Grund lassen alle Public Cloud PaaS-Anbieter ihre Kunden Dienste nutzen. Wenn wir alle nur eine gute Technologiearchitektur entwickelt hätten, hätten wir die Sackgasse von unbeweglichen Anwendungen, nicht gelieferten „Itilities“ und technischen Schulden vermieden.
>>> Springe zu Die Grundlagen der Private-Cloud-Architektur
Nennen wir es Technologiearchitektur, Infrastrukturarchitektur oder IT-Architektur?
Der TOGAF-Standard nennt es Technologiearchitektur. Unser Beratungspraxis für Unternehmensarchitektur verwendet normalerweise die Infrastruktur. Viele andere fordern eine IT-Architektur. Bemühungen, eine klare universelle Definition zu entwickeln, scheitern routinemäßig. Unser dringender Rat ist, sich auf den Zweck und nicht auf die Definition zu konzentrieren.
Die Grenze zwischen den Architekturdomänen hilft uns, die richtigen Fähigkeiten und die richtigen Gespräche zusammenzubringen. Das Nachdenken über diesen Zweck behält den Fokus auf die Entwicklung einer nützlichen Architektur.
Wenn Sie über die Definition nachdenken, geraten Sie routinemäßig in eine sinnlose Diskussion. Ist die KI-Chat-Bot-Anwendung KI oder ein Unternehmen? Ist E-Mail eine Anwendung oder Infrastruktur? Was ist mit der Gesichtserkennung, die für die Zugangskontrolle verwendet wird? Die Permutationen sind endlos.
Alle Domänen der Unternehmensarchitektur gehen ineinander über. Zusammen decken Domänen die komplette Unternehmensarchitektur ab. Wir erstellen eine Domäne, damit ein Facharchitekt Techniken und Fähigkeiten anwenden kann. Es entstehen ständig neue Bereiche der Unternehmensarchitektur. Die meisten werden in a absorbiert klassische Unternehmensarchitekturdomäne wenn sie zum Mainstream werden.
Unser Rat ist, sich keine Gedanken darüber zu machen, was richtig ist. Stellen Sie stattdessen sicher, dass Sie verstehen, was jemand anderes meint, wenn er spricht. Wissen Sie immer, was Ihre Zuhörer vermuten, dass Sie meinen. Übernehmen Sie die Verantwortung für das Verständnis und passen Sie Ihre Bedingungen an.
Was ist der Unterschied zwischen einem Enterprise Architect und einem IT Architect?
Viele Leute gehen davon aus, dass sie einen Unternehmensarchitekten auf die IT-Infrastruktur konzentrieren sollten. Bei mehreren Beratungsaufträgen haben wir unsere Unternehmensarchitekten umbenannt, um dieses Problem zu vermeiden. Der Beruf des Enterprise Architecture ist klar. Die IT-Architektur ist eine Teilmenge der Unternehmensarchitektur. Technologie ist eine Teilmenge der IT-Architektur.
Wir fokussieren Enterprise Architects auf das Zusammenspiel aller Architekturdomänen. In vielen Teams gibt es Datenarchitekten, Anwendungsarchitekten, Sicherheitsarchitekten, Geschäftsarchitekten und Technologiearchitekten. Sie können nach ihrer Rolle oder mit dem allgemeinen Titel Unternehmensarchitekt bezeichnet werden.
TOGAF ADM Phase D Technology Architecture Deliverables
Ein zentrales Ergebnis von Phase D ist eine Technologiearchitektur. Dies ist ein Teil der gesamten Unternehmensarchitektur. Auf Umwegen gibt es also fünf nützliche Ergebnisse für TOGAF ADM Phase D:
- Modelle, die die Technologiearchitektur umfassen
- Lücken zwischen der aktuellen und der angestrebten Technologiearchitektur
- Kandidatenarbeitspakete, die die Lücken füllen
- Kandidatenarchitekturspezifikationen, mit denen Sie die zukünftige Architekturentwicklung und -implementierung steuern können
- Einfluss auf die Geschäftsarchitektur, Anwendungsarchitektur, Datenarchitektur und Sicherheitsarchitektur
Denken Sie immer daran, dass Sie versuchen, die Organisation zu verbessern. Verbesserung erfordert Veränderung. Die Veränderung liefert Wert. Wert und Kosten der Änderung können gemessen werden. Unsicherheit verringert immer den potenziellen Wert. Wenn der Erfolg ungewiss ist, steigen die Kosten geometrisch. Sehr wenig Unsicherheit wird erwartet beseitigt.
Wenn wir über die Technologiearchitektur sprechen, beziehen wir uns meistens auf die Modelle und Architekturspezifikationen. Verschiedene Modelle erläutern unterschiedliche Aspekte der gesamten Infrastruktur. Zusammen bilden die Modelle und die erforderlichen Änderungen die Technologiearchitektur.
Wenn Sie sich verschiedene Modelltypen ansehen, denken Sie daran, dass es viele Verwendungen derselben Begriffe gibt. Wir können nicht genug betonen, dass Sie sich in Bezug auf das Etikett des Modells entspannen sollten. Was Sie ein funktionales Dekompositionsmodell nennen, wird jemand anderes einen Dienst nennen. Unsere Unternehmensarchitekturberatung konzentriert sich auf den Zweck, nicht darauf, wie das Modell genannt wird. Sie können es eine funktionale Zerlegung oder ein Systemmodell oder ein Dienstmodell nennen. Uns interessiert nur der Zweck des Modells – was versuchen Sie zu lernen, und erklärt Ihr Modell effektiv, wie dieser Aspekt der realen Arbeit funktioniert?
Abschluss der Phase-D-Technologiearchitektur
Alle TOGAF ADM-Phasen verfügen über die Informationsinputs und Aktivitäten, um das benötigte Wissen zu entwickeln. Das Ergebnis von Phase D ist die Entwicklung einer Kandidatentechnologiearchitektur.
| Ausgabe & Ergebnis | Wesentliches Wissen |
| Die Technologiedomänenarchitektur, die von den Stakeholdern für das zu behandelnde Problem mit einer Reihe von Lücken genehmigt wurde, und daran arbeitet, die von den Stakeholdern verstandenen Lücken zu schließen. | Wie das aktuelle Technologieportfolio die Präferenzen der Stakeholder nicht erfüllt?
Was muss sich ändern, damit das Softwareportfolio den Präferenzen der Stakeholder entspricht? (Lücken) Welche Arbeiten sind notwendig, um die Veränderungen zu realisieren, die mit der Wertschöpfung vereinbar sind? (Arbeitspaket) Wie sich die Priorität und Präferenz von Stakeholdern als Reaktion auf Wert, Aufwand und Änderungsrisiko anpassen. (Stakeholder-Anforderungen) |
Tabelle aus TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture
Phase D Bare Bones
In Phase D bestimmt die Arbeit eines Technologiearchitekten, was an der Technologie geändert werden muss, damit die Informationssysteme das Unternehmen unterstützen können. Klingt einfach. Alles, was Sie tun müssen, ist zu verstehen, was das Unternehmen zu verbessern versucht, wo es zu kurz kommt und was geändert werden muss.
Die nackten Knochen von Phase D sind:
- Zu wissen, wie das Infrastrukturportfolio die Erfassung von Werten ermöglicht
Organisationen schaffen Wert, wenn sie etwas tun, wofür ein Kunde mehr bezahlt. Werte werden typischerweise generiert, wenn ein Material geändert, eine Dienstleistung erbracht oder Informationen verwendet werden. Eisenerz zu Stahl, gelieferte Wetterwarnung oder Teile, Aufträge und Fertigungskapazitäten, um einen Produktionsauftrag zu erstellen.
Die Technologie spielt in der Regel eine unterstützende Rolle. Es ermöglicht Menschen und Anwendungen, den Wert zu generieren. Als unterstützende Funktion optimieren wir auf Effizienz. Die kritische Frage wird durch die Kenntnis der erforderlichen Mindestleistungen beantwortet.
- Wissen, wie die Infrastruktur bereitgestellt wird
Früher mussten wir unsere Technologie besitzen und betreiben. Mit Public Cloud PaaS-Anbietern können wir global skalierbare Organisationen betreiben, die keine Technologie besitzen. Die meisten Organisationen verfügen über eine Mischung aus Infrastruktur, die sie besitzen und betreiben, Infrastruktur, die sie auswählen und von anderen betrieben werden, und einer Reihe von Infrastrukturdiensten.
- Die Quelle von Kosten, Komplexität und Starrheit kennen
Jedes Infrastrukturportfolio leidet unter Starrheit. Infrastruktur ist schwer zu ändern. Komplexität und Starrheit erzeugen Kosten und Komplexität. Ihre Infrastruktur sieht aus wie ein komplexes Uhrwerk. Eines, das aus fast zufälligen Teilen zusammengesetzt wurde. Die Änderung einer Sache führt normalerweise zu kaskadierenden Änderungen durch das gesamte Portfolio.
Die Technologiearchitektur muss die Starrheit reduzieren, um sie zu ermöglichen Unternehmensagilität. Sie müssen Ihr Kerninfrastrukturportfolio optimieren, um nachhaltige Kosten und Komplexität zu vermeiden. Das Rennen um Public Cloud PaaS ist einfach ein Versuch, etwas Agilität zu kaufen. ITFM verstehen und die Aufrechterhaltung eines Kostenmodells für digitale Produkte und IT-Services ist unerlässlich.
- Wissen, wie man Infrastruktur auswählt
Es gibt vier Infrastrukturmodelle: PaaS, Unternehmenssysteme, Spezialsysteme und kundenspezifische Entwicklung. Jedes hat ein anderes Kosten- und Optimierungsmodell. Sie müssen das richtige Modell für den Erwerb der Infrastruktur an den richtigen Stellen anwenden.
- Die Erwartungen an die Infrastruktur kennen
Manchmal benötigen wir einen generischen Infrastrukturdienst. Manchmal benötigen wir spezielle Hardware. Meistens brauchen wir etwas ohne zu viel Overhead. Wir nutzen die Konzepte und Attribute in Fähigkeitsmodelle um Entscheidungen über unsere Technologiearchitektur zu lenken. Unser Business Architecture Capability Assessment Guide verfügt über eine Reihe von Attributen, die leicht angepasst werden können.
- Wissen, wie man die Infrastruktur nutzt
Was ist die ausgewählte Schnittstelle? Entscheiden Sie sich für einen Industriestandard oder gehen Sie mit einer speziellen Schnittstelle weiter? Maskieren Sie die Schnittstelle mit Abstraktion?
Dazu kommt der Betrieb der Infrastruktur. Was sind die Betriebserwartungen? Was ist mit der Betriebszeit oder der Fähigkeit, Komponentenausfälle zu absorbieren? Was sind die Voraussetzungen, um die Infrastruktur verändern zu können?
- Was muss sich ändern, um das beste Infrastrukturportfolio bereitzustellen?
Wir entwickeln Technologiearchitekturen, um eine Organisation zu verbessern. Das Tempo und die Realität von Infrastrukturänderungen bedeuten, dass die meisten Änderungen außerhalb des Zyklus erfolgen. Aktuelle geschäftliche Änderungen müssen die vorhandene Infrastruktur nutzen. Als Technologiearchitekt arbeiten Sie oft am fünften Aspekt der Modell der Unternehmensagilität - Flexibilität. Ohne vorbeugende Arbeit zum Abbau von Handlungshemmnissen hat Ihr Unternehmen Einschränkungen für unerwartete Änderungen.
Die meisten Änderungen, die Menschen vornehmen möchten, sind nur Bastelei. Im Sinne von Six Sigma handelt es sich um lokale Optimierung. Einen kleinen Teil des Systems verbessern, selbst auf Kosten des gesamten Systems. Verwenden Sie als Technologiearchitekt die Anleitung in TOGAF ADM Phase D, um sich auf wesentliche Änderungen zu konzentrieren, die eine sinnvolle Unternehmensagilität, Kostenverbesserung oder Wertschöpfung fördern.
Die drei wichtigsten Punkte für den Abschluss von Phase D:
- Erstens: Was muss sich ändern? Änderung von Service, Performer, Schnittstelle, Betrieb, Outsourcing, Insourcing oder Automatisierung. Das sind alles Änderungen. Wir tun sie, um eine Organisation zu verbessern. Versuchen Sie, Ihr Infrastrukturportfolio zu verbessern.
- Zweitens, wann muss es sich ändern? Gibt es Abhängigkeiten? Wie sieht es mit den Voraussetzungen aus? Ändern Sie die Bühne für eine spätere Änderung?
- Drittens, woher wissen Sie, ob die Änderung erfolgreich war? Was ist Ihr Governance-Test für den Erfolg? Wie werden Sie den Wert schützen?
Eigene Zustimmung der Stakeholder zu allen Architekturänderungen. Der Technologiearchitekt ist dafür verantwortlich, die Änderung mit Begriffen zu beschreiben, die er versteht. In Begriffen, die ihre Bedenken ansprechen. Sowie die Bereitstellung der Governance-Tests, damit die Stakeholder das Änderungsprojekt steuern können.
TOGAF-Phase-D-Technologiearchitektur-Ergebnisse und Unternehmensarchitektur-Zwecke
Es gibt vier Hauptzwecke für die Entwicklung einer Unternehmensarchitektur. Verschiedene Ergebnisse der Phase D haben für jeden Zweck unterschiedliche Bedeutung.
| 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 D: Kandidatentechnologiearchitektur | Schlüssel lieferbar
Primärer Nutzen ist das Stakeholder-Verständnis von Ziel und Arbeit. Sekundäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Architekten |
Schlüssel lieferbar
Primärer Nutzen ist das Stakeholder-Verständnis von Ziel und Arbeit. Sekundäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Architekten |
Vor Projektinitiierung und Finalisierung des Business Case
Hauptanwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Implementierer |
Vor Beauftragung von Ausführungspartnern (einschließlich interner Anbieter)
Hauptanwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Implementierer |
| Phase-D-Arbeitsprodukt: Kandidaten-Roadmap-Elemente | Schlüssel lieferbar
Primärer Nutzen ist das Verständnis der Arbeit durch die Stakeholder. Sekundäre Verwendung ist die Erstellung von Einschränkungen für Architekten |
Schlüssel lieferbar
Primärer Nutzen ist das Stakeholder-Verständnis von Arbeit und Abhängigkeit. Sekundäre Verwendung ist die Erstellung von Einschränkungen für Architekten |
Eingeschränkte Nutzung Kann als Eingabe für Projekte mit mehreren interaktiven Änderungen verwendet werden |
Vor Beauftragung von Ausführungspartnern (einschließlich interner Anbieter).
Der Hauptzweck ist die Identifizierung erforderlicher Änderungen und Präferenzen für die Durchführung von Änderungen, um die Auswahl und das Engagement von Partnern für die Lösungsbereitstellung zu verwalten |
| Arbeitsprodukt der Phase D: Spezifikation der Architekturanforderungen | Eingeschränkte Nutzung
Normalerweise können Architekten Einschränkungen aus überlegener Architektur ableiten. |
Eingeschränkte Nutzung
Normalerweise können Architekten Einschränkungen aus überlegener Architektur ableiten. |
Schlüssel lieferbar
Vor Abschluss der Projektinitiierung |
Schlüssel lieferbar
Vor Verlobung und Vertragsabschluss |
Tabelle ab TOGAF-Framework Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen
Kandidatentechnologiearchitektur
Es gibt vier Hauptzwecke für die Entwicklung einer Unternehmensarchitektur. Unterschiedliche Modelle haben für jeden Zweck unterschiedliche Bedeutung.
>>> Zum Gemeinsamen springen Technologiearchitekturmodelle
Komponenten der Kandidaten-Technologiearchitektur-Roadmap
Was sind die Mindeständerungen? Wenn Sie einen Wechsel eines Infrastrukturanbieters erwägen, ist es unwahrscheinlich, dass es sich um eine wesentliche Änderung handelt. Wenn Sie von einem generischen Unternehmenssystem zu einer spezialisierten Infrastruktur wechseln, ist die Komponenten- und Spezifikationsänderung im Infrastrukturanbietermodell der Roadmap-Kandidat. Vergessen Sie nie alle kaskadierenden Änderungen. Der Wechsel zu einer spezialisierten Infrastruktur erfordert Änderungen in der gesamten Geschäfts- und Anwendungsarchitektur. Auch wenn es sich nur um Veränderungen im Team handelt, das die Spezialhardware bedient.
Wir verwenden oft ein Infrastruktursystemmodell Änderungen zusammenzufassen. Systemmodelle bieten genügend Abstraktion für Planungs- und Ausführungsgespräche. Wir empfehlen, Partituren und Arbeitspakete zu verwenden, um Änderungen zu erklären. Weitere Informationen zur Verwendung von Partituren finden Sie unter Leitfaden zur Bewertung der Geschäftsarchitekturfähigkeiten.
Wir verwenden alle Architektur-Roadmap-Komponenten in TOGAF Phase E - Architektur-Roadmap.
Anforderungsspezifikation für die Kandidatentechnologiearchitektur
Erläutern Sie die Einschränkungen für Infrastrukturdesigner, Käufer und Implementierer. Erklären Sie, wie Sie die Verbesserung beurteilen werden.
Wir verwenden oft Punktzahlen und vereinfachte Aussagen, um Anforderungen zu beschreiben. Die Anforderung kann ein Automatisierungsmaß oder eine Aussage sein, dass es sich bei dieser Infrastruktur um Public Cloud PaaS oder Spezialhardware handelt. Diese Anforderungen werden verwendet, um ein Änderungsprojekt in TOGAF Phase G zu steuern und zu steuern.
Welche Rolle spielt der Technologiearchitekt in Phase D?
Wir erwarten, dass der Technologiearchitekt TOGAF Phase D leitet und die Domänenarchitektur liefert. Sie müssen die Modelle entwickeln, die die Quelle des Mangels zeigen. Sie müssen ihre Modelle testen, um zu zeigen, wie eine Änderung den Mangel überwindet. Wir erwarten von ihnen, dass sie Stakeholder, Fachexperten und andere Domänenarchitekten durch Trade-off-Analysen führen.
Technologiearchitekten müssen eng mit Geschäftsarchitekten und Anwendungsarchitekten zusammenarbeiten. Die Technologiearchitektur verursacht häufig Mängel in ihrer Domäne. Außerdem erfordert das Entfernen von Komplexität und Starrheit in der Technologiearchitektur normalerweise Änderungen dort.
Wir erwarten, dass der Technologiearchitekt die Geschäftsarchitektur abschließt. Sie müssen das verstehen Betriebsmodell und die Kompetenz- und Automatisierungsattribute der Fähigkeitsmodell. Wir erwarten auch, dass sie das verstehen Anwendungsentwicklungsmodell, die Kompetenz- und Automatisierungsattribute von any Anwendungssystemmodell, und das Digitales Produktmodell.
>>> Zum Gemeinsamen springen Geschäftsarchitekturmodelle und gemein Anwendungsarchitekturmodelle
>>> Zum Gemeinsamen springen Technologiearchitekturmodelle
Unternehmensarchitekturteams können ohne Technologiearchitekten nicht erfolgreich sein. Moderne digitale Unternehmen sehen nur so aus, als würden sie auf Software laufen. Sie laufen auf Infrastruktur. Ohne Infrastruktur geht nichts. Schwache Technologieentscheidungen werden die geschäftliche Agilität und Wertschöpfung beeinträchtigen. Technologiearchitekten sind auf den Technologiebereich spezialisiert. Sie können ihre Arbeit nicht erledigen, ohne effektiv mit ihnen zu arbeiten Geschäftsarchitekten, Daten-, Technologie- und Sicherheitsarchitekten.
Welche Rolle spielt der Enterprise Architect in Phase D?
Der Unternehmensarchitekt hat dieselbe Rolle in TOGAF Phase D. Ein Unternehmensarchitekt muss dort einspringen, wo ein Domänenarchitekt Hilfe benötigt. Entweder die Technologiearchitektur entwickeln, andere Domänen interpretieren oder den Wert schützen. Viele Technologiearchitekten werden die Auswirkungen nicht sehen, die von der Geschäftsarchitektur ausgehen oder auf sie gehen. Oder sie formulieren keine Anforderung in Bezug auf die Sicherheitsarchitekten, auf die sie reagieren können.
Die wichtigste Rolle des Unternehmensarchitekten ist das Überschreiten von Grenzen. Unabhängig davon, ob es sich um Domänen-, Kompetenz- oder Autoritätsgrenzen handelt, muss der Unternehmensarchitekt sie überschreiten.
Modelle, Werkzeuge und Techniken der Technologiearchitektur
Die TOGAF ADM Phase D liefert die Informationssystemarchitektur. Diese Phase besteht darin, die Technologiearchitektur und die Datenarchitektur zu entwickeln, aus denen die Informationssysteme bestehen. In TOGAF besteht der erste Schritt darin, die erforderlichen Ansichten und die erforderlichen Modelle zu bestimmen.
Stakeholder Concerns werden die Ansichten identifizieren. Es gibt sieben zentrale Technologiearchitekturmodelle.
- Infrastrukturanbietermodell legt fest, wie die Infrastruktur bereitgestellt wird
- Infrastruktursystemmodell erfasst die großen Systeme Ihres Infrastrukturportfolios
- Infrastrukturdienstmodell bricht das Infrastrukturportfolio in Black Boxes auf und konzentriert sich auf das Ergebnis und die Eigenschaften des Dienstes
- Schnittstellenmodell beschreibt, wie Sie sich mit der Infrastruktur verbinden oder diese verwenden
- Lebenszyklusmodell identifiziert die erforderlichen Lebenszyklusattribute Ihres Infrastrukturportfolios
- Normenkatalog identifiziert die Beschaffungsstandards für Ihr Infrastrukturportfolio
- Physikalisches Modell der Infrastruktur erklärt, welche reale Infrastruktur im Infrastrukturportfolio vorhanden ist
Technologiearchitekturmuster
Architekturmuster sind eine konsistente Herangehensweise an ein vorhersehbares Problem. Unser Mustervorlage hebt das hervor Vorhersehbares Problem, Ansatz, und das Harte Teile. Wenn wir ein Muster in Betracht ziehen, müssen wir die erforderliche Arbeit, Einschränkungen und Beschränkungen bewerten.
Beispielhafte Technologiearchitekturmuster
- Mehrschichtiges Infrastrukturmuster
Vorhersehbares Problem—Modularität, Wartbarkeit und Skalierbarkeit von Technologiesystemen
Ansatz-unterteilt die Infrastruktur in verschiedene Schichten, von denen jede für bestimmte Funktionen verantwortlich ist, wie z. B. Präsentation, Anwendungslogik und Datenspeicherung. - Hochverfügbarkeit (HA) und Redundanzmuster
Vorhersehbares Problem– Systemverfügbarkeit sowie Fehlertoleranz und Wartbarkeit
Ansatz– Duplikat kritischer Komponenten und Dienste. - Serverloses Architekturmuster
Vorhersehbares Problem—Modularität, Wartbarkeit und Skalierbarkeit von Technologiesystemen
Ansatz– Infrastrukturressourcen als Reaktion auf Ereignisse automatisch zuweisen und skalieren
Technologiearchitekturmodelle
Die Entwicklung einer nützlichen Technologiearchitektur erfordert mehrere Modelle der Unternehmensarchitektur. Jede Modellart erklärt einen anderen Aspekt des Infrastrukturportfolios. Die TOGAF-Phase-D-Technologiearchitektur erläutert die allgemeinen Schritte zur Entwicklung der Zielarchitektur. Verschiedene Modellarten ermöglichen Ihnen, das Infrastrukturportfolio auf unterschiedliche Weise zu betrachten.
Unter Verwendung der minimalen Anzahl von Verknüpfungen beschreiben diese Modelle die Technologiearchitektur. Mit einem Minimum an Verknüpfungen zu anderen Domänen wird eine vollständige Unternehmensarchitektur beschrieben.
Infrastrukturanbietermodell
Das Infrastrukturanbietermodell beschreibt, wie die Infrastruktur bereitgestellt wird. Dieses Modell erfordert ein Infrastrukturdienst- oder Infrastruktursystemmodell.
Es gibt vier grundlegende Anbietertypen:
- Public-Cloud-PaaS, können als Punktinfrastrukturdienste zusammengestellt werden. Einschränkungen und Einschränkungen der Interoperabilität erfordern die Auswahl in Anbieterbündeln
- Enterprise-Systeme, Mainstream-Common-Use-Infrastruktur. Typischerweise wird es in breiten Systemen bereitgestellt, die eine Reihe von Funktionen einbetten. Unternehmenssysteme erfordern Arbeit, um sie zu Infrastrukturdiensten zusammenzusetzen.
- Spezialisierte Systeme brillieren in verschiedenen Nischen. Typischerweise unterstützen spezialisierte Systeme einzigartige Anwendungsfälle. Beispiele sind luftfahrtzertifizierte Infrastruktur, erweiterte Schock- und Temperaturbereiche oder Quantencomputing
- Benutzerdefinierte Infrastruktur, die Sie für Ihre Organisation erstellt haben. In der Regel erfüllt Custom einzigartige Anforderungen in Ihrer Geschäfts- oder Anwendungsarchitektur.
Infrastruktursystemmodell
Das Systemmodell abstrahiert die Infrastruktur, die zum Bereitstellen einer Funktion erforderlich ist. Die meisten Technische Referenzarchitekturen basieren auf einem Systemmodell. Sie identifizieren die verschiedenen Merkmale der Infrastruktur.
Denken Sie an eine Anwendungsumgebung mit Anwendungsservern, Load Balancern und Speicher. Das Design Ihres Systemmodells schränkt Ihre Fähigkeit ein, Duplizierung, Starrheit und Komplexität zu erkennen.
Systemmodelle ermöglichen es Ihnen, auf Bereiche in Ihrer Infrastruktur zu lenken, in denen Betriebskosten, Starrheit und Doppelarbeit angegangen werden müssen. Sie verlagern das Gespräch von bestimmten Varianten des Systems auf den Kompromiss zwischen Auswirkungen auf andere Bereiche, Agilität, Kosten und Betrieb.
FEAF, OPAS und IndEA stellen alle Infrastruktursystemmodelle bereit. Erforderlich, um die Planung des Infrastrukturportfolios durchzuführen. Duplizierung und Spezialisierung treiben Komplexität und Kosten in das Infrastrukturportfolio.
Infrastrukturdienstmodell
Ein Infrastrukturdienstmodell ist eine spezialisierte Version eines Infrastruktursystemmodells. Es kollabiert alles zu einer Blackbox mit bekannten Attributen und Schnittstellen. Sie können Public Cloud PaaS nicht ausführen, oder Private Cloud-PaaS-Architektur ohne Servicemodell.
Ein Infrastrukturdienstmodell ist von unschätzbarem Wert bei der Entwicklung des Infrastrukturanbietermodells und der Validierung des Ziels in einem Infrastruktursystemmodell. Die Schnittstellen in Ihrem Servicemodell sollten alle in Ihrem Schnittstellenmodell gut identifiziert sein.
Unternehmensflexibilität erfordert ein gutes Infrastrukturdienstmodell. Sie müssen in der Lage sein, die Hindernisse für Veränderungen zu finden und zu beseitigen.
Schnittstellenmodell
Ein Schnittstellenmodell identifiziert, wie Sie verschiedene Komponenten Ihrer Infrastruktur miteinander verbinden und wie Anwendungen und Daten auf die Infrastruktur zugreifen. Sie können keine Private-Cloud-PaaS-Architektur ohne ein Schnittstellenmodell entwickeln. Jetzt können Sie Dienste von mehr als einem Public Cloud PaaS-Anbieter verbinden.
Sie jagen Grenzen zwischen Systemen. Sie müssen angeben, ob und wie eine Grenze überschritten werden kann. Zu oft versäumen es Technologiearchitekten, Grenzen zu spezifizieren, die nicht überschritten werden können. Aus diesem Versagen resultiert die meist starre und unveränderliche Infrastruktur.
Das Schnittstellenmodell ist entscheidend, um die Agilität des Unternehmens zu ermöglichen, das Infrastrukturportfolio zu verwalten und die IT-Kosten zu senken.
Lebenszyklusmodell
Ein Lebenszyklusmodell identifiziert die Anforderungen, die in das Infrastrukturdesign einfließen, und die Realität, die sich aus der physischen Infrastruktur ergibt. Wir verwenden das Lebenszyklusmodell, um den Lebenszyklus zu identifizieren, den wir haben und brauchen. Vor Jahren haben wir eine Kommunikationsarchitektur in einem bergigen Gebiet voller geschützter Wildnis entwickelt. Diese Architektur hatte eine Reihe einzigartiger Lebenszyklusanforderungen, die das Design vorangetrieben haben. Es trieb auch die betrieblichen Anforderungen voran.
Normenkatalog
Allzu oft gehen Architekten, mit denen wir zusammenarbeiten, davon aus, dass ein Technologiestandardkatalog Präferenzen für den Infrastrukturbetrieb in die Architektur einfließen lässt. Sie gehen davon aus, dass den anderen Domänen die Technologiestandards mitgeteilt werden. Dies gilt erst, nachdem die Stakeholder die Technologiearchitektur genehmigt haben. Bis Ihre Stakeholder die Architektur genehmigen, können Sie keine Architektur-Governance durchführen.
Die erste Verwendung eines von der Architektur entwickelten Standardkatalogs besteht darin, die nicht konforme Infrastruktur zu identifizieren. Infrastruktur, die Starrheit, Kosten, Komplexität und Mängel in die grundlegende Technologiearchitektur und jeden anderen Bereich einbringt.
Ihr Standardkatalog wird die Infrastrukturbeschaffung vorantreiben. Wenn es kein effektives Infrastrukturdienstmodell oder Infrastrukturschnittstellenmodelle gibt, bietet es Anleitung und Einschränkung für andere Domänen und Implementierer.
Physikalisches Modell der Infrastruktur
Ein physisches Modell beschreibt das tatsächliche Infrastrukturportfolio. Verwenden Sie immer die Begriffe, die von kommerziellen Infrastrukturanbietern verwendet werden. Sie müssen dies den anderen Technologiearchitekturmodellen zuordnen, um das Ziel in die reale Welt zu überführen.
Das physikalische Modell identifiziert viele Lücken in den abstrakteren Technologiearchitekturmodellen. Es bildet auch die Grundlage für die Implementierungs- und Migrationsplan, der in Phase F entwickelt wurde.
Techniken der Technologiearchitektur
Wir verwenden eine breite Palette von Techniken, um unsere Geschäftsarchitektur zu entwickeln und zu kommunizieren.
- Technische Referenzarchitekturen
- UML ist in guter modellgetriebener Entwicklung allgegenwärtig. Wenn Sie in der Architektur arbeiten, um die Lösungsentwicklung zu unterstützen, sollten ein Systemmodell und ein Schnittstellenmodell nach UML-Praktiken entwickelt werden.
- 4+1-Ansichten sind nützlich, um die Auswirkungen des Ziels auf verschiedene Gemeinschaften zu identifizieren. Die Entwicklung von 4+1-Modellen hilft sicherzustellen, dass Sie alle relevanten Änderungen berücksichtigen.
Technologiearchitekturmodelle, die auf den Zweck der Unternehmensarchitektur ausgerichtet sind
Die Ebene der Fragen, die Sie mit Ihrer Geschäftsarchitektur beantworten, wird die Verwendung verschiedener Geschäftsarchitekturmodelle vorantreiben. Beispielsweise entwickelt Architecture to support Portfolio oft kein Wertschöpfungskettenmodell. Stattdessen wird eine Wertschöpfungskette normalerweise eine überlegene Architektur sein und Ihre Freiheit einschränken.
| 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 | |
| Infrastrukturanbietermodell | Schlüssel lieferbar | Schlüssel lieferbar | Überlegene Architektur | Überlegene Architektur |
| Infrastruktursystemmodell | Regelmäßig lieferbar | Schlüssel lieferbar | Überlegene Architektur | Überlegene Architektur |
| Infrastrukturdienstmodell | Regelmäßig lieferbar | Schlüssel lieferbar | Schlüssel lieferbar & überlegene Architektur | Schlüssel lieferbar & überlegene Architektur |
| Schnittstellenmodell | Kaum benutzt | Gelegentlich lieferbar
Ein angemessener Detaillierungsgrad mindert oft den Wert |
Schlüssel lieferbar | Schlüssel lieferbar & überlegene Architektur |
| Lebenszyklusmodell | Gelegentlich lieferbar
Ein angemessener Detaillierungsgrad mindert oft den Wert |
Schlüssel lieferbar
Ein angemessener Detaillierungsgrad mindert oft den Wert |
Schlüssel lieferbar & überlegene Architektur | Überlegene Architektur |
| Normenkatalog | Kaum benutzt | Gelegentlich lieferbar
Ein angemessener Detaillierungsgrad mindert oft den Wert |
Schlüssel lieferbar & überlegene Architektur | Überlegene Architektur |
| Physikalisches Modell der Infrastruktur | Kaum benutzt | Gelegentlich lieferbar
Ein angemessener Detaillierungsgrad mindert oft den Wert |
Schlüssel lieferbar & überlegene Architektur | Schlüssel lieferbar & überlegene Architektur |
Einfluss von Anwendungsarchitekturmodellen auf Technologiearchitekturmodelle
| Anwendungsentwicklungsmodus | Systemmodell | Produktmodell | Integrationsmodell | Anwendungsservice | |
| Infrastrukturanbietermodell | Großer Input | Großer Input | Großer Input | Großer Input
Erfordert ein System- oder Funktionsmodell |
Großer Input
Erfordert ein System- oder Funktionsmodell |
| Infrastruktursystemmodell | Haupteingang | Haupteingang | Haupteingang | Begrenzter Eingang | Begrenzter Eingang |
| Infrastrukturdienstmodell | Haupteingang | Haupteingang | Haupteingang | Beste Eingabe
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
Beste Eingabe
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
| Schnittstellenmodell | Haupteingang | Haupteingang | Beste Eingabe
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
Beste Eingabe
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
|
| Physisches Infrastrukturmodell | Eingang | Haupteingang
Erfordert ein Anbietermodell |
Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Einfluss von Geschäftsarchitekturmodellen auf Technologiearchitekturmodelle
| Geschäftsmodell | Betriebsmodell | Wertschöpfungskette | Fähigkeitsmodell | Prozessmodell | Funktionsmodell | Informationsmodell | Organisationsmodell | |
| Infrastrukturanbietermodell | Großer Input
Erfordert ein System- oder Funktionsmodell |
Großer Input
Erfordert ein System- oder Funktionsmodell |
Großer Input
Erfordert ein System- oder Funktionsmodell |
Großer Input
Erfordert ein System- oder Funktionsmodell |
Großer Input
Erfordert ein System- oder Funktionsmodell |
Großer Input
Erfordert ein System- oder Funktionsmodell |
Begrenzter Eingang | Begrenzter Eingang |
| Infrastruktursystemmodell | Begrenzter Eingang | Begrenzter Eingang | Begrenzter Eingang | Begrenzter Eingang | Begrenzter Eingang | Haupteingang | Begrenzter Eingang | Haupteingang |
| Infrastrukturdienstmodell | Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Beste Eingabe
Eine direkte Verbindung ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen. |
Wird als Vollständigkeitstest verwendet | Haupteingang
Eine direkte Verbindung ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen. |
Haupteingang | |
| Schnittstellenmodell | Wichtiger Beitrag zur Existenz der Schnittstelle
Erfordert ein System- oder Funktionsmodell |
Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Wichtiger Beitrag zur Existenz der Schnittstelle
Erfordert ein System- oder Funktionsmodell |
Wichtige Beiträge zum Kerndesign | Wichtige Beiträge zum Kerndesign
Erfordert ein System- oder Funktionsmodell |
|||
| Physisches Infrastrukturmodell | Wichtiger Beitrag zur Existenz von Infrastrukturstandorten
Erfordert ein Anbietermodell |
Wichtiger Beitrag zur Existenz von Infrastrukturstandorten
Erfordert ein Anbietermodell |
Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Input zum Kerndesign | Begrenzter Eingang
Die Verbindungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Technologiearchitekturmodelle für Unternehmensarchitektur-Anwendungsfälle
Jeden Anwendungsfall der Unternehmensarchitektur geht es darum, wirksame Veränderungen zu ermöglichen. Es gibt viele Arten von Veränderungen. Unsere Anwendungsfälle für Unternehmensarchitekturen helfen bei der Beantwortung häufiger Fragen.
Dabei spielt es keine Rolle, um welchen Anwendungsfall es sich handelt. Die Technology Architects haben das gleiche Ziel – ihren Stakeholdern dabei zu helfen, bessere Entscheidungen zu treffen und erfolgreiche Veränderungsinitiativen zu leiten.
| 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 | |
| Infrastrukturanbietermodell | Sehr hilfreich | Wichtige Einschränkungen | Wichtige Richtlinien | Kritische Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen |
| Infrastruktursystemmodell | Sehr hilfreich
Kritische Lücken und Einschränkungen |
Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | ||||
| Infrastrukturdienstmodell | Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
| Lebenszyklusmodell | Sehr hilfreich
Kritische Lücken und Einschränkungen |
Kritische Lücken und Einschränkungen | Sehr hilfreich
Kritische Lücken und Einschränkungen |
Sehr hilfreich
Kritische Lücken und Einschränkungen |
Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Sehr hilfreich
Kritische Lücken und Einschränkungen |
Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen |
| Standardkatalogmodell | Sehr nützlich für Lücken und Einschränkungen | Sehr hilfreich
Kritische Einschränkungen |
Sehr hilfreich
Kritische Einschränkungen |
Sehr hilfreich
Kritische Einschränkungen |
Einschränkungen | Lücken und Einschränkungen | Lücken und Einschränkungen | Sehr nützlich für Lücken und Einschränkungen |
Anwendung der Prinzipien der Unternehmensarchitektur auf die Technologiearchitektur
Es gibt 7 Architekturprinzipien, die jeder Unternehmensarchitekt kennen sollte. Prinzipien sind überlegene Architektur und schränken Ihre Freiheit bei der Entwicklung von Architektur ein. Jedes Ihrer Architekturprinzipien wird es tun schränken die Entwicklung Ihrer Technologiearchitektur ein. Testen Sie immer Ihre Kandidatenarchitektur, finden Sie keine Ausrichtungsaussage. Beweisen Sie, dass Sie dem Buchstaben und dem Geist folgen. Sie wissen, dass das Prinzip richtig ist. In TOGAF ADM Phase D müssen Sie nachweisen, dass die Technologiearchitektur konform ist.
| Implikation der Technologiearchitektur | |
| Leg dich nicht mit dem Erfolg an | Versuchen Sie, Veränderungen zu eliminieren. Ja, eliminieren Sie alle Änderungen, die nicht ausdrücklich gerechtfertigt sind |
| Fokus auf Exzellenz | Nutzen Sie die Fähigkeitsmodell und das Anwendungsentwicklungsmodell um sicherzustellen, dass die Technologie Enterprise Excellence ermöglicht.
Richten Sie mit aus Digitales Produktmodell. Produkt und Service sind direkt für den Kunden und haben sehr unterschiedliche Mindeststandards. |
| Warum nicht eins? | Nutzen Sie die Anwendungsentwicklungsmodell und Infrastructure Service Model, um herauszufinden, wo eine Duplizierung verboten ist. Dann beseitige es. |
| Daten sind ein Vermögenswert | Stellen Sie sicher, dass die Infrastruktur die Anforderungen des Asset-Managements und der Asset-Nutzung erfüllt. |
| Systeme funktionieren, wo wir arbeiten | Arbeitsort und Arbeitsstil bestimmen die Infrastruktur. |
| Schmerzlose Benutzererfahrung | Differenzierungs-, Transformations- und Effizienzprogramme erfordern Kostenmodelle, die Produktivität liefern. Meistens beseitigen Sie Produktivitätseinbußen, anstatt sie zu verbessern. |
| Selbstbedienung | Verwaltungsaktivitäten und -bereitstellung der Infrastruktur verursachen hohe Kosten, wenn es sich nicht um Self-Service handelt. Alles, was den Self-Service blockiert, mindert die Produktivität und den Umsatz. |
Wie passt TOGAF Phase D zur agilen Entwicklung?
Die Infrastruktur ermöglicht oder entzieht potenziellen Werten aus der agilen Entwicklung. Wenn Ihre Organisation eine starke Fähigkeit zur agilen Entwicklung benötigt, müssen Sie Ihre Infrastruktur um die Fähigkeit zur agilen Entwicklung herum aufbauen. Das Anwendungsentwicklungsmodell identifiziert den Umfang und ob agile Entwicklung hilfreich oder kritisch ist.
Stützen Sie sich auf Ihr Infrastrukturanbietermodell und Ihr Infrastrukturdienstmodell, um die Technologiearchitektur an Ihren agilen Anforderungen auszurichten.
Keiner der vier Bereiche, in denen sich die Unternehmensarchitektur mit der agilen Entwicklung überschneidet, ist immer auf die Technologiearchitektur ausgerichtet. Direkte Ausrichtung kommt von der Produktmodell. Sehen Sie sich neben der direkten Ausrichtung immer die Infrastrukturdienste an.
Wie ermöglicht TOGAF Phase D Unternehmensagilität?
Wie wir wissen, hat Unternehmensagilität nichts damit zu tun, wie Sie Software schreiben. Unternehmensflexibilität Die Fähigkeit Ihres Unternehmens, auf unerwartete Bedrohungen und Chancen zu reagieren. So einfach ist das. Können Sie auf das Unerwartete reagieren?
Der Modell der Unternehmensagilität hat fünf Punkte:
- 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?
Die meiste Zeit arbeitet die Unternehmensarchitektur an #5 - Flexibilität. Suchen Sie nach jedem Bereich, der Starrheit erzeugt, und entfernen Sie ihn. In unserer Infrastruktur-Lebenszyklusplanung diskontieren wir jeden Nutzen, der nicht innerhalb von 2 Jahren bezogen wird. Dies stellt eine erhebliche Belastung für die Technologiearchitektur dar und unterstreicht, warum Public Cloud PaaS so attraktiv ist.
Abschließende Gedanken zu TOGAF ADM Phase D
Erfolgreich Unternehmensarchitekturteams Verschwenden Sie ihre Technologiearchitekten nicht mit dem Entwerfen und Leiten der Implementierung von Infrastrukturen. Das verwechselt einen Technologiearchitekten mit einem Lösungsarchitekten. Es schädigt die Unternehmensstruktur.
Technologiearchitekten müssen die Richtlinien und Leitplanken für die Personen entwickeln, die Lösungsarchitekten entwickeln, das Infrastrukturportfolio des Unternehmens entwerfen, implementieren und möglicherweise erfinden. Kurz gesagt, die Enterprise Technology Architect ist kein Lösungsarchitekt noch ein Technologiespezialist, der als Technologiearchitekt bezeichnet wird. Obwohl diese Rollen wichtig sind, tragen sie nicht zu einem EA-Team bei.
In TOGAF ADM Phase D entwickeln Sie die vier grundlegenden Bereiche der Unternehmensarchitektur. TOGAF ist klar, dass Sie diese Architektur mit den anderen Domänen entwickeln. Der Unterschied besteht darin, dass die Technologiearchitektur häufig Änderungen außerhalb der meisten Änderungsinitiativen vorantreibt. Infrastrukturen, die Sie besitzen, sind langlebige Kapitalanlagen und entwickeln sich in einem sehr unterschiedlichen Tempo. Die Infrastruktur muss vor dem Bedarf da sein. Die Infrastruktur muss in ihrem Zyklus aktualisiert werden.
Erfolgreiche Technologiearchitekten führen und beschränken:
- Der Unternehmensarchitekt Domänenarchitekten nach der Kunst des Möglichen
- Infrastrukturplaner über die Erfolgskriterien
- Lösungsarchitekten und spezialisierte Technologiearchitekten zu Beurteilungskriterien, Erfolgskriterien und Priorität
Großartige Technologiearchitekten ermöglichen Unternehmensagilität und agile Softwareentwicklung. Sie haben sich auf die Balance zwischen Effizienz und Agilität konzentriert.
TOGAF ADM Phase D entwickelt die Technologiearchitektur. Die Technologiearchitektur ist die Grundlage aller modernen digitalen Unternehmen. Verwenden Sie TOGAF Phase D, um knappe Änderungsressourcen auf Effizienz und Agilität zu konzentrieren. Dadurch wird ein nachhaltiger Unternehmenswert aus Infrastrukturinvestitionen erzielt.
