In der heutigen digitalen Ära, in der Informationstechnologie (IT) einen entscheidenden Einfluss auf nahezu jeden Aspekt unseres Lebens hat, ist die Gewährleistung von Qualität in IT-Projekten von größter Bedeutung. Qualitätsmanagement und Qualitätssicherung in der IT sind unverzichtbare Prozesse, die dazu beitragen, sicherzustellen, dass IT-Lösungen den höchsten Standards entsprechen. Im Folgenden werden die Relevanz und die Vorteile von Qualitätsmanagement und Qualitätssicherung in der IT näher erläutert.

1. Relevanz von Qualitätsmanagement in der IT:

• Kundenanforderungen erfüllen: Qualitätsmanagement ermöglicht es, die Anforderungen und Erwartungen der Kunden präzise zu verstehen und sicherzustellen, dass die entwickelten IT-Lösungen diesen Anforderungen entsprechen. Dies führt zu zufriedenen Kunden und langfristigen Beziehungen.

• Fehlerreduzierung: Durch die Implementierung von Qualitätsmanagementprozessen können Fehler frühzeitig erkannt und behoben werden. Dies führt zu einer Verringerung von Fehlern in der Software oder den IT-Systemen und spart Zeit und Kosten.

• Effizienzsteigerung: Qualitätsmanagement trägt dazu bei, die Effizienz in IT-Projekten zu steigern, indem es unnötige Redundanzen oder ineffiziente Prozesse eliminiert. Dies führt zu einer optimalen Ressourcennutzung.

2. Vorteile von Qualitätssicherung in der IT:

• Früherkennung von Problemen: Qualitätssicherung ermöglicht die Identifizierung von Problemen und Mängeln in einem frühen Stadium des Entwicklungsprozesses. Dies erleichtert die Fehlerbehebung und verhindert teure Fehler in späteren Phasen.

• Stabilität und Zuverlässigkeit: Qualitätssicherung stellt sicher, dass IT-Systeme und Software stabil und zuverlässig sind. Dies ist von entscheidender Bedeutung, um Ausfallzeiten und Serviceunterbrechungen zu minimieren.

• Kostenersparnis: Indem Fehler frühzeitig erkannt und behoben werden, reduziert Qualitätssicherung die Kosten für die Fehlerbehebung in späteren Phasen eines Projekts. Dies führt zu erheblichen Einsparungen.

3. Die Bedeutung von Testverfahren:

Ein wesentlicher Bestandteil von Qualitätssicherung in der IT sind umfassende Testverfahren. Durch gründliches Testen können Schwachstellen und Fehler in Software und IT-Systemen aufgedeckt werden. Dies umfasst Funktionstests, Leistungstests, Sicherheitstests und mehr. Qualitätsmanagement umfasst auch die Entwicklung von Testplänen und -strategien, um sicherzustellen, dass alle Aspekte einer IT-Lösung geprüft werden.

4. Fortwährende Verbesserung:

Ein zentraler Grundsatz des Qualitätsmanagements in der IT ist die kontinuierliche Verbesserung. Durch die Analyse von Feedback, Fehlerdaten und Leistungsmetriken können IT-Teams ihre Prozesse ständig optimieren und die Qualität ihrer Produkte und Dienstleistungen steigern.

Insgesamt ist Qualitätsmanagement und Qualitätssicherung in der IT unverzichtbar, um sicherzustellen, dass IT-Projekte erfolgreich abgeschlossen werden und die Anforderungen der Kunden erfüllen. Diese Prozesse helfen nicht nur, Fehler zu vermeiden und Kosten zu senken, sondern tragen auch zur Schaffung von stabilen, zuverlässigen und hochwertigen IT-Lösungen bei, die in unserer zunehmend digitalisierten Welt von entscheidender Bedeutung sind.

IT-Systeme befassen sich mit der Verarbeitung von Informationen, um dem Anwender einen strategischen Vorteil zu verschaffen. Hierfür muss das System eine wichtige Kernaufgabe erfüllen:

Die richtige Information in der richtigen Darstellung zur rechten Zeit am rechten Ort bereitstellen zu können.

Jedoch enthält diese Forderung einen Aspekt, der oftmals zu spät und/oder zu wenig Berücksichtigung findet. Der Aspekt der Bereitstellung "zur rechten Zeit". Dieser stellt in vielen Systemen eine sehr wichtige und kritische nicht-funktionale Anforderung dar. Informationen, welche zu spät bereitgestellt werden, können wertlos sein und in Folge dessen zu strategischen Nachteilen oder finanziellen Verlusten führen. Als Beispiel können Nachrichten im Börsenhandel gesehen werden. Zu spät bereitgestellte Börsendaten können - in Folge von dadurch verspätet getroffenen Entscheidungen - zu hohen Kursverlusten führen.

