Technologieauswahl-Assistent

Das echte Ausmaß des Problems

Technologieentscheidungen zählen zu den teuersten Fehlern in der Softwareentwicklung — nicht weil die initiale Entscheidung falsch war, sondern weil sie so schwer rückgängig zu machen ist. Wer sich für ein Framework, eine Datenbank oder eine Infrastruktur-Plattform entschieden hat, lebt mit dieser Entscheidung für drei bis sieben Jahre. Ein Rewrite kostet typischerweise 30–60 % der ursprünglichen Entwicklungskosten (konservative Schätzung aus Architekturprojekten — je nach Systemkomplexität kann der Aufwand darüber liegen).

Gleichzeitig werden Tech-Stack-Entscheidungen häufig unter schlechten Bedingungen getroffen: Zeitdruck, unvollständige Information, starker Einfluss von persönlichen Vorlieben. “Wir nutzen X, weil unser Tech Lead X kennt” ist eine häufigere Begründung als irgendeine objektive Analyse. Das führt zu Tech-Stacks, die nicht zu den tatsächlichen Anforderungen passen.

Das ThoughtWorks Technology Radar dokumentiert die Schnelllebigkeit des Felds: Alle zwei bis drei Jahre verschieben sich Best Practices erheblich. Die Informationsmenge, die für eine fundierte Entscheidung nötig wäre — Community-Größe, Maintenance-Status, Performance-Benchmarks, Erfahrungsberichte aus ähnlichen Use Cases — übersteigt, was ein Team in vertretbarer Zeit selbst recherchieren kann.

Hier helfen LLMs: Sie können strukturiert durch Anforderungsdimensionen führen, Trade-offs analysieren und Erfahrungen aus Millionen von Quellen synthetisieren. Nicht als Orakel — aber als systematischer Diskussionspartner, der keine Lieblingstechnologien hat.

Mit vs. ohne KI — ein ehrlicher Vergleich

ThoughtWorks Technology Radar 2024; eigene Beobachtungen aus Architekturprojekten.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5) Technologieauswahl ist keine tägliche Aufgabe. Teams treffen vielleicht 2–5 größere Technologieentscheidungen pro Jahr — die LLM-Unterstützung spart bei jeder Entscheidung 2–4 Stunden, aber täglich ist der Effekt minimal.

Kosteneinsparung — mittel (3/5) Präventiv erheblich: Ein verhinderter Rewrite kann Hunderttausende Euro kosten. Aber diese Einsparung ist im Voraus nicht quantifizierbar. Als Investment in bessere Entscheidungsqualität ist es sehr günstig (ChatGPT/Claude-Abonnement reicht). Als ROI-Nachweis schwierig.

Schnelle Umsetzung — sehr hoch (5/5) Sofort nutzbar. Kein Setup, kein Tool-Budget, kein Onboarding. Wer ChatGPT oder Claude hat, kann morgen eine strukturierte Technologieanalyse durchführen. Das ist der einfachste Einstieg im gesamten Branch.

ROI-Sicherheit — sehr niedrig (1/5) Das ist der ehrlichste Punkt: Man kann nie beweisen, dass die bessere Entscheidung einen Rewrite verhindert hat — der Rewrite ist ja nicht eingetreten. Der ROI ist theoretisch sehr hoch, praktisch unbeweisbar. Deshalb sollte dieser Use Case als Prozessverbesserung, nicht als ROI-Projekt positioniert werden.

Skalierbarkeit — niedrig (2/5) Technologieentscheidungen sind Einzelprojekte — jede ist einzigartig. Es gibt keinen skalierbaren Automatisierungseffekt wie bei Ticket-Klassifikation. Der Prozess kann standardisiert werden (Anforderungscheckliste, ADR-Template), aber die eigentliche Analyse erfordert jedes Mal menschliche Aufmerksamkeit.

Richtwerte — Hauptwert liegt in Entscheidungsqualität, nicht in Effizienzgewinn.

Was das System konkret macht

Schritt 1 — Anforderungsaufnahme strukturieren: Der erste Schritt ist nicht das Tool — es ist die präzise Beschreibung der Anforderungen. LLMs führen durch gezieltes Nachfragen: Welche Datenmenge? Welches Lese-Schreib-Verhältnis? Wie viele gleichzeitige Nutzer? Welche Konsistenz-Anforderungen? Welche Regulierungsanforderungen? Welches Team-Know-how? Dieses strukturierte Anforderungsprofil ist die Grundlage für eine sinnvolle Empfehlung.

Schritt 2 — Trade-off-Analyse: Auf Basis des Anforderungsprofils liefert ein LLM eine fundierte Vergleichsanalyse mit expliziten Trade-offs. “Gegeben diese Anforderungen: PostgreSQL wenn Konsistenz und komplexe Queries wichtiger sind als Horizontal-Skalierung. MongoDB wenn flexibles Schema und Document-Daten dominieren. DynamoDB wenn Skalierbarkeit auf AWS mit minimalem Betriebsaufwand Priorität hat.” Mit Begründung, nicht als Autorität.

Schritt 3 — Aktuelle Marktdaten ergänzen: LLMs haben einen Wissensschnitt. Für aktuelle Daten: Ist das Framework noch aktiv maintained? Wie groß ist die Community? Gibt es kritische Security-Issues? ChatGPT mit Web-Zugriff oder Perplexity können aktuelle GitHub-Stars, offene Issues und Community-Aktivität einbeziehen.

Schritt 4 — Architecture Decision Record (ADR) erstellen: Das LLM schreibt auf Basis der Analyse einen strukturierten ADR: Kontext, Entscheidung, Begründung, abgelehnte Alternativen, Konsequenzen. Das schafft Nachvollziehbarkeit — warum wurde damals so entschieden, auch wenn in zwei Jahren jemand anderes die Frage stellt.

Was LLMs nicht können: Euer spezifisches Team-Know-how, vorhandene Schulden und organisatorische Einschränkungen kennen sie nicht. Diese müssen als Input gegeben werden. LLM-Analyse ist immer nur so gut wie die Anforderungen, die ihr eingebt.

Konkrete Werkzeuge

Claude — Besonders stark für mehrstufige, kontextreiche Analysen. Claude kann ein vollständiges Anforderungsdokument einlesen und eine strukturierte Trade-off-Analyse ausgeben — inklusive konkreter Empfehlung mit Begründung. Der lange Kontextfenster (bis zu 200.000 Tokens) ermöglicht, umfangreiche technische Dokumente und ADRs direkt einzuspeisen. Preis: ab 18 €/Monat.

ChatGPT mit Web-Zugriff — ChatGPT mit aktiviertem Browsing kann aktuelle Informationen zu Frameworks einbeziehen: aktuelle GitHub-Metriken, neueste Releases, Community-Aktivität. Gut für die Kombination aus fundierter Analyse (LLM-Wissen) und aktuellen Daten. Preis: ab 20 €/Monat.

Perplexity — Stärker auf aktuelle Recherche ausgerichtet als ChatGPT. Kombiniert Web-Suche mit LLM-Synthese und zitiert Quellen explizit. Nützlich für Fragen wie “Welche aktuellen Erfahrungsberichte gibt es zu Technology X für Anwendungsfall Y?” Preis: ab 20 $/Monat für Pro.

ThoughtWorks Technology Radar — Keine KI, aber die beste kostenlose Quelle für fundierte Technologie-Einschätzungen. Vierteljährlich aktualisiert, kategorisiert Technologien in Adopt/Trial/Assess/Hold mit Begründung. Als Orientierungsraster vor der LLM-Analyse nützlich.

StackShare — Community-Plattform, auf der Unternehmen ihren Tech-Stack öffentlich dokumentieren. Zeigt, welche Technologien von ähnlichen Unternehmen kombiniert werden. Gute Ergänzung zu LLM-Analysen für praxisnahe Perspektiven.

Datenschutz und Datenhaltung

Technologieanalyse mit LLMs hat kaum DSGVO-Relevanz — es werden in der Regel keine personenbezogenen Daten verarbeitet, sondern technische Anforderungen und Architektur-Beschreibungen.

Sensibel kann es werden, wenn Anforderungsdokumente Informationen über interne Systeme, Kundendaten-Kategorien oder regulatorische Anforderungen enthalten, die vertraulich sind. Faustregel: Nichts in ein LLM eingeben, was du nicht in einer öffentlichen Slack-Gruppe teilen würdest.

Praktische Empfehlung: Anforderungen abstrahiert beschreiben (“wir verarbeiten ca. 10 Mio. Datenbankrecords täglich”) statt konkret (“unsere Kundendatenbank mit 2,3 Mio. deutschen Kundenaccounts”). Das reicht für eine gute Analyse und schützt vertrauliche Details.

Was es kostet

Einstieg (ChatGPT oder Claude für adhoc-Analysen):

• Kosten: 18–20 €/Monat, oft bereits im Team vorhanden
• Aufwand pro Entscheidung: 2–4 Stunden für Anforderungsaufnahme und Analyse
• Kein zusätzliches Tool-Budget nötig

Strukturierter Prozess (ADR-Template + LLM-Analyse):

• Einmaliger Invest: 4–8 Stunden für ADR-Template-Entwicklung und Prozess-Dokumentation
• Danach: wiederholbarer Prozess für jede Entscheidung

ROI-Szenario (hypothetisch): Tech-Stack-Fehlentscheidung beim Aufbau einer neuen Plattform, nach 18 Monaten erkannt. Kosten des Rewrites: 3 Entwickler × 6 Monate × 8.000 €/Monat = 144.000 € plus Opportunity-Kosten. Verhinderungskosten: 4 Stunden strukturierte Technologieanalyse mit LLM = ca. 300 € Arbeitszeit. Das Verhältnis spricht für sich — aber es ist hypothetisch, weil der Rewrite vielleicht auch ohne bessere Analyse nicht eingetreten wäre.

Typische Einstiegsfehler

1. LLM-Empfehlung blind übernehmen. Das LLM ist ein Diskussionspartner, kein Entscheidungsträger. Wenn die Analyse sagt “PostgreSQL”, bedeutet das nicht, dass PostgreSQL für euren spezifischen Kontext die richtige Wahl ist — es bedeutet, dass PostgreSQL für die eingegebenen Anforderungen gut passt. Den Kontext korrekt einzugeben ist entscheidend.

2. Nur die favorisierte Technologie analysieren lassen. “Warum ist MongoDB eine gute Wahl für unseren Use Case?” ist eine andere Frage als “Was sind die Trade-offs zwischen MongoDB, PostgreSQL und DynamoDB für unseren Use Case?” Erstere führt zur Bestätigungs-Analyse, letztere zur echten Trade-off-Analyse.

3. ADR nach der Entscheidung nicht schreiben. Der ADR-Schritt wird gerne “für später” aufgeschoben und dann vergessen. Direkt nach der Entscheidung — nicht nach der Implementierung — schreiben. In zwei Jahren ist der Kontext nicht mehr präsent.

4. ADRs schreiben, aber nie wieder lesen. Das häufigste Scheitermuster nach einer erfolgreichen Einführung: Architecture Decision Records existieren, werden aber nicht im Entwicklungsprozess genutzt. Niemand schlägt nach, warum damals X statt Y gewählt wurde — und ein Jahr später diskutiert das Team dieselbe Entscheidung erneut. ADRs brauchen einen Heimatort, der bei Technologiediskussionen reflexartig geöffnet wird. Und alle 6–12 Monate einen kurzen Review: Sind die Annahmen noch gültig? Hat sich der Kontext verändert?

Was mit der Einführung wirklich passiert

Bessere Meetings: Teams, die eine strukturierte LLM-Analyse als Grundlage für Technologiediskussionen nutzen, berichten von deutlich produktiveren Meetings. Anstatt 45 Minuten Bauchgefühl gibt es eine gemeinsame Faktengrundlage — und die Diskussion kann sich auf die tatsächlich strittigen Punkte konzentrieren.

