The problem
In the early 2000s a theatre or cinema that wanted to sell tickets properly had two options: buy a box-office system that lived on a server in a back room, with a consultant to install it and another to upgrade it, or keep the paper. Festivals had a worse version of the same problem, because their box office existed for three weeks a year and had to be set up from nothing each time.
At Athena, where I worked from 2000 to 2006, we set out to build something different: a ticketing platform that a venue could start using without installing anything, that worked with the hardware already on their counter, and that we ran for them.
What it was
Two halves, joined by a wire.
On the venue side, a touchless deployment platform. The client arrived over the network and updated itself; nobody at the venue installed or upgraded anything. The interface was built in Flash, which at the time was the only way to get a rich, fast, consistent screen on whatever machine the venue happened to have. Underneath it, local hardware integration: ticket printers, card readers, the kiosk and counter peripherals a box office lives on, driven from the browser-delivered client.
On the remote side, a fully serviced web-based application: the actual ticketing, seating, pricing, sales and reporting engine, run by us, for every venue, as a shared service. The venue client and the central service talked over Microsoft .NET Remoting, which was cutting edge for the period and let us keep a real object model across the wire instead of hand-rolled messaging.
The word for this arrangement did not exist yet. Today it would be called a platform-as-a-service with a managed edge client. Then it was simply the only way we could think of to serve cinemas, theatres and festivals across the Netherlands from one system without a van and a consultant.
My part moved as the project did. I started with the feasibility studies and proof-of-concept projects, mapped the workflows and reporting the venues actually needed, and then chose the technology that could meet the current requirements and the ones we could see coming. Later I led the engineering, which by then included security, high availability on Windows Server and Cisco infrastructure, and the operations of a service that, when it went down, took a Friday-evening box office with it.
What it taught me
The platform is the product. Nobody bought “ticketing”. They bought not having to think about ticketing. That lesson shaped everything I have built since, from a club platform to the governance platform I am working on now.
Availability is a design decision, not an operations task. A box office cannot wait. We designed for it from the first proof of concept, and it is why I still read every architecture diagram by asking what happens at seven on a Friday evening.
Choose technology for where requirements are going. .NET Remoting was a bet on a programming model, not a protocol. It was the right bet for its time and was later superseded, which is also part of the lesson: a decision is correct for a horizon, and the honest thing is to say which one.
Status
Ran in production for years and served the Dutch venue market. Technology of its era, long since replaced. It is here because it was the first time I built the thing I keep building: a governed service that other organisations run their business on.