Soeverein, wat is dat?

Eigenlijk is dat niet zo relevant. Er is namelijk niemand die verwacht dat u zelf een soevereine cloud bouwt. Want in de puurste vorm koopt u zelf hardware, zoekt u Open Source software uit die op bijna alle hardware kan draaien. Bouwt u infrastructuur. Verbind dat met meerdere ISP's aan het internet waarna u daarop de benodigde applicaties draaien. En dit is alsnog behoorlijk plat geslagen :).

En alle leveranciers duikelen over elkaar heen om vooral het woord soeverein in hun marketing te gebruiken. En daarmee hint ik naar de onzin die AWS, Microsoft en Google verkopen. Daar proberen ze het te verschuiven naar vinkjes in hun cloud waarmee je "controle" hebt over de data. Dan doen ze zelfs met Europese bewoners... Amerikanen die in Europa wonen, geen Europese burgers dus!!!. En ik ben iemand die steeds door die onzin heen prikt. En dan word ik benaderd door een van de drie (uit fatsoen geen naam) zodat hun jurist uit kan leggen wat ze bedoelen. Als een jurist moet uitleggen hoe je product in elkaar zit, dan ben ik er klaar mee. Waarom u niet?

Wat zijn de uitdagingen?:

• Wie kan er bij uw data?
• Waar staat het?
• Is data te herstellen?
• Is de applicatie waar de data in hoort beschikbaar?

Het komt neer op:

• Beschikbaarheid
• Integriteit
• Vertrouwelijkheid

Inderdaad, BIV..

Terug naar soeverein. Het doel is dat u inderdaad controle hebt over uw data, maar niet met een vinkje. U moet een aantal vragen aan uw leverancier stellen om te weten of het OK is. En als er vragen tussen staan die u niet begrijpt, of even niet ziet waarom dat belangrijk is (wil de tekst ook niet te lang maken), zet het even in een reactie, dan geef ik een toelichting. Als het allemaal abracadabra is, dan moet u niet de persoon zijn die de leverancier kiest. En doe geen aannames. Want daar is wat mee: https://www.linkedin.com/pulse/aannames-en-ict-wat-daarmee-het-erg-hoe-voorkom-je-dat-ronald-otto/

De vragen

Als eerste de keten:

• Is het bedrijf 100% Europees?
• Zijn de subverwerkers (wie zijn dat?) ook 100% Europees?
• Hebben de subverwerkers ook subverwerkers? (wordt snel vergeten) en is die ook 100% Europees?
• Zit er ergens burgers in de keten die niet Europees zijn?

Back-ups:

• Wie maakt de back-ups?
• Wie is er verantwoordelijk voor?
• Hoelang worden deze bewaard?
• Hoeveel versies zijn er?
• Waar worden deze bewaard?
• Is er een air-gapped back-up mogelijk?
• Hoelang duurt het herstel (ongeveer)?
• Hoe fijnmazig is het herstel? (1 bestand of moet gelijk uw hele bedrijf een dag terug in de tijd?)

Continuïteit:

• Is er een verzekering tegen aansprakelijkheid? Maakt uw leverancier een fout bij een andere klant, dan moet dat niet gelijk tot faillissement leiden.
• Is er een medewerker, software pakket of leverancier waar de continuïteit van afhankelijk is?
• Wat gebeurt er als er een datacenter uitvalt?
• Wat werkt er nog wel en wat niet?
• Hoeveel tijd werken dingen niet?
• Hoeveel data bent u kwijt?
• Zijn er policies voor privacy, veiligheid, sensible use, werkplekken en beheer?
• Die Mag u vast wel inzien. Zo niet, waarom niet?

Strategisch:

• Is IPv6 standaard meegeleverd (dus niet IPv6 ready, maar gewoon werkend)? (het zegt iets over hoe op de zaak de leverancier zit)
• Is er een Open Source first strategie? (betere ondersteuning, meer controle)
• Als een softwaresubcription of licentie verloopt, blijft de software dan werken?
• Doet de leverancier dingen voor een beter internet? Software bouwen, peering, IPv6?

Contact:

• Kunt u koffie komen drinken?
• Hoe is de ondersteuning geregeld? (neem niet aan dat u mag bellen voor alle problemen)
• Wat kost dat? Die ondersteuning?

Kunt u nog weg?

De leveranciers doen er alles aan om u te binden. Een enkele plug-in in een applicatie kan ervoor zorgen dat u muurvast zit. Daarom zie je een soort van twee kampen. De ene heeft een API gebaseerd op een open standaard en de ander verplicht je om plug-ins te installeren. U wilt een API of koppeling met een open standaard.

Maar hoe weet u of u goed zit?

Dat is best simpel. Stel de volgende vraag: Kan ik alle data gebruiken en bewerken middels een API? Is die API publiek? Mag ik de documentatie? En met publiek bedoel ik, kan ik er vanaf het internet bij, indien nodig. Dus een handige tool die je moet installeren in Outlook is dus een no-go. Dan MOET u namelijk Outlook gebruiken om die tool te kunnen gebruiken. En Outlook werkt dan alleen maar weer echt lekker met spullen van Microsoft. Zie hoe makkelijk dat mis gaat?

Nooit concessies doen

Dat is lastig, kost in het begin meer tijd. Spaart later een hoop tijd uit en bovendien geld alleen is dat niet altijd direct zichtbaar. En dan is er nog de volgende valkuil. De oude rotten in het vak kennen vast nog die boekhouder die een Excel document had vol met VB scripts. Daar draaide het hele bedrijf op. Niemand durfde dat document aan te raken en die boekhouder was koning. Datzelfde gebeurt nu weer met automations of low code. Een medewerker kan legio coole flows bouwen voor bedrijfsprocessen. De oplossing waar die flow in is gebouwd kan nooit meer weg of het ombouwen kost meer dan u lief is. Die medewerker had dat nooit moeten bouwen. Het moet een veel structurelere oplossing zijn. Net als dat die Excel sheet nu in een boekhoudpakket zit, moeten die flows ook een andere plek krijgen.

Programmeurs worden vervangen

Wellicht begrijpt u nu ook waarom bepaalde bedrijven zo sturen op AI. AI gaat programmeurs vervangen.. tuurlijk willen ze dat. En als u het niet door hebt, gebeurt dat ook maar dat maakt het nog geen goed idee.

Medewerkers zijn allemaal lekker complexe dingen even snel aan het bouwen tegen lage kosten (afhankelijk van hoe handig die medewerker is natuurlijk). De rekening komt nadat u niet meer weg kunt. Zeg ik nu dat u maatwerk software moet laten bouwen? Mja, ik zou opletten met SaaS (Software as a Service). Als u software niet zelf kunt draaien, gaat de prijs omhoog wanneer u niet meer weg kunt. En er zijn uitzonderingen, maar niet veel. Maatwerksoftware past bij uw bedrijfsproces, en kan aangepast worden als uw bedrijfsproces verandert.

Dit is alweer veel te veel tekst voor een blogje, dus hier stopt het :-) Ik hoop dat het enigszins inzicht geeft in het probleem en de valkuilen.

Met het bovenstaande in gedachten wil ik toch even meegeven dat de bedrijven waar ik dit toegepast heb tot nu toe in de basis niets hoefden te veranderen om mee te gaan met de volgende situaties:

• Toen de AVG om de hoek kwam. 0 subverwerkers was toch een goed idee :-)
• NIS2. Keten verantwoordelijkheid. Een korte keten is een goed idee.
• Met ISO27001 certificeringen
• Nu duidelijk is dat een Europese cloud een goed idee is.

En dat we er geen last van hebben, hebben we te danken aan een privacy first strategie. Daarover schrijf ik hier: https://www.linkedin.com/pulse/hoe-slim-een-cloud-first-strategie-ronald-otto/

De klanten van bedrijven met een dergelijke insteek hebben vanzelfsprekend dezelfde voordelen.

Vragen? Stel ze gerust.