Publications

API Governance needs Memory

From API Chaos to Business Value (together with Miriam Greis)

Interface standards as a strategic lever

API Thinking

Introducing Data Interface Quadrants (DIQs)

When your API platform lacks the desired impact

Enterprise Integration Patterns Reloaded Part 1

Charge your APIs Volume 36 - Trends for 2025

Charge your APIs Volume 35 - Going Beyond OpenAPI: Using API Value Proposition Canvas and Archimate for Business-Oriented API Descriptions

Charge your APIs Volume 34 - From Christian Posta’s Omni-Directional API Management to a Specification Framework: Bridging Flexibility and Governance in the API Era

Charge your APIs Volume 30 - Gateway to Success: Understanding and Choosing the Right API Gateway for Modern Architectures

Charge your APIs Volume 28: Empowering application and data integration by fulfulling organisational needs

Data for the Masses Volume 2: Data Products, Data Contracts and API Contracts

Charge your APIs Volume 27: Transition from COE/C4E to an API Platform Team

Charge your APIs Volume 26: Choosing the Right API Development Strategy: A Guide to API Design First vs. Code First Approaches

Charge your APIs Volume 24: Harmonizing API Strategy and Team Dynamics - Integrating API Thinking, Federation, and Team Topologies for Digital Excellence

Charge your APIs Volume 22: Mastering the Art of API Federation

Data for the Masses Volume 1: The Digital Product Passport - A Key Element for Sustainable and Transparent Business Practices

Charge your APIs Volume 21: Introduction to OpenTelemetry in the Context of API Operations

Charge your APIs Volume 20: Navigating the OpenAPI Initiative Workflows Specification - Enhancing API Ecosystems

Charge your APIs Volume 19: Understanding Problem Details for HTTP APIs - A Deep Dive into RFC 7807 and RFC 9457

Charge your APIs Volume 18: Unleashing the Power of APIs - From Interfaces to Products

Charge your APIs: NordicAPIs Platform Summit Edition - API first ... not!

Charge your APIs Volume 17: Using Protobuf for Defining gRPC Services - A Guide to Creating Stable and Efficient Service Definitions Part 2

Charge your APIs Volume 16: Using Protobuf for Defining gRPC Services - A Guide to Creating Stable and Efficient Service Definitions Part 1

Charge your APIs apidays Edition: Unlocking Collaboration with Internal Developer Portals & Marketplaces - Democratizing API Access

Charge your APIs Volume 15: API Gateways - Navigating the Agony of Choice and the Role of Evolutionary Architectures

Charge your APIs Volume 14: Is API Management Really Dead? Understanding the Role of APIOps

Charge your APIs Volume 13: Data meets APIOps

Charge your APIs Volume 12: Fern - Streamlining REST API Development 🌿

Charge your APIs Volume 11: Taxi Language - Building APIs with Precision and Ease

Charge your APIs Volume 10: Crafting API Definitions with TypeSpec

Charge your APIs Volume 9: Perfecting APIOps - API Monitoring with Checkly

Charge your APIs Volume 8: Expanding APIOps - API Portals and Marketplaces

Charge your APIs Volume 7: Enhancing APIOps - API Diffing with Tufin/oasdiff

Charge your APIs Volume 6: Perfecting Your APIOps - Harnessing the Power of k6 for API Testing

Charge your APIs Volume 5: Taking APIOps with Continuous Deployment to the Next Level

Charge your APIs Volume 4: Streamlining API Operations with Continuous Integration

Charge your APIs Volume 3: Optimizing API Testing with Contract Testing

Charge your APIs Volume 2 - Guide your teams to achieve value-adding APIs

Charge your APIs Volume 1 - Build a documentation system with mkdocs

The state of APIOps and the deployment of API definitions

API architecture – The path towards evolutionary architectures

API consumers – between search and feedback

Platform Engineering – A primer

API Experience – How API products get ready for digital markets

AsyncAPI specification updates

From specification to infrastructure – automated API deployments

Getting project documentation done with Azure DevOps – Diagrams with PlantUML

AsyncAPI – Documentation of event- and message-driven architectures

API first – now even faster!

API Gateway and Service Mesh in the context of service connectivity

APIOps – Automated processes for even better APIs

Offloading and more from Reedelk Data Integration Services through Kong Enterprise

Creating integration flows with the Reedelk Data Integration Platform

API as a Product insights

Chaos Engineering GameDay

Agile, oven-fresh documentation. Part 3: Tested requirements with JBake

Agile, oven-fresh documentation. Part 2: PlantUML with JBake

Agile, oven-fresh documentation. Part 1: JBake

Data Products, Data Contracts und API Contracts

Die Verwendung von Protobuf zur Definition von gRPC-Services

API-Consumer - Im Spannungsfeld von Suchen und Feedback

API Experience

Von der Spezifikation zur Infrastruktur - Automatisierte API Deployments

AsyncAPI - Dokumentation von Event- und Message-getriebenen Architekturen

API first - jetzt noch schneller!

APIOps - Automatisierte Prozesse für noch bessere APIs

Kontinuierlichees API-Design und -Entwicklung

Die Zukunft von VoiceUIs

Hey Duke, let's talk! - Ein VoiceUI-System auf Basis der JVM erstellen

Continuous Documentation

Governance ohne Gedächtnis ist keine Governance: wenn alles geprüft und trotzdem nichts gelernt wird

In der letzten Folge von „Schöne neue alte API-Welt“ ging es darum, wie Architektur durch automatisierte Prüfungen operativ wirksam wird. Regeln werden maschinenlesbar, Builds werden rot, Architektur verlässt das Papier und landet in der Pipeline. Auf den ersten Blick wirkt das wie ein gelöstes Problem. Man definiert Regeln, lässt sie automatisiert prüfen und stellt so sicher, dass sich alle daranhalten. Viel strukturierter geht es kaum. Und tatsächlich sieht Governance in vielen Organisationen genau so aus. Es gibt Style Guides, sauber definierte Regelwerke und funktionierende Checks in den Pipelines. Alles wirkt kontrolliert und unter Kontrolle. Und trotzdem bleibt oft ein ungutes Gefühl. Denn, obwohl alles geprüft wird, scheint sich erstaunlich wenig zu verbessern.

Wenn der Build rot wird, weil Architektur verletzt wurde

Montagmorgen. Ein Team tätigt einen Merge für einen scheinbar harmlosen Pull Request. Die Pipeline startet, die Tests laufen durch, alles sieht gut aus. Und dann wird der Build rot. Nicht wegen eines fehlgeschlagenen Unit-Tests. Nicht wegen eines Security-Scans. Sondern wegen einer Architekturregel.

TOGAF ist nicht das Problem - Warum Enterprise Governance immer wieder an sich selbst scheitert

TOGAF ist in vielen Enterprise-Organisationen zu einem roten Tuch geworden. Kaum fällt der Begriff, entstehen Bilder von dicken Dokumenten, endlosen Reviews und Architekturgremien, die Entscheidungen verzögern statt ermöglichen. Die Kritik wirkt oft reflexhaft und dennoch speist sie sich aus realen Erfahrungen. In einer Zeit, in der Architektur zunehmend als Navigationssystem verstanden wird, das Orientierung in dynamischen Umgebungen geben soll, scheint TOGAF für viele wie ein Relikt aus der Ära der statischen Landkarten. Doch diese Ablehnung greift zu kurz. Denn selten scheitert TOGAF an seinem Inhalt. Es scheitert an der Art, wie Organisationen Governance denken und leben.

Architecture neu denken - Von Landkarten zu Navigationssystemen

Diese Artikelserie begann mit Themen rund um APIs, mit Strategien, Missverständnissen, Mustern und der Frage, wie Schnittstellen zum Fundament digitaler Ökosysteme werden. APIs waren lange der Ausgangspunkt, um über Strukturen, Zusammenarbeit und Wertschöpfung zu sprechen. Doch im Laufe der Zeit zeigte sich, dass sie nur der sichtbare Teil einer tiefer liegenden Entwicklung sind. Hinter ihnen stehen grundlegende Fragen nach der Funktionsweise moderner Organisationen, nach Entscheidungsprozessen und nach der Fähigkeit, sich in einer zunehmend komplexen Umgebung zu orientieren.

Von Architekturpatterns zum Capability Thinking

In vielen Unternehmen werden Architekturentscheidungen noch immer primär aus einer technologischen Perspektive heraus getroffen. Ein bestimmtes Muster – etwa REST-APIs, Event-Driven Architecture oder gRPC – hat sich in einem Pilotprojekt bewährt, die Ergebnisse sind vielversprechend, und daraufhin wird beschlossen, dieses Muster im gesamten Unternehmen zum Standard zu erheben. Dieses Vorgehen ist nicht untypisch, es liegt sogar nahe: Wenn ein Werkzeug an einer Stelle funktioniert, warum sollte es nicht auch an anderer Stelle Nutzen stiften? Doch dieser Schluss greift zu kurz.

Warum Ihre API-Plattform ohne Betriebsmodell nur Fassade bleibt

Viele Organisationen haben in den letzten Jahren viel Zeit, Geld und Hoffnung in den Aufbau ihrer API-Plattform gesteckt. Manchmal steckt eine strategische Vision dahinter, manchmal einfach nur der Wunsch, das Thema „irgendwie in den Griff zu bekommen“. Die Tools sind eingerichtet, das Gateway steht, das Developer-Portal ist verfügbar. Und dennoch stellt sich oft ein Gefühl von Leere ein. Die Plattform ist zwar technisch verfügbar, aber sie verändert wenig. Sie wird kaum genutzt, bringt kaum Geschwindigkeit und liefert selten den erhofften strategischen Beitrag.

Warum moderne API-Initiativen mehr brauchen als ein Mythos

Um APIs erfolgreich in einer Organisation zu verankern, braucht mehr als ein gut klingendes Memo wie das Bezos-Mandat. Es braucht ein grundlegendes Umdenken, das sich mit dem Begriff API Thinking beschreiben lässt.

Verteilte APIs – Architektur oder Organisationsprinzip?

In der Welt der APIs tauchen regelmäßig neue Begriffe auf, die oft mehr Verwirrung stiften als Klarheit schaffen. Einer davon ist „verteilte APIs“. Während einige darunter eine technische Architektur verstehen, die Skalierbarkeit und Modularität fördert, setzen andere den Begriff mit GraphQL Federation gleich. In vielen Fällen bleibt jedoch unklar, was genau damit gemeint ist – und vor allem, welche organisatorischen Herausforderungen damit einhergehen.

API-Ownership: Warum Verantwortlichkeit der Schlüssel zu erfolgreichen APIs ist

APIs sind das Fundament moderner Softwareentwicklung. Sie verbinden Systeme, treiben Innovationen voran und unterstützen Unternehmen dabei, ihre digitale Transformation voranzutreiben. Doch trotz dieser Bedeutung scheitern viele API-Initiativen an einem zentralen Problem: fehlende Verantwortlichkeit. Wenn niemand für die Entwicklung, Pflege und strategische Ausrichtung einer API verantwortlich ist, bleibt ihr Potenzial oft ungenutzt. Dieser Artikel beleuchtet, warum API-Verantwortlichkeit – oder Ownership – unverzichtbar ist, welche Herausforderungen sie mit sich bringt und wie sie sich erfolgreich etablieren lässt.

Warum Database APIs schlechte API-Design-Prinzipien fördern

Aktuell erleben Database APIs eine Art Renaissance. Die Idee, direkt auf eine Datenbank über eine API zuzugreifen, scheint auf den ersten Blick ideal. In diesem Artikel möchte ich beleuchten, warum Database APIs langfristig mehr Probleme verursachen, als sie lösen, und wie sie die Prinzipien eines nachhaltigen und skalierbaren API-Designs untergraben. Außerdem erklären wir, warum bewährte API-Methoden der Schlüssel zu zukunftssicheren Systemen sind.

Die Trends in der API-Welt 2025

Das Jahr 2025 steht vor der Tür, und mit ihm kommen neue Trends in der Welt der APIs. Nachdem 2024 von der Nutzerorientierung geprägt war, verschiebt sich der Fokus nun wieder stärker auf die Bedürfnisse der Entwickler und die Steigerung der Produktivität. APIs entwickeln sich weiter, und die Technologien rund um sie werden immer leistungsfähiger. In diesem Artikel werfen wir einen detaillierten Blick auf die wichtigsten Trends im Bereich Architektur, Daten, API-Management, API as a Product sowie Integrationstechnologien für das Jahr 2025.

API Operations (APIOps): Ein Leitfaden für API-Beschreibungen

API Operations (APIOps) umfasst die Verwaltung von APIs (Application Programming Interfaces) über ihren gesamten Lebenszyklus. Dieser Prozess reicht von der Konzeption und Entwicklung über Tests und Bereitstellung bis hin zur fortlaufenden Wartung der API. Im Unterschied zu traditioneller Softwareentwicklung wird bei einer API zusätzlich zum Code eine standardisierte API-Beschreibung erstellt. Die Qualität und Richtigkeit der Beschreibung ist von enormer Bedeutung, um eine einfache Nutzung der API zu gewährleisten. Dieser Artikel fokussiert sich deshalb auf Continuous Integration (CI) und Continuous Deployment (CD) von API-Beschreibungen. In der dargestellten Beispiel-Pipeline werden Beschreibungen nach der OpenAPI-Spezifikation und GitHub Actions verwendet. Die vorgestellten Konzepte sind aber auch auf andere API-Standards und CI/CD-Werkzeuge übertragbar.

Schöne neue alte API-Welt: APIs brauchen Dokumentation

APIs sind unerlässlich in der modernen Softwareentwicklung, doch sie sind nur so gut wie ihre Dokumentation. Eine vollständige und aktuelle Dokumentation erleichtert Entwicklern die Nutzung und Integration von APIs, reduziert Missverständnisse und verbessert die Zusammenarbeit. Mit diesem Artikel möchte ich aufzeigen, wie ein lebendiger Dokumentationsraum geschaffen werden kann, der mithilfe von Werkzeugen wie Docusaurus und Prinzipien von APIOps eine kontinuierlich aktualisierte und hochwertige Dokumentation gewährleistet.

Schöne neue alte API-Welt - Von textuellen API-Beschreibungen zu programmatischen mit TypeSpec

Nach langer Zeit besuchen wir das Entwicklungsteam wieder, welches wir in den ersten Teilen unserer Artikelserie kennengelernt haben. Seitdem hat sich viel getan, nicht zuletzt durch die zahlreichen Beiträge zum Thema API, die in dieser Serie erschienen sind. Das Team hat eine spürbare Entwicklung durchgemacht und ist nun deutlich aufgeschlossener gegenüber API-Innovationen. Frühere Versuche, Schnittstellenbeschreibungen manuell zu generieren, erwiesen sich als suboptimal für die Effizienz des Teams. Die Suche nach einem programmatischen Ansatz, der es den Entwicklerinnen und Entwicklern erleichtert, qualitativ hochwertige Schnittstellenbeschreibungen zu erstellen, steht nun im Vordergrund.

Vermeiden von Breaking Changes mit 'API as a Product'

In der Softwareentwicklung sind APIs unverzichtbar geworden, um Systeme und Anwendungen zu verbinden. Sie sind entscheidend für Geschäftsstrategien und das Konzept „API as a Product“ gewinnt an Bedeutung, welches APIs als eigenständige Produkte sieht, die wertvoll entwickelt und verwaltet werden müssen. Breaking Changes in APIs stellen eine Herausforderung dar, da sie Integrationen stören können. Traditionelle Methoden wie API-Versionierung weisen Limitationen auf. Der Ansatz „API as a Product“, der Produktmanagementprinzipien auf APIs anwendet, bietet eine Alternative, die Nutzerbedürfnisse in den Mittelpunkt stellt und die Stabilität der Schnittstellen gewährleistet.

APIs in Transformationsprojekten: Aus der Perspektive von Architekten

Wenn man einmal Buzzword-Bingo bei Transformationsprojekten spielt, werden dort dann sehr häufig APIs oder Schnittstellen als wichtigstes Gut genannt. Meist enden die Gedanken auf der Ebene der Integration. Was Hersteller von Lösungen im Markt hoch erfreut zurücklässt. Eine Transformation bedeutet aber auch das Hervorbringen von neuen Ideen und Möglichkeiten, also Innovation. Deswegen möchte ich einen konkreteren Blick auf die Treiber für die Verwendung von APIs werfen. Hierbei geht es nicht um konkrete technische Implementierungen, sondern wie wir aus den verschiedenen Blickwinkeln eines Enterprise- und eines Lösungsarchitekten auf die kommenden Herausforderungen blicken.

API-Guidelines – ein Korsett für Innovation?

Im Juni 2022 teilte ich in dieser Kolumne meine ersten Gedanken über API-Richtlinien und hob ihre Rolle als Rettungsanker für ein organisationsweit vereinheitlichtes API-Design hervor. Die Essenz zog ich aus den Erfahrungen erster API-Enablement-Projekte, die damals den Grundstein für die Diskussion legten. Liebe Leser, lassen Sie uns nicht missverstehen: API-Richtlinien sind ein starkes Werkzeug im Arsenal jedes Entwicklerteams. Doch wenn es darum geht, die Innovation zu fördern – ein Hauptziel, das wir mit APIs verfolgen –, können diese Richtlinien manchmal eher ein Hindernis sein, statt eine Hilfe. Und genau das steht im Widerspruch zu ihrer eigentlichen Absicht der Unterstützung.

API-Trends 2024

Da das Jahr sich dem Ende neigt, ist es an der Zeit, einen Ausblick auf künftige Entwicklungen zu geben und einige mögliche Trends zu betonen. Was verstehen wir unter Trends im Kontext von APIs? Der Hype Cycle von Gartner liefert uns eine Vielzahl an potenziellen Ansatzpunkten. Welche Themen stehen also momentan bei Architekten und Entwicklern im Fokus?

Alle sprechen von API first – aber was meint das eigentlich?

In der digitalen Wirtschaft sind APIs – Application Programming Interfaces – zu einem integralen Baustein geworden. Sie verbinden Systeme, ermöglichen den Zugriff auf Daten und Dienste und sind daher unerlässlich für die Entwicklung skalierbarer und flexibler Anwendungen. Um diese Komponenten effektiv zu nutzen, sind gut durchdachte Strategien erforderlich. Eine solche Strategie, die in den letzten Jahren an Bedeutung gewonnen hat, ist die API-First-Strategie.

Sind wir schon auf einem Marktplatz oder noch immer in einem Portal? Oder doch dazwischen?

Die Darstellung von APIs erfolgt durch Portale, Marktplätze oder Hubs. Portale bieten Entwicklern Informationen und Tools, während Marktplätze APIs zur Vermarktung und Monetarisierung bereitstellen. Die Wahl zwischen Portalen und Marktplätzen hängt von den Anforderungen einer Organisation ab. Für den Schritt zu Public APIs eignet sich ein Marktplatz mit Fokus auf Marketing und Monetarisierung. Produkte werden in einem Katalog angeboten, in Kategorien eingeteilt und mit attraktiven Geschäftsmodellen präsentiert.

Integrationsplattformen

Neben den Thematiken rund um Gateways treffe ich in Gesprächen mit Kunden und eben auch in Projekten häufig auf Integrationsplattformen in den verschiedensten Ausbaustufen. Da diese Plattformen in API-Kontexten häufig eine Rolle spielen, möchte ich einen genaueren Blick auf diese werfen.

API-Gateway – Das unbekannte Wesen

Die zahlreichen Erfahrungen aus Projekten in Bezug auf API-Gateways zeigen deutlich, dass es wieder mal an der Zeit ist, sich mit dieser Komponente, die Teil des API-Spektrums ist, im Detail auseinanderzusetzen. Was ist eigentlich der Ursprung des API-Gateways? Warum ist es eine tragende Säule beim Design von Architekturen von APIs? Diesen und weiteren Fragen möchte ich im Laufe dieses Artikels auf den Grund gehen.

Von Schatten und Zombies – APIs in freier Wildbahn

