Cloudstrategie: breng eerst de zolder in kaart, dan ruim je slim op

Cloudstrategie-trajecten in de publieke sector hebben een herkenbaar patroon — niet omdat cloud nog een nieuwe belofte is, maar omdat veel organisaties merken dat ze halverwege vastlopen. De discussie over soevereiniteit en autonomie heeft urgentie toegevoegd, maar ook ruis. De echte vraag is allang niet meer óf je iets met cloud doet. De vraag is: weet je wat je hebt, en wat dat vraagt? Want een goede cloudstrategie begint niet met een richting kiezen — die begint met de zolder in kaart brengen. En daarna: slim opruimen.

Vier lagen, één overzicht

Ik werk doorgaans met een eenvoudig model dat de IT-omgeving indeelt in vier lagen. Vakapplicaties — het EPD, het zaaksysteem, het burgersysteem. Kantoorautomatisering, traditioneel het domein van Microsoft in de publieke sector. Platformen, zoals Power BI, Salesforce en andere cloud-native diensten. En de infrastructuur waarop alles draait. Het model is een vereenvoudiging, maar het helpt het gesprek te structureren en te voorkomen dat alles door elkaar loopt. Per laag breng je in kaart wat lokaal staat, wat al in de cloud zit en wat de richting is.

Begin bij wat je al weet — of denkt te weten

Het meest waardevolle werk begint niet bij de strategie, maar bij het overzicht. Wat staat er op de desktop geïnstalleerd? Wat zijn de actieve SaaS-abonnementen? Dat klinkt eenvoudig. Het is het niet. Architectuurtools en CMDB-systemen sluiten zelden op elkaar aan. En je ontdekt al snel dat je niet goed weet welke SaaS-applicaties er überhaupt in gebruik zijn. Dat is geen falen — het is de realiteit in vrijwel elke middelgrote publieke organisatie. Het is ook het startpunt.

Inside-out: contracten, eigenaren, afhankelijkheden

Als het overzicht er is, is de volgende stap: niet direct een soevereiniteitsdiscussie voeren, maar kijken wat je zelf al weet. Wanneer loopt een contract af? Wie is de interne eigenaar van een applicatie? Is er al een leverancier die je richting een verplichte SaaS-migratie duwt?

Dit is een inside-out benadering: eerst de eigen administratie op orde, voordat je je laat leiden door externe ontwikkelingen. Zet het contractnummer gewoon in je architectuurtool. Koppel dat waar mogelijk via een API aan je contractadministratie. Minder complex dan het klinkt — en het bespaart later veel discussie.

Ondertussen zijn er bijna altijd afhankelijkheden die je wilt kennen. Een applicatie die lokaal draait maar via Microsoft Entra ID gekoppeld is aan single sign-on, heeft al een cloudafhankelijkheid. Dat is relevante informatie voor elke beslissing over continuïteit en leveranciersrisico.

Kritikaliteit: grof, maar gericht

Business continuity-trajecten lopen in veel organisaties vast op definitievragen. Wat is een kroonjuweel? Hoe classificeer je een proces? Die discussies zijn niet onbelangrijk, maar ze mogen het overzicht niet in de weg staan.

Een pragmatische aanpak werkt beter: waar zijn de grootste gebruikersgroepen? Bij welke applicaties krijg je direct te maken met toezichthouders als ze uitvallen? Welke applicaties zorgen bij uitval voor directe schade richting burgers? Dat geeft een grove maar bruikbare inschatting van kritikaliteit — zonder dat je eerst alle processen volledig gedocumenteerd hoeft te hebben.

Lessen vastleggen, niet wachten tot alles klopt

De lessen die je onderweg leert zijn minstens zo waardevol als het eindresultaat. Geen lifecycle management-proces? Opschrijven. Contractadministratie niet gekoppeld aan de architectuurtool? Opschrijven. Geen duidelijke applicatie-eigenaren? Opschrijven.

Dat zijn geen faalfactoren — het zijn verbeterpunten die je parallel aanpakt. Begin met twee borden: één voor inzicht, één voor acties. Werk iteratief, in kleine stappen. Wacht niet tot het overzicht compleet is — dat moment komt toch niet. Wat je onderweg leert, stuurt de volgende stap.