Der [Bebauungsplan](/bebauungsplanung/) in der Unternehmensarchitektur umfasst ein ganzes Unternehmen. Aber was ist mit Projekten, Teilbereichen oder anderen größeren Vorhaben? Hier ist es sinnvoll, ein **Big Picture** zu erstellen! Vor allem bei Projekten, die mehrere Anwendungen umfassen oder über Bereichs-/Unternehmensgrenzen hinausgehen. Dieses Bild ist Teil einer [Lösungsarchitektur](/it-architektur/#lösungsarchitektur) und zeigt auf einer übergeordneten Ebene, worum es in dem konkreten Projekt geht. **Big Picture** ist kein standardisierter Begriff. Man kann es auch *IT Landscape View*, *Landscape View* oder ähnliches nennen. Im Grunde ist es der kleine Bruder des *IT Bebauungsplans* in der Unternehmensarchitektur. Das **Big Picture** wird auch nur für große und komplexe Projekte benötigt. Geht es in einem Projekt nur um eine einzelne Anwendung, einen Prozess oder eine Komponente, dann reicht eine [Kontextsicht](/kontextsicht/) zur Visualisierung aus.

## Aufgaben
Das **Big Picture** soll
 * ein gemeinsames Verständnis schaffen
 * Zusammenhänge und Abhängigkeiten zwischen den Komponenten aufzeigen
 * grob visualisieren, was getan werden muss
 * die Projektplanung erleichtern
 * helfen, die richtige Organisation für das Projekt zu finden
 * helfen, das Projekt nach innen und außen zu kommunizieren
 * Ausgangspunkt für tiefer gehende (technische) Diskussionen sein
 * für Nicht-Techniker verständlich sein

Es soll nicht
 * ein detaillierter Implementierungsplan sein
 * eine technische Feinarchitektur darstellen
 * in Stein gemeißelt sein
 * sich zu sehr in technischen Details verlieren

Als Architekt macht man sich das Leben leichter, wenn man die **Big Pictures** im Unternehmen immer weitgehend gleich gestaltet. Dazu sollte man ein [Metamodell](/metamodell/) im Unternehmen etablieren und die Big Pictures nach diesem Standard erstellen.

## Aufbau an Hand eines Beispiels

![Big Picture: GAIA-X Federation Services](gxfs.webp "Big Picture: GAIA-X Federation Services")

Das obige Beispiel eines **Big Picture** zeigt, worum es bei den [GAIA-X Federation Services](https://www.gxfs.eu/de/) geht: Das Projekt (Stand Februar 2022) ist grob in 5 Bereiche gegliedert:
 * Föderierter Katalog
 * Identität & Vertrauen
 * Souveräner Datenaustausch
 * Regelkonformität
 * Portal & Integration

In all diesen Bereichen gibt es *Anwendungen* (blaue Rechtecke), die *Geschäftsfähigkeiten* (gelbe Ellipsen) unterstützen, *Prozesse* (gelbe Parallelogramme) ausführen, aus *Komponenten* (grüne Rechtecke) bestehen und *Datenobjekte* (violette Rechtecke) speichern und verarbeiten:
 * Die [Anwendungen](/anwendung/) zeigen, **was** zu tun ist.
 * Die [Geschäftsfähigkeiten](/business-capability/) zeigen, **warum** es zu tun ist.
 * Die [Prozesse](/business-process/) zeigen, **welche** Abläufe ablaufen
 * Die [IT-Komponenten](/it-komponente/) zeigen, **woraus** eine Anwendung besteht
 * Die [Datenobjekte](/daten/#datenobjekte) zeigen, **was** verarbeitet wird.
 * Ergänzend zeigt die Rollenhierarchie, **wer** welche Aufgaben im System hat.

Für das Verständnis des Gesamtprojektes ist es hilfreich, alle Anwendungen und deren Zweck darzustellen. Weitere Details, wie die Komponenten einer Anwendung oder die ausgeführten Prozesse und verarbeiteten Datenobjekte, werden nur dann dargestellt, wenn sie für das Verständnis des Gesamtprojekts wichtig sind oder eine besondere Bedeutung haben. Noch tiefer gehende Details werden dann erst in einer [Anwendungsarchitektur](/it-architektur/#anwendungsarchitektur) und den darin verorteten [System-](/it-architektur/#systemarchitektur), [Cloud-](/it-architektur/#cloud-architektur) und [Softwarearchitekturen](/it-architektur/#software-architektur) sichtbar.

## Fazit
Jedes Projekt, das mehr als eine Anwendung umfasst, sollte ein **Big Picture** haben. Es liegt in der Verantwortung der verantwortlichen (Lösungs-)Architektin, ein solches zu erstellen. Im Laufe des Projekts entwickelt sich das Bild weiter, wenn neue Informationen hinzukommen oder alte obsolet werden. In einer späteren Projektdokumentation kann das Big Picture als Index verwendet werden, um auf die Dokumentation weiterer Details einer Lösungsarchitektur zu verweisen.