TOGAF-Phase A

Phase A – Architekturvision

TOGAF

In Phase A erfolgen der Projektaufbau und der Anstoß einer Iteration des Architekturennvicklungszyklus zusammen mit der Festlegung von Wirkungsbereich, Rahmenbedingungen und Erwartungen in Bezug auf den jeweiligen Durchlauf. Diese Phase ist notwendig, um den Geschäftskontext zu validieren und einen abgestimmten Auftrag für Architekturarbeit zu erstellen.

IVS-Rahmenarchitektur

In der Phase A wird den Projektaufbau für die Durchführung erfolgreicher IVS-Architekturprojekte geschaffen.

Schritt	TOGAF	Tailoring IVS-Rahmenarchitektur	Umsetzung Rahmenarchitektur
1	Aufsetzen des Architekturprojekts Die Durchführung der Architecture Developement Method (ADM) sollte innerhalb des Projektmanagements der Organisation durchgeführt werden. Manchmal werden Architekturprojekte eigenständigen durchgeführt. In anderen Fällen werden Aktivitäten, bezüglich der Architekturarbeit, als eine Untergruppe innerhalb eines größeren Projekts durchgeführt. In jedem Fall sollten all diese Aktivitäten geplant werden und unter Verwendung von anerkannten Vorgehen der Organisation durchgeführt werden. Verfahren zur Anerkennung und zur Sicherung des Projekts sollten durchgeführt werden, darunter die Billigung der Organisationsführung und die sichere Unterstützung und das Engagement des verantwortlichen Managements. Verweise für andere Management Arbeiten innerhalb der Organisation sollten erstellt werden, um zu klären, wie dieses Projekt mit deren Rahmenbedingungen im Zusammenhang stehen.	./.	Aufgabenstellung & Vorhabens- und Leistungsbeschreibung Los 1
2	Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen	./.	Stakeholder BMVI - Bundesministerium für Verkehr und digitale Infrastruktur: BASt - Bundesanstalt für Strßen und Verkehr (als nachgeordnete Behörde) AlbrechtConsult & Scholtes IT-Beratung als Auftragnehmer Anliegen Umsetzung des nationalen IVS-Aktionsplans Straße zur koordinierten Weiterentwicklung bestehender und beschleunigten Einführung neuer Intelligenter Verkehrssysteme in Deutschland bis 2020 Prioritäres Handlungsfeld 2: DURCHGÄNGIGKEIT DER IVS-DIENSTE IM BEREICH VERKEHRSMANAGEMENT UND VERKEHRSINFORMATION Maßnahme 2.2 Entwicklung einer IVS-Rahmenarchitektur Straße - Erarbeitung und Einführung einer national verbindliche IVS-Rahmenarchitektur, die als Grundlage zur harmonisierten Einführung und Nutzung von IVS angewendet wird.
3	Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen	./.	harmonisierte Einführung von IVS durchgängige und verbesserte IVS-Anwendungen und IVS-Dienste Erleichterung bei der Entwicklung und Einführung von IVS-Diensten Sicherheit für öffentliche Betreiber bezüglich Kompatibilität und Interoperabilität von IVS-Anwendungen geringerer Entwicklungsaufwand und Planungssicherheit für die Industrie Vermeidung technologischer „Insellösungen“ Verbesserung der Investitionssicherheit und Markttransparenz effizienterer und leichterer Verkehr Erhöhung der Verkehrssicherheit und der Wirtschaftlichkeit Reduzierung von negativen Umweltwirkungen des Verkehrs
4	Bewertung der Geschäftsfähigkeiten Für die Organisation ist es sinnvoll, die Geschäftsfähigkeiten innerhalb des Unternehmens zu verstehen. Ein Teil bezieht sich auf die Geschäftsfähigkeit des Unternehmens, die Architektur zu entwickeln und effizient zu nutzen. Ein anderer Teil bezieht sich auf die einzelnen (anderen) Geschäftsfähigkeiten des Unternehmens. Lücken, die in der Geschäftsfähigkeit, die Architektur zu entwickeln und zu nutzen, identifiziert worden sind, erfordern eine erneute Durchführung der Vorlauf-Phase (Prelimary Phase) und Phase A (Architecture Vision), um sicherzustellen, dass diese Geschäftsfähigkeit ausreichend ist, den Umfang des Architektur-Projekts zu stemmen. Gaps, or limitations, identified in the enterprise's capability to execute on change will inform the architect on the description of the Target Architecture and on the Implementation and Migration Plan created in Phase E and Phase F. Der Schritt soll in einem angemessenen Niveau die Fähigkeiten und Wünsche des Unternehmens verständlich machen. Das Darstellen von Basis-Geschäftsfähigkeiten und Ziel-Geschäftsfähigkeiten, im Rahmen des gesamten Unternehmens, kann durch die Erstellung von Wertketten-Diagrammen unterstützt werden. Hiermit können Verknüpfungen der Geschäftsfähigkeiten aufgezeigt werden.	Diskussion Was sind in unserem Falle? die Organisation das Unternehmen
5	Bewertung der Reife für eine Transformation des Geschäfts Eine Bewertung der Reife für die Transformation des Geschäfts kann verwendet werden, um die Bereitschaft der Organisation, sich einer Änderung zu unterziehen, zu bewerten und zu quantifizieren. Diese Einschätzung basiert auf der Ermittlung und Analyse/Bewertung einer Reihe von Reife-Faktoren. Die Ergebnisse der Bewertung der Bereitschaft sollten der Auflistung der Capabilities hinzugefügt werden. Diese Ergebnisse werden dann verwendet, um den Umfang der Architektur zu gestalten, um erforderliche Aktivitäten innerhalb des Architektur-Projekts festzulegen und anzugehende Risikobereiche zu identifizieren.	Diskussion
6	Definition des Wirkungsbereichs Define what is inside and what is outside the scope of the Baseline Architecture and Target Architecture efforts, understanding that the baseline and target need not be described at the same level of detail. In many cases, the Baseline is described at a higher level of abstraction, so more time is available to specify the Target in sufficient detail. In particular, define: The breadth of coverage of the enterprise The level of detail required The partitioning characteristics of the architecture The specific architecture domains to be covered (business, data, application, technology) The extent of the time period aimed at, plus the number and extent of any intermediate time period The architectural assets to be leveraged, or considered for use, from the organization's Enterprise Continuum: Assets created in previous iterations of the ADM cycle within the enterprise Assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)	./.
7	Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien Die Prinzipien, nach denen die Architektur entwickelt werden soll, müssen überprüft werden. Architekturprinzipien sollten in der Phase vor Architecture Vision (A) festgelegt werden. Es sollte sichergestellt werden, dass die bestehenden Definitionen aktuell und eindeutig sind. Ansonsten sollte das mit den Verantwortlichen der Architektur-Governance und den Stakeholdern abgestimmt werden. Architekturprinzipien sind strategische Vorgaben, konkrete und verbindliche (IT-)Grundsätze und Orientierungshilfen. Beispiele hierfür sind: Auswahl von Softwarelösungen: Best-of-Breed, End-to-End, Make or Buy Auswahl und Bewertung von Projekten: Priorität Kerngeschäft, Infrastrukturprojekte zuerst Entwurfsprinzipien: Vermeidung von Heterogenität, Technische Struktur folgt fachlicher Strukturierung, Vermeidung von Redundanzen, Nur das führende System ändert Stammdaten, etc. Ihre Ausarbeitung ist Bestandteil der Architekturplanung. Beispiele für Architekturprinzipien sind: Serviceorientierung: Die Architektur verteilter Anwendungen ist so gestaltet, dass die serviceorientierte Bereitstellung von versicherungsfachlichen Funktionen unterstützt wird. Integrationsplattform: Das führende System für Integrationslösungen des Unternehmens ist ein Applikationsserver. Datenreplikation: Die Replikation von operativen Daten des Backend ist zu vermeiden.	Diskussion
8	Entwicklung der Architekturvision Based on the stakeholder concerns, business capability requirements, scope, constraints, and principles, create a high-level view of the Baseline and Target Architectures. The Architecture Vision (Phase A) typically covers the breadth of scope identified for the project, at a high lev-el. Informal techniques are often employed. A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise. Business scenarios are an appropriate and useful technique to discover and document busi-ness requirements, and to articulate an Architecture Vision that responds to those require-ments. Business scenarios may also be used at more detailed levels of the architecture work (e.g., in Phase B).	./.
9	Definition des Wertbeitrags der Zielarchitektur und der KPIs Develop the business case for the architectures and changes required Produce the value proposition for each of the stakeholder groupings Assess and define the procurement requirements Review and agree the value propositions with the sponsors and stakeholders concerned Define the performance metrics and measures to be built into the enterprise architecture to meet the business needs Assess the business risk The outputs from this activity should be incorporated within the Statement of Architecture Work to allow performance to be tracked accordingly.	Diskussion
10	Identifizierung der Risiken einer Geschäfts-Transformation und der Aktivitäten zur Risikominimierung	Diskussion	Die IVS-Rahmenarchitektur wird nicht von allen Beteiligten mit getragen. Die Architektur beinhaltet zu konkrete oder zu vage Festlegungen (z.B. im Bezug auf den Umfang von festgeschriebenen Standards). Die verbindliche Einführung der IVS-Rahmenarchitektur scheitert.
11	Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit,Sichern der Zustimmung Assess the work products that are required to be produced (and by when) against the set of business performance requirements. This will involve ensuring that: Performance metrics are built into the work products. Specific performance-related work products are available. Then, activities will include: Identify new work products that will need to be changed Provide direction on which existing work products, including building blocks, will need to be changed and ensure that all activities and dependencies on these are co-ordinated Identify the impact of change on other work products and dependence on their activities Based on the purpose, focus, scope, and constraints, determine which architecture do-mains should be developed, to what level of detail, and which architecture views should be built Assess the resource requirements and availability to perform the work in the timescale re-quired; this will include adhering to the organization's planning methods and work products to produce the plans for performing a cycle of the ADM Estimate the resources needed, develop a roadmap and schedule for the proposed devel-opment, and document all these in the Statement of Architecture Work Define the performance metrics to be met during this cycle of the ADM by the enterprise architecture team Develop the specific enterprise architecture Communications Plan and show where, how, and when the enterprise architects will communicate with the stakeholders, including affinity groupings and communities, about the progress of the enterprise architecture developments Review and agree the plans with the sponsors, and secure formal approval of the State-ment of Architecture Work under the appropriate governance procedures Gain sponsor's sign-off to proceed	Diskussion

---

Es werden die Ziele der Bundesregierung und der weiteren Stakeholder für das Straßenverkehrswesen analysiert und auf die High-Level-Capability angewendet. Relevante Bestandteile der Phase sind die Identifikation der betroffenen Stakeholder, die Darstellung des Mehrwerts durch die Architektur und der möglichen Risiken sowie die Entwicklung und Dokumentation der Vision. Hier ergeben sich erste Anforderungen an die Interoperabilität.