Agile Integration – ein ganzheitlicher Blick

Am Schlagwort „Agilität“ führt kein Weg vorbei – doch was bedeutet Agilität im Kontext der Integration von Anwendungen und Services? Geht es um die Nutzung agiler Methoden wie SCRUM oder Kanban und wie berücksichtigt man die wachsende Komplexität bei der Orchestrierung von Services und API’s? Zudem stellt sich in Zeiten von DevOps  die Frage, wer innerhalb der Organisation die Verantwortlichkeit für Schnittstellen übernimmt. Last but not least: Sind zentrale Richtlinien für die Implementierung von Schnittstellen notwendig oder sind agile Integration und Governance Begriffe aus völlig unterschiedlichen Denkmustern, die einfach nicht zusammen passen?

Nicht alle der oben genannten Impulse lassen sich generisch und eindeutig beantworten. Im Folgenden möchte ich aber einige Denkanstösse geben, dafür lohnt sich ein ganzheitlicher Blick.

Die technische Perspektive
Integration in Zeiten von Service Bus – Der Single – Tool Approach

Mit dem Aufkommen von Service Bus Lösungen wurde meist auch ein zentrales Team im Unternehmen geschaffen, welches sich um die Implementierung aller Schnittstellen kümmerte. Ziel war es dabei, alle Integrationen über einen zentralen Bus mit einheitlichem Vorgehen und Methoden zu implementieren und dabei auch das Monitoring an einer Stelle zu konsolidieren.

Somit wurden heterogene Anwendungslandschaften, die über eine Vielzahl von Punkt-zu-Punkt Verbindungen integriert waren, endlich über einen zentralen „Bus“ miteinander vernetzt.
Auf den ersten Blick ein idealer Ansatz, da klar definiert ist, wie Schnittstellen zu implementieren sind und die internen Experten in der Lage sind, die Anforderungen sowohl mit den Fachbereichen zu spezifizieren und anschließend einheitlich mit den für das Unternehmen definierten „Pattern“ umzusetzen.

Im Umkehrschluss entsteht jedoch auch ein Engpass bei den Integrationsteams, die mit der wachsenden Bedeutung von Schnittstellen und damit auch der Zunahme an Anforderungen oftmals die Fachbereiche und Development Teams nicht schnell genug bedienen konnten. Wirklich zum Problem wird dieser Aspekt vor allem durch die Adaption von  Microservice-Architekturen und der zunehmenden Anzahl an Cloud-Services. Zwar können die Prinzipien von Microservices und Dev-Ops auch unter Nutzung eines Service Bus als Plattform umgesetzt werden, der Engpass ist dabei oft der technische Lock-in, denn nur wenige Dev-Teams haben das nötige Skill-Set für die Nutzung herstellerspezifischer Service-Bus Lösungen.

Die Veränderung der Integration durch DevOps und Microservices

Durch das Aufkommen von Microservice-Architekturen wurden selbst innerhalb einer Anwendung die Nutzung von API´s unverzichtbar. Der Siegeszug von API-Management im Development wurde dadurch eingeleitet. Für das Zusammenspiel  unabhängiger Services, die zu einer Gesamtwendung orchestriert werden müssen, wurden Standards wie REST schnell zum Mittel der Wahl und durch Developer schnell adaptiert. Die Einbeziehung des Integrations Teams wurde dabei oft vergessen.  Service Bus Werkzeuge für Anwendungsentwickler werden oftmals als zu schwergewichtig, zu komplex und als zu „Legacy“ empfunden. Schnell entstand eine „Schatten-Integrationslandschaft“ innerhalb der Dev-Ops Teams, die auch über Anwendungsgrenzen hinaus benutzt wurde. Durch die Nutzung von z.B. Containern, Kubernetes / Open Shift ist man dagegen am Ende freier in der Wahl der technologischen Werkzeuge. Trotzdem bleibt eine Vielzahl an Fragen, wie z.B:

• Bedeutet Integration in Zukunft die Ablösung von Service Bus-Konzepten durch API – Tools?
• Werden Standard-Anwendungen aus der Cloud nur noch mittels weniger Clicks und iPaaS integriert?
• Wird es die klassische „Integration – Route“ nicht mehr geben, weil hier einzelne Services übernehmen?

