APIs haben sich zum neuen Standard für die Anbindung von Anwendungen, Daten und Geräten sowie für die Bereitstellung von Services für interne Entwickler, Partner und Endkunden herausgebildet. Sie sind die Grundlage für neue Geschäftsmodelle, die Einbindung von Partnern im Rahmen der Plattform-Ökonomie, den Aufbau von Communities zur Stärkung der Kundenbindung und für die Umsetzung regulatorischer Anforderungen, wie beispielsweise die Zahlungsdiensterichtlinie PSD2 für Banken.

Dabei sind APIs nicht wirklich neu, sie werden schon seit Jahren für interne Aufrufe verwendet. Seit einigen Jahren werden diese Programmierschnittstellen zunehmend auch für die externe Nutzung bereitgestellt. Für Unternehmen bedeutet dies eine zusätzliche Komplexität in der eigenen IT. Daher sollten sich IT-Verantwortliche ein paar grundsätzliche Gedanken über den Lebenszyklus einer API machen - und das möglichst früh.

Der API-Lebenszyklus

Der Lebenszyklus von APIs kann grob in 6 Phasen unterteilt werden.

1. Initialisierung
   Zunächst geht es um die Entwicklung von Ideen für zukünftige APIs. Dieser Prozess kann vom Fachbereich oder von der IT angestoßen werden. Es geht um grundlegende Fragestellungen zur Funktionalität, der zu unterstützenden Customer Journey und um die Monetarisierung.
   In dieser Phase muss erörtert werden, ob bereits vorhandene APIs die Anforderungen abdecken können. So lassen sich doppelte Arbeiten und eine unnötig komplexe API-Landschaft vermeiden.

2. Design
   In dieser Phase wird die API definiert und konzipiert. Dazu gehören Abstimmungen mit beteiligten Entwicklern, Business Analysten, Domänen- und Enterprise-Architekten sowie Sicherheitsexperten. Alle Beteiligten müssen Zugang zu den Spezifikationen erhalten und ihre Freigabe erteilen, die dokumentiert wird.

3. Entwicklung und Test
   Im dritten Schritt wird die API entwickelt - entweder durch die Nutzung beziehungsweise Integration eines bestehenden Services oder komplett neu - und durch intensive fachliche und technische Tests geprüft. In dieser Phase wird die API über verschiedene sogenannte Stages (Entwicklung, Test, Pre-Live, Produktion) geführt und schließlich für die Nutzung freigegeben.

4. Publikation
   Die API wird den Nutzern zur Verfügung gestellt, wobei einerseits die Spezifikation (Funktionsumfang, Aufrufparameter, Ergebnis etc.) veröffentlicht und andererseits der Aufruf der API technisch ermöglicht wird. Gleichzeitig werden die anzuwendenden Regeln, Richtlinien und Sicherheitskonzepte aktiviert.

5. Betrieb
   Ist eine API einmal in Betrieb, werden permanent Informationen gesammelt. Dazu gehören das Nutzungs-Monitoring (wer hat die API wann und wie oft aufgerufen) sowie das Performance-Monitoring (Verfügbarkeiten, Antwortzeiten, SLA-Einhaltung). Die gewonnenen Informationen sind eine wichtige Grundlage für die Monetarisierung und die Weiterentwicklung.

6. Stilllegung
   An einem bestimmten Punkt kann es notwendig werden, eine API zurückzuziehen beziehungsweise stillzulegen. Dann müssen alle Konsumenten darüber informiert werden, dass die Schnittstelle nicht mehr verfügbar ist und gegebenenfalls über verfügbare Alternativen in Kenntnis gesetzt werden. Die technische Nutzung der API muss unterbunden werden.

Diese Phasen bilden die Basis eines API-Governance-Prozesses, der mehrere Beteiligte einbindet, zahlreiche Aktivitäten und Maßnahmen erfordert sowie Informationsflüsse und Entscheidungspunkte beinhaltet, die zu einem Fortschritt oder Rückschritt im Prozess führen.

APIs wie Produkte managen

Immer wieder neigen Entwickler und IT-Projektleiter dazu, einfach mal loszulegen. Schließlich ist gerade die Bereitstellung von APIs für externe Nutzer für viele Unternehmen Neuland, weshalb sie erst einmal ausprobieren wollen, wie die Technologie funktioniert und wie die Akzeptanz der Nutzer überhaupt ist. Doch oft zeigt sich in Projekten, dass es mit der zunehmenden Anzahl von APIs und Nutzern schwierig wird, die Kontrolle zu behalten.

Programmierschnittstellen müssen daher von Anfang an wie ein Produkt gemanagt werden. Dafür sind klare Rollen und Verantwortlichkeiten notwendig. Der "API Product Manager" ist für die Entwicklung der API-Strategie und die API-Roadmap verantwortlich. Er entwickelt die notwendigen Governance-Strukturen (insbesondere den API-Governance-Prozess), wählt geeignete Werkzeuge aus und integriert diese mit anderen Werkzeugen im Unternehmen. Zu seinen Aufgaben gehört auch, die schrittweise Entwicklung des API-Ökosystems im Auge zu behalten und das Erreichen der definierten Ziele sicherzustellen.

Erfolgsfaktoren
Es gibt Erfolgsfaktoren, die generell für die Softwareentwicklung gelten, wie beispielsweise Fehlerfreiheit, Sicherheit und Skalierbarkeit. Neben diesen "harten" Faktoren gibt es noch "weiche" Faktoren, die für ein erfolgreiches API Lifecycle Management von Bedeutung sind.

Transparenz
Für die Fach- und die IT-Seite ist es wichtig, einen vollständigen Überblick über vorhandene und geplante APIs zu erhalten. Grafische Abhängigkeitsanalysen stellen eine einfache und zielführende Möglichkeit dar, sich in der Initialisierungs- und Design-Phase umfassend zu informieren. Durch die Nutzung vorhandener Assets kann die Entwicklung beschleunigt und somit kostengünstiger gestaltet werden.

Zudem wird so ein Wildwuchs an APIs vermieden, der nicht nur die eigenen Mitarbeiter, sondern auch die Nutzer verwirrt. Während der Betriebsphase können anhand von Dashboards die wichtigsten Nutzungs-Kennzahlen permanent überwacht und ausgewertet werden.

Konsistenz
Alle Beteiligten müssen auf die gleichen Informationen zugreifen können. Wenn nicht alle Informationen im gleichen Werkzeug dokumentiert sind, muss sichergestellt sein, dass einmal erfasste Informationen automatisiert zu allen anderen Werkzeugen übertragen werden. Auch über die verschiedenen Phasen des API-Lebenszyklus hinweg müssen API-bezogene Informationen konsistent gehalten werden.

Kontrolle
Regeln und Richtlinien bestimmen, wer eine Programmierschnittstelle nutzen darf, was ein Aufruf kostet und legen weitere Eckpunkte fest. Diese Richtlinien sind nicht nur zu dokumentieren und zu publizieren, sondern deren Einhaltung muss technisch umgesetzt werden können.

Dazu ein Beispiel: Ein Unternehmen inkludiert Google Maps in einem seiner Produkte. Der Aufruf der Google Maps-API kann schnell teuer werden, wenn die Aufrufe sehr häufig erfolgen (Preise der Google Maps Plattform). Daher ist es sinnvoll, eine Obergrenze für die Anzahl der Aufrufe in einem bestimmten Zeitraum zu definieren und vom System permanent überwachen zu lassen. Wird die Obergrenze erreicht, werden alle folgenden Aufrufe unterbunden.

Erst planen, dann starten

Die Bereitstellung von APIs für externe Nutzer erfordert deutlich mehr Agilität als die Entwicklung interner Schnittstellen. Daher ist die Versuchung groß, mit einem Schnellstart, nicht den Anschluss an die Konkurrenz zu verlieren. Doch die Häufigkeit von Änderungen, Fehlerkorrekturen, Erweiterungen und auch die Stilllegung von weniger erfolgreichen APIs können sehr schnell dazu führen, dass ohne entsprechende Governance-Strukturen die Kontrolle verloren geht.

Deshalb sollten IT-Verantwortliche gleich zu Beginn von API-Initiativen geeignete Strukturen und Prozesse aufsetzen und unterstützende Werkzeuge auswählen. Dadurch bleiben Architekturen beherrschbar und sie können sich auf APIs konzentrieren, die wiederverwendbar und skalierbar sind. Je früher dies erfolgt, desto eher kann das Unternehmen davon profitieren und desto erfolgreicher wird es seine APIs über den gesamten Lebenszyklus hinweg managen.