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?
- Technologiearchitekturmodelle, -tools und -techniken
- Technologiearchitekturmodelle
- Werkzeuge und Techniken der Technologiearchitektur
- Wie ist Phase D von TOGAF mit Agile vereinbar?
- Abschließende Gedanken zu TOGAF ADM Phase D – Technologiearchitektur
TOGAF ADM-Übersicht
Verwenden Sie die TOGAF ADM um das notwendige Wissen für die optimale Technologiearchitektur zu entwickeln. Jede ADM-Phase liefert die notwendigen Inputs und Aktivitäten, um Wissen zu einem bestimmten Thema zu entwickeln. Das TOGAF ADM steht im Mittelpunkt des TOGAF-Standards. Es ist die einzige skalierbare universelle Methode zur Entwicklung Unternehmensarchitektur. Es eignet sich für jede Detailebene. Wie alle logischen Modelle muss es erweitert werden, um verschiedene Detailebenen abzudecken – Strategie, Portfolio, Projekt und Lösungsbereitstellung.
Wenn Sie eine Übersicht über das TOGAF ADM, lesen Sie bitte die Erläuterung der TOGAF ADM-Phasen.
Was ist TOGAF Phase D?
In TOGAF Phase D, Technologiearchitekten Leiten Sie die Entwicklung der Technologiearchitektur. Sie tun dies, indem sie die Informationssystemarchitektur ermöglichen – nicht indem sie Befehle entgegennehmen und Hoffnungen erfüllen. Technologiearchitekten wissen, dass langlebige Infrastruktur ihre Umgebung liefert. Sie müssen vorausschauend und bereit sein. Sie müssen sicherstellen, dass kurzfristige Hoffnungen nicht zu langfristigem Leid führen.
Wenn wir Entwicklung von Enterprise-Architecture-Teams, erzählen wir den Architekten zwei zentrale Fakten über TOGAF Phase D - Technologiearchitektur. Erstens, bis Sie eine Anwendungsentwicklungsmodell, Sie können nicht weitermachen. Es ist sinnlos, Details Ihrer Infrastruktur zu entwickeln, bevor Sie die Anforderungen Ihrer Anwendungsarchitektur verstanden haben. Zweitens wird bei der Entwicklung einer IT- oder Infrastrukturagenda immer eine minderwertige Technologiearchitektur entwickelt. Infrastrukturentwickler und -betreiber sollten sich durch die Technologiearchitektur eingeschränkt fühlen.
In einem modernen, digital transformierten Unternehmen interagieren alle Architekturbereiche. Entscheidungen in einem Bereich ermöglichen, liefern oder verhindern Ergebnisse in einem anderen Bereich. Die meisten Geschäftsziele hängen ab von richtige IT-Architektur. Wir können die richtige Technologiearchitektur nur entwickeln, wenn wir über eine solide Anwendungsarchitektur verfügen.
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 besteht eine direkte Verbindung zwischen guter Technologiearchitektur und modernem PaaS bzw. den meisten Cloud-Architekturen. Beide identifizieren Infrastrukturdienste. Beide ermöglichen und beschränken Daten- und Anwendungsauswahl. 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 eine vereinfachte Zielarchitektur – die Architekturvision. Die Architekturvision sollte besser Geschäft, Anwendung, Daten, und Technologiedomänen. Zu oft sehen wir, wie Leute vorgeben, eine Architekturvision zu entwickeln. Sie treten mit einer Fantasie über Geschäftsabläufe auf und betrachten Phase D als eine Übung zur Umsetzung ihrer Fantasie. Echte Unternehmensarchitektur hat eine vereinfachte Zielarchitektur entwickelt. Die Aktivitäten in Phase D entwickeln 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 Wünschen der Stakeholder entspricht? (Lücken)
- Sie verfügen über ein ausreichendes Verständnis der für die Umsetzung von Änderungen notwendigen Arbeit (Arbeitspaket)
- Sie verstehen die Wechselwirkung zwischen Änderungen und Einschränkungen in anderen Architekturdomänen, um den erwarteten Wert zu schützen (Architekturanforderungsspezifikationen).
Das zentrale Ergebnis von Phase D ist die Technologiearchitektur. Technologiearchitekten arbeiten mit den anderen Domänenarchitekten zusammen. Es ist mit einem Austausch von Wünschen und Einschränkungen zu rechnen. Jede Architekturentwicklung erfordert die optimale Lösung für das Unternehmen. Die beste Lösung berücksichtigt Einschränkungen und funktioniert in allen Domänen.
Der Sinn des TOGAF ADM besteht darin, mögliche Veränderungen zu untersuchen. Veränderungen werden in Bezug auf Arbeit, Wert und Risiko. Änderungen, die ausgewählt oder gelöscht werden. Der Satz von Änderungen erstellt die Zielarchitektur und die Architektur-Roadmap.
Technologiearchitekten arbeiten mit Infrastruktur. Infrastruktur ist der am schwierigsten zu verändernde Teil einer Organisation. Technologiearchitekten müssen jede mögliche Änderung hinterfragen und nach Auswegen Ausschau halten. Der kostengünstigste Ausweg ist die Architekturentwicklung. Stoppen Sie schlechte Ideen frühzeitig. Die Beseitigung schlechter Ideen spart Geld und ermöglicht erfolgreiche Veränderungen. Die Notwendigkeit, bei der Infrastruktur vorausschauend zu denken, erfordert von den Technologiearchitekten, Infrastrukturdesigner und -implementierer einzuschränken.
Interaktion mit TOGAF Phase B, Phase C, und Phase E
‘'‘Das Geschäft’Das ist das Unternehmen. Das war schon immer so. Moderne digitale Unternehmen können nicht auf fleißige Mitarbeiter 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 verhindern digitale Transformationen.“.
Sie haben das TOGAF ADM mit der Herausforderung entwickelt, die Aufarbeitung zu unterteilen und die Zusammenarbeit zu fördern. Leider zeigt das klassische TOGAF ADM-Diagramm den Fluss der notwendigen Informationen. Bitte interpretieren Sie das Diagramm nicht als Wasserfall.
Wer behauptet, Unternehmensarchitektur könne sequenziell entwickelt werden, irrt sich. Wer rät, das gesamte Unternehmen zu entwerfen, irrt sich ebenfalls. Komplexität und Spezialisierung erfordern Domänen. Ihre Entwicklung beginnt und verläuft gemeinsam. Sie müssen einen agilen Ansatz verfolgen, der gerade genug Zeit bietet, um die kaskadierenden Einschränkungen zu testen. TOGAF nennt dies Iteration.
Architektonische Entscheidungen wird mehrere überqueren Architekturdomänen erfordert die Verwendung Architekturalternativen.
Was ist Technologiearchitektur?
Technologiearchitektur ist einer der vier grundlegenden Bereiche der Unternehmensarchitektur. Eine Technologiearchitektur beschreibt Ihr komplettes Infrastrukturportfolio und gibt Ihnen Aufschluss darüber, wann Sie Infrastruktur kaufen, wann Sie PaaS nutzen und wann Sie Infrastruktur entwickeln sollten. Sie zeigt Ihnen, wo Sie Grenzen zwischen Systemen setzen und wie Sie den Lebenszyklus Ihrer Infrastruktur gestalten.
Wir garantieren, dass Ihre aktuelle Technologiearchitektur nicht darauf abgestimmt ist. Wir sind überzeugt, dass Ihre Infrastrukturplanung keine solide Grundlage für Ihre Ausgangssituation bietet. Anwendungsarchitektur oder Geschäftsarchitektur.
Wenn Sie über eine Technologiearchitektur verfügen, verfügen Sie über die Infrastrukturdienste, die Ihre Anwendungen benötigen. Sie verfügen über eine Reihe von Richtlinien und Einschränkungen für die Gestaltung und den Betrieb Ihrer Infrastruktur. Sie verfügen über eine Technologie-Roadmap, die Ihre Stakeholder verstehen.
Um die Technologiearchitektur, ihre Dienste, Richtlinien und Einschränkungen zu entwickeln, muss der Technologiearchitekt mit seinen Kollegen und den Stakeholdern zusammenarbeiten. Er muss untersuchen, wie unterschiedliche Infrastrukturoptionen Geschäfts- und Softwareentscheidungen ermöglichen oder blockieren. Er muss herausfinden, wie die verschiedenen Optionen die Unternehmensziele fördern und einschränken. Potenzielle Änderungen, die zu wenig bringen, zu viel Arbeit erfordern oder zu viele Unsicherheiten bergen, sollten verworfen werden. Gute Architektur-Roadmaps enthalten notwendige Änderungen und sind risikoarm.
Wofür wird eine Technologiearchitektur verwendet?
Die Technologiearchitektur hilft bei der Beantwortung der folgenden Fragen:
- Wie das Infrastrukturportfolio Wertschöpfung ermöglicht – Infrastruktur-Servicemodell
- Wie die Infrastruktur bereitgestellt wird – Infrastrukturanbietermodell
- Wo Kosten in das IT-Portfolio einfließen - Schnittstellenmodell
- Wo Starrheit in das IT-Portfolio eingebracht wird - Lebenszyklusmodell
- Was eine Infrastruktur können muss – Infrastruktursystemmodell
- Einschränkungen beim Erwerb und Einsatz von Technologie – Normenkatalog
- So nutzen Sie die Infrastruktur zur Durchführung der Unternehmensaktivitäten – Schnittstellenmodell
- Die gesamten Aktivitäten einer Infrastruktur, gruppiert, um zu zeigen, wie sie zueinander in Beziehung stehen – Servicemodell
- Was das Infrastrukturportfolio ist – Modell der physischen Infrastruktur
Technologiearchitektur vs. Cloud-Architektur
Wir sehen fast keinen Unterschied zwischen gutem PaaS oder gutem Private Cloud-Architektur, und eine gute Technologiearchitektur. Die Kernarbeitsprodukte, ein Systemmodell und Servicemodell, sind gleich. Der Unterschied besteht darin, dass Sie sich bei 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 entwickelt haben, ein klares Paket an Infrastrukturdiensten bereitgestellt. Sie haben die Schnittstellen und Standards für diese Dienste spezifiziert. Wir vermuten, dass Ihre Arbeit problemlos in einen Public Cloud PaaS-Servicekatalog übertragen werden kann.
TOGAF 8 forderte Technologiedienste zur Abstraktion detaillierter Infrastrukturen, um Portabilität zu ermöglichen, die Infrastrukturen zu verwalten und Infrastruktur-Lebenszyklen zu ermöglichen. Aus demselben Grund, aus dem alle Public Cloud PaaS-Anbieter ihre Kunden die Dienste nutzen lassen. Hätten wir alle nur eine gute Technologiearchitektur entwickelt, hätten wir die Sackgasse unbeweglicher Anwendungen, nicht bereitgestellter Infrastrukturen und technischer Schulden vermieden.
>>> Springen zu Die Grundlagen der Private-Cloud-Architektur
Nennen wir es Technologiearchitektur, Infrastrukturarchitektur oder IT-Architektur?
Der TOGAF-Standard nennt es Technologiearchitektur. Unsere Unternehmensarchitektur-Beratungspraxis nutzt in der Regel Infrastruktur. Viele andere fordern eine IT-Architektur. Bemühungen, eine klare, universelle Definition zu entwickeln, scheitern regelmäßig. Wir raten dringend, sich auf den Zweck statt auf die Definition zu konzentrieren.
Die Trennung zwischen den Architekturbereichen hilft uns, die richtigen Fähigkeiten und die richtigen Gespräche zusammenzubringen. Durch die Berücksichtigung dieses Zwecks bleibt der Fokus auf der Entwicklung einer nützlichen Architektur.
Wer über die Definition nachdenkt, landet regelmäßig in sinnlosen Diskussionen. Handelt es sich bei dem KI-Chatbot um eine Anwendung, KI oder ein Geschäft? Ist E-Mail eine Anwendung oder Infrastruktur? Wie wäre es mit Gesichtserkennung für die Zugangskontrolle? Die Möglichkeiten sind endlos.
Alle Domänen der Unternehmensarchitektur gehen ineinander über. Zusammen decken Domänen die gesamte Unternehmensarchitektur ab. Wir erstellen eine Domäne, damit ein spezialisierter Architekt Techniken und Fähigkeiten nutzen kann. Ständig entstehen neue Domänen der Unternehmensarchitektur. Die meisten werden absorbiert in eine klassische Unternehmensarchitekturdomäne wenn sie zum Mainstream werden.
Unser Rat: Machen Sie sich keine Gedanken darüber, was richtig ist. Stellen Sie stattdessen sicher, dass Sie verstehen, was jemand anderes meint, wenn er spricht. Seien Sie sich immer im Klaren darüber, was Ihre Zuhörer von Ihnen erwarten. Übernehmen Sie die Verantwortung für Ihr Verständnis und passen Sie Ihre Formulierungen an.
Was ist der Unterschied zwischen einem Enterprise-Architekten und einem IT-Architekten?
Viele gehen davon aus, dass sich ein Enterprise-Architekt auf die IT-Infrastruktur konzentrieren sollte. Um dieses Problem zu vermeiden, haben wir bei mehreren Beratungsaufträgen unsere Enterprise-Architekten umbenannt. Der Beruf des Enterprise-Architekten ist eindeutig. IT-Architektur ist ein Teilbereich der Enterprise-Architektur. Technologie ist ein Teilbereich der IT-Architektur.
Wir konzentrieren uns bei Enterprise-Architekten auf das Zusammenspiel aller Architekturbereiche. In vielen Teams gibt es Datenarchitekten, Anwendungsarchitekten, Sicherheitsarchitekten, Geschäftsarchitekten und Technologiearchitekten. Sie werden entweder nach ihrer Rolle oder mit der allgemeinen Bezeichnung „Enterprise-Architekt“ bezeichnet.
TOGAF ADM Phase D – Ergebnisse der Technologiearchitektur
Ein zentrales Ergebnis von Phase D ist eine Technologiearchitektur. Diese ist ein Teil der gesamten Unternehmensarchitektur. Auf Umwegen ergeben sich für TOGAF ADM Phase D fünf nützliche Ergebnisse:
- Modelle, die die Technologiearchitektur umfassen
- Lücken zwischen der aktuellen und der Zieltechnologiearchitektur
- Mögliche Arbeitspakete, 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 die Organisation verbessern wollen. Verbesserung erfordert Veränderung. Veränderung schafft Mehrwert. Wert und Kosten von Veränderungen sind messbar. Unsicherheit mindert immer den potenziellen Wert. Ist der Erfolg ungewiss, steigen die Kosten exponentiell. Schon geringe Unsicherheiten können Erwartetes ausschließen.
Wenn wir von Technologiearchitektur sprechen, beziehen wir uns meist auf die Modelle und Architekturspezifikationen. Verschiedene Modelle erklären unterschiedliche Aspekte der gesamten Infrastruktur. Zusammen bilden die Modelle und die erforderlichen Änderungen die Technologiearchitektur.
Bedenken Sie bei der Betrachtung verschiedener Modellarten, dass dieselben Begriffe häufig verwendet werden. Wir möchten Sie dazu anhalten, die Bezeichnung des Modells nicht zu sehr zu berücksichtigen. Was Sie als funktionales Dekompositionsmodell bezeichnen, wird von anderen als Service bezeichnet. Unsere Unternehmensarchitekturberatung konzentriert sich auf den Zweck, nicht auf die Bezeichnung des Modells. Sie können es als funktionale Dekomposition, Systemmodell oder Servicemodell bezeichnen. Uns interessiert nur der Zweck des Modells – was möchten Sie lernen, und erklärt Ihr Modell effektiv, wie dieser Aspekt der realen Arbeit funktioniert?
Abschluss der Phase D der Technologiearchitektur
Alle TOGAF ADM-Phasen bieten die nötigen Informationen und Aktivitäten, um das benötigte Wissen zu entwickeln. Das Ergebnis von Phase D ist die Entwicklung einer geeigneten Technologiearchitektur.
| Ausgabe und Ergebnis | Grundlegendes Wissen |
| Die von den Beteiligten für das zu behandelnde Problem genehmigte Technologiedomänenarchitektur mit einer Reihe von Lücken und die Arbeit zur Beseitigung der von den Beteiligten verstandenen Lücken. | Warum wird das aktuelle Technologieportfolio den Wünschen der Stakeholder nicht gerecht?
Was muss sich ändern, damit das Softwareportfolio den Wünschen der Stakeholder entspricht? (Lücken) Welche Arbeiten sind notwendig, um die Änderungen zu realisieren, die mit der zusätzlichen Wertschöpfung im Einklang stehen? (Arbeitspaket) Wie sich die Prioritäten und Präferenzen der Stakeholder als Reaktion auf Wert, Aufwand und Risiko von Änderungen anpassen. (Anforderungen der Stakeholder) |
Tabelle aus TOGAF 10 TOGAF Series Guide: Enterprise Architect's Guide to Developing Architecture
Phase D Bare Bones
In Phase D besteht die Aufgabe eines Technologiearchitekten darin, zu ermitteln, welche technologischen Änderungen erforderlich sind, damit die Informationssysteme das Unternehmen unterstützen. Klingt einfach. Sie müssen lediglich verstehen, was das Unternehmen verbessern möchte, wo es Defizite hat und was sich ändern muss.
Das Grundgerüst von Phase D ist:
- Wissen, wie das Infrastrukturportfolio die Wertschöpfung ermöglicht
Unternehmen schaffen Wert, wenn sie etwas tun, wofür ein Kunde bereit ist, mehr zu bezahlen. Wert entsteht typischerweise, wenn ein Material ausgetauscht, eine Dienstleistung erbracht oder Informationen genutzt werden. Eisenerz wird zu Stahl, Wetterwarnungen werden übermittelt oder Teile, Bestellungen und Fertigungskapazitäten werden benötigt, um einen Produktionsauftrag zu erstellen.
Technologie spielt in der Regel eine unterstützende Rolle. Sie ermöglicht es Menschen und Anwendungen, Wert zu generieren. Als unterstützende Funktion optimieren wir die Effizienz. Die entscheidende Frage lässt sich durch die Kenntnis der erforderlichen Mindestleistungen beantworten.
- 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 ohne eigene Technologie betreiben. Die meisten Organisationen verfügen über eine Mischung aus eigener und betriebener Infrastruktur, von anderen betriebener Infrastruktur und einer Reihe von Infrastrukturdiensten.
- Die Ursache von Kosten, Komplexität und Starrheit kennen
Jedes Infrastrukturportfolio leidet unter Starrheit. Infrastruktur lässt sich nur schwer verändern. Komplexität und Starrheit führen zu Kosten und Aufwand. Ihre Infrastruktur wirkt wie ein komplexes Uhrwerk. Eines, das aus nahezu zufällig ausgewählten Teilen zusammengesetzt wurde. Die Änderung einer einzigen Komponente führt in der Regel zu kaskadierenden Änderungen im gesamten Portfolio.
Die Technologiearchitektur muss ihre Starrheit reduzieren, um Unternehmensagilität. Sie müssen Ihr Kerninfrastrukturportfolio optimieren, um nachhaltige Kosten und Komplexität zu reduzieren. Der Wettlauf um Public Cloud PaaS ist lediglich ein Versuch, etwas Agilität zu erkaufen. 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 Modell hat ein anderes Kosten- und Optimierungsmodell. Sie müssen das richtige Infrastrukturbeschaffungsmodell an den richtigen Stellen anwenden.
- Die Erwartungen an die Infrastruktur kennen
Manchmal benötigen wir einen allgemeinen Infrastrukturdienst. Manchmal brauchen wir spezielle Hardware. Meistens brauchen wir etwas ohne allzu großen Aufwand. Wir nutzen die Konzepte und Attribute in Fähigkeitsmodelle um Entscheidungen über unsere Technologiearchitektur zu treffen. Unser Business Architecture Capability Assessment Guide enthält eine Reihe von Attributen, die leicht angepasst werden können.
- Wissen, wie man die Infrastruktur nutzt
Welche Schnittstelle wird gewählt? Entscheiden Sie sich für einen Industriestandard oder gehen Sie mit einer speziellen Schnittstelle noch einen Schritt weiter? Maskieren Sie die Schnittstelle mit Abstraktion?
Dann geht es um den Betrieb der Infrastruktur. Welche Erwartungen werden an den Betrieb gestellt? Wie sieht es mit der Verfügbarkeit aus oder mit der Fähigkeit, Komponentenausfälle zu verkraften? Welche Voraussetzungen müssen erfüllt sein, um die Infrastruktur ändern zu können?
- Was muss sich ändern, um das beste Infrastrukturportfolio bereitzustellen?
Wir entwickeln Technologiearchitekturen, um Unternehmen zu verbessern. Das Tempo und die Realität von Infrastrukturänderungen führen dazu, dass die meisten Änderungen außerhalb des Zyklus erfolgen. Aktuelle Geschäftsänderungen müssen die vorhandene Infrastruktur nutzen. Als Technologiearchitekt arbeiten Sie oft am fünften Aspekt der Unternehmensagilitätsmodell - Flexibilität. Ohne präventive Maßnahmen zur Reduzierung von Handlungsbarrieren ist Ihr Unternehmen gegenüber unerwarteten Veränderungen gesperrt.
Die meisten Änderungen sind nur kleine Veränderungen. Im Sinne von Six Sigma handelt es sich um lokale Optimierung. Ein kleiner Teil des Systems wird verbessert, selbst wenn dies zu Lasten des Gesamtsystems geht. Nutzen Sie als Technologiearchitekt die Anleitung in TOGAF ADM Phase D, um sich auf wesentliche Änderungen zu konzentrieren, die die Unternehmensagilität, Kostenoptimierung oder Wertschöpfung fördern.
Die drei wesentlichen Punkte zur Fertigstellung von Phase D:
- Erstens: Was muss sich ändern? Änderungen bei Service, Leistung, Schnittstelle, Betrieb, Outsourcing, Insourcing oder Automatisierung. All das sind Änderungen. Wir nehmen sie vor, um eine Organisation zu verbessern. Versuchen Sie, Ihr Infrastrukturportfolio zu verbessern.
- Zweitens: Wann muss sich etwas ändern? Gibt es Abhängigkeiten? Wie sieht es mit Vorbedingungen aus? Bereiten Sie mit der Änderung die Voraussetzungen für eine spätere Änderung vor?
- Drittens: Wie erkennen Sie, ob die Änderung erfolgreich war? Welchen Governance-Test benötigen Sie, um den Erfolg zu messen? Wie schützen Sie den Wert?
Die Zustimmung aller Architekturänderungen durch die Stakeholder ist erforderlich. Der Technologiearchitekt ist dafür verantwortlich, die Änderungen in verständlichen Begriffen zu beschreiben, die ihre Anliegen berücksichtigen. Außerdem muss er Governance-Tests durchführen, damit die Stakeholder das Änderungsprojekt steuern können.
TOGAF Phase D – Ergebnisse der Technologiearchitektur und Ziele der Unternehmensarchitektur
Die Entwicklung einer Unternehmensarchitektur verfolgt vier Hauptziele. Die einzelnen Ergebnisse der Phase D haben für jeden Zweck eine 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 Phase D: Kandidat-Technologiearchitektur | Wichtigstes Ergebnis
Der Hauptzweck besteht darin, den Stakeholdern das Ziel und die Arbeit zu vermitteln. Sekundäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Architekten |
Wichtigstes Ergebnis
Der Hauptzweck besteht darin, den Stakeholdern das Ziel und die Arbeit zu vermitteln. Sekundäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Architekten |
Vor Projektbeginn und Abschluss des Business Case
Primäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Implementierer |
Vor der Beauftragung von Ausführungspartnern (einschließlich interner Anbieter)
Primäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Implementierer |
| Arbeitsprodukt Phase D: Kandidaten-Roadmap-Elemente | Wichtigstes Ergebnis
Der Hauptzweck besteht darin, die Arbeit den Stakeholdern verständlich zu machen. Sekundäre Nutzung ist die Schaffung von Zwängen für Architekten |
Wichtigstes Ergebnis
Der Hauptzweck besteht darin, den Stakeholdern ein Verständnis von Arbeit und Abhängigkeit zu vermitteln. Sekundäre Nutzung ist die Schaffung von Zwängen für Architekten |
Eingeschränkte Nutzung Kann als Input für Projekte mit mehreren interaktiven Änderungen verwendet werden |
Vor der Beauftragung von Ausführungspartnern (einschließlich interner Anbieter).
Der Hauptzweck besteht in der Identifizierung erforderlicher Änderungen und der Präferenzen für die Durchführung von Änderungen, um die Auswahl und Einbindung von Lösungslieferpartnern zu verwalten. |
| Arbeitsprodukt Phase D: Spezifikation der Architekturanforderungen | Eingeschränkte Nutzung
Normalerweise können Architekten Einschränkungen aus einer besseren Architektur ableiten. |
Eingeschränkte Nutzung
Normalerweise können Architekten Einschränkungen aus einer besseren Architektur ableiten. |
Wichtigstes Ergebnis
Vor Abschluss der Projektinitiierung |
Wichtigstes Ergebnis
Vor der Beauftragung und Vertragsvergabe |
Tabelle von TOGAF-Rahmenwerk TOGAF-Reihenhandbuch: Leitfaden für Unternehmensarchitekten zur Architekturentwicklung
Kandidaten-Technologiearchitektur
Die Entwicklung einer Unternehmensarchitektur verfolgt vier Hauptziele. Für jeden Zweck haben unterschiedliche Modelle eine unterschiedliche Bedeutung.
>>> Zum Common springen Technologiearchitekturmodelle
Komponenten der Roadmap für die Kandidatentechnologiearchitektur
Was sind die Mindeständerungen? Wenn Sie einen Wechsel des Infrastrukturanbieters in Erwägung ziehen, handelt es sich wahrscheinlich nicht um wesentliche Änderungen. Wenn Sie von einem generischen Unternehmenssystem auf eine spezialisierte Infrastruktur umsteigen, ist die Komponenten- und Spezifikationsänderung im Infrastrukturanbietermodell der Roadmap-Kandidat. Vergessen Sie niemals alle kaskadierenden Änderungen. Der Wechsel zu einer spezialisierten Infrastruktur erfordert Änderungen in der gesamten Geschäfts- und Anwendungsarchitektur. Selbst wenn es sich nur um Änderungen im Team handelt, das die spezialisierte Hardware betreibt.
Wir verwenden oft eine Infrastruktursystemmodell um Änderungen zusammenzufassen. Systemmodelle bieten ausreichend Abstraktion für Planungs- und Ausführungsgespräche. Wir empfehlen die Verwendung von Scores und Arbeitspaketen zur Erläuterung von Änderungen. Weitere Informationen zur Verwendung von Scores finden Sie im Leitfaden zur Bewertung der Fähigkeiten der Unternehmensarchitektur.
Wir verwenden alle Komponenten der Architektur-Roadmap in TOGAF Phase E - Architektur-Roadmap.
Spezifikation der Anforderungen an die Kandidatentechnologiearchitektur
Erläutern Sie die Einschränkungen für Infrastrukturdesigner, -käufer und -implementierer. Erläutern Sie, wie Sie die Verbesserung bewerten werden.
Wir verwenden häufig Bewertungen und vereinfachte Aussagen zur Beschreibung von Anforderungen. Eine Anforderung kann ein Maß für die Automatisierung sein oder die Aussage, dass es sich bei der Infrastruktur um Public Cloud PaaS oder spezielle Hardware handelt. Diese Anforderungen dienen der Steuerung und Kontrolle eines Änderungsprojekts in TOGAF Phase G.
Welche Rolle spielt der Technologiearchitekt in Phase D?
Wir erwarten vom Technologiearchitekten die Leitung der TOGAF-Phase D und die Bereitstellung der Domänenarchitektur. Er muss Modelle entwickeln, die die Ursache des Mangels aufzeigen. Er muss seine Modelle anwenden, um zu zeigen, wie eine Änderung den Mangel behebt. Wir erwarten von ihm, dass er Stakeholder, Fachexperten und andere Domänenarchitekten durch die Kompromissanalyse führt.
Technologiearchitekten müssen eng mit Geschäftsarchitekten und Anwendungsarchitekten zusammenarbeiten. Die Technologiearchitektur weist in ihrem Bereich häufig Mängel auf. Auch die Beseitigung von Komplexität und Starrheit in der Technologiearchitektur erfordert in der Regel Änderungen in diesem Bereich.
Wir erwarten vom Technologiearchitekten, dass er sich an der Geschäftsarchitektur orientiert. Er muss die Betriebsmodell und die Kompetenz- und Automatisierungsattribute des Fähigkeitsmodell. Wir erwarten auch, dass sie verstehen, Anwendungsentwicklungsmodell, die Kompetenz- und Automatisierungsattribute aller Anwendungssystemmodell, und die Digitales Produktmodell.
>>> Zum Common springen Geschäftsarchitekturmodelle und gemeinsame Anwendungsarchitekturmodelle
>>> Springe zu Allgemein Technologiearchitekturmodelle
Enterprise-Architektur-Teams können ohne Technologiearchitekten nicht erfolgreich sein. Moderne digitale Unternehmen scheinen nur auf Software zu basieren. Sie basieren auf Infrastruktur. Ohne Infrastruktur passiert nichts. Schwache Technologieentscheidungen beeinträchtigen die geschäftliche Agilität und Wertschöpfung. Technologiearchitekten sind auf den Technologiebereich spezialisiert. Sie können ihre Arbeit nicht erledigen, ohne effektiv mit Geschäftsarchitekten, Daten-, Technologie- und Sicherheitsarchitekten.
Welche Rolle spielt der Enterprise Architect in Phase D?
Der Unternehmensarchitekt hat in TOGAF Phase D dieselbe Rolle. Er muss dort einspringen, wo ein Domänenarchitekt Unterstützung benötigt. Sei es bei der Entwicklung der Technologiearchitektur, der Interpretation anderer Domänen oder der Wertsicherung. Viele Technologiearchitekten erkennen die Auswirkungen auf die Geschäftsarchitektur nicht. Oder sie formulieren Anforderungen nicht so, dass der Sicherheitsarchitekt sie umsetzen kann.
Die wichtigste Aufgabe des Unternehmensarchitekten besteht darin, Grenzen zu überschreiten. Egal, ob es sich um Domänen-, Kompetenz- oder Autoritätsgrenzen handelt, der Unternehmensarchitekt muss sie überschreiten.
Technologiearchitekturmodelle, -tools und -techniken
Die TOGAF ADM-Phase D liefert die Informationssystemarchitektur. In dieser Phase werden die Technologie- und Datenarchitektur der Informationssysteme entwickelt. In TOGAF werden zunächst die benötigten Ansichten und Modelle festgelegt.
Die Anliegen der Stakeholder 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
- Infrastruktur-Servicemodell zerlegt das Infrastrukturportfolio in Blackboxen und konzentriert sich auf Ergebnisse und Eigenschaften des Dienstes
- Schnittstellenmodell beschreibt, wie Sie eine Verbindung zur Infrastruktur herstellen oder diese nutzen
- Lebenszyklusmodell identifiziert die erforderlichen Lebenszyklusattribute Ihres Infrastrukturportfolios
- Normenkatalog identifiziert die Beschaffungsstandards für Ihr Infrastrukturportfolio
- Physisches Infrastrukturmodell erklärt, welche reale Infrastruktur im Infrastrukturportfolio vorhanden ist
Technologiearchitekturmuster
Architekturmuster sind eine konsequente Herangehensweise an ein vorhersehbares Problem. Unsere Mustervorlage hebt die Vorhersehbares Problem, Ansatz, und die Harte Teile. Wenn wir ein Muster in Betracht ziehen, müssen wir den erforderlichen Arbeitsaufwand sowie die Einschränkungen und Beschränkungen bewerten.
Beispiele für Technologiearchitekturmuster
- Mehrschichtiges Infrastrukturmuster
Vorhersehbares Problem– Modularität, Wartbarkeit und Skalierbarkeit von Technologiesystemen
Ansatz-unterteilt die Infrastruktur in verschiedene Schichten, die jeweils für bestimmte Funktionen wie Präsentation, Anwendungslogik und Datenspeicherung verantwortlich sind. - Hochverfügbarkeit (HA) und Redundanzmuster
Vorhersehbares Problem—Systemverfügbarkeit, Fehlertoleranz und Wartbarkeit
Ansatz– Duplizieren Sie kritische Komponenten und Dienste. - Serverloses Architekturmuster
Vorhersehbares Problem– Modularität, Wartbarkeit und Skalierbarkeit von Technologiesystemen
Ansatz– Automatische Zuweisung und Skalierung von Infrastrukturressourcen als Reaktion auf Ereignisse
Technologiearchitekturmodelle
Die Entwicklung einer sinnvollen Technologiearchitektur erfordert mehrere Unternehmensarchitekturmodelle. Jeder Modelltyp erläutert einen anderen Aspekt des Infrastrukturportfolios. Die Technologiearchitektur von TOGAF Phase D erläutert die allgemeinen Schritte zur Entwicklung der Zielarchitektur. Verschiedene Modelltypen ermöglichen Ihnen unterschiedliche Betrachtungsweisen des Infrastrukturportfolios.
Mit einer 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:
- Öffentliche Cloud PaaS, können als punktuelle Infrastrukturdienste zusammengestellt werden. Einschränkungen und Limitationen der Interoperabilität erfordern die Auswahl in Anbieterbündeln
- Unternehmenssysteme, allgemein genutzte Infrastruktur. Typischerweise wird sie in umfassenden Systemen bereitgestellt, die eine Reihe von Funktionen enthalten. Unternehmenssysteme erfordern Arbeit, um sie in Infrastrukturdienste zu integrieren.
- Spezialsysteme zeichnen sich durch unterschiedliche Nischen aus. Typischerweise unterstützen spezialisierte Systeme einzigartige Anwendungsfälle. Beispiele hierfür sind luftfahrtzertifizierte Infrastruktur, erweiterte Schock- und Temperaturbereiche oder Quantencomputing
- Benutzerdefinierte Infrastruktur, die Sie für Ihr Unternehmen erstellt haben. In der Regel erfüllt eine benutzerdefinierte Lösung die individuellen Anforderungen Ihrer Geschäfts- oder Anwendungsarchitektur.
Infrastruktursystemmodell
Das Systemmodell abstrahiert die Infrastruktur, die zur Bereitstellung einer Funktion erforderlich ist. Technische Referenzarchitekturen basieren auf einem Systemmodell. Sie identifizieren die verschiedenen Merkmale der Infrastruktur.
Stellen Sie sich eine Anwendungsumgebung mit Anwendungsservern, Lastenausgleich und Speicher vor. Das Design Ihres Systemmodells schränkt Ihre Fähigkeit ein, Duplizierung, Starrheit und Komplexität zu erkennen.
Systemmodelle ermöglichen es Ihnen, Ihre Überlegungen auf Bereiche Ihrer Infrastruktur zu lenken, in denen Betriebskosten, Starrheit und Duplizierung angegangen werden müssen. Sie verlagern die Diskussion von bestimmten Varianten des Systems auf die Abwägung zwischen Auswirkungen auf andere Bereiche, Agilität, Kosten und Betrieb.
FEAF, OPAS und IndEA bieten alle Infrastruktursystemmodelle. Erforderlich für die Planung des Infrastrukturportfolios. Duplizierung und Spezialisierung erhöhen die Komplexität und die Kosten des Infrastrukturportfolios.
Infrastruktur-Servicemodell
Ein Infrastruktur-Servicemodell ist eine spezialisierte Version eines Infrastruktur-Systemmodells. Es fasst alles in einer Blackbox mit bekannten Attributen und Schnittstellen zusammen. Sie können kein Public Cloud PaaS durchführen, oder Private Cloud PaaS-Architektur ohne Servicemodell.
Ein Infrastruktur-Servicemodell ist für die Entwicklung des Infrastruktur-Providermodells und die Validierung des Ziels in einem Infrastruktur-Systemmodell von unschätzbarem Wert. Die Schnittstellen in Ihrem Servicemodell sollten alle in Ihrem Schnittstellenmodell klar identifiziert sein.
Unternehmensagilität erfordert ein gutes Infrastruktur-Servicemodell. Sie müssen in der Lage sein, die Hindernisse für Veränderungen zu erkennen und zu beseitigen.
Schnittstellenmodell
Ein Schnittstellenmodell beschreibt, wie Sie verschiedene Komponenten Ihrer Infrastruktur miteinander verbinden und wie Anwendungen und Daten auf die Infrastruktur zugreifen. Ohne ein Schnittstellenmodell ist die Entwicklung einer Private Cloud PaaS-Architektur nicht möglich. Jetzt können Sie Dienste von mehreren Public Cloud PaaS-Anbietern verbinden.
Sie verfolgen Grenzen zwischen Systemen. Sie müssen angeben, ob und wie eine Grenze überschritten werden kann. Technologiearchitekten versäumen es allzu oft, Grenzen zu definieren, die nicht überschritten werden können. Aus diesem Versäumnis resultieren meist starre und unveränderliche Infrastrukturen.
Das Schnittstellenmodell ist von entscheidender Bedeutung, um Unternehmensflexibilität zu ermöglichen, das Infrastrukturportfolio zu verwalten und die IT-Kosten zu senken.
Lebenszyklusmodell
Ein Lebenszyklusmodell identifiziert die Anforderungen, die in die Infrastrukturplanung einfließen, und die Realität, die sich aus der physischen Infrastruktur ergibt. Wir nutzen das Lebenszyklusmodell, um den Lebenszyklus zu identifizieren, den wir haben und benötigen. Vor Jahren entwickelten wir eine Kommunikationsarchitektur in einem bergigen Gebiet mit geschützter Wildnis. Diese Architektur hatte eine Reihe einzigartiger Lebenszyklusanforderungen, die das Design prägten. Sie beeinflusste auch die betrieblichen Anforderungen.
Normenkatalog
Zu oft gehen die Architekten, mit denen wir zusammenarbeiten, davon aus, dass ein Katalog mit Technologiestandards die Präferenzen für den Infrastrukturbetrieb in die Architektur einfließen lässt. Sie gehen davon aus, dass die anderen Domänen über die Technologiestandards informiert werden. Dies trifft jedoch erst zu, wenn die Stakeholder die Technologiearchitektur genehmigt haben. Solange Ihre Stakeholder die Architektur nicht genehmigen, ist keine Architektur-Governance möglich.
Der erste Nutzen eines Architekturstandardkatalogs besteht darin, nicht konforme Infrastrukturen zu identifizieren. Infrastrukturen, die Starrheit, Kosten, Komplexität und Mängel in die Basistechnologiearchitektur und alle anderen Bereiche bringen.
Ihr Normenkatalog wird die Infrastrukturbeschaffung vorantreiben. Wenn es kein effektives Infrastruktur-Servicemodell oder Infrastruktur-Schnittstellenmodell gibt, dient er anderen Domänen und Implementierern als Orientierung und Einschränkung.
Physisches Infrastrukturmodell
Ein physisches Modell beschreibt das tatsächliche Infrastrukturportfolio. Verwenden Sie stets die Begriffe kommerzieller Infrastrukturanbieter. Sie müssen es mit den anderen Technologiearchitekturmodellen verknüpfen, um das Ziel in die reale Welt zu übertragen.
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.
Technologiearchitekturtechniken
Wir verwenden eine breite Palette von Techniken, um unsere Geschäftsarchitektur zu entwickeln und zu kommunizieren.
- Technische Referenzarchitekturen
- UML ist in der modellgetriebenen Entwicklung allgegenwärtig. Wenn Sie in der Architektur arbeiten, um die Lösungsentwicklung zu unterstützen, sollten Sie ein Systemmodell und ein Schnittstellenmodell nach UML-Praktiken entwickeln.
- 4+1-Ansichten sind hilfreich, um die Auswirkungen des Ziels auf verschiedene Communities zu ermitteln. Die Entwicklung von 4+1-Modellen stellt sicher, dass Sie alle relevanten Änderungen berücksichtigen.
Technologiearchitekturmodelle, die auf den Zweck der Unternehmensarchitektur abgestimmt sind
Die Fragestellung, die Sie mit Ihrer Geschäftsarchitektur beantworten, bestimmt den Einsatz unterschiedlicher Geschäftsarchitekturmodelle. Beispielsweise wird bei einer Architektur zur Unterstützung des Portfolios häufig kein Wertschöpfungskettenmodell entwickelt. Stattdessen ist eine Wertschöpfungskette in der Regel eine übergeordnete Architektur und schränkt Ihre Freiheit ein.
| 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 | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Infrastruktursystemmodell | Regelmäßige Lieferung | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Infrastruktur-Servicemodell | Regelmäßige Lieferung | Wichtigstes Ergebnis | Wichtigstes Ergebnis & Überragende Architektur | Wichtigstes Ergebnis & Überragende Architektur |
| Schnittstellenmodell | Selten verwendet | Gelegentliche Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Wichtigstes Ergebnis | Wichtigstes Ergebnis & Überragende Architektur |
| Lebenszyklusmodell | Gelegentliche Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Wichtigstes Ergebnis
Angemessener Detaillierungsgrad mindert oft den Wert |
Wichtigstes Ergebnis & Überragende Architektur | Überlegene Architektur |
| Normenkatalog | Selten verwendet | Gelegentliche Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Wichtigstes Ergebnis & Überragende Architektur | Überlegene Architektur |
| Physisches Infrastrukturmodell | Selten verwendet | Gelegentliche Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Wichtigstes Ergebnis & Überragende Architektur | Wichtigstes Ergebnis & Überragende Architektur |
Einfluss von Anwendungsarchitekturmodellen auf Technologiearchitekturmodelle
| Anwendungsentwicklungsmodus | Systemmodell | Produktmodell | Integrationsmodell | Anwendungsservice | |
| Infrastrukturanbietermodell | Wichtige Eingabe | Wichtige Eingabe | Wichtige Eingabe | Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
| Infrastruktursystemmodell | Haupteingabe | Haupteingabe | Haupteingabe | Begrenzte Eingabe | Begrenzte Eingabe |
| Infrastruktur-Servicemodell | Haupteingabe | Haupteingabe | Haupteingabe | Bester Eingang
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
Bester Eingang
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
| Schnittstellenmodell | Haupteingabe | Haupteingabe | Bester Eingang
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
Bester Eingang
Ein direkter Zusammenhang ist schwer zu erkennen. Es lohnt sich, die Arbeit zu machen |
|
| Modell der physischen Infrastruktur | Eingang | Haupteingabe
Erfordert ein Providermodell |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzte Eingabe
Die Verknüpfungen 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 | Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
Wichtige Eingabe
Erfordert ein System- oder Funktionsmodell |
Begrenzte Eingabe | Begrenzte Eingabe |
| Infrastruktursystemmodell | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | Haupteingabe | Begrenzte Eingabe | Haupteingabe |
| Infrastruktur-Servicemodell | Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Bester Eingang
Ein direkter Zusammenhang ist schwer zu erkennen. Die Arbeit lohnt sich. |
Wird als Vollständigkeitstest verwendet | Haupteingabe
Ein direkter Zusammenhang ist schwer zu erkennen. Die Arbeit lohnt sich. |
Haupteingabe | |
| Schnittstellenmodell | Wichtiger Beitrag zur Existenz der Schnittstelle
Erfordert ein System- oder Funktionsmodell |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Wichtiger Beitrag zur Existenz der Schnittstelle
Erfordert ein System- oder Funktionsmodell |
Wichtiger Input zum Kerndesign | Wichtiger Input zum Kerndesign
Erfordert ein System- oder Funktionsmodell |
|||
| Modell der physischen Infrastruktur | Wichtiger Input zur Existenz von Infrastrukturstandorten
Erfordert ein Providermodell |
Wichtiger Input zur Existenz von Infrastrukturstandorten
Erfordert ein Providermodell |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Eingaben zum Kerndesign | Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist schwer zu erkennen |
Technologiearchitekturmodelle für Anwendungsfälle der Unternehmensarchitektur
Jeder Anwendungsfall für Unternehmensarchitektur geht es darum, effektive Veränderungen zu ermöglichen. Veränderungen gibt es in vielen Formen. Unsere Anwendungsfälle für Unternehmensarchitektur helfen bei der Beantwortung gängiger Fragen.
Der Anwendungsfall spielt keine Rolle. Die Technologiearchitekten verfolgen dasselbe Ziel: Sie helfen ihren Stakeholdern, bessere Entscheidungen zu treffen und erfolgreiche Veränderungsinitiativen zu leiten.
| Strategischer Wandel | Inkrementelle Änderung | Kosten senken | Qualität verbessern | Verbessern Sie die Unternehmensagilität | Minimierung des Technologierisikos | IT-Modernisierung | Digitale Transformation | Rationalisierung des Anwendungsportfolios | Akquisitionsintegration | |
| Infrastrukturanbietermodell | Sehr nützlich | 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 nützlich
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 | ||||
| Infrastruktur-Servicemodell | Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
| Lebenszyklusmodell | Sehr nützlich
Kritische Lücken und Einschränkungen |
Kritische Lücken und Einschränkungen | Sehr nützlich
Kritische Lücken und Einschränkungen |
Sehr nützlich
Kritische Lücken und Einschränkungen |
Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Sehr nützlich
Kritische Lücken und Einschränkungen |
Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen |
| Normenkatalogmodell | Sehr nützlich für Lücken und Einschränkungen | Sehr nützlich
Kritische Einschränkungen |
Sehr nützlich
Kritische Einschränkungen |
Sehr nützlich
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 von Prinzipien der Unternehmensarchitektur auf die Technologiearchitektur
Es gibt 7 Architekturprinzipien, die jeder Unternehmensarchitekt kennen sollte. Prinzipien sind übergeordnete Architektur und schränken Ihre Freiheit bei der Entwicklung von Architektur ein. Jedes Ihrer Architekturprinzipien wird die Entwicklung Ihrer Technologiearchitektur einschränken. Testen Sie Ihre Kandidatenarchitektur immer, ohne auf eine Ausrichtungserklärung zu achten. Beweisen Sie, dass Sie dem Wortlaut und dem Sinn der Architektur folgen. Sie wissen, dass das Prinzip richtig ist. In TOGAF ADM Phase D müssen Sie die Konformität der Technologiearchitektur nachweisen.
| Auswirkungen auf die Technologiearchitektur | |
| Spielen Sie nicht mit dem Erfolg | Versuchen Sie, Änderungen zu vermeiden. Ja, beseitigen Sie alle Änderungen, die nicht ausdrücklich gerechtfertigt sind |
| Fokus auf Exzellenz | Nutzen Sie die Fähigkeitsmodell und die Anwendungsentwicklungsmodell um sicherzustellen, dass die Technologie Unternehmensexzellenz ermöglicht.
Richten Sie sich nach dem Digitales Produktmodell. Produkt und Service werden direkt an den Kunden geliefert und unterliegen sehr unterschiedlichen Mindeststandards. |
| Warum nicht eins? | Nutzen Sie die Anwendungsentwicklungsmodell und Infrastruktur-Servicemodell, um herauszufinden, wo Duplizierung verboten ist. Dann beseitigen Sie sie. |
| 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. |
| Problemlose Benutzererfahrung | Differenzierungs-, Transformations- und Effizienzprogramme erfordern Kostenmodelle, die Produktivität liefern. Meistens geht es darum, Produktivitätseinbußen zu beseitigen, nicht sie zu verbessern. |
| Selbstbedienung | Die Verwaltung und Bereitstellung der Infrastruktur ist kostspielig, wenn sie nicht im Self-Service-Verfahren erfolgt. Alles, was den Self-Service blockiert, beeinträchtigt Produktivität und Veränderung. |
Wie passt TOGAF Phase D zur agilen Entwicklung?
Infrastruktur ermöglicht oder schwächt den potenziellen Nutzen agiler Entwicklung. Wenn Ihr Unternehmen starke agile Entwicklungskapazitäten benötigt, müssen Sie Ihre Infrastruktur auf diese Kapazitäten ausrichten. Die Anwendungsentwicklungsmodell wird den Umfang ermitteln und feststellen, ob eine agile Entwicklung hilfreich oder kritisch ist.
Verlassen Sie sich auf Ihr Infrastrukturanbietermodell und Ihr Infrastrukturdienstmodell, um die Technologiearchitektur an Ihre agilen Anforderungen anzupassen.
Keiner der vier Bereiche, in denen sich Unternehmensarchitektur mit agiler Entwicklung überschneidet, stimmt immer mit der Technologiearchitektur überein. Die direkte Ausrichtung ergibt sich aus der Produktmodell. Achten Sie neben der direkten Ausrichtung immer auf die Infrastrukturdienste.
Wie ermöglicht TOGAF Phase D Unternehmensagilität?
Wie wir wissen, hat Unternehmensagilität nichts damit zu tun, wie Sie Software schreiben. Unternehmensagilität bedeutet die Fähigkeit Ihres Unternehmens, auf unerwartete Bedrohungen und Chancen zu reagieren. So einfach ist das. Können Sie auf das Unerwartete reagieren?
Die Unternehmensagilitätsmodell hat fünf Punkte:
- Wachsamkeit – Können Sie Chancen und Bedrohungen erkennen?
- Zugänglichkeit – Können Sie rechtzeitig auf relevante Informationen zugreifen, um zu antworten?
- Entschlossenheit – Können Sie anhand der verfügbaren Informationen eine Entscheidung treffen?
- Schnelligkeit – Können Sie Ihre Entscheidungen in der verfügbaren Zeit umsetzen?
- Flexibilität – Was tun Sie, um Handlungshürden abzubauen?
Die Unternehmensarchitektur arbeitet hauptsächlich an #5 – Flexibilität. Suchen Sie nach Bereichen, die Starrheit erzeugen, und beseitigen Sie diese. Bei unserer Infrastruktur-Lebenszyklusplanung rechnen wir jeden Nutzen ab, der nicht innerhalb von zwei Jahren eintritt. Dies stellt eine erhebliche Belastung für die Technologiearchitektur dar und unterstreicht die Attraktivität von Public Cloud PaaS.
Abschließende Gedanken zu TOGAF ADM Phase D
Erfolgreich Unternehmensarchitekturteams Verschwenden Sie nicht Ihre Zeit als Technologiearchitekten mit der Entwicklung und Umsetzung der Infrastruktur. Das verwechselt einen Technologiearchitekten mit einem Lösungsarchitekten. Es schadet der Unternehmensarchitektur.
Technologiearchitekten müssen die Richtlinien und Leitplanken für die Personen entwickeln, die das Infrastrukturportfolio des Unternehmens als Lösungsarchitekten entwerfen, implementieren und möglicherweise erfinden. Kurz gesagt: Ein Enterprise-Technologiearchitekt ist kein Lösungsarchitekt noch ein Technologiespezialist, genannt Technologiearchitekt. Obwohl diese Rollen wichtig sind, tragen sie nicht zu einem EA-Team bei.
In TOGAF ADM Phase D entwickeln Sie einen der vier grundlegenden Bereiche der Unternehmensarchitektur. TOGAF macht deutlich, dass Sie diese Architektur gemeinsam mit den anderen Bereichen entwickeln. Der Unterschied besteht darin, dass die Technologiearchitektur oft Veränderungen außerhalb der meisten Veränderungsinitiativen vorantreibt. Ihre Infrastruktur ist langlebiges Kapitalvermögen und entwickelt sich in einem ganz anderen Tempo. Die Infrastruktur muss vor dem Bedarf vorhanden sein. Die Infrastruktur muss regelmäßig aktualisiert werden.
Erfolgreiche Technologiearchitekten leiten und beschränken:
- Der Enterprise Architect Domain Architects zur Kunst des Möglichen
- Infrastrukturplaner über Erfolgskriterien
- Lösungsarchitekten und spezialisierte Technologiearchitekten zu Beurteilungskriterien, Erfolgskriterien und Prioritäten
Hervorragende Technologiearchitekten ermöglichen Unternehmensagilität und agile Softwareentwicklung. Sie konzentrieren sich auf die Balance zwischen Effizienz und Agilität.
TOGAF ADM Phase D entwickelt die Technologiearchitektur. Technologiearchitektur ist die Grundlage aller modernen digitalen Unternehmen. Nutzen Sie TOGAF Phase D, um knappe Veränderungsressourcen auf Effizienz und Agilität zu konzentrieren. So generieren Sie nachhaltigen Unternehmenswert durch Infrastrukturinvestitionen.
