IVS-Wiki - Benutzerbeiträge [de]

IVS-Capability-Template

2018-02-15T09:54:51Z

Romas:

== [[IVS-Capibilities|IVS-Capability...]] ==
*ist ein IVS-Architekturbaustein, der eine '''Fähigkeit''' repräsentiert, die ein '''IVS-Akteur als Bestandteil einer IVS-Prozesskette''' (IVS-Wertschöpfungskette/IVS-Wertschöpfungsnetzwerk) mitbringen muss, damit am Ende der potentielle Nutzen des IVS-Dienstes verwirklicht werden kann.
*ist als '''Business Capability (Geschäfts-Fähigkeit)''' für jedes Unternehmen von strategischer Bedeutung, weil sie eine Eigenschaft kennzeichnet, die für eine Institution/ein Unternehmen unbedingt erforderlich ist, damit sie/es ihre/seine strategischen Ziele erreichen kann.

== Template als Tabelle ==

{| class="wikitable" style="width: 941px"
|+
|+
|-
! colspan="2" | IVS-Capability
! colspan="3" | Beteiligungen
! rowspan="2" style="width: 267px" | Abhängigkeit von anderen IVS-Capabilities
|- style="vertical-align:top"
| '''Bezeichnung'''
| '''Beschreibung '''
| '''Beteilgte IVS-Rollen'''
| '''Beteiligte IVS-Prozesse'''
| '''Beteiligte IVS-Anwendungsprozesse'''
|}

== Template als Word-Datei ==
[[Media:IVS-Capability-Template-Katalog_00-00-01.docx|IVS-Capability]]

----
[[Hauptseite|<< Zurück zur Hauptseite]]

Diskussion:IVS-Architekturprinzipien

2017-12-05T15:59:06Z

Romas:

== Intelligent Transport Systems ==

*are intelligent applications in the field of transport, traffic and mobility, which the end-user uses as an ITS service and in which information and communication technologies (ICT) are used to implement the data and information exchange necessary for interaction and enable end-users with more comprehensive information to use transport networks in a safer, more coordinated and "wise" way (see the status and framework conditions for Intelligent Transport Systems ITS in Germany 2010[1]).
*use information and communication technologies (ICT) in road transport and at the interfaces with other modes of transport to collect, transmit, process and exchange traffic-related data and information (see ITS Law).
*are not allowed to use the word intelligence in the sense of artificial intelligence (AI), but must be understood in the sense of business intelligence. Intelligence is a synonym for information and insights gained by collecting and evaluating data and information with the aim of enabling the end-user of ITS to make better strategic and/or operational decisions with regard to his or her objectives, or, from the operator's point of view, to exercise a special effect on end-users of ITS in such a way that they orient their behaviour towards the operator's objectives.

== ITS architecture - the architecture of intelligent transport systems ==

ITS architecture essentially deals with not only the functional, technical and economic realisation but above all the creative planning of ITS and ITS services. ITS architecture is hereby based on overarching policies and aims of the “builder-owners”.

In this respect, the core competence of an ITS architect goes beyond a simple knowledge of how to realise ITS and ITS services and lies primarily in the creation of an ITS architecture based on suggestions and characteristics of features of ITS architecture that correspond to the policies and aims of the builder-owner, or they develop their own ideas on this.

== The ITS architecture pyramid ==

