Meerjarenstrategie Digitale Autonomie 2026-2030

Meerjarenstrategie Digitale Autonomie 2026 - 2035 Gemeente Amsterdam

Versie vastgesteld B&W 20 januari 2026

Gemeente Amsterdam

Pagina 2 van 31

Inhoud 1 Digitale Autonomie ................................................................................................... 3 1.1 Introductie ............................................................................................................................... 3 1.2 Meerjarenstrategie ..................................................................................................................4 1.3 Risico’s.....................................................................................................................................4 1.4 Kansen .................................................................................................................................... 5 1.5 Doelstellingen 2026 - 2035 .......................................................................................................6 2 Digitale autonomie bij de Gemeente Amsterdam ........................................................ 8 2.1 Digitale kernwaarden...............................................................................................................8 2.2 De Amsterdamse omgeving ....................................................................................................9 3 Digitale autonomie als drie fasen-model ...................................................................

12 3.1 Stappen in onzekerheid ......................................................................................................... 12 3.2 De cloud centraal ................................................................................................................... 12 3.3 Autonoom is wendbaarheid ................................................................................................... 16 4 De drie fasen .......................................................................................................... 17 4.1 Fase 3: 10+ jaar ...................................................................................................................... 17 4.2 Fase 2: 1 – 4 jaar..................................................................................................................... 17 4.3 Fase 1: 1 jaar (2026)................................................................................................................ 19 4.4 De basis op orde .................................................................................................................... 19 5 Kosten digitale autonomie ...................................................................................... 22 5.1 Kostenramingen digitale autonomie: NDS .............................................................................

22 5.2 Kostenramingen digitale autonomie: Deloitte........................................................................ 23 5.3 Kosten voor Fase 1 (2026) ...................................................................................................... 25 5.4 Totale kosten digitale autonomie 2026 – 2035 ....................................................................... 26 6 Pilots en experimenten in Fase 1 (2026) .................................................................... 27 6.1 Digitale werkomgeving .......................................................................................................... 27 6.2 Rijkscloud .............................................................................................................................. 29 6.3 AI .......................................................................................................................................... 30 6.4 Inkoop en aanbesteding ........................................................................................................ 30

2

Gemeente Amsterdam

Pagina 3 van 31

1 Digitale Autonomie

1.1 Introductie Op 28 maart 2024 heeft de gemeenteraad van Amsterdam unaniem ingestemd met het (gewijzigde) initiatiefvoorstel Amsterdam Digitaal Onafhankelijk van raadslid IJmker 1. Dit voorstel vraagt om de gemeente minder afhankelijk te maken van grote technologiebedrijven voor digitale diensten en producten. Voor het college is de boodschap duidelijk: Amsterdam, Nederland en Europa moeten digitaal onafhankelijker worden2. Niet omdat de huidige leveranciers geen goed werk leveren, maar omdat we zelf onze keuzes willen blijven maken. We willen de privacy van inwoners, bezoekers, organisaties en bedrijven beschermen en onze digitale veiligheid versterken. Amsterdam staat hierin niet alleen. Digitale autonomie en samenwerking zijn belangrijke pijlers van de nieuwe Nederlandse Digitaliseringsstrategie (NDS) 3. Die strategie benadrukt dat overheden niet langer ieder hun eigen koers moeten varen, maar gezamenlijk moeten optrekken. Zoals ook door de VNG wordt onderschreven in de visie op collectivisering van gemeentelijke digitalisering, waarbij generieke diensten, data-infrastructuur, beveiliging en leveranciersmanagement bij voorkeur in samenhang en op schaal worden ingericht.

Daarnaast hebben zowel Amsterdam 4 als het Rijk (in de NDS) de ambitie om in 2030 30% van clouddiensten in Europese (EER) publieke en private clouddiensten onder te brengen (zonder risico op inmenging door andere statelijke partijen). Door samenwerking kunnen we kennis delen, sneller bewegen en onze digitale weerbaarheid vergroten. Daarom werkt Amsterdam samen met de drie andere grote steden (G4), de Vereniging van Nederlandse Gemeenten (VNG) 5, de Rijksoverheid en andere publieke partners. Een belangrijk doel is de marktmacht van de (gehele) Nederlandse overheid te bundelen, zodat we een sterkere positie hebben tegenover grote technologiebedrijven. Dit vergroot onze mogelijkheden om eisen te stellen op het gebied van veiligheid, privacy en open standaarden. Daarnaast helpt de bundeling van krachten om alternatieven te realiseren die we in Europa hard nodig hebben, maar die niet van de grond komen als we ieder op onze eigen eilanden blijven opereren.

1 Raadsvoordracht gewijzigd initiatiefvoorstel ‘Amsterdam digitaal onafhankelijk’ van het lid IJmker 2 Rapport verkenning digitale autonomie - 5 maart 2025 3 Nederlandse Digitaliseringsstrategie - prioriteit 5: versterken digitale weerbaarheid en autonomie van de

overheid 4 Motie 158 van de leden IJmker, Garmy en Belkasmi inzake maak digitale autonomie concreet 5 VNG nieuwbericht: Gemeenten zetten koers naar collectieve digitalisering

3

Gemeente Amsterdam

Pagina 4 van 31

1.2 Meerjarenstrategie In deze meerjarenstrategie Digitale Autonomie wordt een fasering geïntroduceerd. Hiermee kunnen we, in een technisch en maatschappelijk onzekere toekomst, zicht houden op de nog vrij abstracte lange termijn doelen terwijl we op de korte termijn toch al concreet aan de slag kunnen. In deze fasering beschrijft Fase 3 het uiteindelijke einddoel, met de nadruk op (onder andere) de cloud, digitale werkomgeving (de werkplek) en de samenwerking met andere overheidsonderdelen. Fase 2 beschrijft een tussenstap gericht op de aanstaande nieuwe college periode, waarin de opbouw van kennis en kunde en het leggen van een autonoom fundament belangrijk zijn. En Fase 1 betreft het heden: 2026 - 2027. Hiervoor worden een aantal concrete pilots en experimenten voorgesteld die ons als gemeente enerzijds leren hoe we digitaal autonomer kunnen worden, en die ons anderzijds ook al daadwerkelijk meer autonoom maken. De nadruk ligt op zowel meer nieuwe inzichten vergaren (zodat we met nieuwe kennis gaandeweg Fases 2 en 3 concreter kunnen gaan maken), maar ook op ‘de basis op orde’ brengen, zodat er een goed (en noodzakelijk) fundament ligt voor de vervolgstappen. Immers, na jarenlange inzet op alles-in-een oplossingen van, met name, Microsoft moet de organisatie nu in relatief korte tijd geschikt gemaakt worden voor een meer autonome inrichting.

Dat vraagt forse, doch vaak onzichtbare, inspanning. Logische plekken om te beginnen met de basis op orde zijn in Fase 1 (oa) het identificeren van de kritische bedrijfsprocessen en de gevoelige data, het opbouwen van kennis, het aanpassen van (soms ingesleten) werkwijzen en daarmee de introductie van ‘autonomie’ als nieuwe digitale kernwaarde. Vanuit daar kunnen dan, onder andere met de voorgestelde pilots, samen met het Rijk en andere gemeenten stappen gemaakt worden richting meer autonomie. En vanaf dat moment zullen alle nieuwe grote ontwikkelingen, denk bijvoorbeeld aan AI, als vanzelfsprekend vanaf het begin langs autonome lijn worden ingericht. Omdat de plannen voor 2026 - 2027 nieuw zijn, gericht op een nieuwe ambitie (digitale autonomie) waar in eerdere begrotingen nog geen rekening is gehouden, is de uitvoering uiteraard afhankelijk van de middelen die het nieuwe college beschikbaar stelt.

1.3 Risico’s In oktober 2025 waarschuwt de VNG in haar position paper over digitale autonomie 6 dat de afhankelijkheid van grote, niet-Europese tech-bedrijven leidt tot drie acute bedreigingen: 1. Continuïteit: de gemeentelijke dienstverlening kan onder geopolitieke druk stilgelegd worden, bijvoorbeeld als buitenlandse clouddiensten plotseling ontoegankelijk worden gemaakt. Denk aan scenario’s waarbij kritieke processen zoals uitkeringsverstrekking, vergunningverlening of data-uitwisseling stilvallen door sancties of technische blokkades, zoals recent gebeurde bij personeel van het Internationaal Strafhof in Den Haag. 2. Veiligheid: gegevens van inwoners en ondernemers die bij grote, met name Amerikaanse tech-bedrijven zijn ondergebracht zijn onvoldoende beschermd tegen extraterritoriale 6

https://vng.nl/nieuws/meer-regie-nodig-op-technologie-voor-digitale-autonomie

4

Gemeente Amsterdam

Pagina 5 van 31

wetgeving, waardoor buitenlandse overheden toegang kunnen krijgen tot Nederlandse data zonder dat wij daar controle over (of zelfs weet van) hebben. 3. Keuzevrijheid: afhankelijkheid beperkt de strategische keuzevrijheid van de gemeente: Vendor lock-in en monopolyposities van grote tech-bedrijven maken het moeilijk om over te stappen op alternatieven, zelfs als deze beter aansluiten bij publieke waarden, de financiële situatie van de stad of lokale behoeften.

1.4 Kansen De koers naar digitale autonomie biedt ook grote kansen. Door regie te nemen over onze digitale infrastructuur, kunnen publieke waarden zoals transparantie, veiligheid en democratische controle beter geborgd worden in technologie. Voordelen van het streven naar meer digitale autonomie zijn: •

Weerbaarheid: onze kritische processen en gevoelige data worden juist geclassificeerd en staan veilig opgeslagen zonder mogelijke invloeden van buitenaf. We kunnen zelf onze strategische keuzes maken met betrekking tot de inrichtingen van ons informatielandschap.

•

Samenwerking: een autonome aanpak stelt ons in staat om samen te werken aan Europese en Nederlandse alternatieven, zoals open-source oplossingen en soevereine cloud omgevingen, die beter aansluiten bij onze wet- en regelgeving en maatschappelijke normen.

•

Transparantie: lokaal ontwikkelde producten en open-source software stellen burgers (bv maatschappelijke organisaties) in staat om de software van de gemeente te controleren op fouten of onrechtmatige mogelijkheden, iets wat met gesloten systemen zoals die van grote tech-bedrijven niet kan.

•

Flexibiliteit en wendbaarheid: Exitstrategieën, migratiestrategieën, een actieve multicloud omgeving en gebruik van open source en open standaarden zorgen ervoor dat de gemeente niet afhankelijk is van leveranciers, snel kan wisselen indien nodig en kan blijven functioneren in crisissituaties.

•

Duurzaam & efficiënt: samen met andere lokale overheden kunnen we herbruikbare middelen ontwerpen, die via open source (of andere standaarden) gedeeld kunnen worden.

•

Sterkere marktpositie: digitale autonomie versterkt onze onderhandelingspositie richting leveranciers, biedt de mogelijkheid om de markt actief uit te dagen en stimuleert een gezonder marktecosysteem, waarin innovatie en concurrentie niet worden gedomineerd door een handvol grote tech-bedrijven. Door nu te investeren in kennisopbouw, collectieve inkoop en open standaarden kunnen we niet alleen risico’s mitigeren, maar ook toekomstbestendige, veerkrachtige digitale dienstverlening realiseren die echt dient aan de behoeften van Amsterdammers.

5

Gemeente Amsterdam

Pagina 6 van 31

1.5 Doelstellingen 2026 - 2035 Uiteindelijk is de doelstelling van digitale autonomie om weerbaar te zijn tegen de risico’s die hierboven beschreven zijn. Onze dienstverlening moet continue gegarandeerd zijn, met keuzevrijheid in al onze digitale keuzes, en onze data en processen is veilig afgeschermd van externe invloeden. In combinatie met de doelstelling door de raad gesteld in recente moties zijn de doelstellingen van deze meerjarenstrategie Digitale Autonomie: 2035 -

De volledig digitale omgeving van de Gemeente Amsterdam is autonoom waar het nodig is. Dit is gebaseerd op een volledig ingerichte multicloud omgeving (incl. autonome Rijkscloud). Alle gevoelige data van Amsterdammers staat op Nederlandse/ Europese cloudplatforms en / of on-premise 7 Alle kritische processen en gevoelige data zijn autonoom opgeslagen en beheerd. De digitale inrichting is wendbaar, en kan daarmee snel inspelen op acute (geopolitieke) problemen, bijvoorbeeld door snel van aanbieder te kunnen wisselen.

2030 - Minimaal 30% van de cloudopslagdiensten en cloudapplicaties zijn van Nederlandse / Europese leveranciers (zie ook motie motie 158-25: ‘Maak digitale autonomie concreet’) - Alle Bedrijfskritische processen draaien op Nederlandse/ Europese cloudplatforms. - Autonomie is een nieuwe digitale kernwaarde, in verhouding met de bestaande digitale kernwaarden (kwaliteit, kosten, veiligheid, innovatie, duurzaamheid, transparantie). Nieuwe processen en technologieën zijn daarmee altijd ‘autonoom-by-design’. 2027 -

De basis is op orde (zie paragraaf 4.4). We zijn daarmee gereed voor de volgende stappen richting meer autonomie, ondanks dat nog niet volledig duidelijk is hoe deze eruit zien. Hieronder valt oa het in kaart brengen van kritische data, en classificeren van de gevoelige data. De pilots zoals beschreven in Hoofdstuk 6 zijn uitgevoerd, en hebben kennis en inzicht gebracht in hoe we meer autonomie kunnen bereiken. Ook hebben de pilots de gemeente al een beetje autonomer gemaakt.

Veel onderdelen van deze doelstellingen richten zich expliciet op de cloud, waarbij de doelstelling uit motie 158-25 zo geïnterpreteerd is dat ook de digitale werkomgeving (de werkplek) daaronder valt. Om deze doelstellingen te halen wordt vanaf het begin gemikt op de ontwikkeling van een multicloud omgeving, waarin voor alle gevoelige data en kritische processen een autonome oplossing gerealiseerd kan worden. Deze realisatie is echter wel deels afhankelijk van de ontwikkelingen bij de Rijksoverheid (Rijkscloud) of in de markt (NL/ EU bedrijven met autonome oplossingen). De digitale werkomgeving is een belangrijk onderwerp bij de voorgestelde pilots. Een andere belangrijke afhankelijkheid is de huidige onzekerheid rondom dit onderwerp. Met 7

Met ‘on-premise’ wordt bedoeld dat data fysiek en in beheer op een locatie van de gemeente zelf staat.

6

Gemeente Amsterdam

Pagina 7 van 31

behulp van andere overheidsonderdelen en kennisinstellingen gaan we aan de slag om deze onzekerheid zoveel mogelijk beheersbaar en voorspelbaarder te maken. Tenslotte is het belangrijk om te benoemen dat, in de ontwikkeling naar méér digitale autonomie, het goed mogelijk is dat er tussentijdse stappen gezet moeten worden die, tijdelijk, lijken alsof er juist minder autonomie ontstaat. Bijvoorbeeld als bestaande data of functies van SaaS naar de huidige Microsoft cloud gemigreerd moeten worden, om daarna de cloud als geheel naar een autonome oplossing te migreren. Dergelijke stappen zullen soms onvermijdelijk zijn, en de toezegging om de afhankelijkheid van Microsoft niet te laten groeien moet dan ook vooral in het licht van deze gehele meerjarenstrategie gezien worden, en niet op detailniveau.

7

Gemeente Amsterdam

Pagina 8 van 31

2 Digitale autonomie bij de Gemeente Amsterdam

2.1 Digitale kernwaarden Digitale autonomie is een veelomvattende term, in een snel veranderende omgeving. Het is geen staat om eenmalig te bereiken, maar een continue streven waar onze organisatie voortdurend scherp op moet zijn. Het is daarmee een belangrijke nieuwe digitale kernwaarde die moet worden toegevoegd aan de bestaande digitale kernwaarden 8, en die tijdens elke afweging en keuze voor het binnenhalen en inzetten van (informatie-)technologie meegewogen wordt. Der digitale kernwaarden worden daarmee: • • • • • • •

