ArchiLU, Startseite
Dokumentation

API-Governance in der Unternehmensarchitektur

Eine API, die niemand erfasst, ändert sich, ohne dass ihre Konsumenten davon erfahren. Governance beginnt mit dem Katalog: Verantwortlicher, Konsumenten, Lebenszyklus und Sicherheitsregeln jeder API.

Aktualisiert am

APIs, Projekt für Projekt entstanden

Ein Team stellt eine API für einen bestimmten Bedarf bereit. Andere Teams binden sich an, dann entwickelt sich die API weiter. Ohne gemeinsame Regeln wählt jedes Team eigene Benennungen, Fehlerformate, Authentifizierung und Versionierung.

Diese Abweichungen summieren sich; man spricht dann von API-Drift. Jede Integration erfordert Anpassungen, und die Wiederverwendung sinkt. Eine Sicherheitsregel einer API fehlt bei einer anderen, und die Dokumentation unterscheidet sich von Team zu Team.

APIs in der Unternehmensarchitektur

APIs verbinden Microservices, SaaS-Anwendungen, Partner, digitale Plattformen und Automatisierungen, einschließlich KI-Agenten. Eine API kann einen Teil einer Geschäftsfähigkeit bereitstellen: ein Konto abfragen, einen Vorgang eröffnen, einen Preis berechnen.

Eine Änderung dieser API betrifft die Prozesse, die sie nutzen. API-Governance ist deshalb auch Aufgabe der Unternehmensarchitektur: Vor einer Änderung muss der Architekt wissen, welche Anwendungen, Prozesse und Fähigkeiten davon abhängen.

Regeln, Standards und Kontrollen

API-Governance verbindet Regeln, Standards und automatisierte Kontrollen. Sie steuern Entwurf, Bereitstellung, Sicherheit und Weiterentwicklung jeder API. Ein Dokument, das niemand anwendet, oder eine manuelle Freigabe im Einzelfall erfasst nicht jede Version.

Diese Regeln lassen sich auf vier Ebenen ordnen:

  • Strategie: Jede API ist einer Geschäftsfähigkeit, einer verantwortlichen Domäne und einer Sichtbarkeit zugeordnet, intern, für Partner oder öffentlich.
  • Design: Die Teams folgen gemeinsamen Konventionen für REST- oder ereignisgesteuerte Schnittstellen, Benennung, Versionen und Fehler; der Vertrag entsteht vor dem Code.
  • Sicherheit und Compliance: Jede API wendet Authentifizierung, Verschlüsselung, Ratenbegrenzung, Eingabevalidierung und die für sie geltenden regulatorischen Kontrollen an.
  • Lebenszyklus: Entwurf, Entwicklung, Bereitstellung, Überwachung und Abkündigung folgen bekannten Stufen.

Der API-Katalog

Governance beginnt mit dem Inventar der vorhandenen APIs. Für jede API nennt der Katalog Name, Verantwortlichen, Lebenszyklusstatus, Konsumenten, Dokumentation und Sicherheitsregeln. Ist der Verantwortliche unbekannt, wird die API so erfasst, bis jemand benannt ist.

Die OpenAPI Specification beschreibt eine HTTP-API standardisiert und unabhängig von der Programmiersprache. Eine aktuelle Beschreibung dient als Vertrag: Menschen und Werkzeuge verstehen, was die API leistet, ohne ihren Code zu lesen.

Automatisierte Kontrollen

Automatisierte Kontrollen wenden die Regeln auf jede Version an, ohne auf eine manuelle Prüfung zu warten.

  • In der Pipeline prüfen als Code geschriebene Regeln (Policy as Code) den Stil, validieren die OpenAPI-Beschreibung und erkennen inkompatible Änderungen.
  • Zur Laufzeit setzt das API-Gateway Authentifizierung, Ratenbegrenzung, Protokollierung und Überwachung durch.
  • Die Continuous Integration blockiert die Bereitstellung einer API, die die Regeln nicht erfüllt.

Die API als Produkt

Eine als Produkt geführte API hat einen benannten Verantwortlichen, eine aktuelle Dokumentation, einen ausdrücklichen Lebenszyklus, bekannte Konsumenten und Nutzungskennzahlen. Ihr Verantwortlicher kann dann über eine neue Version entscheiden und weiß, wen sie betrifft.

Die Rolle des Unternehmensarchitekten

Der Unternehmensarchitekt entwirft nicht jede API. Er legt mit den Teams gemeinsame Prinzipien und Regeln fest, verknüpft APIs mit Geschäftsfähigkeiten und erkennt Doppelungen und Abweichungen zwischen Plattformen.

Eine Ausnahme von einer gemeinsamen Regel wird wie eine Ausnahme von einem Architekturprinzip behandelt: mit Begründung, Umfang, Verantwortlichem und Prüfdatum. Die befugte Instanz entscheidet darüber.

Schnittstellen in ArchiLU

In ArchiLU verbindet eine Anwendungsschnittstelle eine Quellanwendung mit einer Zielanwendung. Sie nennt ihr Protokoll, etwa eine API, die transportierten Daten und ihren Verantwortlichen. Eine Schnittstelle ohne Protokoll wird als unvollständig markiert.

Vor der Änderung oder Stilllegung einer API zeigt die 360-Ansicht der Anwendung ihre Flüsse, ihre Schnittstellen, die Prozesse, denen sie dient, und die Fähigkeiten, die sie realisiert. Im freigegebenen Umfang erfasst der Discovery-Kollektor TCP-Verbindungen zwischen Maschinen; daraus entstehen Vorschläge zur Prüfung.

ArchiLU ersetzt weder das API-Gateway noch die Kontrollen der Pipeline. Es hält die umgebende Architektur und die Architekturentscheidungen fest, die sie betreffen.

Häufige Fragen

Was ist API-Governance in der Unternehmensarchitektur?
Die Regeln, Standards und Kontrollen, die Entwurf, Sicherheit, Bereitstellung und Weiterentwicklung von APIs steuern. Die Unternehmensarchitektur ergänzt die Verbindung jeder API zu den Anwendungen, Prozessen und Fähigkeiten, die von ihr abhängen.
Wann scheitert API-Governance?
Meist dann, wenn sie manuell bleibt, von der Auslieferung getrennt ist und sich auf Freigaben statt auf messbare Ergebnisse konzentriert.
Was ist API-Drift?
Die Anhäufung von Designabweichungen zwischen Teams, bei Benennung, Fehlern, Authentifizierung oder Versionen. Er erschwert Integrationen, erhöht Sicherheitsrisiken und verursacht Nacharbeit.
Was ist der erste konkrete Schritt?
Den API-Katalog aufbauen, mit Verantwortlichem, Lebenszyklus, Konsumenten, Dokumentation und Sicherheitsregeln jeder API.
Wie bleibt die Auslieferung schnell?
Kontrollen in der Continuous Integration automatisieren, Laufzeitregeln im API-Gateway durchsetzen und Routineentscheidungen in klaren Grenzen an die Teams delegieren.