Ein CTO bat uns einmal, webMethods „einfach rauszuwerfen und durch etwas Open-Source-Basiertes zu ersetzen, damit die Lizenzrechnung wegfällt“. Ein verständlicher Reflex: Die Rechnung war schwindelerregend hoch. Sechs Wochen später hatten wir erfasst, was die Plattform tatsächlich leistete: mehr als 200 EDI-Partneranbindungen, Dateiübertragungen, die von der Bankenaufsicht seines Hauses geprüft wurden, und ein Monitoring, auf das sich drei Teams stillschweigend verließen. Aus der Open-Source-„Ersparnis“ war ein zweijähriger Neuaufbau geworden.
Die Lehre daraus lautete nicht „Kommerziell gewinnt immer“. Sie lautete: „Kommerziell oder Open Source?“ ist die falsche Frage, solange Sie nicht genau wissen, was Sie integrieren, für wen und was ein Ausfall kostet. Nach fünfzehn Jahren Arbeit mit webMethods (und der Bewertung von Open-Source-Alternativen für Kunden aus dem Finanzwesen, dem Bahnsektor und der Versicherungsbranche in ganz Europa) folgt hier die pragmatische Fassung, ohne Verkaufsrhetorik der Hersteller und ohne Open-Source-Missionierung.
webMethods ist eine ausgereifte Suite für den Unternehmenseinsatz: ESB, API-Management, B2B/EDI, Managed File Transfer und IoT-Konnektivität in einem durchgängigen Produkt.
Wo sich die Lizenz bezahlt macht:
- Eine Plattform statt sieben. ESB, API-Gateway, B2B/EDI, MFT und IoT unter einem Dach, mit einem Supportvertrag und einem Upgrade-Pfad, statt dass Sie erst Ihre Integrationswerkzeuge miteinander integrieren müssen.
- Support, der ans Telefon geht. 24/7-SLAs des Herstellers und planbares Patching: genau das, worauf es um 3 Uhr nachts ankommt, wenn ein Zahlungslauf hängt.
- Bewährt, wo Ausfälle teuer sind. Die Plattform läuft produktiv bei großen Banken, Bahnunternehmen und Krankenversicherungssystemen, die täglich Millionen von Transaktionen verarbeiten. Auf genau diesem Niveau haben wir Lösungen damit gebaut: für die Deutsche Bank, die ÖBB und eine Middleware, die über 80 gesetzliche Krankenkassen verbindet.
- Ausgereiftes Tooling. Monitoring, Dashboards und Administrationskonsolen, die Sie nicht selbst zusammenbauen müssen.
Was Sie dafür bezahlen, und zwar nicht nur in Geld:
- Die Lizenzkosten wachsen mit Prozessorkernen, Konnektoren und Volumen. Im Konzernmaßstab wird daraus ein Posten für den Vorstand, nicht mehr für die IT.
- Der Lock-in ist real. Je tiefer Sie auf proprietären Komponenten aufbauen, desto teurer wird der spätere Ausstieg.
- Der Kreis der Fachleute ist spezialisierter und kleiner als bei gängigen Technologie-Stacks. Richten Sie Ihre Personalplanung und Ihren Bus-Faktor danach aus.
Die Open-Source-Landschaft ist gereift und bietet wirklich produktionstaugliche Optionen. Apache Camel (das Schweizer Taschenmesser der Integrationsmuster), WSO2 Micro Integrator, Apache Kafka Connect und Apache NiFi decken jeweils ein breites Spektrum realer Workloads ab.
Wo Open Source glänzt:
- Kein Lizenzzähler. Die Software ist kostenlos; Sie zahlen für Infrastruktur, Engineering und den Support, den Sie zukaufen möchten.
- Ökosystem und Zugang zum Quellcode. Große Communities, Hunderte von Konnektoren und die Möglichkeit, den Code selbst zu lesen, zu patchen und zu erweitern, statt ein Ticket aufzumachen und zu warten.
- Cloud-native von Haus aus. Die meisten Lösungen sind von Grund auf für Container und Kubernetes gebaut: ein Vorteil, wenn Sie ohnehin in diese Richtung steuern.
Was das Etikett „kostenlos“ verschweigt:
- Der Support liegt bei Ihnen, oder Sie kaufen kommerziellen Support ein, der womöglich nicht an das SLA eines Herstellers heranreicht.
- Lücken im Funktionsumfang. ESB-Kernfunktionen und Routing sind stark, doch für B2B/EDI, MFT und schlüsselfertiges Monitoring müssen Sie meist zusätzliche Werkzeuge anflanschen.
- Betriebsaufwand. Den Stack für Deployment, Monitoring und Governance, den webMethods fertig mitliefert, bauen und pflegen Sie selbst.
Die stärksten Integrationslandschaften, die wir sehen, sind hybrid. Kommerzielle Plattformen tragen die geschäftskritischen, volumenstarken und prüfungsrelevanten Flows, also jene, bei denen ein Hersteller-SLA schlicht günstiger ist als das Risiko. Open Source übernimmt die Integration in Fachabteilungen, Entwicklungs- und Testumgebungen sowie neuere Cloud-native Workloads, bei denen Flexibilität und Kosten mehr zählen als ein Supportvertrag. Die Kunst besteht darin, diese Grenze an der richtigen Stelle zu ziehen und sie neu zu prüfen, wenn sich das Geschäft verändert.
- Volumen und SLAs. Sind diese Flows geschäftskritisch und volumenstark? Genau dort rechnen sich kommerzielle Plattformen in der Regel.
- Bestehende Investitionen. Sie betreiben bereits webMethods und haben ein Team, das die Plattform kennt? Dann fällt die Rechnung für die Migration selten niedriger aus als die Lizenzrechnung.
- Cloud-Strategie. Sie stellen auf Cloud-native Architekturen um? Dann bewerten Sie Cloud-native Integration nach ihren eigenen Stärken: Die Architektur zählt mehr als die Frage „kommerziell oder Open Source“.
- Fähigkeiten des Teams. Fragen Sie sich ehrlich, ob Ihr Team eine Open-Source-Plattform um 3 Uhr nachts im Produktivbetrieb betreiben kann, nicht nur für eine Demo aufsetzen.
Wir verfügen über fundierte webMethods-Expertise und haben kein ideologisches Interesse an der Antwort. Wir haben Flows von kommerziellen Plattformen migriert, wo das echtes Geld gespart hat, und wir haben Kunden von Migrationen abgeraten, die mehr gekostet als eingespart hätten. Die richtige Wahl ist die, die zu Ihrem Transaktionsvolumen, Ihrem Team und Ihrer Roadmap passt, nicht zum Quartal des Herstellers oder zur lautesten Meinung im Netz. Wenn diese Entscheidung bei Ihnen ansteht, sprechen Sie mit uns.
