Digital Platform

The club’s login and payment ran on two systems whose failure would have shown up immediately in merchandise revenue. In the end I was chiefly responsible for both, above all on matchdays, when the online shop saw its heaviest traffic. I had started three years earlier as a junior.

Where it started

The club was driving its digital transformation with a team of external consultants that reported directly to the CIO. I joined as a junior developer and came in on the single sign-on. Over three years I moved from the login through payment into a number of smaller line-of-business applications, while the team grew smaller year by year. In the end there were three of us left, and the club began hiring its own developers. We handed over what we had built to them. Onboarding them and helping screen candidates became part of my job toward the end.

The two systems that could not go down

Login and payment were the backbone of the online shop, and I was chiefly responsible for both. On matchdays of all times, when traffic was heaviest, they had to hold. If one went down, the sale of fan merchandise dropped at once. That everything ran was the baseline, not the goal. Both systems had to run reliably and keep growing at the same time, and both were on me. That is exactly what made the work what it was: every load spike and every problem was in the line of fire straight away, while the systems were being developed further in parallel.

The single sign-on was our own implementation of the CAS standard, with an external variant for the shop customers and an internal one for the departments. I took the system over and developed it for years, latterly leading it with one other developer. A system like that you run yourself, with everything that entails. Every outage and every load spike is on you. Keeping a JavaEE application running reliably on WildFly in that state for years taught me more than any quiet project.

The point of contact for whatever came up

Alongside the two critical systems I was the point of contact for the web-based line-of-business applications. I took the requirements straight from the departments and turned them into usable interfaces. Technically they all followed the same principle: leave SAP in its standard, build everything else in Java and make it available to the departments over the web, with data from OData services.

On top of that came whatever was needed on short notice. When seats from the stadium were sold to fans, I built the application to reserve them online and, on pickup day, prove the holder’s entitlement by QR code. For a customer terminal of the kind you know from retail, an interface took shape where you put together a shirt and later picked it up printed. Things like that landed with me, because it was clear they would run once I took them on.

My role

From joining as a junior on the single sign-on through to the handover to the club’s own developers. Toward the end I was responsible for the two business-critical systems, brought the new colleagues up to speed and helped screen candidates. What the club carried on with its own team afterward built on what we had handed over.