5 Experten verraten Tipps & Tricks - Teil 1

API-Design im Expertencheck: Worauf es bei der Entwicklung von Programmierschnittstellen ankommt
Keine Kommentare

APIs are eating the digital world: Von öffentlichen APIs, die es Unternehmen ermöglichen, ihr Cloud- und SaaS-Geschäftsmodell zu skalieren, bis hin zu Software-Architekturen, bei denen REST-APIs und JSON unverzichtbar sind – Programmierschnittstellen sind heutzutage allgegenwärtig. Anlässlich der APIcon 2018 haben wir 5 Experten gefragt, weshalb die API Economy derzeit Konjunktur hat und wie man API-basierte Projekte erfolgreich gestaltet.

Im ersten Teil unseres großen API-Expertenchecks geht es um die Frage, wie APIs Unternehmen verändern und welche Herausforderungen zu meistern sind, will man APIs in bestehende Unternehmenslandschaften einführen.

Warum überhaupt APIs?

Entwickler: Viele Unternehmen führen derzeit APIs ein, die ältere technische Lösungen wie SOA, ESBs und/oder monolithische Systeme ersetzen. Weshalb eigentlich? Warum hat die sogenannte API Economy momentan Konjunktur?

Arne Limburg: Das hat mehrere Aspekte. Da ist zum Einen der technologische Aspekt. Moderne REST-APIs sind viel schlanker als frühere Lösungen wie SOAP oder XML-RPC und das sowohl im Design als auch bei der Datenmenge, die über die Leitung geht.

Moderne REST-APIs sind viel schlanker als frühere Lösungen wie SOAP oder XML-RPC.

Dann gibt es natürlich den architektonischen Aspekt. Man hat mittlerweile erkannt, dass Architekturen, die auf einem ESB basieren, nicht so leicht zu warten und weiterzuentwickeln sind, als wenn sich die Services direkt unterhalten. Damit das gelingt, benötigt man aber gute APIs, die auch stabil bleiben. Da spielt das Thema Abwärtskompatibilität und Versionierung eine wichtige Rolle.

Und last but not least haben viele Unternehmen erkannt, dass sich mit gut definierten Public APIs auch Geld verdienen lässt. Unternehmen erschließen sich neue Vertriebskanäle, in dem sie APIs anbieten, über die z.B. Mobile Clients angebunden werden können (Stichwort: Multi-Channel-Strategie). Die Clients müssen dann nicht immer vom Unternehmen selbst gebaut werden. Es gibt auch interessante Konstellationen, in denen Drittanbieter an dem Unternehmensumsatz partizipieren können.

Die API-Experten

Arne Limburg – API-Experte bei der open knowledge GmbH und Trainer im Enterprise- und Microservices-Umfeld.

Michael Hofmann – freiberuflicher Entwickler und Coach in den Bereichen Softwarearchitektur, Java Enterprise und DevOps.

Tom Hombergs – Berater, Coach und Architekt bei der adesso AG mit Fokus auf verteilten Architekturen und Spring Boot.

Christoph Wiechmann – berät Kunden auf ihrem Weg ins digitale Zeitalter bei der Einführung API-basierter Architekturen und Geschäftsmodelle.
Thilo Frotscher – freiberuflicher Softwarearchitekt und Experte für Enterprise Java, APIs und Systemintegration.

Tom Hombergs: Ich glaube, der größte Treiber dafür ist der immer noch anhaltende Hype rund um Microservices und ähnliche Modelle. In einer Landschaft mit vielen, kleineren Services, ist das Management von APIs umso wichtiger, weil man sonst schnell den Überblick verliert.

Michael Hofmann: Die Hoffnung dieser Firmen liegt darin, mit den öffentlichen APIs weiteres Geschäft zu erzielen, indem Partner dann in Zusammenarbeit diese APIs nutzen und weiteren Umsatz generieren. Ein weiterer Beweggrund ist die Möglichkeit, mit externen Arbeitskräften neue Projekte anzugehen, in der Hoffnung, dass diese Partner noch Ressourcen verfügbar haben. Nur, wenn alle so agieren, dann löst dies das Ressourcen-Problem auch nicht…

Christoph Wiechmann: Die API Economy hat den Application-Developer/Consumer mehr im Fokus, ist offener und strebt einen höheren Grad an Self-Service für an. Auch macht die API Economy nicht an der Unternehmensgrenze halt, sondern bindet genau wie Unternehmensdienste auch Cloud-Anwendungen in die API-Management-Plattform ein, welche heute für Unternehmen enorm wichtig sind.

Das Ziel ist, dass sich Fachbereiche auf die Entwicklung innovativer digitaler Dienste konzentrieren können und im Self-Service aus einem API-Katalog mit passenden On-Premise- und Cloud-Diensten zugreifen können. Die Projekte der Fachbereiche müssen sich damit nicht um die Integration in einzelne Backend-Systeme kümmern, werden dadurch agiler und sind schneller beim Kunden.

Auf der anderen Seite muss eine API-Management-Plattform dem Betreiber, also der IT bzw. den Service-Providern, die Möglichkeiten bieten, den Self-Service effizient zu überwachen und steuernd einzugreifen.

Lesen Sie auch: RESTful-API-Design: Eine Einführung

APIs in Altsysteme einführen

Entwickler: In den meisten Fällen haben Unternehmen noch Legacy-Systeme am Laufen, die bei der Einführung von APIs integriert werden müssen. Welche technologischen Herausforderungen gilt es dabei zu meistern?

Arne Limburg: Hier gibt es zwei Arten von Legacy-Systemen. Für die einen ist das Unternehmen im Besitz des Source Codes und hat auch das Know-How, um die Systeme weiterzuentwickeln. Hier empfehlen wir immer, ein sauberes RESTful API für das Legacy-System zu realisieren, um es in die „neue Welt“ einzubinden. Häufig ist das gar nicht so schwer.

Sollte sich das nicht realisieren lassen, empfehlen wir einen Anti-Corruption-Layer, der dann die saubere Schnittstelle zur Verfügung stellt und eigentlich nichts anderes macht als zwischen Legacy und neuer Welt hin- und herzumappen. Das kann dann z.B. auch ein Caching beinhalten, wenn das Legacy-System nicht auf eine so hohe Anzahl von Requests ausgelegt ist oder wenn es sogar nur im Batch-Betrieb läuft.

Die größte technologische Herausforderung ist es, den Legacy-Systemen beizubringen, dass sie den definierten Contracts auch in Zukunft gehorchen.

Tom Hombergs: Die größte technologische Herausforderung ist es vermutlich, den Legacy-Systemen beizubringen, dass sie den definierten Contracts auch in Zukunft gehorchen. Hier kommen wieder Contract Tests ins Spiel. Je nachdem, mit welcher Technologie ein Legacy-System umgesetzt ist, kann es schwierig sein, eine Technologie zu finden, die solche Contract-Tests für das jeweilige System ermöglicht.

Christoph Wiechmann: Die Herausforderung besteht darin, diese Legacy-Systeme mit den gewünschten API-Schnittstellen für den API-Management Governance-Layer auszustatten. Kunden setzen dafür auf Fassaden, welche in diese Systeme integrieren, dazu Protokolle und/oder Formate umsetzen, um am Ende eine Standard API zu erzeugen.

Hinzu kommt, dass einige Systeme nicht dafür ausgelegt werden, um im üblichen Request- und Reponse-Modus zu agieren, sondern im Batch-Verfahren angesprochen werden müssen. Auch die Performance einiger Legacy-Systeme ist ein Problem, da diese nicht für viele hundert Anfragen pro Minute entwickelt bzw. ausgelegt wurden, aber mit dieser Anzahl von Anfragen klar kommen müssen.

Welcher technologische Stack bzw. Ansatz dazu verwendet wird, hängt ganz stark vom Backend-System ab und muss von Fall zu Fall entschieden werden. Für Systeme mit unzureichender Performance oder nur Batch-Verhalten könnten Data-Lakes zum Einsatz kommen und Caching auf dem API-Management Layer. Aber es kann sogar so weit gehen, dass es keine andere Möglichkeit gibt, als eine Webbasierte-Legacy-Anwendung mit einer API auszustatten, etwa durch den Einsatz einer Browser-simulierenden Fassade.

APIs weiterentwickeln

Entwickler: Die Wartung und Weiterentwicklung von APIs ist ja generell ein zentrales Thema. Was gilt es hier zu beachten?

Thilo Frotscher: Wartung und Weiterentwicklung eines API sollten bereits während der Entwicklung bedacht werden. Denn ist ein API erst einmal in Betrieb und wird es von einer Vielzahl von Clients angesprochen, dann lassen sich tiefgreifende nachträgliche Änderungen nur noch mit hohem Aufwand umsetzen. Dieser Aufwand könnte mit einem etwas höheren Intialaufwand vermieden werden, beispielsweise indem man sein API von Beginn an so entwirft, dass es eben leicht erweiterbar ist.

Die Erstellung eines unternehmensweiten API Styleguides erweist sich als sehr sinnvoll.

Auch die Erstellung eines unternehmensweiten API Styleguides erweist sich als sehr sinnvoll. Das kann man mit etwas Erfahrung in relativ kurzer Zeit schaffen. Die sich hierbei stellenden Fragen sind nämlich im Grunde immer die gleichen. Ein solcher Styleguide wird sich kurz- bis mittelfristig auf jeden Fall bezahlt machen. Er stellt eine Konsistenz über alle APIs sicher, die nicht nur den Clients hilfreich sein wird, sondern auch die Aufwände für Wartung und Weiterentwicklung reduzieren. Nachträglich lässt sich eine solche Konsistenz jedoch in der Regel nur durch nicht rückwärtskompatible Änderungen erreichen.

Entwickler: Arne, deine Session auf der W-JAX heißt „Abwärtskompatible APIs – Strategien für den Projektalltag.“ Dabei gehst du darauf ein, wie man Schnittstellen sinnvoll weiterentwickelt, wenn sich beispielsweise die Anforderungen verändert haben. Warum genügt es nicht einfach, eine Versionierung für APIs einzuführen?

Arne Limburg: Es geht vor allem um die Pflege alter Versionen. Wenn ich ein Public API betreibe, kann ich nicht einfach eine Version 2 des API zur Verfügung stellen und Version 1 abschalten. Damit erzeuge ich hohen Aufwand bei meinen Clients, die dann zeitgleich updaten müssten. Auf Dauer macht das kein externer Client-Anbieter mit.

Die Erfahrung zeigt aber, dass die Pflege alter Versionen serverseitig sehr aufwendig ist, wenn man es nicht richtig angeht. Es geht also darum, einen Weg zu finden, serverseitig alte Versionen einfach pflegen zu können und gleichzeitig den Clients leichte Wege zu eröffnen, auf die neueste Version zu aktualisieren.

Entwickler: Arne, kannst du einmal einen Tipp geben, wie man Abwärtskompatibilität von APIs sicherstellen kann, ohne sich im Support alter Versionen zu verlieren?

Arne Limburg: In aller Ausführlichkeit erkläre ich das natürlich in meinem Talk auf der W-JAX. Kurz gesagt, geht es darum, einerseits gewisse Anforderungen an den Client zu stellen (Stichwort: Tolerant Reader Pattern) aber andererseits auf dem Server auch dafür zu sorgen, dass die API kompatibel bleibt, in dem innerhalb einer Version nur Attribute hinzukommen, aber niemals welche entfernt werden. Beim Versionssprung ist es wichtig, dass das Mapping zwischen alter und neuer Version nicht zu aufwendig ist.

