4 Strategien um Software-Architektur zukunftssicher zu machen
Wie kann man mit unerwarteten Herausforderungen in der Softwarearchitektur umgehen (ohne alles im Voraus zu wissen)?
Natürlich möchte man die Architektur eines neuen Softwaresystems auf Anhieb so hinbekommen, dass sie über die Jahre stabil bleibt. Leider funktioniert das aber nicht.
Dazu weiss man am Anfang einfach noch viel zu wenig. Wie wird sich das System weiterentwickeln? Was sind zukünftige Nutzerwünsche?
Anforderungsänderungen
Während der Entwicklung kann ein neues Geschäftsszenario oder eine neue Benutzeranforderung auftreten, die eine signifikante Änderung der Softwarearchitektur erfordert. Beispielsweise kann eine Änderung, die eine höhere Skalierbarkeit erfordert, Auswirkungen auf die gesamte Systemstruktur haben.Unvorhergesehene technologische Einschränkungen
Die ursprüngliche Architektur könnte auf Technologien basieren, die sich später als ungeeignet für die Anforderungen erweisen. Dies könnte bedeuten, dass wir die Architektur neu bewerten und möglicherweise stark modifizieren müssen.Unerkannte Interaktionen zwischen Komponenten
Manchmal kann die Art und Weise, wie verschiedene Teile eines Systems interagieren, unerwartete Probleme verursachen. Dies kann dazu führen, dass wir die Architektur ändern dürfen, um diese Probleme zu beheben.Sicherheitslücken
In der Softwarearchitektur können unerkannte Sicherheitsprobleme auftreten, die zu schwerwiegenden Sicherheitslücken führen können. Die Behebung solcher Sicherheitslücken kann eine umfassende Überarbeitung der Architektur erfordern.Neue Technologien oder Plattformen
Die rasche Entwicklung neuer Technologien oder Plattformen kann dazu führen, dass die aktuelle Softwarearchitektur veraltet oder ungeeignet ist und angepasst oder überarbeitet werden muss.Unerwartete Performance-Probleme
Trotz bester Planung und Testverfahren können Leistungsprobleme auftreten, die schwer vorhersehbar waren, wie z.B. Engpässe unter bestimmten Lastbedingungen.
Nur anpassungsfähige Architekturen sind langfristig überlebensfähig.
Stichwort: Unknown unknowns.
“…there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know.”
– Donald Rumsfeld
Umgebungssysteme verändern sich und wir müssen die Architektur an die veränderten Bedingungen anpassen. Alles andere wird obsolet.
Die " unknown unknowns " zeigen eindrucksvoll, wie unvorhersehbare Elemente die gesamte Softwarearchitektur beeinflussen können. Hier wird deutlich, dass es entscheidend ist, stets die gesamte Architektur im Auge zu behalten. Und nicht nur das, wir müssen uns auf Veränderungen und Unsicherheiten einstellen, die während des gesamten Lebenszyklus der Software auftreten werden.
In der Welt der Softwareentwicklung bedeutet Stillstand Rückschritt. Die uns umgebenden Systeme ändern sich ständig und verlangen von uns, dass wir uns ständig anpassen.
Die Alternative? Unsere Arbeit verliert an Relevanz, wird obsolet.
Zum Glück gibt es Wegweiser, die uns zeigen, wie wir uns in dieser sich ständig verändernden Landschaft bewegen können. Einer dieser Wegweiser ist das Buch "Building Evolutionary Architectures" von Neal Ford und Rebecca Parsons.
Hier einige besonders prägnante Gedanken:
Evolutionäre Architektur sieht den Wandel kommen. Es ist unmöglich zu sagen, wann oder wie, aber eines ist sicher: Der Wandel wird kommen, und wir müssen bereit sein.
Ein System ist evolutionär, wenn es leicht zu verstehen und sicher zu verändern ist. Das ist leichter gesagt als getan, denn Verständlichkeit bedeutet nicht immer, dass Änderungen einfach umzusetzen sind.
Microservices sind eine Möglichkeit, aber nicht die einzige. Auch ein Monolith kann evolutionär sein, wenn er gut strukturiert ist und klar definierte und abgegrenzte Kontexte hat.
Conway's Law bietet uns eine Denkweise, wie wir Menschen, Kommunikation und Organisationen zielgerichtet gestalten können.
Die Architektur passt sich den Kommunikationsstrukturen der Organisation an, daher sollten wir die Organisation an die gewünschte Architektur anpassen. Es ist wichtig, dass wir alle an einem Strang ziehen und das gleiche Zielverständnis haben.
Unabhängig davon, welche Architektur wir entwickeln, sollten wir auf Veränderungen vorbereitet sein. Und das geht nur, wenn das System einfach zu verstehen ist. Microservices sind dafür keine Voraussetzung.
Was wirklich zählt, ist, dass wir alle das gleiche Ziel verfolgen und das gleiche Verständnis haben. Dann können wir sicher navigieren, auch wenn die "unknown unknowns" auf uns zukommen.