Suche
Sieben Experten über aktuelle Themen der Software-Architektur

Praxis-Check Software-Architektur: Die Architektur-Trends 2017

Hartmut Schlosser

© Shutterstock / enterlinedesign

 

Wir sprechen mit sieben Software-Architekten über aktuelle Architektur-Trends in der Software-Entwicklung. Eine zentrale Rolle spielt dabei Conway’s Law, aus dem wir die Implikationen auf Domain-driven Design, Microservices und Unternehmensorganisation ableiten. In der Abschlussrunde geht es um die persönlichen Steckenpferde der Experten: Welche Themen im aktuellen Diskurs sind besonders relevant für ihre Praxis?

Was bisher geschah…

Im ersten Teil dieser Reihe ging es um die Erscheinungsformen von Conway’s Law und darum, wie man festgefahrene Unternehmensstrukturen, die sich negativ auf Software-Architekturen auswirken, aufbrechen kann.

In Teil II haben wir uns den Zusammenhang zwischen guter Software und Unternehmensstrukturen genauer angeschaut und die Frage beantwortet, wie viel Flexibilität einer Architektur gut tut.

Im abschließenden dritten Teil fragen wir die Experten, welche Themen in der aktuellen Diskussion um Software-Architektur Ihnen besonders am Herzen liegen.

Trends der Software-Architektur

Die Experten

Dr. Carola Lilienthal ist CEO bei der WPS – Workplace Solutions GmbH. Seit 2003 analysiert sie die Zukunftsfähigkeit von Softwarearchitekturen und wendet in ihren eigenen Projekten DDD an.

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.

Stefan Tilkov ist Geschäftsführer und Principal Consultant bei der innoQ Deutschland GmbH, wo er sich vorwiegend mit der strategischen Beratung von Kunden im Umfeld von Softwarearchitekturen beschäftigt.

Dr. Gernot Starke (innoQ Fellow), ist Gründer und Maintainer der Open-Source-Architekturprojekte arc42 und aim42, (Mit-)Gründer und aktives Mitglied des iSAQB sowie Autor mehrerer Fachbücher.

Lars Röwekamp, Gründer des IT-Unternehmens OPEN KNOWLEDGE GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends.

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.

Matthias Bohlen ist Softwarearchitekt und Mitglied des iSAQB. Mit seinen Coaching-Programmen hilft er Führungskräften und Teams dabei, profitable Produkte zur Tür hinaus zu bekommen, ohne dabei den Verstand zu verlieren.

Welcher Aspekt in der aktuellen Diskussion um Softwarearchitektur ist für dich besonders anregend für deine Arbeit?

Durch Domain-Driven Design wird die Fachlichkeit explizit in den Fokus der Softwareentwicklung gerückt.

Carola Lilienthal: Neben Conway’s Law hat die Diskussion zu Domain-Driven Design und Microservices meine Arbeit in den letzten Jahren sehr beeinflusst und vorangebracht. Durch Domain-Driven Design wird die Fachlichkeit explizit in den Fokus der Softwareentwicklung gerückt. Microservices bieten dann die technische Umsetzung, um die großen fachlichen Strukturen in Software abzubilden.

Ralf D. Müller: Der für mich wichtigste Aspekt ist die richtige Verteilung der Module eines zu implementierenden Systems auf Teams und Personen. Das kann auch bedeuten, dass man aus einem Projekt u.U. zwei machen muss, um den richtigen Schnitt des Systems zu erreichen.

Stefan Tilkov: Für mich ist die Rückkehr zu pragmatischen, einfachen, dem tatsächlich identifizierten Problem angemessenen Lösungen im Kleinen anstelle generischer, eierlegender Wollmilchsäue ein wichtiger Gedanke. Wenn ich Software so baue, dass die einzelnen Teile, aus denen sie besteht, nicht für die Ewigkeit perfekt sein müssen, sondern sich schnell und unkompliziert austauschen lassen, kann ich mich auf das Problem konzentrieren und genau das lösen. Passt die Lösung in 12 Monaten nicht mehr, werfe ich den einen Baustein im Zweifelsfall weg und entwickle ihn auf eine andere, bessere, vielleicht modernere Art neu.

Gernot Starke: Bei vielen Entwicklungsteams, auch in großen Unternehmen, ist mittlerweile angekommen, dass der Wandel unserer Branche immer schneller wird. Das führt dazu, dass verkrustete Strukturen und überkommene Entscheidungen vermehrt in Frage gestellt werden, dass Organisationen und Entwickler die Notwendigkeit für Änderungen, Innovation und Evolution mehr einsehen.

