Sorry, even wat borstklopperij, maar ben wel een beetje trots hierop. Enkele jaren geleden werd ik door een oud collega van mij geïnformeerd: hij had gehoord over een project waarvoor ze eigenlijk iemand zochten met mijn profiel (mijn naam was zelfs genoemd). Interaction design achtergrond, in staat zelfstandig een UI neer te zetten op basis van moderne standaarden. De opdracht: een oude extranet applicatie, met een historie uit begin jaren nul even een nieuwe smoel geven (en responsive maken). De opdracht werd gepubliceerd, ik reageerde, en uiteindelijk werd besloten dat ik deze mocht uitvoeren.
Het bleek te gaan om een verzameling oude stijl PHP en CGI scripts. Met een op framesets gebaseerde layout, zoals je dat rond 2000 wel vaker zag. Ik ken veel collega’s die liever wegrennen bij een dergelijke opdracht, zoveel oude code, zoveel historie, maar ik had het idee dat ik het wel kon doen. Een aanbestedingstraject voor een volledige nieuwbouw bleek jaren geleden mislukt omdat de offertes buiten budget vielen. Of ik er dus misschien nog iets van zou kunnen maken.
Ik had voorgesteld dat ik binnen een week of twee zou inventariseren wat de opties zouden zijn. Al snel moest ik constateren dat simpelweg wat restylen niet tot de mogelijkheid behoorde, de code was te weinig consistent. Plan B diende zich snel aan, er waren immers enkele klanten die al geruime tijd aan het klagen waren, deze zouden we prioriteit gaan geven. Zo geschiede.
Het nieuwe idee was om een API in PHP te maken, zodat deze naast de bestaande applicatie kon draaien op dezelfde server. En daar bovenop vervolgens een moderne React frontend te zetten. Mooi? Mwa, werkbaar: ja. En zo was er aan het einde van 2017 een versie die in productie draaide. Was initieel het plan om het nog te laten draaien op de oude server, inmiddels was de nieuwe applicatie uitgerold op een modernere virtuele private cloud omgeving met authenticatie en autorisatie op basis van Keycloak (een OAuth provider).
Na de initiele oplevering werd gekeken naar het toevoegen van nieuwe portalen, maar budgettaire beperkingen stonden het toen even niet toe. Hier en daar werd er wel wat verbeterd en kleine stukjes functionaliteit toegevoegd (zoals een admin interface om de portalen te kunnen beheren), maar in 2020 kwam er een nieuwe vraag bij mij terecht. Er was nog een ander portaal dat extreem verouderd was.
De vraag was of ik in aanloop van een complete herbouw van luchtvaartmeteo.nl misschien kon zorgen voor een visual update van luchtvaartmeteo.nl. Ook hier was de conclusie dezelfde, dat kan eigenlijk niet, maar inmiddels lag er dus wel een ‘framework’ waarmee de luchtvaart-klanten wellicht ook bediend konden worden.
Parallel aan mijn werkzaamheden werden door andere consultants requirements verzameld en een project start architectuur opgesteld voor wat fase 2 zou worden: een mogelijke nieuwbouw of koop, voor alle extranetten. Terwijl ik doorwerkte aan een nieuwe look & feel, waarbij soms sommige producten toch wat meer werden vernieuwd dan oorspronkelijk beoogd, er soms wél beantwoord werd aan een verzoek om iets extra’s mee te nemen, en alles ondertussen ook nog even werd gemigreerd naar AWS, werd er dus op een ander vlak nagedacht wat er allemaal zou moeten gebeuren om zoiets opnieuw te bouwen.
Begin 2021 werd besloten dat fase 1 (mijn ‘tijdelijke’ oplossing) in eerste inschatting voldeed aan belangrijkste wensen. Er werd een pentest uitgezet (geen zorgelijke bevindingen), de applicatie werd meegenomen in een BIO compliancy check (een ISO 27002 vertaling voor de Nederlandse Overheid), de code werd door een externe partij beoordeeld op kwaliteit en onderhoudbaarheid (ondanks de pragmatische totstandkoming viel het mee), en dus werden de voorbereidingen getroffen voor een daadwerkelijke live-gang. Het externe bureau dat ook had geholpen de code te beoordelen leverde een developer (eindelijk een collega!) die ging meewerken aan de applicatie om deze op een hoger niveau te krijgen.
Inmiddels werd ook de beslissing over fase 2 voorbereid. Was eerst de vraag ‘build’ or ‘buy’, de vraag werd: ‘re-use’, ‘build’ or ‘buy’. Een op het oog kleine aanpassing, maar een aardige semantische verschuiving die wel gelijk ook duidelijker benadrukte dat het voortbouwen op het resultaat uit fase 1 ook een serieuze optie zou kunnen zijn. En dat werd dan ook de insteek: re-use before buy, buy before build. Afgelopen week werd de knoop doorgehakt: dit jaar gaan we live met het nieuwe extranetten portaal dat vervolgens ook zal gelden als de basis voor verdere doorontwikkeling in de komende jaren. Een platform op basis van een systeem dat sinds 2017 ad-hoc door mij was ontwikkeld.
Overheidsprojecten lijken bijna altijd over budget te gaan. De omzet die ik tot dusver op het volledige project heb geboekt de afgelopen vier jaar was €200.000 (dat is niet de volledige prijs; sinds halverwege dit jaar is er ook een extra ontwikkelaar, en zijn er binnen het KNMI ook andere mensen aangehaakt). Ik vrees dat als er was gekozen voor het opnieuw bouwen van de hele applicatie, alles gigantisch over de kop (qua geld en tijd) had kunnen gaan. Ook een ‘buy’, waarbij er zou worden gekeken naar een standaard product dat geconfigureerd en beheerd kon worden door een derde partij zou waarschijnlijk zoveel fijnslijperij vereisen om te voldoen aan alle wensen dat ook die optie veel duurder zou uitvallen. Soms is dan de pragmatische oplossing zo verkeerd nog niet. Half oog op toekomstige ontwikkelingen, proberen te standaardiseren waar mogelijk, en soms toch even voor de snelle in plaats van de perfecte oplossing te gaan, pragmatisch, het kan werken, ook voor de lange termijn.
Vond je dit leuk, volg me op Mastodon, voeg die RSS, euh ATOM feed toe aan je feedreader, of schrijf je hieronder in op mijn nieuwsbrief.
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .