Lie factor

De façon à pouvoir mesurer de façon formelle à quel point un graphique est une distorsion de la réalité (ou en tout cas des valeurs numériques que le graphique tente d’illustrer), Edward Tufte, auteur majeur dans le domaine de la visualisation de l’information (“The Visual Display of Quantative Information“), a défini le concept de “lie factor” (que l’on pourrait traduire par facteur de mensonge) de la façon suivante :

$$\text{lie factor} = \frac{\text{taille de l’effet dans le graphique}}{\text{taille de l’effet dans les donnees}}$$

où

$$\text{taille de l’effet} = \frac{| \text{seconde valeur} – \text{premiere valeur}|}{\text{premiere valeur}}$$

Un “lie factor” de 1 indique donc qu’il n’y a pas de distorsion. Tufte estime que ce facteur doit rester entre 0.95 et 1.05 pour assurer l’intégrité de la visualisation.¹

Par exemple, supposons que l’on veut indiquer dans un diagramme en bâtons (bar chart) qu’un produit A a été deux fois plus vendu qu’un produit B, il faut que la barre représentant A soit deux fois plus longue que celle représentant B. Cela peut paraître naturel… nous verrons dans les exemples qui suivent que c’est loin d’être toujours le cas !

Tronquer l’axe des ordonnées

Un des exemples de distorsion les plus fréquents est l’utilisation de diagramme en bâtons (bar chart) ou en ligne (line chart), représentant en ordonnée des quantités, et démarrant l’axe à une autre valeur que zéro.
Prenons par exemple l’illustration ci-contre, issue d’une infographie de la SNCB, parue dans le journal Métro du mercredi 10 juin 2015. On y montre la baisse du nombre de dépassements de signaux entre 2010 et 2014. Ils sont passés de 110 à 64, soit une baisse de 41.8 % ((110-64)/110). Par contre, visuellement, grâce au/à cause du fait que l’axe vertical démarre à 40 et non en zéro, la baisse est de 70 (110-40) à 24, soit 65.7 %. Notre cerveau enregistre une baisse drastique de quasiment un facteur 3. On a donc un lie factor de 65.7/41.8, soit 1.54. L’effet visuel est dès lors 54% plus important que les données à représenter ². Une version “corrigée” du graphique vous est présentée ci-contre. La diminution semble nettement moins impressionnante !

En cliquant sur l’illustration ci-dessus, vous apercevrez dans la même infographie trois diagrammes utilisant le même stratagème pour vanter la société, dont un avec un lie factor de 20.6 !

L’exemple suivant a été emprunté au parti socialiste français. Il met en avant une épouvantable évolution de la dette lorsque la droite s’est trouvée au pouvoir entre 2002 et 2009. Première chose intéressante à constater : alors qu’en général on représente la base d’un diagramme en bâtons en bas, les “communicants” du PS ont choisi ici de l’inverser. On observe donc une “montée” (quelque chose d’intuitivement positif) pour la gauche, et une “baisse” pour la droite (intuitivement négative).

Mais ce qui est plus important est de remarquer que l’axe vertical débute à 50 %. Alors que visuellement la dette semble avoir enregistré une progression de 317% entre la fin de la dernière valeur associée à la gauche et la dernière de la droite, elle n’a en fait crû que de +/- 57 % à 75 %, soit une progression de 33.9% (18% = 33.9% de 57%), et donc un lie factor de 317/33.9 = 9.3. On a donc une progression visuelle plus de neuf fois plus importante que la réalité ! Ce facteur serait plus bas si l’on considérait plutôt les valeurs moyennes de partie gauche et droite (au lieu, comme nous l’avons fait, du minimum pour l’un et du maximum pour l’autre), mais il en restera largement supérieur à 1.

Notons que cette règle, unanimement reconnue par la communauté scientifique s’intéressant à la visualisation de l’information et voulant que l’axe vertical d’un graphique doit toujours commencer à zéro, s’applique uniquement pour des valeurs pour lesquelles le zéro à une valeur intrinsèque, et signifie l’absence de quantité. Ce sont des valeurs pour lesquelles dire “deux fois plus grand” a un sens : 10 €, c’est bien deux fois plus que 5 €, 50 articles (identiques), c’est bien la moitié de 100 articles. Par ailleurs, cela ne dépend pas des unités utilisées : deux fois plus cher, c’est la même chose en euros ou en dollars, deux fois plus long, ça ne change rien que l’on s’exprime en mètres ou en pieds.

Il n’en ira pas de même lorsque la mesure que l’on considère a un zéro tout à fait arbitraire, comme ça l’est pour la température ou l’heure. On ne peut pas dire que quand il fait 20 °C, c’est deux fois plus chaud que 10 °C, ni que 10 heures du matin, c’est deux fois plus tard que 5 heures (on parle ici bien d’heure, et pas de durée). Minuit, ou 0 °C, ça n’est en rien l’absence d’heure ou de température ; ces valeurs sont choisies de façon conventionnelle. Minuit à Bruxelles ne correspond pas à minuit à New-York et 0 °C n’est pas la même température que 0 °F ou 0 °K. Étant donné qu’un graphique représentant une température au cours du temps ne représentera jamais un ratio ou une variation relative (qui ne serait par ailleurs pas la même si l’on s’exprimait en degrés Centigrades ou Fahrenheit) mais bien une variation absolue, l’origine de l’axe n’a pas d’importance. On évitera alors l’utilisation de diagrammes en bâtons (mettant en avant des longueurs) pour préférer une graphique en ligne (mettant en avant des positions).

Confondre surface et taille

Visuellement parlant, notre cerveau considère qu’un cercle (ou tout autre forme) est deux fois plus grand qu’un autre si sa surface est deux fois supérieure (et non son diamètre). Or on voit souvent des infographies dans lesquelles les diamètres sont proportionnels aux valeurs à représenter. Ce qui implique une relation quadratique entre ce que l’on voit et ce que l’on devrait voir : un ratio de 3 impliquera une surface 9 fois plus importante. Par ailleurs, il a été montré que le cerveau humain (entre autre par Jacques Bertin, dans son ouvrage “Sémiologie Graphique“, ou par Stanley Smith Stevens, dans sa “Psychophysical Power Law“) distingue moins précisément une différence entre deux surfaces qu’entre deux longueurs.

Lorsque l’on mélange ces deux sources de confusions, on arrive à une infographie telle que celle présentée dans le “Sunday Star Times” du 12 février 2012 (reprise sur www.statschart.org.nz). Outre le fait qu’il existe des façons plus adaptées de représenter l’évolution de deux mesures dans le temps, on voit par exemple que le petit cercle orange de 2009 (14 %) a une surface 5.5 plus petite que le cercle dans lequel il est inscrit (33 %), soit une augmentation de surface de 450%, pour représenter en réalité une augmentation de 135% (14% -> 33%). Cela nous donne donc un lie factor de 3.32. Étant la relation quadratique entre diamètre et surface d’un cercle, le lie factor sera en fait différent pour chacun des graphiques (et d’autant plus important que le ratio dans les données est important). Le fait qu’un cercle soit placé devant l’autre est également trompeur : dans le premier item de la seconde infographie, la partie rouge est à peine visible, alors qu’elle représente une quantité supérieure à la partie bleue.

Jouer avec les perspectives

Un outil comme Excel vous permet – pour ne pas dire vous y incite – de rajouter des effets de perspective à vos graphiques. Si le résultat peut être visuellement élégant, il sera bon de s’en servir avec parcimonie, car il est particulièrement trompeur. Prenons l’exemple d’un graphique en tarte : non seulement les segments qui apparaîtront du côté du lecteur seront augmentés d’une “tranche” que n’auront pas les segments opposés, mais par ailleurs la perspective diminuera la surface les segments les plus éloignés. Dans l’exemple ci-contre, on peut voir Steve Jobs, en pleine “Keynote”, présentant la répartition du marché des principaux vendeurs de smartphones. Apple (19.5 %), en vert, occupe une surface à l’écran 1.8 fois supérieure à celle occupée par le segment “Autres” (21.2 %), en violet ! On a donc, pour la comparaison entre ces deux éléments, un lie factor proche de 10 ! Pour mieux visualiser la “tromperie”, voici ci-contre une version du graphique dans lequel on superpose le segment violet des 21.2 % à celui, vert, des 19.5 %. En théorie, le vert devrait donc avoir complètement disparu. Jugez-en par vous-même…

Ignorer les conventions

Les graphiques standards se basent en général sur certaines conventions tacites, en principe naturelles. Par exemple, la somme des segments d’un graphique en tarte doit atteindre 100 %. Ce n’est pas exactement ce qu’a choisi de faire la chaîne américaine Fox pour diffuser ce graphique au moment des présidentielles américaines de 2012. Outre le fait que, dû à l’effet de perspective détaillé ci-dessus, le segment de Romney (60 %) est largement plus grand que celui de Palin (70 %), engendrant un lie factor de 3.7, la somme des segments monte à 193 % !  Il est probable qu’en l’occurrence, les sondés pouvaient donner deux choix, mais il faut reconnaître que ce graphique peut laisser perplexe !

Utiliser des valeurs cumulatives

Une excellente façon de masquer une baisse des ventes ou des revenus est d’utiliser des valeurs cumulatives. Elles ont l’avantage d’être, par définition, toujours croissantes. C’est par exemple ce qu’a choisi de faire Tim Cook lors de la Keynote de présentation de l’iPhone 5S. Il est en effet difficile de voir si, par exemple, la pente (c’est-à-dire le nombre d’unités vendues par quadrimestre) est plus forte début 2011 ou fin 2013 avec le graphique présenté ci-contre (sans compter sur le fait qu’on semble avoir “oublié” de préciser l’échelle de l’axe vertical). Sur la seconde image, David Yanofsky a réintroduit dans le graphique les données non cumulées. Et là, surprise : alors que le graphique de Tim Cook suggère une augmentation explosive et continue, on s’aperçoit que les résultats ont plutôt tendance à se tasser.

Tromper les intuitions

Lorsque l’on voit un diagramme, on pense en général intuitivement qu’il représente une quantité (en fonction du temps, d’une catégorie…). Mais il peut aussi représenter une variation. C’est cette source de confusion qui a été utilisée par l’équipe d’Obama lors de sa seconde campagne en 2010, où on représente les “job loss” sous Bush (en rouge) puis sous Obama (en bleu). On a donc affaire à un problème exactement inverse à celui présenté juste ci-dessus.

On peut d’abord remarquer trois stratagèmes simples utilisés dans ce graphique pour accentuer le point de vue de l’auteur. Le premier a déjà été présenté avec l’exemple du parti socialiste français ci-dessus, et consiste à “retourner” le diagramme en bâton. On a donc quelque chose en décroissance sous l’administration Bush, qui accentue l’aspect dramatique, et en croissance sous celle d’Obama, pour accentuer le sentiment de progrès et de rétablissement. Par ailleurs, on voit un bleu clair, lumineux, pour la partie d’Obama et un rouge foncé, sombre pour celle de Bush. Ce n’est certainement pas innocent. Enfin, la légende indique le graphique va de 2007 à 2010. Si l’on ne fait pas attention aux mois, on pourrait penser que le graphique couvre 3, voire 4 ans, et qu’il s’agit donc d’une progression durable. Or le graphique concerne essentiellement 2008 et 2009 (décembre 2007-janvier 2010), soit à peine plus de deux ans.

Si l’on regarde ce graphique, qui concerne l’emploi aux États-Unis, on a l’impression d’une situation qui s’est terriblement détériorée durant le mandat de Bush, et qu’Obama est parvenu à rétablir. Or le graphique ne représente pas le nombre de sans-emplois, mais bien le nombre de pertes d’emploi par semestre, soit la variation du nombre de sans-emplois. En regardant donc le graphique de plus près, on voit donc que le nombre de sans-emplois augmente moins vite, certes, mais ne diminue pas ou peu. Ce qui est en soi déjà un résultat important, mais qui est largement accentué avec ce graphique.

Le graphique ci-contre, généré par Soquel by de Creek, montre cette fois-ci le nombre total de sans-emplois (c’est-à-dire avec les valeurs cumulées). Il est nettement moins vendeur auprès des électeurs …

Mais encore…

Il existe de nombreuses autres façons de tromper le lecteur. Voici quelques exemples :

• Ignorer l’inflation quand on compare des budgets sur longues périodes. Comparer le budget Défense de Kennedy et d’Obama n’a par exemple pas de sens si l’on ne tient pas compte de la différence de la valeur du dollar entre les deux époques.
• Présenter des histogrammes dont les “bases” ne sont pas homogènes. Si l’on présente le total des ventes de chaque année mais que la dernière année représentée est toujours en cours, il faut ajuster les données pour ne pas donner l’impression d’une brusque baisse.
• Pour réaliser un effet de perspective, ne pas aligner la base des barres d’un histogramme, rendant très difficile la comparaison (exemple).
• Utiliser une échelle logarithmique lorsque ça ne se justifie pas, pour réduire visuellement l’écart entre deux valeurs.

Avoir ces quelques éléments en tête pourra être très utile, à la fois comme “consommateur”, pour éviter d’être leurré par une visualisation un peu trop vendeuse, mais également comme “producteur”, de façon à réaliser des graphiques les plus intègres possibles.

De très nombreuses illustrations de visualisations trompeuses ou mal conçues sont données sur le site wtfviz.net. Le manque de bon sens de certains est parfois surprenant…

Notes

1. Notons que la définition de Tufte peut prêter à confusion et est parfois contestée. En effet, lorsque l’on compare deux valeurs, on peut choisir arbitrairement quelle est la première et quelle est la seconde. Le choix impactera potentiellement fortement le calcul.
   Par ailleurs, si une augmentation de 10 % dans les données est traduite par une diminution visuelle de 5%, cela engendrera le même lie factor que si elle est traduite par une augmentation de 5%, étant donné l’utilisation de la valeur absolue.
   Certains préféreront une autre définition dans laquelle l’effet est calculé en effectuant le ratio entre les deux valeurs (première valeur/seconde valeur). Le choix des valeurs n’aura alors plus d’impact sur le lie factor, le choix étant bien entendu le même pour les données et pour le graphique.
2. Si on avait, comme précisé dans la note ci-dessus, inversé les première et seconde valeurs, on aurait eu un effet dans le graphique de 191.7 % ((70-24)/24), pour un effet dans les données de 71.9%, soit un lie factor de 2.66

Le titre de cet article est librement inspiré de nombreuses publications reprenant un nom très proche : How to lie with maps (Mark Monmonier, 1991), How to lie with statistics (Darrel Huff, 1954), How to lie with charts (Gerald Everett Jones, 2006)…

New S en S PLUS

De huidige versie van R is in grote lijnen gebaseerd op een gewijzigde versie van S die eind de jaren tachtig ingevoerd is. Belangrijke keuzes waren het gebruik van C in de plaats van FORTRAN als onderliggende taal, een consistent gebruik van functies  en een meer  uitgebreid object-georiënteerd model.

Begin de jaren  90 wordt S-PLUS gecommercialiseerd als statistische data analyse tool. Versies voor de belangrijke platformen worden ontwikkeld en de statistische toolkit werd sterk uitgebreid, in lijn met ontwikkelingen in het domein. De strategische keuze om een gratis studentenversie te lanceren (2002) zal zeker bijdragen tot de bekendheid van het systeem onder statistici.

En daar is R …

In 1993 komt een nieuwe groep rond John Chambers (Ross Ihaka en R Gentleman) met een open source versie van de new S programmeertaal. Verschillen tussen deze implementatie en de S-PLUS implementatie zijn beperkt zodat gebruikers van de ene gemakkelijk met de andere van start kunnen. Qua filosofie is er echter een wereld van verschil omdat R een GNU project is.  Dit betekent dat de code open source is  en dus vrij beschikbaar voor gebruikers om ze uit te breiden en te verbeteren. Bovendien zijn er geen beperkingen om R te verdelen onder het grote publiek. Deze filosofie is heel erg aangeslagen in de academische wereld waar het gebruikelijk is dat nieuwe ontwikkelingen gedeeld en gepubliceerd worden.  Heel  veel packages zijn het resultaat van wetenschappelijk onderzoek waar naast het publiceren van de theoretische resultaten nu ook de methoden meer en meer gepubliceerd worden als bijproduct.  Men kan terecht spreken van een community, waar een deel van de gebruikers actief betrokken zijn bij het verder ontwikkelen  en documenteren van het project. Tegelijk worden bijeenkomsten georganiseerd voor gebruikers, en zijn er ontzettend veel initiatieven om het gebruik van R te verbeteren via mailing lijsten en cursussen, zoals bijvoorbeeld Quick-R en  het recente belgische initiatief Datacamp.

Hoewel  het ontwikkelen van R packages zich vooral afspeelt in linux omgevingen en met C code zijn er versies voor alle operating systemen en in het bijzonder voor windows. In combinatie met  R  zijn er bovendien een aantal grafische omgevingen voor handen die gebruikersvriendelijker zijn dan de standaard console, zoals bijvoorbeeld de veel gebruikte RStudio die beschikbaar is in gratis standalone en server versies maar ook in betalende professionele versies met support. OpenAnalytics is een belgisch bedrijf dat onder meer een freeware server platform aanbiedt (Architect) en systemen die toelaten R verwerking te integreren in de business of labo-workflow (R service bus).

Van het labo naar het bedrijf

Ondertussen hebben meerdere generaties enthousiaste studenten hun weg gevonden naar bedrijven en instellingen. Zo is R beetje bij beetje geïntroduceerd in verschillende sectoren, waarvan de biomedische en financiële vooralsnog het meest prominent zijn.

Het feit dat R in een handomdraai gedownload en geïnstalleerd kan worden laat toe dat R gemakkelijk kan ingezet worden. Hoewel de focus van R nog altijd interactieve data-analyse is, worden de grafische mogelijkheden van R ook erg geapprecieerd. Door de ontwikkelingen in een aantal wetenschappelijke disciplines zoals de bio-informatica worden steeds zwaardere eisen gesteld aan de verwerkingscapaciteiten van het R systeem. R volgt dus de ontwikkelingen qua high performance computing op de voet, en heeft ondertussen ook alle functionaliteiten die nodig zijn voor data management.

Dit alles maakt R natuurlijk ook bijzonder interessant voor big data analytics.

Of toch een beetje gehyped ?

Voor vele R gebruikers van het eerste uur is het feit dat R gehyped zou zijn een nogal vreemd idee. Immers, zij gebruiken en ontwikkelen als specialisten een tool die precies  gericht is op de problemen waar zij mee bezig zijn. De hype ontstaat dus als het grote publiek, dat niet noodzakelijk ervaring heeft met data-analyse, voorgespiegeld wordt dat met deze nieuwe tool een hele resem aan complexe problemen kunnen opgelost worden, zonder dat je daarvoor specialist hoeft te zijn.

Het feit dat nu meer gebruikersvriendelijke visuele omgevingen beschikbaar zijn verhult enigszins dat werken in R traditioneel neerkomt op code schrijven. Het feit dat een functie of voorbeeldscript bestaat voor wat je wil doen betekent nog niet dat je deze meteen op je data aan de praat krijgt. Uiteraard is documentatie beschikbaar maar deze kan al eens cryptisch zijn en is niet geschreven voor een groot publiek. Bovendien lijkt het moeilijk de gebruiker volledig af te schermen van technische aspecten van de installatie en object-georiënteerde modellen … en zit er vaak nog een grote performantie winst in het programmeren  van C subroutines voor bepaalde intensieve deeltaken.

De steile leercurve kan natuurlijk altijd verzacht worden door het gebruik van visuele omgevingen (zo bijvoorbeeld RStudio’s Shiny voor het ontwikkelen van web applicaties)  en het voorzien van de nodige omkadering voor support en coaching. De eindgebruiker zal dan ongetwijfeld ervaren dat investeren in R snel vruchten afwerpt (en hierbij wordt al eens vergeten dat het vertrouwd raken met software zoals Excel ook veel tijd gekost heeft).

Besluit

Op zijn bijna 40^ste is R springlevend en heeft het zeker zijn plaats verdiend naast de grote commerciële oplossingen voor statistiek en analytics. Men kan terecht spreken van een lingua franca programmeertaal voor data-analyse en statistical learning. Door het open source karakter zijn er geen beperkingen op de verspreiding van R maar de inzetbaarheid van R voor het grote publiek hangt af van het soort gebruik. De kracht van R en het voordeel van de packages zit vooral in het gevorderd gebruik maar mits de nodige coaching en omkadering kunnen minder gevorderde eindgebruikers ook  met R aan de slag. In dat geval moeten  bedrijven en instellingen rekening houden met kosten voor training en kunnen beschikken over specialisten die het systeem kunnen opzetten en onderhouden. In 2006 vermeldde John Chambers nog de integratie van R in andere systemen als één van de grote uitdagingen voor de toekomst. Ondertussen zien we R meer en meer opduiken als component in de geïntegreerde systemen voor analytics die vendors aanbieden.

Data analyse & aggregaten

In de rol van data-analist (of data scientist) krijgt man vaak de vraag om data op een zodanige manier te manipuleren en transformeren zodat men een beter inzicht in de onderliggende gegevens verkrijgt. Om dit inzicht te verkrijgen gaat de data-analist vaak aggregaten bouwen op één of meerdere niveaus. Zo kan men bij het analyseren van klantengegevens een aggregaat bouwen op het niveau van bv. de individuele klant om inzicht te krijgen in de producten die elke klant koopt. Maar evengoed kan men een aggregaat bouwen op het niveau van de klant’s woonplaats om te weten welk productsegment populair is in welk gebied en hoeveel klanten terug te vinden zijn in elk geografisch gebied. Vaak worden de aggregaten iteratief verfijnd in samenwerking met de klanten/opdrachtgevers om zo de businessvraagstukken beter te begrijpen en het resultaat tijdig bij te sturen waar nodig.

Eens men een aggregaat van gegevens heeft gebouwd kan men dit door middel van verscheidene artefacten presenteren. De drie populairste vormen om aggregaten te presenteren zijn:

1. Visualisaties, waar men de bekomen data visueel gaat voorstellen door middel van een grafische component (histogram, trendlijn, …). Zo kan men op een snelle manier een globaal beeld krijgen van de onderliggende data. Het nadeel van visualisaties is dat men vaak de details over de onderliggende informatie niet meer ziet.
2. Tabellen, waar men textueel in verschillende kolommen weergeeft hoe de data zich gedraagt per rij. Dit geeft goed de details van de data weer, maar het is moeilijker om via een tabel een globaal zicht op de data te krijgen. Ook is het moeilijker om trends in een tabelstructuur weer te geven.
3. Interactieve dashboards, waar men door eenvoudige manipulaties doorheen data kan navigeren en parameters kan aanpassen. Dit is een sterke presentatietechniek, maar niet altijd even eenvoudig te bouwen (hoewel er de laatste jaren een enorme evolutie is ontstaan in de dashboarding tools).

Sparklines: een vernieuwde presentatievorm

Naast de drie traditionele vormen om aggregaten voor te stellen, is er de laatste jaren in de (academische) informatie visualisatie community gewerkt aan nieuwe – betere – voorstellingen van geaggregeerde data. Een van die nieuwe technieken is sparklines, een zeer kleine lijngrafiek zonder assen of coordinaten. Dit laat toe om op een heel kleine ruimte een verloop of trend aan te tonen. Zo kunnen sparklines perfect binnen een tabel of tekst geplaatst worden om het verloop van een parameter aan te geven. Onderstaand ziet men een voorbeeld van een sparkline die de aandelenkoers weergeeft (Bron: Wikipedia).

De democratisering van Sparklines: integratie in populaire data-analyse tools

De laatste tijd worden sparklines steeds populairder buiten het academische milieu. Een belangrijke drijfveer is hiervoor ongetwijfeld de integratie van sparklines in populaire analyse tools zoals onder andere Excel. Met enkele eenvoudige klikken kan je de rijen van je tabel uitbereiden met kleine lijn- of bargrafiekjes. Zo hebben wij in een project voor een klant onlangs sparklines gebruikt om trends aan te tonen voor bepaalde parameters (zie screenshot links). De klant was overigens zeer tevreden over deze presentatievorm.

Conclusie

Als data-scientist grijpen we vaak terug naar de traditionele methodes om data en bijhorende aggregaten voor te stellen. Toch blijft het belangrijk om ook de nieuwe visualisatietrends te volgen. Dit laat toe om data nog begrijpbaarder voor te stellen. Een voorbeeld hiervan is sparklines, dewelke de laatste jaren ook in de standaard analyse tools zijn ingebakken.

Het gebruiken van specifieke programmeeromgevingen heeft echter ook enkele vervelende nadelen:

• De output van de berekeningen uitgevoerd in deze programmeeromgevingen dienen vaak gebruikt te worden als input voor een nieuw programma, rapport, webapplicatie, … .  Dit is vaak een complex gegeven waarbij heel wat configuratie en integratie komt kijken;
• Analyses en berekeningen kunnen vaak nuttig zijn voor meerdere personen, instellingen, onderzoekers…  Het is weinig flexibel om analyses te delen met de requirement om een hele software stack te installeren.

Om code afkomstig van specifieke programmeeromgevingen makkelijker te delen en te integreren introduceert doctoraatsonderzoeker Jeroen Ooms ‘OpenCPU‘. OpenCPU is een centraal platform waarop men R-scripts kan plaatsen. De scripts die men op OpenCPU plaatst worden vervolgens automatisch beschikbaar als REST-services.  Deze services kan men makkelijk integreren in andere programmas/webapplicaties. Belangrijk is ook te vermelden dat OpenCPU een open-source platform is. Dit maakt het mogelijk om intern een eigen OpenCPU-server op te zetten (met de nodige beveiligingen) en indien nodig te koppelen aan interne achterliggende databases.

OpenCPU Tutorial

Bij wijze van proof-of-concept hebben we getest hoe men OpenCPU kan gebruiken om een bar-chart analyse te genereren in een web-applicatie. De stappen die we hierbij ondernomen hebben staan hieronder opgesomd.

Stap 1: Verzamel en upload de nodige data

In deze proof-of-concept analyseren we het klantenbestand van bedrijf X. Elke klant heeft een bepaalde Importance code van 1 tot 9 (1=een klant met weinig opbrengst, 9 een klant met heel veel opbrengst). Per klant houdt men ook bij of  hij makkelijk beschikbaar is voor een telefonische enquete (Y=yes,N=no). Onderstaande tabel geeft deze twee dimensies weer, gekoppeld aan het aantal klanten (Frequency) die in deze categoriëen kunnen ondergebracht worden.

Bovenstaande data kan men uploaden als CSV-file (of ander formaat) op de OpenCPU server via volgende link. Eens de data geupload is krijgt men een unieke ID terug waar de data te vinden is.

