Fast jedes Projekt beginnt mit einem Satz, der harmlos klingt: "Und dann muss es noch mit unserer Buchhaltung sprechen." Ein Nebensatz im Kickoff, eine Zeile im Protokoll. In der Praxis ist das oft der Teil, der am längsten dauert.
Software auf der grünen Wiese gibt es fast nie. In deiner Firma läuft schon etwas: ein Buchhaltungssystem, eine Lagerverwaltung, ein Kassensystem, ein Zahlungsanbieter, eine Excel-Datei, die seit acht Jahren niemand anfassen darf. Deine neue Software muss sich in diese Landschaft einfügen. Der Punkt, an dem sie das tut, heisst Schnittstelle. Und dieser Punkt ist selten der einfachste im Projekt.
Was eine Schnittstelle eigentlich ist
Eine Schnittstelle ist eine vereinbarte Art, wie zwei Systeme miteinander reden. Das eine fragt, das andere antwortet, beide halten sich an dieselben Regeln. Im Fachjargon heisst das API.
Der Vergleich, der am besten passt: ein Schalter am Bahnhof. Du kannst nicht einfach hinter den Tresen laufen und selber im System nachschauen. Du stellst deine Frage in der Form, die vorgesehen ist, und bekommst eine Antwort in der Form, die vorgesehen ist. Das ist keine Schikane, sondern der Grund, warum das System nicht kippt, wenn tausend Leute gleichzeitig fragen.
Für dich als Auftraggeberin heisst das vor allem eines: Was hinter dem Schalter passiert, kannst du nicht bestimmen. Du bist auf das angewiesen, was der andere Anbieter anbietet. Und genau daraus entsteht der Aufwand.
Eine Schnittstelle ist der einzige Teil deiner Software, dessen Regeln jemand anderes schreibt.
Warum die Verbindung oft teurer ist als das Feature
Der Wunsch klingt klein: "Wenn eine Bestellung reinkommt, soll automatisch eine Rechnung in unserer Buchhaltung entstehen." Ein Satz, zwei Systeme, fertig.
Was dahinter steckt: Deine Bestellung kennt Positionen, Rabatte und eine Lieferadresse. Die Buchhaltung kennt Belegnummern, Konten und Mehrwertsteuersätze. Das sind zwei verschiedene Sprachen über dieselbe Sache. Jemand muss entscheiden, was wohin gehört, was passiert, wenn ein Feld fehlt, und was gilt, wenn beide Seiten unterschiedliche Antworten haben. Diese Übersetzungsarbeit ist der eigentliche Auftrag. Das Absenden der Daten ist der kleinere Teil.
Dazu kommt eine Frage, die gerne untergeht: Wer hat recht? Wenn eine Kundenadresse in beiden Systemen steht und sich unterscheidet, braucht es eine klare Regel, welche gilt. Ohne diese Regel bekommst du keinen Fehler, sondern etwas Schlimmeres. Du bekommst zwei plausible Wahrheiten und merkst es erst, wenn ein Kunde reklamiert.
Drei Sorten Schnittstelle, drei Preisklassen
Wenn wir abschätzen, was eine Anbindung kostet, schauen wir zuerst, mit welcher Sorte wir es zu tun haben.
Die dokumentierte Schnittstelle. Der Anbieter hat eine saubere API, eine verständliche Dokumentation und eine Testumgebung. Das ist der gute Fall. Hier arbeiten wir zügig, weil wir ausprobieren können, ohne dein Produktivsystem anzufassen. Viele moderne Schweizer Anbieter, etwa im Buchhaltungs- und Zahlungsbereich, sind hier gut aufgestellt.
Die halbe Schnittstelle. Es gibt eine API, aber sie kann weniger, als du brauchst. Sie liefert Kunden, aber keine Rechnungen. Sie erlaubt Lesen, aber kein Schreiben. Oder die Dokumentation beschreibt eine Version, die es so nicht mehr gibt. Dann bauen wir um die Lücke herum, und das kostet Zeit, die niemand vorher sieht.
Gar keine Schnittstelle. Das System ist alt, lokal installiert, und der Hersteller sieht keinen Grund, das zu ändern. Dann bleiben Dateien: ein Export in der Nacht, ein Import am Morgen. Das funktioniert und ist manchmal die richtige Antwort. Nur ist es dann keine Echtzeit-Verbindung mehr, und das muss man vorher wissen, nicht nachher erklären.

Der Aufwand steckt in der Übersetzung
Zwei Systeme beschreiben dieselbe Bestellung mit verschiedenen Begriffen, Feldern und Regeln. Die Arbeit liegt nicht im Transport der Daten, sondern in der Entscheidung, was auf der anderen Seite was bedeutet. Diese Entscheidungen trifft am Ende niemand ausser euch beiden, und sie gehören ins Projekt, nicht in die Testphase.
Was schiefgeht, wenn niemand früh fragt
Schnittstellen fallen selten spektakulär aus. Sie scheitern leise, und meistens an denselben vier Dingen.
Der Zugang fehlt. Für die Testumgebung braucht es ein Konto beim anderen Anbieter, und das bestellt niemand, bis es weh tut. Wir fragen deshalb in der ersten Woche danach, nicht in der letzten. Ein Freigabeprozess bei einem Drittanbieter dauert manchmal länger als die Anbindung selbst.
Das andere System ist mal weg. Wartungsfenster, Störung, abgelaufenes Passwort. Wenn deine Software dann einfach stehen bleibt, ist das ein Konstruktionsfehler. Sie muss es nochmal versuchen und dir sagen, dass etwas hängt.
Es gibt ein Limit. Viele Anbieter erlauben nur eine bestimmte Anzahl Anfragen pro Minute. Solange du zehn Bestellungen am Tag hast, merkst du davon nichts. Am ersten guten Tag merkst du es sofort.
Der Anbieter ändert etwas. APIs werden weiterentwickelt, Versionen abgelöst, Felder umbenannt. Das ist einer der Gründe, warum Software Pflege braucht, auch wenn du selber nichts änderst. Mehr dazu steht in Software ist nie fertig.
Wie wir das angehen
Wir behandeln jede Anbindung als eigenes Risiko, nicht als Detail am Ende der Liste. Konkret heisst das dreierlei.
Wir bauen die Verbindung früh und echt. Nicht als letzte Aufgabe kurz vor dem Launch, sondern als eine der ersten, mit richtigen Zugangsdaten gegen die Testumgebung. Wenn eine API weniger kann als versprochen, willst du das in Woche zwei wissen, nicht in Woche neun.
Wir kapseln sie. Der Teil deiner Software, der mit dem fremden System redet, sitzt an genau einer Stelle. Ändert der Anbieter etwas oder wechselst du ihn, tauschen wir dieses eine Stück aus, statt dein halbes Produkt zu operieren. Das ist derselbe Gedanke wie die dünne eigene Schicht auf erprobten Bausteinen aus Selber bauen oder kaufen.
Wir machen sichtbar, was durchläuft. Jede Übergabe wird protokolliert, jeder Fehlschlag wird gemeldet und wiederholt. Eine Schnittstelle, die still versagt, ist gefährlicher als eine, die laut abbricht.
Und eine Frage stellen wir immer, bevor Daten fliessen: Was genau geht da eigentlich zu wem? Bei Anbindungen an Dritte verlassen Kundendaten dein System. Das ist manchmal richtig und manchmal unnötig. Wie wir das prüfen, steht in Wo bleiben deine Daten.
Die Faustregel
Frag bei jeder geplanten Anbindung drei Dinge, bevor du eine Offerte unterschreibst: Gibt es eine dokumentierte API? Gibt es eine Testumgebung, und wer besorgt den Zugang? Was passiert, wenn das andere System eine Stunde nicht antwortet? Wer diese drei Antworten hat, kennt achtzig Prozent des Risikos.
Schnittstellen sind kein Randthema. Sie sind der Ort, an dem deine neue Software auf die Realität deiner Firma trifft, und die Realität hat schon Systeme, Verträge und Gewohnheiten. Wer das früh ernst nimmt, baut eine Verbindung. Wer es aufschiebt, baut eine Baustelle.
Deine neue Software soll mit dem reden, was schon läuft? Erzähl uns, welche Systeme im Spiel sind, wir schauen uns die Anbindung ehrlich an.



