Beantwoording technische vragen digitaal onafhankelijk

Beantwoording technische vragen Digitale Autonomie Technische vragen van het lid IJmker (GroenLinks): Vergelijking lopende aanbesteding voor public cloud met debat in commissie: Wethouder zegt (in commissie 27 maart)

Aanbesteding zegt

“In de aanbesteding nemen we digitale onafhankelijkheid mee” “In de aanbesteding nemen we multi cloud oplossingen mee” “Wij zullen het punt van multi cloud meenemen in de gesprekken […] Dat vragen we aan de partijen die meedoen in de aanbesteding” In antwoord op vraag over multi cloud oplossing (#5): De keuze van de Cloud Service Provider (Azure) is geen onderdeel van deze aanbesteding. In antwoord op vraag over multi-cloud soevereiniteit (#276): Dit is geen onderdeel van deze aanbesteding In antwoord op vraag over data soevereiniteit (#282): Dit is géén onderdeel van deze aanbesteding In antwoord op vraag over digitale onafhankelijkheid (#291): In deze (fase van de) aanbesteding niet van toepassing

Antwoord

In antwoord op vraag over rapport Algemene Rekenkamer (#359): De huidige Cloudstrategie is voor onze uitgangspunt. De vragen van de marktpartijen in de Nota van Inlichtingen (NVI) en onze antwoorden daarop gaan over een specifiek document, in een specifieke fase van het aanbestedingstraject. Deze technische vragen impliceren dat bij de vraagstelling verschillende documenten/fases van het traject aan elkaar worden gekoppeld die dat niet zijn. We besteden alleen het beheer en de ontwikkeling van ons bestaande platform aan. De verdere diensten/technische oplossingen die we als stad nodig zullen hebben om te voldoen aan het beleid voor soevereiniteit dat wordt uitgewerkt in de Nationale Digitale Strategie volgen na de nieuwe Sourcings- en Cloudstrategie. Pas dan weten we namelijk wat er binnen de bestaande contracten kan en wat er aanvullend moet worden aanbesteed - of niet omdat we het in eigen beheer willen doen. De gemeente Amsterdam vraagt leveranciers wél naar hun beeld / oplossing voor multicloud danwel soevereine cloud als onderdeel van het onderwerp Innovatie. Bij de inhoudelijke verdieping op de aangeboden diensten wordt er goed gekeken in hoeverre hun oplossing gereed is voor een beweging naar soevereine of multicloud. We kijken hier onder andere specifiek naar het niveau van standaardisatie en de wijze van standaardisatie van de diensten.

Beide zijn van grote invloed op de hoeveelheid effort en tijd er nodig is om over te stappen naar een ander platform. De antwoorden nemen we mee in de beoordeling van de belangrijkste (lees zwaarste) gunningscriteria.

Dit betekent niet dat leveranciers wordt gevraagd een oplossing te bieden voor een multi- of soevereine cloud en deze ook te leveren. Uiteraard willen alle leveranciers allemaal graag hun visie/beeld en oplossing pushen. Uit de marktconsultatie blijkt dat de beelden nog erg uiteen lopen over toekomstig cloudbeleid van overheden, ontwikkelingen van de Europese cloudmarkt, en hoe beide naar een nieuw evenwicht gaan. Wanneer het landelijke beleid duidelijk is en deze is vertaald naar een nieuwe sourcings- en cloudstrategie, kunnen we als stad de beste keuzes maken qua oplossingen. Vandaar dat we deze Vandaar dat we deze vragen op deze manier hebben beantwoord. Het antwoord op vraag 5 gaat over de Selectiefase. Om bedrijfscontinuïteit te borgen selecteert Amsterdam een marktpartij die de beschikbaarheid en kwaliteit van het huidige platform waarborgt. Wethouder zegt (in commissie 27 maart) Aanbesteding zegt

Antwoord

“Er is mogelijkheid om af te schalen [van Microsoft]” “Dat betekent dus niet dat we 10 jaar vastzitten aan Microsoft” Er is sprake van een contract voor vier jaar met daarna mogelijkheid voor twee keer drie jaar verlengen (= 10 jaar) In antwoord op vraag over tussentijds opzeggen (#100) Artikel 16.4 uit de Concept overeenkomst komt te vervallen. [En dus is tussentijds opzeggen onmogelijk gemaakt?] In het contract wordt opgenomen dat de “hoeveelheid” te beheren Azure afgeschaald kan worden, uiteindelijk zelfs tot nul. De te contracteren leverancier heeft juist de kennis en kunde om Amsterdam, desgewenst, te helpen af te schalen van Microsoft-diensten. Daarvoor hoeven we het contract met de beheerpartij voor onze stedelijke Azure-implementatie niet op te zeggen. Pas na de 3de ronde (voorlopige gunning gepland op 11 juli 2025) wordt duidelijk in hoeverre we hierin geslaagd zijn en hoe dat er precies uit gaat zien. Insteek is dat alle diensten die de stad contracteert naast een prijs ook een volume-component krijgen (Kosten = Prijs x Hoeveelheid). We doen dit per dienst zodat bij een eventuele afbouw naar nul of bijna nul altijd de kosten omlaag gaan. Welke dienst we ook precies afbouwen.

Wethouder zegt (in commissie 27 maart) Aanbesteding zegt

Over de 150 applicaties die nu bij KPN staan: “Die aanbesteding moet nog gaan lopen” en “Er is helemaal nergens gezegd dat die straks naar Microsoft gaan” In de ‘Aanleiding’ van de Selectieleidraad: Na een recente verlenging voor de maximale duur van twee jaar, staat vast dat dit KPN HenT-contract eindigt op 31 mei 2026. [Ik concludeer dat ze dus wel naar Azure over gaan en dat dit de aanleiding is voor deze aanbesteding en dus wel onderdeel uitmaakt van deze aanbesteding] In antwoord op vraag over aantal applicaties (#9) Dit kan in 2025/2026 uitgroeien naar 10-15 van de dan 175-200

Antwoord

Deze twee zaken zijn niet aan elkaar gekoppeld. De Public Cloud dienstverlening is in het verleden ingekocht onder het toen al lopende KPN Hosting en Technisch Applicatie Beheer (H en TAB, HenT) contract. De aard van beide diensten is echter zodanig anders, dat HenT en Public Cloud gesplitst zijn. Net als voor het beheren van ons Cloudplatform komt er voor HenT een nieuw contract. De dienstverlening die nu gecontracteerd is onder de naam HenT zal (net als het Cloudplatform) ook onderdeel blijven van het palet aan diensten wat we nodig hebben om te voldoen aan de NDS. Dat kan met een nieuwe, maar ook met de bestaande partij zijn. De inkoopstrategie voor HenT wordt momenteel opgesteld en zal dan naar de Tenderboard en het college van B en W gaan. Het doelplatform voor de 150 HenT-applicaties is de vervanging van HenT, niet het Public Cloud Platform. Het klopt dat het aantal applicaties op Azure kan groeien. Dat is niet als onderdeel van een migratie. Deze groei gebeurt op basis van keuzes die we maken. Keuzes worden gemaakt op basis van de huidige sourcingsstrategie om bepaalde functionaliteit zelf te ontwikkelen in plaats afhankelijk te zijn van marktpartijen (zoals bijvoorbeeld MijnAmsterdam en de Amsterdam App). Dit ontwikkelen doen we primair op een Open Source stack.

Technische vraag van het lid IJmker (GroenLinks): In de commissie zei de wethouder dat de aanbesteding voor de 150 applicaties die nu bij KPN staan “nog moet gaan lopen”. In de inkoopkalender van de gemeente Amsterdam zie ik alleen een aanbesteding voor Azure staan. Hoe zit dat? Antwoord: De extern gepubliceerde kalender wordt eens per kwartaal bijgewerkt conform de afspraken met de Lead Buyers en Directie Inkoop. Doel hiervan is het informeren van de markt over de aanbestedingen die in voorbereiding zijn. Op deze manier willen we de markt tijd geven om zich voor te bereiden waarin zij mogelijkerwijs interesse hebben. De aanbesteding HenT komt in de volgende versie op de externe kalender. Naar verwachting start deze aanbesteding na het zomerreces.

Technische vraag van het lid IJmker (GroenLinks): Hoe definieert de wethouder ‘exit strategie’ en ‘migratie strategie’? De uitleg in de commissie was dat exit strategie gaat om afspraken over meewerken naar overgang naar andere leverancier wanneer de leverancier er mee stopt. Ik interpreteer exit strategie als voorzorgmaatregel van tevoren zodat een overstap (wanneer wij dat willen) makkelijker is. Dat is ook hoe ik het advies van de CPA lees. Hebben we dergelijke exit strategieën op orde op dit moment?

Antwoord: Dat hangt ervan af hoe je op orde definieert. De grote contracten hebben allemaal bepalingen op het vlak van overstappen. Die zijn echter vooral contractueel van aard en niet inhoudelijk. We

hebben als stad niet gedefinieerd wat wij zien als ‘makkelijker’: we hebben geen uitgewerkte vereisten hiervoor, zoals een maximale doorlooptijd, geaccepteerd verlies van data, geaccepteerd verlies van functionaliteit, etc. Een exitstrategie is slechts een paar regels in een contract dat als een leverancier er mee ophoudt (zoals failliet) dat die dan verplicht wordt mee te werken aan een overgang naar een andere leverancier. Een migratiestrategie zien we als van tevoren nadenken over hoe eventueel te migreren. Migratiestrategieën kennen we nu niet. Deze zullen we verder uitwerken in de nieuwe sourcingstrategie.