Liebe Leser,
inspiriert durch unzählige Artikel, erlebte Diskussionen, Vorträge, etc. wollte ich meine ganz persönliche Definition von Software Architektur in diesem Beitrag zum Besten geben. Anfänglich dachte ich an eine glanzvolle, plakative und prägnante Formulierung. Umso mehr ich darüber reflektiert habe, desto weiter habe ich mich von diesem Ziel entfernen müssen. Es gibt viele Definitionen, wovon einige ganz brauchbar sind und andere besser gleich wieder vergessen werden sollten. Von den brauchbaren betrachten alle immer nur einen Aspekt des Themas. Darum möchte ich die für mich relevanten Gedanken zur Definition von Software Architektur in Folge kurz erläutern.
Immer wieder hört man auf die Frage nach der Software Architektur eines konkreten Produktes Antworten, die sich auf die eingesetzten Technologien oder Frameworks beziehen. Eventuell wurden sogar Architekturentscheidungen rein auf Basis der Technologien getroffen. Manchmal bekommt man auch als Antwort, dass keine dedizierte Architektur existiere. Bei Ersterem ist aus meiner Sicht der Architekturansatz viel zu kurz gegriffen. Was alles in eine Architekturbetrachtung einfließen sollte, werde ich in Kürze ausführen. Die zweite Aussage ist schlicht weg falsch. Es gibt immer eine Architektur. Ob diese gut oder schlecht ist, geplant oder im Laufe der Umsetzung zustande gekommen ist, das sei dahingestellt. Extremisten unter den Verfechtern von agilen Vorgehensmodellen vertreten die Meinung, dass sich die Architektur durch Refactoring ergibt. Andere glauben daran, dass sich ein Teammitglied im Sinne der Gruppendynamik die Rolle des Architekten auferlegen wird und dann die Architektur definiert. Ich bin zwar auch ein Anhänger von agilem Vorgehen, teile dennoch nicht diese Überzeugungen.
Worum dreht sich eine Architektur?
Eine Architektur kann man aus mehreren Sichten betrachten. Hier herrscht keine Einigkeit, aber oft werden fachliche Architektur, Anwendungsarchitektur, technologische Architektur und Systemarchitektur unterschieden. Es obliegt dem Architekten in Verbindung mit dem konkreten Fall, welche Sichten für die Umsetzung betrachtet werden sollten. Wichtig ist an dieser Stelle, dass es sich nicht um eine eindimensionale Drehscheibe handelt und man immer auch eine technologieneutrale konzeptionelle Sicht vornehmen muss. Eine einfach aufbauende Herangehensweise würde ausgehend von einer konzeptionellen Architektur in eine Anwendungsarchitektur überführen, bei welcher die Konzepte verwendet werden um die fallspezifische Domäne zu beschreiben. Daran geknüpft würde man dann ein Technologiemapping vornehmen und erhält als Ergebnis eine gesamtheitliche Architektur.
Wie steht es um das Profil eines guten Software Architekten?
Eine knackige Aussage, welche ich einmal zu der Primärtätigkeit eines Software Architekten gehört habe, lautet: "ein Software Architekt erstellt eine Blaupause und die Dokumentation, wie man zu deren Umsetzung kommt". Dem kann ich mich voll anschließen. In meinen Augen entwirft ein guter Architekt ein System passend zu den von ihm selbst vorgegebenen Technologien in enger Anlehnung an den Kunden bzw. das Projekt (Produkt).
"An architect always implements"
Ich bin grundsätzlich davon überzeugt, dass diese Aussage unumstößlich ist. Ich habe sogar schon Jobangebote gesehen, wo dieser Satz – ein wenig ausgeschmückt – direkt in den Anforderungen an den Bewerber enthalten war. Ein Software Architekt hat nicht zwangsläufig Produktcode beizusteuern, aber er muss schon über die eingesetzten Technologien Bescheid wissen und diese auch ausprobiert haben und kennen, wenn gleich er lediglich auf einer Spielwiese experimentiert hat.
Ein Software Architekt muss auch eine kommunikative Persönlichkeit sein. Er hat immerhin die Aufgabe mit relativ vielen Stakeholdern zu interagieren und die Architektur zu beschreiben bzw. diese zu vermitteln.
Architektur vs. Design
Architektur kann man als strategisches Design umschreiben, bei welchem sowohl die nicht funktionalen Anforderungen, als auch die Anforderungen mit systemweitem Einfluss in die fachliche Domäne eingeführt werden. Dem gegenüber steht das taktische Design, welches mehr oder weniger den Rest bis hin zu einer Featureumsetzung abbildet.
Abschließend möchte ich noch eine Aussage von Ralph Johnson anführen, der in einer Mailingliste einmal zum Abschluss einer Diskussion über die offizielle IEEE Definition von Architektur folgenden Satz geschrieben hat: "Architecture is about the important stuff". Er hat sich darauf bezogen, dass eine Architektur auf den für die Entwicklung wichtigsten Dingen basieren sollte, welche das auch immer im konkreten Fall sein mögen. In Anlehnung daran sei es mir gestattet darauf hinzuweisen, dass Architekten keine gottähnlichen, allwissenden, alles könnenden Wesen sind, sondern im tiefsten Inneren Softwareentwickler mit hoffentlich viel Erfahrung und Weitblick.
Euer
JL@coopXarch
Keine Kommentare:
Kommentar veröffentlichen