Zuerst erschienen in der public Ausgabe 02-2021
von Andreas Büchner
Die Auswirkung unterschiedlicher DevOps-Reifegrade auf die Softwarearchitektur
DevOps erhöht die Agilität der gesamten Wertschöpfungskette der IT. Dies hilft, mit den wachsenden Anforderungen an die IT Schritt zu halten. Die Rahmenbedingungen der öffentlichen Verwaltung setzen DevOps-Ansätzen jedoch häufig Grenzen. Mit diesen Einschränkungen gehen Behörden unterschiedlich um, sodass DevOps in ganz unterschiedlichen Reifegraden praktiziert wird. Hinsichtlich der Softwarearchitektur wird meist auf das Umsetzungsparadigma der Microservices verwiesen. In diesem Beitrag werden die Auswirkungen von DevOps auf die Softwarearchitektur vor dem Hintergrund unterschiedlicher Reifegrade konkretisiert und eine Antwort auf die Frage „Wie agil muss Softwarearchitektur sein?“ versucht.
DevOps
DevOps beeinflusst sämtliche Bereiche der IT: von der Organisation der Entwicklungs- und Betriebsabteilungen über Prozesse und Technologien zur Entwicklung, zum Test und zum Deployment bis hin zur Betriebsumgebung der entwickelten Software. Alle Bereiche werden hinsichtlich Agilität der Umsetzung von Anforderungen optimiert. Zwischen dem Schwarz (klassische IT) und Weiß (DevOps) existieren viele Graustufen, bei denen die DevOps-Ansätze in unterschiedlichen Reifegraden umgesetzt werden.
msg DevOps-Reifegradmodell
Das msg DevOps-Reifegradmodell ermöglicht es, den Grad der Umsetzung von DevOps in den Dimensionen Organisation, Plan, Code, Build, Deploy, Test und Operate zu bewerten und zeigt Möglichkeiten zur Erhöhung des Reifegrads auf.1
Ein geringer DevOps-Reifegrad ist nicht zwangsläufig schlecht – entscheidend ist, dass die IT agil genug ist, um an sich ändernde Anforderungen der unterstützten Fachverfahren angepasst werden zu können. Vor der Einführung von DevOps muss daher klar definiert werden, welche Ziele damit verfolgt werden und welcher Reifegrad erreicht werden muss, um diese Ziele zu verwirklichen. Dies resultiert in einem spezifischen Ziel-DevOps-Reifegrad. Der Reifegrad lässt sich an der Häufigkeit und der Erfolgsquote von Inbetriebnahmen neuer Funktionalitäten bemessen. Auch im Umfeld der Behörden-IT spielen die DevOps-Ansätze eine wichtige Rolle, um künftig deutlich kurzfristiger Lösungen für die Anforderungen der Digitalisierung bereitzustellen. Die fachliche Komplexität der Verwaltungsvorgänge und die gegebenen Rahmenbedingungen machen eine vollumfängliche Umsetzung von DevOps meist unmöglich oder zumindest sehr schwierig. So streben wenige Behörden die Organisation von Softwareentwicklung und Betrieb in eigenständigen sogenannten Zwei-Pizza-Teams an, die mithilfe einer vollständig automatisierten Continuous Delivery Pipeline jede noch so kleine Änderung unmittelbar in Betrieb bringen.
Bei der Herstellung des Ziel-DevOps-Reifegrads geht es daher darum, die verschiedenen DevOps-Möglichkeiten zielgerichtet und mit Augenmaß umzusetzen, um die Agilität zu erhöhen, ohne dabei andere Anforderungen, beispielsweise an die Datenqualität, zu gefährden. Wie das Zwei-Pizza-Team für die Organisation und die vollständig automatisierte Delivery Pipeline für die Wertschöpfungskette sind Microservices die „Endausbaustufe“ zur Umsetzung von DevOps in der Softwarearchitektur. Im Folgenden betrachten wir, wie die Agilität der Architektur bedarfsgerecht gestaltet werden kann.
Zwei-Pizza-Teams
Die „Two-Pizza Team Rule“ wurde von Jeff Bezos (Gründer von Amazon) geprägt. Sie besagt, dass ein Team – unabhängig von der Größe der Organisation – maximal so groß sein sollte, dass es von zwei Pizzas satt wird. Grundgedanke ist, dass die Kommunikation zwischen den Teammitgliedern mit der Teamgröße exponentiell steigt und damit die Effektivität des Teams sinkt. Die Faustregel wurde in vielen DevOps-Organisationen übernommen. Als Zielwert hat sich eine Größe von fünf bis acht Teammitgliedern etabliert.
Continuous Delivery Pipeline
Eine Continuous Delivery Pipeline ist eine automatisierte Werkzeugkette, die sämtliche Schritte von der Bereitstellung einer Code-Änderung durch den Entwickler bis zur Inbetriebnahme einer neuen Version der geänderten Komponente abdeckt. Details zum Aufbau einer entsprechenden Pipeline können dem IT-Spickzettel zum Heraustrennen „Continuous Delivery Pipeline“ in dieser .public entnommen werden.
Softwarearchitektur
Eine Softwarearchitektur wird gemäß dem IEEE-Standard 1471- 2000 (frei übersetzt) wie folgt definiert: Softwarearchitektur ist die grundlegende Organisation eines Systems, verkörpert in dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie die Prinzipien, die den Entwurf und die Evolution des Systems bestimmen.
Architekturprinzipien
Der Entwurf einer Softwarearchitektur ist ein kreativer Prozess, bei dem immer wieder unterschiedliche Lösungsansätze gegeneinander abgewogen und Entscheidungen getroffen werden müssen. Architekturprinzipien sind klar definierte Leitlinien, die diesen Entscheidungen eine Richtung geben. Für eine Softwarearchitektur können beliebig viele Prinzipien definiert werden. Wichtig ist jedoch, dass die Menge an Prinzipien handhabbar ist und die Prinzipien auch tatsächlich relevant sind und damit konkret Einfluss auf die Architekturentscheidungen besitzen.
Architekturprinzip: Ausrichtung an der Fachlichkeit
Die Softwarearchitektur richtet sich nach der umzusetzenden Fachlichkeit. Dieses Prinzip fordert eine Durchgängigkeit der Fachlichkeit zur Softwarearchitektur. Jedes Artefakt, das eine fachliche Anforderung an das Gesamtsystem beschreibt (beispielsweise ein Epic, eine User Story oder auch das fachliche Datenmodell) muss eindeutig einem Element der Softwarearchitektur zugeordnet werden können. So wird beispielsweise das Epic „Kunden verwalten“ dem System „Kundenverwaltung“, die Story „Neuen Kunden anlegen“ der Systemkomponente „Neuanlage“ und das fachliche Datenmodell der Kundendaten auf die persistenten Entitäten dieser Komponente abgebildet.
Softwarearchitektur und Architekturprinzipien
Die Softwarearchitektur eines IT-Systems beschreibt (1) die Komponenten, aus denen sich ein Gesamtsystem zusammensetzt, (2) die Abhängigkeiten und Beziehungen der Komponenten untereinander und zur Außenwelt und (3) die Architekturprinzipien, auf deren Grundlage die Architektur entwickelt und weiterentwickelt wird.
Die angewendeten Architekturprinzipien entscheiden darüber, in welche Komponenten ein System unterteilt wird, welche Abhängigkeiten sich daraus ergeben und gewährleisten, dass die Architektur auch langfristig nach klaren Regeln entwickelt wird. Sie beeinflussen damit maßgeblich die Tragfähigkeit der Architektur für den jeweiligen Kontext und müssen daher entsprechend den jeweils geltenden Anforderungen und Rahmenbedingungen ausgewählt werden. Der Ziel-DevOps-Reifegrad bestimmt dabei über den Einsatz von eher klassischen oder eher agilen Architekturprinzipien.
Natürliche Architektur als Zielbild
Die Leistungen der öffentlichen Verwaltung werden meist durch fachlich sehr komplexe IT-Systeme unterstützt, mit hohen nichtfunktionalen Anforderungen, zum Beispiel an die langfristige Wartbarkeit und Zuverlässigkeit. Um diese Komplexität zu beherrschen, haben sich die beiden Prinzipien Ausrichtung an der Fachlichkeit und Einfachheit bewährt.
Die Ausrichtung an der Fachlichkeit prägt den Schnitt der Komponenten. Es entsteht ein IT-System, bei dem die Auswirkungen von fachlichen Änderungen eindeutig einzelnen Komponenten zugeordnet und seiteneffektfrei umgesetzt werden können. Umgekehrt bedeutet dies aber auch, dass die Komponenten des Systems die Komplexität der Fachlichkeit widerspiegeln: Sind einzelne fachliche Teilbereiche sehr komplex, entstehen hieraus komplexe IT-Komponenten. Existieren viele Abhängigkeiten zwischen den fachlichen Prozessen, bestehen auch viele Abhängigkeiten zwischen den Komponenten des Systems.
Das Prinzip der Einfachheit wirkt sich übergreifend auf alle Architekturentscheidungen aus. Lösungen sollen einheitlich, redundanzfrei und leicht verständlich umgesetzt, unnötig komplexe Lösungen und „goldene Henkel“ vermieden werden. Die durch Anwendung der beiden Prinzipien entstehende Architektur bezeichnen wir als natürliche Architektur eines Softwaresystems. Sie zeichnet sich dadurch aus, dass Änderungen an der Software mit minimalem Aufwand und maximaler Zuverlässigkeit hinsichtlich deren Korrektheit und der Freiheit von Seiteneffekten möglich sind.
Architekturprinzip: Einfacheit
Bei der Auswahl zwischen mehreren geeigneten Lösungen ist immer die einfachste zu bevorzugen.
Architekturprinzip: Minimale Komplexität und Kopplung der Komponente
Die Komplexität der einzelnen Komponenten der Architektur wird minimiert und gleichzeitig die Abhängigkeiten zwischen den Komponenten weitestmöglich reduziert.
Agilität der natürlichen Architektur erhöhen
Die Agilität einer Softwarearchitektur ergibt sich nicht aus der Häufigkeit, mit der die Architektur geändert wird, sondern daraus, wie effizient fachliche Anforderungen in der Software umgesetzt werden können, ohne die Architektur zu ändern.
„Architecture is a framework for change.“
Tom DeMarco
Agilität betrachtet demnach die Geschwindigkeit der Durchführung von Änderungen. Diese Geschwindigkeit hängt unmittelbar von dem Aufwand und der Zuverlässigkeit ab, mit der Änderungen an der Software möglich sind. Daher fördert die natürliche Architektur auch die Agilität.
Entscheidend ist, dass die Agilität einer Architektur im Kontext von DevOps eine neue Bedeutung erlangt und nun nicht mehr nur daran gemessen wird, wie schnell Änderungen umgesetzt werden können (Dev), sondern auch wie schnell diese den Anwendern bereitgestellt werden können (Ops). Es wird eine maximale Geschwindigkeit der gesamten Wertschöpfungskette von Änderungen an der Software angestrebt. Dies wird durch die natürliche Architektur nicht direkt adressiert und erfordert daher ein zusätzliches Prinzip: Minimale Komplexität und Kopplung der Komponenten.
Durch konsequente Anwendung des Prinzips entstehen eigenständige Komponenten, die einzeln entwickelt und in Betrieb gebracht werden können. Spannend sind die Wechselwirkungen zwischen den Architekturprinzipien und deren Auswirkung auf die Architektur:
Fachlichkeit bestimmt den Komponentenschnitt:
Die Komponenten der Architektur ergeben sich sowohl beim Prinzip der „Ausrichtung an der Fachlichkeit“ als auch bei der „Minimalen Komplexität und Kopplung einzelner Komponenten“ unmittelbar aus der umzusetzenden Fachlichkeit. Denn wird die Komplexität einer einzelnen Komponente entgegen ihrer Fachlichkeit künstlich reduziert, steigt zwangsläufig die Kopplung zu anderen Komponenten, die dann die in der Komponente fehlende Fachlichkeit bereitstellen. Diese beiden Prinzipien unterstützen sich daher gegenseitig. Dies bedeutet aber auch, dass eine komplexe Fachlichkeit, die zu hoher Komplexität der Komponenten führt, die erreichbare Agilität begrenzt.
Technische Abhängigkeiten erfordern Kompromisse:
Die Prinzipien „Einfachheit“ des Gesamtsystems und die „Minimale Komplexität und Kopplung einzelner Komponenten“ stehen in Konkurrenz zueinander, da zur Entkopplung der einzelnen Komponenten zusätzliche Mechanismen, Technologien oder Infrastrukturkomponenten benötigt werden. Die Konsequenz ist, dass genau zwei Möglichkeiten existieren, um die Agilität der natürlichen Architektur effektiv zu erhöhen:
Ändern der Fachlichkeit, um die Komplexität der einzelnen Komponenten zu reduzieren
Dieser Punkt mag zwar irritieren, aber eine Anpassung der fachlichen Prozesse kann notwendig sein, um die angestrebte Agilität zu erreichen. Grundsätzlich geht es darum, die Fachlichkeit in einzelne Teilbereiche mit minimaler Komplexität und Kopplung zu unterteilen. Dies kann die Einführung von Redundanz oder asynchroner Bearbeitungsmuster (wie beispielsweise Eingangskörbe) notwendig machen – oder gar nicht sinnvoll möglich sein.
Reduzieren der technischen Kopplung der Komponenten auf Kosten der Einfachheit des Gesamtsystems „Monolithen“ scheinen aus der Zeit gefallen zu sein. Tatsächlich ist die Umsetzung definierter fachlicher Komponenten in einem einzelnen strukturierten IT-System aber weiterhin die einfachste Möglichkeit, um ein Verfahren zu realisieren. Die maximale Agilität wird jedoch erreicht, wenn jede Komponente als eigenständiges System (eigenständige Deployment-Einheit) betrieben wird, wodurch die Komplexität des Gesamtsystems steigt.
Die konkrete Umsetzung der beiden genannten Möglichkeiten ist im Detail komplex und abhängig von den spezifischen Merkmalen des jeweiligen Verfahrens, beispielsweise ob temporäre Inkonsistenzen (Eventual Consistency) akzeptabel sind oder nicht. Sie erfordern eine enge Abstimmung zwischen dem Entwicklungs- und dem Fachteam. Wichtig ist die Erkenntnis, dass die Agilität einer Architektur von der umzusetzenden Fachlichkeit abhängt und die Steigerung der Agilität die Einfachheit des Gesamtsystems reduziert.
Microservices bieten maximale Agilität
Microservices sind unumstritten das Idealbild einer agilen Architektur und optimal für den Einsatz im Kontext von DevOps geeignet: Die Fachlogik wird in einer Vielzahl eigenständiger Komponenten mit minimaler Komplexität und Kopplung umgesetzt. Der Fallstrick bei Microservices ist, dass sie häufig durch Beispiele aus dem Bereich von Internet-Dienstleistungen betrachtet werden – wie zum Beispiel Streaming-Diensten, sozialen Netzwerken oder Online-Shops. Hier kommen zwei Aspekte zusammen. Erstens: Die Fachlichkeit dieser Dienstleistungen lässt sich sehr leicht in einzelne Teilbereiche zerlegen, sodass die natürliche Architektur unmittelbar eine hohe Agilität besitzt. Zweitens: Die Systeme sind einer immens hohen, schwankenden Last ausgesetzt und müssen weltweit kontinuierlich verfügbar sein, sodass schon aus diesen Gründen der Betrieb der Komponenten in einzelnen skalierbaren Containern sinnvoll ist. Hierdurch wird bereits eine technische Entkopplung der Komponenten erreicht und ist keine zusätzliche Hürde. In anderen Kontexten – insbesondere bei Verwaltungsvorgängen – gelten diese Eigenschaften nur eingeschränkt.
So agil muss Softwarearchitektur sein
Die Frage „Wie agil muss Softwarearchitektur sein?“ kann nur in Bezug auf ein konkretes Verfahren und dessen Kontext beantwortet werden. Die Agilität der Architektur muss im Einklang mit dem Ziel-DevOps-Reifegrad der Organisation stehen und die Komplexität der umzusetzenden Fachlichkeit berücksichtigen. Zum Entwurf einer tragfähigen Architektur müssen die oben genannten Prinzipien entsprechend priorisiert und bei jeder Entwurfsentscheidung angewendet werden.
Im Folgenden wird die Frage nach der Agilität exemplarisch an einem Beispiel in unterschiedlichen Szenarien beantwortet. Mit jedem Szenario steigt der angestrebte DevOps-Reifegrad.
Beispiel „Einheitliche Stadtverwaltung“:
Es wird eine einheitliche Softwarelösung für alle Stadtverwaltungen geschaffen. Diese soll langfristig wartbar sein und zuverlässig entwickelt werden. Ein Entwurf der Architektur nach den klassischen Prinzipien „Ausrichtung an der Fachlichkeit und Einfachheit“ ergibt einen Komponentenschnitt in vier Komponenten mit teilweise hoher Komplexität, aber hoher Kohäsion und geringen Abhängigkeiten zwischen den Komponenten.2
Abbildung 1: „Einheitliche Stadtverwaltung“ mit vier fachlichen Komponenten
Szenario 1 – Sehr geringer Ziel-DevOps-Reifegrad:
Das entwickelte System wird in mehreren Instanzen in unterschiedlichen Rechenzentren durch jeweils eigene Teams betrieben. Die Implementierung des Systems erfolgt durch ein zentrales Entwicklungsteam. Neue Releases können aufgrund der komplexen Konstellation der beteiligten Behörden maximal halbjährlich in Betrieb genommen werden. Inbetriebnahmen gehen in der Regel mit einem Ausfall der Produktionsumgebung einher und werden daher außerhalb der Geschäftszeiten durchgeführt. Agilität spielt im Kontext des Verfahrens kaum eine Rolle. Der verantwortliche Architekt wählt und priorisiert die Architekturprinzipen wie folgt:
1. Ausrichtung an der Fachlichkeit
2. Einfachheit
3. Weitere (für das Beispiel nicht relevanten) Prinzipien ...
Es wird der im Beispiel beschriebene fachliche Schnitt der Komponenten umgesetzt (Ausrichtung an Fachlichkeit). Da die Inbetriebnahmen sehr selten erfolgen, werden in nahezu jedem Release alle Komponenten aktualisiert. Aus Gründen der „Einfachheit“ wird das System daher als Monolith entworfen, in dem die Fachkomponenten als Subkomponenten mit klar definierten Schnittstellen implementiert werden.
Abbildung 2: „Einheitliche Stadtverwaltung“ mit vier fachlichen Komponentenals monolithisches IT-System
Szenario 2 – Geringer Ziel-DevOps-Reifegrad:
Das entwickelte System wird als zentraler Dienst bereitgestellt, der von allen Stadtverwaltungen genutzt wird. Neue Funktionen und Änderungen sollen quartalsweise bereitgestellt werden. Die Entwicklung erfolgt durch mehrere Entwicklungsteams. Der Betrieb wird durch ein Rechenzentrum verantwortet, das organisatorisch von der Entwicklung getrennt ist und keine Erfahrung hinsichtlich Container-Plattformen besitzt. Der Architekt wählt die folgenden Prinzipien:
1. Ausrichtung an der Fachlichkeit
2. Einfachheit
3. Minimale Komplexität und Kopplung
4. Weitere Prinzipien ...
Um die Inbetriebnahme einzelner Komponenten zu erleichtern, wird jede fachliche Komponente in einem eigenen IT-System mit klar definierter und versionierter Schnittstelle implementiert (Minimale Komplexität und Kopplung der Komponenten). Die Systeme können dadurch einzeln aktualisiert und Auswirkungen von Schnittstellenänderungen auf andere Komponenten minimiert werden. Jede Komponente wird von einem einzelnen Entwicklungsteam verantwortet. Die Größe der Teams variiert entsprechend der Komplexität der Komponenten (Ausrichtung an der Fachlichkeit). Build, Test und Inbetriebnahme der Komponenten erfolgt über eine automatisierte Deployment Pipeline, die insbesondere für den Test jedoch noch zahlreiche manuelle Schritte vorsieht. Auf Containerisierung wird verzichtet (Einfachheit).
Abbildung 3: „Einheitliche Stadtverwaltung“ mit vier fachlichen Komponenten als vier unabhängige IT-Systeme
Szenario 3 – Mittlerer Ziel-DevOps-Reifegrad:
Die Anforderungen an das System sind mit vielen Unsicherheiten verbunden und ändern sich häufig, sodass fachliche Änderungen zwingend alle vier Wochen in Betrieb genommen werden müssen. Minimierung der Komplexität und Kopplung werden daher höher priorisiert:
1. Ausrichtung an der Fachlichkeit
2. Minimale Komplexität und Kopplung
3. Einfachheit
4. Weitere Prinzipien ...
Im Rahmen des Architekturentwurfs stellt der Architekt fest, dass die Komponente zur Verwaltung der Parkausweise (Komponente 1) sehr komplex ist und die angestrebte Agilität an dieser Stelle vermutlich nicht erreicht werden kann. In Abstimmung mit dem Fachbereich wird entschieden, dass die fachlichen Prozesse in „Parkausweise für Bürger“ und „Parkausweise für Unternehmen“ aufgeteilt werden (Ausrichtung an der Fachlichkeit und Minimale Komplexität und Kopplung der Komponenten). In der natürlichen Architektur entstehen dadurch die Komponenten 1 (Bürger) und Komponente 5 (Unternehmen). Dies führt dazu, dass einzelne Teilschritte redundant in den beiden Komponenten implementiert werden müssen und potenziell auseinanderlaufen. Dies erweist sich im weiteren Verlauf sogar als Vorteil, da Bürger eher eine interaktive Oberfläche bevorzugen, während Unternehmen eine „Bulk-Schnittstelle“ benötigen und die Komponenten entsprechend optimiert werden können. Um die relativ häufigen Inbetriebnahmen zu bewältigen und die wachsenden Ressourcenanforderungen erfüllen zu können, wird mit dem Rechenzentrum die Einführung einer Container-Plattform in einer Cloud mit Anbindung an eine CI/CD-Pipeline abgestimmt. Jede Komponente wird in einem eigenen Container betrieben.
Abbildung 4: „Einheitliche Stadtverwaltung“ mit fünf fachlichen Komponentenals Container in einer Cloud
Szenario 4 – Hoher Ziel-DevOps Reifegrad:
Die Zufriedenheit der Anwenderinnen und Anwender soll explorativ und schrittweise erhöht werden. Anforderungen können über einen öffentlichen Bug-Tracker eingestellt werden. Neue Funktionen sollen kontinuierlich in Produktion gebracht werden. Es wird eine maximale Agilität angestrebt.
In Abstimmung mit dem Fachbereich stellt der Architekt fest, dass die Fachlichkeit nicht sinnvoll weiter unterteilt werden kann. Er weist darauf hin, dass dementsprechend auch eine weitere Unterteilung der Komponenten zwar zu einzelnen Komponenten mit geringerer Komplexität, aber zu einer engen Kopplung zwischen den Komponenten führt. Dies würde die Agilität nicht fördern und die Komplexität des Gesamtsystems würde unnötig steigen. Es zeigt sich jedoch, dass sich die angestrebte Agilität primär auf die Benutzeroberfläche und weniger auf die eigentliche Fachlogik bezieht: Die Benutzeroberfläche hat den größten Einfluss auf die Zufriedenheit der Anwenderinnen und Anwender. Die fachlichen Prozesse sind etabliert, Änderungen sind kritisch und erfordern umfangreiche Abstimmungen.
Die Komponenten werden jeweils technisch in eine Frontend- Komponente, die die Benutzeroberfläche bereitstellt, und eine Backend-Komponente unterteilt. Dies hat keine Auswirkungen auf die Fachlichkeit, aber die Komplexität des Gesamtsystems steigt (Minimale Komplexität und Kopplung der Komponenten vor Einfachheit). Vorteil ist, dass die unterschiedlichen Komponenten in zwei Geschwindigkeiten weiterentwickelt werden können und so die angestrebte Agilität der Benutzeroberflächen erreicht wird: Änderungen an den Frontend-Komponenten werden kontinuierlich in Produktion gebracht – hier werden temporäre „Unschönheiten“ akzeptiert, solange sie schnell wieder behoben werden. Änderungen an den Backend-Komponenten sind alle vier Wochen möglich.
Abbildung 5: „Einheitliche Stadtverwaltung“ mit Trennung von Frontend- und Backend-Komponenten und „zwei Geschwindigkeiten“
Ergänzende Betrachtung zu Microservices:
Ein maximaler DevOps-Reifegrad beziehungsweise eine vollständige Umsetzung von Microservices (im Sinne von sehr kleinen Komponenten) ist im vorliegenden fiktiven Beispiel auf Grund der Komplexität der fachlichen Teilfunktionen nicht möglich.
Bei einem anderen Verfahren mit einer entsprechend geringeren Komplexität der Teilfunktionen würde bereits durch die Anwendung der Architekturprinzipien gemäß Szenario 3 Microservices mit einer maximalen Agilität entstehen:
Abbildung 6: Microservice-Architektur, die sich aus einer Fachlichkeit mit einfachen Teilfunktionen ergibt
Fazit
Eine agile Softwarearchitektur ist Voraussetzung für erfolgreiches DevOps. Wie agil die Architektur sein muss, wird vom angestrebten DevOps-Reifegrad bestimmt. Es ist nicht sinnvoll, die Agilität der Architektur ziellos zu maximieren, da sich dies negativ auf die Komplexität und die Tragfähigkeit des Gesamtsystems auswirkt. Durch die klare Definition eines Ziel-DevOps-Reifegrads und einer zielgerichteten Anwendung von Architekturprinzipien wird die angestrebte Agilität erreicht, ohne andere Qualitätsmerkmale der Architektur zu vernachlässigen – vorausgesetzt, dass die zu implementierende Fachlichkeit diese Agilität überhaupt zulässt.
Quellen
1 Siehe https://www.msg.group/public-sector/devops-maturity/file (abgerufen am 24.08.2021).
2 Die Anzahl der Komponenten wäre in Wirklichkeit sicherlich viel größer, sie wurde zur Nachvollziehbarkeit des Beispiels aber bewusst klein gehalten.
