Die Rolle der Architektur in der Anwendungsentwicklung bzw. Informations-Technologie

Dieses Papier umreißt den Begriff der "Architektur" und stellt deren Bedeutung in der Software-Entwicklung dar. Der Begriff der "Architektur" basiert auf den Erfahrungen, welche wir in mittleren bis großen Software-Entwicklungsprojekten gemacht haben. Darauf aufbauend gibt er eine Übersicht über die konkreten Arbeitsprodukte, mit denen eine Architektur in der Informations-Technologie definiert werden kann und ordnet diese in den Phasenprozess ein. Der Artikel schliesst mit einer Reihe von praktischen Hinweisen.

Den Artikel können Sie rechts herunterladen.

Der Begriff der „Architektur“

Die Architektur besitzt in der Softwareentwicklung eine große Bedeutung, der Begriff selbst wird jedoch unterschiedlich und oft nur sehr vage definiert. Ein einheitliches Verständnis ist aber die Voraussetzung dafür, dass nicht in jedem Projekt erneut über das Ob und Wie einer Architektur diskutiert werden muss und auf Dauer Architekturkonzepte oder -teile zwischen Projekten ausgetauscht werden können.

In diesem Artikel werden unter Architektur die Dinge verstanden, welche die Struktur eines Systems definieren. Mit Struktur sind dabei nicht nur die statischen Aspekte eines Systems wie z.B. Komponenten, ihre Schnittstellen und Beziehungen untereinander gemeint, sondern auch dynamische Aspekte wie etwa die Kommunikation zwischen den Komponenten. Die Struktur eines Systems ergibt sich aus einer Reihe von sich ergänzenden und überlagernden Teilstrukturen (beispielsweise die physische Komponentenstruktur, die logische Paketstruktur der die Verteilungsstruktur). Sie wird aus einer Reihe von Sichten – d.h. einzelnen Arbeitsprodukten – beschrieben, die zusammen das ausmachen, was wir unter „Architektur“ verstehen (vgl. die ähnliche Definition in [1], [4], [5]). Diese Arbeitsprodukte werden im 4. Abschnitt näher betrachtet und in den Phasenprozess eingeordnet.

Das Ziel einer Architektur ist es sicherzustellen, dass das spätere System die Anforderungen erfüllt (utilitas), robust gegenüber Änderungen ist (firmitas) und eine gewisse „Schönheit“ besitzt (venustas). Diese allgemeine Definition von „Architektur“ in der Encyclopaedia Britannica [7] ist auch für die Softwaretechnik unverändert gültig (zur Robustheit siehe z.B. [13]). Schönheit ist dabei die Schönheit für das trainierte Auge, also in der Softwareentwicklung die Schönheit eines klaren, verständlich strukturierten Systems, dessen Form die Funktionalität kommuniziert (wie z.B. ein klares, modulares System im Gegensatz zu Spaghetti-Code oder die Verwendung sprechender Bezeichnungen). Die Begriffe utilitas, firmitas und venustas fassen die drei wichtigsten Fragen zusammen, der sich eine Architektur täglich stellen muss: Erfüllt sie die Anforderungen? Ist sie robust gegenüber den möglichen Änderungen? Werden die Anwendungsentwickler sie verstehen und darauf aufbauen können?

Eine Architektur bestimmt die Struktur eines Systems auf zwei Ebenen. Einerseits definiert sie Regeln, die bei der Entwicklung des Systems einzuhalten sind. Damit definiert sie die Metaebene der Entwicklung, z.B. durch Programmierrichtlinien oder Muster. Andererseits legt die Architektur das Modell des späteren Systems in einem gewissen Umfang fest und definiert damit die Gegenstandsebene, bei spielsweise durch die Strukturierung des Systems in bestimmte Subsysteme oder durch die Entwicklung von Basiskomponenten wie einem Persistenzframework.

Der Architekt ist in den frühen Projektphasen Designer, wenn er die grundsätzliche Struktur des Systems entwirft, und Berater in den späteren Phasen, wenn die Anwendungsentwicklung die Architekturentscheidungen umsetzen bzw. von der Architektur zur Verfügung gestellten Komponenten nutzt.

Bedeutung der Architektur für die Anwendungsentwicklung

Die Architektur ist die Basis der Anwendungsentwicklung. Sie ist der Schlüssel zur Erfüllung der Anforderungen und zur Sicherstellung von Robustheit und „Schönheit“ des Systems. Die Qualität des Systems steht und fällt mit der Qualität der Architektur. Sie legt die Grundsteine für die Erfüllung oder Nichterfüllung von Qualitätsmerkmalen (bzw. allgemein von nicht-funktionalen Anforderungen), und auf Basis der Architektur kann bereits geprüft werden, ob ein System diese Qualitätsmerkmale erfüllen kann. Obwohl die funktionalen Anforderungen (UseCases) von der Anwendungsentwicklung realisiert werden, legt die Architektur durch die Vorgabe von Entwicklungsregeln und Systemstrukturen auch hier die Basis. Anhand der Architektur kann geprüft werden, ob das System grundsätzlich in der Lage sein wird, die geforderte Funktionalität zu erfüllen.

