Sourcing en cloudstrategie 2026 - 2030.docx

Sourcing- en cloudstrategie 2026 - 2030

Oplegger bij de Sourcing- en cloudstrategie (2026 - 2030) Onze IT-dienstverlening van de gemeente gaat uit van een simpele vergelijking: Continuïteit + efficiënt gebruik + privacy = vertrouwen van onze burgers. Dit betekent dat we onder alle omstandigheden goede dienstverlening aan onze bewoners, ondernemers en bezoekers (de BOB) bieden. De geopolitieke omstandigheden waarin onze stad en ons land zich bevinden zijn snel onvoorspelbaarder geworden. Dit kan impact hebben op de continuïteit van onze dienstverlening en brengt mogelijk nieuwe risico’s met zich mee1. Dit vraagt om een nieuwe blik op hoe we onze dienstverlening inrichten en hoe we met andere overheden en leveranciers samenwerken. De Sourcing- en cloudstrategie 2026 - 2030 neemt deze nieuwe realiteit expliciet mee in de afweging hoe we inkopen en waar ons landschap gehost wordt, met extra aandacht voor soevereiniteit, veerkracht en strategische afhankelijkheden binnen een snel veranderend geopolitiek speelveld.

De focus op digitale autonomie Op 28 maart 2024 heeft de gemeenteraad van Amsterdam unaniem ingestemd met het gewijzigde initiatiefvoorstel Amsterdam Digitaal Onafhankelijk van raadslid IJmker2. 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 worden3. Niet omdat de huidige leveranciers geen goed werk leveren, maar omdat we zelf onze keuzes willen blijven maken. We willen de privacy van inwoners, organisaties en bedrijven beschermen en onze digitale veiligheid versterken. Dit is een trendbreuk met de strategie 2021-2025 waar de public cloud altijd de voorkeur had en digitale autonomie geen onderdeel was van de strategie. Hieruit volgt het principe ‘autonomie, tenzij..’, waarbij het streven is om autonome keuzes te maken, tenzij deze praktisch of financieel (nog) onmogelijk zijn. Verdere intensivering op samenwerking met andere (nationale) overheden moet de praktische mogelijkheden vervolgens gaan verbreden. Amsterdam staat hierin niet alleen. Digitale autonomie en samenwerking zijn belangrijke pijlers van de nieuwe Nederlandse Digitaliseringsstrategie (NDS)4. 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 leveranciers-management bij voorkeur in samenhang en op schaal worden ingericht.

1 Rapport verkenning digitale autonomie - 5 maart 2025

2 Raadsvoordracht gewijzigd initiatiefvoorstel ‘Amsterdam digitaal onafhankelijk’ van het lid IJmker 3 Rapport verkenning digitale autonomie - 5 maart 2025

4 Nederlandse Digitaliseringsstrategie - prioriteit 5: versterken digitale weerbaarheid en autonomie van de overheid

Daarnaast hebben zowel Amsterdam5 als het Rijk de ambitie om in 2030 30% van clouddiensten in Europese (EER) publieke en private clouddiensten onder te brengen (zonder mogelijke inmenging door andere statelijke partijen). Door samenwerking kunnen we kennis delen, sneller bewegen en onze digitale weerbaarheid vergroten. Daarom werkt Amsterdam samen met de Vereniging van Nederlandse Gemeenten (VNG)6, de vier grote steden (G4) 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 op onze eigen eilanden blijven opereren. Tot slot ziet Amsterdam digitale autonomie als een versneller voor andere strategische doelen, zoals duurzaamheid. In de huidige situatie hebben we te maken met een markt die voornamelijk door monopolisten beheerst wordt en dat betekent dan ook dat onze duurzaamheid afhankelijk is ambities van de monopolisten. Door meer keuzevrijheid voor onszelf in te bouwen, zorgen we ervoor dat we ook voor ons IT-landschap in de toekomst kunnen kiezen voor duurzame alternatieven.

Wat verandert er ten opzichte van situatie 2025 De verandering is een optelsom van: ▪ De instemming van het College van B&W met twee moties op de ALV VNG, te weten: - Resolutie ‘Als één sterke bestuurslaag regie op de digitale samenleving’. Daarmee spreken we -gemeenten- de bereidheid uit om samen de regie te pakken op alle digitale zaken waarvan inwoners niet verwachten dat gemeenten zich daarop onderling van elkaar onderscheiden. Naar verwachting is dat minstens 80% van al onze digitalisering. - Propositie ‘Realisatiekoers Common Ground’. Dat is het eerste collectiveringsvoorstel dat volgt uit de resolutie ‘Als één sterke bestuurslaag regie op de digitale samenleving’. Het voorstel introduceert een vorm van samenwerking waarin gemeenten hun opdrachtgeverschap professionaliseren en gezamenlijk de regie nemen over het ontwikkelen en delen van digitale voorzieningen. Gemeenten starten met het domein van digitale dienstverlening en pakken daarna elk domein apart op.

▪ De initiatiefnota ‘Amsterdam Digitaal Onafhankelijk’ en de daaropvolgende moties in de Raad, zoals - Maak digitale autonomie concreet, waaronder ‘in ieder geval het doel om vóór 2030 voor minimaal 30% van de cloudopslagdiensten en cloudapplicaties gebruik te maken van Nederlands-Europese leveranciers’ - Maak het mogelijk om over te stappen naar andere providers; - Sluit aan bij Overheidscloud initiatief; - Conformeren aan de Haven standaard; - Afhankelijkheid van Microsoft niet laten groeien; 5 Motie 158 van de leden IJmker, Garmy en Belkasmi inzake maak digitale autonomie concreet 6 VNG nieuwbericht: Gemeenten zetten koers naar collectieve digitalisering

Aansluiten bij open-source initiatieven. Sturen onder Enterprise architectuur om het informatiedomein meer samen te laten werken als één geheel, zoals uitgaan van generieke voorzieningen; Bestaande noodzaak tot dataclassificatie om vertrouwelijke gegevens goed te borgen; Doorontwikkeling van de voorafgaande Cloudstrategie 2020-2025 waarbij Multicloud al het toekomstige groeipad was; De lessen uit Businesscontinuïteitsmanagement (BCM) om meer waarborgen te creëren voor de continuïteit van dienstverlening. Daarnaast speelt de eerdergenoemde maatschappelijke aandacht voor digitale autonomie en digitale weerbaarheid een rol.

-

▪ ▪ ▪ ▪ ▪

Er zijn een aantal significante wijzigingen ten opzichte van de vorige sourcingstrategie- en Cloudstrategie: ▪

▪

▪ ▪

▪

▪

▪

▪

▪

We werken bij bedrijfskritische processen en gevoelige data met het principe ‘Autonoom, tenzij..’, waarbij de ‘tenzij’ alleen bedoeld is om te voorkomen dat we voor praktische, juridische of financiële onmogelijkheden komen te staan. We willen de beste diensten voor Amsterdammers, veilig, autonoom en betaalbaar. Daarvoor zullen we naast kwaliteit, prijs, veiligheid, innovatie, duurzaamheid en social return nu ook autonomie moeten afwegen. Autonomie is daarom toegevoegd als één van de belangrijk(st)e afwegingen in het inkoopproces. We maken in de beslisboom om te komen tot keuzes in de sourcing het onderscheid tussen bedrijfskritisch en niet-bedrijfskritisch. Hiermee houden we de opgave behapbaar. We kiezen in de beslisboom om te komen tot keuzes in de sourcing in eerste instantie voor landelijke generieke diensten. Dat past in de ambitie om aan te sluiten bij de Nederlandse Digitaliseringsstrategie. We bewegen toe naar een model met meerdere clouddiensten (multicloud) in plaats van public cloud als enige uitgangspunt. Public cloud (optie 1) blijft één van de mogelijkheden, maar we opteren steeds meer voor het gebruik van de Overheidsscloud (optie 2). Op termijn zullen (tenminste) alle bedrijfskritische processen hierop draaien. Daarnaast zullen we SaaSoplossingen (optie 3) blijven gebruiken, maar minder. En ook bij SaaS is autonomie toegevoegd aan de afwegingen hoe we inkopen.

Naast het draaien van bedrijfskritische processen en vertrouwelijke data in soevereine cloudomgevingen binnen de Europese Economische Ruimte (EER, en zonder mogelijke inmenging door andere statelijke partijen), richten we ons ook op toekomstige technologieën, zoals AI-toepassingen. Deze worden waar mogelijk soeverein-by-design ingericht om strategische controle en veiligheid te waarborgen. De Sourcing- en cloudstrategie is er voor de hele gemeente. Vanuit de stelselverantwoordelijkheid stuurt en rapporteert de CIO aan het college over de naleving van de Sourcing- en cloudstrategie. Voorafgaand aan de "vraag uit de business" wordt er een strategische portfolio planning gemaakt en wordt er gewerkt onder stedelijke architectuur. Dit is een IT-meerjarenplanning (inclusief begroting) die door de CIO voor elk nieuw college wordt gepubliceerd. We komen terug op het besluit dat het aantal generieke voorzieningen niet uitbreidt. We zullen actief, samen met andere onderdelen van de overheid, werken aan (waar mogelijk collectieve) generieke voorzieningen.

