TOGAF® ADM Phase C – Entwicklung der Anwendungsarchitektur

Wir entwickeln Architektur von Informationssystemen, das aus der Anwendungsarchitektur besteht und Datenarchitektur, in TOGAF ADM Phase C.

Anwendungsarchitektur ist ein Domäne der Unternehmensarchitektur. TOGAF ist sehr klar – Anwendungs- und Datenarchitektur sind untrennbar und existieren, um dies zu ermöglichen Geschäftsarchitektur.

In einem modernen digital transformiertes Unternehmen, Entscheidungen in einem Architekturbereich Ergebnisse in anderen Domänen aktivieren, liefern oder blockieren. Unternehmensziele hängen von der ab richtige IT-Architektur.

Beste Übung Anwendungsarchitektur konzentriert sich auf kritische Einschränkungen beim Kauf, der Integration und der Entwicklung von Software. Systemgrenzen und Integrationsstandards sind entscheidend. Schließlich wird Ihre Unternehmensanwendungsarchitektur die agile Entwicklung vorantreiben. Ohne diese Einschränkungen auf oberster Ebene sind Details innerhalb einer Anwendung von geringem praktischen Wert.

TOGAF ADM-Übersicht

Der TOGAF ADM ist ein logischer Ansatz zur Wissensgenerierung. Wissen zur Entwicklung einer 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ähle den Weg nach vorne und das Ziel
  • durchführen Implementierungs-Governance
  • Bewerten Sie den weiteren Weg und korrigieren Sie den Kurs

Was ist TOGAF Phase C?

Phase C treibt das Konzept der Architekturdomänen. In dieser Phase werden die Anwendungsarchitektur und die Datenarchitektur entwickelt. Formal betrachtet, behandelt Phase C die Domäne der Datenarchitektur und die Anwendungsarchitekturdomäne sind individuell.

Wie Phase B baut Phase C auf der Architekturvision auf. Es gibt jedoch einen Unterschied: Phase C hat eine weitere Verpflichtung, die Geschäftsarchitektur zu ermöglichen. Dabei wird die Geschäftsarchitektur nicht als Anforderung behandelt, sondern es wird sichergestellt, dass die sich entwickelnden Gesamtziele zusammenpassen.

Änderungen in einer Domäne führen zu Einschränkungen und Anforderungen in anderen Domänen. Das Ziel besteht darin, die besten Änderungen für alle Domänen zu finden.

Architektur von Informationssystemen

Mithilfe der Schritte der Phase C entwickeln Architekten folgende Kenntnisse:

  • Welche Referenzarchitektur wird die Architekturentwicklung beschleunigen?
  • welche Gesichtspunkte werden relevante Analysen für Stakeholder vorantreiben, um zwischen Architekturalternativen zu wählen
  • Welche Anwendungsarchitekturmodelle und Datenmodelle helfen, die Ursache des Mangels zu finden und welche Änderungen ihn beheben?
  • wo Änderungen in der Anwendungsarchitektur Änderungen in anderen Bereichen nach sich ziehen
  • wo Änderungen in anderen Domänen Änderungen in der Anwendungsarchitektur bewirken

Es entstehen folgende zentrale Werksprodukte:

  • Ansichten, die die Architektur der Kandidateninformationssysteme im Hinblick auf die Anliegen der Stakeholder analysieren
  • dass eine aktuelle und eine mögliche Zielanwendungsarchitektur
  • Lücken in der Anwendungsarchitektur
  • mögliche Arbeitsergebnisse, die das Geschäft verändern

In Phase C stehen Dinge wie Anwendungsdesign, Datenfluss, Integration, Entwicklungsansatz, Eigenbau oder Kauf und Änderungsplanung im Mittelpunkt. Eine ordnungsgemäße 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 Sie die Entwicklung Ihrer Anwendungsarchitektur. Der architektonische Entscheidungen Die in Phase C für die Anwendungsarchitektur erstellten Elemente interagieren mit den in jeder Phase getroffenen Entscheidungen Domäne der Unternehmensarchitektur.

 

Phase C in Aktion

Die Anwendungsarchitektur hilft bei der Beantwortung der folgenden Fragen:

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

Denken Sie immer daran, dass Sie versuchen, die Organisation zu verbessern. Verbesserung erfordert Veränderung und liefert Wert. Wert und Kosten der Änderung können gemessen werden. Unsicherheit verringert immer den potenziellen Wert. Unsicherheit erhöht immer die Kosten. Wir behandeln Unsicherheit als geometrische Auswirkung. Ein wenig Unsicherheit verringert den potenziellen Wert erheblich.

Denken Sie beim Lesen daran, dass es viele Verwendungen derselben Begriffe gibt. Suchen Sie nach dem Zweck des Modells und lassen Sie sich nicht gefangen nehmen, wenn das Etikett von dem abweicht, was Sie es nennen würden. Was Sie beispielsweise als funktionales Modell bezeichnen, wird jemand anderes als Service bezeichnen. In unserer Unternehmensarchitekturberatung, konzentrieren wir uns immer auf das, was wir zu verstehen versuchen, nicht auf den Namen des Modells.

Verschiedene Modelle erklären verschiedene Aspekte des Unternehmens. Zusammen bilden die Modelle und die erforderlichen Änderungen die Anwendungsarchitektur.

Was ist Anwendungsarchitektur?

Eine Anwendungsarchitektur ist eine Beschreibung Ihres gesamten Softwareportfolios, die Ihnen sagt, wann Sie kaufen, wann Sie SaaS verwenden und wann Sie bauen müssen. Es sagt Ihnen, wo Sie Grenzen zwischen Systemen ziehen sollten. Es sagt Ihnen, wie Sie Ihren Software-Lebenszyklus angehen werden.

Wir können garantieren, dass Ihre aktuelle Anwendungsarchitektur nicht an Ihrer Geschäftsarchitektur ausgerichtet ist. Eine Anwendungsarchitektur erfordert a Geschäftsarchitektur. Die Entwicklung der Geschäftsarchitektur erfordert, dass Anwendungsarchitekten sich ihnen anschließen und mit Interessenvertretern zusammenarbeiten.

Zusammen mit dem Stakeholder und dem Geschäftsarchitekten untersucht der Anwendungsarchitekt, wie Softwareentscheidungen die Ziele der Organisation ermöglichen und einschränken. Wir betrachten mögliche Verbesserungen, um die unmittelbaren und mittelfristigen Auswirkungen zu verstehen. Gemeinsam werden potenzielle Änderungen, die zu wenig liefern, zu viel Arbeit erfordern oder zu viele Unsicherheiten aufweisen, aus der Architektur-Roadmap gestrichen.

Wenn wir sind Entwicklung von Unternehmensarchitekturteams, sagen wir den Unternehmensarchitekten zwei zentrale Fakten zu TOGAF Phase C - Anwendungsarchitektur. Erstens, bis Sie eine haben Anwendungsentwicklungsmodell, Sie können nicht fortfahren. Bis Sie wissen, wie Ihre Anwendungsauswahl Ihre Geschäftsarchitektur ermöglicht und einschränkt, sind die Details Ihrer Anwendungen sinnlos. Zweitens, wenn sie glauben, dass sie in die Anwendungsfunktionalität und -integration einsteigen müssen, werden sie immer eine Anwendungsarchitektur von geringer Qualität entwickeln.

In einem modernen digital transformiertes Unternehmen, interagieren alle Architekturdomänen. Entscheidungen in einer Domäne aktivieren, liefern oder blockieren Ergebnisse in einer anderen Domäne. Die meisten Geschäftsziele hängen davon ab richtige IT-ArchitekturIronischerweise können wir nur dann die richtige Anwendungsarchitektur 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 Rolle des Unternehmensarchitekten darin, den gesamten Wert zu schützen. Abhängig von den Fähigkeiten der Domänenarchitekten muss der Unternehmensarchitekt ausfüllen. Beispielsweise sieht ein Anwendungsarchitekt möglicherweise nicht die Auswirkungen von Änderungen in der Geschäftsarchitektur. Oder sie formulieren keine Anforderung in Bezug auf die Sicherheitsarchitekten, auf die sie reagieren können.

Die wichtigste Rolle des Unternehmensarchitekten ist das Überschreiten von Grenzen. Unabhängig davon, ob es sich um Domänen-, Kompetenz- oder Autoritätsgrenzen handelt, muss der Unternehmensarchitekt sie überschreiten.

Welche Rolle spielt der Anwendungsarchitekt in Phase C?

In TOGAF Phase C erwarten wir, dass der Anwendungsarchitekt die Domänenarchitektur liefert. Das erfordert die Entwicklung von Modellen, die die Quelle des Mangels zeigen und wie man ihn überwindet. Sie führen Trade-Off-Analysen mit Stakeholdern durch, um die Zielarchitektur zu bestimmen.

Der Anwendungsarchitekt muss mit den anderen Domänenarchitekten zusammenarbeiten.

Schalten Sie die Geschäftsarchitektur aus. Kennen und verstehen Sie die Betriebsmodell und die Kompetenz- und Automatisierungsattribute der Fähigkeitsmodell.

Was ist die Rolle des Sicherheitsarchitekten in Phase C?

In TOGAF Phase C erwarten wir, dass der Anwendungsarchitekt die Domänenarchitektur liefert. Das erfordert die Entwicklung von Modellen, die die Quelle des Mangels zeigen und wie man ihn überwindet. Sie führen Trade-Off-Analysen mit Stakeholdern durch, um die Zielarchitektur zu bestimmen.

Der Anwendungsarchitekt muss mit den anderen Domänenarchitekten zusammenarbeiten.

Schalten Sie die Geschäftsarchitektur aus. Kennen und verstehen Sie die Betriebsmodell und die Kompetenz- und Automatisierungsattribute der Fähigkeitsmodell.

Denken Sie daran, dass Mängel in einem Bereich oft in einem anderen behoben werden und Änderungen in einem Bereich oft Kosten und Änderungen in einem anderen verursachen.

Welche Rolle spielt das EA-Team in der Anwendungsarchitektur?

Denken Sie daran, dass Mängel in einem Bereich oft in einem anderen behoben werden und Änderungen in einem Bereich oft Kosten und Änderungen in einem anderen verursachen.

Wechselwirkung mit TOGAF Phase B, Phase D und Phase E

Wasserfallansätze liefern nicht. Best-Practice-Unternehmensarchitektur ist keine Wasserfallaktivitä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 Sequenz, 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 stimmte früher nicht und ist in einem modernen digitalen Unternehmen lächerlich. Diese Illusion ist der schnellste Weg, sie zu beseitigen Unternehmensagilität oder die Möglichkeit digitale Transformation Erfolg.

Anwendungsarchitekten spielen eine entscheidende Rolle in einem Unternehmensarchitekturteam. Ohne Software läuft in einem modernen digitalen Unternehmen nichts. Schlechte Anwendungsauswahl wird lähmendas Geschäft.' Anwendungsarchitekten sind Spezialisten in einer Architekturdomäne. Sie können ihre Domäne nicht ohne regelmäßiges Engagement mit entwerfen Geschäftsarchitekten, Daten, Technologie und Sicherheitsarchitekten.

Laden Sie den KI-Leitfaden für Führungskräfte herunter

Laden Sie den Leitfaden für Führungskräfte zur künstlichen Intelligenz herunter. Organisationen, die innovative Technologie erfolgreich anwenden, haben einen Wettbewerbsvorteil. Innovative Technologie geht nicht mit etablierten Erfolgsmustern und Best Practices einher. Innovative Technologie ist neuartig und […]

Laden Sie die Einführung in den TOGAF-Standard, 10. Ausgabe, herunter

Herunterladen Einführung in den TOGAF®-Standard, 10. Ausgabe Der TOGAF-Standard, 10. Ausgabe, erleichtert die Einführung von Best Practices für Unternehmensarchitekturen. Es trennt die universellen Konzepte von bewährten Best Practices. Der Standard-Unterstrich wo […]

Laden Sie den Leitfaden zur fähigkeitsbasierten Planung herunter

Laden Sie den Leitfaden zur fähigkeitsbasierten Planung herunter. Streben Sie stets danach, Werte zu realisieren. Eine halbe Verbesserung ist 100% Verschwendung! Niemand bringt einem Adler das Krabbeln, Gehen oder Laufen bei. Adler fliegen! Laden Sie „Teach your Eagles to Fly: Capability-based Planning“ herunter […]

Laden Sie den Leitfaden zur Bewertung der Geschäftsarchitektur herunter

Leitfaden zur Bewertung der Geschäftsarchitektur herunterladen Laden Sie einen Leitfaden zur Bewertung der Geschäftsarchitektur herunter. Die fähigkeitsbasierte Planung ist eine der leistungsstärksten Techniken zur Verbesserung der Geschäftsarchitektur. Best Practice der fähigkeitsbasierten Planung nutzt Fähigkeit als Management […]

Laden Sie Beispiele für Prinzipien der Unternehmensarchitektur herunter

Beispielprinzipien für die Architektur herunterladen Laden Sie ein Beispiel für Prinzipien der Unternehmensarchitektur herunter. Die Prinzipien der Unternehmensarchitektur legen fest, wie man ein Problem oder eine Entscheidung angeht. Der Ansatz treibt Sie immer zu Ihren dauerhaften Prioritäten. Beispielprinzipien der Unternehmensarchitektur herunterladen […]

Laden Sie den Governance-Leitfaden für Unternehmensarchitekturen herunter

Leitfaden zur Unternehmensarchitektur-Governance herunterladen Laden Sie den Leitfaden zur Unternehmensarchitektur-Governance herunter, um Best Practices zur Lenkung und Kontrolle der Entwicklung von Architekturen und Änderungen zu verstehen, um die erwarteten Ergebnisse zu erzielen. Governance-Leitfaden für Unternehmensarchitektur herunterladen […]

Laden Sie die TOGAF- und SABSA-Integration herunter

TOGAF- und SABSA-Integration herunterladen Bringen Sie SABSA, das weltweit beste Sicherheitsarchitektur-Framework, und TOGAF, das Industriestandard-Unternehmensarchitektur-Framework, zusammen. TOGAF- und SABSA-Integration herunterladen TOGAF- und SABSA-Integration Beinhaltet SABSA verwendet ein […]

Laden Sie die Enterprise Architecture Capability Reference Architecture herunter

Laden Sie die Referenzarchitektur „Enterprise Architecture Capability“ herunter. Die Referenzarchitektur „Enterprise Architecture Capability“ beschleunigt den Aufbau und die Weiterentwicklung Ihres EA-Teams. Gestalten Sie Ihr Enterprise-Architecture-Team für den Erfolg. Identifizieren und verbessern Sie die Architektur Ihres Unternehmens […]

Laden Sie den Agile Enterprise Architecture Report herunter

Laden Sie den Agile Enterprise Architecture Report herunter Der Agile Enterprise Architecture Report deckt unsere Erfahrung ab – Agile Enterprise Architecture ist real, praktisch und wertvoll. Wir tun es jeden Tag. Erfahrungsberichte überbrücken die theoretischen Konzepte und […]

Fallstudie zur agilen Unternehmensarchitektur herunterladen

Laden Sie die Fallstudie „Agile Unternehmensarchitektur“ herunter Laden Sie die Fallstudie „Agile Unternehmensarchitektur“ herunter, um ein Beispiel für die gleichzeitige Entwicklung einer EA-Fähigkeit und einer nützlichen Architektur zu sehen. Wir decken alle sechs Anwendungsfälle ab […]

Grundlegendes Wissen für Phase C

Alle TOGAF ADM-Phasen führen Sie dazu, das Wissen zu entwickeln, das Sie benötigen. Das Ergebnis von Phase C ist die Kandidatenanwendungsarchitektur, die in der Kandidateninformationssystemarchitektur enthalten ist.

Ausgabe & Ergebnis Wesentliches Wissen
Der Anwendungsarchitektur Domänenarchitektur die von den Interessengruppen für das zu behandelnde Problem mit einer Reihe von Lücken genehmigt wurden, und daran arbeiten, die von den Interessengruppen verstandenen Lücken zu schließen. Wie das aktuelle Software-Portfolio die Präferenzen der Stakeholder nicht erfüllt?

