Cloud, de toverdoos van informatievoorziening?

Door: Ben van der Veen

In deze blog ga ik in op een thema dat veelal vraagstukken oplevert binnen organisaties: het concept Cloud … de toverdoos van ICT?

Om te starten is het nuttig en raadzaam om een aantal grondconcepten, afkortingen en termen te benoemen van en rondom Cloud. Dit met de reden dat in mijn constateringen tot nu toe is gebleken dat deze begrippen, termen en concepten niet helder zijn bij een ieder waarmee de dialoog wordt gevoerd. Ook zal ik de Engelse vorm voor deze termen hanteren, aangezien deze vorm in toekomstige stukken terug zal komen en een Nederlandse vertaling afbreuk doet aan de inspanning en te behalen winst.

Waarbij ik direct aangeef dat ik hier niet de ISO-normen opnieuw ga schrijven. Cloud omvat uiteraard meer begrippen, maar in deze blog houd ik het beperkt. Ik pik er een aantal uit die zullen bijdragen aan mijn bewering: 

Cloud vraagstukken raken de organisatie in haar geheel en niet alleen het perspectief ICT.

Een samenstelling van het begrippenkader in de context van dit schrijven: 

  • Cloud deployment modellen: Public, Private, Community en Hybrid
  • Cloud servicemodellen: IaaS, PaaS, Saas en Serverless.
  • Cloud termen: Cloud Solutions (bouwblokken), TCO, ROI, Security, Compliancy, Pricing, Capex, Opex
  • Cloud kenmerken: High Availabilty, Fault Tolerance, Scalability, Elasticity, Disaster Recovery, Agility

De beschrijving zal ik hanteren uit de ISO al zouden de beschrijvingen uit de NIST mogelijk een betere zijn. Echter de NIST lijkt meer de security scope te bevatten en de ISO lijkt meer algemeen. Maar beide bronnen zijn interessant en naar mijn weten congruent.

Cloud Deployment modellen

Public Cloud

Mogelijke (voor alle afnemers gelijke [generieke]) Cloud diensten (services) beschikbaar gesteld door een externe dienstverlener (Cloud serviceprovider) voor elke klant waarbij de middelen volledig worden beheerd door deze externe dienstverlener. 

Private Cloud

Cloudimplementatiemodel waarbij Cloud diensten uitsluitend voor één klant en resources worden beheerd door die ene klant. Oftewel de klantorganisatie heeft de volledige controle over gegevens, beveiliging en kwaliteit van de dienst.  Deze vorm kan in een locatie van een overheidsorganisatie worden vormgegeven, maar dat kan ook bij een leverancier. In het laatste geval wordt de oplossing niet gedeeld met andere klanten.

Community Cloud

Cloudimplementatiemodel waarbij Cloud diensten exclusief worden ondersteund en gedeeld door een specifieke verzameling klanten die gedeelde kenmerken, vereisten en een gemeenschappelijk belang hebben. Denk hierbij aan een OverheidsCloud voor wat betreft een taakstelling, missie, beveiligingseisen, beleid-, en compliance eisen. Een community Cloud kan eigendom zijn van, beheerd en geëxploiteerd worden door een of meer van de organisaties in de gemeenschap, een derde partij of een combinatie daarvan, en het kan zowel op als buiten het terrein bestaan.

Hybride Cloud

Cloudimplementatiemodel waarbij er een combinatie is van een Public Cloud en Private Cloud. De betrokken implementaties blijven unieke entiteiten, maar zijn met elkaar verbonden door gebruik te maken van gedeelde geschikte technologie in interoperabiliteit en maakt data- en applicatie verplaats- en overdraagbaarheid mogelijk.

Cloud Service modellen

On Premise

De IT benaming voor lokaal geïnstalleerde automatiseringssoftware. Ook wel traditionele IT genoemd.

Infrastructure-as-a-Service

Cloudmogelijkheden worden weergegeven en geleverd aan de klant van het type infrastructuur. Denk aan servers, storage, netwerk, virtualisatie.

Platform-as-a-Service

Cloudfunctionaliteit wordt geboden aan de klant van de Cloud dienst van het type platformfunctionaliteit. Denk aan Databasemanagement- en Operating systemen.

Software-as-a-Service

Cloudfunctionaliteit wordt geboden aan de klant van de Cloud dienst van het type toepassingsmogelijkheden. Denk aan volledig vormgegeven applicatie functionaliteit. Voorbeelden: HRM systemen, LinkedIn, Teams, Zoom, Office 365, ….

Serverless

Je hebt geen operationele middelen in eigen beheer. Je host als het ware alleen een stuk functionaliteit of functie. Deze oplossing zal zelf en afzonderlijk gedeployed, gemanaged en beheerd worden.

De figuur hieronder toont de diverse Cloud Deployment modellen:

Shared Responsibility

Cloud gaat ook over gedeelde verantwoordelijkheid. Wanneer een organisatie de keuze maakt voor het SaaS model wordt veelal de aanname gemaakt dat “alles” uit handen wordt genomen. Niets is minder waar. Bij o.a. SaaS ben jezelf nog verantwoordelijk voor o.a. apparatuur, accounts, informatie, data & identiteitsborging.

De toverdoos…

Al het voorgaande draagt bij aan inzichten die leiden tot de gemaakte bewering. In Cloud wordt gesproken over diensten. Diensten zijn nooit louter en alleen vormgegeven vanuit het perspectief ICT of Informatievoorziening. De organisatie gaat een (langdurige) verbinding aan met een externe leverancier (c.q. Cloud Service Provider) voor een gekozen oplossing. Deze keuze maakt de oirganisatie samen met de ondersteunende diensten (dus ook ICT). Kortom zoals de architectuurmethode GEA aangeeft, raakt het vraagstuk meerdere perspectieven en daarmee de organisatie ook op dieperliggende (recursieve) niveaus. Immers een dergelijke vormgeving of oplossingscontour als cloud kan vanuit meerdere divisies en organisatieniveaus worden hergebruikt.

In het verleden kocht een organisatie functionaliteit in, veelal in de vorm van een applicatie en/of software. Denk o.a. aan de XIS-en, HRM oplossingen, FMIS-systemen, EPD’s, ECD’s en o.a. ERP’s. Voordat er gekozen wordt voor een oplossing doorloopt de organisatie processen zoals het opstellen van Pakket van Eisen, uitvoeren van Business Impact Assessments, doorlopen van selectieprocedures en uitzetten van aanbestedingen.

Waar deze oplossingen uiteindelijk worden geïmplementeerd voldeden deze aan de inrichting van de traditionele ICT en dus aan de On Premise vorm. De implementatie verliep vaak projectmatig en het beheer werd dan vaak in huis verricht. Een vanzelfsprekendheid. 

Specifieke productkennis en Functioneel Beheer zijn in vele organisaties onderbelicht. Vaak doet de organisatie (of ICT) het er even bij. Hierdoor zijn er bevindingen ontstaan dat het anders of beter zou kunnen. Door een Cloud model te kiezen denkt men alle problematiek als gevolg van een gebrek aan kennis op het gebied van specifieke productkennis en functioneel beheer te tackelen. 

Ook voor hosting (onderbrengen van beheer bij een derde partij) was deze problematiek al aan de orde. Het gele boekje “Outsourcing Performance” met de presentatie van de onderzoeksresultaten van Giarte geeft dit onder andere weer. Serviceorganisaties werden buiten de deur gezet en men sprak in diverse dialecten met beheerorganisaties die het bestaan niet wisten van de postcode waarin jij je als organisatie je begaf. Laat staan dat men het besef had wat de organisatie als doelstellingen had en waar men naartoe wilde.

Kortom het concept “outsouring” is niks nieuws en bestaat al jaren. Het heeft alleen nu een extra synoniem gekregen met de naam Cloud. Het verschil lijkt hem te zitten in het feit dat organisaties meer grip willen hebben op maatwerk. En dat applicaties en software tot nu toe veelal niet de meest recente versie bevatten, waardoor beloofde functionaliteit vanuit de leveranciers en sales niet gebruikt kan worden. Tot ergernis van de organisatie.

Er zijn nu leveranciers die functionaliteiten als bouwblokken kunnen leveren. Op de gehele infrastructuur (techniek), die benodigd is om deze functionaliteit beschikbaar te stellen aan het proces van de organisatie, is ingespeeld. Dit betekent mede dat de Capex impact verschuift naar meer Opex. Het is net de telefoon die je aanschaft bij je abonnement. Je koopt hem zelf, maar zo voelt het niet… en mocht je er een ander OS op willen dan moet je hem uit de lockdown verkrijgen en vervalt de garantie en alle aansprakelijkheid.

De Cloud Service Providers denken ook mee in TCO-berekeningen en ROI inzichten. Dit door dashboards of rekenmodellen aan te bieden, waardoor de organisatie direct inzichten krijgt in het ongrijpbare vooruitzicht van prijzen en licenties. Dit alles om de organisatie zoveel mogelijk mee te nemen in dat wat komen gaat. 

Maar heeft Cloud geen toegevoegde waarde? Jazeker wel. Denk aan de Cloud kenmerken als High Availabilty, Fault Tolerance, Scalability, Elasticity, Disaster Recovery en Agility. Waarbij organisaties vaak behoorlijke investeringen vooraf (Capex en Opex) dienen uit te voeren op eigen On Premise omgevingen willen ze dezelfde Quality of Service kunnen behalen.

Bewustwording

