BluLogix CIS: Telecom-Billing trifft Salesforce via ETL

Es gibt eine bestimmte Kategorie von Integrationsproblemen, die auf dem Whiteboard straightforward aussehen und dich dann jede Woche ein Jahr lang etwas lehren. Die CIS-to-Salesforce-Integration bei BluLogix war dieses Problem.

BluLogix baut die Cloud Innovation Suite (CIS) - eine Cloud-Billing-Plattform für Telecom-Betreiber. Kein generisches SaaS-Billing. Telecom-Billing im Spezifischen: usage-basierte Gebühren, Plan-Hierarchien, Promotionspreise, Bundle-Management, Mid-Cycle-Anpassungen, anteilige Rechnungen. Die Art von Billing-Komplexität, die nur Leute wirklich schätzen können, die drin gewesen sind. Ich war Team Lead und Developer auf der Frontend-Seite und leitete die Salesforce-Integration von 2013 bis 2014.

Warum Telecom-Billing eine eigene Domain ist

Telecom-Billing ist keine vereinfachte Version von allgemeinem Billing. Es ist eine eigenständige Disziplin mit eigenständigen Datenmodellen.

Das Billing-System eines Telecom-Betreibers trackt Nutzung - Anrufe, Daten, SMS - auf Event-Ebene, aggregiert diese Events gegen Plan-Entitlements, wendet gestaffelte und Promotionsraten an, generiert Rechnungen, handhabt Gutschriften und Anpassungen, verwaltet Zahlungszyklen und produziert das regulatorische Reporting, das Telecom-Betreiber einzureichen verpflichtet sind. All das passiert in großem Maßstab, kontinuierlich, für jeden Teilnehmer im Netz.

Das Datenmodell spiegelt diese Komplexität. Ein Subscriber hat ein Service-Profil. Das Service-Profil hat einen oder mehrere Pläne. Jeder Plan hat Entitlements, Overages und Promotionsmodifikatoren. Usage-Events kommen kontinuierlich herein und müssen gegen die korrekte Plan-Version für den Zeitraum, in dem sie aufgetreten sind, bewertet werden - weil der Subscriber möglicherweise den Plan mid-cycle gewechselt hat oder der Betreiber die Planbedingungen geändert hat, und das historische Rating muss korrekt sein.

Das ist CIS’ Domain. Sie kennt diese Domain tief. Das Problem ist, dass CRM-Systeme - Salesforce im Speziellen - eine vollkommen andere Domain kennen.

Das Problem der inkompatiblen Datenmodelle

Salesforce ist um das CRM-Objektmodell gebaut: Accounts, Contacts, Opportunities, Leads, Cases. Es kennt Kunden und Deals und Support-Tickets. Es kennt keine Subscriber und Service-Profile und Usage-Events und Rating-Zyklen.

Die Integrationsanforderung war real: Die Telecom-Betreiber, die CIS verwendeten, nutzten auch Salesforce für ihre Vertriebs- und Support-Operationen. Ein Subscriber in CIS hatte einen entsprechenden Account in Salesforce. Eine CIS-Planänderung, die das Support-Team in Salesforce initiiert hatte, musste zu CIS fließen, ohne dass der Support-Mitarbeiter sich separat in CIS einloggen musste. Abrechnungshistorie musste aus dem Salesforce-Interface einsehbar sein, ohne einen separaten Login zu erfordern.

Das sind vernünftige Produktanforderungen. Sie sind in der Praxis auch ein Datenmodell-Übersetzungsproblem in beide Richtungen gleichzeitig.

Talend ETL: die Integration-Layer, die tatsächlich geliefert wurde

Der Ansatz war Talend ETL - eine Enterprise-ETL-Plattform - als Integration-Layer zwischen CIS und Salesforce. Keine direkte API-Integration, kein Custom-Middleware-Service, sondern eine dedizierte ETL-Job-Orchestrierungsschicht, die die Übersetzungsverantwortung explizit besaß.

Das war die richtige Entscheidung, aus mehreren Gründen, die erst im Nachhinein vollständig klar wurden.

Die Transformation ist stateful. Einen CIS-Subscriber auf einen Salesforce-Account zu mappen, ist keine einmalige Übersetzung. Es ist eine laufende Synchronisation. Änderungen fließen in beide Richtungen. Die ETL-Layer trackt Synchronisations-State, handhabt Konflikte und verwaltet die Historie dessen, was synchronisiert wurde - was ein anderer Job ist als der, den die CIS-Billing-Engine oder die Salesforce-Org erledigen sollte.

Die Failure-Modes sind verschieden. Eine direkte API-Integration zwischen zwei Produktionssystemen koppelt ihre Failure-Modes: Wenn Salesforces API langsam ist, wird dann CIS langsam? Wenn ein CIS-Event nicht gepusht wird, sieht der Support-Mitarbeiter in Salesforce veraltete Daten oder einen Fehler? Die ETL-Layer entkoppelt diese Failure-Domains. CIS läuft, Salesforce läuft, die ETL-Layer handhabt die Lücke.

Die Business-Regeln leben an einem Ort. Das Mapping von CIS-Service-Profil zu Salesforce-Account-Feldern ist eine Business-Regel. Das Mapping von Plan-Status zu Opportunity-Stage ist ebenfalls eine. Dass diese Regeln in der ETL-Job-Konfiguration statt verstreut über beide Systeme leben, machte sie auditierbar, testbar und änderbar, ohne beide Produktionssysteme anfassen zu müssen.

BPMN-Workflow-Design

Die Billing-Workflows und die Integration-Workflows wurden in BPMN - Business Process Model and Notation - modelliert. Nicht als Dokumentation im Nachhinein, sondern als Spezifikation, die die Workflow-Engine ausführte.

Dieser Unterschied zählt. BPMN-als-Dokumentation ist ein Diagramm, das am Tag seiner Erstellung korrekt ist und dann von der Realität abdriftet. BPMN-als-Ausführung ist die maßgebliche Definition dessen, was das System tut. Wenn das Vertriebsteam des Telecom-Betreibers verstehen wollte, warum eine Planänderung noch nicht zu Salesforce propagiert hatte, war die Antwort ein BPMN-Diagramm, das exakt zeigte, wo im Workflow der Job stand, auf welche Bedingung er wartete und welcher nächste Schritt folgen würde.

Ich leitete das BPMN-Workflow-Design für die Integration-Seite. Die Herausforderung bestand darin, dass Telecom-Billing-Workflows natürliche Timing-Abhängigkeiten haben - man kann Salesforce nicht mit Rechnungsdaten aktualisieren, bevor der Rechnungszyklus geschlossen ist - die als explizite Wait-Conditions im Workflow-Modell ausgedrückt werden mussten, nicht als Sleep-Timer oder Cron-Schedules. Der Unterschied: Das BPMN-Workflow weiß, warum es wartet, und kann korrekt reagieren, wenn die Bedingung sich auflöst, anstatt zu pollen bis ein Timer feuert.

Frontend: GWT im Jahr 2013

Das CIS-Frontend war auf GWT gebaut - dem Google Web Toolkit, das Java zu JavaScript kompiliert. In 2013 war das für eine komplexe Enterprise-Data-Applikation eine vernünftige Architekturentscheidung. Die Typsicherheit, die Java über eine große Codebase mit vielen Entwicklern bietet, ist nicht trivial. Das Komponentenmodell war ausgereift. Das Debugging-Tooling war besser als die damaligen Alternativen des JavaScript-Ökosystems.

Es ist auch, im Jahr 2026, eine Technologieentscheidung, die eindeutig überholt wurde. Die Web-Plattform hat sich weiterentwickelt. JavaScript-Frameworks haben sich auf Muster geeinigt, die die GWT-Trade-offs unnötig machen. Ich sage das klar, weil es zum ehrlichen Rückblick auf die Arbeit gehört: Ich habe wesentliche UI in GWT gebaut, ich habe ein Team bei GWT-Entwicklung geleitet, und ich kann dir genau erklären, warum diese Wahl 2013 Sinn machte und warum ich sie heute nicht mehr treffen würde.

Ich leitete das Frontend-Development-Team - Code-Reviews, Architekturentscheidungen, die Art von task-leveliger Koordination, die den Unterschied macht zwischen einem Team, das liefert, und einem, das Pull-Requests produziert, die nie gemerged werden. Das war meine erste Erfahrung in einer echten Team-Lead-Rolle, und die Lektionen daraus - über technische Entscheidungen auf Team-Ebene, über die Lücke zwischen Wissen, wie man etwas tut, und Wissen, wie man es jemandem erklärt, der lernt - haben mich durch jede nachfolgende Rolle begleitet.

Was ich mir vorher gesagt hätte

Das Problem der inkompatiblen Datenmodelle zwischen zwei Enterprise-Systemen wird fast nie gelöst, indem man eines der Systeme flexibler macht. Es wird gelöst, indem man die Übersetzungs-Layer explizit besitzt, ihr die richtigen Verantwortlichkeiten gibt und keine der beiden Seiten so tun lässt, als existierte das Modell der anderen nicht.

Die Talend-ETL-Layer funktionierte, weil sie den Übersetzungsjob ernst als Job nahm - nicht als dünnen Adapter, der an eine bestehende API angeschraubt wird. Sie hatte ihren eigenen State. Sie hatte ihre eigene Fehlerbehandlung. Sie war verantwortlich für die Lücke zwischen CIS’ Welt und Salesforces Welt, und sie kannte diese Verantwortung klar.

Dieses Modell - die Grenze besitzen, nicht so tun als wäre sie dünner als sie ist - ist das Ding, zu dem ich bei jedem Integrationsproblem seitdem greife. Andere Tools, gleiche Erkenntnis.