„Ja, macht nur einen Plan!“ Was versteht man unter Software-Architektur?

Anbieter zum Thema

DAXTEN GmbH

Kentix GmbH

EPS Rechenzentrum Infrastruktur GmbH

Dass es so etwas wie „Software-Architektur“ gibt, wird man kaum bestreiten können, wenn man Programme und Module entwickelt. Nur dass ein diesbezüglicher Bauplan die „IT-Bauleute“ bei der Entwicklung sinnvoll leiten kann, das ist die Frage.

Die Redeweise von der Software-Architektur ist mittlerweile gut 30 Jahre alt, spätestens um 1990 kam sie in der akademischen Welt auf und im Anschluss an einige Jahre akademische Diskussion wurde die Rede von der Softwarearchitektur auch ein etablierter Topos in der IT-Arbeitswelt.

Jedenfalls gab es in der Deutschen Gesellschaft für Informatik Anfang der „Nullerjahre“ schon einen Arbeitskreis für Software-Architektur, der 2006 in eine ständige GI-Fachgruppe umgewandelt wurde. Ab 2003 wurden von der GI auch entsprechende Zertifizierungen vergeben. Und nicht zu vergessen: In den USA wurde im Jahr 2000 ein gewisser Bill Gates „Chief Software Architect“ bei Microsoft.

Eine abstrakte Metaebene und ihre Probleme

Auf den ersten Blick scheint der Begriff Software-Architektur ganz einfach zu sein: Bei der Software-Architektur handelt es sich um eine programmiertechnische Meta-Ebene, auf der Programm-Module und ihre Konnektoren in verschiedene Typen kategorisiert werden (in der so genannten Client-Server-Architektur zum Beispiel Datenhaltung, Geschäftslogik und Präsentationslogik), hierarchische Abhängigkeiten festgelegt und das funktionale Zusammenspiel der verschiedenen Elemente in abstrakter Form beschrieben werden.

Bald nach der Etablierung des Begriffs gab es entsprechende formale Werkzeuge wie die Unified Modeling Language (UML), in der ein Algorithmus zur Lösung eines bestimmten Problems abstrakt, sprich „programmiersprachenunabhängig“ beschrieben und dann händisch oder (semi-)automatisch in eine maschinenlesbare Sprache transformiert wurde.

Tatsächlich gerät diese Art einer modellgetriebenen Software-Architektur in der IT-Realität schnell an ihre Grenzen. Sie ist in aller Regel zu abstrakt, um (kostenmäßig) sinnvoll eingesetzt werden zu können. Und es stellt sich überdies die Frage, ob sie überhaupt „teamfähig“ ist, sprich ob man auf einer solchen abstrakten Ebene ein größeres Entwickler:innen-Team auf ein gemeinsames Ziel hin „ein-norden“ kann.

Die Verwendung der Unified Modelling Language war jedenfalls von Anfang dadurch gekennzeichnet, dass in konkreten Projekten sowohl geschäftsorientierte als auch technische Aspekte in die Modellierung einflossen, was den Abstraktionsgrad des Modells deutlich verminderte.

Vor allem wenn man eine (voll-)automatische Umsetzung des aufgebauten Modells in konkrete maschinenlesbare Anweisungen für eine Maschine realisieren wollte, mussten die Formalisierung und die Formulierung so ausgefeilt sein, dass man die maschinenverwertbaren Anweisungen eigentlich gleich selbst schreiben konnte.

Die Sache mit den nicht-funktionalen Anforderungen

Auf jeden Fall klingt in Zeiten agiler Software-Entwicklung mit ihren schnellen Zyklen und geschmeidig angelegten Prozessen eine Vorgehensweise wie die obige eher unhandlich, um es einmal freundlich zu formulieren. Und wie steht es mit den nicht-funktionalen Anforderungen an ein Software-Produkt, die zunehmend zahlreicher und gewichtiger werden: Einhaltung des Unternehmenskodex (neudeutsch „Governance“), Einhaltung vorgegebener Regularien (neudeutsch „Compliance“), Vereinfachung der Wartbarkeit von Software und nicht zuletzt „grüne Software“, sprich Klima-effiziente Programmentwicklung?