Was muss sich ändern, damit das Softwareportfolio den Präferenzen der Stakeholder entspricht? (Lücken)

Welche Arbeiten sind notwendig, um die Veränderungen zu realisieren, die mit der Wertschöpfung vereinbar sind? (Arbeitspaket)

Wie sich die Priorität und Präferenz von Stakeholdern als Reaktion auf Wert, Aufwand und Änderungsrisiko anpassen. (Stakeholder-Anforderungen)

Tabelle 4 aus Leitfaden der TOGAF-Reihe: Leitfaden für Unternehmensarchitekten zur Entwicklung von Architekturen

Phase C Bare Bones

In Phase C können wir die Arbeit eines Anwendungsarchitekten vereinfachen, um festzustellen, wie ein Unternehmen besser werden sollte. Dazu muss man verstehen, worin es gut sein möchte, wo es hinter den Besten zurückbleibt und was sich ändern muss, um der Beste zu sein.

Die nackten Knochen von Phase C sind:

  • Zu wissen, wie das Anwendungsportfolio es ermöglicht, Werte zu erfassen

Jede Organisation hat eine Wertschöpfungskette. Aktivität, die eine Eingabe in etwas Wertvolleres für ihre Kunden verwandelt. Anwendungen führen entweder eine Wertschöpfung durch oder liefern Aufzeichnungen. Traditionell lieferte fast jede Software Aufzeichnungen.

Sie müssen Ihre Software für die Rolle optimieren – Wertschöpfung oder Aufzeichnungen. Übernehmen Sie die Aufzeichnungen. Verwechseln Sie die wichtige Rolle der Aufzeichnungen nicht mit der Wertschöpfung.

  • Die Quelle von Kosten und Komplexität kennen

Jedes Anwendungsportfolio verursacht Kosten und Komplexität. Wir betrachten Software als ein komplexes Uhrwerk, das im Laufe der Zeit zusammengestellt wurde. Wir haben alles mit allem verbunden. Mit digitalen Produkten und allgegenwärtigen IT-Diensten ITFM verstehen ist eine grundlegende Fähigkeit.

Sie müssen Ihr Kernportfolio optimieren, um nachhaltige Kosten und Komplexität zu vermeiden. Sie müssen aktivieren Unternehmensagilität. Moderne digitale Organisationen können sich nur im Tempo der Software verbessern.

  • Wissen, wie man Software auswählt

Es gibt vier Softwaremodelle: SaaS, Unternehmenssuiten, kommerzielle Spezialpakete und kundenspezifische Entwicklung. Jedes hat ein anderes Kosten- und Optimierungsmodell. Sie müssen das richtige Softwaremodell an den richtigen Stellen anwenden.

  • Wissen, wann die Software Teil von 'das Produkt'

Unsere Organisationen liefern ein Produkt oder eine Dienstleistung. Software, die 'das Produkt' unterscheidet sich stark 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 proaktiv eine Situation erkennen und reagieren. Software tut genau das, was ihr gesagt wird. Software tut nur, was ihr gesagt wird.

Der Informationsfluss findet rund um die Software statt, um das Richtige zu erledigen. Diese Art des Informationsflusses beeinträchtigt die Agilität des Unternehmens. Sie lähmen die Effizienz. Diese Flüsse treiben die Kosten.

  • Die Erwartungen an Software kennen

Manchmal brauchen wir einen lässigen Protokollführer. Manchmal brauchen wir ein autonomes System. Meistens brauchen wir etwas, das ohne zu viel Overhead hilft. Wir nutzen die Konzepte und Attribute in Fähigkeitsmodelle um Entscheidungen über unsere Anwendungsarchitektur zu treffen. Siehe die Leitfaden zur Bewertung der Geschäftsarchitekturfähigkeiten.

  • Wissen, was die Organisation tun muss

Jedes Unternehmen hat eine Reihe von Prozessen, die es ausführen muss: primäre Wertschöpfung, Unterstützung und Verwaltung. Jeder von ihnen braucht Software. Jeder von ihnen erstellt und produziert Informationen. Sie müssen wissen, was sie sind, welche Informationen sie verbrauchen und wer sie macht.

  • Was muss sich ändern, um das beste Anwendungsportfolio zu liefern?

Wir entwickeln Anwendungsarchitekturen, um eine Organisation zu verbessern. Die meisten Änderungen machen keinen wesentlichen Unterschied. Die meisten Änderungen basteln an den Rändern herum. Konzentrieren Sie Ihre Zeit auf wesentliche Veränderungen, die eine sinnvolle Unternehmensagilität, Kosten oder Wertschöpfung fördern.

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

  • Zuerst, was muss sich ändern? Änderung des Fokus, Organisationsdesign, Höherqualifizierung, Outsourcing, Insourcing, Automatisierung. Das sind alles Änderungen. Wir nehmen sie vor, um eine Organisation zu verbessern.
  • Sekunde, wann muss es geändert werden? Gibt es Abhängigkeiten? Wie sieht es mit Voraussetzungen aus? Bereiten Sie mit Ihren Änderungen die Voraussetzungen für eine spätere Änderung vor?
  • Dritter, wie werden Sie wissen, 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 sowie die zweiten und dritten Ergebnisse steuern können.

Enterprise Architecture Training und TOGAF Training

Benutzerdefinierte Schulung für Unternehmensarchitektur

Maßgeschneiderte Schulungen zu Unternehmensarchitekturen Maßgeschneiderte Schulungen zu Unternehmensarchitekturen zielen auf die berufliche Weiterentwicklung ab, die Ihr EA-Team benötigt. Gute Unternehmensarchitekten verwenden ein breites Spektrum an Fähigkeiten und Methoden sowie spezialisiertes Domänenwissen, um Unternehmen zu entwickeln […]

Avolution ABACUS-Schulungskurs

Avolution ABACUS Training Effektive Unternehmensarchitektur basiert auf formaler Modellierung und Analyse. Wir bieten Avolution ABACUS-Schulungen von praxisorientierten Unternehmensarchitekten an. Die Studierenden erwerben Fähigkeiten und Kenntnisse zur Erstellung integrierter Unternehmens- und Domänenarchitekturen in diesem […]

Kickstart für Enterprise-Architekten

Kickstart für Enterprise-Architekten 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 bereitzustellen. Dieser 90-tägige Kickstart ist der Weg, den Conexiam Consulting […]

TOGAF-Schulungskurs für Unternehmensarchitektur

Möchten Sie eine Schulung zur TOGAF-Zertifizierung? Demonstrieren Sie Ihr Wissen über Unternehmensarchitektur mit der TOGAF-Zertifizierung. TOGAF® Enterprise Architecture-Schulungskurs Machen Sie einen großen Schritt, um ein besserer Unternehmensarchitekt zu werden mit TOGAF Standard, 10. […]

Schulungskurs für Unternehmensarchitektur

Business-Architektur-Schulung Effektive Unternehmensarchitektur basiert auf der Geschäftsarchitektur. Der Kurs vermittelt den Studierenden die Fähigkeiten und das Wissen, um eine Geschäftsarchitektur in einer Unternehmensarchitekturumgebung zu entwickeln. Bei der Geschäftsarchitektur geht es um die Beschreibung der Struktur des […]

Effektive Online-Bildung

Effektive Online-Bildung Effektive Online-Bildung funktioniert. Studenten haben Zugang zum besten verfügbaren Lehrer. Studenten bestimmen ihr Lerntempo. Lehrer können reichhaltiges Zusatzmaterial bereitstellen, ohne vom Hauptthema abzulenken. Effektive Distanz […]

Ergebnisse der TOGAF ADM-Anwendungsarchitektur Phase C

Ein zentrales Ergebnis der Phase C ist eine Anwendungsarchitektur. Dies ist ein Teil der gesamten Unternehmensarchitektur.

TOGAF Phase C - Ergebnisse der Anwendungsarchitektur und Anwendungsfälle der Unternehmensarchitektur

Es gibt vier Hauptzwecke für die Entwicklung einer Unternehmensarchitektur. Verschiedene TOGAF-Phase-C-Ergebnisse haben für jeden Zweck unterschiedliche Bedeutung.

Architektur zur Unterstützung der Strategie Architektur zur Unterstützung des Portfolios Architektur zur Unterstützung des Projekts Architektur zur Unterstützung der Lösungsbereitstellung
Arbeitsprodukt der Phase C: Kandidatenanwendungsarchitektur Schlüssel lieferbar

Primärer Nutzen ist das Stakeholder-Verständnis von Ziel und Arbeit.

Sekundäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Architekten

Schlüssel lieferbar

Primärer Nutzen ist das Stakeholder-Verständnis von Ziel und Arbeit.

Sekundäre Verwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Architekten

Vor Projektinitiierung und Finalisierung des Business Case

Hauptanwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Implementierer

Vor Beauftragung von Ausführungspartnern (einschließlich interner Anbieter)

Hauptanwendung ist die Erstellung von Architektur-Anforderungsspezifikationen für Implementierer

Arbeitsprodukt der Phase C: Kandidaten-Roadmap-Elemente Schlüssel lieferbar

Primärer Nutzen ist das Verständnis der Arbeit durch die Stakeholder.

Sekundäre Verwendung ist die Erstellung von Einschränkungen für Architekten

Schlüssel lieferbar

Primärer Nutzen ist das Stakeholder-Verständnis von Arbeit und Abhängigkeit.

Sekundäre Verwendung ist die Erstellung von Einschränkungen für Architekten

Eingeschränkte Nutzung
Kann als Eingabe für Projekte mit mehreren interaktiven Änderungen verwendet werden
Vor Beauftragung von Ausführungspartnern (einschließlich interner Anbieter).

Der Hauptzweck ist die Identifizierung erforderlicher Änderungen und Präferenzen für die Durchführung von Änderungen, um die Auswahl und das Engagement von Partnern für die Lösungsbereitstellung zu verwalten

Arbeitsprodukt der Phase C: Spezifikation der Architekturanforderungen Eingeschränkte Nutzung

Normalerweise können Architekten Einschränkungen aus überlegener Architektur ableiten.

Eingeschränkte Nutzung

Normalerweise können Architekten Einschränkungen aus überlegener Architektur ableiten.

Schlüssel lieferbar

Vor Abschluss der Projektinitiierung

Schlüssel lieferbar

Vor Verlobung und Vertragsabschluss

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

 

Kandidatenanwendungsarchitektur

Es gibt vier Hauptzwecke für die Entwicklung einer Unternehmensarchitektur. Unterschiedliche Modelle haben für jeden Zweck unterschiedliche Bedeutung.

Komponenten der Kandidaten-Anwendungsarchitektur-Roadmap

Was muss sich ändern? Wenn Sie das Anwendungsentwicklungsmodell ändern, ist der Unterschied zwischen aktuell und Ziel der Roadmap-Kandidat. Also ist alles nötig, um diese Veränderung zu ermöglichen.

Wir verwenden oft ein Systemmodell, um die Änderung zusammenzufassen. Das Systemmodell ermöglicht gerade genug Abstraktion von echter Software, um eine Planungs- und Ausführungsdiskussion zu führen. Wir verwenden normalerweise Punktzahlen und Arbeitspakete, um eine Änderung zu artikulieren. Weitere Informationen zur Verwendung von Partituren finden Sie unter Leitfaden zur Bewertung der Geschäftsarchitekturfähigkeiten.

Wir verwenden alle Architektur-Roadmap-Komponenten in TOGAF Phase E - Architektur-Roadmap.

Anforderungsspezifikation für die Kandidatenanwendungsarchitektur

Definieren Sie, wie Sie die Änderung bewerten. Wie wird die Verbesserung bewertet?

Wir verwenden in unseren Modellen häufig Punktzahlen, um Anforderungen zu beschreiben. Jede Anforderung ist ein Maß für Effizienz, Automatisierung, Agilität oder Leistung. Dann, wenn wir arbeiten TOGAF-Phase G durchführen Architektur-Governance mit einem Change-Projekt Wir verwenden diese Bewertungen, um Designs und Implementierungen zu bewerten.

Gehen Sie noch einen Schritt weiter mit Best Practice-Prozessen und -Methoden für die Unternehmensarchitektur

Beste Übung Unternehmensstruktur aus Conexiam navigieren

Einrichten eines Prüfungsgremiums für moderne Architektur

Einrichten eines modernen Architekturprüfungsgremiums Um ein modernes Architekturprüfungsgremium einzurichten, ist die Schaffung eines dynamischen Governance-Prozesses und die Einrichtung eines Entscheidungsgremiums auf höchster Ebene erforderlich, das als Rückhalt fungiert. Ziel ist die Einrichtung einer effektiven Architektur-Governance ohne Bürokratie. […]

Arbeitsmanagement für die Unternehmensarchitektur

Enterprise Architecture Work Management Enterprise Architecture Work Management ist entscheidend für den täglichen Erfolg eines Enterprise Architecture-Teams. Architekten müssen nützliche Anleitungen liefern, bevor die Beteiligten fundierte Entscheidungen treffen. Enterprise-Architekten müssen die […]

Die Kraft der fähigkeitsbasierten Planung freisetzen: Eine Kurzanleitung

Nutzen Sie die Möglichkeiten der fähigkeitsbasierten Planung: Eine Kurzanleitung Suchen Sie nach einer effektiveren Möglichkeit, Ihre Geschäftsstrategie zu planen und umzusetzen? Dann ist die fähigkeitsbasierte Planung genau das Richtige für Sie. Identifizieren und Nutzen Ihrer Organisation […]

So definieren Sie Prinzipien der Unternehmensarchitektur

So definieren Sie Prinzipien der Unternehmensarchitektur Um Prinzipien der Unternehmensarchitektur zu definieren, müssen Sie zunächst verstehen, was ein Prinzip ist und wie man es anwendet. Dann können wir starke Architekturprinzipien entwickeln, die dazu beitragen, unsere Organisation zu verbessern. […]

Enterprise Architecture Framework Vergleich: Welches ist das Richtige für Sie?

Vergleich von Enterprise-Architektur-Frameworks: Welches ist das Richtige für Sie? In der Wirtschaft gibt es keine Einheitslösung. Auch nicht bei Enterprise-Architektur-Frameworks. Vergleichen Sie die Vorzüge beliebter Frameworks, um herauszufinden, welches optimierte Framework das Richtige für Sie ist. Während […]

Unternehmensarchitektur und Agilität verstehen

Unternehmensarchitektur und Agile verstehen Sowohl agile als auch Unternehmensarchitektur sind darauf ausgelegt, Risiken zu reduzieren. Agile Softwareentwicklung zeichnet sich dadurch aus, dass sie etwas schafft, das wir noch nie zuvor hatten und von dem wir nicht wissen, wie man es baut. […]

Erschließen Sie Ihr Geschäftspotenzial: So erstellen Sie eine effektive Fähigkeitskarte

Erschließen Sie Ihr Geschäftspotenzial: So erstellen Sie eine effektive Fähigkeitskarte. Fällt es Ihnen schwer, die Fähigkeiten zu identifizieren, die Sie benötigen, um Ihr Unternehmen auf die nächste Stufe zu bringen? Finden Sie es schwierig, Ressourcen aufeinander abzustimmen?

Szenarioanalyse für die Unternehmensarchitektur nutzen

Szenarioanalyse für die Unternehmensarchitektur verwenden Ein Szenario ist einfach eine plausible Zukunft. Die Szenarioanalyse untersucht, wie wir zu einer plausiblen Zukunft gelangen und wie sich unterschiedliche Szenarien auf unsere aktuellen Entscheidungen auswirken. Szenarien helfen Führungskräften […]

Entwicklung einer Architekturansicht

Die Entwicklung einer Architekturansicht Die Unternehmensarchitektur ist ein wesentlicher Kompass. Es hilft Unternehmen, die Komplexität von Technologie, Strategie und Betrieb zu bewältigen. Der Kern der Unternehmensarchitektur ist ein systematischer Ansatz. Ziel ist es sicherzustellen, dass […]