Daher ist die Performance ein kritischer Faktor für den Erfolg von IT-Systemen und Unternehmen und sollte frühzeitig untersucht und einbezogen werden. Dies erfordert zunächst im Requirements Engineering eine Aufnahme der Performanceanforderungen an das System. Die daraus resultierenden Messkriterien finden später in der Testphase und den entsprechenden Performancetests Verwendung.

Weit wichtiger ist jedoch, diese Performanceanforderungen im Requirements Engineering zu erfassen und bereits bei der Architektur und dem Design des Systems zu berücksichtigen. Nachträgliche Performanceoptimierungen in bestehenden Systemen sind in der Regel nur schwer durchführbar und teuer. Nicht zuletzt da dies in vielen Fällen zu einer Neuausrichtung der Architektur sowie dem Design führt. Dies resultiert oftmals in einer Neuimplementierung des Systems.

Als Entscheidungsbasis für Performanceoptimierungen ist jedoch eine Performanceanalyse basierend auf den Ergebnissen der Performancetests unerlässlich. Nur wenn Performanceleaks und deren Ursachen richtig erkannt und priorisiert werden, können Optimierungsmaßnahmen gezielt, nutzenstiftend und kosteneffizient umgesetzt werden.

Andernfalls bestehen diverse Risiken, welche bei Performanceoptimierungen berücksichtigt werden sollten. Es besteht z.B. zunächst die Gefahr knappe und teure Ressourcen ineffizient für Mikrooptimierungen im Millisekundenbereich einzusetzen. Hierdurch wären diese Ressourcen gebunden und könnten nicht für Weiterentwicklungen oder Fehlerbehebung eingesetzt werden. Somit wäre weder ein wirtschaftliches Kosten-Nutzen-Verhältnis gewahrt, noch die Opportunitätskosten entsprechend berücksichtigt. Weiter besteht unter anderem das Risiko, anstatt eine spürbare Performancesteigerung zu erzielen, schwer erkennbare Fehler in das System zu bringen. Als Beispiel können Raceconditions aufgrund falsch eingesetzter bzw. falsch umgesetzter Parallelverarbeitung angeführt werden. Ein weiteres und nicht zu unterschätzendes Risiko ist die entstehende Systemerosion, welche mit Mikrooptimierungen oft einhergeht. Diese führt, aufgrund der zunehmenden Vermengung von technischem und fachlichem Code, im weiteren Verlauf meist zu unverständlichen und somit unwartbaren Komponenten. Dadurch können die späteren Wartungs- und Weiterentwicklungskosten auf unwirtschaftliche Größenordnungen ansteigen und eine vorzeitige Systemablösung bedingen.

Negativ Beispiel : Nachträgliche Parallelisierung eines Produktes

Ein Softwarehersteller versuchte seine Performanceprobleme dadurch zu lösen, indem er sein Produkt nachträglich auf Parallelverarbeitung umstellte. Jedoch erwies sich dies schnell als Fehleinschätzung. Anstatt die gewünschte Performancesteigerung zu erzielen, lieferte das System nun falsche Daten. Dies resultierte zunächst in einem hohen finanziellen und personellem Aufwand des Herstellers, um die Fehlerursache zu analysieren und zu beheben. Weit schlimmer war allerdings der Vertrauensverlust des Kunden in das Produkt. Derartige Imageschäden sind im hart umkämpften Markt kaum bezifferbar.

Positiv Beispiel : Umstellung der Verarbeitung von Massendaten

In einem BI-Umfeld wurden täglich mehrere Gigabyte an Daten in eine historisierte Datenbank übertragen. Die eingesetzten Algorithmen bedienten sich dabei auch der mehreren Terrabyte umfassenden, historisierten Daten. Aufgrund einer ungenügenden Analyse, wurde zunächst eine einfache, sequentielle Batcharchitektur umgesetzt. Diese resultierte in Verarbeitungszeiten von zum Teil mehreren Stunden pro Algorithmus. Nach einer Untersuchung der Datenstrukturen sowie der Anforderungen, konnte eine mehrfachparallele Architektur mit Datensegmentierung als Lösung präsentiert werden. Diese Umstellung der Algorithmen führte im ersten Schritt zu einer sauberen Trennung der technischen und fachlichen Logik. Somit konnte - als Nebenprodukt - die Anpassungsgeschwindigkeit der Algorithmen signifikant erhöht und die Fehleranfälligkeit reduziert werden. Im zweiten Schritt war es durch gezielte Performanceoptimierungen möglich, die Laufzeit der Algorithmen auf jeweils ca. 10 bis 15 Minuten zu senken.

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 Architektur¹⁾ 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.

¹⁾ Themen der Architektur - Quellen:

Wikipedia-Eintrag Architektur
architekt.de - Wichtige Themen in der Architektur