{"id":4593,"date":"2024-11-11T16:21:28","date_gmt":"2024-11-11T16:21:28","guid":{"rendered":"https:\/\/frachtwerk.fw-web.space\/?p=4593"},"modified":"2024-11-11T16:21:29","modified_gmt":"2024-11-11T16:21:29","slug":"der-architekturentscheidungstrichter-hilfestellungen-fuer-software-architekturentscheidungen","status":"publish","type":"post","link":"https:\/\/frachtwerk.fw-web.space\/der-architekturentscheidungstrichter-hilfestellungen-fuer-software-architekturentscheidungen\/","title":{"rendered":"Der Architekturentscheidungstrichter: Hilfestellungen f\u00fcr Software-Architekturentscheidungen."},"content":{"rendered":"\n

Versetze dich in die folgende Situation: Du bist kein erfahrener Software-Architekt, ben\u00f6tigst aber kurzfristig Hilfestellungen zum Thema Software-Architektur in deinem Projekt. Wie kannst du vorgehen? Wie kann dir geholfen werden? Welcher Architekturstil ist am besten geeignet, um dein Problem zu l\u00f6sen? Diese und weitere Fragen beantworten wir im folgenden Blog Post. Hierbei verfolgen wir das Ziel, strukturiert und iterativ bei der Entscheidung f\u00fcr einen Softwarearchitekturstil zu helfen.<\/p>\n\n\n\n

Eine Entscheidung zu treffen, ist kompliziert<\/h2>\n\n\n\n

Sich f\u00fcr oder gegen verschiedene Architekturstile zu entscheiden, ist kompliziert. Wenn etwa in einem Projekt mit sehr dynamischen Anforderungen \u00c4nderungen an diesem – aus welchen Gr\u00fcnden auch immer – l\u00e4ngere Zeit oder komplett ignoriert werden, dann ist es ziemlich wahrscheinlich, dass die entwickelte Softwarearchitektur nicht zu den aktuellen Anforderungen passt. \u00c4hnlich dynamisch k\u00f6nnen auch die Anzahl und Skillsets der verf\u00fcgbaren Entwickler im Projekt sein. Wenn mitten im Projekt einige Senior-Devs das Projekt verlassen, dann kann das zu gro\u00dfen Schwierigkeiten f\u00fchren.<\/p>\n\n\n\n


Derweil sind dynamische Anforderungen und Fluktationen innerhalb des Dev-Teams nur zwei von vielen M\u00f6glichkeiten, weshalb man als Softwarearchitekt die getroffene Architekturstilentscheidung regelm\u00e4\u00dfig hinterfragen sollte. Auch argumentieren Mark Richards, Neal Ford und J\u00f8rgen W. Lang in ihrem Buch \u201eHandbuch moderner Softwarearchitektur: Architekturstile, Patterns und Best Practices\u201c in der aktuellen Ausgabe von 2020, dass das \u201eWarum\u201c wichtiger sei als das \u201eWie\u201c. Die Begr\u00fcndung f\u00fcr eine Architekturentscheidung ist also wichtiger also die Entscheidung an sich. Nat\u00fcrlich fallen Entscheidungen am Anfang eines Projekts anders aus als gegen Ende, weil man zu Beginn eines Projekts viel weniger wei\u00df als zum Projektende. Man sollte aber trotzdem zu jedem Zeitpunkt einen sinnvollen Plan haben, in welche Richtung man die Softwarearchitektur entwickeln m\u00f6chte.<\/p>\n\n\n\n


Anlehnend an den\u00a0NoSQL Decision Tree<\/a>\u00a0haben wir deshalb eine Entscheidungshilfe gesucht, mit deren Hilfe wir einen Architekturstil schnell und fundiert ausw\u00e4hlen k\u00f6nnen, ohne dabei wichtige Punkte zu vergessen. Dazu haben wir uns \u00fcberlegt, wie wir ein m\u00f6glichst vollst\u00e4ndiges Bild von verschiedenen Klassen an Anforderungen bekommen und abbilden k\u00f6nnen, um zu jedem Zeitpunkt im Projekt gut dokumentiert und begr\u00fcndet eine Architekturstilentscheidung treffen und danach die Entscheidung sinnvoll begr\u00fcnden zu k\u00f6nnen.
<\/p>\n\n\n\n

Unser Ergebnis ist der\u00a0Architekturentscheidungstrichter<\/strong>.<\/p>\n\n\n\n

<\/a>Warum ein weiteres Vorgehensmodell f\u00fcr Architekturstile?<\/h2>\n\n\n\n

In der Literatur zu Softwarearchitektur gibt es bereits unz\u00e4hlige und beliebig komplexe Vorgehensmodelle. Doch genau hier liegt das Problem: Der n\u00f6tige Zeitinvest, um ein ausreichendes Verst\u00e4ndnis f\u00fcr diese Methodiken zu erreichen, ist hoch.<\/p>\n\n\n\n

Die zwei wohl bekanntesten Schulen f\u00fcr Softwarearchitektur sind das\u00a0TOGAF-Framework<\/a>\u00a0und\u00a0ISAQB<\/a>. Sie sind jeweils nicht nur eine eigene Methodik, sondern eine Sammlung aus einer Vielzahl von Vorgehensweisen. Wer ein Zertifikat in einer dieser beiden Schulen erworben hat, kennt den hohen Zeitaufwand, der hierf\u00fcr n\u00f6tig ist.<\/p>\n\n\n\n

Aus unserer Sicht ist der Zeitaufwand gerechtfertigt, wenn man eine Karriere als Softwarearchitekt anstrebt und sich daf\u00fcr fundiertes und breites Know-How aneignen m\u00f6chte. Wir empfehlen f\u00fcr Softwarepraktiker insbesondere die ISAQB Zertifizierung. Denen von euch allerdings, die akut in einem Projekt eine Hilfestellung brauchen, um eine Architekturentscheidung zu treffen, bleibt meist keine Zeit f\u00fcr eine umfangreiche Schulung.<\/p>\n\n\n\n

Wir als Autoren dieses Artikels waren in den letzten Monaten in genau dieser Situation und suchten nach einer Hilfestellung, die mit begrenztem Zeitinvest verst\u00e4ndlich und gleichzeitig ausreichend vollst\u00e4ndig ist. Leider vergeblich. So haben wir uns selbstst\u00e4ndig einen Werkzeugkasten gebaut, der uns ohne aufw\u00e4ndige Zertifizierung bei Architektur-Themen tatkr\u00e4ftig geholfen hat. Und genau den m\u00f6chten wir mit euch teilen.<\/p>\n\n\n\n

Update<\/strong>: Wir haben in diesem Zuge an dem Thema Softwarearchitektur Freude gefunden. Manche von uns haben sp\u00e4ter selbst u. a. die ISAQB Zertifizierung durchgef\u00fchrt. Vielleicht f\u00fchlt ihr euch dazu auch ermutigt, wenn ihr dazu weiterlest!<\/p>\n\n\n\n

<\/a>Wie funktioniert der Architekturentscheidungstrichter?<\/h2>\n\n\n\n

Zur Erstellung des Vorgehensmodells haben wir aus unseren Erfahrungen die wesentlichen Fragestellungen geclustert, die f\u00fcr eine Architekturentscheidung betrachtet werden sollten. Wesentlich daf\u00fcr war u. a. die DIN ISO\/IEC 25010 \u00fcber nicht-funktionale Anforderungen, denn diese Qualit\u00e4tskriterien sind f\u00fcr den Erfolg einer guten Softwarearchitektur sehr wichtig.<\/p>\n\n\n\n

Unser Modell umfasst vier Cluster an Anforderungen, die vom Abstrakten bis ins Detail alles Wesentliche betrachten:<\/p>\n\n\n\n

    \n
  1. regulatorische,<\/li>\n\n\n\n
  2. organisatorische,<\/li>\n\n\n\n
  3. produktbezogene und<\/li>\n\n\n\n
  4. technische Anforderungen.<\/li>\n<\/ol>\n\n\n\n

    Jeder Cluster besteht aus einer Reihe an Fragen, die der Reihe nach beantwortet werden. Diese Antworten sind der Input f\u00fcr den Entscheidungstrichter:<\/p>\n\n\n\n

    \"\"\/<\/figure>\n\n\n\n

    Anhand der Antwort werden im Trichter alle m\u00f6glichen Architekturstile dahingehend bewertet, ob sie f\u00fcr das vorliegende Projekt mehr oder weniger geeignet sind. Im Ergebnis f\u00e4llt unten am Ausgang des Trichters dann der eine Architekturstil heraus, der am besten passt. Das kann auch eine Mischung aus zwei Stilen sein, wie wir sp\u00e4ter noch sehen werden.<\/p>\n\n\n\n

    In der Praxis sehen wir, dass sich Anforderungen im Projektverlauf noch \u00e4ndern. Wir haben das Modell deswegen als zyklisches Modell entworfen: Es erlaubt also Iterationen. Teilschritte, die sich nicht ge\u00e4ndert haben, k\u00f6nnen dabei einfach auf dem alten Stand belassen werden, ohne dass man Informationen vergisst.<\/p>\n\n\n\n

    Ein weiterer Vorteil: Die Beantwortung der Fragen der vier Cluster unterst\u00fctzt die Dokumentation und Begr\u00fcndung von Entscheidungen. So l\u00e4sst sich sp\u00e4ter im Projektverlauf jederzeit nachvollziehen, warum (!) eine bestimmte Entscheidung getroffen wurde. Die sich daraus ergebenden Vorteile kann man nur untersch\u00e4tzen:<\/p>\n\n\n\n