Kontinuierliches API-Management, 2. Auflage

Kapitel 1. Die Herausforderung und das Versprechendes API-Managements

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Management ist vor allem eine Praxis, in der sich Kunst, Wissenschaft und Handwerk treffen.

Henry Mintzberg

Laut einem IDC-Bericht aus dem Jahr 2019 erwarten 75 % der befragten Unternehmen, dass sie in den nächsten zehn Jahren "digital transformiert" werden und dass 90 % aller neuen Apps eine Microservice-Architektur mit APIs nutzen werden.¹ Es wurde auch festgestellt, dass bei API-fokussierten Unternehmen bis zu 30 % des Umsatzes über digitale Kanäle generiert wird. Gleichzeitig nannten diese Unternehmen die Haupthindernisse für die Einführung von APIs: "Komplexität", "Sicherheit" und "Governance".

Dies war eine der wichtigsten Erkenntnisse: "Die Definition der richtigen App-Architektur erfordert ein tiefes Verständnis der Herausforderungen, die mit der Steuerung, Verwaltung und Orchestrierung dieser grundlegenden Technologiekomponenten verbunden sind."² Diese Studie, wie auch die von Coleman Parkes, die wir in der ersten Ausgabe dieses Buches zitiert haben, enthält eine Mischung aus Ermutigung und Warnung.

Ein interessanter Trend, den wir in den letzten Jahren beobachten konnten, ist die wachsende Kluft zwischen den "API-Habenden" und den "API-Nichthabenden". Auf die Frage "Verfügt Ihr Unternehmen über eine API-Verwaltungsplattform? antworteten 72% der Medien- und Dienstleistungsunternehmen mit "Ja", während nur 46% der Unternehmen im verarbeitenden Gewerbe diese Frage bejahten.³ Alles deutet darauf hin, dass APIs auch in Zukunft das Geschäftswachstum ankurbeln werden, und es ist unerlässlich, dass Unternehmen aus allen Bereichen der Wirtschaft die Herausforderung der digitalen Transformation annehmen.

Die gute Nachricht ist, dass es da draußen viele Unternehmen gibt, die ihre API-Programme erfolgreich verwalten. Die weniger gute Nachricht ist, dass ihre Erfahrung und ihr Fachwissen nicht leicht zu teilen oder allgemein verfügbar sind. Hierfür gibt es mehrere Gründe. Meistens sind die Unternehmen, die ihre API-Programme gut verwalten, einfach zu beschäftigt, um ihre Erfahrungen mit anderen zu teilen. In einigen Fällen haben wir mit Unternehmen gesprochen, die sehr vorsichtig damit sind, wie viel von ihrem API-Management-Know-how sie mit der Außenwelt teilen; sie sind davon überzeugt, dass API-Kenntnisse ein Wettbewerbsvorteil sind, und geben ihre Erkenntnisse nur langsam preis. Und selbst wenn Unternehmen ihre Erfahrungen auf öffentlichen Konferenzen, in Artikeln und Blogbeiträgen teilen, sind die Informationen, die sie weitergeben, meist unternehmensspezifisch und lassen sich nur schwer auf die API-Programme anderer Unternehmen übertragen.

Dieses Buch ist ein Versuch, dieses letzte Problem anzugehen - unternehmensspezifische Beispiele in gemeinsame Erfahrungen zu übersetzen, die alle Organisationen nutzen können. Zu diesem Zweck haben wir Dutzende von Unternehmen besucht, viele API-Technologen interviewt und versucht, die Gemeinsamkeiten zwischen den Beispielen zu finden, die die Unternehmen mit uns und der Öffentlichkeit geteilt haben. Es gibt eine kleine Handvoll Themen, die sich durch das Buch ziehen und die wir hier in diesem Einführungskapitel vorstellen wollen.

Eine der wichtigsten Herausforderungen, die gleich zu Beginn erkennen muss, ist die Klärung der Frage, was genau gemeint ist, wenn von APIs gesprochen wird. Erstens kann der Begriff API nur die Schnittstelle bezeichnen (z. B. eine HTTP-Anfrage-URL und eine JSON-Antwort). Er kann sich auch auf den Code und die Bereitstellungselemente beziehen, die benötigt werden, um einen zugänglichen Dienst in Produktion zu bringen (z. B. die customerOnBoarding API). Schließlich verwenden wir den Begriff API manchmal, um eine einzelne Instanz einer laufenden API zu bezeichnen (z. B. die customerOnBoarding API, die in der AWS-Cloud läuft, im Gegensatz zur customerOnBoarding API, die in der Azure-Cloud läuft).

Eine weitere wichtige Herausforderung bei der Verwaltung von APIs ist der Unterschied zwischen dem Entwerfen, Erstellen und Freigeben einer einzelnen API und der Unterstützung und Verwaltung vieler APIs - waswir eine API-Landschaft nennen. Wir werden in diesem Buch viel Zeit auf beide Enden dieses Spektrums verwenden. Konzepte wie API als Produkt (AaaP) und die Fähigkeiten, die für die Erstellung und Pflege von APIs benötigt werden (wir nennen sie API-Säulen), sind Beispiele für den Umgang mit den Herausforderungen einer einzelnen API. Wir werden auch über die Rolle von API-Reifegradmodellen und den Umgang mit Veränderungen im Laufe der Zeit als wichtige Aspekte der Verwaltung einer API sprechen.

Das andere Ende des Spektrums ist die Arbeit der Verwaltung der API-Landschaft. Deine Landschaft ist die Sammlung von APIs aus allen Geschäftsbereichen, die auf allen Plattformen laufen und von allen API-Teams deines Unternehmens verwaltet werden. Die Herausforderungen dieser Landschaft sind vielfältig: Umfang und Reichweite verändern die Art und Weise, wie APIs entworfen und implementiert werden, und große Ökosysteme können allein aufgrund ihrer Größe für zusätzliche Unbeständigkeit und Anfälligkeit sorgen.

Schließlich gehen wir auf den Prozess der Entscheidungsfindung bei der Verwaltung deines API-Ökosystems ein. Unserer Erfahrung nach ist dies der Schlüssel zu einem erfolgreichen Governance-Plan für deine API-Programme. Es zeigt sich, dass sich die Art und Weise, wie du Entscheidungen triffst, zusammen mit deiner Landschaft verändern muss. Das Festhalten an alten Governance-Modellen kann den Erfolg deines API-Programms einschränken und sogar mehr Risiken für deine bestehenden APIs mit sich bringen.