The “ITS System Architectures” working group of the Road and Transportation Research Association (FGSV) has suggested that ITS architects use the “ITS pyramid” described and substantiated below as a suitable meta-model and methodological aid for a well-organised and understandable representation and description of ITS services ([[Media:W1-Papier_AK_3_1_4_v2_1.pdf|see Notes on Structuring a Framework Architecture for Intelligent Transport Systems (ITS) in Germany – Necessity and Methodology, FGSV No. 305<ref>Rittershaus, Lutz; Aicher, Peter; Albrecht, Hanfried u.a. (2012): Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland – Notwendigkeit und Methodik. Hg. v. FGSV. FGSV. Köln (Nr. 305). Online verfügbar unter https://trid.trb.org/view.aspx?id=1141880, zuletzt geprüft am 24.10.2017.</ref>]]).

[[File:The ITS architecture pyramid with 5 levels en.png|thumb|right|250px|The ITS architecture pyramid with 5 levels]]

'''The ITS architecture pyramid'''

*consists of five layers, which together cover the potentially possible scope within which an ITS architecture can be considered and shown.
*represents the structure of ITS services so as to be able to better identify, classify and correlate their properties by means of this.
*provides the semantics for the ITS business models needed to describe ITS services.

The ITS architecture pyramid contains the following layers:

'''The policy/strategy level''' describes...

*the goals of ITS and ITS services (creation of added value) in the form of a policy,
*how, i.e. in which way the ITS goals are to be achieved (strategy).

'''The processes level '''describes and identifies...

*which ITS roles are involved in the creation of added value with the help of ITS,
*how the ITS roles interpret ITS goals and ITS strategy for themselves as a business case,
*how the ITS added value/ITS benefits are generated by means of the cooperation/relationship between the ITS roles and operationalized in ITS business processes.

'''The information structures level '''describes and identifies ...

*which ITS information contributes to the creation of ITS added value, and
*how this is structured.

'''The IT services level''' and '''IT infrastructure level''' describe ...

*how the ITS information can be generated, and
*how/where it is provided.

The ITS architecture pyramid can be used in all phases of a content-related discussion on all relevant aspects of ITS and ITS services. Above all, demands for an altered understanding of roles can be identified and specified using the ITS architecture pyramid. The ITS architecture pyramid can always convey the logical context, particularly if distributed ITS services are to be realised.

== Instances of ITS architecture ==

The [[Media:W1-Papier_AK_3_1_4_v2_1.pdf|“Notes on Structuring a Framework Architecture for Intelligent Transport Systems (ITS) in Germany – Necessity and Methodology, FGSV No. 305”]] differentiate between three instance levels for ITS architectures.

[[File:Instance levels of ITS architecture en.png|thumb|right|250px|Instance levels of ITS architecture]]

The '''ITS framework architecture...'''

*specifies ITS design elements as architectural modules (TOGAF: building blocks) and defines terms and their corresponding semantics (ITS glossary).
*specifies design principles, on the basis of which the ITS architect is to proceed when planning and realising ITS services.

An'''ITS reference architecture...'''

*specifies the concepts for an ITS service category (ITS service family) for the scope of a specific ITS domain predetermined by the ITS framework architecture.

The '''ITS architecture of real ITS services...'''

*is the actual implementation of relevant ITS reference architectures down to the last level of detail in a concrete application case.

The number of ITS reference architectures is basically unlimited. In the present project network for lots 1- 4, ITS reference architectures have been developed for '''three ITS service categories''' in lots 2 to 4, namely:

*Lot 2: '''Continuous traffic information private traffic'''
*Lot 3: '''Cross-organisational traffic management'''
*Lot 4: '''Multi-modal travel information'''

== Features of ITS architecture to implement ITS architecture ==

[[File:Implementation of ITS architecture en.png|thumb|right|250px|Implementation of ITS architecture]]

ITS architecture concepts that are formulated by '''features '''of '''ITS architecture''' and '''their semantics '''and that should uniformly determine the character and nature of ITS services have to be developed for the implementation of ITS architecture. The entirety of ITS architecture concepts could be called the '''ITS architecture school'''.

For example, if “interoperability” is a stylistic feature of the ITS architects/ITS architecture school, the architectural feature “interoperability” will turn up again in all parts of the ITS object of reflection in a wide variety of manifestation.

The ITS architecture school that is represented by the ITS framework architecture predominantly implements political objectives. However, because “clever” politics always incorporates the interests of the basis too, the "received opinion" also reflects the '''builder-owner’s interest in real ITS services '''through the permanent incorporation of stakeholders and ITS actors (see also[[Open-IVS|“Open ITS” as a main idea]]).

== Concept instantiation to specify ITS architecture ==

[[File:Going Meta en.png|thumb|right|250px|Going Meta]]

The methodology of '''concept instantiation''', in other words the transfer and representation of ITS architecture concepts with their semantics (see too [[Meta-Modelle#Modelle_als_Grundlage_f.C3.BCr_Nachvollziehbarkeit|the model basis for comprehensibility]]), starting from the ITS framework architecture, through the ITS reference architecture, right down to ITS architectures for real ITS services.

*'''The''' '''ITS framework architecture '''(meta-meta model of the real world) structures, describes semantically and ultimately substantiates the architectural concepts necessary for the ITS architecture of ITS services through the suggestion of corresponding features of ITS architecture.
*'''ITS reference architectures''' (meta-models of the real world) specify the architectural concepts of the ITS framework architecture for a category of ITS services.
*'''ITS architectures for real ITS services''' (models of the real world) further specify and implement the architectural concepts of the ITS framework architecture for a real ITS service that has already been specified for a category of ITS services.

'''Examples of concept instantiation''' are:

{| class="wikitable"
|-
! scope="col" style="width: 292px; height: 66px;" |
'''The ITS framework architecture module'''

! scope="col" style="width: 305px; height: 66px;" |
'''Use for the ITS reference architecture'''

! scope="col" style="width: 286px; height: 66px;" |
'''Use for the ITS architecture of real ITS services'''

|-
| style="width: 292px; height: 124px;" |
'''ITS service as '''a concept'''(principle of the ITS value-added chain/ITS value-added network)'''

| style="width: 305px; height: 124px;" |
'''Stereotype of ITS services '''(traffic information private traffic, cross-organisational traffic management and multi-modal traffic information)

| style="width: 286px; height: 124px;" |
'''Real ITS service''' (Google Maps, Dmotion traffic control for alternative routes, Deutsche Bahn travel information ...)

|-
| style="width: 292px; height: 86px;" |
'''ITS role as '''a concept'''(as an add-on element for ITS value-added chains and networks)'''

| style="width: 305px; height: 86px;" |
'''Stereotypes of ITS actors '''(navigation service provider, public roads operator, transport company ...)

| style="width: 286px; height: 86px;" |
'''Real ITS actors''' (Google, Hessen Mobil/Office for Traffic Management Düsseldorf and Deutsche Bahn)

|-
| style="width: 292px; height: 105px;" |
'''ITS added value as '''a concept (as a goal and result of the ITS value-added chains and networks)

| style="width: 305px; height: 105px;" |
'''Stereotypes of ITS added values''' (increased safety, improved efficiency, reduction of environmental impacts ...)

| style="width: 286px; height: 105px;" |
'''Real ITS parameters''' (number of deaths by accident, traffic jam balance, CO2 and NOX emissions)

|}

However, the '''ITS architecture of a real ITS service '''does not necessarily have to '''comply with the ITS framework architecture and ITS reference architecture in all points'''. The breadth and depth of the ITS architecture concept instantiation are left to the '''discretion of the implementer'''. The evaluation of the ITS architecture and thus the benefit of a real ITS service is therefore left to the '''discretion of the user'''.

== Quality of ITS architecture ==

'''Is there a “good” ITS architecture?'''

Constructive foresight is a desirable qualification of an ITS architect; it is something he/she either does or does not have. If they have it, they will use the freedom it offers to design ITS services so that the features of the current service to be implemented do not get in the way of one of the main goals of ITS architecture, insofar as they are aware of this, '''namely future possibilities for integration or extension'''.

An ITS reference architecture or the ITS architecture of a real ITS service are a “good” architecture if they transfer the features of the ITS framework architecture to the architecture of an ITS service category or a real ITS service true to the concept.

However, it should be remembered that “good” is an ideal. In other words,'''the ITS framework architecture is primarily an aid to orientation and assessment in a concrete application case''' so as to be able to understandably pursue the purpose of achieving a good architecture. Unavoidable deviations can then be identified, evaluated and in classified in an overall picture.

== Combination of TOGAF concepts with the ideas of ITS architecture ==

=== Architecture domains of TOGAF ===

[[File:Architecture domains of TOGAF en.png|thumb|right|250px|Architecture domains of TOGAF en.png]]

In order to make the discussion about terms and their semantics in the “ITS Architecture Road for Germany” project more objective and effective from the very outset, and to adjust this to the overarching objective of a consensual creation of an ITS framework architecture and three ITS reference architectures, [https://de.wikipedia.org/wiki/TOGAF the standardisation initiative TOGAF] offer the meta-model of TOGAFG architecture domains arranged in layers with the aim of being able to describe the complex behaviour of companies on the basis of agreed (standardised) fundamental concepts (so-called base architectures) homogeneously in future under the key word corporate architecture.

This brings us full circle to the current idea of ITS architecture, which is characterised by the ITS architecture pyramid as a hierarchic regulating principle that can be portrayed on the layers of the layer model.

;Important notice:
:to find out more about TOGAF and the individual steps of the TOGAF ADM, an account has to be created on the “The Open Group” website ([https://www2.opengroup.org/ogsys/common/createIndividual.html?popup=true/ TOGAF-Login]).

=== TOGAF architecture domains and the levels of the ITS pyramid ===

TOGAF is an extensive model and contains some very powerful concepts. In this respect, one particular issue in the development of the ITS framework architecture is first to identify TOGAF concepts that are actually relevant for the ITS architecture and then to transpose these to ITS and put them across in such a way that ITS experts see a genuine benefit in them, actually accept and internalise them in the form of ITS architecture in the sense of an [[Open-IVS|“Open ITS” ]]('''theory meets practice''').

Against this background, the methodological challenge of using TOGAF consists of:

*transposing the TOGAF concepts, in other words what TOGAF is structurally and semantically really about, associated with the TOGAF architecture domains shown to ITS architecture domains, and
*addressing, and interpreting for ITS, those levels and sub-levels of the TOGAF architecture domains that are in fact important for the ITS functionality and ITS behaviour through the use and adaptation of the TOGAF-ADM (quality over quantity).

[[File:Illustration of the TOGAF architecture domains on the levels of the ITS pyramid en.png|thumb|right|250px|Illustration of the TOGAF architecture domains on the levels of the ITS pyramid]]

Of course, it is obvious that only the most important levels/sub-levels of the ITS framework architecture and their areas can and must be addressed, i.e. precisely those that are important '''for the functionality and behaviour of ITS services'''. Put metaphorically, those sub-areas of in the TOGAF levels have to be identified for ITS services that can subsume '''general design goals for ITS architectures''' (ITS reference architectures, ITS architecture of real ITS services) '''to the general TOGAF goals'''. ITS goals in this sense are more specific than TOGAF goals. A conformity is given, for example, if features of an ITS goal can also be identified as features of a TOGAF goal.

=== Relationship between TOGAF and ITS ===

TOGAF on the whole stands for a semantic structure that relates the TOGAF-relevant concepts and hence provides a fundamental order for the overarching designs of TOGAF domains. '''Designs should improve or even enable types of cooperation between ITS actors in global contexts in the first place'''. Efficiency and effectiveness are hereby key quality features in the arrangement of design-related decisions.

There has as yet been no “sharp” definition of ITS. This means that ways have to be found for interpretations which allow an explanation of how a general TOGAF view of TOGAF concepts can be transposed or related to ITS concepts that is comprehensible for third parties. Conversely, it also has to be shown that the generally speaking more specific ITS concepts are relevant for TOGAF. In other words, '''it must be possible to verify that the focus of ITS design corresponds to the purpose of the TOGAF design.'''

An agreement should be reached, wherever possible, on the use of existing and proven standards and the concepts offered therein for the linguistic description of elements of the terminology and their presentation. This is the only way to objectify subjective issues, at least in the presentation.

== Bibliography ==

<references />

[[Hauptseite|<< Zurück zur Hauptseite]]

Diskussion:TOGAF-Phase B

2017-09-22T08:59:46Z

Romas:

== Schritte der Phase B - IVS-Geschäftsarchitektur ==

'''Wichtige Hinweise''': [[Hinweise_zu_den_Phasen_B,C_und_D|zu den Schritten der IVS-Architekturentwicklung in den Phasen B, C und D]]

{| class="wikitable" width="1092"
|-
! Step
! TOGAF
! style="width: 141px" | Tailoring for ITS-Architectures
! style="width: 231px" | Instruction
! style="width: 219px" | Artefacts {C=Catalog, M=Matrix, D=Diagram}, O=Other Deliverables
! Recommendation for ITS-Reference Architectures
! Recommendation for ITS-Architectures of real ITS-Services
|- style="vertical-align:top"
| 1
| Selection  [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_01 of means, views and tools for the presentation of the Business Architecture]
| style="width: 141px" | Selection of means, views and tools for the presentation of the ITS-Business Architecture
| style="width: 231px" | [[Hilfsmittel,_Sichten_und_Werkzeuge_für_IVS-Geschäftsarchitektur|'''Means, views and tools for the presentation of the ITS-Business Architecture''']]
;Background information and techniques
:[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|Presentation of ITS Value-added chains and networks]]
:[[IVS-Governance|Presentation of ITS-Governance]]
:[[Geschäftsprozesse|Presentation of ITS-Business processes]]

| style="width: 219px" | Project-specific solutions
| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a ITS category service
*[[PhaseB-Step1-Los2|Traffic information of individual transport]]
*[[PhaseB-Step1-Los3|Cross-organisational traffic management]]
*[[Hilfsmittel_und_Werkzeuge_Los4|Multimodal travel information]]

| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a specific ITS-Service
|- style="vertical-align:top"
| 2
| Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_02 initial situation  of the Business Architecture]
| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture
| style="width: 231px" | '''[[IVS-Geschäftsarchitektur_Ausgangssituation|Initial situation of the ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business Process]]

| style="width: 219px" | Project-specific solution (where available or required)
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| Description of the initial situation of the ITS-Business Architecture for the ITS-Category (where available)
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| Description of the initial situation of the ITS-Business Architecture for the specific ITS-Service (where required)
|- style="vertical-align:top"
| 3
| Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_03 Target Business Architecture]
| style="width: 141px" | Description of the Target-ITS-Business Architecture
| style="width: 231px" | '''[[Zielsituation_der_IVS-Geschäftsarchitektur|Target-ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business process]]

| style="width: 219px" |
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:_IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-]][[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| Description of the Target-ITS-Business Architecture for the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| Description of the Target-ITS-Business Architecture for the specific ITS-Service
|- style="vertical-align:top"
| 4
| Implementation of a [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_04 Gap-Analysis]
| style="width: 141px" | Implementation of a Gap-Analysis for the ITS-Business Architecture
| style="width: 231px" | '''[[Gap-Analyse_Geschäftsarchitektur|Gap-Analysis for the ITS-Business Architecture]]'''
| style="width: 219px" | Project-specific solution
| Implementation of a Gap-Analysis for the ITS-Business Architecture of the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| Implementation of a Gap-Analysis for the ITS-Business Architecture of the specific ITS-Service
|- style="vertical-align:top"
| 5
| Festlegung von Kandidaten für [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_05 die Architektur Roadmap]
| style="width: 141px" | Festlegung von IVS-Geschäftsarchitektur-Kandidaten für die IVS-Architektur-Roadmap
| style="width: 231px" | [[Roadmap_Geschäftsarchitektur|'''IVS-Geschäftsarchtekturkandiaten für die IVS-Architektur-Roadmap''']]
*[[Architektur-Roadmap|Template: Baustein IVS-Architektur-Roadmap]]

;Hintergrundinformationen und Techniken
:[[Roadmap_IVS-Architektur|Roadmap für IVS-Architektur]]

| style="width: 219px" |
*[[/images/5/55/Architektur-Roadmap_00-00-01.docx|O:IVS-Architektur-Roadmap]]

| Anlegen der IVS-Architektur-Roadmap für die IVS-Dienstekategorie
*[[PhaseB-Step5-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseB-Step5-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Architektur-Roadmap_Los4|Multimodale Reiseinformation]]

| Anlegen der IVS-Architektur-Roadmap für die IVS-Architektur des spezfischen IVS-Dienstes
|- style="vertical-align:top"
| 6
| Klärung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_06 Auswirkungen auf die gesamte Architekturlandschaft]
| style="width: 141px" | Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft (Ebenen der IVS-Pyramide)
| style="width: 231px" | [[Auswirkungen_auf_die_Architekturlandschaft|'''Auswirkungen von IVS-Architekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft''']]
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft der IVS-Dienstekategorie
| Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft des realen IVS-Dienstes
|- style="vertical-align:top"
| 7
| Durchführung eines formalen [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_07 Stakeholder-Reviews]
| style="width: 141px" | Durchführung eines formalen Stakeholder-Reviews für IVS-Geschäfstarchitektur
| style="width: 231px" | '''[[IVS-Leitbild_für_Deutschland#"Open_IVS"_als_Leitgedanke|Formales Stakeholder-Reviews für IVS-Geschäftsarchitektur]]'''
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Geschäftsarchitektur der IVS-Dienstekategorie
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Geschäftsarchitektur eines realen IVS-Dienstes
|- style="vertical-align:top"
| 8
| Finalisierung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_08 Geschäftsarchitektur]
| style="width: 141px" | Finalisierung der IVS-Geschäftsarchitektur
| style="width: 231px" | [[Finalisierung_der_IVS-Geschäftsarchitektur|'''Finalisierung der IVS-Geschäftsarchitektur''']]
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Finalisierung der IVS-Geschäftsarchitektur für die IVS-Dienstekategorie
| Finalisierung der IVS-Geschäftsarchitektur für den realen IVS-Dienst
|- style="vertical-align:top"
|
9

 

| Anlegen der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_09 Dokumentation für die Architekturdefinition]
| style="width: 141px" | Anlegen des IVS-Architekturdefinitionsdokuments
| style="width: 231px" | [[IVS-Architekturdefinitionsdokument|'''IVS-Architekturdefinitionsdokument''']]
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Anlegen des IVS-Architekturdefinitionsdokuments für die IVS-Dienstekategorie
| Anlegen des IVS-Architekturdefinitionsdokuments für den realen IVS-Dienst
|}

 

 

 

{| class="wikitable" width="1093"
|-
! style="text-align: left" | Step
! 1
! style="width: 141px" | 2
! style="width: 231px" | 3
! style="width: 219px" | 4
|- style="vertical-align:top"
| '''TOGAF'''
| Selection  [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_01 of means, views and tools for the presentation of the Business Architecture]
| style="width: 141px" | Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_02 initial situation  of the Business Architecture]
| style="width: 231px" | Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_03 Target Business Architecture]
; 
: 

| style="width: 219px" | Implementation of a [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_04 Gap-Analysis]
|- style="vertical-align:top"
| '''Tailoring for ITS-Architectures'''
| Selection of means, views and tools for the presentation of the ITS-Business Architecture
| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture
| style="width: 231px" | Description of the Target-ITS-Business Architecture
| style="width: 219px" | Implementation of a Gap-Analysis for the ITS-Business Architecture
|- style="vertical-align:top"
| '''Instruction'''
| [[Hilfsmittel,_Sichten_und_Werkzeuge_für_IVS-Geschäftsarchitektur|'''Means, views and tools for the presentation of the ITS-Business Architecture''']]
;Background information and techniques
;[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|Presentation of ITS Value-added chains and networks]]
;[[IVS-Governance|Presentation of ITS-Governance]]
;[[Geschäftsprozesse|Presentation of ITS-Business processes]]

| style="width: 141px" | '''[[IVS-Geschäftsarchitektur_Ausgangssituation|Initial situation of the ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business Process]]

| style="width: 231px" | '''[[Zielsituation_der_IVS-Geschäftsarchitektur|Target-ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business process]]

| style="width: 219px" | '''[[Gap-Analyse_Geschäftsarchitektur|Gap-Analysis for the ITS-Business Architecture]]'''
|- style="vertical-align:top"
| '''Artefacts {C=Catalog, M=Matrix, D=Diagram}, O=Other Deliverables'''
| Project-specific solutions
| style="width: 141px" | Project-specific solution (where available or required)
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| style="width: 231px" |
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:_IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-]][[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| style="width: 219px" | Project-specific solution
|- style="vertical-align:top"
| '''Recommendation for ITS-Reference Architectures'''
| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a ITS category service
*[[PhaseB-Step1-Los2|Traffic information of individual transport]]
*[[PhaseB-Step1-Los3|Cross-organisational traffic management]]
*[[Hilfsmittel_und_Werkzeuge_Los4|Multimodal travel information]]

| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture for the ITS-Category (where available)
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| style="width: 231px" | Description of the Target-ITS-Business Architecture for the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| style="width: 219px" | Implementation of a Gap-Analysis for the ITS-Business Architecture of the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

|- style="vertical-align:top"
| '''Recommendation for ITS-Architectures of real ITS-Services'''
| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a specific ITS-Service
| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture for the specific ITS-Service (where required)
| style="width: 231px" | Implementation of a Gap-Analysis for the ITS-Business Architecture of the specific ITS-Service
| style="width: 219px" | Implementation of a Gap-Analysis for the ITS-Business Architecture of the specific ITS-Service
|}

Diskussion:TOGAF-Phase B

2017-09-22T08:56:10Z

Romas:

== Schritte der Phase B - IVS-Geschäftsarchitektur ==

'''Wichtige Hinweise''': [[Hinweise_zu_den_Phasen_B,C_und_D|zu den Schritten der IVS-Architekturentwicklung in den Phasen B, C und D]]

{| class="wikitable" width="1092"
|-
! Step
! TOGAF
! style="width: 141px" | Tailoring for ITS-Architectures
! style="width: 231px" | Instruction
! style="width: 219px" | Artefacts {C=Catalog, M=Matrix, D=Diagram}, O=Other Deliverables
! Recommendation for ITS-Reference Architectures
! Recommendation for ITS-Architectures of real ITS-Services
|- style="vertical-align:top"
| 1
| Selection  [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_01 of means, views and tools for the presentation of the Business Architecture]
| style="width: 141px" | Selection of means, views and tools for the presentation of the ITS-Business Architecture
| style="width: 231px" | [[Hilfsmittel,_Sichten_und_Werkzeuge_für_IVS-Geschäftsarchitektur|'''Means, views and tools for the presentation of the ITS-Business Architecture''']]
;Background information and techniques
:[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|Presentation of ITS Value-added chains and networks]]
:[[IVS-Governance|Presentation of ITS-Governance]]
:[[Geschäftsprozesse|Presentation of ITS-Business processes]]

| style="width: 219px" | Project-specific solutions
| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a ITS category service
*[[PhaseB-Step1-Los2|Traffic information of individual transport]]
*[[PhaseB-Step1-Los3|Cross-organisational traffic management]]
*[[Hilfsmittel_und_Werkzeuge_Los4|Multimodal travel information]]

| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a specific ITS-Service
|- style="vertical-align:top"
| 2
| Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_02 initial situation  of the Business Architecture]
| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture
| style="width: 231px" | '''[[IVS-Geschäftsarchitektur_Ausgangssituation|Initial situation of the ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business Process]]

| style="width: 219px" | Project-specific solution (where available or required)
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| Description of the initial situation of the ITS-Business Architecture for the ITS-Category (where available)
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| Description of the initial situation of the ITS-Business Architecture for the specific ITS-Service (where required)
|- style="vertical-align:top"
| 3
| Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_03 Target Business Architecture]
| style="width: 141px" | Description of the Target-ITS-Business Architecture
| style="width: 231px" | '''[[Zielsituation_der_IVS-Geschäftsarchitektur|Target-ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business process]]

| style="width: 219px" |
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:_IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-]][[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| Description of the Target-ITS-Business Architecture for the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| Description of the Target-ITS-Business Architecture for the specific ITS-Service
|- style="vertical-align:top"
| 4
| Implementation of a [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_04 Gap-Analysis]
| style="width: 141px" | Implementation of a Gap-Analysis for the ITS-Business Architecture
| style="width: 231px" | '''[[Gap-Analyse_Geschäftsarchitektur|Gap-Analysis for the ITS-Business Architecture]]'''
| style="width: 219px" | Project-specific solution
| Implementation of a Gap-Analysis for the ITS-Business Architecture of the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| Implementation of a Gap-Analysis for the ITS-Business Architecture of the specific ITS-Service
|- style="vertical-align:top"
| 5
| Festlegung von Kandidaten für [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_05 die Architektur Roadmap]
| style="width: 141px" | Festlegung von IVS-Geschäftsarchitektur-Kandidaten für die IVS-Architektur-Roadmap
| style="width: 231px" | [[Roadmap_Geschäftsarchitektur|'''IVS-Geschäftsarchtekturkandiaten für die IVS-Architektur-Roadmap''']]
*[[Architektur-Roadmap|Template: Baustein IVS-Architektur-Roadmap]]

;Hintergrundinformationen und Techniken
:[[Roadmap_IVS-Architektur|Roadmap für IVS-Architektur]]

| style="width: 219px" |
*[[/images/5/55/Architektur-Roadmap_00-00-01.docx|O:IVS-Architektur-Roadmap]]

| Anlegen der IVS-Architektur-Roadmap für die IVS-Dienstekategorie
*[[PhaseB-Step5-Los2|Verkehrsinformation Individualverkehr]]
*[[PhaseB-Step5-Los3|Zuständigkeitsübergreifendes Verkehrsmanagement]]
*[[IVS-Architektur-Roadmap_Los4|Multimodale Reiseinformation]]

| Anlegen der IVS-Architektur-Roadmap für die IVS-Architektur des spezfischen IVS-Dienstes
|- style="vertical-align:top"
| 6
| Klärung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_06 Auswirkungen auf die gesamte Architekturlandschaft]
| style="width: 141px" | Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft (Ebenen der IVS-Pyramide)
| style="width: 231px" | [[Auswirkungen_auf_die_Architekturlandschaft|'''Auswirkungen von IVS-Architekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft''']]
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft der IVS-Dienstekategorie
| Klärung der Auswirkungen der IVS-Geschäftsarchitekturkandidaten der IVS-Architektur-Roadmap auf die gesamte IVS-Architekturlandschaft des realen IVS-Dienstes
|- style="vertical-align:top"
| 7
| Durchführung eines formalen [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_07 Stakeholder-Reviews]
| style="width: 141px" | Durchführung eines formalen Stakeholder-Reviews für IVS-Geschäfstarchitektur
| style="width: 231px" | '''[[IVS-Leitbild_für_Deutschland#"Open_IVS"_als_Leitgedanke|Formales Stakeholder-Reviews für IVS-Geschäftsarchitektur]]'''
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Geschäftsarchitektur der IVS-Dienstekategorie
| Durchführung eines formalen Stakeholder-Reviews für die IVS-Geschäftsarchitektur eines realen IVS-Dienstes
|- style="vertical-align:top"
| 8
| Finalisierung der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_08 Geschäftsarchitektur]
| style="width: 141px" | Finalisierung der IVS-Geschäftsarchitektur
| style="width: 231px" | [[Finalisierung_der_IVS-Geschäftsarchitektur|'''Finalisierung der IVS-Geschäftsarchitektur''']]
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Finalisierung der IVS-Geschäftsarchitektur für die IVS-Dienstekategorie
| Finalisierung der IVS-Geschäftsarchitektur für den realen IVS-Dienst
|- style="vertical-align:top"
|
9

 

| Anlegen der [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_09 Dokumentation für die Architekturdefinition]
| style="width: 141px" | Anlegen des IVS-Architekturdefinitionsdokuments
| style="width: 231px" | [[IVS-Architekturdefinitionsdokument|'''IVS-Architekturdefinitionsdokument''']]
| style="width: 219px" | Bestandteil der IVS-Architektur Version 1.0
| Anlegen des IVS-Architekturdefinitionsdokuments für die IVS-Dienstekategorie
| Anlegen des IVS-Architekturdefinitionsdokuments für den realen IVS-Dienst
|}

 

 

 

{| class="wikitable" width="1093"
|-
! style="text-align: left" | Step
! 1
! style="width: 141px" | 2
! style="width: 231px" | 3
! style="width: 219px" | 4
!  
!  
|- style="vertical-align:top"
| '''TOGAF'''
| Selection  [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_01 of means, views and tools for the presentation of the Business Architecture]
| style="width: 141px" | Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_02 initial situation  of the Business Architecture]
| style="width: 231px" | Description of the [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_03 Target Business Architecture]
; 
: 

| style="width: 219px" | Implementation of a [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap08.html#tag_08_04_04 Gap-Analysis]
|  
|  
|- style="vertical-align:top"
| '''Tailoring for ITS-Architectures'''
| Selection of means, views and tools for the presentation of the ITS-Business Architecture
| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture
| style="width: 231px" | Description of the Target-ITS-Business Architecture
| style="width: 219px" | Implementation of a Gap-Analysis for the ITS-Business Architecture
|  
|  
|- style="vertical-align:top"
| '''Instruction'''
| [[Hilfsmittel,_Sichten_und_Werkzeuge_für_IVS-Geschäftsarchitektur|'''Means, views and tools for the presentation of the ITS-Business Architecture''']]
;Background information and techniques
;[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|Presentation of ITS Value-added chains and networks]]
;[[IVS-Governance|Presentation of ITS-Governance]]
;[[Geschäftsprozesse|Presentation of ITS-Business processes]]

