Suche
Praxis-Check Software-Architektur - Teil 3

Software-Architektur-Trends 2018: Auf diese Themen lohnt sich der Blick

Hartmut Schlosser

© Shutterstock / patpitchaya

Sieben Experten sprechen über die Rolle des Software-Architekten im Jahr 2018. Im dritten Teil unserer Reihe geht es um die Frage, welche Trends der Software-Architektur momentan ein besonderes Interesse verdienen.

Architektur-Trends 2018

Im ersten Teil unseres Praxis-Checks Software-Architektur ging es um die Frage, wie man als Software-Architekt den Spagat zwischen Flexibilität und Stabilität einer Architektur schafft. Teil 2 widmete sich der Aufgabe des Architekten als Vermittler zwischen Fachlichkeit und Technologie. Im dritten Teil soll es um eine persönliche Einschätzung der Experten gehen, welche Themen der Software-Architektur aktuell eine besondere Beachtung finden sollten.

JAXenter: Welchen Trend findest du im Bereich der Software-Architektur momentan besonders spannend – und warum?

Ich sehe zu oft Architekturen, die dem letzten Trend entsprechen, aber keiner kann sagen, welche Ziele damit wie erreicht werden sollen.

Eberhard Wolff: Der nächste Trend sollte sein, sich mit den Zielen und Herausforderungen des jeweiligen Projekts auseinanderzusetzen und dafür passende technische Lösungen zu finden. Andere Trends können sicher helfen, um neue Lösungsmöglichkeiten kennen zu lernen. Es ist gut, wenn man sie unvoreingenommen für die passenden Szenarien nutzt. Aber ich sehe zu oft Architekturen, die dem letzten Trend entsprechen, aber keiner kann sagen, welche Ziele damit wie erreicht werden sollen. Das finde ich schade, denn die Aufgabe eines Architekten ist eben, eine technische Lösung zum Erreichen der Ziele des Projekts zu finden.

Die Experten

Ralf D. Müller arbeitet als Architekt und Entwickler und erlebt täglich die Notwendigkeit effektiver Dokumentation. Er ist erklärter AsciiDoc-Fan und Committer bei arc42 sowie Gründer des docToolchain Projektes.

Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie.

Henning Schwentner (@hschwentner), Coder • Coach • Consultant bei der WPS – Workplace Solutions

Ana Medina – Software-Entwicklerin und Chaos Engineer bei Gremlin, San Francisco

Michael Plöd – Principal Consultant bei innoQ. @bitboss

Andreas Weigel ist Softwareentwickler und Berater bei synyx GmbH & Co. KG

Christian Stettler ist Senior Consultant und Architekt bei INNOQ in der Schweiz

Ralf D. Müller: Ich beobachte momentan, wie der Ansatz der Microservices reift. Zum Einen setzt sich die Erkenntnis durch, dass auch Microservices nicht die Lösung für jedes Problem sind und man abwägen muss. Aber auch die Art der Implementierung von Microservices auf der JVM entwickelt sich weiter. So steht mit micronaut.io mittlerweile ein Framework zur Verfügung, welches zielgerichtet auf Microservices hin entwickelt wurde und nicht als Full-Stack Framework entstand. Auch der Serverless-Ansatz ist in diesem Zusammenhang spannend. Solche Entwicklungen sorgen dafür, dass die Arbeit als Software-Architekt immer spannend bleiben wird.

Henning Schwentner: Mir ist das Thema „Domäne verstehen, um die richtige Software zu bauen“ sehr wichtig. Neben Event Storming ist Domain Storytelling ein tolles Werkzeug dafür. Wir lassen die Anwender ihre Geschichte erzählen. Dabei zeichnen wir sie mit einer einfach zu verstehenden Bildsprache auf. Die entstehenden Bilder (die sogenannten Domain Stories) verwendet man, um direkt rückzukoppeln, ob wir die Anwender richtig verstanden haben. Mehr Infos gibt’s auf domainstorytelling.org und hoffentlich bald in dem Buch, das Stefan Hofer und ich gerade darüber schreiben.

Andreas Weigel: Aktuell beschäftigen mich Fragestellungen in Bezug auf die Vertikalisierung eines Produktes, die auf autarke Teams abzielen. Der fachliche oder organisatorische Schnitt, sowie die Implikation auf die Architektur sind nur eine Facette davon. Die eventuell folgende Integration auf Frontendebene oder ein Betrieb, der definierten Service Level Agreements genügt, sind dabei weitere wichtige Themen.

Christian Stettler: Mir gefällt generell der Trend zu „self-contained systems“, auf allen Ebenen, nicht nur auf der technischen. Ich finde es spannend, dass wir zunehmend in „Produkten“ denken, nicht mehr in Projekten, und dass wir dabei langfristig Verantwortung für Problemstellungen und deren Lösungen übernehmen wollen, in der ganzen Breite und Tiefe und über den ganzen Lebenszyklus hindurch. Dabei nehme ich wahr, dass sich der Fächer der konzeptionellen und technischen Möglichkeiten ständig verbreitert, was die Auswahl des erfolgsbringenden Ansatzes nicht einfacher macht. Die für eine gute Entscheidung aus meiner Sicht zwingend notwendige Nähe zum “Business” und anderen Disziplinen empfinde ich als herausfordernd und bereichernd. Dies erlaubt es uns auch, über die Zeit besser zu lernen, welche unserer Entscheidungen sinnvoll waren, und in welchen Bereichen unsere Annahmen bzw. die Schlussfolgerungen daraus nicht richtig waren und weshalb. Dadurch sehen wir direkter, welchen Einfluss unsere Arbeit auf den Geschäftserfolg hat. Ich persönlich bin gerne dort, wie es “real” ist, auch wenn es dort nicht immer gemütlich ist.

Michael Plöd: Generell finde ich ein Rückbesinnen auf zahlreiche Grundlagen spannend. Dazu gehören zum Beispiel Event-getriebene Systeme, die an sich nichts Neues sind, aber gerade im Bereich lose gekoppelter Microservices viele Vorteile aufweisen. Weiterhin finde ich das Zusammenwachsen von Architektur und Organisation sehr interessant, weil sich hierbei viele noch ungehobene Potentiale verstecken.

Ana Medina: Ich habe die meiste Zeit damit verbracht, mich um die Zuverlässigkeit von Systemen zu kümmern. Dabei habe ich viele neue Prinzipien von der Observability Community gelernt. Da ich auf der Seite der Infrastruktur-Entwicklung arbeite, sehe ich die Schmerzpunkte, die uns komplexe IT-Systeme immer wieder bringen. Alles, was helfen kann, das in Ordnung zu bringen, erregt meine Aufmerksamkeit: Observability bedeutet, in das Innere des Systems sehen zu können, indem man es von außen beobachtet. Das ist insbesondere dann gut, wenn man nicht weiß, wo man zu suchen anfangen soll, wenn etwas passiert ist.

MEHR ZUM THEMA: Keynote: „Chaos engineering is not about causing chaos“

Wie werde ich ein erfolgreicher Softwarearchitekt?

Unsere Experten sind zu verschiedenen Themen auf Konferenzen und Trainings unterwegs. In einer Schlussrunde wollen wir wissen, womit sie sich aktuell beschäftigen und welche Erkenntnisse man aus ihren Vorträgen und Workshops mit nach Hause nehmen kann.

Eberhard, auf der W-JAX hältst du einen Talk namens „Wie werde ich ein erfolgreicher Softwarearchitekt?“ Dabei gehst du auf Voraussetzungen für einen guten Softwarearchitekten ein, auf die man zunächst vielleicht nicht gleich kommt. Kannst du da einmal ein Beispiel nennen?

Eberhard Wolff: Softwarearchitekten arbeiten zwar mit technischen Herausforderungen, aber zentral ist die gemeinsame Arbeit an den zu lösenden Problemen. Daher geht es in dem Vortrag vor allem darum, wie Architekten ihre Rolle leben sollten, ihr Wissen so einbringen können, dass es auch wirklich umgesetzt wird, und wie man auch das Wissen der anderen Team-Mitglieder nutzbar macht. Aber es gibt natürlich auch ein paar ganz praktische Tipps.

Ich verfolge den Anspruch, den  fachlichen Fokus bis in die hinterletzte Code-Zeile zu tragen.

Christian, du bist auf dem Software Architecture Summit mit einem Workshop zu Domain-driven Design vertreten. Dabei wird es darum gehen, Bounded Contexts ganz konkret in Code umzusetzen. Als Optionen erwähnst du die Onion Architecture und Stereotypen. Worum geht es dabei?

Christian Stettler: Dabei geht es darum, wie wir den fachlichen Fokus aus den Diskussionen mit unseren Stakeholdern und aus dem strategischen Design von DDD bis in den Code beibehalten können. Seit ich mich intensiv mit DDD beschäftige, verfolge ich den Anspruch, diesen fachlichen Fokus wirklich bis in die hinterletzte Code-Zeile zu tragen, die gemeinsame Sprache (sowohl die fachliche, als auch diejenige der Elemente der Applikationsarchitektur) darin abzubilden und dabei die Fachlichkeit konsequent von Technologien und Frameworks zu trennen.

Dabei können die Konzepte der Onion Architecture und der Einsatz von Stereotypen wirklich helfen. Ich habe damit in der Vergangenheit in “Real World“ spannende Erfahrungen gemacht und auch wahrgenommen, dass Kollegen im Team (und auch ich) wiederholt einen “Eye-Opener-Moment” erlebten. In diesem Workshop möchte ich basierend auf diesen Erfahrungen aufzeigen, wie eine solche Umsetzung aussehen kann. Dabei möchte ich auch Aspekte ansprechen, über welche man erst stolpert, wenn man es wirklich tut.

W-JAX 2018 Java-Dossier für Software-Architekten

Kostenlos: 40+ Seiten Java-Wissen von Experten

Sie finden Artikel zu Enterprise Java, Software-Architektur, Agilität, Java 11, Deep Learning und Docker von Experten wie Kai Tödter (Siemens), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

Ralf, dein Thema auf der W-JAX ist „Docs-as-Code.“ Zusammen mit Gernot Starke schreibst du hier auf JAXenter ja auch eine Kolumne dazu. Wo liegt der große Unterschied zwischen dem Docs-as-Code-Ansatz, den ihr beschreibt, und der traditionellen Art und Weise, Software zu dokumentieren?

Ralf D. Müller: Der Unterschied ist recht groß und vielfältig. Ich denke, jeder kennt die klassische, mit einer Textverarbeitung erstellte Dokumentation, die getrennt vom Code verwaltet wird. Dokumentation gehört aber, wie Tests auch, zum Code und sollte mit diesem verwaltet werden. Dadurch ist immer klar, wo die aktuelle Version liegt.

Sobald die Dokumentation zusammen mit dem Code verwaltet wird, können auch weitere Aspekte der Softwareentwicklung auf die Dokumentation übertragen werden. So kann z.B. das Aktualisieren von Diagrammen automatisiert im Build umgesetzt und die Dokumentation sogar automatisiert getestet werden. Wird eine Änderung am Code vorgenommen, so gehört es mittlerweile zur Definition of Done, auch die Tests anzupassen. Mit Docs-as-Code wird im gleichen Schritt auch die Dokumentation gepflegt, weil ein Pull-Request sonst nicht als vollständig im Sinne der DoD angesehen wird.

JAXenter: Ana, du stellst Chaos Engineering auf dem Software Architecture Summit vor. Welche Botschaft sollen die Teilnehmer mit nach Hause nehmen?

Ana Medina: Wir sollten keine Angst davor haben, dass Systeme einmal ausfallen. Wir sollten die Angst davor verlieren, Dinge auch einmal absichtlich kaputt zu machen. Denn Systeme gehen ohnehin die ganze Zeit über kaputt, und zwar auf ganz unterschiedliche Art und Weise. Wenn man proaktiv kontrollierte Chaos-Engineering-Experimente durchführt, dann kommt man dem unkontrollierten Ausfall zuvor. Mit dem Aufkommen der Microservices-Architekturen sind unsere Systeme komplexer geworden und haben daher auch mehr Fehlerquellen. Unternehmen sind mit der Situation konfrontiert, dass sie durch Ausfälle viel Geld verlieren. Ausfallzeiten oder eine schlechte Performance werden immer schwieriger zu rechtfertigen, und Kunden sind zunehmend bereit, auf die Suche nach einem anderen Produkt oder einer besseren Dienstleistung zu gehen, bis sie diejenigen finden, die ihre Zuverlässigkeitsanforderungen erfüllen.

Henning, auf der W-JAX wird es ein Lab zum Thema „Event Storming“ geben. Wie funktioniert Event Storming – und weshalb sollte man es machen?

Henning Schwentner: Die Grundaufgabe von Software ist, unseren Anwender bei seiner Arbeit zu unterstützen. Damit wir das tun können, müssen wir seine Arbeit (d.h. die Domäne) verstehen. Event Storming ist ein Werkzeug, das uns dabei hilft. Bewaffnet mit haufenweise Klebezetteln wird Wissen aufgebaut, ausgetauscht und vertieft. Es hilft uns dabei, eine gemeinsame Sprache, Kontextgrenzen und Domänenmodelle zu finden.

Domain Driven Design im Videotutorial

Im entwickler.tutorial Domain-Driven Design, führt Hennig Schwentner Sie Schritt für Schritt durch das komplexe DDD-Themengebiet: Event Storming, Strategic Design, Context Mapping, Ubiquitous Language u.v.m.

Michael, auf dem Software Architecture Summit machst du einen Deep-Dive-Workshop zur Modellierung von Aggregaten, Entities und Value Objects. Dabei wirst du den Bereich des Tactical Designs von DDD behandeln, insbesondere in Bezug auf Aggregates. Was hat es mit Tactical Design und Aggregates auf sich, und wie setzt du sie ein, um eine losere Kopplung der fachlichen Bereiche zu erhalten?

Michael Plöd: Generell geht es beim Tactical Design um die Ausgestaltung der so genannten „Internal Building Blocks“. Diese stellen als Architekturmuster den internen Aufbau eines Bounded Contexts dar. Es geht hierbei somit primär um eine interne Entkopplung einzelner Teilbereiche und nicht um eine externe. Letztere wird üblicherweise durch den Bounded Context abgedeckt.

Lesen Sie auch: Domain-driven Design in Aktion: Mehr Dynamik mit Event Storming

Aggregates sind eine fachliche Klammer um Entities und Value Objects. Sie besitzen eine Root Entity, die häufig als „Aggregate Root“ bezeichnet wird und die den Lebenszyklus des Aggregates steuert. Im Laufe der Zeit haben sich Aggregates auch ein wenig weiterentwickelt. So betrachtet die DDD-Community Aggregates inzwischen auch als Konsistenz- und Transaktionsgrenze. Kombiniert man diese Idee mit gutem objektorientiertem Design, und berücksichtigt man hierbei zudem noch das Geheimnisprinzip, dann erhält man eine potentiell sehr saubere Entkopplung innerhalb einer Applikation.

Ich sage immer wieder gerne, dass man mit Aggregates sehr gute und wartbare Monolithen bauen kann, was trotz des derzeitigen Microservices-Trends für einige Teams eine bessere Option darstellt. Im Rahmen meines Workshops werden wir anhand einer Fallstudie ein komplexes Beispiel in Bezug auf Aggregates zerlegen und modellieren.

Andreas, „Observability in einer Microservice-Welt“ lautet dein Talk auf der W-JAX. Dabei beschreibst du eine Migration einer bestehenden Anwendung zu einer verteilten Systemarchitektur. Weshalb ist dabei das Thema „Observability“ so wichtig?

Andreas Weigel: „Observability“ als Ausdruck der unterschiedlichen Beobachtungsmöglichkeiten ist in verteilten Systemarchitekturen wichtig, um das Verhalten der Software nachvollziehen zu können. Während man bei monolithischen Anwendungen eine einfache Möglichkeit hat, die Anwendung zu debuggen, ist die Analyse über Servicegrenzen hinweg ein höherer Aufwand. Damit sieht man sich schon in der Entwicklungsphase mit neuen Herausforderungen konfrontiert.

In dem Talk beschreiben wir, welchen Informationsgehalt Techniken wie zentrales Logging, Metrics und Tracing haben und wie sie sich unterscheiden. Außerdem, wie sie dabei helfen können, Anomalien zu entdecken und zu verstehen, ob sich die Software in Produktion so verhält, wie es erwartet wird.

JAXenter: Vielen Dank für eure spannenden Antworten!

Praxis-Check Software-Architektur

HINTERGRUND ZUM THEMA:

Die Rolle des Architekten im 21. Jahrhundert

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: