To cliënt, to server or to JavaScript?

Hoe moeilijk kan het zijn? Bepalen wat op de cliënt moet gebeuren en wat op de server. Blijkbaar best moeilijk als je ziet dat de taken tussen die twee al pakweg 30 jaar alsmaar anders worden verdeeld.

In het mainframe- en minitijdperk was de wereld nog eenvoudig: bijna alle slimmigheid zat in de server. Maar ook toen waren er al grafische terminals die schermafhandeling deden en snapte Sun al dat schijven in werkstations meer konden dan alleen lokale data opslaan.

De pc zette de boel flink op zijn kop. De meeste slimmigheid zat opeens in dat doosje op je bureau en de server mocht een beetje dommig file- en printserver spelen.

Kaboem: het internet! Een "cliënt" kan opeens wereldwijd diensten opvragen bij "servers". Met de browser als moderne kijkdoos om content te tonen die servers opsturen.

Al snel werd de browser ook ingezet om aan de client-kant kunstjes te gaan doen: "Met blijdschap geven wij in 1995 kennis van de geboorte van onze browser-scripttaal. Wij noemen haar: Java Script". Niks voor echte programmeurs natuurlijk, maar best leuk om op de cliënt mee te hobbyen.

Het blijft wonderlijk dat wat ooit een tweederangs script-taaltje werd genoemd is uitgegroeid tot misschien wel de belangrijkste programmeertaal op dit moment. Programmeertaal? Jazeker. Je mag het met alle uitbreidingen tegenwoordig een echte programmeertaal noemen. Belangrijkste? Daar kun je natuurlijk eindeloos over discussiëren. Maar feit is dat veel vernieuwingen tegenwoordig komen uit de JavaScript hoek.

Naast het feit dat JavaScript als taal volwassen is geworden, is er ook een gigantisch 'ecosysteem' omheen ontstaan. Een JavaScript framework als jQuery wordt in meer dan 90% van de webpagina's wereldwijd gebruikt. JSON is misschien wel het belangrijkste uitwisselformaat voor berichten geworden. Wat je ook nodig hebt, in de JS-wereld is er wel wat voor te vinden. Vaak in de vorm van open source en gratis beschikbaar.

Maar de cliënt vreet nog verder aan de server. Hij is tegenwoordig geschikt als runtime-omgeving voor volwaardige applicaties. Met JavaScript Front End frameworks, zoals React, Angular en Vue, bouw je volwaardige applicaties die in een browser of via een app draaien.

En onze vriend de server? Die heeft het moeilijk. Hij mag mag nog steeds doen wat hij goed kan. Bijv. data leveren aan cliëntapplicaties als die daar om vragen. Of slimme dingen doen waar veel capaciteit voor nodig is. Maar waar hij samenwerkt met een cliënt steekt zijn vriendje hem steeds vaker de loef af.

Een mooi bewijs van het volwassen worden van JavaScript is dat, met de komst van Node.js in 2009, Javascript "zelfs" is te gebruiken is op de server. Waarmee je als JavaScript-ontwikkelaar nu de luxe hebt om te kunnen kiezen waar je je code wilt laten uitvoeren. Oftewel: 'to cliënt or to server' wordt met JavaScript 'to cliënt and to server'.

Design-dingen die uit dingen bestaan

Service-oriëntatie en daarvan afgeleide Service geOrienteerde Architectuur zijn voor een belangrijk deel gebaseerd op "systeemdenken”. Bijvoorbeeld terug te zien in de ISO-42010 definitie van architectuur: “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”. Het zegt dus iets over een systeem dat uit elementen bestaat, maar dat zelf ook onderdeel is van een omgeving (wat ook een systeem is...). Een bekende manier om het "dingen die uit dingen bestaan" uit te leggen zijn de Lego-blokjes waarmee je stapsgewijs steeds grotere dingen kunt maken.

Vandaag kwam ik een originele uitleg van modulair denken tegen in relatie tot “design”. Om de denkwijze duidelijk te maken wordt daar verwezen naar weer een ander vakgebied: scheikunde. Een gebied waar de kleinste eenheid. het atoom, in verschillende samenstelling moleculen vormen, die op hun beurt samenklonteren tot complexe organismen en uiteindelijk onze wereld vormen. Voorwaar een mooi voorbeeld van modulair denken dat goed illustreert hoe je met slim combineren een heel eind kunt komen. 

“Atomic Design” kijkt op een vergelijkbare manier naar het ontwerpen van web-pagina’s die stapsgewijs zijn opgebouwd uit:

1. Atomen – HTML-tags als label, input, button
2. Moleculen – HTML-tags als een Form waarin label, inpt en button samen worden gebruikt
3. Organismen  - “groepen van moleculen” die vaak samen worden ingezet; bijv. een header met daarin een logo, navigatiemenu en zoekbox.
4. Templates – hier eindigt de analogie met scheikunde en wordt een concreet eindobject samengesteld dat herkenbaar wordt voor gebruikers (bijv. een html-wireframe) 
5. Pages – een instantie van een template (bijv. een webpagina) met echte content.

Voordelen van deze manier van ontwerpen zijn vergelijkbaar als bij dienstgericht denken: je kunt van meer abstract naar concreet werken, het komt de consistentie en schaalbaarheid ten goede en je realiseert stapsgewijs en met bijgestelde inzichten het uiteindelijke product.

Nieuw? In deze context voor mij zeker. Maar denken in termen van “dingen in dingen” is natuurlijk niet nieuw. De auteur verwijst terecht naar een stukje van Tim Berners Lee, die nog maar eens uitlegt waarom “modulariteit” zo’n cruciaal ontwerpprincipe is van het World Wide Web. Het product dat misschien wel het beste bewijst wat zo'n ontwerpprincipe aan kwaliteit kan opleveren.

App en cloud: that's all

Een van de mooie dingen van de toekomst is dat niemand zeker weet hoe hij er uit ziet. Zelfs Gardner niet. Maar die heeft er vaak best wel kijk op.

Bijvoorbeeld in het al weer een paar jaar oude ‘The Nexus of Forces’. Over de vier krachten, mobile, cloud, information en social, die tsunami-achting steeds meer kracht ontwikkelen en bezig zijn de wereld op zijn kop te zetten.

Zo hoeven gebruikers zich bijvoorbeeld niet meer aan te passen aan wat IT biedt, maar moet IT zich aanpassen aan wat de gebruiker wil. Een computer aan een draadje? Ik dacht het niet. Iets bestellen en het een dag later ontvangen? Ooit van Netflix en Spotify gehoord? Coolblue wil pakjes dezelfde dag gaan bezorgen en Jeff ‘Amazone’ Bezos is wel degelijk serieus als hij zegt dat drones de bezorgers van de nabije toekomst zijn.

Steeds meer diensten worden snel en op maat geleverd met de gebruiker aan de knoppen. De knoppen van zijn mobiele device dus Dat draadloos communiceert met een cloud die diensten op maat levert.  Meer is er niet meer nodig. Denkt Gardner. En denk ik.

Mobiele diensten worden het niet

Mobiele diensten worden het echt niet. Ze zijn het al. Des te opvallender hoe veel bedrijven nog in de niet-mobiele stand staan. Die nog steeds niet-responsieve websites opleveren en desktops kantoorgebouwen binnendragen.

Of dat erg is ligt natuurlijk aan wat je doelen zijn en of je afhankelijk bent van wat je klanten van je vinden. Ik zag gisteren bij de Belastingdienst hoe ze daar de afgelopen 3 jaren 40 apps hebben gemaakt. Niet voor de fun, maar om de dingen die ze deden beter te kunnen doen en om dingen te kunnen doen die ze eerder niet konden.

De aangifteapp werd dit jaar meteen bij het verschijnen de meest gedownloade app in Nederland en in de eerste week al meer dan 270.000 keer gebruikt. Maar ook de medewerkers van de Belastingdienst maken dankbaar gebruik van de appificatie. Een douanier liet zien hoe hij met zijn Ipad- app beter kan controleren en uren per dag aan papierwerk en reiskosten bespaart. Effectief voor de Belastingdienst en mooi meegenomen voor de douanier die een uurtje later op kan staan, minder in de file staat en meer plezier in zijn werk heeft gekregen.

Mobiel biedt enorm veel nieuwe kansen. Of, wanneer en hoe organisaties die gaan benutten is nog een  vraag. Zeker als bij gebruik door medewerkers beveiligingsaspecten een rol gaan spelen kun je verschillende kanten op. Op safe spelend kun je via remote beheertools die mobiele devices prima tot draagbare dichtgetimmerde desktops reduceren. Vanuit beheeroptiek goed geregeld, vanuit gebruikersoptiek helaas pindakaas.

Net zoals bij steeds meer uitdagingen ligt de sleutel voor een belangrijk deel bij het opleiden van gebruikers en het (durven) geven van eigen verantwoordelijkheid. Waar bedrijfspc's nog werden gekocht en beheerd door het bedrijf, zullen mobiele devices steeds vaker worden gekocht en beheerd door gebruikers. Inclusief het verantwoordelijk zijn voor verantwoord gebruik. Maar ook daarbij gaat het om een verandering, dus…

  

Zweedse services als voorbeeld

"Met onze extra services helpen we je graag een handje!" Die tekst zag ik onlangs in enorme letters staan op de wand van het restaurant bij IKEA Eindhoven. Reden om nog eens na te denken over wat IKEA nou zo bijzonder maakt. Want bijzonder is het als een bedrijf over de hele wereld succesvol is en blijft met een concept dat ogenschijnlijk best valt te kopiëren. Nou, blijkbaar niet dus.

Een belangrijk deel van 'het geheim van IKEA' zit volgens mij in het feit dat ze echt snappen wat klanten belangrijk vinden en dat vervolgens ook nog eens vertalen naar concrete diensten. Diensten waarbij klanten veel keuzevrijheid hebben en meer of minder eigen verantwoordelijkheid kunnen nemen. Je merkt er dat klanten niet alleen op papier centraal worden gesteld, maar dat er bij alles wat ze doen vanuit die klant wordt gedacht. En mochten ze dat volgens jou niet goed doen, dan willen ze dat graag van je horen. Bijvoorbeeld via die pc naast de serviceteksten, waar ik ze getipt heb dat die koffiekopjes toch echt een stuk fijner waren dan die goedkope kartonnen bekertjes.

Die muurteksten over mogelijke extra services passen bij de mentaliteit van dit bedrijf. Klanten zijn bij hen geen eenheidsworsten en mogen steeds meer zelf bepalen. Want waar de een Billy of Ivar liever met zijn aanhanghertje mee naar huis neemt, wil de ander de boel lekker laten bezorgen en in elkaar zetten. Rekening houden met verschillende ("lastige") klantvoorkeuren zal voor veel bedrijven vrees ik altijd een of meer bruggen te ver zijn. Maar voor de betere bedrijven is het natuurlijk een mooie uitdaging om zichzelf continu te blijven verbeteren. Zodat mensen niet alleen online spullen kunnen bestellen, maar dat ze dan ook weten of het product 's morgens of 's middags wordt afgeleverd. Om niet alleen soepel abonnementen af te sluiten, maar om fouten die daarbij worden gemaakt direct in plaats van pas weken later te herstellen.

Het zou mooi zijn als bedrijven zich wat vaker spiegelden aan onze Zweedse vrienden en bedachten hoe ze services kunnen gaan leveren zoals ze daar al tientallen jaren doen.

The end of architecture as usual

Alweer een paar jaar terug las ik het boek “The end of business as usual” van Brian Solis. Inspirerende literatuur over de noodzaak om als bedrijf fundamenteel na te denken over hoe je om moet gaan met een wereld die steeds sneller verandert. 

Net terug van de jaarlijkse DYA-dag (“Dynamische architectuur”), met als thema "Innoveren (z)onder architectuur”, werd me duidelijk dat het besef dat ook architectuur op zijn grondvesten trilt, bij meer mensen is doorgedrongen. Oftewel: architectuur zoals het was is voorbij. Tot zover het slechte nieuws. Het goede nieuws is dat er meer dan ooit behoefte is aan architectuur. Maar wel op een manier die past bij hoe de wereld zich ontwikkelt.

Dat bestaande bedrijfsmodellen steeds minder goed werken wordt dagelijks via de media duidelijk. Voor bijna ieder bedrijf is/wordt het een kwestie van pompen of verzuipen. Marlies van Steenbruggen, mede bedenkster van DYA, illustreerde dit mooi met behulp van een variatie op het Valley-of-Death model: als bedrijf zul je de oversteek moeten maken van “business as usual” naar “the new normal”. Om de vallei tussen oud en nieuw te kunnen oversteken heb je een brug nodig met een aantal stevige pijlers. Pijlers die er behoorlijk anders uitzien dan we gewend zijn.

Aan de overkant van die vallei gelden andere regels en andere verwachtingen. Als bedrijf je interne efficiency verhogen is ook daar natuurlijk niet weg. Maar waar het echt om draait is wat klanten aan je hebben. Zij beslissen immers of de diensten die je levert deugen of niet en bepalen of je eigenlijk nog wel bestaansrecht hebt.

Is er dan nog architectuur nodig? Ja dus. Net zo goed als op de vertrouwde linkeroever, zul je moeten bepalen wat je belangrijkste doelen zijn en hoe je die denkt te gaan realiseren. Architecten die luisteren naar wat gewenst is, die vanuit een architectuur invalshoek meedenken en de juiste vertalingen kunnen maken, blijven nuttig. Maar het zal wel hard werken worden. Want die kritische consument zit ook binnen  Ook daar zal hij, terecht, architecten steeds meer gaan afrekenen op de kwaliteit van geleverde diensten.

Moet die architectuur dan nog dienstgericht zijn? Wat mij betreft zeker wel. Nog veel sterker dan op de linkeroever is het immers op de rechteroever gemeengoed om in termen van diensten te denken.Met verhalen over hoe dingen werken en hoe complex alles is hoef je daar niet meer aan te komen. Deugen je diensten dan ben je okee,  deugen ze niet dan ben je niet okee. Zo simpel wordt het. Tijdens de DYA-dag bleek ik tot mijn verbazing de enige in de zaal te zijn die het beroemde (?) memo van Jeff Bezos kende waarover ik eerder schreef (‘Jeff Bezos: held van dienst’). Hij had al in 2002 door dat in een modern bedrijf alles om diensten draait. Het feit dat Amazon met die mantra is uitgegroeid tot een van de succesvolste bedrijven ter wereld laat zien hoe je met dat besef levend de vallei over kunt steken.

“Dynamische architectuur” en “dienstgericht benaderen” zijn en blijven in mijn ogen dus een ijzersterke combinatie. Eentje die je kan helpen om op een dag heelhuids aan te komen op de rechteroever.

Service Load Balancing via ‘Copy mdb’

Cloud computing is in een aantal opzichten ‘another cup of tea’ dan niet-cloud computing. Maar soms valt het ook wel mee als je denkt in termen van diensten.

Omgevingen worden ingericht om bepaalde soorten diensten optimaal te kunnen leveren. Bij cloud is het bekendste onderscheid in soorten diensten: Infrastructuur, Platform en Software (“As A Service”).

Bij het inrichten van een omgeving worden ‘patronen’ gebruikt om it-bouwblokken op een bepaalde manier te combineren. Een zo’n patroon is “Service Load Balancing”. Het doel daarvan is om belasting ten gevolge van servicegebruik dynamisch te verdelen over aanwezige resources.

Tijdens het lezen daarover moest ik denken aan zo'n situatie eind jaren negentig. Het ging om een applicatie die steeds meer werd gebruikt, waardoor het MsAccess .mdb bestand dat werd gebruikt tegen de 255-gebruikers grens aanliep. Het signaal daarvan kwam niet, zoals in een cloud, van een monitor-agent, maar van de 251e gebruiker die het bij de Helpdesk meldde.

Om het probleem op te lossen moesten er meer (dezelfde) resources beschikbaar komen om aan de toenemende vraag te kunnen voldoen. De "service load balancing oplossing" was om een batchscript te maken dat iedere nacht (na aanmaak van het .mdb bestand) 10 keer het commando “copy telefoon.mdb telefoon-i.mdb” uitvoerde (waarbij 'i' opliep van 1 tot 10). De betreffende applicatie koos voortaan bij het opstarten willekeurig 1 van de 10 .mdb bestanden en via deze simpele vorm van "horizontaal schalen" werden alle benodigde diensten weer geleverd.

Okee, het is natuurlijk een stuk mooier als op- en afschalen automatisch gebeurt op de momenten dat het nodig is. Laat dat nou net een van de redenen zijn waarom thee in een cloud anders smaakt...