Softwarearchitektur – voll 80er? tot? oder noch schlimmer?

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Wie funktioniert Softwarearchitektur heutzutage eigentlich? Seit den 80ern hat sich eine Menge getan und die agile Bewegung brachte noch einmal Schwung in die Entwicklung hin zu… ja hin zu was? Gibt es Architektur als Disziplin noch?

Anforderungen an eine Architekturmethodik

Wir arbeiten gerade an einem neuen Architektur-Curriculum für 2011 und versuchen unsere Praxis auf ein vermittelbares Fundament zu stellen. Aber Architektur fühlt sich nicht mehr an wie noch vor einigen Jahren. Viele Projekte mit denen ich zu tun habe verabschieden sich von groß angelegten Architekturphasen zu Projektbeginn, arbeiten stetig, iterativ, kundengetrieben und oft auch ohne die Rolle „Architekt“ im ursprünglichen Sinn. Das ist erfolgreich und eine äußerst positive Entwicklung, verändert die Disziplin der Softwarearchitektur aber auch nachhaltig. Die Disziplin gibt es zwar noch, wir müssen sie aber offener beschreiben und einige Paradigmen ersetzen.

Nun hilft es meiner Ansicht nach wenig, Architektur einfach nur agil zu machen. Zumindest die Projekte unserer Kunden sind sehr unterschiedlich was ihre Agilität angeht. „Emergentes Design“ und Agilität in Reinkultur funktionieren nicht unter allen Voraussetzungen. Eine Architektur-Methodik muss also skalieren und braucht eine Entscheidungsgrundlage. Wann arbeitet man mehr, wann weniger an der Architektur? Wann implementiert man einfach, wann lohnt sich Design?

Architekturarbeit im Kontext

Ein erster Versuch darzustellen wie ein einfacher Architekturprozess aussehen kann, der diese Abwägungen lokalisiert, ist in folgender Abbildung zu sehen.

[caption id="attachment_244" align="aligncenter" width="480" caption="Architekturarbeit im Kontext"][/caption]

Die Abbildung zeigt 2 Zyklen: links den Architekturzyklus, rechts den Implementierungszyklus. Tätigkeitsbereiche sind in grauen Kästen dargestellt und werden durch eine Auflistung typischer Artefakte ergänzt. Basis für Architektur und Umsetzung sind in jedem Fall priorisierte Anforderungen von Kundenseite. Anforderungen können direkt in Code gegossen werden, Funktionalität wird stetig ausgeliefert, bildet aber auch iterativ Feedback für noch nicht umgesetzte Anforderungen.

Architekturzyklus: Wann und wie oft?

Wie man sieht, ist der Architekturzyklus optional. Zu Beginn wird den Zyklus aber fast jedes Projekt durchlaufen. Zumindest um eine gemeinsame Vision zu entwickeln, spätere Entscheidungen zu vereinfachen und den groben Rahmen für die Entwicklung festzulegen. Üblicher Weise versucht man sich vorab auf ein Minimum zu beschränken. Anforderungen sind hier, genau wie später im Prozess, der entscheidende Faktor: Architekturarbeit wird interessanter wenn:

• Anforderungen beträchtliche Risiken bergen
• höhere qualitative Anforderungen (Sicherheit, Verfügbarkeit, Skalierbarkeit, etc.) ins Spiel kommen.

Um Risiken zu mindern wird man vor der tatsächlichen Umsetzung eventuell Prototypen oder Durchstiche bauen und versucht neue Technologien auszuprobieren bevor man sie breit einsetzt.

Hohe qualitative Anforderungen, wie im zweiten Punkt genannt, kommen fast immer mit der Notwendigkeit von Kompromissen einher. Diese Kompromisse willentlich abzuwägen, zum Kunden zu tragen und entsprechende Entscheidungen konsistent und transparent zu treffen ist ebenfalls Architektur- und vor allem Architekturbewertungsaufgabe.

Dinge die man später noch einfach ändern kann, fallen nicht in dieses Schema. Sie werden am besten auf einfache Weise direkt umgesetzt.

Anmerkung: Die bloße Präsenz von Architekturaufgaben hat, aus meiner Sicht, nichts mit der Notwendigkeit eines Architekten zu tun.

Ausblick

Wie man qualitative Anforderungen und Risiken nun entsprechend festhält und auch in agilen Projekten verankert (ohne diese schwergewichtiger oder weniger kundenorientiert zu machen), wird Thema eines folgenden Blogeintrags. Danach werde ich auch darauf eingehen wie Architekturbewertung effektives Feedback ermöglicht und dabei Gedanken des „Lean Development“ aufgreift.