KI-gestützte Integration: Wie Apache Camel proprietäre Low-Code-Lösungen ersetzt

Es sei eine Software im Bereich Healthcare zu entwickeln, die Informationen (z.B. Patientendaten, Diagnosen, Laborergebnisse) aus verschiedenen medizinischen Systemen aggregieren und einer anderen Komponente zur Weiterverarbeitung mit einer eigens definierten API zur Verfügung stellen soll. Das System soll über ein Monitoring verfügen und von außen konfigurierbar sein. Der System-Context sieht also so aus:

In diesem Umfeld gibt es neben generischen Technologien (REST, SOAP, Files, JSON, XML, SQL) auch branchenspezifische Protokolle und Datenformate (FHIR, HL7, MLLP) zu unterstützen.

Die zu entwickelnde Lösung soll den Betrieb in einer komplexen Systemlandschaft erlauben und mandantenfähig in mehreren Instanzen ausgerollt werden. Jede Instanz erfordert eine hochgradig konfigurierbare und durch spezifische Plugins erweiterbare Funktionalität. Die Verwendung einer zentralen Plattform für Monitoring, Deployment und Konfiguration zur Beherrschung dieser Multi-Instanz-Umgebung bietet sich an.

Warum Low-Code in Integrationsprojekten verlockt

Integrationsprojekte stehen häufig unter massivem Zeitdruck. Auf Low-Code setzende Integration-Tools wirken hier auf den ersten Blick wie die ideale Lösung: Sie ermöglichen eine schnelle Entwicklung durch visuelle Editoren und fertige Konnektoren. Die unmittelbare Sichtbarkeit der Datenflüsse und die geringe Einstiegshürde erlauben es, rasch einen Proof-of-Concept oder eine erste Produktivversion zu liefern. Das Aufsetzen bzw. die Installation der initialen Umgebung ist gerade bei PaaS-Lösungen verhältnismäßig einfach und schnell geschehen. Der anfängliche Fokus liegt dabei auf der Geschwindigkeit und der reinen Abbildung der Fachlogik. Gerade im Bereich Healthcare gibt es Lösungen von z.B. Mulesoft, Infor oder x-tention.

Ein weiterer häufiger Wunsch bei Low-Code/No-Code Lösungen ist, die Entwicklung eher in die Hände von Fachexperten als von internen oder externen IT-Experten zu legen. Die Hoffnung dabei ist zum einen, die Reibungsverluste zwischen Fachabteilung und Entwicklung zu reduzieren, und zusätzlich die Wartezeiten zwischen Anforderung und Bereitstellung zu verkürzen.

Die Nachteile einer Low-Code-Lösung und eine möglichen Alternative

Die Implementierung mit einer Low-Code-Lösung erlaubt zwar den schnellen Start. Mit steigender Komplexität und zunehmenden Instanzen zeigen sich jedoch schnell die inhärenten Nachteile (teilweise stark abhängig von der verwendeten Low-Code-Lösung):

• Mangelnde Testbarkeit: Die visuell erstellten Flows lassen sich z.T. schwer automatisiert testen (Unit-, Modul-, Integration- und E2E-Tests). In kritischen Integrationsumgebungen stellt dies ein hohes Qualitätsrisiko dar, insbesondere bei späteren Änderungen am Code.
• Debugging: Auch wenn einige Low-Code-Tools einen Debugger für die visuellen Prozesse anbieten, bleiben die Möglichkeiten zur Fehlersuche z.B. beim Mapping von Daten, Verwendung von Breakpoints oder Anzeige von Variablen beschränkt.
• Teamwork: Proprietäre Code- und Dateiformate - häufig xml-basiert - erschweren moderne Development-Workflows und Versionskontrolle mit paralleler Zusammenarbeit in Teams oder Entwicklung paralleler Features erheblich (branching/merging von Code).
• Vendor-Lock-in: Die Abhängigkeit vom Hersteller für notwendige Bugfixes, Security-Patches oder die Unterstützung neuer technologischer Standards kann zu Sicherheitsproblemen, höherem Entwicklungsaufwand und Schulungsaufwänden, wenn nicht gar zu einem Kapazitätsproblem wegen fehlendem Know-How auf dem Markt führen.
• Lizenzkosten: In der Regel lassen die Hersteller sich die Tools gut bezahlen. Bei einigen kosten die Healthcare-Komponenten sogar extra.
• Fehlende Flexibilität: Über die Low-Code Plattform ist man an die Funktionalität der Umgebung gebunden. Weitergehende Entwicklung geht nur, wenn man bspw. externe Bibliotheken einbinden kann.

Die Kernfrage lautete: Können wir die Vorteile der schnellen Abbildung von Fachlogik, das initiale Aufsetzen der Umgebung und ein vernünftiges Monitoring einer Low-Code-Plattform erhalten, gleichzeitig aber die Nachteile durch eine wartbare Eigenentwicklung eliminieren? Die Verwendung von KI bietet die Möglichkeit, dass man - ähnlich wie bei einer No-Code Umgebung - nur durch Beschreibung der Anforderungen eine Lösung erstellen kann, ohne mit Source-Code in Berührung zu kommen.

