Het hart van Cloud computing

Disclaimer: Dit artikel is nog niet bewerkt en bevat nog ruwe kantjes. Op basis van “engagement” bepaal ik of dit artikel bewerkt zal worden tot een definitieve vorm.

Software as a service (Saas), Platform as a service (Paas), Infrastructure as a service (Iaas) zijn geen cloud computing. De reden hiervoor is simpel. In 1999 heb ik mijn eerste saas gebouwd en dat was een web applicatie gebouwd op classic ASP in combinatie met Microsoft SQL Server. In 2005 heb ik de architectuur gemaakt voor een platform as a service. Met een webapplicatie kun je eigen schermen maken en database velden toevoegen en dit aan een andere partij aanbieden als saas. Dit is gebouwd op wat gevirtualiseerde servers ASP.NET en Microsoft SQL Server. Bij Leaseweb huur ik een paar servers die wat webpagina’s hosten. Is dat infrastructuur as a service? Zeker wel, maar als de fysieke machine uitvalt, is mijn server verdwenen zonder de mogelijkheid om hem ergens anders weer aan te laten gaan.

Saas, paas en iaas zijn mogelijk manieren waarop je cloud computing kunt afnemen, maar dit is dus niet exclusief voor cloud computing. Als je als organisatie deze modellen afneemt betekend dit niet de adoptie van cloud computing. Het betekent dat je een manier hebt gevonden om bepaalde IT gerelateerde zaken uit te besteden, en dit kan specifieke voordelen hebben waar ik volledig achter sta.

Er wordt veel geschreven en gepraat over de definitie van cloud computing. NIST heeft een mooi document geschreven wat dieper in gaat op de karakteristieken, maar zorgt wel voor veel verwarring waardoor het niet goed duidelijk is wat nu het hart van cloud computing is.

Traditioneel
Om de veranderingen te begrijpen moeten we teruggrijpen op wat we weten en kennen. Wat we als organisatie willen bereiken is een verregaande vorm van automatisering. Goede automatisering zorgt ervoor dat je meer werk kunt verzetten met minder arbeid en tegen lagere kosten. Ook moet automatiseren leiden tot minder fouten. De noodzaak om te automatiseren is in een land met grote welvaart hoger dan in een land waar welvaart nog een belofte is. In een welvarend land is de arbeid per definitie een hoge kostenpost. Door de vele administratieve processen bestaat er veel kantoorautomatisering. Dit bestaat uit het verwerken van administratie, financiën, het schrijven van documenten, beheren van agenda’s, versturen van e-mails et cetera. In kleine organisaties worden de werkplek Pc’s vaak met de hand geïnstalleerd en grote organisaties is het vooral belangrijk om een vorm van uniformiteit toe te passen en loont het om het installeren van werkplekken geautomatiseerd te doen. Hoe meer variatie ontstaat hoe meer kosten oplopen om gebruikers te onderhouden en problemen op te lossen. Dit zelfde geldt voor de server kant. Kleine organisaties kopen een server en richten deze in. Steeds vaker zie je dat organisatie server virtualisatie gebruiken om dit een aantal voordelen biedt. Maar door de beperkte schaal komt hier niet alleen veel arbeid bij kijken, ook het onderhoud en beheer is niet bepaald generiek. Upgrades van software welke ook nog moet integreren met andere bedrijfssoftware kunnen wel eens dure projecten worden. En door de tijd heen wordt software legacy. Het is een noodzaak om het aan te houden, maar de kosten stijgen hard mee. Ondanks dat er minder vaak fysieke hardware hoeft worden aangeschaft is veel beheer en probleem oplossen handwerk.

Cloud Computing
Door verder te gaan met het automatiseren van nieuwe servers en virtualisatie gebeuren er een paar dingen. Een cloud provider zoals Microsoft met Azure en Amazon met AWS hebben de automatisering zo ver doorgevoerd dat er nagenoeg geen menselijke arbeid aan te pas komt om nieuwe fysieke servers toe te voegen aan het serverpark. Op generieke manier worden nieuwe servers ingericht zodat ze automatisch in gebruik genomen kunnen worden door middel van virtualisatie. Dit kan alleen maar als je servers beschouwd als “eenheidsworst” ofwel; One Size Fits All. Door hier een interface voor te bouwen heeft Amazon het mogelijk gemaakt dat je server capaciteit bij kunt schakelen door middel van zelfbediening. Door slim om te gaan met het meten van gebruik op het gebied van processor kracht, geheugen, schijfgrootte en bandbreedte kan ook het afrekenen van gebruik geautomatiseerd plaatsvinden.

Het vergroten van de totale server capaciteit betekent gewoon op een standaard manier fysieke servers bijplaatsen. In een filmpje over Microsoft Azure zie je hoe dit tegenwoordig gaat: Een zeecontainer vol met servers wordt over een rails in een “slot” geplaatst. Daar wordt de container aangesloten op stroom, water voor koeling en Air flow. Wat gebeurt er als er een harde schijf stuk gaat, of een server niet meer functioneert? Helemaal niets! Lekker laten zitten totdat een bepaald percentage falende servers bereikt wordt. Dan wordt de gehele container uit het slot gehaald en een nieuwe container geplaatst. Goede spullen worden hergebruikt, oude spullen gerecycled.

Dat je niet precies weet waar je server draait, op welke server je data wordt opgeslagen, of waar je server naar toe gaat als deze labiel wordt is de aard van cloud computing. Een server wordt in feite een generiek apparaat die processorkracht, geheugen en opslagcapaciteit levert. En dat allemaal op basis van automatisering.

Clusters
Virtualiseren betekent dat je een fysieke server opdeelt in een aantal kleinere virtuele servers. Je maakt een server in feite kleiner. En dit terwijl je functioneel gezien servers zou willen clusteren. Je wilt bijvoorbeeld één grote database en dat die servers samen functioneren als één server. Dit doe je in feite met virtualisatie. Het clusteren vind alleen plaats op een ander niveau. Software op de servers zorgt voor het samenwerken, alsof al die servers één zijn.

Goedkoper
Waarom kan cloud computing goedkoper zijn? Hier zijn een hele reeks voorbeelden met aan het eind de klapper. Een cloud provider kan zijn stroom goedkoper inkopen, door slim te bouwen kan er veel stroom voordeel opgedaan worden door de locatie. In het noorden is het koud en dat is gratis koeling. Door de locatie kan ook bandbreedte goedkoper worden ingekocht of er kan zelfs eigen infrastructuur worden aangelegd. Door bulk aankopen wordt hardware tegen de laagst mogelijke prijs aangekocht. De werkelijke besparing zit hem in de automatisering waardoor er weinig menselijke arbeid nodig is per server.

In een traditionele organisatie waarin het inrichten van servers en uitrollen van werkplekken niet volledig geautomatiseerd is en waarbij maatwerk wordt gebruikt voor het gebruik van software. Vaak worden database servers weer anders ingericht dan bijvoorbeeld een storage area network (NAS). Als de database uit de voegen groeit wordt er database server capaciteit handmatig toegevoegd. Dit schaalt niet. Hoe meer werkplekken en servers, hoe meer beheerders, consultants en helpdeskmedewerkers er nodig zijn. Dit is de praktijk die ik zie bij veel organisaties. Netwerk en software lijken dus door de tijd heen te groeien, maar de kosten om dit te beheersen worden progressief hoger.

De werkelijke besparing kan dus alleen maar gerealiseerd worden als er minder arbeid aan te pas komt. Deze week is DynamoDB van Amazon gelanceerd. Deze biedt een database aan als een service. Dit is overigens een “NoSql” database. Dit houdt in dat de structuur niet relationeel is. Als je persoonsgegevens opslaat en je besluit ineens ook kleur ogen op te slaan, dan kan dit zonder dat je na hoeft te denken hoe je de structuur aanpast. Het maakt niet uit hoeveel mensen tegelijk data in de database stoppen of eruit halen. Het maakt niet uit hoe groot je database is. Dit is allemaal geautomatiseerd! Dat is de kracht van cloud computing. Daar zit de winst.

Maar wat moet je daarmee als organisatie? Hoe behaalt jouw organisatie hier zijn winst uit? De techniek van cloud computing staat niet in directe relatie tot de voordelen voor een organisatie. Maar door deze techniek, en hiermee doel ik niet specifiek op DynamoDB, bestaat de mogelijkheid dat één programmeur, of een klein team een applicatie kan ontwikkelen die gebruikt maakt van cloud computing.

Voorbeeld
Ik zal dit illustreren met een voorbeeld. Nalden is een sympathieke Nederlander en medeoprichter van WeTransfer.com. Een gratis dienst waarmee je grote bestanden van maximaal 2 GB gratis kunt verplaatsen naar mensen van jouw keuze. Miljoenen mensen gebruiken deze dienst. Hij hoeft zich echter niet druk te maken als zijn dienst ineens extra aandacht krijgt. Er is zelfs een grote kans dat hij de laatste week niet eens met de site is bezig geweest. WeTransfer.com is gebaseerd op een dienst van Amazon die gebaseerd is op cloud computing. Die dienst is zo goedkoop dat met een beetje reclame geld oplevert om Amazon te betalen en ook wat te verdienen. De achtergrond van de WeTransfer site bestaat uit mooie scherm vullende plaatjes welke dienst doen als reclame.

Dus jij als internet gebruiker kunt zonder moeite zijn dienst gebruiken die niets kost en er hip uitziet. Deze dienst was onmogelijk te realiseren zonder cloud computing. Er zou bij grote vraag capaciteitsproblemen ontstaan, en heel veel capaciteit realiseren is te duur.

Dus cloud computing voor jou als eindgebruiker is niet direct interessant. De diensten die bouwen op cloud computing en jou van een mooie web applicatie voorzien voor een interessante prijs is dat wel.

De crux is dus niet om als ondernemer cloud computing te adopteren, maar om diensten toe te passen die door cloud computing gemakkelijk, goedkoop en zonder veel arbeid te gebruiken zijn.

Zelfbediening
Hoe kan WeTransfer.com miljoenen mensen bedienen? Omdat de dienst geautomatiseerd is. Er is geen menselijke handelen nodig om nieuwe klanten te krijgen, aan te sluiten en te bedienen. Klanten bedienen zich zelf.

Om deze enorme hefboom zelf ook te kunnen gebruiken zal je dus als ondernemer moeten afvragen wat jij kunt doen om zelfbediening mogelijk te maken. De voorbeelden die ik schets liggen voor de hand, toch is zelfbediening niets iets van vanzelf ontstaat.

Zo heb ik voor een partner een Software as a service webapplicatie ontworpen. Deze wordt ingezet voor personeelszaken. Dossiers van medewerkers, ziek en verzuimmeldingen, roosterplanning en urenregistratie kunnen hiermee gedaan worden. Zij kunnen deze dienst 24 uur per dag gebruiken 365 dagen van het jaar. Deze applicatie werkt op basis van zelfbediening. Voor het inloggen van klanten hoeft het bedrijf zelf niets te doen. Klinkt goed, maar hier komt het addertje onder het gras. Een nieuwe klant kan zichzelf namelijk niet aanmaken. Voordat de klant de applicatie kan gebruiken moet deze worden ingericht. Afdelingen worden aangemaakt en de organisatie wordt op zodanige wijze ingericht dat het voor de klant zo min mogelijk moeite kost om met de software te starten. Maar voor elke klant is dus wel arbeid nodig voordat deze zichzelf kan helpen.

Hier ligt de kans.

Als mijn partner per week tien klanten erbij krijgt moet hij er mensen aan gaan nemen omdat hij anders tijd te kort heeft. Als klanten zichzelf aan konden sluiten en de applicatie in konden richten kan hij wel 1000 klanten per dag aan!

Neem zelf eens de tijd om na te denken hoe zelfbediening jouw organisatie een boost kan geven, ik kan daar eventueel een handje bij helpen.

Veiligheid
Wellicht lachen de mogelijkheden gedreven door cloud computing je toe. Maar is het wel veilig? Als er één grote drempel is om dingen te doen in de cloud (gedreven door cloud computing) dan is het veiligheid. Heel diep hier op in gaan zou dit artikel veel te lang maken, maar ik zal een paar handvatten aanreiken die de mogelijkheden en risico’s wat tastbaarder maken.

Allereerst een vergelijking die David Geens maakt in een uitbereiding van zijn eBook “Het is cloudy vandaag”. Hij vraagt de lezer; “Wat is het veiligste: uw juwelen thuis in een sigarenkist bewaren of in een kluis in een bankkantoor?”

Buiten de discussie die je kunt voeren (je kunt thuis ook een kluis bouwen) zullen veel mensen terecht vermoeden dat juwelen veiliger zijn bij de bank. Zo is het ook met IT. Bijna alle MKB bedrijven doen aan automatisering en hebben eigen servers, maar een cloud provider heeft meer verstand van beveiliging.

Google versleuteld praktisch alle data. En niet met één sleutel. Nee, elke klant heeft een eigen sleutel. Mijn data is dus voor iemand anders niet te lezen. Pik een server uit een Google datacenter en gegarandeerd dat je er niets mee kunt. Medewerkers van Google kunnen ook niet bij jouw sleutel. Sommige Google medewerkers kunnen wel bij jouw sleutel en dus je data, maar moeten een procedure volgen voordat ze dit mogen. Dit soort beleid is vastgelegd in standaarden en Google gaat daar serieus mee om. Dat Google onderwerp is van kritiek over privacy is een andere discussie. Deze vindt meer plaats op het gebied van social media en het vastleggen van Wi-Fi punten. Maar data van documenten en bedrijfsgegevens zijn goed afgeschermd tegen oneigenlijke toegang. Dit betekent niet google apps gebruiken direct veilig is voor jouw organisatie! Dat ligt niet aan Google, maar aan de gebruikers. Als iemand jouw gebruikersnaam en wachtwoord weet kan hij overal bij. Als medewerkers makkelijk te raden wachtwoorden gebruiken, of deze delen met anderen, dan is je veiligheid natuurlijk direct weg.

Ook in dit kader zal ik een treffend voorbeeld geven. Stel je hebt PietDeVries@Gmail.com als e-mail adres. Als je bij een webshop wat koopt maak je een account aan met PietDeVries@Gmail.com en een wachtwoord. Als je hierbij hetzelfde wachtwoord gebruikt als bij je Gmail dan heb je een potentieel probleem. En ik zou de mensen die hun wachtwoorden voor meerdere diensten gebruiken niet de kost willen geven. Dan heb je aan de voedselbank niet genoeg. Stel dat die webshop gehackt wordt, dan zal dit hergebruik van wachtwoorden ontdekt worden en nog geautomatiseerd ook. Maar het kan ook zijn dat de webshop eigenaar niet koosjer is en zelf met jouw wachtwoord aan de haal gaat.

Dit is een serieus probleem en als ondernemer moet je hier iets mee naar je medewerker.

Maar gelukkig zitten SaaS aanbieders zoals Google ook niet stil. Zij weten ook wel dat gegevens opslaan in de cloud vragen oproept. Zo heeft Google bijvoorbeeld tweeweg verificatie opgezet. Met alleen je gebruikersnaam en wachtwoord kom je er niet in. Je moet iets op te telefoon installeren en autoriseren wat je nodig hebt om in te kunnen loggen. Dit werkt net als zo’n kastje wat je gebruikt als je gaat internetbankieren. Dit is dus wel veilig. Al weet iemand jouw wachtwoord, dan nog komt hij er niet in. Je moet dan wel altijd je telefoon bij je hebben, maar dat is een fundamenteel aspect van veiligheid. Meer veiligheid gaat altijd ten koste van gebruiksvriendelijkheid.

Cloud computing is niet fundamenteel veilig, maar grote cloud providers zijn gewilde doelwitten voor hackers en veel grote cloud providers hebben verregaande maatregelen genomen om oneigenlijk toegang tot data tegen te gaan. Er is een ISO certificering, 27001, die gaat over een standaard hoe er met veiligheid wordt omgegaan. Daarbij is er een Sas 70 Type II audit certificaat -een derde partij die controleert of de onderneming zich ook echt aan de ISO 27001 houdt- welke toch wel het gevoel geeft dat de cloud aanbieder zijn zaakjes op orde heeft. Hierbij wel twee kanttekeningen. Sommige lokale cloud providers schermen wel met deze standaarden, maar bezitten ze niet. Zij ontlenen hun uiting vaak omdat zij zelf weer cloud providers gebruiken die wel deze certificering bezitten. Bij de wet ben je in principe verplicht zelf te controleren dat een leverancier waar je data hebt opgeslagen zich aan zijn afspraken houdt met betrekking tot de bescherming van persoonsgegevens. Bij heel veel SaaS aanbieders is overigens niets te vinden over veiligheid. Dat is een slechte zaak.

Punt is dat veiligheid nog zeker een aandachtspunt is, maar dat de ontwikkelingen zich snel opvolgen en het al maar beter wordt.

Conclusie
Cloud computing is heel technisch. Computers op een zodanige manier laten samenwerken dat je niet weet waar je data of server zich bevindt is een prestatie van formaat. Als organisatie heb je vaak niet direct te maken met cloud computing maar met een dienst of webapplicatie die van cloud computing gebruik maakt. Cloud computing is dus geen doel, maar een indirect middel om bepaalde voordelen te behalen in prijs, gemak en betalen voor wat je daadwerkelijk gebruikt zonder langlopende contracten. En dit allemaal op een schaalbare manier.

Over wetten en veiligheid is het laatste woord nog niet gezegd, maar er zijn goede indicatoren dat dit slecht een tijdelijke drempel is.

Om daadwerkelijk grote voordelen te behalen met cloud computing is visie nodig. De techniek doet het wel, het gaat om het vinden van een hefboom waardoor er minder arbeid nodig is om doelen te bereiken.

Cloud computing maakt het mogelijk om als eenling of klein team een krachtig middel in te zetten waarmee miljoenen gebruikers bediend kunnen worden over de hele wereld.

Dropbox handleiding voor gevorderden

Ik ben een groot fan van Dropbox en weet er meer over dan de gemiddelde gebruiker. Nu wil ik graag mijn kennis delen en een gratis ebook schrijven “on-demand”.  Ik geef hier een paar scenario’s waar in mijn ogen veel vraag naar is. Als tien mensen behoefte hebben aan het antwoord op deze scenario’s zal ik het boekje schrijven.

Dus stuur een e-mail naar Henri@henrikoppen.nl met als onderwerp Dropbox en als ik daar tien van heb stuur ik je het boekje toe.

Dit is een experiment waarin ik dus schrijf over waar werkelijk behoefte naar is. Het zou leuk zijn als dit experiment wordt uitgevoerd, dus deel het zal ik zeggen…

Scenario 1: Ik gebruik Dropbox op mijn werk, maar wil niet dat alle dropbox bestanden op mijn werkplek staan

Scenario 2: Hoe beveilig ik mijn dropbox bestanden tegen diefstal van mijn laptop?

Scenario 3: Hoe ga ik op een veilige manier met vertrouwelijke documenten om?

Scenario 4: Hoe kan ik goed zoeken op tekst in allerlei documenten, bijvoorbeeld op een prijs die op een opgeslagen factuur staat?

Scenario 5: Hoe kan ik Dropbox koppelen aan Google Docs?

Scenario 6: Hoe detecteer ik welke files door anderen zijn gewijzigd?

Update 19-01-2012: 6 e-mails binnen.

Open data en trends van 2012

Artikelen schrijf je met een doel. Bij blogs mag je daarin wat losser zijn. Hierbij wil ik een eerste aanzet doen om sneller mijn gedachten en actualiteiten te delen zonder eerst te reviewen en te editen om meer focus in een boodschap te stoppen.

Vandaag was ik bij een presentatie over Open Data. Dit werd gegeven in de Innovatie Fabriek te Zoetermeer. Ik ging er vooral heen omdat er een aantal ondernemers kwamen die hun kantoor gaan betrekken in de Innovatie Fabriek. Ik wil dat wellicht ook en heb daarom polshoogte genomen. Jaren geleden heb ik daar ook een kantoortje gehad, maar sindsdien het pand vooral leeg gestaan.

“Open Data” wordt door de overheid aangepakt om data van overheden te delen die door ieder die daarin interesse heeft. Momenteel zijn enkele tientallen datasets beschikbaar. Dit gaat om allerlei data van overheden die niet naar personen te herleiden zijn. In andere Europese landen is dit initiatief al een stuk verder, maar ook Nederland heeft grote plannen. Denk bijvoorbeeld aan kadaster informatie of een lijst van alle publieke oplaadpunten voor elektrische auto’s.

Wat ik wel mooi vond aan het verhaal is dat het vooral pragmatisch wordt opgezet. Gewoon maar wat proberen, zie http://data.overheid.nl/

Vorige week heb ik zelf twee seminars gegeven over Cloud Computing en die waren vanuit mij gezien succesvol. Veel positieve feedback. 100% van de vooraf aangemelde gasten waren aanwezig en dat is ook uitzonderlijk. De dag na de seminar kwamen er veel mailtjes en telefoontjes en dus ook leads. Wat ik vooral belangrijk vond is dat het publiek een anderhalf uur echt heeft opgelet. Cloud houdt mensen niet alleen bezig, het kan ook leuk zijn. In maart komt een vervolg op dit seminar waarin ik in ga op werkelijke praktijk cases en methodieken uitleg hoe je daadwerkelijk kunt besparen met cloud computing. Daarnaast leg ik ook uit hoe je de organisatie flexibeler kunt maken zodat deze wendbaarder is in de toekomst.

Een aantal dingen die mij zijn opgevallen en die we veel terug zullen zien komen dit jaar:

1) De drempel om cloud computing te adopteren wordt steeds lager
2) Steeds meer mensen zijn bewust van de verandering en verwelkomen deze ook
3) Onderscheid tussen privé en wat je transparant kan en mag maken wordt steeds duidelijker met het gevolg dat er ook meer data gedeeld gaat worden.
4) Social Media wordt steeds gewoner en wellicht zelfs saai. Dit maakt wel ruimte voor dingen die echt werken en omarmd zullen worden
5) Het Nieuwe Werken wordt ook steeds normaler waardoor de snelheid van adoptie alleen maar toeneemt. 6) De snelheid van ontwikkelingen in SaaS producten zoals Google Apps & Office 365 gaan steeds sneller en het krijgt zelfs symptomen van volwassenheid!
7) Om tegengas te geven aan al dit positieve nieuws denk ik dat de adoptie van het digitale lezen dit hele jaar nog steeds tegen veel weerstand zal aanlopen. Nederland is nog niet klaar om massaal over te stappen op digitaal lezen. Dit komt door het uitblijven van een “killer” gadget aan de ene kant, maar vooral aan het vastklampen aan het oude vertrouwde en niet willen loslaten van het huidige business model. Gevolg zal alleen maar meer slachtoffers maken.
8) Ook denk ik dat dit het jaar nog niet wordt van de video on demand ondanks dat dit wel klaar is voor een massale doorbraak. Ook hier lijkt het huidige business model innovatie tegen te gaan.

Wat je wel ziet gebeuren is dat er meer inhoud gegenereerd wordt welke zijn weg zal vinden buiten de bestaande modellen om. Zoals zelfs schrijven en publiceren zonder tussenkomst van uitgever.

Deze punten zal ik in prikkelende artikelen verder uitwerken. Wil je al snel meer weten? Neem dan contact met mij op.

Top 5 Cloud wensen voor 2012

Zo op de valreep van 2011 wil ik nog wat gedachten delen. Ik ben helemaal into the cloud en help bedrijven om ook te profiteren van cloud computing. Om de adoptie van cloud computing te versnellen heb ik een aantal wensen die het voor bedrijven makkelijker maken om de overstap te doen en daarnaast heb ik persoonlijk ook nog wat wensen voor de cloud.

Wens 1: Jezelf kunnen identificeren

Je kunt lang mijmeren over wat the Next Big Thing is na sites zoals Twitter, Facebook, Google, et cetera. Maar soms zie je dingen niet aankomen die achteraf zo voor de hand liggen. Een online paspoort is zo’n ding. Ja er zijn dappere pogingen gedaan door onder andere Microsoft met Passport, of OpenID, maar deze hebben nooit tot een hefboom geleidt of tot een breder gedragen veilige manier om jezelf aan te tonen. Google heeft onlangs zijn twee stappen verificatie uitgerold en dit is al een serieuze poging om de cloud een stuk veiliger te maken. In ieder geval is een username en wachtwoord onvoldoende veilig voor werken in de cloud, en een centrale vertrouwde dienst zou de cloud vleugels kunnen geven.

Wens 2: Tegendruk tegen het cloud geweld uit de verenigde staten

Alle grote cloud aanbieders komen uit de VS. De VS is ook een broedplaats voor allemaal vileine initiatieven zoals SOPA en Patriot Act. Niet alleen wettelijk is dit een doorn in het oog ook compliance (zoals klanten die aangeven dat hun data niet buiten de EU mag worden opgeslagen) is een beperking om aanbieders uit de verenigde staten te gebruiken. Daarnaast is hun mentaliteit drastisch anders dan in landen zoals Nederland en België. Ze hechten daar minder waarde aan privacy. Er zijn wel Benelux aanbieders maar het niveau van Amazon, Google, Microsoft, SalesForce et cetera wordt bij lange na niet gehaald. Met name het maken en bewerken van office documenten en synchroniseren van bestanden zou ik graag in de EU doen. Maar ook een selfservice zoals dit bij Amazon EC2 mogelijk is zou een welkome toevoeging zijn. En bijvoorbeeld een Azure oplossing die niet door Microsoft gehost wordt. Feit is dat Eu weinig krachtige alternatieven heeft, en als die er zijn, weten ze die goed verborgen te houden.

Wens 3: Een betaalbaar abonnement voor digitale diensten

Waarom is downloaden van films nog steeds gemakkelijker en veel goedkoper dan kopen? Waarom is streamen zoals Netflix dit in de verenigde staten doet goedkoop en bij ons zo beperkt en duur? Waarom doen uitgevers van boeken er alles aan om digitaal niet door te laten breken? Waarom zijn gekochte digitale boeken onhandiger dan gedownloade boeken? Waarom zijn digitale boeken niet substantieel goedkoper dan fysieke boeken? Waarom heb ik bij mijn eReader nog een computer nodig?

Voor muziek gebruik ik Spotify –betaald omdat ik het ook op mijn iPhone gebruik- maar voor films en boeken zijn nog geen goede oplossingen? Ik wil graag betalen, alleen niet veel meer dan ze in de verenigde staten doen. En ik snap dat Nederlandse boeken wel duurder zijn dat Amerikaanse boeken door de beperkte afzetmarkt. Maar een Nederlandse of Europees eco systeem ontbreekt.

Wens 4: Het kunnen monitoren van Cloud activiteiten

Ik ben over naar de Cloud. Ik werk veel samen met mensen uit andere bedrijven en freelancers, maar ik mis bepaalde tools in mijn cloud als het gaat om eigen medewerkers. Als ik bestanden deel in de cloud, dan wil ik iets meer gevoel van controle hebben. Bijvoorbeeld een waarschuwing als een exotisch IP adres bestanden opent. Of een overzicht van de sterkte van wachtwoorden van medewerkers, of een indicatie waar bestanden worden opgeslagen. Een dashboard met de hoeveel activiteit per medewerker zou al welkom zijn. Dus kortom meer mogelijkheden om het gevoel van inzicht te verstevigen.

Wens 5: Een gebruiksvriendelijk sociaal netwerk.

Ik had het met Hyves, ik heb het met Facebook, maar Google+ en LinkedIn zijn ook niet veel beter. Geregeld ben ik kwijt waar ik ben, waar ik naar kijk en of ik iets juist gedeeld heb. De usability van sociale netwerk sites is in de regel belabberd. Geregeld krijg ik een melding op telefoon of e-mail, daar klik ik dan op en vervolgens zie ik andere dingen dan ik verwacht had. Als ik het al moeilijk vind, wat moet mijn moeder ervan vinden? Daarnaast erger ik me dood al alle apps die rechten vragen op meer dan nodig is. Kun je op een site inloggen met je Facebook account, willen die meteen rechten om uit mijn naam status updates te schrijven. Daarnaast is het vaak onduidelijk of het koppelen op een veilige manier gebeurt. Wil je een spelletjes spelen, ziet iedereen meteen dat je het spelletje gespeeld hebt.

Wellicht kan ik nog meer wensen opschrijven, maar deze zijn voor mij een top 5 wensen die ik in 2012 graag gerealiseerd zou zien. Wat vind jij?

Hoe wordt ik een goede consultant?

Een paar jaar geleden gaf mijn zwager Jorg een tip over een boek wat ik in zijn ogen moest lezen. Flawless consulting van Peter Block. Als je consultant bent en dit boek nog niet kent, dit zou mijn eerste tip zijn. En om daar wat kracht achter te zetten zal ik een citaat opnemen waar ik persoonlijk veel van geleerd heb, een valkuil waar ik redelijk vaak ben ingestapt; consultant als “extra handjes”.

Consultant as an extra "pair-of-hands"
Here the manager sees the consultant as an extra "pair-of-hands".
The manager says in effect, "I have neither the time nor the inclination to deal with this problem. I have examined the deficiencies and have prepared an outline of what needs to be done. I want you to get it done as soon as possible". The manager retains full control. The consultant is expected to apply specialized knowledge to implement action plans toward the achievement of goals defined by the manager.

Here are some of the clues that the consultant is acting as a pair of hands.

The consultant takes a passive role. The order of the day is responding to the manager’s request, and the consultant does not question the manager’s action plans.

Decisions on how to proceed are made by the manager. The consultant may prepare recommendations for the manager’s review and approval.

The manager’s selects methods for data collection and analysis. The consultant may do the actual data collection in accordance with procedures outlined by the manager.

Control rests with the manager. The consultant is expected to make suggestions, but the outright disagreement is avoided as this would be seen as a challenge to the manager’s authority.

Collaboration is not really necessary. The manager feels that it is his or her responsibility to specify goals and procedures. The consultant can ask questions for clarification.

Two-way communication is limited. The manager initiates and the consultant responds. The manager initiates in a descriptive or evaluative mode.

The manager specifies change procedures for the consultant to implement.
The manager’s role is to judge and evaluate from a close distance.
The consulant’s goal is to make the system more effective by the application of specialized knowledge.

The major problem emerges in the discovery phase. In a pair-of-hands mode, the consultant is dependent on the manager’s ability to understand what is happening and to develop an effective action plan. If the manager’s assessment is faulty, the action plan won’t work. The consultant who provided the “service” becomes a convenient scapegoat.

To avoid the big trap, the consultant may ask for time to verify the manager’s assessment. And then the consultant may face other problems—managers who have a preference for consultants who take on the pair-of-hands role may interpret such requests as questioning their experience, their authority, or both.

~~~

Het hele boek staat vol van dit soort voorbeelden. En ook de manier waarop je hier mee om moet gaan zodat je consultancy zuiver houdt. Ik zal geen link geven waar je dit boek kunt bestellen, maar in de UK of VS is het boek zelfs inclusief verzendkosten een stuk goedkoper. Go get it!

Google is your friend.

2 Dropbox tips

Ik ben een enthousiast gebruiker van Dropbox. Hier zijn twee tips die het nog beter maken.

Tip 1: Indexeer PDF Files op 64 bits Windows
Ik heb een Fujitsu ScanSnap  en daarmee scan ik alle post in die ik binnen krijg. Deze scans worden ook meteen door de OCR heen gehaald. De scanner maakt PDF files aan welke ook nog eens doorzoekbaar zijn op woorden. Helaas als je Windows 64 bit versie hebt geïnstalleerd werkt deze standaard niet. Je moet hiervoor een Adobe PDF filter voor Windows installeren.

Na installatie zal je merken dat je nog steeds niet binnen PDF files kunt zoeken. Dit komt omdat de index over deze files opnieuw moet worden aangemaakt. De index opnieuw op laten bouwen is gelukkig niet moeilijk.

Klik op de Windows button (of start knop) en tik daar in Index. Je ziet dan een programma in de lijst verschijnen, in het Engels is dit “Indexing Options” in Nederlandstalig Windows “indexeringsopties”.

Klik op de knop Advanced (Geavanceerd)  en in het scherm staat in het midden een knop “Rebuild” of de Nederlandse variant “Opnieuw samenstellen”. Nu gaat hij opnieuw de indexen opbouwen en daarna kun je wel alle PDF files doorzoeken op trefwoorden.

Tip 2: Versleutel je dropbox folder op de laptop.
Stel je laptop wordt gestolen. Standaard zijn de gegevens op je laptop niet versleuteld en voor iedereen leesbaar. Dus ook de inhoud van je gehele Dropbox map. De oplossing is te maken met de tool TrueCrypt. Hiermee kun je een file maken die functioneert als een versleutelde harde schijf.  Door de DropBox folder op deze nieuwe virtuele harde schijf te plaatsen zijn de Dropbox files op de laptop onleesbaar bij verlies.

Nu moet je nog wel instellen dat Dropbox niet direct start als je jouw laptop opstart.

Bij het aanmaken van een harde schijf met TrueCrypt kun je aangeven dat deze automatisch start als je de laptop opstart. Hij zal dan om een wachtwoord vragen. Nadat dit gebeurd is kun je Dropbox starten. Met Google is ook wel te vinden hoe dit automatisch gebeurt, maar persoonlijk vind ik het niet erg om Dropbox handmatig op te starten.

Hiermee heb je de zekerheid dat je geen data aan derden overlaat als jouw laptop gestolen wordt. Uiteraard kun je ditzelfde doen op de vast PC thuis. Nu nog zorgen dat je een sterk wachtwoord gebruikt bij Dropbox zelf en deze niet voor andere diensten gebruikt, dan zit je wel veilig.

Veel instructies op het internet leggen je uit hoe je in Dropbox zelf de files kunt versleutelen, maar het nadeel hiervan is dat je dan de files niet kunt openen op je smartphone.

De server verdwijnt

Software op abonnementsbasis neemt momenteel een enorme vlucht en onderlinge integratie neemt werkbare vormen aan. Bij het oprichten van een nieuw bedrijf is het een reële mogelijkheid geworden om dit zonder eigen servers te doen. Sterker nog, ik denk dat er in veel gevallen helemaal geen server meer nodig is. Klinkt radicaal? Misschien wel, maar dat maakt het niet minder waar.

Het klinkt als een cliché vergelijking, toch pak ik hem weer op: stroom. Stroom is iets wat je afneemt en betaald naar gebruik. Van stroom zijn we behoorlijk afhankelijk en als een graafmachine de kabels kapot harkt doet niets het meer. Welk bedrijf heeft nog een eigen generator om stroom op te wekken? Juist, geen enkel bedrijf meer op een paar zeer uitzonderlijke gevallen na zoals een ziekenhuis. Gelukkig vertrouwen we op stroom en wordt er keihard aan gewerkt om je weer van stroom te voorzien. Zo is het ook met grote bedrijf die software aanbieden over het internet. Er kan altijd een ramp gebeuren, maar dit niet oplossen hoort niet bij de mogelijkheden.

Die generator om stroom op te wekken kun je vergelijken met een server. Ergens moet er nog wel een generator zijn om stroom op te wekken, maar je ziet hem niet meer. Het is voor het gebruik niet meer relevant geworden.

Terug naar de server. En de cloud. Cloud computing is helemaal niet relevant voor een afnemer van een software abonnement. Het is hooguit interessant voor het bedrijf dat de software maakt. Dus vergeet cloud computing.

Vanuit het perspectief van de software leverancier is het installeren van een server iets wat snel zal verdwijnen. Zeker in een tijd van cloud computing zijn alle servers sowieso al virtueel. En virtuele servers installeer je niet, het zijn gewoon files die door een stukje techniek zich voordoen als een server. Met een serverimage factory houd je virtuele servers up-to-date. AOL heeft een onbemand datacenter welke een virtuele server binnen 60 seconde productieklaar kan maken. Dat is iets anders dan een server bestellen en met de hand installeren.

Maar zelfs als softwaremaker wil je helemaal niet meer bezig zijn met een server. Je wilt code deployen op een platform. Dat het platform op servers draait zie je als ontwikkelaar niet. Het beheren van dit platform gaat gewoon met een management console die functioneert in een browser. Ook de database kan gewoon draaien op een platform en geldt hetzelfde voor.

Net als de generator is een server een generiek product geworden waar je eigenlijk niet meer individueel naar hoeft te kijken. Een server is nog steeds een complex stukje ijzer, maar het beheer is grotendeels versimpeld door verregaande automatisering. Automatisering bestaat uit laagjes en hoe beter de lagen op laag niveau geautomatiseerd zijn hoe minder er naar omgekeken hoeft te worden.

Traditioneel doet een server van alles. Het hosten van files, aannemen van connecties en het uitvoeren van code. Waar het in een virtueel scenario om draait is dat een server CPU kracht levert om code uit te voeren met vluchtig geheugen (RAM) . De specifieke files van bijvoorbeeld  de applicatie staan niet op de server maar op virtuele harde schijven (niet vluchtig geheugen). Wil je meer kracht? Dan schakel je virtuele servers bij. Gaat er één stuk? Dan switch een deel van de verwerkingskracht naar andere virtuele servers.

In de definities van cloud computing wordt vaak het piramide model gebruikt van SaaS, Paas en Iaas (afkortingen voor Software as a Service, Platform as a service en Infrastructure as a service). Als automatisering moderniseert zal de IaaS laag steeds minder zichtbaar worden en op termijn misschien zelfs verdwijnen. Je wilt geen servers, je wilt software!

Virtuele servers draaien op fysieke servers. Dat is onvermijdelijk. De titel van dit artikel zou dus eigenlijk moeten zijn; “De server verdwijnt uit het zicht…..”, maar dat klinkt al veel minder radicaal.

Rationalisering case: Productiviteit

Ik heb een aantal artikelen geschreven over het rationaliseren van het applicatie landschap. In deze artikelen ging ik niet dieper in op de praktijk met voorbeelden. Daarom beschrijf ik hier een concrete case waarin duidelijk wordt wat ik met rationaliseren bedoel en waarom het best lastig is.

De Case: Productiviteit
Bij een grote opdrachtgever kreeg ik de opdracht om productiviteit inzichtelijk te maken. Veel medewerkers werkte met een administratief systeem. Handelingen hadden een nummer en voor elke handeling stond het aantal minuten hoelang er over die handeling gedaan mocht worden. Dat lag in waardes tussen de 2 en 20 minuten. Per dag had een medewerker dus een aantal handelingen verricht en door dat te vermenigvuldigen met de normtijd kon je uitrekenen hoeveel werk een medewerker had verricht. Voor de berekening van productiviteit was dit niet genoeg. De input van het werkelijk aantal gewerkte uren was nodig om te kijken hoe de werkelijke productie was. Mensen hadden meer taken en variabele werktijden. Als iemand volgens de norm 6 uur had gewerkt, maar in de werkelijkheid 8 uur was bezig geweest, dan was diens productiviteit dus onder de norm.

Overigens is dit een vereenvoudiging van de werkelijke opdracht, ik houd me aan het noodzakelijke voor dit stuk.

Om de berekening dus te kunnen maken had ik de werkelijk gewerkte uren nodig. Deze konden (met enige moeite en autorisatie) uit een centraal management systeem verkregen worden. Daar zaten echter twee nadelen aan: De output was op weekniveau, en er was geen onderverdeling in het soort uren (administratieve handelingen en al het andere). Als iemand vergadering, studiedag of telefonische werkzaamheden verrichtte, dan kon dit niet herleid worden. Daarmee werd een berekening waardeloos.

Uitwerking van de case
Voor deze opdracht heb ik een tool ontwikkeld. Deze las dagelijkse de afgewerkte handelingen uit van medewerkers en controleerde op veranderingen in de norm tijden. Nu had ik nog de input nodig van de medewerkers die aan konden geven hoeveel uur ze op het administratieve systeem hadden gewerkt. Om dit zo eenvoudig mogelijk te maken konden roosters eenvoudig ingevoerd worden. Deze werden naar een planning in tijd geëxtrapoleerd. Alleen de afwijkingen invoeren volstond.

Nu was de output zuiver als mensen op tijd hun uren hadden ingevoerd. Diverse rapporten gaven inzicht op medewerker en afdeling niveau afgezet tegen een periode van tijd.

Door teamleiders aan te sturen kon de tool per afdeling worden uitgerold.

Teamleiders blij omdat ze nu ook op getallen konden sturen, opdrachtgever blij omdat een probleem was opgelost.

Alleen als je dit bekijkt in het kader van rationaliseren was dit helemaal niet goed. Het applicatielandschap was namelijk ingewikkelder geworden. Bij veranderingen had dit mogelijk ook impact op de tool en mensen moesten weer extra handelingen verrichten en een tool heeft ook onderhoud nodig als iets niet werkt of als er een fout hersteld moet worden. De IT kosten zijn dus toegenomen.

Hoe de case uitgewerkt had moeten worden
Allereerst was een besluit nodig of het een probleem was dat uren op week niveau binnen kwamen zoals beschreven in de case. Als dit geen probleem was, konden de uren geautomatiseerd worden ingelezen. Ik denk dat het geen probleem was. Je stuurt niet op wat er op een dag is gebeurd. Een slechte dag wordt misschien weer gecompenseerd met een goede dag later in de week. Je wilt niet sturen op microniveau, maar op trends. Welke afdeling zit onder de norm, en daarna, welke medewerker zit onder de norm, en in mijn ogen gebeurt dit niet op dagniveau.

Het eerste probleem dat er alleen een geautomatiseerde input op weekniveau beschikbaar was lijkt dus niet het grote probleem te zijn. De specificatie van de uren was dat wel. Door te kijken wat er mogelijk was aan de invoerkant, namelijk dat uren beter gespecificeerd moeten worden bij invoer zou dit opgelost kunnen worden. Ik had kort onderzoek gedaan en zag dat er wel wat meer mis was met de invoer. Zo boekte de ene afdeling reistijdcompensatie netjes, bij de andere afdeling werd alleen het totaal ingevoerd. Hier zat dus al een vervuiling die organisatorisch opgelost kon worden. Ook dat is rationaliseren, processen uniform maken levert economisch voordeel op.

Door dus de wijziging in de manier van registreren te veranderen (een organisatorische uitdaging) zou de berekening geautomatiseerd kunnen verlopen en het systeem veel eenvoudiger maken. Wellicht is er dan helemaal geen tool nodig en kan het met slimme rapportages worden uitgevoerd.

Deze manier van uitvoeren is wel lastiger omdat meer mensen op één lijn moesten komen en er meer mensen bij het proces betrokken zijn. Er was dus minder input van techniek nodig en meer input van de organisatie.

Conclusie
De case is in mijn ogen een goed voorbeeld over de subtiliteit van rationalisatie en het nemen van goede, maar moeilijke beslissingen. De case was goed uitgewerkt en heeft geleid tot een goed resultaat, de gekozen oplossing was dus helemaal niet fout en mogelijk de enige mogelijkheid. Maar op de langere termijn en met een visie van vereenvoudiging was de case niet goed uitgewerkt. De investering lag nu meer in techniek terwijl deze in de organisatie had moeten zitten. Dit is in mijn ogen een heel goed voorbeeld hoe het er in de praktijk aan toe gaat. Er wordt een technische oplossing gezocht terwijl een voornamelijk organisatorische oplossing had kunnen volstaan. En als je aan een techneut of leverancier een probleem beschrijft, zal deze in de regel zoeken naar een technische oplossing omdat dit namelijk geld oplevert en met de minste weerstand kan worden uitgevoerd. De gerationaliseerde oplossing zou de leverancier overbodig maken, en als de trend doorzet voor omzetverlies zorgen. Maar dan moet er wel goed leiderschap aanwezig zijn.

Rationaliseren is zeker niet (in alle gevallen) slecht voor een leverancier, maar dit voorbeeld illustreert wel wat ik bedoel met rationaliseren en dat dit meer vergt van een organisatie dan een besteding van geld.

Wat laatste gedachten
Uiteraard is niet alles zwart-wit. In het beschreven geval was rationaliseren misschien niet goed mogelijk geweest. Een andere oplossing was wellicht dat de administratieve software zou registreren wanneer een gebruiker inlogt en uitlogt, maar dan heb je weer de mogelijke afwijking dat iemand niet netjes afsluit voordat hij of zij een vergadering in gaat. Punt blijft wel dat als je een ontwikkelaar vraagt naar een oplossing, deze vaak gevonden wordt in het maken van een tool.

Besparen met rationaliseren

Het hebben en beheren van software kost veel geld. Vooral als dit maatwerk is of maatwerk op standaard software. Dit kom ik zeer veel tegen in de praktijk en de werkelijke kosten hiervan zijn nog hoger dan een optelling van de uren die besteed worden aan externe consultants, licentiekosten en kosten die gepaard gaan met het upgraden van deze niet meer zo standaard software. Deze kosten stijgen nog sneller als de software al langer mee gaat. Een ander fenomeen is dat er door de tijd steeds meer software bij komt.

Naast al deze zichtbare kosten zijn er ook onzichtbare kosten die niet direct gekoppeld worden aan het hebben beheren en onderhouden van deze software. Dit zijn kosten zoals de uren die vanuit de eigen organisatie besteedt worden aan deze software, bijvoorbeeld die van de IT afdeling. Maar de vergaderingen, testen en overleg uren van niet IT mensen over de software problematiek zijn per definitie onzichtbaar en worden niet toegekend aan de total cost of ownership (TCO).

Hoe groter het applicatielandschap hoe meer verborgen kosten er zijn en de grootte is nauwelijks vast te stellen. Vraag er eens naar binnen de organisatie. Kansen zijn zeer groot dat mijn stelling direct bewezen wordt. Klopt dit niet? Gefeliciteerd, u bent echt de eerste!

Hoe kunnen die kosten verlaagd worden? Hoe kan er op software bespaard worden?

Dit is geen gemakkelijke taak en het inhuren van een ervaringsdeskundige is een goede beslissing (hint: check de schrijver van dit artikel).

Een belangrijke eerste stap is bewustwording. Als de kosten inzichtelijk worden gemaakt kan de potentie van de besparing gedimensioneerd worden. Als deze bewustwording er is komt stap 2: Het rationaliseren van het applicatielandschap; of in mensen taal economischer maken.

Een aantal acties die onder rationaliseren vallen zijn: Pensioneren, Consolideren, vervangen, verbouwen, bevriezen, virtualiseren, ontsluiten, et cetera.

Voor elke voorbeeld geldt dat sommige manieren veel beter zijn dan andere manieren en foute toepassing leidt tot meer kosten. Onderschat interne politiek en gebrek aan consensus niet.

Praktische voorbeelden van rationaliseren zijn dat aanvragen op het gebied van aanpassingen scherp onder de loep genomen worden en dat een organisatorische wijziging verkozen wordt boven een software aanpassing. Dat er serieus gekeken wordt om een applicatie met pensioen te sturen of te verplaatsen naar een gevirtualiseerde server. Uiteindelijk wil je het applicatie landschap eenvoudiger maken en zoveel mogelijk aan laten sluiten op standaard software. Als een ander bedrijf in dezelfde branche het met standaard software kan, waarom uw organisatie niet?

Hoe slanker de software, hoe minder er over gesproken hoeft te worden, hoe minder incidenten plaats vinden en hoe makkelijker de software mee groeit met de nieuwe ontwikkelingen. Less is more. En hoe minder er is om rekening mee te houden hoe flexibeler uw organisatie wordt.

Cloud strategie: Zelf bediening

In een serie artikelen over cloud computing wil ik concreter ingaan op strategieën voor cloud computing. Dit keer over zelfbediening.

Een belangrijk onderdeel van cloud computing is het zelfbediening aspect. Dit heeft meerdere kanten. Aan de ene kant betekent dit dat u bijvoorbeeld capaciteit kunt “bijkopen” als er behoefte aan is, of juist de capaciteit terug brengen als dit niet meer nodig is. Dit belicht de kant van uw organisatie als klant bij een cloud dienst. De andere kant gaat over hoe uw organisatie met zelfbediening om gaat. Hierin is uw organisatie de kant van de aanbieder van zelf bediening, mogelijk in de vorm van cloud computing.

Een aantal voorbeelden:

Laatst was ik op een site over psychologie: PsyBlog  (http://goo.gl/IthGr). Daar werd een e-book verkocht voor 6 euro. Dit boek wordt alleen elektronisch verkocht en de schrijver van dit boek gebruikt hiervoor een cloud dienst die de distributie en betaling regelt. Zonder dat de schrijver enige inspanning meer hoeft te leveren kan hij geld verdienen. Het maakt niet uit of hij 100, 1000 of een miljoen exemplaren verkoopt. Er verplaatst geld zonder dat hier achteraf nog arbeid in gestopt hoeft te worden. Dit is in tegenstelling tot de fysieke wereld een enorm krachtig principe. In de VS lopen ze sowieso al voorop als het gaat om ebooks, maar ook hier hebben genoeg mensen een iPad. Juist doordat er geen arbeid meer aan te pas komt is de prijs ook laag, ik heb het gekocht als impuls aankoop. Met PayPal (ook een cloud dienst) heb ik binnen een minuut betaald en mijn boek binnen..

Een ander voorbeeld is euromasters. Zonder tussenkomst van een mens regel ik zelf mijn afspraak wanneer ik mijn banden wil verwisselen.

Vroeger kwam er iemand langs om mijn meters te controleren, nu krijg ik een kaartje, maar binnenkort krijg ik wellicht alleen nog maar een e-mail. Zolang de standen redelijk lijken is er geen fysieke controle nodig. Dit is een enorme besparing.

Voor een klant heb ik een training plan systeem ontwikkeld. Stapje voor stapje gaat ook dat steeds dichter naar zelfbediening toe. Klanten krijgen automatisch een e-mail met een aantal voorgestelde trainingsdata in hun regio waarin een certificaat door middel van een training verlengd kan worden. Inschrijven gaat daarna ook volledig digitaal. Nieuwe klanten kunnen zichzelf registreren en cursisten aanmelden op open inschrijvingen. Vroeger ging er klantcontact vooraf aan het aansluiten van nieuwe klanten, nu melden zich klanten aan waarvoor geen inspanning meer geleverd hoeft te worden.

Een ander voorbeeld is de extractie tool die ik voor een klant gebouwd heb. Voorheen werden bestanden versleuteld en verstuurd of geüpload naar een sftp server. Hier kwam bijna per definitie mensenhanden aan te pas. Met de tool wordt data direct uit een database gehaald en versleuteld verstuurd. Ook werd een map door de tool (in de vorm van een service) gemonitord en werden bepaalde bestanden direct automatisch en veilig naar een centrale server toe gestuurd.

Coaching is hot, vaak gebeurt dit één op één, maar er zijn ook coaches die coachen als seminar dus voor een groep mensen. Maar er zijn coaches die interessante mensen interviewen en een deel van dit interview bieden ze gratis aan, wilt u meer, dan moet er een lidmaatschap afgesloten worden. Dit lid worden en betalen gaat zonder tussenkomst van menselijk contact. De hefboom hiervan is natuurlijk enorm.

Neem de tijd en besef dat er ook mogelijkheden zijn voor uw organisatie om te profiteren van zelfbediening, een aantal voorbeelden heb ik gegeven. Zelfbediening kan leiden tot grote veranderingen in bijvoorbeeld schaalvergroting of enorme kostenbesparing. Het kan letterlijk een organisatie naar een hoger plan tillen.

Ik hoor van steeds meer klanten dat hun klanten en leveranciers steeds meer zaken digitaal willen ontvangen. Het is niet alleen sneller, maar hoeft ook niet eerst ingescand te worden voordat het intern kan worden doorgestuurd.

Een andere aardige oplossing is het gebruik maken van post services. Zo is er bijvoorbeeld BlueMailCentral (http://goo.gl/aKYdg ).  Met hun software krijgt u er een virtuele printer bij op de computer. Als deze gebruikt wordt om te printen, dan wordt het digitale document verstuurd naar een dienst die de brief discreet uitprint en in een (aanpasbare) envelop stopt en vervolgens verstuurd. Dit gebeurt uiteraard volledig geautomatiseerd. De software is zelf zo slim om meestal al de juiste geadresseerde in te stellen. Dit kan overigens ook grote voordelen hebben als post verstuurd wordt naar bijvoorbeeld Australië, deze wordt binnen 2 dagen bezorgd. De software kent ook een Application Programming Interface (API) waardoor eigen software hierop kan worden aangesloten. Bij het versturen van post komt zodoende geen menselijk handelen meer kijken.

Dit is in feite waar cloud computing over gaat. Automatiseren, zelfbediening en schaalbaarheid. Het verplaatsen van bitjes in plaats van atomen kan voor drastisch andere kostenplaatjes zorgen.

Cloud computing biedt enorm veel voordelen en kan leiden tot een hefboom, soms kan een kleine verandering al enorm veel positieve gevolgen hebben.

Uw organisatie heeft ook mogelijkheden op dit vlak, deze inventariseer ik graag voor u.

Stevey's Google Platforms Rant

Steve Yegge (http://goo.gl/KwURQ) is a google engineer who also worked at Amazon. What’s bothering Steve is that Google has a wrong approach to its products. He’s having a rant about it but he posted it to the public instead of to his colleagues at Google. It’s a brilliant read and this is just a mirror since he deleted his post. I can write a lot about the content, but I will not, judge yourself.

____

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't really have SREs and they make engineers pretty much do everything, which leaves almost no time for coding - though again this varies by group, so it's luck of the draw. They don't give a single shit about charity or helping the needy or community contributions or anything like that. Never comes up there, except maybe to laugh about it. Their facilities are dirt-smeared cube farms without a dime spent on decor or common meeting areas. Their pay and benefits suck, although much less so lately due to local competition from Google and Facebook. But they don't have any of our perks or extras -- they just try to match the offer-letter numbers, and that's the end of it. Their code base is a disaster, with no engineering standards whatsoever except what individual teams choose to put in place.

To be fair, they do have a nice versioned-library system that we really ought to emulate, and a nice publish-subscribe system that we also have no equivalent for. But for the most part they just have a bunch of crappy tools that read and write state machine information into relational databases. We wouldn't take most of it even if it were free.

I think the pubsub system and their library-shelf system were two out of the grand total of three things Amazon does better than google.

I guess you could make an argument that their bias for launching early and iterating like mad is also something they do well, but you can argue it either way. They prioritize launching early over everything else, including retention and engineering discipline and a bunch of other stuff that turns out to matter in the long run. So even though it's given them some competitive advantages in the marketplace, it's created enough other problems to make it something less than a slam-dunk.

But there's one thing they do really really well that pretty much makes up for ALL of their political, philosophical and technical screw-ups.

Jeff Bezos is an infamous micro-manager. He micro-manages every single pixel of Amazon's retail site. He hired Larry Tesler, Apple's Chief Scientist and probably the very most famous and respected human-computer interaction expert in the entire world, and then ignored every goddamn thing Larry said for three years until Larry finally -- wisely -- left the company. Larry would do these big usability studies and demonstrate beyond any shred of doubt that nobody can understand that frigging website, but Bezos just couldn't let go of those pixels, all those millions of semantics-packed pixels on the landing page. They were like millions of his own precious children. So they're all still there, and Larry is not.

Micro-managing isn't that third thing that Amazon does better than us, by the way. I mean, yeah, they micro-manage really well, but I wouldn't list it as a strength or anything. I'm just trying to set the context here, to help you understand what happened. We're talking about a guy who in all seriousness has said on many public occasions that people should be paying him to work at Amazon. He hands out little yellow stickies with his name on them, reminding people "who runs the company" when they disagree with him. The guy is a regular... well, Steve Jobs, I guess. Except without the fashion or design sense. Bezos is super smart; don't get me wrong. He just makes ordinary control freaks look like stoned hippies.

So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.

His Big Mandate went something along these lines:

1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

6) Anyone who doesn't do this will be fired.

7) Thank you; have a nice day!

Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.

#6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Armgy Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Wal*Mart, and is a big genial scary man who used the word "hardened interface" a lot. Rick was a walking, talking hardened interface himself, so needless to say, everyone made LOTS of forward progress and made sure Rick knew about it.

Over the next couple of years, Amazon transformed internally into a service-oriented architecture. They learned a tremendous amount while effecting this transformation. There was lots of existing documentation and lore about SOAs, but at Amazon's vast scale it was about as useful as telling Indiana Jones to look both ways before crossing the street. Amazon's dev staff made a lot of discoveries along the way. A teeny tiny sampling of these discoveries included:

- pager escalation gets way harder, because a ticket might bounce through 20 service calls before the real owner is identified. If each bounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build a lot of scaffolding and metrics and reporting.

- every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service.

- monitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum.

- if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't be able to find any of them without a service-discovery mechanism. And you can't have that without a service registration mechanism, which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where.

- debugging problems with someone else's code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox.

That's just a very small sample. There are dozens, maybe hundreds of individual learnings like these that Amazon had to discover organically. There were a lot of wacky ones around externalizing services, but not as many as you might think. Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers.

This effort was still underway when I left to join Google in mid-2005, but it was pretty far advanced. From the time Bezos issued his edict through the time I left, Amazon had transformed culturally into a company that thinks about everything in a services-first fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally.

At this point they don't even do it out of fear of being fired. I mean, they're still afraid of that; it's pretty much part of daily life there, working for the Dread Pirate Bezos and all. But they do services because they've come to understand that it's the Right Thing. There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it's the right thing because SOA-driven design enables Platforms.

That's what Bezos was up to with his edict, of course. He didn't (and doesn't) care even a tiny bit about the well-being of the teams, nor about what technologies they use, nor in fact any detail whatsoever about how they go about their business unless they happen to be screwing up. But Bezos realized long before the vast majority of Amazonians that Amazon needs to be a platform.

You wouldn't really think that an online bookstore needs to be an extensible, programmable platform. Would you?

Well, the first big thing Bezos realized is that the infrastructure they'd built for selling and shipping books and sundry could be transformed an excellent repurposable computing platform. So now they have the Amazon Elastic Compute Cloud, and the Amazon Elastic MapReduce, and the Amazon Relational Database Service, and a whole passel' o' other services browsable at aws.amazon.com. These services host the backends for some pretty successful companies, reddit being my personal favorite of the bunch.

The other big realization he had was that he can't always build the right thing. I think Larry Tesler might have struck some kind of chord in Bezos when he said his mom couldn't use the goddamn website. It's not even super clear whose mom he was talking about, and doesn't really matter, because nobody's mom can use the goddamn website. In fact I myself find the website disturbingly daunting, and I worked there for over half a decade. I've just learned to kinda defocus my eyes and concentrate on the million or so pixels near the center of the page above the fold.

I'm not really sure how Bezos came to this realization -- the insight that he can't build one product and have it be right for everyone. But it doesn't matter, because he gets it. There's actually a formal name for this phenomenon. It's called Accessibility, and it's the most important thing in the computing world.

The. Most. Important. Thing.

If you're sorta thinking, "huh? You mean like, blind and deaf people Accessibility?" then you're not alone, because I've come to understand that there are lots and LOTS of people just like you: people for whom this idea does not have the right Accessibility, so it hasn't been able to get through to you yet. It's not your fault for not understanding, any more than it would be your fault for being blind or deaf or motion-restricted or living with any other disability. When software -- or idea-ware for that matter -- fails to be accessible to anyone for any reason, it is the fault of the software or of the messaging of the idea. It is an Accessibility failure.

Like anything else big and important in life, Accessibility has an evil twin who, jilted by the unbalanced affection displayed by their parents in their youth, has grown into an equally powerful Arch-Nemesis (yes, there's more than one nemesis to accessibility) named Security. And boy howdy are the two ever at odds.

But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network.

So yeah. In case you hadn't noticed, I could actually write a book on this topic. A fat one, filled with amusing anecdotes about ants and rubber mallets at companies I've worked at. But I will never get this little rant published, and you'll never get it read, unless I start to wrap up.

That one last thing that Google doesn't do well is Platforms. We don't understand platforms. We don't "get" platforms. Some of you do, but you are the minority. This has become painfully clear to me over the past six years. I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.

But no. No, it's like our tenth or eleventh priority. Or fifteenth, I don't know. It's pretty low. There are a few teams who treat the idea very seriously, but most teams either don't think about it all, ever, or only a small percentage of them think about it in a very small way.

It's a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they're building products. And a stubby service is a pretty pathetic service. Go back and look at that partial list of learnings from Amazon, and tell me which ones Stubby gives you out of the box. As far as I'm concerned, it's none of them. Stubby's great, but it's like parts when you need a car.

A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.

Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don't get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. We had no API at all at launch, and last I checked, we had one measly API call. One of the team members marched in and told me about it when they launched, and I asked: "So is it the Stalker API?" She got all glum and said "Yeah." I mean, I was joking, but no... the only API call we offer is to get someone's stream. So I guess the joke was on me.

Microsoft has known about the Dogfood rule for at least twenty years. It's been part of their culture for a whole generation now. You don't eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.

Google+ is a knee-jerk reaction, a study in short-term thinking, predicated on the incorrect notion that Facebook is successful because they built a great product. But that's not why they are successful. Facebook is successful because they built an entire constellation of products by allowing other people to do the work. So Facebook is different for everyone. Some people spend all their time on Mafia Wars. Some spend all their time on Farmville. There are hundreds or maybe thousands of different high-quality time sinks available, so there's something there for everyone.

Our Google+ team took a look at the aftermarket and said: "Gosh, it looks like we need some games. Let's go contract someone to, um, write some games for us." Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.

You can't do that. Not really. Not reliably. There have been precious few people in the world, over the entire history of computing, who have been able to do it reliably. Steve Jobs was one of them. We don't have a Steve Jobs here. I'm sorry, but we don't.

Larry Tesler may have convinced Bezos that he was no Steve Jobs, but Bezos realized that he didn't need to be a Steve Jobs in order to provide everyone with the right products: interfaces and workflows that they liked and felt at ease with. He just needed to enable third-party developers to do it, and it would happen automatically.

I apologize to those (many) of you for whom all this stuff I'm saying is incredibly obvious, because yeah. It's incredibly frigging obvious. Except we're not doing it. We don't get Platforms, and we don't get Accessibility. The two are basically the same thing, because platforms solve accessibility. A platform is accessibility.

So yeah, Microsoft gets it. And you know as well as I do how surprising that is, because they don't "get" much of anything, really. But they understand platforms as a purely accidental outgrowth of having started life in the business of providing platforms. So they have thirty-plus years of learning in this space. And if you go to msdn.com, and spend some time browsing, and you've never seen it before, prepare to be amazed. Because it's staggeringly huge. They have thousands, and thousands, and THOUSANDS of API calls. They have a HUGE platform. Too big in fact, because they can't design for squat, but at least they're doing it.

Amazon gets it. Amazon's AWS (aws.amazon.com) is incredible. Just go look at it. Click around. It's embarrassing. We don't have any of that stuff.

Apple gets it, obviously. They've made some fundamentally non-open choices, particularly around their mobile platform. But they understand accessibility and they understand the power of third-party development and they eat their dogfood. And you know what? They make pretty good dogfood. Their APIs are a hell of a lot cleaner than Microsoft's, and have been since time immemorial.

Facebook gets it. That's what really worries me. That's what got me off my lazy butt to write this thing. I hate blogging. I hate... plussing, or whatever it's called when you do a massive rant in Google+ even though it's a terrible venue for it but you do it anyway because in the end you really do want Google to be successful. And I do! I mean, Facebook wants me there, and it'd be pretty easy to just go. But Google is home, so I'm insisting that we have this little family intervention, uncomfortable as it might be.

After you've marveled at the platform offerings of Microsoft and Amazon, and Facebook I guess (I didn't look because I didn't want to get too depressed), head over to developers.google.com and browse a little. Pretty big difference, eh? It's like what your fifth-grade nephew might mock up if he were doing an assignment to demonstrate what a big powerful platform company might be building if all they had, resource-wise, was one fifth grader.

Please don't get me wrong here -- I know for a fact that the dev-rel team has had to FIGHT to get even this much available externally. They're kicking ass as far as I'm concerned, because they DO get platforms, and they are struggling heroically to try to create one in an environment that is at best platform-apathetic, and at worst often openly hostile to the idea.

I'm just frankly describing what developers.google.com looks like to an outsider. It looks childish. Where's the Maps APIs in there for Christ's sake? Some of the things in there are labs projects. And the APIs for everything I clicked were... they were paltry. They were obviously dog food. Not even good organic stuff. Compared to our internal APIs it's all snouts and horse hooves.

And also don't get me wrong about Google+. They're far from the only offenders. This is a cultural thing. What we have going on internally is basically a war, with the underdog minority Platformers fighting a more or less losing battle against the Mighty Funded Confident Producters.

Any teams that have successfully internalized the notion that they should be externally programmable platforms from the ground up are underdogs -- Maps and Docs come to mind, and I know GMail is making overtures in that direction. But it's hard for them to get funding for it because it's not part of our culture. Maestro's funding is a feeble thing compared to the gargantuan Microsoft Office programming platform: it's a fluffy rabbit versus a T-Rex. The Docs team knows they'll never be competitive with Office until they can match its scripting facilities, but they're not getting any resource love. I mean, I assume they're not, given that Apps Script only works in Spreadsheet right now, and it doesn't even have keyboard shortcuts as part of its API. That team looks pretty unloved to me.

Ironically enough, Wave was a great platform, may they rest in peace. But making something a platform is not going to make you an instant success. A platform needs a killer app. Facebook -- that is, the stock service they offer with walls and friends and such -- is the killer app for the Facebook Platform. And it is a very serious mistake to conclude that the Facebook App could have been anywhere near as successful without the Facebook Platform.

You know how people are always saying Google is arrogant? I'm a Googler, so I get as irritated as you do when people say that. We're not arrogant, by and large. We're, like, 99% Arrogance-Free. I did start this post -- if you'll reach back into distant memory -- by describing Google as "doing everything right". We do mean well, and for the most part when people say we're arrogant it's because we didn't hire them, or they're unhappy with our policies, or something along those lines. They're inferring arrogance because it makes them feel better.

But when we take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we're being fools. You can attribute it to arrogance, or naivete, or whatever -- it doesn't matter in the end, because it's foolishness. There IS no perfect product for everyone.

And so we wind up with a browser that doesn't let you set the default font size. Talk about an affront to Accessibility. I mean, as I get older I'm actually going blind. For real. I've been nearsighted all my life, and once you hit 40 years old you stop being able to see things up close. So font selection becomes this life-or-death thing: it can lock you out of the product completely. But the Chrome team is flat-out arrogant here: they want to build a zero-configuration product, and they're quite brazen about it, and Fuck You if you're blind or deaf or whatever. Hit Ctrl-+ on every single page visit for the rest of your life.

It's not just them. It's everyone. The problem is that we're a Product Company through and through. We built a successful product with broad appeal -- our search, that is -- and that wild success has biased us.

Amazon was a product company too, so it took an out-of-band force to make Bezos understand the need for a platform. That force was their evaporating margins; he was cornered and had to think of a way out. But all he had was a bunch of engineers and all these computers... if only they could be monetized somehow... you can see how he arrived at AWS, in hindsight.

Microsoft started out as a platform, so they've just had lots of practice at it.

Facebook, though: they worry me. I'm no expert, but I'm pretty sure they started off as a Product and they rode that success pretty far. So I'm not sure exactly how they made the transition to a platform. It was a relatively long time ago, since they had to be a platform before (now very old) things like Mafia Wars could come along.

Maybe they just looked at us and asked: "How can we beat Google? What are they missing?"

The problem we face is pretty huge, because it will take a dramatic cultural change in order for us to start catching up. We don't do internal service-oriented platforms, and we just as equally don't do external ones. This means that the "not getting it" is endemic across the company: the PMs don't get it, the engineers don't get it, the product teams don't get it, nobody gets it. Even if individuals do, even if YOU do, it doesn't matter one bit unless we're treating it as an all-hands-on-deck emergency. We can't keep launching products and pretending we'll turn them into magical beautiful extensible platforms later. We've tried that and it's not working.

The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later. Certainly not easily at any rate -- ask anyone who worked on platformizing MS Office. Or anyone who worked on platformizing Amazon. If you delay it, it'll be ten times as much work as just doing it correctly up front. You can't cheat. You can't have secret back doors for internal apps to get special priority access, not for ANY reason. You need to solve the hard problems up front.

I'm not saying it's too late for us, but the longer we wait, the closer we get to being Too Late.

I honestly don't know how to wrap this up. I've said pretty much everything I came here to say today. This post has been six years in the making. I'm sorry if I wasn't gentle enough, or if I misrepresented some product or team or person, or if we're actually doing LOTS of platform stuff and it just so happens that I and everyone I ever talk to has just never heard about it. I'm sorry.

But we've gotta start doing this right.

Banken hebben de sleutel

Normaal schrijf ik artikelen over de toekomst van de automatisering. Vandaag wil ik schrijven over de toekomst van ons land en hoe deze ten goede veranderd kan worden. Het is een oproep en een vraag. De oproep is om dit te delen zodat de vraag beantwoord kan worden: Wat kan er aangevuld worden op onderstaande redenering?

We zitten in een vicieuze cirkel die ons allemaal raakt. De economie hapert en niet alleen die van Nederland. In 2008 zijn we geraakt door een financiële crisis waarin banken de hoofdrol speelden. Vandaag worden we ook geraakt alleen niet door een directe oorzaak in het nu, maar als een gevolg. Een nasleep van de crisis die in 2008 begon. Deze crisis kan worden opgelost en dit is hoe.

Er moeten meer huizen verkocht worden.

Als je de tijd neemt om de redenering te volgen kun je in mijn ogen geen andere conclusie trekken. En als mijn conclusie niet goed is, vul hem alsjeblieft aan zodat hij wel kloppend is en deze cirkel doorbroken kan worden ten goede van ons allen.

Dit is wat er gebeurt als er huizen worden verkocht: Mensen kopen nieuwe keukens en gaan naar bouwmarkten. Keukens bevatten aanrechtbladen die ook in Nederland geproduceerd worden. Vorig jaar zijn er 120.000 minder keukens verkocht en dit raakt de hele branche hard. Maar ook makelaars, hypotheek adviseurs en notarissen worden geraakt. Ook verhuizers beginnen het nu echt te voelen en in de gehele keten gaan er mensen uit. Dit zijn ook huizenbezitters die mogelijk in de problemen zitten of potentiële huizenkopers die dit voorlopig niet zullen doen.

Minder huizen verkopen leidt ook tot minder huizen bouwen, veel ZZP’ers in de bouw hebben zo geen werk, en er worden zelfs minder kilometers gemaakt zodat de pompstations een teruggang voelen.

De hele keten voelt de malaise en als ondernemer wordt je echt niet gelukkig van deze situatie. Mensen in de keten zullen zuinig zijn en dat raakt ook weer de horeca. Alles is met deze keten verbonden.

Doordat er minder huizen worden verkocht daalt de prijs en de kans dus op een restschuld waardoor er alleen maar meer problemen ontstaan.

Momenteel worden veel hypotheek aanvragen niet gehonoreerd. Enerzijds omdat mensen teveel willen lenen, anderzijds omdat er meer gekeken wordt naar de risico’s. Er zijn in het verleden veel hypotheken verkocht met een hoog percentage aflossingsvrij. Dit levert toekomstige risico’s op, ik ben daar niet blind voor. Maar om de deur dicht te houden schaadt de economie op zeer veel vlakken.

Door gewoon weer hypotheken af te sluiten en daarin wat soepeler te zijn zullen er meer huizen verkocht worden en zal de huizenprijs weer stijgen. Er vloeit weer geld en daardoor hoeven minder mensen ontslagen te worden. Mensen die nu een hypotheek probleem hebben, krijgen zo meer kans om dit probleem op te lossen als de economie weer draait. En als je nu als bank een hypotheek afsluit met wat meer risico, bijvoorbeeld 100% aflossingsvrij, dan kun je dit ook wel weer aan voorwaarden verbinden. Bijvoorbeeld maximaal tien jaar. Mijn hypotheeklast is momenteel ongeveer 1000 euro bruto. Dat is deze over vijftien jaar nog steeds. 1000 euro is over vijftien jaar is echter een stuk minder waard geworden door onder andere inflatie.

Banken en aanverwante bedrijven stonden aan de wieg van de kredietcrisis. Ze hebben ook nu de sleutel in handen voor verbetering.

Laten zijn de vicieuze cirkel doorbreken en de spiraal omhoog terugvinden.

Niets doen maakt de crisis alleen maar slepend. En wat de regering ook voor extra’s doet, het zal in veelvoud bij ze terugkomen. Op alle genoemde zaken zit belasting, dus als de keten een boost krijgt zullen de belastinginkomsten groeien.

Ik zie het voor me en hoor graag waar mijn beredenering niet klopt.

Banken worden soepeler, mensen krijgen sneller een hypotheek en kunnen eindelijk huizen kopen. Verkopers zijn van een probleem af en kunnen nu zelf ook verhuizen of hoeven nu geen dubbele hypotheeklasten meer op te brengen. Tussenpersonen, notarissen, makelaars verdienen weer meer geld en hoeven geen mensen meer te ontslaan. Bouwmarkten krijgen het drukken, keukenwinkels verkopen weer keukens. Transport sector mag meer gaan rijden, huizenprijzen zullen weer stijgen zodat mensen die niet aan de verplichtingen kunnen voldoen met minder restschuld blijven zitten.

En als het allemaal weer goed gaat kunnen we ook naar Griekenland op vakantie.

In 2008 was er een hele duidelijke oorzaak waarom alles instortte. Nu is het vooral de angst en sentiment wat ons tegenhoudt. Hier kunnen we pas uit stappen als we gaan investeren in plaats van alleen maar bezuinigen. Hogere kosten zijn beter te dragen als je groeit.

Wat is nu feitelijk het risico? Dat banken leningen verstrekken aan mensen die het niet terug kunnen betalen? En is dat risico niet beter te dragen als er meer binnenkomt? Geld moet rollen en momenteel hebben we gewoon een adrenaline boost nodig om dit in werking te stellen.

YES WE CAN!

Rationalisatie op weg naar de cloud

Eerder schreef ik al over de veranderingen die cloud computing ons gaat brengen en dat het nu de tijd is dat bedrijven een cloud strategie ontwikkelen. De cloud bied niet alleen mogelijkheden voor bedrijven om verder te automatiseren, flexibel te zijn en kosten te besparen, maar het verandert ook de markt voor consumenten, de manier waarop de jeugd werkt en leert en wellicht dus het hele ecosysteem van een branche.

Daarnaast zijn de kosten voor het huidige landschap hoger dan de optelsom van hardware, licenties en arbeid van de IT afdeling om het in de lucht te houden. Hoe hoger de gemiddelde leeftijd van applicaties hoe meer verborgen kosten er zijn. Verborgen kosten zijn wachttijden van medewerkers bij uitval, extra handelingen die nodig zijn omdat een systeem niet optimaal (meer) is, extra tijd die nodig is bij het uitvoeren van handelingen omdat het landschap complex is.

Tijdens een presentatie van Martien Ouwens van Oracle op een Computerworld event gaf Martien aan dat bedrijven die goed zijn in het rationaliseren van het applicatielandschap, goed zijn in het adopteren van cloud computing.

Toevallig schreef Ron Tolido van Capgemini ( http://goo.gl/CBlGQ ) onlangs ook over het rationaliseren van het applicatielandschap in de Automatiseringsgids, en dat dit één van de grootste kopzorgen van CIO’s geworden is.

Nu is dus een goed moment om hier wat handen en voeten aan te geven.

Saillant detail is dat het lastig is om een definitie van applicatielandschap te vinden terwijl de term al qua beeld scheppend is. Mijn definitie is de gebruikte applicaties binnen een organisatie inclusief de onderliggende samenhang.

Met rationaliseren wordt het praktisch maken of economisch inrichten bedoeld. Dat huidige legacy applicaties een groot obstakel vormen voor het bewegen richting cloud computing lijkt mij een no-brainer. De applicatie heeft al een hoop meegemaakt en is vergroeid met de organisatie waardoor onderlinge afhankelijkheden in de regel alleen maar zijn toegenomen. Het gat tussen cloud en deze applicaties is dus ook het grootst. 

Een belangrijk inzicht dat de slagingskans van rationaliseren vergroot is dat de projecten die voortvloeien uit rationalisatie wel betrekking hebben op de IT maar zeker niet allemaal IT projecten zijn. Het zijn veelal ook organisatorische veranderingen. Rationaliseren is dus een symbiose van organisatie en techniek.

Een voorbeeld: Door een opdrachtgever werd me gevraagd structurele management rapportages te genereren om productiviteit inzichtelijk te maken. Snel ontdekte ik dat afdelingen onderling een iets andere methode hadden voor het registreren van uren. Dit maakte berekeningen arbeidsintensiever en moeilijker. Door hier eerst uniformiteit in aan te brengen (organisatorisch, aansturen van chefs), hoefde er minder aanpassingen gedaan worden om de rapportages structureel te kunnen genereren. Vaak wordt de applicatie aangegrepen om een organisatorisch probleem te kunnen omzeilen.

Overstap naar virtueel
Bij veel MKB bedrijven draaien applicaties (en database) nog op fysieke servers. Als een moederbord het begeeft faalt de server en de applicatie. Hoewel het verplaatsen van software van een vaste server naar een gevirtualiseerde server zeker niet altijd een appeltje-eitje is (http://goo.gl/jRynh) , maakt het wel de weg vrij om de applicatie te zijner tijd te verplaatsen naar een datacenter. Kijk in hoeverre de servers zijn afgeschreven, of wellicht dat de servers ook te gebruiken zijn voor virtualisering.

Toen applicaties werden aangeschaft en ingezet, waren er wellicht minder mogelijkheden om deze applicaties te verbinden met andere applicaties. Vaak zie je dat bij het volwassen worden van applicaties er ook veel gedaan wordt aan integratie mogelijkheden. Omdat deze er in het begin niet waren zijn deze waarschijnlijk nooit ingezet en is hier omheen gewerkt of is er maatwerk voor gemaakt. Het gebruiken van Application Programming Interfaces (API), bijvoorbeeld in de vorm van (platform onafhankelijke) webservices, kan het rationalisatie proces enorm versnellen en eenvoudiger maken. Er kan toegewerkt worden om de oorspronkelijke software meer als standaard te gebruiken. Ik zie vaak dat bedrijven maatwerk laten bouwen op standaard software. Dit heeft drie grote nadelen:

1)    Er wordt betaald voor de licenties en er wordt betaald voor het maatwerk inclusief onderhoud.
2)    Door het maatwerk is het upgrade proces van de standaard software duur en moeizaam geworden waardoor er slechts traag van nieuwe functionaliteit gebruik gemaakt kan worden terwijl er in feite wel voor die ontwikkeling wordt betaald
3)    Standaard software wordt doorontwikkeld. Dit zit het maatwerk steeds meer in de weg en de architectuur van de software sluit steeds slechter aan op het maatwerk

Standaardisatie is bijna een vereiste voor cloud computing. Om te kunnen profiteren van drastische kostenverlagingen lijkt rationaliseren dus onvermijdelijk.

Rationalisatie is strategie. Strategie werkt alleen als het op het hoogste niveau gedragen wordt en tot op het laagste niveau wordt uitgevoerd. Rationalisatie zal dus pas effectief uitgevoerd kunnen worden als de directie erachter staat en niet alleen in naam, maar ook in daad. Rationaliseren leidt tot pittige trajecten welke doorzettingskracht en focus vragen, tel hierbij de weerstand tegen verandering op en de financiën die nodig zijn en dan is de rol van sterk leiderschap noodzakelijk.

Rationaliseren is niet alleen een IT aangelegenheid
Zoals ik eerder in dit artikel aangaf leidt rationaliseren van applicaties ook tot rationaliseren van processen. Hoeveel procent van de processen wordt standaard uitgevoerd, en hoeveel procent heeft uitzonderingen? Een goede indicatie van standaard werk is de hoeveelheid parate kennis die een medewerker nodig heeft om zijn werk te kunnen doen. Hoe meer opgebouwde parate kennis iemand nodig heeft, hoe minder standaard het proces blijkbaar is. Dit leidt tot langere inwerktijden, meer afhankelijkheden en daardoor hogere salarissen. Door te sturen op de standaard, zoveel mogelijk afscheid te nemen van uitzonderingen en het bevorderen van uniformiteit (mensen nemen dezelfde beslissingen op gelijke situaties) worden processen gerationaliseerd wat leidt tot betere aansluiting op de cloud.

Om inzicht te krijgen in de latente rationaliseringsbehoefte van de organisatie stel ik voor om antwoord te vinden op een aantal vragen:

- Hoeveel parate kennis is nodig om het primaire productieproces uit te voeren? (standaardisatie)
- Worden processen door verschillende mensen met gelijke functies hetzelfde uitgevoerd? (uniformiteit)
- Versterkt aanwezige software en automatisering de productiviteit?
- Wordt het standaard proces en de uitzonderingen door dezelfde mensen uitgevoerd?
- Is integratie van IT en hoe werk wordt uitgevoerd met de beschikbare applicaties vaak een onderwerp op de agenda van vergaderingen?

Als de vragen leiden tot lange antwoorden is dit een serieuze indicatie dat rationaliseren van het applicatie landschap en processen zinvol is en geld kan opleveren. Deze vragen zijn minder interessant als het primaire productieproces per definitie ad hoc is of uit veel R&D bestaat.

De business case van applicatie rationalisatie
Volgens mij is het moeilijk om een directie te overtuigen rationalisatie prioriteit te geven. De business case is namelijk niet heel gemakkelijk te maken. Je moet immers geld uitgeven zonder dat je er iets voor koopt. Omdat ik eerder al schreef over verborgen kosten kun je dus ook niet snel een ROI berekenen. Daarnaast vereist rationalisatie denkwerk en inspanning van de organisatie. Het niet rationaliseren van het applicatie landschap en het bijkomende verzuim op applicatielandschap governance kan gezien worden als een technologie schuld (Technical debt, aardige blog op http://goo.gl/IKFpH ). Kosten van veranderingen, onderhoud en integratie worden steeds hoger door eerder gemaakte keuzes. Om dit tastbaar te maken heb ik hier een kleine anekdote die het principe duidelijk maakt. Op mijn afdeling staat een vaatwasser. Mensen worden geacht zelf hun vaat in de vaatwasser te doen. Een aantal keer heb ik expres mijn kopje niet in maar op de vaatwasser gezet. Zonder uitzondering zorgde dit ervoor dat voor het eind van de middag de vaatwasser vol stond met kopjes en borden. Hiermee bedoel ik dat als je uitzonderingen toelaat dit alleen maar meer uitzonderingen aantrekt. Bij de vaatwasser is dit nog wel te overzien, maar bij organisaties kunnen deze kosten enorm zijn. Beginnen met rationalisatie is in het begin dus vooral inlossen op een opgebouwde technologie schuld en dat maakt een business case minder aantrekkelijk om mee te beginnen. Vergelijk het met hoe overheid met de pensioenproblemen omgaat. Die worden steeds maar vooruit geschoven.

Conclusie
De kracht uit de cloud en daarmee de drastische kosten besparing, schaalbaarheid, elasticiteit en mogelijkheid van het nieuwe werken ontstaan dus als er goede aansluiting is op de mogelijkheden van cloud computing en die worden dus bereikt met rationaliseren van applicaties en processen.

De cloud lost niet de IT problemen en hoge kosten op. Pas als er een rationaliseringsgraad bereikt is ontstaat er aansluiting op drastische besparingen en andere voordelen van cloud computing. Voorbeelden hiervan beschrijf ik in een vervolg artikel.

Cloud Computing: Adopt or Die!

Bij veel organisaties loop ik tegen weerstand aan als het gaat om cloud computing. Ook in de reacties op cloud artikelen lees ik dat veel collega’s in het vak denken dat cloud computing wel over waait. Of dat het oude wijn in nieuwe zakken is, of dat cloud computing een commercieel buzz woord is, een hype. Vaak lijkt die weerstand functie afhankelijk en zijn bijvoorbeeld de ceo en de cfo wel enthousiast wanneer het over cloud computing gaat.
Maar laten we de zaak eens omdraaien en samen onderzoeken wat de cloud zou kunnen betekenen voor bepaalde branches, of dit nu de it-branche is of heel andere branche. Ik neem een - in mijn ogen - realistische insteek met techniek die nu voorhanden is.

De vraag die we moeten stellen is: Zou een nieuw op te starten bedrijf in onze bedrijfstak opgezet kunnen worden met gebruik van cloud diensten? Zou dat leiden tot een besparing op bijvoorbeeld it en personeelskosten?

Neem bijvoorbeeld een adviesbureau. Het bureau is zojuist opgezet en doet zijn crm zo standaard mogelijk in Salesforce.com. De financiële administratie gaat via Exact en hrm wordt ook door middel van een SaaS afgenomen. Voor documenten, email, agenda en virtueel vergaderen worden Google Apps gebruikt en bij bedrijfsmiddelen zoals smartphone, laptop, tablet et cetera wordt BYOD toegepast, ofwel Bring Your Own Device. Ze kiezen voor T-Mobile en zetten hierbij T-Mobile Family in zodat ze onderling gratis bellen. Met projecten gaan ze voor BaseCampHQ en voor het delen intern van kennis en voor gebruik van Social Media zetten ze Yammer in. De website is opgedeeld in een statisch deel wat gehost wordt met AWS CloudFront en dynamische content via Blogger, YouTube, Twitter, et cetera. Hiermee ben je volgens mij redelijk compleet en voor wat overblijft, is vast wel een cloud oplossing te vinden.

Is dit mogelijk? Zeker wel. Is het schaalbaar? Absoluut, personeelsgroei of krimp brengt variabele kosten met zich mee die meegroeien (of krimpen) met het bedrijf. Qua kantoor kun je ook slank blijven en wat je vooral nodig hebt is een goede internetverbinding; het liefst dubbel uitgevoerd.

Natuurlijk bestaat een adviesbureau bij de kwaliteit en kunde van diens adviseurs, maar door deze bedrijfslenigheid en moderne manier van werken zullen ze niet alleen concurrerend zijn op gebied van prijs, maar zelfs op aantrekkelijkheid als werkgever. Flexibel werken, output gestuurd in plaats van vast te maken uren op vaste tijden. Daarbij het gebruik van devices die bij jou passen voor samenwerken op een niet hiërarchische manier.

Kunnen andere bedrijfstakken ook zo lenig opgezet worden? Bijvoorbeeld een software ontwikkelaar, een uitgever, een advocatenkantoor, een aannemer, een uitzendbureau, een webshop, een reclamebureau of een makelaar? Ik denk het wel. Met een beetje fantasie kun je je wellicht voorstellen dat veel bedrijfsvormen op een kosteneffectieve, schaalbare manier bezig kunnen zijn op een uiterst concurrerende en wellicht bedreigende manier. Risico’s zijn er ook zoals vendor lock-in, omvallen van een dienstverlener en gegevens beveiliging. Dit is een risico dat voor veel bedrijven nu ook al geldt en gewoon geïnventariseerd kan worden.

Als jouw soort bedrijf dus als 'cloud only' zou kunnen bestaan is dit dus een serieuze bedreiging waar je iets mee moet. Een cloud only bedrijf heeft minder vaste kosten, is minder gebonden aan plaats en grootte en heeft veel minder overhead dan een traditioneel bedrijf en zal dus altijd goedkoper zijn en sneller in kunnen spelen op verandering en heeft qua automatisering meer snelheid. Als de business case er is zal die concurrent er komen. En als je om je heen kijkt zie je dat alle grote partijen op it-gebied vol inzetten op de cloud, denk hierbij aan Microsoft (Azure, Office365), Google (Google Apps, Gmail), Apple (iCloud), Amazon (AWS), Salesforce.com (inclusief Force.com) en ga zo maar door.

En nu komt natuurlijk de vraag, wat kan jouw organisatie doen om kosten te besparen en flexibeler te worden? Je zit immers met een huidig serverpark, legacy applicaties, meer data dan je lief is, eigen mail servers, werkplekken, een groot kantoor en een IT afdeling die echt nodig is om alles draaiend te houden in een applicatie landschap dat zich echt niet leent voor een eenvoudige migratie naar de cloud. Om van de cloud te profiteren moet er dus eerst flink geïnvesteerd worden in bedrijfsverandering, migraties en onderzoek. En vergeet de exit strategie niet. Naar de cloud klinkt dan helemaal niet zo interessant en de transitie vergt een behoorlijke investering.

Maar de potentiële dreiging van een nieuwe dynamische organisatie in jouw branche is aanwezig. De organisatie zal vroeg of laat dus uitgedaagd worden. Koppen zullen rollen en de kaarten worden opnieuw geschud. Natuurlijk wil je er niet in geloven, maar laten we eens wat bedrijfstakken onder de loep nemen zoals de videotheek, boekenwinkels, muziekwinkels en dergelijke. Ze verdwijnen in een rap tempo door initiatieven zoals Amazon, iTunes, Netflix en dergelijke. Het is naïef om te denken dat jouw branche niet vatbaar is. Zelfs banken nemen de aankomende veranderingen serieus en tien jaar geleden stond de digitale fotocamera nog in kinderschoenen, nu is de analoge camera een niche markt. Kijk eens hoe de reus Nokia in zeer korte tijd geslonken is door de opkomst van smartphones. Dit komt door het internet en wordt enorm gestuwd door cloud computing en bedrijven gebouwd op en voor de cloud.

Mijn conclusie is duidelijk, hoe pittig het pad ook moge zijn; adopt or die.

Dit artikel is ook gepubliceerd in de Computable : http://goo.gl/cfGUp