| style="width: 141px" | '''[[IVS-Geschäftsarchitektur_Ausgangssituation|Initial situation of the ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business Process]]

| style="width: 231px" | '''[[Zielsituation_der_IVS-Geschäftsarchitektur|Target-ITS-Business Architecture]]'''
*[[IVS-Geschäftsprozess|Template: Building block ITS-Business process]]

| style="width: 219px" | '''[[Gap-Analyse_Geschäftsarchitektur|Gap-Analysis for the ITS-Business Architecture]]'''
|  
|  
|- style="vertical-align:top"
| '''Artefacts {C=Catalog, M=Matrix, D=Diagram}, O=Other Deliverables'''
| Project-specific solutions
| style="width: 141px" | Project-specific solution (where available or required)
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| style="width: 231px" |
*[[Aufbau_von_IVS-Wertschöfungsketten_und_-netzwerke|D:ITS-Roles matrix]]
*[[IVS-Governance|O:ITS-Governance]]
*[[Media:_IVS-Geschäftsprozess-Katalog_00-00-03.docx|C:ITS-]][[Media:IVS-Geschäftsprozess-Katalog_00-00-03.docx|Business processes]]
*[[Geschäftsprozessdiagramm|D:ITS-Business process diagramm]]

| style="width: 219px" | Project-specific solution
|  
|  
|- style="vertical-align:top"
| '''Recommendation for ITS-Reference Architectures'''
| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a ITS category service
*[[PhaseB-Step1-Los2|Traffic information of individual transport]]
*[[PhaseB-Step1-Los3|Cross-organisational traffic management]]
*[[Hilfsmittel_und_Werkzeuge_Los4|Multimodal travel information]]

| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture for the ITS-Category (where available)
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| style="width: 231px" | Description of the Target-ITS-Business Architecture for the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

| style="width: 219px" | Implementation of a Gap-Analysis for the ITS-Business Architecture of the ITS-Service Category
*[[PhaseB-Step2-Los2|Traffic information of individual transport]]
*[[PhaseB-Step2-Los3|Cross-]][[PhaseB-Step1-Los3|organisational ]][[PhaseB-Step2-Los3|traffic management]]
*[[TOGAF_B#Ausgangssituation_der_IVS-Gesch.C3.A4ftsarchitektur|Multimodal travel information]]

|  
|  
|- style="vertical-align:top"
| '''Recommendation for ITS-Architectures of real ITS-Services'''
| Selection of means, views and tools for the presentation of the ITS-Business Architecture of a specific ITS-Service
| style="width: 141px" | Description of the initial situation of the ITS-Business Architecture for the specific ITS-Service (where required)
| style="width: 231px" | Implementation of a Gap-Analysis for the ITS-Business Architecture of the specific ITS-Service
| style="width: 219px" | Implementation of a Gap-Analysis for the ITS-Business Architecture of the specific ITS-Service
|  
|  
|}

Diskussion:TOGAF-Phase B

2017-09-12T14:10:10Z

Romas:

Diskussion:TOGAF-Phase B

2017-09-12T13:52:40Z

Romas:

Diskussion:TOGAF-Phase B

2017-09-12T13:49:48Z

Romas:

Diskussion:TOGAF-Phase B

2017-09-12T13:48:39Z

Romas:

Diskussion:TOGAF-Phase B

2017-09-12T13:47:38Z

Romas:

Diskussion:TOGAF-Phase B

2017-09-12T13:47:17Z

Romas:

Diskussion:TOGAF-Phase B

2017-09-12T13:42:24Z

Romas:

Leitfaden zur Entwicklung von Lösungsbereitstellungen

2017-08-16T11:53:27Z

Romas:

<div class="text-wrap">

==   Einleitung ==

*Formulieren Sie die Projektempfehlung      Gehen Sie für jedes einzelne Implementierungs- und Bereitstellungsprojekt wie folgt vor:         
**Dokumentenumfang des einzelnen Projektes in der Wirkungsanalyse         
**Dokument strategische Anforderungen (aus der architektonischen Perspektive) in der Wirkungsanalyse         
**Dokumentenänderungsanforderungen (wie zB Unterstützung für eine Standardschnittstelle) in der Wirkungsanalyse         
**Dokumentenregeln für Konformität in der Wirkungsanalyse         
**Dokument Zeitleiste Anforderungen aus Roadmap in der Auswirkungen Analyse     
*Dokumentarchitekturvertrag         
**Erhalten Sie Unterzeichnung von allen Entwicklungsorganisationen und Sponsoring-Organisation     
*Update Enterprise Continuum Verzeichnis und Repository für Lösungen     
*Leitfaden Entwicklung von Business & IT Betriebsmodellen für Dienstleistungen     
*Bereitstellung von Serviceanforderungen aus Unternehmensarchitekturen     
*Leitfaden Definition von Business & IT Betriebsanforderungen     
*Führen Sie eine Lückenanalyse zwischen der Solution Architecture und Operationen durch     
*Implementierungsplan erstellen

Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement

2017-08-16T11:16:49Z

Romas:

== Einleitung ==

*Überprüfen Sie die Migrationsplanungsausgaben und geben Sie Empfehlungen zum Einsatz     
*Identifizieren Sie Unternehmensarchitekturprioritäten für Entwicklungsteams     
*Identifizierung von Bereitstellungsproblemen und Empfehlungen     
*Bausteine für Ersatz, Update, etc. identifizieren     
*Führen Sie Lückenanalyse auf Enterprise Architecture und Solutions Framework     

Die Lücken in der bestehenden Enterprise Solutions Framework müssen identifiziert werden und die spezifischen Solution Building Blocks (SBBs) erforderlich, um diese Lücken zu füllen wird die von den Lösungen Architekten identifiziert werden. Diese SBBs können eine Eins-zu-eins- oder viel-zu-eins-Beziehung zu den Projekten haben. Die Lösungsarchitekten müssen genau definieren, wie dies geschehen wird. Es können andere Projekte sein, die an diesen Fähigkeiten arbeiten und die Lösungen Architekten müssen sicherstellen, dass sie den besten Nutzen aus diesen Investitionen nutzen können.     

*Erstellen Sie einen Lückenanalysebericht

Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan

2017-08-16T11:15:37Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"> == Einleitung == <div class="result-shield-container">Dieser Schritt besteht darin, den Implementierungs- und…“

<div class="text-wrap">
== Einleitung ==
<div class="result-shield-container">Dieser Schritt besteht darin, den Implementierungs- und Migrationsplan mit den Management-Frameworks innerhalb der Organisation zu koordinieren. Es gibt typischerweise vier Management-Frameworks, die für den Implementierungs- und Migrationsplan eng zusammenarbeiten müssen, um erfolgreich zu sein:     </div>
*Business Planning, die konzipiert, leitet und liefert die Ressourcen für alle Aktivitäten, die erforderlich sind, um konkrete Unternehmensziele / Ergebnisse zu erreichen.     
*Enterprise Architecture, die Strukturen und Kontext für alle Unternehmenstätigkeiten vermittelt und konkrete Geschäftsergebnisse vor allem aber nicht ausschließlich im IT-Bereich liefert.     
*Portfolio / Projektmanagement, das die Geschäftssysteme koordiniert, entwirft und baut, die die konkreten Geschäftsergebnisse liefern.     
*Operations Management, das die Ergebnisse, die die konkreten Geschäftsergebnisse liefern, integriert, betreibt und unterhält.
<div class="result-shield-container">Der Implementierungs- und Migrationsplan wird sich auf die Ergebnisse jedes dieser Rahmenbedingungen auswirken und muss daher in ihnen reflektiert werden. Im Laufe dieses Schrittes, verstehen Sie die Rahmenbedingungen innerhalb der Organisation und stellen Sie sicher, dass diese Pläne koordiniert und eingefügt (in einem zusammenfassenden Format) innerhalb der Pläne eines jeden dieser Frameworks.</div> <div class="result-shield-container">Das Ergebnis dieses Schrittes kann sein, dass der Implementierungs- und Migrationsplan Teil eines anderen Plans sein könnte, der von einem anderen Rahmen mit der Teilnahme der Unternehmensarchitektur erstellt wurde.</div> </div>

TOGAF-Phase F

2017-08-16T11:09:02Z

Romas:

== Phase F – Migrationsplanung ==

;TOGAF

:In Phase F geht es nach TOGAF im Prinzip darum, die ausgewählte Lösung aus Phase E zu planen. Geht es um eine IT-Lösung, dann muss diese von einem Softwareunternehmen beschafft und implementiert werden. D.h. man muss einen Vertrag mit dem Softwareanbieter schließen und ein Projekt aufsetzen zur Implementierung der Software. Handelt es sich nicht um Software, sondern z.B. um Personal, muss man sich in dieser Phase u.a. überlegen, wann wieviele neue Stellen geschaffen werden oder welche Qualitfikationen die neuen Mitarbeiter haben sollen. Evtl. muss auch hier ein Vertrag mit einem externen "Lieferanten" (HR-Spezialist) abgeschlossen werden. 
:Bestandteil des Vertrtags sollte u.a. sein, dass die neue Lösung konform zu den Architekturprinzipien ist. 

;IVS-Rahmenarchitektur
:Die Phase F beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_01 der Interaktion des Framework Managements für die Implementierung und die Migrationsplanung]
| Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan
| [[Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan|Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan]]
|  
|-
| 2
| Bestimmung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_02 eines wirtschaftlichen Werts für jedes Arbeitspaket]
| Zuweisung eines Geschäftswerts zu jedem Arbeitspaket
| [[Zuweisung_eines_Geschäftswerts_zu_jedem_Arbeitspaket|Zuweisung eines Geschäftswerts zu jedem Arbeitspaket]]
|  
|-
| 3
| Einschätzung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_03 der Anforderungen an die Ressourcen, die Zeitplanung des Projekts und die Verfügbarkeit/Lieferfahrzeug]
| Schätzung der Ressourcenanforderungen, Projektzeiten und Verfügbarkeit / Lieferwagen
| [[Schätzung_der_Ressourcenanforderungen,_Projektzeiten_und_Verfügbarkeit_/_Lieferwagen|Schätzung der Ressourcenanforderungen, Projektzeiten und Verfügbarkeit / Lieferwagen]]
|  
|-
| 4
| Priorisierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_04 der Migrationsprojekte mittels Durchführung einer Kosten-Nutzen-Analyse und Risiko Validierung]
| Priorisierung der Migrationsprojekte durch die Durchführung einer Kosten- / Nutzenbeurteilung und Risikobewertung
| [[Priorisierung_der_Migrationsprojekte_durch_die_Durchführung_einer_Kosten-_/_Nutzenbeurteilung_und_Risikobewertung|Priorisierung der Migrationsprojekte durch die Durchführung einer Kosten- / Nutzenbeurteilung und Risikobewertung]]
|  
|-
| 5
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_05 der Roadmap und Aktualisierung des Definitions Dokument der Architektur]
| Bestätigung von Architektur-Roadmap und Aktualisierung des Architekturdefinitionsdokumentes
| [[Bestätigung_von_Architektur-Roadmap_und_Aktualisierung_des_Architekturdefinitionsdokumentes|Bestätigung von Architektur-Roadmap und Aktualisierung des Architekturdefinitionsdokumentes]]
|-
| 6
| Entwicklung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_06 der Implementierung und der Migrationsplanung]
| Erzeugung von einem Implementierungs- und Migrationsplan
| [[Erzeugung_von_einem_Implementierungs-_und_Migrationsplan|Erzeugung von einem Implementierungs- und Migrationsplan]]
|  
|-
| 7
| Vervollständigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_07 des Entwicklungszyklus und des Dokuments über gewonnene Erkenntnisse der Architektur]
| Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden
| [[Vervollständigung_des_Architekturentwicklungszyklus_und_der_Unterrichtsstunden|Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden]]
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Zuweisung eines Geschäftswerts zu jedem Arbeitspaket

2017-08-16T11:05:51Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"><div class="result-shield-container">Festlegen und Zuordnen von Geschäftswerten für alle Arbeitspakete. Die…“

<div class="text-wrap"><div class="result-shield-container">Festlegen und Zuordnen von Geschäftswerten für alle Arbeitspakete. Die Absicht besteht darin, zunächst festzustellen, was den Unternehmenswert innerhalb der Organisation ausmacht, wie der Wert gemessen werden kann, und dann auf jeden der Projekte und Projektschritte anwenden.</div> <div class="result-shield-container">Wenn eine leistungsfähige Planung verwendet wurde, sollten die mit den Fähigkeiten und den zugehörigen Leistungsschritten verbundenen Geschäftswerte verwendet werden, um die Geschäftswerte für die Ergebnisse zuzuordnen.</div> <div class="result-shield-container">In dieser Tätigkeit gibt es mehrere Fragen:    </div>
*Performance-Evaluation Kriterien werden von Portfolio- und Capability-Managern genutzt, um den Fortschritt der Architektur-Transformation zu genehmigen und zu überwachen.     
*Return-on-Investment-Kriterien müssen detailliert und von den verschiedenen Stakeholdern unterzeichnet werden.     
*Business Value muss definiert werden sowie Techniken wie die Wertschöpfungskette, die verwendet werden sollen, um die Rolle bei der Erreichung konkreter Geschäftsergebnisse zu veranschaulichen. Der Geschäftswert wird von Portfolio- und Kapazitätsmanagern genutzt, um Ressourcen zuzuordnen, und in Fällen, in denen es Kürzungen gibt, kann der Unternehmenswert im Zusammenhang mit der Kapitalrendite verwendet werden, um festzustellen, ob ein Bestimmungsprozess erfolgt, verzögert oder storniert wird.    
*Es sollten kritische Erfolgsfaktoren (CSFs) eingerichtet werden, um Erfolg für ein Projekt- und / oder Projektinkrement zu definieren. Diese werden den Managern und Mitarbeitern ein Maßstab geben, was eine erfolgreiche Umsetzung darstellt.     
*Maßnahmen der Wirksamkeit (MOE) sind oft Leistungskriterien und viele Unternehmen schließen sie in die GFK ein. Wo sie diskret behandelt werden, sollte klar sein, wie diese Kriterien gruppiert werden sollen.   
*Strategic Fit auf der Grundlage der Gesamtarchitektur (alle Ebenen) wird der entscheidende Faktor für die Genehmigung eines neuen Projekts oder einer Initiative und zur Bestimmung des Wertes eines lieferbaren sein.

Verwenden Sie die Arbeitspakete als Grundlage für die Identifizierung von Projekten, die im Implementierungs- und Migrationsplan liegen werden. Die identifizierten Projekte werden in anderen Schritten in Phase F vollständig entwickelt. Die Projekte und Projektschritte können eine Anpassung des Architektur-Roadmaps und des Architekturdefinitionsdokuments erfordern.
<div class="result-shield-container">Die Risiken sollten dann den Projekten und den Projektschritten zugeordnet werden, indem sie die in der Konsolidierten Lücken, Lösungen und Dependenzen Matrix (aus Phase E) identifizierten Risiken zusammenfassen. Schätzen Sie den Geschäftswert für jedes Projekt anhand der Business Value Assessment Technique (siehe Teil III, 28.5 Business Value Assessment Technique).</div> </div> <div class="result-footer"><div class="share-mail"> </div> </div>

TOGAF-Phase F

2017-08-16T11:02:11Z

Romas:

== Phase F – Migrationsplanung ==

;TOGAF

:In Phase F geht es nach TOGAF im Prinzip darum, die ausgewählte Lösung aus Phase E zu planen. Geht es um eine IT-Lösung, dann muss diese von einem Softwareunternehmen beschafft und implementiert werden. D.h. man muss einen Vertrag mit dem Softwareanbieter schließen und ein Projekt aufsetzen zur Implementierung der Software. Handelt es sich nicht um Software, sondern z.B. um Personal, muss man sich in dieser Phase u.a. überlegen, wann wieviele neue Stellen geschaffen werden oder welche Qualitfikationen die neuen Mitarbeiter haben sollen. Evtl. muss auch hier ein Vertrag mit einem externen "Lieferanten" (HR-Spezialist) abgeschlossen werden. 
:Bestandteil des Vertrtags sollte u.a. sein, dass die neue Lösung konform zu den Architekturprinzipien ist. 

;IVS-Rahmenarchitektur
:Die Phase F beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_01 der Interaktion des Framework Managements für die Implementierung und die Migrationsplanung]
| Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan
| [[Management-Interaktion_für_den_Implementierungs-_und_Migrationsplan|Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan]]
|  
|-
| 2
| Bestimmung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_02 eines wirtschaftlichen Werts für jedes Arbeitspaket]
| Zuweisung eines Geschäftswerts zu jedem Arbeitspaket
| [[Zuweisung_eines_Geschäftswerts_zu_jedem_Arbeitspaket|Zuweisung eines Geschäftswerts zu jedem Arbeitspaket]]
|  
|-
| 3
| Einschätzung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_03 der Anforderungen an die Ressourcen, die Zeitplanung des Projekts und die Verfügbarkeit/Lieferfahrzeug]
| Schätzung der Ressourcenanforderungen, Projektzeiten und Verfügbarkeit / Lieferwagen
| [[Schätzung_der_Ressourcenanforderungen,_Projektzeiten_und_Verfügbarkeit_/_Lieferwagen|Schätzung der Ressourcenanforderungen, Projektzeiten und Verfügbarkeit / Lieferwagen]]
|  
|-
| 4
| Priorisierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_04 der Migrationsprojekte mittels Durchführung einer Kosten-Nutzen-Analyse und Risiko Validierung]
| Priorisierung der Migrationsprojekte durch die Durchführung einer Kosten- / Nutzenbeurteilung und Risikobewertung
| [[Priorisierung_der_Migrationsprojekte_durch_die_Durchführung_einer_Kosten-_/_Nutzenbeurteilung_und_Risikobewertung|Priorisierung der Migrationsprojekte durch die Durchführung einer Kosten- / Nutzenbeurteilung und Risikobewertung]]
|  
|-
| 5
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_05 der Roadmap und Aktualisierung des Definitions Dokument der Architektur]
| Bestätigung von Architektur-Roadmap und Aktualisierung des Architekturdefinitionsdokumentes
| [[Bestätigung_von_Architektur-Roadmap_und_Aktualisierung_des_Architekturdefinitionsdokumentes|Bestätigung von Architektur-Roadmap und Aktualisierung des Architekturdefinitionsdokumentes]]
|-
| 6
| Entwicklung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_06 der Implementierung und der Migrationsplanung]
| Erzeugung von einem Implementierungs- und Migrationsplan
| [[Erzeugung_von_einem_Implementierungs-_und_Migrationsplan|Erzeugung von einem Implementierungs- und Migrationsplan]]
|  
|-
| 7
| Vervollständigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_07 des Entwicklungszyklus und des Dokuments über gewonnene Erkenntnisse der Architektur]
| Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden
| [[Vervollständigung_des_Architekturentwicklungszyklus_und_der_Unterrichtsstunden|Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden]]
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Management-Interaktion für den Implementierungs- und Migrationsplan

2017-08-16T10:56:17Z

Romas:

== Einleitung ==

Dieser Schritt besteht darin, den Implementierungs- und Migrationsplan mit den Management-Frameworks innerhalb der Organisation zu koordinieren. Es gibt typischerweise vier Management-Frameworks, die für den Implementierungs- und Migrationsplan eng zusammenarbeiten müssen, um erfolgreich zu sein:     

*Business Planning, die konzipiert, leitet und liefert die Ressourcen für alle Aktivitäten, die erforderlich sind, um konkrete Unternehmensziele / Ergebnisse zu erreichen.     
*Enterprise Architecture, die Strukturen und Kontext für alle Unternehmenstätigkeiten vermittelt und konkrete Geschäftsergebnisse vor allem aber nicht ausschließlich im IT-Bereich liefert.     
*Portfolio / Projektmanagement, das die Geschäftssysteme koordiniert, entwirft und baut, die die konkreten Geschäftsergebnisse liefern.     
*Operations Management, das die Ergebnisse, die die konkreten Geschäftsergebnisse liefern, integriert, betreibt und unterhält.

Der Implementierungs- und Migrationsplan wird sich auf die Ergebnisse jedes dieser Rahmenbedingungen auswirken und muss daher in ihnen reflektiert werden. Im Laufe dieses Schrittes, verstehen Sie die Rahmenbedingungen innerhalb der Organisation und stellen Sie sicher, dass diese Pläne koordiniert und eingefügt (in einem zusammenfassenden Format) innerhalb der Pläne eines jeden dieser Frameworks.

Das Ergebnis dieses Schrittes kann sein, dass der Implementierungs- und Migrationsplan Teil eines anderen Plans sein könnte, der von einem anderen Rahmen mit der Teilnahme der Unternehmensarchitektur erstellt wurde.

Aktivieren des Prozesses zum Implementieren von Änderungen

2017-08-16T10:49:42Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == Aktiviere den Architekturprozess, um den Wandel zu implementieren:      *<span class="…“

== Einleitung ==

Aktiviere den Architekturprozess, um den Wandel zu implementieren:     

*Produzieren Sie eine neue Anfrage für Architektur Arbeit und Investitionsanforderung     
*Sicherstellen, dass alle Änderungen, die in dieser Phase implementiert wurden, im Architektur-Repository erfasst und dokumentiert werden

TOGAF-Phase H

2017-08-16T10:48:54Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung_eines_Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
| Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]
| Bereitstellen von Überwachungswerkzeugen
| [[Bereitstellen_von_Überwachungswerkzeugen|Bereitstellen von Überwachungswerkzeugen]]
|  
|-
| 3
| [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]
| Risiken verwalten
| [[Risiken_verwalten|Risiken verwalten]]
|  
|-
| 4
| Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]
| Bereitstellung von Analysen für Architektur Change Management
| [[Bereitstellung_von_Analysen_für_Architektur_Change_Management|Bereitstellung von Analysen für Architektur Change Management]]
|  
|-
| 5
| Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]
| Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen
| [[Entwicklung_von_Änderungsvoraussetzungen,_um_Leistungsziele_zu_erfüllen|Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen]]
|  
|-
| 6
| Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]
| Verwaltung von Governance-Prozessen
| [[Verwaltung_von_Governance-Prozessen|Verwaltung von Governance-Prozessen]]
|  
|-
| 7
| Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]
| Aktivieren des Prozesses zum Implementieren von Änderungen
| [[Aktivieren des Prozesses zum Implementieren von Änderungen|Aktivieren des Prozesses zum Implementieren von Änderungen]]
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Verwaltung von Governance-Prozessen

2017-08-16T10:47:02Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"> == Einleitung == <div class="result-shield-container">Verwalten von Governance-Prozess und Framework für Arc…“

<div class="text-wrap">
== Einleitung ==
<div class="result-shield-container">Verwalten von Governance-Prozess und Framework für Architektur:     </div>
*Treffen des Architekturausschusses (oder eines anderen EZB-Rates)     
*Halten Sie das Treffen des Architekturausschusses mit dem Ziel des Treffens, sich über den Umgang mit Veränderungen zu entscheiden (Technik und Wirtschaft und Dispensationen)
</div>

TOGAF-Phase H

2017-08-16T10:46:29Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung_eines_Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
| Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]
| Bereitstellen von Überwachungswerkzeugen
| [[Bereitstellen_von_Überwachungswerkzeugen|Bereitstellen von Überwachungswerkzeugen]]
|  
|-
| 3
| [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]
| Risiken verwalten
| [[Risiken_verwalten|Risiken verwalten]]
|  
|-
| 4
| Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]
| Bereitstellung von Analysen für Architektur Change Management
| [[Bereitstellung_von_Analysen_für_Architektur_Change_Management|Bereitstellung von Analysen für Architektur Change Management]]
|  
|-
| 5
| Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]
| Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen
| [[Entwicklung_von_Änderungsvoraussetzungen,_um_Leistungsziele_zu_erfüllen|Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen]]
|  
|-
| 6
| Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]
| Verwaltung von Governance-Prozessen
| [[Verwaltung von Governance-Prozessen|Verwaltung von Governance-Prozessen]]
|  
|-
| 7
|
Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen

2017-08-16T10:38:49Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"> == Einleitung == <div class="result-shield-container">Empfehlungen zu Änderungsvorgaben zur Erfüllung von L…“

<div class="text-wrap">
== Einleitung ==
<div class="result-shield-container">Empfehlungen zu Änderungsvorgaben zur Erfüllung von Leistungszielen und zur Entwicklung von Handlungspositionen.</div> </div>

TOGAF-Phase H

2017-08-16T10:38:27Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung_eines_Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
| Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]
| Bereitstellen von Überwachungswerkzeugen
| [[Bereitstellen_von_Überwachungswerkzeugen|Bereitstellen von Überwachungswerkzeugen]]
|  
|-
| 3
| [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]
| Risiken verwalten
| [[Risiken_verwalten|Risiken verwalten]]
|  
|-
| 4
| Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]
| Bereitstellung von Analysen für Architektur Change Management
| [[Bereitstellung_von_Analysen_für_Architektur_Change_Management|Bereitstellung von Analysen für Architektur Change Management]]
|  
|-
| 5
| Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]
| Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen
| [[Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen|Entwicklung von Änderungsvoraussetzungen, um Leistungsziele zu erfüllen]]
|  
|-
| 6
|
Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]

|  
|  
|  
|-
| 7
|
Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Bereitstellung von Analysen für Architektur Change Management

2017-08-16T10:36:49Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"> == Einleitung == <div class="result-shield-container">Bereitstellung von Analysen für das Architekturänderu…“

<div class="text-wrap">
== Einleitung ==
<div class="result-shield-container">Bereitstellung von Analysen für das Architekturänderungsmanagement:    </div>
*Leistung analysieren     
*Durchführung von Enterprise-Architektur-Performance-Reviews mit Service-Management     
*Beurteilen Sie Änderungsanforderungen und Berichte, um sicherzustellen, dass die Erwartungen der erwarteten Wertrealisierung und der Service Level Agreement (SLA) der Kunden erfüllt sind     
*Nehmen Sie eine Lückenanalyse der Leistung der Unternehmensarchitektur ein     
*Sicherstellen, dass Änderungsverwaltungsanforderungen an die Unternehmensarchitektur Governance und Framework eingehalten werden
</div>

TOGAF-Phase H

2017-08-16T10:35:36Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung_eines_Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
| Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]
| Bereitstellen von Überwachungswerkzeugen
| [[Bereitstellen_von_Überwachungswerkzeugen|Bereitstellen von Überwachungswerkzeugen]]
|  
|-
| 3
| [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]
| Risiken verwalten
| [[Risiken_verwalten|Risiken verwalten]]
|  
|-
| 4
| Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]
| Bereitstellung von Analysen für Architektur Change Management
| [[Bereitstellung von Analysen für Architektur Change Management|Bereitstellung von Analysen für Architektur Change Management]]
|  
|-
| 5
|
Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]

|  
|  
|  
|-
| 6
|
Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]

|  
|  
|  
|-
| 7
|
Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

TOGAF-Phase H

2017-08-16T10:33:07Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung_eines_Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
| Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]
| Bereitstellen von Überwachungswerkzeugen
| [[Bereitstellen_von_Überwachungswerkzeugen|Bereitstellen von Überwachungswerkzeugen]]
|  
|-
| 3
| [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]
| Risiken verwalten
| [[Risiken_verwalten|Risiken verwalten]]
|  
|-
| 4
|
Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]

|  
|  
|  
|-
| 5
|
Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]

|  
|  
|  
|-
| 6
|
Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]

|  
|  
|  
|-
| 7
|
Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Risiken verwalten

2017-08-16T10:27:58Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == Verwalten von Unternehmensarchitekturrisiken und Empfehlungen für die IT-Strategie.“

== Einleitung ==

Verwalten von Unternehmensarchitekturrisiken und Empfehlungen für die IT-Strategie.

TOGAF-Phase H

2017-08-16T10:27:35Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung_eines_Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
| Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]
| Bereitstellen von Überwachungswerkzeugen
| [[Bereitstellen_von_Überwachungswerkzeugen|Bereitstellen von Überwachungswerkzeugen]]
|  
|-
| 3
| http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]
| Risiken verwalten
| [[Risiken verwalten|Risiken verwalten]]
|  
|-
| 4
|
Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]

|  
|  
|  
|-
| 5
|
Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]

|  
|  
|  
|-
| 6
|
Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]

|  
|  
|  
|-
| 7
|
Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Bereitstellen von Überwachungswerkzeugen

2017-08-16T10:25:37Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == Sicherstellen, dass Überwachungsinstrumente eingesetzt und angewendet werden, um Folgendes zu ermöglichen: &nbsp…“

== Einleitung ==

Sicherstellen, dass Überwachungsinstrumente eingesetzt und angewendet werden, um Folgendes zu ermöglichen:     

*Überwachen Sie Technologieänderungen, die die Baseline-Architektur beeinflussen könnten     
*Überwachen Sie Geschäftsänderungen, die die Baseline-Architektur beeinflussen könnten     
*Geschäftswertverfolgung; Z. B. Investitionsbewertungsmethode, um Wertmetriken für die Geschäftsziele zu bestimmen     
*Monitoring Enterprise Architektur Fähigkeitsreife     
*Verfolgen und bewerten Asset Management Programme     
*Verfolgen Sie die QoS-Aufführungen und die Nutzung     
*Ermittlung und Verfolgung von Geschäftskontinuitätsanforderungen

TOGAF-Phase H

2017-08-16T10:24:37Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung_eines_Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
| Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]
| Bereitstellen von Überwachungswerkzeugen
| [[Bereitstellen von Überwachungswerkzeugen|Bereitstellen von Überwachungswerkzeugen]]
|  
|-
| 3
|
[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]

|  
|  
|  
|-
| 4
|
Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]

|  
|  
|  
|-
| 5
|
Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]

|  
|  
|  
|-
| 6
|
Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]

|  
|  
|  
|-
| 7
|
Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Feststellung eines Wertrealisierungsprozess

2017-08-16T10:23:13Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == Einfluss der Geschäftsprojekte zur Nutzung der Unternehmensarchitektur für die Wertrealisierung (Ergebnisse).</s…“

== Einleitung ==

Einfluss der Geschäftsprojekte zur Nutzung der Unternehmensarchitektur für die Wertrealisierung (Ergebnisse).

TOGAF-Phase H

2017-08-16T10:22:46Z

Romas:

== Phase H – Archtektur Änderungsmanagement ==

;TOGAF

:In der Phase H geht es nach TOGAF darum, ein langfristiges Architekurmanagement aufzusetzen und zu verstetigen, das dafür sorgt, dass die Architektur auch in Zukunft noch zu den Unternehmenszielen passt. 
:Es wird zunächst geprüft, ob die Maßnahme (Implementierung einer neuen IT-Lösung oder Einstellung von Personal oder ähnliches) erfolgreich war, indem z.B. gemessen wird, wie viel schneller der Prozesse nun danach abläuft. 
:Dann wird ein langfristiger Change-Management-Prozess etabliert, der in gewissen Abständen wieder nach Gaps in der Architektur sucht und prüft, ob die Architektur, die Architekturvision und die Vorgaben der Architektur (z.B. Architekturprinzipien) noch akuell sind. 
:In einem Architektur-Board (runder Tisch zum Thema Architektur mit Vertretern aus den Betroffenen Bereichen bzw. Unternehmen) werden Change Requests abgearbeitet und es wird geprüft, welche Change Requests umgesetzt werden sollen und welche nicht. 
:Gründe für notwendige Änderungen an der Architektur können z.B. sein, dass sich die Ziele bzw. Anforderungen des Unternehmens geändert haben, dass die Lösung nicht skaliert, dass neue Technologien verfügbar sind oder dass Lösungen veralten und nicht mehr unterstützt werden. 

;IVS-Rahmenarchitektur
:Die Phase H beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Etablierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 eines Wertrealisierungsprozess][http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_01 es]
| Feststellung eines Wertrealisierungsprozess
| [[Feststellung eines Wertrealisierungsprozess|Feststellung eines Wertrealisierungsprozess]]
|  
|-
| 2
|
Einsatz von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_02 Kontrollwerkzeugen]

|  
|  
|  
|-
| 3
|
[http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_03 Risikomanagement]

|  
|  
|  
|-
| 4
|
Bereitstellung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_04 Analysen für die Architektur des Change Managements]

|  
|  
|  
|-
| 5
|
Entwicklung von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_05 Anforderungsänderungen, um sich dem Erfolgsziel anzunähern]

|  
|  
|  
|-
| 6
|
Management von [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_06 Steuerungsprozessen]

|  
|  
|  
|-
| 7
|
Aktivierung des [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap16.html#tag_16_04_07 Prozesses, um Veränderungen zu implementieren]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Eine Post-Implementierung durchführen und die Implementierung abschließen

2017-08-16T10:18:55Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == *Durchführung von Nachprüfungen      *Veröffentlichen Sie…“

== Einleitung ==

*Durchführung von Nachprüfungen     
*Veröffentlichen Sie Kommentare und schließen Sie Projekte

Verschluss auf Phase G wird sein, wenn die Lösungen einmal vollständig eingesetzt werden.

TOGAF-Phase G

2017-08-16T10:17:53Z

Romas:

== Phase G – Steuerung der Einführung ==

;TOGAF

:In Phase G geht es darum, dass das EAM-Team die Umsetzung des Plans aus Phase F überwacht. Also wenn z.B. von einem externen Softwarelieferanten oder Beratungshaus eine neue Software-Lösung implementiert werden soll, dann muss das EAM-Team mit darauf achten, dass die zeitliche Planung eingehalten wird, aber auch dass die Software nachher das tut, was sie tun soll (also ob alle Funktionen darin sind, die benötigt werden). Insbesondere muss auch sichergestellt werden, dass die neue Lösung konform zu den aufgestellten Architekturprinzipien ist. 
:Am Ende der Phase G findet eine Abnahme der neuen Lösung statt. 

;IVS-Rahmenarchitektur
:Die Phase G beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_01 des Umfangs und der Prioritäten für die Bereitstellung von Entwicklungsmanagement]
| Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement
| [[Bestätigung_des_Bereiches_und_der_Prioritäten_für_die_Bereitstellung_mit_dem_Entwicklungsmanagement|Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement]]
|  
|-
| 2
| Identifikation [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_02 von Bereitstellungsressourcen und Fähigkeiten]
| Identifikation von Deployment Resources und Skills
| [[Identifikation_von_Deployment_Resources_und_Skills|Identifikation von Deployment Resources und Skills]]
|  
|-
| 3
| Anleitung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_03 der Entwicklungen von Lösungsbereitstellungen]
| Leitfaden zur Entwicklung von Lösungsbereitstellungen
| [[Leitfaden_zur_Entwicklung_von_Lösungsbereitstellungen|Leitfaden zur Entwicklung von Lösungsbereitstellungen]]
|  
|-
| 4
| Prüfung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_04 der Einhaltung von Unternehmensarchitektur ]
| Durchführung von Enterprise Architecture Compliance Reviews
| [[Durchführung_von_Enterprise_Architecture_Compliance_Reviews|Durchführung von Enterprise Architecture Compliance Reviews]]
|  
|-
| 5
| Implementierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_05 von Wirtschafts- und IT Vorgängen]
| Implementieren von Business- und IT-Operationen
| [[Implementieren_von_Business-_und_IT-Operationen|Implementieren von Business- und IT-Operationen]]
|  
|-
| 6
| Ausführung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_06 der Überprüfung der Durchführungsphase und Abschluss der Implementierung]
| Eine Post-Implementierung durchführen und die Implementierung abschließen
| [[Eine Post-Implementierung durchführen und die Implementierung abschließen|Eine Post-Implementierung durchführen und die Implementierung abschließen]]
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Implementieren von Business- und IT-Operationen

2017-08-16T10:11:28Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == *Führen Sie die Bereitstellungsprojekte durch: Business-Service-Implementierung; Fähigkeiten Entwicklung und Aus…“

== Einleitung ==

*Führen Sie die Bereitstellungsprojekte durch: Business-Service-Implementierung; Fähigkeiten Entwicklung und Ausbildung Umsetzung; Kommunikationsdokumentation     
*Veröffentlichen Sie neue Baseline-Architekturen in das Architektur-Repository und aktualisieren Sie andere betroffenen Repositories, wie z. B. operative Konfigurationsverwaltungsspeicher

TOGAF-Phase G

2017-08-16T10:10:19Z

Romas:

== Phase G – Steuerung der Einführung ==

;TOGAF

:In Phase G geht es darum, dass das EAM-Team die Umsetzung des Plans aus Phase F überwacht. Also wenn z.B. von einem externen Softwarelieferanten oder Beratungshaus eine neue Software-Lösung implementiert werden soll, dann muss das EAM-Team mit darauf achten, dass die zeitliche Planung eingehalten wird, aber auch dass die Software nachher das tut, was sie tun soll (also ob alle Funktionen darin sind, die benötigt werden). Insbesondere muss auch sichergestellt werden, dass die neue Lösung konform zu den aufgestellten Architekturprinzipien ist. 
:Am Ende der Phase G findet eine Abnahme der neuen Lösung statt. 

;IVS-Rahmenarchitektur
:Die Phase G beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_01 des Umfangs und der Prioritäten für die Bereitstellung von Entwicklungsmanagement]
| Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement
| [[Bestätigung_des_Bereiches_und_der_Prioritäten_für_die_Bereitstellung_mit_dem_Entwicklungsmanagement|Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement]]
|  
|-
| 2
| Identifikation [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_02 von Bereitstellungsressourcen und Fähigkeiten]
| Identifikation von Deployment Resources und Skills
| [[Identifikation_von_Deployment_Resources_und_Skills|Identifikation von Deployment Resources und Skills]]
|  
|-
| 3
| Anleitung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_03 der Entwicklungen von Lösungsbereitstellungen]
| Leitfaden zur Entwicklung von Lösungsbereitstellungen
| [[Leitfaden_zur_Entwicklung_von_Lösungsbereitstellungen|Leitfaden zur Entwicklung von Lösungsbereitstellungen]]
|  
|-
| 4
| Prüfung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_04 der Einhaltung von Unternehmensarchitektur ]
| Durchführung von Enterprise Architecture Compliance Reviews
| [[Durchführung_von_Enterprise_Architecture_Compliance_Reviews|Durchführung von Enterprise Architecture Compliance Reviews]]
|  
|-
| 5
| Implementierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_05 von Wirtschafts- und IT Vorgängen]
| Implementieren von Business- und IT-Operationen
| [[Implementieren von Business- und IT-Operationen|Implementieren von Business- und IT-Operationen]]
|  
|-
| 6
|
Ausführung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_06 der Überprüfung der Durchführungsphase und Abschluss der Implementierung]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Durchführung von Enterprise Architecture Compliance Reviews

2017-08-16T10:07:58Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == *Überprüfen Sie die laufende Implementierung Governance und Architektur Compliance für jeden Baustein  &nb…“

== Einleitung ==

*Überprüfen Sie die laufende Implementierung Governance und Architektur Compliance für jeden Baustein     
*Nachprüfungen durchführen     
*Enge Entwicklung Teil der Bereitstellung Projekte

TOGAF-Phase G

2017-08-16T10:07:23Z

Romas:

== Phase G – Steuerung der Einführung ==

;TOGAF

:In Phase G geht es darum, dass das EAM-Team die Umsetzung des Plans aus Phase F überwacht. Also wenn z.B. von einem externen Softwarelieferanten oder Beratungshaus eine neue Software-Lösung implementiert werden soll, dann muss das EAM-Team mit darauf achten, dass die zeitliche Planung eingehalten wird, aber auch dass die Software nachher das tut, was sie tun soll (also ob alle Funktionen darin sind, die benötigt werden). Insbesondere muss auch sichergestellt werden, dass die neue Lösung konform zu den aufgestellten Architekturprinzipien ist. 
:Am Ende der Phase G findet eine Abnahme der neuen Lösung statt. 

;IVS-Rahmenarchitektur
:Die Phase G beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_01 des Umfangs und der Prioritäten für die Bereitstellung von Entwicklungsmanagement]
| Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement
| [[Bestätigung_des_Bereiches_und_der_Prioritäten_für_die_Bereitstellung_mit_dem_Entwicklungsmanagement|Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement]]
|  
|-
| 2
| Identifikation [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_02 von Bereitstellungsressourcen und Fähigkeiten]
| Identifikation von Deployment Resources und Skills
| [[Identifikation_von_Deployment_Resources_und_Skills|Identifikation von Deployment Resources und Skills]]
|  
|-
| 3
| Anleitung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_03 der Entwicklungen von Lösungsbereitstellungen]
| Leitfaden zur Entwicklung von Lösungsbereitstellungen
| [[Leitfaden_zur_Entwicklung_von_Lösungsbereitstellungen|Leitfaden zur Entwicklung von Lösungsbereitstellungen]]
|  
|-
| 4
| Prüfung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_04 der Einhaltung von Unternehmensarchitektur ]
| Durchführung von Enterprise Architecture Compliance Reviews
| [[Durchführung von Enterprise Architecture Compliance Reviews|Durchführung von Enterprise Architecture Compliance Reviews]]
|  
|-
| 5
|
Implementierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_05 von Wirtschafts- und IT Vorgängen]

|  
|  
|  
|-
| 6
|
Ausführung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_06 der Überprüfung der Durchführungsphase und Abschluss der Implementierung]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Leitfaden zur Entwicklung von Lösungsbereitstellungen

2017-08-16T10:04:11Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"> ==   Einleitung == *Formulieren Sie die Projektempfehlung   …“

<div class="text-wrap">
==   Einleitung ==

*Formulieren Sie die Projektempfehlung     

Gehen Sie für jedes einzelne Implementierungs- und Bereitstellungsprojekt wie folgt vor:         

*Dokumentenumfang des einzelnen Projektes in der Wirkungsanalyse         
*Dokument strategische Anforderungen (aus der architektonischen Perspektive) in der Wirkungsanalyse         
*Dokumentenänderungsanforderungen (wie zB Unterstützung für eine Standardschnittstelle) in der Wirkungsanalyse         
*Dokumentenregeln für Konformität in der Wirkungsanalyse         
*Dokument Zeitleiste Anforderungen aus Roadmap in der Auswirkungen Analyse     
*Dokumentarchitekturvertrag         
**Erhalten Sie Unterzeichnung von allen Entwicklungsorganisationen und Sponsoring-Organisation     
*Update Enterprise Continuum Verzeichnis und Repository für Lösungen     
*Leitfaden Entwicklung von Business & IT Betriebsmodellen für Dienstleistungen     
*Bereitstellung von Serviceanforderungen aus Unternehmensarchitekturen     
*Leitfaden Definition von Business & IT Betriebsanforderungen     
*Führen Sie eine Lückenanalyse zwischen der Solution Architecture und Operationen durch     
*Implementierungsplan erstellen
</div>

TOGAF-Phase G

2017-08-16T09:59:37Z

Romas:

== Phase G – Steuerung der Einführung ==

;TOGAF

:In Phase G geht es darum, dass das EAM-Team die Umsetzung des Plans aus Phase F überwacht. Also wenn z.B. von einem externen Softwarelieferanten oder Beratungshaus eine neue Software-Lösung implementiert werden soll, dann muss das EAM-Team mit darauf achten, dass die zeitliche Planung eingehalten wird, aber auch dass die Software nachher das tut, was sie tun soll (also ob alle Funktionen darin sind, die benötigt werden). Insbesondere muss auch sichergestellt werden, dass die neue Lösung konform zu den aufgestellten Architekturprinzipien ist. 
:Am Ende der Phase G findet eine Abnahme der neuen Lösung statt. 

;IVS-Rahmenarchitektur
:Die Phase G beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_01 des Umfangs und der Prioritäten für die Bereitstellung von Entwicklungsmanagement]
| Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement
| [[Bestätigung_des_Bereiches_und_der_Prioritäten_für_die_Bereitstellung_mit_dem_Entwicklungsmanagement|Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement]]
|  
|-
| 2
| Identifikation [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_02 von Bereitstellungsressourcen und Fähigkeiten]
| Identifikation von Deployment Resources und Skills
| [[Identifikation_von_Deployment_Resources_und_Skills|Identifikation von Deployment Resources und Skills]]
|  
|-
| 3
| Anleitung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_03 der Entwicklungen von Lösungsbereitstellungen]
| Leitfaden zur Entwicklung von Lösungsbereitstellungen
| [[Leitfaden zur Entwicklung von Lösungsbereitstellungen|Leitfaden zur Entwicklung von Lösungsbereitstellungen]]
|  
|-
| 4
|
Prüfung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_04 der Einhaltung von Unternehmensarchitektur ]

|  
|  
|  
|-
| 5
|
Implementierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_05 von Wirtschafts- und IT Vorgängen]

|  
|  
|  
|-
| 6
|
Ausführung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_06 der Überprüfung der Durchführungsphase und Abschluss der Implementierung]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Identifikation von Deployment Resources und Skills

2017-08-16T09:56:57Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"> == Einleitung == <div class="result-shield-container">Die Projektressourcen umfassen die Entwicklungsressourc…“

<div class="text-wrap">
== Einleitung ==
<div class="result-shield-container">Die Projektressourcen umfassen die Entwicklungsressourcen, die in den Gesamtbetriebsarchitekturleistungen und Erwartungen aus den spezifischen Entwicklungs- und Implementierungsprojekten erarbeitet werden müssen. Folgende Überlegungen sollten in diesem Schritt behandelt werden:     </div>
*Identifizierung von Systementwicklungsmethoden für die Lösungsentwicklung     
<div class="result-shield-container">'''Hinweis:'''</div> <div class="result-shield-container">Für die Projektteams stehen eine Reihe von Systementwicklungsmethoden und -werkzeugen zur Verfügung. Die Methode sollte idealerweise in der Lage sein, mit den Architekturausgängen zusammenzuarbeiten; Zum Beispiel, generieren Code aus Architektur Artefakte geliefert bis heute. Dies könnte durch die Verwendung von Modellierungssprachen erreicht werden, die für die Entwicklung von Unternehmensarchitekturen verwendet werden, die als Eingaben in die Systementwicklungswerkzeuge erfasst werden können und dadurch die Kosten der Lösungsentwicklung verringern.     </div>
*Stellen Sie sicher, dass die Systementwicklungsmethode Feedback an das Architekturteam bei Entwürfen ermöglicht
</div>

TOGAF-Phase G

2017-08-16T09:50:40Z

Romas:

== Phase G – Steuerung der Einführung ==

;TOGAF

:In Phase G geht es darum, dass das EAM-Team die Umsetzung des Plans aus Phase F überwacht. Also wenn z.B. von einem externen Softwarelieferanten oder Beratungshaus eine neue Software-Lösung implementiert werden soll, dann muss das EAM-Team mit darauf achten, dass die zeitliche Planung eingehalten wird, aber auch dass die Software nachher das tut, was sie tun soll (also ob alle Funktionen darin sind, die benötigt werden). Insbesondere muss auch sichergestellt werden, dass die neue Lösung konform zu den aufgestellten Architekturprinzipien ist. 
:Am Ende der Phase G findet eine Abnahme der neuen Lösung statt. 

;IVS-Rahmenarchitektur
:Die Phase G beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_01 des Umfangs und der Prioritäten für die Bereitstellung von Entwicklungsmanagement]
| Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement
| [[Bestätigung_des_Bereiches_und_der_Prioritäten_für_die_Bereitstellung_mit_dem_Entwicklungsmanagement|Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement]]
|  
|-
| 2
| Identifikation [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_02 von Bereitstellungsressourcen und Fähigkeiten]
| Identifikation von Deployment Resources und Skills
| [[Identifikation von Deployment Resources und Skills|Identifikation von Deployment Resources und Skills]]
|  
|-
| 3
|
Anleitung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_03 der Entwicklungen von Lösungsbereitstellungen]

|  
|  
|  
|-
| 4
|
Prüfung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_04 der Einhaltung von Unternehmensarchitektur ]

|  
|  
|  
|-
| 5
|
Implementierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_05 von Wirtschafts- und IT Vorgängen]

|  
|  
|  
|-
| 6
|
Ausführung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_06 der Überprüfung der Durchführungsphase und Abschluss der Implementierung]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement

2017-08-16T09:48:32Z

Romas:

== Einleitung ==

Überprüfen Sie die Migrationsplanungsausgaben und geben Sie Empfehlungen zum Einsatz     

*Identifizieren Sie Unternehmensarchitekturprioritäten für Entwicklungsteams     
*Identifizierung von Bereitstellungsproblemen und Empfehlungen     
*Bausteine für Ersatz, Update, etc. identifizieren     
*Führen Sie Lückenanalyse auf Enterprise Architecture und Solutions Framework     

Die Lücken in der bestehenden Enterprise Solutions Framework müssen identifiziert werden und die spezifischen Solution Building Blocks (SBBs) erforderlich, um diese Lücken zu füllen wird die von den Lösungen Architekten identifiziert werden. Diese SBBs können eine Eins-zu-eins- oder viel-zu-eins-Beziehung zu den Projekten haben. Die Lösungsarchitekten müssen genau definieren, wie dies geschehen wird. Es können andere Projekte sein, die an diesen Fähigkeiten arbeiten und die Lösungen Architekten müssen sicherstellen, dass sie den besten Nutzen aus diesen Investitionen nutzen können.     

*Erstellen Sie einen Lückenanalysebericht

Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement

2017-08-16T09:45:51Z

Romas:

== Einleitung ==

Überprüfen Sie die Migrationsplanungsausgaben und geben Sie Empfehlungen zum Einsatz     

*Identifizieren Sie Unternehmensarchitekturprioritäten für Entwicklungsteams     
*Identifizierung von Bereitstellungsproblemen und Empfehlungen     
*Bausteine für Ersatz, Update, etc. identifizieren     
*Führen Sie Lückenanalyse auf Enterprise Architecture und Solutions Framework     

Die Lücken in der bestehenden Enterprise Solutions Framework müssen identifiziert werden und die spezifischen Solution Building Blocks (SBBs) erforderlich, um diese Lücken zu füllen wird die von den Lösungen Architekten identifiziert werden. Diese SBBs können eine Eins-zu-eins- oder viel-zu-eins-Beziehung zu den Projekten haben. Die Lösungsarchitekten müssen genau definieren, wie dies geschehen wird. Es können andere Projekte sein, die an diesen Fähigkeiten arbeiten und die Lösungen Architekten müssen sicherstellen, dass sie den besten Nutzen aus diesen Investitionen nutzen können.     

Erstellen Sie einen Lückenanalysebericht.

Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement

2017-08-16T09:45:29Z

Romas: Die Seite wurde neu angelegt: „ Überprüfen Sie die Migrationsplanungsausgaben und geben Sie Empfehlungen zum Einsatz      *<span class…“

Überprüfen Sie die Migrationsplanungsausgaben und geben Sie Empfehlungen zum Einsatz     

*Identifizieren Sie Unternehmensarchitekturprioritäten für Entwicklungsteams     
*Identifizierung von Bereitstellungsproblemen und Empfehlungen     
*Bausteine für Ersatz, Update, etc. identifizieren     
*Führen Sie Lückenanalyse auf Enterprise Architecture und Solutions Framework     

Die Lücken in der bestehenden Enterprise Solutions Framework müssen identifiziert werden und die spezifischen Solution Building Blocks (SBBs) erforderlich, um diese Lücken zu füllen wird die von den Lösungen Architekten identifiziert werden. Diese SBBs können eine Eins-zu-eins- oder viel-zu-eins-Beziehung zu den Projekten haben. Die Lösungsarchitekten müssen genau definieren, wie dies geschehen wird. Es können andere Projekte sein, die an diesen Fähigkeiten arbeiten und die Lösungen Architekten müssen sicherstellen, dass sie den besten Nutzen aus diesen Investitionen nutzen können.     

Erstellen Sie einen Lückenanalysebericht.

TOGAF-Phase G

2017-08-16T09:42:52Z

Romas:

== Phase G – Steuerung der Einführung ==

;TOGAF

:In Phase G geht es darum, dass das EAM-Team die Umsetzung des Plans aus Phase F überwacht. Also wenn z.B. von einem externen Softwarelieferanten oder Beratungshaus eine neue Software-Lösung implementiert werden soll, dann muss das EAM-Team mit darauf achten, dass die zeitliche Planung eingehalten wird, aber auch dass die Software nachher das tut, was sie tun soll (also ob alle Funktionen darin sind, die benötigt werden). Insbesondere muss auch sichergestellt werden, dass die neue Lösung konform zu den aufgestellten Architekturprinzipien ist. 
:Am Ende der Phase G findet eine Abnahme der neuen Lösung statt. 

;IVS-Rahmenarchitektur
:Die Phase G beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_01 des Umfangs und der Prioritäten für die Bereitstellung von Entwicklungsmanagement]
| Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement
| [[Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement|Bestätigung des Bereiches und der Prioritäten für die Bereitstellung mit dem Entwicklungsmanagement]]
|  
|-
| 2
|
Identifikation [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_02 von Bereitstellungsressourcen und Fähigkeiten]

|  
|  
|  
|-
| 3
|
Anleitung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_03 der Entwicklungen von Lösungsbereitstellungen]

|  
|  
|  
|-
| 4
|
Prüfung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_04 der Einhaltung von Unternehmensarchitektur ]

|  
|  
|  
|-
| 5
|
Implementierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_05 von Wirtschafts- und IT Vorgängen]

|  
|  
|  
|-
| 6
|
Ausführung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap15.html#tag_15_04_06 der Überprüfung der Durchführungsphase und Abschluss der Implementierung]

|  
|  
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden

2017-08-16T09:38:49Z

Romas: Die Seite wurde neu angelegt: „<div class="text-wrap"> == Einleitung == <div class="result-shield-container">Dieser Schritt überträgt die Governance von der Entwi…“

<div class="text-wrap">
== Einleitung ==
<div class="result-shield-container">Dieser Schritt überträgt die Governance von der Entwicklung der Architektur bis zur Realisierung der Architektur. Wenn die Reife der Architekturfähigkeiten gewährleistet ist, kann ein Implementierungs-Governance-Modell erstellt werden (siehe Teil IV, 36.2.15 Implementierungs-Governance-Modell).</div> <div class="result-shield-container">Die Lehren, die während der Entwicklung der Architektur gelernt wurden, sollten durch den entsprechenden Governance-Prozess in Phase H als Inputs zur Verwaltung der Architekturfähigkeit dokumentiert und erfasst werden. Die Details der Architektur-Roadmap und des Implementierungs- und Migrationsplans sollten in einem ähnlichen Detaillierungsgrad des in den Phasen B, C und D entwickelten Architekturdefinitionsdokuments ausgedrückt werden. Wo in der nächsten Phase erhebliche zusätzliche Details erforderlich sind, ist die Architektur wahrscheinlich Übergang auf eine andere Ebene. Abhängig von der Ebene der Zielarchitektur und des Implementierungs- und Migrationsplans kann es notwendig sein, einen weiteren ADM-Zyklus auf einer niedrigeren Detaillierungsstufe zu iterieren. Siehe Teil III, 19. Anwenden der Iteration auf das ADM und 20. Anwenden des ADM über die Architekturlandschaft für Techniken zur Verwaltung von Iteration und verschiedenen Detailebenen.</div> </div>

TOGAF-Phase F

2017-08-16T09:37:43Z

Romas:

== Phase F – Migrationsplanung ==

;TOGAF

:In Phase F geht es nach TOGAF im Prinzip darum, die ausgewählte Lösung aus Phase E zu planen. Geht es um eine IT-Lösung, dann muss diese von einem Softwareunternehmen beschafft und implementiert werden. D.h. man muss einen Vertrag mit dem Softwareanbieter schließen und ein Projekt aufsetzen zur Implementierung der Software. Handelt es sich nicht um Software, sondern z.B. um Personal, muss man sich in dieser Phase u.a. überlegen, wann wieviele neue Stellen geschaffen werden oder welche Qualitfikationen die neuen Mitarbeiter haben sollen. Evtl. muss auch hier ein Vertrag mit einem externen "Lieferanten" (HR-Spezialist) abgeschlossen werden. 
:Bestandteil des Vertrtags sollte u.a. sein, dass die neue Lösung konform zu den Architekturprinzipien ist. 

;IVS-Rahmenarchitektur
:Die Phase F beschreibt ....

{| class="wikitable"
|-
! Schritt
! TOGAF
! Tailoring IVS-Rahmenarchitektur
! Anleitung
! Artefakte {K=Katalog, M=Matrix, D=Diagramm}, O=Other Deliverables
|-
| 1
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_01 der Interaktion des Framework Managements für die Implementierung und die Migrationsplanung]
| Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan
| [[Management-Interaktion_für_den_Implementierungs-_und_Migrationsplan|Bestätigung von Management-Interaktion für den Implementierungs- und Migrationsplan]]
|  
|-
| 2
| Bestimmung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_02 eines wirtschaftlichen Werts für jedes Arbeitspaket]
| Zuweisung von einem Geschäftswert zu jedem Arbeitspaket
| [[Zuweisung_von_einem_Geschäftswert_zu_jedem_Arbeitspaket|Zuweisung von einem Geschäftswert zu jedem Arbeitspaket]]
|  
|-
| 3
| Einschätzung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_03 der Anforderungen an die Ressourcen, die Zeitplanung des Projekts und die Verfügbarkeit/Lieferfahrzeug]
| Schätzung der Ressourcenanforderungen, Projektzeiten und Verfügbarkeit / Lieferwagen
| [[Schätzung_der_Ressourcenanforderungen,_Projektzeiten_und_Verfügbarkeit_/_Lieferwagen|Schätzung der Ressourcenanforderungen, Projektzeiten und Verfügbarkeit / Lieferwagen]]
|  
|-
| 4
| Priorisierung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_04 der Migrationsprojekte mittels Durchführung einer Kosten-Nutzen-Analyse und Risiko Validierung]
| Priorisierung der Migrationsprojekte durch die Durchführung einer Kosten- / Nutzenbeurteilung und Risikobewertung
| [[Priorisierung_der_Migrationsprojekte_durch_die_Durchführung_einer_Kosten-_/_Nutzenbeurteilung_und_Risikobewertung|Priorisierung der Migrationsprojekte durch die Durchführung einer Kosten- / Nutzenbeurteilung und Risikobewertung]]
|  
|-
| 5
| Bestätigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_05 der Roadmap und Aktualisierung des Definitions Dokument der Architektur]
| Bestätigung von Architektur-Roadmap und Aktualisierung des Architekturdefinitionsdokumentes
| [[Bestätigung_von_Architektur-Roadmap_und_Aktualisierung_des_Architekturdefinitionsdokumentes|Bestätigung von Architektur-Roadmap und Aktualisierung des Architekturdefinitionsdokumentes]]
|-
| 6
| Entwicklung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_06 der Implementierung und der Migrationsplanung]
| Erzeugung von einem Implementierungs- und Migrationsplan
| [[Erzeugung_von_einem_Implementierungs-_und_Migrationsplan|Erzeugung von einem Implementierungs- und Migrationsplan]]
|  
|-
| 7
| Vervollständigung [http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap14.html#tag_14_04_07 des Entwicklungszyklus und des Dokuments über gewonnene Erkenntnisse der Architektur]
| Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden
| [[Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden|Vervollständigung des Architekturentwicklungszyklus und der Unterrichtsstunden]]
|  
|}

----

...

----

[[Hauptseite|<< Zurück zur Hauptseite]]

Erzeugung von einem Implementierungs- und Migrationsplan

2017-08-16T09:34:34Z

Romas: Die Seite wurde neu angelegt: „ == Einleitung == Erzeugen Sie den abgeschlossenen Implementierungs- und Migrationsplan. Ein Großteil der Details für den Plan wur…“

== Einleitung ==

Erzeugen Sie den abgeschlossenen Implementierungs- und Migrationsplan. Ein Großteil der Details für den Plan wurde bereits gesammelt und dieser Schritt bringt alles zusammen mit akzeptierten Planungs- und Managementtechniken.

Dazu gehört die Integration aller Projekte und Aktivitäten sowie Abhängigkeiten und Auswirkungen des Wandels in einen Projektplan. Alle Übergangsarchitekturen werden als Portfolio-Meilensteine fungieren.

Alle externen Abhängigkeiten sollten erfasst und aufgenommen werden, und die Gesamtverfügbarkeit der beurteilten Ressourcen. Projektpläne können in den Implementierungs- und Migrationsplan aufgenommen werden.