De wederopstanding van de Fat Client

De jaren tachtig staan bekend om onrust in het Midden Oosten, ongelooflijk slechte kapsels en vreselijke muziek. Maar natuurlijk vooral om het client/server-model voor applicaties. Zoals alles in de cultuur komt al het oude vroeg of laat weer terug in het straatbeeld. Met het stempel ‘retro’ erop zijn de muziek, de mode en de kapsels uit de jaren tachtig ineens weer in de mode. Hetzelfde geldt voor mobiele applicaties en het client/server-model.

De mobiele applicaties van vandaag binden de strijd aan met de uitdagingen die client server computing in de jaren tachtig om zeep hebben geholpen. Het complexe distributiemodel om client-software bij te werken, de gedistribueerde architectuur en de noodzaak om voor verschillende platformen te ontwikkelen door gebrek aan overdraagbaarheid, zorgen voor extra kosten en vertraging. De vraag is of mobiele applicaties kunnen winnen van de jarenoude plaag die client/server tergt, nu er een sterk verbeterde architectuur beschikbaar is en er betere distributiemodellen zijn. Of zullen enterprise mobile apps net zo eindigen als de thin clients?

Ik ben vast niet de enige die weet dat er soms veranderingen niet werden doorgevoerd, puur omdat het te moeilijk was en teveel kostte. Met de opkomst van app stores is dit probleem aanzienlijk verminderd. Maar een nieuwe uitdaging dient zich aan: bij de meeste applicaties controleert de eindgebruiker de updates. Dit is vergelijkbaar met de situatie waarin het IT-team er geen controle over had welk werkstation werd in- of uitgeschakeld en zo het risico liep dat gebruikers de nachtelijke update misliepen. In de mobiele wereld zijn ontwikkelaars ervan afhankelijk of gebruikers de update daadwerkelijk uitvoeren. Hoewel dit beter is dan de werkwijze in de jaren tachtig is het nog steeds een potentieel probleem, vooral als er kritieke updates moeten worden uitgevoerd. Vergeet niet dat ontwikkelaars nog steeds alle oude api’s moeten handhaven tot alle gebruikers hun (fat) clients hebben geüpdate. Problemen met de api’s zijn echte maintenance uitdagingen en dat leidt tot het tweede probleem, de complexiteit van gedistribueerde architecturen.

Je kunt je afvragen of een gedistribueerde architectuur echt een probleem is. Iedere architectuur heeft uiteraard zowel voor- als nadelen. Ik doel vooral op de cyclus van verandering. Complexiteit is zonder twijfel de Magere Hein van applicaties. Mijn ervaring is dat een gedistribueerde architectuur, zoals je die ziet in de huidige golf van mobiele applicaties, complex wordt door twee drie vragen. Waar moet de functionaliteit geplaatst worden? Hierbij is het vinden, debuggen en uiteindelijke oplossen van het probleem het meest complex. En wat gebeurt er als er geen 3G-netwerkverbinding is? Hoe gaan we om met security issues van een mobiele applicatie? Normaal gesproken zou het een oplossing zijn om ervoor te zorgen dat mensen op afstand kunnen werken, maar dit vraagt uiteraard meer van de applicatie. Niet alleen moet er worden geïnvesteerd in lokale dataopslag voor ieder apparaat, maar het zorgt ook voor een complex geheel van dataconnectiviteit en synchronisatiekwesties. Los van het feit dat niet iedere applicatie zijn minimale dataset lokaal op een device kan plaatsen, simpelweg omdat de dataset te groot is voor het device.

In de mobiele wereld blijven deze complexiteitsfactoren ontwikkelaars achtervolgen, terwijl de toenemende vraag naar functionaliteit en beschikbaarheid een angstaanjagend tempo vereist. Dit is een nieuw paradigma. Omdat toestellen en applicaties vervangbaar zijn, is het cruciaal om de vraag te kunnen bijbenen. Wie daar niet in slaagt, moet met lede ogen toezien dat er simpelweg voor een andere applicatie wordt gekozen.

Tot slot de uitdaging van het gebrek aan draagbaarheid, die bij velen herinneringen zal oproepen aan de oude OS/2- en Windows-compatibiliteitsoorlogen. Vandaag de dag moeten applicaties kunnen draaien op alle mogelijke soorten hardware en software zoals verschillende edities van Windows, Mac OS en Android. Bedenk eens hoeveel verschillende mobiele apparaten je de afgelopen zeven jaar gebruikt hebt en reken daarbij de levensduur van de gemiddelde zakelijke applicatie mee. Eng toch? Het snelle tempo van veranderingen in relatie tot mobiele apparaten onderstrepen dit probleem voor alle ontwikkelaars van mobiele applicaties die werken binnen het client-server paradigma. Bijblijven kost veel geld en tijd en dat leidt in de mobiele wereld vrijwel altijd tot een afgeschreven applicatie.

Met de komst van HTLM5 en 4G netwerken denk ik dat de geschiedenis zich zal herhalen. Het huidige mobiele computing-paradigma zal snel worden vervangen door thin client applicaties, net als client-server met de ondersteuning van HTML en RIA. Deze toepassingen krijgen misschien een bepaald omhulsel om beter te integreren met een specifiek apparaat, maar zijn in de kern gewoon browsers die toegang hebben tot webapplicaties. En gezien het tempo van de mobiele wereld denk ik dat deze verschuiving veel sneller plaatsvindt dan in de client-server. Samenvattend: 'Thin is in, vooral voor enterprise mobile toepassingen.'

Belangrijke voetnoot bij deze ontwikkeling is dat het, net als bij andere keuzes in relatie tot de business en haar processen, er niet altijd een zwart-wit antwoord uit komt. Er zijn veel aspecten die van invloed zijn op het afwegingsproces voor een native client-applicatie versus een webgebaseerde app. De keuze voor laatstgenoemde biedt aantoonbare voordelen als het gaat om bedrijfsmatige applicaties. Soms kun je echter in specifieke situaties toch beter rekenen op native applicaties. Wanneer je bijvoorbeeld als vertegenwoordiger een catalogus-/pricing-applicatie gebruikt op locatie, wil je niet afhankelijk zijn van de 3G-verbinding. Die vormt, zeker binnen een modern pand, een behoorlijk operationeel risico. Zo zijn er nog meerdere voorbeelden te bedenken waarom ‘fat clients’ voorlopig nog relevant blijven. Het is hoe dan ook belangrijk om als bedrijf stil te staan bij de benodigde functionaliteit en toegankelijkheid bij het bepalen van de mobiele strategie en de juiste keuzes te maken met betrekking tot beheersbaarheid, functionaliteit en beschikbaarheid van applicaties.