Fallbeispiel · Tendenziell förderfähig

Grundlegend neue Softwarearchitektur mit technischem Neuheitsgehalt

Dieses Beispiel beschreibt ein typisches, generisches technisches Muster — keinen realen Kundenfall — zur Veranschaulichung der Förderlogik bei Softwarevorhaben.

Ausgangslage

Ein Softwareunternehmen stößt mit seiner bestehenden Systemarchitektur an Grenzen, sobald eine deutlich höhere Zahl gleichzeitiger Nutzer mit Echtzeitanforderungen bedient werden soll. Bereits verfügbare Architekturmuster lösen das Problem nicht zuverlässig, weshalb das Unternehmen eine grundlegend neue Systemarchitektur entwirft und prototypisch umsetzt, deren Skalierungsverhalten unter Last zu Beginn nicht sicher vorhersagbar ist.

Warum das tendenziell förderfähig ist

Zu Projektbeginn ist offen, ob die neu entworfene Architektur die geforderte Skalierbarkeit tatsächlich erreicht — dieses technische Risiko lässt sich erst durch Implementierung, Lasttests und iterative Anpassung auflösen. Da bereits am Markt verfügbare Architekturmuster für diesen spezifischen Anwendungsfall nachweislich nicht ausreichen, geht das Vorhaben über den Stand der Technik hinaus. Für den Antrag ist wichtig, konkret zu benennen, an welchen bestehenden Architekturansätzen die Anforderungen scheitern und welche neue technische Lösung dafür entwickelt wird — statt die Architektur nur allgemein als „modern“ oder „skalierbar“ zu beschreiben.

Passende Förderprogramme

Ein solches Vorhaben lässt sich in der Regel über ZIM fördern, ergänzt um die Forschungszulage für die laufenden Personalkosten der Architekturentwicklung. Mehr zur grundsätzlichen Abgrenzung auf der Themenseite Software und Digitalisierung.

Zum Vergleich: das Gegenstück

Würde dasselbe Unternehmen stattdessen ausschließlich bestehende Software warten und kleinere Anpassungen an der Benutzeroberfläche vornehmen, läge in der Regel keine förderfähige Entwicklungstätigkeit vor — siehe das Gegenbeispiel Routinemäßige Wartung, Bugfixing und UI-Anpassungen.

Häufige Fragen zu diesem Fallbeispiel

Reicht ein kompletter Rewrite eines bestehenden Systems für die Förderfähigkeit aus?

Nein, ein Rewrite allein — also die Neuimplementierung derselben Funktionalität mit bereits bekannten Mitteln, etwa nur um technische Schulden abzubauen — begründet für sich genommen keine Förderfähigkeit, solange keine neue technische Unsicherheit gelöst wird. Entscheidend ist, ob die neue Architektur eine Anforderung erfüllen soll, die mit bereits verfügbaren Architekturmustern nachweislich nicht zuverlässig lösbar war, und ob der Ausgang dieser Neuentwicklung zu Projektbeginn offen war. Ein reiner Rewrite ohne neue technische Fragestellung bleibt in der Regel investiv, nicht forschungsnah.

Muss die neue Architektur am Ende tatsächlich erfolgreich sein, um förderfähig zu bleiben?

Nein, die Förderfähigkeit knüpft an die zu Projektbeginn bestehende technische Unsicherheit an, nicht an den späteren Erfolg. Auch ein Architekturansatz, der sich im Projektverlauf als nicht tragfähig erweist, kann förderfähig gewesen sein, sofern die Unsicherheit zu Beginn real war und systematisch untersucht wurde. Eine sorgfältige Dokumentation gescheiterter Zwischenschritte und der daraus gezogenen Erkenntnisse ist dabei oft sogar der überzeugendste Beleg für echte technische Unsicherheit.

Wie unterscheidet sich dieses Fallbeispiel von der allgemeinen Einordnung auf der Themenseite Software und Digitalisierung?

Die Themenseite Software und Digitalisierung ordnet die grundsätzliche Förderlogik für Softwarevorhaben ein und benennt allgemeine Muster, einschließlich der Post-go-digital-Förderlandschaft. Dieses Fallbeispiel vertieft konkret den Grenzfall einer grundlegenden Architekturneuentwicklung, der in der Praxis besonders häufig zu Unsicherheit bei der Selbsteinschätzung führt. Beide Seiten ergänzen sich für eine vollständige Einordnung Ihres konkreten Vorhabens.

Ihr Softwarevorhaben mit ClausiusAI einordnen lassen

ClausiusAI prüft, ob Ihre Architekturentwicklung die geforderte technische Unsicherheit erfüllt, und ordnet sie dem passenden Förderprogramm zu.

Schnellere Antragstellung
Der Antrag wird strukturiert vorbereitet, statt bei null anzufangen.
Strukturierter Prozess
Alle Angaben, Dokumente und offenen Punkte in einem gemeinsamen Online-Kooperationstool statt verstreuten E-Mails und Dateien.
Belastbarer Antragsinhalt
Ihr Unternehmenskontext und der wissenschaftlich-technische Hintergrund fließen in den Antrag ein, statt einer generischen Vorlage.
Passende Fördersumme
Förderfähige Kostenarten werden systematisch geprüft, statt Positionen zu übersehen.

Kostenlosen Fördercheck starten

Fallbeispiele aus der Praxis

Tendenziell Routine

Standardintegration eines bestehenden Sprachmodells über eine API

Ein Chatbot auf Basis eines vortrainierten Sprachmodells ohne eigenes Training — ein typisches Beispiel für nicht förderfähige Standardanwendung.

Tendenziell Routine

Routinemäßige Wartung, Bugfixing und UI-Anpassungen

Laufende Pflege einer bestehenden Softwarelösung ohne neuen Entwicklungsanteil — ein typisches Beispiel für nicht förderfähige Routine.

Alle Fallbeispiele im Überblick: Fallbeispiele · Zum Thema: Software und Digitalisierung