Kwaliteit (incl. gebruikersgemak) Kosten Veiligheid en weerbaarheid Innovatie Duurzaamheid Transparantie/ openbaarheid Autonomie

Niet alle kernwaarden zijn op elk moment even belangrijk. Zo ook digitale autonomie. Het is immers niet nodig, en waarschijnlijk ook niet mogelijk, om als gemeente volledig digitaal autonoom te worden. Dat hoeft ook niet, want de risico’s die hierboven in kaart gebracht zijn spelen niet bij alle onderdelen van de gemeentelijke informatievoorziening of ICT. Denk bijvoorbeeld aan niet gevoelige data of makkelijk te vervangen (of te verplaatsen) processen. Om deze alsnog autonoom in te richten zou een onevenredig grote last zijn voor de organisatie opleveren, bijvoorbeeld qua kwaliteit, gebruikersgemak en kosten. Om deze afwegingen altijd goed te kunnen maken worden de digitale kernwaarden bij alle keuzes binnen het digitale domein van de gemeente Amsterdam elke keer gezamenlijk afgewogen, waarbij over het algemeen aan elke kernwaarde tenminste deels moet zijn voldaan. Een veilig en autonoom systeem is immers nutteloos als het kwalitatief zo slecht is dat het niet gebruikt wordt. En andersom. Net zoals eerder benoemd in de sourcing- en cloudstrategie zal in het algemeen het adagium ‘autonoom, tenzij..’ gehanteerd worden, wat zoveel betekent als dat autonomie een belangrijke kernwaarde is, maar ook altijd zal moeten worden afgewogen tegen andere kernwaarden zoals kosten en kwaliteit.

8

De digitale kernwaarden zijn bedoeld voor een gebalanceerde afweging bij de inzet, inkoop en ontwikkeling van technologie, en zijn deels gebaseerd op de zes Tada-waarden (gericht op verantwoord data-gebruik): https://www.amsterdam.nl/innovatie/digitalisering-technologie/data/tada-waarden/

8

Gemeente Amsterdam

Pagina 9 van 31

2.2 De Amsterdamse omgeving Om stappen te zetten richting meer digitale autonomie is het belangrijk een goed beeld te hebben van de onderdelen van de Amsterdamse Informatievoorziening (IV) en ICT omgeving waar digitale autonomie een belangrijke impact gaat hebben. De belangrijkste daarbij is natuurlijk de cloud. Hier wordt in paragraaf 3.2 dieper op ingegaan. Het overzicht van alle relevante onderdelen: •

•

Digitale Werkomgeving o

Beter bekend als ‘de werkplek’, hieronder vallen de centrale onderdelen van de kantooromgeving zoals email, agenda, bestandenopslag, samen werken in bestanden, en communicatie (Teams en Chat). Deze functies zijn vrijwel allemaal kritiek voor het functioneren van de gemeente.

o

Ook met betrekking tot gevoelige data valt veel onder de digitale werkomgeving, omdat hier ook alle bestanden staan die gebruikers, afdelingen, teams, etc zelf opslaan en delen. Dit staat op de achtergrond op een Microsoft M365 Cloud.

o

Hoe en door welke leverancier de digitale werkomgeving geregeld wordt heeft daarmee een sterke invloed op de mate van digitale autonomie van de gemeente.

De cloud o

De cloud (of beter gezegd: het cloudplatform) is de omgeving waar onze applicaties en data fysiek staan. In de praktijk is dit niet één (soort) cloud, maar zijn het meerdere cloud omgevingen bij diverse aanbieders. De belangrijkste die nu binnen de gemeente gebruikt worden: ▪

De Office M365 cloud omgeving, waar de gebruikersdata uit Office 365 staat (zie ook hierboven bij ‘digitale werkomgeving’).

9

Gemeente Amsterdam

•

•

Pagina 10 van 31

▪

Het standaard public cloudplatform waar al onze zelfgebouwde en nieuw aangekochte applicaties staan, en ook onze grote datasets. Momenteel is dit Microsoft Azure, verreweg de populairste binnen de Nederlandse overheid.

▪

Het HenT-platform, wat staat voor Hosting en Technisch applicatiebeheer. Dit is ook een cloud, maar met meer technische dienstverlening (en minder vrijheid om het zelf in te richten), en daarom ook duurder. Hier staan met name verouderde en/of bijzondere applicaties die om diverse redenen niet op een reguliere cloud passen.

▪

SaaS-applicaties, wat staat voor Software-as-a-Service, oftewel losse applicaties die elk bij hun eigen leverancier draaien en waar ambtenaren via een website op in kunnen loggen. Dit geldt ook als cloud, maar eigenlijk zijn het ongeveer 1300 kleine cloudjes (en een paar grotere) waar applicatie(s) en data samen ergens bij een leverancier staan.

o

Door de omvang van de totale cloud (het public cloudplatform, HenT en alle SaaSapplicaties bij elkaar) heeft deze een enorme invloed op de mate van digitale autonomie van de gemeente. En daarmee is het ook de grootste kluif om aan te pakken als Amsterdam autonomer wil worden. Vandaar het grote belang van de ontwikkeling van ‘de Rijkscloud’ (die waarschijnlijk ook niet uit één, maar uit meerdere cloud omgevingen zal gaan bestaan).

o

De gemeente heeft geen eigen datacentra (meer). In een toekomstige situatie zou dit mogelijk weer kunnen veranderen. Het gaat dan echter alleen om het (opnieuw) in gebruik nemen van serverruimtes in bestaande gebouw(en) van de gemeente, en niet om een nieuw te bouwen datacentrum oid (wat qua omvang ook een volstrekt andere orde van grootte is).

Data o

Er zijn veel verschillende soorten data binnen de gemeente, die op verschillende plekken zijn ondergebracht. Zo staat bijvoorbeeld nog veel data in individuele SaaSapplicaties, waarvan niet altijd duidelijk is hoe autonoom dit is.

o

De huidige datastrategie richt zich op het loskoppelen van belangrijke data van individuele applicaties. Daarmee zijn we minder afhankelijk van leveranciers en kan data gemakkelijker hergebruikt en verplaatst worden (portabiliteit).

o

We gaan onderzoeken hoe we data kunnen classificeren, zodat we kunnen prioriteren welke gegevens als eerste veiliggesteld moeten worden. Dit helpt ons om gevoelige en kritieke data beter te beschermen en meer controle te krijgen.

Sourcing o

Met sourcing wordt bedoeld alle manieren om aan nieuwe applicaties of functies te komen. De meest gebruikte opties zijn inkopen, laten ontwikkelen, zelf ontwikkelen of zelf ontwikkelen samen met andere organisaties (gemeenten, rijk). Om digitaal autonomer te worden moet autonomie als kernwaarde hier structureel meegenomen

10

Gemeente Amsterdam

Pagina 11 van 31

worden. Dit gebeurt middels de nieuwe (en op autonomie aangepaste) sourcing- en cloudstrategie. •

Sturing en regie o

Op veel verschillende plekken binnen de Amsterdamse informatievoorziening worden keuzes gemaakt die effect hebben op de mate van digitale autonomie van de gemeente. Op al deze plekken moet autonomie daarom meegenomen worden. Belangrijke onderdelen van deze sturing zijn (van breed naar smal): ▪

▪ ▪ ▪ ▪ •

De versterking en verdere inrichting van de CIO-stelsel-verantwoordelijkheid (oa. sturen op data classificatie, interoperabiliteit, bewustwording, eigenaarschap en de invulling van rollen) Integraal Risico Management De digitale strategie van de gemeente Amsterdam (in ontwikkeling) en de sturing op complexe uitdagingen (zoals AI) Enterprise architectuur en domein-architecturen Applicatieportfolio’s

AI o

o

o

AI is zonder twijfel de meest besproken, gehoopte en gevreesde technologische ontwikkeling van deze tijd is, en de mogelijke afhankelijkheid van buitenlandse, vaak Amerikaanse, grote tech-bedrijven is enorm. We staan in Amsterdam (vermoedelijk) nog aan het begin van de AI-revolutie. De vraag naar AI-toepassingen neemt enorm toe. Idealiter richten we deze vanaf de basis autonoom in. Een van de voorgestelde pilots is expliciet hierop gericht. Als we bij AI nu al op digitale autonomie investeren scheelt dat later een hoop ‘reparatie-werk’. Dit uitgangspunt, noem het ‘autonomie-by-design’, geldt ook voor andere grote nieuwe ontwikkelingen die op ons afkomen. Denk bijvoorbeeld aan Quantum Computing. Een onderwerp waar we nu, net als bij AI twee jaar geleden, nog nauwelijks iets over horen…

11

Gemeente Amsterdam

Pagina 12 van 31

3 Digitale autonomie als drie fasen-model

3.1 Stappen in onzekerheid Met de complexiteit van het vraagstuk digitale autonomie en de zeer snelle ontwikkelingen in de maatschappij, wetenschap en de markt is het zeer lastig om op de toekomst te anticiperen. Toch is dat wat met deze meerjarenstrategie Digitale Autonomie beoogd wordt. Om alle onzekerheden enigszins het hoofd te kunnen bieden ligt er een strategie in drie fasen: Fase 3 (10+ jaar) is een abstract vergezicht over (ongeveer) 10 jaar waarin vooral staat wat er uiteindelijk met digitale autonomie bereikt moet worden (welke risico’s moeten gemitigeerd worden, en onder welke voorwaarden). Fase 2 (1-4 jaar) is een (iets) concreter beeld over de stappen die in de aankomende nieuwe collegeperiode gezet kunnen gaan worden om op het juiste pad te blijven richting Fase 3. En Fase 1 (1 - 2 jaar) bestaat uit enerzijds een overzicht van concrete activiteiten die nodig zijn om de basis op orde te krijgen voor de vervolgstappen in Fase 2 en 3, en anderzijds een aantal praktische pilots die in 2026 uitgevoerd zouden kunnen worden, die zowel inzichten opleveren over de manier waarom Amsterdam steeds een beetje digitaal autonomer kan worden, als die de gemeente nu ook al concreet meer digitaal autonoom maken.

Deze opdeling in 3 fasen geeft de ruimte om de toekomstige situatie (met haar forse onbekendheden) nog niet concreet te hoeven schetsen, terwijl we wel al direct aan de slag kunnen met praktische acties en pilots. Gaandeweg zal Fase 3 (10+ jaar) concreter worden, waarmee Fase 2 weer aangescherpt kan worden. En Fase 1 is de periodieke uitwerking van concrete stappen om op de goede weg (richting digitale autonomie) te blijven. Een belangrijk onderdeel van Fase 1, de sourcing- en cloudstrategie, is begin 2026 door de raad vastgesteld. Op deze manier blijft Amsterdam meebewegen richting de meest actuele ontwikkelingen, terwijl er al wel stevige stappen gezet kunnen worden. De totale verzameling van activiteiten, pilots en experimenten die de aankomende jaren zal plaatsvinden (zowel de hier bijgevoegde voorstellen, als nieuwe voorstellen die later naar de raad zullen komen) richting digitale autonomie zijn een samenhangend geheel, maar zullen elk met een eigen plan of businesscase worden uitgewerkt. Zo kan actueel grip gehouden worden op de bijbehorende kosten, zonder het doel uit het oog te verliezen. De drie fasen worden inhoudelijk uitgewerkt in Hoofdstuk 4.

3.2 De cloud centraal Centraal in deze hele beweging staat de cloud. Met een autonoom cloudplatform zou een enorme stap gezet kunnen worden richting digitale autonomie, maar deze stap is ook gelijk de meest ambitieuze, en meest lastig te voorspellen. Overheid en markt zijn op dit moment nog ver verwijderd van een realistisch alternatief voor de cloudplatformen van grote (buitenlandse) tech-

12

Gemeente Amsterdam

Pagina 13 van 31

bedrijven, en zelfs de wijze waarop een alternatief (of alternatieven) gerealiseerd kunnen gaan worden is nog onduidelijk. Er zijn meerdere initiatieven op het gebied van een Rijkscloud (in diverse vormen) en er komen mondjesmaat meer opties op de markt met allerlei autonomieclaims (waar tot nu toe met de nodige scepsis naar gekeken moet worden). En ook op het gebied van de digitale werkomgeving is Office 365 van Microsoft nog heer en meester in een verder nog vrij kaal landschap (hoewel: zie pilot 1). Toch kunnen we nu al stappen zetten, zowel binnen Amsterdam als in samenwerking met de NDS, en via de G4 in de VNG. Hiermee bundelt Amsterdam haar krachten met anderen die dezelfde doelstellingen hebben. Daarbij is het goed om te bedenken dat ‘de cloud’ ook in de toekomst niet één grote autonome cloud zal zijn, maar eerder een verzameling van meerdere cloud omgevingen die elk een eigen mate van autonomie hebben, geschikt voor de processen en data die op die specifieke cloud draaien. Dit noemen we een multicloud omgeving. En we weten nu al wat er nodig is om een proces, applicatie of dataset over te zetten naar een (autonome) cloud. Dus ook zonder Rijkscloud is het mogelijk om hier al stappen te zetten, of tenminste experimenten uit te voeren met alternatieve cloud omgevingen. Zie daarvoor de pilots in Hoofdstuk 6.

Ook de digitale werkomgeving is onder de motorkap uiteindelijk een cloud-dienst. En ook hier weten we nu al welke voorwaarden er nodig zijn om de digitale werkomgeving (en vooral de cloud die eronder zit) flexibeler in te richten. In pilot 1 kunnen we kijken naar een van de alternatieven die recent in zwang is geraakt waar nu al mee experimenteren zou kunnen worden.

Huidige situatie: •

Amsterdam neemt verschillende clouddiensten af, wat wel lijkt op een multicloud, maar waar nog geen bewuste, doordachte en overkoepelende multicloud strategie achter zit. Zo zijn er geen vaste afspraken wat waar moet staan en is alle kennis, kunde en sturing nog volledig georganiseerd rondom Microsoft Azure.

•

Onze cloud bestaat uit: ◦

Publieke cloud: Microsoft Azure voor de werkplek, voor data (Dataplatform) en voor appliciaties (Cloudplatform). Applicaties en data staan hier nog deels door elkaar.

13

Gemeente Amsterdam

Pagina 14 van 31

◦

Publieke cloud met extra beveiliging: op een klein deel van de MS Azure omgeving wordt gewerkt met extra beveiligingsmaatregelen voor kritische processen en gevoelige data.

◦

SaaS: staat voor ‘Software as a Service’. circa 1300 applicaties worden elk apart gehost op de platformen van de leveranciers van de betreffende SaaS-applicaties. Applicaties en data zitten altijd door elkaar, en in de meeste gevallen gaat het hier om publieke of private cloud, vaak buiten Nederland en de EU. En soms weten we dat zelfs niet. ▪

Het verschil tussen public en private cloud zit hem vooral in de mate waarin het voor de gemeente op maat gemaakt is, qua autonomie verschilt het weinig.

▪

Bij SaaS zitten ook 'grote brokken' voor gestandaardiseerde bedrijfsprocessen, zoals onze CRM die door Salesforce wordt geleverd, die daarvoor op haar beurt weer diensten afneemt van AWS (Amazon Web Services) en Oracle.

◦

Private cloud (NL/EU): dit gaat over Hosting en Technisch applicatiebeheer (HenT), wat nu nog wordt uitgevoerd door KPN, op haar eigen datacentra. Het is een (relatief dure) voorziening waar legacy software (= oud maar belangrijk, en zeer moeilijk te verplaatsen) op draait. Uiteindelijk moet dit uitgefaseerd worden.

◦

Overheidscloud: dit is nu nog een erg klein deel, gehost bij en door de gemeente zelf. Het gaat dan puur om Operationele Technologie (OT), oftewel de digitale processen van bruggen, sluizen, stoplichten, etc. Het zijn dus vooral hoog-technische applicaties, en vrijwel geen data.

Gewenste situatie: Dit plaatje is een ‘educated guess’ (dus geen exact doelscenario!) op basis van de kennis van nu, vooral bedoeld om een beeld te geven hoe een toekomstige multicloud eruit zou kunnen zien) •

Amsterdam werkt in een multicloud omgeving op basis van een actieve multicloud strategie (deels reeds vervat in de nieuwe sourcing- en cloudstrategie), in samenwerking met andere overheidspartners.

•

We gebruiken daar waar mogelijk de overheidscloud, voor zowel cloud-native, SaaS en zelf ontwikkelde applicaties. Er wordt zelf (vanuit het collectief) beheer gevoerd, danwel beheer autonoom ingekocht.

•

Daar waar sprake zou zijn van nieuwe datacentra, gaat dit alleen om het kleinschalig inrichten van nieuwe, of uitbreiden van bestaande serverruimtes, in bestaande gebouwen van de gemeente. Dus geen nieuw te bouwen datacentra.

•

Diensten, applicaties en data zijn flexibel (‘portable’) en kunnen indien nodig snel en makkelijk gemigreerd worden (oa door gebruik te maken van standaarden hiervoor, zoals van het Forum Standaardisatie en Haven/Haven+).

•

Alle bedrijfskritische processen en gevoelige data staat op de autonome overheidscloud (en is ten alle tijden flexibel, dus snel en makkelijk te migreren). 14

Gemeente Amsterdam

Pagina 15 van 31

•

De Enterprise architectuur maakt wendbaarheid door modulariteit mogelijk door een scheiding tussen processen, diensten en data. Dat kan bijvoorbeeld door het Common Ground 5-lagen model te adopteren.

•

De multicloud bestaat uit: ◦

Publieke cloud: Microsoft Azure of een andere internationale hyperscaler (bv AWS, Google, Oracle), maar alleen voor de niet-bedrijfskritische processen en minst gevoelige data.

◦

Publieke cloud met extra beveiliging: het grootste deel van de publieke cloud van een internationale hyperscaler is uitgerust met extra maatregelen voor beveiliging en continuïteit, bedoeld voor laag tot midden kritische processen en laag tot midden gevoelige data.

◦

SaaS: het aantal SaaS-applicaties is drastisch verminderd, en op basis van een risico en gevoeligheids-classificatie verdeeld over SaaS bij internationale en bij Nederlands / Europese aanbieders, en SaaS vanuit de overheid (ontwikkeld of ingekocht samen met bv G4, VNG en/of Rijk). ▪

◦

Private cloud (NL/EU): dit kan zowel HenT als een andere (gezamenlijk met andere lokale overheden of overheidsdiensten) ingekochte dienst in Nederland / Europa. ▪

◦

Dit geldt voor zowel public als private cloud. De Rijkscloud is per definitie private als we deze mede zelf ontwikkelen.

Zowel HenT als een overheidscloud zijn sterk autonoom, maar elk net op een andere manier. De keuze hiertussen is per keer anders, en de criteria hiervoor moeten in de multicloud strategie verder uitgewerkt worden.

Overheidscloud: een aanzienlijk deel van onze cloud komt van de Rijkscloud, zowel voor OT, applicaties, data, digitale werkomgeving en via SaaS.

Route naar de multicloud Van de huidige situatie naar een bewuste en effectieve multicloud-situatie is een lange weg. Als eerste moet daarvoor de basis op orde zijn, zoals beschreven in paragraaf 4.4. Als onze data en applicaties multicloud geschikt zijn gemaakt, de kritische processen en data geïnventariseerd zijn en alle kennis en kunde in huis is, dan kunnen stap voor stap onderdelen van de huidige cloudomgeving gemigreerd gaan worden naar nieuwe cloud-onderdelen. Die moeten er dan wel zijn, dus parallel hieraan zal daarvoor geïnvesteerd moeten worden in de samenwerking met andere lokale overheden en het Rijk voor de ontwikkeling van nieuwe (Rijks)cloud oplossingen. Veel SaaS zal bijvoorbeeld naar de private of overheidscloud gemigreerd kunnen worden. Andere SaaS-oplossingen kunnen blijven bestaan, mogelijk met aanpassingen in hun infrastructuur of contracten. Er moet opnieuw gekeken worden naar de rol van HenT binnen de multicloud, en er is een stevige overkoepelende infrastructuur nodig waarin alle verschillende cloud omgevingen samen kunnen werken. Binnen dit alles moet tegelijkertijd de digitale werkomgeving, tenminste voor een deel van de medewerkers, bij een nieuwe leverancier ondergebracht worden (en ook weer in verbinding gebracht met de nieuwe multicloud omgeving). Daar waar een kleine SaaS15

Gemeente Amsterdam

Pagina 16 van 31

oplossing nog relatief snel te migreren is, geldt voor veel van de grotere applicaties, datasets of andere toepassingen dat elke migratie op zich al een complex proces is. Vandaar de forse kosten en tijdsspanne die voor deze hele beweging nodig zijn.

3.3 Autonoom is wendbaarheid Tenslotte de observatie dat digitale autonomie soms nog vooral gezien wordt als onafhankelijkheid van grote Amerikaanse tech-bedrijven. Hoewel terecht, is dit niet het complete verhaal. Autonomie gaat immers over de onafhankelijkheid van alle externe invloeden. Denk bijvoorbeeld aan een autonome cloud die in een EU-land gerealiseerd is, waar vervolgens een radicaal-populistische regering aan de macht komt. Of een volledig Nederlandse autonome cloudoplossing die voor haar infrastructuur (de chips, de servers, de geheugen capaciteit) alsnog afhankelijk is van buitenlandse aanbieders, die mogelijk op een zeker moment geen reserveonderdelen meer willen of kunnen leveren. En recent heeft Amsterdam ondervonden dat zelfs als er een volledig Nederlands bedrijf gevonden wordt om een deel van de diensten te leveren, deze ook weer overgenomen kan worden door een groot bedrijf buiten de EU, en onze autonomie daarmee alsnog een klap krijgt. Uiteindelijk betekent digitale autonomie dus niet alleen onafhankelijk zijn in het hier en nu, maar ook dat de IV-omgeving flexibel en wendbaar ingericht moet zijn zodat processen en data bij nieuwe ontwikkelingen of calamiteiten snel verplaatst kunnen worden zonder al te grote impact op de continuïteit.

Dit vraagt dus ook om een heel andere kijk op het inrichten van onze processen, data en infrastructuur, en Amsterdam zal de komende jaren nodig gaan hebben om deze paradigma verschuiving verder vorm te kunnen geven. Om deze hele beweging mogelijk te maken zal er vanaf 2026 een groep mensen, van diverse vakgroepen en i-afdelingen in het i-domein, samen gaan werken om digitale autonomie de komende jaren stapsgewijs dichterbij te brengen. Zij kunnen dit grotendeels naast hun bestaande werk doen, met een klein vrijgemaakt kernteam Digitale Autonomie voor de gehele coördinatie, en om urgentie en tempo erop te houden. Vanuit dit team zullen ook de contacten met alle bovengemeentelijke en landelijke ontwikkelingen plaatsvinden. De snelheid en effectiviteit van dit team zijn uiteindelijk afhankelijk van de middelen die het nieuwe college hiervoor beschikbaar stelt.

16

Gemeente Amsterdam

Pagina 17 van 31

4 De drie fasen

4.1 Fase 3: 10+ jaar Over 10 jaar wil de gemeente Amsterdam zo autonoom mogelijk zijn. Van de doelstellingen in Fase 2 (30% autonoom) naar de doelstelling ‘volledig autonoom’. Hoe, dat is op deze termijn nog nauwelijks te voorspellen. Wel weten we dat dit tenminste betekent dat alle hierboven genoemde risico’s van continuïteit, veiligheid en keuzevrijheid gemitigeerd zijn, en dat we een aantal basisprincipes zullen volgen die in de loop der jaren steeds concreter gemaakt zullen worden. Zo gaan we van een abstract doel in Fase 3 naar praktische doelen in Fase 2 naar concrete acties in Fase 1: •

Amsterdam heeft een multicloud omgeving voor al onze processen, data en applicaties. Binnen deze multicloud omgeving staan tenminste alle kritische processen en gevoelige data op een volledig autonome cloud, zonder (technische en/ of juridische) toegang van externe partijen of statelijke actoren.