Die Architektur strukturiert nicht nur das System an sich. Sie macht darüber hinaus Vorgaben, wie diese Struktur erreicht werden soll. Dadurch spiegelt sich die Struktur des Systems zwangsläufig in der Projektorganisation wieder. Beispielsweise sind Komponenten oftmals die Basis für eine arbeitsteilige Entwicklung und die Planung eines inkrementellen Vorgehens. Die Architektur kann also gezielt das Projektmanagement unterstützen. So wird ein System, bei dem die Architektur eine klare Einteilung in Komponenten mit definierten Schnittstellen und ein Schichtenmodell vorsieht, wesentlich einfacher mit mehreren Teams zu entwickeln sein als ein System, bei dem die Architektur keine Vorgaben macht und alle Komponenten „irgendwie“ miteinander in Verbindung stehen können. Umgekehrt sind die organisatorischen Rahmenbedingungen des Projekts ein wesentlicher Einflussfaktor für die Architektur. Eine Architektur für ein unerfahrenes Team wird ganz anders ausfallen als für ein erfahrenes, und im ersten Fall weitaus mehr Schablonen, Basiskomponenten, Entwicklungsregeln etc. zur Verfügung stellen, d.h. die Komplexität der Anwendungsentwicklung so weit wie möglich reduzieren und im Rahmen der Architektur auffangen.

Methode und Architektur strukturieren beide die Anwendungsentwicklung und stehen in einem engen wechselseitigen Verhältnis. Die Methode definiert die grundlegende Struktur eines Projekts. Sie gibt Hilfestellungen für die Festlegung der Arbeitsprodukte, Vorgehensweise und Rollen in einem Projekt. Die Architektur definiert die Struktur des Zielsystems – mit den beschriebenen Rückwirkungen auf die Projektdurchführung. So werden einerseits die Arbeitsprodukte, in denen sich eine Architektur manifestiert, durch die Methode vorgegeben. Andererseits beeinflusst die Architektur die Arbeitsprodukte, Vorgehensweise und Organisation und damit die konkrete Ausgestaltung der Methode im Projekt.

Indem die Architektur die Grundsteine für die Anwendungsentwicklung erstellt, definiert sie zusammen mit der Methode die technische „Sprache“ des Projekts und legt damit eine wichtige Basis für die Kommunikation der Projektbeteiligten. So können z.B. den Anwendern die zentralen Komponenten, neuen Entwicklern die Entwicklungsgrundsätze sowie Projektleitern und Experten im Review die Architekturentscheidungen erläutert werden. Gerade für große Projekte ist die präzise Erfassung komplexer Sachverhalte und ihre Zusammenfassung unter einem „Begriff“ unumgänglich. Nur so kann in einem Team mit unterschiedlichen Erfahrungen und Aufgabengebieten klar, unmissverständlich und effizient kommuniziert werden. Die Entwicklung der „Pattern Languages“ ([10], [11], [12]) ist ein gutes Beispiel für eine solche effiziente Kommunikation (in diesem Fall über ein Projekt hinweg).

Eine Architektur legt die Basis für die gemeinsame Arbeit einer Gruppe von Personen. Mit einer Architektur wird erreicht, dass Projektbeteiligte eine gemeinsame Sprache sprechen, dass bewährte Lösungen nicht wiederholt neu erfunden werden müssen, dass Komponenten gewissen Strukturregeln folgen und sich in ein gemeinsames größeres Ganzes einfügen (Interoperabilität, Integrierbarkeit, Austauschbarkeit). Eine solche gemeinsame Basis kann für ein Projekt, aber auch für eine Produktlinie, ein ganzes Unternehmen oder gar für die Softwareentwicklung allgemein geschaffen werden. Sie ist damit eine wesentliche Basis für Wiederverwendung. Eine Architektur kann selbst in Schichten aufgebaut sein, d.h. die unternehmensweite Softwarearchitektur baut auf grundlegende Architekturen auf, und die Architektur für ein Projekt oder eine Produktlinie wiederum auf die unternehmensweite Softwarearchitektur. So wird z.B. die unternehmensweite Softwarearchitektur auf bewährten Konzepten wie Transaktionsmustern oder Enterprise Java Beans basierend definiert; die Architektur für eine Produktlinie baut darauf auf und definiert die Komponenten und die Struktur von Internet-basierten Anwendungen, und die Architektur für eine konkrete Anwendung definiert den Zugang zu einem speziellen Altsystem (vgl. Abbildung 2).

Zusammen genommen bedeutet dies, dass die Architektur einer der kritischen Erfolgsfaktoren eines Projekts ist. Ihre Fertigstellung ist ein zentraler Meilenstein im Projekt. Auch wenn die Architektur in Abhängigkeit von der Art des Projekts (Komplexität, Einmaligkeit, etc.) unterschiedlich umfangreich sein kann (5% vom Gesamtaufwand bei einer bekannten Architektur, 10% im Mittel, 20% bei besonders komplexen Anforderungen), so darf ihre explizite Erstellung auf keinen Fall ausgelassen werden. Jedes System hat zwangsläufig eine Architektur – wenn sie nicht geplant wird, ergibt sie sich mehr oder weniger unkontrolliert von selbst, und damit ist einer der kritischen Erfolgsfaktoren für das Projekt außer Kontrolle (vgl. [5]).

Das Gebiet der Architektur

Bei der Definition des Begriff der Architektur wurde bewusst die Art des Systems offengelassen. Häufig wird der Begriff der Architektur nur auf das Anwendungssystem bezogen – diese Grenzziehung ist aber in praktischen Projekten zu eng und nicht realistisch. Eine zu erstellende Anwendung wird oftmals die Form der Geschäftsabwicklung, also das Unternehmen in seinen Strukturen verändern. Gerade diese Änderungen sind dabei der Treiber für die Anwendungsentwicklung. Die (Neu-) Definition der Unternehmensabläufe stellt zusammen mit der Entwicklung der sie unterstützenden technischen Basis ein gemeinsames Projekt dar. Wir sprechen daher auch von einer Lösung, die ein Entwicklungsprojekt zu erreichen hat. Schließlich hat das Entwicklungsprojekt als sozio-technisches System eine Struktur, die geplant und aufgebaut werden muss (Projektorganisation, Projektablauf, Projektinfrastruktur).

Eine explizite Betrachtung der drei Bereiche (soziotechnisches Unternehmens- und Entwicklungssystem, technisches Zielsystem) erfordert auch eine explizite Betrachtung von drei unterschiedlichen Architekturen. Wir sprechen daher von der Geschäftsarchitektur des Unternehmens, der Entwicklungsarchitektur des Projekts und der technischen Systemarchitektur des Zielsystems. Abbildung 3 führt einige der Punkte, die in den Rahmen dieser drei Architekturkategorien fallen, exemplarisch auf. Die Systemarchitektur wird in Abschnitt 4 mit ihren konkreten Arbeitsprodukten näher betrachtet.

Die Geschäftsarchitektur definiert und strukturiert das Unternehmen; sie wird bestimmt durch die Unternehmensziele. Die Beschreibung einer solchen Architektur ist wenig definiert und kann in den verschiedenen Unternehmen sehr unterschiedlich sein (für eine Beschreibungsmöglichkeit siehe [15]). Wesentlich ist, dass die Prozesse, die Geschäftsobjekte und die Organisationsstrukturen (incl. Rollen) festgelegt sind, insofern diese als Basis für ein Entwicklungsprojekt dienen sollen. Die Geschäftsarchitektur ist eines der zentralen Arbeitsprodukte, welche in die Anwendungsentwicklung einfließen.

Das Vorliegen einer Geschäftsarchitektur ist die Grundlage dafür, dass eine Vorstellung vom Unternehmen, seinen Abläufen und seinen Zielen existiert und damit klare Vorgaben für eine Anwendungsentwicklung gemacht werden können. Auch formal ist die Geschäftsarchitektur eine wichtige Grundlage für die Erfassung und Strukturierung der Anforderungen. So werden die unternehmerischen Ziele eine Fortentwicklung des Geschäfts in einem Unternehmensbereich notwendig machen. Infolgedessen wird die Geschäftsarchitektur in dem Unternehmensbereich neu definiert. Die Durchführung der Geschäftsprozesse soll dann durch Informationstechnologie unterstützt werden, d.h. einzelne Bereiche der Geschäftsprozesse werden durch EDV-Systeme unterstützt. Diese Ausschnitte der Geschäftsprozesse sind der Kern der UseCases, d.h. der funktionalen Anforderungen. Die im Rahmen dieser Prozesse genutzten Ressourcen, erfasst im Geschäftsobjektmodell, stellen die Basis der Objekte (bzw. der Entitäten) dar, die innerhalb der UseCases verarbeitet werden (für eine ausführliche Darstellung des Zusammenhangs zwischen Geschäftsprozessen und den Use Cases siehe [9]). Das Vorliegen einer Geschäftsarchitektur ist mithin kritisch für ein Projekt, da sie die unternehmerischen Ziele vorgibt, die das Projekt begründen, und die Grundlage für ein Verständnis der Anforderungen an das System ist.

Die Entwicklungsarchitektur definiert die Struktur des Entwicklungsprojekts, das die Lösung bereitstellt. Hierzu gehören u.a. die Definition und der Aufbau der Projektorganisation (Projektaufbau, Rollen und Personen), des Projektablaufs (Vorgehensweise/Methodik und detaillierte Projektablaufplanung) und der Arbeitsprodukte des Projekts, die schließlich in das installierte Zielsystem münden. Die Definition dieser Dinge gehört typischerweise zum Projektmanagement, aber häufig delegiert der Projektleiter die Definition der Projektprozesse, -organisation und -ressourcen an eine speziell hierfür zuständige Person (oder ein Team). Die Ähnlichkeit mit der Geschäftsarchitektur ist nicht zufällig, und gerade große Projekte sind ein kleines Unternehmen in sich. Die Arbeit des Projekts wird durch Projektsysteme unterstützt (Versionierung) bzw. möglich gemacht (Entwicklungsumgebung). Sind diese das Projekt unterstützenden Hard- und Softwarestrukturen aufwendig, so sollten sie durch eine eigene (vom Zielsystem getrennte) Systemarchitektur definiert werden.

Beschreibung einer Systemarchitektur – Arbeitsprodukte im Phasenprozess

Die beiden zentralen Bereiche der Systemarchitektur sind die Definition der softwaretechnischen Architektur und der Infrastrukturarchitektur als Teile der Systemarchitektur.

Die Infrastrukturarchitektur erfasst die holistische, operationale Sicht auf das System. Hierzu zählen unter anderem das technische System (mit Hardware, Plattformen, Lokationen, Verbindungen), die Platzierung der Softwarekomponenten in Rahmen des technischen Systems, die Konfiguration und das Management des Systems (Kapazitätsplanung, Softwareverteilung, Datensicherung und Wiederanlauf).

Die softwaretechnische Architektur erfasst die Softwarekomponenten, die auf den Hardwarekomponenten ausgeführt werden, d.h. die funktionale Sicht auf das System. Hierzu gehören unter anderem die Struktur und Aufteilung der Softwarekomponenten, die Schnittstellen der Komponenten, die Beziehungen zwischen den Komponenten und die Zusammenarbeit der Komponenten miteinander.