Zu Letzterem nur eine Bemerkung, weil die damit einhergehenden nicht-funktionalen Anforderungen relativ neu in der Diskussion der Branche sind: Auch wenn bei CO₂-Emissionen, die durch Rechnerleistung entstehen wie etwa bei einer Suchmaschinenanfrage, oft nicht stringent entschieden werden kann, welcher Anteil auf die Hardware und welcher auf die Software entfällt, trägt die „weiche Ware“ doch in hohem Maße zu den weltweiten CO₂-Emissionen bei, beispielsweise durch funktionslosen („vergessenen“) Code, durch schlecht geschriebene, „lahme“ Apps oder durch aufgeblähten HTML-Code.

Architektur versus „Architektur“

Wenn wir weiter oben Software-Architektur als eine im Vergleich zu existierenden Programmiersprachen abstrakte Metaebene bezeichnet haben, die als gemeinsame Basis für Entwicklerteams in einem konkreten Softwareprojekt verwendet wird, so ist das schon eine ganz bestimmte Interpretation des Begriffs Software-Architektur. Man setzt dabei voraus, dass sich aus dieser Metaebene sinnvoll etwas machen lässt, was ein Projekt schneller voranbringt oder dass eine solche Metaebene eine Art Erfolgsgarant ist. Dass Unternehmen „Software-Architekten“ installieren beziehungsweise installierten, so wie Microsoft seinerzeit seinen Boss als „Chief Software Architect“ modellierte, geht in diese Richtung.

Tatsächlich kann man aber den Begriff Software-Architektur auch mit deutlich geringerem semantischem Ballast benutzen, nämlich als etwas, das bei jeder Software-Entwicklung einfach entsteht, mehr nicht. Boshaft gesagt: auch windschiefe Häuser folgen irgendwelchen „Architekturprinzipien“, sind folglich Architektur.

Offensichtlich besteht der wesentliche Unterschied in der Verwendung des Begriffs Architektur darin, dass dieser in traditioneller Vorgehensweise, beispielsweise auf Basis des so genannten Wasserfallansatzes, technisch-funktional genommen wird: Es werden Architekturziele und Architekturkonzepte und -strategien in spezifischen Dokumenten erfasst und ausgearbeitet. Diese bilden dann den verbindlichen Rahmen für Softwaredesign, Testkonzepte und so weiter.

Emergente Architektur

Im Fall der heute weitgehend üblichen Form agiler Software-Entwicklung werden solche Dokumente nicht erstellt, mehr noch: im agilen Manifest, einem echten Stück (scheinbar?) anarchischer Software-Entwicklung wird sogar ausdrücklich in Abrede gestellt, dass es für die entstehende „Architektur“ irgendetwas bringt, einen der Architektur zugrunde liegenden Bauplan festzuschreiben und aktiv voranzutreiben. Vielmehr wird diese als Ergebnis eines weitgehend spontan entstandenen Ergebnisses eines selbstorganisatorischen Prozesses gesehen.

Diese Emergenztheorie hat eine lange Tradition in Philosophie, Psychologie und nicht zuletzt den Naturwissenschaften („Laplacescher Dämon“) und lässt ich mindestens bis zu einem Grundlagenwerk unserer gesamten wissenschaftlichen Zivilisation zurückverfolgen, nämlich zur Metaphysik des Aristoteles.

Software-Architektur entsteht so oder so, auch wenn einen der Bauplan nicht interessiert und auch wenn man meint, dass im Rahmen des Schöpfungsprozesses ein solcher Bauplan in expliziter Weise ganz grundsätzlich nicht zur Verfügung stehen kann. Und wenn man daran denkt, wie viele scheinbar minuziös geplanten Softwareprojekte „grandios teuer“ den Bach hinuntergegangen sind (wir verzichten hier auf Namen und Projekte), dann kann man dieser „Dekomposition aller Software-Architektur“ viel abgewinnen.

(ID:49734237)