Entwicklung einer Strategie für die Unternehmensarchitektur

Entwicklung einer Strategie für die Unternehmensarchitektur: Strategischer Plan für Veränderungen Eine Strategie für die Unternehmensarchitektur ist eine Aktion. Die Maßnahmen, die Ihr Unternehmen ergreifen wird, und die Veränderungen, die Sie vornehmen werden, um Ihre strategischen Ziele zu erreichen. Bei der Strategieentwicklung geht es vor allem um Entscheidungen. […]

Modelle, Tools und Techniken der Anwendungsarchitektur

Die TOGAF ADM Phase C liefert die Informationssystemarchitektur. Diese Phase besteht darin, die Anwendungsarchitektur und die Datenarchitektur zu entwickeln, aus denen die Informationssysteme bestehen. In TOGAF besteht der erste Schritt darin, die erforderlichen Ansichten und die erforderlichen Modelle zu bestimmen.

Stakeholder Concerns werden die Ansichten identifizieren. Es gibt sieben zentrale Anwendungsarchitekturmodelle.

  • Anwendungsentwicklungsmodell, das die akzeptable Methode beschreibt, mit der ein System entwickelt wird
  • Systemmodell, das die großen Systeme erfasst, auf die Ihr Anwendungsportfolio ausgelegt ist
  • Funktionsmodell, das alle Dinge beschreibt, die Ihr Softwareportfolio erfüllen muss
  • Produktmodell, das die Funktionalität identifiziert, die in den Produkten und Diensten Ihrer Organisation verwendet wird, sowie diejenigen, die sie verwalten
  • Das Integrationsmodell beschreibt, wie Informationen durch Ihr Anwendungsportfolio fließen
  • Das Servicemodell zerlegt Ihr Anwendungsportfolio in Blackboxes und ermöglicht es Ihnen, sicherzustellen, dass jeder Service über die erforderliche Agilität, Automatisierung und andere erforderliche Attribute verfügt
  • Physical Model identifiziert die echten kommerziellen, SaaS- oder kundenspezifischen Anwendungen in Ihrem Anwendungsportfolio

Die Anwendungsarchitektur hilft bei der Beantwortung der folgenden Fragen:

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

Denken Sie immer daran, dass Sie versuchen, die Organisation zu verbessern. Verbesserung erfordert Veränderung und liefert Wert. Wert und Kosten der Änderung können gemessen werden. Unsicherheit verringert immer den potenziellen Wert. Unsicherheit erhöht immer die Kosten. Wir behandeln Unsicherheit als geometrische Auswirkung. Ein wenig Unsicherheit verringert den potenziellen Wert erheblich.

Denken Sie beim Lesen daran, dass es viele Verwendungen derselben Begriffe gibt. Suchen Sie nach dem Zweck des Modells und lassen Sie sich nicht gefangen nehmen, wenn das Etikett von dem abweicht, was Sie es nennen würden. Was Sie beispielsweise als funktionales Modell bezeichnen, wird jemand anderes als Service bezeichnen. In unserer Unternehmensarchitekturberatung, konzentrieren wir uns immer auf das, was wir zu verstehen versuchen, nicht auf den Namen des Modells.

Verschiedene Modelle erklären verschiedene Aspekte des Unternehmens. Zusammen bilden die Modelle und die erforderlichen Änderungen die Anwendungsarchitektur.

Anwendungsarchitekturmuster

Wir gebrauchen Architekturmuster um die Produktivität und Qualität unserer Architekturentwicklung drastisch zu steigern. Die Architekturmustervorlage treibt uns zum Verständnis der vorhersehbares Problem, Musteransatz, und das Harte Teile. Um mit diesem Muster erfolgreich zu sein, müssen die Harte Teile (erforderliche Arbeit, Einschränkungen und Beschränkungen).

Beispielmuster für Anwendungsarchitekturen

Beispielhafte Anwendungsarchitekturmuster decken das Problem der Anwendungsstruktur, der Migration und des Anwendungsdesigns ab.

  • Anwendungsstruktur
    • MVC-Muster (Model-View-Controller).
      Vorhersehbares Problem– Codeorganisation, Wartbarkeit und Testbarkeit
      Ansatz– trennt 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).
  • Anwendungsmigration
    • Strangler-Muster
      Vorhersehbares Problem– Ersetzen von Altsystemen
      Ansatz– Ersetzen oder „erwürgen“ Sie schrittweise ein vorhandenes Altsystem, indem Sie neue Komponenten darauf aufbauen, um das System schrittweise zu ersetzen
  • Anwendungsdesign (Gruppe von vier Anwendungsmustern)
    Als Unternehmensarchitekten nutzen wir Entwurfsmuster als Einschränkungen für die Freiheit von Anwendungsentwicklungsteams. (Sehen Unternehmensarchitektur und Agilität – 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 Modelle der Unternehmensarchitektur. Jeder erklärt das Softwareportfolio des Unternehmens anders. Bei der TOGAF-Phase-C-Anwendungsarchitektur geht es darum, die Zielarchitektur mithilfe dieser Modelle zu entwickeln. Stellen Sie sicher, dass der Zielanwendungsarchitekt mit den anderen Domänen zusammenarbeitet, um die bestmögliche Verbesserung für Ihr Unternehmen zu ermöglichen.

Zusammengenommen beschreiben die Modelle die Anwendungsarchitektur. In der vollständigen Unternehmensarchitektur werden diese Modelle mit anderen Modellen verknüpft, die die anderen Bereiche der Unternehmensarchitektur beschreiben.

 

Anwendungsentwicklungsmodell

Das Anwendungsentwicklungsmodell beschreibt, wie Software entwickelt wird. Das Modell erfordert ein funktionales oder physisches Modell. Das Funktionsmodell ist viel besser, weil es eine logische Identifikationssoftware ist.

Es gibt vier Anwendungsentwicklungstypen: SaaS, Enterprise-Suiten, spezialisierte kommerzielle Pakete und kundenspezifische Entwicklung. Jeder Typ hat einzigartige Eigenschaften und Auswirkungen.

  • SaaS-Merkmale umfassen Softwarepakete mit gut definierten Schnittstellen. Ein Dritter kontrolliert den Lebenszyklus. Anpassung ist nicht verfügbar.

Am besten geeignet für geschäftliche Aktivitäten, die administrativer Natur sind und indirekt wertschöpfende Aktivitäten unterstützen. Die strengen Softwareeinschränkungen führen zu Beschränkungen in der Geschäftstätigkeit und tragen dazu bei, die Einführung von branchenüblichen Praktiken zu erzwingen.

  • Zu den Merkmalen von Unternehmenssuiten gehören mehrere überlappende Funktionsmodelle mit einem definierten Datenmodell. Schnittstellen und Funktionalität können konfiguriert oder angepasst werden. Anpassungen verursachen während des Lebenszyklus ausnahmslos zusätzliche Kosten. Der Lebenszyklus wird von einem Dritten beeinflusst.
  • Zu den Merkmalen der Fachhandelspakete gehören Punktfokussierung und funktionale Optimierung für die Fachtätigkeit. In der Regel um eine Herangehensweise an die Geschäftstätigkeit herum konzipiert. Verfügt normalerweise über ein eindeutiges, genau definiertes Datenmodell. Schnittstellen und Funktionalität sind konfigurierbar. Anpassung könnte möglich sein. Anpassungen verursachen während des Lebenszyklus ausnahmslos erhebliche Kosten. Der Lebenszyklus wird stark von Dritten beeinflusst.
  • Zu den Merkmalen der benutzerdefinierten Entwicklung gehört die direkte Ausrichtung zwischen den alten Organisationsgrenzen und -aktivitäten Ihres Unternehmens. Ausnahmslos darauf ausgelegt, das bestehende Kommunikationsmodell Ihrer Organisation zu unterstützen. Punktuelle Fokussierung und funktionale Optimierung für die Fachtätigkeit. Erwarten Sie ein schlecht definiertes Datenmodell. Schnittstellen und Funktionalität müssen angepasst werden. Das Lebenszyklusmanagement wird in der Regel vernachlässigt und ist mit hohen laufenden Kosten verbunden.

Am besten geeignet für Geschäftsaktivitäten in der primären Wertschöpfungskette. Die Flexibilität ermöglicht eine Optimierung der Wertschöpfung. Eine effektive Nutzung erfordert das Verständnis der Wertschöpfung heute und in der Zukunft.

Anwendungsentwicklungsmodell

Das Anwendungsentwicklungsmodell beschreibt, wie Software entwickelt wird. Das Modell erfordert ein funktionales oder physisches Modell. Das Funktionsmodell ist viel besser, weil es eine logische Identifikationssoftware ist.

Es gibt vier Anwendungsentwicklungstypen: SaaS, Enterprise-Suiten, spezialisierte kommerzielle Pakete und kundenspezifische Entwicklung. Jeder Typ hat einzigartige Eigenschaften und Auswirkungen.

  • SaaS-Merkmale umfassen Softwarepakete mit gut definierten Schnittstellen. Ein Dritter kontrolliert den Lebenszyklus. Anpassung ist nicht verfügbar.

Am besten geeignet für geschäftliche Aktivitäten, die administrativer Natur sind und indirekt wertschöpfende Aktivitäten unterstützen. Die strengen Softwareeinschränkungen führen zu Beschränkungen in der Geschäftstätigkeit und tragen dazu bei, die Einführung von branchenüblichen Praktiken zu erzwingen.

  • Zu den Merkmalen von Unternehmenssuiten gehören mehrere überlappende Funktionsmodelle mit einem definierten Datenmodell. Schnittstellen und Funktionalität können konfiguriert oder angepasst werden. Anpassungen verursachen während des Lebenszyklus ausnahmslos zusätzliche Kosten. Der Lebenszyklus wird von einem Dritten beeinflusst.
  • Zu den Merkmalen der Fachhandelspakete gehören Punktfokussierung und funktionale Optimierung für die Fachtätigkeit. In der Regel um eine Herangehensweise an die Geschäftstätigkeit herum konzipiert. Verfügt normalerweise über ein eindeutiges, genau definiertes Datenmodell. Schnittstellen und Funktionalität sind konfigurierbar. Anpassung könnte möglich sein. Anpassungen verursachen während des Lebenszyklus ausnahmslos erhebliche Kosten. Der Lebenszyklus wird stark von Dritten beeinflusst.
  • Zu den Merkmalen der benutzerdefinierten Entwicklung gehört die direkte Ausrichtung zwischen den alten Organisationsgrenzen und -aktivitäten Ihres Unternehmens. Ausnahmslos darauf ausgelegt, das bestehende Kommunikationsmodell Ihrer Organisation zu unterstützen. Punktuelle Fokussierung und funktionale Optimierung für die Fachtätigkeit. Erwarten Sie ein schlecht definiertes Datenmodell. Schnittstellen und Funktionalität müssen angepasst werden. Das Lebenszyklusmanagement wird in der Regel vernachlässigt und ist mit hohen laufenden Kosten verbunden.

Am besten geeignet für Geschäftsaktivitäten in der primären Wertschöpfungskette. Die Flexibilität ermöglicht eine Optimierung der Wertschöpfung. Eine effektive Nutzung erfordert das Verständnis der Wertschöpfung heute und in der Zukunft.

Systemmodell

Das Systemmodell ist eine Abstraktion von Software um eine Aktivität herum. Denken Sie an das „Supply-Chain-System“ und alles, was an der Supply Chain beteiligt ist. Das Design Ihres Systemmodells richtet sich nach der Funktionsweise Ihres Unternehmens.

Wie das Fähigkeitsmodell des Geschäftsarchitekten ermöglicht Ihnen ein Systemmodell, das Denken auf ein System zu lenken. Sie können ein komplettes System verbessern und sich dann mit den 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, was in vergleichbaren Begriffen durchgeführt wird.

Ein gutes Produktmodell bildet die Grundlage für a Referenzarchitektur für Ihre Produkte. Sie müssen Funktionen angeben, die für den Wert, die Verwendung und die Verwaltung des Produkts von zentraler Bedeutung sind. Ein Produktmodell informiert über 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 funktionale Modell schlüsselt Ihr Softwareportfolio nach Funktionalität auf. Es identifiziert alle Dinge, die Ihre Software tun muss. Gute Funktionsmodelle bieten eine breite Abdeckung.

Wie das Prozessmodell des Geschäftsarchitekten ist ein Funktionsmodell häufig eine Referenzarchitektur. Es ist leistungsstark, wenn Sie nach Duplizierung und Integration suchen. Bildet häufig die Grundlage eines Anwendungsentwicklungsmodells, in dem verschiedenen Funktionsblöcken ein Zielanwendungsentwicklungstyp zugewiesen wird.

Entscheidend bei der Planung des Anwendungsportfolios. Duplizierung und Integration treiben Komplexität und Kosten in das IT-Portfolio.

BIAN, FEAF, TMForums ODF und IndEA bieten allesamt funktionale Modelle.

Integrationsmodell

Ein Integrationsmodell identifiziert Grenzen in Ihrer Software und die Methode, mit der die Grenze überschritten wird. Scheuen Sie sich nicht, anzugeben, dass die Grenze nicht überschritten werden kann oder manuell überschritten werden muss. Viele schwache Anwendungsintegrationen liefern nur Starrheit. Die Entwicklung eines nützlichen Integrationsmodells erfordert eine Iteration mit der Arbeit eines Business-Architekten, der ein entwickelt Organisationskarte und Informationsmodell. Das Integrationsmodell, die Organisationskarte und das Informationsmodell informieren und beschränken sich gegenseitig.

Das Integrationsmodell ist entscheidend, um die Agilität des Unternehmens zu ermöglichen, das Anwendungsportfolio zu verwalten und die IT-Kosten zu senken.

Servicemodell

Ein Dienstmodell ist eine spezialisierte Version eines Funktionsmodells, das die Funktionalität in eine Blackbox mit bekannten Schnittstellen zusammenfasst. Ein gutes Servicemodell ist von unschätzbarem Wert bei der Entwicklung des Anwendungsentwicklungsmodells und der Validierung des Ziels in einem Systemmodell. Die Schnittstellen in Ihrem Servicemodell sollten alle in Ihrem Integrationsmodell gut identifiziert sein.

Ein gutes Servicemodell ermöglicht Unternehmensagilität. Nicht aus der Entwicklung von Anwendungsdiensten, sondern indem Sie Änderungen in einem Teil Ihres Unternehmens von einem anderen befreien.

Physikalisches Modell

Ein physisches Modell ist das eigentliche Softwareportfolio. Wir werden es mit Begriffen beschreiben, die von kommerziellen Softwareanbietern und Ihrem Anwendungsentwicklungsprogramm verwendet werden. Sie müssen dies den anderen Anwendungsarchitekturmodellen zuordnen, um das Ziel in die reale Welt zu überführen.

Sie verwenden das physische Modell als Einschränkung für die abstrakten Anwendungsarchitekturmodelle. Es bildet auch die Grundlage für die Implementierungs- und Migrationsplan, der in Phase F entwickelt wurde.

Techniken der Anwendungsarchitektur

Wir verwenden eine breite Palette von Techniken, um unsere Anwendungsarchitektur zu entwickeln und zu kommunizieren.

  • UML ist in guter modellgetriebener Entwicklung allgegenwärtig. Wenn Sie in der Architektur arbeiten, um die Lösungsentwicklung zu unterstützen, sollten ein Funktionsmodell und ein Integrationsmodell nach UML-Praktiken entwickelt werden.
  • 4+1-Ansichten sind sehr nützlich, um die Auswirkungen des Ziels auf verschiedene Gemeinschaften zu identifizieren. Die Entwicklung von 4+1-Modellen hilft sicherzustellen, dass Sie alle relevanten Änderungen berücksichtigen.
  • Die Information Needlines von DODAF stellen alle erforderlichen Informationsflüsse bereit. Dabei spielt es keine Rolle, ob der Knoten eine Person, eine Organisation oder ein System ist. Informationen fließen ein und aus. Der schnellste Weg, die Automatisierung zu eliminieren, besteht darin, manuelle Schritte in die Mitte eines Informationsflusses zu stellen.

Auf den Anwendungsfall der Unternehmensarchitektur abgestimmte Anwendungsarchitekturmodelle

Die Fragestellung, die Sie mit Ihrer Anwendungsarchitektur beantworten, wird den Einsatz unterschiedlicher Anwendungsarchitekturmodelle vorantreiben. Beispielsweise wird bei einer Architektur zur Unterstützung des Portfolios häufig kein Wertschöpfungskettenmodell entwickelt. Stattdessen wird eine Wertschöpfungskette in der Regel eine überlegene Architektur sein und deine Freiheit einschränken.

Architektur zur Unterstützung der Strategie Architektur zur Unterstützung des Portfolios Architektur zur Unterstützung des Projekts Architektur zur Unterstützung der Lösungsbereitstellung
Anwendungsentwicklungsmodell Schlüssel lieferbar Schlüssel lieferbar Überlegene Architektur Überlegene Architektur
Systemmodell Regelmäßig lieferbar Schlüssel lieferbar Überlegene Architektur Überlegene Architektur
Funktionsmodell Regelmäßig lieferbar Schlüssel lieferbar Schlüssel lieferbar & überlegene Architektur Schlüssel lieferbar & überlegene Architektur
Produktmodell Gelegentlich lieferbar

Ein angemessener Detaillierungsgrad mindert oft den Wert

Regelmäßig lieferbar

Ein angemessener Detaillierungsgrad mindert oft den Wert

Schlüssel lieferbar Schlüssel lieferbar
Integrationsmodell Gelegentlich lieferbar

Ein angemessener Detaillierungsgrad mindert oft den Wert

Regelmäßig lieferbar

Ein angemessener Detaillierungsgrad mindert oft den Wert

Schlüssel lieferbar Schlüssel lieferbar & überlegene Architektur
Servicemodell Gelegentlich lieferbar

Ein angemessener Detaillierungsgrad mindert oft den Wert

Regelmäßig lieferbar Schlüssel lieferbar & überlegene Architektur Schlüssel lieferbar & überlegene Architektur

 

Einfluss von Geschäftsarchitekturmodellen auf Anwendungsarchitekturmodelle

Geschäftsmodell Betriebsmodell Wertschöpfungskette Fähigkeitsmodell Prozessmodell Funktionsmodell Informationsmodell Organisationsmodell
Anwendungsentwicklungsmodell Großer Input

Erfordert ein System- oder Funktionsmodell

Großer Input

Erfordert ein System- oder Funktionsmodell

Großer Input

Erfordert ein System- oder Funktionsmodell

Großer Input

Erfordert ein System- oder Funktionsmodell

Großer Input

Erfordert ein System- oder Funktionsmodell

Großer Input

Erfordert ein System- oder Funktionsmodell

Begrenzter Eingang Begrenzter Eingang
Systemmodell Begrenzter Eingang Begrenzter Eingang Begrenzter Eingang Begrenzter Eingang Begrenzter Eingang Haupteingang Begrenzter Eingang Haupteingang
Produktmodell Haupteingang Haupteingang Haupteingang Begrenzter Eingang Begrenzter Eingang Begrenzter Eingang Begrenzter Eingang
Integrationsmodell Sehr begrenzter Eingang Wichtige Beiträge zum Kerndesign

Erfordert ein System- oder Funktionsmodell

Wichtige Beiträge zum Kerndesign

Erfordert ein System- oder Funktionsmodell

Beste Eingabe

Eine direkte Verbindung ist sehr schwer zu erkennen. Es lohnt sich, die Arbeit zu machen.

Wichtige Beiträge zum Kerndesign

Erfordert ein System- oder Funktionsmodell

Begrenzter Eingang

Nur verwenden, wenn andere Modelle nicht verfügbar sind

Wichtige Beiträge zum Kerndesign

Erfordert ein System- oder Funktionsmodell

Wichtige Beiträge zum Kerndesign

Erfordert ein System- oder Funktionsmodell

Servicemodell Begrenzter Eingang

Die Verbindungen sind wichtig, aber eine direkte Verbindung ist sehr schwer zu erkennen

Begrenzter Eingang

Die Verbindungen sind wichtig, aber eine direkte Verbindung ist sehr schwer zu erkennen

Begrenzter Eingang

Die Verbindungen sind wichtig, aber eine direkte Verbindung ist sehr schwer zu erkennen

Beste Eingabe

Eine direkte Verbindung ist sehr schwer zu erkennen. Es lohnt sich, die Arbeit zu machen.

Wird als Vollständigkeitstest verwendet Haupteingang

Eine direkte Verbindung ist sehr schwer zu erkennen. Es lohnt sich, die Arbeit zu machen.

Haupteingang

Anwendungsarchitekturmodelle für Anwendungsfälle der Unternehmensarchitektur

Alle Anwendungsfälle der Unternehmensarchitektur geht es um Veränderung. Sie alle betrachten Arten von Veränderungen und wie Unternehmensarchitekt 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 führen wir die gleiche Funktion aus. Wir unterstützen Stakeholder dabei, bessere Entscheidungen zu treffen und führen erfolgreiche Veränderungsinitiativen durch. Alles, was sich ändert, ist die Frage.

Strategischer Wandel Inkrementelle Änderung Kosten verbessern Qualität verbessern Verbessern Sie die Unternehmensagilität Minderung des Technologierisikos IT-Modernisierung Digitale Transformation Rationalisierung des Anwendungsportfolios Akquisitionsintegration
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 hilfreich

Kritische Lücken und Einschränkungen

Kritische Lücken und Einschränkungen Kritische Lücken und Einschränkungen Kritische Lücken und Einschränkungen Kritische Lücken und Einschränkungen
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 Einschränkungen informieren 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 der Prinzipien der Unternehmensarchitektur auf die Anwendungsarchitektur

Wir haben uns identifiziert 7 Architekturprinzipien, die jeder Unternehmensarchitekt kennen sollte. In der folgenden Tabelle sind die Auswirkungen dieser Architekturprinzipien auf die Anwendungsarchitektur aufgeführt. Beim Aufführen Unternehmensarchitektur-Governance, müssen Sie Ihre Anwendungsarchitektur testen, um sicherzustellen, dass sie der übergeordneten Architektur entspricht. Entspricht es hier den Grundsätzen der Unternehmensarchitektur?

Auswirkungen auf die Anwendungsarchitektur
Leg dich nicht mit dem Erfolg an Wenn das Programm keine Differenzierung oder Transformation ist, versuchen Sie, Veränderungen zu eliminieren. Versuchen Sie, alle Änderungen an Prozessen oder Systemen zu vermeiden, die nicht ausdrücklich kosten- und ergebnisgerecht sind.
Fokus auf Exzellenz Richten Sie mit aus Betriebsmodell das Fähigkeitsmodell.

Nutzen Sie das Anwendungsentwicklungsmodell, um die 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 eine Duplizierung verboten ist.
Daten sind ein Vermögenswert Stellen Sie sicher, dass die Kontrolle über das Datenmodell nicht auf eine Weise abgegeben wird, die den Wert der Datenbestände mindert.
Systeme funktionieren, wo wir arbeiten Arbeitsort und Arbeitsstil, Schnittstelle und Anwendungsmodell.
Schmerzlose Benutzererfahrung Effizienzprogramme konzentrieren sich auf bestehende Geschäftsprozesse.

Differenzierungs- und Transformationsprogramme erfordern eine Änderung der Benutzeroberfläche und des Engagements, wenn Erfahrungen mit neuen Prozessen gesammelt werden.

Selbstbedienung Verwaltungsaktivitäten und Bereitstellung von Anwendungen sind teuer, wenn es sich nicht um Self-Service handelt

Schwache UX ist teuer..

Wie passt TOGAF Phase C zur agilen Entwicklung?

Die Anwendungsarchitektur bietet mehrere Einschränkungen und Anleitungen für die agile Entwicklung. Die grundlegende Anleitung stammt aus dem Anwendungsentwicklungsmodell. Es identifiziert, wo Sie keine agile Entwicklung wünschen.

Unternehmensarchitektur und agile Entwicklung wird sich in vier Bereichen kreuzen. Das Unternehmensarchitektur wird:

  1. Definieren Sie den agilen Ansatz
  2. Führen Sie den Rückstand im Sprint
  3. Auswahlmöglichkeiten innerhalb der Sprints einschränken
  4. Lösung für Kreuzproduktabhängigkeit

Wir konzentrieren uns bei der agilen Entwicklung immer auf neuartige differenzierende Aktivitäten und folgen rücksichtslos etablierten Best Practices an anderer Stelle. Best Practice kommt von etablierter kommerzieller Software. Stellen Sie sicher, dass Sie Ihre Anwendungsarchitektur an Ihrer Geschäftsarchitektur ausrichten und konzentrieren Sie sich darauf, wie Sie Systeme erwerben.

Wie ermöglicht TOGAF Phase C Enterprise Agility?

Unternehmensagilität hat nichts damit zu tun, wie Sie Software schreiben. Bei der Unternehmensagilität geht es um die Fähigkeit Ihres Unternehmens, auf unerwartete Bedrohungen und Chancen zu reagieren. Wenn Sie Code schreiben müssen, müssen Sie dazu in der Lage sein auf eine Bedrohung oder Chance reagieren, die gefährdet ist.

Ein Anwendungsarchitekt wird sich auf den fünften Aspekt des konzentrieren Modell der Unternehmensagilität - Flexibilität. Wir verwenden das gleiche Beweglichkeitsattribut und die gleichen Punktzahlen in der Leitfaden zur Fähigkeitsbewertung um die Informationssysteme zu identifizieren, die sich schnell ändern können müssen. Dann entwerfen wir, um Veränderungen zu ermöglichen.

Enterprise-Agilitätsmodell

  1. Wachsamkeit – Können Sie Chancen und Risiken erkennen?
  2. Zugänglichkeit – Können Sie rechtzeitig auf relevante Informationen zugreifen, um zu antworten?
  3. Entscheidungskraft – Können Sie sich anhand der verfügbaren Informationen entscheiden?
  4. Schnelligkeit – Können Sie Ihre Entscheidungen in der zur Verfügung stehenden Zeit umsetzen?
  5. Flexibilität – Was tun Sie, um Handlungshindernisse abzubauen?

Was ist das Ziel von TOGAF ADM Phase C?

In Phase A, du hast a identifiziert vereinfachte Zielarchitektur - die Architekturvision. Die Architekturvision umfasste alle Domänen. Aktivität in Phase C, entwickelt die Anwendungs- und Datenarchitekturdomänen weiter. Erfolg erfordert:

  • Sie sprechen das Problem an, wie das aktuelle Unternehmen die Präferenzen der Stakeholder nicht erfüllen kann
  • Sie erfahren, was sich ändern muss, damit das Unternehmen die Präferenzen der Stakeholder erfüllen kann? (Lücken)
  • Sie haben ein ausreichendes Verständnis der Arbeit, die erforderlich ist, um Änderungen zu liefern (Arbeitspaket)
  • Sie verstehen die Wechselwirkung zwischen Änderungen und Einschränkungen in anderen Architekturdomänen, um den erwarteten Wert zu schützen (Architecture Requirements Specifications)

Das zentrale Ergebnis von Phase C ist die Kandidatenanwendungsarchitektur. Anwendungsarchitekten arbeiten mit anderen Domänenarchitekten zusammen, um zu verstehen, welche Einschränkungen der Anwendungsarchitektur auferlegt werden und welche Einschränkungen anderen Domänen auferlegt werden.

Denken Sie daran, dass das TOGAF ADM potenzielle Änderungen untersucht. Bis Sie die entwickeln Umsetzungsplan in Phase F, suchen Sie nach der günstigsten Ausfahrt. Schlechte Ideen bedeuten nicht, dass Sie das Problem nicht lösen. Du solltest schwach abwerfen architektonische Alternativen. Schlechte Ideen früher zu stoppen, spart Geld und ermöglicht erfolgreiche Veränderungen. In dem Moment, in dem eine Idee schlecht wird, bleiben Sie stehen. Töte die Idee. Feiern Sie Ihren Sieg! Feiern Sie, dass Sie erfolgreiche Veränderungen ermöglichen!

Anwendungsarchitekturmuster

Wir gebrauchen Architekturmuster um die Produktivität und Qualität unserer Architekturentwicklung drastisch zu steigern. Wir verwenden eine vereinfachte Architekturmustervorlage Das treibt uns dazu, das zu verstehen vorhersehbares Problem, Musteransatz, und das Harte Teile. Die Anwendbarkeit des Musters hängt in der Regel von der erforderlichen Arbeit, den Einschränkungen und Einschränkungen ab.

Beispielmuster für Anwendungsarchitekturen

Beispielhafte Anwendungsarchitekturmuster decken das Problem der Anwendungsstruktur, der Migration und des Anwendungsdesigns ab.

  • Anwendungsstruktur
    • MVC-Muster (Model-View-Controller).
      Vorhersehbares Problem– Codeorganisation, Wartbarkeit und Testbarkeit
      Ansatz– trennt 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).
  • Anwendungsmigration
    • Strangler-Muster
      Vorhersehbares Problem– Ersetzen von Altsystemen
      Ansatz– Ersetzen oder „erwürgen“ Sie schrittweise ein vorhandenes Altsystem, indem Sie neue Komponenten darauf aufbauen, um das System schrittweise zu ersetzen
  • Anwendungsdesign (Gruppe von vier Anwendungsmustern)
    Als Unternehmensarchitekten nutzen wir Entwurfsmuster als Einschränkungen für die Freiheit von Anwendungsentwicklungsteams. (Sehen Unternehmensarchitektur und Agilität – 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 an Unternehmensarchitektur-Team eine Reihe von Verantwortlichkeiten haben, 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, entwerfen, implementieren und entwickeln. Kurz gesagt, die Unternehmensanwendungsarchitekt unterscheidet sich von einem Lösungsarchitekten oder einem Anwendungsarchitekten der nicht mit einem EA-Team arbeitet.

Anwendungsarchitekten, die in TOGAF ADM Phase C arbeiten, haben eine komplexe Rolle.

  • Arbeiten Sie mit Stakeholdern und KMU zusammen, um Änderungen im Anwendungsportfolio auszuwählen, die die beste zukünftige Organisation ermöglichen
  • mit ihresgleichen arbeiten Domänenarchitekten um zu untersuchen, wie Verbesserungen, die in der Geschäftsdomäne erforderlich sind, in der Anwendungsdomäne ermöglicht oder verhindert werden
  • Arbeiten Sie mit den Beteiligten zusammen, um Änderungen im Anwendungsportfolio zu eliminieren, die zu wenig liefern oder zu viel kosten. Eliminieren Sie außerdem Änderungen in anderen Bereichen, die zu unannehmbaren Kosten und Änderungen im Anwendungsportfolio führen

In TOGAF ADM Phase C, einer der vier grundlegenden Domänen der Unternehmensarchitektur ist entwickelt. TOGAF ist sehr klar, dass Sie diese Architektur während der Entwicklung der anderen Domänen entwickeln. Änderungen in einer Domäne aktivieren, erzwingen oder blockieren Änderungen in einer anderen Domäne.

Hochfunktionierende EA-Teams verwenden ihre Anwendungsarchitekten nicht als Designer einer einzelnen Anwendung. Diese Rolle ist notwendig, aber ohne eine Anwendungsarchitektur, die wesentliche Teile des Unternehmens abdeckt, können Sie das Unternehmen nicht optimieren.

TOGAF ADM Phase C entwickelt die Anwendungsarchitektur. Anwendungsarchitektur ist die Grundlage aller modernen digitalen Unternehmen. Verwenden Sie dazu TOGAF Phase C Fokussieren Sie knappe Änderungsressourcen darauf, den größtmöglichen Unternehmenswert zu erzielen.

Nach oben scrollen