Reichweite der Architektur - Versionsgeschichte

Kopylova am 15. November 2017 um 14:55 Uhr

2017-11-15T14:55:19Z

Pfähler am 14. September 2016 um 12:13 Uhr

2016-09-14T12:13:56Z

Scholtes am 31. August 2016 um 13:56 Uhr

2016-08-31T13:56:04Z

Scholtes: /* Übertragung des Reichweitekonzepts auf IVS-Architektur */

2016-08-31T13:49:25Z

Übertragung des Reichweitekonzepts auf IVS-Architektur

Scholtes: /* Übertragung des Reichweitekonzepts auf IVS-Architektur */

2016-08-31T13:48:29Z

Übertragung des Reichweitekonzepts auf IVS-Architektur

Scholtes: /* Übertragung des Reichweitekonzepts auf IVS-Architektur */

2016-08-31T13:47:28Z

Übertragung des Reichweitekonzepts auf IVS-Architektur

Scholtes: /* Übertragung des Reischweitekonzepts auf IVS-Architektur */

2016-08-31T13:42:47Z

Übertragung des Reischweitekonzepts auf IVS-Architektur

Scholtes: /* Reichweite von Architektur nach TOGAF */

2016-08-31T13:37:00Z

Reichweite von Architektur nach TOGAF

Albrecht: /* Reichweite von Architektur nach TOGAF */

2016-08-30T14:37:01Z

Reichweite von Architektur nach TOGAF

Albrecht: /* Tiefe */

2016-08-30T14:13:30Z

Tiefe

@@ Zeile 1: / Zeile 1: @@
 == Reichweite von Architektur nach TOGAF ==
-Laut TOGAF wird hier definiert, wie weitreichend die Ausgangssituation der Architektur (Ist-Architektur) und die Ziel-Architektur (Soll-Architektur) beschrieben werden soll. Die Ist- und die Soll-Architektur werden in unterschiedlichem Detaillierungsgrad beschrieben. Häufig wird die Ist-Architektur nicht so detailliert beschrieben wie die Soll-Architektur, damit mehr Zeit verfügbar ist, um den Soll-Zustand zu beschreiben.
+Laut TOGAF wird hier definiert, wie weitreichend die Ausgangssituation der Architektur (Ist-Architektur) und der Ziel-Architektur (Soll-Architektur) beschrieben werden soll. Die Ist- und die Soll-Architektur werden in unterschiedlichem Detaillierungsgrad beschrieben. Häufig wird die Ist-Architektur nicht so detailliert beschrieben wie die Soll-Architektur, damit mehr Zeit verfügbar ist, um den Soll-Zustand zu beschreiben.
 Die Reichweite der Architektur wird typischerweise in den folgenden vier Dimensionen beschrieben:
 #'''Breite''': Die Breite entspricht der fachlichen Domäne, für die eine Architektur entwickelt wird.
-#'''Tiefe''': Die Tiefe gibt den Detaillierungsgrad, in dem die Architektur beschrieben wird, an.
+#'''Breite''': Die Breite entspricht der fachlichen Domäne, für die eine Architektur entwickelt wird.
-#'''Zeit''': Hier wird festgelegt, für welchen Zeithorizont die Architektur entwickelt werden soll.
+#'''Tiefe''': Die Tiefe gibt den Detaillierungsgrad an, in dem die Architektur beschrieben wird.
-#'''Architekturebenen''': Hier wird beschrieben, welche Architekturebenen (Geschäfts-, Daten-, Anwendungs-, Technologiearchitektur) im Fokus der Architekturentwicklung stehen.
+#'''Zeit''': Hier wird festgelegt, für welchen Zeithorizont die Architektur entwickelt werden soll.
 Diese vier Dimensionen werden für die Referenzarchitekturen und die Architekturen realer IVS-Dienste unterschiedlich festgelegt.
 == Übertragung des Reichweitekonzepts auf IVS-Architektur ==
-Im IVS-Architekturkontext geht es um Capabilities und dort hauptsächlich um Interoperabilität. In diesem Kontext ist Interoperabilität Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide dargestellt - nebenstehende Abbildung.
+[[File:IVS-Interoperabilität Horizontal.png|thumb|right|400px|Interoperabilität zwischen den Schichten der IVS-Architekturpyramide]]
 Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei unterschiedliche Formen von Interoperabilität unterschieden werden:
-* '''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen
+*'''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen
-* '''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen
+*'''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen
-(siehe auch [[IVS-Capibilities#Formen von Interoperabilität|Formen von Interoperabilität]])
+(siehe auch [[IVS-Capibilities#Formen_von_Interoperabilität|Formen von Interoperabilität]])
 == Definition der Reichweite für IVS-Referenzarchitekturen ==
 === Breite ===
 Die in [[IVS-Dömänen|Schritt 1 der Vorbereitungsphase]] beschriebene fachliche Domäne einer Referenzarchitektur legt die Breite der Architekturentwicklung fest.
 === Tiefe ===
-Bei der Beschreibung der Tiefe der Architekturentwicklung muss zwischen der Ist- und der Soll-Architektur unterschieden werden. Ziel der Referenzarchitekturen ist es, einen Soll-Zustand zu beschreiben. Deshalb sollte der Detaillierungsgrad für die Beschreibung der Soll-Architektur höher gewählt werden als für die Ist-Architektur.
+Die Detaillierungstiefe der Architekturentwicklung einer Referenzarchitektur ist so zu wählen, dass die '''Interoperabilität zwischen IVS-Akteuren''' gewährleistet ist. Der Detaillierungsgrad sollte nicht höher sein, als zur Beschreibung der Interoperabilität benötigt.
 Bei der Beschreibung der Ist-Architektur werden die bereits vorhandenen Architekturbausteine, die unverändert in die Soll-Architektur übernommen werden können, oft gar nicht oder nur kurz erwähnt. Der Schwerpunkt liegt auf der Beschreibung fehlender, zu verändernder oder für die Soll-Architektur hinderlicher Architekturbausteine. Dabei werden die Bausteine in der Regel nicht ausführlich beschrieben, sondern lediglich skizziert, welche Hemmnisse bei der Entwicklung der Soll-Architektur bestehen. Außerdem sollte für jeden beschriebenen Architekturbaustein eine Begründung angegeben werden, warum dieser neu erstellt, verändert oder entfernt werden soll.
 Bei der Beschreibung der Soll-Architektur werden die neu zu entwickelnden und die zu verändernden Architekturbausteine ausführlicher beschrieben. Die Architekturbausteine, die zukünftig nicht mehr verwendet werden sollen, wurden bereits bei der Ist-Architektur aufgelistet und werden hier nicht nochmals aufgeführt.
 === Zeit ===
 Der Zeithorizont, für den die Referenzarchitekturen entwickelt werden, kann pro Referenzarchitektur unterschiedlich festgelegt werden. Als Defaultwert wird ein Zeithorizont von fünf Jahren vorgeschlagen.
 === Architekturebenen ===
-== Definition der Reichweite für Architekturen realer IVS-Dienste==
+Der Schwerpunkt der Referenzarchitekturen liegt auf den Architekturebenen B und C (Geschäfts-, Daten- und Anwendungsarchitektur). Da die Referenzarchitekturen für viele reale IVS-Dienste gelten, kann die Technologiearchitektur nicht im selben Maße wie die Geschäfts-, Daten- und Anwendungsarchitektur beschrieben werden. Häufig werden von den Referenzarchitekturen für die Technologiearchitektur keine Vorgaben gemacht. Trotz alledem kann eine Referenzarchitektur auch Vorgaben für die Technologiearchitektur machen. Dabei sollte jedoch berücksichtigt werden, dass die Festlegungen bezüglich anzuwendender Technologien die Umsetzung der Referenzarchitekturen nicht einschränkt oder behindert.
 === Breite ===
 Bei der Entwicklung eines realen IVS-Dienstes soll die fachliche Domäne des IVS-Dienstes beschrieben werden.
 === Tiefe ===
 Die Detaillierungstiefe der Architekturentwicklung einer Architektur eines realen IVS-Dienstes ist so zu wählen, dass eine reale '''Umsetzung bzw. Implementation des IVS-Dienstes''' gewährleistet ist.
@@ Zeile 49: / Zeile 64: @@
 Bei der Beschreibung der Ist-Architektur werden die bereits vorhandenen Architekturbausteine, die unverändert in die Soll-Architektur übernommen werden können, oft gar nicht oder nur kurz erwähnt. Der Schwerpunkt liegt auf der Beschreibung fehlender, zu verändernder oder für die Soll-Architektur hinderlicher Architekturbausteine. Dabei werden die Bausteine in der Regel nicht ausführlich beschrieben, sondern lediglich skizziert, welche Hemmnisse bei der Entwicklung der Soll-Architektur bestehen. Außerdem sollte für jeden beschriebenen Architekturbaustein eine Begründung angegeben werden, warum dieser neu erstellt, verändert oder entfernt werden soll.
 Bei der Beschreibung der Soll-Architektur werden die neu zu entwickelnden und die zu verändernden Architekturbausteine ausführlicher beschrieben. Die Architekturbausteine, die zukünftig nicht mehr verwendet werden sollen, wurden bereits bei der Ist-Architektur aufgelistet und werden hier nicht nochmals aufgeführt.
 === Zeit ===
 Der Zeithorizont der Architekturentwicklung wird durch den Zeitrahmen des Realisierungsprojektes, in dem der IVS-Dienst entwickelt werden soll, vorgegeben.
 === Architekturebenen ===
 Im Gegensatz zu den Referenzarchitekturen werden bei der Entwicklung der Architektur eines realen IVS-Dienstes alle Architekturebenen (Geschäfts-, Daten-, Anwendungs- und Technologiearchitektur) durchlaufen. Dabei muss die Technologiearchitektur so klar beschrieben werden, dass die Realisierung des IVS-Dienstes in einem "Technologie-Stack" eindeutig vorgegeben ist.
 ----
 [[Hauptseite|<< Zurück zur Hauptseite]]

← Nächstältere Version		Version vom 14. September 2016, 12:13 Uhr
Zeile 54:		Zeile 54:
	=== Architekturebenen ===		=== Architekturebenen ===
	Im Gegensatz zu den Referenzarchitekturen werden bei der Entwicklung der Architektur eines realen IVS-Dienstes alle Architekturebenen (Geschäfts-, Daten-, Anwendungs- und Technologiearchitektur) durchlaufen. Dabei muss die Technologiearchitektur so klar beschrieben werden, dass die Realisierung des IVS-Dienstes in einem "Technologie-Stack" eindeutig vorgegeben ist.		Im Gegensatz zu den Referenzarchitekturen werden bei der Entwicklung der Architektur eines realen IVS-Dienstes alle Architekturebenen (Geschäfts-, Daten-, Anwendungs- und Technologiearchitektur) durchlaufen. Dabei muss die Technologiearchitektur so klar beschrieben werden, dass die Realisierung des IVS-Dienstes in einem "Technologie-Stack" eindeutig vorgegeben ist.
		+
		+	----
		+	[[Hauptseite\|<< Zurück zur Hauptseite]]

@@ Zeile 27: / Zeile 27: @@
 Die in [[IVS-Dömänen|Schritt 1 der Vorbereitungsphase]] beschriebene fachliche Domäne einer Referenzarchitektur legt die Breite der Architekturentwicklung fest.
 === Tiefe ===
 Bei der Beschreibung der Tiefe der Architekturentwicklung muss zwischen der Ist- und der Soll-Architektur unterschieden werden. Ziel der Referenzarchitekturen ist es, einen Soll-Zustand zu beschreiben. Deshalb sollte der Detaillierungsgrad für die Beschreibung der Soll-Architektur höher gewählt werden als für die Ist-Architektur.
 Bei der Beschreibung der Ist-Architektur werden die bereits vorhandenen Architekturbausteine, die unverändert in die Soll-Architektur übernommen werden können, oft gar nicht oder nur kurz erwähnt. Der Schwerpunkt liegt auf der Beschreibung fehlender, zu verändernder oder für die Soll-Architektur hinderlicher Architekturbausteine. Dabei werden die Bausteine in der Regel nicht ausführlich beschrieben, sondern lediglich skizziert, welche Hemmnisse bei der Entwicklung der Soll-Architektur bestehen. Außerdem sollte für jeden beschriebenen Architekturbaustein eine Begründung angegeben werden, warum dieser neu erstellt, verändert oder entfernt werden soll.
-Bei der Beschreibung der Soll-Arhitektur werden die neu zu entwickelnden und die zu verändernden Architekturbausteine ausführlicher beschrieben. Die Architekturbausteine, die zukünftig nicht mehr verwendet werden sollen, wurden bereits bei der Ist-Architektur aufgelistet und werden hier nicht nochmals aufgeführt. Die Beschreibung der neu zu entwickelnden und der zu verändernden Architekturbausteine muss so detailliert vorgenommen werden, dass eine Interoperalität der Bausteine gewährleistet ist. Dabei soll die Detaillierungstiefe aber auch nicht höher sein, als benötigt.
+Bei der Beschreibung der Soll-Architektur werden die neu zu entwickelnden und die zu verändernden Architekturbausteine ausführlicher beschrieben. Die Architekturbausteine, die zukünftig nicht mehr verwendet werden sollen, wurden bereits bei der Ist-Architektur aufgelistet und werden hier nicht nochmals aufgeführt.
 === Zeit ===
 Der Zeithorizont, für den die Referenzarchitekturen entwickelt werden, kann pro Referenzarchitektur unterschiedlich festgelegt werden. Als Defaultwert wird ein Zeithorizont von fünf Jahren vorgeschlagen.
-=== Architekturphasen ===
+=== Architekturebenen ===
-Der Schwerpunkt der Referenzarchitekturen liegt auf den Architekturphasen B und C (Geschäfts-, Daten- und Anwendungsarchitektur). Da die Referenzarchitekturen für viele reale IVS-Dienste gelten, kann die Technologiearchitektur nicht im selben Maße wie die Geschäfts-, Daten- und Anwendungsarchitektur beschrieben werden. Häufig werden von den Referenzarchitekturen für die Technologiearchitektur keine Vorgaben gemacht. Nichtsdestotrotz kann eine Referenzarchitektur auch Vorgaben für die Technologiearchitektur machen. Dabei sollte jedoch berücksichtigt werden, dass die Festlegungen bezüglich anzuwendender Technologien die Umsetzung der Referenzarchitekturen nicht einschränkt oder behindert.
+Der Schwerpunkt der Referenzarchitekturen liegt auf den Architekturebenen B und C (Geschäfts-, Daten- und Anwendungsarchitektur). Da die Referenzarchitekturen für viele reale IVS-Dienste gelten, kann die Technologiearchitektur nicht im selben Maße wie die Geschäfts-, Daten- und Anwendungsarchitektur beschrieben werden. Häufig werden von den Referenzarchitekturen für die Technologiearchitektur keine Vorgaben gemacht. Nichtsdestotrotz kann eine Referenzarchitektur auch Vorgaben für die Technologiearchitektur machen. Dabei sollte jedoch berücksichtigt werden, dass die Festlegungen bezüglich anzuwendender Technologien die Umsetzung der Referenzarchitekturen nicht einschränkt oder behindert.
 == Definition der Reichweite für Architekturen realer IVS-Dienste==
@@ Zeile 41: / Zeile 43: @@
 Bei der Entwicklung eines realen IVS-Dienstes soll die fachliche Domäne des IVS-Dienstes beschrieben werden.
 === Tiefe ===
 Auch hier muss zwischen der Ist- und der Soll-Architektur unterschieden werden. Ziel der Architektur eines realen IVS-Dienstes ist es, einen Soll-Zustand zu beschreiben. Deshalb sollte der Detaillierungsgrad für die Beschreibung der Soll-Architektur höher gewählt werden als für die Ist-Architektur.
 Bei der Beschreibung der Ist-Architektur werden die bereits vorhandenen Architekturbausteine, die unverändert in die Soll-Architektur übernommen werden können, oft gar nicht oder nur kurz erwähnt. Der Schwerpunkt liegt auf der Beschreibung fehlender, zu verändernder oder für die Soll-Architektur hinderlicher Architekturbausteine. Dabei werden die Bausteine in der Regel nicht ausführlich beschrieben, sondern lediglich skizziert, welche Hemmnisse bei der Entwicklung der Soll-Architektur bestehen. Außerdem sollte für jeden beschriebenen Architekturbaustein eine Begründung angegeben werden, warum dieser neu erstellt, verändert oder entfernt werden soll.
-Bei der Beschreibung der Soll-Architektur werden die neu zu entwickelnden und die zu verändernden Architekturbausteine ausführlicher beschrieben. Die Architekturbausteine, die zukünftig nicht mehr verwendet werden sollen, wurden bereits bei der Ist-Architektur aufgelistet und werden hier nicht nochmals aufgeführt. Die Beschreibung der neu zu entwickelnden und der zu verändernden Architekturbausteine muss so detailliert vorgenommen werden, dass aufgrund der Beschreibung eine reale Umsetzung bzw. Implementation der Bausteine möglich ist. Dabei soll die Detaillierungstiefe aber auch nicht höher sein, als benötigt.
+Bei der Beschreibung der Soll-Architektur werden die neu zu entwickelnden und die zu verändernden Architekturbausteine ausführlicher beschrieben. Die Architekturbausteine, die zukünftig nicht mehr verwendet werden sollen, wurden bereits bei der Ist-Architektur aufgelistet und werden hier nicht nochmals aufgeführt.
 === Zeit ===
 Der Zeithorizont der Architekturentwicklung wird durch den Zeitrahmen des Realisierungsprojektes, in dem der IVS-Dienst entwickelt werden soll, vorgegeben.
-=== Architekturphasen ===
+=== Architekturebenen ===
-Im Gegensatz zu den Referenzarchitekturen werden bei der Entwicklung der Architektur eines realen IVS-Dienstes alle Architekturphasen (Geschäfts-, Daten-, Anwendungs- und Technologiearchitektur) durchlaufen. Dabei muss die Technologiearchitektur so klar beschrieben werden, dass die Realisierung des IVS-Dienstes in einem "Technologie-Stack" eindeutig vorgegeben ist.
+Im Gegensatz zu den Referenzarchitekturen werden bei der Entwicklung der Architektur eines realen IVS-Dienstes alle Architekturebenen (Geschäfts-, Daten-, Anwendungs- und Technologiearchitektur) durchlaufen. Dabei muss die Technologiearchitektur so klar beschrieben werden, dass die Realisierung des IVS-Dienstes in einem "Technologie-Stack" eindeutig vorgegeben ist.

@@ Zeile 21: / Zeile 21: @@
 * '''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen
-(siehe auch [[IVS-Capibilities#Formen von Interoperabilität|Formen von Interoperabilität]
+(siehe auch [[IVS-Capibilities#Formen von Interoperabilität|Formen von Interoperabilität]])
 == Definition der Reichweite für IVS-Referenzarchitekturen ==

@@ Zeile 21: / Zeile 21: @@
 * '''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen
-(siehe auch [[IVS-Capibilities#Interoperabilit.C3.A4t_als_Schl.C3.BCsselbegriff|Formen von Interoperabilität]
+(siehe auch [[IVS-Capibilities#Formen von Interoperabilität|Formen von Interoperabilität]
 == Definition der Reichweite für IVS-Referenzarchitekturen ==

@@ Zeile 11: / Zeile 11: @@
 Diese vier Dimensionen werden für die Referenzarchitekturen und die Architekturen realer IVS-Dienste unterschiedlich festgelegt.
-== Übertragung des Reischweitekonzepts auf IVS-Architektur ==
+== Übertragung des Reichweitekonzepts auf IVS-Architektur ==
-Im IVS-Architekturkontext get es um capabilities und dprt hauptsächlich um Interoperabilität ....
+Im IVS-Architekturkontext geht es um Capabilities und dort hauptsächlich um Interoperabilität, die Bestandteil von Verhalten auf den Ebenen von IVS-Architektur ist. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide dargestellt - nebenstehende Abbildung.
 Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei unterschiedliche Formen von Interoperabilität unterschieden werden:

← Nächstältere Version		Version vom 30. August 2016, 14:37 Uhr
Zeile 10:		Zeile 10:

	Diese vier Dimensionen werden für die Referenzarchitekturen und die Architekturen realer IVS-Dienste unterschiedlich festgelegt.		Diese vier Dimensionen werden für die Referenzarchitekturen und die Architekturen realer IVS-Dienste unterschiedlich festgelegt.
		+
		+	== Übertragung des Reischweitekonzepts auf IVS-Architektur ==
		+
		+	Im IVS-Architekturkontext get es um capabilities und dprt hauptsächlich um Interoperabilität ....
		+
		+	Bestandteil von Verhalten auf den Ebenen von IVS-Architektur. Diesen Zusammenhang zeigt - mit den Darstellungsmitteln der IVS-Architekturpyramide dargestellt - nebenstehende Abbildung.
		+
		+	Interoperabilität wird sichtbar an Schnittstellen. Generell müssen dabei zwei unterschiedliche Formen von Interoperabilität unterschieden werden:
		+
		+	* '''Kommunikative Interoperabilität''': Kommunikatives Verhalten an Schnittstellen
		+	* '''Verhaltens-Interoperabilität''': Funktionales Verhalten an Schnittstellen

	== Definition der Reichweite für IVS-Referenzarchitekturen ==		== Definition der Reichweite für IVS-Referenzarchitekturen ==