▪ ▪

▪

De koers om het applicatielandschap drastisch te verkleinen wordt voorgezet en versterkt door het denken in functies en werken vanuit (landelijke) generieke voorzieningen. We sourcen functies en geen oplossingen. Dit om de hoeveelheid applicaties te verminderen en beter gebruik te kunnen maken van generieke voorzieningen. Dit betekent dat we weg bewegen van applicatie 1:1 te vervangen en toe bewegen naar een meerjarenplan per domein. We gaan uit van sturen onder architectuur en strategie. Dit betekent een meer dwingende sturing op technologiekeuze richting de lijndirecties. Het uitgangspunt zijn landelijke generieke voorzieningen en de doelstelling om (uiteindelijk) 80% van de generieke diensten met andere gemeenten in te kopen7. Er zal daarom eerst gekeken worden of de functie onder de landelijke lijst generieke voorzieningen valt. Als deze beschikbaar is, dan heeft deze methode de voorkeur. Hierin sorteren we expliciet voor op het gebruik van de Overheidscloud. Als deze wel beschikbaar is maar niet voldoende aan de vereisten voldoet, kan er tijdelijk gebruik gemaakt worden van de lokale inkooproute (conform het principe ‘autonomie, tenzij’). In dat geval volgt wel ook een migratieplan om ervoor te zorgen dat we op een later moment alsnog aansluiten.

7 VNG-resolutie Als één sterke bestuurslaag regie op de Digitale Samenleving - 21 mei 2025

Sourcing- en cloudstrategie (2026 - 2030) Inleiding Dit is de Sourcing- en Cloud strategie voor 2026-2030. Deze strategie is opgesteld ter vervanging van de IT-sourcingstrategie en de Cloudstrategie 2021-2025, die aflopen. Daarnaast vraagt het raadsinitiatief Amsterdam Digitale Onafhankelijk en aanverwante moties om een koerswijziging om te streven naar digitale autonomie. Deze vernieuwing en koerswijziging vormen de basis voor de Sourcing- en cloudstrategie (2026 - 2030). Digitale autonomie wordt door het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties als volgt omschreven in de Nederlandse Digitaliseringstrategie (NDS): Nederland focust (samen met de EU) op de eigen strategische autonomie, ook in de digitale wereld. Dat betekent niet dat we alles zelf gaan doen, maar wel dat we onze kritieke processen en gegevens beter onder controle krijgen. Wij gebruiken dezelfde definitie voor deze strategie en de activiteiten daaromheen.8 Deze strategie bouwt voort op eerder ingeslagen paden en sluit aan bij bestaande beleidslijnen. Daarom moet zij in samenhang worden gelezen met de volgende documenten: ▪ Naar betrouwbare en professionele digitalisering Versie 1.1 - 20 mei 20259 ▪ Dataclassificatie10 ▪ Bedrijfskritische en niet-bedrijfskritische processen welke jaarlijks worden vastgesteld door het GMT11.

Wat is de Sourcing- en cloudstrategie? Deze strategie is geen ‘routekaart’ van A naar B, maar is een van de onderdelen van de (hierna volgende) meerjaren-strategie Digitale Autonomie, en geeft daarbinnen een praktisch kader voor de keuzes van de sourcing (bouwen of kopen) van alle12 ICT-infrastructuur, clouddiensten, digitale functies en applicaties van de organisatie en waar deze staan. Het is een toetsingskader dat richting geeft aan keuzes bij het nemen van een sourcingbeslissing voor een IT-dienst13. Dit toetsingskader 8 Nederlandse Digitaliseringsstrategie (NDS) 9 GMT - Naar betrouwbare en professionele digitalisering - volgende fase digitale transformatie 10 Dit is de dataclassificatie die gebruikt wordt om de juiste security en privacy maatregelen te nemen. Dit is niet de dataclassificatie openbaar/vertrouwelijk/geheim zoals vastgesteld door het College van B&W. Die classificatie is gekoppeld aan informatie om te voldoen aan de WOO. 11 Het gaat hier om bedrijfskritische processen, vastgesteld door Gemeentelijk Managementteam (GMT) op voordacht van de directie Middelen en Control (DMC). 12 Er is naast de Sourcing en cloudstrategie 2026 – 2030 geen andere strategie die richting geeft aan sourcing en cloudkeuzes. Deze strategie vervangt daarom de IT Sourcingstrategie 2011, de Cloudstrategie 2021-2025 en het Architectuurkader sourcing IT-diensten.

13 Sourcingsbeslissingen, zoals: - Behoefte aan nieuwe of gewijzigde functionaliteit, veelal voortkomend uit projecten of opgaves; - Standaardisatie aan business zijde; - Rationalisatie van het IT –landschap; - Een contract voor een applicatie loopt af;

geldt voor de periode tot en met 2030, en zal daarna herijkt worden, op basis van de dan beschikbare kennis en mogelijkheden.

Wat is het gewenste resultaat? De Sourcing- en cloudstrategie (2026 - 2030) beoogt: 1. Streven naar digitale autonomie om onze weerbaarheid te vergroten: We zijn in staat om strategische keuzes te maken om zorg te dragen dat op de bedrijfskritische systemen en processen en hoog vertrouwelijke data we niet afhankelijk zijn van niet-Europese partijen. Deze systemen, processen en data staan uiteindelijk in soevereine cloud-omgevingen binnen de Europese Economische Ruimte (EER), zonder mogelijke inmenging door andere statelijke partijen14. Hierbij kijken we niet alleen naar het huidige landschap, maar nadrukkelijk ook naar het toekomstige landschap. Functies en toepassingen die nu nog niet bestaan, zoals verschillende AI-toepassingen, richten we waar mogelijk en wenselijk soeverein-by-design in. Dit betekent vooral, dat als bijvoorbeeld een nieuwe AI-toepassing bedrijfskritisch wordt of gevoelige data gaat verwerken, we deze inkopen of ontwikkelen volgens deze strategie. 2. Realistisch stappenplan richting meer autonomie: de uitgangspunten van deze sourcing- en cloud strategie leiden tot ambitieuze stappen richting meer autonomie, maar is ook realistisch en erkent dat sommige (toekomstgerichte) keuzes nog niet altijd beschikbaar, betaalbaar of toegestaan zijn. Daarom hanteren we ‘autonomie, tenzij’ dit leidt tot keuzes die praktisch, juridisch of financieel (nog) onmogelijk zijn.

Afwijkingen worden altijd expliciet en beargumenteerd voorgelegd aan het College van B&W. 3. Veilig omgaan met informatie: Informatie en informatiesystemen worden juist geclassificeerd en opgeslagen op een plek met passende beveiliging. Bedrijfscontinuïteit en dataclassificatie vormen de basis voor het kiezen van de cloud-infrastructuur, dus waar we onze data en applicaties opslaan, zonder de huidige veiligheid en operationele beveiliging te verlagen. Nieuwe cloud-omgevingen betekenen een fragmentatie van IT-landschap en kennen nieuwe risicoprofielen. Kennis over beveiliging en risico’s moet ervoor zorgen dat het beveiligingsniveau onveranderd hoog is en Amsterdam digitaal weerbaar blijft. In de praktijk betekent dit dat specifieke functionaliteiten op het gebied van beveiliging en privacy bij ingebruikname van toekomstige sourcingsopties niet noodzakelijkerwijs opnieuw beschikbaar zijn. We hebben daarom een zorgplicht om mogelijkheden en beperkingen van nieuwe sourcingsopties vooraf met een risicio-assessment te beoordelen. Op deze manier blijven wijzigingen in onze veiligheidssituatie transparant en verlagen we onze tactische en operationele weerbaarheid niet ongemerkt. 4. Regie en governance: We versterken de regie vanuit de Enterprise architectuur en portfoliomanagement op generieke functies15.

Door van tevoren in onze architectuur scherp - Waar moet data of een applicatie landen; - Er wordt een digitaliseringsstrategie voor een specifiek domein gemaakt. 14 Wanneer deze beschikbaar zijn. 15 Zie ‘governance en rapportages’ in dit document voor definitie van functies.

te hebben wat er nodig is en welke vereisten daarbij horen, zijn we minder reactief (en dus afhankelijk) van wat de grote marktpartijen bieden. Deze proactieve houding stelt ons in staat om digitale autonomie sterker mee te wegen tijdens sourcing16. En we versterken onze kennis en kunde op het gebied van aanbestedingen en contract management, zodat we zo scherp mogelijk kunnen zijn in onze inkoopvoorwaarden, met name gericht op meer autonomie (en geen Amerikaanse servers op EU-bodem). 5. Flexibiliteit en weerbaarheid: Met exitstrategieën, migratiestrategieën, multicloud en gebruik van open source (of common ground) zorgen we dat de gemeente niet afhankelijk is van één leverancier en kan blijven functioneren in crisissituaties. Ook zetten we in op overheids-samenwerking en schaalvoordelen. Samen met de Vereniging van Nederlandse Gemeenten (VNG) werken we aan één lijn in het gebruik van cloud en het sourcen van IT-diensten. En we sluiten aan bij het nieuwe cloudbeleid van de Rijksoverheid en volgen we de Nederlandse Digitalisering Strategie (NDS). We zetten daarbij actief in op de (toekomstige) Overheidscloud.

Hoe we komen tot dit resultaat? Om tot zorgvuldige en toekomstbestendige sourcingkeuzes te komen doorlopen we een uniform beoordelingsproces. Dit proces bepaalt op welk niveau (landelijk, lokaal of maatwerk) een digitale voorziening het beste kan worden gerealiseerd, en op welke wijze (hergebruiken, herbruikbaar maken, zelf ontwikkelen of inkopen). Hieronder staat het proces beschreven. De beslisboom aan het einde van het hoofdstuk geeft dit proces visueel weer.

Vraag uit de business (uit een van de lijn directies) Het proces start met een vraag vanuit de business, met een behoefte die voortkomt uit de strategische portfolioplanning of een actuele behoefte vanuit een lijndirectie. Voordat de beslisboom wordt toegepast, moet de vraag zodanig zijn uitgewerkt dat een zorgvuldige sourcing afweging mogelijk is. Hiervoor gelden de volgende randvoorwaarden: • De functionele behoefte is vastgesteld; • Het is duidelijk welke gemeentelijke functie wordt ondersteund; • De samenhang met het portfolio en de architectuur is bekend; • Er is een businesscase beschikbaar. Als deze basis op orde is, wordt getoetst of 1) de functie een bedrijfskritisch proces ondersteunt en 2) welke dataclassificatie van toepassing is. Deze analyse bepaalt niet wat we sourcen, maar wel hoe strikt de eisen zijn voor (eigen) regie en autonomie. • Bij bedrijfskritische processen en/of gevoelige data geldt ‘autonomie, tenzij’, waarbij in principe gekozen wordt voor een zo autonoom mogelijke oplossing tenzij dit praktisch, juridisch of financieel onmogelijk is. In die gevallen wordt de keuze voorgelegd aan het college. Met autonoom wordt bedoeld dat voorzieningen zoveel mogelijk onder eigen regie 16 Onderdeel van de Enterprise architectuur zijn ook de Amsterdamse principes en het inkoopkader Duurzame IT.

•

binnen de EER moeten draaien, bij voorkeur binnen een overheidscloud (en zonder mogelijke inmenging door andere statelijke partijen). Bij niet-bedrijfskritische processen met een lage dataclassificaties zijn worden de waarden autonomie, kosten, kwaliteit, veiligheid, innovatie, duurzaamheid en social return gebalanceerd afgewogen.

Pas wanneer deze stappen zijn doorlopen, wordt de vraag opgenomen in de strategische portfolioplanning en doorloopt zij de beslisboom om de optimale sourcingroute te bepalen.

Landelijke voorzieningen De beoordeling start altijd op landelijk niveau. Vraagt de functie landelijke standaardisatie? Allereerst wordt vastgesteld of de functie vraagt om landelijke standaardisatie (keuze 1). Dit is het geval wanneer: • Deze onder identieke wet- en regelgeving valt voor alle gemeenten; • Deze een generieke gemeentelijke functie betreft die in heel Nederland op vergelijkbare wijze wordt uitgevoerd; • Er interoperabiliteit met landelijke ketens vereist is; • Collectieve ontwikkeling of inkoop duidelijke schaalvoordelen oplevert; • Landelijke samenwerking leidt tot meer digitale autonomie en minder afhankelijkheid van grote leveranciers. Voorbeelden van functies die landelijke standaardisatie vragen: HaalCentraal APIs voor ontsluiting Basisregistraties, en/of BRP-ontsluiting via RvIG en Signalen17. Kan de landelijke voorziening worden hergebruikt? Wanneer is vastgesteld dat de functie landelijk hergebruik vraagt, wordt vastgesteld of dit daadwerkelijk mogelijk is. Zo ja, dan sluiten we aan op de landelijke voorziening (eindpunt A). Wanneer een voorziening nog in ontwikkeling is, of nog niet beschikbaar, wordt beoordeeld of wachten verantwoord is. Indien dat niet het geval is, wordt een tijdelijke uitzondering gemaakt en kijken we naar volgende stappen in de beslisboom.

Gezamenlijk opdrachtgeverschap Wanneer hergebruik niet mogelijk is maar meerdere gemeenten dezelfde behoefte delen, wordt gekozen voor gezamenlijk generiek opdrachtgeverschap (eindpunt B), conform de principes van PIANOo. Gezamenlijk opdrachtgeverschap betekent dat de deelnemende partijen gezamenlijk richting geven aan ontwikkeling of inkoop. Opdrachtnemer kan het Rijk zijn, de VNG, een gemeente (ook Amsterdam zelf), een publiek consortium, een marktpartij of een hybride samenwerkingsverband.

