Oft steckt der Teufel im Detail, manchmal geht es aber auch um das große Ganze. Zum Beispiel bei Softwarearchitekturen. Hier stehen die grundlegenden Strukturen eines Softwaresystems im Mittelpunkt. Und diese Systeme werden in puncto Bedeutung für das Unternehmen und Funktionsfähigkeit bewertet. Wie das typischerweise ablaufen kann, beschreibt dieser Blogbeitrag.
1. Dezember 2022
© iStock/noppadon sangpeam
Bei Softwarearchitekturen geht es nicht darum, sich in eine endlose Abfolge von Code-Zeilen zu vertiefen. Software-Architektur beschreibt das große Ganze. Grundlegende Strukturen eines Softwaresystems, deren Komponenten und Zusammenhänge durch sie beschrieben werden. Aber warum möchte man eine Softwarearchitektur bewerten? Das hängt damit zusammen, dass die Software eines Unternehmens einen wichtigen Wert und Wettbewerbsfaktor darstellt. Qualität und Quantität des gefertigten Produktes oder einer angebotenen Dienstleistung hängen maßgeblich vom reibungslosen Funktionieren der Software ab. Und diesen Zustand gilt es zu erhalten.
Dies vor Augen, sollte sich jedes Unternehmen regelmäßig fragen, ob die verwendete Software noch alle an sie gestellten Anforderungen erfüllt. Auch gilt es zu ermitteln, ob ein dauerhafter Erhalt der Wettbewerbsfähigkeit im Kontext der Software gewährleistet ist: Lässt die Software mögliche Erweiterungen zu oder können die viel zitierte Digitale Transformation bzw. Teile davon umgesetzt werden?
An dieser Stelle kommt die Softwarearchitektur-Bewertung ins Spiel. Sie kann Klarheit schaffen und Informationen liefern, auf deren Grundlage betroffene Unternehmen wiederum Entscheidungen über die weitere Verwendung ihres Softwaresystems treffen können. Dabei sollte auch ein Unternehmen mit eigener Expertise auf die Unterstützung eines externen Partners zurückgreifen. Denn der Blick von außen, jenseits der eigene Perspektive, verbunden mit der Kenntnis aktueller Entwicklungen und Trends, ermöglicht eine objektive und am aktuellen Stand der Technik ausgerichtete Bewertung.
Das Fraunhofer-Institut für Kognitive Systeme IKS unterstützt Unternehmen und Organisationen beim Software-Engineering für sicherheitskritische Anwendungen, beispielsweise in der Produktion. Das umfasst auch die Softwarearchitektur-Bewertung. Daher sind den Forscherinnen und Forschern des Instituts viele Sorgen und Nöte der Partner bekannt. Oftmals ist es Unsicherheit, ob und wie man auf die Vielzahl an technischen Entwicklungen und ständig neu aufkommenden Trends richtig reagieren soll. Eine Softwarearchitektur-Bewertung kann bei solchen Entscheidungen helfen: Ist etwas zu verändern, welche Veränderungen helfen wirklich und wie werden sie richtig umgesetzt?
Eine typische Softwarearchitektur-Bewertung ist eine schrittweise Analyse der Programmstruktur. Schritt für Schritt wird diese verfeinert und am Ende des Weges liegt eine konkrete Bewertung der wesentlichen Softwareteile vor.
Am Anfang muss ein klarer Rahmen abgesteckt werden. Möglichst konkret ist zu klären, was durch die Softwarearchitektur-Bewertung tatsächlich erreicht werden soll. Oft ist eine Bewertung gewünscht, inwiefern bestimmte Ziele mit der vorliegenden (oder auch neuen) Softwarearchitektur erreicht werden können. Ob Business-, Technologie- oder Qualitätsziele: Stets sollte eine möglichst konkrete Formulierung angestrebt werden.
Softwaresysteme sind oftmals umfangreiche und enorm komplexe Gebilde. Bei einer Softwarearchitektur-Bewertung kann nicht jede Code-Stelle betrachtet werden. Eine gezielte Eingrenzung ist unumgänglich. Gemeinsam mit dem Kunden ist dabei festzulegen, welche Systembereiche für die Analyse von zentraler Bedeutung sind und welche Systembereiche nicht berücksichtigt werden sollen bzw. nur auf äußere Schnittstellen reduziert werden können.
Für die Bewertung von Softwarearchitekturen ist ein hohes Maß an Wissen und Erfahrung notwendig. Aber auch ohne Unterstützung des Kunden geht es nicht. Es muss daher festgelegt werden, wer (welche Stakeholder) von Kundenseite den Bewertungsprozess durch die Bereitstellung von Hintergrundwissen als auch bei der anstehenden Herausarbeitung konkreter Zielstellungen unterstützt.
Diese initiale Abstimmungsphase muss zu einem klar kommunizierten und von allen Seiten akzeptierten Rahmen sowie einer abgestimmten Vorgehensweise führen. In einem Kundenprojekt lässt sich das sehr gut in einem Tages-Workshop umsetzen. Dieser bietet die Möglichkeit, mit einer generellen Vorstellung der Softwarearchitektur-Bewertung zu starten und anschließend den sinnvollen Rahmen und die notwendigen Vorgehensschritte herauszuarbeiten.
Für eine tiefergehende Betrachtung der Softwarearchitektur werden anschließend Interviews mit den verschiedenen Stakeholdern durchgeführt. Hierbei treten Stärken als auch Schwächen der Softwarearchitektur zu Tage. Gleichzeitig werden die Interviewpartner aufgefordert, Wünsche und konkrete Anforderungen an die Software-architektur zu äußern. Unterschiedliche Stakeholder (z.B. aus der Entwicklung, dem Marketing oder Management …) haben dabei unterschiedliche Perspektiven. Dinge werden aus der jeweils eigenen Sicht beschrieben und priorisiert. Ergebnis der Interviews ist ein umfangreicher und unstrukturierter Bestand an Informationen.
Häufig zielt die Softwarearchitektur-Bewertung auf die Bewertung qualitativer Anforderungen ab. Für die notwendige Überführung der Interviewergebnisse in ein strukturiertes Modell kann in diesem Fall auf das standardisierte Software Product Quality Model des ISO 25010 zurückgegriffen werden. Hier werden die wichtigsten Qualitätskategorien und Subkategorien erfasst. Durch das Mapping der Interviewergebnisse auf die Kategorien entsteht eine leichter handhabbare Struktur aus Qualitätsanforderungen. Die einzelnen Qualitätsanforderungen werden anschließend durch die Einführung individueller Architekturtreiber weiter verzweigt: Jeder Architekturtreiber beschreibt dabei ein individuelles Szenario, das einen bestimmten Aspekt innerhalb der jeweiligen Qualitätsanforderung abbildet. Die Szenarien weisen jeweils ein Stimulus-Response-Schema auf und lassen sich anhand einer Metrik überprüfen.
Bevor der eigentliche Bewertungsprozess in Gang gesetzt wird, sollte ein weiterer Workshop mit dem Projektpartner stattfinden. Dabei sind die Architekturtreiber zu diskutieren und für den weiteren Bewertungsprozess zu priorisieren. Am Ende des Workshops sollte klar sein, welche Qualitätsanforderungen und zugehörigen Architekturtreiber im Projektverlauf untersucht werden und wie der dazugehörige Bewertungsprozess abläuft.
Gibt es eine Vielzahl an Qualitätsanforderungen und Architekturtreibern zu bewerten und steht dem nur ein begrenztes Projektbudget gegenüber, kann es ratsam sein, nachfolgende Analyseschritt in einem agilen Prozess anzugehen. In aufeinander folgenden Sprints können Qualitätsanforderungen und Architekturtreiber stets neu priorisiert und so flexibel für die weitere Bearbeitung ausgewählt werden. Der Kunde bestimmt also mit, was im Rahmen des Projektes bewertet wird. Die in einem Sprint bereits gewonnenen Erkenntnisse fließen bei der Zusammenstellung des nächsten Sprints direkt mit ein.
Die eigentliche Softwarearchitektur-Bewertung startet mit der Analyse der vorliegenden Architekturdokumente. Ziel ist die Sammlung und Beschreibung aller für die Bewertung relevanten Design Decisions. Dabei werden Pros & Cons, Annahmen und Kompromisse erfasst. Für die Bewertung eines einzelnen Architekturtreibers bzw. der damit verbundenen Anforderung an das vorliegende System, betrachtet man nun alle speziell hierfür verantwortlichen Design Decisions. Es wird aufgezeigt, wie die Design Decisions wirken und welche Vor- und Nachteile daraus erwachsen. Letztendlich wird auf dieser Basis eine Abschätzung der Eignung bestimmter Design Decisions für die Erfüllung der mit dem Architekturtreiber verbundenen Anforderungen vorgenommen. Nach einer umfassenden Abwägung kann der Architekturtreiber, z. B. auf einer Skala von 1-5 (n/a, no, partial, large, full), bewertet werden.
Gleichzeitig werden Vorschläge unterbreitet, welche technischen Lösungen die mit einem Architekturtreiber verbundenen Anforderungen noch besser erfüllen können.
Für den Abschluss des Projektes sollte wiederum ein Workshop organisiert werden, auf dem alle Bewertungsergebnisse detailliert vorgestellt werden.
Kontaktieren Sie unseren Autor Dr. Erik Oswald, erik.oswald@iks.fraunhofer.de
