Starres Softwaresystem-Design war gestern 6 Prinzipien einer Continuous Architecture

Anbieter zum Thema

Endava

netfiles GmbH

Insider Research

Cloudgermany.de GmbH

Continuous Architecture beschreibt einen flexiblen Ansatz in der Software-Entwicklung. Dabei löst man sich von einer starren Vorabplanung und geht zu einer Systemarchitektur über, die sich kontinuierlich weiterentwickeln und an neue Herausforderungen anpassen kann.

Das Paradigma hinter dem Continuous-Architecture-Ansatz besagt, dass es heute nicht mehr funktioniert, ein vollständiges, starres Systemdesign vorab zu entwerfen. Der Ansatz versucht stattdessen, die Architektur als ein sich kontinuierlich entwickelndes Set von Wissen und Entscheidungen zu gestalten, wobei die kollektive Verantwortung aller Beteiligten für die daraus resultierende Architektur betont wird.

Was in der Theorie einfach klingt, kann in der Praxis schnell zur Herausforderung werden. Damit der Ansatz auch tatsächlich ein Erfolg wird, sollten einige wichtige Aspekte beachtet werden, Im Folgenden stellt der Autor sechs Prinzipien und fünf Praktiken vor, an denen sich Unternehmen orientieren können, die Continuous Architecture implementieren möchten.

Sechs Prinzipien von Continuous Architecture

1. Prinzip: Produkte entwickeln – Empfohlen ist ein Wechsel von Projekten zu Produkten. Die Entwicklung von Produkten ist effizienter als das Entwerfen von Einzellösungen für Projekte und stellt das Team und die Anforderungen der Kunden in den Mittelpunkt.

2. Prinzip: Fokus auf Qualitätsattribute – Ein Fokus sollte auf Qualitätsattributen, und nicht auf funktionalen Anforderungen liegen. Die Anforderungen an die Qualitätsattribute bestimmen dann die Architektur.

3. Prinzip: Design-Entscheidungen verschieben, bis sie absolut notwendig sind – Architekturen sollten prinzipiell auf Fakten basierend entworfen werden, nicht auf Grundlage von Vermutungen. Es ist nicht sinnvoll, Funktionen zu entwerfen und zu implementieren, die möglicherweise nie genutzt werden – das wäre nur Verschwendung von Zeit und Ressourcen.

4. Prinzip: Architektur für den Wandel – In der modernen Software-Entwicklung empfiehlt es sich häufig, auf die „Macht des Kleinen“ zu vertrauen. Große, monolithische, eng gekoppelte Komponenten sind schwer zu verändern. Stattdessen sollte man heute eher kleine, lose gekoppelte Software-Elemente einsetzen.

5. Prinzip: Ganzheitliche Architektur – Eine umfassende Architektur berücksichtigt Entwicklung, Testing, Bereitstellung und Betrieb. Die meisten Architekturmethoden konzentrieren sich ausschließlich auf die Software-Erstellung. Wir sind jedoch der Meinung, dass sich Architekten auch mit dem Testing, der Bereitstellung und dem Betrieb befassen sollten, um den Continuous-Delivery-Ansatz zu unterstützen.

6. Prinzip: Team-Aufbau folgt dem Systemdesign – Die Organisation von Teams sollte sich nach dem Design des Systems richten, an dem sie arbeiten. Die Art und Weise, wie Teams organisiert sind, beeinflusst die Architektur und das Design der Systeme.

Fünf Praktiken von Continuous Architecture

1. Technische Führung etablieren

Software-Architekten sollten sich nicht als diejenigen sehen, die alle Entscheidungen in einem Projekt treffen. Stattdessen sollten sie eine aktive technische Führungsrolle übernehmen, um sicherzustellen, dass gute Entscheidungen getroffen werden. Dazu gehört auch die Einrichtung eines technischen Führungsteams, das die Richtung vorgibt und viele der Entscheidungen lenkt. Die eigentliche Architektur sollte jedoch letztlich aus dem Team heraus entstehen.

Als „Gewissen des Teams“ sollten Architekten stets die Folgen von Entscheidungen bedenken und darauf hinweisen, wo sie später Probleme verursachen könnten. Sie sind auch oft die Schnittstelle zu anderen Abteilungen im Unternehmen, wie beispielsweise Compliance oder IT-Sicherheit, und müssen in der Lage sein, ihr Team in schwierigen Diskussionen zu vertreten.

2. Qualitätsattribute priorisieren

Die Qualitätsattribute des Systems, wie Sicherheit, Leistung, Skalierbarkeit und Ausfallsicherheit, werden weitgehend durch seine Architektur bestimmt und müssen daher im Mittelpunkt der Arbeit stehen. Funktionalen Anforderungen, die von der Architektur weniger betroffen sind und in der Regel vom Team in Zusammenarbeit mit dem Product Owner erfüllt werden können, kommt hier eine geringere Bedeutung zu.

3. Entscheidungen steuern

Für die kontinuierliche Weiterentwicklung der Architektur sind gute Entscheidungen zentral. Verantwortlich dafür, diese zu treffen, zu überprüfen, zu verwalten und zu implementieren, ist das technische Führungsteam. Alle Entscheidungen sollten in einem definierten, verständlichen Rahmen festgehalten werden, beispielsweise mithilfe von Architecture Decision Records (ADRs), die als Textdateien neben dem Quellcode oder als Wiki-Seiten gespeichert werden.

4. Technische Schulden managen

Technische Schulden sind in der Software-Architektur eine Metapher, um suboptimale Design- und Implementierungsentscheidungen zu beschreiben, die kurzfristige Vorteile auf Kosten der Software-Qualität bringen, welche sich langfristig verschlechtert. Problematisch werden die technischen Schulden, wenn sie sich anstauen und es irgendwann zu teuer wird, Änderungen vorzunehmen, da das Team nicht mehr effizient arbeiten kann oder Updates der Technologie zu Risiken führen würden. Daher müssen Probleme, die zu technischen Schulden führen könnten, regelmäßig proaktiv angegangen werden.

5. Feedback-Schleifen etablieren

Um die Auswirkungen ihrer Architekturentscheidungen besser zu verstehen, sollten Teams regelmäßige Feedback-Schleifen einführen. Dabei hat sowohl automatisches, halbautomatisches und manuelles Feedback seinen Platz. Üblicherweise wird dabei die Performance gegenüber den Qualitätsattributen gemessen, es können aber auch funktionale Betrachtungen miteinfließen.

Berücksichtigt werden sollten sowohl interne Faktoren (z. B. Code-Komplexität) als auch externe Faktoren (z. B. API-Reaktionszeiten). Regelmäßige Überprüfungen und gezielte Anpassungen fördern nicht nur die stetige Verbesserung der Architektur, sondern tragen auch dazu bei, technische Schulden zu minimieren und die Resilienz des Systems zu erhöhen.

(ID:49982806)