Abbildung 4 stellt die Arbeitsprodukte im Überblick dar, die in den Bereich der Systemarchitektur fallen. Arbeitsprodukte definieren die fassbaren (Teil-) Ergebnisse, d.h.„was“ für eine Architektur getan werden muss - unabhängig vom zeitlichen „wann“ (zur Bedeutung von Arbeitsprodukten siehe [14]). Die Auswahl dieser Arbeitsprodukte zur Definition einer Architektur beruht auf den praktischen Erfahrungen, die in vielen Projekten gemacht wurden und die sich in mehreren Schritten herauskristallisiert haben (siehe z.B. die Entwicklungsmethoden der IBM in [6], [8], [14]). Im Folgenden werden die wichtigsten Pakete von Arbeitsprodukten dargestellt, und anschließend wird jedes einzelne Arbeitsprodukt näher erläutert.

Das in der Abbildung 4 mit „Systemarchitektur (Gegenstandsebene)“ bezeichnete Paket enthält die Elemente der Systemarchitektur, welche die Gegenstandsebene betreffen (zur Gegenstandsebene siehe Abbildung 1). Im Wesentlichen sind dies das Komponentenmodell (component model) der Softwaretechnischen Architektur und das Operationale Modell (operational model) der Infrastrukturarchitektur. Zum Komponentenmodell gehören auch Architekturkomponenten, die der Anwendungsentwicklung zur Verfügung gestellt werden – z.B. gekaufte Komponenten oder von der Architekturgruppe entwickelte (Framework-)Komponenten. Die Architekturskizze (architecture overview diagram) entspricht dem mit „Systemarchitektur (Gegenstandsebene)“ bezeichneten Paket in einem frühen Stadium.

Architekturmuster (architectural templates) stellen Anleitungen auf der Metaebene dar; sie bilden zusammen mit dem inneren Paket „Systemarchitektur (Gegenstandsebene)“ die Systemarchitektur.

Eine solche Systemarchitektur muss insgesamt die Anforderungen erfüllen, die durch eine Reihe von Arbeitsprodukten im Paket „Anforderungen“ festgehalten werden. Bei der Definition einer Architektur ist es sinnvoll, auf bewährte Konzepte zurückzugreifen – die gezielte Auswahl von Referenzarchitekturen ist daher ein eigenes Arbeitsprodukt (reference architecture fit/gap analysis).

Schließlich muss eine Architektur überprüft werden. Einzelne Fragestellungen können ggf. durch Prototypen beantwortet werden. Darüber hinaus ist aber eine Überprüfung der Architektur hinsichtlich der qualitativen Anforderungen notwendig (service level characteristic analysis), wie auch gegenüber den Anforderungen insgesamt (viability assessment).

Eine Architektur muss aufgrund ihrer Komplexität iterativ entwickelt werden. Während der Definitionsphase des Projekts sollte ein konzeptioneller Zwischenstand erreicht werden, der auf einem relativ hohen und abstrakten Niveau die Architektur skizziert. Zum Ende des Projekts hin muss eine Architektur bis hinunter auf die physische Ebene exakt definiert sein (sie darf nicht auf einem „high-level“-Niveau stehenbleiben). Dazwischen gibt es eine Reihe von Zwischenständen, die projektspezifisch zu definieren sind. Auf jeden Fall muss vor Beginn der Anwendungsentwicklung die Architektur so weit definiert und gesichert sein, dass sie im wesentlichen eine „Black Box“ gegenüber der Anwendungsentwicklung darstellt. Änderungen innerhalb der Architektur dürfen dann nicht mehr maßgeblich auf die Anwendungsentwicklung durchschlagen (was nicht bedeutet, dass Fehler in der Architektur nicht mehr behoben werden sollten).

Eine iterative Entwicklung kann nur dann zielorientiert und kontrolliert erfolgen, wenn die zu erreichenden Zwischenstufen vorher festgelegt werden (z.B. durch einen grundsätzlichen Plan zu Anfang des Projekts und detaillierte Vorgaben jeweils zu Beginn einer Phase). Bei der Architektur wird die Verfeinerung dabei nicht durch das schrittweise Erstellen einzelner Arbeitsprodukte erreicht, sondern durch die schrittweise Detaillierung ganzer Pakete in unterschiedlichen Projektphasen. Diese Beoachtung – die nicht nur für die Architektur gilt – ist besonders deshalb von einer hohen Bedeutung, da in vielen Projekten insbesondere hier Fehler gemacht werden: so wird z.B. in der Evaluierungsphase nicht auf die Architektur eingegangen, und dann wird die komplette Architektur in einem großen Wurf implementiert.

Softwaretechnische Architektur

Die softwaretechnische Architektur, die den funktionalen Aspekt erfasst, gliedert das System in Komponenten. Dies sind funktionale Einheiten, die eine Schnittstelle, ein Verhalten und einen internen Zustand haben. Komponenten können miteinander in Beziehung stehen; solche Beziehungen sind die Nutzung oder Spezialisierung anderer Komponenten. Komponenten können wiederum andere Komponenten enthalten. Diese Definition lehnt sich an die Definition eines Objekts an, und Objekte sind die Blätter einer solchen Komponentenstruktur. Damit können zur Beschreibung der softwaretechnischen Architektur in Form eines Komponentenmodell (component model) die bekannten Diagramme der UML verwendet werden (Klassendiagramm und Kollaborations- bzw. Interaktionsdiagramme – siehe Abbildung 5 und Abbildung 6). Der Vorteil dieser Definition liegt darin, dass Komponenten eine klare Semantik haben und dass bestehende Notationen zur Darstellung eines Komponentenmodells verwendet werden können.

Die obige Definition ermöglicht es, Komponenten auf unterschiedlichen Abstraktionsebenen zu handhaben (Abbildung 5). Jede Abstraktionsebene ist für sich lesbar und verbirgt die darunter liegenden Details. So kennt z.B. das Modell auf der Entwurfsebene Geschäftsobjekte, die als Klassen modelliert werden. Auf der Implementierungsebene wird die Funktionalität eines solchen Geschäftsobjekts dann durch eine Menge von Klassen, d.h. durch eine Komponente realisiert. Dadurch besitzen die Modelle einerseits einen sinnvollen Abstraktionsgrad und bleiben aussagefähig, indem sie nicht durch (immer wiederkehrende) Implementierungsdetails überfrachtet werden. Andererseits existiert eine klare Umsetzung des Modells auf eine Implementierung, und die Modelle haben eine klare Bedeutung. Insbesondere bei großen Projekten bzw. bei umfangreichen Systemen ist die durchgängige Erstellung eines Modells auf der Implementierungsebene zu umfangreich, zu detailliert und nicht lesbar. Ohne die Nutzung des obigen Komponentenkonzepts und der Verwendung von unterschiedlichen Abstraktionsebenen in der Modellierung besteht die Gefahr, dass entweder die Modelle zu detailliert und umfangreich sind (wenn jede Klasse im Modell mit einer Klasse im Code korrespondiert) oder dass die Modelle keinen Bezug zur Implementierung haben und damit eine rein akademische Übung bleiben.

Eine solche Umsetzung von Objekten der Modellierungsebene auf Komponenten der Implementierungsebene setzt voraus, dass klare Umsetzungsregeln definiert sind. Die Definition solcher Umsetzungsund Modellierungsregeln ist eine Aufgabe der Architektur. Die Regeln werden in der Form von Architekturschablonen bzw. Architekturmustern (architectural templates) formuliert. Sie stellen Anleitungen für den Anwendungsentwickler dar, wie die bestimmte Aspekte zu lösen bzw. zu implementieren sind (Metaebene, vgl. Abbildung 1). Zusätzlich zu dem Architekturmustern müssen ggf. technische Basiskomponenten bzw. Frameworks (z.B. solche für die Persistenz oder Verteilung), auf denen die Umsetzung beruht und deren Schnittstellen von den Anwendungskomponenten genutzt werden, definiert und implementiert werden (Gegenstandsebene). Abbildung 7 stellt dies ausschnittsweise dar. Die Umsetzung der Architekturmuster kann ggf. durch Werkzeuge unterstützt werden (Prüfung auf Einhaltung der Regeln, automatische Umsetzung der Objekte der höheren Abstraktionsebene auf Objekte der Implementierungsebene). Diese Werkzeuge müssen dann im Rahmen der Architekturarbeit erstellt bzw. gekauft werden.

Infrastrukturarchitektur

Das Operationale Modell (operational model) bildet den Kern der Infrastrukturarchitektur. Zum Operationalen Modell gehören Diagramme, welche die Topologie und geographische Verteilung des Systems darstellen (siehe Abbildung 8). Außerdem werden die Knoten, Netzwerkverbindungen und Anwender des Systems spezifiziert, indem die Funktionalität (und später die Services) des Knotens beschrieben werden (z.B. in Form einer Tabelle). Später wird das Operationale Modell um eine Festlegung konkreter (Middleware-)Produkte erweitert, und bei den Netzverbindungen sind die entsprechenden Protokolle anzugeben. Zusätzlich kann die Vollständigkeit des Operationalen Modells durch Szenarien (Walkthroughs) überprüft werden. Solche Szenarien (in Textform oder als Interaktionsdiagramm) zeigen den Fluss einer Aktion eines UseCases vom Anwender durch das System zum Anwender zurück.

Indem die Komponenten auf den Knoten des Operationalen Modells platziert werden, wird die Verbindung zwischen dem Komponentenmodell und dem Operationalen Modell hergestellt. Die auf einem Knoten platzierten Komponenten erfüllen dann mit ihren Leistungen die Services, wie sie im operationalen Modell definiert wurden. Die Angabe, welche Komponenten auf welchen Knoten liegen, erfolgt im operationalen Modell. Komponentenpakete (deployment units) gruppieren dabei die Komponenten, die zusammen ausgeliefert und auf einem Knoten platziert werden.

Das Operationale Modell wird durch einen Plan zur Softwareverteilung (software distribution plan) ergänzt. Dieser beschreibt, wie die Deployment Units auf die Knoten verteilt werden. Mit dem Operationalen Modell eng verbunden ist der Plan zum System Management. Er stellt dar, welche Knoten verwaltet werden müssen und durch welche Prinzipien, Prozesse, Werkzeuge und Rollen dies bewerkstelligt wird.

Überprüfung der Architektur

Da die Architektur eine zentrale Rolle spielt, sollte in mehreren Schritten überprüft werden, ob sie die Anforderungen erfüllen kann. Während der Architekturentwicklung können Prototypen (technical prototypes) genutzt werden, um einzelne technische Aspekte zu überprüfen, bevor eine Architekturentscheidung getroffen wird. Später muss gezielt kontrolliert werden, ob die in den nicht-funktionalen Anforderungen festgelegten Qualitätsanforderungen durch eine Anwendung auf Basis der konzipierten Architektur erreicht werden können (service level characteristic analysis). Schließlich ist zum Ende hin die Tragfähigkeit der ganzen Architektur bezüglich der gesamten Anforderungen zu überprüfen (viability assessment). Neben statischen Überprüfungen wie z.B. Reviews kommen hierfür wiederum Prototypen in Frage. Durch eine prototypische Implementierung einer Anwendungskomponente (oder bei größeren Systemen durch eine Anwendung) können sowohl einzelne Qualitätsmerkmale (Durchsatz) als auch die Tragfähigkeit des gesamten Architekturkonzepts überprüft werden (vgl. [3], [4]).

