Eine einzelne Schnittstelle ist selten das Problem. Ich habe noch kein Projekt gesehen, bei dem eine API technisch gescheitert ist. Gescheitert sind Projekte daran, dass niemand mehr sagen konnte, welches System bei welchem Datenfeld das letzte Wort hat.
Wie es anfängt
Es beginnt fast immer harmlos. Ein System braucht Daten aus einem anderen, jemand baut eine direkte Verbindung, es funktioniert. Ein Jahr später kommt die nächste Anforderung, wieder eine direkte Verbindung. Nach drei, vier Jahren hat eine mittelgrosse Systemlandschaft oft ein Dutzend solcher Punkt-zu-Punkt-Verbindungen – gewachsen, nicht geplant.
Das Muster kenne ich aus HR- und Payroll-Landschaften besonders gut, weil dort viele Systeme gleichzeitig auf dieselben Personendaten zugreifen: Personalsystem, Zeiterfassung, Lohnbuchhaltung, Zutrittskontrolle, manchmal noch ein separates Bewerbermanagement. Bei einer Transformation mit über fünfzehn Organisationseinheiten, die ich begleitet habe, lief zu Beginn ein einziges Feld – die Kostenstelle eines Mitarbeitenden – über vier verschiedene Wege ins Zielsystem. Bei einer Planänderung kam es vor, dass drei davon einen anderen Wert lieferten als der vierte. Niemand hatte das böswillig gebaut. Es war einfach nie jemand explizit für die Datenhoheit verantwortlich gewesen.
Die Frage, die zuerst geklärt gehört
Bevor eine Schnittstelle technisch spezifiziert wird, sollten vier Dinge auf dem Tisch liegen: Welches System ist für dieses Datenfeld führend? Wer trägt die fachliche Verantwortung, wenn sich die Regel einmal ändert? Was passiert automatisch, wenn die Übertragung fehlschlägt – und wer bemerkt es? Und: Ist diese Verbindung eine Ausnahme, oder wird sie Teil eines Musters, das sich wiederholen wird?
Die letzte Frage wird am häufigsten übersprungen. Eine einzelne Direktverbindung ist meist die schnellste Lösung. Das Problem entsteht, wenn aus einer Ausnahme ein Standardvorgehen wird, ohne dass das je entschieden wurde.
Wo Middleware hilft – und wo nicht
Eine Integrationsplattform oder ein Datenverzeichnis löst kein fachliches Problem. Wenn zwei Systeme unterschiedliche Werte für dieselbe Kostenstelle führen, kann keine Middleware entscheiden, welcher richtig ist. Sie kann die Entscheidung nur sichtbar erzwingen – was schon viel wert ist, aber die eigentliche Arbeit bleibt fachlich, nicht technisch.
Was Middleware wirklich bringt: eine zentrale Stelle für Monitoring, ein einheitliches Fehlerbild statt zehn verschiedener Log-Formate, und die Möglichkeit, eine Verbindung auszutauschen, ohne fünf andere Systeme anzufassen. Das ist der Moment, in dem sich der Aufwand rechnet – meistens erst ab der dritten oder vierten Integration, nicht bei der ersten.
Was ich vor jeder neuen Schnittstelle prüfe
In der Praxis reicht selten eine grosse Architekturübung. Was hilft, ist eine kurze, ehrliche Bestandsaufnahme: Welche Verbindungen existieren heute wirklich – nicht nur die dokumentierten? Wo laufen dieselben Daten über mehr als einen Weg? Und wo würde ein Ausfall am nächsten Morgen zuerst auffallen – und wem?
Diese drei Fragen zeigen meistens innerhalb weniger Tage, wo das eigentliche Risiko liegt. Nicht in der Technik, sondern in den Lücken zwischen den Systemen, für die niemand explizit zuständig ist.
Kurz gefasst
- Einzelne Schnittstellen scheitern selten technisch – das Risiko liegt in fehlender Ownership.
- Vier Fragen vor jeder neuen Verbindung: führendes System, fachliche Verantwortung, Fehlerverhalten, Ausnahme oder Muster.
- Middleware löst kein fachliches Problem, macht Konflikte aber sichtbar und erleichtert den Austausch einzelner Verbindungen.
- Eine ehrliche Bestandsaufnahme der tatsächlichen – nicht nur dokumentierten – Verbindungen ist der schnellste Einstieg.
Wenn Sie unsicher sind, wie viele Ihrer Schnittstellen heute tatsächlich Ownership haben: Das lässt sich in einem ersten Gespräch oft schon grob einschätzen.
