Eine nutzenorientierte Betrachtung Wie viel Architektur/Modell darf ‘s denn bitteschön sein?

Das Interesse an Architekturarbeit und modellbasierter Entwicklung steigt auf Software- und Systemebene unentwegt an. In der Praxis herrscht aber eine gewisse Unsicherheit, wann was in welchem Umfang zu betrachten oder zu modellieren ist. Zur besseren Orientierung vermittelt dieser Beitrag einige Orientierungshilfen, Ziele und Nutzen von Architekturarbeit, sowie Empfehlungen für die Umsetzung.

Anbieter zum Thema

MHP Management- und IT-Beratung GmbH

Axivion GmbH

RTI Real-Time Innovations

Fraunhofer-Institut für Experimentelles Software Engineering IESE

Das Interesse an Architekturarbeit und modellbasierter Entwicklung steigt auf der Software- und Systemebene unentwegt an. Zentrale Treiber sind dabei unter anderem die steigende Komplexität der Systeme und regulatorische bzw. Marktvorgaben. Der Blick in den Praxisalltag zeigt dabei bei vielen Firmen eine gewisse Unsicherheit wann, was in welchem Umfang zu betrachten beziehungsweise zu modellieren ist. Auf folgende Fragen erhält man dann oftmals keine oder nur vage Antworten:

• Zu welchem Zweck modellieren Sie diese Sichten / Inhalte?

• Wie detailliert müssen Sie dies modellieren, beziehungsweise wann können Sie aufhören?

• Wie wird der Modellinhalt später wann von wem genutzt?

• Welcher Nutzen entsteht dadurch der Firma/den einzelnen Abteilungen?

• Wie wird der Nutzen transparent gemacht?

• Wie halten Sie die Modelle möglichst effizient aktuell?

• Sind die Inhalte in einer wiederverwendbaren Form dokumentiert?

In der Konsequenz ergibt sich dabei oftmals ein ungutes Gefühl, ob hier nicht am Bedarf vorbei gearbeitet wird.

Zur besseren Orientierung möchte dieser Beitrag einige Orientierungshilfen vermitteln. Zunächst werden typische Treiber hinter dem steigenden Interesse gelistet, dann wird besprochen was passiert, wenn am Bedarf vorbei gearbeitet wird. Anschließend werden typische Nutzungsszenarien von Architekturmodellen aufgezeigt und der dafür erforderliche Modellumfang sowie die Modellqualität abgesteckt. Einflussfaktoren, die sich auf den Modellierungsumfang und -zeitpunkt auswirken, werden dabei ebenfalls betrachtet.

Treiber für steigendes Interesse

Über alle Anwendungsbereiche hinweg hat das Interesse an Architektur- und Modellierungsarbeit auf der System- und Softwareebene in den letzten Jahren deutlich zugenommen. Während noch vor 10 Jahren vor allem Early Adopters eifrig am Werk waren, breitet sich die Architekturarbeit und die Verwendung von SysML/UML-Modellen in den letzten Jahren deutlich aus. Dies zeigt zum Beispiel auch unsere Systems Engineering Umfrage [HBK+17]. Folgende Treiber lassen sich hinter dem wachsenden Interesse identifizieren:

Zunehmende Komplexität. Die zunehmende Komplexität von Produkten, begleitet von zunehmender Vernetzung und Interdisziplinarität bei kürzeren Änderungszyklen, macht es notwendig, geeignete Modelle / Abstraktionen zu nutzen, um dieser Komplexität zu beherrschen.

Einhaltung von Standards. Kunden verpflichten ihre Lieferanten, die Prozessqualität auf einem bestimmten Reifegrad zu sichern. Dies ist derzeit z.B. in der Automotive-Domäne der Fall. Automotive SPICE [VDAQMC] ist eine Variante der internationalen Norm ISO/IEC 15504 (SPICE). Der Zweck von Automotive SPICE besteht darin, die Entwicklungsprozesse von Steuergerätelieferanten in der Automobilindustrie zu bewerten. Der Standard fordert von den Zulieferern die Entwicklung und Verwendung entsprechender System- und Software-Architekturartefakte im Laufe der Entwicklung. Da viele Unternehmen hier extrinsisch motiviert sind, suchen sie nach Ansätzen, um die notwendigen Architekturen/Modelle kosteneffizient bereitzustellen.

Höhere Abstraktionsebene. Nicht zuletzt wird die Darstellung von Systemen auf einer höheren Abstraktionsebene ermöglicht und eine Plattform für die Diskussion mit den verschiedenen Interessengruppen geschaffen, von denen einige mit dem Thema nicht vertraut sind. Dies fördert ein gemeinsames Verständnis und bietet die Möglichkeit, Unklarheiten frühzeitig zu erkennen. Eine Darstellung einer systemübergreifenden Kommunikation kann in manchen Fällen durch drei Diagramme leichter verstanden werden als durch 80 Seiten Spezifikationen. Neben der Erhöhung der Verständlichkeit kann eine Erhöhung des Abstraktionsgrades die Implementierung von Software durch die Verwendung geeigneter Modelle unterstützen. Modelle können verwendet werden, um das Verhalten zu spezifizieren und automatisch Software-Implementierungen oder Verifikations- und Validierungsartefakte abzuleiten [KSW12].

Verfügbarkeit von Werkzeugen. Die Verfügbarkeit von vielversprechenden Modellierungs- und Analysewerkzeugen motiviert viele Organisationen, Schritte hin zu einer stärker modell-basierten Entwicklung zu nehmen.

Wie viel Architektur/Modell darf 's denn bitteschön sein?

Zunächst vorweg: Die Architekturarbeit auf der System- und Softwareebene ist sehr wichtig, da hier die weitreichendsten Entscheidungen getroffen werden. Grady Booch hat dies sehr prägnant formuliert: “Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change”. In der Regel umfasst dies Entscheidungen, die mehrere Lösungsbausteine betreffen.

Leider lässt sich der Nutzen von Architektur- und Modellierungsarbeit oftmals nicht einfach messen, da sich viele positive Effekte nur mittelfristig zeigen. Deshalb kommt im Praxisalltag mancherorts die Architekturarbeit aufgrund der zeitlichen und personellen Rahmenbedingungen etwas zu kurz. Anderseits gibt es durchaus auch Organisationen, die die Bedeutung von Architektur- und Modellierungsarbeit erkannt haben und hier aufgrund der oben genannten Treiber signifikante Aufwände investieren. Dabei hilf viel aber nicht unbedingt viel. Der Bedarf an Architekturarbeit ist stark vom Kontext abhängig, z.B. vom zu entwickelndem System, von den verwendeten Technologien, dem betreffenden Team und der Zielsetzung. Dieser Zusammenhang wird auch in Abbildung 1 schematisch dargestellt. Auf das richtige Maß kommt es also an.

Wird zu wenig, zu spät oder an der falschen Stelle gearbeitet, kommt es zu kostspieligen Fehlentscheidungen, z.B. fehlende Funktionalität, inkonsistente Schnittstellennutzung, schlechte Performanz, Integrationsprobleme aufgrund zu knapper Ressourcen. Wird zu viel, zu früh, oder nicht nutzengerecht gearbeitet, entstehen Mehrkosten, denen kein realer Nutzen gegenübersteht. Diese sollten ebenfalls vermieden werden. Gerade der Übergang zu stärker modellbasierter Architekturarbeit birgt im Praxisalltag hier einige Risiken. Hier versprechen sich viele Firmen Verbesserungen, ohne eine klare Vorstellung vom Nutzen, der Nutzung und den Rahmenbedingungen zu haben. Abbildung 2 zeigt typische Fälle, wo am Bedarf vorbei gearbeitet wird.

Orientierungshilfen

Es gibt viele Arbeiten rund um Architektur- und Modellierungsarbeit. Oft ist davon die Rede,was darunter zu verstehen und wie alles zu tun ist. Das Wozu bleibt dabei manchmal unklar. Daher werden zur besseren Orientierung in Abbildung 3 zunächst Ziele und Nutzen der Architekturarbeit aufgelistet [Schäfer2020][Starke2018]. Diese sind zunächst nach Wichtigkeit für das aktuelle Projekt zu priorisieren.

Automotive SPICE [VDAQMC] liefert mit den Prozessen SYS.3 System Architectural Design und SWE.2 Software Architectural Design übrigens schon eine recht gute Richtschnur zu sinnvollen Architekturtätigkeiten.

Bevor mit der begonnen werden sollte, ist es sinnvoll sich über das Einsatzziel des Architekturmodells im Klaren zu sein. Unterschiedliche Architekturnutzungsszenarien haben unterschiedliche Architekturen zur Folge, welche gegenläufige Ziele und Prioritäten verfolgen. Wird eine Architektur gefordert, welche die Anforderungsaufnahme unterstützen soll, kann eine Operationelle Architektur hilfreich sein. Sollten die grundlegenden Anforderungen an das System bereits bekannt sein oder durch eine bereits implementierte Methode realisiert werden, bieten funktionale, logische oder eine Kombination beider Architekturmodell den größeren Mehrwert.

Ein typisches Ziel eines Architekturmodells mit dem Fokus auf der Problemanalyse ist die Entscheidungshilfe bei der Lösungsdefinition. Architekturmodelle auf der Ebene der Lösungsdefinition zielen auf die Spezifikation aus technischer Sicht ab, wie z.B. die Beschreibung technischer Schnittstellen. Ein weiteres, in der Industrie weit verbreitetes Nutzungsszenario ist die Kommunikationsunterstützung zwischen Nicht-Modellierungsexperten. Hierbei liegt der Fokus auf der Verständlichkeit der Architektur vor dem Hintergrund des Stakeholders.

Ist das Nutzungsszenario des Architekturmodells gewählt und dessen Ziele und Nutzen priorisiert, macht es Sinn, sich einen klaren Blick über die Stakeholder der Architektur und deren Anliegen und Fähigkeiten zu verschaffen. Letzteres ist insbesondere wichtig, damit die erforderliche Information möglichst effizient erhoben und bedarfsgerecht dokumentiert werden kann. Da sich diese im Laufe des Lebenszyklus verändern können, sollte auch festgelegt werden, welche Darstellung und welcher Detaillierungsgrad zu welchem Zeitpunkt sinnvoll ist. Der Aufwand zum Erlernen von Modellierungssprachen und -Werkzeugen sollte dabei nicht unterschätzt werden.

Aus der Sicht von Architekten, die oftmals über das notwendige Abstraktionsvermögen und die erforderlichen Modellierungsfähigkeiten verfügen, erscheint vieles einfach und intuitiv. Fehlen die benötigten Fähigkeiten bei den Stakeholdern, läuft man jedoch Gefahr, dass sich die Investition in die Architekturarbeit nur teilweise bezahlt macht. Daher sollten bei der Definition von geeigneten Viewpoints, die Stakeholder nach deren Präferenzen befragt werden.

In der Praxis erfolgt die Architektur-/Modellierungsarbeit oftmals sequentiell, wobei Sichten möglichst vollständig erarbeitet werden. Dies ist jedoch selten der richtige Weg. Vielversprechender ist ein iterativer und inkrementeller Ansatz, der von Mehrwert, z.B. Risikominimierung, getrieben ist. An dieser Stelle bieten die Architektur-Bücher von Coplien [CoBj2010] und Fairbanks [Fairbanks2010] interessante Ansätze. Mit der Architekturarbeit möchte man ja gerade teuren Missverständnissen / Fehlentscheidungen und langwierigen Diskussions- und Entscheidungsprozessen entgegenwirken. Hierfür sollte man stets den Fokus auf Sachverhalte setzen, die neu, riskant oder schwer zu ändern sind und eine gewisse Ungenauigkeit in den Modellen akzeptieren, falls aktuell noch nicht alle Fakten bekannt sind.

Ein Ansatz zur Priorisierung der Architekturarbeiten kann dabei die Weighted Shortest Job First (WSJF) Priorisierung aus der Agilen Entwicklung sein. Hier werden die Kosten, die durch eine Verzögerung der Arbeiten entstehen, zur Dauer der Arbeiten in Beziehung gesetzt. Auf die Architektur-/Modellierungsarbeit bezogen bedeutet dies, dass Arbeiten bevorzugt werden, die einen greifbaren Nutzen bringen, in dem sie neue Features ermöglichen oder Risiken reduzieren.

Literaturverzeichnis

[CoBj2010] James Coplien and Gertrud Bjørnvig: Lean Architecture for Agile Software Development, John Wiley & Sons Ltd, 2010.

[Fairbanks2010] George Fairbanks: Just Enough Software Architecture - A Risk-Driven Approach, Marshall & Brainerd 2010.

[HBK+2017] Heidrich, Jens, Martin Becker, Thomas Kuhn, Thomas Kleinberger, Markus Damm, and Anne Duell. "Systems Engineering as an Enabler for Future Innovation." Tag des Systems Engineering: Paderborn, 8.-10. November 2017 (2017): 87.

[KSW2012] Kaffenberger, Rüdiger; Schulze, Sven-Olaf; Weber, Hanno: "INCOSE - Systems Engineering Handbuch". v. 3.2.2-de, 2012.

[Schäfer2020] Andreas Schäfer: Methode zur modellbasierten Entwicklung von multidisziplinären Systemen in kleinen Unternehmen. Masterarbeit TU Kaiserslautern, 2020.

[Starke2018] Gernot Starke: Effektive Softwarearchitekturen, Hanser Verlag.

[VDAQMC] VDA QMC: Automotive SPICE® Process Reference Model / Process Assessment Model Version 3.1.

Dieser Beitrag stammt mit freundlicher Genehmigung des Autors aus dem Tagungsband des ESE Kongress 2020.

* Dr. Martin Becker leitet die Embedded Systems Engineering Abteilung am Fraunhofer IESE in Kaiserslautern. Zu seinen Kernkompetenzen zählt die strategische Wiederverwendung mit Software- und System-Produktlinien und das Varianten-management. Darin fokussiert er sich auf die führenden Bereiche, d.h. Requirements Engineering und Architekturdesign. In zahlreichen Transferprojekten mit Industrie-partnern in unterschiedlichen Anwendungsdomänen hat er sich insbesondere mit der Analyse, der Planung und der Umsetzung von Plattformen und Produktlinien im Bereich software-intensiver Systeme beschäftigt.

(ID:48116065)