Wat een Cloud exit strategie inhoudt? Het SCAF? Ik praat je graag even bij.

We zijn met iets moois bezig binnen Salomon, al maanden, of eigenlijk kan ik (Bas) wel zeggen, al ruim 16 maanden (zo lang ben ik namelijk al weer werkzaam voor Salomon), maar dat is natuurlijk niet wat ik bedoel. Het gaat over Cloud, maar dat zal geen verrassing zijn.

Ok, vooruit, een heel klein tipje van de sluier…

Als onderdeel van onze bredere Roadmap propositie maken jullie binnenkort kennis met het Salomon Cloud Adoptie Framework, of SCAF afgekort.

En nee, bij ons geen dertien in een dozijn. Geen kloon van Microsoft, Amazon, Google of welke andere aanbieder dan ook. Dat kan anders, dat kan beter! Een unieke aanpak waarbij we samen aan de slag gaan om jou de juiste keuzes te laten maken.

Het SCAF is toepasbaar op zowel kleine(re) als grote organisaties en zoals jullie van ons gewend zijn opereren we volkomen vendor en merk onafhankelijk. We bieden een pragmatisch en getoetst model waarbij de techniek feilloos aansluit op de gestelde (bedrijfs) doelstellingen, wensen en eisen vanuit “de business”.

Later (nog veel) meer…

Dat is slechts het begin, gedurende 2020 hebben we nog een aantal zeer aangename verrassingen voor jullie in petto. Wij zijn super enthousiast en kunnen niet wachten om dit alles in de komende maanden uitgebreider met jullie te delen.

Cloud exit strategie

Een van de onderwerpen waar we als onderdeel van het SCAF aandacht aan besteden is een Cloud exit strategie.

Dat klinkt misschien vreemd. Waarom zou je een lange termijn relatie met een Cloud Service Provider aangaan terwijl je tegelijkertijd jezelf voorbereid op een eventueel afscheid? Je gaat immers altijd van het positieve uit.

Maar wat als je niet tevreden bent, het gras bij de buren groener is, of lijkt? De provider zich niet aan de gemaakte afspraken houdt of zonder opgaaf van reden bepaalde diensten stop zet of zelfs failliet gaat? Mogelijk is het een kosten overweging, valt de kwaliteit tegen, is er een verandering in IT/bedrijfsstrategie of speelt er misschien wel iets heel anders.

Je gaat er niet vanuit maar je moet er wel rekening mee houden. Het is niet meer dan realistisch om te denken dat er ooit een moment komt dat je (op z’n minst) een deel van je applicaties, data, systemen etc. ergens anders onder wil brengen. En mocht het zo ver komen, dan ben je blij dat je er vroegtijdig aandacht aan hebt besteed.

Waar kan of moet je zoal rekening mee houden, wat zijn de aandachtspunten? Hoewel de onderstaande lijst je een beeld geeft van waar te beginnen, is deze niet uitputtend. In veel gevallen zal het een kwestie zijn van de risico’s afwegen tegen de voordelen. Overigens is een dergelijk model toe te passen op bestaande en toekomstige Cloud omgevingen.

Punten van aandacht

1. Om te beginnen, werk georganiseerd en houdt het overzichtelijk. Breek het geheel op in kleine(re) stappen.
2. Inventariseren. Een belangrijke stap. Zorg ervoor dat je weet welke diensten op welke manier worden afgenomen, of afgenomen gaan worden. Hoe meer detail hoe beter. Bestaan er bijvoorbeeld afhankelijkheden tussen de verschillende componeten/systemen/applicaties etc? Kan het een zonder het ander? Maar ook, hoe vaak gebeurt het wel niet dat wordt “aangenomen” dat er xxx applicaties en/of systemen in gebruik zijn maar het er al snel 40% meer blijken te zijn? Inderdaad, te vaak.
3. PaaS en SaaS diensten zijn vaak erg specifiek en diep geworteld binnen de onderliggende infrastructuur. Je kunt ze daarom niet “zomaar” van het ene naar het andere platform verhuizen. Hoe generieker de aanpak hoe flexibeler de workload. Aan de andere kant leveren PaaS en SaaS diensten vaak wel de grootste en snelste winst. Afwegen geblazen.
4. Licenties. Het gebruik van bestaande (on-premises) licenties is in veel gevallen toegestaan. Echter, de regels en kleine lettertjes veranderen continue – zo ook gedurende de afgelopen weken.
5. In welk formaat is je data te exporteren of te downloaden? Niet alle formaten worden door alle platformen ondersteund. Zijn hier afspraken over te maken?
6. Om hoeveel data gaat het? Wanneer je “vertrekt”, je diensten opzegt, een provider failliet gaat, etc. heb je vaak beperkt de tijd om je data, systemen en dergelijke “weg” te halen. Praten we over petabytes aan data, honderden TB’s? Dan heb je aan 30 tot 60 dagen waarschijnlijk niet genoeg. Hoeveelheid data + beschikbare tijd + doorvoersnelheid = exporteer mogelijkheid. Data kan, zonder dat je het door hebt snel in omvang toenemen, zorg dat je dit monitort en dat je, wanneer mogelijk, weet wat de “voorwaarden” zijn.
7. Regels rondom het gebruik van Clouddiensten kunnen per provider verschillen (en tussentijds wijzigen). Gelukkig zijn de SLA’s en dergelijke vrij inzichtelijk. Zo kan het gebeuren dat je bij opzeggen van bepaalde diensten “in eens” niet meer over dezelfde “extra’s” kan beschikken als daarvoor.
8. Probeer een globale inschatting te maken van de kosten om van A naar B te komen. Maar ook, hoe lang het gaat duren, zodat je niet voor verrassingen komt te staan mocht het ooit zo ver komen.
9. Kom je vanuit een managed service provider situatie dan kan het zijn dat je te maken krijgt met afspraken rondom SLA’s richting je gebruiker organisatie(s). Mogelijk zijn er ook andere contracten of afspraken van toepassing.
10. Kies niet “zo maar” een alternatief of vervangende oplossing. De impact kan groot zijn – hoe is het gesteld met het huidige kennisniveau binnen je organisatie, is dat op orde/voldoende? Dit is het moment om (opnieuw) goed na te denken over je volgende stap. Je wil niet over twee jaar voor dezelfde uitdaging komen te staan.

Het bovenstaande is bedoelt om je een idee te geven, een startpunt (de lijst is minstens drie keer zo lang). Natuurlijk komt er meer bij kijken en staat er tegenover ieder punt van aandacht een overweging, mogelijk te nemen actie of alternatief. Iets waar we je graag bij helpen of ondersteunen, als onderdeel van ons SCAF of opzichzelfstaand.