Stap 2: Creëer en save het R-script

In een volgende stap willen we een barchart genereren die per Importance-code weergeeft hoeveel klanten er zijn, en elke bar inkleurt in twee vlakken: een vlak makkelijk beschikbare klanten en een vlak met moeilijk beschikbare. Deze grafiek genereren we met de ggplot2 library. Onderstaande code omvat het complete R-script:

#Include ggplot 2 library
library("ggplot2"); 
#Haal de geuploade data op (zie stap1, de DATAID is dezelfde als uit deze stap) 
myTable <- read.csv("http://public.opencpu.org/R/tmp/DATAID/csv?");
#Plot en print te barchart
pl <- ggplot(myTable, aes(x = Importance, y = Frequency,fill=Available) ) + geom_bar(stat="identity");
print(pl);

Dit script zetten we op de OpenCPU-server via volgende link, we kiezen voor de optie ‘save to store’. Deze code krijgt ook een unieke ID, dewelke we later kunnen gebruiken om de code uit te voeren via een REST-service.

Stap 3: Maak de web-applicate met de REST service

De bar-chart die we gemaakt hebben in het R-script willen we nu tonen in een web-applicatie. Dit doen we via een eenvoudige Javascript applicatie die de OpenCPU-REST webservice aanroept. OpenCPU biedt verscheidene webservices aan om een plot te laden: als pdf, png, svg, R-file, … Wij hebben hier gekozen om de plot in te laten als SVG. Onderstaand is de source-code  en een screenshot van de webapplicatie weergegeven (de status na het klikken op de “calculate graph” button).

<html>
 <head>
 <script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js"  type="text/javascript">
 </script>
 
 <script type="text/javascript"> 
     $(document).ready(function() { 
          $("button").click( 
                 function(){ 
                      $("#svg").load("http://public.opencpu.org/R/tmp/SCRIPTOPENCPUID/svg", function() {});
                 } 
          );
     }); 
 </script>
 
 </head>
 <body>
   
   <button>Calculate graph</button> 
   <div id="svg"> </div>
   
 </body>
 </html>

Besluit

Specifieke softwarepakketten en programmeertalen zijn handig om in enkele lijnen code complexe berekeningen uit te voeren. Het is echter moeilijk om deze scripts te koppelen met bestaande code en te delen met verschillende mensen. Als oplossing voor dit probleem kunnen we OpenCPU gebruiken, een opensource server waar R-code op gepusht kan worden en vervolgens kan aangeroepen worden als REST-service. In een tutorial toonden we aan hoe deze aanpak werkt.  Er zijn ook nog 2 blogposts die deze aanpak beschrijven: embedding a plot in your website en running a block of R-code in OpenCPU.

Waarom public clouds goedkoper zijn

Het is een feit dat leveranciers van public cloud services goedkoper kunnen zijn per feature, omdat:

• ze korting krijgen op hardware, elektriciteit, etc… door de grote afname;
• ze doorgedreven automatiseren & standaardiseren;
• ze de vraag statistisch kunnen uitmiddelen door het grote aantal klanten;
• de kost per feature (bij SaaS) lager is ten gevolge de multi-tenancy;
• ze hun portfolio extreem efficiënt beheren: de cloud leverancier bepaalt het aanbod, niet de klant.

Dit betekent daarom echter niet dat het gebruik van cloud computing steeds voordelig uitkomt!

“Amazon is zo goedkoop”: leugen!

Bij het beschouwen van de kostenbesparing door cloud computing, moet goed gekeken worden waar de werkelijke kosten liggen. Vaak wordt verwezen naar Amazon EC2, waarbij de vraag gesteld wordt waarom interne servers zo duur zijn en traag geprovisioneerd worden, als dat bij Amazon veel sneller goedkoper kan. Deze vergelijking gaat echter niet op, omdat appels met peren vergeleken worden. Amazon biedt virtuele servers aan met beperkte performantie, en bovendien zijn

• bandbreedte,
• support,
• monitoring,
• maintenance en
• beheer

niet inbegrepen in de prijs. Ter illustratie hebben we een vergelijking gemaakt van prijzen voor een virtuele server (incl. support, monitoring, maintenance) met een bepaalde rekenkracht waarbij een bepaalde bandbreedte (4000 Gb) wordt gebruikt. De vergelijking staat in onderstaande tabel:

Hierbij komt meteen naar voren dat traditionele hosting pakketten zoals Hostway tot >50% goedkoper zijn. Het grote voordeel aan Amazon is dan ook niet de rauwe prijs, maar de flexibele provisionering, het starten & stoppen van een server aan de hand van een webservice call.

Waarom de Cloud niet altijd goedkoper is

Bij elk business proces komen “verborgen kosten” kijken — of het nu zelf uitgevoerd, geoutsourced wordt of naar de cloud uitbesteed.  Algemeen geldt dat hoe “hoger” de abstractie van de cloud is (SaaS > PaaS > IaaS), hoe groter de mogelijke kostenbesparingen zijn, omdat er steeds minder interne processen vereist zijn.  Typische “administratieve”  processen zijn aankoop, monitoring, maintenance en support.

Integratie

Een belangrijke kost vindt zijn oorsprong in de integratie in de huidige processen.  Public cloud providers bieden immers standaard-oplossingen aan die weliswaar gecustomiseerd kunnen worden maar er is weinig tot geen ruimte voor contractonderhandelingen om de integratie te vereenvoudigen.  Typisch zal de provider een (vaste) API / SOA-interface aanbieden waarmee alle communicatie zal moeten verlopen.

Behalve pure programmatorische integratie, zijn er natuurlijk nog “hogere orde” processen die geïntegreerd moeten worden, denken we bv. aan user access management (UAM), Data Integration, Single-Sign on,….   Daarom moeten policies opgesteld worden die de hele keten omvatten.

Ook op vlak van processen moeten de nodige stappen gezet worden: de huidige organisatie moet zo afgesteld zijn dat bepaalde stappen in het proces nu volledig elektronisch en automatisch gebeuren.  Een significante kost en mentaliteitswijziging kan komen kijken bij deze integratie.

Migratie

Zoals bij elke technologische verandering, kan de migratie erg risicovol en duur zijn.  Dit is zeker het geval bij cloud computing daar de gegevens niet meer intern beheerd, verwerkt of bezit worden.  Verder is er veel minder ruimte tot onderhandeling met de leverancier daar de (publieke) cloud standaardoplossingen aanbiedt.  Ook moet (op voorhand!!!) afgevraagd worden hoe gemakkelijk de gegevens uit de cloud kunnen gehaald worden en aan welke kost.

Licenties

De kost van het beheer en aankoop van licenties mag ook niet vergeten worden.  Zeker bij automatisch schalende applicaties moet deze problematiek vanaf het begin opgenomen worden in de algemene Software Asset Management strategie.

Hoe kostenbesparen in de Cloud

Er zijn 3 fundamentele manieren om kosten te besparen met Cloud Computing.

1. Beter inspelen op de markt

Een nieuw deel van de markt kan ontgind worden of het marktaandeel vergroot door de nieuwe mogelijkheden van cloud computing technologie (bv. de schaalbaarheid) aan te wenden.  Bovendien laat de flexibiliteit van cloud computing toe om de marktvraag beter te volgen (bv. er wordt vermeden dat een onverwachte vraag niet gevolgd kan worden door een tekort aan middelen).

2. De efficiëntie verhogen

De flexibiliteit laat toe om efficiënt gebruik te maken van resources, bv. door het vermijden van overprovisionering.  Beschouw het voorbeeld in onderstaande figuur. In een traditionele omgeving wordt infrastructuur statisch gereserveerd op basis van de piekvraag; in een cloud architectuur worden de resources geschaald evenredig met de vraag.

Bovendien worden de doorlooptijden worden verminderd door de snelle provisioning en kan de administratieve en support kost worden verminderd doordat deze kost nu bij de leverancier ligt.  SaaS gebruikt meestal de nieuwste Web 2.0 technologieën. Zo kan de samenwerking binnen het bedrijf verhoogd worden door geïntegreerde collaboratie-tools (bv. Google Apps).  Last but not least kan het gebruik van “cloud” technieken (vooral op vlak van governance) de efficiëntie van de huidige processen verhogen.

3. Focus op de kernactiviteiten

Doordat bijkomstige activiteiten naar de cloud verschoven worden (bv. enquêtes ontwerpen met SurveyMonkey), kan de organisatie kan beter gestroomlijnd worden doordat ze eenvoudiger wordt.

Conclusie

Cloud Computing biedt enorm interessante mogelijkheden, zowel op functioneel als op kostenvlak.  Op huidig moment echter, is het business model van de cloud en van de enterprise wereld nog niet goed op elkaar afgesteld.  Onthoud dat:

• vooral de flexibiliteit van de cloud interessant is;
• SaaS over het algemeen meer besparing oplevert dan PaaS en Iaas, maar ook meer aanpassing vereist;
• de verborgen kosten goed in rekening gebracht moeten worden.