Het probleem
Begin jaren 2000 had een theater of bioscoop dat fatsoenlijk kaarten wilde verkopen twee opties: een kassasysteem kopen dat op een server in een achterkamer leefde, met een consultant om het te installeren en een andere om het te upgraden, of bij papier blijven. Festivals hadden een ergere versie van hetzelfde probleem, omdat hun kassa drie weken per jaar bestond en elke keer vanaf niets moest worden opgezet.
Bij Athena, waar ik van 2000 tot 2006 werkte, wilden we iets anders bouwen: een ticketingplatform dat een zaal kon gaan gebruiken zonder iets te installeren, dat werkte met de hardware die al op de balie stond, en dat wij voor hen draaiden.
Wat het was
Twee helften, verbonden door een draad.
Aan de kant van de zaal een touchless deploymentplatform. De client kwam over het netwerk binnen en werkte zichzelf bij; niemand in de zaal installeerde of upgradede iets. De interface was gebouwd in Flash, destijds de enige manier om een rijk, snel en consistent scherm te krijgen op welke machine de zaal ook toevallig had. Daaronder lokale hardware-integratie: ticketprinters, kaartlezers, de kiosk- en balierandapparatuur waar een kassa op draait, aangestuurd vanuit de via de browser geleverde client.
Aan de remote kant een volledig beheerde webapplicatie: de eigenlijke engine voor ticketing, zaalindeling, prijzen, verkoop en rapportage, door ons gedraaid, voor elke zaal, als gedeelde dienst. De zaalclient en de centrale dienst praatten via Microsoft .NET Remoting, destijds cutting edge, waardoor we een echt objectmodel over de draad konden behouden in plaats van zelfgebouwde messaging.
Het woord voor deze opzet bestond nog niet. Vandaag zou het een platform-as-a-service met een beheerde edge-client heten. Toen was het simpelweg de enige manier die we konden bedenken om bioscopen, theaters en festivals in heel Nederland vanuit één systeem te bedienen zonder busje en consultant.
Mijn rol bewoog mee met het project. Ik begon met de haalbaarheidsstudies en proof-of-concept-projecten, bracht de workflows en rapportages in kaart die de zalen werkelijk nodig hadden, en koos daarna de technologie die de huidige eisen aankon en de eisen die we zagen aankomen. Later leidde ik de engineering, die tegen die tijd ook beveiliging omvatte, hoge beschikbaarheid op Windows Server en Cisco-infrastructuur, en het beheer van een dienst die, als hij uitviel, een kassa op vrijdagavond meenam.
Wat het me leerde
Het platform is het product. Niemand kocht “ticketing”. Ze kochten niet hoeven nadenken over ticketing. Die les heeft alles gevormd wat ik sindsdien heb gebouwd, van een clubplatform tot het governanceplatform waar ik nu aan werk.
Beschikbaarheid is een ontwerpbesluit, geen beheertaak. Een kassa kan niet wachten. We ontwierpen ervoor vanaf het eerste proof of concept, en het is waarom ik nog steeds elk architectuurdiagram lees door te vragen wat er gebeurt om zeven uur op vrijdagavond.
Kies technologie voor waar de eisen heen gaan. .NET Remoting was een weddenschap op een programmeermodel, niet op een protocol. Het was de juiste weddenschap voor zijn tijd en werd later ingehaald, wat ook deel is van de les: een besluit is juist voor een horizon, en het eerlijke is om te zeggen welke.
Status
Draaide jaren in productie en bediende de Nederlandse zalenmarkt. Technologie van zijn tijdperk, allang vervangen. Het staat hier omdat het de eerste keer was dat ik bouwde wat ik steeds opnieuw bouw: een bestuurde dienst waar andere organisaties hun bedrijf op draaien.