Ein bekanntes, weit verbreitetes Framework für Integrationslösung bietet sich mit Apache Camel an. Dieses bietet, wie kommerzielle Integrationslösungen, ebenfalls eine riesige Auswahl an Komponenten für Protokolle und Datenformate, Runtimes, und sogar eine Unterstützung für graphische Designer. Dabei ist Camel aber gleichzeitig Java-basiert und komplett offen.

Der PoC-Blueprint: Die Anforderungen

In einem PoC soll geprüft werden, wie gut sich Apache Camel mit KI-Unterstützung in der Entwicklung eignet, um eine entsprechende Lösung zu entwickeln. Neben der reinen Funktionalität soll dabei auch die Qualität des Codes und die Testbarkeit geprüft werden.

Um das zu prüfen, wählen wir einen fachlich relevanten Ausschnitt der existierenden Low-Code-Lösung. Das Ziel der Implementierung war es, die Low-Code-Vorteile beizubehalten und die technischen Probleme zu reduzieren.

Die fachlichen Anforderungen an den Proof-of-Concept umfassen:

• HL7-Integration: Bereitstellen einer MLLP-Schnittstelle zum Empfangen von HL7-Nachrichten, die Befunde enthalten (ORU-R01-Nachrichten).
• Nachvollziehbarkeit und Persistenz: Die empfangenen HL7-Roh-Nachrichten müssen gespeichert werden, um eine lückenlose Nachvollziehbarkeit zu gewährleisten und die Möglichkeit zum erneuten Einspielen von Fehlerszenarien zu schaffen.
• Fehlerbehandlung: Wenn Nachrichten nicht verarbeitet werden können (unbekanntes Format, fehlende Felder, Datenbank nicht verfügbar, …) soll die Nachricht abgelehnt werden, so dass der Sender ggf. wiederholen kann
• Datenabfrage per REST: Bereitstellung einer REST-Schnittstelle, um konfigurierbare fachliche Informationen zu einem Patienten aus den persistenten HL7-Nachrichten abfragen zu können.

Zudem soll rudimentär gezeigt werden, dass eine zentrales Monitoring und Deployment möglich ist:

• Zentrale Verwaltung: Die neue Umgebung soll einfach aufzusetzen sein und für verschiedene Instanzen eine zentrale Monitoring-, Update- und Konfigurationsmöglichkeit bieten.

KI als Product-Engineer: Spezifikation und Implementierung mit BMAD

Das gewählte Vorgehen geht über reines Vibe-Coding hinaus: Gemeinsam mit der KI wurde im Sinne von Spec-Driven-Development ein KI-gesteuerten Vorgehen verwendet, um den gesamten Prozess von der Erhebung der Anforderung bis zum fertigen, lauffähigen Code zu automatisieren. So sollte die Time-to-Market verkürzt werden, ohne dabei auf wartbaren Code zu verzichten. Als Tooling wurde BMAD mit Claude Code verwendet. Apache Camel bietet einen MCP-Server an, der bei der Implementierung unterstützt.

Spezifikation und Epics: Zuerst wurden, von BMAD gesteuert, die Anforderungen erhoben, eine detaillierte technische Spezifikation und Architektur erstellt, sowie die umzusetzenden Epics generiert. Dies etablierte eine saubere und vollständige Grundlage für die nachfolgende Implementierung. Währenddessen hat BMAD auf unklare Beschreibungen und offene Punkte hingewiesen und z. T. alternative Lösungen angeboten. Diese Phase hat einen Großteil der Zeit in Anspruch genommen.

Implementierung – Ralph Wiggum Loop: Die eigentliche Entwicklung mit Apache Camel (mit Spring Boot) erfolgte in einer iterativen Schleife, der sogenannten "Ralph Wiggum Loop". Das Konzept wurde bspw. hier gut beschrieben. In einer Schleife (sic!) arbeiten KI-Agenten Aufgaben ab, bis keine mehr übrig ist. Mit BMAD-Automate und BMALPH stehen für BMAD zwei Implementierung zur Verfügung. Diese Definieren jeweils die High-Level Tasks (Stories in Aufgaben herunterbrechen,Tests schreiben, implementieren, Tests ausführen, Code-Review, Commit), die von den jeweiligen Agenten ausgeführt werden sollen, und steuern die eigentliche Loop. Während der Ausführung kümmert sich das jeweilige Tool zusätzlich um das Context-Handling und erlaubt teilweise die Auswahl verschiedener KI-Modelle für unterschiedliche Aufgaben.

Das Ergebnis und die Rolle des menschlichen Architekten: Das Ergebnis war eine vollständige Implementierung inklusive Spezifikation, Dokumentation und einem Satz gut getesteten Codes. Alle Korrekturen und Anpassungen am Code wurden durch die KI selbst vorgenommen. Dennoch zeigten sich wichtige Erkenntnisse bezüglich der notwendigen menschlichen Expertise:

• Architektur und Fachexpertise: Obwohl die KI sehr gute Vorschläge lieferte, war der erfahrene Architekt weiterhin notwendig, um fachliche und technologische Verbesserungen zu identifizieren (die KI hat einige mögliche Lösungsansätze übersehen) und Best Practices durchzusetzen. Diese können jedoch effizient im Dialog mit BMAD eingepflegt werden.
• Qualitätssicherung und Clean Code: Der generierte Code entsprach nicht immer den vorher festgelegten Richtlinien (z.B. YAML-DSL statt Java-DSL) und neigte zu unnötiger Komplexität. Besonders kritisch war die Unit-Test-Qualität, wo die KI Routen direkt in den Test kopierte – ein Antipattern, das Wartungsprobleme nach sich zieht. Manuelles Review war zwar nicht zur Sicherstellung der Funktionalität nötig, jedoch zur Verbesserung der Les- und Wartbarkeit und zur Einhaltung von Clean Code Prinzipien.

Fazit: KI verschiebt die Make-or-Buy-Entscheidung hin zu Eigenimplementierung mit Apache Camel

Die Erfahrung mit BMAD und Apache Camel zeigt, dass der KI-Einsatz die wirtschaftliche Abwägung in Integrationsprojekten fundamental verändert. Die anfänglichen Geschwindigkeitsvorteile von Low-Code-Plattformen werden durch die KI nivelliert, während deren Nachteile (technische Schulden, schlechtere Testbarkeit, Vendor-Lock-in, Lizenzkosten) vermieden werden. Dies dürfte sich mit der Weiterentwicklung der KI-Modelle noch weiter verschieben.

Beispielhaft wurde eine Lösung implementiert, die die geforderten Funktionen enthält und den Ansprüchen an Enterprise-Integration genügt:

• Qualität: Durch gute Testabdeckung mit Tests, die automatisiert in einer CI-Pipeline ausgeführt werden können.
• Wartbar: Lesbarer Code mit Coding-Guidelines
• Standardisiert: Java/Spring Boot mit Standard-Frameworks

Die KI ist (noch) kein Ersatz für Fachexperten, Architekten und Entwickler. Sie ist jedoch ein gutes Werkzeug, das die Umsetzung drastisch beschleunigt und uns in die Lage versetzt, komplexe Integrationsanforderungen nachhaltig zu erfüllen. Fachexperten beschreiben die fachlichen Anforderungen, Architekten und Entwickler die technischen Rahmenbedingungen und prüfen die entstandenen Architekturvorschläge, den Code und die Testqualität. KI-Agenten können als Teammitglieder in die Organisationsstruktur integriert werden und alle oben beschriebenen Rollen in deren Aufgaben unterstützen.

Als Learning habe ich einige Punkte identifiziert, die ein Entwickler in dem Zusammenhang gerade mit Camel zu beachten hat - wobei viele davon auch in “normalen” Entwicklungsprojekten sinnvoll sind:

• Ein Verständnis bzw. Vorwissen von Apache Camel und Java sollte vorhanden sein.
• Definiere Architektur- und Coding-Richtlinien und überprüfe, ob die von der KI eingehalten werden (z.B. Paketstruktur, Routendesign und -aufteilung). Diese sollten über Tooling (Linting, ArchUnit, o.ä.) erzwungen werden.
• Bestimme und prüfe bei den Mappings, die in den Prozessen benötigt werden (z.B. Jackson, datasonnet, Java-code), ob die passenden Mittel gewählt werden, die Mappings lesbar sind und ggf. Tests für Logik in den Mappings existieren.
• Mache Reviews auf den generierten Code und prüfe die Komplexität und Qualität der Tests. Code-Coverage sollte genutzt werden, um ein Gefühl für die Testabdeckung zu bekommen.
• Lasse eine technische Dokumentation erzeugen und aktuell halten (z.B. über Hooks). Die jeweiligen Artefakte (Mappings, Prozesse, Adapter-Konfigurationen) sind tendenziell schwerer zu finden als in dedizierten Low-Code-Lösungen.
• Die Verwendung unterschiedlicher Modell (z.B. Claude Sonnet vs. Opus) erzeugt deutlich unterschiedlichen Code. Dieser Unterscheidet sich vor allem in der Struktur, Allgemeinheit und Lesbarkeit (ich bevorzuge den von Opus generierten Code).

Von Haus aus bieten Low-Code-Integrationslösungen häufig Features, die in Camel nicht Out-of-the-Box vorhanden sind (z.B. Monitoring, Deployment, API-Gateways, Hochverfügbarkeit, Adapter zu Fremdsystemen, …). Es sollte deswegen geprüft werden, welche dieser Features für die Lösung benötigt werden und wie diese ggf. in der Lösung mit zu entwickeln sind.

Eine interessante Idee für weitere Projekte dieser Art ist, einen oder mehrere Skills für einen Apache Camel Entwickler zu bauen und in BMAD zu integrieren.