Die Software-Architektur eines Software-Systems umfasst vor allem die Entscheidungen, die für das System weitreichende, querschnittliche Auswirkungen haben und später schwer zu ändern sind. Dass solche Architekturentscheidungen gut begründet sein sollten, liegt also auf der Hand.

Ich wurde in den letzten Jahren ziemlich oft mit der immer wieder gleichen Begründung für Architekturentscheidungen konfrontiert: „Das macht man heute so!“

Das hört sich im ersten Moment nach einer plausiblen Begründung an. Ist es aber nicht!

In diesem Artikel möchte ich diese Begründung genauer unter die Lupe nehmen. Dabei schauen wir uns an, warum diese Begründung so oft kommt und was die Konsequenzen so getroffener Entscheidungen sind.

Baustile in der Gebäudearchitektur erscheinen auf den ersten Blick vielleicht ähnlich. Beim romanischen oder gotischen Stil war es tatsächlich so, dass in gewissen Zeitaltern bevorzugt in einem gewissen Stil gebaut wurde. Aber einerseits spiegeln diese Baustile viel die technischen Möglichkeiten der jeweiligen Zeitalter wider und andererseits haben sie auch sehr viel ästhetische Anteile, für die es bei der Softwarearchitektur keine direkte Parallele gibt. Deshalb sollte man sich also nicht unreflektiert der Analogie bedienen.

”Conference-Driven Software Architecture“

Es gibt einige absolute Paradebeispiele, bei denen gerne das Argument „Das macht man heute so!“ gerne gezogen wird:

• Microservices
• Container-Technologien wie Docker, Kubernetes, …
• UIs mit Technologien wie React
• Event-Orientierung
• KI-Modelle für bestimmte Funktionalitäten

So ist scheinbar mühelos und schnell eine „Software-Architektur“ skizziert, indem einige dieser Architekturstile oder auch Technologien ausgewählt werden.

Auf zahlreichen Architektur- und Entwickler-Konferenzen werden wir mit Vorträgen zu diesen Themen versorgt. Je nach angesagtem Trend bekommen wir gleich mehrere Vorträge zu einem der Themen geboten.

Ganz wichtig: Die Vorträge sagen meist nicht, dass „man das heute so macht!“. Vielmehr ist es ja gut, zu sehen, was wiederkehrende Architekturmuster sein können und wie diese zum Einsatz kommen können. Zur Beschreibung eines sinnvollen Patterns gehören aber immer mehrere Bestandteile:

• Was ist das wiederkehrende Problem?
• Was sind passende Kontexte zur Anwendung?
• Was ist die beschriebene, wiederverwendbare Lösung?

An dieser Stelle wird es dann aber oft dünner in den Vorträgen: Bei vielen Vorträgen hat man den Eindruck, dass sie schon annehmen, dass alle Zuhörer wissen, was die geeigneten Einsatzzwecke wären und dann erläutern sie einen bestimmten (meist eher technischen) Aspekt in der Tiefe.

Aber alleine die schiere Masse an Informationen zu einem bestimmten Hype-Thema hinterlässt dann wohl häufig beim Publikum den Eindruck, „dass man das heute wohl so macht!“. Ohne dass überzeugende Gründe für den eigenen Fall genannt wurden.

Gefährliche Vorbilder

Solche Vorträge oder auch ausführliche Beschreibungen in Blog-Artikeln kommen häufig von namhaften Unternehmen oder Beratern. Dies stärkt weiter die Konfidenz, dass da ja was dran sein muss an diesen Lösungen und „man das heute so macht!“.

Unternehmen, die ihre Erfahrungen teilen, haben aber meist überhaupt nicht die Absicht, diese Message zu transportieren. Große Beratungsunternehmen müssen sich manchmal schon dem Verdacht stellen, gewisse Hype-Themen auch anzufeuern, um dann davon zu profitieren, egal ob das im jeweiligen Fall sinnvoll ist oder nicht.

Es gibt mehrere große Gefahren, wenn solchen Vorbildern ohne tieferes Hinterfragen gefolgt wird und eine Architekturentscheidung nur getroffen wird, weil viele andere das auch schon so gemacht haben:

• Die Systeme, für die Unternehmen ihre Architekturlösungen veröffentlichen, sind typischerweise ganz anders als das eigene System
  • Sie haben andere AnforderungenSie sind oft sehr groß und massiv skalierendSie werden oft durch ein großes Team entwickeltSie haben oft sehr viel Geld verschlungen
  • Sie wurden nicht unbedingt so konzipiert, sondern sind das Ergebnis längerer Evolution
• Beschreibungen zu Architekturlösungen auf Konferenzen müssen Schwerpunkte setzen
  • Viele detaillierte und auch herausfordernde Aspekte wurden dann doch nicht beschrieben.
  • So erscheint eine Lösung dann einfacher umzusetzen als es tatsächlich ist
• Beschreibungen zu Architekturlösungen auf Konferenzen fokussieren oft auf Technik und Technologie
  • Vorträge können vor allem die technischen Aspekte gut transportieren, weil diese besser übertragbar sindFachlichkeit kommt meist zu kurz und ist nicht übertragbar
  • So werden dann Architekten verleitet, zu viel Aufwand in die Konzeption von Technik zu investieren und die Fachlichkeit zu vernachlässigen
• Gerade wenn Architekturlösungen mehrerer Hype-Themen in einem System zusammen verwendet werden, fehlt es häufig an der sauberen Integration der Lösungen

„Das macht man heute so!“ ist eine Art Totschlagargument. Viele Leute trauen sich dann nicht mehr zu hinterfragen oder zu widersprechen, wenn jemand zahlreiche Big Player anführt, deren Architektur angeblich auch so designed wurde. Und das Management hört es auch oft gerne, „wenn man sich an bewährten Ansätzen orientiert“.

Dein System hat individuelle Architekturentscheidungen verdient

Natürlich ist überhaupt nichts dagegen einzuwenden, die obengenannten Lösungsmuster, Architekturentscheidungen oder Technologien zu verwenden.

Aber die Begründung für Architekturentscheidungen sollte sich immer aus den konkreten und gut verstandenen Anforderungen eines Systems ergeben. Vor allem auch aus den Qualitätsanforderungen.

Wenn die Anforderungen für den Einsatz einer bewährten Lösung sprechen, dann nurzu. Aber dann ist es auch besonders wichtig, die ausgewählten Lösungen wirklich gut auszugestalten und sauber miteinander zu verzahnen.

Ansonsten endet die Architektur als wildes Sammelsurium von schlecht verstandenen und kaum nutzbringenden Lösungsbestandteilen. Die dann auch noch aufwändig zu bauen und schwer zu warten sind.

Mein Wunsch für ”Das macht man heute so!”

Das gerade beschriebene Vorgehen ist dann nicht mehr und nicht weniger als ein methodisch sauberes und pragmatisches Vorgehen bei der Architekturarbeit.

Und über genau dieses Vorgehen wünsche ich mir, dass in Zukunft viel öfter gesagt wird „Das macht man heute so!“. Das führt dann auch automatisch dazu, dass Architekturentscheidungen zur geeigneten Erfüllung gut verstandener Anforderungen getroffen werden.

Wann hast du schon mal gehört „Das macht man heute so“ und wie seid ihr dann damit umgegangen?