Bevor wir in die Details gehen, wie du lernen kannst, mit beiden Herausforderungen - deinen einzelnen APIs und deiner API-Landschaft - umzugehen, lass uns einen Blick auf zwei wichtige Fragen werfen: Was ist API-Management, und warum ist es so schwierig?

Was ist API-Management?

Wie bereits erwähnt, geht es bei der API-Verwaltung nicht nur darum, den Entwurf, die Implementierung und die Freigabe von APIs zu regeln. Es umfasst auch die Verwaltung eines API-Ökosystems, die Verteilung von Entscheidungen innerhalb deiner Organisation und sogar den Prozess der Migration bestehender APIs in deine wachsende API-Landschaft. In diesem Abschnitt werden wir uns mit jedem dieser Konzepte befassen, aber zunächst ist es wichtig, über den eigentlichen Grund für APIs zu sprechen: das Geschäft mit APIs.

Das Geschäft mit APIs

Abgesehen von den Details der Erstellung und Verwaltung von APIs ist es wichtig, sich vor Augen zu halten, dass all diese Arbeit dazu dient, die Unternehmensziele zu unterstützen. APIs sind mehr als nur die technischen Details von JSON oder XML, synchron oder asynchron, etc. Sie sind eine Möglichkeit, die Geschäftsbereiche miteinander zu verbinden, um wichtige Funktionen und Wissen auf eine Weise zugänglich zu machen, die dem Unternehmen hilft, effektiv zu sein. APIs sind oft ein Weg, um Werte zu erschließen, die bereits im Unternehmen vorhanden sind, z. B. durch die Entwicklung neuer Anwendungen, die Erschließung neuer Einnahmequellen und die Anbahnung neuer Geschäfte.

Diese Art des Denkens konzentriert sich mehr auf die Bedürfnisse der API-Kunden als auf die derjenigen, die die APIs erstellen und veröffentlichen. Dieser verbraucherzentrierte Ansatz wird gemeinhin als "Aufträge to Be Done" oder JTBD bezeichnet. Er wurde von Clayton Christensen von der Harvard Business School eingeführt, der sich in seinen Büchern The Innovator's Dilemma und The Innovator's Solution (Harvard Business Review Press) eingehend mit diesem Ansatz beschäftigt. Für den Start und die Verwaltung eines erfolgreichen API-Programms dient es als klare Erinnerung daran, dass APIs dazu da sind, Geschäftsprobleme zu lösen. Unserer Erfahrung nach behandeln Unternehmen, die APIs gut auf Geschäftsprobleme anwenden können, ihre APIs als Produkte, die dazu dienen, "eine Aufgabe zu erledigen", in demselben Sinne, wie Christensens JTBD-Framework Verbraucherprobleme löst.

Zugang zu Daten

Eine Möglichkeit, wie APIs zum Unternehmen beitragen können, ist der einfache Zugang zu wichtigen Kunden- oder Marktdaten, die mit aufkommenden Trends oder einzigartigen Verhaltensweisen in neuen Kundensegmenten in Verbindung gebracht werden können. Indem diese Daten sicher und einfach verfügbar gemacht werden (richtig anonymisiert und gefiltert), können APIs dein Unternehmen in die Lage versetzen, neue Chancen zu entdecken, neue Produkte/Dienstleistungen zu realisieren oder sogar neue Initiativen zu geringeren Kosten und schnellerer Markteinführung zu starten.

Zugang zu Produkten

Eine weitere Möglichkeit, wie ein API-Programm dem Unternehmen helfen kann, ist die Schaffung einer flexiblen Reihe von "Werkzeugen" (den APIs), um neue Lösungen zu entwickeln, ohne hohe Kosten zu verursachen. Wenn du zum Beispiel über eine OnlineSales API verfügst, die es wichtigen Partnern ermöglicht, ihre Verkaufsaktivitäten zu verwalten und zu verfolgen, und über eine MarketingPromotions API, die es dem Marketingteam ermöglicht, Produktwerbekampagnen zu entwerfen und zu verfolgen, hast du die Möglichkeit, eine neue Partnerlösung zu erstellen: die SalesAndPromotions Tracking-Anwendung.

Zugang zur Innovation

Unserer Erfahrung nach haben viele Unternehmen interne Prozesse, Praktiken und Produktionsabläufe, die zwar effektiv, aber wenig effizient sind. Einige davon gibt es schon eine ganze Weile (in manchen Fällen Jahrzehnte), und wir haben sogar Fälle erlebt, in denen sich niemand mehr daran erinnern kann, wann (oder warum) das Unternehmen einen bestimmten Prozess eingeführt hat. Bestehende Prozesse zu ändern ist nicht einfach. Es kann auch kostspielig sein. Durch den Aufbau einer API-Infrastruktur in deinem Unternehmen kannst du die Kreativität innerhalb deines Unternehmens freisetzen und in einigen Fällen Gatekeeping-Mechanismen umgehen und Verbesserungen und Effizienzsteigerungen innerhalb deines Unternehmens ermöglichen.

Wir behandeln diese wichtigen Aspekte von AaaP in Kapitel 3. Doch zunächst wollen wir kurz erklären, was wir unter dem Begriff API verstehen.

Was ist eine API?

Manchmal, wenn Leute den Begriff API verwenden, sprechen sie nicht nur über die Schnittstelle, sondern auch über die Funktionalität - den Code hinter der Schnittstelle. Zum Beispiel könnte jemand sagen: "Wir müssen die aktualisierte Kunden-API bald veröffentlichen, damit andere Teams die neue Suchfunktion nutzen können, die wir implementiert haben." Manchmal wird der Begriff aber auch nur für die Details der Schnittstelle selbst verwendet. Jemand in deinem Team könnte zum Beispiel sagen: "Ich möchte eine neue JSON-API für die bestehenden SOAP-Dienste entwerfen, die unseren Workflow beim Kundeneinstieg unterstützen." Beides ist natürlich richtig und es scheint ziemlich klar zu sein, was in beiden Fällen gemeint ist, aber es kann manchmal verwirrend sein.

Um die Unterscheidung zu verdeutlichen und es uns einfacher zu machen, sowohl über die Schnittstelle als auch über die Funktionalität zu sprechen, werden wir einige zusätzliche Begriffe einführen: Schnittstelle, Implementierung und Instanz.

Schnittstelle, Implementierung und Instanz

Das Akronym API steht für Application Programming Interface. Wir verwenden Schnittstellen, um Zugang zu etwas zu erhalten, das "hinter" der API läuft. Du könntest zum Beispiel eine API haben, die Aufgaben zur Verwaltung von Benutzerkonten bereitstellt. Diese Schnittstelle könnte es Entwicklern ermöglichen:

• Eröffne ein neues Konto.

• Ein bestehendes Kontoprofil bearbeiten.

• Den Status eines Kontos ändern (aussetzen oder aktivieren).

Diese Schnittstelle wird in der Regel über gemeinsame Protokolle wie HTTP, Message Queuing Telemetry Transport (MQTT), Thrift, Transfer Control Protocol/Internet Protocol (TCP/IP) usw. ausgedrückt und basiert auf standardisierten Formaten wie JSON, XML, YAML oder HTML.

Aber das ist nur die Schnittstelle. Um die geforderten Aufgaben zu erfüllen, braucht es noch etwas anderes. Dieses Etwas nennen wir im Folgenden die Implementierung. Die Implementierung ist der Teil, der die eigentliche Funktionalität bereitstellt. Oft wird diese Implementierung in einer Programmiersprache wie Java, C#, Ruby, Python oder einer anderen Sprache geschrieben. Um beim Beispiel des Benutzerkontos zu bleiben: Eine Implementierung von User​Man⁠age⁠ment könnte die Möglichkeit bieten, Benutzer zu erstellen, hinzuzufügen, zu bearbeiten und zu entfernen. Diese Funktionen könnten dann über diebereits erwähnte Schnittstelle zugänglich gemacht werden.

Entkopplung der Schnittstelle von der Implementierung

Beachte, dass die Funktionalität der beschriebenen Implementierung aus einer einfachen Reihe von Aktionen besteht, die das CRUD-Muster (Create, Read, Update, Delete) verwenden, während die von uns beschriebene Schnittstelle drei Aktionen hat (OnboardAccount, EditAccount und ChangeAccountStatus). Diese scheinbare "Diskrepanz" zwischen der Implementierung und der Schnittstelle ist üblich und kann sehr nützlich sein: Sie entkoppelt die genaue Implementierung jedes Dienstes von der Schnittstelle, die für den Zugriff auf diesen Dienst verwendet wird.

Der dritte Begriff in unserer Liste ist Instanz. Eine API-Instanz ist eine Kombination aus der Schnittstelle und der Implementierung. Dies ist ein praktischer Weg, um über die tatsächlich laufende API zu sprechen, die für die Produktion freigegeben wurde. Wir verwalten Instanzen mithilfe von Metriken, um sicherzustellen, dass sie in Ordnung sind. Wir registrieren und dokumentieren die Instanzen, damit Entwickler die API leicht finden und für die Lösung realer Probleme nutzen können. Und wir sichern die Instanzen, um sicherzustellen, dass nur autorisierte Nutzer die Aktionen ausführen und die Daten lesen/schreiben können, die für diese Aktionen erforderlich sind.

Abbildung 1-1 verdeutlicht die Beziehung zwischen den drei Elementen. Wenn wir in diesem Buch API schreiben, meinen wir oft die Instanz der API: eine voll funktionsfähige Kombination aus Schnittstelle und Implementierung. In Fällen, in denen wir nur die Schnittstelle oder nur die Implementierung hervorheben wollen, werden wir das im Text erwähnen.

Abbildung 1-1. Drei API-Elemente

API-Stile

Ein weiteres wichtiges Element von APIs ist der so genannte Stil. Wie Stile in anderen Bereichen (Malerei, Dekoration, Mode und Architektur) sind auch API-Stile kohärente, identifizierbare Ansätze zur Erstellung und Nutzung von APIs. Es ist wichtig zu wissen, welchen API-Stil deine Kundenanwendungen nutzen wollen, und bei der Erstellung deiner API-Implementierungen eine einheitliche Umsetzung dieses Stils vorzusehen.

Der häufigste API-Stil ist heute der REST- oder RESTful-API-Stil. Aber das ist nur eine Möglichkeit. Tatsächlich beobachten wir in großen und kleinen Organisationen einen immer stärkeren Trend zur Verwendung von Nicht-REST- und Nicht-HTTP-APIs. Der Aufstieg der ereignisgesteuerten Architektur (EDA) ist ein Beispiel für diese neue Realität im API-Management.

Hinweis

Es gibt zwar viele Stile mit jeweils eigenen Namen, aber nach unserer Erfahrung gibt es fünf allgemeine Stile, die du bei der Verwaltung deines API-Programms beachten solltest. In Kapitel 6 gehen wir auf die Bedeutung der API-Stile ein und besprechen jeden einzelnen von ihnen.

Es ist selten, dass ein Unternehmen mit nur einem API-Stil im gesamten Unternehmen auskommt. Und es ist unwahrscheinlich, dass ein einziger Stil, den du einführst, für immer Bestand haben wird. Die Berücksichtigung des Stils bei der Gestaltung, Implementierung und Verwaltung deines API-Ökosystems ist ein entscheidendes Element für den Erfolg und die Stabilität deines API-Programms.

Diese vielgestaltige API-Realität führt zu einem weiteren wichtigen Aspekt erfolgreicher API-Verwaltungsprogramme: die Fähigkeit, viele APIs auf kohärente und konsistente Weise zu verwalten.

Mehr als nur die API

Die API selbst - die technischen Details der Schnittstelle und der Implementierung - ist nur ein Teil der Geschichte. Die traditionellen Elemente von Design-Build-Deploy sind natürlich entscheidend für die Lebensdauer deiner APIs. Aber APIs zu verwalten bedeutet auch, sie zu testen, zu dokumentieren und in einem Portal zu veröffentlichen, damit die richtige Zielgruppe (interne Entwickler, Partner, anonyme App-Entwickler von Drittanbietern usw.) sie finden und lernen kann, wie man sie richtig nutzt. Außerdem musst du deine APIs sichern, sie während der Laufzeit überwachen und sie über ihre gesamte Lebensdauer hinweg pflegen (einschließlich der Bearbeitung von Änderungen). All diese zusätzlichen Elemente einer API nennen wir API-Säulen: Elemente, die alle APIs brauchen und mit denen sich alle API-Programmmanager befassen müssen. In Kapitel 4 gehen wir auf die Pfeiler ein und stellen die zehn wichtigsten Praktiken vor, die für die Erstellung und Pflege gesunder APIs unerlässlich sind.

Das Gute an diesen Praxisbereichen ist, dass sie über eine einzelne API hinausgehen. Die Fähigkeit, APIs gut zu dokumentieren, kann zum Beispiel von einem API-Team auf das nächste übertragen werden. Das Gleiche gilt für das Erlernen von Testfähigkeiten, Sicherheitsmustern und so weiter. Das bedeutet auch, dass du, selbst wenn du getrennte Teams für jeden API-Bereich hast (Vertriebsteam, Produktteam, Back-Office-Team usw.), auch "übergreifende" Interessen hast, die die Menschen in den Teams mit denen in anderen Teams verbinden.⁴

Ein weiterer wichtiger Aspekt der Verwaltung von APIs ist die Befähigung und das Engineering der Teams, die sie erstellen. In Kapitel 8 erfahren wir mehr darüber, wie dies in verschiedenen Organisationen funktioniert.

API-Reifegrad-Stufen

Die API-Säulen zu verstehen, ist nicht das ganze Bild. Jede API in deinem Programm durchläuft ihren eigenen "Lebenszyklus" - eine Reihe von vorhersehbaren und nützlichen Phasen. Wenn du weißt, wo du dich auf der API-Reise befindest, kannst du bestimmen, wie viel Zeit und Ressourcen du im Moment in die API investieren willst. Wenn du verstehst, wie APIs reifen, kannst du die gleichen Phasen für eine breite Palette von APIs erkennen und dich auf die unterschiedlichen Anforderungen an Zeit und Energie in jeder Phase vorbereiten und reagieren.

Oberflächlich betrachtet macht es Sinn zu denken, dass alle API-Säulen bei der Entwicklung, Erstellung und Freigabe deiner APIs berücksichtigt werden müssen. Aber die Realität sieht anders aus. Bei APIs in der Anfangsphase ist es oft am wichtigsten, sich auf den Entwurf und die Erstellung zu konzentrieren und den Aufwand für die Dokumentation zu reduzieren. In anderen Stadien (z. B. wenn ein Prototyp in den Händen von Betatestern ist) ist es wichtiger, mehr Zeit in die Überwachung der Nutzung der API und ihre Absicherung gegen Missbrauch zu investieren. Wenn du die Reifegrade verstehst, kannst du entscheiden, wie du deine begrenzten Ressourcen am effektivsten einsetzt. Wir werden dich in Kapitel 7 durch diesen Prozess führen.

Mehr als nur eine API

Wie viele Leserinnen und Leser von vielleicht schon wissen, ändern sich die Dinge, wenn du anfängst, eine Menge APIs zu verwalten. Wir haben Kunden mit Tausenden von APIs, die sie im Laufe der Zeit erstellen, überwachen und verwalten müssen. In dieser Situation konzentrierst du dich weniger auf die Details, wie eine einzelne API implementiert wird, sondern mehr auf die Details, wie diese APIs in einem ständig wachsenden, dynamischen Ökosystem nebeneinander bestehen. Wie bereits erwähnt, nennen wir dieses Ökosystem die API-Landschaft, und wir widmen diesem Konzept in der zweiten Hälfte des Buches mehrere Kapitel.

Die Herausforderung besteht darin, ein gewisses Maß an Konsistenz zu gewährleisten, ohne dass es zu Engpässen und Verlangsamungen aufgrund einer zentralen Verwaltung und Überprüfung aller API-Details kommt. Dies wird in der Regel dadurch erreicht, dass die Verantwortung für diese Details auf die einzelnen API-Teams übertragen wird und sich die zentrale Verwaltung darauf konzentriert, die Art und Weise, wie APIs miteinander interagieren, zu normalisieren, sicherzustellen, dass ein Kernbestand an gemeinsam genutzten Diensten oder Infrastrukturen (Sicherheit, Überwachung usw.) vorhanden und für alle API-Teams verfügbar ist, und generell die autonomeren Teams anzuleiten und zu unterstützen. Das bedeutet, dass es oft notwendig ist, von dem üblichen zentralisierten Befehls- und Kontrollmodell abzuweichen.

Eine der Herausforderungen, wenn es darum geht, die Entscheidungsfindung und die Autonomie tiefer in der Organisation zu verankern, besteht darin, dass die höheren Stellen im Unternehmen leicht den Überblick über wichtige Aktivitäten auf Teamebene verlieren können. Während ein Team in der Vergangenheit vielleicht um Erlaubnis bitten musste, um eine Maßnahme zu ergreifen, ermutigen Unternehmen, die den einzelnen Teams mehr Autonomie gewähren, sie dazu, zu handeln, ohne auf die Überprüfung und Erlaubnis der höheren Ebene zu warten.

Die meisten Herausforderungen bei der Verwaltung einer API-Landschaft haben mit der Größe und dem Umfang zu tun. Wenn dein API-Programm wächst, wird es nicht nur größer, sondern ändert auch seine Form. Und das werden wir als Nächstes besprechen.

Warum ist API-Management so schwierig?

Wie zu Beginn dieses Kapitels erwähnt hat, haben zwar die meisten Unternehmen bereits ein API-Programm eingeführt, aber einige Wirtschaftszweige sind mit ihren APIs weiter fortgeschritten als andere. Was ist hier los? Woran liegt es, dass einige Unternehmen besser darin sind als andere? Was sind die gemeinsamen Herausforderungen und wie kannst du deinem Unternehmen helfen, sie zu überwinden?

Wenn wir mit Unternehmen auf der ganzen Welt über das API-Lebenszyklusmanagement sprechen, kristallisieren sich ein paar grundlegende Themen heraus:

Umfang

Worauf sollten zentrale Softwarearchitektur-Teams achten, wenn sie APIs im Laufe der Zeit verwalten?

Skala

Was am Anfang der API-Reise eines Unternehmens funktioniert, lässt sich oft nicht skalieren, wenn das Programm von ein paar kleinen Teams zu einer globalen Initiative wächst.

Normen

Mit zunehmender Programmreife müssen sich die Bemühungen von Management und Governance von detaillierten Ratschlägen zu API-Design und -Implementierung auf eine allgemeinere Standardisierung der API-Landschaft verlagern, damit die Teams mehr eigene Entscheidungen auf detaillierter Ebene treffen können.

Im Wesentlichen ist es das Gleichgewicht dieser drei Elemente - Umfang, Größe und Standards -, das ein gesundes, wachsendes API-Management-Programm ausmacht. Aus diesem Grund lohnt es sich, diese Elemente etwas genauer zu betrachten.

Umfang

Eine der großen Herausforderungen beim Betrieb eines gesunden API-Verwaltungsprogramms ist es, das richtige Maß an zentraler Kontrolle zu erreichen und, was die Sache noch schwieriger macht, das richtige Maß an Veränderungen, wenn das Programm reift.

In der Anfangsphase des Programms ist es sinnvoll, sich direkt auf die Details des API-Designs zu konzentrieren. In Fällen, in denen APIs noch in den Kinderschuhen stecken, können diese Designdetails direkt von dem Team kommen, das die API erstellt - sie schauen sich bestehende Programme "in freier Wildbahn" an, nehmen Werkzeuge und Bibliotheken an, die für die Art von API, die sie erstellen wollen, sinnvoll sind, und machen sich daran, diese API zu implementieren.

Gerade in dieser "ersten Phase" im Leben der APIs in deinem Unternehmen können detaillierte Empfehlungen und klare Rollen zu einem frühen Erfolg führen. In den Kapiteln 3 und 4 sind viele Materialien aufgeführt, die wir für Unternehmen hilfreich finden, die gerade erst mit ihrer API-Reise beginnen.

In diesem "frühen Stadium" des API-Programms ist alles neu; alle Probleme werden zum ersten Mal aufgetreten (und gelöst). Diese ersten Erfahrungen werden oft in den "bewährten Methoden" des Unternehmens oder in den Unternehmensrichtlinien usw. festgehalten. Für ein kleines Team, das zum ersten Mal an ein paar APIs arbeitet, sind sie durchaus sinnvoll. Diese ersten Richtlinien können sich jedoch als unvollständig erweisen.

Je mehr Teams in einem Unternehmen an APIs arbeiten, desto größer ist die Vielfalt an Stilen, Erfahrungen und Ansichten. Es wird immer schwieriger, die Einheitlichkeit in allen Teams zu wahren - und das nicht nur, weil einige Teams sich nicht an die veröffentlichten Unternehmensrichtlinien halten. Es kann sein, dass ein neues Team mit anderen Standardprodukten arbeitet, so dass es nicht in der Lage ist, die ursprünglichen Richtlinien zu befolgen. Vielleicht arbeiten sie nicht in einer Event-Streaming-Umgebung und unterstützen XML-basierte Call-and-Response-APIs. Natürlich brauchen sie eine Anleitung, aber sie muss zu ihrem Bereich und zu den Bedürfnissen ihrer Kunden passen.

In dieser "mittleren Phase" deines API-Verwaltungsprogramms müssen sich die Führung und die Richtlinien von spezifischen Anleitungen für die Gestaltung und Implementierung von APIs zu einer allgemeineren Anleitung für den Lebenszyklus deiner APIs und die Art und Weise, wie sie miteinander interagieren müssen, verlagern. In den Kapiteln 6 und 7 findest du die Maßnahmen, die wir bei erfolgreichen Organisationen für API-Programme im mittleren Stadium beobachten.

Es gibt sicherlich einige Richtlinien, die alle Teams teilen müssen, aber diese Richtlinien müssen sowohl auf die Problembereiche als auch auf die Bedürfnisse der API-Kunden zugeschnitten sein. Je größer deine Gemeinschaft wird, desto vielfältiger wird sie, und du darfst nicht den Fehler machen, diese Vielfalt zu eliminieren. An dieser Stelle musst du den Hebel umlegen und nicht mehr nur Befehle erteilen (z. B. "Alle APIs müssen die folgenden URL-Muster verwenden..."), sondern Anleitungen geben (z. B. "APIs, die über HTTP laufen, sollten eine der folgenden URL-Vorlagen verwenden...").

In dieser "späteren Phase" der API-Verwaltung wird die Perspektive der Governance noch weiter ausgedehnt, um sich darauf zu konzentrieren, wie APIs im Laufe der Zeit interagieren und wie deine APIs mit den APIs anderer Unternehmen in deinem Markt und deiner Branche interagieren. Die Kapitel 9, 10 und 11 spiegeln die Art von "Big-Picture"-Denken wider, das notwendig ist, um ein gesundes und stabiles API-Ökosystem bis weit in die Zukunft zu erhalten.

Wie du siehst, muss deine Sammlung von Richtlinien entsprechend erweitert werden, wenn der Umfang deines Programms zunimmt. Das ist besonders wichtig für globale Unternehmen, in denen die lokale Kultur, Sprache und Geschichte eine wichtige Rolle für die Art und Weise spielen, wie Teams denken, arbeiten und Probleme lösen.

Und das führt uns zum nächsten Schlüsselelement: dem Umfang.

Skala

Eine weitere große Herausforderung bei der Erstellung und Aufrechterhaltung eines gesunden API-Verwaltungsprogramms ist der Umgang mit Veränderungen in der Größenordnung im Laufe der Zeit. Wie im vorigen Abschnitt beschrieben, kann es eine Herausforderung sein, die Anzahl der Teams und die Anzahl der von diesen Teams erstellten APIs zu erhöhen. Auch die Prozesse, die für die Überwachung und Verwaltung der APIs zur Laufzeit erforderlich sind, ändern sich mit der Reifung des Systems. Die Werkzeuge, die benötigt werden, um eine Handvoll APIs zu überwachen, die alle vom selben Team an einem einzigen Standort erstellt wurden, unterscheiden sich stark von den Werkzeugen, die benötigt werden, um Hunderte oder Tausende von API-Einstiegspunkten zu überwachen, die über mehrere Zeitzonen und Länder verstreut sind.

In diesem Buch bezeichnen wir diesen Aspekt der API-Verwaltung als "Landschaft". Wenn dein Programm größer wird, musst du in der Lage sein, viele Prozesse von vielen Teams an vielen Orten im Auge zu behalten. Du wirst dich immer mehr auf die Überwachung des Laufzeitverhaltens verlassen müssen, um ein Gefühl dafür zu bekommen, wie gesund dein System zu einem bestimmten Zeitpunkt ist. Im zweiten Teil dieses Buches (ab Kapitel 9) werden wir untersuchen, wie das Konzept der Verwaltung der API-Landschaft dir dabei helfen kann, herauszufinden, auf welche Elemente du dich konzentrieren solltest und welche Werkzeuge und Prozesse dir helfen können, deine wachsende API-Plattform im Griff zu behalten.

API-Landschaften stellen eine Reihe neuer Herausforderungen dar. Die Prozesse, mit denen du eine einzelne API entwirfst, implementierst und pflegst, sind nicht immer dieselben, wenn du dein Ökosystem skalieren musst. Das ist im Grunde ein Zahlenspiel: Je mehr APIs du in deinem System hast, desto wahrscheinlicher ist es, dass sie miteinander interagieren, und das erhöht die Wahrscheinlichkeit, dass einige dieser Interaktionen zu unerwartetem Verhalten (oder "Fehlern") führen. Das ist die Art und Weise, wie große Systeme funktionieren - es gibt mehr Wechselwirkungen und mehr unerwartete Ergebnisse. Wenn du versuchst, diese unerwarteten Ergebnisse zu beseitigen, kommst du nur zum Teil weiter. Du kannst nicht alle Fehler beseitigen.

