Lesezeit: 5 Minuten

API Maturity: Wie reif sind unsere Schnittstellen?

Reifegradmodelle für die Enterprise-Integration als Hebel der Digitalisierung im Unternehmen

In unserem Blogartikel Strategische Bedeutung von APIs erläuterten wir die hohe strategische Bedeutung von Schnittstellen in modernen IT-Organisationen. Offen blieb dabei die Frage, wie wir, ausgehend von diesem Bewusstsein für die Wichtigkeit hochwertiger, langlebiger und nachhaltiger APIs, konkrete Handlungsentscheidungen für unsere eigene API-Landschaft ableiten können. Dieser Frage wollen wir uns nun widmen. 

Dazu müssen wir den Reifegrad unserer APIs bewerten und verstehen, inwieweit die aktuelle Situation von der gewünschten Reife abweicht. So können wir etwaige Lücken zielgerichtet schließen und die digitale Transformation im Unternehmen schneller vorantreiben. Durch ein solches analytisches Vorgehen gelingt es uns, 

• bestehende Defizite besser nachzuvollziehen, 

• zukünftige Probleme vorherzusagen, 

• anfallende Kosten zu bewerten und 

• einen zielorientierten Maßnahmenplan zu erstellen. 

Gerade dieser letzte Punkt sollte nicht unterschätzt werden. Mithilfe eines zielorientierten Maßnahmenplans vermeiden wir die in der IT weit verbreiteten Bad Practice, in einen ebenso sinnfreien wie kostenintensiven blinden Aktionismus zu verfallen, mittels dessen zwar oft zahlreiche umfangreife Änderungen initiiert, aber kaum Verbesserungen erzielt werden. 

Welche Ziele verfolgt eine erfolgreiche API-Strategie?

Bei der Analyse der API-Reife in unserer bestehenden API-Landschaft ist es wichtig, die Ziele im Blick zu behalten, die wir mit unserer API-Strategie verfolgen:

• Verbesserung der Entwicklererfahrung: APIs sind oft das Hauptwerkzeug, mit dem Entwickler auf Funktionen und Daten in einer Organisation zugreifen. Ein hoher Reifegrad bedeutet, dass die API gut dokumentiert, konsistent und einfach zu nutzen ist, was die Produktivität der Entwickler steigert. Entwickler können schneller und effizienter arbeiten, was zu einer schnelleren Markteinführung von Produkten und gleichzeitig zu einer höheren Mitarbeiterzufriedenheit und -motivation führt.
• Verbesserung der Kundenerfahrung: Die Bewertung des Reifegrads hilft dabei, sicherzustellen, dass alle APIs in der Organisation nach den gleichen hohen Standards und einer hochwertigen Qualitätssicherung entwickelt werden. Dies führt zu einer konsistenteren Nutzung von Ressourcen und Prozessen, was die Wartung erleichtert und die Wahrscheinlichkeit von Fehlern verringert.
• Organisatorische Skalierbarkeit: APIs sind ideale Schnittstellen nicht nur zwischen IT-Systemen, sondern auch zwischen den für sie verantwortlichen Teams. APIs ermöglichen daher eine effiziente, serviceorientierte Kommunikation und eine klare Abgrenzung von Verantwortung und Zuständigkeit zwischen Teams. Dadurch können Organisationen ihre Teams und IT-Systeme nahezu beliebig horizontal skalieren, statt an den Grenzen vertikaler Skalierung zu scheitern.
• Systemische Skalierbarkeit: Eine API mit einem hohen Reifegrad ist besser darauf ausgelegt, mit dem Wachstum der Organisation mitzuhalten. Dies bedeutet, dass sie leichter skaliert werden kann, sowohl was die Anzahl der Nutzer als auch die Menge der verarbeiteten Daten betrifft.
• Förderung der Agilität und Reaktionsfähigkeit: Wenn APIs gut entwickelt und flexibel sind, können sie schneller an neue Geschäftsanforderungen angepasst werden und die Organisation kann schneller auf disruptive neue Technologien, Mitbewerber und Trends der Digitalisierung reagieren, sowie mit der stetig voranschreitenden Digitalisierung der Arbeitswelt schritthalten.
• Förderung der Innovationsfähigkeit: Je reifer eine API ist, desto einfacher ist es für Entwickler und Partner, neue Produkte und Dienstleistungen darauf aufzubauen. Dies fördert Innovation innerhalb und außerhalb der Organisation, indem es externe Entwickler und Partner dazu ermutigt, neue Anwendungen und Lösungen zu entwickeln, mithilfe derer es möglich wird, den Vorsprung gegenüber Mitbewerbern auszubauen.
• Förderung der Automatisierbarkeit: Je reifer eine API und das sie umgebende Ökosystem ist, desto einfacher ist es für Entwickler und Partner, bestehende manuelle Prozesse und Prozessschritte zu automatisieren. Dadurch werden Abläufe beschleunigt, Mitarbeiter können ihre Zeit sinnvoller einsetzen und werden dadurch effektiver, das Fehlerpotenzial sinkt und die Nachvollziehbarkeit von Prozessen wird erhöht.
• Steigerung des Geschäftswerts: Je eher es uns gelingt, APIs als primäres und hochwertiges Integrationskonzept für unsere IT-Systeme zu etablieren, desto leichter erschließen wir Chancen auf neue Einnahmequellen und auf Einsparungen durch die Steigerung der Effizienz bestehender Prozesse.
• Kostenkontrolle: Reife APIs sind oft effizienter in Bezug auf Entwicklungs- und Betriebskosten gegenüber weniger reifen APIs und versteckten Integrationskanälen wie geteilten Datenbanken und Netzwerk-Dateisystemen. Sie verursachen weniger Fehler, sind einfacher zu warten und erfordern weniger Nacharbeit. Eine regelmäßige Bewertung hilft, kostspielige technische Schulden zu vermeiden und die Gesamtkosten der API-Entwicklung und -Wartung zu senken.
• Erleichterung der Governance: Durch die Bewertung des Reifegrads können Richtlinien und Standards eingeführt, weiterentwickelt und durchgesetzt werden, die sicherstellen, dass alle APIs den strategischen Zielen der Organisation entsprechen. Dieses Vorgehen unterstützt auch die langfristige Wartbarkeit und Weiterentwicklung der API-Landschaft.
• Optimierung der Betriebsfähigkeit: Reife APIs sind besser überwachbar und eignen sich für den Einsatz robuster Mechanismen zur Fehlerbehandlung und für den Umgang mit Lastspitzen. Die Bewertung des Reifegrads hilft, Schwachstellen zu identifizieren und gezielte Verbesserungen vorzunehmen, was die Zuverlässigkeit und Verfügbarkeit der APIs erhöht.
• Sicherstellung von Compliance und Sicherheit: APIs mit einem höheren Reifegrad sind in der Regel besser in Bezug auf Sicherheitspraktiken und die Einhaltung gesetzlicher Vorgaben gestaltet. Die Bewertung hilft dabei, potenzielle Risiken zu identifizieren und Maßnahmen zu ergreifen, um die Sicherheit und Compliance zu gewährleisten.
   

Was sind API-Reifegradmodelle und wie werden sie angewendet?

Die Anwendung von Reifegrad-Modellen hat sich bei der Bewertung von Ist-Zuständen, der Erstellung von Soll-Ist-Vergleichen und der Ableitung von Handlungsmaßnahmen bewährt. Reifegrad-Modelle ermöglichen einerseits einen Rückgriff auf existierende Erfahrungsschätze und Learnings, und andererseits auch eine organisationsübergreifende Vergleichbarkeit. Dadurch wird es leichter, geeignete, bewährte und begründbare Maßnahmen zur Erreichung der Ziele auszuwählen. So existieret beispielsweise auch eine Methodik zur Bewertung des Cloud-native Reifegrads von Organisationen, die sogenannte Cloud-Native Maturity Matrix.

Daher ist es hilfreich, dass auch für APIs Reifegrad-Modelle existieren. Im Rahmen unserer Betrachtung gliedern wir diese Modelle in drei Ebenen: 

1. API Strategy Maturity Models: Reifegrad-Modelle auf API-strategischer Ebene 

2. API Platform Maturity Models: Reifegrad-Modelle auf API-Plattform-Ebene 

3. API Maturity Models: Reifegrad-Modelle auf Ebene individueller APIs 

Reifegrad-Modelle auf strategischer Ebene

Ausschlaggebend dafür, eine insgesamt hohe Reife der API-Landschaft erzielen zu können, ist die Reife der API-Strategie, die damit einen elementaren Bestandteil der Digitalisierungsstrategie der Organisation ausmacht. Umgekehrt stellt ein niedriger Reifegrad der API-Strategie ein Hindernis der Entwicklung der Digitalisierung im Unternehmen dar. Deshalb ist es naheliegend, zunächst die Reife der API-Strategie zu untersuchen. Wir bewerten dabei die folgenden Dimensionen: 

• Investitionskonzept 

• Integrationskonzept 

• Teams und Verantwortung 

• API-Ökonomie 

Dabei ist es in der Regel möglich, in jeder dieser Dimensionen der API-Strategie unserer Organisation einen Reifegrad zwischen 0 (provisorisch), 1 (funktional), 2 (skalierbar) und 3 (optimiert) zuzuordnen. Am Beispiel der Dimension der API-Ökonomie: 

0. Stufe 0 würde bedeuten, dass, wenn überhaupt, nur eine Dokumentation von APIs auf individueller Ebene existiert, die deren jeweilige Nutzung skizziert und Verantwortliche benennt. 

1. Stufe 1 setzt voraus, dass nicht nur diese individuelle Dokumentation existiert, sondern auch eine übergeordnete, durchsuchbare und navigierbare Sammlung der verfügbaren APIs unserer Organisation existiert. 

2. Um Stufe 2 zu erreichen, setzen wir eine Erweiterung des API-Katalogs hin zu einem API-Marktplatz voraus, der Konsumenten und APIs zusammenbringt und ihre Dienstleistungsbeziehungen abbildet und unterstützt. 

3. In der höchsten Stufe öffnet sich unser API-Marktplatz für unsere Partner und Kunden, sodass auch diese ihre eigenen APIs einbringen und sie sich und uns gegenseitig zur Verfügung stellen können. 
    

Reifegrad-Modelle auf Plattform-Ebene

Die Bewertung auf Plattform-Ebene vertieft und konkretisiert die Bewertung gegenüber der Bewertung auf strategischer Ebene. Wir empfehlen hier eine Betrachtung der Reife in den folgenden Dimensionen: 

• Governance 

• Sicherheit 

• Prozesse 

• Entwickler-Erfahrung 

• Konsumenten-Erfahrung 

• Beobachtbarkeit 

Auch bei der Bewertung der API-Plattform unserer Organisation streben wir eine Einordnung anhand der Reifegrade zwischen 0 (provisorisch), 1 (funktional), 2 (skalierbar) und 3 (optimiert) an. Am Beispiel der Dimension der Governance:  

• Stufe 0 in würde bedeuten, dass keine oder zumindest keine ausreichenden Regeln, Standards und Good-Practices in der Organisation etabliert sind für die Erstellung und das Management von APIs. 

• Stufe 1 könnte erreicht werden durch die Einführung einer API-Guideline, die beispielsweise REST als gesetzte API-Technologie festlegt und Regeln für den Einsatz von REST-APIs vorgibt. 

• Sollen jedoch höhere Stufen erreicht werden (sowohl in der Dimension Governance als auch in der Dimension Entwickler-Erfahrung), müsste das Regelwerk jedoch auch die Use-Case-orientierte Auswahl geeigneter anderer Technologien ermöglichen und auch für diese entsprechende Regeln, Standards und Good-Practices definieren. Das Provider-Team muss beispielsweise befähigt werden, auch APIs zu entwerfen, die vorwiegend solche Use-Cases abbilden müssen, die mit asynchroner Kommunikation einfacher und hochwertiger umsetzbar sind. Für diese Art von APIs ist das REST-Paradigma, das auf dem synchronen HTTP-Protokoll aufsetzt, weniger gut geeignet ist. 
   

Reifegrad-Modelle auf Ebene individueller APIs

Für individuelle APIs existieren je nach Technologie unterschiedliche API-Maturity-Modelle. Ein bekanntes Beispiel ist das Richardson Maturity Model.
Für individuelle APIs existieren je nach Technologie unterschiedliche API-Maturity-Modelle, da es ebenso wichtig ist, den für die jeweilige Technologie geeignete Bewertungsansatz anzuwenden, wie es wichtig ist, die geeignete API-Technologie für den Use-Case, den die API bedient, zu wählen. 

Richardson Maturity Model 

Viele APIs setzen auf den HTTP-Standard auf und eines der häufigsten Paradigmen für den Entwurf von HTTP-APIs ist REST, dessen Grundprinzip es ist, die Funktionen des HTTP-Protokolls möglichst in der im Standard vorgesehenen Semantik zu verwenden. Abbildung 1 zeigt das bekannteste API-Reifegradmodell, das Richardson Maturity Model für REST-APIs. Es grenzt REST-APIs einerseits von SOAP-artigen APIs (Reifegrad 0) ab und priorisiert darüber hinaus die Wichtigkeit verschiedener Aspekte von REST. 

0. REST API Maturity Level 0: Reifegrad 0 beschreibt nicht dem REST-Paradigma entsprechende APIs wie etwa SOAP-APIs, die auch namensgebend sind für den „Swap of POX“ (Plain Old XML), da sie üblicherweise XML-basierte Nachrichten verwenden. Reifegrad 0 beschränkt sich jedoch nicht auf XML-basierte APIs, sondern umfasst alle HTTP-APIs, die nicht ausreichend dem REST-Paradigma folgen, um den Bedingungen für einen höheren Reifegrad zu genügen. 

1. REST API Maturity Level 1: Reifegrad 1 setzt voraus, dass die Dinge, die im Fokus der Kommunikation mit der API stehen, die also beispielsweise gelesen oder manipuliert werden, in fachlich sinnvolle URL-Ressourcen zusammengefasst bzw. dadurch voneinander abgegrenzt, gegebenenfalls hierarchisch gegliedert und eindeutig adressiert werden. 

2. REST API Maturity Level 2: Reifegrad 2 erfordert den semantisch korrekten Einsatz der HTTP-Verben zur Durchführung von Aktionen auf Ressourcen. Die gängigsten HTTP-Verben sind dabei: 

Selbstverständlich dürfen auch weitere HTTP-Verben eingesetzt werden, vorausgesetzt, ihr Einsatz ist konform mit der vom HTTP-Standard für sie vorgesehenen Semantik. 

3. REST API Maturity Level 3: Reifegrad 3 erfordert die Umsetzung des HATEOAS-Prinzips (Hypermedia As The Engine Of Application State). Dieses verlangt, dass ein Service zusammen mit seiner Antwort auf eine Anfrage weiterführende Verweise mitgibt, beispielsweise die URL zu einer soeben neu angelegten Ressource oder die Verweise auf die nächste oder vorhergehende Seite beim Abruf einer Seite einer paginierten Listenressource. 

Weitere technologiespezifische Reifegradmodelle

Auch für weitere synchrone API-Technologien wie GraphQL oder SOAP, aber auch für asynchrone API-Technologien wie Kafka oder RabbitMQ gibt es Ansätze zur Bewertung des Reifegrads. Bewertungskriterien sind hierbei 

ähnlich wie beim Richardson Maturity Model Aspekte wie 

• Standardkonformität 
• Ausnutzung der semantischen Möglichkeiten und Funktionen der Technologie, 
• sowie Governance-Integration, 

aber auch technologiespezifische Schwerpunkte wie beispielsweise 

• Schema-Design und Abfragekomplexität bei GraphQL oder 
• Zuverlässigkeits-, Konsistenz-, Fehlerbehandlungs- und Orchestrierungkonzepte bei asynchronen APIs. 

Fazit

Mithilfe von Reifegrad-Modellen ist eine systematische Analyse der Reifegrade unserer API-Strategie, unserer API-Prozesse und API-Plattform, sowie unserer APIs selbst möglich. Darüber hinaus ermöglichen sie uns, einen Soll-Ist-Abgleich durchzuführen und Verbesserungspotenzial aufzuzeigen. Dabei ist es wichtig, unsere Ziele nicht aus den Augen zu verlieren. Nicht immer ist es erforderlich (oder überhaupt sinnvoll) direkt den höchsten Reifegrad anzustreben: beispielsweise setzen nur wenige REST-APIs HATEOAS flächendeckend ein, weil der Mehrwert oft nicht den Aufwand rechtfertigt. Aber erst mithilfe einer stichhaltigen Methodik ist eine Kosten-Nutzen-Abwägung möglich. 

Gerne möchten wir an dieser Stelle auf unseren Fragenkatalog verweisen, mit dem Sie selbst eine erste Reifegrad-Einschätzung der API-Landschaft Ihrer Organisation vornehmen können.