Lars Röwekamp: Wenn wir schon bei „Gesetzen“ sind, fällt mir sofort Postel’s Law ein: „Be conservative in what you do, be liberal in what you accept from others.“ Auch dieses Gesetz deckt sich stark mit der Aussage von Jeff Sussna (siehe Teil 2 dieser Serie: ein System muss bereit für Änderungen sein), da es sinngemäß besagt, dass ich von Anfang an „tolerante“ Schnittstellen in meinem Design einplanen sollte, um so flexibel auf geänderte Anforderungen reagieren zu können.

Von Anfang an sollte man „tolerante“ Schnittstellen in seinem Design einplanen.

Ebenfalls für extrem wichtig halte ich – nicht nur, aber vor allem auch bei lose gekoppelten Systemen, wie Microservices – ein gutes Domänen-Design. Mir wird leider nach wie vor viel zu viel über Technologie und zu wenig über eine geschickte Modularisierung der Fachlichkeit diskutiert. Gut durchdachte Bounded Contexts verbunden mit einem sauberen, zukunftssicheren Schnittstellendesign haben schon so manches Projekt zum Erfolg geführt.

Eberhard Wolff: Continuous Delivery (CD) ist für mich ein wichtiger Fortschritt für die Produktivität. Microservices unterstützt CD in der Architektur. Die beiden Themen finde ich so wichtig, dass ich darüber Bücher geschrieben habe. Microservices machen Fachlichkeit und Domain-driven Design wieder wichtiger. Alle diese Punkte sind meiner Meinung nach bei der Software-Architektur wegweisend.

Matthias Bohlen: Spannend finde ich im Moment die Idee, einen expliziten Unterschied zwischen Makro- und Mikroarchitektur zu machen. Die Makroarchitektur beschreibt den „äußeren Rand“ eines jeden Subsystems. Da möchte man Einheitlichkeit, damit die Subsysteme gut zusammenpassen. Die Mikroarchitektur beschreibt das Innere eines Subsystems. Es stellt sich heraus, dass man dort keine Einheitlichkeit braucht, sondern die Mikroarchitektur jedem Team selbst überlassen kann, solange es die Konsequenzen daraus selbst zu tragen bereit ist und nicht auf eine arme Operations-Mannschaft verschiebt, die sich dann damit herumschlagen muss. Die Trennung in Makro und Mikro kann Teams richtig schnell machen. Als Architekt brauche ich so weit weniger einzugreifen als früher.

Schlußrunde: Deine Themen der Software-Architektur

Carola, Domain-driven Design ist dein Thema auf der kommenden W-JAX. Welchen Zusammenhang siehst du zwischen DDD und der Theorie Conway’s?  

Carola Lilienthal: Conway gibt die theoretische Fundierung zu der Empfehlung von Eric Evans bei Domain-Driven Design, dass es pro Bounded Context (abgegrenzter Teil der Fachlichkeit) ein eigenes Team geben soll. Ein Bounded Context soll seine Fachlichkeit konsistent unabhängig von den anderen Teilen der Software umsetzen. Dieses Ziel erreicht man laut Eric Evans und auch nach der Theorie von Conway am besten, wenn ein geschlossenes Team an der Software für diesen Bounded Context arbeitet.

Ralf, auf dem Software Architecture Summit hältst du einen Talk zum Thema “Hitchhiker’s Guide to Architecture Documentation.”  Ich nehme an, das Wichtigste beim Dokumentieren ist ein Handtuch. Was ist aber das Zweitwichtigste? Worauf sollte man beim Dokumentieren von Software-Architektur achten?

Ralf D. Müller: Das Zweitwichtigste ist natürlich, dass man nicht in Panik verfällt 😉

Spaß beiseite – die Art und Weise, wie eine Softwarearchitektur dokumentiert wird, muss zur Vorgehensweise des Projekts und den dokumentierenden Personen passen.

Gernot Starke und ich stellen einen Ansatz vor, wie die Erstellung der Dokumentation mit den Tools eines Entwicklers effizient erfolgen kann. Die in agilen Projekten dringend notwendige Dynamik der Dokumentation spielt dabei eine genauso große Rolle, wie das kollaborative Erstellen der Doku im Team.

Stefan, auf der W-JAX stellst du Patterns und Antipatterns von Microservices vor. Kannst du einmal ein Beispiel nennen, wann eine Microservices-Architektur eine gute Lösung, wann aber auch eher ein Irrweg darstellen kann?

Stefan Tilkov: Ein schönes Beispiel, ebenfalls aus der Praxis: Man entwickelt eine Microservice-Architektur, bestehend aus unzähligen, winzig kleinen Services, schneidet aber so, dass einzelne Services eine zentrale Rolle spielen und fast alle anderen von ihnen abhängen. Man kauft sich damit enorme Koordinationsprobleme ein und wundert sich, dass man statt einer agilen Architektur nur einen verteilten Monolithen bekommt, der sich vor lauter Container-Overhead auf einem 16GB-Entwickler-Laptop nur noch mit Mühe starten lässt. Im Prinzip ist das auch wieder eine Conway-Verletzung, weil man vergisst, dass ein zentraler Grund für Modularisierung eine gute Entkopplung und eine „Separation of Concerns“ ist. Das hat David Parnas übrigens schon Anfang der 70er gut erkannt …

