Softwarearchitekturziele? Wer braucht schon Ziele?
In der Softwarearchitektur nimmt die Diskussion von Zielbildern viel Platz ein – schließlich muss es ein Ziel geben, auf das man hinarbeitet. Aber die Prioritäten sollten anders verteilt sein, und eigentlich sind Zielbilder auch nicht das Ziel.
- Eberhard Wolff
In der Softwarearchitektur nimmt die Diskussion von Zielbildern viel Platz ein – schließlich muss es ein Ziel geben, auf das man hinarbeitet. Aber die Prioritäten sollten anders verteilt sein, und eigentlich sind Zielbilder auch nicht das Ziel.
Zielbilder stellen dar, wie eine Architektur idealerweise aussehen sollte und in welche Teile das System zerlegt werden soll. Der Entwurf einer solchen Architektur scheint die zentrale Architekturherausforderung zu sein: kein Wunder, dass Teams dieser Aufgabe so viel Zeit einräumen.
In den meisten Fällen ist aber schon eine Architektur vorhanden. Eine neue muss eigentlich die vorhandene Architektur als Rahmenbedingungen für den Entwurf mitbetrachten. Dennoch erscheint eine Zielarchitektur sinnvoll: Schließlich muss man wissen, auf welches Ziel man hinarbeiten muss. Die vorhandene Architektur dabei mitzubetrachten, kann dazu verleiten, die Fehler der Vergangenheit zu wiederholen.
Umsetzbarkeit
Wenn das Zielbild fertig ist, muss man die Frage nach der Umsetzbarkeit stellen: Wann lässt sich das Zielbild mit welchem Aufwand erreichen? Spätestens an dieser Stelle wird oft klar, dass ein Zielbild alles andere als einfach zu erreichen ist. Aber das war auch gar nicht die Idee beim Entwurf des Zielbilds: Es soll eine Architekturutopie darstellen, die daher nicht realistisch erreichbar sein muss.
Die Diskussion über das Zielbild ist jedoch nur dann sinnvoll, wenn sie Auswirkungen auf das Projekt hat. Das Zielbild hat oft kaum noch etwas mit der aktuellen Situation zu tun. Es gibt also unzählige Stellen, an denen man auf das Zielbild hinarbeiten kann. Wo aber anfangen?
Für eine Zielbilddiskussion drängt sich der Vergleich mit einer Expedition zu einem Berggipfel auf: Natürlich ist es sinnvoll, einen Blick auf den Berggipfel in der Ferne zu werfen, um zu schauen, ob man in die richtige Richtung unterwegs ist. Aber noch wichtiger sind der nächste Schritt und der nächste Fluss oder das nächste Hindernis, das es zu überwinden gilt.
Die Metapher der Expedition nimmt an, dass man das Zielbild, also den Berggipfel, erreichen wird. Bei einem Architekturzielbild ist das nicht unbedingt so: Ich jedenfalls sehe praktisch nie Projekte, die das Zielbild erreicht haben. Das kann aber daran liegen, dass Berater*innen nur dann gebraucht werden, wenn es gilt, etwas zu verbessern, und daher kaum perfekte Projekte sehen.
Wichtiger als eine Diskussion zum Erreichen eines Zielbilds finde ich daher konkrete Maßnahmen, um in einem Projekt besser zu werden. Solche Aktivitäten müssen nicht auf die Strukturierung des Systems begrenzt sein, wie es der Begriff "Zielbild" nahelegt, sondern es können ganz unterschiedliche Aktivitäten im Bereich von Entwicklung, Betrieb oder auch Anforderungsmanagement sein. Solche Maßnahmen sind im Gegensatz zu einem Zielbild tatsächlich umsetzbar und bringen schon kurzfristig einen Nutzen.
Kein Zielbild
Eigentlich ist ein Zielbild sogar verzichtbar. Die Stakeholder eines Systems interessieren sich für Features und Qualitäten der Software wie Performance oder Sicherheit. Der interne Aufbau, den ein Zielbild zeigt, ist nur wichtig, wenn er Qualitäten wie die Wartbarkeit beeinflusst. Das Zielbild beeinflusst viele wichtige Qualitäten wie Benutzerfreundlichkeit gar nicht. Die Features und Qualitäten sind eigentlich die Ziele des Projekts. Sie haben sogar weitergehende Konsequenzen: Qualitäten wie Benutzerfreundlichkeit können wesentlich für den Erfolg eines Produkts oder gar einer Firma sein.
Die meisten Architekturdokumentationen, die ich bei Reviews oder Beratungen sehe, zeigen eine Aufteilung des Systems oder ein Zielbild, oft sogar als Hauptartefakt. Die Ziele des Projekts und die daraus abgeleiteten Features und Qualitäten finden sich nur sehr selten, obwohl sie wichtiger wären. Und genau hier wäre eine Zieldiskussion angebracht: Was soll das Projekt erreichen? Welche Features und Qualitätsziele müssen erfüllt sein? Das führt zu einem besseren Verständnis für die Domäne und damit zu einer besseren Grundlage für das Projekt.
Und dann sollte es Maßnahmen geben, um die Qualitätsziele auch tatsächlich zu erreichen. Auch das kommt in den meisten Projekten zu kurz. Schließlich mag Benutzerfreundlichkeit ja wichtig sein, aber es in der Architektur zu betrachten, unterbleibt dann doch oft.
Vielleicht ist das also der Berggipfel, den wir in Wirklichkeit in Augenschein nehmen und dann erklimmen sollten.
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer und Martin Otten für die Kommentare zu einer früheren Version des Artikels.
tl;dr
Diskussionen über Zielbilder können zwar hilfreich sein, aber nur konkrete Maßnahmen führen zu einer wirklichen Verbesserung. Und wichtiger als ein Architekturzielbild ist Klarheit über das Ziel des Projekts. ()
