Von Zeit zu Zeit wird man in seinem Leben mit einer bestimmten Art von Fragen konfrontiert, bei denen jeder - vor allem man selbst - davon ausgeht, dass man diese mit Leichtigkeit beantworten können müsste, aber: Nichts da! Just in dem Moment, in dem man zu einer Antwort ansetzt, fällt einem ein Aspekt ein, den man noch nicht bedacht hat. Und je länger man über die Antwort nachdenkt, desto tiefer steigt man in die verworrenen Feinheiten der Frage ab und kommt nach Tagen zu dem Ergebnis, dass man eigentlich mit dem Nachdenken und all den neu gewonnenen Erkenntnissen noch einmal ganz von vorne anfangen müsste.
Vor einigen Wochen war es bei mir wieder einmal so weit: Peter Bucher, MVP für ASP.NET und ein von mir äußerst geschätzter MSN-Kontakt, hat mich gefragt, wie ich eigentlich den Begriff der Softwarearchitektur definieren würde. Als Architekt, so dachte ich, müsste mir die Antwort bereits vorformuliert auf der Zunge liegen, nur noch darauf wartend, dass ich sie ausspreche. Meine spontane Antwort lautete, dass ich erst einmal einen Tag Bedenkzeit benötigte.
Aus dem einen Tag sind inzwischen einige Wochen geworden, und ich glaube, die Frage inzwischen zumindest nach bestem Wissen und Gewissen als Diskussionsgrundlage beantworten zu können. Ich bin mir sicher, dass ich mindestens einen, garantiert aber eher zahlreiche Aspekte nicht abgedeckt habe, aber eben deshalb stellt meine Antwort auch nur eine Grundlage für eine weiterführende Diskussion dar.
Der Frage von Peter liegt meines Erachtens eine andere, tiefer gehende Frage zu Grunde: Wie schreibt man gute Software? Letztendlich geht es bei der Entwicklung von Software auch in Zeiten von C#, WPF und Silverlight immer noch um das klassische EVA-Prinzip: Irgendwelche Daten werden eingegeben, sie werden verarbeitet und schließlich wieder ausgegeben. Egal, ob es sich um eine kryptische Konsolenanwendung oder eine grafisch aufpolierte und moderne Web 2.0-Anwendung handelt, die in der neuesten Hype-Technologie geschrieben wurde: Fehlt einer dieser drei Aspekte, verliert die entsprechende Anwendung ihren Sinn.
Anders formuliert: Anwendungen sind dazu da, um Probleme zu lösen, wobei das Wort Problem im weitesten Sinne gebraucht wird (auch das Schreiben einer E-Mail an meine Schwiegereltern ist in diesem Zusammenhang ein Problem, obwohl ich sehr nette Schwiegereltern habe). Man könnte also auch sagen, Anwendungen sind dazu da, um Aufgaben zu meistern, die wir ihnen stellen, und die wir ohne sie (zumeist) nicht lösen könnten. Natürlich kann ich an Stelle einer E-Mail auch einen Brief auf einer Schreibmaschine schreiben, aber das hätte dann nichts mehr mit Software zu tun.
Wann ist also eine Software gut? Dann, wenn sie die zu lösende Aufgabe löst, wenn sie also ihre Funktion erfüllt, wegen derer sie überhaupt erst geschrieben wurde. Doch dies ist - wenn nicht falsch - so doch im äußersten Maße unzureichend. Denn die Bereitstellung der Funktionalität ist zwar eine notwendige Voraussetzung, sie ist aber bei weitem nicht die einzige: Neben der Funktionalität spielen zahlreiche Faktoren wie Stabilität, Portabilität, Erweiterbarkeit, Austauschbarkeit, Wartbarkeit, ... eine Rolle - und hier kommt schnell eine weitere Frage ins Spiel: Interessant ist auf einmal nämlich nicht mehr, was gemacht wird, sondern wie es gemacht wird.
Genau das ist der entscheidende Unterschied zwischen Programmierung, Entwicklung und Architektur: Während sich die Programmierung mit dem reinen Was auseinandersetzt, beschäftigt sich Architektur mit dem Wie. Und die Schnittstelle zwischen beidem - quasi die architekturbewusste Programmierung - ist die Entwicklung. Deshalb besteht für mich auch immer ein großer Unterschied zwischen Programmierern und Entwicklern - während erstere nur versuchen, ihren Code irgendwie herunterzuschreiben, denken zweitere auch darüber nach, wie man Code beispielsweise effizient, sicher oder performant gestaltet.
Nun ist es aber auch so, dass es nicht nur einen einzigen Weg gibt, der glücklichmachend ist - das Wie kann also auf viele verschiedene Arten umgesetzt werden. So könnte der Schwerpunkt der Entwicklung beispielsweise auf eine möglichst gute Erweiterbarkeit oder eine möglichst gute Portabilität gelegt werden. Idealerweise sollten alle diese Aspekte gleichermaßen berücksichtigen, aber das ist aus Zeit-, Geld- oder sonstigen Gründen oftmals nicht möglich. Häufig schließen sich bestimmte Aspekte sogar gegenseitig aus. Performance und Plattformunabhängigkeit beispielsweise: Entweder schreibt man performanten, an eine Plattform optimierten und damit gebundenen Code - oder generischen, plattformunabhängigen Code, der dafür nicht mehr das Optimum aus der jeweiligen Plattform herausholt.
Insgesamt ergeben sich daraus viele verschiedene Stile, wie man das Wie leben kann. Und letztendlich führen diese Überlegungen, die für jede Software neu angestellt werden müssen, letztlich zu einer bestimmten Art und Weise der Herangehensweise - eben der Architektur.
Zusammenfassend könnte man also sagen, dass Architektur das vorausschauende Planen einer Software unter Berücksichtigung aller derzeitig und potenziell zukünftig relevanten Aspekte in dem ihnen zustehenden Maß ist, ohne dabei die Funktionalität aus den Augen zu verlieren, auf Grund derer die Software überhaupt erst entwickelt wird.