Im thinkBI Podcast geht es diesmal um eine Schnittstellenlogik, die in modernen Systemlandschaften fast automatisch vernünftig wirkt: die Web-API. Sobald ein System eine API anbietet, scheint die Integrationsfrage oft schon beantwortet. Der Zugriff wirkt sauber, standardisiert und zeitgemäß.
Genau diese Selbstverständlichkeit lohnt einen genaueren Blick. Denn was für operative Integration sinnvoll ist, ist noch lange keine gute Datenquelle für Business Intelligence.
APIs wirken sauber, weil sie Distanz schaffen
Eine Web-API trennt den Konsumenten von der direkten Datenhaltung. Das ist ihr offensichtlicher Vorteil. Niemand greift unmittelbar auf Tabellen zu. Stattdessen läuft der Zugriff über eine definierte Anwendungsschicht, über Authentifizierung, Business-Logik und ein kontrolliertes Antwortformat wie JSON oder XML.
Für transaktionale Anwendungen ist das oft sinnvoll. Systeme sollen nicht beliebig von außen geöffnet werden. Die Anwendung schützt ihre Regeln, validiert Zugriffe und stellt genau die Funktionen bereit, die andere Prozesse benötigen.
Für BI entsteht daraus aber ein anderer Sachverhalt. BI will in vielen Fällen keine einzelnen Geschäftsvorfälle auslösen oder validierte Anwendungsprozesse durchlaufen. BI will Daten laden, zusammenführen, transformieren und analysierbar machen. Dafür sind zusätzliche Schichten nicht automatisch ein Qualitätsmerkmal. Sie können auch schlicht ein Umweg sein.
Jede API-Abfrage trägt architektonischen Ballast
Der eigentliche Widerspruch liegt in der Zugriffskette. Eine ETL- oder BI-Strecke spricht nicht direkt mit der Datenhaltung. Sie schickt eine Anfrage über ein Protokoll wie HTTPS, in einem Format wie JSON oder XML, an die Anwendung. Dort wird geprüft, interpretiert und häufig erst intern wieder per SQL auf die Datenbank zugegriffen. Anschließend werden die Daten erneut aufbereitet, serialisiert und an die ETL-Strecke zurückgegeben, wo sie wieder zerlegt und weiterverarbeitet werden.
Damit laufen dieselben Informationen durch mehrere Schichten, obwohl sie am Ende meist in einer analytischen Struktur landen sollen. Das erzeugt Overhead. Nicht nur technisch durch Transportformate und zusätzliche Zeichen, sondern auch architektonisch: Die Anwendungsschicht übernimmt Arbeit, die für BI oft keinen echten Mehrwert erzeugt.
Das ist keine Spitzfindigkeit. Es ist eine Frage der Systemökonomie. Wenn große Datenmengen regelmäßig geladen werden, ist jede unnötige Zwischenschicht ein Kostenfaktor in Laufzeit, Last und Fehleranfälligkeit.
Web-APIs sind meist transaktional gedacht, nicht analytisch
Hinzu kommt ein zweites, tieferes Problem. Die meisten APIs werden nicht für analytische Exporte gebaut. Sie entstehen aus einer transaktionalen Denkweise heraus. Sie sollen Datensätze lesen, ändern oder Prozesse anstoßen. Entsprechend sind viele Endpunkte auf Einzelfälle, Ressourcenbeziehungen und konkrete Anwendungsvorgänge ausgelegt.
Für BI ist genau das oft unpraktisch.
Statt eine große fachliche Datenmenge in einem Zug laden zu können, beginnt ein Kettenspiel von Abfragen. Zuerst wird ein Kopfdatensatz geladen, dann eine ID ermittelt, danach werden untergeordnete Informationen in weiteren Requests geholt. Aus analytischer Sicht ist das keine saubere Bereitstellung, sondern ein mühsames Nachbauen transaktionaler Navigationslogik.
Man sieht daran, dass moderne Schnittstellen und gute BI-Bereitstellung nicht dasselbe sind. Eine API kann hervorragend für System-zu-System-Interaktion geeignet sein und trotzdem eine schwache Quelle für analytische Massendaten bleiben.
Die Anwendung wird zum Durchlauferhitzer
Besonders problematisch wird das dort, wo BI regelmäßig größere Bestände laden soll. Dann wird der Applikationslayer zum Durchlauferhitzer für Daten, die eigentlich möglichst roh und effizient in eine analytische Verarbeitung gelangen sollten.
Die Anwendung prüft Berechtigungen, interpretiert Parameter, verarbeitet Logik, formatiert Antworten und trägt damit Last, die nicht aus ihrem eigentlichen Geschäftszweck entsteht. Im Extremfall laufen ungeschickte API-Abfragen auf nahezu vollständige Selektierungen hinaus, weil Filter fehlen, unvollständig übergeben werden oder das Interface selbst nur begrenzte Filtermöglichkeiten bietet.
Gerade weil viele Web-Interfaces weniger standardisiert sind, als ihr moderner Eindruck vermuten lässt, beginnt oft eine neue Abhängigkeit vom jeweiligen Anbieter. Manche unterstützen OData-artige Selektionslogik, andere liefern proprietäre Muster, wieder andere stellen nur begrenzte Exportoptionen bereit. Dann muss BI nicht nur Daten laden, sondern die Eigenarten eines Mitteltier-Interfaces permanent mitdenken.
Das ist keine robuste Datenarchitektur. Das ist eine Form von Kopplung, die modern aussieht, aber analytisch schwach bleibt.
Für BI sind rohe Daten oder definierte Exporte oft die reifere Lösung
Der Perspektivwechsel ist deshalb einfach, aber wichtig: Gute BI fragt nicht zuerst, welche Schnittstelle am modernsten wirkt. Gute BI fragt, welche Bereitstellungsform für analytische Nutzung am belastbarsten ist.
Wenn ein direkter SQL-Zugriff verantwortbar ist, kann er für BI deutlich geeigneter sein. Die Daten lassen sich gezielt, ohne zusätzliche Anwendungsschichten und näher an ihrer ursprünglichen Form laden. Transformation und Anreicherung passieren dann dort, wo sie hingehören, in der analytischen Strecke.
Wenn direkter Zugriff nicht sinnvoll ist, sind definierte Exporte oft die bessere Alternative. Dann wird das Vorsystem nicht bei jeder Ladeanfrage erneut beansprucht. Es stellt Daten kontrolliert bereit, und BI arbeitet auf einer sauberen Übergabe statt auf einer permanenten Anwendungsinteraktion.
Damit wird auch die Reihenfolge der Optionen klarer. Nicht jede bereitgestellte API ist automatisch der Königsweg. Für BI kann sie sogar die schwächere Wahl sein, wenn sie operative Interaktionslogik dort verlängert, wo analytische Bereitstellung gebraucht wird.
Moderne Integration ist nicht automatisch gute BI-Integration
Die ruhigere, aber wichtigere Pointe lautet deshalb: APIs sind keine schlechte Technologie. Sie sind oft nur für eine andere Aufgabe gebaut.
Wer operative Anwendungen miteinander verbindet, Prozesse anstößt oder fachliche Transaktionen kontrolliert austauschen will, braucht häufig genau diese Art von Schnittstelle. Wer hingegen analytische Daten laden, historisieren und modellieren will, sollte genauer prüfen, ob der Weg durch die Anwendungsschicht wirklich sinnvoll ist.
Business Intelligence braucht Daten nicht in der Form, in der eine Anwendung sich selbst schützt. Sie braucht Daten in einer Form, die Verarbeitung, Entkopplung und belastbare Analyse unterstützt.
Deshalb ist die eigentliche Architekturfrage nicht: Gibt es eine API?
Sondern: Ist diese Schnittstelle für analytische Nutzung gebaut, oder trägt sie nur die Logik der operativen Anwendung nach außen?
Vielleicht ist genau das die entscheidende Klarstellung: Nicht jede moderne Schnittstelle ist eine gute BI-Schnittstelle. Manchmal ist der reifere Weg der unspektakulärere.
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