ADR-Kultur: Das wertvollste langfristige Ergebnis ist nicht die beste Einzelentscheidung, sondern die Kultur dokumentierter Entscheidungen. Teams, die ADRs konsequent schreiben, haben nach zwei Jahren eine wertvolle Wissensbasis: Warum haben wir damals X gewählt? Was haben wir abgelehnt? Das reduziert die “warum machen wir das eigentlich so?”-Fragen dramatisch.

Entscheidungsgeschwindigkeit: Strukturierte Analyse mit LLM dauert nicht länger als eine Meeting-Stunde Bauchgefühl — oft sogar kürzer. Der Unterschied ist die Qualität, nicht die Zeit.

Realistischer Zeitplan

Häufige Einwände

„KI kann nicht wissen, welche Technologie zu uns passt — sie kennt unsere Situation nicht.” Das stimmt für eine nicht kontextualisierte Anfrage. Mit vollständigem Anforderungsprofil, Team-Beschreibung und bisheriger Architektur liefert das LLM eine Analyse, die besser ist als das meiste, was in Diskussionen ohne diese Grundlage entsteht. KI ist kein Orakel — aber ein unermüdlicher, gut informierter Diskussionspartner.

„Unsere Entwickler wissen selbst, was die beste Technologie ist.” Das stimmt für den Bereich, den sie kennen. Das Problem sind blinde Flecken: Der Backend-Entwickler, der die Datenbankwahl trifft, kennt möglicherweise das Skalierungsmuster nicht, das in fünf Jahren relevant wird. LLM-Analysen bringen externe Perspektiven — nicht als Autorität, sondern als strukturierter Gegencheck.

„Technologieentscheidungen treffen wir selten — ein eigener Prozess lohnt sich nicht.” Wenn große Entscheidungen selten sind, ist das ein Argument für, nicht gegen einen Prozess: Wer selten entscheidet, hat wenig eigene Erfahrung aufgebaut, wie man das gut macht. Ein wiederholbarer Prozess kompensiert genau diesen Erfahrungsmangel. Und kleine Entscheidungen (neue Bibliothek, neues Tool) sind in jedem Team häufig genug.

Woran du merkst, dass das zu dir passt

• Euer Team trifft Tech-Stack-Entscheidungen ohne dokumentierten Entscheidungsprozess oder Anforderungsanalyse
• Ihr habt in den letzten 2 Jahren eine Technologieentscheidung bereut, die mit mehr Analyse anders ausgefallen wäre
• Architecture Decision Records existieren bei euch nicht

Das passt noch nicht, wenn:

• Euer Team hat einen sehr stabilen Tech-Stack und trifft selten neue Technologieentscheidungen (einmal alle 2–3 Jahre) — dann ist ein eigener Analyse-Prozess Overhead.
• Eure Entscheidungen sind vollständig durch bestehende Unternehmens-Vorgaben determiniert — dann ist der Analyse-Spielraum so klein, dass der Prozess keinen Wert bringt.
• Niemand im Team ist bereit, Entscheidungen in ADRs zu dokumentieren und diese auch bei späteren Diskussionen nachzuschlagen. Ohne diese Disziplin ist der Prozess eine einmalige Übung ohne kumulativen Nutzen.

Das kannst du heute noch tun

Nimm eine anstehende Technologieentscheidung (oder eine, die gerade diskutiert wird) und beantworte diese 5 Fragen in einem Dokument: Welche Datenmenge? Welche Skalierungsanforderungen? Welche Konsistenz-Anforderungen? Welche regulatorischen Einschränkungen? Welches Team-Know-how ist vorhanden? Dann gib das Dokument dem folgenden Prompt.

Quellen & Methodik

• ThoughtWorks Technology Radar April 2024 — Technologie-Kategorisierungen und Bewertungen für aktuell relevante Frameworks, Datenbanken und Tools.
• Stack Overflow Developer Survey 2024 — Most-loved und most-used Technologien nach Entwicklerpopulation; Adoption-Trends und Zufriedenheits-Daten.
• Eigene Beobachtungen aus Architekturberatungen; Rewrite-Kosten-Schätzungen auf Basis interner Entwicklungskapazitäten typischer mittelständischer Software-Unternehmen.