Devops, meer of minder secure?

We hadden het eerder over ‘agile development’, waarvan het voordeel is dat organisaties daarmee sneller kunnen inspelen op de vragen van de omgeving. De belangrijkste prestatie indicator van agile development is ‘feature velocity’: de snelheid waarmee functionaliteit aangepast kan worden. Hoe korter de tijd tussen een nieuw idee en het testen er van in de praktijk, hoe minder verspilling er ontstaat.

Agile development is een competentie van een organisatie. Eerder beargumenteerde ik dat cloud computing daarvoor een essentiële component is. Maar hoe zit dat nu precies?

Dat is waar DevOps om de hoek komt kijken. DevOps is uiteraard een hype woord dat voor van alles wordt gebruikt, maar zoals bij veel hype woorden zit er wel een harde kern in.

Ontwikkeling en beheer

Traditioneel zijn ontwikkeling en beheer gescheiden werelden. Het zijn andere processen, andere mensen, andere afdelingen, en ga zo maar door. Ontwikkelaars houden van verandering, ze worden afgerekend op de hoeveelheid nieuwe dingen die ze produceren. Beheerders daarentegen zien elke wijziging als een bedreiging, want die kan het systeem dat net een beetje lekker begon te draaien weer om zeep helpen.

In de praktijk leidt deze scheiding van ontwikkeling en beheer er toe dat mooie nieuwe features maanden op implementatie moeten wachten vanwege een of andere suffe reden. Of het nu de levertijd van een server is, een security analyse of simpelweg gebrek aan handjes om de gewenste wijzigingen in te kloppen, het duurt altijd veel langer dan je denkt. Een of andere met stroop ingesmeerde ophaalbrug tussen ontwikkelaars en beheer belet elke nuttige vooruitgang, zo lijkt het.

Taakverdeling

DevOps stelt voor dit proces anders te zien. In plaats van beheerders op het kritische pad naar productie te laten zitten, en ze af te rekenen op incidenten veranderen we de taakverdeling. Ontwikkelaars krijgen de taak om code in productie te brengen, maar worden ook afgerekend op het aantal incidenten dat daarvan het gevolg is. Beheerders stappen uit de delivery straat, maar krijgen de taak om die delivery straat optimaal in te richten zodat ontwikkelaars daadwerkelijk code in productie kunnen brengen.

Het lijkt eng. Bij DevOps kunnen praktijken horen als testen in productie, productieservers niet patchen, en het overslaan van change advisory board bijeenkomsten voor de meeste functionele wijzigingen. Voor old-school auditors zijn dit rode vlaggen die meteen leiden tot bevindingen van de hoogste categorie.

DevOps kan veiliger zijn

Maar wie een goede risico analyse maakt van de werkelijke bedreigingen ziet dat, met de juiste automatisering die door DevOps mogelijk gemaakt wordt, DevOps juist veel veiliger kan zijn.

Bij DevOps worden handmatige goedkeuringsstappen vervangen door automatische. Functionele en performance wijzigingen worden vaak getest door ze in productie op een klein percentage van de gebruikers los te laten, en onmiddellijk weer terug te draaien bij ongeschiktheid. Productieservers die niet meer actueel zijn worden binnen een paar minuten vervangen door modernere.

Vanuit de risico’s bezien zijn deze praktijken eigenlijk superieur.

Devops kan dus leiden tot betere procesbeheersing, en daarmee tot meer veiligheid.

 

Dit artikel is geplaatst in het Tijdschrift IT Management, een uitgave van ICT Media.

Dick Berlijn meets Max Verstappen

Boek bespreking

Titel: Cyberrisico als kans
Ondertitel: strategisch cyberrisicomanagement in het informatietijdperk
Auteur: Roel van Rijsewijk

Te koop bij: diverse webshops.

Dit boek is ten eerste een introductie in de digitale revolutie en wat nu eigenlijk cyberrisico is.

Cyberrisico’s, en risico’s van cloud computing in het algemeen krijgen inmiddels hype status. Denk alleen maar aan Snowden, het ongebreideld datagraaien door overheden, en vele hacks en data breaches die het nieuws halen.

De digitale revolutie, die er eerst nog leuk en behulpzaam uitzag, begint zijn donkere kanten te laten zien. En de dialoog er over gaat vaak in termen van good guys, bad guys en strijd. Niet verwonderlijk dat het voorwoord is geschreven door Dick Berlijn, Generaal b.d., voormalig Commandant der Strijdkrachten.

In dit boek wordt deze digitale revolutie, en diens risico’s, vanuit een historisch perspectief uiteengezet. De vele voorbeelden kende ik vrijwel allen, want ik ben op dit gebied werkzaam als cursusleider en adviseur. Maar ik zie ze zelden zo helder uitgelegd, en in voldoende detail uitgewerkt om de werkelijke risico’s te leren inzien. Ik vind alleen
al de voorbeelden eigenlijk verplichte kennis voor tenminste elke professionele ITer.

Maar wat is nu het antwoord op die risico’s? Volgens de auteur is zwaarder beveiligen en verder dichttimmeren niet de oplossing. En het is ook niet goed te verkopen. Security verkopen via het aanjagen van angst heeft zijn langste tijd gehad.

Roel van Rijsewijk’s centrale stelling is dat het hanteren van cyberrisico’s eigenlijk de essentiële keerzijde is van de digitale revolutie. Open communicatie tussen bedrijven onderling en met consumenten is de kern van die ontwikkeling. De risico’s daarvan horen er bij, en moeten adequaat worden behandeld. Wie met die revolutie wil mee racen, moet ook goede remmen hebben.

En daarmee laat de auteur de omkering in de titel zien. Het zijn de goede remmen die de auto in staat stellen om harder te rijden. Max Verstappen wint geen races omdat zijn auto sneller is, maar omdat hij beter kan remmen.

De weg naar het beter hanteren van cyberrisico’s is door dat voortdurend te koppelen aan de voordelen die het aangaan van die risico’s kan opleveren. Dat maakt dan ook de business case.

En dan kom ik op mijn belangrijkste punt van kritiek op het boek. Het smaakt naar meer. Hoe doen we deze koppeling nu in detail in een specifieke case? Hoe verloopt de afweging naar precies genoeg controle nu in de praktijk? Daar zou ik graag meer uitwerking en voorbeelden van zien.

Agile development vraagt om moderne digitale infrastructuren

Agile development is helemaal de mode tegenwoordig. Waarom is dat, en wat voor digitale infrastructuren heb je daarvoor nodig?

Vroeger werd business software vooral geschreven om bestaande bedrijfsprocessen te automatiseren. Die werden middels software weliswaar wel wat veranderd, maar in de kern waren de processen niet anders. We denken daarbij dan aan boekhoud systemen, roosterplanning, ‘customer relationship management’ enzovoort.

Tegenwoordig zien we dat software niet alleen de bedrijfsprocessen automatiseert, maar deel gaat uitmaken van het product, of zelfs het product is. En die software is dan bovendien ook nog vaak een on-line dienst. Denk aan de slimme kamerthermostaat. Ook in financiële dienstverlening is software meer en meer het hoofdonderdeel van het product: denk aan online bankieren. En bij social media van Facebook tot relatieplanet is software de dienst.

De dans

Elk product verandert de wereld die het gebruikt, dat geldt ook voor software. Maar een veranderende wereld verandert ook de producten die we kunnen of willen gebruiken. Er ontstaat een soort dans tussen vraag en aanbod. Gaan we vaker buiten de deur ontbijten omdat er meer mogelijkheden voor zijn, of ontstaan er meer ontbijttentjes omdat we vaker buiten de deur gaan eten? Net als in een dans is het niet altijd eenvoudig te zeggen wie door wie geleid wordt.

Nu software het product is gaat het ook meedoen aan die dans, en dan wordt het belangrijk om sneller aan te passen aan de danspartner.

Hoe sneller, hoe beter.

Dat verklaart de noodzaak voor agile development. Tussen wens en realisatie moet geen twee jaar staan, maar twee weken, en liefst nog minder.

Wat voor digitale infrastructuren zijn daarvoor nodig?

Het belangrijkste doel van digitale infrastructuren is het beschikbaar maken van applicatie functionaliteit. De kwaliteit daarvan wordt bijvoorbeeld uitgedrukt in het aantal ondersteunde gebruikers. Bijvoorbeeld: 10.000 gelijktijdige gebruikers op 10 locaties met een responstijd van minder dan 4 seconden.

Maar met agile development komt daar een nieuw doel bij: ‘feature velocity’. Dat is de snelheid waarmee nieuwe features kunnen worden uitgerold. De tijd tussen het bedenken van een feature en het testen van de zinvolheid bij echte gebruikers moet korter zijn dan de tijd waarin de omgeving verandert. In een dans wil je anticiperen op je partner, niet op diens tenen staan.

De digitale infrastructuur moet daarin geen flessenhals zijn. Dat vraagt een aantal dingen van die digitale infrastructuur zoals automatisch testen, snel op- en afschalen van capaciteit, en zo weinig mogelijk handmatig ingrijpen. Alleen zo kan de doorlooptijd van een wijziging worden verkort.

Kortom: agile development vraagt om cloud computing. Immers: essentiële karakteristieken van cloud computing zijn onder meer snelle, elastische en zelfbedieningsuitrol van middelen. Dat is wat nodig is voor agile development.

En dan gaat de dans door. Want als dat mogelijk is zijn er weer nieuwe dingen mogelijk. Betere security bijvoorbeeld. Als je sneller kunt reageren op functionele vragen, kun je ook sneller reageren op security problemen.

 

Dit artikel verscheen eerder in Tijdschrift IT Management, een uitgave van ICT Media.

Is IT security slechter of beter in de cloud?

Is IT security nu beter of slechter in de cloud? Dat is een vraag die zo goed als garant staat voor een pittige scholenstrijd. En daar doe ik fijn aan mee.

Het basis sentiment is bekend: “Wij gaan onze data niet in de cloud zetten, nooit niet”.

Dat klinkt als een emotie, en daar helpt geen enkele redenering tegen. Maar voor wie openstaat voor een rationele risico afweging, is de vraag: waarom eigenlijk, wat is eigenlijk de redenering, en snijdt die hout?

Een van de belangrijkste zorgen is: ‘Ik weet niet waar mijn data staat’.

Waarom wil je eigenlijk weten waar je data staat? Dat lijkt uit te gaan van de veronderstelling dat locatie hetzelfde is als controle. Met andere woorden: als het in mijn rekencentrum staat, kunnen we bepalen wat er met de data gebeurt. En: als het niet in mijn rekencentrum staat, heb ik er geen controle over.

Maar tegenwoordig is dat niet meer helemaal waar. Stel je eens voor dat jouw data sterk versleuteld op een Amerikaanse of Russische server staat. Wie kan er dan bij, en wie anders dan jij bepaalt dat?

Gatenkaas

En omgekeerd, denk je nu werkelijk dat in een connected wereld de muren van je data center ook maar enige bescherming van betekenis opleveren? Goede data bescherming vergt meer dan een stapeltje stenen. Als je daaraan twijfelt, denk dan maar eens aan DigiNotar of aan Target supermarkten, wier on-premisses IT een complete gatenkaas bleek.

Kortom, in de moderne IT wereld heeft locatie weinig met controle te maken.

Belangrijker dan de fysieke muren zijn de logische muren.

NSA

Hoe gaan logische muren ons tegen bijvoorbeeld de NSA (national security agency) beschermen? Die hacked bedrijven vooral via verouderde software versies, slordigheden van beheerders, en gebrek aan belemmeringen als men eenmaal ‘binnen’ is.

Hoe is dat anders in de cloud?  Een van de belangrijkste kenmerken van cloud computing is ‘self-service provisioning’: de afnemer bepaalt zelf wel wanneer zijn bestelling geleverd wordt. En een van de voordelen daarvan voor de afnemers is dat logische muren automatisch, sneller reproduceerbaar en grootschaliger kunnen worden uitgerold. Dan krijgt elke virtuele machine en container zijn eigen firewall. Dit heet hypersegregation en is een stuk effectiever te beheren dan een centrale firewall met duizenden regels er in.

Hoe dan wel?

Self-service provisioning maakt ook continuous deployment mogelijk. Dat maakt dat het nog maar een paar uur of minder kost om nieuwe features uit te rollen, in plaats van een paar maanden. Dat kan je ook inzetten voor security features en patches en daarmee neemt je kwetsbaarheid enorm af. Stel je voor dat je betrouwbaar binnen een paar uur al je applicaties en servers up to date kan hebben. Hoe reduceert dat je risico’s?

Dit zijn maar een paar voorbeelden van security in de cloud. Het kernbegrip daarbij is “Cloud Security Automation”. Want de kenmerken van cloud computing creëren niet alleen nieuwe risico’s, maar helpen ook om ze op te lossen.

Dit artikel verscheen eerder in Tijdschrift IT Management, een uitgave van ICT Media.

Aan de slag met betere cloud security? Kijk naar mijn online of classroom workshop.

Service management in de cloud

Wat zijn de uitdagingen die IT service management in de cloud met zich meebrengt? Wie doet eigenlijk wat? Wat is het ‘operating model’? Dat zijn voorbeelden van vragen die met de introductie van het cloud denken nadrukkelijker worden gesteld.

Laatst deed ik in een in-company cloud security training met de groep een oefening die men erg verhelderend vond.

We namen als voorbeeld het beheer van een enterprise content management (ECM) systeem. Het probleem van een ECM is niet dat het een complex systeem is. Dat is het namelijk niet, het is eigenlijk vaak gewoon een Drupal website.

Het probleem is dat er erg veel mensen bij betrokken zijn omdat de content uit veel verschillende hoeken komt, veel mensen er iets van willen vinden, en omdat men vrij zeker wil zijn dat het spul blijft werken.

Hoe ga je hier in een cloud context mee om?

Wat we in de oefening deden was de verschillende onderdelen van de technologie stack uit elkaar trekken, en daar dan vragen bij stellen. In de technologie stack zit bijvoorbeeld de hypervisor, en nog veel meer verschillende software componenten. Wie is daarvoor verantwoordelijk (in het engels: ‘who controls’)? En wie is verantwoordelijk voor de stylesheets op de webpagina?

Dan blijkt het beheer van zo’n website toch wel iets meer om handen te hebben, en begin je beter te begrijpen waarom je dat toch maar niet aan het neefje van de directeur moet overlaten.

Om het simpel te houden beperkten we de klus in de oefening tot een stuk of acht taken.

Elk van die taken staat dan op een apart kaartje. Die verdelen we over twee partijen die we (service)provider en cloud consumer (of afnemer) noemen. En vervolgens kijken we of die verdeling een beetje logisch is.

Zo is het voor het beheer van de hypervisor wel zo handig als je ook verantwoordelijk bent voor het beheer van de hardware, maar andersom geldt dat dan weer niet. En als de ‘look and feel’ van de website je verantwoordelijkheid is, zal je ook veel te zeggen willen hebben over de stylesheets.

Het maakt niet zoveel uit of de kaartjes vooral bij de provider of vooral bij de consumer terecht komen, als ze maar logisch bij elkaar horen.

Wat heeft dit met cloud computing te maken? Het blijkt dat bij het afnemen van software as a service (SaaS) de meeste kaartje bij de provider komen te liggen, terwijl bij het afnemen van infrastructure as a service (IaaS) de meeste kaartjes bij de consumer terecht komen.

Op deze manier kan de afnemer dus beter zien welke taken die zelf te doen heeft in het service management, en waar het service management bezig zal moeten met het besturen van een externe provider.

Tenslotte is er ook een relatie met security. Elk van de taken bestuurt een stuk techniek. En wie de techniek bestuurd is ook verantwoordelijk voor de beveiliging er van. Voorbeeldje: wiens probleem is het gevaar van cross-site scripting?

 

Deze column verscheen eerder in TITM magazine

Welke stappen zijn nodig voor snelle en veilige cloud adoptie

In veel bedrijven wordt inmiddels fors druk uitgeoefend om tot cloud adoptie te komen. De directie ziet kostenbesparingen en uitstel van investeringen, de business ziet meer agility.

Maar om daar veilig te komen zijn nog wel een paar stappen nodig.

Ik noem er hier een paar.

  1. Ten eerste: wat is dat cloud gebeuren, wat zijn de voordelen, en hoe bereiken we die. Dat cloud geld bespaart is heel wel mogelijk, maar de andere voordelen zijn meestal belangrijker.
  2. Ten tweede: een goed begrip van de risico’s. Natuurlijk is het een nieuwe wereld om derden delen van je IT te laten beheren, en dat vergt een aantal nieuwe technieken. Maar het grootste risico is misschien wel om onvoldoende rendement uit je cloud kansen te halen.
  3. Ten derde: goede besluitvorming over cloud beslissingen en investeringen. Dat moet snel genoeg gaan, en niet worden verlamt door oeverloze discussies. Maar ongeleide projectielen moeten ook tijdig op de radar komen te staan.
  4. Ten vierde: effectief met cloud omgaan vergt goede architectuur keuzes.  Niet alleen de cloud oplossing moet verstandig in elkaar zitten, maar de koppeling met de bestaande IT ook. Dat gaat iets verder dan een VPN.

En zo zijn er nog een paar stappen.

Ook het idee dat het allemaal wel wat sneller en veiliger kan? Kom naar mijn aanstaande cloud security training, of bel me voor een nadere afspraak. Er is meer mogelijk dan op mijn kalender past.

Cloud computing noopt ons tot een andere manier van denken over security

Vroeger konden we ons bij in-huis IT nog permitteren om de security er achteraf aan te plakken. Daar hadden we onze eigen mensen voor.

Dat kan nu niet meer.

Cloud en ander vormen van uitbesteden maken dat we veel nauwkeuriger en vroeger om moeten gaan met security.

Hier is het typische verhaal van een organisatie die volwassen wordt in het beheersen van IT risico’s.

In stap 1 worden applicaties ingezet zonder over de beveiliging na te denken. Dat ging vroeger verbazingwekkend lang goed. Maar dat was vroeger. Dan ontstaan de eerste incidenten, of blijkt compliance plotseling van belang.

Dan gaan we over naar stap 2: timmer alles dicht. Dat blijkt best lastig te zijn. Databases die voor alle ontwikkelaars open staan moeten ineens beveiligd worden. Alleen, als je zo maar wat access control regels op de servers zet kan dat de productie flink verstoren. Dan moeten er dus dure ‘data access monitor’ tools aangeschaft worden, met de bijbehorende consultants. Bovendien is het dweilen met de kraan open, want elke dag produceren de ontwikkelaars weer nieuwe lekken.

Met een beetje geluk komt dan het inzicht dat het probleem meer stroomopwaarts moet worden aangepakt.

In stap 3 wordt elke project en elke change vooraf beoordeeld op een strikt normenkader voor beveiliging. Alle ‘controls’ moeten aanwezig zijn en worden afgetekend door de security officer. Dit is een taak waar IT architecten zich ook met veel genoegen op storten. Eindelijk weer een manier om die “wildgroei” in de business onder controle te krijgen.

Maar ook deze aanpak heeft zo zijn beperkingen. Kort samengevat zijn die: duur, traag en niet altijd gepast. In de techniek zijn de kosten van het laatste restje risico afdichting niet altijd in verhouding tot de mogelijke gevolgschade, of tot de effectiviteit van alternatieve inzet van middelen. Hoeveel sloten wil je op de voordeur als de achterdeur wijd open staat?

Dan komen er externe partijen (bijvoorbeeld cloud providers) die zich niet in alles aan je normenkader houden en ook andere manieren van werken hebben. En die zouden wel eens effectiever kunnen zijn.

Een voorbeeld: je normenkader kan zeggen dat er een patch proces voor operating systems in productie moet zijn. Maar in een secure devops omgeving wordt een verouderde server instance in productie niet gepatched, maar gewoon afgeschoten, waarna de load balancer vanzelf een vers gepatchte instance opstart.

En dan krijgen we stap 4, waarin we zien dat we risico gedreven moeten werken, in plaats van maatregel gedreven. En natuurlijk is dat best lastig, want nu moeten we gaan nadenken en overleggen, in plaats van lijstjes met best practices afvinken.

We moeten gaan bedenken of onze eigen wijze van werken beter is dan die van een externe partij, en of we het de moeite waard vinden om onze manier af te dwingen, terwijl een andere manier in die situatie misschien wel net zo goed is. Dan pas worden we ‘cloud ready’.

Deze column verscheen eerder in TITM magazine

Is private cloud een goede toekomst voor een datacenter vol servers?

Stel: je hebt een datacenter vol met servers. Is het dan een goed idee om daar een private cloud van te maken?

Eerst even de makkelijk weg: plak er een sticker op met ‘private cloud inside’ en je bent klaar. Je mag er om lachen, maar dit soort marketing cloud washing gebeurt echt.

Ik denk dat er wel verschil is tussen een datacenter en een private cloud, en dat private cloud ook voordelen kan hebben. Maar om de voordelen van private cloud te kunnen realiseren moeten de spullen wel voldoende flexibel inzetbaar zijn. Dat veronderstelt korte provisioning tijden. Voor productie servers hooguit dagen, en voor test en ontwikkeling hooguit uren. En wil je naar continuous integration en deployment toe, dan praten we over minuten.

Dat vergt nogal wat in tooling en procesbeheersing. Bovendien komt de governance ten aanzien van resource conflicten over business unit grenzen ook om de hoek kijken. Voor je het weet is dat een hoofdpijn dossier voor de CEO en CIO.

Maar laten we ook de vraag eens stellen waarom je eigenlijk een private cloud zou willen hebben in plaats van naar public cloud te gaan?

Sommigen zeggen dat een private cloud goedkoper is dan public cloud, onder andere wijzende naar een McKinsey rapport van een aantal jaren geleden. Dat liet zien dat een goed georganiseerd datacentrum met een stabiele workload goedkoper is dan een public IaaS provider.

Dat klopt ook wel met geluiden die ik uit de markt hoor van hosters en IaaS providers, en van grote gebruikers van IaaS. Je kan het zelf in principe wel goedkoper, maar er zitten nog wel een paar belangrijke aannames achter deze waarneming.

Het veronderstelt dat je een stabiele workload hebt voor een paar jaar, die dus niet groeit of krimpt en een beetje redelijk over de weken en maanden gemiddeld is. Het veronderstelt ook dat je een goed georganiseerd datacentrum hebt, en ik denk ook dat je je demand management stevig op orde moet hebben. Al deze zaken zijn voor het doorsnee rekencentrum niet heel erg waarschijnlijk in mijn waarneming.

Een andere reden die heel valide kan zijn is de zorg over security en compliance. Nu geef ik het je te doen om veiligheidsmaatregelen in je private cloud te implementeren die op hetzelfde niveau kunnen staan als die van grote providers, maar toezichthoudende instanties hebben vaak nog een mening die achterloopt bij de realiteit.

Private cloud kent, meer dan silo servers, dezelfde security uitdagingen als public cloud. Ze zijn in principe hanteerbaar, maar dat is wel specialisten werk. Het kan dus een goede reden zijn om beheer en eventueel eigendom van die private cloud uit te besteden aan specialisten.

Kortom: een goede private cloud heeft zijn nut, maar kost wel wat moeite. De vraag is hoeveel je daar zelf van wilt doen. Kijk dus of de inspanning voor een private cloud wel in balans is met de voordelen.

Deze column verscheen eerder in TITM magazine

Kijk naar cloud waarde, dan pas naar risico

De belangrijkste hobbel die bedrijven tegenkomen als het gaat om de adoptie van de cloud is niet de beveiliging. Natuurlijk is security belangrijk, en het is zeker waar dat cloud computing nieuwe risico’s met zich mee brengt, maar zo goed als alle risico’s kunnen worden afgedekt. Dat gebeurt niet altijd, en dan worden er dure fouten gemaakt.

Zo hoorde ik laatst van een Nederlands bedrijf dat in een weekend een ton kwijt was geraakt via een hack op hun IaaS-masteraccount. Voor de inbreker was het businessmodel goed: 100K machine uren omzetten in 20K bitcoins. Maar dit zijn slechts smeuïge details over ongelukken in de pionierfase.

De belangrijkste hobbel die ik zie is de onvoldoende breed gedragen visie op de gewenste voordelen van cloud computing. En zonder gezamenlijk beeld van die voordelen is een discussie over de risico’s bij voorbaat zinloos.
Een bekend misverstand is dat cloud computing goedkoper is. Dat kan zo zijn, maar het is een erg matige driver van de business case. It-kosten gaan als gevolg van cloud computing zelden omlaag. En als it-kosten als gevolg van cloud computing omlaag gaan, worden er meestal kansen gemist.

Het grootste deel van de levensduurkosten van een it-oplossing zit meestal in het begin: het implementatietraject. Een bestaand systeem ongewijzigd in de lucht houden is maar een beperkte kostenpost op het geheel. Puur rekenkundig is er daarom aan de laatste jaren van een systeem niet veel te besparen.

Maar wat door de business ook als hoge it-kosten worden gezien zijn de kosten van nieuwe it. Wat er voor de afnemers uitziet als een eenvoudige aanpassing of een simpel nieuw systeem, blijkt te vaak in de praktijk een lijdensweg van kostenoverschrijdingen. Dat is steeds minder goed uit te leggen, vooral omdat er meer en meer bruikbare alternatieven in de cloud beschikbaar komen.

Het werkelijk verwachte voordeel van cloud computing is dan niet verlaging van bestaande it-kosten, maar verlaging van de kosten van nieuwe it-oplossingen. Daar komt nieuwe business van. Hoe meer nieuwe business er komt, hoe meer nieuwe it er mag worden ingezet.

Stap één gaat dus over de gewenste voordelen. Elk voordeel vraagt zijn eigen strategie. De beste strategie voor lagere operationele it-kosten is vaak infrastructure as a service. De beste strategie voor sneller nieuwe it is meestal software as a service. Na deze keuze kunnen we het pas over risico’s hebben.

Lees het commentaar ook op de Computable site.

Is Big Data een hoop bagger?

Is Big Data een door de industrie aangezwengelde marketing hype om veel nieuwe spullen te verkopen? Jazeker, maar er is meer.

Het klassieke IT wereldbeeld is database centrisch. Alles moet in die ene database, en dat moet dan ook nog allemaal kloppen ook. Eerst modelleren, dan schema maken, dan een paar jaar programmeren en dan klaar is Kees.

Helaas laat de werkelijkheid zich niet altijd zo modelleren. Ja, misschien wel bij de stabiele kernbedrijfsprocessen zoals financiën en HR, ook al weten ze bij Defensie inmiddels wel beter.

Nee, nieuwe inzichten komen van nieuwe manieren om naar de data te kijken. Essentieel aan Big Data zijn daarom niet alleen de volumes, maar vooral de variëteit.

We kunnen de nieuwe trends niet zien met een oude bril op.

Vernieuwing komt daarom vaak van mensen die met spreadsheets aan de gang gaan en wat uitproberen.

Mijn vader reisde in de jaren zestig de product managers af van alle Europese landen waar Philips industriële weegschalen verkocht. Hij ging dan niet praten over de omzet en winst cijfers. Die hadden ze in Eindhoven al lang gecontroleerd en geconsolideerd. Daar hoefde hij niet voor van huis.

Waar hij naar op zoek ging bij de product managers waren de tabelletjes in de binnenzak of onder de bureaulegger. Daaraan kon hij zien hoe de betreffende manager zijn eigen visie had op hoe hij succes ging krijgen. (In KPI speak: de leading indicators, ipv lagging indicators).

Die gegevens gaven werkelijk nieuwe inzichten over wat de markt wilde, en dat leidde tot een beter resultaat.

Tegenwoordig hebben we veel meer data dan ooit. En in die bergen data zitten nieuwe inzichten verscholen, ook al is de data vaak bagger. Maar die komen er niet uit met een standaard data model, daarvoor moet je experimenteren met manieren om er naar te kijken.

Dat gaat met Excel beter dan met een ERP systeem. Maar de data is nu zo groot dat Excel niet meer voldoet. Daarom denk ik dat Big Data in de kern een ‘cloud native’ toepassing is. Voor goed gebruik van Big Data is een cloud oplossing daarom onontbeerlijk.

Meer weten over Big Data?  Kijk bijvoorbeeld naar de Big Data Foundation training op mijn website. Het plan is om aan het einde van de drie dagen in staat te zijn je eigen datasets in een cloud oplossing te draaien.

Meer weten over hoe IT werk veranderd? Kijk eens naar mijn artikel (in het engels) over digitaal leiderschap.