Organisaties dienen bewust te overwegen wanneer men met het Cloud concept bezig gaat. En hoe bepaalde transities tot uitvoering kunnen worden gebracht en in welke vorm. Bijvoorbeeld omdat men een applicatie X wil migreren van On Premise naar de Hybride Cloud. Of dat men voor een specifiek domein in zee gaat met een SaaS vormgegeven oplossing. 

Per oplossingscontour dient vastgesteld te worden of PaaS het geschikte model is of dat het een andere variant moet worden. Dit met de juiste onderbouwing. Denk ook aan organisatie compliance met o.a. dataclassificaties en beveiligingsbeleid.

Mocht er maatwerk binnen de organisatie nodig zijn en of de ambitie organisatie specifieke functies verbeteren betreft, dan zijn de beschikbare functionele bouwblokken mogelijk interessant. Waar men vroeger frameworks had (ingelijste functionaliteit in software met een coherente taak, concreet doel en waarde) hebben we nu de bouwblokken. En daaromheen hebben de leveranciers selfservice portalen neergezet, wat deze functionaliteit makkelijk toegankelijk maakt. En wanneer je de bouwblokken gebruikt dan zorgt de externe dienstverlener voor alle beheerprocessen en kost het de eigen organisatie geen FTE. Mede bestaat de mogelijkheid om het “pay-per-use” of verbruik direct inzichtelijk te maken door de diversie dashboards die al aanwezig zijn bij Cloud Service Providers. Het is namelijk in hun belang en dat van hun klanten dat er direct inzicht is in kosten. De governance voor de baten dient op een andere manier te worden gefaciliteerd.

Kortom geen andere managers meer naast de tafel van de Informatiemanager met de vraag om effe snel te helpen omdat er een issue is, of toch wel omdat de contracten van deze ingekochte functionaliteit nog steeds op de kostenplaats van ICT rusten? 

Ook dient de inkooporganisatie bewust te zijn van re-transitie voorwaarden. Afrist- en/of afritsbaarheid zit hem vaak niet in de techniek, maar zit hem meer in de functionele duurzame verbondenheid die de organisatie is aangegaan met een leverancier. En dus vaak contractueel en afgesproken SLA’s en DAP’s. Ook de mate van compliance is daarin meegenomen. En ja of dit nu voor een SaaS, PaaS of IaaS model geldt of voor een applicatie of stuk software?

In Architectuur is veelal aandacht voor de “snijvlakken”. Wanneer je Cloud inbrengt in je organisatie dan heb je mijns inziens raakvlakken en gespreksstof met diverse perspectieven. En deze gesprekken dienen integraal gevoerd te worden. Dit eveneens met de leveranciers. Cloud gaat ook meer uit van een partnermodel dan de traditionele klant-leverancier constructie.

Dus ja het is de toverdoos van ICT … Cloud oogt technisch…. en de ICT bepaalt de techniek en technologie Maar ze denken alleen maar mee heb ik altijd begrepen. Toch? Doordat de procesautomatisering doorzet, processen veelal ondersteund worden door functionaliteit en dat functionaliteit vormgegeven wordt door techniek (en niet meer handmatig) lijkt het onderwerp al snel een ICT-feestje te zijn, maar of het daarmee ook de toverdoos is van ICT vind ik wat paradoxaal.

In welke vraagstukken kun je Cloud tegenkomen

  • Wet & Regelgeving (Compliance) (o.a. Safe Harbor)
  • Security & Privacy
  • Inkoop & Contractbeheer
  • Functionele domein
  • RCA (Risicomanagement)
  • Transities van functionaliteit van het ene model naar het andere
  • Uitfasering producten vanuit Life Cycle Management constateringen
  • Enforce Control vs Enable Support
  • Innovatie

Toepassing van de methode GEA op het vraagstuk ‘hoe en in welke mate gaan wij gebruikmaken van Cloudservices’ verhoogt de kans op bereiken wat ermee is beoogd aanzienlijk. Dit komt omdat enerzijds wordt overgegaan tot een grondige vraagstukanalyse in termen van aanleidingen/oorzaken, mate van urgentie, mate van belang, op voorhand bekende risico’s en implicaties. Hiermee wordt al de eerste basis gelegd voor de te maken keuzes in de mogelijke cloudservices. Anderzijds wordt met toepassing van de methode GEA goed inzichtelijk gemaakt wat de impact is op c.q. benodigde veranderinitiatieven zijn voor zowel het ICT-domein als alle andere bestuurlijke invalshoeken. Denk hierbij aan Klant, Processen, Producten/Diensten, Medewerkers, Marketing, Leveranciers et cetera. In GEA wordt enterprisearchitectuur ook ‘sturen op samenhang’ genoemd.

Enterprisearchitectuur is mensenwerk. Het succes van sturen op samenhang staat of valt niet alleen met de juiste competenties van de architect. Het is ook een kwestie van gunning en vooral vertrouwen en vooral integraal samenwerken.