© Berezovska Anastasia/Shutterstock.com
Java Magazin
Über die Kernelemente evolutionärer Architekturen

Bewegung im Architektur-Genpool

Microservices sind in aller Munde und meist auch schon in Produktion. Mit einem technischen Trend allein ist es jedoch nicht getan, wenn es darum geht, die zentralen Versprechungen rund um Langlebigkeit, Innovationsfähigkeit, Geschwindigkeit und Zuverlässigkeit einzulösen. Dieser Artikel verbreitert die Basis der Diskussion und führt in das ADES Framework ein.

Stefan Toth


In der Softwareentwicklung haben wir uns im letzten Jahrzehnt endgültig vom klassischen Ingenieurswesen verabschiedet. Es wird nurmehr selten versucht, aus weitreichender Analyse und konzeptioneller Betrachtung stabile Pläne zu entwickeln, die Entwicklung aufzuspalten und im Gleichschritt Richtung Umsetzung zu marschieren. Stattdessen werden immer dynamischere Wege gefunden, abstrakte Betrachtung und reale Umsetzung zu verzahnen. Einem groben Plan folgt ein langer empirischer Weg, der mit Unsicherheiten arbeitet und durch stetige Adaption zu einer gültigen Lösung führt. Warum? Weil ein solches Vorgehen besser mit Überraschungen umgehen kann.

Casey Rosenthal und Kollegen meinen, ein verteiltes System sinnvoller Größe werde schnell zu komplex, um von einem Menschen verstanden zu werden [1]. Auch größere monolithische Systeme könnten nicht von einzelnen Architekten oder Entwicklern im Detail durchdrungen werden. Nüchtern betrachtet merken wir oft schon vor der IDE sitzend, dass wir eigentlich eher rumprobieren und hoffen, dass es funktioniert, als einen Masterplan ohne Umschweife in Code zu gießen. Effektiv ist oft, mit einem Ziel im Hinterkopf zu experimentieren, zu erkennen, was funktioniert und erfolgreich ist, und dann entsprechend zu handeln. In der Gesamtbetrachtung der Entwicklung inklusive Lösungsdesign, Technologieauswahl, Integration, Framework-Einsatz und Legacy-Anbindung ist es noch unwahrscheinlicher, mit trockener Analyse allein erfolgreiche Lösungsstrategien zu finden. Evolutionäre Architekturansätze erkennen das an und lassen sich auf empirisches Vorgehen, Experimente und Bewegung in der Lösungsidee ein. Überraschungen sind das neue Normal.

Evolutionäre Architektur = Microservices?

Evolutionäre Architektur ist als Metapher dem Evolutionary Computing entlehnt und eine Idee zur Architekturausgestaltung, stark verknüpft mit agilen Werten und Prinzipien. Zentrales Paradigma ist, dass sich Architektur für größere Systeme stetig weiterentwickeln muss. Sei es aufgrund von Erkenntnissen aus der Implementierung, aufgrund von Innovationsdruck oder wegen aktueller Probleme in Betrieb oder Nutzung. Wir befinden uns mit Softwarelösungen demnach bestenfalls in einem „dynamischen Gleichgewicht“, in dem eine konstant gute Lösung stetige Anpassung braucht. Weil sich die Disziplin der Softwareentwicklung und generell der IT so schnell weiterentwickelt, ist jeder Stillstand auf Lösungs- und Architekturseite schädlich. Evolutionäre Architektur unterstützt die kl...

Java Magazin
Über die Kernelemente evolutionärer Architekturen

Bewegung im Architektur-Genpool

Microservices sind in aller Munde und meist auch schon in Produktion. Mit einem technischen Trend allein ist es jedoch nicht getan, wenn es darum geht, die zentralen Versprechungen rund um Langlebigkeit, Innovationsfähigkeit, Geschwindigkeit und Zuverlässigkeit einzulösen. Dieser Artikel verbreitert die Basis der Diskussion und führt in das ADES Framework ein.

Stefan Toth


In der Softwareentwicklung haben wir uns im letzten Jahrzehnt endgültig vom klassischen Ingenieurswesen verabschiedet. Es wird nurmehr selten versucht, aus weitreichender Analyse und konzeptioneller Betrachtung stabile Pläne zu entwickeln, die Entwicklung aufzuspalten und im Gleichschritt Richtung Umsetzung zu marschieren. Stattdessen werden immer dynamischere Wege gefunden, abstrakte Betrachtung und reale Umsetzung zu verzahnen. Einem groben Plan folgt ein langer empirischer Weg, der mit Unsicherheiten arbeitet und durch stetige Adaption zu einer gültigen Lösung führt. Warum? Weil ein solches Vorgehen besser mit Überraschungen umgehen kann.

Casey Rosenthal und Kollegen meinen, ein verteiltes System sinnvoller Größe werde schnell zu komplex, um von einem Menschen verstanden zu werden [1]. Auch größere monolithische Systeme könnten nicht von einzelnen Architekten oder Entwicklern im Detail durchdrungen werden. Nüchtern betrachtet merken wir oft schon vor der IDE sitzend, dass wir eigentlich eher rumprobieren und hoffen, dass es funktioniert, als einen Masterplan ohne Umschweife in Code zu gießen. Effektiv ist oft, mit einem Ziel im Hinterkopf zu experimentieren, zu erkennen, was funktioniert und erfolgreich ist, und dann entsprechend zu handeln. In der Gesamtbetrachtung der Entwicklung inklusive Lösungsdesign, Technologieauswahl, Integration, Framework-Einsatz und Legacy-Anbindung ist es noch unwahrscheinlicher, mit trockener Analyse allein erfolgreiche Lösungsstrategien zu finden. Evolutionäre Architekturansätze erkennen das an und lassen sich auf empirisches Vorgehen, Experimente und Bewegung in der Lösungsidee ein. Überraschungen sind das neue Normal.

Evolutionäre Architektur = Microservices?

Evolutionäre Architektur ist als Metapher dem Evolutionary Computing entlehnt und eine Idee zur Architekturausgestaltung, stark verknüpft mit agilen Werten und Prinzipien. Zentrales Paradigma ist, dass sich Architektur für größere Systeme stetig weiterentwickeln muss. Sei es aufgrund von Erkenntnissen aus der Implementierung, aufgrund von Innovationsdruck oder wegen aktueller Probleme in Betrieb oder Nutzung. Wir befinden uns mit Softwarelösungen demnach bestenfalls in einem „dynamischen Gleichgewicht“, in dem eine konstant gute Lösung stetige Anpassung braucht. Weil sich die Disziplin der Softwareentwicklung und generell der IT so schnell weiterentwickelt, ist jeder Stillstand auf Lösungs- und Architekturseite schädlich. Evolutionäre Architektur unterstützt die kl...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang