Was eine Schnittstelle wirklich kostet

„Die beiden Programme reden nicht miteinander.“ So wird das Problem im Betrieb beschrieben, und es ist eines der häufigsten überhaupt. Artikel werden in der Warenwirtschaft und im Shop gepflegt. Anfragen vom Kontaktformular werden ins CRM abgetippt. Stunden werden erfasst und danach in die Buchhaltung übertragen.

Die Arbeit selbst ist dabei nicht das Schlimmste. Schlimmer ist, dass jede doppelte Eingabe zwangsläufig Abweichungen erzeugt — und dass anschließend niemand sagen kann, welche Seite recht hat.

Eine Schnittstelle löst genau das. Sie ist außerdem eines der am besten abgrenzbaren Vorhaben, die es gibt: klein genug für einen Festpreis, und das Ergebnis ist am Tag der Übergabe sichtbar.

Was eine Schnittstelle ist

In verständlichem Deutsch: eine vereinbarte Tür an einem Programm. Durch diese Tür darf ein anderes Programm Daten holen oder abgeben, und zwar in einer festgelegten Form — welche Felder es gibt, was darin stehen darf, wie eine Anfrage aussieht und wie die Antwort. Weil beide Seiten sich auf diese Form verlassen können, muss kein Mensch mehr abtippen.

Der englische Begriff dafür ist API, kurz für Programmierschnittstelle. Er taucht in Angeboten auf und meint nichts anderes.

Ob eine solche Tür existiert, entscheidet der Hersteller des jeweiligen Systems. Das ist der Grund, warum die erste Frage in jedem Schnittstellenprojekt nicht lautet, was Sie wollen, sondern was Ihre Systeme zulassen.

Frage 1: Hat das System überhaupt eine Tür?

Es gibt vier Stufen, und der Unterschied zwischen ihnen ist erheblich:

1. Dokumentierte Programmierschnittstelle. Der beste Fall. Es ist beschrieben, welche Daten wie abrufbar und änderbar sind, und der Hersteller hält sich daran. Der Aufwand ist gut schätzbar.
2. Geregelter Import und Export. Das System kann Dateien ausgeben und einlesen. Das funktioniert zuverlässig, ist aber immer ein Abgleich in Schüben und nie sofort.
3. Direkter Zugriff auf die Datenbank. Technisch häufig möglich, aber mit Vorsicht zu behandeln: Lesen ist meist vertretbar, Schreiben selten, weil dabei die Prüfungen des Programms umgangen werden. Außerdem kann sich die Struktur mit jedem Update ändern, ohne dass jemand das ankündigt.
4. Gar nichts davon. Dann bleibt nur, die Bedienoberfläche zu automatisieren. Das funktioniert, ist aber die anfälligste Variante: Sobald sich am Bildschirm etwas verschiebt, steht sie still. Wir empfehlen das nur, wenn die Alternative Dauerabtippen heißt — und sagen vorher, dass hier laufende Betreuung dazugehört.

Deshalb sage ich zu keinem Fremdsystem etwas zu, bevor ich dessen Dokumentation gesehen haben. Diese Prüfung ist der erste, kurze Arbeitsschritt und erspart beiden Seiten ein Angebot, das auf einer Annahme steht.

Frage 2: In welche Richtung fließen die Daten?

Einseitig ist deutlich einfacher: Ein System gibt, das andere nimmt. Der Shop bekommt Artikel und Bestände aus der Warenwirtschaft; geändert werden sie nur in der Warenwirtschaft.

Beidseitig ist ein anderes Vorhaben. Sobald beide Seiten dieselbe Angabe ändern dürfen, brauchen Sie eine Regel für den Fall, dass beide es tun. Die brauchbarste Antwort ist selten „das jüngere gewinnt“, sondern eine Festlegung je Feld: Der Preis wird nur in der Warenwirtschaft geändert, die Beschreibung nur im Shop, die Bestandsmenge kommt aus der Warenwirtschaft und wird durch Bestellungen im Shop verringert.

Diese Festlegung ist fachliche Arbeit, keine technische. Sie entsteht in einem Gespräch und gehört ins Angebot. Wo sie fehlt, entstehen später die Fälle, in denen jemand eine Änderung vornimmt und sie eine Stunde später wieder verschwunden ist.

Frage 3: Wie oft muss das passieren?

Drei übliche Takte:

• Einmal täglich, meist nachts. Günstig und robust, weil ein Durchlauf sich einfach wiederholen lässt, wenn etwas schiefging.
• Regelmäßig, etwa stündlich. Guter Mittelweg für Bestände und Preise.
• Im Moment des Ereignisses. Sobald eine Bestellung eingeht, geht sie weiter. Das ist der aufwendigste Fall, weil jeder Einzelvorgang für sich zuverlässig sein muss — mit Wiederholung, Warteschlange und Protokoll.

Die richtige Frage ist nicht „wie schnell geht es“, sondern: Wie alt darf diese Angabe im schlimmsten Fall sein, ohne dass daraus ein Problem wird? Bei einem Lagerbestand mit knapper Ware ist die Antwort eine andere als bei einer Artikelbeschreibung. Wer hier ehrlich unterscheidet, spart einen erheblichen Teil des Aufwands.

Frage 4: Woran erkennen beide Seiten denselben Datensatz?

Der am häufigsten unterschätzte Punkt im ganzen Thema. Damit zwei Systeme über dasselbe sprechen, braucht jeder Datensatz auf beiden Seiten eine eindeutige, stabile Kennung — eine Artikelnummer, eine Kundennummer, eine Belegnummer.

In der Praxis fehlt sie oft, oder sie ist nicht stabil: Artikel wurden im Shop neu angelegt statt übernommen, Kunden existieren doppelt, Nummern wurden zwischendurch umgestellt. Dann besteht ein Teil des Vorhabens darin, eine Zuordnung herzustellen und danach sauber zu halten.

Namen und Bezeichnungen taugen dafür nicht. „Müller GmbH“ und „Mueller GmbH“ sind für einen Menschen dasselbe und für zwei Systeme nicht. Wenn Sie ein Schnittstellenprojekt vorbereiten wollen, ist das Aufräumen der Kennungen das Nützlichste, was Sie vorher tun können.

Frage 5: Was passiert im Fehlerfall?

Hier trennt sich eine Verbindung, die trägt, von einer, die Ärger macht. Fremdsysteme sind zeitweise nicht erreichbar, Wartungsfenster gibt es überall, und Datensätze enthalten manchmal etwas, das die Gegenseite ablehnt. Das ist normal und muss eingeplant sein:

• Erneut versuchen, mit wachsenden Abständen statt im Sekundentakt.
• Offene Vorgänge in einer Warteschlange halten, damit nichts verloren geht, während die Gegenseite fehlt.
• Jeden Vorgang so bauen, dass er zweimal ankommen darf, ohne zweimal zu wirken. Sonst entstehen bei jeder Wiederholung Dubletten — im Zweifel doppelte Bestellungen.
• Protokollieren, was wann übertragen wurde. Ohne Protokoll ist keine Frage der Art „warum steht das dort nicht“ beantwortbar.
• Einen Menschen benachrichtigen, wenn es länger klemmt.

Der letzte Punkt ist der wichtigste. Eine Schnittstelle, die ausfällt und laut ist, ist ein kleines Problem. Eine, die still stehen bleibt, wird oft erst durch einen Kunden entdeckt — und dann liegt bereits eine Woche falscher Daten dazwischen.

Eine Schnittstelle ist nichts, was man einmal baut

Sie verschleißt nicht, aber ihre Umgebung ändert sich, und zwar auf Seiten, die Ihnen nicht gehören:

• Hersteller veröffentlichen neue Versionen ihrer Schnittstellen und schalten alte nach einer Frist ab.
• Zugänge, Schlüssel und Zertifikate laufen ab.
• Felder bekommen neue Bedeutungen, Pflichtangaben kommen hinzu.
• Mengen wachsen, bis ein nächtlicher Durchlauf nicht mehr in sein Zeitfenster passt.

Deshalb gehören zu einer Verbindung zwei Dinge dauerhaft dazu: eine Überwachung, die meldet, wenn nichts mehr fließt, und jemand, der erreichbar ist, wenn sich auf der Gegenseite etwas ändert. Wie so ein Rahmen aussieht, steht auf der Seite Website-Wartung — die dortigen Stufen gelten auch für Verbindungen, die nichts mit einer Website zu tun haben.

Ein Hinweis zu personenbezogenen Daten

Sobald Kundendaten zwischen Systemen fließen, ist es keine rein technische Frage mehr. Klären Sie, wer die Daten verarbeitet, ob ein Vertrag zur Auftragsverarbeitung nötig ist und wo die beteiligten Dienste betrieben werden. Wir sind keine Rechtsanwälte und sagen das offen; ich weise aber im Angebot darauf hin, wenn ein Vorhaben diese Frage aufwirft.

Was Sie vorbereiten können

Fünf Angaben genügen für eine erste, belastbare Einschätzung:

1. Welche beiden Systeme sollen verbunden werden, in welcher Version?
2. Welche Daten genau — Artikel, Bestände, Preise, Kunden, Belege?
3. In welche Richtung, und wer darf was ändern?
4. Wie aktuell muss es sein?
5. Gibt es zu beiden Systemen eine Schnittstellenbeschreibung oder einen Ansprechpartner beim Hersteller?

Punkt 5 ist der, der am häufigsten fehlt und am meisten spart. Oft genügt eine kurze Mail an Ihren Systemanbieter mit der Frage, ob und in welcher Form eine Schnittstelle zur Verfügung steht.

Warum das ein guter erster Schritt ist

Weil es klein bleibt und trotzdem sofort etwas ändert. Doppelte Eingaben verschwinden an einer klar benennbaren Stelle, und Sie sehen an einem überschaubaren Auftrag, ob die Zusammenarbeit trägt, bevor größere Vorhaben anstehen. Häufig ist die Verbindung zwischen zwei vorhandenen Systemen ohnehin die günstigere Antwort auf ein Problem, für das jemand anders gleich eine neue Anwendung vorschlägt — dazu mehr im Artikel Individualsoftware oder Standardsoftware?.

Wenn Sie wissen möchten, ob Ihre beiden Systeme miteinander können: Nennen Sie sie im kostenlosen Erstgespräch. Die Prüfung der Dokumentation steht am Anfang, und danach gibt es eine belastbare Aussage statt einer Vermutung. Die Details stehen auf der Seite Software entwickeln lassen.