Und das führt zu der dritten Herausforderung, mit der die meisten wachsenden API-Programme konfrontiert sind: Wie kannst du unerwartete Änderungen reduzieren, indem du das richtige Maß an Standards in deinem API-Programm anwendest?

Normen

Eine der wichtigsten Veränderungen, die sich ergeben, wenn du anfängst, auf der Landschaftsebene statt auf der API-Ebene zu managen, liegt in der Macht der Standards, die den Teams, die APIs in deinem Unternehmen entwerfen, implementieren und einsetzen, eine einheitliche Anleitung bieten.

Wenn Gruppen größer werden - einschließlich der Gruppe von Teams, die für die APIs deiner Organisation verantwortlich sind -, entstehen Kosten für die Koordination (siehe "Entscheidungen"). Der wachsende Umfang erfordert eine Änderung des Aufgabenbereichs. Ein wichtiger Weg, mit dieser Herausforderung umzugehen, besteht darin, sich mehr auf allgemeine Standards statt auf spezifische Designvorgaben zu verlassen.

Einer der Gründe dafür, dass das World Wide Web seit seiner Gründung im Jahr 1990 so gut funktioniert, ist zum Beispiel, dass sich seine Entwickler/innen schon früh für allgemeine Standards entschieden haben, die für alle Arten von Softwareplattformen und Sprachen gelten, anstatt eng gefasste Implementierungsrichtlinien zu erstellen, die auf einer einzigen Sprache oder einem einzigen Framework basieren. Dies ermöglicht es kreativen Teams, neue Sprachen, Architekturmuster und sogar Laufzeit-Frameworks zu entwickeln, ohne bestehende Implementierungen zu zerstören.

Ein roter Faden, der sich durch die langlebigen Standards zieht, die dem Web zum Erfolg verholfen haben, ist der Fokus auf die Standardisierung der Interaktion zwischen Komponenten und Systemen. Anstatt die Art und Weise zu standardisieren, wie Komponenten intern implementiert werden (z. B. diese Bibliothek, dieses Datenmodell usw.), zielen die Webstandards darauf ab, dass sich die Beteiligten über das Internet leicht verstehen können. Wenn dein API-Programm ausgereifter wird, müssen sich auch die Leitlinien, die du deiner API-Gemeinschaft zur Verfügung stellst, mehr auf allgemeine Interaktionsstandards als auf spezifische Implementierungsdetails konzentrieren.

Das kann ein schwieriger Übergang sein, aber er ist unerlässlich, um zu einer gesunden API-Landschaft aufzusteigen, in der es den Teams möglich ist, APIs zu erstellen, die sowohl mit den bestehenden als auch den zukünftigen APIs in deinem System interagieren können.

Verwaltung der API-Landschaft

Wie zu Beginn dieses Kapitels erwähnt hat, gibt es zwei zentrale Herausforderungen im Bereich der API-Verwaltung: die Verwaltung einer einzelnen API und die Verwaltung der Landschaft aller APIs. Bei unseren Besuchen in vielen Unternehmen und unseren Recherchen zum API-Management im Allgemeinen finden wir viele Versionen der "Verwaltung einer einzelnen API". Es gibt viele "Lebenszyklen" und "Reifegradmodelle", die solide Ratschläge zur Identifizierung und Entschärfung der Herausforderungen bei der Entwicklung, Erstellung und Bereitstellung einer API geben. Für ein Ökosystem (wir nennen es eine Landschaft) von APIs haben wir jedoch nur wenige Anleitungen gefunden.

Landschaften haben ihre eigenen Herausforderungen und ihre eigenen Verhaltensweisen und Tendenzen. Was du berücksichtigen musst, wenn du eine einzelne API entwirfst, ist nicht dasselbe wie das, was du berücksichtigen musst, wenn du zehn, hunderte oder sogar tausende von APIs unterstützen musst. In einem Ökosystem gibt es neue Herausforderungen, die bei einer einzelnen Instanz oder Implementierung einer API nicht auftreten. Wir werden uns später im Buch eingehend mit der API-Landschaft befassen, aber wir möchten bereits zu Beginn des Buches auf drei Aspekte hinweisen, die die API-Landschaft zu einer besonderen Herausforderung für das API-Management machen:

• Skalierungstechnologie

• Teams skalieren

• Skalierung der Governance

Nehmen wir uns einen Moment Zeit, um jeden dieser Aspekte des API-Managements in Bezug auf Landschaften zu betrachten.

Technologie

Wenn du dein API-Programm zum ersten Mal startest, musst du eine Reihe von technischen Entscheidungen treffen, die sich auf alle deine APIs auswirken werden. Die Tatsache, dass "alle" deine APIs zu diesem Zeitpunkt nur eine kleine Gruppe sind, ist nicht wichtig. Wichtig ist, dass du dich beim Aufbau deines API-Programms auf eine Reihe von Tools und Technologien verlassen kannst. Wie du sehen wirst, wenn wir uns mit den Details des API-Lebenszyklus(Kapitel 7) und der API-Reife beschäftigen, sind API-Programme nicht billig, und du musst deine Investitionen von Zeit und Energie in Aktivitäten, die einen großen Einfluss auf den Erfolg deiner API haben, sorgfältig überwachen, ohne zu früh viel Kapital zu riskieren. Das bedeutet in der Regel, dass du eine kleine Anzahl von Tools auswählst und unterstützt und klare, oft detaillierte Anleitungen bereitstellst, die deinen API-Teams helfen, APIs zu entwerfen und zu erstellen, die sowohl deine Geschäftsprobleme lösen als auch gut zusammenarbeiten. Mit anderen Worten: Du kannst frühzeitig Erfolge erzielen, indem du deinen technischen Umfang begrenzst.

Zu Beginn funktioniert das aus den genannten Gründen gut. Wenn dein Programm jedoch an Umfang zunimmt (siehe "Umfang") und sich der Geltungsbereich ausweitet (z. B. wenn mehr Teams mehr APIs für mehr Geschäftsbereiche an mehr Standorten entwickeln), ändern sich auch die Herausforderungen. Wenn du dein API-Programm ausbaust, kann das Vertrauen in eine begrenzte Anzahl von Tools und Technologien zu einem der wichtigsten Faktoren werden, die dich ausbremsen. Während du am Anfang, als du noch eine kleine Gruppe von Teams hattest, durch die Beschränkung der Auswahlmöglichkeiten schneller vorankamst, ist es ein kostspieliges und riskantes Unterfangen, einer großen Gruppe von Teams Grenzen zu setzen. Das gilt besonders, wenn du anfängst, Teams an geografisch weit entfernten Standorten hinzuzufügen und/oder wenn du neue Geschäftsbereiche aufnimmst oder neue Unternehmen erwirbst, um deine API-Landschaft zu erweitern. An diesem Punkt wird die Vielfalt (siehe "Vielfalt") zu einem viel wichtigeren Erfolgsfaktor für dein Ökosystem.

Ein wichtiger Teil des Technologiemanagements für API-Landschaften besteht also darin, zu erkennen, wann die Landschaft groß genug ist, um die Vielfalt der Technologien zu erhöhen, anstatt sie einzuschränken. Ein Teil davon hat mit den Realitäten der bestehenden Implementierungen zu tun. Wenn deine API-Landschaft die bestehenden SOAP-over-TCP/IP-Dienste deines Unternehmens unterstützen muss, kannst du nicht verlangen, dass alle diese Dienste dieselbe URL-Anleitung verwenden, die du für deine neuen CRUD-over-HTTP-APIs erstellt hast. Das Gleiche gilt für die Erstellung von Diensten für neue ereignisgesteuerte Angular-Implementierungen oder die alten Remote Procedure Call (RPC)-Implementierungen.

Eine größere Bandbreite bedeutet mehr technische Vielfalt in deiner Landschaft.

Teams

Die Technologie ist nicht der einzige Aspekt des API-Managements, der mit dem Wachstum des Programms neue Herausforderungen mit sich bringt. Auch die Zusammensetzung der Teams selbst muss sich anpassen, wenn sich die Landschaft verändert. Auch hier gilt: Zu Beginn deines API-Programms kannst du mit nur wenigen engagierten Personen arbeiten, die - größtenteils - alles machen. Dann hört man Bezeichnungen wie "Full-Stack-Entwickler" oder "MEAN-Entwickler" oder eine andere Variante der Idee eines einzigen Entwicklers, der alle Aspekte deines API-Programms beherrscht. (MEAN steht für MongoDB, Express.js, Angular.js, Node.js.) Du hörst vielleicht auch viel über "Startup-Teams" oder "eigenständige Teams". Dabei geht es vor allem darum, alle benötigten Fähigkeiten in einem Team zu haben.

Das macht Sinn, wenn du nur wenige APIs hast und sie alle mit denselben Tools entwickelt und implementiert werden (siehe "Technologie"). Doch mit der Größe und dem Umfang deines API-Programms wächst auch die Zahl der Kompetenzen, die für die Erstellung und Pflege deiner APIs erforderlich sind. Du kannst nicht mehr davon ausgehen, dass jedes API-Team aus einer bestimmten Anzahl von Personen mit Kenntnissen in den Bereichen Design, Datenbank, Backend, Frontend, Testen und Bereitstellung besteht. Du könntest ein Team haben, dessen Aufgabe es ist, eine datenzentrierte Dashboard-Oberfläche zu entwerfen und zu erstellen, die von einer Vielzahl anderer Teams genutzt wird. Ihre Fähigkeiten können zum Beispiel alle verwendeten Datenformate und Tools abdecken, die für die Erfassung dieser Daten benötigt werden. Oder du hast ein Team, dessen Hauptaufgabe darin besteht, mobile Apps zu entwickeln, die eine einzige Technologie wie GraphQL oder eine andere abfrageorientierte Bibliothek nutzen. Wenn die technologische Vielfalt wächst, müssen sich deine Teams vielleicht spezialisieren. Wir werden später in Kapitel 8 Gelegenheit haben, dies im Detail zu untersuchen.

Eine andere Art und Weise, in der sich die Teams ändern müssen, wenn deine API-Landschaft wächst, ist die Art und Weise, wie sie an den täglichen Entscheidungsprozessen teilnehmen. Wenn du eine kleine Anzahl von Teams hast und ihre Erfahrung nicht sehr tief ist, kann es sinnvoll sein, die Entscheidungsfindung auf eine einzige, leitende Gruppe zu zentralisieren. In großen Organisationen ist dies oft die Gruppe für Unternehmensarchitektur oder etwas mit einem ähnlichen Namen. Das funktioniert in kleineren Unternehmen, wird aber zu einem großen Problem, wenn das Ökosystem weniger homogen und umfangreicher wird. Je mehr Technik im Spiel ist, desto unwahrscheinlicher ist es, dass ein einzelnes Team mit den Details der einzelnen Tools und Frameworks Schritt halten kann. Und je mehr Teams hinzukommen, desto verteilter müssen die Entscheidungen getroffen werden; ein zentraler Ausschuss versteht selten die Realitäten des Tagesgeschäfts in einem globalen Unternehmen.

Die Lösung von besteht darin, den Entscheidungsprozess in so genannte Entscheidungselemente zu unterteilen (siehe "Die Elemente einer Entscheidung") und diese Elemente auf die richtigen Ebenen innerhalb deines Unternehmens zu verteilen. Ein wachsendes Ökosystem bedeutet, dass sich die Teams auf technischer Ebene spezialisieren und auf der Entscheidungsebene mehr Verantwortung übernehmen müssen.

Governance

Der letzte Bereich, den wir im Hinblick auf die Herausforderung von API-Landschaften ansprechen wollen, ist der allgemeine Ansatz zur Steuerung deines API-Programms. Wie in den anderen hier erwähnten Fällen haben wir auch hier festgestellt, dass sich die Rolle und die Hebel der Governance mit dem Wachstum deines Ökosystems verändern werden. Neue Herausforderungen tauchen auf, und alte Methoden sind nicht mehr so effektiv wie in der Vergangenheit. Vor allem auf Unternehmensebene kann das Festhalten an alten Governance-Modellen den Erfolg deiner APIs verlangsamen oder sogar aufhalten.

Wie in jedem anderen Bereich der Führung kann ein Ansatz, der auf direkter Anleitung basiert, am effektivsten sein, wenn der Umfang und die Größe begrenzt sind. Das gilt oft nicht nur für kleine Teams, sondern auch für neue Teams. Wenn es noch nicht viel Betriebserfahrung gibt, ist der schnellste Weg zum Erfolg, diese Erfahrung in Form von detaillierten Anleitungen und/oder Prozessdokumenten zu vermitteln. Wir haben zum Beispiel festgestellt, dass die frühe Steuerung von API-Programmen oft die Form von mehrseitigen Prozessdokumenten annimmt, in denen bestimmte Aufgaben erklärt werden: wie man die URLs für eine API gestaltet, oder welche Namen für URLs gültig sind, oder wo die Versionsnummer in einem HTTP-Header erscheinen muss. Klare Richtlinien mit wenigen Optionen machen es den Entwicklern schwer, von der genehmigten Art und Weise der Implementierung deiner APIs abzuweichen.

Aber auch hier gilt: Wenn dein Programm wächst, wenn du mehr Teams hinzufügst und mehr Geschäftsbereiche unterstützt, wird es aufgrund der schieren Größe und des Umfangs der Community schwierig, einen einzigen Leitfaden zu pflegen, der für alle Teams gilt. Und obwohl es möglich ist, die Aufgabe, detaillierte Prozessdokumente für das gesamte Unternehmen zu schreiben und zu pflegen, "auszulagern", ist dies in der Regel keine gute Idee - wie wir bereits im Abschnitt "Technologie" erwähnt haben , wird die Technologievielfalt in einem großen Ökosystem zu einer Stärke, und der Versuch, sie auf der Ebene der Unternehmensführung einzudämmen, kann den Fortschritt deines Programms verlangsamen.

Wenn sich deine API-Landschaft ausweitet, müssen sich deine Governance-Dokumente daher von direkten Prozessanweisungen hin zu allgemeinen Grundsätzen verändern. Anstatt z. B. detailliert festzulegen, was eine gültige URL für dein Unternehmen ist, solltest du die Entwickler auf die Richtlinien der Internet Engineering Task Force zum URI-Design und -Eigentum (RFC 7320) verweisen und allgemeine Hinweise geben, wie dieser öffentliche Standard in deinem Unternehmen anzuwenden ist. Ein weiteres gutes Beispiel für diese Art von prinzipieller Anleitung findest du in den meisten UI/UX-Richtlinien, z. B. in den "10 Usability Heuristics for User Interface Design" der Nielsen Norman Group. Diese Dokumente bieten eine Vielzahl von Optionen und Begründungen für die Verwendung eines bestimmten UI-Musters im Vergleich zu einem anderen. Sie bieten Entwicklern und Designern eine Anleitung, warum und wann sie etwas verwenden sollten, anstatt ihnen einfach nur Vorgaben zu machen, denen sie folgen müssen.

Bei großen Organisationen und insbesondere bei Unternehmen, die an mehreren Standorten und in verschiedenen Zeitzonen tätig sind, muss die Unternehmensführung von der Verteilung von Prinzipien zur Sammlung von Ratschlägen übergehen. Damit wird das typische Modell der zentralen Unternehmensführung im Wesentlichen umgekehrt. Anstatt den Teams vorzuschreiben, was sie zu tun haben, besteht die Hauptaufgabe des zentralen Governance-Ausschusses darin, Erfahrungswerte aus der Praxis zu sammeln, Zusammenhänge festzustellen und die "bewährten Methoden" in der gesamten Organisation wiederzugeben.

Wenn deine API-Landschaft also wächst, muss dein API-Governance-Modell von der direkten Beratung über die Vorstellung allgemeiner Grundsätze bis hin zum Sammeln und Weitergeben von Praktiken erfahrener Teams innerhalb deines Unternehmens gehen. Wie wir in Kapitel 2 sehen werden, gibt es eine Handvoll Prinzipien und Praktiken, die du nutzen kannst, um ein Governance-Modell zu schaffen, das für dein Unternehmen funktioniert.

Zusammenfassung

In diesem Eröffnungskapitel haben wir eine Reihe wichtiger Aspekte des API-Managements angesprochen, die in diesem Buch vorkommen. Wir haben festgestellt, dass APIs zwar nach wie vor eine treibende Kraft sind, aber nur knapp 50 % der befragten Unternehmen davon überzeugt sind, dass sie in der Lage sind, diese APIs richtig zu verwalten. Wir haben auch die vielen Verwendungen des Begriffs API erläutert und erklärt, wie diese unterschiedlichen Verwendungen es erschweren können, ein einheitliches Verwaltungsmodell für dein Programm zu erstellen.

Vor allem haben wir den Gedanken eingeführt, dass die Verwaltung einer "API" (d.h. einer einzelnen API) etwas ganz anderes ist als die Verwaltung deiner "API-Landschaft". Im ersten Fall kannst du dich auf AaaP-, API-Lebenszyklus- und API-Reifegradmodelle verlassen. Auch das Änderungsmanagement für APIs ist sehr stark auf diese "eine API"-Denkweise ausgerichtet. Aber das ist nur ein Teil der Geschichte.

Als Nächstes haben wir über die Verwaltung deiner API-Landschaft gesprochen - das gesamte API-Ökosystem in deinem Unternehmen. Um eine wachsende API-Landschaft zu verwalten, bedarf es einer Reihe von Fähigkeiten und Kennzahlen, die sich mit der Vielfalt, dem Umfang, der Volatilität, der Anfälligkeit und verschiedenen anderen Aspekten befassen. Alle diese Aspekte wirken sich auf den API-Lebenszyklus aus und wir werden sie später in diesem Buch im Detail besprechen.

Schließlich haben wir darauf hingewiesen, dass sich auch die Art und Weise, wie du deine Entscheidungen über dein API-Programm triffst, mit der Zeit ändern muss. Wenn dein System wächst, musst du die Entscheidungsfindung genauso verteilen, wie du IT-Elemente wie die Speicherung von Daten, Rechenleistung, Sicherheit und andere Teile der Infrastruktur deines Unternehmens verteilst.

Mit dieser Einführung als Hintergrund wollen wir uns zunächst auf den Begriff der Governance konzentrieren und darauf, wie du die Entscheidungsfindung und die Verteilung von Entscheidungen als primäres Element in deinem gesamten API-Management-Ansatz nutzen kannst.

¹ Jennifer Thomson und George Mironescu, "APIs: The Determining Agents Between Success or Failure of Digital Business", IDC, https://oreil.ly/9yshw.

² Thomson und Mironescu, "APIs: Die entscheidenden Faktoren für den Erfolg oder Misserfolg des digitalen Geschäfts".

³ Ebd.

⁴ Beim Musikstreamingdienst Spotify werden diese übergreifenden Gruppen Gilden genannt. Mehr zu diesem Thema findest du unter "Scaling Up Your Teams".