Das – uns schon bekannte – Entwicklungsteam ist weiter damit beschäftigt, die Themen rund um APIs innerhalb der gesamten Organisation voranzutreiben. Vor kurzer Zeit kam das Business, in der Person eines Domänen-Owners, auf das Team zu. Man habe eine API entdeckt, die Daten aus der Domäne innerhalb der Organisation zur Verfügung stelle. Leider seien die bereitgestellten Daten mit Fehlern behaftet. Ebenso wenig wusste der Owner etwas über diese API, da diese wohl auch nirgendwo dokumentiert war. Da der Domänen-Owner von Erfolgen des Teams innerhalb der Organisation erfahren hatte, fragte er das Team, ob es ihn bei dieser API unterstützen könnte, damit diese unter anderem den Richtlinien der Organisation genügt und auch wieder Wert für diese stiftet.

Nicht alle APIs müssen Rest(ful) sein

Erneut besuchen wir unser Entwicklungsteam, welches diesmal eine schwere Nuss zu knacken hat. Denn die Ideen bei der Umsetzung einer API unterstützt durch Rest(ful) scheinen nicht so zu funktionieren, wie gewünscht. Leider erhalten die Konsumenten nicht die Daten, die sie benötigen, dafür aber viele Daten, die nicht gebraucht werden. Aus diesem Grund ist das Feedback der Konsumenten eher negativ. Aber was ist hier nun schiefgelaufen?

API-Guidelines, der Rettungsanker beim Design von APIs

Im letzten Beitrag der Artikelreihe ging es darum, warum das Design von APIs mit sehr viel Arbeit verbunden ist und nicht so einfach mal im Vorbeigehen erledigt werden kann. API-Guidelines können ein Rettungsanker für das Design von APIs sein.

Design von APIs ist Arbeit, Arbeit und nochmals Arbeit

Herzlich willkommen zu einer Situation aus dem Alltag eines Entwicklungsteams. Es ist Mittwoch und das Planning für den kommenden Sprint ist im vollen Gange. Das Team soll Abschätzungen in Bezug auf eine neu zu schaffende API für die ERP-Lösung anstellen. Für alle Mitglieder des Teams scheint die Lösung auf Basis einer Rest(ful)-API klar und wird mit einem geringen Zeitaufwand geschätzt. Während des Sprints wird nach einer ersten Feedbackschleife mit dem Konsumenten deutlich, dass der Use-Case der Schnittstelle doch nicht so klar und eindeutig ist. Ebenso wurden auch die Belange von Security bei der Schätzung erst mal außen vorgelassen. Sodass am Ende des Sprints keine API bereitgestellt werden konnte. Warum konnte es zu einer solchen Fehlinterpretation und -abschätzung kommen?

Navigating through API Design

Are you struggling to find the right API design for your project? Or perhaps your organization is suffering from 'we’ve always done it this way' statements? The landscape is constantly evolving, and a 'one-size-fits-all' approach just doesn't work. Tune in to our next Live Stream: Navigating API Design. We’re bringing together two amazing minds from codecentric, Dr. Miriam Greis and Daniel Kocot, to help you tackle the challenge of navigating API design!

Building Great APIs

Daniel has been part of the codecentric team since October 2016. Since the beginning of 2022 he works as Principal API Consultant at the Dortmund branch. Starting as a consultant with a focus on application lifecycle management, his focus shifted more and more towards APIs. In addition to numerous customer projects and his involvement in the open source world around APIs. He is also a frequent speaker at conferences.

APIs sind mehr als Technik

Daniel, API-Experte bei codecentric, blickt auf eine spannende Entwicklung zurück - vom technischen Spezialisten zum strategischen Berater für Schnittstellen-Management. In dieser Episode der Strategiewerkstatt erfahrt ihr, wie der Wandel von reiner Technik zu ganzheitlicher API-Strategie gelingt. Daniel teilt wertvolle Einblicke darüber, wie Unternehmen durch 'API-Thinking' ihre digitalen Schnittstellen optimieren können, warum der Mensch trotz Technologie im Mittelpunkt stehen muss und weshalb das 'Upskilling' vorhandener Kompetenzen entscheidender ist als die Einführung neuer Tools. Eine Geschichte über die Verschmelzung von Strategie und Umsetzung, die Bedeutung menschlicher Expertise in komplexen IT-Landschaften und die Kunst, in einer zunehmend vernetzten Welt den organisatorischen Aspekt von Schnittstellen nicht aus den Augen zu verlieren...

API Evangelist Conversation

