TOGAF-Phase A: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(328 dazwischenliegende Versionen von 7 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
== Phase A – Architekturvision ==
 
  
−
;TOGAF
+
== Einführung in die "Phase A – Entwicklung einer Architekturvision" ==
  
−
: 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.
+
In '''Phase A – Entwicklung einer Architekturvision''' geht es grundsätzlich darum, eine Vision für einen IVS-Dienst bzw. eine IVS-Dienstkategorie zu entwickeln und - auf einem hohen Niveau - einen ersten Aufschlag für die IVS-Architektur und ihre Architekturdomänen zu machen. Stakeholdern und Beteiligten soll anhand der Vision vermittelt werden, wie ihre strategischen und geschäftlichen Erwartungen berücksichtigt werden, wie diese in Form von geschäftlichen Zielen (engl. business goals) formuliert werden und mit welchen messbaren Zielen (engl. business objectives) ihre Zielerreichung am Ende bewertet werden kann.
  
−
;IVS-Rahmenarchitektur
+
Ein wichtiger Kern der Phase A ist es, den Zweck des Architekturansatzes zu klären (zu erklären), darüber unter allen Beteiligten Konsens zu erzielen und diesen in Form einer Vision zu formulieren.
−
: In der Phase A wird den Projektaufbau für die Durchführung erfolgreicher <u>IVS-Architekturprojekte</u> geschaffen.
+
 
 +
Normalerweise sind Schlüsselelemente einer Architekturvision bereits Bestandteil einer weiter gefassten, z. B. politischen Strategie. Hier gilt es, die Vision so zu formulieren, dass ein Bezug zu dieser Strategie hergestellt wird und die Architekturvision darin eingeordnet werden kann. Beispiele für politische Strategien sind der '''europäische IVS-Aktionsplan''', die '''europäische IVS-Direktive''' und der '''[[Media:_C-ITS-Masterplan.pdf|Europäische C-ITS-Masterplan]]'''. Beispiele für nationale Strategien sind der '''IVS-Aktionsplan Straße''' sowie die '''Strategie automatisiertes und vernetztes Fahren''' der Bundesregierung.
 +
 
 +
'''Business-Szenarien''' stellen eine nützliche Technik dar, um strategische und geschäftliche Anforderungen zu identifizieren, zu dokumentieren und daraus eine Vision zu artikulieren, die diesen Anforderungen entspricht. Business-Szenarien stellen insofern eine gesonderte Methode innerhalb der TOGAF-ADM dar.
 +
 
 +
== Schritte der "Phase A - IVS-Architekturvision" ==
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! Schritt !! TOGAF !! Tailoring IVS-Rahmenarchitektur !! Umsetzung Rahmenarchitektur
 
 
|-
 
|-
−
|- style="vertical-align:top;"
+
! Schritt
−
| 1 || ''' Aufsetzen des Architekturprojekts '''
+
! TOGAF
−
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.
+
! Tailoring IVS-Rahmenarchitektur
−
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.
+
! Anleitung
−
|| ''' Aufsetzen des IVS-Rahmenarchitekturprojekts ''' ||[[Aufgabenstellung]] & [[Media:Los1 IVS-Rahmenarchitektur Vorhabensbeschreibung Anonymisiert 01-00-00.pdf | Vorhabens- und Leistungsbeschreibung Los 1]]  
+
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
 +
! Empfehlung für IVS-Referenzarchitekturen
 +
! Empfehlung für IVS-Architekturen realer IVS-Dienste
 +
|- style="vertical-align:top"
 +
| 1
 +
| Aufsetzen des [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_01 Architekturprojekts]
 +
| Aufsetzen des IVS-Architekturprojekts
 +
| [[Aufsetzen_von_IVS-Architekturprojekten|'''Aufsetzen eines Architekturprojekts''']]
 +
*[[IVS-Domäne-Template|Template: Other Deliverable IVS-Domäne]]
 +
*[[IVS-Dienst-Template|Template: Other Deliverable IVS-Dienst]]
 +
 
 +
;'''Hintergrundinformationen und Techniken''' "IVS-Domäne"
 +
:[[IVS-Dömänen|IVS-Domänen-Konzept]]
 +
;Hintergrundinformationen und Techniken "IVS-Dienst"
 +
:[[IVS-Dienste-Konzept|IVS-Dienste-Konzept]]
 +
;'''Hintergrundinformationen und Techniken''' "IVS-Wertschöpfungskette"
 +
:[[BusinessFootprintDiagramm_Los3-2|Beispiel Wertschöpfung im System Straße]]
 +
:[[BusinessFootprintDiagramm_Los2|Beispiel Verkehrsinformation Individualverkehr]]
 +
:[[BusinessFootprintDiagramm_Los3|Beispiel Zuständigkeitsübergreifendes Verkehrsmanagement]]
 +
:[[BusinessFootprintDiagramm_Los4|Beispiel Multimodale Verkehrsinformation]]  
 +
 
 +
|
 +
Aufsetzen eines IVS-Architekturprojekts unter Nutzung von:
 +
 
 +
*[[Media:_IVS-Domäne-Template_00-00-01.docx|O:IVS-Domäne]]
 +
*[[Media:_IVS-Dienst-Template_00-00-01.docx|O:IVS-Dienst]]
 +
 
 +
| Aufsetzen des IVS-Referenzarchitekturprojekts
 +
*[[PhaseA-Step1-Los2|Verkehrsinformation Individualverkehr]]
 +
*[[PhaseA-Step1-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
 +
*[[Kap._1_Aufsetzen_des_Architekturprojekts|Multimodale Reiseinformation]]  
  
−
|-
+
| Aufsetzen des IVS-Architekturprojekts für einen realen IVS-Dienst
−
|- style="vertical-align:top;"
+
|- style="vertical-align:top"
−
| 2 || ''' Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen '''
+
| 2
−
Identifizieren Sie die wichtigsten Stakeholder und ihre Anliegen/Ziele und definieren Sie die wichtigsten Business-Anforderungen verbindlich für die Architektur.  
+
| Identifizierung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_02 Stakeholdern mit deren Anliegen und Geschäftsanforderungen]
−
Drei Wichtige Ziele sollen in dieser Phase erreicht werden:
+
| Identifizierung der IVS-Rollen mit deren Anliegen und Geschäftsanforderungen
−
*Mögliche Komponenten und Anforderungen für die Phase A (Architekture Vision) identifizieren und diese während des Ablaufes von Phase A überprüfen.
+
| [[IVS-Rollenkonzept#Erfassung_und_Beschreibung_von_IVS-Rollen|'''Erfassung und Beschreibung von IVS-Rollen''']]
−
*Den Umfang der möglichen Komponenten begrenzen, um das Ausmaß der anschließenden Überprüfungen so gering wie möglich zu halten.
+
*[[IVS-RollenMap-Template|Template: IVS-Rollen-Map]]
−
*Identifizierung von Anliegen der Stakeholder, möglichen Problemen und kulturellen Faktoren, zu Festlegung, wie und in welcher Form die Architektur präsentiert und kommuniziert wird.
+
*[[IVS-Rolle|Template: Baustein IVS-Rolle]]
−
Das Resultat am Ende dieses Schrittes ist eine „Karte“, die zeigt, welche Stakeholder beteiligt sind, deren Grad der Beteiligung, und ihre wichtigsten Anliegen. Die Stakeholder-Karte wird verwendet, um verschiedene Outputs der Architecture Vision (Phase A) zu unterstützen und zu identifizieren:
+
*[[IVS-Anforderungen|Template: Baustein IVS-Anforderung]]
−
*Die Bedenken und Perspektiven, die für dieses Projekt relevant sind.
+
*[[BS_Template_Seite|Template: Business Szenario]]
−
*Die Stakeholder, die an dem Projekt beteiligt sind, als Ausgangspunkt zur Bildung eines Kommunikationsplans.  
+
 
−
*Die wichtigsten Aufgaben und Verantwortlichkeiten innerhalb des Projekts, die im Statement der zu verrichtenden Architektur-Arbeit aufgenommen werden sollten.
+
;'''Hintergrundinformationen und Techniken'''
−
Eine weitere wichtige Aufgabe ist es zu prüfen, welche Architektur-Sichten und Perspektiven entwickelt werden müssen, um die verschiedenen Stakeholder-Anforderungen zu erfüllen.  
+
:[[IVS-Rollenkonzept|IVS-Rollenkonzept]]
−
Die während der Architecture Vision (Phase A) erzeugte neue Anforderungen an die künftige Architektur müssen, im Rahmen der Anforderungen, dokumentiert werden (Bspw. in einer sog. Architecture Requirements Specification). Neue Anforderungen, die nicht in dem vorbestimmten Rahmen der ausgewählten Anforderungen sind, müssen in ein Anforderungen-Repository aufgenommen werden zur anschließenden Weiterverarbeitung durch einen Anforderungsmanagement-Prozess.
+
:[[Business-Szenarien|Business-Szenarien als Technik zur Erhebung von Anforderungen, Stakeholdern, IVS-Rollen ...]]
−
||  
+
 
−
''' Identifizierung
+
|
−
*''' der IVS-Wertschöfungskette/des IVS-Wertschöfungsnetzwerks'''
+
*[[Media:_IVS-Rollen-Template-Katalog_00-00-06.xlsx|O:IVS-Rollen-Map]]
−
*''' des IVS-Produkts für den Endkunden'''  
+
*[[Media:_IVS-Rollen-Template-Katalog_00-00-04.docx|K:IVS-Rollen]]
−
*'''Identifizierung der IVS-Rollen mit deren Anliegen und Geschäftsanforderungen '''
+
*[[Media:_IVS-Anforderung-Template-Katalog_00-00-01.docx|K:IVS-Anforderungen]]
 +
*[[Media:_IVS-Business-Szenario-Template_00-00-04.docx|O:Business Szenarien]]
 +
 
 +
| IVS-Referenzarchitekturspezifische Erfassung und Beschreibung von IVS-Rollen
 +
*[[PhaseA-Step2-Los2|Verkehrsinformation Individualverkehr]]
 +
*[[PhaseA-Step2-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
 +
*[[Kap._2_Identifizierung_der_Stakeholder|Multimodale Reiseinformation]]
 +
 
 +
| IVS-Dienstspezifische Erfassung und Beschreibung von IVS-Rollen
 +
|- style="vertical-align:top"
 +
| 3
 +
| Bestätigung und Ausarbeitung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_03 geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen]
 +
| Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für IVS-Dienste
 +
| '''[[IVS-Geschäftsziele|Geschäftliche Ziele, strategische Einflussfaktoren und Rahmenbedingungen für IVS]]'''
 +
*[[IVS-Leitbild|Template: Baustein IVS-Leitbild]]
 +
*[[IVS-Geschäftsziele-Template|Template: Baustein IVS-Geschäftsziele]]
 +
 
 +
'''Hintergrundinformationen und Techniken'''
 +
 
 +
:[[IVS-Leitbild_Verständnis|Was verstehen wir unter einem IVS-Leitbild]]
 +
:[[Leitbild|Definition und Aufbau eines IVS-Leitbilds]]
 +
 
 +
|
 +
*[[Media:_IVS-Leitbild-Template-Katalog_00-00-01.docx|K:IVS-Leitbilder]]
 +
*[[Media:_IVS-Geschäftsziele-Template_00-00-01.docx|K:IVS-Geschäftsziele]]
 +
 
 +
| Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für IVS-Dienste-Kategorien
 +
*[[PhaseA-Step3-Los2|Verkehrsinformation Individualverkehr]]
 +
*[[PhaseA-Step3-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
 +
*[[Kap._3_Geschäftsziele_&_Geschäftstreiber|Multimodale Reiseinformation]]
 +
 
 +
| Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für spezifische IVS-Dienste
 +
|- style="vertical-align:top"
 +
| 4
 +
| Bewertung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_04 Geschäftsfähigkeiten]
 +
| Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen
 +
| '''[[IVS-Capibilities|IVS-Capabilities von IVS-Rollen]]'''  
 +
*[[IVS-Capability-Template|Template: Baustein IVS-Capability]]
 +
 
 +
|
 +
*[[Media:_IVS-Capability-Template-Katalog_00-00-01.docx|K:IVS-Capabilities]]
 +
 
 +
| IVS-Kategoriespezifische Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen
 +
*[[PhaseA-Step4-Los2|Verkehrsinformation Individualverkehr]]
 +
*[[PhaseA-Step4-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
 +
*[[Kap._4_Bewertung_der_Geschäftsfähigkeiten|Multimodale Reiseinformation]]
 +
 
 +
| IVS-Dienstspezifische Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen
 +
|- style="vertical-align:top"
 +
| 5
 +
| Bewertung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_05 Reife für eine Transformation des Geschäfts]
 +
| Bewertung der Reife für das Aufsetzen eines IVS-Dienstes
 +
| Projektspezifische Anleitung (Schritt nicht IVS-spezifisch)
 +
| Projektspezifische Lösung
 +
|
 +
Projektspezifische Lösung
 +
 
 +
*[[Kap._5_Transformation_des_Geschäfts|Multimodale Reiseinformation]]
 +
 
 +
| Projektspezifische Lösung
 +
|- style="vertical-align:top"
 +
| 6
 +
| [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap07.html#tag_07_04_06 Reichweite der Architektur festlegen]
 +
| Reichweite von Referenzarchitekturen und Architekturen realer Systeme
 +
| '''[[Reichweite_der_Architektur|Reichweite der Architektur]]'''
 +
| Projektspezifische Lösung
 +
| Projektspezifische Lösung
 +
*[[PhaseA-Step6-Los2|Verkehrsinformation Individualverkehr]]
 +
*[[Kap._6_Definition_des_Wirkungsbereichs|Multimodale Reiseinformation]]
 +
 
 +
| Projektspezifische Lösung
 +
|- style="vertical-align:top"
 +
| 7
 +
| Bestätigung und Ausarbeitung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_07 Architekturprinzipien, einschließlich Geschäftsprinzipien]
 +
| Überprüfung und ggf. Konkretisierung/Ergänzung der in der Vorbereitungsphase aufgestellten Architektur- und Geschäftsprinzipen
 +
| Projektspezifische Anleitung
 +
| Projektspezifische Lösung
 +
|
 +
Projektspezifische Lösung
 +
 
 +
*[[Kap._7_Architekturprinzipien_und_Geschäftsprinzipien|Multimodale Reiseinformation]]
  
−
Das Resultat am Ende dieses Schrittes ist eine „Karte“, die zeigt, welche Stakeholder beteiligt sind, deren Grad der Beteiligung, und ihre wichtigsten Anliegen. Die Stakeholder-Karte wird verwendet, um verschiedene Outputs der Architecture Vision (Phase A) zu unterstützen und zu identifizieren:
+
| Projektspezifische Lösung
−
*Die Bedenken und Perspektiven, die für dieses Projekt relevant sind.
+
|- style="vertical-align:top"
−
*Die Stakeholder, die an dem Projekt beteiligt sind, als Ausgangspunkt zur Bildung eines Kommunikationsplans.  
+
| 8
−
*Die wichtigsten Aufgaben und Verantwortlichkeiten innerhalb des Projekts, die im Statement der zu verrichtenden Architektur-Arbeit aufgenommen werden sollten.
+
| Entwicklung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_08 Architekturvision]
−
Eine weitere wichtige Aufgabe ist es zu prüfen, welche Architektur-Sichten und Perspektiven entwickelt werden müssen, um die verschiedenen Stakeholder-Anforderungen zu erfüllen.  
+
| Entwicklung der IVS-Architekturvision
−
Die während der Architecture Vision (Phase A) erzeugte neue Anforderungen an die künftige Architektur müssen, im Rahmen der Anforderungen, dokumentiert werden (Bspw. in einer sog. Architecture Requirements Specification). Neue Anforderungen, die nicht in dem vorbestimmten Rahmen der ausgewählten Anforderungen sind, müssen in ein Anforderungen-Repository aufgenommen werden zur anschließenden Weiterverarbeitung durch einen Anforderungsmanagement-Prozess.
+
| '''[[IVS-Architekturvision|IVS-Architektur Vision]]'''
−
+
*[[IVS-Vision-Template|Template: Other Deliverable IVS-Architekturvision]]  
−
|| [[IVS-Wertschöpfung | IVS-Wertschöpfungs- und Rollenkonzept]]
 
  
−
|-
+
|  
−
|- style="vertical-align:top;"
+
*[[Media:_IVS-Architekturvision_Template.docx|O: IVS-Architekturvision]]
−
| 3 || ''' Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen '''
 
−
Identifizieren Sie die Unternehmensziele und die strategischen Treiber der Organisation.
 
  
−
Falls diese bereits an anderer Stelle innerhalb der Organisation definiert worden sind, sollte sichergestellt sein, dass die bestehenden Definitionen aktuell sind und mögliche Mehrdeutigkeiten geklärt sind. Andernfalls sollte mit den verantwortlichen Planern der durchzuführenden Architektur-Arbeit zusammengearbeitet werden, indem wesentlichen Elemente definiert und diese mit der Organisationsführung abgeklärt werden.
+
| Entwicklung der IVS-Architekturvision für die IVS-Kategorie
 +
*[[PhaseA-Step8-Los2|Verkehrsinformation Individualverkehr]]
 +
*[[PhaseA-Step8-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
 +
*[[Kap._8_Entwicklung_der_Architekturvision|Multimodale Reiseinformation]]
  
−
Definieren Sie einzuhaltenden Auflagen, einschließlich unternehmensweiten Einschränkungen aber auch projektspezifischen Einschränkungen (Zeit, Zeitplan, Ressourcen usw.). Unternehmensweite Auflagen können in der Vorphase (Prelimary Phase) oder in Phase A geklärt werden. (Architekturprinzipien und Unternehmensprinzipien)
+
| Entwicklung der IVS-Architekturvision für den spezifischen IVS-Dienst
−
||''' Bestätigung und Ausarbeitung von Geschäftszielen, Geschäftstreibern und Rahmenbedingungen für IVS''' ||
+
|- style="vertical-align:top"
−
*harmonisierte Einführung von IVS
+
| 9
−
*durchgängige und verbesserte IVS-Anwendungen und IVS-Dienste
+
| Definition des [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_09 Wertbeitrags der Zielarchitektur und der KPI's]
−
*Erleichterung bei der Entwicklung und Einführung von IVS-Diensten
+
| Definition des Wertbeitrags und KPI's von IVS-Architektur
−
*Sicherheit für öffentliche Betreiber bezüglich Kompatibilität und Interoperabilität von IVS-Anwendungen
+
| '''[[Ziele_und_Nutzen|Wertbeitrag und KPI's von IVS-Architektur]]'''  
−
*geringerer Entwicklungsaufwand und Planungssicherheit für die Industrie
+
*[[WertbeitragVonIVS-Architektur-Template|Template: Other Deliverable Wertbeitrag und KPI's von IVS-Architekturbausteinen]]
−
*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
 
  
−
|-
+
|  
−
|- style="vertical-align:top;"
+
*[[Media:_IVS-KPIs-Template-Katalog_00-00-01.docx|O:Wertbeitrag und KPI's von IVS-Architekturbausteinen]]  
−
| 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
 
−
||
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
| 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 [http://wikiivs.albrechtconsult.com/index.php?title=TOGAF-Reifefaktoren 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 '''    ||
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
| 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:'''
+
| Definition des Wertbeitrags und KPI's von IVS-Architektur für die IVS-Dienstekategorie
−
*The breadth of coverage of the enterprise
+
*[[PhaseA-Step9-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
−
*The level of detail required
+
*[[Kap._9_Wertbeitrag_der_Zielarchitektur|Multimodale Reiseinformation]]
−
*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.)
 
−
||  ./. ||
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
| 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 '''
+
| Definition des Wertbeitrags und KPI's von IVS-Architektur für den spezifischen IVS-Dienst
−
*sind strategische Vorgaben, konkrete und verbindliche (IT-)Grundsätze und Orientierungshilfen. Beispiele hierfür sind:
+
|- style="vertical-align:top"
−
**Auswahl von Softwarelösungen: Best-of-Breed, End-to-End, Make or Buy
+
| 10
−
**Auswahl und Bewertung von Projekten: Priorität Kerngeschäft, Infrastrukturprojekte zuerst
+
| Identifizierung der [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_10 Risiken einer Geschäfts-Transformation und der Aktivitäten zur Risikominimierung]
−
**Entwurfsprinzipien: Vermeidung von Heterogenität, Technische Struktur folgt fachlicher Strukturierung, Vermeidung von Redundanzen, Nur das führende System ändert Stammdaten, etc.
+
| Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung
−
*Ihre Ausarbeitung ist Bestandteil der Architekturplanung. Beispiele für Architekturprinzipien sind:
+
| '''[[Risiko-Management|Risikomanagement bei der Umsetzung von IVS-Architektur]]'''  
−
**Serviceorientierung: Die Architektur verteilter Anwendungen ist so gestaltet, dass die serviceorientierte Bereitstellung von versicherungsfachlichen Funktionen unterstützt wird.
+
*[[IVS-Risikomanagement-Template|Template: Baustein Risiko von IVS-Architektur]]
−
**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.
 
−
|| Es werden Architektur-relevante Prinzipien auf allen Ebenen der IVS-Pyramide festgelegt||  
 
−
''' Strategie-Ebene '''
 
−
* Der Reisende ist Mittelpunkt des gemeinsamen Handelns aller IVS-Akteure
 
−
* Anwendung des "Open Data Prinzips"
 
−
* Einhaltung der [http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32013R0886 DELEGIERTE VERORDNUNG (EU) Nr. 886/2013 DER KOMMISSION vom 15. Mai 2013 zur Ergänzung der Richtlinie 2010/40/EU] des Europäischen Parlaments und des Rates in Bezug auf Daten und Verfahren für die möglichst unentgeltliche Bereitstellung eines Mindestniveaus allgemeiner für die Straßenverkehrssicherheit relevanter Verkehrsinformationen für die Nutzer
 
−
''' Geschäftsprozess-Ebene'''
 
−
* Service-Orientierung
 
−
* Datenaustasuch über den National Access Point MDM
 
−
''' Informationsarchitekur-Ebene''' 
 
−
* Offene Schnittstellen
 
−
* Nutzung und Anwendung internationaler Standards für den Datenaustausch
 
−
|-
 
−
|- style="vertical-align:top;"
 
−
| 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).
+
|
 +
*[[Media:IVS-Risikomanagement-Template-00-00-02.docx|K:Risiken von IVS-Architektur]]
  
−
|| ./.  ||
+
| Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung für die IVS-Dienstekategorie
−
|-
+
*[[PhaseA-Step10-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
−
| 9 || ''' Definition des Wertbeitrags der Zielarchitektur und der KPIs '''
+
*[[Kap._10_Risiken_einer_Geschäftstransformation|Multimodale Reiseinformation]]
−
*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.
+
| Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung für den spezifischen IVS-Dienst
−
|| ''' Diskussion '''    ||
+
|- style="vertical-align:top"
−
|-
+
| 11
−
| 10 || ''' Identifizierung der Risiken einer Geschäfts-Transformation und der Aktivitäten zur Risikominimierung''' || ''' Diskussion '''    ||
+
| Entwicklung von [http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap07.html#tag_07_04_11 Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit, Sichern der Zustimmung]
−
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.
+
| Entwicklung von IVS-Architekturplänen und Aufträgen für die IVS-Architekturarbeit, Sichern der Zustimmung der Stakeholder
−
|-
+
| Projektspezifische Anleitung (Schritt nicht IVS-spezifisch)
−
| 11 || '''Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit,Sichern der Zustimmung'''
+
| Projektspezifische Lösung
−
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.
+
Projektspezifische Lösung
−
*Specific performance-related work products are available.
 
  
−
Then, activities will include:
+
*[[Kap._11_Entwicklung_von_Unternehmensarchitekturplänen|Multimodale Reiseinformation]]
  
−
*Identify new work products that will need to be changed
+
| Projektspezifische Lösung
−
*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 '''    ||
 
 
|}
 
|}
 +
 +
== Schritte der Phase A - IVS-Architekturvision im Überblick ==
 +
 +
[[File:Phase-A 00-00-03.png|thumb|left|300px|Phase A - IVS-Architekturvision]]
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
  
  
Zeile 174: Zeile 243:
  
  
−
-----------------------------------------------------------------------------
+
[[Hauptseite|<< Zurück zur Hauptseite]]
−
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.
 

Aktuelle Version vom 21. Juni 2018, 11:00 Uhr

Einführung in die "Phase A – Entwicklung einer Architekturvision"

In Phase A – Entwicklung einer Architekturvision geht es grundsätzlich darum, eine Vision für einen IVS-Dienst bzw. eine IVS-Dienstkategorie zu entwickeln und - auf einem hohen Niveau - einen ersten Aufschlag für die IVS-Architektur und ihre Architekturdomänen zu machen. Stakeholdern und Beteiligten soll anhand der Vision vermittelt werden, wie ihre strategischen und geschäftlichen Erwartungen berücksichtigt werden, wie diese in Form von geschäftlichen Zielen (engl. business goals) formuliert werden und mit welchen messbaren Zielen (engl. business objectives) ihre Zielerreichung am Ende bewertet werden kann.

Ein wichtiger Kern der Phase A ist es, den Zweck des Architekturansatzes zu klären (zu erklären), darüber unter allen Beteiligten Konsens zu erzielen und diesen in Form einer Vision zu formulieren.

Normalerweise sind Schlüsselelemente einer Architekturvision bereits Bestandteil einer weiter gefassten, z. B. politischen Strategie. Hier gilt es, die Vision so zu formulieren, dass ein Bezug zu dieser Strategie hergestellt wird und die Architekturvision darin eingeordnet werden kann. Beispiele für politische Strategien sind der europäische IVS-Aktionsplan, die europäische IVS-Direktive und der Europäische C-ITS-Masterplan. Beispiele für nationale Strategien sind der IVS-Aktionsplan Straße sowie die Strategie automatisiertes und vernetztes Fahren der Bundesregierung.

Business-Szenarien stellen eine nützliche Technik dar, um strategische und geschäftliche Anforderungen zu identifizieren, zu dokumentieren und daraus eine Vision zu artikulieren, die diesen Anforderungen entspricht. Business-Szenarien stellen insofern eine gesonderte Methode innerhalb der TOGAF-ADM dar.

Schritte der "Phase A - IVS-Architekturvision"

Schritt TOGAF Tailoring IVS-Rahmenarchitektur Anleitung Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables Empfehlung für IVS-Referenzarchitekturen Empfehlung für IVS-Architekturen realer IVS-Dienste
1 Aufsetzen des Architekturprojekts Aufsetzen des IVS-Architekturprojekts Aufsetzen eines Architekturprojekts
Hintergrundinformationen und Techniken "IVS-Domäne"
IVS-Domänen-Konzept
Hintergrundinformationen und Techniken "IVS-Dienst"
IVS-Dienste-Konzept
Hintergrundinformationen und Techniken "IVS-Wertschöpfungskette"
Beispiel Wertschöpfung im System Straße
Beispiel Verkehrsinformation Individualverkehr
Beispiel Zuständigkeitsübergreifendes Verkehrsmanagement
Beispiel Multimodale Verkehrsinformation

Aufsetzen eines IVS-Architekturprojekts unter Nutzung von:

Aufsetzen des IVS-Referenzarchitekturprojekts Aufsetzen des IVS-Architekturprojekts für einen realen IVS-Dienst
2 Identifizierung von Stakeholdern mit deren Anliegen und Geschäftsanforderungen Identifizierung der IVS-Rollen mit deren Anliegen und Geschäftsanforderungen Erfassung und Beschreibung von IVS-Rollen
Hintergrundinformationen und Techniken
IVS-Rollenkonzept
Business-Szenarien als Technik zur Erhebung von Anforderungen, Stakeholdern, IVS-Rollen ...
 IVS-Referenzarchitekturspezifische Erfassung und Beschreibung von IVS-Rollen IVS-Dienstspezifische Erfassung und Beschreibung von IVS-Rollen
3 Bestätigung und Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für IVS-Dienste Geschäftliche Ziele, strategische Einflussfaktoren und Rahmenbedingungen für IVS

Hintergrundinformationen und Techniken

Was verstehen wir unter einem IVS-Leitbild
Definition und Aufbau eines IVS-Leitbilds
 Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für IVS-Dienste-Kategorien Ausarbeitung von geschäftlichen Zielen, strategischen Einflussfaktoren und Rahmenbedingungen für spezifische IVS-Dienste
4 Bewertung der Geschäftsfähigkeiten Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen IVS-Capabilities von IVS-Rollen IVS-Kategoriespezifische Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen IVS-Dienstspezifische Entwicklung/Bewertung der IVS-Capabilities von IVS-Rollen
5 Bewertung der Reife für eine Transformation des Geschäfts Bewertung der Reife für das Aufsetzen eines IVS-Dienstes Projektspezifische Anleitung (Schritt nicht IVS-spezifisch) Projektspezifische Lösung

Projektspezifische Lösung

Projektspezifische Lösung
6 Reichweite der Architektur festlegen Reichweite von Referenzarchitekturen und Architekturen realer Systeme Reichweite der Architektur Projektspezifische Lösung Projektspezifische Lösung Projektspezifische Lösung
7 Bestätigung und Ausarbeitung von Architekturprinzipien, einschließlich Geschäftsprinzipien Überprüfung und ggf. Konkretisierung/Ergänzung der in der Vorbereitungsphase aufgestellten Architektur- und Geschäftsprinzipen Projektspezifische Anleitung Projektspezifische Lösung

Projektspezifische Lösung

Projektspezifische Lösung
8 Entwicklung der Architekturvision Entwicklung der IVS-Architekturvision IVS-Architektur Vision Entwicklung der IVS-Architekturvision für die IVS-Kategorie Entwicklung der IVS-Architekturvision für den spezifischen IVS-Dienst
9 Definition des Wertbeitrags der Zielarchitektur und der KPI's Definition des Wertbeitrags und KPI's von IVS-Architektur Wertbeitrag und KPI's von IVS-Architektur Definition des Wertbeitrags und KPI's von IVS-Architektur für die IVS-Dienstekategorie Definition des Wertbeitrags und KPI's von IVS-Architektur für den spezifischen IVS-Dienst
10 Identifizierung der Risiken einer Geschäfts-Transformation und der Aktivitäten zur Risikominimierung Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung Risikomanagement bei der Umsetzung von IVS-Architektur Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung für die IVS-Dienstekategorie Identifizierung der Risiken der Umsetzung von IVS-Architektur und der Aktivitäten zur Risikominimierung für den spezifischen IVS-Dienst
11 Entwicklung von Unternehmensarchitekturplänen und Aufträgen für die Architekturarbeit, Sichern der Zustimmung Entwicklung von IVS-Architekturplänen und Aufträgen für die IVS-Architekturarbeit, Sichern der Zustimmung der Stakeholder Projektspezifische Anleitung (Schritt nicht IVS-spezifisch) Projektspezifische Lösung

Projektspezifische Lösung

Projektspezifische Lösung

Schritte der Phase A - IVS-Architekturvision im Überblick

Phase A - IVS-Architekturvision















<< Zurück zur Hauptseite

Abgerufen von „http://wikiivs.albrechtconsult.com/index.php?title=TOGAF-Phase_A&oldid=13838“