•

Amsterdam zet in op het collectief ‘sourcen’ (ontwikkelen of inkopen) van zoveel mogelijk onderdelen van de multicloud en andere onderdelen (bv de werkplek), met tenminste één volledig autonome cloud optie (bij voorkeur de Rijkscloud). Voor het collectief kijken we naar Europese, landelijke en bovengemeentelijke samenwerking.

•

Amsterdam erkent dat het als grootste gemeente een belangrijke rol heeft te spelen in deze ontwikkelingen, maar zet daarbij wel in op het ‘peleton-model’: om als hele groep (lokale overheden) gezamenlijk zo snel mogelijk te kunnen gaan wisselen de voorste renners, die het hele peleton voortstuwen, elkaar regelmatig af zodat ook iedereen af en toe middenin het peleton op adem kan komen. Amsterdam gebruikt deze meerjarenstrategie9 daarom ook als lobby strategie, en als basis om te onderhandelen wie er allemaal in het peleton zitten, en wie wanneer aan kop.

4.2 Fase 2: 1 – 4 jaar Aan het einde van de aankomende nieuwe collegeperiode willen we flinke stappen gezet hebben richting digitale autonomie, richting Fase 3. Gaandeweg zullen de concrete mogelijkheden en daarmee de invulling van Fase 3 hierdoor ook meer duidelijk worden. De concrete stappen die in deze periode gezet moeten worden (waarbij de concrete invulling soms pas over 1 of 2 jaar duidelijk kan worden): •

9

We hebben een functionerende (kwalitatieve, veilige, betaalbare) multicloud omgeving met autonome optie(s) voor kritische processen en/of gevoelige data

Waarvan de sourcing- en cloudstrategie een onderdeel uitmaakt

17

Gemeente Amsterdam

o o

o

•

Het concrete aantal/ percentage is afhankelijk van de werkplek & gebruikers analyse die in Fase 1 plaats vindt

We zijn structureel participerend in bovengemeentelijke en/of landelijke initiatieven, en voortrekker (aan kop van het peleton) op geselecteerde onderwerp(en) o

o o

•

30% van onze applicaties staan op een autonoom deel van de cloud Alle bedrijfskritische processen staan op een autonoom deel van de cloud ▪ Dit behelst waarschijnlijk ongeveer of zelfs meer dan de gewenste 30% van het totaal aantal applicaties, dus dan overlappen deze twee doelstellingen. Dit betekent dat er, naast het huidige cloudplatform (nu Microsoft Azure) en de HenT voorziening (in aanbesteding), een nieuwe autonome optie bij moet komen (indien er binnen dit tijdsbestek al collectieve opties beschikbaar zijn, participeren we daarin)

Tenminste een deel van de werkplekken is autonoom georganiseerd o

•

Pagina 18 van 31

Belangrijke ontwikkelingen (op dit moment) zijn hierin onder andere common ground, en de samen slim-methodiek (‘samen slim functionaliteit ontwikkelen’, ‘samen slim inkopen’, ‘samen slim souverein’) vanuit de G4/ VNG. In Fase 1 gaat de VNG 3 collectiveringsvoorstellen (covo’s) uitrollen, waarvan tenminste 1 op digitale autonomie Omdat er op dit moment veel collectieve initiatieven lopen geeft Amsterdam prioriteit aan de volgende drie routes: ▪ Via G4 aansluiten bij ontwikkelingen van de VNG en NDS ▪ Ontwikkelingen bij voorkeur zo breed mogelijk (binnen de NDS) ▪ Kennisontwikkeling via het Digitale Autonomie Competentie Centrum (DACC), waarin Amsterdam participeert via het AMS-instituut

We hebben eigen kennis en kunde opgebouwd rondom de uitdagingen van digitale autonomie o o

o

Technisch: beheer en ontwikkeling van de multicloud Inkoop: hoe bij inkoop en aanbesteding zo sterk mogelijk op autonomie aan te sturen ▪ Dit is deels bestaande kennis, maar vooral ook lobby en input bij de aanpassing van bestaande en nieuwe wetten (bv voor meer mogelijkheden in de aanbestedingswetgeving, meer samenwerkingsmogelijkheden tussen de verschillende overheidslagen in Nederland) Amsterdam doet dit waar mogelijk binnen samenwerkingsverbanden zoals het DACC (Digitale Autonomie Competentie Centrum)

18

Gemeente Amsterdam

Pagina 19 van 31

4.3 Fase 1: 1 -2 jaar (2026 - 2027) De inzet voor de aankomende periode bestaat uit twee delen: een aantal pilots en activiteiten om de basis op orde te krijgen. De basis op orde activiteiten zijn essentieel voor vrijwel elke richting die de ontwikkelingen rondom digitale autonomie in de toekomst gaan nemen. Deze zullen we dus sowieso goed geregeld moeten hebben om de volgende stappen richting meer digitale autonomie, welke dat ook gaan zijn, te kunnen zetten. Of we over 10 jaar nu werken met een landelijk ontwikkelde Rijkscloud, een intensieve samenwerking met een nieuwe Nederlandse cloud-provider of we bouwen alles helemaal zelf, de basis moet daarvoor op orde zijn (zie de volgende paragraaf). De voorgestelde pilots lijken per stuk optioneel, maar zijn nodig om kennis en ervaring op te bouwen met de nieuwe manier van werken die nodig gaat zijn om meer autonoom te worden. Bijvoorbeeld, ongeacht bij welke werkplek-provider we uiteindelijk uitkomen, er moet begonnen worden met pilots op gebied van de digitale werkomgeving (werkplek) om ervaring op te bouwen met een omgeving waar meerdere werkomgevingen naast elkaar staan, waarin we alternatieven van de markt onderzoeken en de markt ook willen uitdagen hiermee te komen.

En de pilot gericht op samenwerking met het Logius Standaard Platform levert veel praktische kennis en ervaring op over het werken met meerdere cloud-aanbieders, samenwerking met landelijke overheidsdiensten op het gebied van cloud en het opbouwen van technische kennis rondom beheer van de cloud. Iets dat de afgelopen jaren allemaal bij Microsoft en beheerpartijen was belegd. En hoewel het een pilot is, zou deze samenwerking ons zomaar nu al een stap(je) richting de doelstelling van 30% autonoom kunnen brengen. Zo is elke voorgestelde pilot opgezet als zowel een leerdoel, en als een praktische stap voorwaarts richting meer digitale autonomie. De uitwerking van de pilots staat beschreven in hoofdstuk 6.

4.4 De basis op orde Hoewel de toekomst nog verre van zeker is, weten we nu al wel ongeveer welke kant Amsterdam op wil gaan met digitale autonomie (Fase 3). Dat maakt dat, ongeacht welke richting de technische, maatschappelijke en juridische ontwikkelingen rondom digitale autonomie nemen, we sowieso een aantal basiszaken op orde moeten krijgen. Zodat Amsterdam klaar staat om verdere stappen te nemen zodra deze zich aandienen. Met deze basis op orde kan direct begonnen worden, en een deel zal ook al in 2026 afgerond kunnen worden. Sommige zaken zijn veel breder in scope, en zullen tot in 2027 (of verder) doorlopen. Daar waar dit nu al bekend is, is dit aangegeven. Tenslotte, deze inhaalslag is niet alleen zinvol voor digitale autonomie, maar geeft de gemeente in het algemeen meer grip en controle op haar digitale processen, ook voor toekomstige nieuwe uitdagingen. Het gaat om de volgende activiteiten: -

