Digitale Plattform

Login und Bezahlung des Vereins liefen über zwei Systeme, deren Ausfall sofort im Merchandise-Umsatz sichtbar gewesen wäre. Für beide war ich am Ende hauptverantwortlich, gerade an Spieltagen, wenn der Online-Shop seinen größten Andrang hatte. Angefangen hatte ich drei Jahre zuvor als Junior.

Ausgangslage

Der Verein trieb seine digitale Transformation mit einem Team externer Berater voran, das direkt unter dem CIO arbeitete. Ich kam als Junior-Entwickler dazu und stieg beim Single-Sign-On ein. Über drei Jahre wanderte ich vom Login über die Bezahlung bis in etliche kleinere Fachanwendungen, während das Team von Jahr zu Jahr kleiner wurde. Am Ende waren wir noch zu dritt, und der Verein begann, eigene Entwickler einzustellen. Ihnen übergaben wir, was wir gebaut hatten. Sie einzuarbeiten und Bewerber mitzuscreenen gehörte zuletzt zu meiner Aufgabe.

Die zwei Systeme, die nicht ausfallen durften

Login und Bezahlung waren das Rückgrat des Online-Shops, und für beide war ich hauptverantwortlich. Ausgerechnet an Spieltagen, wenn der Andrang am größten war, mussten sie halten. Fiel eines aus, brach der Verkauf von Fanartikeln sofort ein. Dass alles lief, war dabei die Grundannahme, nicht das Ziel. Beide Systeme mussten zuverlässig laufen und zugleich weiterwachsen, und beides lag bei mir. Genau das machte die Arbeit besonders: Jede Lastspitze und jedes Problem stand sofort im Kreuzfeuer, während die Systeme parallel weiterentwickelt wurden.

Der Single-Sign-On war eine eigene Implementierung nach dem CAS-Standard, mit einer externen Variante für die Shop-Kunden und einer internen für die Fachbereiche. Ich habe das System übernommen und über Jahre weiterentwickelt, zuletzt mit einem weiteren Entwickler in der Hauptverantwortung. Ein solches System betreibt man selbst, mit allem, was dazugehört. Jeder Ausfall und jede Lastspitze liegt bei einem. Eine JavaEE-Anwendung, die auf WildFly lief, über Jahre in diesem Zustand zuverlässig zu halten, hat mir mehr beigebracht als jedes ruhige Projekt.

Ansprechpartner für alles, was dazwischen kam

Neben den beiden kritischen Systemen war ich die Anlaufstelle für die webbasierten Fachanwendungen. Ich nahm die Anforderungen direkt bei den Fachbereichen auf und übersetzte sie in benutzbare Oberflächen. Technisch folgten sie alle demselben Prinzip: das SAP im Standard belassen, alles andere in Java bauen und den Fachbereichen über das Web zugänglich machen, mit Daten aus OData-Services.

Dazu kam, was spontan gebraucht wurde. Als Sitze aus dem Stadion an Fans verkauft wurden, baute ich die Anwendung, über die man sie online reservierte und am Abholtag per QR-Code als berechtigt auswies. Für ein Kundenterminal, wie man es aus dem Einzelhandel kennt, entstand eine Oberfläche, an der man sich ein Trikot zusammenstellte und später fertig bedruckt abholte. Solche Sachen landeten bei mir, weil klar war, dass sie liefen, wenn ich sie übernahm.

Meine Rolle

Vom Einstieg als Junior am Single-Sign-On bis zur Übergabe an die eigenen Entwickler des Vereins. Zuletzt verantwortete ich die beiden geschäftskritischen Systeme, arbeitete die neuen Kollegen ein und screente Bewerber mit. Was der Verein danach mit eigenem Team weiterführte, baute auf dem auf, was wir übergeben hatten.