Mit dem Begriff der Architektur verbinden wir zunächst bemerkenswerte Gebäude wie das Taj Mahal oder den Petersdom. Auch assoziieren wir den Begriff Architektur mit dem Städtebau und der Stadtentwicklung, wie sie z.B. in Tokio und New York praktiziert wird. Wir sind fasziniert von der Leistung der Architekten derart komplexe Strukturen zu ersinnen und zu verstehen. Begeistert davon, wie Architekten es vermögen diese Werke perfekt in ihre Umgebung zu integrieren und in kleine Bestandteile für die Umsetzung aufzuteilen. Wir sind erstaunt von der Voraussicht der Architekten diese Werke in Form einer evolutionären oder iterativen Entwicklung teils über Jahrzehnte oder Jahrhunderte hinweg zu planen und zu erstellen. Ebenfalls bewundern wir die Fähigkeit der Architekten Gebäude und Städte für den Wandel der Zeit vorzubereiten, sodass diese Werke für nachfolgende Generationen erhalten bleiben.
Diese Herausforderungen lassen sich ebenfalls auf die Softwarearchitektur und das Softwaredesign übertragen. Dabei sind die relevanten Themen der Architektur1) auch in diesem Bereich relevant:
Raum:
Die Definition, Dimensionierung, Disposition, Fügung und formale Gestaltung von Räumen ist die wichtigste Aufgabe der Architektur.
Das Analogon zum Raum auf Seite der Softwarearchitektur ist die Komponente. Somit ist die Definition, Dimensionierung, Verteilung und Komposition von Komponenten sowie die Ausarbeitung von Mustern und Vorgaben die zentrale Aufgabe der Softwarearchitektur. Hierbei spielen insbesondere die Erfahrungen und das Wissen des Architekten eine große Rolle, welche er in die genannten Aspekte einfließen lassen kann.
Positionierung und Orientierung:
Die Positionierung eines Bauwerks in der Landschaft beziehungsweise auf der zur Verfügung stehenden Fläche (Grundstück) und seine Orientierung geben den Ausschlag über das Erscheinungsbild des Bauwerks, den Grad der Privatsphäre gegenüber dem öffentlichen Raum, die Erschließung, das Verhältnis von Außenraum und Innenraum und mögliche solare Wärmegewinne.
Die Positionierung und Orientierung im Sinne der Softwarearchitektur und des Softwaredesigns entspricht der Kontextabgrenzung und Zielsetzung hinsichtlich des betrachteten Systems. So wird in diesem Zusammenhang geklärt, wie sich eine Komponente oder ein System in die Systemlandschaft integrieren und an welcher Stelle das System entstehen soll. Es wird untersucht, welche anderen Systeme in Beziehung zum betrachteten System stehen: Nachbarsysteme, Vor- und Nachsysteme, Konkurrenz- oder Parallelsysteme. Dabei wird unter anderem auch geklärt, ob das System für die Umgebung offen oder abgeschlossen gestaltet werden soll.
Form:
Die Gestalt des Gebäudes, also sein Grundriss, seine Form und Kubatur, seine Proportion, das alles sind ästhetische Aspekte, die sich nicht allein von der Funktion ableiten lassen. Ein Entwurf lässt sich nicht anhand aller Randparameter „generieren“. Dazu kommt immer die Komponente der ästhetischen und formalen Gestaltung.
Die "Form" in der Softwarearchitektur und im Softwaredesign befasst sich ebenfalls mit den grundlegenden Aspekten von Komponenten und Systemen. Hier werden Entscheidungen hinsichtlich der Grundstruktur, des generellen Lösungsansatzes getroffen - soll eine Webapplikation mit einer vollständigen 3-Schicht-Architektur, ein Fat-, Smart- oder Thin-Client zu Grunde gelegt werden. Wie auch in der realen Architektur spielen hierbei weniger die funktionalen als die ästhetischen Aspekte, Randbedinungen, Qualitätsanforderungen und Architekturvorgaben eine Rolle.
Funktion:
Das gute Funktionieren eines Gebäudes ist oberstes Ziel eines Entwurfes. Das betrifft sowohl die Funktionsabläufe, das technische Funktionieren der Gebäudehülle als auch ästhetische und nicht-technische Funktionen, die ein Bauwerk zu erfüllen hat. Da Architektur eine der wenigen praktischen Künste ist (siehe auch Design), die neben dem ästhetischen Wert auch einen Gebrauchswert haben, steht sie immer im Spannungsfeld von Kunst und Funktion.
Auch in der Softwarearchitektur und im Softwaredesign gilt die Grundregel "Form follows Function" - also dass das primäre Ziel die adäquate und effiziente Umsetzung der Funktionalität ist. Ähnlich wie in der Architektur von Gebäuden, entsteht allerdings auch in der Softwarearchitektur und im Softwaredesign ein Spannungsfeld zwischen dem ästhetischen Anspruch ein "schönes" System (im Sinne von Wartbarkeit, Erweiterbarkeit, Stabilität, Performanz, Fehlertoleranz etc.) zu entwerfen und dem Anspruch die Funktionalität mit möglichst wenig Aufwand abzubilden. In diesem Kontext ist der Architekt gefragt einen Mittelweg zu finden, um beide Punkte sinnvoll in einem System zu vereinen.
Konstruktion:
Um die gewünschten Räume zu erzeugen, ist die Wahl der richtigen Baukonstruktion entscheidend. Dabei müssen zum Beispiel auch Kosten- und Terminfaktoren bedacht sowie Komfortstandards erreicht werden. Die Skelettbauweise ermöglicht zum Beispiel einen freien Grundriss, für einen Apartmentblock ist unter Umständen die Raumzellenbauweise die beste Lösung. Der Rahmen der Möglichkeiten erweitert sich dabei kontinuierlich, man vergleiche einmal eine romanische Kirche mit der Leipziger Messe.
Die Konstruktion (i.S.d. Gebäudearchitektur) ist auch in der Softwarearchitektur ein wichtiger Aspekt, der zu definieren, abzustimmen und zu klären ist. Dabei ist die grundlegende Frage welche Technik, welche Methodik oder welche Herangehensweise die Umsetzung einer Komponente oder eines Systems bestmöglich unterstützen kann. Hierunter fallen unter anderem die Auswahl einer geeigneten Entwicklungsumgebung, eines passenden Build- und Deploymentprozesses sowie die Verwendung bestehender Frameworks und Komponenten, um Budgetvorgaben und Termine durch die Minimierung von Aufwänden, Risiken und Einarbeitungszeiten einhalten zu können. In diesem Kontext darf das Gesetz von Conway nicht vernachlässigt werden, wonach sich Organisationsstrukturen (z.B. Fähigkeiten von Entwicklern) sich auf die Art und Weise der Softwareentwicklung auswirken.
Fassade:
Wie sollen die Fassaden, also die äußere Hülle eines Gebäudes aussehen? Welche Farben und Materialien werden verwendet? Das alles liegt im Ermessensspielraum der Gestalter (und damit sowohl des Architekten, aber auch des Bauherren).
Die Thematik der Fassade - also der Außenansicht des Systems - ist oft ein stark diskutierter Aspekt eines Systems. Hierbei geht es vorallem um die Gestaltung der Schnittstelle(n) des Systems zu den Nutzern. Hier können - wie in der klassischen Architektur - Fragestellungen zu Farbe, Form, Darstellung und Struktur aufkommen und ggf. hitzig und emotional diskutiert werden. Über Scribbles und Layoutdefinitionen werden im Rahmen der Softwarearchitektur und des Softwaredesigns diese Fragestellungen oft geklärt und deren Lösung beschrieben.
Lesbarkeit:
Darunter versteht man, inwieweit an der äußeren Erscheinung eines Bauwerks zu erkennen ist, „was in ihm steckt“, also zum Beispiel, welche Funktion es hat, welche Konstruktion, welche innere Gliederung oder auch welche Bedeutung. Ob ein Gebäude dies nach außen zeigen soll, kann sehr unterschiedlich beantwortet werden. Die Französische Nationalbibliothek zum Beispiel hat die Form von vier aufgeklappten Büchern und signalisiert somit ihre Funktion nach außen. Etwas subtiler gingen die Architekten Herzog & de Meuron bei der Bibliothek der Fachhochschule Eberswalde vor, wo die Fassade mit Fotomotiven überzogen ist, was den Informationsgehalt einer Bibliothek nach außen hin symbolisiert. Andere Gebäude verschleiern ihr Innerstes dagegen hinter einer Schulfassade.
Die Lesbarkeit einer Architektur hat eine Vielzahl verschiedener Facetten. Eine Facette stellt die Lesbarkeit der Schnittstellen dar. Also ob eine Schnittstelle in ihrer Struktur, Signatur und Protokoll ihren Sinn, Zweck und Verwendung klar widerspiegelt. Eine weitere Facette bildet z.B. die Komponentenstruktur. In diesem Kontext bedeutet Lesbarkeit, in wie weit sich die Architektur im Zusammenspiel der Komponenten wiederfinden und erkennen lässt. Hierzu zählt auch eine klare Verantwortlichkeits- und Aufgabenzuordnung der einzelnen Komponenten. Ebenfalls stellt die Trennung von Fachlichkeit und Technik eine weitere Facette der Lesbarkeit dar, durch die - von außen betrachtet - Ziel und Zweck der Komponente leichter erkennbar wird. Wie in der klassischen Architektur, gibt es jedoch auch in Softwarearchitektur und -design Systeme und Komponenten, welche ihre Lesbarkeit begründet mindern oder verschleiern wollen.
Bezüge zur Umgebung:
Das idealisierte Leitbild der Architektur ist der Entwurf eines Bauwerks, das mit der Umgebung in vielschichtiger Art und Weise in Verbindung steht. Ein Bauwerk kann sich in seine Umgebung einfügen oder bewusst als Kontrast gestaltet sein. Die Beziehung wird äußerlich zum Beispiel durch Formgebung, Farbgestaltung und Materialauswahl hergestellt. Sichtbezüge, Raumabfolgen und Wegeführungen außen und innen spielen eine entscheidende Rolle für den Bezug zwischen Bauwerk und Umgebung.
In den seltensten Fällen existieren Systeme und Komponenten auf der "grünen Wiese". Im Regelfall stehen Systeme und Komponenten in Wechselwirkung mit ihrer Umgebung. Wie auch in der klassischen Architektur sind in Softwarearchitektur und -design die Bezüge zur Umgebung aufzugreifen und zu berücksichtigen. Diese Schnittstellen zur Umwelt - ob technisch, fachlich oder in Form einer Oberfläche - stellen einen wesentlichen Bestandteil der Softwarearchitektur und des Softwaredesigns dar. Diese Bezüge zur Umgebung können durch die Übernahme von Styleguides und Farben nach außen hin visuell dargestellt werden. Mittels gemeinsamer Strukturen und Architekturansätze bishin zur gemeinsamen Nutzung von Komponenten und Softwarestacks können diese Bezüge zur Umgebung technisch aufgegriffen und durch Diagramme (Informationsflussdiagramm, Schnittstellendiagramm, Sequenzdiagramm etc.) adäquat dokumentiert werden.
Ideeller Bezug:
Im Rahmen der Denkmalpflege haben bestimmte Orte, Straßen, Plätze oder Gebäude eine besondere Bedeutung. Der ideelle Bezug leitet sich dabei weniger aus formal-ästhetischen Gesichtspunkten ab, sondern aus einem oder mehreren historischen Ereignissen, Gegebenheiten oder einem besonderen historischen Kontext, in dem ein Areal oder ein Gebäude steht oder stand, z. B. bestimmte Abschnitte der ehemaligen Mauer bzw. die Übergangsstelle Checkpoint Charlie in Berlin, Geburtshäuser oder Wohn- bzw. Arbeitsstätten bedeutender Persönlichkeiten, Stätten politischen Umbruchs usw.; selbst bei fehlender architekturhistorischer Bedeutung haben Architekten und Planer bei Rückbauten, Rekonstruktionen, Umnutzungen, Umbauten oder Erweiterungen solcher historisch und gesellschaftlich spezifischen Orte den ideellen Bezug zu berücksichtigen.
Auch der ideele Bezug der klassischen Architektur besitzt ein Pendent in der Softwarearchitektur. Wie bereits erwähnt, werden Systeme und Komponenten kaum noch auf einer "grünen Wiese" gebaut. Oft müssen sich diese Systeme und Komponenten in eine bestehende Landschaft einfügen, bestehende Systeme und Komponenten erweitern oder gar ablösen. Daher ist bei der Definiton der Zielarchitektur und des Zieldesigns auch der ideele Bezug der Stakeholder zu den bereits bestehenden Systemen zu berücksichtigen. Hierdurch kann die Akzeptanz der ggf. neuen Architektur, des neuen Designs bei den Stakeholdern gesteigert werden.
Nachhaltigkeit, Ökologie und Energieverbrauch:
Seit den 1980er Jahren, jedoch verstärkt seit die Debatte um die Globale Erwärmung immer breiter geführt wurde, sind Nachhaltigkeit, Ökologisches Bauen und die Verminderung des Energieverbrauchs von Gebäuden zu wichtigen Themen in der Architektur geworden. Viele Gebäude haben einen hohen Heiz- und Kühlenergiebedarf; auf die Lebensdauer des Gebäudes projiziert gibt es erhebliche Energie-Einsparungspotenziale. Beim Entwurf von Gebäuden werden heute die Ausrichtung, die Form des Baukörpers, die Gebäudehülle und die Baustoffe auch in Hinsicht auf ökologische Aspekte gewählt. Dies hat zum Teil weitreichende Auswirkungen auf die Architektur der Gebäude. Unter dem Stichwort Solararchitektur werden Konzepte zusammengefasst, die eine weitgehende Minimierung des Energieverbrauchs zum Ziel haben. Viele moderne Gebäude erreichen heute einen guten Energiestandard.
Nachhaltigkeit, Ökologie und Energieverbrauch sind im übertragenen Sinne ebenfalls Aspekte, welche in Softwarearchitektur und Softwaredesign einfließen sollten. Nachhaltigkeit in Bezug auf Software bedeutet, dass diese auch über mehrere Jahre hinweg genutzt und an die Bedürfnisse angepasst werden kann. Die Ökologie einer Software (i.S.e. Wirtschaftlichkeit) besteht z.B. in ihrem Nutzen, dem Einsparungspotenial oder der Effizienzsteigerung, welche den Anschaffungs- und Unterhaltskosten gegenüberstehen. Auch der Energieverbrauch aus der klassischen Architektur kann in Bezug auf Softwarearchitektur auf die Betriebskosten abgebildet werden. Diese Betriebskosten fallen z.B. in Form von notwendigen Personalressourcen, Betriebsmitteln oder Server- und Lizenzkosten an. Wie in der klassischen Architektur können auch in der Softwarearchitektur und im Softwaredesign Nachhaltigkeit, Ökologie und "Energieverbrauch" adressiert werden.
Kosten:
Das Budget, das der Bauherr zur Errichtung eines Gebäudes bereitstellt, ist ein zentraler Faktor, der über die Qualität des Ergebnisses entscheidet. Oft werden Entwurfsentscheidungen aufgrund des Budgets getroffen, es hat also wesentlichen Einfluss auf die Architektur. Das Thema Kosten begleitet die Planer durch den gesamten Planungs- und Ausführungsprozess.
Die oben erwähnten Auswirkungen des bereitgestellten Budgets auf die klassische Architektur können auch auf die Softwarearchitektur und das Softwaredesign übernommen werden. Auch dort stehen Qualität und Umfang in einem Spannungsdreieck mit dem Budget. Dies bedeutet, dass auch bei Software Qualität ein Kostenfaktor ist. Hierbei muss der Auftraggeber entscheiden, wie viel ihm Faktoren wie Erweiterbarkeit, Wartbarkeit oder simpel die Stabilität des Systems wichtig sind. Diese Qualitätsanforderungen sind dann entsprechend bei der Softwarearchitektur zu berücksichtigen. Jedoch sollte dies nicht zur blinden Anwendung des Grundsatzes "Design to Budget" führen. Eine unreflektierte Anwendung führt entweder zu sinnfreiem Budgetverbrauch oder einer fehlenden Information des Auftraggebers über mögliche Risiken und Abstriche bei der Qualität durch fehlendes Budget und der damit verbundenen Folgekosten.
Software und somit Softwarearchitektur und Softwaredesign sind immateriell und nicht greifbar. Daher benötigen diese sowie deren Vor- und Nachteile eine adäquate Visualisierung und Dokumentation.
Jedoch besteht für die Softwarearchitektur und das Softwaredesign eine weitere und nicht zu vernachlässigende Herausforderung. Während wir den Petersdom und das Taj Mahal besichtigen also im wörtlichen Sinne begreifen können, ist Software - und damit das Design und die Architektur - immateriell; somit weder sicht- noch greifbar. Daher steht der Softwarearchitekt prinzipiell vor dem Problem der Visualisierung und Verargumentierung derjenigen Vorteile, welche mit einer guten Architektur und einem klarem Design einhergehen. Letztendlich befindet sich der Architekt also vor der Herausforderung, dem Kunden den Mehrwert und Nutzen einer guten, passenden Architektur sowie eines klaren Designs - insbesondere über die Nutzungsdauer hinweg - (be-)greifbar zu machen.
Allerdings bleibt trotz dieser Immaterialität die Bedeutung der Architektur für Software, Produkte, Projekte und letztendlich das Unternehmen als solches sowie dessen Erfolg unverändert:
Architektur und Design sind kritische Erfolgsfaktoren für den Projekt- und Unternehmenserfolg - auf operativer, strategischer und taktischer Ebene.
Heute werden Geschäftsprozesse signifikant durch IT unterstützt. Damit das Unternehmen sich an neue Begebenheiten am Markt anpassen und somit bestehen kann, unterliegen diese Geschäftsprozesse jedoch einem mitunter kurzem Lebenszyklus oder einem schnellem Wandel. Daher ist es für Unternehmen essentiell, dass ihre Systeme mit diesem Wandel Schritt halten können. Voraussetzung hierfür ist jedoch, dass Architektur und Design der Systeme derartige Anpassungen ohne eine signifikante Erosion ermöglichen. Sollten Systeme aufgrund schlechter Architektur, schlechtem Design oder bereits vorhandener Erosion nicht mehr an neue Gegebenheiten anpassbar sein, drohen dem Unternehmen also gegebenfalls Wettbewerbsnachteile und somit Verluste.
Analog verhält es sich während der Projektlaufzeit. Auch dort unterliegen die Anforderungen einem Wandel über die Projektlaufzeit. Die ursprünglich gestellten Anforderungen werden verworfen, neue Anforderungen aufgenommen, bestehende Anforderungen geändert oder verfeinert. Wird hier an einer adäquaten Architektur gespart, so können ggf. Anforderungen nicht oder nur noch mit sehr hohem Aufwand umgesetzt bzw. angepasst werden. Dies kann die Erreichung der Projektziele und - in letzter Konsequez - die Fortführung des Projektes gefährden, indem Budgets für Anforderungen gesprengt oder Terminpläne nicht mehr eingehalten werden können.
1) Themen der Architektur - Quellen:
Wikipedia-Eintrag Architektur
architekt.de - Wichtige Themen in der Architektur