Beheersing van Informatievoorziening uit de Wolk

Beheersing van Informatievoorziening uit de wolk

Door Lex Scholten en Frank van Outvorst

Inleiding

Door toenemende complexiteit van bedrijfsprocessen, globalisering, ketensamenwerking, maar ook door de groeiende klantverwachtingen, worden organisaties steeds meer afhankelijk van informatie. Het thema “regie op informatievoorziening” wordt daarmee in steeds meer organisaties een belangrijk onderwerp. Hoe borg je de toegankelijkheid en juistheid van de informatie? En welke ITmiddelen en –services heb je nodig en wat moet je doen om die in de juiste kwaliteit en tegen een passende prijs te kunnen gebruiken. Hoewel regie op informatievoorziening een relatief nieuw vakgebied is, zijn inmiddels de nodige stappen in de ontwikkeling van dit vakgebied gezet. Veel organisaties hebben dit onderwerp geïdentificeerd en geïntegreerd in hun procesbesturing. Bij een groot deel van die organisaties is het procesframework Business Informatie Services Library (BISL®) een waardevol hulpmiddel gebleken bij die inrichting. BISL® heeft zich inmiddels gevestigd als de industriestandaard voor het vormgeven van de regie op de informatievoorziening (Business Informatie Management).

Naast de bedrijfsprocessen wordt ook de wereld van IT steeds complexer. Nieuwe technieken komen steeds sneller beschikbaar voor een breed publiek en maken het lastig om overzicht te houden over wat er allemaal kan. En moet. Een van de sterk opkomende nieuwe technieken voor distributie van IT-middelen en –diensten is bekend onderde naam cloud. De stormachtige opkomst van deze techniek maakt dat veel organisaties het gevoel hebben dat ze achter de feiten aanlopen en dat de regie, die ze met allerlei verbetertrajecten op basis van BISL® zo zorgvuldig hadden opgebouwd, ze weer ontglipt. In dit artikel gaan we in op de vraag waar dat gevoel vandaan komt en reiken we handvatten aan –in lijn met het BISL® framework- om voldoende regie op de informatievoorziening te houden.

Voordelen en beperkingen aan cloud?

De specifieke kenmerken van cloud hebben stuk voor stuk betrekking op flexibiliteit. Dit levert de volgende voordelen op:

  • makkelijker toegankelijk;
  • goedkoper;
  • robuuster;
  • proven technology, brede ervaring van andere gebruikers beschikbaar.

Maar er zijn ook beperkingen:

  • Er is geen sprake van een oplossing op maat. Het is een one size fits all. Dat betekent dat een zekere aanpassing van de gebruiker gevraagd wordt.
  • Het voortbrengingsproces is niet duidelijk, de gebruiker heeft geen controle over de manier waarop de kwaliteit wordt geborgd.
  • Er is minder controle op de resource. Het is niet duidelijk waar de schijf staat, waar de gegevens worden opgeslagen en of dat wel veilig gebeurt.
  • Certificering van cloud-leveranciers staat (nog) in de kinderschoenen – het is niet duidelijk met wat voor leverancier je in zee gaat en hoe die zijn kwaliteit en robuustheid borgt.
  • De cloud-dienstverlening gebeurt in losse componenten die meestal niet op elkaar afgestemd zijn als ze van verschillende leveranciers afkomstig zijn. En als ze wel op elkaar zijn afgestemd, ontneemt dat de begeerde flexibiliteit.
  • Het is niet altijd duidelijk of de keuze voor cloud ook weer teruggedraaid kan worden. Zijn de gegevens die in de cloud-applicatie zijn opgeslagen, eenvoudig over te dragen naar een andere applicatie, als die keuze ooit wordt gemaakt? En is het mogelijk om de gegevens in de oude applicatie te verwijderen?

