Bouw niet opnieuw — bouw eromheen.
Elke organisatie heeft ze: applicaties die functioneel doen wat ze moeten doen, maar waar gebruikers tegenop zien. Trage interfaces, omslachtige flows, vijf klikken voor wat er één zou moeten zijn. De software werkt — maar werkt tegen je.
De reflex is: vervangen. Een nieuw systeem bouwen. Migreren. Budget aanvragen. Achttien maanden later live.
Er is een andere weg.
AAD is het principe waarbij je een bestaande applicatie niet vervangt, maar verrijkt. Je bouwt een nieuwe ervaring bovenop de bestaande infrastructuur — zonder die infrastructuur aan te raken.
Geen migratie. Geen vendor lock-in discussies. Geen achttien maanden wachten. Dezelfde backend, dezelfde API's, dezelfde data — maar een fundamenteel betere gebruikerservaring.
Het is verwant aan het Strangler Fig Pattern uit software-architectuur: je laat het oude systeem intact, bouwt er geleidelijk omheen, en op het moment dat de nieuwe laag compleet is, is het oude systeem vanzelf overbodig geworden.
Een gemeente biedt burgers de mogelijkheid om overlastmeldingen te doen via een webformulier. Het formulier is gebouwd op een standaard formulierenplatform — prima technologie, maar de gebruikerservaring is ontworpen voor de meest generieke situatie. Meerdere stappen, verplichte velden die niet relevant zijn, een sessie die verloopt als je even nadenkt.
Wat ik bouwde: een native app en een webvariant die exact dezelfde API aanspreken — dezelfde sessie-cookies, dezelfde CSRF-tokens, dezelfde backend. Maar met een interface die is geoptimaliseerd voor de meest voorkomende meldingen. Vooraf ingevulde gegevens, slimme defaults, lokatiebewust.
Het gemeentelijke systeem merkt er niets van. Dezelfde meldingen komen binnen in dezelfde database, verwerkt door dezelfde ambtenaren. Maar de burger is in 30 seconden klaar in plaats van 5 minuten.
De uitdaging was niet de interface maar de sessie. Het formulierenplatform vereist een actieve browsersessie met specifieke cookies. Oplossing: een verborgen WebView die de sessie initialiseert, cookies extraheert via de CookieManager, en deze injecteert in native API-calls. Een auto-refresh houdt de sessie levend. Geen enkele regel code op de server gewijzigd.
Een landelijke vervoersdienst biedt een mobiele app aan. Die app is technisch een React Native wrapper rondom een Angular webapplicatie. Elke interactie laadt een volledig webframework, geauthenticeerd via Azure AD B2C. Trage laadtijden, geen offline mogelijkheden, een generieke interface die niet is geoptimaliseerd voor de meest voorkomende actie — een rit boeken.
Wat ik bouwde: een native Android app die dezelfde authenticatie en dezelfde REST API aanspreekt. De API werd volledig geanalyseerd vanuit de bestaande webapplicatie — elke endpoint, elke parameter, elke flow. Vervolgens: een interface gebouwd rond de primaire use case. Vooraf ingevulde vertrekadressen, favoriete bestemmingen, boeking in twee tikken.
De backend merkt er niets van. Dezelfde boekingen in hetzelfde systeem. Maar de gebruiker boekt een rit in 15 seconden in plaats van 2 minuten.
De originele app verstopt een complete Angular SPA achter een WebView. Door de API te analyseren kon alle WebView-overhead worden geëlimineerd. MSAL Android handelt de B2C-authenticatie af, Retrofit doet de API-calls. Geen proxy, geen wrapper, geen web — puur native. Gedeployed als installeerbare PWA.
Voor prototyping: Je kunt een verbeterde ervaring bouwen en testen zonder enige backend-wijziging. Als het prototype faalt, is er niets kapot. Als het slaagt, heb je direct een werkend product.
Voor geleidelijke uitfasering: AAD is de eerste stap van het Strangler Fig Pattern. Je begint met de gebruikerservaring — de laag die het dichtst bij de mens zit. Vervolgens vervang je geleidelijk de onderliggende services:
Elke fase levert direct waarde. Elke fase is onafhankelijk testbaar. En op elk moment kun je stoppen zonder dat je half-af zit — want de bestaande infrastructuur draait gewoon door.
Voor risicoreductie: De grootste oorzaak van gefaalde IT-migraties is de big bang: alles tegelijk vervangen, alles tegelijk live. AAD elimineert die big bang. Je vervangt incrementeel, valideert per fase, en de oude en nieuwe wereld draaien parallel.
Dit is geen kwestie van "een appje bouwen." Je bouwt een architectuurlaag die moet integreren met bestaande systemen — vaak zonder documentatie.
API's analyseren vanuit bestaande applicaties, authenticatieflows reconstrueren, sessiemanagement begrijpen
Android CookieManagers, Azure B2C tokenvernieuwing, CSRF-protectie, WebView-sessies
Het Strangler Fig Pattern is geen truc maar een strategie die over maanden wordt uitgerold
Je bouwt eromheen, niet ertegen. Eén verkeerde API-call en je verstoort het productiesysteem van je opdrachtgever
De beste applicatie die je kunt bouwen is soms niet de applicatie die alles vervangt — maar de applicatie die alles beter maakt zonder iets aan te raken.
Bouw niet opnieuw. Bouw eromheen.
Christian Glebbeek — iCt Horse | Connecting the dots