Natürlich stimmt das nicht so ganz, aber ein wenig provozieren darf man ja mal. Nils hat aber in seinen über zwanzig Jahren Erfahrung in der Webentwicklung schon so einiges mitmachen dürfen, daher nehmen wir Euch heute mit auf eine kleine empirische Zeitreise in Sachen Software-Architektur.

Die 90er: PHP 4

Vor zwanzig Jahre (oder so) war PHP4 gerade groß im Trend. Hier war die Einstiegshürde am geringsten. Es war schnell. Es war einfach auf dem Rechner zu installieren. Alles in allem der perfekte Anfang einer langen Beziehung.
Es war die richtige Entscheidung.

Die 00er: PHP 5

Ein paar Jahre danach kam PHP5 auf den Markt. Endlich richtige Objektorientierung. Endlich kein PHP-Code mehr in HTML-Templates. Der Code wurde erwachsen. PHP4-Code und guter OOP-PHP5-Style hatten nichts mehr miteinander zu tun. Also die aktiven Projekte neu schreiben.
Es war die richtige Entscheidung. 

2005: Symfony

Nachdem jeder sein eigenes kleines Framework auf PHP5-Basis geschrieben hat, kamen die großen Frameworks wie Zend und Symfony auf den Markt. Da dort hunderte von Freiwilligen ihre Freizeit reingesteckt haben, waren sie natürlich ein kleines Stück besser als das, was wir gebaut hatten. Also: Migration auf ein MVC-Framework namens Symfony. Wobei man es nicht Migration nennen konnte. Eigentlich war es ein neu Schreiben.
Aber, es war die richtige Entscheidung.

2011: Symfony2

Wie es immer so ist. Die erste Version einer Software ist nie der heilige Gral und viele Architekturentscheidungen, die man getroffen hat, waren schlichtweg falsch. Das passiert nicht nur uns, sondern auch anderen. Symfony2 hat sehr viel anders gemacht als sein Vorgänger. Eine klare Entscheidung für Doctrine, saubere Strukturen, viele tolle Bundles. Der Unterschied der zwei Major-Versionen war so groß, dass wir sehr viel der Software neu schreiben mussten.
War aber die richtige Entscheidung. 

Microservices

Wir waren eine relativ lange Zeit sehr glücklich über die Software, die wir auf Symfony2 aufgesetzt hatten. Dann kam aber jemand auf die Idee, dass man Software anders schneiden sollte. In Zeiten von Cloud, Docker und Co. sollte Software in Microservices geschnitten werden. Stimmt. Junge Entwickler wollen ja eh nicht mehr mit “Monoliten” arbeiten. Was macht man also? So langsam alles aus der alten Software raus ziehen, bis man eine Microservice-Architektur auf die Beine gestellt bekommt.
Ist aber auf jeden Fall die richtige Entscheidung. 

NodeJS

PHP? Quatsch! Die coolen Jungs machen NodeJS. JavaScript ist die Sprache der Zukunft, weil Browser und das Web die Zukunft sind. Stimmt. Also? Genau, neue Paradigmen, alles eher funktional, wenn man will. Eine ganz neue Welt. Eine ganz neue Software. Also neu schreiben.
Richtige Entscheidung.

NodeJS++

Vor kurzem wurde angekündigt, dass der Erfinder von NodeJS ein neues Projekt hat: Deno. Klingt sehr vielversprechend. Wird sicherlich eine richtige Entscheidung sein, darauf zu wechseln, auch wenn es vielleicht nicht mehr abwärtskompatibel ist.

Auf Software-Architektur ist kein Verlass (mehr)

Was bedeutet das ganze für Architektur?
“Wenn ich ehrlich bin, habe ich kein Stück Software erlebt, in dem es nach 3 Jahren Entwicklung noch Spaß gemacht zu arbeiten.” gibt Chief Technology Koala Nils zu. “Auch wenn die Architektur für die jeweilige Zeit immer echt gut war (ich hatte das Glück mit vielen sehr guten Leuten zusammengearbeitet zu haben).” 
Es liegt also nicht (immer) an der Software, die man selbst geschrieben hat, sondern vielmehr daran, dass die Welt da draußen sich meistens schneller fortbewegt, als man selbst denken und coden kann. Um wieder aufzuholen muss man manchmal das, was man gebaut hat, wegwerfen. Früher oder später.

Ist eine saubere Architektur also unnötig? Wahrscheinlich nicht, da sie uns ein paar Monate oder vielleicht auch Jahre mehr Zeit erkauft. Sie ist aber nicht die Silberkugel, die unsere Projekte unsterblich macht. Alles ist vergänglich, egal wie toll es einmal aussah.

Was passiert dann aber in Sachen QA, wenn Software-Architektur seinen Stellenwert verliert, da sie nicht mehr das unumstößliche Gerüst guter digitaler Produkte bildet? Dann müssen eben andere, zeitgemäße Lösungen zur QA her, zum Beispiel Leankoala, das nicht nur eigenschaftsbasiert testet, sondern auch Web Testing und Monitoring miteinander verbindet.

PS: Wusstet ihr, dass die Berufsbezeichnung Software-Architekt in Deutschland verboten ist?