Wir haben uns mit sechs Experten – allesamt erfahrene Software-Architekten und Sprecher auf der W-JAX-Konferenz und dem Software Architecture Summit – über aktuelle Themen der Software-Architektur unterhalten. Sandra Parsick, Hanna Prinz, Thomas Kruse, Markus Harrer, Stephan Pirnbaum und Franziska Dessart geben Einschätzungen zu Architektur-Trends, unterbelichteten Themen jenseits der Trends und den Aufgaben eines modernen Software-Architekten.

Wozu eigentlich Software-Architekten?

JAXenter: Die Rolle des Software-Architekten kann verschiedentlich interpretiert werden: Technologieplaner, Change Manager, Chefentwickler, Projektkoordinator, Kommunikator, Kundenberater, etc. Worauf kommt es dir persönlich in deiner Rolle als Software-Architekt an?

Ein Software-Architekt ist ein Vermittler zwischen Techniker und Nicht-Techniker

Sandra Parsick: Aus meiner Sicht ist ein Software-Architekt ein Vermittler zwischen Techniker und Nicht-Techniker. Dabei ist es hilfreich, wenn der Software-Architekt im Team mitentwickelt. Vermehrt sehe ich den Trend, dass die Rolle des Architekten als Teamaufgabe interpretiert wird, so dass die Entwickler aktiv an der Architektur mitarbeiten und auch gleich sehen, wie die Architektur sich im Code widerspiegelt.

Hanna Prinz: Meiner Meinung nach ist es wichtig, dass Architekten möglichst nah am Team sind und einen guten Draht zu Product Ownern haben. Nur mit regelmäßigem, direktem Austausch über Fachlichkeit, Architektur und Technologien können gute technische Entscheidungen gefällt werden. Viele – wenn nicht die meisten – Architektur-Entscheidungen fällen sowieso die Entwickler im Alltag. Umso besser das Team bei Architektur-Entscheidungen involviert und informiert ist, desto besser werden diese Entscheidungen sein und desto weniger erodiert die Architektur.

Thomas Kruse: Ich denke, dass ein guter Softwarearchitekt tatsächlich von allem etwas mitbringen muss. In erster Linie muss ein Architekt das Geschäft des Kunden besser verstehen, als der Kunde selbst. Nur so lassen sich geeignete technische Loesungen auswählen, mit denen sowohl die aktuellen Anforderungen als auch vorhersehbare Änderungen umgesetzt werden können.

Dabei ist der Schritt dann nicht mehr weit, den Kunden auch dahingehend zu beraten, wie er seine Geschäftsprozesse optimiert oder sogar dank geeigneter Software völlig neue Prozesse oder Modelle anbieten kann.

In zweiter Linie finde ich es wichtig, dass man nicht ausschließlich seine Lieblingsarchitektur hat, sondern über ein breites Spektrum an Wissen und Erfahrung verfügt und unter Berücksichtigung aller Anforderungen und Rahmenbedingungen dann eine passende Auswahl treffen kann.

Markus Harrer: Mir kommt es einfach darauf an, dass sich das Entwicklungsteam bei der Technik nicht übernimmt, um noch genug Zeit zu haben, einen Mehrwert für die Kunden zu liefern. Bei meinen Beratungen zum Entwurf oder der Modernisierung von Softwaresystemen stehen daher der Abbau unnötiger Komplexitäten und Standardisierung mit Hirn im Vordergrund. Ich will nicht, dass die besten Entwickler*innen ihre wertvolle Zeit mit dem Aufbau von eigenentwickelten Infrastrukturlösungen oder dem Zurechtbiegen von Standard-Frameworks verwenden. Sie sollen ihr Gehirnschmalz in die fachlich anspruchsvollen Teile stecken und hier die inhärente Komplexität clever in einfache Softwaresysteme gießen. Das bringt den wahren Wert der Software – und letztendlich auch den Mehrwert für die Kunden.

Stephan Pirnbaum: Als Software-Architekt ist es meiner Meinung nach besonders wichtig, die verschiedenen Anforderungen der einzelnen Stakeholder sowohl von technischer als auch besonders von fachlicher Seite sinnvoll zu vereinen und auf dieser Basis zukunfts- und evolutionsfähige Entscheidungen für das Software-System zu treffen. Dabei ist Kommunikation ein essentieller Bestandteil der Tätigkeit. Dokumentation von Entscheidungen und ein aktiver Wissensaustausch gehören aber für mich ebenso selbstverständlich dazu wie das Mitentwickeln an der Software.

Franziska Dessart: Software-Architektur ist das, was entsteht, wenn Software geschaffen wird. Genauso wie etwas bei seiner Herstellung automatisch eine Gestalt (-ung, also ein Design) bekommt. Hierzu braucht es keinen Designer. Architektur entsteht immer, egal ob Entscheidungen bewusst getroffen werden oder nicht. Unabhängig davon, ob ein sogenannter “Architekt” dazu beigetragen hat oder nicht. Auch die Sandburg meiner Kinder hat sowohl eine Gestalt, als auch eine Architektur.

Idealerweise werden jedoch die meisten Entscheidungen bewusst getroffen und nicht basierend auf Vorlieben oder dem “Bauchgefühl” Einzelner. Hierzu gilt es, Vor- und Nachteile aller erdenklichen Möglichkeiten zu beleuchten und gegeneinander abzuwägen. Es gibt keine perfekten oder allgemeingültigen Entscheidungen, aber immer die unter den momentanen Bedingungen bestmögliche Variante (die das unter Umständen schon Tage, Wochen oder Monate später nicht mehr sein muss, wenn sich die Rahmenbedingungen ändern).

Dabei spreche ich von Architekturentscheidungen auf allen Ebenen. Von weitreichenden Makroarchitekturentscheidungen (wie z.B. “Datenreplikation immer per Feed”) bis hin zu extrem detaillierten Entscheidungen (etwa Variablen- und Methodennamen bzw. Anzahl und Art ihrer Parameter), sowie allen Schattierungen dazwischen. Mir ist wichtig, dass jeder, der an der Herstellung von Software beteiligt ist, sich jederzeit so gut wie möglich mit seinem Wissen und seinen Fähigkeiten in die Architekturarbeit einbringen kann und dadurch die bestmögliche Architektur entsteht. Die Vorraussetzung dafür ist, dass eine offene und sichere Kommunikationskultur herrscht, die das überhaupt erst ermöglicht.

Architektur-Trends 2019

Welchen Trend in Sachen Software-Architektur findest du momentan besonders spannend?

Sandra Parsick: Ich finde es momentan spannend zu beobachten, wie die Wahl der Cloud-/Infrastrukturtechnologie Auswirkung auf die Software-Architektur hat. Noch vor ein paar Jahren haben sich Entwickler/Architekten wenig Gedanken darüber gemacht, so zumindest meine Wahrnehmung, ob die Architektur der Software die Anforderungen aus der Infrastruktur erfüllen kann. Ich denke da an Beispiele wie: “Kommt meine Software damit zurecht, dass sie im Kubernetes-Cluster einfach mal beendet wird und wo anders wieder gestartet wird?”

Hanna Prinz: Ich habe natürlich einen Starken Bias in Richtung Cloud, Kubernetes und Service Mesh. Es fasziniert mich immer wieder, wie beliebt und erfolgreich Microservices sind, obwohl es bis vor kurzem so schwer war, sie zu betreiben, zu kontrollieren und Einblicke in das Gesamtsystem zu gewinnen. In diesem Bereich gibt es ständig neue interessante Ideen und Technologien.

Der Trend zu Containern zieht unglaublich viele Bereiche nach sich.

Thomas Kruse: Der Trend zu Containern ist in meinen Augen eine Bewegung, die Auswirkungen auf unglaublich viele Bereiche nach sich zieht. Neben etablierten Technologien stehen dabei auch Organisationsstrukturen und etablierte Verfahrensweisen zur Diskussion. Das Potential, das Kubernetes bietet, liegt dabei natürlich auf der Hand. Auf der anderen Seite sollte man auch mit Bedacht vorgehen,. Nur um bei einem Trend dabei zu sein, aber dann doch eigentlich nichts ändern zu wollen, bringt aus meiner Sicht keine Vorteile und potentiell viel Frust und vergebene Energie. Dabei ist Kubernetes in der Tat bei vielen Firmen ein Wegbereiter zur Cloud und den damit verbundenen Chancen.

Markus Harrer: In vielen Firmen sind mittlerweile eine Unmenge an Softwaresystemen mit zahlreichen Anbauten und undurchsichtigen Kommunikationsbeziehungen entstanden. Für Softwarearchitekt*innen wird es dadurch immer schwerer, den Überblick zu behalten. Meist kennen diese nur Methoden zur Analyse einzelner Systeme. Das bringt Softwarearchitekt*innen bei der Beratung des Managements zur strategischen Ausrichtung des vorhandenen Systemzoos an ihre Grenzen. Daher finde ich besonders neu aufkommende Methoden interessant, welche ganze Systemlandschaften überschaubar machen.

Hier haben es mir besonders Wardley Maps [1] angetan. Eine Wardley Map ist eine Art Strategielandkarte, auf der Softwaresysteme nach ihrem Nutzen für einen Stakeholder (meist dem zahlenden Kunden) und dem jeweils gegebenen Evolutionsstadium (Prototyp, Eigenentwicklung, Produkt oder Gebrauchsgut) eingeordnet werden. Dadurch entsteht ein sehr kontextspezifisches Situationsbewusstsein über die eigene Systemlandschaft. Dank des immer vorhandenen Bezugs zum Stakeholder-Nutzen können auch Nicht-Techniker*innen bei strategischen Überlegungen zur IT mitreden. Durch die Einordnung der Systeme gemäß ihrer Evolutionsstufe können situationsspezifische Maßnahmen wie Know-How-Aufbau, Standardisierung oder Outsourcing sachlich diskutiert werden – je nachdem, wohin sich ein Softwaresystem entwickeln soll.

Stephan Pirnbaum: Aktuell finde ich Service-Meshes sehr spannend, denn leider wird der einfache Betrieb von Anwendungen bei deren Entwicklung häufig erst zweitrangig betrachtet. Dabei stellen insbesondere dynamisch skalierende Microservice-Landschaften große Herausforderungen insbesondere bezüglich Resilienz, Security, Monitoring und Logging. Zwar gibt es zahlreiche Frameworks, um dies zu bewerkstelligen, doch fügen diese weitere Komplexität sowohl in der Entwicklung als auch im Betrieb hinzu. Service-Meshes wie Istio erachte ich durch das Sidecar-Konzept und die Control Plane daher als einen interessanten Ansatz, diese Komplexität zumindest etwas einzudämmen. Dabei ist jedoch auch zu prüfen, ob die Mächtigkeit von Service-Meshes in dem jeweiligen Projektkontext notwendig ist.

Franziska Dessart: Mob Programming – hier ist jeder im Team an jeder wichtigen Entscheidung beteiligt und gleichzeitig immer über alles informiert. Ich mache das jetzt schon mehrere Monate erfolgreich bei meinem aktuellen Kunden. Von zuhause, vom Homeoffice aus. Wir nennen das Remote Mob Programming. Wie das funktioniert, haben meine Kollegen Jochen Christ, Simon Harrer und Martin Huber auf remotemobprogramming.org aufgeschrieben. Das funktioniert auch mit Teilzeit und sonstigen Abwesenheiten (Urlaub, Konferenzen, …), ganz ohne lästige Übergaben. Der Mob fängt das auf!

Jenseits der Trends

Welches Architekturthema außerhalb der Trends liegt dir besonders am Herzen und sollte deiner Meinung nach mehr Beachtung finden?

Sandra Parsick: Ist vielleicht kein direktes Architekturthema, aber ich finde, dass sich viel zu wenig Gedanken darüber gemacht wird, wie Architekturentscheidungen die Testmöglichkeiten einer Software beeinflussen. Daher wünsche ich mir, dass bei der Entscheidungsfindung mitberücksichtigt wird, wie ich das Ganze auch getestet bekomme.

Hanna Prinz: Man kann förmlich dabei zusehen, wie Softwareentwicklung immer dynamischer wird. Es geht häufig darum, schnell handeln zu können, selbst wenn dieser Vorteil auch mit ganz offensichtlichen Nachteilen einher geht. Architektur ist aber etwas, wo diese Dynamik nicht möglich und häufig auch nicht sinnvoll ist. Eine Architektur sollte deshalb nur so viel vorgeben, wie unbedingt nötig, und genug Raum für kontinuierliche Verbesserung lassen. Entscheidungen können nur dann wirklich in Frage gestellt werden, wenn der Aufwand, sie zu ändern, beherrschbar ist. Dieses offene Reflektieren über den Ist-Zustand setzt voraus, dass Alternativen bekannt sind.

Man kann förmlich dabei zusehen, wie Software-Entwicklung immer dynamischer wird.

Im Alltag ist man aber mit den immer gleichen Tools und Ideen konfrontiert. Deshalb brauchen wir Kollaboration und Austausch mit anderen. Meetups, Podcasts, Blogs und Workshops sind ein guter Anfang. Aber längst nicht alle Unternehmen ermutigen ihre Entwickler, sich so kontinuierlich weiterzuentwickeln und auszutauschen.

Thomas Kruse: Ich sehe oft, dass klassische Muster immer wieder Anwendung finden, die durch neue Optionen wie bspw. leistungsfähigere Hardware in Frage gestellt werden sollten. Ein Klassiker ist zum Beispiel die Verwendung von Batch-Jobs, weil auf Datenmengen im Gigabyte-Bereich gearbeitet wird – also Datenmengen, die locker in aktuellen Systemen auch im Hauptspeicher gehalten und performant verarbeitet werden könnten.

Markus Harrer: Es sind zwei Themen, die mir persönlich zu kurz kommen. Das eine Thema ist die Softwaremodernisierung. Auf Konferenzen reden wir meist nur über den Neubau von Software. Aber gefühlt sind doch 80% von uns in den sogenannten Legacy-Systemen unterwegs. Meistens haben diese Systeme vor allem bei der jüngeren Generation einen eher schlechten Ruf. Das finde ich sehr schade, denn es kann geistig sehr erfüllend sein, schwerwiegende Probleme in Bestandssystemen systematisch zu lösen. Es gibt viele Methoden und Vorgehen, wie etwa die Object-Oriented Reengineering Patterns [2] oder die Architecture Improvement Method aim42 [3], um Softwaresysteme Stück für Stück zu verbessern. Es fehlt leider jedoch noch an mehr Ausbesserinnen und Ausbessern, die sich in das Licht der Konferenzsäle wagen, um über solche Techniken und die eigenen Erfahrungen zu sprechen.

Das andere Thema ist das Dokumentieren von Softwaresystemen. Ich finde hier den Ansatz Docs-As-Code [4] insbesondere in der Ausprägung Arch-As-Code sehr spannend. Dokumentation auf den Stellenwert von Code zu heben, um damit Entwickler*innen keine Ausweichmöglichkeiten mehr zu geben, nichts zu dokumentieren? Genial! Gleiche Tools, gleiche Prozesse, gleiche Regeln. Die zusätzliche Verzahnung von den dokumentierten, architekturellen Spielregeln und deren Prüfung gegenüber dem echten Code bei Arch-as-Code treibt das noch ein Stück weiter. Werkzeuge wie ArchUnit [5] oder jQAssistant [6] prüfen hier beim Test oder Bau der Software automatisiert, ob die dokumentierten Architekturregeln auch eingehalten werden. Damit gibt es zusätzlich noch eine neutrale Instanz, welche dem sonst schleichenden Verfall von Softwaresystemen entgegenwirkt.

Stephan Pirnbaum: Für mich ist das Thema „Monolith“ und deren Verbesserung sehr wichtig, obwohl es leider in der Vergangenheit aufgrund neuer Trends als nicht sehr ansprechend galt. Im Gegenteil, schaut man zurück, waren lange Zeit Microservices (zumindest gefühlt) das Nonplusultra und Monolithen alles andere als attraktiv. Ebenfalls gefühlt hat sich diese Situation aber wieder gelegt, und es geht viel stärker darum, was tatsächlich für den Use Case und die Projektzukunft notwendig und sinnvoll ist. Dies kann ich nur unterstützen und finde, dass die Diskussion um die „richtige“ Architektur (soweit es diese überhaupt gibt) noch viel stärker auf Basis geschäftlicher Anforderungen und Rahmenbedingungen geführt werden sollte, anstatt auf der Grundlage aktueller Trends zu entscheiden.

Franziska Dessart: ADRs, also Architecture Decision Records, sind ein Mittel, das auf effiziente Art und Weise die wichtigsten Architekturentscheidungen dokumentiert. Es wird sowohl die Entscheidung selbst explizit dokumentiert, als auch, wie das Team zu dieser gekommen ist. Welche Information zum Zeitpunkt der Entscheidungsfndung zur Verfügung standen und welche Alternativen möglich gewesen wären.

Das hilft dem Team selbst: Entscheidungen werden explizit gemacht, Alternativen beleuchtet, Vor- und Nachteile abgewogen. Gleichzeitig schafft man Transparenz für Stakeholder außerhalb des Teams und erleichtert das Onboarding für neue Kollegen. Das Aufschreiben fördert die strukturierte Herangehensweise an die Entscheidung und gibt allen die Möglichkeit, sich daran zu beteiligen.

Architektur-Themen der Experten

Hanna, du hältst auf der W-JAX einen Talk namens Istio & Co: Service Mesh – das Missing Piece der Microservices-Architektur. Welche Vorteile hat man beim Einsatz eines Service Mesh Tools?

Hanna Prinz: Die Automatisierungs-Werkzeuge, die wie nutzen, sind teilweise schon so unsichtbar geworden, dass wir uns ihrer gar nicht mehr bewusst sind. Erst wenn man einen Container-Orchestrierer wie Kubernetes oder das CI/CD-Tooling wegnehmen würde, würde uns deren Mehrwert auffallen. Ich denke, dass es im Bereich solcher Automatisierungswerkzeuge noch viel mehr Potential gibt. Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features wie Monitoring, Routing, Circuit Breaking und die Absicherung des Netzwerkverkehrs hinzu – und zwar ohne, dass die Anwendungsentwickler auch nur eine Zeile Code ändern müssen. Der Hype um das Thema ist also durchaus berechtigt.

Neben den vielen Vorteilen: Erkauft man sich dabei auch einige Nachteile?

Selbst die sinnvollsten Veränderungen haben immer den Nachteil, dass es Zeit und Ressourcen kostet, die Veränderung zu evaluieren, zu planen, zu kommunizieren und herbeizuführen. Das trifft auch auf die Einführung eines Service Mesh zu. Noch dazu unterscheiden sich die verfügbaren Service-Mesh-Implementierungen stark – nicht nur im Feature-Umfang und was die Kompatibilität mit anderer Infrastruktur wie Kubernetes angeht, sondern auch in der Benutzbarkeit der API für Entwickler. Der mentale Overhead ist meiner Meinung nach aktuell der größte Nachteil von Service Meshes.

Schließlich ist das auch nicht die einzige Veränderung, mit denen die Teams konfrontiert sind. Ein Service Mesh hat außerdem einen Einfluss auf die Antwortzeit einer Anwendung und auf deren Ressourcenverbrauch. Ich empfehle deshalb immer, einen Benchmark mit der individuellen Anwendung zu machen.

Ein Service Mesh fügt einer beliebig großen Microservice-Anwendung essentielle Features wie Monitoring, Routing, Circuit Breaking und die Absicherung des Netzwerkverkehrs hinzu.

Sandra, du bist auf der W-JAX und dem Software Architecture Summit aktiv. Dabei geht es beides Mal ums Testen: auf der W-JAX mit dem Vortrag Testen von und mit Infrastruktur, auf dem Summit mit dem Workshop Softwarearchitektur automatisiert testen. Was bedeutet es überhaupt, eine Architektur zu testen?

Sandra Parsick: Es geht in erster Linie darum, die Frage zu beantworten, wie ich erkenne, ob meine Architektur die gewählten Qualitätsmerkmale erfüllt. Da können oft schon klassische Testtechniken helfen. Bei anderen Fällen muss ich den Begriff “Testen” eher als Qualitätssicherung interpretieren, und dann kommen auf einmal andere Methoden in Spiel, die man erstmal nicht so auf dem Schirm hatte.

Thomas, deine Session auf der W-JAX lautet Frontend-Architektur für Microservices. Dabei gehst du explizit auf Chancen ein, die sich dank des etablierten Web-Components-Standards ergeben. Welche Chancen gibt es da?

Thomas Kruse: Der Vortrag liefert ein ganzes Buffet an Optionen, wie Webfrontends für eine Microservice-Architektur umgesetzt werden können. Ziel des Vortrages ist dabei vor allem, das Spektrum aufzuzeigen und nicht einen goldenen Hammer zu vermarkten. Webcomponents spielen für mich eine besondere Rolle, wenn es darum geht, wiederverwendbare Widgets oder Teilfunktionalitaet anzubieten, die nicht an ein spezifisches Framework gekoppelt ist. Auch wenn der Tradeoff besteht, dass dann nicht unmittelbar Frameworkvorteile bei der Einbettung genutzt werden können, stellen Webcomponents einen guten Mittelweg dar, wenn Team, Projekt oder sogar unternehmensübergreifend Funktionalität wiederverwendet werden soll. Dabei ist es z.B. mit Angular Elements oder Polymer auch möglich, bei der Entwicklung der Komponenten auf ein Framework mit den entsprechenden Vorteilen zurückzugreifen.

Markus, du übernimmst auf der W-JAX den Workshop Architektur 101: Praktisch, konzentriert und ohne Hype. Dabei ist dein Spezialgebiet die datenzentrierte Analyse von Softwareprodukten. Weshalb ist diese aus deiner Sicht so wichtig?

Markus Harrer: Die Analyse von Softwaresystemen mit Hilfe von Werkzeugen aus dem Data-Science-Bereich ist für mich einer der Wege, wie Softwareentwickelnde ihre Bedenken und Schmerzen an Nicht-Techies kommunizieren können [7]. Durch nachvollziehbare Datenanalysen werden die ansonsten verborgenen Gedankengänge der Bedenkenträger*innen offengelegt. Probleme können somit Stück für Stück systematisch herausgearbeitet werden – von den Rohdaten zu den Erkenntnissen bis hin zur managementgerechten Darstellung. Dies ermöglicht eine sachliche Diskussion auch über unangenehme Probleme, deren Schwere in politisch überhitzten Projekten gerne heruntergespielt wird.

Stephan, du bist Trainer auf dem Software Architecture Summit. In deinem Workshop Lasst uns einen Monolithen (z)erlegen gehst du von einem Legacy-System aus, das schrittweise in eine Microservices-Struktur überführt wird. Welchen typischen Problemen begegnet man dabei?

Eine Anwendung ist nicht aufgrund ihrer technischen Architektur, sondern ihrer fachlichen Fähigkeiten so wichtig für den Kunden.

Stephan Pirnbaum: Ich sehe primär drei Probleme. Erstens: Die Lieferfähigkeit ist zu jeder Zeit zu erhalten. Das heißt, dass für die Umsetzung geplanter Refaktorisierungen die Lieferung neuer Features nicht gefährdet werden darf. Schließlich ist die Anwendung nicht aufgrund ihrer technischen Architektur, sondern ihrer fachlichen Fähigkeiten so wichtig für den Kunden und damit für uns. Demzufolge kann es erforderlich sein, zunächst architekturell suboptimale Lösungen zu finden, um dafür langfristig sicher zum Ziel zu kommen.

Zweitens: Fehlendes Wissen (z. B. durch Mitarbeiterfluktuation) und mangelhafte Dokumentation erschweren sowohl die Wartung und Weiterentwicklung als auch die Planung von Refaktorisierungen. Dies wird verstärkt durch über Jahre gewachsene Strukturen, unterschiedliche Entwicklungsstile und verschiedene eingesetzte Technologien.

Drittens: Die vollständige Entkopplung auf Java-Code-Ebene bringt ganz neue Herausforderungen mit sich. Dabei geht es sowohl um die Änderung von Abhängigkeitsstrukturen, zum Beispiel durch Einführung von asynchronem Messaging, aber auch um Themen wie Laufzeitverhalten, Verfügbarkeit und Resilienz gegenüber Infrastrukturproblemen. Allesamt Themen, die im Monolithen nie derart bedacht werden mussten.

Franziska, du bist auf der W-JAX ebenso im Workshop „Architektur 101: Praktisch, konzentriert und ohne Hype“ aktiv. Dabei soll auch das Handling von nichtfunktionalen Anforderungen nicht zu kurz kommen. Kannst du einmal ein Beispiel ausführen, wie man mit einer nichtfunktionalen Anforderung umgeht?

Franziska Dessart: In meinem aktuellen Projekt spielt Resilienz eine sehr große Rolle. Das System soll funktionieren, auch wenn Probleme auftreten oder umliegende System nicht so arbeiten, wie erwartet. Wir sind hier auch für den Betrieb zuständig und halten uns dieses Ziel in Diskussionen immer wieder vor Augen: “Wir wollen nachts nicht angerufen werden!” Das hilft, zu priorisieren und insgesamt bessere Entscheidungen zu treffen.

Take-aways – was haben wir nun gelernt?

Zum Schluss noch ein Take-away. Was sind eure Kernbotschaften, die die Leser – und natürlich die Teilnehmer eurer Sessions und Workshops – mitnehmen sollten?

Sandra Parsick: Die Kernbotschaft soll sein, dass, wenn ich Ziele definiere, ich mir auch darüber Gedanken machen muss, wie ich erkenne, dass ich diese Ziele erreicht habe – und das auf Dauer!

Hanna Prinz: Am besten nehmen die Teilnehmer natürlich ein Service Mesh für ihre Microservice-Anwendung mit und setzen es gleich in ihrer Microservice-Anwendung ein 🙂 Aber Spaß beiseite. Es gibt viele gute Gründe für ein Service Mesh, aber auch ein paar dagegen. Meine Teilnehmer werden den Workshop mit einer Einschätzung verlassen, ob sich ein Service Mesh für ihr Projekt lohnt. Es würde mich wundern, wenn der Großteil keine überzeugenden Gründe dafür sieht. Deshalb, und weil der Markt nicht ganz einfach zu durchschauen ist, wird es auch darum gehen, das richtige Service Mesh Tool auszuwählen. Doch auch wenn ein Service Mesh nicht sofort in die Projekte eingeführt wird, möchte ich die Teilnehmer dazu anregen, darüber nachzudenken, wie (oder ob) typische Service-Mesh-Funktionen wie Monitoring, Resilienz und Sicherheit aktuell umgesetzt sind – oder auch nicht.

Es gibt nicht nur Nachteile bei einem monolithischen Ansatz. Gerade wenn es um hochintegrierte Frontends geht, kann hier eine Architektur, die auf ein Modulsystem aufsetzt und im Backend Microservices nutzt, viele Vorteile ausspielen.

Thomas Kruse: Es gibt nicht nur Nachteile bei einem monolithischen Ansatz. Gerade wenn es um hochintegrierte Frontends geht, kann hier eine Architektur, die auf ein Modulsystem aufsetzt und im Backend Microservices nutzt, viele Vorteile sowohl für Entwickler als auch Anwender ausspielen.

Typischerweise ist ein Frontend eher nach fachlichen Aufgaben aufgeteilt und weist eine etwas gröbere Granularitaet auf, als dies bei Microservices möglich ist. Jedoch bieten sich dafür auch flexiblere Möglichkeiten zur (Re-)Integration an, wie zum Beispiel Hyperlinks. Mit der passenden Architektur merkt dabei ein Nutzer nicht einmal unbedingt, dass er die Anwendung wechselt.

Markus Harrer: Softwarearchitekt*innen sollen sich von Anfang an mit den Qualitätsansprüchen der Stakeholder beschäftigen, um deren ganz konkreten Bedürfnisse frühzeitig als Einflussfaktoren für Architekturentscheidungen nutzen zu können.

Stephan Pirnbaum: Euer bestehendes System ist nicht ohne Grund so wertvoll und schwer ersetzbar geworden, wie es heute ist. Dieser Schatz darf aufgrund neuer Hypes nicht einfach weggeworfen werden. Eine Bewertung der Umsetzbarkeit neuer Technologien und Ansätze im Rahmen der kontinuierlichen Verbesserung ist daher unabdingbar. So kann man mit kontinuierlichem Einsatz und planvollem Vorgehen dem Monolithen zu neuem Glanz verhelfen, egal ob am Ende eine Microservices-Landschaft oder ein strukturierter Monolith steht.

Franziska Dessart: Unser Workshop ist ja in vier Teile gegliedert, die sich jeweils auf unterschiedliche Aspekte von Software-Architektur konzentrieren. Jeder der Teile bringt sicherlich eine eigene Kernbotschaft mit sich. Allen gemeinsam ist aber vermutlich: Am Ende geht es immer irgendwie um Kommunikation, um das Miteinander-Reden, um den Austausch und auch das Festhalten von Informationen. Wenn wir darin gut sind, schaffen wir es auch, eine gute Architektur für unsere Systeme zu erarbeiten.

Vielen Dank für Eure Interviews!