Daniel Kocot came by again to talk about the lines between our private and public APIs. We had been talking about internal, first-party, and third-party APIs back and forth on LinkedIn, and I recommended that he come by and we will have a conversation. He helped me realize that my separation between the layers was more about access, control, and velocity over just about being inside or outside the firewall and DMZ. Daniel sees this for what it is--it is about people. Lines of business, teams, tribes, and partners. Daniel has that very outside-in view of API operations, but Codecentric is being brought inside to solve the big problems for their customers. Talking with Daniel makes me realize how important it is to have these conversations about our APIs and portals, because not everyone has a handle on the nuance of what is happening at the edge of our enterprises.

API Evangelist Conversation

Daniel has been part of the codecentric team since October 2016. Since the beginning of 2022 as Senior Solution Architect at the Dortmund location. Starting as a consultant with a focus on application lifecycle management, his focus shifted more and more towards APIs. In addition to numerous customer projects and his involvement in the open source world around APIs, he is also a frequent speaker as Head of API Consulting.

#14 - Federated Bubble in APIs

In this insightful podcast episode, the hosts engage in a deep dive discussion with Daniel Kocot from codecentric on the complexities of API federation and the challenges surrounding standardisation in the API gateway market. They explore the need for a shift towards simplification and standardisation to enable easier adoption and value creation in the API landscape.

API-Management | Eine Mate mit Daniel Kocot #EineMateMit

API-Management ermöglicht es, Geschäftsprozesse, -modelle und IT-Architekturen sowohl flexibel und medienbruchfrei als auch zukunftsorientiert zu gestalten. Daniel Kocot zeigt u. a., was der Begriff umfasst, was API-Gateways ausmacht und wie eine mögliche Architektur für eine API-Management-Plattform aussieht.

HTTP Query fixes the method. Not the promise.

Capabilities Are Not Just Better APIs

Enabling Teams Are Becoming the Backbone of AI-Native Engineering

APIs Don’t Follow Domains. They Follow Capabilities.

ArchiMate Next: From Layers to Living Systems

Why AI Transformation Is a Software Engineering Discipline Problem - Part 3

Why AI Transformation Is a Software Engineering Discipline Problem - Part 2

Why AI Transformation Is a Software Engineering Discipline Problem - Part 1

Closing 2025

What apidays Paris 2025 Really Revealed About the Future of APIs

When Ontologies Meet APIs

Context Lives in People, Not Data

Beyond the Edge: What Comes After the Gateway

Event Streaming Hasn’t Topped Out. Our Organizations Have.

DeutschlandStack: Governance After the Fact?

From Experiment to Execution — The Reality of TypeSpec in API Design

The Myth of the Talking Gateway

If Not the Gateway, Then Where?

When Gateways Start Solving the Wrong Problem

From Data Mesh to Interface Mesh

ODPS ≠ ODPS: Why Your Data Product Strategy Needs Both

Registries Reloaded: Why We Still Don’t Understand Them

API Is Solved? Think Again

The Real Jobs of an API Gateway

Why ‘API Gateway’ is Not an Integration Style

Beyond MCP

Distributed APIs

Why ownership is the key to successful APIs

Why database APIs promote bad API design principles

Embracing Ecosystems: From Isolation to Interconnected Innovation

Are We Still Building Application Programming Interfaces?

Integrations Are Not Dead - They Get a Different Meaning

Standards in Software Engineering – Navigating the Maze

Completing the Modern Enterprise Architecture: Aligning ArchiMate with TOGAF, API Thinking, and Team Topologies

Lost in Translation: The Impact of Misused Terminology in the API Space

Aligning API Thinking and Team Topologies with TOGAF: A Modern Approach to Enterprise Architecture

Trust and Cooperation: Navigating APIs through the Prisoner's Dilemma

Maslow's Hierarchy of Needs Applied to API Development: Creating Exceptional User-friendly APIs

GenAI - Really The Next Big Thing...?

Evolving Systems: The Role of Fitness Functions in Continuous Adaptation

The Great of Unbundling of API Management

The Synergy of API Federation and Team Topologies - Team interaction modes under the looking glass

The Synergy of API Federation and Team Topologies - Platform Teams under the looking glass