TOGAF ADM Phase C – Entwicklung der Anwendungsarchitektur
Auf einen Blick
- TOGAF Phase C in Aktion
- Was ist Anwendungsarchitektur?
- Welche Rolle spielt der Unternehmensarchitekt in Phase C?
- Was ist die Rolle des Anwendungsarchitekten?
- Welche Rolle spielt der Sicherheitsarchitekt in der Anwendungsarchitektur?
- Welche Rolle spielt das EA-Team in der Anwendungsarchitektur?
Grundlegendes Wissen zu Phase C
Abschließende Gedanken zu TOGAF ADM Phase C – Anwendungsarchitektur
TOGAF ADM-Übersicht
Die TOGAF ADM ist ein logischer Ansatz zur Wissensgenerierung. Wissen, das zur Entwicklung eines Unternehmensarchitektur, die effektive Veränderungen steuert. Dann Wissen, um sicherzustellen, dass der erwartete Wert erreicht wird.
Das TOGAF ADM ist in Phasen unterteilt. Jede Phase konzentriert sich auf die Schaffung von Wissen, das für Folgendes verwendet wird:
- Wählen Sie den Weg nach vorne und das Ziel
- durchführen Umsetzungs-Governance
- Bewerten Sie die weitere Reise und korrigieren Sie den Kurs
Was ist TOGAF Phase C?
Phase C treibt das Konzept weiter voran Architekturdomänen. In dieser Phase werden die Anwendungsarchitektur und die Datenarchitektur entwickelt. Formal betrachtet, behandelt Phase C die Domäne „Datenarchitektur“ und die Anwendungsarchitekturdomäne sind individuell.
Wie Phase B baut auch Phase C auf der Architekturvision auf. Es gibt jedoch einen Unterschied: Phase C hat die zusätzliche Verpflichtung, die Geschäftsarchitektur zu ermöglichen. Dabei geht es nicht darum, die Geschäftsarchitektur als Anforderung zu behandeln, sondern sicherzustellen, dass die sich entwickelnden Gesamtziele zusammenpassen.
Änderungen in einer Domäne führen zu Einschränkungen und Anforderungen in anderen Domänen. Ziel ist es, die besten Änderungen für alle Domänen zu finden.
Mithilfe der Schritte der Phase C entwickeln Architekten folgende Kenntnisse:
- welche Referenzarchitektur die Architekturentwicklung beschleunigen wird
- welche Standpunkte relevante Analysen für die Stakeholder ermöglichen, um zwischen Architekturalternativen zu wählen
- Welche Anwendungsarchitekturmodelle und Datenmodelle helfen, die Ursache des Mangels zu finden und welche Änderungen zu dessen Behebung erforderlich sind?
- wo Änderungen in der Anwendungsarchitektur Veränderungen in anderen Bereichen bewirken
- wo Änderungen in anderen Domänen Änderungen in der Anwendungsarchitektur bewirken
Es werden folgende zentrale Werksprodukte erstellt:
- Ansichten, die die Architektur der Kandidaten-Informationssysteme im Hinblick auf die Anliegen der Stakeholder analysieren
- dass eine aktuelle und eine mögliche Zielanwendungsarchitektur
- Lücken in der Anwendungsarchitektur
- Kandidaten für Arbeitsprodukte, die das Geschäft verändern
In Phase C stehen Aspekte wie Anwendungsdesign, Datenfluss, Integration, Entwicklungsansatz, Eigenentwicklung oder Kauf sowie Änderungsplanung im Mittelpunkt. Eine sorgfältige Bewertung und ein gutes Verständnis dieser Phase sind entscheidend.
Was ist TOGAF Phase C?
In TOGAF Phase C erstellen Sie die Anwendungsarchitektur. Anwendungsarchitekten leiten die Entwicklung Ihrer Anwendungsarchitektur. Die architektonische Entscheidungen Die in Phase C für die Anwendungsarchitektur getroffenen Entscheidungen interagieren mit den Entscheidungen, die in jedem Domäne der Unternehmensarchitektur.
Phase C in Aktion
Die Anwendungsarchitektur hilft bei der Beantwortung der folgenden Fragen:
- Wie das Anwendungsportfolio Wertschöpfung ermöglicht – Anwendungsentwicklungsmodell
- Wo Kosten in das IT-Portfolio einfließen - Funktionsmodell
- Wo Starrheit in das IT-Portfolio eingebracht wird - Integrationsmodell
- Wie das Unternehmen läuft – Systemmodell
- Für die Bereitstellung des Produkts oder der Dienstleistung erforderliche Systeme – Produktmodell
- Die Dinge, die eine Organisation können muss - Funktionsmodell
- Der Informationsfluss, der für die Durchführung der Aktivitäten eines Unternehmens erforderlich ist - Integrationsmodell
- Die Gesamtheit der Aktivitäten eines Unternehmens, typischerweise gruppiert, um zu zeigen, wie sie zueinander in Beziehung stehen – Servicemodell
- Was das Softwareportfolio ist – Physikalisches Modell
Denken Sie immer daran, dass Sie die Organisation verbessern möchten. Verbesserung erfordert Veränderung und schafft Mehrwert. Wert und Kosten von Veränderungen sind messbar. Unsicherheit mindert immer den potenziellen Wert. Unsicherheit erhöht immer die Kosten. Wir betrachten Unsicherheit als geometrische Auswirkung. Schon geringe Unsicherheit mindert den potenziellen Wert erheblich.
Bedenken Sie beim Lesen, dass dieselben Begriffe häufig verwendet werden. Achten Sie auf den Zweck des Modells und lassen Sie sich nicht von einer anderen Bezeichnung irritieren. Was Sie beispielsweise als Funktionsmodell bezeichnen, wird von anderen als Service bezeichnet. In unserem Unternehmensarchitekturberatung, wir konzentrieren uns immer darauf, was wir verstehen wollen, und nicht darauf, wie das Modell heißt.
Verschiedene Modelle erklären unterschiedliche Aspekte des Unternehmens. Zusammen bilden die Modelle und die erforderlichen Änderungen die Anwendungsarchitektur.
Was ist Anwendungsarchitektur?
Eine Anwendungsarchitektur beschreibt Ihr komplettes Softwareportfolio und gibt Ihnen an, wann Sie kaufen, wann Sie SaaS nutzen und wann Sie entwickeln sollten. Sie zeigt Ihnen, wo Sie Grenzen zwischen Systemen setzen sollten. Sie zeigt Ihnen, wie Sie Ihren Software-Lebenszyklus angehen.
Wir garantieren, dass Ihre aktuelle Anwendungsarchitektur nicht mit Ihrer Geschäftsarchitektur übereinstimmt. Eine Anwendungsarchitektur erfordert eine Geschäftsarchitektur. Die Entwicklung der Geschäftsarchitektur erfordert, dass Anwendungsarchitekten mit den Stakeholdern zusammenarbeiten.
Gemeinsam mit den Stakeholdern und dem Business-Architekten erkundet der Anwendungsarchitekt, wie Softwareentscheidungen die Unternehmensziele unterstützen und einschränken. Wir prüfen mögliche Verbesserungen, um die unmittelbaren und mittelfristigen Auswirkungen zu verstehen. Gemeinsam werden potenzielle Änderungen, die zu wenig bringen, zu viel Aufwand erfordern oder zu viele Unsicherheiten bergen, aus der Architektur-Roadmap gestrichen.
Wenn wir Entwicklung von Enterprise-Architecture-Teams, sagen wir dem Unternehmensarchitekten zwei zentrale Fakten zu TOGAF Phase C - Anwendungsarchitektur. Erstens, bis Sie eine Anwendungsentwicklungsmodell, Sie können nicht weitermachen. Solange Sie nicht wissen, wie Ihre Anwendungsauswahl Ihre Geschäftsarchitektur ermöglicht und einschränkt, sind die Details Ihrer Anwendungen sinnlos. Zweitens: Wenn sie glauben, dass sie sich in die Anwendungsfunktionalität und -integration stürzen müssen, werden sie immer eine minderwertige Anwendungsarchitektur entwickeln.
In einer modernen digital transformiertes Unternehmen, alle Architekturdomänen interagieren. Entscheidungen in einer Domäne ermöglichen, liefern oder blockieren Ergebnisse in einer anderen Domäne. Die meisten Geschäftsziele hängen ab von richtige IT-Architektur. Ironischerweise können wir die richtige Anwendungsarchitektur nur entwickeln, wenn wir über eine solide Geschäftsarchitektur verfügen.
Welche Rolle spielt der Enterprise Architect in Phase C?
In TOGAF Phase C besteht die Aufgabe des Unternehmensarchitekten darin, den gesamten Wert zu schützen. Abhängig von den Fähigkeiten der Domänenarchitekten muss der Unternehmensarchitekt einspringen. Beispielsweise erkennt ein Anwendungsarchitekt möglicherweise nicht die Auswirkungen von Änderungen in der Geschäftsarchitektur. Oder er formuliert eine Anforderung nicht so, dass der Sicherheitsarchitekt darauf reagieren 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.
Welche Rolle spielt der Anwendungsarchitekt in Phase C?
In TOGAF Phase C erwartet der Anwendungsarchitekt die Bereitstellung der Domänenarchitektur. Dazu müssen Modelle entwickelt werden, die die Ursache der Mängel und deren Behebung aufzeigen. Der Anwendungsarchitekt führt eine Kompromissanalyse mit den Stakeholdern durch, um die Zielarchitektur zu bestimmen.
Der Anwendungsarchitekt muss mit den anderen Domänenarchitekten zusammenarbeiten.
Schlüssel der Geschäftsarchitektur. Kennen und verstehen Sie die Betriebsmodell und die Kompetenz- und Automatisierungsattribute des Fähigkeitsmodell.
Welche Rolle spielt der Sicherheitsarchitekt in Phase C?
In TOGAF Phase C erwartet der Anwendungsarchitekt die Bereitstellung der Domänenarchitektur. Dazu müssen Modelle entwickelt werden, die die Ursache der Mängel und deren Behebung aufzeigen. Der Anwendungsarchitekt führt eine Kompromissanalyse mit den Stakeholdern durch, um die Zielarchitektur zu bestimmen.
Der Anwendungsarchitekt muss mit den anderen Domänenarchitekten zusammenarbeiten.
Schlüssel der Geschäftsarchitektur. Kennen und verstehen Sie die Betriebsmodell und die Kompetenz- und Automatisierungsattribute des Fähigkeitsmodell.
Bedenken Sie, dass Mängel in einem Bereich häufig in einem anderen behoben werden und dass Änderungen in einem Bereich häufig Kosten und Änderungen in einem anderen Bereich nach sich ziehen.
Welche Rolle spielt das EA-Team in der Anwendungsarchitektur?
Bedenken Sie, dass Mängel in einem Bereich häufig in einem anderen behoben werden und dass Änderungen in einem Bereich häufig Kosten und Änderungen in einem anderen Bereich nach sich ziehen.
Interaktion mit TOGAF Phase B, Phase D und Phase E
Wasserfall-Ansätze liefern keine Ergebnisse. Best-Practice-Unternehmensarchitektur ist keine Wasserfall-Aktivität. Der einzige erfolgreiche Ansatz erfordert die Entwicklung der Geschäftsarchitektur, Anwendungsarchitektur, Datenarchitektur, Technologiearchitektur und Sicherheitsarchitektur gleichzeitig. Die gleichzeitige Entwicklung erfordert einen agilen Ansatz, der gerade ausreicht, um die kaskadierenden Einschränkungen zu testen.
Die klassische Reihenfolge, die in vielen TOGAF ADM-Diagrammen impliziert ist, ist die Reihenfolge, in der wir die Architekturentwicklung abschließen, nicht beginnen können.
Geben Sie sich nicht der Illusion hin, dass das Unternehmen in irgendeiner Weise von seinen Anwendungen, Daten und seiner Infrastruktur getrennt ist. Das war in der Vergangenheit nicht der Fall und ist in einem modernen digitalen Unternehmen lächerlich. Diese Illusion ist der schnellste Weg, Unternehmensagilität oder die Chance von digitale Transformation Erfolg.
Anwendungsarchitekten spielen eine entscheidende Rolle in einem Enterprise-Architektur-Team. In einem modernen digitalen Unternehmen läuft nichts ohne Software. Schlechte Anwendungsauswahl kann die Produktivität beeinträchtigen.'das Geschäft.' Anwendungsarchitekten sind Spezialisten in einem Architekturbereich. Sie können ihren Bereich nicht ohne regelmäßige Zusammenarbeit mit Geschäftsarchitekten, Daten, Technologie und Sicherheitsarchitekten.
Agentische KI-Playbook-Konversationen
Agentic AI Playbook-Gespräche Wir haben uns intensiv mit der sich wandelnden Landschaft der KI-Einführung auseinandergesetzt und eine Reise unternommen, die sowohl technische Feinheiten als auch die umfassendere digitale Transformation beinhaltet. Wir haben den Leitfaden für Führungskräfte entwickelt […]
Laden Sie die Referenzarchitektur für kritische Fähigkeiten zur KI-Einführung herunter
Laden Sie die Referenzarchitektur für kritische Fähigkeiten zur KI-Einführung herunter. Die Einführung von KI erfordert innovatives Denken. Derzeit verfügen wir nicht über bewährte Best Practices für eine flächendeckende KI-Einführung, die unsere Organisationen nachhaltig verbessern. Wir benötigen die Fähigkeit, unsere Vorgehensweise neu zu denken. […]
Leitfaden für Unternehmensleiter zu AI herunterladen
Download Business Leader's Guide to Artificial Intelligence Unternehmen, die innovative Technologien erfolgreich einsetzen, haben einen Wettbewerbsvorteil. Innovative Technologie ist nicht mit etablierten Erfolgsmustern und bewährten Verfahren verbunden. Innovative Technologie ist neu und [...]
Download der Einführung in den TOGAF-Standard, 10. Ausgabe
Download Einführung in den TOGAF®-Standard, 10. Auflage Der TOGAF-Standard, 10. Auflage erleichtert die Einführung von Best Practices für Unternehmensarchitektur. Er trennt die universellen Konzepte von bewährten Best Practices. Der Standard unterstreicht, wo man [...]
Leitfaden zur fähigkeitsbasierten Planung herunterladen
Download Leitfaden für die fähigkeitsbasierte Planung Immer auf die Realisierung von Werten hinarbeiten. Eine halbe Verbesserung ist 100% Verschwendung! Niemand bringt einem Adler das Krabbeln, Gehen oder Laufen bei. Eagles Fly! Download Bringen Sie Ihren Adlern das Fliegen bei: Capability-based Planning [...]
Leitfaden zur Bewertung der Geschäftsarchitekturfähigkeit herunterladen
Leitfaden zur Bewertung der Geschäftsarchitektur herunterladen Laden Sie einen Leitfaden zur Bewertung der Geschäftsarchitektur herunter. Die fähigkeitsbasierte Planung ist eine der leistungsfähigsten Techniken zur Verbesserung der Unternehmensarchitektur. Die bewährte Praxis der fähigkeitsbasierten Planung verwendet die Fähigkeit als Managementinstrument [...]
Muster für Unternehmensarchitekturprinzipien herunterladen
Download von Beispielen für Architekturprinzipien Laden Sie ein Beispiel für die Prinzipien der Unternehmensarchitektur herunter. Die Grundsätze der Unternehmensarchitektur zeigen auf, wie man an ein Problem oder eine Entscheidung herangeht. Der Ansatz führt Sie immer zu Ihren dauerhaften Prioritäten. Muster für Unternehmensarchitekturprinzipien herunterladen [...]
Leitfaden zur Unternehmensarchitektur-Governance herunterladen
Download Enterprise Architecture Governance Guide Laden Sie den Enterprise Architecture Governance Guide herunter und erfahren Sie mehr über bewährte Verfahren zur Steuerung und Kontrolle der Architekturentwicklung und -änderung, um die erwarteten Ergebnisse zu erzielen. Leitfaden zur Unternehmensarchitektur-Governance herunterladen [...]
TOGAF und SABSA Integration herunterladen
Download TOGAF und SABSA Integration Bringen Sie SABSA, das weltweit beste Framework für Sicherheitsarchitekturen, und TOGAF, das branchenübliche Framework für Unternehmensarchitekturen, zusammen. Download TOGAF und SABSA-Integration TOGAF und SABSA-Integration Enthält SABSA verwendet ein [...]
Referenzarchitektur für die Unternehmensarchitektur herunterladen
Download Enterprise Architecture Capability Reference Architecture Die Enterprise Architecture Capability Reference Architecture wird den Aufbau und die Verbesserung Ihres EA-Teams beschleunigen. Gestalten Sie Ihr Enterprise Architecture Team für den Erfolg. Identifizieren und verbessern Sie Ihre Unternehmensarchitektur [...]
Grundlegendes Wissen zu Phase C
Alle TOGAF ADM-Phasen führen Sie zum Aufbau des erforderlichen Wissens. Das Ergebnis von Phase C ist die Kandidaten-Anwendungsarchitektur, die in die Kandidaten-Informationssystemarchitektur integriert ist.
| Ausgabe und Ergebnis | Grundlegendes Wissen |
| Die Anwendungsarchitektur Domänenarchitektur von den Beteiligten für das zu behandelnde Problem genehmigt, mit einer Reihe von Lücken, und daran arbeiten, die von den Beteiligten verstandenen Lücken zu schließen. | Warum erfüllt das aktuelle Softwareportfolio nicht die Wünsche der Stakeholder?
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 4 von TOGAF-Reihenhandbuch: Leitfaden für Unternehmensarchitekten zur Architekturentwicklung
Phase C Bare Bones
In Phase C können wir die Arbeit eines Anwendungsarchitekten vereinfachen und bestimmen, wie sich ein Unternehmen verbessern kann. Dazu müssen wir verstehen, worin das Unternehmen gut sein möchte, wo es hinter den Besten zurückbleibt und was sich ändern muss, um das Beste zu erreichen.
Das Grundgerüst von Phase C ist:
- Wissen, wie das Anwendungsportfolio die Wertschöpfung ermöglicht
Jede Organisation verfügt über eine Wertschöpfungskette. Dabei handelt es sich um Aktivitäten, die einen Input in etwas Wertvolleres für ihre Kunden umwandeln. Anwendungen leisten entweder Wertschöpfung oder dienen der Datenerfassung. Traditionell diente fast jede Software der Datenerfassung.
Sie müssen Ihre Software für die jeweilige Rolle optimieren – Wertschöpfung oder Datenhaltung. Übernehmen Sie die Datenhaltung. Verwechseln Sie die wichtige Rolle der Datenhaltung nicht mit der Wertschöpfung.
Die Quelle von Kosten und Komplexität kennen
Jedes Anwendungsportfolio verursacht Kosten und Komplexität. Wir betrachten Software als komplexes Uhrwerk, das im Laufe der Zeit zusammengebaut wurde. Wir haben alles mit allem verbunden. Mit digitalen Produkten und allgegenwärtigen IT-Services ITFM verstehen ist eine grundlegende Fähigkeit.
Sie müssen Ihr Kernportfolio optimieren, um nachhaltige Kosten und Komplexität zu reduzieren. Sie müssen Unternehmensagilität. Moderne digitale Organisationen können sich nur im gleichen Tempo wie die Software verbessern.
- Wissen, wie man Software auswählt
Es gibt vier Softwaremodelle: SaaS, Enterprise-Suiten, spezialisierte kommerzielle Pakete und kundenspezifische Entwicklung. Jedes Modell hat ein anderes Kosten- und Optimierungsmodell. Sie müssen das richtige Softwaremodell an den richtigen Stellen einsetzen.
- Wissen, wann die Software Teil von 'das Produkt'
Unsere Organisationen liefern ein Produkt oder eine Dienstleistung. Software, die 'das Produkt' unterscheidet sich erheblich von Software, die das Geschäft unterstützt.
- Den Informationsfluss kennen
Menschen sind unendlich flexibel. Wir können entscheiden, Informationen zu teilen. Wir können Situationen proaktiv erkennen und reagieren. Software tut genau das, was man ihr sagt. Software tut nur das, was man ihr sagt.
Der Informationsfluss erfolgt rund um die Software, um die richtigen Aufgaben zu erledigen. Diese Art von Informationsfluss beeinträchtigt die Agilität des Unternehmens. Er beeinträchtigt die Effizienz und treibt die Kosten in die Höhe.
- Die Erwartungen an die Software kennen
Manchmal brauchen wir einen gelegentlichen Datenverwalter. Manchmal brauchen wir ein autonomes System. Meistens brauchen wir etwas, das ohne zu viel Aufwand hilft. Wir nutzen die Konzepte und Attribute in Fähigkeitsmodelle um Entscheidungen über unsere Anwendungsarchitektur zu treffen. Siehe die Leitfaden zur Bewertung der Fähigkeiten der Unternehmensarchitektur.
- Wissen, was die Organisation tun muss
Jedes Unternehmen muss eine Reihe von Prozessen durchführen: primäre Wertschöpfung, unterstützende und administrative Prozesse. Jeder dieser Prozesse benötigt Software. Jeder dieser Prozesse erzeugt und produziert Informationen. Sie müssen wissen, um welche Prozesse es sich handelt, welche Informationen sie nutzen und wer sie durchführt.
- Was muss sich ändern, um das beste Anwendungsportfolio bereitzustellen?
Wir entwickeln Anwendungsarchitekturen, um Ihr Unternehmen zu verbessern. Die meisten Änderungen sind unwesentlich. Sie beschränken sich meist nur auf Randbereiche. Konzentrieren Sie sich auf wesentliche Änderungen, die die Unternehmensflexibilität, die Kosten oder die Wertschöpfung deutlich steigern.
Die drei wesentlichen Punkte zur Fertigstellung von Phase C:
- Erste, Was muss sich ändern? Fokusänderung, Organisationsgestaltung, Weiterbildung, Outsourcing, Insourcing, Automatisierung. All das sind Veränderungen. Wir führen sie durch, um eine Organisation zu verbessern.
- Zweite, wann muss es geändert werden? Gibt es Abhängigkeiten? Wie sieht es mit Vorbedingungen aus? Bereiten Sie mit der Änderung die Voraussetzungen für eine spätere Änderung vor?
- Dritte, wie können Sie feststellen, ob die Änderung erfolgreich war? Was ist Ihr Governance-Test für den Erfolg? Wie werden Sie den Wert schützen?
Die Stakeholder der Unternehmensarchitektur sind für alle Entscheidungen verantwortlich, was wann geändert werden muss. Der Anwendungsarchitekt ist für die Beschreibung der Governance-Tests verantwortlich, damit die Stakeholder das Änderungsprojekt steuern können, sowie für die zweiten und dritten Ergebnisse.
Unternehmensarchitektur-Schulung und TOGAF-Schulung
Schulungskurs Geschäftsarchitektur
Business Architecture Training Eine effektive Unternehmensarchitektur beruht auf der Geschäftsarchitektur. Der Kurs vermittelt den Teilnehmern die Fähigkeiten und das Wissen, um eine Geschäftsarchitektur im Rahmen einer Unternehmensarchitektur zu entwickeln. Die Unternehmensarchitektur umfasst die Beschreibung der Struktur des [...]
TOGAF-Schulung zur Unternehmensarchitektur
Sie möchten eine Schulung für die TOGAF-Zertifizierung? Beweisen Sie Ihr Wissen über Unternehmensarchitektur mit der TOGAF-Zertifizierung TOGAF® Enterprise Architecture Training Course Machen Sie einen großen Schritt, um ein besserer Unternehmensarchitekt zu werden mit TOGAF Standard, 10.
Avolution ABACUS-Schulungskurs
Avolution ABACUS Training Effektive Unternehmensarchitektur beruht auf formaler Modellierung und Analyse. Wir bieten eine Avolution ABACUS-Schulung von Unternehmensarchitekten aus der Praxis an. Die Teilnehmer erwerben Fähigkeiten und Kenntnisse, um integrierte Unternehmens- und Domänenarchitekturen in diesem [...]
Effektive Online-Bildung
Effektive Online-Bildung Effektive Online-Bildung funktioniert. Die Schüler haben Zugang zu den besten verfügbaren Lehrkräften. Die Studierenden bestimmen ihr Lerntempo selbst. Die Lehrkräfte können umfangreiches Zusatzmaterial zur Verfügung stellen, ohne vom Hauptthema abzulenken. Effektiver Fernunterricht [...]
Kickstart für Unternehmensarchitekten
Enterprise Architect's Kickstart Wir müssen unsere Fähigkeiten auf dem neuesten Stand halten. Jetzt mehr denn je. Nutzen Sie den Enterprise Architecture Kickstart, um Ihre Fähigkeit zu verbessern, transformative Unternehmensarchitektur zu liefern. Dieser 90-Tage-Kickstart ist die Art und Weise, wie Conexiam Consulting [...]
Maßgeschneiderte Schulungen zur Unternehmensarchitektur
Maßgeschneiderte Schulungen für Unternehmensarchitektur Maßgeschneiderte Schulungen für Unternehmensarchitektur sind auf die professionelle Entwicklung Ihres EA-Teams ausgerichtet. Gute Unternehmensarchitekten nutzen ein breites Spektrum an Fähigkeiten, Methoden und spezialisiertem Fachwissen zur Entwicklung von [...]
TOGAF ADM Phase C Anwendungsarchitektur – Ergebnisse
Ein zentrales Ergebnis der Phase C ist eine Anwendungsarchitektur. Diese ist ein Teil der gesamten Unternehmensarchitektur.
TOGAF Phase C – Ergebnisse der Anwendungsarchitektur und Anwendungsfälle der Unternehmensarchitektur
Die Entwicklung einer Unternehmensarchitektur verfolgt vier Hauptziele. Die einzelnen Ergebnisse der TOGAF-Phase C 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 C: Kandidatenanwendungsarchitektur | 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 C: 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 im Verständnis der Stakeholder für Arbeit und Abhängigkeit. 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 C: 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 3 TOGAF-Reihenhandbuch: Leitfaden für Unternehmensarchitekten zur Architekturentwicklung
Architektur der Kandidatenbewerbung
Die Entwicklung einer Unternehmensarchitektur verfolgt vier Hauptziele. Für jeden Zweck haben unterschiedliche Modelle eine unterschiedliche Bedeutung.
Komponenten der Roadmap zur Architektur der Kandidatenbewerbung
Was muss sich ändern? Wenn Sie das Anwendungsentwicklungsmodell ändern, ist der Unterschied zwischen dem aktuellen und dem Ziel der Roadmap-Kandidat. Dies gilt auch für alles, was für die Umsetzung dieser Änderung erforderlich ist.
Wir verwenden häufig ein Systemmodell, um die Änderung zusammenzufassen. Das Systemmodell ermöglicht gerade genug Abstraktion von der realen Software, um eine Planungs- und Ausführungsdiskussion zu ermöglichen. Wir verwenden üblicherweise Scores und Arbeitspakete, um eine Änderung zu artikulieren. 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.
Anforderungsspezifikation für die Architektur der Kandidatenanwendung
Definieren Sie, wie Sie die Änderung bewerten werden. Wie wird die Verbesserung bewertet?
Wir verwenden in unseren Modellen häufig Scores, um Anforderungen zu beschreiben. Jede Anforderung ist ein Maß für Effizienz, Automatisierung, Agilität oder Leistung. Wenn wir dann in TOGAF Phase G Durchführung Architektur-Governance mit einem Änderungsprojekt Wir verwenden diese Bewertungen, um Designs und Implementierungen zu bewerten.
Mehr erreichen mit Best-Practice-Unternehmensarchitektur-Prozess und -Methode
Bewährte Verfahren Unternehmensarchitektur von Conexiam Navigieren
Unternehmensarchitektur-Framework-Vergleich: Welches ist das Richtige für Sie?
Unternehmensarchitektur-Framework-Vergleich: Welches ist das richtige für Sie? In der Geschäftswelt gibt es keine Einheitsgröße für alle. Auch nicht bei Frameworks für Unternehmensarchitekturen. Vergleichen Sie die Vorzüge beliebter Frameworks, um herauszufinden, welches optimierte Framework das richtige für Sie ist. Während [...]
Klügere Entscheidungen treffen: Warum Ihr Unternehmen architektonische Entscheidungen braucht
Klügere Entscheidungen treffen: Warum Ihr Unternehmen Architekturentscheidungen braucht Unternehmen stehen ständig vor der Herausforderung, wichtige Entscheidungen zu treffen. Jeden Tag haben Entscheidungen, einschließlich Betriebspraktiken und Technologieauswahl, erhebliche Auswirkungen auf ein […]
Verwendung der Szenarioanalyse für die Unternehmensarchitektur
Verwendung der Szenarioanalyse für die Unternehmensarchitektur Ein Szenario ist einfach eine plausible Zukunft. Die Szenarioanalyse untersucht, wie wir zu einer plausiblen Zukunft gelangen und wie sich verschiedene Szenarien auf unsere aktuellen Entscheidungen auswirken. Szenarien helfen Führungskräften [...]
Entwicklung einer Architekturansicht
Entwicklung einer Architekturansicht Die Unternehmensarchitektur ist ein wichtiger Kompass. Sie hilft Unternehmen, die Komplexität von Technologie, Strategie und Betrieb zu meistern. Der Kern der Unternehmensarchitektur ist ein systematischer Ansatz. Ziel ist es, sicherzustellen, dass […]
Verständnis von Unternehmensarchitektur und Agile
Agile und Unternehmensarchitektur verstehen Sowohl die agile als auch die Unternehmensarchitektur sind darauf ausgerichtet, Risiken zu verringern. Agile Softwareentwicklung zeichnet sich dadurch aus, dass sie etwas schafft, das wir noch nie hatten und von dem wir nicht wissen, wie wir es schaffen können. [...]
Entwicklung einer Unternehmensarchitektur-Strategie
Entwicklung einer Enterprise-Architektur-Strategie: Strategischer Plan für Veränderungen. Eine Enterprise-Architektur-Strategie ist Handeln. Maßnahmen, die Ihr Unternehmen ergreifen wird, und Veränderungen, die Sie vornehmen werden, um Ihre strategischen Ziele zu erreichen. Bei der Strategieentwicklung geht es vor allem um Entscheidungen. […]
Unternehmensarchitektur-Roadmap als Entwurf
Unternehmensarchitektur-Roadmap als Design Eine Architektur-Roadmap ist ein Planungsinstrument, das den Entscheidungsträgern eines Unternehmens hilft. Eine dynamische Architektur-Roadmap soll ihnen helfen, den besten Weg zu entwickeln und zu beschreiten. Sie ist auch [...]
Sicherstellung von Ausrichtung und Verantwortlichkeit: Die entscheidende Rolle von Enterprise Architecture Governance Checklisten
Sicherstellung von Ausrichtung und Verantwortlichkeit: Die entscheidende Rolle von Governance-Checklisten für Unternehmensarchitekturen Governance-Checklisten für Unternehmensarchitekturen vereinfachen die Governance-Prozesse für Unternehmensarchitekturen. Der Governance-Prozess muss die Zielarchitektur genehmigen und die Umsetzung steuern. Ein robustes Unternehmen [...]
Bewährte Praktiken zur Implementierung von Tools für das Management der Unternehmensarchitektur
Best Practices für die Implementierung von Enterprise Architecture Management Tools Enterprise Architecture Management Tools wurden entwickelt, um die Planung, den Entwurf, die Analyse und die Ausführung der Unternehmensarchitektur zu unterstützen. Sie versetzen Unternehmensarchitekten in die Lage, die Notwendigkeit von Änderungen zu untersuchen [...]
Entdecken Sie die Leistungsfähigkeit von Enterprise Architecture Patterns
Entdecken Sie die Leistungsfähigkeit von Enterprise-Architektur-Mustern: Ein umfassender Leitfaden. Jedes Unternehmen möchte sich verbessern. Seine Abläufe rationalisieren. Seine Unternehmensagilität steigern. Veränderungen an seinen Strategien ausrichten. Die digitale Transformation erfolgreich meistern. Enterprise Architecture, eine Disziplin […]
Modelle, Tools und Techniken der Anwendungsarchitektur
Die TOGAF ADM Phase C liefert die Informationssystemarchitektur. In dieser Phase werden die Anwendungs- 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 Anwendungsarchitekturmodelle.
- Anwendungsentwicklungsmodell, das die akzeptable Methode beschreibt, mit der ein System entwickelt wird
- Systemmodell, das die großen Systeme erfasst, um die Ihr Anwendungsportfolio herum konzipiert ist
- Funktionsmodell, das alle Aufgaben beschreibt, die Ihr Softwareportfolio erfüllen muss
- Produktmodell, das die in den Produkten und Dienstleistungen Ihres Unternehmens verwendete Funktionalität sowie diejenigen identifiziert, die diese verwalten
- Das Integrationsmodell beschreibt, wie Informationen durch Ihr Anwendungsportfolio fließen
- Das Servicemodell zerlegt Ihr Anwendungsportfolio in Blackboxen und ermöglicht Ihnen sicherzustellen, dass jeder Service über die erforderliche Agilität, Automatisierung und andere Attribute verfügt
- Das physische Modell identifiziert die tatsächlichen Anwendungen (kommerziell, SaaS oder benutzerdefiniert) in Ihrem Anwendungsportfolio
Die Anwendungsarchitektur hilft bei der Beantwortung der folgenden Fragen:
- Wie das Anwendungsportfolio Wertschöpfung ermöglicht – Anwendungsentwicklungsmodell
- Wo Kosten in das IT-Portfolio einfließen - Funktionsmodell
- Wo Starrheit in das IT-Portfolio eingebracht wird - Integrationsmodell
- Wie das Unternehmen läuft – Systemmodell
- Für die Bereitstellung des Produkts oder der Dienstleistung erforderliche Systeme – Produktmodell
- Die Dinge, die eine Organisation können muss - Funktionsmodell
- Der Informationsfluss, der für die Durchführung der Aktivitäten eines Unternehmens erforderlich ist - Integrationsmodell
- Die Gesamtheit der Aktivitäten eines Unternehmens, typischerweise gruppiert, um zu zeigen, wie sie zueinander in Beziehung stehen – Servicemodell
- Was das Softwareportfolio ist – Physikalisches Modell
Denken Sie immer daran, dass Sie die Organisation verbessern möchten. Verbesserung erfordert Veränderung und schafft Mehrwert. Wert und Kosten von Veränderungen sind messbar. Unsicherheit mindert immer den potenziellen Wert. Unsicherheit erhöht immer die Kosten. Wir betrachten Unsicherheit als geometrische Auswirkung. Schon geringe Unsicherheit mindert den potenziellen Wert erheblich.
Bedenken Sie beim Lesen, dass dieselben Begriffe häufig verwendet werden. Achten Sie auf den Zweck des Modells und lassen Sie sich nicht von einer anderen Bezeichnung irritieren. Was Sie beispielsweise als Funktionsmodell bezeichnen, wird von anderen als Service bezeichnet. In unserem Unternehmensarchitekturberatung, wir konzentrieren uns immer darauf, was wir verstehen wollen, und nicht darauf, wie das Modell heißt.
Verschiedene Modelle erklären unterschiedliche Aspekte des Unternehmens. Zusammen bilden die Modelle und die erforderlichen Änderungen die Anwendungsarchitektur.
Anwendungsarchitekturmuster
Wir verwenden Architekturmuster die Produktivität und Qualität unserer Architekturentwicklung drastisch zu steigern. Die Architektur-Mustervorlage treibt uns zum Verständnis der vorhersehbares Problem, Musteransatz, und die Harte Teile. Um mit diesem Muster erfolgreich zu sein, müssen Sie sich mit den Harte Teile (erforderliche Arbeit, Einschränkungen und Beschränkungen).
Beispiele für Anwendungsarchitekturmuster
Beispiele für Anwendungsarchitekturmuster behandeln die Probleme der Anwendungsstruktur, Migration und Anwendungsgestaltung.
- Anwendungsstruktur
- MVC-Muster (Model-View-Controller)
Vorhersehbares Problem– Codeorganisation, Wartbarkeit und Testbarkeit
Ansatz– unterteilt eine Anwendung in drei miteinander verbundene Komponenten – Modell (Daten und Geschäftslogik), Ansicht (Benutzeroberfläche) und Controller (verarbeitet Benutzereingaben und aktualisiert Modell und Ansicht entsprechend)
- MVC-Muster (Model-View-Controller)
- Anwendungsmigration
- Würgemuster
Vorhersehbares Problem– Ersetzen von Altsystemen
Ansatz– schrittweises Ersetzen oder “erwürgen” eines bestehenden Altsystems durch den Aufbau neuer Komponenten um das System herum, um es schrittweise zu ersetzen
- Würgemuster
- Anwendungsdesign (Gang of Four-Anwendungsmuster)
Als Unternehmensarchitekten verwenden wir Designmuster als Einschränkung der Freiheit von Anwendungsentwicklungsteams. (Siehe Unternehmensarchitektur und Agile – Sprints einschränken)- Singleton-Muster- stellt sicher, dass eine Klasse nur eine Instanz hat und bietet einen globalen Zugriffspunkt auf diese Instanz
Anwendungsarchitekturmodelle
Die Entwicklung einer Anwendungsarchitektur erfordert die Entwicklung mehrerer Unternehmensarchitekturmodelle. Jeder erklärt das Softwareportfolio des Unternehmens anders. Bei der Anwendungsarchitektur von TOGAF Phase C geht es darum, die Zielarchitektur anhand dieser Modelle zu entwickeln. Stellen Sie sicher, dass der Architekt der Zielanwendung mit den anderen Domänen zusammenarbeitet, um die bestmögliche Verbesserung für Ihr Unternehmen zu ermöglichen.
Zusammen beschreiben die Modelle die Anwendungsarchitektur. In der gesamten Unternehmensarchitektur werden diese Modelle mit anderen Modellen verknüpft, die die anderen Domänen der Unternehmensarchitektur beschreiben.
Anwendungsentwicklungsmodell
Das Anwendungsentwicklungsmodell beschreibt, wie Software entwickelt wird. Das Modell erfordert ein funktionales oder physisches Modell. Das funktionale Modell ist weitaus besser, da es eine logische Identifikationssoftware darstellt.
Es gibt vier Arten der Anwendungsentwicklung: SaaS, Enterprise-Suiten, spezialisierte kommerzielle Pakete und kundenspezifische Entwicklung. Jede Art hat einzigartige Merkmale und Auswirkungen.
- SaaS zeichnet sich durch vorgefertigte Software mit klar definierten Schnittstellen aus. Der Lebenszyklus wird von einem Drittanbieter gesteuert. Anpassungen sind nicht möglich.
Am besten geeignet für Geschäftsaktivitäten, die administrativer Natur sind und indirekt wertschöpfende Aktivitäten unterstützen. Die strengen Softwarebeschränkungen führen zu Einschränkungen der Geschäftstätigkeit und tragen zur Einführung branchenüblicher Verfahren bei.
- Merkmale von Enterprise-Suiten sind mehrere überlappende Funktionsmodelle mit definiertem Datenmodell. Schnittstellen und Funktionen können konfiguriert oder angepasst werden. Anpassungen verursachen im Laufe des Lebenszyklus unweigerlich zusätzliche Kosten. Der Lebenszyklus wird von Dritten beeinflusst.
- Zu den Merkmalen spezialisierter kommerzieller Pakete gehören Fokussierung und funktionale Optimierung für die jeweilige Tätigkeit. Sie sind typischerweise auf eine bestimmte Herangehensweise an die Geschäftstätigkeit ausgerichtet. Sie verfügen üblicherweise über ein einzigartiges, klar definiertes Datenmodell. Schnittstellen und Funktionen sind konfigurierbar. Anpassungen sind möglich. Anpassungen verursachen während des Lebenszyklus unweigerlich erhebliche Kosten. Der Lebenszyklus wird stark von Dritten beeinflusst.
- Zu den Merkmalen der kundenspezifischen Entwicklung gehört die direkte Abstimmung mit den bestehenden Organisationsgrenzen und -aktivitäten Ihres Unternehmens. Die Entwicklung ist stets darauf ausgelegt, das bestehende Kommunikationsmodell Ihres Unternehmens zu unterstützen. Fokussierung und funktionale Optimierung auf die Fachtätigkeit. Erwarten Sie ein schlecht definiertes Datenmodell. Schnittstellen und Funktionalität müssen angepasst werden. Das Lebenszyklusmanagement wird meist vernachlässigt und verursacht hohe laufende Kosten.
Optimal für Geschäftsaktivitäten in der primären Wertschöpfungskette. Die Flexibilität ermöglicht eine Optimierung der Wertschöpfung. Effektive Nutzung erfordert ein Verständnis der Wertschöpfung heute und in Zukunft.
Anwendungsentwicklungsmodell
Das Anwendungsentwicklungsmodell beschreibt, wie Software entwickelt wird. Das Modell erfordert ein funktionales oder physisches Modell. Das funktionale Modell ist weitaus besser, da es eine logische Identifikationssoftware darstellt.
Es gibt vier Arten der Anwendungsentwicklung: SaaS, Enterprise-Suiten, spezialisierte kommerzielle Pakete und kundenspezifische Entwicklung. Jede Art hat einzigartige Merkmale und Auswirkungen.
- SaaS zeichnet sich durch vorgefertigte Software mit klar definierten Schnittstellen aus. Der Lebenszyklus wird von einem Drittanbieter gesteuert. Anpassungen sind nicht möglich.
Am besten geeignet für Geschäftsaktivitäten, die administrativer Natur sind und indirekt wertschöpfende Aktivitäten unterstützen. Die strengen Softwarebeschränkungen führen zu Einschränkungen der Geschäftstätigkeit und tragen zur Einführung branchenüblicher Verfahren bei.
- Merkmale von Enterprise-Suiten sind mehrere überlappende Funktionsmodelle mit definiertem Datenmodell. Schnittstellen und Funktionen können konfiguriert oder angepasst werden. Anpassungen verursachen im Laufe des Lebenszyklus unweigerlich zusätzliche Kosten. Der Lebenszyklus wird von Dritten beeinflusst.
- Zu den Merkmalen spezialisierter kommerzieller Pakete gehören Fokussierung und funktionale Optimierung für die jeweilige Tätigkeit. Sie sind typischerweise auf eine bestimmte Herangehensweise an die Geschäftstätigkeit ausgerichtet. Sie verfügen üblicherweise über ein einzigartiges, klar definiertes Datenmodell. Schnittstellen und Funktionen sind konfigurierbar. Anpassungen sind möglich. Anpassungen verursachen während des Lebenszyklus unweigerlich erhebliche Kosten. Der Lebenszyklus wird stark von Dritten beeinflusst.
- Zu den Merkmalen der kundenspezifischen Entwicklung gehört die direkte Abstimmung mit den bestehenden Organisationsgrenzen und -aktivitäten Ihres Unternehmens. Die Entwicklung ist stets darauf ausgelegt, das bestehende Kommunikationsmodell Ihres Unternehmens zu unterstützen. Fokussierung und funktionale Optimierung auf die Fachtätigkeit. Erwarten Sie ein schlecht definiertes Datenmodell. Schnittstellen und Funktionalität müssen angepasst werden. Das Lebenszyklusmanagement wird meist vernachlässigt und verursacht hohe laufende Kosten.
Optimal für Geschäftsaktivitäten in der primären Wertschöpfungskette. Die Flexibilität ermöglicht eine Optimierung der Wertschöpfung. Effektive Nutzung erfordert ein Verständnis der Wertschöpfung heute und in Zukunft.
Systemmodell
Das Systemmodell ist eine Abstraktion der Software rund um eine Aktivität. Denken Sie an das ‘Supply-Chain-System’ und alles, was damit zusammenhängt. Das Design Ihres Systemmodells wird auf die Arbeitsweise Ihres Unternehmens abgestimmt.
Ähnlich wie das Fähigkeitsmodell des Business-Architekten ermöglicht Ihnen ein Systemmodell, Ihr Denken auf ein System auszurichten. Sie können sich auf die Verbesserung eines kompletten Systems konzentrieren und dann die erforderlichen Änderungen auf alles konzentrieren, was das System ausmacht und mit ihm interagiert.
Produktmodell
Ein Produktmodell ist eine spezialisierte Version eines Funktionsmodells, das die für Ihre Produkte oder Dienstleistungen erforderlichen Funktionen hervorhebt. Ein gutes Produktmodell klassifiziert die Funktionen in vergleichbaren Begriffen.
Ein gutes Produktmodell bildet die Grundlage für Referenzarchitektur für Ihre Produkte. Sie müssen Funktionen spezifizieren, die für den Wert, die Nutzung und die Verwaltung des Produkts von zentraler Bedeutung sind. Ein Produktmodell dient als Grundlage für die Auswahl des Anwendungsentwicklungsmodells. Sie benötigen kundenspezifische Entwicklung, Duplizierung und eine deutlich höhere Änderungsfähigkeit, wenn die Funktionen mit Ihren Produkten und Dienstleistungen verknüpft sind.
Funktionsmodell
Das Funktionsmodell zerlegt Ihr Softwareportfolio in seine Funktionalität. Es identifiziert alle Aufgaben, die Ihre Software erfüllen muss. Gute Funktionsmodelle decken ein breites Spektrum ab.
Wie das Prozessmodell des Business-Architekten ist auch ein Funktionsmodell häufig eine Referenzarchitektur. Es ist besonders hilfreich, wenn Sie Duplizierung und Integration anstreben. Es bildet oft die Grundlage eines Anwendungsentwicklungsmodells, bei dem verschiedenen Funktionsblöcken ein Zielanwendungsentwicklungstyp zugewiesen wird.
Entscheidend bei der Planung des Anwendungsportfolios. Duplizierung und Integration erhöhen die Komplexität und die Kosten des IT-Portfolios.
BIAN, FEAF, ODF von TMForum und IndEA bieten alle Funktionsmodelle.
Integrationsmodell
Ein Integrationsmodell identifiziert die Grenzen Ihrer Software und die Methode, mit der diese Grenzen überschritten werden. Scheuen Sie sich nicht, festzulegen, dass die Grenze nicht überschritten werden kann oder manuell überschritten werden muss. Viele schwache Anwendungsintegrationen führen nur zu Starrheit. Die Entwicklung eines nützlichen Integrationsmodells erfordert Iterationen mit der Arbeit eines Business-Architekten, der ein Organisationsstruktur und Informationsmodell. Das Integrationsmodell, die Organisationskarte und das Informationsmodell informieren und beschränken sich gegenseitig.
Das Integrationsmodell ist entscheidend für die Unternehmensflexibilität, die Verwaltung des Anwendungsportfolios und die Senkung der IT-Kosten.
Servicemodell
Ein Servicemodell ist eine spezialisierte Version eines Funktionsmodells, das die Funktionalität in einer Blackbox mit bekannten Schnittstellen zusammenfasst. Ein gutes Servicemodell ist für die Entwicklung des Anwendungsentwicklungsmodells und die Validierung des Ziels in einem Systemmodell von unschätzbarem Wert. Die Schnittstellen Ihres Servicemodells sollten alle in Ihrem Integrationsmodell klar identifiziert sein.
Ein gutes Servicemodell ermöglicht Unternehmensflexibilität. Nicht durch die Entwicklung von Anwendungsdiensten, sondern durch die Freigabe von Änderungen in einem Teil Ihres Unternehmens von einem anderen.
Physikalisches Modell
Ein physisches Modell ist das reale Softwareportfolio. Wir beschreiben es anhand der Begriffe kommerzieller Softwareanbieter und Ihres Anwendungsentwicklungsprogramms. Sie müssen es mit den anderen Anwendungsarchitekturmodellen verknüpfen, um das Ziel in die reale Welt zu übertragen.
Sie verwenden das physikalische Modell als Einschränkung für die abstrakten Anwendungsarchitekturmodelle. Es bildet auch die Grundlage für Implementierungs- und Migrationsplan, der in Phase F entwickelt wurde.
Anwendungsarchitekturtechniken
Wir verwenden eine breite Palette von Techniken, um unsere Anwendungsarchitektur zu entwickeln und zu kommunizieren.
- UML ist in der modellgetriebenen Entwicklung allgegenwärtig. Wenn Sie in der Architektur arbeiten, um die Lösungsentwicklung zu unterstützen, sollten Sie ein Funktionsmodell und ein Integrationsmodell nach UML-Praktiken entwickeln.
- 4+1-Ansichten sind sehr 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.
- Die Information Needlines von DODAF ziehen alle erforderlichen Informationsflüsse heraus. Dabei spielt es keine Rolle, ob es sich bei dem Knotenpunkt um eine Person, eine Organisation oder ein System handelt. Informationen fließen ein und aus. Der schnellste Weg, Automatisierung zu vermeiden, besteht darin, manuelle Schritte in die Mitte eines Informationsflusses zu setzen.
Anwendungsarchitekturmodelle, die auf den Anwendungsfall der Unternehmensarchitektur abgestimmt sind
Die Fragestellung, die Sie mit Ihrer Anwendungsarchitektur beantworten, bestimmt den Einsatz unterschiedlicher Anwendungsarchitekturmodelle. Beispielsweise wird bei der Portfolio-Unterstützung oft kein Wertschöpfungskettenmodell entwickelt. Stattdessen ist eine Wertschöpfungskette in der Regel eine übergeordnete Architektur und schränke deine 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 | |
| Anwendungsentwicklungsmodell | Wichtigstes Ergebnis | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Systemmodell | Regelmäßige Lieferung | Wichtigstes Ergebnis | Überlegene Architektur | Überlegene Architektur |
| Funktionsmodell | Regelmäßige Lieferung | Wichtigstes Ergebnis | Wichtigstes Ergebnis & Überragende Architektur | Wichtigstes Ergebnis & Überragende Architektur |
| Produktmodell | Gelegentliche Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Regelmäßige Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Wichtigstes Ergebnis | Wichtigstes Ergebnis |
| Integrationsmodell | Gelegentliche Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Regelmäßige Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Wichtigstes Ergebnis | Wichtigstes Ergebnis & Überragende Architektur |
| Servicemodell | Gelegentliche Lieferung
Angemessener Detaillierungsgrad mindert oft den Wert |
Regelmäßige Lieferung | Wichtigstes Ergebnis & Überragende Architektur | Wichtigstes Ergebnis & Überragende Architektur |
Einfluss von Geschäftsarchitekturmodellen auf Anwendungsarchitekturmodelle
| Geschäftsmodell | Betriebsmodell | Wertschöpfungskette | Fähigkeitsmodell | Prozessmodell | Funktionsmodell | Informationsmodell | Organisationsmodell | |
| Anwendungsentwicklungsmodell | 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 |
| Systemmodell | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | Haupteingabe | Begrenzte Eingabe | Haupteingabe |
| Produktmodell | Haupteingabe | Haupteingabe | Haupteingabe | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | Begrenzte Eingabe | |
| Integrationsmodell | Sehr begrenzte Eingabe | Wichtiger Input zum Kerndesign
Erfordert ein System- oder Funktionsmodell |
Wichtiger Input zum Kerndesign
Erfordert ein System- oder Funktionsmodell |
Bester Eingang
Ein direkter Zusammenhang ist nur schwer zu erkennen. Die Arbeit lohnt sich. |
Wichtiger Input zum Kerndesign
Erfordert ein System- oder Funktionsmodell |
Begrenzte Eingabe
Nur verwenden, wenn keine anderen Modelle verfügbar sind |
Wichtiger Input zum Kerndesign
Erfordert ein System- oder Funktionsmodell |
Wichtiger Input zum Kerndesign
Erfordert ein System- oder Funktionsmodell |
| Servicemodell | Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist sehr schwer zu erkennen |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist sehr schwer zu erkennen |
Begrenzte Eingabe
Die Verknüpfungen sind wichtig, aber eine direkte Verbindung ist sehr schwer zu erkennen |
Bester Eingang
Ein direkter Zusammenhang ist nur schwer zu erkennen. Die Arbeit lohnt sich. |
Wird als Vollständigkeitstest verwendet | Haupteingabe
Ein direkter Zusammenhang ist nur schwer zu erkennen. Die Arbeit lohnt sich. |
Haupteingabe |
Anwendungsarchitekturmodelle für Anwendungsfälle der Unternehmensarchitektur
Alle Anwendungsfälle für Unternehmensarchitektur drehen sich um Veränderung. Sie alle betrachten die Arten von Veränderung und wie eine Enterprise-Architekt hilft Entscheidungsträgern, einen Weg nach vorne zu finden.
Ich betrachte die Anwendungsfälle der Unternehmensarchitektur als die Art der Änderung, den Zweck des Unternehmensarchitekturteams oder häufig gestellte Fragen.
In jedem Anwendungsfall der Unternehmensarchitektur erfüllen wir die gleiche Funktion. Wir unterstützen Stakeholder dabei, bessere Entscheidungen zu treffen und erfolgreiche Veränderungsinitiativen zu leiten. Das Einzige, was sich ändert, ist die Frage.
| 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 | |
| Anwendungsentwicklungsmodell | Wichtige Einschränkungen | Wichtige Richtlinien | Kritische Einschränkungen | 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 | ||
| Systemmodell | 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 | |||||
| Produktmodell | 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 | |||||
| Integrationsmodell | Informierende 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 | Kritische Lücken und Einschränkungen | Kritische Lücken und Einschränkungen | |
| Servicemodell | Sehr nützlich für Lücken und Einschränkungen | Sehr nützlich für Lücken und Einschränkungen | Sehr nützlich für Lücken und Einschränkungen | Sehr nützlich für Lücken und Einschränkungen | Sehr nützlich für Lücken und Einschränkungen | Sehr nützlich für Lücken und Einschränkungen | Sehr nützlich für Lücken und Einschränkungen |
Anwendung von Prinzipien der Unternehmensarchitektur auf die Anwendungsarchitektur
Wir haben festgestellt 7 Architekturprinzipien, die jeder Unternehmensarchitekt kennen sollte. Die folgende Tabelle zeigt die Auswirkungen dieser Architekturprinzipien auf die Anwendungsarchitektur. Bei der Durchführung Unternehmensarchitektur-Governance, müssen Sie Ihre Anwendungsarchitektur testen, um sicherzustellen, dass sie der übergeordneten Architektur entspricht. Entspricht sie den Prinzipien der Unternehmensarchitektur?
| Auswirkungen auf die Anwendungsarchitektur | |
| Spielen Sie nicht mit dem Erfolg | Wenn das Programm weder auf Differenzierung noch auf Transformation abzielt, versuchen Sie, Änderungen zu vermeiden. Vermeiden Sie alle Änderungen an Prozessen oder Systemen, deren Kosten und Ergebnisse nicht ausdrücklich gerechtfertigt sind. |
| Fokus auf Exzellenz | Richten Sie sich nach dem Betriebsmodell Die Fähigkeitsmodell.
Nutzen Sie das Anwendungsentwicklungsmodell, um Ihre Ausgaben auf die Differenzierung zu konzentrieren. Nutzen Sie das Produktmodell, um sich auf die Bereitstellung von Produkten und Dienstleistungen zu konzentrieren. |
| Warum nicht eins? | Nutzen Sie das Anwendungsentwicklungsmodell und das Produktmodell, um Bereiche zu identifizieren, in denen Duplizierung verboten ist. |
| Daten sind ein Vermögenswert | Stellen Sie sicher, dass die Kontrolle über das Datenmodell nicht auf eine Weise aufgegeben wird, die den Wert des Datenbestands mindert. |
| Systeme funktionieren, wo wir arbeiten | Arbeitsort und Arbeitsstil bestimmen die Schnittstelle und das Anwendungsmodell. |
| Problemlose Benutzererfahrung | Effizienzprogramme konzentrieren sich auf bestehende Geschäftsprozesse.
Differenzierungs- und Transformationsprogramme erfordern Änderungen an der Benutzeroberfläche und am Engagement, während Erfahrungen mit neuen Prozessen gesammelt werden. |
| Selbstbedienung | Anwendungsadministrationsaktivitäten und -bereitstellung sind kostspielig, wenn sie nicht im Self-Service-Verfahren erfolgen
Schwache UX ist teuer. |
Wie ist TOGAF Phase C mit der agilen Entwicklung vereinbar?
Die Anwendungsarchitektur bietet zahlreiche Einschränkungen und Richtlinien für die agile Entwicklung. Die grundlegenden Richtlinien stammen aus dem Anwendungsentwicklungsmodell. Es zeigt auf, wo Sie keine agile Entwicklung wünschen.
Unternehmensarchitektur und agile Entwicklung wird sich auf vier Bereiche überschneiden. Die Die Unternehmensarchitektur wird:
- Definieren Sie den agilen Ansatz
- den Rückstand im Sprint steuern
- Auswahlmöglichkeiten innerhalb der Sprints einschränken
- Lösen Sie die produktübergreifende Abhängigkeit
Wir konzentrieren uns bei der agilen Entwicklung stets auf neuartige Differenzierungsmaßnahmen und folgen konsequent etablierten Best Practices. Best Practices stammen von etablierter kommerzieller Software. Passen Sie Ihre Anwendungsarchitektur an Ihre Geschäftsarchitektur an und konzentrieren Sie sich auf die Beschaffung von Systemen.
Wie ermöglicht TOGAF Phase C Unternehmensagilität?
Unternehmensagilität hat nichts damit zu tun, wie Sie Software schreiben. Unternehmensagilität bedeutet, dass Ihr Unternehmen auf unerwartete Bedrohungen und Chancen reagieren kann. Wenn Sie Code schreiben müssen, ist Ihre Fähigkeit, auf eine Bedrohung reagieren oder eine Chance gefährdet ist.
Ein Anwendungsarchitekt konzentriert sich auf den fünften Aspekt der Unternehmensagilitätsmodell - Flexibilität. Wir verwenden das gleiche Agilitätsattribut und die gleichen Werte in der Leitfaden zur Fähigkeitsbewertung Wir identifizieren die Informationssysteme, die schnell veränderbar sein müssen. Anschließend entwickeln wir eine Architektur, die Veränderungen ermöglicht.
Unternehmensagilitätsmodell
- 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?
Was ist das Ziel von TOGAF ADM Phase C?
In Phase A, haben Sie einen vereinfachte Zielarchitektur – die Architekturvision. Die Architekturvision umfasste alle Domänen. Die Aktivitäten in Phase C entwickeln die Domänen Anwendungs- und Datenarchitektur weiter. Erfolg erfordert:
- Sie sprechen das Problem an, dass das aktuelle Unternehmen die Präferenzen der Stakeholder nicht erfüllen kann.
- Sie erfahren, was sich ändern muss, damit das Unternehmen den Wünschen der Stakeholder gerecht wird? (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 C ist die mögliche Anwendungsarchitektur. Anwendungsarchitekten arbeiten mit anderen Domänenarchitekten zusammen, um die Einschränkungen der Anwendungsarchitektur und anderer Domänen zu verstehen.
Denken Sie daran, dass das TOGAF ADM mögliche Änderungen untersucht. Bis Sie die Umsetzungsplan in Phase F, suchen Sie nach dem günstigsten Ausweg. Schlechte Ideen bedeuten nicht, dass Sie das Problem nicht lösen. Sie sollten schwache Architekturalternativen. Schlechte Ideen frühzeitig zu stoppen, spart Geld und ermöglicht erfolgreiche Veränderungen. Sobald eine Idee schlecht wird, stoppen Sie sofort. Beenden Sie die Idee. Feiern Sie Ihren Sieg! Feiern Sie, dass Sie erfolgreiche Veränderungen ermöglichen!
Anwendungsarchitekturmuster
Wir verwenden Architekturmuster um die Produktivität und Qualität unserer Architekturentwicklung drastisch zu steigern. Wir verwenden eine vereinfachte Architektur-Mustervorlage das uns zum Verständnis der vorhersehbares Problem, Musteransatz, und die Harte Teile. Die Anwendbarkeit des Musters wird normalerweise durch die erforderliche Arbeit, Einschränkungen und Beschränkungen bestimmt.
Beispiele für Anwendungsarchitekturmuster
Beispiele für Anwendungsarchitekturmuster behandeln die Probleme der Anwendungsstruktur, Migration und Anwendungsgestaltung.
- Anwendungsstruktur
- MVC-Muster (Model-View-Controller)
Vorhersehbares Problem– Codeorganisation, Wartbarkeit und Testbarkeit
Ansatz– unterteilt eine Anwendung in drei miteinander verbundene Komponenten – Modell (Daten und Geschäftslogik), Ansicht (Benutzeroberfläche) und Controller (verarbeitet Benutzereingaben und aktualisiert Modell und Ansicht entsprechend)
- MVC-Muster (Model-View-Controller)
- Anwendungsmigration
- Würgemuster
Vorhersehbares Problem– Ersetzen von Altsystemen
Ansatz– schrittweises Ersetzen oder “erwürgen” eines bestehenden Altsystems durch den Aufbau neuer Komponenten um das System herum, um es schrittweise zu ersetzen
- Würgemuster
- Anwendungsdesign (Gang of Four-Anwendungsmuster)
Als Unternehmensarchitekten verwenden wir Designmuster als Einschränkung der Freiheit von Anwendungsentwicklungsteams. (Siehe Unternehmensarchitektur und Agile – Sprints einschränken)- Singleton-Muster- stellt sicher, dass eine Klasse nur eine Instanz hat und bietet einen globalen Zugriffspunkt auf diese Instanz
Abschließende Gedanken zu TOGAF ADM Phase C
Anwendungsarchitekten arbeiten mit einem Enterprise-Architektur-Team haben eine Reihe von Aufgaben, die wichtiger sind als das Entwerfen einer Anwendung. Sie müssen die Richtlinien und Leitplanken für die Mitarbeiter entwickeln, die das Anwendungsportfolio des Unternehmens entwerfen, implementieren und entwickeln. Kurz gesagt: Enterprise Application Architect unterscheidet sich von einem Solution Architect oder einem Application Architect der nicht mit einem EA-Team zusammenarbeitet.
Anwendungsarchitekten, die in TOGAF ADM Phase C arbeiten, haben eine komplexe Rolle.
- Zusammenarbeit mit Stakeholdern und KMU, um Änderungen im Anwendungsportfolio auszuwählen, die die beste zukünftige Organisation ermöglichen
- mit ihren Kollegen arbeiten Domänenarchitekten zu untersuchen, wie im Geschäftsbereich erforderliche Verbesserungen im Anwendungsbereich ermöglicht oder verhindert werden
- Arbeiten Sie mit den Stakeholdern zusammen, um Änderungen im Anwendungsportfolio zu vermeiden, die zu wenig bringen oder zu viel kosten. Vermeiden Sie außerdem Änderungen in anderen Bereichen, die zu inakzeptablen Kosten und Änderungen im Anwendungsportfolio führen.
In TOGAF ADM Phase C, einer der vier grundlegenden Domänen der Unternehmensarchitektur wird entwickelt. TOGAF macht deutlich, dass diese Architektur parallel zur Entwicklung der anderen Domänen entwickelt wird. Änderungen in einer Domäne ermöglichen, erzwingen oder blockieren Änderungen in einer anderen Domäne.
Hochfunktionale EA-Teams setzen ihre Anwendungsarchitekten nicht als Designer einer einzelnen Anwendung ein. Diese Rolle ist notwendig, aber ohne eine Anwendungsarchitektur, die wesentliche Teile des Unternehmens abdeckt, ist eine Optimierung des Unternehmens nicht möglich.
TOGAF ADM Phase C entwickelt die Anwendungsarchitektur. Die Anwendungsarchitektur ist die Grundlage aller modernen digitalen Unternehmen. Verwenden Sie TOGAF Phase C, um Konzentrieren Sie die knappen Änderungsressourcen darauf, den größtmöglichen Unternehmenswert zu erzielen.
