Anti-Pattern: Die perfekte Softwarearchitektur

Als junger Entwickler war ich naiv und ambitioniert. Ich suchte die perfekte Softwarearchitektur, einen Ansatz, den ich über alle Probleme stülpen könnte, unabhängig von der Branche, den Skalierungsanforderungen, den Sicherheitsmaßnahmen oder den Usern. Man müsste nur dieses eine Problem abstrakt lösen, dann könnte diese Architektur doch überall angewandt werden. Oder?

Dieser Artikel erklärt, warum die Suche nach der perfekten Softwarearchitektur eine Illusion ist. Aktuelle Trends und Moden diktieren oft universelle Lösungen, die jedoch die notwendige Flexibilität vermissen lassen, um im Markt zu bestehen. Das ist besonders relevant für technische Leiter und Entscheider im Mittelstand. Aber wie kann man eine Architektur gestalten, die flexibel genug ist, um sich an wechselnde Anforderungen anzupassen?

Viele Entwickler jagen dem Traum der perfekten Softwarearchitektur hinterher. Heute weiß ich: Es gibt sie nicht. Jede Organisation ist anders. Die Strukturen sind anders. Die Kunden sind anders. Die Regeln für das Unternehmen sind anders. Die Menschen sind anders. Keine Architektur kann diese Vielfalt abdecken.

Mittelständische Unternehmen müssen flexibel und anpassungsfähig bleiben, um im Wettbewerb bestehen zu können. Eine Architektur sollte nicht nur den aktuellen Anforderungen gerecht werden, sondern auch zukünftige Veränderungen berücksichtigen. Sie muss sich zusammen mit dem Unternehmen entwickeln und wachsen.

Trends in der Softwarearchitektur

Softwarearchitektur bezeichnet die grundlegende Struktur eines Softwaresystems. Sie umfasst die Komponenten, ihre Beziehungen zueinander und die Prinzipien, die das Design und die Evolution des Systems leiten. Die Wahl der Architektur beeinflusst die Entwicklung, Wartung und Skalierbarkeit der Software maßgeblich.

In den vergangenen Jahren erwiesen sich bestimmte Architekturstile als besonders populär. Dazu gehören Microservices und Serverless Computing. Microservices zerlegen Anwendungen in kleine, unabhängige Dienste, die jeweils eine spezifische Aufgabe erfüllen. Dies ermöglicht eine bessere Skalierbarkeit und einfachere Wartung einzelner Komponenten.

Serverless Computing geht einen Schritt weiter und bietet eine Architektur, bei der Entwickler keinen festen Server betreiben müssen. Stattdessen läuft der Code in einer Cloudumgebung und skaliert automatisch nach Bedarf.

Diese Trends werden oft als die optimalen Lösungen für viele Probleme in der Softwareentwicklung präsentiert. Doch die Herangehensweisen haben ihre eigenen Herausforderungen. Ohne in diesem Artikel in die Details einzugehen – sie erfordern eine sorgfältige Planung und können zu komplexeren Systemen führen, die schwerer zu managen sind .

Die Renaissance des Modulithen

Diese Erfahrungen machten viele Unternehmen. In den vergangenen zwei bis drei Jahren erlebte der Monolith, mit der Idee des Modulithen, eine Renaissance. Der Modulith verbindet die Vorteile der Modularisierung mit der Einfachheit der Wartung eines Monolithen.

Ein Blick in die Historie der Softwareentwicklung zeigt, dass diese Zyklen von einer service-orientierten Architektur zum Monolithen und zurück bereits mehrfach stattfanden. In den 1980er Jahren dominierte die Idee der Monolithen, bei denen Anwendungen als einheitliche, untrennbare Einheiten entwickelt wurden. Diese waren oft schwer zu warten und zu skalieren.

In den 1990er Jahren setzte sich dann das Konzept der serviceorientierten Architektur (SOA) durch. SOA zerlegte große Anwendungen in unabhängige Services, die über definierte Schnittstellen miteinander kommunizierten. Diese Herangehensweise bot viele Vorteile in Bezug auf Flexibilität und Wiederverwendbarkeit von Code. Doch auch SOA hatte seine Herausforderungen, insbesondere hinsichtlich der Komplexität und des Overheads bei der Verwaltung der vielen Dienste.

Um die Jahrtausendwende erlebten einige Unternehmen aufgrund der Schwierigkeiten mit SOA einen Rückschritt zu eher monolithischen Ansätzen. Ein Beispiel dafür ist die Einführung von Enterprise Resource Planning (ERP)-Systemen, die als integrierte, monolithische Lösungen für Unternehmenssoftware entwickelt wurden.

ERP-Systeme von Anbietern wie SAP boten umfassende Funktionalitäten in einem einzigen, großen System. Diese monolithischen Systeme waren einfacher zu verwalten als komplexe SOA-Implementierungen, aber sie litten unter den gleichen Problemen von Skalierbarkeit und Flexibilität wie die Monolithen der 1980er Jahre.

Mitte der Zweitausender erlebte SOA durch die Popularität von Enterprise Service Bus als Integration Broker einen erneuten Aufschwung. Mit dem Aufkommen von Microservices in den 2010er Jahren war die Idee der Serviceorientierung erneut in jedem Unternehmen präsent. Unternehmen wie Netflix und Amazon nutzten Microservices, um ihre Anwendungen besser skalierbar und wartbarer zu machen. Sie bewiesen, dass eine fein granulare Modularität auf der Ebene der Infrastruktur erhebliche Vorteile bieten kann.

Allerdings zeigte sich auch hier, dass ohne sorgfältige Planung und effektive Managementstrategien die Systeme schnell unübersichtlich und schwer zu handhaben werden können. Gerade kleinere Unternehmen ohne die große Anzahl an verfügbaren Entwicklern und vergleichbaren Umsatz wie die FAANG-Unternehmen ächzten unter der Komplexität von Microservices .

Die Softwarearchitektur verändert sich, die Probleme bleiben gleich

Diese historischen Zyklen zeigen, dass sich die dominante Softwarearchitektur zwar immer wieder veränderte, die zugrunde liegenden Probleme jedoch meist die gleichen blieben. Unabhängig davon, ob ein Unternehmen eine monolithische, SOA- oder Microservices-Architektur verwendet, stehen oft Skalierbarkeit, Wartbarkeit und Flexibilität im Mittelpunkt der Herausforderungen.

Diese Perspektive soll dazu anregen, neutraler über die eigene Architektur nachzudenken und sich nicht blindlings von aktuellen Trends leiten zu lassen. Stattdessen sollte die Wahl der Architektur immer auf den spezifischen Anforderungen und Rahmenbedingungen des jeweiligen Unternehmens basieren.

Lehren von Amazon: Anpassungsfähigkeit statt Perfektion in der Softwareentwicklung

Ein Unternehmen durchläuft in seiner Lebenszeit natürliche Phasen, die jeweils unterschiedliche Anforderungen an die Softwarearchitektur stellen. In der Anfangsphase als Start-up steht Geschwindigkeit im Vordergrund. Ein junges Unternehmen muss schnell Ergebnisse erzielen und sich am Markt beweisen. Die Anzahl der User ist oft noch gering, und es geht vor allem darum, möglichst schnell Feedback zu sammeln und auf Marktveränderungen zu reagieren.

Für diese Phase ist eine Microservice-Architektur in der Regel nicht geeignet. Sie ist zu komplex und starr, um den schnellen Entwicklungszyklen eines Start-ups gerecht zu werden. Start-ups müssen ihre Applikationen häufig ändern und anpassen, weil sie kontinuierlich lernen, wie der Markt funktioniert, und diese Erkenntnisse schnell in ihre Produkte einfließen lassen müssen.

Eine monolithische Architektur oder ein Modulith, der die Einfachheit eines Monolithen mit der Modularität verbindet, ist in dieser Phase oft die bessere Wahl. Sie ermöglicht schnelle Entwicklungszyklen und einfachere Änderungen.

Amazon ist dafür ein Beispiel. In den frühen Jahren setzte Amazon auf eine monolithische Architektur, um schnell neue Features zu entwickeln und auf Marktanforderungen zu reagieren. Diese Architektur ermöglichte es Amazon, schnell zu iterieren und sich als führender Onlinehändler zu etablieren.

Später, als Amazon begann zu skalieren und die Anzahl der User und Transaktionen stark zunahm, änderten sich die Anforderungen. Das Unternehmen trat in die Scale-Up-Phase ein, in der Skalierbarkeit und Performance entscheidend wurden.

In dieser Phase investierte Amazon in den grundlegenden Umbau seiner bestehenden Anwendung hin zu einer Microservice-Architektur. Diese Umstellung ermöglichte es, die verschiedenen Teile der Plattform unabhängig voneinander zu skalieren und zu warten, was für die Bewältigung des massiven Wachstums entscheidend war.

Eine zu frühe Festlegung kann hinderlich sein

Die Geschichte von Amazon ist nur ein Beispiel, um zu zeigen, wie wichtig es ist, die Architektur an die jeweilige Unternehmensphase anzupassen. Eine zu frühe Fixierung auf eine vermeintlich perfekte Architektur wie Microservices kann in der Anfangsphase hinderlich sein und zu unnötiger Komplexität führen.

Stattdessen sollten Unternehmen flexibel bleiben und ihre Architektur im Einklang mit ihrem Wachstum und den sich ändernden Anforderungen weiterentwickeln.

Praktische Empfehlungen für die Softwarearchitektur

Es ist weder möglich noch sinnvoll, die perfekte Softwarearchitektur bauen zu wollen. Stattdessen muss die Architektur sich mit den Gegebenheiten und dem Kontext des Unternehmens anpassen. Dafür muss und wird sie sich im Laufe der Zeit verändern.

Eine gute Architektur unterstützt das. Doch welche konkreten Empfehlungen können im Team umgesetzt werden? Die nachfolgenden Empfehlungen basieren auf bewährten Praktiken und erfolgreichen Beispielen aus der Industrie.

1. Beginne einfach und iteriere

Gestartet werden sollte mit einer einfachen, monolithischen Architektur. Das ermöglicht schnelle Entwicklungszyklen und einfache Änderungen, die in der frühen Phase eines Unternehmens entscheidend sind.

2. Implementiere Modulithen

Um die Vorteile der Modularisierung mit der Einfachheit der Wartung eines Monolithen zu verbinden, sollten Modulithen genutzt werden. Modulithen ermöglichen es, einzelne Module unabhängig voneinander zu entwickeln und zu testen, während die Anwendung weiterhin als einheitliches System betrieben wird. Mit dieser Grundlage kann man zu einem späteren Zeitpunkt einfacher in eine serviceorientierte Architektur migrieren.

3. Refaktoriere und baue technische Schulden ab

Entwickler sollten Zeit bekommen und zu regelmäßigem Refactoring ermutigt werden. Das verhindert, dass kurzfristige Lösungen langfristig zu großen Problemen führen.

4. Iterative Entwicklung und Deployment

Es sollten agile Methoden und Continuous Integration/Continuous Deployment (CI/CD) Pipelines verwendet werden, um kleine, inkrementelle Änderungen schnell in die Produktion zu bringen. Das fördert die Anpassungsfähigkeit und ermöglicht es, schnell auf Veränderungen im Markt zu reagieren.

5. Fokus auf die Kernkompetenz

Der Wert der Software steckt in der fachlichen Domäne. Die Softwarearchitektur sollte um diese Fachlichkeit herum konzipiert und entwickelt werden. Andere Funktionalitäten sollten durch das Zurückgreifen auf externe Dienste und Libraries gelöst werden. Beispielsweise kann für die Authentifizierung ein Identity-Provider wie Keycloak als Dienst oder der Spring Authorization Server als eingebettetes Modul verwendet werden.

6. Fördere eine starke Teamkultur

Eine starke Teamkultur und effektive Zusammenarbeit sind entscheidend für die erfolgreiche Umsetzung einer flexiblen Architektur. Das heißt: den Austausch von Wissen und die Zusammenarbeit zwischen verschiedenen Teams fördern. Ein Unternehmen, das regelmäßige Schulungen und Workshops anbietet, kann sicherstellen, dass alle Teammitglieder die Prinzipien der flexiblen Architektur verstehen und anwenden können.

7. Cross-funktionale Teams

Cross-funktionale Teams umfassen sowohl Entwickler als auch Operationsspezialisten und Businessanalysten. Das fördert ein besseres Verständnis der Geschäftsanforderungen und ermöglicht es, die Architektur entsprechend anzupassen.

Fazit

Die Suche nach der perfekten Softwarearchitektur ist eine Illusion. Die Bedürfnisse eines Unternehmens ändern sich ständig, und die Architektur muss in der Lage sein, sich diesen Veränderungen anzupassen. Statt auf eine vermeintlich perfekte Lösung zu setzen, sollten technische Leiter, CTOs und alle anderen Entscheider auf Flexibilität und Anpassungsfähigkeit achten.

Wie die Beispiele und Empfehlungen zeigen, ist es entscheidend, pragmatisch und iterativ vorzugehen. Man sollte mit einer einfachen Architektur starten und sie kontinuierlich weiterentwickeln.

Es sollten die Vorteile von Modulithen genutzt und eine starke Teamkultur gefördert werden, um technische Schulden zu vermeiden und eine nachhaltige Entwicklung zu gewährleisten.

Erfolgreiche Unternehmen wie Amazon haben gezeigt, dass die Fähigkeit, die Architektur im Einklang mit dem Unternehmenswachstum anzupassen, ein wesentlicher Faktor für den langfristigen Erfolg ist. Indem man auf flexible und anpassungsfähige Architekturen setzt, kann man sicherstellen, dass die Software nicht nur den aktuellen Anforderungen gerecht wird, sondern auch für zukünftige Herausforderungen gewappnet ist.

Eine gute Softwarearchitektur ist nicht statisch. Sie lebt, wächst und entwickelt sich zusammen mit dem Unternehmen. Wichtig ist, flexibel zu bleiben, kontinuierliche Verbesserungen zu fördern und auf Zusammenarbeit zu setzen. So entsteht eine solide Grundlage für nachhaltigen Erfolg.