W-JAX 2019: „Java-Entwickler müssen eine Mauer überwinden“

Die W-JAX 2019 ist eröffnet. In der ersten Konferenz-Keynote ging es um eine Standortbestimmung der Java-Community. Zudem erhielt die spannende Frage eine Antwort, wie Software-Architekturen mit dem immer schnelleren Wandel der Märkte Schritt halten können. Denn konstant scheint hier nur eins zu sein: die Veränderung!

Wie schlägt sich Java im Jahr 2019? Es steht anscheinend vor einer Mauer, die es überwinden muss. Diese Mauer heißt „Java 8“, wie W-JAX-Program-Chair Sebastian Meyen in seiner Eröffnungskeynote demonstrierte. Während die Innovationsgeschwindigkeit von Java mit der erhöhten Release-Frequenz gestiegen ist, verweilt ein Großteil der Entwickler noch bei der Java-Version 8, was Statistiken belegen:

Java vor der Mauer Java 8, Quelle: JetBrains

Wie kann man die Mauer überwinden? Ein Mittel dazu ist die Einführung von Continuous Delivery, regt Sebastian Meyen an. Für Unternehmen, die die Kunst beherrschen, Software schnell und regelmäßig in Betrieb zu nehmen, ist ein Java-Update alle 6 Monate kein Schreckensszenario. Wer nicht updated, läuft Gefahr, abgehängt zu werden – denn sind inkrementelle Updates von einer Version zur nächsten meist einfacher als der Sprung über viele Versionsnummern hinweg. Die Mauer wird dann zwar nicht höher, dafür aber umso breiter, könnte man sagen.

Wie auch immer man mit den schnelleren Java-Releases umgeht – es wäre tragisch, wenn der Java-Zug just zu dem Zeitpunkt zum Stillstand käme, da die Innovation Fahrt aufnimmt. Meyen:

Es wäre schade, wenn Java zum neuen Cobol würde, wenn die IT-Welt in einigen Jahren resümieren müsste: Java ist bei Version 8 stehengeblieben – den Rest hat niemand mehr mitgemacht.

Angst vor Stillstand muss indes niemand haben – dafür ist die immerhin fast 25 Jahre alte Java Community in den letzten Jahren zu beweglich gewesen. Und auch jetzt tut sich viel in der Breite – beispielsweise mit Cloud-native Frameworks wie Quarkus, Micronaut und der GraalVM.

Auf Architekturebene scheint der Hype um Microservices zu verebben und die bleibende Erkenntnis zu hinterlassen, dass die Strukturierung von Software gemäß überschaubarer fachlicher Einheiten vorteilhaft ist. „Der Hype um Microservices hat uns das alte Konzept DDD wiederentdecken lassen. DDD lehrt uns, dass eine domänenspezifische Software-Struktur nicht unbedingt mittels Microservices erreicht werden muss.“ Welch Ironie.

Das Thema Domain-driven Design ist auf der W-JAX denn auch in einem speziellen Track vertreten – genauso wie Java Core, Serverside Java, Spring, Serverless, DevOps, Kubernetes & Cloud sowie Webdevelopment mit JavaScript und Software-Architektur.

Nur eins ist konstant: die Veränderung

Dem Thema Software-Architektur nahm sich auch die folgende Keynote von Patrick Kua an. Der Chief Scientist und ehemalige CTO der Bank N24 stellte die brennende Frage: Wie schafft man es in Zeiten sich immer schneller verändernden Rahmenbedingungen, Software-Architekturen zu bauen, die mit dem steten Wandel Schritt halten?

Kua sieht die Antwort in dem Konzept evolutionärer Architekturen. Wodurch zeichnen sich diese aus?

Patrick Kua in seiner W-JAX Keynote: Building Evolutionary Architectures

 

Evolutionäre Architekturen tragen zunächst einmal der Erkenntnis Rechnung, dass Software in inkrementellen Schritten entsteht. Software-Entwicklung ist kein linearer Prozess, an dessen Anfang eine Architektur-Skizze steht, die dann stur implementiert wird, um am Ende das fertige Produkt zum Release auszukotzen. Evolutionäre Software-Architektur vollzieht sich vielmehr in vielen Schleifen: Nach dem Release einer kleinen Einheit wird Feedback eingeholt, auf dessen Basis Entscheidungen für die Weiterentwicklung getroffen werden können.

Feedback ermöglicht fundierte Veränderung – Guided Change, sagt Kua. Grundlage dafür können sogenannte Fitness Functions sein, die messen, wie gut eine gegebene Lösung einen bestimmten Zweck erfüllen. Auch die Konzepte des Chaos Engineering sind hilfreich, insofern hier gezielt überprüft wird, wie gut Software-Systeme mit Ausfällen zurecht kommen. Resiliente Software-Entwicklung lautet hier das Stichwort.

Von diesem Punkt aus kommt man dann schnell auf die Idee des Continuous Delivery, die schon Meyen evozierte. Grundlage für die Etablierung einer CD-Pipeline sei allerdings eine passende Kultur, ergänzt Kua, eine Art „DevOps-Mindset“, bei dem interdisziplinäre Teams die Verantwortung über den gesamten Feedback-Zyklus übernehmen. Kuas Liebslingszitat aus dem Buchklassiker „Continuous Delivery“ von Jez Humble und David Farley lautet:

If it hurts, do it more often.

Zu guter Letzt vollzieht sich Weiterentwicklung stets auf mehreren Dimensionen. Auf technischer Ebene sind dies zum Beispiel neue Sprachen, Frameworks, Tools und Systemupdates. Auf fachlicher Ebene können Änderungen des Marktes, neue Einkommensmodelle, ein verändertes Konsumverhalten oder eine neue Wettbewerbssituation Anpassungen an die Software-Architektur verlangen.

Kuas Fazit: Software-Architektur beschäftigt sich nicht nur mit dem Problem der richtigen technischen Entscheidung. Software-Architekten sind zunehmend mit der Frage konfrontiert, WIE gewisse Entscheidungen getroffen werden (sollten). Es geht um die Entscheidungskultur, die Grundlage ist für eine evolutionäre Software-Architektur.

Mit dieser Kernbotschaft entlies Patrick Kua die Zuhörer in die weitere Konferenzwoche.