Thema: Software-Architektur

Durch die agile Bewegung ist Architektur ein vieldiskutiertes und umstrittenes Thema geworden. War Architektur Mitte der 90er Jahre noch unumstritten der Nabel der IT-Welt, so gab es in den letzten 10 Jahren nicht wenige Stimmen, die Architektur zur Nebensache und den Architekten zur Persona non grata erklärt haben. Genauso unerbittlich haben viele der Befürworter von Architektur an dem Weltbild der 90er Jahre festgehalten. Interessant - und auch ein wenig traurig - war dabei zu beobachten, dass es vielfach keinerlei Austausch zwischen den beiden Lagern zu geben schien.

Jede Partei hielt an ihrer Sichtweise fest, ohne sich einmal Gedanken über die Argumente der Gegenseite zu machen. Dabei ist es genau dieser Austausch, der das Thema Architektur voranbringen kann, denn beide Seite haben - obgleich meistens zu extrem in ihren Standpunkten - auf ihre Weise recht: Architektur wird häufig zu sinnentleert als Selbstzweck betrieben, ohne echte Verbindung zum Rest der Software-Entwicklung, ohne einen klaren Mehrwert für das Vorhaben. Auf der anderen Seite ist es praktisch unmöglich, ein nicht-triviales System ohne eine vernünftige Architektur so zu entwickeln, dass es über seinen Lebenszyklus wartbar und änderbar bleibt - von einer zuverlässigen und durchgängigen Umsetzung der anderen nicht-fachlicher Anforderungen einmal ganz abgesehen.

Agilität hilft der Architektur also, ihren Sinn und Fokus (wieder) zu erlangen, während Architektur der Agilität hilft, nachhaltig zu funktionieren - denn ist das System erst einmal nicht mehr wartbar, hilft auch das schönste agile Vorgehen nicht mehr. Auch das von vielen Agilisten als Universallösung hochgehaltene Konzept der emergenten Architektur ist an der Stelle kein Allheilmittel: es gibt zwar in der Tat Teile einer Architektur, die kann und sollte man emergent entstehen lassen. Aber es gibt auch Teile, über die man explizit nachdenken muss, die man vorab festlegen sollte, wenn man einem System eine solide Basis geben will und es nachhaltig verständlich und änderbar halten will. Dei Wahrheit liegt also - wie so oft - in der Mitte.

Dass wir Architektur und Architekturarbeit benötigen, ist unbestreitbar. Und gerade heute in Zeiten von Scale-Out-Lösungen, von BigData, Cloud und verteilten Systemen rückt eine gute Architektur als essentieller Erfolgsfaktor wieder stärker in den Fokus: die meisten Scale-Out- Lösungen werden auf (unzuverlässiger) Standard-Hardware betrieben, es gibt kein High-Availability, kein Clustering, keine ACID-Transaktionen, usw., die einen die Lösungen bequem so entwickeln lassen, als würden sie lokal auf einem Rechner laufen. Das hat zur Folge, dass wir Skalierbarkeit sowie Fehlertoleranz vom Ausfall von Knoten bis hin zum Umgang mit inkonsistenten Daten explizit in unseren Anwendungen umsetzen müssen - was ein Architekturthema ist: solche Konzepte entstehen nicht emergent, man muss sie (upfront) explizit in den Lösungen vorsehen.

Wir leben in spannenden Zeiten, was Architektur angeht: Durch die Agilität haben wir eine immer noch laufende Diskussion über den Wert von Architekturarbeit und Architekten, die uns hilft, den Sinn unserer Arbeit (wieder) zu erkennen und echten Mehrwert von selbstverliebtem Ballast zu trennen. Durch Scale-Out-Lösungen, sei es im Umfeld von BigData, Cloud oder großen Web-Systemen, haben wir einen Paradigmen-Shift in den Architekturen, der neue Herausforderungen für unsere Arbeit bedeutet und dem wir gerecht werden müssen.

Es gibt viel zu tun, es gibt viel zu erforschen, es gibt viel zu lernen - Architektur war selten interessanter und spannender als heute!


Newsletter abonnieren



Empfehlung an diese E-Mail-Adresse senden:


 

 

 

Ihre eigenen Angaben:

 

 

 

 

Diese Seite empfehlen Sie weiter: