Selbst wenn Ihnen der Begriff „Softwarearchitektur“ nichts sagt, bleiben Sie dabei, denn in diesem Beitrag geht es um das warum von bestimmten Dokumenten in unseren Organisationen.

Softwarearchitektur

Softwarearchitektur ist laut des Software Engineering Institute der Carnegie Mellon University der konzeptuelle Klebstoff, der jede Phase des Projekts für seine vielen Akteure zusammenhält (“Software architecture is the conceptual glue that holds every phase of the project together for its many stakeholders.”) [1]. Softwarearchitektur ist etwas, das auch entsteht, wenn sich keiner explizit damit beschäftigt. Jede Software, jedes System hat eine Architektur. Um es frei nach Paul Watzlawick [2] zu sagen: Man kann nicht keine Softwarearchitektur erzeugen.

Mit unserem Team bei Elektrobit begleiten wir bisweilen Organisationen in Fragen rund um Software- und Systemarchitektur [4]. Dabei spielen oft Hardwareaspekte eine Rolle, also wie etwa eine zukünftige Fahrzeug E/E-Architektur aussehen sollte, und ganz konkret wie zentrale Steuergeräte, so genannte Domain Controller oder Cluster ECUs in sich beschaffen sein sollen. So spannend diese Fragen auch sind: Das ist oft eher kompliziert als komplex, weil es dafür in weiten Teilen gute Vorgehensweisen gibt. Technische Fragestellungen sind es, die eben tiefe Analyse, viel Nachdenken, lange Erfahrung, wohlgewählte Experimente benötigen, um dann zu einer Software- und Systemarchitektur zu kommen, die meist Anforderungen an Performance und Kosten, aber auch Erweiterbarkeit und Wartbarkeit und ganz besonders auch funktionale Sicherheit (Safety) sowie Informationssicherheit (Security) erfüllt.

Was wir ebenso feststellen ist, dass Architektur ganz oft a posteriori dokumentiert wird. Man schaut also, was sich an Architektur in System und Software ergeben hat, und schreibt diese dann auf. Das muss per se nicht schlecht sein, nur sollte die Organisation dann nicht so tun, als wäre die Architektur immer noch der Ausgangspunkt [5]. Das Aufschreiben kann prosaisch erfolgen, ganz oft informell in Office-Werkzeugen wie Visio oder PowerPoint, informell in sehr frei interpretierten UML/SysML-Diagrammen, oder semiformal ebenfalls in UML/SysML-Diagrammen.

Auch fordern dann wunderbare Prozessbeschreibungen ganz bestimmte Diagrammtypen oder Zeichnungsarten.

Dysfunktionale Architekturarbeit

Und Wunder oh Wunder: Die Diagramme werden gezeichnet, ohne dass sie jemals jemand wieder ansieht oder gar für anstehende Architekturentscheidungen verwendet. Für diese Entscheidungen ziehen die Ingenieure dann eher komplett informelle Zeichnungen zu Rate, die sie selbst erzeugt haben statt die derjenigen Kollegen, die eigentlich für die Softwarearchitektur da wären.

Wessen Schuld ist das? Falsche Frage. Wir suchen nicht nach Schuldigen, wir stellen fest, dass das System der Zusammenarbeit nicht funktioniert [3, 6].

Denn das beschriebene Szenario hat mehrere gravierende Nachteile:

1. Die Lebens- und Arbeitszeit des Architekten wird verschwendet, wenn keiner dessen Artefakte nutzt.
2. Der Entwickler, der nochmals für sich nützliche Zeichnungen anfertigt, verbraucht extra Zeit.
3. Die vom Prozess eingeforderte Architekturdokumentation korreliert schlecht mit dem tatsächlichen System, weil ja keiner sie nutzt.
4. Die fehlende Architektursicht, die ja Nachhaltigkeit sicherstellen sollte, führt zu „Technischen Schulden“ (engl. technical debt) und stellt damit ein Entwicklungsrisiko dar.

Und das, ohne dass jemand zwingend irgendetwas falsch gemacht hätte. Wie so oft gilt auch hier: wenn mehrere Personen miteinander zusammenhängend Unsinn machen, dann könnte das System kaputt sein. Dann verkommt Softwarearchitektur zu Business-Theater [7, 8].

Reifegradmodell-zentriertes Systems Engineering

Mit arc42 [9] als prominentem Beispiel existieren einige etablierte Methoden für Design von Softwarearchitekturen. UML und SysML haben sich als grafische Notation weitgehend durchgesetzt. Vereinzelt findet sich an der Stelle auch Simulink, das Ingenieure normalerweise ja für dynamische Modellierung von Systemverhalten nutzen.

Die Kernfrage ist jedoch: Wieso schreibt eine Prozessanweisung den Entwicklungsteams eine bestimmte Menge an Diagrammen vor, die diese dann gar nicht weiter aktiv benutzen?

Diagramme werden vorgeschrieben, weil Entwicklungs-Reifegradmodelle wie SPICE (ISO/IEC 15504–5) [3], CMMI [11] oder im Automobilsektor Automotive SPICE (kurz AutoSPICE oder ASPICE) [12] eben für bestimmte Stufen die Existenz von Architekturmodellen vorschreiben. Weil die Entwicklungsorganisation die Zertifizierung nach Reifegradmodell haben möchte, sorgt sie dafür, dass dieser Forderung Genüge getan wird. Und vergisst dabei den tieferen Sinn mancher Forderung.

Wie ginge es besser?

Wer ist der Nutzer des Architektur-Dokuments?

Was ist besser als das Abfrühstücken von Artefakten für ein Reifegradmodell? Indem wir uns erinnern, wozu es die Architektur-Diagramme eigentlich gibt.

Diagramme und Modelle existieren, damit wir Kollegen eine Grundlage für deren Designentscheidungen geben können. Das, was wir an Information in Softwarearchitekturen zusammentragen, dient der besseren Entscheidungsfindung im täglichen Arbeiten.

Dokumentiere Softwarearchitekturen für Menschen, nicht für Prozesse.

Joachim Schlosser

Aber dem Prozess muss doch gefolgt werden, mag da mancher nun ausrufen. Ja, aber wenn der Prozess Quatsch ist, dann muss man ihn ändern. Aber im SPICE steht doch drin, dass ich Architekturmodelle machen muss. Ja, aber da steht nicht drin, genau dieses Diagramm zu verwenden, wenn es keiner in der Realität der Organisation braucht.

Bei jedem Diagramm ist also zu ergründen: Wer sind ganz konkret die Nutzer des Architektur-Dokuments? Welche Art Information brauchen diese zu verschiedenen Zeitpunkten über die Architektur?

Das kann für ein System eine andere Antwort sein als für das nächste System. Es liegt in der Absprache.

Gute Vorgehensweise in Softwarearchitektur ist nutzerzentriert.

Joachim Schlosser

„Nutzer“ meint hier eben nicht den Anwender des Systems, sondern die Anwender der Softwarearchitektur.

Softwarearchitekt als Systemingenieur

Softwarearchitektur dient letztendlich der Zusammenarbeit, wobei Zusammenarbeit nicht Selbstzweck ist, sondern ja ein Ergebnis im Außen erzeugen soll. Softwarearchitektur dient also mittelbar der Schaffung eines Wertes in Form eines Produkts oder Projekts.

Und ja, das beinhaltet auch Aspekte, die nicht direkt in Features ausgedrückt werden können, wie Wartbarkeit, oder das Erfüllen von Qualitätskriterien, die ein Kunde verlangt [13]. Denn ohne die Korrektheit bezüglich der „nichtfunktionalen Anforderungen“ besteht immer das Risiko, dass das Produkt nicht abgenommen wird, oder gar spätere Schäden geltend gemacht werden.

Softwarearchitektur selbst hat also Nutzer und ist selbst als Gewerk aufzufassen.

Der Softwarearchitekt hat damit eben nicht die Aufgabe, UML-Bildchen zu malen, sondern als eine Art Systemingenieur dafür Sorge zu tragen, dass Projektbeteiligte die Rahmenbedingungen ihrer eigenen Aktivitäten in der Entwicklung kennen und verstehen können.

