Der Tech-Stack als Schlüsselfaktor für erfolgreiche Softwareprojekte. Grundlegende Kriterien für die Auswahl der richtigen Technologie.
Dieses Essay soll dem geneigten Leser einen Leitfaden für die Auswahl der Technologien eines Softwareprojekts geben. Es richtet sich nicht an Programmierer oder CTO, sondern an Gründer und CEO, die ein Unternehmen gründen, Unternehmenssoftware erweitern oder ersetzen möchten. Beleuchtet werden nicht einzelne Technologien, sondern grundlegende Kriterien für die Auswahl, historische Hintergründe und einige Klassifikationen.
Als Tech-Stack bezeichnet man sämtliche Komponenten, die für die Entwicklung und den Betrieb einer Software benötigt werden. Das umfasst sowohl Hard- als auch Software. In einem Unternehmen mit digitaler Ausrichtung hat der Tech-Stack maßgeblichen Anteil am Unternehmenserfolg. Seine Zusammensetzung hat Einfluss auf die Handlungsfähigkeit des Unternehmens und die Ausgaben für IT und Entwicklung.
Er muss den Anforderungen von Kunden und Mitarbeiten gerecht werden und zum Produkt passen und vor allem der aktuellen Situation des Unternehmens gerecht werden. Idealerweise ist er so konzipiert, dass sich Komponenten ersetzen und ergänzen lassen. Es gilt bei der Auswahl auch rechtliche, bzw. Lizenzrechtliche Aspekte zu berücksichtigen. Weiterhin ist darauf zu achten das die Technologien langlebig und einfach wartbar sind. Ein Tech-Stack sollte immer geplant werden. Einfach zu verwenden, was man immer verwendet, kann ein Fehler sein.
Ein etablierter Tech-Stack wird im IT-Team oftmals mit der gleichen Hingabe gefeiert und verteidigt wie eine Fußballmannschaft. Dies wird zusätzlich befeuert durch eine enthusiastische Community, die sich im Ökosystem des Stacks oder seiner Komponenten gebildet hat. Konferenzen und lokale Usergroups verstärken das „Wir" Gefühl weiter.
In Stellenausschreibungen wird mit der Attraktivität des Stack geworben und gleichzeitig ein Einblick in Kultur des Unternehmens gewährt. Am Tech-Stack kann die Innovationsfreude und damit auch die Dynamik und Experimentierfreude eines Unternehmens abgelesen werden. Ein konservativer Tech-Stack deutet auf Stabilität und bewusstes Risikomanagement hin.
Ein Tech-Stack beschreibt alle Technologien, die für die Entwicklung und Betrieb einer Software erforderlich sind. Das umfasst sowohl Hard- als Software. Die wichtigsten Softwarekomponenten sind:
Die grundlegende Zusammensetzung eines Tech-Stacks hat sich den letzten Jahrzehnten dahingehend gewandelt, dass heute wesentlich mehr Technologien zur Verfügung stehen und die Auswahlkriterien sich stark verändert haben. Es stehen heute auf allen Ebenen ausgereifte Alternativen zu Verfügung.
Ein ewiges Paradigma der Softwareentwicklung ist die Trennung von Darstellung und Verwaltung von Daten. Entlang dieser Trennline spricht man vom Backend (für die Verwaltung) und Frontend (für die Darstellung). Ein Entwickler der beide Seiten beherrscht wird heute als „Full-Stack Entwickler" bezeichnet.
In früheren Zeiten wurden Anwendungen oftmals im Rahmen einer monolithischen Architektur entwickelt, wobei alle Bereiche einer Anwendung auf der gleichen Technik basierten und die Trennung von Frontend und Backend mit Hilfe eigener Komponenten realisiert wurden, z.B. durch Template Engines oder interner UI Libraries. Dies gilt in besonderem Maße für die Entwicklung von Web-Applikationen.
Mitte der 10er Jahre wurde dann, angetrieben in erster Linie von React, das Frontend neu definiert. Sowohl was die Technik als auch den Umfang angeht. Das führte zu einer neuen Art von Webanwendungen, die sich in erster Linie für den unbedarften Endnutzer geschmeidiger anfühlten und dem Entwickler neue Möglichkeiten der Strukturierung an die Hand geben. Die Innovationslust in diesem Bereich konzentriert sich naturgemäß auf eine Programmiersprache Javascript bzw. Typescript und ist einmalig in der Historie der Softwareentwicklung. Siehe: https://dayssincelastjavascriptframework.com
Durch die Verschiebung zum Frontend wurde die Entwicklung anspruchsvoller, mächtiger, aber auch komplizierter. Das gilt insbesondere für den Datenstand einer Anwendung, denn die Daten werden zwar im Frontend – also im Browser - angezeigt, müssen am Ende aber fast immer zwingend im Backend gespeichert werden. Die Quelle der Wahrheit liegt in der Regel in der Datenbank und damit im Backend.
Es entsteht also zusätzliche Logik, und damit auch Aufwand und Fehlerquellen, weil die Daten im Frontend mit den Daten im Backend und innerhalb des Frontend selbst synchron gehalten werden müssen.
Die so gewonnene neue Qualität im Frontend kommt also immer auch mit einem Preisschild und der Nutzen sollte vorab zumindest diskutiert werden, bevor Zeit und Geld aufgewendet werden, ohne dass das Projekt einen signifikanten Nutzen aus dem Einsatz einer komplexen Frontend Technologie zieht.
In der heutigen Zeit spielt es keine Rolle mehr, was das Subjekt Ihres Interesses ist, Sie können sicher sein das sich dahinter eine ganze Industrie verbirgt, die um Ihre Aufmerksamkeit und Kaufkraft buhlt. Das gilt ganz besonders auch für Technologien, egal ob Open Source oder proprietär, es gilt immer auch Geld zu verdienen und das ist am Ende des Tages auch gut so.
Für die Auswahl einer Technologie sollte dieser Aspekt aber nicht vergessen werden. Im Hintergrund steht immer die Frage wer bietet was aus welchen Gründen an. Wie langlebig ist dieses Geschäftsmodel und wie hat sich der Player in der Vergangenheit verhalten? Nehmen zum Beispiel Microsoft, wie viele Technologien wurden eingestampft, jüngstes Beispiel Xamarin. Es kann sich auszahlen die Reputation des Anbieter kritisch zu prüfen, kann man sich unter Umständen doch eine komplette Neuentwicklung ersparen. Fragen Sie jetzt nicht, woher wir das Wissen…
Gehen sie immer davon aus, dass Ihre Software langlebig ist.
Glücklicherweise ist in weiten Teilen der Entwicklergemeinde die Erkenntnis eingedrungen, dass grade was Technologie-Einsatz angeht, weniger oft mehr ist. Jede Library die eingesetzt wird erhöht die Komplexität, Abhängigkeit und Anfälligkeit für Störungen jeder Art.
Als Programmierer sind wir nicht davor gefeit das neue XY einsetzen zu wollen, es ist ultracool ist und Problem A, B und C löst, aber nichts ist umsonst und daher ist es sinnvoll zu prüfen, ob man die eine oder andere Fähigkeit nicht besser selbst entwickeln und damit auch kontrollieren möchte. Muss es wirklich React sein, wo HTMX ausreichen würde, weil die Anwendung eigentlich kein reaktives Frontend erfordert (Ja, sowas gibt und tatsächlich viel öfter, als man gemeinhin annimmt). Schreibe ich lieber ein paar hundert Zeilen JavaScript oder importiere 10.000+ Node Module, einfach weil ich daran gewöhnt bin so zu arbeiten, oder schlimmer noch, gar nicht weiss dass es auch anders geht?
Technische Schulden erscheinen in vielen Gewändern, bei der Auswahl eines Tech Stacks erzeugt man diese, wenn man Technologien einsetzt, die die Komplexität künstlich erhöhen, um dann Technologien einzusetzen, welche die künstlich erhöhte Komplexität dämpfen sollen, z.B. RXJS oder Kubernetes auf AWS, welche Probleme lösen, die vielleicht gar nicht erst entstehen müssten, würde/könnte man auf die eine gerade gehypte Technologie (Babel, Transpiling, GraphQL, Kafka etc…) verzichten.
Diesem Problem zugrunde liegt oft eine Architektur, von der angenommen wird, dass sie gut skaliert, so dass man in der Zukunft nicht vor dem Problem steht, Performance Probleme nicht lösen zu können. Vergessen wird dabei allzu oft, dass wenn diese Probleme auftauchen, vorab eine ganze Menge richtig gelaufen sein muss, ansonsten wäre die vertikal maximal skalierte Architektur nicht am Limit, will sagen: Der Rubel rollt und die Probleme können gelöst werden, und zwar die echten Flaschenhälse, nicht jenen von den man vor Jahren angenommen hat, dass Sie einmal aufpoppen könnten.
Die KI spielt in jedem Fall eine Rolle bei der modernen Softwareentwicklung, das sollte mittlerweile überall angekommen sein. Im Allgemeinen wird der Nutzen vom Laien zwar maßlos überschätzt, aber er ist doch signifikant. Eine KI mit der Planung eines Tech Stacks zu beauftragen ist aber Stand heute (Februar 2025) keine gute Idee. Das bleibt auf absehbare Zeit erst einmal Chefsache.
Der wirklich wichtige Aspekt ist, wie viel Trainingsdaten für eine Technologie standen der KI zur Verfügung. Moderne, aber relativ neue Technologien sind der KI fremd und bieten daher auch kaum einen Benefit, wohin gegen bei gereiften weit verbreiteten Technologien nicht nur ausreichend Trainingsdaten in die LLM geflossen sind, sondern vermutlich auch eine große Entwicklergemeinde zur Verfügung steht. Dennoch kann es sinnvoll sein auf ein modernere Technologie zu setzen, sofern Pro's und Con's sorgfältig abgewogen werden.
Auch der Hosting Aspekt und die damit verbunden Kosten an Mann und Material sind in die Überlegungen einzubeziehen. Auch hier gilt wieder weniger ist mehr, braucht man ein Operationsteam das die AWS Services orchestriert? Schon, es gibt eine Menge an Szenarien in denen dass erforderlich ist, aber unter der Prämisse, dass dieser Artikel von der Auswahl eines Tech Stack handelt, ist anzunehmen, dass die aktuelle Last bei null liegt und eine gesunde Zurückhaltung ist angezeigt. Es macht Sinn den Tech Stack mit dem Unternehmen wachsen zu lassen.
Das Verwenden vorgefertigter Libraries und Frameworks ist unvermeidlich, es macht keinen Sinn mit allem bei Adam und Eva anzufangen, aber man sollte sich auf das notwendigste Beschränken, denn quasi alles kommt mit der ein oder anderen Form eines Package Managers, der die Aufgabe hat, die Abhängigkeiten einer Software zu verwalten, so das immer die benötigte Library in der benötigten Version zur Verfügung steht. Im Klartext heißt das aber auch, dass es in manchen Fällen unmöglich ist, zu kontrollieren was in den Libraries enthalten ist.
Diese Umstand wird gerne von sogenannten Thread-Aktoren ausgenutzt, die versuchen bösartigen Code in die Libraries einzuschmuggeln, was in der Vergangenheit mehr als einmal gelungen ist. Wer ein modernes Javascript Framework einsetzt, nimmt in Kauf über 10.000 externe Libraries einzubinden.
In der PHP Welt landet man gerne auch mal in der Composer Hölle und verbringt Stunden damit alle Abhängigkeiten in Einklang zu bringen. Nicht jede externe Komponente wird mit der gleichen Leidenschaft dem aktuellen Stand der Technik angepasst. Drum prüfe wer sich ewig bindet…am besten vorab…
Sie haben es schon bemerkt, unsere Erfahrung kumuliert in der Ansicht das jegliches seine Zeit hat. Das aktuelle Geschäft definiert in weiten die Komplexität des Tech Stacks, die Aufgabe des Geschäftsführers/CTO ist sicherzustellen, dass die technikliebe der Entwickler nicht zum Boomerang wird. Kubernetes, Terraform, Vercel, AWS, Microservices, CQRS etc.pp. alles hat seine Berechtigung und ist oft unvermeidlich, aber jede Entscheidung sollte gründlich erwogen werden.
Ihr persönlicher Ansprechpartner