Wie APIs Unternehmen verändern

Entwickler: Bei der Einführung von APIs bleibt es aber ja nicht bei den technologischen Herausforderungen. Weshalb hat das auch Konsequenzen auf die gesamte Organisation eines Unternehmens?

Arne Limburg: In vielen Unternehmen ist es nach wie vor so, dass die Entwicklung sehr Projekt-getrieben ist. Die Einführung eines neuen Features ist ein eigenes Projekt, für das es ein separates Budget gibt und häufig auch noch ein Plichten- und Lastenheft.

Moderne APIs müssen allerdings als Produkt betrieben werden, das kontinuierlich weiterentwickelt wird und auf diese Weise benötigte Features zur Verfügung stellt. Die Art und Weise, wie neue Themen in die IT eingebracht werden, muss sich daher häufig komplett ändern.

Lesen Sie auch: APIs – die Zukunft der Softwareentwicklung?!

Tom Hombergs: Die organisatorischen Herausforderungen halte ich für viel schwieriger als die technologischen. Man muss erstmal herausbekommen, welches System mit welchem spricht und die Abhängigkeiten organisieren. Dann muss man z.B. die Frage beantworten, wie oft ein System seine Schnittstelle ändert und wer davon betroffen ist. Dahinter hängen dann jeweils Aufwände und Zeitpläne unterschiedlicher Entwicklerteams, die in Einklang gebracht werden müssen.

Michael Hofmann: In Banken mit ihrer IT hat sich über Jahre hinweg eine Organisationsform entwickelt, die auf den Betrieb von Produkten ausgelegt ist. Diese Strukturen sind auch weiterhin notwendig, um den korrekten Betrieb dieser Systeme zu gewährleisten. Leider sind solche Organisationsstrukturen und deren zugehörige Prozesse in der Regel für dynamische Projekte eher hinderlich.

Um Projekte schnell und effizient voranzutreiben, sind DevOps-Organisationen notwendig.

Um Projekte schnell und effizient voranzutreiben, sind DevOps-Organisationen notwendig. Diese sind aber schwer gegen die gewachsenen Strukturen durchzusetzen. Es macht sich zum Teil eine Skepsis vor Veränderungen bemerkbar, was sicherlich nicht förderlich ist, wenn man neue Organisationsansätze etablieren will.

Christoph Wiechmann: Nur die Einführung einer API-Management-Plattform ist noch kein Garant, dass diese zum Erfolg wird. Es muss ein Umdenken im gesamten Unternehmen geben, weg von einem Silo-Denken hin zu einer offenen API-basierten Architektur. Service-Provider sollten ihre Services als API in der Plattform zu Verfügung stellen und können im Gegenzug als Mehrwert aus dem API-Katalog für eigene Entwicklungen schöpfen. Nur so wird möglich, dass sämtliche Dienste/Services inkl. Cloud-Anwendungen zur Verfügung stehen und der Nutzen der Plattform steigt.

Das Aufschalten von Services muss für Service-Provider schnell und einfach gehen, so dass es nicht als Hürde, sondern als Gewinn für das Unternehmen verstanden wird. Selbstredend, dass API-Konsumenten auf einfache, aber kontrollierte Art und Weise auf APIs zugreifen können, um diese für eigene Zwecke einzubinden.

Um das zu erreichen, müssen Unternehmen internes und externes Marketing betreiben, Service-Provider und -Consumer müssen geschult und ein API-Team unterstützt werden, besonders aktiv in der ersten Ramp-Up-Phase nach Go-Live der Plattform

Entwickler: Vielen Dank für diese spannenden Einsichten!

Weiter geht’s mit Teil 2 unseres API-Checks: Die Experten geben Tipps für die erfolgreiche Implementierung von API-basierten Projekten.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -