Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Lead API Consultant

heise Developer

JavaScript

Testing

Auf dem Prüfstand: Wie JavaScript-Tests wieder lesbar werden

Es gibt viele Patterns, die helfen können, die Les- und Wartbarkeit von JavaScript-Tests zu verbessern. Zehn davon stellt dieser Artikel vor.

Auf dem Prüfstand: Wie JavaScript-Tests lesbar werden

In der heutigen schnelllebigen und datengesteuerten Welt stehen Unternehmen vor einer zunehmend komplexen Herausforderung: Wie können Datenschnittstellen so gestaltet, implementiert und verwaltet werden, dass sie sowohl den unmittelbaren betrieblichen Anforderungen als auch den langfristigen strategischen Unternehmenszielen gerecht werden? Eine Datenschnittstelle ist ein definierter Verbindungspunkt, über den Daten zwischen Systemen, Anwendungen oder Komponenten ausgetauscht werden. Sie legt die Regeln, Formate und Protokolle fest, die für eine reibungslose Kommunikation und Interoperabilität erforderlich sind, und bildet das Rückgrat moderner Datenökosysteme.

Die Mehrheit der Unternehmen hat erkannt, dass Daten eine zentrale Rolle bei der Entscheidungsfindung spielen, Innovationen fördern und Wettbewerbsvorteile schaffen. Allerdings sind die vielfältigen Möglichkeiten zur Gestaltung von Datenschnittstellen oft schwer zu durchschauen, insbesondere für Softwarearchitekten, die die Kluft zwischen technischen Lösungen und Geschäftsergebnissen überbrücken müssen.

Hier kommt das Data Interface Quadrants (DIQs) Framework als transformatives Werkzeug ins Spiel. Die DIQs bieten einen strukturierten und visuellen Ansatz zur Analyse und Kategorisierung von Datenschnittstellen, der Architekten, Entwicklungsteams und Entscheidungsträgern hilft, die Komplexität zu reduzieren. Durch die Umwandlung der Komplexität von Datenschnittstellen in ein intuitives Format ermöglichen die DIQs wertvolle Einblicke, die eine bessere strategische Ausrichtung und fundierte Entscheidungen unterstützen.

In diesem Blog-Beitrag werden wir das Potenzial und den Wert der DIQs aus zwei Perspektiven betrachten: aus der Sicht des Unternehmensarchitekten, der sich auf die langfristige Unternehmensstrategie konzentriert, und aus der Sicht des Lösungsarchitekten, der sich mit projektspezifischen Implementierungsproblemen auseinandersetzt. Diese beiden Blickwinkel zeigen, wie DIQs eine effektive Zusammenarbeit fördern, um robuste und zukunftssichere Datenökosysteme zu schaffen und bestehende Systeme zu modernisieren. DIQs sind mehr als nur ein Diagramm – sie dienen als Kompass für die Entscheidungen und Kompromisse, die beim Design von Datenschnittstellen getroffen werden müssen.

## Einführung in die DIQs

![data-interface-quadrants-plain.jpg](https://media.graphassets.com/ojiHNTPMR7uzJZM3aCte)

Die DIQs bieten eine strukturierte Methode zur Kategorisierung von Datenschnittstellen anhand zweier Hauptdimensionen: dem Umfang der Datenverarbeitung und der Anzahl der Nutzerinnen und Nutzer. Die horizontale Achse der DIQs zeigt den Grad der Datenaggregation oder -transformation. Auf der linken Seite werden Rohdaten dargestellt, die kaum oder gar nicht umgewandelt werden. Diese sind besonders für Anwendungsfälle geeignet, die Basisdaten in ihrer ursprünglichen Form benötigen. Auf der rechten Seite hingegen werden aggregierte oder transformierte Daten dargestellt, die spezifische Anwendungsfälle unterstützen oder erweiterte Funktionen auf Service-Ebene bieten.

Die Komplexität der Datenverarbeitung steigt beim Übergang von Rohdaten zu aggregierten oder transformierten Daten. Rohdaten erfordern nur minimale Eingriffe und sind in der Regel schneller verfügbar, jedoch müssen die Nutzerinnen und Nutzer möglicherweise mehr Aufwand betreiben, um aussagekräftige Erkenntnisse daraus zu gewinnen. Im Gegensatz dazu erfordern aggregierte oder transformierte Daten zusätzliche Verarbeitungsschritte, wie die Kombination von Datensätzen, die Anwendung von Geschäftslogik oder die Anpassung der Daten an spezifische Anwendungsfälle. Obwohl dies die Erstellung und Pflege der Schnittstelle komplexer macht, kann es den Aufwand für die Nutzerinnen und Nutzer erheblich reduzieren und die Daten sofort für ihre Bedürfnisse nutzbar machen.

Die vertikale Achse der DIQs zeigt die Anzahl der Konsumenten, die mit den Daten interagieren. Im unteren Bereich liegt der Fokus auf produktinternen oder anwendungsspezifischen Schnittstellen, die in der Regel von einem einzigen Team oder einer klar definierten technischen Zielgruppe mit gemeinsamen Fachkenntnissen genutzt werden. Im oberen Bereich der DIQs hingegen werden externe und wiederverwendbare Schnittstellen dargestellt, die für mehrere Teams und verschiedene Zielgruppen konzipiert sind. Diese Zielgruppen können Personen mit unterschiedlichen technischen Kenntnissen oder sogar unbekannte Konsumenten umfassen.

Die beiden Achsen erzeugen vier Quadranten, von denen jeder eine bestimmte Art von Datenschnittstelle repräsentiert. Der Quadrant **Data Link** unten links steht für Rohdatenschnittstellen, die innerhalb eines einzelnen Produkts oder Teams verwendet werden. Diese Schnittstellen sind einfach und direkt, erfordern oft nur minimale Transformation und richten sich hauptsächlich an technische Zielgruppen mit klaren, gemeinsamen Anforderungen. Der Quadrant **Backend for Frontend (BFF)** unten rechts umfasst anwendungsspezifische Schnittstellen, die aggregierte oder transformierte Daten bereitstellen. Diese Schnittstellen sind auf spezifische Anwendungsbedürfnisse zugeschnitten und optimiert für Effizienz innerhalb eines einzelnen Produkts oder Teamkontexts. Entwicklungsteams entwerfen und implementieren beide Arten von Schnittstellen mit einem starken Fokus auf die Technologie.

Der Quadrant **Platform Data Product** oben links repräsentiert Rohdatenschnittstellen, die extern und wiederverwendbar sind. Diese Schnittstellen stellen grundlegende Daten in ihrer ursprünglichen Form einem breiten Publikum zur Verfügung, einschließlich unbekannter Konsumenten und Personen mit unterschiedlichem technischen Hintergrund. Hier stehen Wiederverwendbarkeit und Skalierbarkeit anstatt Spezifität im Vordergrund. Der Quadrant **Composition Service** oben rechts umfasst externe und wiederverwendbare Schnittstellen, die aggregierte und transformierte Daten bereitstellen. Diese Schnittstellen sind für verschiedene Anwendungsfälle konzipiert und werden von mehreren Teams genutzt. Ihre Erstellung und Pflege sind daher am komplexesten, gleichzeitig bieten sie jedoch die größte Vielseitigkeit für die Bedürfnisse des Unternehmens. Das breite Publikum erfordert von den Entwicklungsteams, beide Arten von Schnittstellen so zu gestalten und zu implementieren, dass der Fokus auf den geschäftlichen Anforderungen liegt und nicht auf der Technologie.

## Die Auswirkungen eines API-First-Geschäftsmodells

Wenn Unternehmen eine API-First-Strategie verfolgen, werden APIs zu einem zentralen Bestandteil ihres Geschäftsmodells. Dadurch verlagert sich der Fokus für Datenschnittstellen zunehmend auf die oberen Quadranten der DIQs. Anstatt produktinterne und anwendungsspezifische Schnittstellen zu entwickeln, müssen sich die Entwicklungsteams darauf konzentrieren, mehr externe und wiederverwendbare Schnittstellen für ein größeres Publikum zu erstellen, was zu höheren geschäftlichen Auswirkungen führt. Wenn die Teams bisher hauptsächlich **Backend for Frontend**-Schnittstellen erstellt haben, fehlt ihnen möglicherweise das Wissen, um einen erfolgreichen **Composition Service** zu entwickeln, der auf geschäftliche Auswirkungen abzielt. Enabling und Platform Teams können die Entwicklungsteams dabei unterstützen, den Übergang der APIs von rein technischen Schnittstellen zu geschäftsrelevanten Produkten zu vollziehen. Die DIQs helfen, solche strategischen Entscheidungen und ihre Auswirkungen auf das Design von Datenschnittstellen zu visualisieren.

![data-interface-quadrants-api-first.jpg](https://media.graphassets.com/YzoIBqRdT2z3FPXec4Dm)

## Unternehmensarchitekten: Die DIQs als strategische Linse

Unternehmensarchitekten agieren an der Schnittstelle von Geschäftsstrategie und technologischer Umsetzung und prägen damit auch die übergreifende Datenarchitektur. Die DIQs geben ihnen eine ganzheitliche Perspektive und ermöglichen eine strategische Übersicht, die die Kluft zwischen organisatorischen Zielen und technischen Realitäten überbrückt.

Mit Hilfe der DIQs können Unternehmensarchitekten Schnittstellen kategorisieren und bewerten sowie Investitionen dort priorisieren, wo sie am wichtigsten sind. Produktinterne und anwendungsspezifische Schnittstellen, die aggregierte oder transformierte Daten bereitstellen, können beispielsweise die Skalierbarkeit verbessern. Externe und wiederverwendbare Schnittstellen, die Rohdaten bereitstellen, bieten Optimierungsmöglichkeiten, da sie nur minimale Datenverarbeitung erfordern, aber aufgrund ihrer breiten Zielgruppe einen großen Einfluss auf das Unternehmen haben. Die DIQs helfen auch dabei, Engpässe und redundante Systeme zu identifizieren und unterstützen die Bemühungen zur Rationalisierung von Prozessen und Verbesserung der Integration.

Die DIQs dienen auch als Kommunikationsinstrument, indem sie Datenschnittstellen in einem klaren, visuellen Format darstellen. Unternehmensarchitekten können damit Diskussionen mit Stakeholdern erleichtern und technische Initiativen mit den umfassenderen Geschäftszielen in Einklang bringen. In Projekten zur digitalen Transformation helfen die DIQs, Schnittstellen zu identifizieren, die für eine Neugestaltung oder Investitionen geeignet sind. Dies stellt sicher, dass die heutigen Entscheidungen das zukünftige Wachstum unterstützen. Zudem können Unternehmensarchitekten die Entwicklungsteams erkennen, die mehr Unterstützung von Enabling und Platform Teams benötigen, um die Neugestaltung und Investitionen erfolgreich umzusetzen.

## Lösungsarchitekten: Eine Brücke zwischen Strategie und Ausführung

Lösungsarchitekten setzen Ideen um, indem sie Systeme entwerfen, die den unmittelbaren Projektanforderungen gerecht werden und gleichzeitig umfassende Architekturprinzipien berücksichtigen. Die DIQs unterstützen sie dabei, konkurrierende Prioritäten zu bewältigen und bieten eine strukturierte Sichtweise, um Datenschnittstellen effektiv zu bewerten und zu implementieren.

Bei der Integration von Systemen, wie einer CRM-Plattform, stehen Lösungsarchitekten vor der Herausforderung, ein Gleichgewicht zwischen schneller Bereitstellung und langfristiger Skalierbarkeit zu finden. Einerseits besteht der Druck, funktionale Lösungen schnell bereitzustellen, um unmittelbare Geschäftsanforderungen zu erfüllen, beispielsweise dem Vertriebsteam den Zugriff auf wichtige Kundendaten in Echtzeit zu ermöglichen. Andererseits müssen diese Schnittstellen so entwickelt werden, dass sie zukünftiges Wachstum und Integration unterstützen, um den sich im Laufe der Zeit verändernden Anforderungen, zusätzlichen Systemen und größeren Datenmengen gerecht zu werden. Dieser Balanceakt wird durch konkurrierende Prioritäten weiter erschwert. Eine schnelle Bereitstellung bevorzugt oft leichtgewichtige und minimal komplexe Schnittstellen, die mit begrenzten Ressourcen schnell implementiert werden können. Diese Schnittstellen könnten jedoch die Robustheit oder Flexibilität vermissen lassen, die für eine nahtlose Integration in zukünftige Systeme oder die Bewältigung wachsender organisatorischer Anforderungen erforderlich ist. Im Gegensatz dazu erfordert die Entwicklung einer langfristigen Skalierbarkeit zusätzlichen Aufwand im Vorfeld, wie die Implementierung aggregierter oder wiederverwendbarer Datenschnittstellen. Dies kann die anfängliche Bereitstellung verzögern, verbessert jedoch die allgemeine Belastbarkeit und Anpassungsfähigkeit des Systems erheblich.

Durch die Einordnung von Schnittstellen innerhalb der DIQs erhalten Lösungsarchitekten eine strukturierte Methode zur Bewertung und Abstimmung ihrer Entscheidungen, um sowohl unmittelbare Projektziele als auch übergeordnete Unternehmensstrategien zu berücksichtigen. Leichtgewichtige Schnittstellen können beispielsweise die Bereitstellung beschleunigen und harte Deadlines einhalten. Sie müssen jedoch auch auf ihre Kompatibilität mit zukünftigen Integrationen geprüft werden, um kostspielige Redesigns zu vermeiden. Mithilfe der DIQs können Lösungsarchitekten erkennen, wo Kompromisse notwendig sind und wo sich Investitionen in Skalierbarkeit auszahlen. So wird sichergestellt, dass kurzfristige Erfolge den langfristigen Erfolg nicht gefährden.

## Zusammenarbeit durch DIQs: Überbrückung von Rollen

Die DIQs fördern die Zusammenarbeit zwischen Unternehmens- und Lösungsarchitekten, indem sie eine gemeinsame Sprache bieten, die verschiedene Perspektiven vereint. Dadurch unterstützen sie die Entwicklung einer kohärenten Datenstrategie, die über die einzelnen Rollen hinausgeht.

In Workshops oder Planungsmeetings, die auf den DIQs basieren, können Prioritäten für Schnittstellen abgestimmt werden, um sicherzustellen, dass taktische Entscheidungen zu langfristigen Zielen beitragen. Diese Zusammenarbeit verbessert nicht nur das Schnittstellendesign, sondern schafft auch Vertrauen und Synergien zwischen den Teams. Die DIQs sind zudem hilfreich, wenn Schnittstellenanforderungen mit Entwicklungsteams geteilt werden, da sie ein gemeinsames Verständnis des erwarteten Ergebnisses gewährleisten. Besonders nützlich sind sie, wenn konkrete Richtlinien und Best Practices für jeden Quadranten bereitgestellt werden.

## Fazit

Das Data Interface Quadrants Framework (DIQs) ist mehr als nur ein Werkzeug – es dient als strategischer Begleiter. Durch die visuelle Darstellung kritischer Dimensionen von Datenschnittstellen ermöglichen die DIQs Architekten und Unternehmen, technische Entscheidungen mit den Geschäftszielen in Einklang zu bringen und Investitionen zu priorisieren, die den Wert steigern. Unternehmensarchitekten erhalten eine zusätzliche strategische Perspektive für die langfristige Planung, während Lösungsarchitekten die DIQs nutzen können, um sicherzustellen, dass der Projekterfolg mit den übergeordneten Zielen übereinstimmt und die Entwicklungsteams genau wissen, was von ihnen erwartet wird.

Vor allem haben wir die DIQs entwickelt, um die Zusammenarbeit zu fördern und die Kluft zwischen Strategie und Ausführung zu überbrücken. Sie bieten einen gemeinsamen Rahmen, der Architekten hilft, die Komplexität zu meistern, Innovationen voranzutreiben und robuste Datenökosysteme zu schaffen. Angesichts der Herausforderungen bei Integration, Skalierbarkeit und Governance sind die DIQs eine wertvolle Ressource für Klarheit, Orientierung und Kommunikation.

Setzt die DIQs in eurer Organisation, eurem Team oder eurem Projekt ein. Nutzt sie, um Datenstrategien zu analysieren, zu optimieren und zu verbessern. Teilt anschließend eure Gedanken und Erfahrungen mit uns, damit wir die DIQs weiterentwickeln und sie in unserer schnelllebigen, datengesteuerten Welt noch nützlicher machen können. Wir freuen uns auf eure Geschichten!

Kategorisierung von Schnittstellen: Data Interface Quadrants (DIQs)

*Viele Unternehmen setzen große Hoffnungen in API-Plattformen. Sie sollen Integrationen erleichtern, Wiederverwendung fördern und das Unternehmen technologisch zukunftssicher machen. Nach der Einführung scheint vieles auf einem guten Weg zu sein: Die Plattform ist etabliert, erste Projekte wurden erfolgreich umgesetzt und das Team rund um die API-Plattform baut Wissen auf. Doch nach einer gewissen Zeit zeigt sich ein wiederkehrendes Muster. Die Nachfrage nach neuen APIs nimmt ab, bestehende APIs werden kaum wiederverwendet und das API-Team wird zunehmend als Flaschenhals wahrgenommen. APIs entstehen meist erst dann, wenn sie unmittelbar für ein Projekt benötigt werden – oft unter Zeitdruck und ohne Blick auf eine langfristige Strategie.*

In diesem Blog Post verwenden wir die Begriffe *Integration* und *API* und definieren sie dafür wie folgt:

> **Integration**: bezeichnet die Verknüpfung verschiedener Systeme oder Anwendungen, um einen nahtlosen Datenaustausch zu automatisierte Prozesse zu ermöglichen.

>**API**:  ist eine definierte Schnittstelle, die es Anwendungen ermöglicht, miteinander zu kommunizieren.

Das API-Team ist sich dieser Herausforderungen bewusst und versucht gegenzusteuern. Es werden Workshops organisiert, Best Practices definiert und Optimierungen der Plattform, wie z.B. die Entwicklung von Self-Service Funktionalitäten, angestoßen. Doch strukturelle Probleme lassen sich auf diese Weise nur schwer lösen. Solange Integrationen in einzelnen Projekten isoliert betrachtet werden und keine übergreifende API-Strategie existiert, bleibt die Plattform in ihrer Wirkung begrenzt. APIs entstehen und verschwinden, ohne dass sie langfristig einen Mehrwert bieten.

## Warum die Bereitstellung von APIs nicht automatisch zu ihrer effektiven Nutzung führt
Was viele Organisationen unterschätzen: Der Aufbau einer API-Plattform ist nur der erste Schritt. Der eigentliche Mehrwert entsteht erst dann, wenn APIs nicht nur bereitgestellt, sondern auch aktiv genutzt und weiterentwickelt werden. Doch genau hier scheitern viele Organisationen. Die Gründe sind vielfältig: Oft fehlt eine übergeordnete API-Strategie, die eine konsistente und wiederverwendbare API-Landschaft fördert, andere Organisationen scheitern dagegen an der Umsetzung oder Kommunikation der Strategie.

Ein zentrales Problem ist, dass APIs oft als rein technische Notwendigkeit verstanden werden, nicht als Business-Enabler. Solange sie nur entwickelt werden, weil eine Schnittstelle auf die Schnelle gebraucht wird, fehlt die strategische Komponente. APIs entstehen sehr oft ausschließlich reaktiv im Rahmen eines bestimmten Projekts – als Mittel, um eine Integration schnell zum Laufen zu bringen. Dabei wird wenig darüber nachgedacht, ob eine API auch für andere Anwendungsfälle geeignet und damit wiederverwendbar sein könnte, sie langfristig erweiterbar ist oder einen nachhaltigen Mehrwert für das Unternehmen schafft.

Diese projektgetriebene Entwicklung führt dazu, dass APIs kaum über den unmittelbaren Anwendungsfall hinaus gedacht werden. Das Ergebnis ist eine Sammlung von punktuellen Integrationen zwischen genau zwei Systemen. Diese Integrationen erfüllen kurzfristig ihren Zweck, führen aber langfristig zu einer fragmentierten, schwer wartbaren Architektur.

Auch ist die Rolle des API-Teams ein Problem. Häufig wird es als reiner „Service Provider“ betrachtet, der Integrationen auf Zuruf entwickelt. Die Einbindung erfolgt oft erst spät im Projekt, wenn die grundlegenden Anforderungen bereits festgelegt sind und keine Möglichkeit mehr besteht, das API-Design hinsichtlich Wiederverwendung zu optimieren. Dadurch bleibt das API-Team auf die Umsetzung beschränkt und kann keinen strategischen Einfluss auf die API-Landschaft nehmen. Gleichzeitig fehlt es vielen Entwicklungsteams an einem tiefgehenden Verständnis für gutes API-Design, weil es keine systematische Unterstützung oder Enablement-Prozesse gibt.

Ein weiteres Problem ist die Wahrnehmung der Plattform selbst. Anstatt als Enabler für moderne Integration gesehen zu werden, wirkt sie auf viele Entwickler eher wie eine Vorgabe, die es zu erfüllen gilt. Die Technologie steht im Mittelpunkt, nicht der eigentliche Mehrwert von APIs. Statt die Plattform zu nutzen, um Integrationen nachhaltig zu verbessern, wird sie oft nur als Mittel zum Zweck zur punktuellen Integration eingesetzt. Das führt dazu, dass APIs entstehen, weil sie ad hoc gebraucht werden – nicht, weil sie als wertvolles Werkzeug zur Optimierung von Geschäftsprozessen verstanden werden.

Gleichzeitig sind API-Plattformen oft komplex und schwerfällig. Ohne größere Anpassungen werden nur wenige Standardfälle für Integrationen abgedeckt und der Automatisierungsgrad ist niedrig. Damit wirken sie auf Entwicklungsteams oft abschreckend und nicht gewinnbringend.

Auch API-Governance wird oft falsch verstanden. Zwar existieren in vielen Unternehmen technische Standards, doch es fehlen Metriken, um den tatsächlichen Nutzen und die Effektivität von APIs zu bewerten. Fragen wie „Wird eine API tatsächlich genutzt?“, „Wie lange dauert es, bis Entwicklungsteams sie erfolgreich einsetzen können?“ oder „Trägt die API in Zukunft dazu bei, Integrationsaufwände zu reduzieren?“ werden selten gestellt. Ohne diese Daten bleibt unklar, ob eine API wirklich einen Mehrwert liefert oder nur eine weitere technische Schnittstelle ist, die in Vergessenheit gerät.

Letztlich reicht es nicht aus, APIs einfach nur bereitzustellen. Sie müssen so gestaltet werden, dass sie langfristig Wert stiften, effizient nutzbar sind und strategisch zur Unternehmensarchitektur passen. Fehlt dieser Ansatz, bleibt eine API-Plattform ein gut gemeintes, aber wirkungsloses Werkzeug, das eher als Hürde denn als Enabler wahrgenommen wird.

## API-Effektivität durch Team Topologies
Der Schlüssel zu effektiven APIs liegt nicht nur in der Technologie, sondern vor allem in der richtigen Organisationsstruktur. Unternehmen müssen den Wechsel von einer projektgetriebenen API-Entwicklung zu strategischen API-Produkten vollziehen. Hier bietet das Konzept der **Team Topologies** einen klaren Rahmen.

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YcV9FmkrQOyVUqMeOZpn" width="400" height="500"/>

*Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.*

Team Topologies definiert vier verschiedene Team-Typen, von denen drei im API-Kontext besondere Relevanz haben: Platform Team, Enabling Team und Stream-Aligned Teams.

Ein **Platform Team** bildet das Rückgrat der API-Plattform. Es stellt nicht nur die Infrastruktur bereit, sondern sorgt auch für eine gute Developer Experience, fördert die Wiederverwendbarkeit von APIs und bietet Self-Service-Funktionen mit hohem Automatisierungsgrad an. Anstatt sich auf Governance oder Tooling zu beschränken, sollte das Platform Team APIs gezielt nutzbar machen und eine API-Strategie mit messbaren Zielen entwickeln.

Ein **Enabling Team** unterstützt andere Teams dabei, APIs als Produkte zu denken. Es hilft Entwicklungsteams, Best Practices zu etablieren, Wiederverwendung zu fördern und APIs gezielt für eine breitere Nutzerbasis zu gestalten. Ohne eine solche Unterstützung bleibt API-Entwicklung oft isoliert und ineffektiv.

Die größte Veränderung entsteht jedoch in den **Stream-Aligned Teams**. Diese Teams verantworten ihre APIs eigenständig und entwickeln sie mit einem langfristigen Produktgedanken. APIs werden nicht mehr nur gebaut, um ein Projekt abzuschließen, sondern um nachhaltig Mehrwert zu schaffen. So entsteht echte API-Ownership, die sich direkt auf die Effektivität auswirkt. Wenn Teams die volle Verantwortung für ihre APIs übernehmen, denken sie über deren langfristige Nutzung, Erweiterbarkeit und Qualität nach. Dadurch entstehen besser durchdachte, wiederverwendbare und wirtschaftlich sinnvolle APIs.

Ein zentraler Vorteil, der durch Team Topologies realisiert wird, ist die Abkehr von isolierten Punkt-zu-Punkt-Integrationen hin zu strategisch geplanten API-Produkten. APIs müssen langfristig gedacht werden, mit einer klaren Roadmap und definierten Metriken zur Erfolgsmessung: Adoption Rate, Time-to-First-Success oder die Reusability Rate sind essentiell, um zu verstehen, ob eine API tatsächlich genutzt und wiederverwendet wird oder nur ein weiteres technisches Artefakt bleibt.

## Fazit: API-Strategie entscheidet über den Erfolg
Eine API-Plattform allein reicht nicht aus, um nachhaltige Integrationserfolge zu erzielen. Entscheidend ist, dass APIs nicht nur bereitgestellt, sondern effektiv genutzt und weiterentwickelt werden. Ohne eine klar formulierte und umgesetzte Strategie bleibt eine API-Plattform eine technische Notwendigkeit, die genutzt wird, weil sie vorgeschrieben ist – mit der richtigen Teamstruktur wird sie hingegen zu einem echten Enabler für digitale Transformation.
Der Wechsel von reiner API-Bereitstellung zu API-Effektivität erfordert mehr als gute Technologie. Es geht darum, APIs als wertvolle Assets zu betrachten und ihre Entwicklung so zu organisieren, dass sie langfristig einen echten Beitrag zur Unternehmensstrategie leisten. Wer möchte, dass eine API-Plattform in der Organisation ihre erhoffte Wirkung entfaltet, muss über Technologie hinausdenken – und das Zusammenspiel von Teams, Prozessen und Strategie in den Mittelpunkt stellen.






Wenn die erhoffte Wirkung der API-Plattform ausbleibt

In vielen Projekten entstehen technisch funktionale APIs ohne echten Fokus auf die Fachlichkeit und spätere Nutzung. Oft folgt die Entwicklung immer noch einem klassischen Muster: Ticket zuweisen, Schnittstelle implementieren und Ticket abschließen. Was dabei fehlt: die Perspektive derjenigen, die diese APIs später tatsächlich verwenden. Genau an dieser Stelle setzt API Thinking als Denkweise an, um APIs konsequent nutzerzentriert und strategisch zu gestalten.

Der Begriff "API Thinking" ist inspiriert von [Design Thinking](https://wirtschaftslexikon.gabler.de/definition/design-thinking-54120) und dem [Design Sprint](https://www.thesprintbook.com/the-design-sprint), geprägt durch unsere Erfahrungen aus der Praxis. Gemeinsam mit Impulsen von [Dr. Martin Kiel](https://www.the-black-frame.de) haben wir API Thinking entwickelt, um APIs nicht nur technisch zu implementieren, sondern als bewusst gestaltete Produkte zu verstehen: mit Wert, Zweck, klaren Verantwortlichkeiten und klarer Zielgruppe.

## Was steckt hinter API Thinking?

API Thinking bedeutet, APIs nicht als rein technische Komponenten zur Systemintegration zu betrachten, sondern als Teil eines größeren Zusammenhangs. Im Kern geht es darum, sich frühzeitig mit den Bedürfnissen der Konsumierenden einer API auseinanderzusetzen. Seien es Entwicklungsteams, Fachabteilungen oder externe Partner. Ja, APIs sind Schnittstellen, aber eben auch Zugangspunkte zu geschäftlichen Funktionen, Daten und Prozessen. APIs stehen damit im Spannungsfeld zwischen Technologie, Fachlichkeit und Erwartungen der Nutzerinnen und Nutzer. Sie sollen Probleme lösen und echten Mehrwert bieten. Wer APIs gestaltet, muss also verstehen, wer sie nutzt, in welchem Kontext das geschieht und was eine einfache und wertstiftende Nutzung überhaupt ausmacht. Das erfordert die Bereitschaft, Designentscheidungen nicht nur technisch, sondern auch strategisch zu treffen.

Gleichzeitig gilt: APIs entstehen nicht im luftleeren Raum. Sie sind eingebettet in Datenmodelle, Prozesse und Organisationen. API Thinking nimmt diese Verflechtung ernst. Es betrachtet APIs als Produkte, die entwickelt, betreut und weiterentwickelt werden. Das beinhaltet auch die Verantwortung für ihre Qualität, Nutzbarkeit und Zukunftsfähigkeit.

## Vom Denken ins Tun: Das Modell hinter API Thinking

API Thinking ist kein starrer Prozess, sondern ein Modell für einen iterativen Ansatz.
Ein strukturierter Rahmen hilft dabei, die Idee greifbar zu machen:

![de_api_thinking.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma0qc0oagw2a08ulvtbikb6o)

Am Anfang steht das Verständnis der Stakeholder. Wer nutzt die API? Wofür? Was bedeutet für diese Personen "gute Nutzungserfahrung"? Statt Zielgruppen abstrakt zu beschreiben, geht es darum, konkrete Perspektiven einzunehmen, etwa durch strukturierte Workshops, Interviews oder die Analyse bestehender Nutzungsmuster.

Aufbauend auf dem Verständnis für die Stakeholder wird definiert, welche Daten eine Rolle spielen. Das erfolgt nicht technisch, sondern inhaltlich. Was wird wirklich gebraucht? In welcher Qualität und Aktualität? 

Erst danach folgt das API-Design: Welche Interaktionsmuster passen? Welcher Detailierungsgrad ist sinnvoll? Wie bleibt die Schnittstelle konsistent und verständlich?

Die Implementierung ist dann ein Ergebnis dieser Überlegungen und nicht ihr Ausgangspunkt. Und sie ist auch nicht das Ende: Eine API wird idealerweise frühzeitig durch Stakeholder validiert, Feedback wird aktiv eingeholt, neue Erkenntnisse fließen wieder zurück. So entsteht nicht nur ein funktionierender Endpunkt, sondern eine tatsächlich nutzbare und nutzbringende API.

## Abgrenzung: Was API Thinking nicht ist

API Thinking wird gern mit Begriffen wie API First oder API Management vermischt, dabei gibt es klare Unterschiede. API Thinking ist keine Methode, kein Toolset und kein Architekturprinzip, sondern eine Denkweise.

Während API First eine organisatorische Entscheidung beschreibt, APIs frühzeitig in den Mittelpunkt zu stellen, liefert API Thinking die inhaltliche Grundlage dafür, eine konkrete API zu erstellen. Es beleuchtet die API aus einem Produktgedanken heraus: Warum braucht es diese API überhaupt? Wer profitiert davon? Und wie wird sie gestaltet, damit sie echten Nutzen bringt?

API Design First bedeutet, das API-Design vor der Implementierung bewusst zu definieren, idealerweise mit Blick auf Wiederverwendbarkeit und Konsistenz. Doch auch hier gilt: Ohne Verständnis für die eigentlichen Nutzenden bleibt die API oft technisch sauber, aber fachlich wenig relevant.

Und API Management? Das kümmert sich um den Betrieb, das Monitoring, die Sicherheit und weitere Querschnittsthemen. Auch das ist wichtig, greift aber erst, wenn die API bereits erstellt ist. API Thinking setzt viel früher an: Es klärt, ob und wie eine API überhaupt sinnvoll ist.

## Was API Thinking für verschiedene Rollen bedeutet

API Thinking wirkt auf mehreren Ebenen und betrifft nicht nur Entwicklung und Architektur.

Für Entwicklungsteams bedeutet es, APIs nicht nur umzusetzen, sondern mitzugestalten. Sie übernehmen Verantwortung für Verständlichkeit, Konsistenz und Wartbarkeit und treten in Dialog mit ihren Nutzerinnen und Nutzern, um deren Bedürfnisse zu verstehen. 

Für Produktverantwortliche werden APIs sichtbarer Teil der Wertschöpfung, mit eigenen Nutzenden, Erfolgsmetriken und strategischer Relevanz. APIs sind kein technisches Nebenprodukt, sondern ein bewusster Bestandteil des Produktportfolios und können somit messbar zum Geschäftserfolg beitragen.

Architektinnen und Architekten können mithilfe von API Thinking Systeme strukturieren, Verantwortung klären und Komplexität reduzieren, zum Beispiel durch klar definierte technische Verträge zwischen Domänen. 

Und für alle Rollen im Business-Kontext öffnen APIs mit der richtigen Denkweise neue Türen: für Partnerschaften, neue digitale Erlösmodelle oder effizientere Prozesse. Nicht die API selbst steht im Vordergrund, sondern das, was sie ermöglicht.

## Vom Konzept zum Geschäftswert

APIs entfalten ihren Wert nicht allein durch saubere Technik, sondern durch ihre Wirkung im jeweiligen Kontext. Eine API wird zum echten Business-Enabler, wenn sie Prozesse beschleunigt, Integration vereinfacht oder neue Märkte zugänglich macht. Das gelingt aber nur, wenn sie auch genutzt wird und das wiederum setzt gute Gestaltung voraus. Wenn die Bedürfnisse der Zielgruppe bekannt sind, kann eine API verständlich, relevant und vertrauenswürdig umgesetzt werden. Das spart Aufwand, erhöht die Akzeptanz und verbessert die Qualität des Gesamtprodukts. API Thinking unterstützt dabei, diesen Zusammenhang herzustellen. Es hilft, technische Schnittstellen mit strategischen Zielen zu verknüpfen und die Frage nach dem "Warum" konsequent mitzudenken, egal ob intern oder extern, ob für Menschen oder Maschinen.

## Fazit: Denken statt nur machen

API Thinking ist kein Framework, kein Template, kein Werkzeugkasten. Es ist eine Denkweise. Eine, die APIs nicht als technischen Selbstzweck betrachtet, sondern als Teil einer größeren Idee: Nutzende befähigen, Wert schaffen, Systeme vernetzen. Wer APIs ausschließlich baut, weil es technisch notwendig ist, verschenkt Potenzial. Wer hingegen versteht, wie und warum sie genutzt werden, schafft Schnittstellen, die funktionieren, wachsen und dauerhaft gebraucht werden.

Die entscheidenden Fragen bei der API-Erstellung lauten nicht: "Welche Methode wenden wir an?" oder "Welches Tool setzen wir ein?". Sondern: "Für wen machen wir das?", "Welches Problem lösen wir?" und "Wie bleibt unsere Schnittstelle langfristig relevant?"

**API Thinking liefert dafür keine fertigen Antworten. Aber es hilft, die richtigen Fragen zu stellen.**


API Thinking – mehr als nur Schnittstellenentwicklung

*API Discovery bezeichnet die Fähigkeit, alle in einer Organisation verwendeten APIs zu identifizieren, zu katalogisieren und zu dokumentieren mit dem Ziel, sie auffindbar und nutzbar zu machen und die Governance zu stärken. Es gibt unzählige Tools, die die API Discovery unterstützen. Typischerweise heißen sie Developer Portal, Katalog oder Marktplatz. Bei dieser Fülle an unterschiedlichen Namen ist es leicht möglich, den Überblick zu verlieren. Was sollte ein API Discovery Tool überhaupt leisten? Und welcher Name ist für welche Art Tool der richtige?*

## Developer Portal

Developer Portale bieten den Zugriff auf APIs als Self-Service, ein nahtloses Onboarding, gute Dokumentation und Integrationsunterstützung. Ihre Hauptzielgruppe ist technisch, was auch durch den Namen repräsentiert wird.

Die typischen Funktionen, die ein Developer Portal unterstützt sind:
- API Dokumentation
- Interaktive API Exploration und Sandboxes
- SDKs, Beispielcode, Bruno / Postman Collections
- Authentifizierung & API Key/Token Management
- Support für Entwicklungsteams

Ein gutes Developer Portal unterstützt Entwicklungsteams dabei zu verstehen, wie sie eine API verwenden. Es reduziert die für die Integration nötige Zeit, auch bereits bei der ersten Benutzung. Zusätzlich erhöht es die Adoptionsrate für APIs durch den angebotenen Self-Service.

## Katalog

Kataloge organisieren und verwalten APIs für eine bessere Auffindbarkeit und Konsistenz. Ihre Hauptzielgruppe ist meist technisch und unternehmensintern, da sie eine komplette Übersicht bieten, die für Externe oft nicht notwendig ist.

Die typischen Funktionen, die ein Katalog unterstützt sind:
- Zentralisiertes API-Inventar
- Suche, Filterung & Kategorisierung
- Visualisierung von API Metadaten
- Governance und Durchsetzung von Richtlinien
- Standardisierung von API-Verträgen und Abhängigkeiten

Ein guter Katalog führt dazu, dass APIs wiederverwendet werden, weil sie einfacher zu finden sind. Damit reduziert er auch Duplikate und API-Sprawl. Er fördert Governance über die Durchsetzung von Richtlinien und Konsistenz über die Grenzen von Teams hinweg. Durch das zentralisierte API-Inventar ermöglicht ein Katalog auch die Standardisierung von API-Verträgen und Abhängigkeiten.

## Marktplatz

Marktplätze verbinden API-Anbietende mit ihren Konsumierenden und fördern dabei Monetarisierung und Partnerschaften. Ihre Zielgruppe ist vielfältiger und schließt sowohl Menschen mit Business- als auch Technik-Fokus ein. Meist werden Marktplätze unternehmensextern angeboten und zeigen nur einen ausgewählten Ausschnitt der API-Landschaft.

Die typischen Funktionen, die ein Marktplatz unterstützt sind:
- Bewertungen, Rezensionen und Community-Engagement
- Mechanismen zur Abrechnung und Umsatzbeteiligung
- Rechtliche Vereinbarungen und transparente SLAs
- Onboarding von Anbietenden und Konsumierenden
- Preismodelle für APIs

Ein guter Marktplatz erweitert die API-Verwendung über interne Teams hinaus. Er unterstützt vor allem bei der Kommerzialisierung und der Monetarisierung von APIs. Gleichzeitig muss er Entscheidungsträger*innen eine effektive Überwachung ihrer API-Nutzung ermöglichen.

## Bedürfnisse der Konsumierenden

Discovery Tools sind das Fenster zur API-Landschaft einer Organisation. Die wichtigsten Stakeholder sind die Konsumierenden der APIs, die typischerweise vier Bedürfnisse haben:
- Auffindbarkeit: Welche API ist die richtige für meinen Use Case?
- Onboarding: Wie kann ich sofort loslegen?
- Integration: Ist die API stabil, verlässlich und sicher?
- Geschäftsausrichtung: Was kostet mich die Nutzung der API?

Die vorgestellten Typen von Discovery Tools fokussieren sich auf unterschiedliche Bedürfnisse:

<style>
  .api-table {
    width: 100%;
    border-collapse: collapse;
    margin: 20px 0;
    border-radius: 8px;
    box-shadow: 0 0 20px rgba(0, 0, 0, 0.1);
    overflow: hidden;
  }
  
  .api-table thead {
    background-color: #007286;
    color: white;
  }
  
  .api-table th {
    padding: 12px 15px;
    text-align: left;
    font-weight: bold;
    text-transform: uppercase;
    font-size: 14px;
    letter-spacing: 0.5px;
  }
  
  .api-table td {
    padding: 12px 15px;
    border-bottom: 1px solid #eee;
  }
  
  .api-table tbody tr:nth-child(even) {
    background-color: #f9f9f9;
  }
  
  .api-table td:first-child {
    font-weight: bold;
    color: #333;
  }
</style>

<table class="api-table">
  <thead>
    <tr>
      <th>Bedürfnis</th>
      <th>Developer Portal</th>
      <th>Katalog</th>
      <th>Marktplatz</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Auffindbarkeit</td>
      <td>❌ Nicht der primäre Fokus</td>
      <td>✅ API Metadaten, Kategorisierung, Taxonomie</td>
      <td>✅ Kategorisierung basierend auf Preismodellen und Fit zum Ökosystem</td>
    </tr>
    <tr>
      <td>Onboarding</td>
      <td>✅ Tutorials, interaktive Dokumentation, SDKs, Sandboxes</td>
      <td>❌ Nicht die Hauptfunktion</td>
      <td>❌ Limitiert auf die Beschreibung der APIs</td>
    </tr>
    <tr>
      <td>Integration</td>
      <td>✅ Self-Service</td>
      <td>❌ Nicht die Hauptfunktion, mehr Governance</td>
      <td>❌ Vorgefertigte Integrationen, API Verträge</td>
    </tr>
    <tr>
      <td>Geschäftsausrichtung</td>
      <td>❌ Hauptsächlich auf Entwickler*innen ausgerichtet</td>
      <td>✅ Governance über den API Lebenszyklus</td>
      <td>✅ Ermöglicht Monetarisierung und Partnerschaften</td>
    </tr>
  </tbody>
</table>

## Ein Tool für API-Verantwortliche

Zusätzlich zu Developer Portalen, Katalogen und Marktplätzen entstehen auch immer mehr API Registries. Registries verwalten API-Artefakte, um Transparenz über deren Lebenszyklus zu schaffen. Ihre Hauptzielgruppe sind API-Verantwortliche.

Die typischen Funktionen, die eine Registry unterstützt sind:
- Versionierung & Änderungsverfolgung
- Zentrale Speicherung von API-Definitionen
- Schema- und Abhängigkeitserkennung
- Verwaltung des Lebenszyklus

Eine gute Registry stellt die Transparenz des API-Lebenszyklus sicher. Sie verbessert die Kollaboration zwischen Teams und stellt strukturiert alle API-Artefakte zur Verfügung. Im Gegensatz dazu fokussieren sich Portale, Kataloge und Marktplätze auf den Konsum von APIs. Die Registry ist somit die zentrale und maßgebliche Datenquellen für alle Discovery Tools, die intern und extern im Einsatz sind.

![API-Zugangskanäle.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb5brkk9ogkf06ug5276vid0)
*Die API Registry dient der zentralen Speicherung von API-Artefakten. Von ihr werden APIs in verschiedene Zugangskanäle wie Developer Portale, Kataloge und Marktplätze synchronisiert, wo sie unterschiedlichen Zielgruppen von Konsumierenden zur Verfügung stehen.*

## Fazit

Unterschiedliche API Discovery-Tools haben auch einen unterschiedlichen Fokus. Je nachdem, ob das Publikum rein technisch ist oder Business-Stakeholder mit eingeschlossen werden sollen, sollte ein anderes Tool eingesetzt werden. Dabei haben die unterschiedlichen Tool-Typen auch verschiedene Aufgaben. Während Registries und Kataloge eher den Lebenszyklus der API regeln und eine Übersicht über alle APIs bieten, fokussieren sich Developer Portale und Marktplätze auf den Konsum der APIs.

![DevPortal Quadrants - de.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb4ntkwvbzbc07tflsqd97dv)
*Übersicht über die typische Zielgruppe (horizontale Achse) und die typische Aufgabe (vertikale Achse) verschiedener Tool-Typen für die API Discovery.*

API Discovery mit Developer Portalen, Katalogen und Marktplätzen: Das richtige Tool für API-Konsumenten finden

3 Steps to Access AWS Resources with Google Sign-In

How to create an AWS Lambda Authorizer for an Amazon API Gateway

*An Enabling Team is one of the four team types of the Team Topologies framework, as introduced by Matthew Skelton and Manuel Pais. How can this pattern be successfully applied to the design and development of APIs to create interfaces that really contribute to the business strategy?*

APIs are an important building block for digitalization and thus, the pressure on development teams to provide APIs is constantly growing. However, development teams often lack the necessary knowledge and experience, especially when they are mainly working in the ERP environment or in backend systems. Combined with pressing deadlines, this leads to APIs that are non-reusable, difficult to maintain, insecure and poorly documented. This frustrates and significantly slows down the development teams that rely on APIs and therefore has a negative impact on an organisation's ability to innovate. An API Enabling Team made up of experts can help teams to get started to ensure that high-quality APIs are created which contribute to the business strategy and promote the success of the organisation. This article highlights the challenges, foundations, prerequisites and opportunities of API enabling as an important success factor for establishing APIs as building blocks for digitalization.

## Challenges
Why do many development teams struggle to build high-quality APIs? Development teams that mainly work with legacy systems or have very specialised skills lack the necessary knowledge. Many practices of modern software development have not yet reached them, but these are essential for the development of high-quality APIs. 

In huge organisations, a large number of teams and different services have to be involved for the provisioning of interfaces. This includes teams who are responsible for integration, middleware (such as API management) or authorisation. This is particularly difficult to navigate for beginners, but it also puts experienced development teams to the test. 

In addition, requirements are often ‘thrown over the wall’ to the development teams. As a result, they have very little knowledge of the stakeholders of their APIs and therefore cannot identify with them or understand what they need to deliver to satisfy their stakeholders. The users of the API are thus not perceived as customers, but as someone who creates additional work for the team, namely the development of an API, which is not one of the team's core tasks and poses major challenges.

## Team Topologies as Foundation
The Team Topologies framework provides the basis for efficient software development. It distinguishes between four different types of teams: Stream-Aligned (business-oriented), Enabling (supporting), Complicated Subsystem (specialised) and Platform (accelerating). The teams interact using three different interaction patterns, either collaboratively, as-a-service or through facilitation. Exemplary interaction between the team types of the Team Topologies framework: 

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Pug7EuqDTdaSn5j1CHUQ" width="700" alt="Exemplary interaction between the team types of the Team Topologies framework" />

*Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.*

An Enabling Team consists of experts who impart knowledge and expand the skillset of the stream-aligned teams by taking over the evaluation and testing of new tools, methods, frameworks and the like. They only support stream-aligned teams for a certain period of time and not permanently.

This article sheds light on the extent to which an Enabling Team specialised on APIs (hereinafter referred to as an API Enabling Team) can support Stream-Aligned Teams in broadening their skillset to make them fit for API design and implementation.

## Tasks of an Enabling Team for APIs
The primary task of an API Enabling Team is to support other teams and train them with regard to APIs. To do this, the team must develop a workshop concept that takes into account both modern standards as well as the organisation’s circumstances and API strategy. At best, the team supports the Stream-Aligned Teams during the design and development of their first API. It is important that the Enabling Team only provides support and does not develop the API itself. As the API Enabling Team cannot be familiar with every backend technology in the organisation, the Stream-Aligned Teams must be sufficiently familiar with their technology. Once the Enabling Team has provided support, it provides documentation that enables the Stream-Aligned Teams to go through the same process independently the next time. Of course, it will also remain available in the future for special questions, reviews and the like.

An API Enabling Team is most effective when it is also involved in high-level topics and can influence the API strategy, governance and operations so that the experiences with the individual teams can be taken into account and, ideally, incorporated there.

An API Enabling Team also helps to build a vibrant API community, as it establishes the necessary contacts with the individual development teams and can thus connect them with each other.

## Following a Philosophy
To be successful as an API Enabling Team, the team must be guided by the organisation's enterprise architecture and API strategy and derive its philosophy from these.

Based on the organisation's enterprise architecture, the API Enabling Team derives a golden path and identifies the procedures and tools that must be observed and used by the Stream-Aligned Teams. These can be, for example, certain architecture patterns, a prescribed API management tool or prescribed quality features.

Based on the organisation's API strategy, the Enabling Team supplements its philosophy with specific API topics. The main focus here is on aspects such as reusability, APIs as a product, user-centred development and API design first vs. code first.

It is important that the API Enabling Team makes its philosophy transparent and bases all its actions and workshops on it.

## Developing a workshop concept based on the philosophy
Based on its philosophy derived from the organisation, the API Enabling Team then develops a tailor-made workshop concept:

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/fECA7aLLR3qUjlmNosuU" width="500" alt="How to derive a workshop concept" />

The workshop concept consists of individual building blocks and must take into account the different levels of knowledge of different Stream-Aligned Teams. The following topics should at least be covered by the workshop concept: 
* Basic functionality of an API
* User-centred API development and stakeholder involvement, including developer experience
* Various interaction patterns and their areas of application
* Creation of a data model
* API design & standard formats (e.g. OpenAPI)
* API guidelines, standards and helpful tools in the organisation and beyond
* API management in connection with the topics of security and authentication/authorisation
* Backend development (as far as possible)
* Testing

The development of such a comprehensive workshop concept requires time and expertise. Further development and improvement of the concept based on experience with the Stream-Aligned Teams is essential.

## Implementing the workshop concept
To test the workshop concept, the API Enabling Team first approaches selected Stream-Aligned Teams that are open to new ideas and direct dialogue. After trialling, all Stream-Aligned Teams are given the opportunity to make use of the API Enabling Team to develop their first high-quality API. Firstly, the API Enabling Team always clarifies the requirements and expectations with the respective Stream-Aligned Team and makes its philosophy transparent. It must then clarify that APIs are the right technical solution for the tasks of the Stream-Aligned Team. It often turns out that this is not the case at all. However, if this is the case, the necessary workshops and work sessions can then be planned together in the way that best suits the Stream-Aligned Team's day-to-day work. Once the workshops have been held, the Enabling Team systematically collects feedback and integrates the Stream-Aligned Team into an API community, where team members can share problems, challenges and successes with other development teams. 
It is important that no Stream-Aligned team is forced into enabling if it does not want to. However, experience shows that good enabling is spread by word of mouth among teams. This automatically increases the demand for enabling.

## Platform Aspects
In order to work effectively and efficiently as an API Enabling Team, the general process of how APIs are created in the organisation must be as lean and clear as possible. The team must be enabled to improve the process together with other teams. It is also a good idea to establish an API Platform Team if many parts of the existing process are not yet automated. Automated API operations support the Enabling Team in transferring knowledge more quickly and making the existing services known to the Stream-Aligned Teams rather than reinventing the wheel for each individual Stream-Aligned Team. At the same time, the offered services help to reduce the cognitive load for the Stream-Aligned Teams, who already have to learn a lot of new things during the enabling process.

## Prerequisites for success
In order for the introduction of an API Enabling Team to be successful, a number of prerequisites must be met. Firstly, it is important that the team has the support of management. As the Enabling Team itself does not write any software and therefore does not deliver any demonstrable products, management must be convinced of its importance and also use the right metrics for evaluation. The number of APIs created, for example, which is often used as a metric, is only meaningful to a limited extent, as it neither says anything about the quality of the APIs nor takes into account teams for which an API was not a sensible solution.

A successful API Enabling Team also works with many other teams, mainly Platform, Complicated Subsystem and other Enabling Teams (e.g. authorisation teams, integration teams, etc.). These teams must be prepared to exchange the necessary information with the API Enabling Team which they share with the Stream-Aligned Teams in a condensed and processed form.

Another important prerequisite for the success of an API Enabling Team is to motivate the Stream-Aligned Teams to collaborate with them. This is difficult to achieve if the costs for the Enabling Team are passed on internally to the Stream-Aligned Teams. The enabling should be free of charge for all teams and it should be as simple as possible to make use of it.

## Conclusion
An API Enabling Team, based on the team types introduced in Team Topologies, successfully supports Stream-Aligned Teams in publishing their first API following a well-established approach. An organisation that relies on an API Enabling Team can ensure that high-quality APIs are created, which contribute to the business strategy and success of the organisation. The Enabling Team achieves this through a customised workshop concept, which ensures that Stream-Aligned Teams learn and master all important tasks related to the creation, development and publication of APIs.

The success of an API Enabling Team is closely linked to the support of management, the willingness of other central teams to work together and the motivation of the Stream-Aligned Teams. It is only when these requirements are met that the API Enabling Team can become a critical factor in the success of your business.

Charge your APIs Volume 29: API enabling as a factor for success

In today’s rapidly evolving, data-driven world, organisations face an increasingly complex challenge: how to design, implement, and manage data interfaces that meet both immediate operational demands and long-term strategic business objectives. A data interface is a defined connection point where data is exchanged between systems, applications, or components. It specifies the rules, formats, and protocols needed for smooth communication and interoperability, acting as the backbone of modern data ecosystems.

Organisations became aware of data being central to decision-making, driving innovation, and leading to competitive advantage. However, clarity in navigating the myriad possibilities of data interface design is often elusive, particularly for software architects who must bridge the divide between technical solutions and business outcomes.

This is where the Data Interface Quadrants (DIQs) framework steps in as a transformative tool. The DIQs provide a structured, visual approach to understanding and categorising data interfaces, empowering architects, development teams, and decision-makers to navigate complexity with confidence. By distilling the complexities of data interfaces into an intuitive format, DIQs offer insights that drive better strategic alignment and informed decision-making.

In this blog post, we unpack the potential of the DIQs and explore their value through two key lenses: the enterprise architect, who focuses on long-term organisational strategy, and the solution architect, who addresses project-specific implementation challenges. Together, these perspectives reveal how DIQs enable them to collaborate effectively to create and modernise robust, future-proof data ecosystems. The DIQs are more than just a diagram - they are a compass for navigating the trade-offs inherent in data interface design.

## Introducing the DIQs

![data-interface-quadrants-plain.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/ojiHNTPMR7uzJZM3aCte)

The DIQs offer a structured way to categorise data interfaces along two primary dimensions: the extent of data processing and the scope of its consumers. The horizontal axis of the DIQs focuses on the degree of data aggregation or transformation. On the left side, it emphasises raw data, where minimal or no transformation is applied, catering to use cases that require base-level data in its original form. On the right side, the framework highlights aggregated or transformed data, which is designed to support specific use cases or provide enhanced service-level functionality.

The complexity of data processing increases as you move from raw data to aggregated or transformed data. Raw data requires minimal intervention and is typically faster to provide but may demand more effort from consumers to extract meaningful insights. On the other hand, aggregated or transformed data involves additional processing steps, such as combining datasets, applying business logic, or reformatting data to fit specific use cases. While this adds a layer of complexity to the creation and maintenance of the interface, it can significantly reduce the effort required by consumers, making the data more immediately usable for their needs.

The vertical axis in the DIQs addresses the scope of consumers who interact with the data. At the bottom, the focus is on product-internal or usecase specific interfaces. These are typically consumed by a single team or a well-defined, technical audience with shared expertise. Conversely, the top of the DIQs shifts attention to external and reusable interfaces, which are designed to accommodate multiple teams and diverse audiences. These can include individuals with varying technical skills or even unknown consumers.

The framework defines four quadrants, each representing a specific type of data interface. The **Data Link** quadrant, located at the bottom-left, represents raw data interfaces used within a single product or team. These interfaces are simple and direct, often involving minimal transformation and primarily serving technical audiences with clear, shared requirements. The **Backend for Fronted (BFF)** quadrant, positioned at the bottom-right, includes usecase specific interfaces that offer aggregated or transformed data. These interfaces are tailored for particular application needs and are optimised for efficiency within a single product or team context. Development teams usually design and implement both types of interfaces with a strong focus on the technology.

At the top-left, the **Platform Data Product** quadrant represents raw data interfaces that are external and reusable. These interfaces provide foundational data in its original form to a broad audience, including unknown consumers or those with varying technical backgrounds. They prioritise reusability and scalability over specificity. Finally, the **Composition Service** quadrant at the top-right captures external and reusable interfaces offering aggregated and transformed data. These interfaces are designed to meet diverse use cases and are consumed by multiple teams, making them the most complex to build and maintain but the most versatile in addressing organisational needs. 
The broader audience requires development teams to design and implement both types of interfaces with a strong focus on the business requirements instead of technology.

## The Implications of an API-First Business Model

As organisations strive to become API-First, APIs become the relevant business model for them. Therefore, the focus for data interfaces shifts more towards the top quadrants of the DIQs. Instead of building product internal and usecase specific interfaces, development teams have to focus on building more external and reusable interfaces for larger audiences which also results in a higher business impact. However, if the team’s experience so far lies in technology building **Backend for Frontend** interfaces, they might not be aware of what’s needed to build a successful **Composition Service** aiming for business impact. Enabling and platform teams can empower development teams supporting the shift from APIs as solely technical interfaces to business relevant products. The DIQs can help visualise such strategic decisions and their implications on data interface design.

![data-interface-quadrants-api-first.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YzoIBqRdT2z3FPXec4Dm)

## Enterprise Architects: The DIQs as Strategic Lens

Enterprise architects operate at the intersection of business strategy and technological implementation, thereby also shaping the overarching data architecture. The DIQs equip them with a holistic perspective, enabling strategic oversight that bridges the gap between organisational objectives and technical realities.

Using the DIQs, enterprise architects can categorise and evaluate interfaces, prioritising investments where they matter most. For instance, interfaces that are product internal and usecase specific, offering aggregated or transformed data, can enhance scalability, while those designed for external and reusable purposes, providing raw data, present opportunities for optimisation as they require minimal data processing but have a high impact on the business due to a broad audience. The DIQs also help identify bottlenecks and redundant systems, guiding efforts to streamline processes and enhance integration.

Moreover, the DIQs serve as a communication tool by presenting data interfaces in a clear, visual format. Enterprise architects can use it to facilitate discussions with stakeholders to align technical initiatives with broader business goals. For example, in a digital transformation project, the DIQs help to spotlight interfaces that require redesign or investment, ensuring decisions made today support future growth. In addition, enterprise architects can identify development teams needing more support from enabling and platform teams to make sure that redesign and investment are successful.

## Solution Architects: Bridging Strategy and Execution

Solution architects bring ideas to life by designing systems that meet immediate project demands while adhering to broader architectural principles. The DIQs help them navigate competing priorities, offering a structured lens to evaluate and implement data interfaces effectively.

When integrating systems, for example a CRM platform, solution architects face the challenge of balancing rapid delivery with long-term scalability. On one hand, there is pressure to deliver functional solutions quickly to meet immediate business needs, such as enabling a sales team to access critical customer data in real time. On the other hand, these interfaces must also be designed with future growth and integration in mind, ensuring they support evolving requirements, additional systems, and increased data volumes over time. This balancing act is further complicated by competing priorities. Rapid delivery often favors lightweight and minimally complex interfaces that can be implemented quickly with limited resources. However, these interfaces may lack the robustness or flexibility required to integrate seamlessly with future systems or handle growing organisational demands. Conversely, designing for long-term scalability might require additional time and effort upfront, such as implementing aggregated or reusable data interfaces, which can delay initial delivery but significantly enhance the system’s overall resilience and adaptability. 

By mapping options within the DIQs, solution architects gain a structured way to evaluate and align their decisions with both immediate project goals and overarching enterprise strategies. For example, lightweight interfaces may expedite delivery, meeting urgent deadlines, but must also be assessed for compatibility with future integrations to avoid costly redesigns. Using the DIQs, they can identify where compromises are necessary and where investments in scalability will pay off, ensuring that short-term achievements do not undermine long-term success. 

## Collaboration Through DIQs: Bridging Roles

The DIQs transcend individual roles, fostering collaboration between enterprise and solution architects. The quadrants serve as a ubiquitous language, bridging these perspectives to create a cohesive data strategy.

Workshops or planning sessions anchored in the DIQs can align priorities, ensuring tactical decisions contribute to long-term goals. This iterative collaboration not only enhances interface design but also builds trust and synergies between teams. In addition, the DIQs can be a useful tool to communicate interface requirements to development teams and make sure everyone involved has the same understanding of the expected outcome. Especially, if concrete guidelines and best practices for each quadrant are provided.

## Conclusion

The Data Interface Quadrants framework (DIQs) is more than a tool - it can serve as a strategic enabler. By mapping critical dimensions of data interfaces into a visual structure, DIQs empower architects and organisations to align technical decisions with business objectives and prioritise investments that drive value. Enterprise architects gain an additional strategic lens for long-term planning, while solution architects use DIQs to ensure project success aligns with broader goals and development teams understand what’s expected from them.

Above all, we created the DIQs to foster collaboration, bridging the gap between strategy and execution. They provide a shared framework that enables architects to navigate complexity, drive innovation, and build resilient data ecosystems. As organisations face the challenges of integration, scalability, and governance, DIQs emerge as an essential resource for clarity, direction, and communication.

Explore the DIQs in your organisation, in your team, or in your project. Use them to analyse, optimise, and elevate your data strategies. Share your thoughts and experiences to help improve them and make the DIQs even more useful in our fast-changing, data-driven world. We’re excited to hear your stories!


Introducing Data Interface Quadrants (DIQs)

*Many companies have high hopes for API platforms, expecting them to facilitate integrations, promote reuse and future-proof the company technologically. Initially, a lot of things seem to go well: the platform is established, the first projects have been successfully implemented and the team around the API platform builds knowledge. However, over time, a recurring pattern emerges. The demand for new APIs declines, existing APIs are rarely reused, and the API team is increasingly perceived as a bottleneck. APIs are usually only created when needed for a project – often under time pressure and without a long-term strategy.*

In this blog post, we use the terms *integration* and *API* and define them as follows:

> **Integration**: refers to the linking of different systems or applications to enable seamless data exchange for automated processes.

> **API**: is a defined interface that allows applications to communicate with each other.

The API team recognises these challenges and actively works to counteract them. They organise workshops, define best practices and initiate platform optimisations, such as developing self-service functionalities. However, addressing structural problems proves difficult with these efforts alone. As long as integrations are handled in isolation within individual projects and there is no overarching API strategy, the platform’s effectiveness remains limited. APIs are created and discarded without delivering long-term value.

## Why simply providing APIs doesn't guarantee their effective utilisation
Many organisations underestimate that building an API platform is just the first step. The real added value only comes when APIs are not only provided, but also actively used and further developed. However, many organisations fail at this stage. The reasons are numerous: often, they lack an overarching API strategy that promotes a consistent and reusable API landscape.

A key problem is that many view APIs as merely a technical necessity rather than a business enabler. When developed solely to meet immediate interface needs, they lack a strategic component.  Often, APIs are created reactively within specific projects to quickly establish integrations.  This approach overlooks whether an API could serve other use cases and be reusable, whether it can be extended long-term, or whether it provides sustainable value for the company.

 This project-driven development leads to APIs being considered only for their immediate use case. Consequently, organisations end up with a collection of selective integrations between exactly two systems. While these integrations serve their short-term purpose, they eventually create a fragmented architecture that is difficult to maintain.

 The role of the API team poses a problem as well. Many view it purely as a "service provider" that develops integrations on demand. Often, the team gets involved late in the project, after the basic requirements have already been defined, leaving no opportunity to optimise the API design for reuse. Consequently, the API team focuses solely on implementation and cannot influence the API landscape strategically. Additionally, many development teams lack a thorough understanding of good API design due to the absence of systematic support or enablement processes.

 Another problem lies in the perception of the platform itself. Many developers view it as a requirement to be met rather than an enabler of modern integration. The focus remains on the technology rather than the actual added value of APIs. Instead of leveraging the platform to improve integrations long-term, developers often use it merely as a means for selective integration. Consequently, APIs are created out of immediate necessity rather than being recognized as valuable tools for optimising business processes.

At the same time, API platforms can be challenging and cumbersome to work with. They typically cover only a few standard integration cases and offer low levels of automation without significant customisation. This complexity frequently discourages development teams from utilising them.

Many also misunderstand API governance. While companies often have technical standards, they lack metrics to evaluate the actual benefits and effectiveness of APIs. They rarely ask questions like, "Is an API actually being used?", "How long does it take for development teams to successfully use it?", or "Will the API help reduce integration efforts in the future?". Without this data, determining whether an API truly delivers added value or is just another forgotten technical interface remains unclear.

Ultimately, simply providing APIs is not enough. They must be designed to deliver long-term value, be efficient to use, and align strategically with the enterprise architecture. Without this, an API platform becomes a well-intentioned but ineffective tool, perceived as a hurdle rather than an enabler.

## API Effectiveness through Team Topologies

Effective APIs depend not only on technology but also on the right organisational structure. Companies must transition from project-driven API development to strategic API products. The concept of **team topologies** offers a clear framework for achieving this.

<img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YcV9FmkrQOyVUqMeOZpn" width="400" height="500"/>

*Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.*

Team Topologies defines four different team types, with three being particularly relevant in the API context: Platform Team, Enabling Team and Stream-Aligned Teams.

A **Platform Team** forms the backbone of the API platform. It provides the infrastructure, ensures a good developer experience, promotes API reusability, and offers self-service functions with a high degree of automation. Instead of limiting its role to governance or tooling, the platform team should focus on making APIs usable and developing an API strategy with measurable goals.

An **Enabling Team** helps other teams view APIs as products. It assists development teams in establishing best practices, promoting reuse, and designing APIs for a broader user base. Without this support, API development often remains isolated and ineffective.

The biggest change, however, occurs in **Stream-Aligned Teams**. These teams take ownership of their APIs and develop them with a long-term product perspective. They no longer build APIs just to complete a project but to create sustainable value. This approach establishes true API ownership, directly impacting effectiveness. When teams fully own their APIs, they consider long-term use, extensibility, and quality. This results in better-designed, reusable, and economically sensible APIs.

A key advantage of Team Topologies is the shift from isolated point-to-point integrations to strategically planned API products. Teams must build APIs with a long-term perspective, creating a clear roadmap and defining metrics to measure success. Adoption rate, time-to-first-success, and reuse rate are essential for understanding whether an API is actively used and reused or merely another technical artefact.

## Conclusion: API strategy is crucial for success

An API platform alone cannot achieve sustainable integration success. APIs must be effectively used and further developed, not just provided. A clearly formulated and implemented strategy is crucial; otherwise, the API platform remains a technical necessity used out of obligation. With the right team structure, however, it becomes a true enabler for digital transformation.

Achieving API effectiveness requires more than good technology; it involves viewing APIs as valuable assets and organising their development to ensure they contribute to corporate strategy over the long term. To maximise the benefits of an API platform in your organisation, focus beyond technology and emphasise the interaction between teams, processes, and strategy.


When your API platform lacks the desired impact

In many projects, teams create technically functional APIs without focusing on business requirements or future use. Development often still follows a classic pattern: assign a ticket, implement the interface, and close the ticket. What's missing is the perspective of those who will actually use these APIs. This is where API Thinking comes in, as a mindset for consistently designing APIs in a user-centric and strategic way. 

Inspired by [design thinking](https://www.nngroup.com/articles/design-thinking/) and the [design sprint](https://www.thesprintbook.com/the-design-sprint), API Thinking reflects our practical experience. Together with input from [Dr. Martin Kiel](https://www.the-black-frame.de), we developed API Thinking to look beyond technical implementation and treat APIs as consciously designed products with value, purpose, clear responsibilities, and a clearly defined target audience.

## What is API Thinking?

API Thinking challenges you to view APIs not just as technical components for system integration but as part of a broader context. At its core, it focuses on addressing the needs of API consumers from the very beginning. These consumers could be development teams, specialist departments, or external partners. Yes, APIs are interfaces, but they also provide access to business functions, data, and processes. APIs sit at the intersection of technology, technical expertise, and user expectations. They must solve problems and deliver real value. Anyone who designs APIs must understand who will use them, in what context, and what makes usage easy and valuable. This demands design decisions not only on a technical level but also on a strategic level. 

APIs do not exist in a vacuum; they operate within data models, processes, and organisations. API Thinking takes this interdependence seriously, treating APIs as products that teams must develop, maintain, and enhance. It also places responsibility for their quality, usability, and long-term viability firmly in the hands of their creators.

## From thinking to action: The model behind API Thinking

API Thinking doesn’t impose a rigid process. Instead, it offers a model for an iterative approach. A structured framework makes the idea tangible:

![en_api_thinking.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cma0q07fegdmc07um5e81egyj)

Start by understanding your stakeholders. Who uses the API? For what purpose? What does a good user experience mean to them? Rather than describing audiences in abstract terms, you gain concrete insights through structured workshops, interviews, or analysis of existing usage patterns. 

Based on this understanding, define which data plays a role, not technically, but in terms of content. What do users really need? How important are quality and timeliness?

Only then should you design the API: Which interaction patterns fit? What level of detail makes sense? How will the interface remain consistent and understandable? 

Implementation follows these considerations and not the other way around. And it doesn’t end there: ideally, stakeholders validate the API at an early stage, teams actively seek feedback, and they feed new insights back into the process. This approach delivers not just a working endpoint, but an API that users can actually use and find valuable.

## Distinction: What API thinking is not 

Many confuse API Thinking with concepts like API First or API Management, but they differ clearly. API Thinking isn’t a method, a toolset, or an architectural principle, it’s a way of thinking. 

While API First means prioritising APIs organisationally from the start, API Thinking provides the content foundation for creating a concrete API. It looks at APIs from a product perspective: Why do we need this API? Who benefits? How should we design it to deliver real value?

API Design First calls for consciously designing APIs before implementing them, aiming for reusability and consistency. But even then, without understanding real users, APIs often end up technically sound but practically irrelevant. 

API Management focuses on operating, monitoring, securing, and scaling APIs. Important, but only after building the API. API Thinking, by contrast, starts much earlier: it questions whether and how an API even makes sense.

## What API thinking means for different roles 

API Thinking operates on multiple levels and impacts more than just developers and architects. 

For development teams, it means not just implementing APIs but as well shaping them. Teams take responsibility for intelligibility, consistency, and maintainability, while actively engaging with users to understand their needs.

For product managers, APIs become visible elements of the value chain with their own users, success metrics, and strategic relevance. APIs cease to be mere technical by-products and become deliberate parts of the product portfolio, capable of contributing measurably to business success.

Architects can apply API Thinking to structure systems more effectively, clarify responsibilities, and reduce complexity. For example, establishing clearly defined technical contracts between domains.

For all business roles, API Thinking with the right mindset opens doors: to partnerships, new digital revenue models, and more efficient processes. The focus shifts from APIs themselves to what they enable.

## From concept to business value

APIs reveal their impact not through technical cleanliness alone but through real-world application. APIs become true business enablers when they accelerate processes, simplify integration, or open new markets. But this only works if users adopt them. Good design makes adoption possible. By understanding user needs, teams build APIs that feel understandable, relevant, and trustworthy. This saves effort, increases adoption, and improves overall product quality. API Thinking makes this connection visible. It links technical interfaces with strategic goals and ensures a consistent focus on the "why". Whether for internal or external users, humans or machines.

## Conclusion

API Thinking isn’t a framework, a template, or a toolbox. It’s a mindset that refuses to see APIs as technical ends in themselves but instead views them as part of a bigger idea: empowering users, creating value, and connecting systems. Those who build APIs merely to meet technical needs waste their potential. Those who understand how and why users engage with APIs build interfaces that work, grow, and remain relevant.

The critical questions when designing APIs aren’t "Which method do we use?" or "Which tool do we choose?" Instead, they are: "Who are we doing this for?", "What problem are we solving?", and "How will our interface stay relevant long-term?"

**API Thinking won’t hand you ready-made answers. But it will help you ask the right questions.**

API Thinking

*API Discovery refers to the ability to identify, catalog, and document all APIs used within an organisation with the goal of making them discoverable and usable while strengthening governance. There are countless tools that support API discovery. Typically, they are called developer portal, catalog, or marketplace. With this abundance of different names, it's easy to lose track. What should an API discovery tool actually accomplish? And which name is right for which type of tool?*

## Developer Portal

Developer portals provide access to APIs as self-service, seamless onboarding, good documentation, and integration support. Their main target audience is technical, which is also represented by the name.

The typical functions supported by a developer portal are:
- API documentation
- Interactive API exploration and sandboxes
- SDKs, sample code, Bruno / Postman Collections
- Authentication & API key/token management
- Support for development teams

A good developer portal helps development teams understand how to use an API. It reduces the time needed for integration, even during first use. Additionally, it increases the adoption rate for APIs through the self-service offering.

## Catalog
Catalogs organise and manage APIs for better discoverability and consistency. Their main target audience is usually technical and internal to the company, as they provide a complete overview that is often not necessary for external users.

The typical functions supported by a catalog are:
- Centralised API inventory
- Search, filtering & categorisation
- Visualisation of API metadata
- Governance and policy enforcement
- Standardisation of API contracts and dependencies

A good catalog leads to APIs being reused because they are easier to find. This also reduces duplicates and API sprawl. It promotes governance through the enforcement of policies and consistency across team boundaries. Through the centralised API inventory, a catalog also enables standardisation of API contracts and dependencies.

## Marketplace

Marketplaces connect API providers with their consumers and promote monetisation and partnerships. Their target audience is more diverse and includes people with both business and technical focus. Marketplaces are usually offered externally and show only a selected subset of the API landscape.

The typical functions supported by a marketplace are:
- Ratings, reviews, and community engagement
- Billing mechanisms and revenue sharing
- Legal agreements and transparent SLAs
- Onboarding of providers and consumers
- Pricing models for APIs

A good marketplace extends API usage beyond internal teams. It primarily supports the commercialisation and monetisation of APIs. At the same time, it must enable decision-makers to effectively monitor their API usage.

## Consumer Needs

Discovery tools are the window to an organisation's API landscape. The most important stakeholders are the consumers of the APIs, who typically have four needs:
- Discoverability: Which API is right for my use case?
- Onboarding: How can I get started immediately?
- Integration: Is the API stable, reliable, and secure?
- Business alignment: What does using the API cost me?

The presented types of discovery tools focus on different needs:

<style>
  .api-table {
    width: 100%;
    border-collapse: collapse;
    margin: 20px 0;
    border-radius: 8px;
    box-shadow: 0 0 20px rgba(0, 0, 0, 0.1);
    overflow: hidden;
  }
  
  .api-table thead {
    background-color: #007286;
    color: white;
  }
  
  .api-table th {
    padding: 12px 15px;
    text-align: left;
    font-weight: bold;
    text-transform: uppercase;
    font-size: 14px;
    letter-spacing: 0.5px;
  }
  
  .api-table td {
    padding: 12px 15px;
    border-bottom: 1px solid #eee;
  }
  
  .api-table tbody tr:nth-child(even) {
    background-color: #f9f9f9;
  }
  
  .api-table td:first-child {
    font-weight: bold;
    color: #333;
  }
</style>

<table class="api-table">
  <thead>
    <tr>
      <th>Consumer Need</th>
      <th>Developer Portal</th>
      <th>Catalog</th>
      <th>Marketplace</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Discoverability</td>
      <td>❌ Not the primary focus</td>
      <td>✅ API metadata, categorisation, taxonomy</td>
      <td>✅ APIs listed based on pricing or ecosystem fit</td>
    </tr>
    <tr>
      <td>Onboarding</td>
      <td>✅ Tutorials, interactive documentation, SDKs, sandboxes</td>
      <td>❌ Not a core function</td>
      <td>❌ Limited to API descriptions</td>
    </tr>
    <tr>
      <td>Integration</td>
      <td>✅ Self-Service</td>
      <td>❌ Primarily a governance tool</td>
      <td>❌ Pre-built integrations, API contracts</td>
    </tr>
    <tr>
      <td>Business Alignment</td>
      <td>❌ Mostly developer-centric</td>
      <td>✅ Supports API lifecycle governance</td>
      <td>✅ Enables monetisation and partnerships</td>
    </tr>
  </tbody>
</table>

## A Tool for API Owners

In addition to developer portals, catalogs, and marketplaces, API registries are also emerging. Registries manage API artefacts to create transparency throughout their lifecycle. Their main target audience is API owners.

The typical functions supported by a registry are:
- Versioning & change tracking
- Central storage of API definitions
- Schema and dependency detection
- Lifecycle management

A good registry ensures transparency of the API lifecycle. It improves collaboration between teams and provides structured access to all API artefacts. In contrast, Portals, catalogs, and marketplaces focus on the consumption of APIs. The registry is thus the central and authoritative data source for all discovery tools used internally and externally.

![APIAccessChannels.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb5brkk4ogkd06ug221nqhee)
*The API registry serves as the central storage for API artefacts. From here, APIs are synchronised to various access channels such as developer portals, catalogs, and marketplaces, where they are made available to different target groups of consumers.*

## Conclusion

Different API discovery tools also have different focuses. Depending on whether the audience is purely technical or should include business stakeholders, a different tool should be used. The different tool types also have various tasks. While registries and catalogs tend to regulate the lifecycle of the API and provide an overview of all APIs, developer portals and marketplaces focus on the consumption of APIs.

![DevPortal Quadrants - en.jpg](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmb5bot6yodxn06ugxjvm1616)
*Overview of the typical target audience (horizontal axis) and the typical task (vertical axis) of different tool types for API discovery.*


API Discovery with Developer Portals, Catalogs and Marketplaces: Finding the Right Tool for API Consumers

Hier gibt's noch mehr spannende Infos von uns für euch

BLOG

codecentric Blog

Auf unserem Blog findest du viele Artikel zu Tech-Themen von unseren Mitarbeitenden. Vielleicht ist auch hier ein Thema für dich dabei. Schau gerne mal rein!

WISSENS-HUB

Events – codecentric mittendrin

Community

Softwareentwicklung

Kultur

Der Softwerker

Auf dem Prüfstand: Wie JavaScript-Tests wieder lesbar werden | codecentric AG

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Auf dem Prüfstand: Wie JavaScript-Tests wieder lesbar werden

Aus dem Inhalt:

Hier gibt's noch mehr spannende Infos von uns für euch

codecentric Blog

Events – codecentric mittendrin

Der Softwerker

Jetzt für unseren Newsletter anmelden