Zum Glück von Architekten und Entwicklern gibt es heutzutage auch eine reichhaltige Auswahl an Programmiersprachen neben Java, etwa Go, Rust, Julia, Zig, Python, JS, C#, TypeScript oder Kotlin, die den ohnehin schon umfangreichen Werkzeugkasten bereichern. Da sich die genannten Technologien beständig weiterentwickeln, ist es mit einem einmaligen Erlernen nicht getan. Wir müssen kontinuierlich am Ball bleiben, um nicht den Anschluss zu verlieren. Der Begriff des Full-Stack-Developers bekommt dadurch eine ganz neue Bedeutung.
Das alles stellt nur die Spitze des Eisbergs dar, gibt es doch zahlreiche weitere Bibliotheken, Werkzeuge und APIs, die unserem Entwicklerleben einen neuen Sinn geben. Allein AWS bietet auf seiner Plattform Dutzende von Diensten für unterschiedlichste Aspekte, deren Zahl schneller wächst als Anwender lernen können. Eigentlich sollten sich Softwareentwickler mehr um die Fachdomäne kümmern müssen und weniger um Technologien, auch wenn Letztere zugegebenermaßen intellektuell sehr viel Spaß bereiten. Mir fällt in diesem Zusammenhang Aesops Fabel vom Schwein ein, das schon gierig auf die anderen Eicheln starrt, während es bereits Eicheln frisst.
Jede dieser technologischen Entwicklungen startet typischerweise mit einer "prototypischen" Implementierung, also einer Version 0.x. Deren Urheber sowie Dritte versuchen anschließend, die Komplexität in den Griff zu bekommen, indem sie in rascher Aufeinanderfolge weitere Features hinzufügen. Es wirkt beinahe so, als würden sie Komplexität bekämpfen, indem sie neue hinzufügen.
Das alles hat natürlich seine Gründe, weil es mittlerweile darum geht, als Erster am Markt zu sein, um eine möglichst große Community aufzubauen. Das gilt auch für Open-Source-Projekte, die sich schließlich um die Mitarbeit von Entwicklern bemühen.
Die einzige Konstante bleibt die Veränderung
Die Frage an dieser Stelle lautet, was in einem Entwicklungsuniversum zu tun ist, dessen einzige Konstante die Veränderung bleibt. Ignorieren können wir die technologische Entwicklung schließlich nicht. Folgende Aspekte spielen eine wichtige Rolle:
Einsatz von Java: Auch das Java-Ökosystem befindet sich im ständigen Fluss. Dafür gibt es einige Fixpunkte wie das JDK, das für alle JVM-Sprachen dasselbe bleibt. Dadurch lassen sich unterschiedliche Programmiersprachen einsetzen und sogar miteinander kombinieren.
Domain-Driven Design und Softwarearchitektur: In Projekten sollte es primär darum gehen, zunächst die Fachdomäne zu analysieren, um anschließend daraus passende Lösungstechnologien abzuleiten. Es bringt nichts, erst eine Lösung herauszupicken, um danach ein passendes Problem dafür zu finden. Die Softwarearchitektur fungiert immer als Rückgrat der Anwendung. Speziell Qualitätsattribute wie Sicherheit, Skalierbarkeit oder Verfügbarkeit sollten dabei Beachtung finden.
Microservices: Microservice-Architekturen schützen den Microservice-Aufrufer vor den Details der Implementierung. Das erlaubt die Nutzung der jeweils am besten geeigneten Technologie-Stacks. Gleichzeitig ist ein vermehrter Fokus auf APIs und deren Management sowie auf geeignete Governance-Maßnahmen erforderlich.
Spezialisierung und Kompetenzaufbau: Entwickler sollten ein breites Allgemeinwissen über für sie relevante technologische Portfolios besitzen, sich gleichzeitig aber auf eine Menge handhabbarer Technologien fokussieren, um nicht als "Jack of all trades, but Master of none" zu enden. Architektur- und Programmierkenntnisse dienen dabei als Basis. Für Organisationen empfiehlt sich gleichzeitig ein Technologieradar, um den Markt zu beobachten und bei Bedarf Experten anzuheuern oder anzulernen.
Prototypen: Beim Einsatz neuer Technologien sollten prototypische Realisierungen, etwa in eigenen Code-Branches, erfolgen, um die tatsächlichen Konsequenzen und Charakteristika der Technologien kennenzulernen. Nicht immer treffen die Versprechungen der Technologielieferanten zu.
Inseln der Stabilität
Das sind freilich nur einige Facetten, die in einer sich dynamisch ändernden Technologielandschaft helfen, Inseln der Stabilität zu etablieren und Projektbeteiligte vor dem technologischen Overkill zu retten.
