Wie aus einem Migrationsengpass im Jahr 2001 eine Plattform wurde, die heute täglich über 23.000 Jobs in Produktion steuert.
Die Geschichte von JOX beginnt 1995 bei der
Talkline GmbH, damals ein junger
Mobilfunkanbieter im wachsenden deutschen Markt. Den
Tagesbetrieb des damaligen Abrechnungssystems
realisierte Talkline mit einem großen Bestand an
Shell-Skripten mit eingebetteten
sqlplus-Aufrufen. Diese Skripte wurden
manuell gestartet und überwacht. Fehler mussten
erkannt und einzeln nachbearbeitet werden;
Sichtbarkeit über den Gesamtfortschritt der täglichen
Abläufe war kaum vorhanden.
Aus diesem Umfeld entstand bei Talkline schrittweise ein erstes Werkzeug, entwickelt von Alexander Odesser in enger Abstimmung mit den System- und Billing-Analysten im Talkline-Servicebüro: eine Server-Anwendung in Perl, die auf einer Oracle-Datenbank arbeitete, mit einer GUI in SQL-Windows. "Job Maintenance" hieß das. Es lief sehr gut, allerdings nur auf einem einzigen Server. Für die wachsenden Anforderungen einer Multi-Server-Landschaft war es nicht ausgelegt.
In den Folgejahren entwickelte derselbe Autor bei einer Nachfolgefirma eine zweite Generation: den "Job Manager". Er war multi-server-fähig und sauberer aufgebaut, wurde bei Talkline aber nie eingeführt, weil Job Maintenance dort zu gut lief, um es abzulösen.
Den Anstoß gab eine Entscheidung im Jahr 2000: Talkline wollte das in die Jahre gekommene Abrechnungssystem durch eine neue Plattform eines internationalen Anbieters ersetzen. Das Versprechen umfasste auch eine moderne Scheduling-Schicht, die den Batch-Betrieb tragen sollte. In der Praxis stellte sich heraus, dass die mitgelieferte Schicht für den realen Talkline-Betrieb nicht ausreichte. Routine-Abläufe mussten weitgehend manuell gefahren werden, mit den entsprechenden Folgen für Fehlerquote, Nachtdienste und Sichtbarkeit.
An diesem Punkt rief Talkline beim Entwickler von Job Maintenance an. Inzwischen selbständig, übernahm er den Auftrag, das interne Tool so weiterzuentwickeln, dass es den neuen Betrieb tragen würde. Aus diesem Auftrag entstand JOX.
JOX wurde von Grund auf neu in Java entwickelt, von Anfang an multi-server-fähig und mit einem zentralen Repository und verteilt arbeitenden Server-Prozessen. Eine Migrations-Funktion las die Job-Definitionen aus Job Maintenance direkt ein, sodass das angesammelte Talkline-Know-how nicht verloren ging.
Die Einführung dauerte fünf bis sechs Monate. Das Vorgehen war iterativ und eng am tatsächlichen Migrations-Bedarf orientiert; die Branchen- und Talkline-Kenntnis des Entwicklers verkürzte die Abstimmungswege mit dem Servicebüro erheblich.
Die Prozessautomatisierung für das neue Abrechnungssystem und die JOX-Einführung liefen parallel, Schritt für Schritt. Einen vorab festgelegten Endzustand gab es nicht. Die Anforderungen wurden laufend neu priorisiert; was funktionierte, ging in Produktion, und das jeweils Nächstwichtige wurde nachgezogen.
Die Talkline-Kollegen gestalteten beides aktiv mit: die Prozesse, die in JOX abgebildet werden sollten, und JOX selbst, durch Anforderungen, Tests und schnelles Feedback aus dem Produktivbetrieb. In dieser täglichen Zusammenarbeit entwickelte sich das Werkzeug für einen einzelnen Kunden zu einer Plattform, von der seither auch andere Installationen profitieren.
Das neue Abrechnungssystem ging in Produktion, die Prozesse mussten Tag und Nacht laufen. Im Tagesgeschäft waren bei Talkline rund 20 bis 30 eigene Mitarbeiter beschäftigt, dazu 10 bis 15 externe Consultants des Plattform-Anbieters. Drei bis vier Studenten begleiteten zusätzlich nachts die End-of-Day-Verarbeitung. Fehler waren in dieser Phase häufig. Neue Abrechnungslogik traf auf neue Schnittstellen, das sind übliche Anlaufprobleme. Ohne tragfähige Scheduling-Schicht zog aber jeder einzelne Fehler vielfachen Folgeaufwand nach sich.
Mit JOX nahm man das Anstoßen, Überwachen und Behandeln dieser Prozesse Schritt für Schritt in die Hand. Die Analysten modellierten die Abhängigkeiten zwischen den Verarbeitungsschritten als JOX-Gruppen/Workflows, definierten Fehler-Behandlung und Wiederholungslogik einmalig, und ließen sie in JOX laufen. Was vorher manuelle Aufmerksamkeit erforderte, lief jetzt deterministisch. Die eigentlichen Fehler, also die fachlichen in der Abrechnungslogik selbst, wurden erst jetzt sichtbar, weil die manuellen Pannen sie nicht mehr überdeckten.
Der Effekt der Einführung zeigte sich an drei Stellen:
Innerhalb weniger Jahre wuchs die JOX-Installation bei Talkline auf rund 1.000 Jobs pro Tag. Verteilt auf drei bis fünf Solaris-Server, drei bis fünf Oracle-Datenbanken und drei bis vier Areas: eine marktübergreifende plus marktspezifische für die einzelnen Märkte. Eine typische Tagesverteilung umfasste 50 bis 100 Jobs für einen Billrun (der etwa einen Tag lief), 100 bis 200 für die End-of-Day-Verarbeitung, dazu rund 100 für sonstige Prozesse.
Die Arbeit des Talkline-Teams änderte sich grundlegend. Anstelle von manuellem Skriptstart und Fehlersuche modellierten die Kollegen neue Prozesse und brachten sie in JOX. JOX war von Anfang an als Plattform angelegt und nicht als Notlösung für die Migration. In den Folgejahren wurde JOX bei Talkline die zentrale Steuerung für jeden neuen Abrechnungsprozess.
In den Jahren nach der Talkline-Hochphase wurde das Unternehmen Teil eines größeren Mobilfunkanbieters. Der Kundenbestand wurde in das hauseigene Abrechnungssystem migriert. Der hauseigene Scheduler kam damit automatisch zum Einsatz.
Im neuen Betrieb bewährte sich dieser Scheduler nicht in dem Maße, wie JOX es zuvor bei Talkline getan hatte. Die Erinnerung an die JOX-Zeit war im Haus präsent: viele der Kollegen, die die JOX-Landschaft über die Jahre mit aufgebaut hatten, waren weiterhin im Unternehmen.
2013 wurde JOX zurückgeholt, mit einem konkreten Auftrag: Billing und Rating sollten wieder auf JOX laufen. Die Entscheidung fiel ohne akute Krise, auf Grundlage der eigenen Erfahrung. Politisch war sie nicht trivial, fachlich war sie eindeutig.
Im Jahr 2026 steuert JOX bei der freenet DLS GmbH einen wesentlichen Teil des operativen Abrechnungsbetriebs des Mobilfunkanbieters. Seit der Rückkehr 2013 ist die Plattform dort produktiv im Einsatz.
| Kennzahl | Stand 2026 |
|---|---|
| Job-Templates | ca. 4.000 |
| Verteilt auf Gruppen | 77 |
| Areas in Produktion | 15 |
| JOX Locations | 89 |
| Aktive JOX-Server-Anwendungen | 73 |
| Ausgeführte Jobs täglich | über 23.000 |
| Benutzer (in 24h aktiv / gesamt) | ~20 / über 100 |
Diese Skala ist auf eine technisch heterogene Landschaft verteilt. JOX-Repository und Job-Ziele decken heute PostgreSQL, Oracle, MySQL und weitere DBMS ab. Das Betriebssystem ist durchgängig Linux, der Betrieb verteilt sich auf on-premise und Cloud-Umgebungen.
Die 15 Areas in Produktion gliedern den Betrieb: fünf mandantenspezifische Areas für Rating und Billing, eine markenübergreifende für die o.g. Prozesse, weitere für angrenzende Anwendungen. Dazu kommt eine zweite JOX-Installation als Test-Repository, die als Entwicklungs- und Test-Umgebung dient.
Bei freenet DLS dient JOX neben der Steuerung des laufenden Betriebs auch als Entwicklungswerkzeug. Neue Prozesse werden direkt in JOX implementiert und getestet. Die über 100 Benutzer der Plattform kommen aus Entwicklung, Analyse, Betrieb und den verschiedenen Fachbereichen.
Seit den frühen 2000er-Jahren ist die Plattform mehrfach gewachsen. Die Grundarchitektur ist seit 2001 dieselbe: ein zentrales Repository, verteilte Server-Prozesse, eine klare Trennung zwischen Was (Job-Templates in Gruppen) und Wann und Wo (Orders mit Locations in Areas).
Was 2001 als Lösung für ein konkretes Talkline-Problem entstand, ist heute ein tragender Teil des Mobilfunk-Abrechnungsbetriebs.
Aufgrund der Entstehungsgeschichte wurde JOX auf unsere Bedürfnisse hin gebaut und ständig weiterentwickelt, so dass ein perfektes und sehr stabiles Werkzeug für alle operativen Aufgaben entstanden ist.
Ich schätze sehr, dass der Fokus seit Beginn auf der Funktionalität und nicht auf visuellen Effekten liegt. Das hält die Anwendung klein und die GUI schnell.
Das Konzept mit zentralem Repository für Verwaltung, Definition und Ausführungssteuerung hat sich bewährt, ist sehr flexibel in der Nutzung und auch über weite Netzwerkstrecken zwischen Repository und Serverprozess stabil.
Mit JOX haben wir einen äußerst zuverlässigen Scheduler mit deterministischen Ergebnissen, der aufgrund der Historisierung von Abläufen und Ergebnissen die Wirtschaftsprüfer mehr als zufriedenstellt. Wir setzen ihn bei kleinen Routineaufgaben, umfangreichen Tagesverarbeitungen bis hin zur Migration eines Abrechnungssystems erfolgreich ein.