Eingehende Arbeitsprodukte

Neben den funktionalen und nicht-funktionalen Anforderungen (use Eingehende Anforderungen cases, usability requirements, nonfunctional requirements) sowie der Definition der Systemgrenze (system context) stellen insbesondere die derzeitige Infrastruktur (current IT environment) und die im Unternehmen geltenden Standards (current IT standards) wichtige Anforderungen dar, die im Rahmen der Architektur berücksicht werden müssen. Standards und aktuelle Infrastruktur sind oftmals bereits beschrieben, so dass diese Arbeitsprodukte nicht im Projekt erstellt, wohl aber als Anforderungen betrachtet werden müssen.

Obwohl mögliche zukünftige Änderungen, die explizit nicht Gegenstand des aktuellen Projektauftrags sind, ihrer Definition nach keine Anforderungen darstellen, sollten diese potentiellen Änderungen dennoch festgehalten werden (change cases). Bei der Entwicklung der Architektur sind häufig Entscheidungen zu treffen, die vom Implementierungsaufwand bzw. von den Kosten her identisch sind. In solchen Fällen kann die Kenntnis solcher möglichen zukünftigen Änderungen als Entscheidungshilfe dienen.

Eine Referenzarchitektur ist ein Muster für eine Architektur und umfasst die funktionalen wie operationalen Aspekte einer Architektur für eine bestimmte Klasse von Anwendungen. Konkrete Ausprägungen der Referenzarchitektur sind in einer Reihe von Projekten erfolgreich eingesetzt worden. Die Referenzarchitektur ist dann als eine generische Zusammenfassung der projektspezifischen Lösungen entstanden. Eine solche Referenzarchitektur (beispielsweise für e-Shop-Anwendungen) besitzt einen hohen Wert für ein Projekt: sie ist ein Muster für eine gesamte Architektur und nicht nur für einen bestimmten isolierten Aspekt; die Architektur hat sich in konkreten Projekten bewährt, und das Zusammenspiel unterschiedlicher Einflussfaktoren auf die Architektur (architecture tradeoff analysis) wurde bereits in der Praxis erprobt. Solche Informationen können sonst nur über aufwendige Prototypen oder Simulationen gewonnen werden. Die explizite Suche nach Referenzarchitekturen und deren Evaluierung (reference architecture fit/gap analysis) sollte daher am Anfang einer Architekturentwicklung stehen.

Dokumentation von Architekturentscheidungen

Häufig vernachlässigt aber wichtig ist die Dokumentation zentraler Architekturentscheidungen (architectural decisions). Dies kann eine Datenbank oder ein Textdokument sein, in dem Entscheidungen und Prinzipien in Form eines Formulars abgelegt werden (für jede Entscheidung werden u.a. Problem, Entscheidung, Alternativen mit ihren Konsequenzen und Entscheidungshintergründe erfasst). Dieses Dokument ist nicht nur für die Dokumentation der Entscheidungen wichtig, sondern es hilft auch, die Architektur später zu verstehen und zu vertreten. Es stellt den Leitfaden für das Architekturteam und im Folgenden (zumindest ausschnittsweise) auch für die Anwendungsentwickler dar. Nicht zuletzt kann dadurch vermieden werden, dass schon adressierte Probleme immer wieder diskutiert werden. Wichtig ist es jedoch, nicht einfach alle, sondern die wenigen zentralen (Grundsatz-)Entscheidungen zu dokumentieren.

Einordnung der Architektur in den Phasenprozess

Im Folgenden wird von einem iterativen und inkrementellen Entwicklungsprozess mit 5 Phasen ausgegangen (vgl. Abbildung 9). Diese Phasen beziehen sich auf ein Anwendungsentwicklungsprojekt und entstammen der IBM Global Services Method [6]. Sie stellen eine Möglichkeit dar, den Prozess für die Entwicklung einer größeren Anwendung zu gliedern. Diese Aufteilung soll hier als Grundlage dafür dienen, die Rolle der Architektur über die Projektlaufzeit hinweg zu erläutern. Jede Ausprägung der Phasen dauert 1-2 Monate und schließt mit einem Meilenstein ab.

Aufgabe der ersten Phase (Solution Outline) ist es, die Ziele, Anforderungen, Struktur und Komplexität des Projekts sicher zu erfassen, um eine fundierte Investitionsentscheidung über die Projektdurchführung treffen zu können. In der ersten Phase werden der Rahmen des Projekts und dessen wesentliche Strukturen festgelegt. Hierzu zählen die Festlegung der Projektstrukturen und der Vorgehensweise, die Aufnahme der Anforderungen sowie eine erste Skizze des Anwendungsmodells und der Architektur. Relativ häufig wird ein Werkvertrag für das gesamte Projekt erst nach dieser Phase abgeschlossen.

In der zweiten Phase (Macro Design) werden die Anforderungen im Detail erfasst (z.B. System-Anwender-Interaktionstabellen für die Use-Cases), das Modell der Anwendung wird in einem großen Rahmen spezifiziert, d.h. globale Designentscheidungen werden getroffen und die Releases des Systems definiert. In dieser Phase liegt der Schwerpunkt der Architekturdefinition, da die Architektur die Struktur des Systems definiert und die Anwendungsentwicklung mit den Release Cycles auf die Architektur aufsetzt. Insgesamt muss die Architektur dem Projekt eine releaseübergreifende Basis geben. Das Komponentenmodell ist hierbei nicht nur für die Planung der Releases von entscheidender Bedeutung, sondern auch für die Planung der gesamten Entwicklung einschließlich der Teamstruktur. Die Entkopplung der Komponenten ist einer der maßgeblichen Faktoren für den Grad der arbeitsteiligen Entwicklung und deren Effizienz.

Der Release Cycle umfasst die drei Phasen Micro Design, Build und Deployment, die das Vorgehen innerhalb eines Releases unterteilen (und jeweils pro Release durchgeführt werden). Ein Release ist dadurch gekennzeichnet, dass es mit einem installierten und in Produktion gegangenen (Teil-)System endet. Innerhalb eines Releases werden im Wesentlichen nur die Komponenten betrachtet, die durch das Release betroffen sind bzw. in diesem erstellt und ausgeliefert werden.

In der dritten Phase (Micro Design) wird das Feindesign für die Komponenten des jeweiligen Releases erstellt. Ggf. kann hierbei noch ein Teil der Architekturarbeit abgeschlossen werden, z.B. die Implementierung von Frameworks. Die Festlegung der Architektur muss aber spätestens mit dieser Phase so abgeschlossen sein, dass sich keine wesentlichen Änderungen für die Anwendungsentwicklung mehr ergeben. Möglich ist jedoch noch eine Ergänzung und Erweiterung der Architektur, sofern sie durch die Architekturkonzepte gekapselt ist und nicht mehr auf die Anwendungsentwicklung durchschlägt. In späteren Releasezyklen können in dieser Phase releasespezifische Ergänzungen sowie Verfeinerungen und Verbesserungen an der Architektur durchgeführt werden. Diese dürfen aber keine grundlegenden Änderungen oder gar ein Re-Design der Anwendungskomponenten zur Folge haben.

Die vierte Phase (Build) wird iterativ, d.h. mehrfach für ein Release durchgeführt und umfasst das Detaildesign und die Implementierung der Komponenten sowie die Erstellung der Dokumentation – am Ende der Build-Zyklen steht das auszulieferende Produkt. In dieser Phase setzt die Anwendungsentwicklung auf die Architektur auf, und letztere muss jetzt abgeschlossen sein. Der Architekt fungiert in dieser Phase nicht mehr als Designer des Systems, sondern als Berater für die Anwendungsentwicklung.

Die letzte Phase (Deployment) hat die primäre Aufgabe, das erstellte Produkt auszuliefern. Daneben werden aber auch die Erfahrungen des Releases zusammengestellt, um ggf. die Planung des nächsten Releases zu korrigieren. Die Arbeit in dieser Phase baut insbesondere auf dem operationalen Teil der Architektur auf (wichtige Arbeitsprodukte sind hier die auszuliefernden Komponentenpakete, der System Management Plan und der Softwareverteilungs-Plan).

Die obigen Phasen sind ein mögliches Muster, um die Anwendungsentwicklung in mehrere Phasen zu unterteilen. Es muss auf die spezifischen Anforderungen eines jeden Projekts angepasst werden. So kann es sein, dass bei großen Entwicklungsprojekten die Architektur nicht in einem Zeitraum von 2 Monaten erstellt werden kann. In diesem Fall kann z.B. die Architektur (zusammen mit einer ausgewählten Funktionalität zur Verifizierung) als Ergebnis eines ersten Releases entwickelt werden.

Unabhängig von der geplanten Vorgehensweise müssen natürlich immer – unter Abwägung von Kosten und Nutzen – Fehler behoben werden. Dies können zum einen weniger schwerwiegende Fehler sein, die sicherlich im ersten Release häufiger auftreten. Solche Fehler werden dann sofort im Rahmen der normalen projektbegleitenden Fehlerbehebung gelöst. Wenn sich eine Architektur darüber hinaus – trotz einer sorgfältigen Risikoabwägung, eines schrittweisen Vorgehens und einer wiederholten Überprüfung der Architektur (vgl. Abschnitt 4.3) – als nicht tragfähig erweist, ist in diesem Fall als Konsequenz das Projekt neu zu planen. Ein solcher Fall sollte jedoch bei einer sorgfältigen Projektplanung und -steuerung nicht auftreten. Die obigen Arbeitsprodukte, eine schrittweise Vorgehensweise und ein gutes Verständnis für die Architektur können dieses Risiko auf ein Minimum begrenzen helfen.

Fazit

Eine Architektur bestimmt die Struktur eines Systems. Die explizite Definition einer Architektur ist unerlässlich, um die Systemstruktur nicht dem Zufall zu überlassen, sondern um sie gezielt zu gestalten. Aufgabe einer Architektur ist es, die Grundlagen für ein System (bzw. für eine unternehmensweite Systemfamilie) so zu legen, dass es die Anforderungen erfüllt, robust gegenüber Änderungen und verständlich ist. Die in diesem Artikel vorgestellten Arbeitsprodukte sind geeignet, eine Systemarchitektur umfassend bis hinunter auf Detailebene zu definieren. Diese Arbeitsprodukte werden von Architekten erstellt und müssen von den Anwendungsentwicklern als Nutzer der Architektur verstanden werden. Für ein konkretes Projekt ist es meist nicht erforderlich, alle vorgestellten Arbeitsprodukte als jeweils einzelne Dokumente zu erstellen, aber das Komponentenmodell, das Operationale Modell und die Architekturmuster sollten auf keinen Fall fehlen.

Praktische Hinweise

• Die explizite Erstellung und Berücksichtigung einer Architektur ist essentiell für ein Projekt.
• Die Rolle des Architekten darf nicht als Titel gesehen werden. Projektleiter und Chef-Architekt stellen die beiden wichtigsten Führungspersonen im Projekt; ihre Positionen sollten entsprechend qualifiziert besetzt werden.
• Die Architektur muss vor dem Beginn der eigentlichen Entwicklung fertiggestellt sein, d.h. die Arbeit des Architekten als Designer muss weitgehend abgeschlossen sein (Verbesserung und „Wartung“ der Architektur ist natürlich eine projektbegleitende Aufgabe).
• Die Architektur ist in klar definierten Arbeitsprodukten zu dokumentieren; nur dann kann sie als Referenz dienen, Hilfestellungen und Anleitungen bieten sowie generell dem Projekt Richtung, Struktur und „Sprache“ geben.
• Die Architektur darf kein „High-Level“ Diagramm sein. Sie muss die unterschiedlichen Punkte, wie sie in diesem Artikel dargestellt wurden, klar berücksichtigen. Sie hat u.a. Komponenten und ihre Schnittstellen zu definieren und zentrale Probleme (Persistenz, Verteilung) zu lösen.
• Ausgangspunkt und Treiber jeder Architektur sind die Anforderungen. Aufgabe der Architektur ist es, ein System so zu strukturieren, dass es die Anforderungen erfüllen kann.
• Die Architektur soll Architekturmuster und Architekturtypen, d.h. allgemein anerkannte Architekturgrundlagen und ggf. unternehmensweite Architekturentscheidungen, nutzen. Allgemein bedeutet dies, dass die Architektur Motor der Wiederverwendung bewährter Konzepte und Komponenten ist.
• Die Architektur muss eine solche Teilbarkeit der Systemstruktur sicherstellen, dass die unterschiedlichen Aspekte getrennt voneinander betrachtet werden können (separation of concern). Dies ist insbesondere eine Voraussetzung für das Management großer Projekte. So sollten z.B. Repräsentation, Technik und fachliche Logik voneinander getrennt sein - vgl. hierzu die RTA-Gliederung in [13].
• Bei der Erstellung der Systemarchitektur sollte deren Einbettung in das Gesamtumfeld (Geschäfts- und Entwicklungsarchitektur) berücksichtigt werden. So muss innerhalb des Projekts das Wechselspiel von Systemarchitektur und Entwicklungsarchitektur sowie der Zusammenhang zwischen der Entwicklung der neuen Lösung mit der Geschäftsarchitektur bewusst gehandhabt werden. So sollte bei der Erstellung der Systemarchitektur auch die Qualifikation der Unternehmensmitarbeiter berücksichtigt werden, die das System warten oder bedienen müssen.

Referenzen

1. L. Bass, R. Kazman: Architecture-Based Development, Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI- 99-TR-007/ESC-TR-99-007, Pittsburgh, 1999
2. R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson, J. Carriere: The Architecture Tradeoff Analysis Method, Software Engineering Institute, Technical Report CMU/SEI-98-TR-008/ESC TR-98-007, Pittsburgh, 1998
3. M. R. Barbacci et. al: Steps in an Architecture Tradeoff Analysis Method: Quality Attribute Models and Analysis, Software Engineering Institute, Technical Report CMU/SEI-97-TR-029/ESC-TR-97-029, Pittsburgh, 1998
4. L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, Addisson-Wesley Publishing Company, Reading, 1998
5. P. C. Clements, L. M. Northrop: Software Architecture: An Executive Overview, Carnegie Mellon University, Software Engineering Institute, Technical Report CMU/SEI-96-TR-003/ESC TR-96-003, Pittsburgh, 1999
6. IBM (Hrsg.): IBM Global Services Method 3.0, Familie von Vorgehensweisen für Serviceprojekte, IBM internes Dokument, Dokument-Nummer ZZ81-0045-00, 2000
7. Encyclopaedia Britannica Inc. (Hrsg.): The New Encyclopaedia Britannica, Macropaedia, Volume1, Stichwort Architecture, Seiten: 1088-1115, Encyclopaedia Britannica Inc, Chicago, 1978
8. R. Youngs, D. Redmond-Pyle, P. Spaas, and E. Kahan: A standard for architecture description, IBM Systems Journal, Vol. 38, No. 1, Seiten 32ff, IBM, 1999
9. J. Herzog, T. Gorchs: Geschäftsprozessintegration in IT Systeme, OOP München, 2000
10. J. Coplien, J. Vlissides, R. Martin, N. Harrison: Pattern Languages of Program Design, Volumne 1-4, Addison-Wesley, Reading, 1995-2000
11. Gamma et. al: Design Patterns, Addison-Wesley, Reading, 1996
12. F. Buschmann: Pattern Oriented Software Architecture, Wiley & Sons, Chichester, 1996
13. J. Siedersleben, E. Denert: Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur, Informatik Spektrum, Band 23, Seiten 247ff, Springer Verlag, Heidelberg, 2000
14. IBM, Developing Object Oriented Software, An Experience-Based Approach, Prentice Hall, Upper Saddle River, 1997
15. D. W. McDavid: A standard for business architecture description, IBM Systems Journal, Vol. 38, No. 1, Seiten 12ff, IBM, 1999

---