17 Signalen is de Open Source software van, voor en door Nederlandse gemeenten voor het ontvangen en afhandelen

van meldingen uit de openbare ruimte. https://signalen.org/

Lokale voorzieningen Wanneer landelijke standaardisatie niet van toepassing is, wordt vastgesteld of de functie het beste kan worden ondergebracht in een lokale voorziening (keuze 3). Hergebruik of ontwikkeling van een lokale voorziening heeft nadrukkelijk de voorkeur zodra dat binnen de architectuur en autonomiekaders past. Vraagt de functie lokale standaardisatie? Een functie vraagt om lokale standaardisatie wanneer deze: • Past binnen bestaande gemeentelijke voorzieningen (bijvoorbeeld het Cloud- en Dataplatform, Dienst HenT, de Digitale Werkplek, netwerkvoorzieningen). • Een generieke gemeentelijke behoefte vervult die niet landelijk hoeft te worden gestandaardiseerd. Kan de lokale voorziening worden hergebruikt? Indien een passende lokale voorziening reeds bestaat en aansluit op de eisen, wordt deze hergebruikt (keuze 4 -> eindpunt C). Wanneer is vastgesteld dat een functie het beste als lokale generieke voorziening kan worden belegd, maar de voorziening nog niet bestaat, dan wordt beoordeeld of: • Een bestaande lokale voorziening herbruikbaar kan worden gemaakt (keuze 5 -> eindpunt D); • Een nieuwe lokale voorziening moet worden ontwikkeld of ingekocht via lokaal opdrachtgeverschap (eindpunt E).

Lokaal opdrachtgeverschap Wanneer hergebruik of herbruikbaar maken niet mogelijk is, maar meerdere onderdelen binnen de gemeente dezelfde behoefte hebben, wordt gekozen voor gezamenlijk lokaal opdrachtgeverschap. Dit kan zowel gezamenlijke inkoop als gezamenlijke ontwikkeling omvatten.

Maatwerk Indien geen landelijke of lokale voorziening passend of beschikbaar is, resteert maatwerk (keuze 6). Zelf bouwen of inkopen? De keuze tussen zelfbouw en inkoop (keuze 7) wordt gemaakt op basis van een afweging van alle relevante waarden (kosten, kwaliteit, autonomie, veiligheid, innovatie, duurzaamheid). Daarmee wordt de strategische waarde van eigen ontwikkeling vergeleken met de mate waarin marktopties voldoen aan autonomie-, architectuur- en functionele eisen. De onderstaande punten zijn criteria die pleiten voor zelfbouw of voor inkoop; zij vormen geen harde voorwaarden, maar worden in samenhang gewogen. We kiezen voor zelfbouw (eindpunt F) wanneer één of meerdere van de volgende aspecten zwaar wegen: • Autonomie en regie zijn essentieel; • De markt biedt geen passende soevereine of vendor-lock-vrije oplossingen; • Wendbaarheid en iteratief ontwikkelen zijn belangrijk; • Er zijn goede open-source bouwstenen beschikbaar waardoor ontwikkeling efficiënt en beheersbaar kan plaatsvinden.

• •

De functie vormt een strategische publieke bouwsteen die later hergebruikt kan worden. De totale kosten over de levensduur zijn lager bij zelfbouw (inclusief beheer, beveiliging, updates en schaalbaarheid).

We kiezen voor inkoop (eindpunt G) wanneer één of meerdere van de volgende aspecten zwaar wegen: • De functie betreft een generieke of gestandaardiseerde behoefte waarvoor de markt een volwassen, breed beschikbare en kwalitatief betrouwbare oplossing heeft. • De functionaliteit heeft geen onderscheidend karakter voor de gemeente, en standaardproducten in de markt sluiten afdoende aan op de behoefte. • Marktopties voldoen aan de eisen voor veiligheid en open standaarden en creëren daarmee geen ongewenste afhankelijkheden. • De totale kosten over de levensduur zijn lager bij inkoop (inclusief beheer, beveiliging, updates en schaalbaarheid).

Cloudkeuze Na het vaststellen van de sourcingroute volgt de keuze voor de cloudomgeving. Doordat er verschillende keuzemogelijkheden zijn, bewegen we dus nadrukkelijk naar een situatie waarin meerdere cloudopties naast elkaar bestaan, ook wel multi-cloud genoemd. Deze keuze wordt bepaald door de uitgangspunten die eerder tijdens de analyse zijn getoetst (bedrijfscontinuïteit en dataclassificatie). Indien het een bedrijfskritisch proces betreft, worden het proces en de bijbehorende data onder eigen regie gebracht (eindpunt H). Dit betekent dat de voorziening wordt ondergebracht in een soevereine cloud binnen de Europese Economische Ruimte (EER) of binnen de Overheidscloud (en daarmee zonder mogelijke inmenging door andere statelijke partijen). Indien het proces niet-bedrijfskritisch is, maar de dataclassificatie Hoog of Midden is, gelden eveneens aanvullende eisen ten aanzien van opslaglocatie en beheer. Bij een lage dataclassificatie en een niet-bedrijfskritisch proces gelden geen aanvullende eisen (eindpunt I).

