Architektur und Implementierung

Architektur

Während mit Requirements Engineering und Spezifikation beschreibende Kernaktivitäten im Vordergrund standen, sind die Aktivitäten der Architektur (auch: Design) konstruktive Aktivitäten: Hier werden aufbauend auf den ermittelten fachlichen Anforderungen und der technischen Spezifikation erstmals konkrete Festlegungen getroffen, wie das zu erstellende System diese Anforderungen erfüllt.

In der Literatur und der praktischen Verwendung der Begriffe Architektur und Design hat sich bis heute keine allgemein anerkannte Definition oder Begriffsbildung durchgesetzt. Als Konsequenz wird insbesondere der Begriff "Architektur" je nach Organisation, persönlicher Prägung und Vorliebe anders verwendet. So kann der Begriff der IT-Architektur eingesetzt werden, um - ähnlich dem klassischen Architekturbegriff - folgende Dinge zu bezeichnen:

• Den Prozess der Gestaltung von Softwaresystemen (und Teilsystemen) aller Art.
• Die Titel einer IT-Architekturtypologie, zum Beispiel "Client-Server-Architektur".
• Das Berufsfeld des IT-Architekten, also das Fachgebiet IT-Architektur.
• Das Ergebnis für das ein IT-Architekt verantwortlich ist, also die Menge der Artefakte die er erzeugt.
• Die Bezeichnung für die Wissenschaft vom Gestalten von IT-Systemen, also die Lehre der IT-Architektur.

Sowohl Architektur als auch Design sind Aktivitäten, in denen entschieden wird, wie das zukünftige System strukturiert und aufgebaut ist. Oft wird mit Architektur auch der "Grobentwurf" eines Softwaresystems bezeichnet und mit Design der "Feinentwurf". Verglichen mit der Architektur eines Hauses bedeutet das, dass mit der Architektur die Grundstruktur, Form, Art des Daches, Anzahl der Zimmer sowie Anordnung und Form der Fenster festgelegt wird. Wie die Wasserhähne aussehen, welche Farbe die Fliesenfugen haben und in welche Richtung sich welche Tür öffnet, wird im Design festgelegt. Allerdings wird auch diese Bezeichnung nicht einheitlich verwendet.
Hier wird der Begriff Architektur für alle Festlegungen und Entscheidungen über das System verwendet, die vor der Implementierung getroffen werden. Also als Sammelbegriff für alles, was an anderer Stelle auch als Entwurf, Design, Grobentwurf oder Feinentwurf bezeichnet wird.

Überführung von Problemraum in Lösungsraum

Die Einbettung der Aktivitäten in die Architektur ist in untenstehender Abbildung dargestellt: Die Architektur bezeichnet die Überführung der Menge aller Anforderungen an ein System (den Problemraum) in ein konkretes, ausführbares Softwaresystem (den Lösungsraum).

Beginnend mit dem RE wird analysiert und anschließend spezifiziert, was vom System verlangt wird. Bei der Implementierung wird die Menge von Bedingungen und Vorgaben an ein konkretes System in ausführbaren Programmcode übersetzt. Zwischen RE/Spezifikation und Implementierung ist die Architektur angesiedelt. Der IT-Architekt muss die Bedürfnisse der Stakeholder analysieren und verstehen, gegeneinander abwägen und durch eine Menge von Entscheidungen und Gestaltungsaktivitäten eine Architekturbeschreibung entwickeln. Die Architekturbeschreibung (auch: Architekturdefinition) stellt die Verbindung von Lösungsraum und Problemraum dar. Sie dient dem Entwicklerteam als Vorlage und Rahmenwerk für die Aktivitäten zur Implementierung.

Kernaktivitäten der Architekturerstellung

Die Aktivitäten der Architekturerstellung, also der Prozess, der zu einer Architekturbeschreibung führt, lassen sich in drei Kernaktivitäten einteilen:

1. Erfassen der Anforderungen und Interessen der Stakeholder
   Zuerst analysiert der Architekt, was für die jeweiligen Stakeholder wichtig ist. Dabei muss er neben den spezifizierten fachlichen Anforderungen insbesondere auch die Stakeholder mit berücksichtigen, die an der Entwicklung und dem Betrieb des Systems beteiligt sind, sowie den Auftraggeber.
   In der Regel gibt der Architekt auch eine erste Aufwandsschätzung, da er einschätzen kann, wie aufwendig die spezifizierten Anforderungen in der Umsetzung sind. Daher hilft und unterstützt der Architekt bei Abwägungen und Entscheidungen zwischen Kosten und Funktionalität. Anschließend muss die nun gegebenenfalls eingeschränkte Menge der Anforderungen dokumentiert und von den Stakeholdern angenommen werden.
2. Entwerfen einer Architektur, die diese Menge an Anforderungen erfüllt
   Auf Basis der Menge der Anforderungen trifft der Architekt Entwurfsentscheidungen zur Erfüllung der Anforderungen. Das heißt, er erstellt eine erste Version der Architekturbeschreibung. Anschließend müssen die getroffenen Entscheidungen gegen die Anforderungen geprüft und bewertet werden. Gegebenenfalls muss die IT-Architektur überarbeitet werden. Fällt das Ergebnis der Bewertung positiv aus, wird die IT-Architektur so lange weiter verfeinert und detailliert, bis eine ausreichende Lösung gefunden ist.
3. Beschreiben und Dokumentieren der Architektur
   Als dritte Kernaktivität müssen die getroffenen Entscheidungen in Form einer Architekturbeschreibung dokumentiert werden. Wie bei den Aktivitäten der Spezifikation werden Architekturen unter Verwendung von Softwaremodellen technisch dokumentiert. Je detaillierter die Entscheidungen zur Architektur werden, umso technischer und präziser müssen die Ergebnisse dokumentiert werden.
   Vergleichbar mit den Kernaktivitäten des Requirements Engineerings finden die Aktivitäten zur Architekturbeschreibung iterativ (in mehreren Zyklen) statt. Jede zusätzliche Anforderung, die im Verlauf der Softwareentwicklung erkannt wird und als erforderlich eingestuft wird, muss durch den Softwarearchitekten bewertet und in die bestehende Architekturbeschreibung eingebracht werden.

Architekturbeschreibung

Das Ergebnis der Gestaltungsaktivitäten eines IT-Architekten ist die Architekturbeschreibung. Die eigentliche Architektur des Systems manifestiert sich jedoch erst während der Implementierung des Systems. Jedes System hat eine Architektur, auch wenn kein Softwarearchitekt eine Architekturbeschreibung erstellt hat. Architektur ist also systemimmanent. Man kann auch ein Haus bauen, ohne einen Architekten hinzuzuziehen. Das fertige Haus hat dann ebenfalls eine "Architektur", auch wenn diese vielleicht nicht sehr schön oder praktisch ist. Dieses Bild ist auf Softwaresysteme übertragbar. Grundsätzlich kann ein System auch ohne Architekt implementiert werden. Jedoch ist die Gefahr - wie beim Hausbau -, dass wichtige Elemente vergessen oder ungeschickt platziert werden oder die Grundstruktur des Systems den tatsächlichen Belastungen - zum Beispiel durch hohe Nutzerzahlen - nicht standhält, groß.

Dokumentation von IT-Architekturen

IT-Architekturen können auf unterschiedliche Weise dokumentiert werden. Für erste Ideen werden oft einfache Skizzen und PowerPoint-Grafiken erstellt. Diese können zwar schnell angefertigt werden, sind jedoch ohne festgelegte Semantik und lassen einen oft gefährlich großen Interpretationsspielraum zu. Für Personen, die am Erstellungsprozess nicht beteiligt sind, ist diese Art der Darstellung in der Regel nicht zu verstehen. Daher sollten Architekturbeschreibungen immer mit strukturierten Softwaremodellen (z. B. UML) dokumentiert werden. Deren Notationselemente haben eine festgelegte Bedeutung (Semantik) und sind weltweit verbreitet.
Darüber hinaus gibt es auch spezifische Architekturbeschreibungssprachen (ADL), die in der Forschung zu Softwarearchitekturen eingesetzt werden. Diese ADLs zeichnen sich daher zwar durch eine formal definierte Semantik ihrer Notationselemente aus, sind jedoch für praktische Zwecke oft nicht geeignet.
Eine weitere Möglichkeit Architekturentscheidungen zu dokumentieren bietet direkt der Programmcode. Auf diese Weise ist die Architekturbeschreibung immer aktuell und konsistent zum erzeugten Programmcode. Jedoch erlaubt diese Dokumentationsform keinen einfachen Überblick mehr und sie ist nur von Programmierexperten lesbar.

Eine große Herausforderung im Umgang mit Architekturbeschreibungen stellt die Divergenz der dokumentierten Design-Entscheidungen in Form der Architekturbeschreibung und der tatsächlichen Systemarchitektur dar. Softwareentwickler sind weder physikalisch noch logisch an die Vorgaben des Architekten gebunden. Es gibt bei der Programmierung grundsätzlich keine Einschränkungen, sodass jederzeit die Ausdrucksstärke einer Programmiersprache durch die Entwickler ausgenutzt weden kann - auch wenn sie den ursprünglichen Architekturvorgaben widersprechen.

Einsatzszenarien für Architekturdokumentation

Grundlegend lassen sich zwei verschiedene Einsatzmöglichkeiten von Architekturdokumentationen unterscheiden:

A priori Dokumentation, also die Erstellung einer Architekturbeschreibung vor der Umsetzung des Systems auf Grundlage von Designaktivitäten und -entscheidungen. In diesem Fall wird die Architekturdokumentation verwendet, um Vereinbarungen über die Gestaltung des Systems zu explizieren und zu dokumentieren. Sie legt den Rahmen fest, in dem die Entwicklerteams eigenständige Entscheidungen treffen dürfen, und damit den Soll-Zustand der Softwarearchitektur. Die a priori Dokumentation bildet auch den Ausgangspunkt für die Validierung der Eignung einer Architektur zur Unterstützung geforderter Qualitätseigenschaften und Randbedingungen.

Ex post Dokumentation, also die Erstellung der Architekturbeschreibung nach der Umsetzung des Systems auf Grundlage des implementierten Programmcodes. Sie dient dem Darstellen und Dokumentieren der tatsächlich implementierten Architektur. Eine so erzeugte Architekturbeschreibung stellt den Ist-Zustand der Softwarearchitektur dar. Sie kann entweder für den Vergleich der geplanten Architektur und der implementierten Architektur oder als Ausgangspunkt für die Architekturbewertung hinsichtlich der Einhaltung von Normen, Richtlinien oder Gesetzen genutzt werden.

Ebenen von IT-Architekturen

Grundsätzlich lassen sich im Software Engineering Architekturen auf verschiedenen Ebenen erstellen. Von der Übersicht über fachliche Konzepte und Zusammenhänge mit einer Facharchitektur über die Darstellung von Struktur und Aufbau einzelner Softwaresysteme mit einer Softwarearchitektur bis hin zur Darstellung der gesamten Unternehmens-IT in einer IT-Unternehmensarchitektur gibt es verschiedene IT-Architekturen. Grundsätzlich kann für jeden relevanten Teilbereich beziehungsweise jede Spezialsicht auf ein Softwaresystem eine spezifische Architektur erstellt werden, zum Beispiel eine Sicherheitsarchitektur oder eine Kommunikationsarchitektur. In nachstehender Tabelle werden die verschiedenen Ebenen der IT-Architekturen (Facharchitektur, Softwarearchitektur und IT-Unternehmensarchitektur) gegenübergestellt.