Technologieauswahl als strategische Entscheidung
Der Tech-Stack als Schlüsselfaktor für erfolgreiche Softwareprojekte. Grundlegende Kriterien für die Auswahl der richtigen Technologie.
Es dauert nur 2 Minuten
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.
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.
Programmiersprachen
Datenbanken und Datenhaltung
Datensicherung
Server
UI-Frameworks
Entwicklungstools
API-Anbindungen
Monitoring und Analyse Tools
Ein Tech-Stack beschreibt alle Technologien, die für die Entwicklung und Betrieb einer Software erforderlich sind. Das umfasst sowohl Hard- als Software. Die 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.
Die Daten werden zwar im Frontend – also im Browser - angezeigt, müssen am Ende aber im Backend gespeichert werden. Die Quelle der Wahrheit liegt 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 wir zum Beispiel Microsoft und das jüngste Beispiel Xamarin. Diese Technologie wurde kurzerhand eingestampft. 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 durchgedrungen, 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 und löst Problem A, B und C. Aber nichts ist umsonst. Manchmal siegen die einfachen Lösungen.
Muss es wirklich React sein, wo HTML und Tailwind ausreichen würden, weil die Anwendung eigentlich kein reaktives Frontend erfordert (Ja, sowas gibt es 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 der KI zur Verfügung standen. Je mehr Code-Beispiele und Dokumentation in den Trainingsdatensätzen enthalten sind, desto besser kann die KI beim Entwickeln unterstützen.
Moderne, aber relativ neue Technologien sind der KI fremd und bieten daher kaum einen Benefit. Dennoch kann es sinnvoll sein, auf eine 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.
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.
In früheren Zeiten wurden Anwendungen oftmals im Rahmen einer monolithischen Architektur entwickelt, wobei alle Bereiche einer Anwendung auf der gleichen Technik basierten. Dies gilt in besonderem Maße für die Entwicklung von Web-Applikationen.
Wer heute ein modernes Javascript Framework einsetzt, nimmt in Kauf über 10.000 externe Libraries einzubinden. Der Wunsch nach modernster Technik beisst sich mit der Anforderung nach Kontrolle und Sicherheit.
Es ist unmöglich, zu kontrollieren was in den Libraries wirklich enthalten ist. Dieser Umstand wird häufig ausgenutzt, um bösartigen Code in die Libraries einzuschmuggeln, was in der Vergangenheit mehr als einmal gelungen ist.
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 Teilen 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