Lesen Sie auch: Knigge für Softwarearchitekten: Fortschritt oder Verschlimmbesserung?

Gernot, du erzählst auf der kommenden W-JAX die „VENOM“-Story. Klingt irgendwie giftig. Worum wird es gehen?

Gernot Starke: Im Open-Source-Projekt aim42 (http://aim42.org) engagiere ich mich für mehr Systematik bei der Verbesserung und Evolution bestehender Systeme. VENOM illustriert anhand eines (riesigen) Beispiels, was dabei geschehen könnte, und zeigt praktische Maßnahmen auf, um große Systeme wieder „auf die Spur“ zu bringen. Dabei prallen Meinungen aufeinander, es gibt Streit, Opfer und überraschende Wendungen. Wie der Showdown ausgeht, verrate ich erst im Vortrag.

Lars, auf der W-JAX hältst du unter anderem auch einen Talk zum Thema Serverless. Welchen Zusammenhang siehst du zwischen Serverless und der Theorie Conway’s?

Lars Röwekamp: Im Zusammenhang mit Serverless fällt auch immer wieder der Begriff NoOps. NoOps bedeuten in diesem Zusammenhang zwar nicht, dass gar kein operationaler Aufwand mehr notwendig ist. In Konsequenz benötigt man aber kein dezidiertes Ops bzw. DevOps Team. Auf die Spitze getrieben könnte man also soweit gehen und behaupten, dass dank Serverless keine Kommunikation mit anderen und somit auch keine Architektur mehr notwendig ist. Dies wäre allerdings ein wenig blauäugig, denn in der Praxis muss sich natürlich trotzdem jemand um die ursprünglich bei dem Ops- oder DevOps-Team aufgehängten Themen, wie Security, API Gateway etc. kümmern und die durch den Cloud-Anbieter für diesen Zweck zur Verfügung gestellte Infrastruktur konfigurieren und administrieren. Gleiches gilt für weitere, klassische Cross-Cutting-Aspekte, wie zum Beispiel verteiltes Logging und übergreifendes Monitoring.

Eberhard, auf der W-JAX hältst du eine Session, in der du hinter den aktuellen Hype um Microservices blickst. Was würdest du momentan eher dem Hype zuordnen, was der echten Wertschöpfung, die die Microservices-Idee ermöglicht?

Für mich sind Microservices ein guter Türöffner, um eine Architektur-Diskussion zu starten.

Eberhard Wolff: Für mich sind Microservices ein guter Türöffner, um eine Architektur-Diskussion zu starten und Themen wie Fachlichkeit, Domain-driven Design oder Continuous Delivery ebenfalls anzusprechen. Dafür ist der Hype auf jeden Fall nützlich. Außerdem erlauben Microservices viel stärkere Entkopplung und lösen so viele Probleme klassischer Modularisierung. Mit Self-contained Systems gibt es außerdem einen Best-Practices-Ansatz für Microservices, deren Vorteile in der Praxis schon viele Projekte aufgezeigt haben.

Matthias, auf dem Software Architecture Summit entwirfst du eine Smartphone-App, wobei du Prinzipien des DDD anwendest, um das Java-Backend zu aufzuteilen. Weshalb ist DDD an dieser Stelle nützlich?

Matthias Bohlen: DDD ist nützlich, um eine App schnell in ihre Bestandteile aufteilen und diese Bestandteile an getrennte Teams geben zu können. So können alle getrennt losmarschieren und trotzdem gibt es bei der Integration nur wenig Probleme.

Die Idee in DDD ist ja, die Grenzen in der Software dort zu ziehen, wo zwischen den Menschen sowieso natürliche Sprachgrenzen herrschen. Trenne dort auf, wo ein Wort nicht mehr dasselbe bedeutet  – man denke nur an Martin Fowlers schönes Beispiel mit den Worten „Kunde“ und „Produkt“, jeweils einmal im Sales- und einmal im Support-Kontext betrachtet – sehr erhellend!

Das passt wunderbar zu Conway’s Law: Wo Sprachgrenzen sind, sind Kommunikationsschwierigkeiten. Also ist es total sinnvoll, dort auch in der Software die Schnittstellen sitzen zu haben. In der Session wird uns das helfen, diese Grenzen schnell zu finden und zu definieren, damit wir weiterkommen.

Vielen Dank an Euch alle für die ausführlichen Antworten!

Praxis-Check Software-Architektur


Teil 1: Conway’s Law auf der Spur
Teil 2: Was macht gute Architektur aus?
Teil 3: Architektur-Trends 2017

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.