Mich beschleicht immer mehr der Eindruck, dass Software-Architektur anscheinend nicht mehr wichtig ist oder zumindest nicht mehr so bewusst von Entwicklern berücksichtigt, gelebt und erfahren wird. Immer öfter trifft man auf Systeme, die in den Grundfesten ihrer Substanz keine ernsthaft durchdachte und geplante Architektur aufweisen. Hieraus resultieren in der Folge Systeme, die entweder hohe Kosten in der Maintenance-Phase nach sich ziehen oder die schlicht und einfach inperformant sind.
Wie kann das sein? Zweifellos ist in den letzten Jahren viel zum Thema Software-Architektur veröffentlicht und vorgetragen worden. Es hapert teilweise jedoch schon an den grundlegenden Ansätzen der Software-Architektur. Ich spreche hierbei noch nicht von Themen wie dem Abstrahieren von Laufzeitumgebungen durch Mock-Verwendung, DDD etc.
Kann es sein, dass die Entwickler heutzutage durch die stetige Verbesserung der Werkzeuge – wie zum Beispiel die Eclipse-IDE oder BPM-Suiten – immer stärker davon entkoppelt werden, sich Gedanken über die Auswirkung des Einsatzes einer bestimmten Technologie und konkreter Architekturmuster zu machen? Die Werkzeuge generieren immer mehr Code, Fragmente, Komponenten etc. Je stärker die Werkzeuge, um so mehr ziehen sich die Entwickler von den Architekturfragen zurück; zumindest scheint es so zu sein.
Heutzutage bewegen wir uns im Umfeld von verteilten Systemen. Diese implizieren in Richtung Software-Architektur und Technologien viele enorm wichtige Punkte, die berücksichtigt werden müssen. Wir verfügen heute über deutlich stärkere Server und auch die Laufzeitumgebungen sind besser geworden. Dennoch sind grundsätzliche Themen wie Latenzzeiten in entfernten Methodenaufrufen oder das über ein Netzwerk zu transportierende Datenvolumen in Verbindung mit vielen Anwendern und ggf. transaktionaler Absicherung immer noch – oder erst recht – Themen, die wir als Entwickler und Architekten zu berücksichtigen haben. Leider abstrahieren die Werkzeuge und eingesetzten Laufzeitumgebungen immer mehr, dass es sich oftmals um eine Art von verteilten Sytemen handelt.
Um auf meine Eingangsfrage zurückzukommen: Software-Architektur ist wichtig. Sie ist sogar sehr wichtig. Eine geplante und gute Software-Architektur wirkt sich nachhaltig (und hiermit ist jetzt keine Vertriebsfloskel gemeint) positiv auf die Kosten der Maintenance-Phase eines Systems aus. Zudem ist eine geplante und dem Anwendungszweck angemessene Software-Architektur die Grundlage für ein performantes, skalierbares und erweiterbares System.
Letztlich bedeutet dies, dass die Entwickler und Architekten sich gerade vor dem Hintergrund der immer besser werdenden Entwicklungs- und Laufzeitumgebungen wieder verstärkt dem Thema Software-Architektur widmen müssen. Die Entwickler sollten sich nicht blind auf mehr oder minder vollständig generierte Artefakte, abstrahierende Laufzeitumgebungen und die Arbeit erleichternde Tools verlassen. Es ist wichtig zu verstehen, welche architektonischen Ansätze implizit durch das Tooling genutzt werden oder ob diese überhaupt in genügender Tiefe und Breite im Hintergrund vorhanden sind. Und es ist Aufgabe der Entwickler und Architekten, diese „generischen“ Architekturmuster vor dem Hintergrund der konkreten Verwendung in einem System zu hinterfragen und anzupassen.
