Met de huidige politieke turbulentie en de effecten daarvan die meteen wereldwijd voelbaar zijn, beseffen veel bedrijven dat ze het zich niet kunnen veroorloven om vast te zitten aan de diensten van een enkele cloudaanbieder. Bovendien hebben financiële instellingen in Europa de wettelijke verplichting om aan te tonen dat ze hun contracten met serviceproviders voor kritieke functionaliteiten kunnen beëindigen.
Voorbereid zijn op een exit is een complexe aangelegenheid voor financiële instellingen en andere organisaties die gevoelige informatie in grote volumes verwerken. Bovendien wordt het nog ingewikkelder als je dat wilt doen zonder de continuïteit van de business te raken. Door het aanbieden van Cloud Exit as a Service (CEaaS) maakt Schuberg Philis deze dimensie van de digitale transformatie strategisch inzichtelijk en stressvrij.
Risicotolerantie en de kleine letters
Of een klant nu levenslang bij dezelfde aanbieder van een publieke cloud blijft of juist op een dag het contract wil beëindigen, onze CEaaS kijkt altijd naar de risicotolerantie van die klant. We beginnen met de vraag welke diensten essentieel zijn voor hun operationele continuïteit, waardecreatie en reputatie, en dan bepalen we welk risicoprofiel daarbij hoort. Deze aanpak past perfect bij hoe wij kijken naar alle andere dimensies van een organisatie: luisteren naar de IT-vragen en daar een antwoord op vinden waarvan de business beter wordt.
Als we hebben vastgesteld waar onze klanten zich goed bij voelen in een exitscenario, zorgen we ervoor dat ze alles krijgen wat ze nodig hebben voor een eventuele (of hypothetische) exit. We zien het als onze taak om onze klanten te begeleiden naar compliance. Nu de Europese Commissie in mei 2022 haar voorlopige goedkeuring heeft gegeven aan de Digital Operational Resilience Act (DORA), die waarschijnlijk begin 2023 in werking treedt, ontkomen banken en andere financiële organisaties in Europa er binnenkort niet meer aan om een exitplan voor te bereiden. Artikel 25.9 van DORA geeft aan dat financiële entiteiten exitstrategieën moeten invoeren om rekening te houden met risico’s die zich op het niveau van derde aanbieders van ICT-diensten kunnen voordoen. Tevens stelt het artikel dat deze exitstrategieën alomvattend, gedocumenteerd en in lijn met de criteria genoemd in Artikel 3a(2) moeten zijn, en dat ze voldoende getest en periodiek opnieuw beoordeeld moeten worden.
Naast het plannen van een exitstrategie lezen we ook altijd aandachtig de kleine lettertjes. Op basis van onze interpretatie daarvan geven we dan advies over welke actie er genomen kan worden. Een voorbeeld: een klant kan gebruikmaken van een publieke clouddienst van een Amerikaans bedrijf met hoofdkwartier in de VS en datacentra in de EU. Die klant kan zelfs bewust gekozen hebben voor een contract met datacentra in de EU, zodat de overeenkomst onder Europese regelgeving valt en de grote risico’s van een contract onder Amerikaanse wetgeving beperkt blijven. Maar omdat de cloudprovider een Amerikaans bedrijf blijft, is het risico nooit nul. Als onze klant er in zo’n scenario voor kiest om zo veel mogelijk risico te mijden, kunnen we een exit adviseren naar een datacentrum met een vestiging én eigendom die volledig binnen de EU vallen. Aan de andere kant, als de klant iets meer risico accepteert, dan zou het advies kunnen zijn om alle mission-critical processen te migreren naar een lokaal datacentrum, en voor minder belangrijke workloads nog steeds gebruik te maken van het brede palet aan beschikbare, betaalbare, innovatieve oplossingen van die Amerikaanse cloudprovider. Dat gezegd hebbende, stel dat een andere klant ervoor kiest om hun mission-critical activiteiten wel onder te brengen in de publieke cloud van een bedrijf met hoofdkwartier in de VS, dan zijn er nog altijd effectieve strategieën voor risicobeperking die wij kunnen aanbevelen.
Het strategiedocument
Een belangrijk onderdeel van onze CEaaS is een document waarin we de exit van de klant strategisch analyseren. Concreet betekent dit: het identificeren van verschillende redenen waarom de relatie met een cloudaanbieder beëindigd moet worden, met de bijbehorende planning en scope. Deze scenario’s kunnen variëren van een bedrijf dat zonder al te veel frictie afscheid kan nemen tot (aan het andere uiteinde) een versneld noodgedwongen vertrek. Een voorbeeld van de eerste situatie is een bedrijf dat over een periode van negen maanden overstapt naar een andere provider omdat die functionaliteit aanbiedt die hun huidige partner niet heeft. Een voorbeeld van de tweede situatie, al zal die zich niet snel voordoen, is een snelle exit die in een paar dagen uitgevoerd moet worden vanwege geopolitieke ontwikkelingen die de veiligheid van een digitale omgeving in gevaar brengen.
In alle gevallen geeft het strategiedocument de factoren aan die meewegen bij het ontwerpen van een exit, en ook de concrete keuzes die gemaakt moeten worden bij een werkelijke exit. Zo omschrijven we functionele en niet-functionele vereisten, zoals welke cloud(s) erbij betrokken zijn, wat binnen en buiten de scope valt, hoe de exit uitgevoerd moet worden, en wie ervan op de hoogte gebracht moet worden. Maar ook technische details zoals de vraag of onderdelen van het netwerk op een ander platform moeten draaien, authenticatie van gebruikers, toegang op basis van specifieke rollen, het gebruik van hardware, een containerservice, of een directe dedicated verbinding naar de cloud vanaf een datacentrum op de eigen locatie.
Hoewel Schuberg Philis actief betrokken is bij het gezamenlijk ontwikkelen van dit plan, is het uiteindelijk altijd de klant die de vereisten en parameters vastlegt. Zij zijn te allen tijde de eigenaar van hun eigen exitstrategie en de documentatie die daarbij hoort.
Testen en nog eens testen
Digitale veerkracht krijg je niet zonder te oefenen, en daarom is testen een onderdeel van al onze klantovereenkomsten. Door de exitstrategie te testen, bevestigen we dat een exit werkelijk uitgevoerd kan worden binnen de juiste scope en binnen de gegeven tijd. Zo weten we zeker dat onze hoge beschikbaarheid intact blijft, ook als de auditor een inspectie uitvoert. Dit biedt ook zekerheid voor de stakeholders door te laten zien hoe het bedrijf een workload kan migreren vanaf de ene serviceprovider, en hem binnen een redelijke termijn weer kan activeren en laten draaien bij een andere serviceprovider, met behoud van alle functionaliteit. Omdat onze strategie is getest en is goedgekeurd door de businessafdeling bij de klant, weten we dat ze zowel functioneel als technisch solide is.
We maken een helder onderscheid tussen een tabletop assessment en het technisch testen. Het doel van het tabletop assessment is om te bevestigen dat bepaalde technologieën aanwezig zijn in de cloud waar een bedrijf heen wil migreren, en dat de hardware geschikt is voor specifieke frameworks. Het technisch testen levert het functionele bewijs dat de workload echt in een andere cloud kan draaien. Daarbij hoort het ontwerpen, implementeren, in bedrijf nemen, uit bedrijf nemen en uitvoeren van disaster recoveries, op basis van de vereisten. Voor klanten die gebruikmaken van onze eigen private cloud, sbp.cloud, is het testen helemaal makkelijk, omdat we dan te maken hebben met onze eigen hardware die we volledig onder controle hebben en waarvan we de locatie en workloads door en door kennen.
Door elk jaar een exittest te doen kunnen we gaandeweg de exitstrategie als geheel steeds verder verbeteren. De code blijft intact en elke nieuwe ronde biedt een kans om de scope te vergroten. Omdat dit volledig geautomatiseerd is en door code wordt uitgerold, is het herbruikbaar en makkelijk uit te breiden.
Deskundigheid en overstappen
Als cloud-agnostische IT-partner hebben wij doorlopende contracten met Amazon Web Services (AWS), Microsoft Azure en Google Cloud Platform. Zo kunnen we namens onze klanten de overeenkomsten en cloudfinanciering afhandelen – een activiteit die voor het testen op kleine schaal al snel de nodige rompslomp met zich mee zou brengen. Bovendien zorgen we ervoor dat ze niet veel tijd en energie hoeven te steken in het verkennen van wat de publieke cloud te bieden heeft. Dat komt omdat wij die diensten door en door kennen, inclusief de meest recente features. Tegelijkertijd zorgen we ervoor dat onze klanten niet vastzitten aan één aanbieder als dat niet past bij hun risicoprofiel.
Of het nu is om aan een bepaalde risicotolerantie te voldoen of om de DORA-regels te volgen, CEaaS past perfect in ons expertiseprofiel. Het is in lijn met ons commitment om onze klanten maximale veerkracht te helpen bereiken. Voor financiële instellingen betekent dat het vermogen om snel en foutloos diensten aan hun eindgebruikers te leveren. Met de garantie dat als (met name) hun cloudaanbieder tekortschiet of de impact ervaart van een lokale of wereldwijde bedreiging, hun exitplan de overstap naar een andere cloud simpel en stressvrij maakt.
Een andere belangrijke factor bij de exitstrategie is het stimuleren van onze klanten en al hun werknemers om een flexibele manier van denken te omarmen. Dat zie je terug in het vermogen om technologieën gemakkelijk te verplaatsen en de kracht van schaalbaarheid in te zetten bij het kiezen van een andere cloudprovider. Bovendien betekent het: niet te veel gebonden zijn aan de eerdere keuze voor een technologie of serviceprovider – inclusief Schuberg Philis. Een constante factor in al onze partnerships is dat we verwachten dat onze klanten hun relatie met ons steeds blijven evalueren. Mochten ze ooit besluiten om onze eigen cloud te verlaten, dan ondersteunen we ze volledig bij die overstap. Sterker nog, we blijven ze de volle 100% geven, tot en met het moment van hun exit.
Door Stefan Wessels Beljaars en Jos Vliegenthart