Welche Teile der Softwarearchitektur brauchen wir dann?

Die Antwort ist ebenso simpel wie schwierig: Softwarearchitektur muss genau den Mehrwert des besseren Systemverständnisses liefern, und zwar passgenau auf die anstehenden Entscheidungen.

Stellt irgendeiner der Projektbeteiligten – also nicht nur der Projektleiter! – fest, dass außerhalb der Softwarearchitektur Bildchen gemalt werden, die im weitesten Sinne jedoch der Architektur zuzuordnen sind, dann sollten sich der Softwarearchitekt und der Bildermaler unbedingt zusammensetzen und herausfinden, was letzterer braucht und in den vorhandenen Architekturmodellen nicht findet.

Und andersherum: Sichten der Softwarearchitektur, die niemand benutzt, braucht auch keiner erstellen. Gute Trainings – so auch das, was wir anbieten [14] – lehren übliche Modellierungsarten und Diagramme, aber eben immer nicht als Pflicht, sondern als Angebot. Es hilft, seine Diagrammarten zu kennen, um dann das benutzen zu können, das auf die Fragestellung passt, und auf Entwurfsmuster („Pattern“) zurückzugreifen [15].

Ein strikter Pragmatismus ist anzuraten bei gleichzeitig strikter Modellierung. Wenn schon UML-Modellierung, dann bitte in korrekter Syntax und Semantik. Es hilft niemandem, wenn es für jedes Diagramm im Kopf der erstellenden Person seitenweise Gedanken gibt, wie das Diagramm zu interpretieren ist und UML-Konstrukte anders verwendet wurden, als sie definiert sind. Sie sollten generell für die zu transportierende Information die geeignete Darstellungsform wählen: Text, Aufzählung, Tabelle, oder eben UML/SysML-Diagramm. Wenn Sie eine vollständig modellbasierte Entwicklung beabsichtigten, bei der der Code am Ende generiert wird, dann kann man in diesen Tools zu einzelnen Views und Diagrammen viele Zusatzinfos angeben, die über UML/SysML hinausgehen: Beschreibungen, Verlinkte Requirements, und so weiter,  damit aus dem Modell nicht nur der Code, sondern auch die Dokumentation generiert werden kann. Und wenn schon Simulink für Architektur, auch dann bitte korrekt, und den Vorteil der Simulation nutzend.

Nicht nur für Softwarearchitektur

Wenn Sie bis hierher gelesen haben und selbst gar nichts mit Softwarearchitektur zu tun hast, dann haben Sie‘s bestimmt schon gemerkt: Überall, wo „Softwarearchitektur“ steht, könnte auch „Formular“ oder „Dokument“ stehen. Das gilt überall. Wenn nicht mehr bekannt ist, wozu ein Artefakt gut ist, dann lohnt es sich, darüber zu diskutieren. Wenn Menschen in Organisationen Artefakte erschaffen, die sie laut Rolle eigentlich nicht selbst erzeugen müssten sondern zugeliefert bekommen, dann muss man gucken, was weiter vorne schiefläuft.

Prinzipien für sinnvolle Softwarearchitekturen

Ja an was soll ich mich im Projekt denn dann überhaupt halten in Sachen Softwarearchitektur?

1. Die Softwarearchitektur ist für die Entwicklung da, nicht umgekehrt und nicht für den Prozess.
2. Softwarearchitektur ist niemals Selbstzweck.
3. Softwarearchitektur-Modelle, die niemand braucht, können weg.
4. Für jedes Diagramm der Softwarearchitektur ist festgehalten, welchem Zweck dieses dient.
5. Architekturähnlichen Bilder sollten in die Softwarearchitektur hinein, nicht wild und frei existieren.
6. Artefakte der Softwarearchitektur werden behandelt wie jedes andere Software-Artefakt.
7. Artefakte der Softwarearchitektur werden automatisiert so einfach wie möglich allen Projektbeteiligten zugänglich und präsent gemacht.
8. Softwarearchitektur wird in allgemeinverständlichen Notationen niedergeschrieben.
9. Missbrauch von Modellierungskonstrukten führt zu Missverständnis und stellt deshalb ein Geschäftsrisiko dar.

Was tun als Projektleiter, als Abteilungsleiter, als Softwarearchitekt?

Verletzt Ihre Softwarearchitektur oder die Art, wie Sie mit Softwarearchitektur umgehen, obige Prinzipien, dann sprechen Sie darüber. Machen Sie es zum Thema. Ein Prozess der gewisse Eigenschaften der Arbeit an der Softwarearchitektur fordert, war (hoffentlich) zu seiner Entstehung sinnvoll, muss es jedoch jetzt nicht mehr sein. Ändern Sie den Prozess, wenn es sinnvoll ist. „Weil das schon immer so sein muss” oder „weil der Prozess es fordert“ ist ein ganz schlechter Grund für Softwarearchitektur.

Kein Kunde zahlt Ihnen Geld, weil Sie als Projektleiter einen unpassenden Prozess befolgen, als Softwarearchitekt unnütze Diagramme malen oder als Abteilungsleiter auf Einhaltung von nicht länger passenden Prozessen pochen. Der Kunde zahlt Ihnen Geld, weil ein sinnvolles, nützliches, langlebiges, wartbares Lieferergebnis herauskommt.

Literatur

1. Software Architecture, https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=21328, last accessed 2019/10/01.
2. Gelesen: Paul Watzlawick – Wie wirklich ist die Wirklichkeit? Wahn, Täuschung, Verstehen. « Dr. Joachim Schlosser, https://www.schlosser.info/gelesen-paul-watzlawick-wie-wirklich-ist-die-wirklichkeit-wahn-tauschung-verstehen/.
3. Softwarearchitektur als Mittel der Zusammenarbeit « Dr. Joachim Schlosser, https://www.schlosser.info/softwarearchitektur-zusammenarbeit/.
4. Elektrobit: Architecture & strategy consulting, https://www.elektrobit.com/services/consulting/software-architecture/.
5. Boris Gloger: Vom Ende der Software-Architektur, https://insightsbyborisgloger.com/2019/09/27/vom-ende-der-software-architektur/, last accessed 2019/09/30.
6. Simon, F.B.: Einführung in die systemische Organisationstheorie. Carl-Auer-Systeme Verlag, Heidelberg (2018).
7. Kundennutzen statt Businesstheater: Zurück an die Arbeit « Dr. Joachim Schlosser, https://www.schlosser.info/kundennutzen-statt-businesstheater-zurueck-an-die-arbeit-lars-vollmer/.
8. Vollmer, L.: Zurück an die Arbeit! wie aus Business-Theatern wieder echte Unternehmen werden. Linde international, Wien (2016).
9. Dr. Peter Hruschka, Dr. Gernot Starke: arc42, https://arc42.de/, last accessed 2019/10/01.
10. ISO/IEC 15504-5:2012 Information technology – Process assessment – Part 5: An exemplar software life cycle process assessment model. International Standardization Organization (2012).
11. CMMI for Systems Engineering/Software Engineering. Version 1.1 Continuous Representation. Software Engineering Institute, Carnegie Mellon University, Pittsburgh (2002).
12. Automotive SPICE Process Reference Model / Process Assessment Model. VDA Quality Management Center (2017).
13. ISO/IEC 25010 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE. International Standardization Organization (2014).
14. Software architecture for the automotive industry training – inhouse, https://www.elektrobit.com/consulting
15. Richards, M.: Software Architecture Patterns. O’Reilly Media, Inc. (2015).

Photo: www.joachimschlosser.de, License Creative Commons Attribution Share-Alike

Offenlegung: Durch meinen Arbeitgeber Elektrobit Automotive verdiene ich meinen Lebensunterhalt auch mit der Lösung derlei Fragestellungen. Dieser Artikel teilt meine eigene Meinung und stellt keine Firmenverlautbarung dar.