Die TOGAF-Standard<\/a> ist sich \u00fcber zwei Dinge im Klaren. Erstens unterst\u00fctzt die Technologiearchitektur direkt die Informationssystemarchitektur (Anwendung und Daten), um die Gesch\u00e4ftsarchitektur zu erm\u00f6glichen. Zweitens entwickeln wir Dom\u00e4nenarchitekturen nicht sequentiell.<\/p>\n Die digitale Transformation erfordert die richtige IT-Architektur<\/a>. Eine gute Technologiearchitektur ist erforderlich, da jede Architekturdom\u00e4ne<\/a> erm\u00f6glicht, liefert oder blockiert Ergebnisse in anderen Bereichen.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tEntdecken Sie die TOGAF-Zertifizierungsschulung\n\t\t\t<\/a>\n\t Auf einen Blick<\/p>\n Verwenden Sie die TOGAF ADM<\/a> um das notwendige Wissen f\u00fcr die optimale Technologiearchitektur zu entwickeln. Jede ADM-Phase liefert die notwendigen Inputs und Aktivit\u00e4ten, 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<\/a>. Es eignet sich f\u00fcr jeden Detaillierungsgrad. Wie alle logischen Modelle muss es erweitert werden, um verschiedene Detailebenen abzudecken \u2013 Strategie, Portfolio, Projekt und L\u00f6sungsbereitstellung.<\/p>\n Wenn Sie eine \u00dcbersicht \u00fcber das TOGAF ADM<\/a>, lesen Sie bitte die Erl\u00e4uterung der TOGAF ADM-Phasen<\/a>.<\/p>\n In TOGAF Phase D, Technologiearchitekten<\/a> Sie leiten die Entwicklung der Technologiearchitektur. Dies erreichen sie, indem sie die Informationssystemarchitektur erm\u00f6glichen \u2013 nicht indem sie Anweisungen befolgen und Erwartungen erf\u00fcllen. Technologiearchitekten verstehen, dass eine langlebige Infrastruktur ihre Umgebung bereitstellt. Sie m\u00fcssen vorausschauend planen und vorbereitet sein. Sie m\u00fcssen sicherstellen, dass kurzfristige Hoffnungen nicht zu langfristigen Problemen f\u00fchren.<\/p>\n Wenn wir Entwicklung von Enterprise-Architecture-Teams<\/a>, Wir erl\u00e4utern den Architekten zwei zentrale Fakten zur TOGAF-Phase D \u2013 Technologiearchitektur. Erstens, bis Sie eine Anwendungsentwicklungsmodell,<\/a> Sie k\u00f6nnen 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\u00e4nkt f\u00fchlen.<\/p>\n In einem modernen, digital transformierten Unternehmen interagieren alle Architekturbereiche. Entscheidungen in einem Bereich erm\u00f6glichen, liefern oder verhindern Ergebnisse in einem anderen Bereich. Die meisten Gesch\u00e4ftsziele h\u00e4ngen ab von richtige IT-Architektur<\/a>. Wir k\u00f6nnen die richtige Technologiearchitektur nur entwickeln, wenn wir \u00fcber eine solide Anwendungsarchitektur verf\u00fcgen.<\/p>\n Die wahre Schwierigkeit der Technologiearchitektur liegt in der Langlebigkeit der Infrastruktur. Ohne eine Technologiearchitektur, die Einschr\u00e4nkungen bietet, f\u00fchren taktische Infrastrukturentscheidungen immer zu schlechteren Unternehmensergebnissen.<\/p>\n Es besteht eine direkte Verbindung zwischen guter Technologiearchitektur und modernem PaaS bzw. den meisten Cloud-Architekturen. Beide identifizieren Infrastrukturdienste. Beide erm\u00f6glichen und beschr\u00e4nken Daten- und Anwendungsauswahl. Beide isolieren Anwendungen von der zugrunde liegenden Infrastruktur.<\/p>\n Das TOGAF ADM beginnt mit Phase A<\/a>. Es liefert eine vereinfachte Zielarchitektur \u2013 die Architekturvision<\/a>. Die Architekturvision sollte besser Gesch\u00e4ft, Anwendung, Daten, und Technologiedom\u00e4nen<\/em>. Zu oft sehen wir, wie Leute vorgeben, eine Architekturvision zu entwickeln. Sie treten mit einer Fantasie \u00fcber Gesch\u00e4ftsabl\u00e4ufe auf und betrachten Phase D als eine \u00dcbung zur Umsetzung ihrer Fantasie. Echte Unternehmensarchitektur hat eine vereinfachte Zielarchitektur entwickelt. Die Aktivit\u00e4ten in Phase D entwickeln die Technologiearchitekturdom\u00e4nen weiter. Erfolg erfordert:<\/p>\n Das zentrale Ergebnis von Phase D ist die Technologiearchitektur. Technologiearchitekten arbeiten mit den anderen Dom\u00e4nenarchitekten zusammen. Es ist mit einem Austausch von W\u00fcnschen und Einschr\u00e4nkungen zu rechnen. Jede Architekturentwicklung erfordert die optimale L\u00f6sung f\u00fcr das Unternehmen. Die beste L\u00f6sung ber\u00fccksichtigt Einschr\u00e4nkungen und funktioniert in allen Dom\u00e4nen.<\/p>\n Der Sinn des TOGAF ADM besteht darin, m\u00f6gliche Ver\u00e4nderungen zu untersuchen. Ver\u00e4nderungen werden in Bezug auf Arbeit, Wert und Risiko<\/a>. \u00c4nderungen, die ausgew\u00e4hlt oder gel\u00f6scht werden. Der Satz von \u00c4nderungen erstellt die Zielarchitektur und die Architektur-Roadmap.<\/p>\n Technologiearchitekten arbeiten mit Infrastruktur. Infrastruktur ist der am schwierigsten zu ver\u00e4ndernde Teil einer Organisation. Technologiearchitekten m\u00fcssen jede m\u00f6gliche \u00c4nderung hinterfragen und nach Auswegen Ausschau halten. Der kosteng\u00fcnstigste Ausweg ist die Architekturentwicklung. Stoppen Sie schlechte Ideen fr\u00fchzeitig. Die Beseitigung schlechter Ideen spart Geld und erm\u00f6glicht erfolgreiche Ver\u00e4nderungen. Die Notwendigkeit, bei der Infrastruktur vorausschauend zu denken, erfordert von den Technologiearchitekten, Infrastrukturdesigner und -implementierer einzuschr\u00e4nken.<\/p>\n \u2018'\u2018Das Gesch\u00e4ft<\/em>\u2018Das Unternehmen ist so aufgestellt. Das war es schon immer. Moderne digitale Unternehmen k\u00f6nnen nicht mehr allein auf die Arbeitskraft ihrer Mitarbeiter setzen, um Einschr\u00e4nkungen in Anwendungen und Infrastruktur zu \u00fcberwinden. Solche Einschr\u00e4nkungen verhindern die Agilit\u00e4t des Unternehmens und bringen die digitale Transformation zum Erliegen.<\/p>\n Sie haben das TOGAF ADM mit der Herausforderung entwickelt, die Aufarbeitung zu unterteilen und die Zusammenarbeit zu f\u00f6rdern. Leider zeigt das klassische TOGAF ADM-Diagramm den Fluss der notwendigen Informationen. Bitte interpretieren Sie das Diagramm nicht als Wasserfall.<\/p>\n Wer behauptet, Unternehmensarchitektur k\u00f6nne sequenziell entwickelt werden, irrt sich. Wer r\u00e4t, das gesamte Unternehmen zu entwerfen, irrt sich ebenfalls. Komplexit\u00e4t und Spezialisierung erfordern Dom\u00e4nen. Ihre Entwicklung beginnt und verl\u00e4uft gemeinsam. Sie m\u00fcssen einen agilen Ansatz verfolgen, der gerade genug Zeit bietet, um die kaskadierenden Einschr\u00e4nkungen zu testen. TOGAF nennt dies Iteration.<\/p>\n Architektonische Entscheidungen<\/a> wird mehrere \u00fcberqueren Architekturdom\u00e4nen<\/a> erfordert die Verwendung Architekturalternativen<\/a>.<\/p>\n Technologiearchitektur<\/a> ist einer der vier grundlegenden Bereiche der Unternehmensarchitektur. Eine Technologiearchitektur beschreibt Ihr komplettes Infrastrukturportfolio und gibt Ihnen Aufschluss dar\u00fcber, 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.<\/p>\n Wir garantieren, dass Ihre aktuelle Technologiearchitektur nicht darauf abgestimmt ist. Wir sind \u00fcberzeugt, dass Ihre Infrastrukturplanung keine solide Grundlage f\u00fcr Ihre Ausgangssituation bietet. Anwendungsarchitektur<\/a> oder Gesch\u00e4ftsarchitektur.<\/p>\n Wenn Sie \u00fcber eine Technologiearchitektur verf\u00fcgen, verf\u00fcgen Sie \u00fcber die Infrastrukturdienste, die Ihre Anwendungen ben\u00f6tigen. Sie verf\u00fcgen \u00fcber eine Reihe von Richtlinien und Einschr\u00e4nkungen<\/a> f\u00fcr die Gestaltung und den Betrieb Ihrer Infrastruktur. Sie verf\u00fcgen \u00fcber eine Technologie-Roadmap, die Ihre Stakeholder verstehen.<\/p>\n Um die Technologiearchitektur, ihre Dienste, Richtlinien und Einschr\u00e4nkungen zu entwickeln, muss der Technologiearchitekt eng mit seinen Kollegen und den Stakeholdern zusammenarbeiten. Sie m\u00fcssen untersuchen, wie unterschiedliche Infrastrukturoptionen Gesch\u00e4fts- und Softwareentscheidungen erm\u00f6glichen oder behindern. Dabei gilt es zu analysieren, wie die verschiedenen Optionen die Ziele der Organisation unterst\u00fctzen und einschr\u00e4nken. Potenzielle \u00c4nderungen, die zu wenig Nutzen bringen, zu viel Aufwand erfordern oder mit zu gro\u00dfer Unsicherheit behaftet sind, sollten verworfen werden. Gute Architektur-Roadmaps beinhalten notwendige \u00c4nderungen und minimieren Risiken.<\/p>\n Die Technologiearchitektur hilft bei der Beantwortung der folgenden Fragen:<\/p>\n Wir sehen fast keinen Unterschied zwischen gutem PaaS oder gutem Private Cloud-Architektur<\/a>, und eine gute Technologiearchitektur. Die Kernarbeitsprodukte, ein Systemmodell<\/a> und Servicemodell<\/a>, sind gleich. Der Unterschied besteht darin, dass Sie sich bei Verwendung von PaaS oder Public Cloud keine Gedanken \u00fcber die zugrunde liegende Infrastruktur machen m\u00fcssen.<\/p>\n 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\u00fcr diese Dienste spezifiziert. Wir vermuten, dass Ihre Arbeit problemlos in einen Public Cloud PaaS-Servicekatalog \u00fcbertragen werden kann.<\/p>\n TOGAF 8 forderte von Technologie-Services die Abstraktion detaillierter Infrastrukturen, um Portabilit\u00e4t zu erm\u00f6glichen, die einzelnen \u2018Illities\u2019 zu verwalten und Infrastrukturlebenszyklen zu unterst\u00fctzen. Aus demselben Grund nutzen Kunden aller Public-Cloud-PaaS-Anbieter diese Dienste. H\u00e4tten wir alle eine gute Technologiearchitektur umgesetzt, h\u00e4tten wir die Sackgasse unbeweglicher Anwendungen, nicht bereitgestellter \u2018Illities\u2019 und technischer Schulden vermeiden k\u00f6nnen.<\/p>\n >>> Springen zu Die Grundlagen der Private-Cloud-Architektur<\/a><\/p>\n Der TOGAF-Standard nennt es Technologiearchitektur. Unsere Unternehmensarchitektur-Beratungspraxis<\/a> nutzt in der Regel Infrastruktur. Viele andere fordern eine IT-Architektur. Bem\u00fchungen, eine klare, universelle Definition zu entwickeln, scheitern regelm\u00e4\u00dfig. Wir raten dringend, sich auf den Zweck statt auf die Definition zu konzentrieren.<\/p>\n Die Trennung zwischen den Architekturbereichen hilft uns, die richtigen F\u00e4higkeiten und die richtigen Gespr\u00e4che zusammenzubringen. Durch die Ber\u00fccksichtigung dieses Zwecks bleibt der Fokus auf der Entwicklung einer n\u00fctzlichen Architektur.<\/p>\n Wer \u00fcber die Definition nachdenkt, landet regelm\u00e4\u00dfig in sinnlosen Diskussionen. Handelt es sich bei dem KI-Chatbot um eine Anwendung, KI oder ein Gesch\u00e4ft? Ist E-Mail eine Anwendung oder Infrastruktur? Wie w\u00e4re es mit Gesichtserkennung f\u00fcr die Zugangskontrolle? Die M\u00f6glichkeiten sind endlos.<\/p>\n Alle Dom\u00e4nen der Unternehmensarchitektur gehen ineinander \u00fcber. Zusammen decken Dom\u00e4nen die gesamte Unternehmensarchitektur ab. Wir erstellen eine Dom\u00e4ne, damit ein spezialisierter Architekt Techniken und F\u00e4higkeiten nutzen kann. St\u00e4ndig entstehen neue Dom\u00e4nen der Unternehmensarchitektur<\/a>. Die meisten werden absorbiert in eine\u00a0klassische Unternehmensarchitekturdom\u00e4ne<\/a>\u00a0wenn sie zum Mainstream werden.<\/p>\n Unser Rat: Machen Sie sich keine Gedanken dar\u00fcber, was richtig ist. Konzentrieren Sie sich stattdessen darauf, zu verstehen, was Ihr Gegen\u00fcber meint. Seien Sie sich stets bewusst, was Ihre Zuh\u00f6rer von Ihnen annehmen. \u00dcbernehmen Sie die Verantwortung f\u00fcr Ihr Verst\u00e4ndnis und passen Sie Ihre Ausdrucksweise entsprechend an.<\/p>\n 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\u00e4gen 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.<\/p>\n Wir konzentrieren uns bei Enterprise-Architekten auf das Zusammenspiel aller Architekturbereiche. In vielen Teams gibt es Datenarchitekten, Anwendungsarchitekten, Sicherheitsarchitekten, Gesch\u00e4ftsarchitekten und Technologiearchitekten. Sie werden entweder nach ihrer Rolle oder mit der allgemeinen Bezeichnung \u201eEnterprise-Architekt\u201c bezeichnet.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tLaden Sie den Leitfaden f\u00fcr die Unternehmensarchitektur herunter\n\t\t\t<\/a>\n\t\t\t\t Ein zentrales Ergebnis von Phase D ist eine Technologiearchitektur. Diese ist ein Teil der gesamten Unternehmensarchitektur. Auf Umwegen ergeben sich f\u00fcr TOGAF ADM Phase D f\u00fcnf n\u00fctzliche Ergebnisse:<\/p>\n Denken Sie immer daran, dass Sie die Organisation verbessern wollen. Verbesserung erfordert Ver\u00e4nderung. Ver\u00e4nderung schafft Mehrwert. Wert und Kosten von Ver\u00e4nderungen sind messbar. Unsicherheit mindert immer den potenziellen Wert. Ist der Erfolg ungewiss, steigen die Kosten exponentiell. Schon geringe Unsicherheiten k\u00f6nnen Erwartetes ausschlie\u00dfen.<\/p>\n Wenn wir von Technologiearchitektur sprechen, beziehen wir uns meist auf die Modelle und Architekturspezifikationen. Verschiedene Modelle erkl\u00e4ren unterschiedliche Aspekte der gesamten Infrastruktur. Zusammen bilden die Modelle und die erforderlichen \u00c4nderungen die Technologiearchitektur.<\/p>\n Bei der Betrachtung verschiedener Modelltypen ist zu beachten, dass dieselben Begriffe oft unterschiedlich verwendet werden. Wir m\u00f6chten betonen, dass Sie sich nicht zu sehr um die Bezeichnung des Modells k\u00fcmmern sollten. Was Sie als funktionales Dekompositionsmodell bezeichnen, wird von anderen als Service bezeichnet. Unsere Beratung im Bereich Unternehmensarchitektur konzentriert sich auf den Zweck, nicht auf die Bezeichnung des Modells. Sie k\u00f6nnen es funktionales Dekompositionsmodell, Systemmodell oder Servicemodell nennen. Uns interessiert allein der Zweck des Modells \u2013 was m\u00f6chten Sie lernen, und erkl\u00e4rt Ihr Modell effektiv, wie dieser Aspekt der realen Arbeit funktioniert?<\/p>\n Alle TOGAF ADM-Phasen bieten die n\u00f6tigen Informationen und Aktivit\u00e4ten, um das ben\u00f6tigte Wissen zu entwickeln. Das Ergebnis von Phase D ist die Entwicklung einer geeigneten Technologiearchitektur.<\/p>\nTOGAF ADM Phase D \u2013 Entwicklung der Technologiearchitektur<\/h2>\n
\n
\n
\n
TOGAF ADM-\u00dcbersicht<\/a><\/h2>\n
Was ist TOGAF Phase D?<\/h2>\n
Was ist das Ziel von TOGAF ADM Phase D?<\/h3>\n
\n
Interaktion mit TOGAF Phase B<\/a>, Phase C<\/a>, und Phase E<\/a><\/h3>\n
Was ist Technologiearchitektur?<\/h2>\n
Wof\u00fcr wird eine Technologiearchitektur verwendet?<\/h3>\n
\n
Technologiearchitektur vs. Cloud-Architektur<\/h2>\n
Nennen wir es Technologiearchitektur, Infrastrukturarchitektur oder IT-Architektur?<\/h2>\n
Was ist der Unterschied zwischen einem Enterprise-Architekten und einem IT-Architekten?<\/a><\/h2>\n
![\"TOGAF](\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_321372600.jpeg\" "\\"TOGAF")
\n\tTOGAF ADM Phase D \u2013 Ergebnisse der Technologiearchitektur<\/h2>\n
\n
Abschluss der Phase D der Technologiearchitektur<\/h2>\n
![\"Technologiearchitektur\"](\"https:\/\/conexiam.com\/wp-content\/uploads\/2022\/08\/AdobeStock_300597970.jpeg\" "\\"Technologiearchitektur\\"")
\n\t\n