Bei der Schnittstellenentwicklung kommt es darauf an, wie viele Systeme beteiligt sind, wie oft sich Anforderungen ändern und wer die Lösung später betreibt. Für zwei bis drei stabile Systeme kann Individualcode wirtschaftlich bleiben, für wachsende Landschaften mit mehreren Partnern zahlt sich eine Integrationsplattform meist schneller aus.
Im Mittelstand ist die Ausgangslage selten ein weißes Blatt. ERP, Onlineshop, EDI-Partner und Fachanwendungen sind über Jahre gewachsen, oft mit einzelnen Skripten, die ein bestimmter Kollege oder eine externe Agentur einmal geschrieben hat. Genau hier stellt sich bei jeder historisch gewachsenen Systemlandschaft die Frage: Bauen Sie die neue Schnittstelle wieder als Einzelstück, oder setzen Sie sie auf eine gemeinsame Plattform?
Stand der Quellenprüfung: 16. September 2026
Vier Punkte sollten Sie vor jeder Entscheidung schwarz auf weiß haben:
Die Basis für eine neue Schnittstelle richtet sich nach der Anzahl der zu verbindenden Systeme und nach deren erwarteter Änderungsrate. Bei zwei Systemen mit stabilen Anforderungen ist ein direkt programmierter Konnektor oft die schlankere Lösung. Sobald mehrere Systeme, Partner oder Formate zusammenkommen, spricht das immer mehr für eine zentrale Plattform, weil jedes neue System dann nur noch eine einzige Verbindung braucht: die zur Plattform.
Hub-and-Spoke heißt das Prinzip dahinter: Die Plattform übernimmt die Rolle der Nabe, alle Systeme hängen als Speichen daran. Wie eine solche Integrationsplattform im Alltag funktioniert zeigt sich vor allem daran, dass Mapping-Regeln zentral gepflegt und nur einmal pro System angelegt werden. Wir haben da keine grundsätzliche Vorliebe für einen der beiden Wege: Entscheidend ist, was sich für Ihre konkrete Landschaft über Jahre im Betrieb trägt.
Middleware setzt sich bei fast allen sieben Kriterien durch, sobald mehr als drei Systeme im Spiel sind, während Individualbau bei sehr spezifischer Logik und wenigen, stabilen Verbindungen mithalten kann.
| Kriterium | Middleware / Plattform | Individualbau |
|---|---|---|
| Time-to-Value | Oft 1–4 Wochen bis Go-live bei vorhandenen Konnektoren | Meist 4–16 Wochen, abhängig von Sonderlogik |
| Änderbarkeit | Anpassung per Konfiguration, geringere Folgekosten | Jede Anpassung erfordert neuen Entwicklungsaufwand |
| Mapping-Aufwand | Zentrale Regeln, einmalige Anbindung pro System | Steigt mit jeder neuen Punkt-zu-Punkt-Verbindung |
| Governance | Nachvollziehbare Prozesse, leichter dokumentierbar | Oft nur im Kopf des Entwicklers, schwer prüfbar |
| Testbarkeit | Wiederholbare Testläufe über Plattform-Tools | Abhängig von Testdisziplin des Einzelprojekts |
| Betrieb & Monitoring | Zentrales Monitoring über alle Schnittstellen | Meist Einzellösung pro Schnittstelle nötig |
| Personenabhängigkeit | Mehrere Personen können Plattform pflegen | Wissen oft an einer Person gebunden |
Die konkreten Zahlen zu Time-to-Value stammen aus Angeboten für ERP- und Shop-Anbindungen und variieren je nach Anbieter, geben aber eine belastbare Größenordnung für die Planung. Bei den anderen Kriterien entscheidet die konkrete Ausgangslage, ob Individualbau eine echte Alternative bleibt oder die Plattform zwingend wird.
Wenige, klar abgegrenzte Systeme mit sehr spezifischer Fachlogik sind der Fall, in dem Individualentwicklung technisch und wirtschaftlich vorne liegt, weil eine Standardplattform diese Logik nur über Umwege abbilden könnte. Analysen des CHAOS Reports der Standish Group untermauern das mit Zahlen: Kleine, klar geschnittene Softwareprojekte erreichen je nach Auswertung eine Erfolgsquote von rund 90 Prozent, große Projekte dagegen deutlich unter 10 Prozent. Insgesamt gelten über alle Größen hinweg nur etwa 31 Prozent aller Projekte als vollständig erfolgreich. Die Datenbasis ist überwiegend US-geprägt und über mehrere Berichtsjahre hinweg nicht ganz einheitlich, der Trend lässt sich aber auf Schnittstellenprojekte übertragen: Kleine, klar abgegrenzte Vorhaben laufen zuverlässiger als große, komplexe.
Für eine einzelne, stark spezialisierte Anbindung, etwa zwischen einer Branchensoftware und einem selbst entwickelten Prüfsystem, kann ein sauber durchdachtes Einzelprojekt günstiger sein als eine Plattformlizenz. Voraussetzung ist, dass Tests, Dokumentation und Zuständigkeiten von Anfang an mitgedacht werden, denn genau daran scheitern individuelle Schnittstellen in der Praxis am häufigsten.
Gut zu wissen: Kleine Projekte mit klar begrenztem Umfang scheitern laut CHAOS-Report-Analysen deutlich seltener als große. Wer Individualbau wählt, sollte den Zuschnitt bewusst klein halten und nicht schrittweise zu einer Integrationsplattform in Eigenbau ausbauen.
Ab drei bis vier verbundenen Systemen, Partnern oder Formaten wird eine Integrationsplattform zur klar besseren Option, weil die Zahl der Einzelverbindungen bei reiner Punkt-zu-Punkt-Anbindung förmlich explodiert. Bei 50 zu verbindenden Systemen entstehen so rund 1.225 Einzelverbindungen, jede mit eigener Wartung, eigenem Fehlerbild und eigener Testlogik. Für ERP-Anbindungen, EDI-Partner, Shop-Integrationen und gewachsene Systemlandschaften mit mehreren Beteiligten ist das der Punkt, an dem sich der Umstieg auf eine gemeinsame Plattform rechnet.
Bei der klassischen ERP-Anbindung zeigt sich diese Spanne bereits im Angebot: Eine einfache Plugin-Lösung liegt bei rund 4.000 Euro, ein umfangreiches Middleware-Projekt mit vollständiger Fehlerbehandlung kann bis zu 80.000 Euro kosten, je nach Datenfluss-Richtung und Zahl der abzudeckenden Ausnahmefälle. Für die Shopware-ERP-Anbindung lassen sich vier typische Wege konkret gegenüberstellen, wie sie unter anderem die Agentur Qualimero in ihrem Kostenvergleich für 2026 skizziert:
Für EDI-Partnerschaften mit wechselnden Formaten wie EDIFACT, VDA oder IDoc gilt dasselbe Argument in verschärfter Form, weil jeder neue Partner sonst eine eigene Übersetzungslogik braucht. Bei gewachsenen Landschaften mit mehreren ERP-Modulen, einem Shop und diversen Fachanwendungen kommt hinzu, dass niemand im Unternehmen mehr vollständig überblickt, welche Skripte an welcher Stelle greifen, was jede weitere Änderung zum Risiko macht.
Auf einer Plattform lassen sich neue Releases meist zentral testen und schrittweise ausrollen, bei mehreren Individualschnittstellen bleibt dagegen jede Anpassung Einzelarbeit, weil es keine gemeinsame Testumgebung gibt. Das wirkt sich noch lange nach dem ersten Go-live auf Releases, Störungserkennung und Supportanfragen aus. Für den laufenden Betrieb bedeutet das: Ohne aktives Monitoring der Datenflüsse bleiben Fehler in Individuallösungen oft tagelang unentdeckt, bis ein Partner oder Kunde sich meldet.
Eine Befragung von Pegasystems und Savanta unter mehr als 500 IT-Entscheidern weltweit zeigt, dass 78 Prozent der Befragten Zeit und Budget für die Pflege von Altsystemen als Fehlinvestition betrachten. Die Erhebung stammt überwiegend aus großen Unternehmen und ist kein Mittelstands-Durchschnitt, zeigt aber die Richtung: Wo das Wissen in einzelnen Altsystemen festhängt, hängt eben auch das Personal daran, das diese Systeme noch versteht.
Der deutsche IT-Fachkräftemangel verschärft diese Abhängigkeit zusätzlich. Aktuell fehlen in Deutschland laut Bitkom rund 109.000 IT-Fachkräfte, 85 Prozent der Unternehmen spüren diesen Mangel bereits, und 79 Prozent erwarten eine weitere Verschärfung in den kommenden Jahren. Wenn eine individuell programmierte Schnittstelle nur von einer Person verstanden wird, reicht schon ein längerer Krankheitstag oder ein Wechsel, um den Support ins Stocken zu bringen. Eine Plattform mit dokumentierten Mappings verteilt dieses Wissen auf mehrere Schultern, weil sich neue Kolleginnen und Kollegen schneller einarbeiten können als in fremden Individualcode.
Governance-Pflicht seit Dezember 2025: Das NIS2-Umsetzungsgesetz verlangt von betroffenen Unternehmen, Sicherheitsrisiken bei Lieferanten und IT-Dienstleistern aktiv zu bewerten, vertraglich zu regeln und laufend zu überwachen, wie es das BSI in seinem Infopaket zu NIS-2-Risikomanagementmaßnahmen beschreibt. Schätzungen zufolge sind hierzulande rund 29.500 Unternehmen direkt betroffen, für sie ist eine dokumentierte, wiederholbare Schnittstellen-Governance jetzt gesetzlich vorgeschrieben.
Für die meisten Mittelstandsszenarien lässt sich die Entscheidung an drei einfachen Fragen festmachen: Wie viele Systeme sind beteiligt, wie oft ändern sich Formate oder Partner, und wer trägt die Verantwortung, wenn die Schnittstelle in zwei Jahren noch läuft. Bei einer einzelnen ERP-Shop-Verbindung mit stabilen Stammdaten reicht häufig ein Plugin oder eine direkte API-Anbindung. Bei mehreren EDI-Partnern, einem ERP-Wechsel oder einer historisch gewachsenen Landschaft mit vielen Einzelverbindungen überwiegen die Vorteile einer zentralen Plattform, weil sich Mapping, Monitoring und Governance dort an einer Stelle bündeln lassen.
In der Praxis lassen sich beide Wege oft kombinieren. Viele Mittelständler starten mit einer einzelnen Individualschnittstelle und stoßen erst beim dritten oder vierten System an die Grenze, an der Punkt-zu-Punkt-Verbindungen unübersichtlich werden. Der Wendepunkt ist dabei meist gar nicht technisch: Es geht um die Frage, ob die Schnittstelle noch jemand versteht außer der Person, die sie damals geschrieben hat.
Wer heute eine neue Schnittstelle plant, sollte vor allem fragen, welcher Ansatz in drei Jahren noch wartbar, dokumentiert und personell abgesichert ist. Das schließt Änderbarkeit, Testbarkeit und Betriebssicherheit als gleichwertige Kriterien neben den reinen Anschaffungskosten ein.
Sprechen Sie mit uns über Ihre aktuelle Systemlandschaft: Wie viele Verbindungen bestehen heute schon, und wer könnte sie in einem Jahr noch erklären? Gemeinsam ordnen wir ein, ob ein einzelnes gut dokumentiertes Individualprojekt reicht oder ob sich der Umstieg auf eine gemeinsame Plattform für Sie bereits rechnet.
Lassen sich Middleware und Individualentwicklung kombinieren?
Ja, und das ist in der Praxis oft sogar der sinnvollste Weg. Kernsysteme wie ERP, Shop und EDI-Partner laufen über die Plattform, während eine einzelne, sehr spezifische Nischenanbindung weiterhin individuell programmiert wird. Wichtig ist, dass auch dieser individuelle Teil dokumentiert und ins zentrale Monitoring eingebunden bleibt.
Wovon hängt der Umstieg von gewachsenen Individualschnittstellen auf eine Middleware-Plattform ab?
Entscheidend sind die Zahl bestehender Punkt-zu-Punkt-Verbindungen und deren Dokumentationsstand. Je mehr Verbindungen unklar oder undokumentiert sind, desto mehr Zeit fließt in die Analyse vor der eigentlichen Migration. Ein stufenweiser Umstieg, bei dem Schnittstelle für Schnittstelle abgelöst wird, reduziert das Risiko gegenüber einem Komplett-Umzug an einem Termin.
Was passiert mit individuell programmierten Schnittstellen, wenn der zuständige Entwickler das Unternehmen verlässt?
Ohne saubere Dokumentation wird jede Anpassung riskant, weil niemand mehr die genaue Fehlerbehandlung oder die Ausnahmefälle im Code kennt. In vielen Fällen bleibt nur die aufwendige Reverse-Engineering-Analyse des bestehenden Codes, bevor überhaupt Änderungen möglich sind. Das ist genau das Szenario, das eine zentral dokumentierte Plattform von Anfang an vermeiden soll.
Lohnt sich eine Middleware auch bei nur zwei Systemen, etwa ERP und Onlineshop?
Bei einem reinen ERP-Shop-Paar meist nicht, solange beide Systeme stabil bleiben und keine weiteren Partner absehbar sind. Häufig ist dann ein fertiges Plugin oder eine direkte API-Anbindung die schnellere und günstigere Lösung. Sobald ein dritter Partner, ein EDI-Anschluss oder ein ERP-Wechsel absehbar ist, kehrt sich diese Rechnung meist um.
Verändert die NIS2-Pflicht auch bestehende, schon laufende Individualschnittstellen?
Ja, denn die Nachweispflicht bezieht sich nicht nur auf neue Projekte, sondern auf alle laufenden Lieferanten- und Software-Beziehungen betroffener Unternehmen. Wer eine Schnittstelle vor Jahren individuell bauen ließ, muss die damit verbundenen Risiken jetzt genauso bewerten und laufend überwachen wie bei einem neuen Dienstleister. Fehlende Dokumentation macht diesen Nachweis in der Praxis deutlich aufwendiger.
Quellen:
Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen