Reichweite der Architektur: Unterschied zwischen den Versionen
| (20 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | |||
| − | |||
| − | + | == Reichweite von Architektur nach TOGAF == | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | 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: | |
| − | Die | + | #'''Breite''': Die Breite entspricht der fachlichen Domäne, für die eine Architektur entwickelt wird. |
| + | #'''Tiefe''': Die Tiefe gibt den Detaillierungsgrad an, in dem die Architektur beschrieben wird. | ||
| + | #'''Zeit''': Hier wird festgelegt, für welchen Zeithorizont die Architektur entwickelt werden soll. | ||
| + | #'''Architekturebenen''': Hier wird beschrieben, welche Architekturebenen (Geschäfts-, Daten-, Anwendungs-, Technologiearchitektur) im Fokus der Architekturentwicklung stehen. | ||
| − | == Definition der Reichweite == | + | Diese vier Dimensionen werden für die Referenzarchitekturen und die Architekturen realer IVS-Dienste unterschiedlich festgelegt. |
| + | |||
| + | == Übertragung des Reichweitekonzepts auf IVS-Architektur == | ||
| + | |||
| + | [[File:IVS-Interoperabilität Horizontal.png|thumb|right|400px|Interoperabilität zwischen den Schichten der IVS-Architekturpyramide]] | ||
| + | |||
| + | Im IVS-Architekturkontext geht es um Capabilities und dort hauptsächlich um Interoperabilität. In diesem Kontext ist Interoperabilität ein 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 | ||
| + | |||
| + | (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 === | ||
| + | |||
| + | 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 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-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 === | ||
| + | |||
| + | 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. | ||
| + | |||
| + | == Definition der Reichweite für Architekturen realer IVS-Dienste == | ||
| + | |||
| + | === 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. | ||
| + | |||
| + | 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. | ||
| + | |||
| + | === 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]] | ||
Aktuelle Version vom 15. November 2017, 15:55 Uhr
Inhaltsverzeichnis
Reichweite von Architektur nach TOGAF
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 an, in dem die Architektur beschrieben wird.
- Zeit: Hier wird festgelegt, für welchen Zeithorizont die Architektur entwickelt werden soll.
- Architekturebenen: Hier wird beschrieben, welche Architekturebenen (Geschäfts-, Daten-, Anwendungs-, Technologiearchitektur) im Fokus der Architekturentwicklung stehen.
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 ein 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
(siehe auch Formen von Interoperabilität)
Definition der Reichweite für IVS-Referenzarchitekturen
Breite
Die in Schritt 1 der Vorbereitungsphase beschriebene fachliche Domäne einer Referenzarchitektur legt die Breite der Architekturentwicklung fest.
Tiefe
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 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-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
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.
Definition der Reichweite für Architekturen realer IVS-Dienste
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.
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.
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.
