„Sie geben die Richtung vor“

Beides spielt eine sehr wichtige Rolle. Eine hybride Integration ist für offene Ökosysteme nahezu eine Notwendigkeit: Denn könnte eine Architektur nur Ressourcen und Dienste einer bestimmen Herkunft beinhalten, hätte man zahlreiche Möglichkeiten einer echten Offenheit bereits verspielt.

API Management kann man auf verschiedene Arten interpretieren, aber das spielt für diese Frage nur eine untergeordnete Rolle. Es sind die APIs selbst, denen die größte Bedeutung zukommt: IT-Architekturen, die als offene Ökosysteme konzipiert sind, sollten konsequent auf APIs als die wichtigste Abstraktionsebene setzen. Dies unterscheidet sich deutlich von traditionellen Ansätzen, bei denen zentrale Komponenten (wie z.B. ein Enterprise Service Bus, ESB) eine Kernrolle spielen. Der größte Unterschied ist, dass API-Produzenten und Konsumenten direkt miteinander kommunizieren. Auf diese Weise können erfolgreiche APIs von einer immer größeren Zahl an Konsumenten genutzt werden, ohne dass jeweils individueller Integrationsaufwand entsteht.

Diese verteilten Nutzungsmodelle gehen jedoch nicht mehr durch eine zentrale Verbindungsstelle, die z.B. Versionierungen verwalten könnte. Es wird daher wichtiger, jedes API, welches von Konsumenten genutzt werden kann, als ein eigenständiges Produkt zu betrachten und zu managen. Für das Management derartig komplexer Abhängigkeiten stehen entsprechend produktorientierte Aspekte im Vordergrund: Beschreibung des Business-Nutzens, Dokumentation des API, Dokumentation der Versionierung und andere Aspekte, die es Nutzern ermöglichen, APIs zu finden, zu verstehen und sicher und zuverlässig zu nutzen.

Einer der wichtigsten Eigenschaften von APIs ist, dass sie genutzt werden können, ohne dass man dazu wissen muss, wo und wie sie implementiert sind. Aus diesem Grund entwickelt sich eine hybride Integration nahezu automatisch, sofern man konsequent auf APIs als die sicht- und nutzbare Oberfläche seines offenen Ökosystems setzt. Die APIs können an beliebigen Stellen entstehen und zur Verfügung stehen: Solange sie auffindbar und nutzbar sind, ist das Ziel, der IT-Architektur und den Diensten möglichst viel Entwicklungsspielraum zu lassen, erreicht. Das, was oftmals etwas abwertend als „Shadow IT“ bezeichnet wird, also dezentrale Lösungen, die oft aus pragmatischen Überlegungen heraus entstehen, soll in Zukunft nicht vermieden werden, sondern ein bewusst mitgeplanter Teil der gesamten IT-Architektur werden.

Fasst man die beiden Aspekte API Management und hybride Integration zusammen, so geben diese relativ gut die Richtung vor, in die sich offene Ökosysteme entwickeln werden: Die Architektur kümmert sich weniger um das „wie“, sondern mehr um das „was“. Dazu muss vor allem sichergestellt werden, dass Implementierungsdetails nicht zu sehr die Offenheit der Architektur bestimmen. Dies erfordert eine Neuorientierung für viele Architekturen, bei denen das „wie“ und das „was“ oft zu stark miteinander verwoben sind.

Natürlich werden IT-Abteilungen nach wie vor auch Unterstützung bei Entscheidungen über die Umsetzung von Lösungen leisten. Aber es wird wichtiger werden, immer bewusst im Blick zu behalten, dass diese IT-Dienste lediglich ein weiterer Baustein in einem offenen Ökosystem sind, welchem die Architektur stets Rechnung tragen muss.