Deze beperkingen leiden tot risico’s voor de bedrijfsvoering. Soms zijn dat risico’s die in de bestaande informatievoorziening ook al spelen. Het kan ook gaan om risico’s waar de organisatie tot nu toe niet bekend mee was.

  • gegevens uit cloud-toepassingen schieten inhoudelijk net tekort als aanleverend systeem voor vervolgstappen in proces. Dit deed zich natuurlijk ook voor in informatievoorziening zonder cloud, maar dan was het vaak mogelijk om een aanpassing in een applicatie te doen, waarmee het probleem werd opgelost. Dat is lastiger als cloud-oplossingen gebruikt worden.
  • Cloud-toepassing wijzigt waardoor interfaces niet meer werken. Ook dit kon zich voordoen in “eigen” systemen, maar dan was het altijd mogelijk om de wijziging uit te stellen tot de interface adequaat was aangepast.
  • Bij faillissement van de cloud-leverancier zijn diens productspecificaties en testrapporten niet meer beschikbaar. Dat maakt, dat de criteria waarop een vervangende dienst gekozen dient te worden niet beschikbaar zijn. En dat geldt zelfs als die vervangende dienst niet meer uit de cloud komt – het is niet duidelijk wat de specificaties voor een maatwerkoplossing moeten zijn.
  • Weinig cloud-leveranciers leveren diensten om te migreren vanuit hun cloud-oplossing naar een andere oplossing, als dat in de toekomst nodig of gewenst zou zijn. Daarmee ontstaat (vaak onbewust) een vorm van vendor-lock in.

Cloud-gebruik binnen een organisatie bestaat uit allerlei losse componenten die onderling wel met elkaar moeten kunnen samen werken. Daarmee kan cloud gezien worden als een vorm van Service Oriented Architecture (SOA). Belangrijk bij SOA (en dus ook bij cloud):

  • Een afsprakenset voor de samenwerking van de services of componenten. (Vergelijkbaar met de architectuur in de klassieke omgeving.)
  • Een mechanisme om naleving van die afsprakenset te bewaken.
  • Een mechanisme voor facilitering van SOA-gedrag

Hoewel de definitie van cloud anders doet vermoeden is een keuze voor cloud (of SOA) dus niet vrijblijvend! Cloud is makkelijk en flexibel, maar wel binnen kaders! Deze kaders staan niet expliciet genoemd in de definitie, maar ze zijn er wel degelijk. En wat nog meer impact heeft: de kaders zijn vaak niet zichtbaar of worden pas zichtbaar als de keuze al onomkeerbaar is gemaakt. Veel mensen en organisaties beleven de kaders van cloud niet of zien het belang hiervan niet in.

Aan de andere kant wordt een keuze voor cloud vaak beleefd als het uit handen geven van controle en om die reden niet gemaakt. Men heeft het idee dat men minder invloed heeft op de functionaliteit van een SaaS oplossing of op de beveiliging van een platform in de cloud. Dat is niet geheel terecht. Vaak is bij een conventionele oplossing sprake van dezelfde beperkingen, bijvoorbeeld vanwege budgettaire redenen. En vaak is diezelfde gewenste functionaliteit of het gewenste beveiligingsniveau wel verkrijgbaar in de cloud, maar duurder. Toch wordt in het conventionele geval het afzien van de gewenste functionaliteit gevoeld als een bewust gemaakte keuze, terwijl een cloud-oplossing wordt beleefd als “take-it-or-leave-it”, alsof er geen keuze is. Dit geldt ook voor het meegaan met nieuwe versies van de uit de cloud afgenomen functionaliteiten.

Wat betekent cloud voor de regie op IV?

Het is altijd van belang om regie te voeren op informatievoorziening. Om behoeften in kaart te brengen, risico’s en voor- en nadelen af te wegen en vervolgens keuzes te maken. Zelf te maken. Daar verandert op zich niets aan als de keuze voor cloud-oplossingen wordt gemaakt. Gebruik van cloud-voorzieningen maakt bepaalde keuzes wel belangrijker. Daardoor verandert op die punten de noodzaak voor regie en wordt die noodzaak wellicht ook meer manifest. Hoewel veel leveranciers een (gratis) proefperiode (vaak met beperkte functionaliteit) aanbieden, blijft het overgaan op een cloud-oplossing lijken op kopen van kleding uit een postordercatalogus. Echt passen, voordat onomkeerbare keuzes worden gemaakt, kan niet. Het is goedkoop en makkelijk te bestellen. Maar als men overgaat en tot de conclusie komt dat de oplossing toch niet past, kunnen de consequenties fors zijn.

Deze manier van kiezen is wezenlijk anders dan wat men gewend is. Van een proces van opstellen van specificaties, langs een traject van ontwerp en bouw en voortdurend toetsen en testen, is geen sprake. De opzet lijkt eerder gericht op “trial and error” – probeer een oplossing en als het niet past, dan kiezen we iets anders. Het is echter niet vanzelfsprekend dat keuzes omkeerbaar zijn. Er is expliciete aandacht nodig voor het scenario dat er op een keuze teruggekomen moet worden. Wat zijn de risico’s als zo’n scenario zich voordoet? En wat als pas na verloop van tijd behoefte is om de keuze te herzien? Wat zijn de consequenties dan en accepteren we die consequenties nu al. Want nu maken we de keuze.

Door de intense relatie van cloud-oplossingen met Internet krijgt het begrip “kwaliteitsborging” een nieuwe betekenis. Anderen, die het product al gebruiken, delen in reviews hun ervaringen en overtuigen daarmee voor of tegen een oplossing. Dat gebeurt op verschillende kanalen, die lang niet altijd objectief zijn. Soms staat een review op een site die (al dan niet zichtbaar) is gelieerd aan de leverancier. Of aan zijn concurrent. Maar ook als het een onpartijdig review is, is alles wat erin staat dan wel relevant voor ons? Spelen er bij ons zaken die anderen niet (kunnen) weten en waar men dus geen aandacht voor heeft gehad? Het kunnen kiezen en beoordelen van een review wordt een competentie op zich.

Integratie met de bestaande Informatievoorziening vergt speciale aandacht. Hoe makkelijk een cloud-oplossing past binnen het landschap van applicaties, dat in gebruik is en dat in gebruik moet blijven, is iets wat niet altijd uit reviews valt te beoordelen. Dat geldt zeker als dat landschap belangrijke maatwerk-componenten bevat. Er is dan ook behoefte aan inzicht in wat vanuit het bestaande landschap de eisen zijn die gehanteerd moeten worden bij de keuze voor een cloud-oplossing en wat de consequenties zijn als die eisen losgelaten worden.

Veel meer nog dan bij conventionele pakketten is er sprake van snelle verspreiding van ideeën. Het is van belang om de “rages en hypes” te onderscheiden van de “revoluties”. En het is belangrijk om te weten welke “bagage” een oplossing met zich meebrengt. Komen er niet allerlei componenten mee die we niet op onze eigen infrastructuur willen hebben?

De keuze van een leverancier gaat ook over aspecten die minder inhoudelijk zijn. Hoe stabiel is deze leverancier, kan hij zijn dienst ook over drie jaar nog wel aanbieden, weet ik waar ik hem kan vinden als het nodig is? Is hij betrouwbaar, levert hij goede nazorg? Bij een “echt” bedrijf hebben we middelen om dit te onderzoeken. Voor cloud-diensten ligt dat, door de laagdrempelige toegang, een stuk ingewikkelder. Het lijkt of “iedereen kan aanbieden” en het is moeilijk overzicht te krijgen. Om hier structuur is te krijgen is er een behoefte aan een vorm van certificering van cloud-leveranciers. Een kwaliteitsstempel dat aangeeft dat een leverancier voldoet aan bepaalde eisen. Maar wie mag zo’n stempel zetten? Hoe onderscheiden we stempels als “wij van WC-eend adviseren WC-eend”.

Door de laagdrempelige en brede toegang is het niet meer vanzelfsprekend dat formele goedkeuringsprocedures worden gevolgd. Een gebruiker of een afdeling kan kiezen om gebruik te maken van een cloud-dienst (zeker als het een gratis dienst is), zonder dat centraal en uniform getoetst wordt of deze dienst voldoet aan de eisen die de organisatie stelt. Is dat erg en zo ja, hoe sturen we dat bij? Is het voldoende om de gebruikers een bewustwordingsprogramma te laten volgen? Dwingt dit de organisatie om technische maatregelen te nemen die dit soort keuzes bij gebruikers weghalen en wat zijn daar de consequenties van? Is het werkbaar als medewerkers niet meer op Internet kunnen of bestanden kunnen downloaden? Of is het beter om de sturing op dit punt los te laten? Op bedrijfsniveau zal in elk geval inzicht (moeten) ontstaan wat er ongeveer speelt op dit terrein en als dat uit de hand dreigt te lopen zijn regie-ingrepen van hogerhand noodzakelijk.

Het voorgaande leidt tot een lijst van zaken waar expliciet aandacht voor nodig is bij de keuze voor een cloud-oplossing:

  1. Een overall beeld van de totale informatievoorziening binnen de eigen organisatie. En als onderdeel daarvan: meer en beter inzicht in de risico’s van deze IV;
  2. Een helder beeld van welke functionaliteiten nodig zijn en hoe deze functionaliteiten
    onderling samenhangen en interacteren;
  3. Gekoppeld aan deze overall architectuur een helder beeld van alle continuïteitsrisico’s
    (tijdens en na afloop van contract), compliance factoren, behoefte aan exclusiviteit op
    infra/software/datagebied;
  4. In het overall IV-plaatje ook heel scherp de niet-functionele eisen en voorwaarden aangeven, zoals schaalbaarheid, beveiliging, financiën, kwaliteit in zin van kosten en baten: dus eisen stellen aan invulling van de functionaliteiten;
  5. Overall beeld van de cloud-wereld is nodig om alle aanbod, kwaliteitsverschillen en alle andere verschillen te kunnen overzien (vergelijkbaar krijgen om keuzes te kunnen maken);
  6. Ook is enig inzicht in de wijze waarop de cloud-leverancier zijn diensten levert noodzakelijk om de risico’s in te kunnen schatten;
  7. Op basis van eisen en keuzes door middel van een contractset invulling geven en alle andere randvoorwaarden invullen.

De genoemde BIM-onderwerpen zijn natuurlijk niet nieuw. Ook bij de traditionele IV spelen dergelijke onderwerpen. Maar doordat in de traditionele IV bij specifieke ontwikkeltrajecten of pakketimplementaties nog veel rework mogelijk is, zijn deze onderwerpen vaak te weinig benadrukt. In de cloud-situatie dienen alle onderwerpen aandacht te krijgen. Nieuwe onderwerpen daarbij zijn de onderwerpen 5 en 6. Dit betekent dat hiervoor specifieke deskundigheid opgebouwd moet worden om dit in te kunnen vullen.

Conclusies

De introductie van cloud-diensten behoeft regie. Daar is op zich niets nieuws aan – de behoefte aan regie op de integrale informatievoorziening is inmiddels een geaccepteerd gegeven. We hebben echter ook gezien dat het gebruik van cloud-voorzieningen die regie functie op een aantal punten wezenlijk verandert en nieuwe behoeften veroorzaakt:

  • Er is een behoefte om diensten en leveranciers objectief te kunnen beoordelen, voordat een keuze wordt gemaakt. Daarbij onderkennen we twee behoeftes:
    • Normering van leveranciers
    • Normering van geleverde diensten
  • Het is nodig om te zorgen dat acquisitie gestructureerd blijft verlopen en dat de juiste rollen bij besluitvorming zijn betrokken en hun rol kunnen spelen. Dit speelt zowel op organisatie- en afdelingsniveau als op het niveau van de individuele eindgebruiker. Hierdoor is het nodig om sommige BIM-competenties, die voorheen centraal konden worden belegd, breder te introduceren. Dit kan weer leiden tot nieuwe competenties voor BIM of zelfs BIM rollen.

Vanuit de business-optiek is het van belang om de juiste afwegingen niet uit het oog te verliezen bij het maken van keuzes. Dan is de vraag meer of het bedrijfsproces ruimte en behoefte heeft aan cloud-diensten en hoe deze diensten onderling en in de reeds bestaande informatievoorziening geïntegreerd kunnen worden.

Deel via:
LinkedInTwitterFacebookGoogle+WhatsAppEmail