Scheiden van data en applicaties (zodat zowel data als applicaties makkelijker individueel verplaatst kunnen worden als nieuwe, autonomere, opties zich aandienen o

Bijna 80% van onze applicaties is SaaS, waarvan bij het grootste deel data en applicatie nog verweven is.

19

Gemeente Amsterdam

o o o -

Pagina 20 van 31

Deels betekent dit dat SaaS-functies overgezet moeten worden naar de huidige cloud, ook al is dit nu (nog) Microsoft Azure Dit gebeurt op basis van een nieuwe beoordeling van SaaS-applicaties op de nieuwe digitale kernwaarde Autonomie Deze scheiding zal dan ook (veel) langer duren dan 2026

Kritische functies, applicaties en andere onderdelen van de informatievoorziening in kaart brengen en inventariseren welke randvoorwaarden nodig zijn om deze autonomer te maken o

-

-

Er zijn momenteel diverse inventarisaties, met elk een ander oogmerk. Er is een centrale, actuele lijst nodig van kritische processen, conform vaste criteria ▪ Gereed in 2026 Gevoelige data in kaart brengen o Hiervoor moet alle data van de gemeente geclassificeerd worden, wat een aanzienlijke klus is. Er gaat onderzocht worden hoe dit praktisch en handig aangevlogen kan worden. ▪ Gereed in 2027 In gebruik name van de nieuwe sourcing- en cloudstrategie o

o

-

Verdieping aanbrengen op de nieuwe cloud-strategie o

-

Het adagium van de oude sourcing- en cloudstrategie was: SaaS boven PaaS boven IaaS. Het adagium van de nieuwe strategie is: (collective) reuse before buy before build Hiermee worden alle nieuwe vragen vanuit de lijndirecties op zo autonoom mogelijke wijze ingevuld ▪ Gereed in 2026

De nieuwe sourcing- en cloudstrategie richt zich voornamelijk op het sourcingdeel, omdat het cloud-deel nog te veel onbekendheden bevat. Werkend richting een multicloud omgeving moet regelmatig opnieuw gekeken worden naar de cloud-strategie, en deze worden bijstellen ▪ Doorlopend (2026 en verder)

Clusteren van bestaande applicaties en datasets o

Zelfs als dit betekent dat er dan toch gemigreerd moet worden naar de huidige (Microsoft Azure) cloud

o

Omdat sommige migraties simpelweg niet kunnen wachten 10 op een autonome cloud, omdat het bijeenbrengen van functies op de huidige (niet-autonome) cloud ook helpt om straks sneller meer functies over te zetten naar een wel-autonome cloud, en omdat sommige functies ook in de toekomst, conform onze ambities,

10

Bijvoorbeeld omdat de huidige infrastructuur niet veilig of functioneel meer is, er contracten aflopen die moeilijk (duurder, minder kwaliteit) verlengd kunnen worden of omdat we functies zelf willen ontwikkelen waarvoor de azure cloud nu de enige realistische landing-plek is

20

Gemeente Amsterdam

Pagina 21 van 31

op een niet-autonome cloud zouden mogen blijven staan (als het om nietkritische processen of data gaat) o

-

Inrichten van een interne structuur rondom digitale autonomie o o o

-

Dit gaat in tegen een eerdere wens van de raad, om geen enkele migratie naar de Microsoft Cloud meer uit te voeren. In de praktijk kan dit echter juist belemmerend werken voor het bereiken van meer autonomie. Uiteraard zal de wens van de raad gevolgd worden door elke migratie aan de Wethouder voor te leggen, en de raad te informeren. ▪ Doorlopend (2026 en verder)

Zodat ook op langere termijn urgentie en actualiteit behouden blijft Zodat gestructureerd aangesloten kan worden bij externe ontwikkelingen (bv vanuit de NDS, VNG, G4) Gekoppeld aan de CIO-stelselverantwoordelijkheid ▪ Gereed in 2026

Aanpassen werkwijze inkoop, aanbestedingen en contractbeheer o

Deels komt dit uit de pilot 3, maar deels zijn er al lessons learned, bijvoorbeeld uit de situatie rondom Solvinity. Deze kunnen nu al doorgevoerd worden in nieuwe aanbestedingen en contracten. ▪ Al gestart in 2025, loopt door in 2026 (e.v.)

21

Gemeente Amsterdam

Pagina 22 van 31

5 Kosten digitale autonomie

5.1 Kostenramingen digitale autonomie: NDS Vanwege de grote onzekerheid is het niet goed mogelijk om een accurate inschatting te geven van de kosten van digitale autonomie voor de gemeente Amsterdam in de komende jaren. Er zijn wel twee recente berekeningen uitgekomen die een globaal idee kunnen geven van de orde van grootte van de investeringen die nodig zullen zijn. Ten eerste is er de brief met de voorlopige investeringsagenda voor de Nederlandse Digitaliseringsstrategie (NDS) 11 die voormalig staatssecretaris Van Marum in november naar de Tweede Kamer stuurde. Hierin staat een raming van de kosten die van 2026 tot en met 2030 nodig zijn voor de uitvoering van de verschillende onderdelen van de NDS. Zoals in de tabel hieronder te zien is (overgenomen uit de brief van Van Marum) zijn de kosten voor de NDS uitgesplitst in een aantal categorieën. De activiteiten die overeenkomen met de activiteiten die Amsterdam moet uitvoeren om meer digitaal autonoom te worden, staan in de volgende drie categorieën: -

-

Data (het aanpassen van de databronnen en de wijze waarop met data gewerkt wordt, onder andere op basis van brede standaarden, om deze vervolgens in een autonome en flexibele oplossing onder te kunnen brengen) Cloud (het realiseren van overheidsbrede soevereine cloudoplossingen) Digitale weerbaarheid en autonomie (alle overige kosten die met autonomie gepaard gaan, zoals die ook in deze meerjarenstrategie naar voren komen)

De totale kosten voor digitale autonomie binnen de NDS is grofweg de optelling van deze drie posten, waarbij Data voor de helft wordt meegerekend omdat daar ook nog andere zaken onder vallen die niet essentieel zijn voor digitale autonomie. Daarom komen deze kosten op:

11

https://open.overheid.nl/documenten/0d842ed5-cf22-47ab-9501-49c492519908/file

22

Gemeente Amsterdam

Pagina 23 van 31

2026

2027

2028

2029

2030

Structureel p/j

242,5

417,5

545

637,5

725

392,5

In hoeverre deze investeringen ruimte gaan bieden voor Amsterdam om initiatieven te ontplooien, of dat er juist gekeken wordt naar investeringen vanuit (aan de NDS) deelnemende gemeenten om deze kosten juist te dekken, is nog onduidelijk. Het is daarom wenselijk om het streven naar digitale autonomie in Amsterdam niet in al te grote mate afhankelijk te laten zijn van de NDS. In het ergste geval zou dit kunnen betekenen dat de Rijkscloud als optie binnen de multicloudstrategie wegvalt. Ook dan zijn er nog zeker mogelijkheden zoals het zelf ontwikkelen of inkopen van een Nederlandse/ Europese autonome cloud. De uiteindelijke mate van autonomie zal echter zonder een vorm van autonome Rijkscloud vanuit de NDS wel mogelijk minder groot worden.

5.2 Kostenramingen digitale autonomie: Deloitte Omdat de indicatie vanuit de NDS gericht is op digitale autonomie van de gehele overheid, is aan Deloitte consultancy gevraagd om, vanuit haar ervaring met deze trajecten bij grote organisaties en zeer actuele kennis van de markt, de specifieke Amsterdamse uitdaging op autonomie voor de komende 10 jaar beter in kaart te brengen. Een samenvatting van deze vingeroefening van Deloitte vindt u in de meerjarenstrategie. In haar rapportage geeft Deloitte daarbij aan dat een volledig beeld niet mogelijk is, met name omdat een aantal aspecten buiten beschouwing (‘buiten scope’) gelaten moest worden vanwege te weinig concrete inzichten of houvasten (deels vanuit de gemeentelijke organisatie, deels vanuit de markt). Wel heeft Deloitte, op basis van de huidige situatie van de gemeente en de inkoopkalender (welke contracten met grote invloed op digitale autonomie lopen er in deze periode af) vijf onderwerpen geïdentificeerd waar autonomie een grote rol speelt, en een overzicht kunnen maken van de kosten als we deze vijf zouden migreren naar autonome oplossingen. Het gaat daarbij om: -

Digitale werkomgeving (werkplek) Cloud (de huidige Microsoft Azure omgeving) Systeem Vernieuwing Werk en Inkomen (SVWI) Amsterdam Financieel Systeem (AFIS) Programma Interactie met de Amsterdammer (PRIMA)

Dit behelst uiteraard maar een deel van het IV-landschap, en beslaat een totale uitgave van ongeveer 41 miljoen euro (uit een totale IT-uitgave van ongeveer 240 miljoen euro). Om dit autonoom te maken komt Deloitte op de volgende meerkosten:

23

Gemeente Amsterdam

Pagina 24 van 31

De bovenste lijn zijn de ‘huidige operationele kosten’ zonder extra inzet op autonomie, met als peilbedrag 41M in 2026, en daarna geïndexeerd naar de verwachtte kosten bij gelijkblijvend gebruik en dienstverlening. Het staafdiagram geeft aan wat de kosten per jaar zouden zijn bij inzet op zo groot mogelijke autonomie. Dit is een optelling van de ‘alternatieve operationele kosten’ (= OPEX) en de ‘kosten verandering (eenmalig)’ (=CAPEX). Het verschil daartussen is weergegeven in ’verschil in kosten per jaar’ (= verschil tussen de groene lijn en de toppen van het staafdiagram per jaar). Kort gezegd kost digitale autonomie, op dit deel van het IV-landschap, de komende 10 jaar ongeveer 4,6 miljoen euro gemiddeld extra per jaar en in totaal 24 miljoen euro extra over dezelfde 10 jaar. Dat is gemiddeld 7 miljoen euro per jaar tot en met 2035. Zoals gezegd, dit gaat over een deel van het IV-landschap, maar wel een belangrijk deel. Ook deze berekening is wederom als (grove) indicatie bedoeld, maar geeft qua omvang en looptijden een vergelijkbaar beeld als de raming van de NDS.

24

Gemeente Amsterdam

Pagina 25 van 31

5.3 Kosten voor Fase 1 (2026 - 2027) Voor veel van de verwachtingen en ramingen is het lastig om echt concreet te worden. De grote onzekerheid in de nabije toekomst op dit onderwerp maakt het maken van inschattingen moeilijk. Toch kan er wel met concrete dingen gestart worden. In Hoofdstuk 6 staan een aantal concrete pilots genoemd, waarvan de kosten duidelijk zijn. En we weten ook wat er nodig is om de basis op orde te krijgen. Veel van die werkzaamheden vallen binnen de bestaande bezetting van de directies binnen het cluster Digitalisering. Om het geheel te realiseren zal er echter op verschillende onderwerpen stevig extra ingezet moeten worden. Ook is het geheel aan maatregelen, pilots en veranderingen die in deze meerjarenstrategie staan beschreven samen dermate omvangrijk, zeker voor het werk van het cluster Digitalisering, dat er enige extra coördinatie op nodig is. Tenslotte zal gaandeweg steeds vaker verwacht worden dat vanuit Amsterdam inzet geleverd wordt op gezamenlijke projecten met G4, VNG en NDS. Voor de extra inzet op de uitvoering van de basis op orde werkzaamheden, de landelijke inzet en de coördinatie op het streven naar digitale autonomie in het geheel zal in totaal ongeveer 5 FTE (= € 600.000) personeel en € 500.000 technische middelen nodig zijn.

Hiermee komen de totale kosten voor Fase 1 (uitgegaan van de nog niet gedekte onderdelen van de pilots, zoals aangegeven in Hoofdstuk 6) op: Basis op orde

€ 1.100.000

Pilots Digitale werkomgeving -

Alternatief NextCloud BBN2+ dataopslagdienst Extra dataopslag als alternatief voor SharePoint

€ 500.000 – € 1.000.000 € 50.000 € 100.000 – € 200.000

Rijkscloud -

Logius Standaard Platform

€ 540.000 – € 1.200.000

Artificial Intelligence -

Verkenning autonome AI

€ 775.000

Inkoop en aanbesteding -

Kennis en expertise verwerving

Totaal Fase 1

€ 150.000 € 3.215.000 –

€4.475.000

25

Gemeente Amsterdam

Pagina 26 van 31

5.4 Totale kosten digitale autonomie 2026 – 2035 In dit hoofdstuk zijn enkele indicaties gegeven die hopelijk enig inzicht bieden in de te verwachten kosten voor het streven naar meer digitale autonomie. Voor Fase 1, in 2026 (en deels 2027) is een vrij concrete menukaart van basis op orde activiteiten en pilots beschikbaar. Voor Fase 2 en zeker Fase 3 is er alleen een tweetal ramingen met grove indicaties. Deze geven echter alleen een beeld van de omvang die, naar nu verwacht is, fors zal zijn zelfs als alleen de kritische processen en meest gevoelige data autonoom moet worden. Naar mate het streven naar meer digitale autonomie vordert zullen de volgende fasen concreter (en daarmee herijkt) worden, maar voor nu is dit het beeld. Gezien de timing van deze meerjarenstrategie (vanaf 2026) versus de start van het nieuwe college (vermoedelijk Q2 2026) zullen de activiteiten en werkzaamheden die zonder extra dekking mogelijk zijn alvast in gang gezet worden, danwel doorgaan waar ze al gestart zijn. Met name voor de basis op orde activiteiten is dit van aanzienlijk belang. Door te schuiven met inzet van bestaand personeel en het aanpassen van bestaande projecten (kleiner en/of later) zal getracht worden zoveel mogelijk van de voorgestelde basis op orde activiteiten uit te voeren.

Echter, dit is geen duurzame oplossing en het is van belang dat mid-2026 er meer duidelijkheid komt over de ambities van de gemeente Amsterdam over de mate van digitale autonomie die zij na wil streven voor de data en dienstverlening van haar bewoners.

26

Gemeente Amsterdam

Pagina 27 van 31

6 Pilots en experimenten in Fase 1 (2026)

6.1 Digitale werkomgeving Met de digitale werkomgeving wordt de digitale werkplek van Amsterdamse ambtenaren bedoeld, oftewel de kantoorautomatisering. Op dit moment is dat Office 365 van Microsoft. Kijkend naar de belangrijkste onderdelen daarvan wordt meteen duidelijk hoe sterk Microsoft verweven is in ons praten en denken over kantoorwerk: -

Email (Outlook) Tekstverwerking (Word) Spreadsheets (Excell) Presentaties (Powerpoint) Communicatie via chat en video overleg (Teams) Samenwerken in en delen van bestanden (Teams en SharePoint) Bestandenopslag (Onedrive)

En niet alleen deze applicaties, maar ook de data die hierbij opgeslagen wordt (documenten, communicatie, contactgegevens, emails) staan in de cloud bij Microsoft. Weliswaar in Europese datacentra, maar daarmee nog steeds binnen bereik van de Amerikaanse overheid. De kantoorprocessen zijn de basis van het werk van de gemeente, en daarmee kritiek voor haar functioneren. En de informatie die daarbij verwerkt wordt is vaak erg gevoelig. Door de dominantie van Microsoft (zowel thuis als op verreweg de meeste kantoor omgevingen) is het voor veel mensen moeilijk voor te stellen, maar al deze functies kunnen ook door andere leveranciers geleverd worden. Om deze stap later te kunnen zetten, moeten we beter beeld krijgen van de mogelijkheden op de markt, de stappen die andere overheidspartijen hierin zetten en de gevolgen voor onze interne organisatie. Hiervoor starten we in 2026 met de volgende drie pilots.

6.1.1 NextCloud Dit project richt zich op het praktisch uitvoeren van een pilot om te testen of het open-source product NextCloud als Europees alternatief kan dienen voor de huidige Office-functionaliteit van Microsoft. In samenwerking met Sogeti (onze dienstverlener op de digitale werkomgeving) en de VNG wordt een voorstel uitgewerkt voor een pilot met een groep medewerkers op NextCloud. Het doel is om praktijkervaring op te doen over de effectiviteit van een alternatief, de verbinding tussen een alternatief en de huidige Office-omgeving, de wijze van inzetten (gebruiken we ze naast elkaar, of de een als backup voor de ander), inzicht in de verschillende typen medewerkers en daarbij benodigde werkomgeving en de criteria op basis waarvan selecties gemaakt kunnen worden in het soort digitale werkomgeving. Idealiter laat deze pilot ons zien welke mogelijkheden