API-Landschaften verstehen statt nur verwalten

API-Management-Plattformen beantworten viele operative Fragen zuverlässig. Sie zeigen, welche APIs verfügbar sind, über welche Routen sie erreichbar sind, welche Richtlinien gelten und welche Konsumenten registriert wurden. Für Architektur, Governance und Modernisierung reicht diese Sicht häufig nicht aus. Das Problem besteht dabei nicht zwingend in fehlenden Daten. Meist sind die Informationen, die durch den Zusammenhang/durch die Relation von Daten entstehen, nicht ausreichend durchsuchbar oder durch eine Benutzeroberfläche abgebildet. Nutzungsdaten liegen im Monitoring, technische Konfigurationen im API-Management, Verträge in Repositories oder Registries, Verantwortlichkeiten in organisatorischen Verzeichnissen und fachliche Zuordnungen in Architekturmodellen oder im Wissen einzelner Teams. Jedes System zeigt einen relevanten Ausschnitt. Mithilfe all dieser Ausschnitte sind jedoch viele Fragen nur mit vielen Klicks und hohen manuellen Aufwand beantwortbar. Ein transparentes Bild der API-Landschaft ergibt sich nicht.

Dafür wird eine zusätzliche Wissensschicht benötigt. Sie verbindet APIs mit ihren Verträgen, Versionen, Services, Konsumenten, Teams, fachlichen Capabilities, Zusammenhänge, Definitionen und Laufzeitdaten. Ein Knowledge Graph ist eine Möglichkeit, eine solche Schicht technisch umzusetzen. Die zentrale Unterscheidung lautet: API-Management organisiert den Betrieb von APIs. Eine Wissensschicht organisiert das Wissen über diese APIs.

Legacy ist kein Qualitätsurteil

Besonders sichtbar wird das fehlende Wissen über Zusammenhänge bei Legacy APIs. Der Begriff wird häufig mit veralteter Technik, schlechter Dokumentation oder dringendem Ablösebedarf verbunden. Das trifft die Realität vieler Organisationen nur unzureichend. Zahlreiche APIs sind seit Jahren produktiv, stabil und geschäftskritisch. Sie unterstützen Prozesse, die sich weder kurzfristig neu bauen noch ohne erhebliche Risiken abschalten lassen. Dass eine API lange existiert, sagt zunächst wenig über ihre technische Qualität aus. Mit Legacy meinen wir daher etablierte Schnittstellen, die über längere Zeit in eine gewachsene Systemlandschaft eingebettet wurden. Während die API weiterhin ihren Zweck erfüllt, verändern sich um sie herum Teams, Plattformen, Verantwortlichkeiten und fachliche Anforderungen. Schwierig wird es, wenn die geschäftliche Bedeutung erhalten bleibt, die Einbettung aber zunehmend schwerer nachvollziehbar ist. Wer verantwortet die API heute? Welche Anwendungen nutzen sie tatsächlich? Welche Services hängen von ihr ab? Welche Verträge und Versionen sind maßgeblich? Welche fachliche Capability unterstützt sie? Welche Folgen hätte eine Änderung?

Das relevante Merkmal einer Legacy API ist in diesem Zusammenhang nicht ihr Alter. Entscheidend ist die Lücke zwischen ihrer fortbestehenden Bedeutung und dem verfügbaren Wissen über Nutzung, Verantwortung und Abhängigkeiten.

Ein API-Inventar zeigt noch keine API-Landschaft

API-Management-Plattformen und Developer Portals schaffen Sichtbarkeit. Sie zeigen, welche APIs registriert sind, welche Endpoints sie anbieten, welche Authentifizierungsmethoden verwendet werden und welche Rate Limits gelten. Damit beantworten sie viele operative Fragen schnell und zuverlässig. Das Verständnis einer Landschaft erfordert jedoch mehr als eine Liste ihrer Bestandteile. Welche Konsumenten Anwendung verwendet eine bestimmte Operation? Welches Team verantwortet diese Anwendung? Welche Route führt zu welchem Service? Welche API ist im Gateway vorhanden, aber nicht im Portal veröffentlicht? Welche Subscription besteht formal, zeigt jedoch keine tatsächliche Nutzung?

Ein Inventar beschreibt Objekte. Eine Landschaft entsteht aus deren Beziehungen. Diese Beziehungen verteilen sich häufig über mehrere Systeme. Das API-Management kennt einen Konsumenten, aber nicht zwingend dessen fachliche Rolle. Das Monitoring kennt die Zahl der Aufrufe, kann sie jedoch nicht immer einem verantwortlichen Team oder Geschäftsprozess zuordnen. Eine Architekturdokumentation beschreibt möglicherweise den beabsichtigten Zustand, während Laufzeitdaten zeigen, welche Abhängigkeiten tatsächlich genutzt werden. Diese operative Sicht ist notwendig. Sie bildet jedoch nicht automatisch die Grundlage für organisationsweite Architektur- und Governance-Entscheidungen.

Der Lösungsraum beginnt mit den Beziehungen

Für diese Beziehungen braucht es ein gemeinsames Modell. Eine API steht etwa in Beziehung zu ihren Verträgen, Versionen, Operationen, Routen und Services. Konsumenten Anwendungen verwenden diese Operationen. Teams verantworten Anwendungen oder APIs. Fachliche Capabilities beschreiben, welche organisatorische Fähigkeit durch eine oder mehrere APIs unterstützt oder realisiert wird. Policies definieren Zugriffs- und Laufzeitregeln. Monitoring-Daten zeigen, welche der modellierten Verbindungen tatsächlich genutzt werden.

Beispiel Ontologie-Modellierung: Vereinfacht könnten die oben beschriebenen Beziehungsketten so aussehen:

Diese Ontologie lässt sich beispielhaft in Teilpfade zerlegen. Damit lässt sich verdeutlichen, welche Information man mithilfe dieser Beziehungen abfragen kann:

Über den ersten Pfad lässt sich untersuchen, welche Teams und Anwendungen von einer Änderung an der API betroffen sein könnten. Dazu muss der Graph von der geänderten Komponente zu den konsumierenden Anwendungen traversiert werden.

Der zweite Pfad verbindet die technische Schnittstelle mit ihrem fachlichen Zweck.

Diese Capabilities sind jedoch meist nicht im API Management System hinterlegt und können daher nicht ohne Aufwand in den Graphen eingepflegt werden. Ein maschinenlesbarer Vertrag beschreibt, welches Verhalten die API zusichert. Die Zuordnung einer API zu einer Capability lässt sich allerdings nicht zuverlässig allein aus Gateway-Metadaten, Pfaden oder Schema-Namen ableiten. Sie erfordert fachliches Wissen und eine nachvollziehbare Modellierungsentscheidung. Eine API kann mehrere Capabilities unterstützen; zugleich kann dieselbe Capability durch mehrere APIs oder andere Schnittstellen implementiert werden.

Das Ziel einer (ersten) Modellierung sollte keine möglichst umfassende Ontologie sein. Ausgangspunkt der Modellierung sind stattdessen konkrete Fragen: Welche Änderungen verursachen heute besonders viel manuelle Recherche? Welche Governance-Prüfungen benötigen Informationen aus mehreren Systemen? Wo fehlen belastbare Aussagen über Ownership, Capabilities, Abhängigkeiten oder Nutzung? Aus diesen Fragen lässt sich ein minimales Modell ableiten. Erst wenn es einen nachweisbaren Nutzen liefert, sollte es erweitert werden.

Warum ein Graphmodell zu dieser Aufgabe passt

Effiziente relationale Abfragen: Der Mehrwert entsteht nicht durch Neo4j oder eine bestimmte Graphdatenbank. Entscheidend ist ein Datenmodell, das Beziehungen als eigenständige Informationen behandelt. Relationale Modelle drücken Beziehungen typischerweise über Schlüssel und Verknüpfungen zwischen Tabellen aus. Das ist für viele Anwendungsfälle vollkommen ausreichend. Ein Graphmodell macht Relationen jedoch direkt zum Gegenstand der Navigation und Analyse. Graphdatenbanken sind darauf spezialisiert und optimiert, komplexe relationale Abfragen möglichst effizient auszuführen. Eine Abfrage kann von einer API zu ihrem Vertrag, von dort zu einer Operation, einer Route, einem Service und anschließend weiter zu konsumierenden Anwendungen und verantwortlichen Teams führen. Ebenso kann sie einer Capability zu den vorhandenen API-Implementierungen und deren tatsächlicher Nutzung folgen. Mit wachsender Anzahl und Vielfalt der Beziehungen lässt sich ein Graphmodell häufig leichter um neue Analysepfade erweitern als ein Schema, das für feste Reports entworfen wurde.

Im relationalen Modell können Abfragen mit vielen aufeinanderfolgenden Joins einen hohen Rechen- und Speicheraufwand verursachen. Die Zeilenanzahl kann durch die Rekombination explodieren, die Spaltenanzahl steigt, und die Datenbank kann große Zwischenergebnisse berechnen und im Arbeitsspeicher halten müssen. Auch die Optimierung für den Ausführungsplan der Abfrage (Reihenfolge der Tabellenverknüpfung, Algorithmus) kann viel Zeit benötigen, da der Suchraum für Pläne komplexer Abfragen sehr groß sein kann.

Graphmodelle sind zum Traversieren von Relationen optimiert. Beziehungen werden als eigenständige Elemente bzw. direkte Verweise zwischen Knoten gespeichert, sodass Traversierungen entlang dieser Kanten erfolgen können, ohne dass die Beziehungen zur Laufzeit über Join-Operationen rekonstruiert werden müssen (index-free adjacency). Zwischenergebnisse, die nicht für die finale Antwort benötigt werden, müssen nicht im Arbeitsspeicher gehalten werden. Dieser Vorteil zeigt sich insbesondere bei stark vernetzten Daten und tiefen Traversierungen.

Visualisierung: Auch die Visualisierung profitiert davon. Stark vernetzte Services, zentrale Abhängigkeitspunkte oder ungewöhnliche Verbindungsmuster sind in Graphen schneller erkennbar als in Tabellen. Der praktische Nutzen eines Graphmodells liegt allerdings primär in effizienter maschineller Analyse.

Heterogene Kontexte auflösen: Ein Graph kann zudem unterschiedliche Bedeutungen desselben Wortes explizit auseinanderhalten. Ein Plattformobjekt, das in einem API-Gateway als „Service“ bezeichnet wird, muss nicht deckungsgleich mit einem Deployment, einem Repository oder einem fachlichen Service sein. Das gemeinsame Modell kann diese Objekte getrennt abbilden und ihre Verbindungen festhalten. Diese Fähigkeit ist besonders nützlich, wenn der Graph als Wissensquelle eines Chatbots verwendet wird. So können in der Kommunikation mit dem Nutzer Synonyme mithilfe des Kontextes der Frage aufgelöst werden.

API-Management, Monitoring, Developer Portal, Registry und Repositories bleiben die führenden Quellen für ihre jeweiligen Informationen. Das Graphmodell verbindet Verträge, Laufzeitdaten, Verantwortlichkeiten, Capabilities und Abhängigkeiten und beantwortet übergreifende relationale Fragen.

Landschaftswissen als Grundlage für Governance

Diese Verbindung ist auch für API Governance relevant. Bevor eine Organisation Regeln definiert und automatisiert prüft, sollte sie verstehen, welche API-Landschaft tatsächlich vorhanden ist. Kin Lane sieht die Erfassung des realen API-Portfolios als ersten Schritt zu einer wirksamen API-Governance. Regeln, die ohne Kenntnis des Bestands formuliert werden, führen häufig zunächst zu einer großen Zahl von Verstößen, schaffen aber noch keine tragfähige Veränderungsstrategie. Die Bestandsaufnahme ermöglicht dagegen, Regeln an beobachtbaren Mustern auszurichten und ihre Einführung realistisch zu priorisieren.

Dafür lassen sich Informationen aus API-Management, Monitoring, Portalen, Verträgen und organisatorischen Quellen in einem gemeinsamen Graphmodell verbinden. So wird sichtbar, wie APIs genutzt werden, wem sie zugeordnet sind, welche Capabilities sie unterstützen und welche Auswirkungen Änderungen haben könnten.

Governance-Findings lassen sich dadurch in ihrem jeweiligen Zusammenhang bewerten. Eine stark genutzte API mit zahlreichen abhängigen Anwendungen benötigt möglicherweise einen anderen Migrationspfad als eine kaum genutzte Schnittstelle mit derselben Abweichung. Regeln bleiben notwendig, ihre Priorisierung kann sich aber an Nutzung, Risiko, Ownership und Auswirkungen orientieren. Für die Governance von REST APIs setzt Kin Lane den maschinenlesbaren OpenAPI-Vertrag ins Zentrum. Styleguides, Linting-Regeln, Reviews und Pipeline-Prüfungen beziehen sich auf dieses maschinenlesbare Artefakt. Das Graphmodell ergänzt den Vertrag um Versionen, Laufzeitdaten, Ownership, fachliche Zuordnungen und abhängige Konsumenten.

Der Knowledge Graph ersetzt keine API Governance. Er liefert jedoch das Landschaftswissen, ohne das Regeln leicht auf unklaren Verträgen, veralteten Versionen oder falsch zugeordneten APIs angewendet werden.

Ein Proof of Concept als architektonische Untersuchung

Um die Architekturidee zu überprüfen, entwickeln wir derzeit einen Proof of Concept (PoC). Er untersucht, ob sich Daten aus API-Management und Monitoring in einem gemeinsamen Graphmodell so verbinden lassen, dass zusätzliche Analysen möglich werden.

Kong dient als erste API-Management-Quelle und steht exemplarisch für ein API-Gateway beziehungsweise API-Management-System. Prometheus liefert Nutzungsdaten. Neo4j speichert die daraus abgeleiteten Entitäten und Beziehungen, Grafana stellt ausgewählte Auswertungen dar. Ein Chat Interface ermöglicht natürlichsprachliche Fragen auf dem Graphmodell.

Zwischen den Quellsystemen und dem Graphen liegt eine Transformationsschicht. Sie überführt die Plattformobjekte in das gemeinsame Wissensmodell.

Welche Fragen sich untersuchen lassen

Die Demo orientiert sich an Fragen aus den Bereichen Nutzung, Governance und Abhängigkeiten.

• Welche APIs und Endpoints werden besonders häufig verwendet?

• Welche Konsumenten erzeugen das höchste Aufrufvolumen?

• Gibt es Subscriptions, die registriert sind, aber keine erkennbare Nutzung zeigen?

• Bei welchen Services treten ungewöhnliche Nutzungsspitzen auf?

Weitere Fragen betreffen die technische Governance.

• Welche Endpoints besitzen keine Authentifizierungs-Plugins?

• Wie hoch ist der Anteil erfolgreicher API-Aufrufe?

• Wo weichen Konfigurationen von erwarteten Regeln ab?

Für eine Change Impact Analysis sieht das Modell Beziehungen zwischen Services, Routes, API-Operationen, Konsumenten Anwendungen und Teams vor. So kann der Pfad von einer technischen Änderung zu potenziell betroffenen Konsumenten nachvollzogen werden. Die Aussagekraft hängt davon ab, ob die erforderlichen Beziehungen vollständig und aktuell vorliegen. Auch API Sprawl ist Teil des Lösungsraums. Ähnliche Namen, Pfade oder Schemas können auf Überschneidungen hinweisen, sie beweisen jedoch noch keine fachliche Redundanz. Zwei ähnlich strukturierte Schnittstellen können unterschiedliche Nutzergruppen, Qualitätsanforderungen oder Verantwortungsbereiche bedienen. Für eine belastbarere Bewertung muss daher betrachtet werden, welche Capability eine API unterstützt und ob mehrere Schnittstellen tatsächlich alternative Implementierungen derselben fachlichen Fähigkeit darstellen. Erst die Verbindung aus struktureller oder semantischer Ähnlichkeit, Capability-Zuordnung und realer Nutzung liefert eine tragfähige Grundlage für Konsolidierungsentscheidungen. Kin Lane argumentiert in seiner Arbeit zur messbaren Wiederverwendung, dass nicht die einzelne API, sondern die Capability die relevante Einheit der Wiederverwendung ist. Mehrere APIs können Implementierungen derselben Capability darstellen. Für die Bewertung unterscheidet er zudem zwischen Wiederverwendungspotenzial und realer Adoption und bezieht dafür unter anderem Konsumenten- und Traffic-Daten ein.

Ein Knowledge Graph kann Capabilities, ihre verschiedenen Implementierungen, technische Eigenschaften und Nachfragedaten miteinander verbinden. Er liefert damit Evidenz für eine Konsolidierungsentscheidung, trifft diese Entscheidung aber nicht selbst. Eine stark genutzte, technisch nicht ideale API kann betrieblich relevanter sein als eine elegantere Alternative ohne aktive Konsumenten. Das Chat Interface vereinfacht den Zugang zu den Abfragen. Seine Zuverlässigkeit hängt unmittelbar vom zugrunde liegenden Modell ab. Es erschließt vorhandenes Wissen, kann fehlende Beziehungen oder fachliche Bewertungen jedoch nicht kompensieren.

Die eigentliche Herausforderung liegt in den Daten

Eine Graphdatenbank lässt sich schnell installieren. Der Aufbau einer verlässlichen Wissensschicht ist deutlich anspruchsvoller. Besonders schwierig ist die eindeutige Zuordnung von Objekten aus verschiedenen Quellen. Sind ein API-Eintrag, ein Gateway-Service und ein Repository eigenständige Objekte oder unterschiedliche Repräsentationen desselben Systems? Namensähnlichkeiten reichen für diese Entscheidung häufig nicht aus. Für Governance muss zudem nachvollziehbar sein, welcher Vertrag kanonisch ist, welche Version betrachtet wird und wer Verantwortung trägt. Fehlt diese Zuordnung, kann eine Regel technisch korrekt ausgeführt werden und sich dennoch auf ein veraltetes oder nicht maßgebliches Artefakt beziehen. Genau solche unklaren Quellen, Versionen und Stakeholder beschreibt Kin Lane als ein zentrales Problem beim Erfassen einer API-Landschaft.

Ähnlich anspruchsvoll ist die Verbindung statischer Konfiguration mit Laufzeitdaten. Eine Subscription beschreibt zunächst eine erlaubte oder vorgesehene Nutzung. Erst Metriken zeigen, ob diese Beziehung in der Praxis aktiv ist. Fehlende Ownership, inkonsistente Bezeichnungen und veraltete Informationen werden durch das gemeinsame Modell leichter sichtbar. Die Korrektur bleibt Aufgabe der verantwortlichen Prozesse und Quellsysteme. Auch das gemeinsame Vokabular benötigt Pflege. Begriffe wie API, Service, Konsumenten, Capability oder Produkt müssen ausreichend eindeutig sein. Insbesondere darf eine technische Operation nicht vorschnell mit einer fachlichen Capability gleichgesetzt werden. Ohne abgestimmte Definitionen verliert das Modell mit jeder Erweiterung an Verständlichkeit.

Schließlich müssen die Beziehungen, ihre Herkunft und ihr Aktualisierungsstand nachvollziehbar bleiben. Ein einmaliger Import genügt für eine Demo, nicht aber für Architektur- oder Governance-Entscheidungen. Synchronisation und Datenherkunft gehören deshalb zur produktiven Architektur.

Vom PoC zur plattformunabhängigen Wissensschicht

Eine spätere Ausbaustufe könnte AsyncAPI-Beschreibungen, Repositories, CI/CD-Ergebnisse und Architekturmodelle einbeziehen. Dadurch ließen sich technische Metadaten um Vertragsinformationen, Implementierungsdetails, Governance-Ergebnisse, Capabilities und weitere fachliche Zuordnungen ergänzen. Auch unterschiedliche API-Gateways und API-Management-Plattformen sollten unterstützt werden. Dafür braucht die Wissensschicht ein eigenes, plattformunabhängiges Modell und klar abgegrenzte Adapter zu den Quellsystemen. Nur so bleibt sie unabhängig von den Begriffen und Strukturen eines einzelnen Herstellers. Perspektivisch könnten auch Governance-Entscheidungen Teil des Modells werden. Zu einem Finding ließen sich Review, verantwortliches Team, Entscheidung, Begründung und Gültigkeitsdauer einer Ausnahme erfassen. Kin Lane beschreibt diese Provenienz als Grundlage für Verantwortlichkeit. Relevant ist nicht allein, dass ein Finding existiert, sondern auch, wer es bewertet hat und welche Entscheidung daraus hervorging. Damit könnte neben dem aktuellen Zustand auch ein Teil der Entscheidungsgeschichte zugänglich werden. Der Ausbau sollte schrittweise erfolgen. Statt sofort die gesamte Integrationslandschaft zu modellieren, empfiehlt sich ein klar abgegrenztes Szenario: eine Auswirkungsanalyse, die Identifikation ungenutzter Subscriptions oder die Prüfung sicherheitsrelevanter Policies.

Ein solches Szenario begrenzt den Umfang des Modells und macht den Nutzen überprüfbar. Danach lässt sich entscheiden, welche weiteren Datenquellen, Adapter und Beziehungen tatsächlich benötigt werden.

API-Management braucht eine ergänzende Wissensschicht

Mit zunehmender Größe und Heterogenität einer API-Landschaft reicht die operative Sicht einzelner Plattformen nicht aus. Architektur, Governance und Modernisierung benötigen zusätzlich ein gemeinsames Modell von Verträgen, Capabilities, tatsächlicher Nutzung, Verantwortlichkeiten und Abhängigkeiten. Eine graphbasierte Wissensschicht kann diese Informationen verbinden und abfragbar machen. Ihr Wert liegt weder in einer bestimmten Datenbank noch in der Visualisierung, sondern in einem nachvollziehbaren Modell der Zusammenhänge. Der Proof of Concept untersucht eine konkrete technische Umsetzung. Die zugrunde liegende Architekturthese reicht weiter: API-Management organisiert den Betrieb von APIs. Eine Wissensschicht organisiert das Wissen, das erforderlich ist, um APIs als Teil ihrer technischen, organisatorischen und fachlichen Landschaft zu verstehen und weiterzuentwickeln.