Allein diese drei Fragestellungen zeigen, dass es  in der modernen, cloud-nativen IT – Welt nicht so einfach ist, eine Standardantwort zu finden, es kommt eben darauf an und oftmals sind wir am Ende wieder eher in einer philosophischen als technischen Diskussion. Trotzdem zeigen wir an Hand des Beispiels der Definition des Begriffs „Agile Integration“  auf, wie moderne Integration gelebt werden kann.

One fits all approach?

Während man zu Zeiten der Service Bus uns SOA-Paradigmen oft mit einer „Suite“ alle Integrationsaspekte abdecken wollte, setzt sich heute mehr und mehr das Bild eines „Multi-tool-approach“ durch, da oftmals andere Zielgruppen adressiert werden – während Kubernetes/Open Shift – Camel – Fuse und Kafka eher die Werkzeuge der ehemaligen Integrationsexperten sind, siedeln sich API-Portale eher im Application Development an. iPaaS Lösungen – wie die von Dell Boomi – setzen den Schwerpunkt dagegen näher am Fachbereich, wo es weniger um die Technologie geht als vielmehr um die schnelle Implementierung von (SaaS-) Applikationen.

Die fachliche Perspektive – Transparenz und Kommunikation

Integration war immer schon komplex, weniger technisch als vielmehr aus Sicht der Koordination der Beteiligten. Die Anforderungen das Fachbereichs müssen zuerst in die Sprache der Technik übersetzt werden, danach gilt es alle Beteiligten, entweder aus dem internen Development, von externen Partner oder Softwareherstellern einzubeziehen. Die Anforderungen erscheinen dabei im ersten Moment wenig „agil“, da kaum Spielraum zwischen Anforderung und zu erreichendem Ziel vorhanden ist und die klassische „User Story“ schnell technisch wird.

Diese Feststellung ist erstmal unabhängig vom Werkzeug und der gewählten Art der Integration zu sehen, sondern vielmehr eine Herausforderung an die interne Projektorganisation. Wie sieht daher ein agiler Ansatz aus?

Die Antwort ist einfach – Transparenz zwischen allen Beteiligten schaffen, um böse Überraschungen zu vermeiden. Dies fängt bei der Formulierung der einzelnen Tasks oder User Stories an und geht weiter mit der engen Einbindung aller Parteien im Rahmen von täglichen Abstimmungen. Doch neben Transparenz bedeutet Agilität auch die Übernahme von Verantwortung und die Fähigkeit der schnellen Anpassungsfähigkeit ohne „Fingerpointing“. Gerade wenn über Integration gesprochen wird, kann es jederzeit passieren, dass es zu Änderungen durch angebundene Systeme oder externen Services kommt, die oftmals sehr kurzfristig adaptiert werden müssen. Hier zeigt sich dann am Ende, welche Teams den Gedanken und die Prinzipien der Agilität zu Ende denken.

Am Ende führen Methoden aus der agilen Entwicklung auch im Bereich der Integration zu einem besseren Verständnis der Herausforderungen und einer schnelleren Zielerreichung. Dabei ist ein wichtiger Teil die Entscheidung, wie im jeweiligen Fall integriert wird und welche Werkzeuge am besten geeignet sind. War die Frage bei einem zentralen Service Bus schnell beantwortet, sollte heute eine Art „Integrationsmatrix“ definiert werden, die aufzeigt, welche Optionen im Unternehmen möglich sind und genutzt werden können.

Zwischenfazit
Integration im „Big Picture“ und nicht als Tool- oder Werkzeugdiskussion

Integration von Anwendungen kann heute nicht mehr aus einer reinen Werkzeugperspektive betrachtet werden, da Architekturen mit der Nutzung eines zentralen Service Bus den aktuellen Anforderungen nicht mehr gewachsen sind. Dies ist aber nicht technisch bedingt, denn auch heute wären die Ansätze Service orientierter Architekturen unter Einbeziehung einer einzigen und zentralen Integrationsplattform in der Lage, die Kernprobleme bei der Integration und Orchestrierung zu lösen.  Vielmehr wird ein zentraler und technisch proprietärer Plattform Ansatz zum „Bottleneck“ im Development und ist für agile Projekte und DevOps-Teams nur bedingt geeignet.

Für viele scheint der neue Schlüssel zum Erfolg im Aufbau eines API-Managements zu liegen. Getrieben aus der agilen Entwicklung von Microservices scheinen API´s und deren zentrales Management der beste Weg um Services aber auch Systeme, Anwendungen aber Prozesse zu integrieren.

Aber Vorsicht: Hier werden oft Äpfel mit Birnen verglichen, denn nur auf ein API Management zu setzen, und die Integrationsprozesse direkt in die Anwendungen zu verlagern ist ein Schritt in die falsche Richtung!  Dadurch entstehen Abhängigkeiten, die schnell außer Kontrolle geraten.

Beispiel –  Integration on Open Shift

Ein gutes Beispiel für den etwas breiteren Blick auf das Thema Integration bildet das Konzept zur „Agile Integration“ von Red Hat.
Ausgehend von der zunehmenden Relevanz von Microservices und deren „DevOps“ Ansatz in der Entwicklung wurde Kubernetes und Open Shift zu einem wichtigen Marktteilnehmer im Bereich der Containerplattformen. Unter dem Begriff „Integration“ werden hier mehrere Werkzeuge zusammengefasst, die genau das „Big Picture“ ermöglichen und dabei Integration für unterschiedliche Zielgruppen und Anwendungsfälle zusammenfassen:

• Red Hat Fuse zur Integration von Integration Patterns unter Nutzung von Apache Camel
• 3scale als Werkzeug zum Aufbau eines API Managements
• Red Hat AMQ als zentrale Messaging Plattform unter Nutzung von Kafka für MicroService Integration / Streaming

Alle Werkzeuge sind dabei sowohl für Integration-Experten aber auch für DevOps Teams schnell adaptierbar, es entsteht eine Plattform, die aus einer technischen Sicht perfekt innerhalb von Kubernetes / Open Shift betrieben und skaliert werden kann. Durch die Einbeziehung von Process Automation kann zudem auch eine prozessuale Sicht geschaffen werden, die als Grundlage für Fachbereiche dienen kann, die fachlichen Prozesse zu definieren, welche anschließend über die Orchestrierung einzelner Services umgesetzt werden.

Eben dieser Ansatz, nicht über Features und Funktionen eines einzelnen Bausteins zu diskutieren, sondern eine Plattform zu schaffen mit allen relevanten Optionen für Integration ist ein elementarer Baustein für den Erfolg von agiler Integration und ein Kernbestandteil der Definition von Agile Integration bei Red Hat. Dabei liegt der Fokus nicht nur auf den technischen Bausteinen, sondern auch auf den Rollen der Beteiligten im Unternehmen. Hier spürt man den „Impact“ des Leitgedanken der „Open Organization“, welcher bei Red Hat nicht nur intern gelebt wird, sondern auch auf die Methoden und Produkte teilweise Einfluss hat.

Agile Integration aber wie?

Integration kann – wie beschrieben – Methoden der Agilität nutzen, um mehr Transparenz für alle Beteiligten zu schaffen! Gerade eben durch die Vielzahl an Optionen, die für Integration zur Verfügung stehen und unterschiedliche Sichten von Development, Nutzer von Standardanwendungen oder Prozessexperten auf die Anforderungen macht dieses Vorgehen notwendig.

Aus einer technischen Sicht ist eine durchdachte Architektur notwendig, die gewisse Leitplanken schafft und die geeigneten Werkzeuge zur Verfügung stellt, die es erlauben die notwendige Geschwindigkeit aufzunehmen und dabei trotzdem dafür sorgt, dass Schnittstellen transparent und wartbar bleiben. So viel Freiheit wie möglich – soviel Governance wie nötig.

Die oben gezeigten technischen Beispiele für Tools sind dabei als Impuls zu verstehen, wie man das „große Bild“ verfolgen kann und nicht in einem limitierten Werkzeugvergleich stecken bleibt.