Governance en rapportages De Sourcings- en cloudstrategie is er voor de hele gemeente. Vanuit de stelsel-verantwoordelijkheid stuurt en rapporteert de CIO aan het college over de naleving van de Sourcings- en cloudstrategie. De dagelijks sturing gebeurt onder architectuur en portfoliomanagement en volgt het integraal plan architectuur18. Voorafgaand aan de "vraag uit de business" wordt er een strategische portfolio planning gemaakt en wordt er gewerkt onder stedelijke architectuur. Dit is een IT-meerjarenplanning als onderdeel van de digitale strategieën per domein. In deze aanpak staan functies19 en processen centraal en wordt er vanuit de samenhang gestart. We sourcen functies en géén oplossingen. Dit om de hoeveelheid applicaties te verminderen en beter gebruik te kunnen maken van generieke voorzieningen. Een functie wordt als volgt gedefinieerd: ▪ Bedrijfsfuncties leveren producten en diensten. Bedrijfsfuncties beschrijven de bijdrage van taken of activiteiten van een organisatie onafhankelijk van de inrichting. Verschillende taken kunnen tot eenzelfde bedrijfsfunctie behoren. ▪ Voorbeeld: de bedrijfsfunctie "Schoonmaken" kan worden gerealiseerd door de taken stofzuigen en dweilen. ▪ Bedrijfsfuncties zijn samen met de gerelateerde taken een logische eenheid waarin activiteiten zijn gegroepeerd waarvoor vergelijkbare bedrijfsmiddelen, kennis of competenties nodig zijn.

Elke bedrijfsfunctie kent bepaalde taken en verantwoordelijkheden. ▪ We gebruiken dit functiemodel als basis om generieke voorzieningen te definiëren, zowel binnen de stad zodat we hergebruik bevorderen als landelijk om gezamenlijk inkoop te bevorderen. We gebruiken twee verschillende rapportages om voorgang te meten en te communiceren: 1) In de kwartaalrapportage van de verschillende clusters wordt gerapporteerd over de voortgang en uitzonderingen per cluster. 2) We rapporteren20 het college over de over de voortgang en het college informeert de raad. De governance heeft ook een grote externe component, doordat we aansluiten op de NDS en het voornemen van de VNG om 80% van de generieke voorzieningen gezamenlijk in te kopen. We sluiten daarom aan bij de verschillende overlegtafels van de NDS, VNG, het G4 CIO overleg en Common Ground. We organiseren de interne en externe kennisdeling en groeien naar een gezamenlijk aanpak, zowel als gemeente als onderdeel van de VNG.

18 GMT - Naar betrouwbare en professionele digitalisering - volgende fase digitale transformatie

19 Het Enterprise Architectuur model van de Gemeente Amsterdam vormt de basis voor het definiëren van

processen. Vakgroep Architectuur - https://hoofdstad.sharepoint.com/sites/StedelijkeEnterpriseArchitectuur

20 Dit volgt in de nog op te stellen meerjarenstrategie Digitale Autonomie, zoals door de raad gevraagd in motie 158.25

inzake Maak digitale autonomie concreet

Randvoorwaarden Om succesvol te zijn, zijn we afhankelijk van anderen in de gemeente en van externe factoren. In deze alinea omschrijven we de randvoorwaarden voor een succesvolle uitrol van de Sourcing- en cloudstrategie. Interne randvoorwaarden: ▪ Functies en classificatie: De uitvoering van deze strategie valt of staat met het definiëren van de functies en de classificatie op basis van bedrijfscontinuïteit en dataclassificatie. Zonder deze twee stappen is het onmogelijk om betekenisvolle vervolgstappen te nemen. ▪ Sturing onder enterprise architectuur en portfoliomanagement: We sluiten aan op de ingezette ontwikkeling van sturing onder architectuur en portfoliomanagement. Daarmee zijn we ook afhankelijk van het succesvol neerzetten van deze sturing in de organisatie en de budgetten, capaciteit en kennisontwikkeling die dat vereist. In praktijk betekent dit dat we veranderen van het vervangen van applicaties naar vooruitkijken en veranderen per functie. Dit zal ook betekenen dat er een digitaliseringsstrategie per cluster moet komen. Ook is het belangrijk dat het I-domein goed zicht heeft op het applicatielandschap en meer zelf in beheer heeft.

▪ Inkoop: - Enterprise Architectuur en softwareontwikkelteams sluiten aan bij sourcing: Deze strategie heeft uitwerking op de positie van Enterprise Architectuur en de Software ontwikkel teams, die meer regie moeten voeren en eerder betrokken moeten worden bij sourcing. De planning van Architectuur, DevOps en Inkoop zullen met elkaar gelijklopen en deze teams zullen meer gezamenlijk optrekken bij marktverkenningen en aanbestedingen.

-

▪

▪

▪

Digitale Autonomie zal toegevoegd worden als strategisch inkoopdoel. Op deze manier creëren we de randvoorwaarden voor de inkoopafdeling om te sturen op digitale autonomie.

Ontwikkelen van Risicomanagement als discipline: Excepties worden beheerst via het risicomanagementproces van het i-domein. Dit zorgt ervoor dat er voorwaarden gesteld kunnen worden als er niet voldaan wordt aan de autonome vereisten bij bedrijfskritische of hoogvertrouwelijke functies. Bij eventuele toekomstige migraties (transities) naar nietEuropese providers als voorwaarde te stellen dat er van tevoren een goede migratiestrategie is ontwikkeld. Er zal geïnvesteerd moeten worden in het uitwerken van deze discipline en capabilities. Het verlangt het (intern) opbouwen van kennis en capaciteit rond public en private clouds met zich mee, met specifieke risicoprofielen en mitigerende maatregelen. Verbinding tussen extern, intern en concern: Samendoen betekent ook afhankelijkheid. We zijn afhankelijk van de snelheid en kwaliteit van het Rijk en de VNG, onze interne processen binnen het I-domein en de uitvoer in de verschillende clusters in de gemeente. Wij kunnen een rol spelen om deze drie niveaus met elkaar te verbinden, maar blijven afhankelijk van capaciteit, kennis en kwaliteit van andere op al deze niveaus.

Externe randvoorwaarden ▪ Succesvolle implementatie NDS: BZK is verantwoordelijk voor het succesvol uitrollen van de NDS en het creëren van veel van de randvoorwaarden van deze strategie, zoals het faciliteren van de Overheidscloud en het faciliteren van landelijke afstemming voor het centraal inkopen

▪

▪

van generieke voorzieningen. Wij kunnen daarin een actieve rol spelen, maar zijn ook afhankelijk voor snelheid en kwaliteit. VNG en andere gemeenten: Om gezamenlijk in te kopen moeten andere gemeenten en de VNG zichzelf ook inrichten op gezamenlijk inkoop en het gezamenlijk definiëren van generieke voorzieningen. Wij kunnen daarin een aanjagende rol spelen, maar zijn ook afhankelijk van de snelheid en kwaliteit van de rest van Nederland. Gedeeld risico-kader: De strategie betekent dat we met nieuwe, andere risico’s te maken krijgen. We moeten bijvoorbeeld kunnen gaan steunen op de veiligheid van systemen die door de Rijksoverheid, de VNG of nieuwe samenwerkingsverbanden worden ontwikkeld en beheerd. Dit betekent dat we op dit gebied veel meer met deze organisaties moeten gaan samenwerken en een gemeenschappelijk risico-kader moeten inrichten.

Meerjarenstrategie Digitale Autonomie Deze sourcing- en cloud strategie is onderdeel van de bredere meerjarenstrategie Digitale Autonomie21 waarin een op langere termijn autono(o)m(er) toekomstbeeld wordt geschetst, met verschillende concrete acties en experimenten voor het aankomende jaar.

Financiële impact De Sourcing- en cloudstrategie geeft het kader voor de sourcing van alle infrastructuur, clouddiensten, functies en applicaties van de organisatie en waar deze staan. Het is een toetsingskader dat richting geeft aan keuzes bij het nemen van een sourcingbeslissing voor een ITdiensten. Het opzetten van dit kader heeft geen extra financiële middelen nodig, maar de uitwerking hiervan zal wel een financiële impact op de organisatie hebben. De financiële dekking om te versnellen op digitale autonomie in brede zin wordt separaat aan de Raad voorgelegd, met de meerjarenstrategie digitale autonomie. Voor elk onderdeel van de meerjarenstrategie zal een eigen onderliggende businesscase gepresenteerd worden om op die manier de kosten inzichtelijk en beheersbaar te houden.

21 Dit volgt in het nog op te stellen Meerjarenstrategie Digitale Autonomie, zoals door de raad gevraagd in

Motie 158 van de leden IJmker, Garmy en Belkasmi inzake maak digitale autonomie concreet