|
|
| Zeile 75: |
Zeile 75: |
| | ! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Umsetzung IVS-Rahmenarchitektur | | ! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Umsetzung IVS-Rahmenarchitektur |
| | |- | | |- |
| − | | 1 || '''Auswahl von Referenzmodellen, Perspektiven und Werkzeugen ''' | + | | 1 || Auswahl von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap11.html#tag_11_04_01 Referenzmodellen, Perspektiven und Werkzeugen] |
| | | | |
| − | Überprüfung und Validierung (oder ggf. Generierung) einer Menge an Anwendungsprinzipien (application principles). Diese bilden in der Regel einen Teil eines umfassenden Satzes von Architekturprinzipien.
| |
| − | Wahl der entsprechenden Anwendungsarchitektur-Ressourcen (Referenzmodelle, Muster, etc.) auf Basis der Business-Treiber, Stakeholders, deren Anliegen und der Geschäftsarchitektur.
| |
| − | Wahl der relevanten Anwendungsarchitektur-Perspektiven (z.B. Stakeholder der Applikationen – relevante Perspektiven aus der Sicht der funktionalen Nutzer und aus Sicht der individuellen Nutzer der Applikationen, etc.); das heißt, diejenigen, die es den Architekten ermöglichen zu zeigen, wie die Stakeholder-Anliegen in der Anwendungsarchitektur adressiert werden.
| |
| | | | |
| − | Identifizierung geeigneter Werkzeuge und Techniken, die für die Erfassung, Modellierung und Analyse der Anwendungen, in Verbindung mit den ausgewählten Perspektiven, verwendet werden können. Je nach Grad der gewollten Komplexität können diese eine Form von einfachen Dokumenten oder Tabellen haben, oder in Form von komplexeren Modellierungstools und Techniken.
| + | || || |
| − | | + | |- |
| − | Erwägen Sie die Verwendung von plattformunabhängige Beschreibungen von der Geschäfts-Logik. Zum Beispiel bietet die OMG's Model Driven Architecture (MDA) einen Ansatz zur Modellierung von Anwendungsarchitekturen, die die Geschäfts-Logik von Änderungen durch die zugrundeliegende Plattform und Implementierungstechnologie bewahrt.
| + | | 2 || Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap11.html#tag_11_04_02 Ausgangssituation für die Anwendungsarchitektur] |
| | | | |
| − | '''1.1: Festlegung des allgemeinen Modellierungsprozesses '''
| |
| | | | |
| − | For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.
| |
| − | Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see above).
| |
| − | The recommended process for developing an Application Architecture is as follows:
| |
| − | * Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the business architecture scope
| |
| − | * Simplify complicated applications by decomposing them into two or more applications
| |
| − | * Ensure that the set of application definitions is internally consistent, by removing duplicate functionality as far as possible, and combining similar applications into one
| |
| − | * Identify logical applications and the most appropriate physical applications
| |
| − | * Develop matrices across the architecture by relating applications to business service, business function, data, process, etc.
| |
| − | * Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns
| |
| − |
| |
| − | The level and rigor of decomposition needed varies from enterprise to enterprise, as well as within an enterprise, and the architect should consider the enterprise's goals, objectives, scope, and purpose of the enterprise architecture effort to determine the level of decomposition.
| |
| − | The level of granularity should be sufficient to enable identification of gaps and the scope of candidate work packages.
| |
| − |
| |
| − | '''1.2: Benötigte Kataloge für Daten Building Blocks identifizieren '''
| |
| − |
| |
| − | The organization's Application Portfolio is captured as a catalog within the Architecture Repository. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., logical application component -> physical application component ->] information system service).
| |
| − | Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.
| |
| − | The following catalogs should be considered for development within an Application Architecture:
| |
| − | * Application Portfolio catalog
| |
| − | * Interface catalog
| |
| − |
| |
| − | '''1.3: Matrizen definieren '''
| |
| − |
| |
| − | Matrices show the core relationships between related model entities.
| |
| − | Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.
| |
| − | Once the baseline Application Portfolio has been assembled, it is necessary to map the applications to their purpose in supporting the business. The initial mapping should focus on business services within the Business Architecture, as this is the level of granularity where architecturally significant decisions are most likely to be needed.
| |
| − | Once applications are mapped to business services, it will also be possible to make associations from applications to data, through the business-information diagrams developed during Business Architecture.
| |
| − | If readily available, baseline application data models may be used to validate the Business Architecture and also to identify which data is held locally and which is accessed remotely.
| |
| − | The Data Architecture phase will focus on these issues, so at this point it may be appropriate to drop into a short iteration of Data Architecture if it is deemed to be valuable to scope of the architecture engagement.
| |
| − | Using existing information in the baseline application catalog, the Application Architecture should identify user and organizational dependencies on applications. This activity will support future state planning by determining impacted user communities and also facilitating the grouping of application by user type or user location.
| |
| − | A key user community to be specifically considered is the operational support organization. This activity should examine application dependencies on shared operations capabilities and produce a diagram on how each application is effectively operated and managed.
| |
| − | Specifically considering the needs of the operational community may identify requirements for new or extended governance capabilities and applications.
| |
| − | The following matrices should be considered for development within an Application Architecture:
| |
| − | * Application/Organization matrix
| |
| − | * Role/Application matrix
| |
| − | * Application Interaction matrix
| |
| − | * Application/Function matrix
| |
| − |
| |
| − | '''1.4: Benötigte Diagramme definieren '''
| |
| − |
| |
| − | Diagrams present the Application Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.
| |
| − | Once the desired functionality of an application is known, it is necessary to perform an internal assessment of how the application should be best structured to meet its requirements.
| |
| − | In the case of packaged applications, it is likely to be the case that the application supports a number of configuration options, add-on modules, or application services that may be applied to the solution. For custom developed applications, it is necessary to identify the high-level structure of the application in terms of modules or sub-systems as a foundation to organize design activity.
| |
| − | The following diagrams should be considered for development within an Application Architecture:
| |
| − | * Application Communication diagram
| |
| − | * Application and User Location diagram
| |
| − | * Enterprise Manageability diagram
| |
| − | * Process/Application Realization diagram
| |
| − | * Application Migration diagram
| |
| − | * Software Distribution diagram
| |
| − | * Software Engineering diagram
| |
| − | * Application Use-Case diagram
| |
| − |
| |
| − | '''1.5: Arten von Anforderungen identifizieren '''
| |
| − |
| |
| − | Once the Application Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the application-focused requirements for implementing the Target Architecture.
| |
| − | These requirements may:
| |
| − | * Relate to the application domain
| |
| − | * Provide requirements input into the Data and Technology Architectures
| |
| − | * Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements
| |
| | | | |
| | || || | | || || |
| | |- | | |- |
| − | | 2 || '''Entwicklung einer Beschreibung der Ausgangssituation für die Anwendungsarchitektur ''' | + | | 3 || Entwicklung einer Beschreibung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap11.html#tag_11_04_03 Ziel-Anwendungsarchitektur] |
| | | | |
| − | Entwicklung einer Ausgangsbeschreibung der bestehenden Anwendungsarchitektur im erforderlichen Umfang, um auf Basis dieser, die Ziel-Anwendungsarchitektur zu erstellen. Der Umfang und die Detailebene sind abhängig vom Umfang der vorhandenen Anwendungen, die in die Ziel-Anwendungsarchitektur übertragen werden und ist zusätzlich abhängig von bereits existierenden architektonischen Beschreibungen. So weit wie möglich sollten die relevanten Bausteine der Anwendungsarchitektur identifiziert werden (s.g. Building Blocks), durch Inanspruchnahme des Architektur-Repositories.
| |
| − | Falls Anwendungen (Building Blocks) noch nicht im Architektur-Repository vorhanden sind, muss jede Anwendung im Einklang mit dem Anwendungs-Portfolio-Katalog definiert werden.
| |
| − | Falls neue Architekturmodelle entwickelt werden müssen, um Stakeholder-Anliegen gerecht zu werden, sollten die in Schritt 1 definierten Modelle als Leitfaden für die Erstellung neuer Architektur-Inhalte herangezogen werden.
| |
| | | | |
| − | || ||
| |
| − | |-
| |
| − | | 3 || '''Entwicklung einer Beschreibung der Ziel-Anwendungsarchitektur '''
| |
| − |
| |
| − | Entwicklung einer Zielbeschreibung für die Anwendungsarchitektur in dem erforderlichen Umfang, um die Architektur Vision (Output Phase A), die Ziel-Geschäftsarchitektur (Output Phase B) und die Ziel-Datenarchitektur (Output Teil 1 Phase C) zu unterstützen. Der Umfang und die Detailebene werden auf Basis der Relevanz der Applikationen zur Erreichung der Zielarchitektur bestimmt und ob, oder ob keine architektonischen Beschreibungen existieren. So weit wie möglich sollten die relevanten Bausteine der Anwendungsarchitektur identifiziert werden (s.g. Building Blocks), durch Inanspruchnahme des Architektur-Repositories.
| |
| − | Falls neue Architekturmodelle entwickelt werden müssen, um Stakeholder-Anliegen gerecht zu werden, sollten die in Schritt 1 definierten Modelle als Leitfaden für die Erstellung neuer Architektur-Inhalte herangezogen werden.
| |
| | | | |
| | || || | | || || |
| | |- | | |- |
| − | | 4 || '''Durchführung einer Gap-Analyse ''' | + | | 4 || Durchführung einer Gap-Analyse |
| − | | |
| − | Überprüfung der Architekturmodelle auf Konsistenz und Genauigkeit:
| |
| − | - Durchführung von trade-off Analysen zur Lösung von Konflikten (falls vorhanden).
| |
| − | - Überprüfung, ob die Modelle die Prinzipien, Ziele und Anliegen unterstützen.
| |
| − | - Änderungen, in den ausgewählten Modellen aus dem Architektur-Repository, zu den jeweiligen Perspektiven notieren und dokumentieren.
| |
| − | - Architekturmodelle auf Vollständigkeit gegeben den Anforderungen überprüfen.
| |
| − | | |
| − | Identifizierung von Lücken zwischen der Ausganssituation der Anwendungsarchitektur und der Ziel-Anwendungsarchitektur.
| |
| − | | |
| − | '''Zusatz: Durchführung der Gap-Analyse - Schritte '''
| |
| − | | |
| − | '''Schritt 1: '''Zeichnen Sie eine Matrix mit allen Architektur-Bausteinen der Ausgangsarchitektur auf der vertikalen Achse, und allen Architekturbausteinen der Zielarchitektur auf der horizonta-len Achse.
| |
| − | | |
| − | '''Schritt 2: '''Addieren Sie in der Ausgangsarchitektur-Achse eine Zeile "Neu", und bei der Zielarchitektur-Achse eine Spalte mit der Bezeichnung "Ausgeschieden".
| |
| − | | |
| − | '''Schritt 3: '''Ist ein Architekturbausein sowohl in der Ausgangs- als auch in der Zielarchitektur verfügbar, notieren Sie bei der Kreuzung von Spalte und Zeile "inbegriffen".
| |
| − | | |
| − | '''Schritt 4: '''Wenn ein Baustein der Ausgangsarchitektur in der Zielarchitektur fehlt, muss jeder überprüft werden. Wenn der Baustein gerechtfertig beseitigt wurde, markieren Sie diesen in der entsprechenden "Ausgeschieden" Zelle. Wenn es nicht gerechtfertigt ist, handelt es sich um eine zufällige Aufdeckung eines Fehlers, dieser muss in der nächsten Iteration des Architektur-Design behoben werden. Der Baustein muss also als solcher gekennzeichnet werden in der entsprechenden "Ausgeschieden" Zelle.
| |
| − | | |
| − | '''Schritt 5: '''Wenn ein Architekturbaustein der Zielarchitektur nicht in der Ausgangsarchitektur zu finden ist, dann muss dies an der Kreuzung in der "Neuen" Zeile als Lücke markiert wer-den, die gefüllt werden muss, entweder durch die Entwicklung oder Beschaffung eines solchen Bausteins.
| |
| − | | |
| − | '''Schritt 6: '''Ist die Analyse beendet, zeigt alles unter "Ausgeschieden" oder "Neu" eine Lücke auf, die entweder als richtig eliminiert erklärt werden kann oder markiert werden muss zur Wiederherstellung oder Entwicklung / Beschaffung.
| |
| | | | |
| | || || | | || || |
| | |- | | |- |
| − | | 5 || '''Definition von Roadmap-Komponenten ''' | + | | 5 || Durchführung einer Gap-Analyse |
| − | | |
| − | Nach Erstellung der Ausgangssituation der Anwendungsarchitektur, der Ziel-Anwendungsarchitektur und der Gap-Analyse ist eine Applikations-Roadmap erforderlich, die die auszuführenden Aktivitäten in den kommenden Phasen priorisiert.
| |
| − | Diese erste Anwendungsarchitektur-Roadmap wird als Grundlage für eine detailliertere Definition einer konsolidierten, disziplinübergreifenden Roadmap innerhalb der Opportunities & Solutions Phase (Phase E) verwendet.
| |
| | | | |
| | || || | | || || |
