Reichweite der Architektur

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.

Die Reichweite der Architektur wird typischerweise in den folgenden vier Dimensionen beschrieben:

1. Breite: Die Breite entspricht der fachlichen Domäne, für die eine Architektur entwickelt wird.
2. Tiefe: Die Tiefe gibt den Detaillierungsgrad, in dem die Architektur beschrieben wird, an.
3. Zeit: Hier wird festgelegt, für welchen Zeithorizont die Architektur entwickelt werden soll.
4. Architekturphasen: Hier wird beschrieben, welche Architekturphasen (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 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

Breite

Die in 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.

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

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.

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

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.

Zeit

Der Zeithorizont der Architekturentwicklung wird durch den Zeitrahmen des Realisierungsprojektes, in dem der IVS-Dienst entwickelt werden soll, vorgegeben.

Architekturphasen

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.