2. Cloudstrategie gemeente Amsterdam 2022-2025.pdf

Cloudstrategie gemeente Amsterdam 2021 - 2025

Terug naar de inhoudsopgave

Aanleiding

De koers is uitgezet in de eindrapportage Bestuursopdracht I-domein: betrouwbare en veilige diensten die bij de tijd zijn Efficiënt omgaan met beschikbare middelen

Betrouwbare en veilige (digitale) diensten die bij de tijd zijn

Bron: “20200217 Bestuursopdracht I-domein - Eindrapportage GMT vFinal2.pdf”

Duurzame toegankelijkheid en openbaarheid van informatie

Modern IT-fundament: betrouwbaar, veilig, gestandaardiseerd, wendbaar

Competenties voor de toekomst

1

Terug naar de inhoudsopgave

Aanleiding

In antwoord op de bestuursopdracht zijn zes sporen gedefinieerd om de digitale ambities te vervullen, waarvan Spoor 3 focust op het technisch fundament Sporen: Het I-domein en de gemeente … 1

Hebben een duidelijke richting en regie

Voorbeelden van uitkomsten voor de gemeente

Dit document betreft een uitwerking van een onderdeel van dit spoor

• Het I-domein werkt samen met de business aan die onderwerpen die de grootste waarde bieden voor de stad in nauwe samenwerking met alle clusters

• Ontwikkeling, inkoop en onderhoud van diensten zijn betrouwbaar en van hoge kwaliteit en worden 2

Leveren effectief

3

Bouwen op de juiste technische fundamenten

4

Maken gebruik van een sterke datafunctie

5

Opereren met kennis en expertise

6

Bouwen op een sterke financiële basis

geleverd door een optimale mix van gemeentemedewerkers en derde partijen

• Er is minder kans op uitval van diensten door het gebruik van een veilige en stabiele onderliggende infrastructuur • Het technisch fundament is klaar voor de toekomst en schaalbaar

• Clusters kunnen gebruikmaken van één bron, waarin data op een consistente en veilige manier ontsloten wordt, in lijn met alle geldende regelgeving

• Het I-domein én de business beschikken over alle benodigde competenties om de verdere digitaliseringsslag te maken, inclusief versterkte expertise op belangrijke gebieden als veiligheid en privacy

• Financiering van activiteiten in het I-domein is zodanig ingericht dat de clusters goed kunnen sturen, marktpartijen op de juiste wijze kunnen worden ingezet en de effectiviteit van de uitgaven gemaximaliseerd wordt

2

Terug naar de inhoudsopgave

Aanleiding

Amsterdam heeft een Cloud strategie opgesteld om Cloud keuzen en beleid in de toekomst te richten

Context & vraagstelling

Doelstellingen

 De koers van het i-domein is verankerd in de Bestuursopdracht: het realiseren van een modern fundament voor een digitaliserende gemeente om opgaven in de stad en ambities van het college mogelijk te maken

De digitale transformatie en het gebruik van data vereist een solide en breed gedragen Cloud strategie. Dit betreft een strategie die:

 Om dit te bereiken zal de gemeente de ‘achterkant' moeten transformeren tot een hybride organisatie, waarin de ondersteunende IT is georganiseerd in een hybride IT-omgeving

1.

De clusters in staat stelt de digitale ambities waar te maken

2.

Kaderstellend is op basis van marktontwikkelingen en het Amsterdamse strategisch kader

 Binnen Spoor 3 is reeds een Cloud Competence Centre in opbouw

3.

Uitgaat van de huidige Amsterdamse situatie

 Op dit moment ontbreekt een overkoepelende Cloud strategie die het beleid met principes randvoorwaarden en uitgangspunten richt

4.

Cloud inrichtingskeuzes specificeert

5.

Op basis van een plateauplanning het handelingsperspectief detailleert

 In antwoord op de bestuursopdracht zijn zes sporen gedefinieerd, waarvan Spoor 3 zich concentreert op het technisch fundament

 Amsterdam heeft Gartner gevraagd te ondersteunen in het opstellen van een gemeente-brede Cloud strategie

3

Doelstelling en uitkomsten

Om de gemeente te laten bouwen op de juiste technische fundamenten, realiseren een flexibele en betrouwbare basisinfrastructuur

Uitkomsten Doelstelling: De gemeente laten bouwen op de juiste technische fundamenten

1. Een infrastructuur die schaalbaar en wendbaar is en voldoet aan steeds hogere standaarden in snelheid en veiligheid

Hierbij werken we naar de volgende toekomstsituatie toe*: 

Verhogen van de flexibiliteit van de basisinfrastructuur, zonder hierbij in te leveren op betrouwbaarheid van de dienstverlening



Bieden van een technisch fundament waarbij informatie juist geclassificeerd wordt en kan landen op een omgeving met de juiste beschermingsmaatregelen





Verhogen toekomstvastheid van de gebruikte technologie voor de basisinfrastructuur door gebruik te maken van de kracht en expertise van de markt Standaardiseren van de dienstverlening voor de integratie van het totale landschap: zowel voor standaard applicaties als modern maatwerk en het dataplatform

*Verankerd in de bestuursopdracht i-domein

2. De organisatie wordt ontlast in het beheer, door verbetering van samenhang in, en sturing op, het gemeentelijke applicatie- en datalandschap. Dit betekent niet dat dit goedkoper is.

Uitkomsten

3. Veilige opslag van geheime en vertrouwelijke gegevens op basis van de beschikbare technische mogelijkheden, die als voorbeeld dient voor andere overheidsinstellingen hoe om te gaan met privacy in de Cloud

Ambitie: Amsterdam zet de norm samen met de Nederlandse publieke sector 4

Voordelen

Het gebruik van Cloud levert hierbij vier grote voordelen op

Schaalbaarheid

Verbeterde veiligheid

Snelheid en wendbaarheid

Flexibele capaciteit

Biedt een infrastructuur die applicaties en toepassingen ondersteunt schaalbaar maakt

Brengt verbeterde veiligheid voor IT door gebruik van laatste ontwikkelingen binnen cybersecurity en het gebruiken van kennis rondom veiligheid vanuit de Cloudleveranciers

Maakt kortere ontwikkelingscyclus mogelijk door verbeterde inzet van IT-middelen, snellere inzet van de nieuwste technologieën en updates van verouderde software en infrastructuur

Geeft meer mogelijkheden in op- en afschalen van benodigde capaciteit door flexibiliteit vanuit de Cloud en biedt meer inzicht in consumptie per gebruiker

Samenwerking met zorgvuldig gekozen marktpartijen is noodzakelijk om continu ontwikkelingen op gebied van multiCloud bij te houden en te implementeren. Dit kan niet zonder de expertise van deze marktpartijen.

5

Waarborgen

De gemeente gebruikt Cloud diensten met de beheersmaatregelen afgestemd op het risicoprofiel van het proces waarin de gegevens gebruikt worden

Processen met een laag risico

Processen met een hoger risico, bijvoorbeeld door persoonsgegevens Additionele focus

Beheersmaatregelen Amsterdam

Beheersmaatregelen Cloud aanbieder

Activiteiten zoals:  Uitvoering DPIA’s en andere complaincy processen  Afsluiten verwerkingsovereenkomsten  Risico analyses  Claims evaluatie  Compliancy evaluatie  Afsluiten van overeenkomst op basis van Gemeentelijke Inkoopvoorwaarden bij IT (GIBIT 2020), waarin eisen zijn opgenomen voor het voorkomen van vendor lock in en faillissement Activiteiten zoals:  Beveiligingsmaatregelen  Privacy en control maatregelen  Compliancy methodieken en formats  Kosten en gebruik transparantie  Leveringzekerheid maatregelem

Aanvullende beheersmaatregelen zoals: Nadere afspraken met Cloud aanbieder

Additionele waarborgen zoals:

6

Terug naar de inhoudsopgave

De gemeente realiseert haar technische en organisatorische basis voor de Cloud om de digitale versnelling in de clusters te faciliteren

Cloud strategie ‘21-’25: Versnelling door te bouwen op de juiste technische fundamenten

Situatie   

Amsterdam wil digitaal bij zijn en blijven vernieuwen op basis van een modern i-fundament, zoals verankerd in de Bestuursopdracht i-domein De uitvoering van de digitale ambities van de verschillende clusters worden versneld door de mogelijkheden van de Cloud De gemeente heeft de eerste stappen gezet richting de doelstelling om de flexibiliteit en betrouwbaarheid van de basisinfrastructuur te verhogen

 

 

Uitvoeringskalender

Vraagstelling & Aanpak  



De digitale transformatie en het gebruik van data vereist een solide en breed gedragen Cloud strategie In de Cloud strategie zijn de ambities, prioriteiten en speerpunten van Amsterdam vertaald naar principes, inrichtingskeuzen en acties, in een samenwerking tussen de verschillende belanghebbenden binnen de gemeente Voorliggende document is het resultaat van het strategievorming proces

Om de gemeente te laten bouwen op de juiste technische fundamenten werken we toe naar een infrastructuur die schaalbaar en wendbaar is en voldoet aan steeds hogere standaarden in snelheid en veiligheid Door gebruik te maken van de verschillende Cloud vormen, wordt de organisatie ontlast in het beheer, en behouden we de sturing op het applicatie- en datalandschap De gemeentelijke Cloud principes geven richting aan het gebruik en de adoptie van Cloud diensten, waarbij Public Cloud PaaS het voorkeursmodel is bij vernieuwing We gebruiken een eenduidig afwegingskader om de juiste infrastructuur te kiezen



 

In de komende twee jaar, realiseert de gemeente haar Cloud fundament. Amsterdam verstevigd niet alleen de technische basis, maar ook de organisatorische basis. Amsterdam kan hierdoor effectief regie voeren (technisch en strategisch), solutions en tools effectief gebruiken en in control blijven op het gebied van financiën en risico’s. Vanaf 2023 groeit Amsterdam toe naar een nieuw infrastructuur evenwicht, waarbij in 2023 een strategische keuze gemaakt over het wel of niet actief migreren van de traditionele on-premises en TAB/Hosting omgevingen naar de Cloud omgevingen. Om deze plateau’s te realiseren, zal Amsterdam haar Agile manier van werken specificeren, cultuurverandering adresseren en executiekracht organiseren om de volledige set aan voordelen te kunnen realiseren.

7

Terug naar de inhoudsopgave

Voorbeelden digitale ambities

De digitale ambities van de verschillende clusters worden versneld door de mogelijkheden van de Cloud

Stadsbeheer

Ruimte en Economie

Dienstverlening en Informatie

Sociaal

Cluster Interne Dienstverlening

Bestuur en Organisatie

 Voorspellend onderhoud plegen  Continue inzicht in de duurzame afvalketen  Geoptimaliseerd en voorspellende toezicht en handhaving processen  Digitale inzichten t.b.v. dagelijkse beheeractiviteiten

 Verbeteren ruimtelijke en economische randvoorwaarden middels voorspellende stadsmodellen  Faciliteren inzicht in de status van ruimtelijke en economische randvoorwaarden t.b.v. besluitvorming

 Verbeterde interactie en dienstverlening aan burger en bedrijf  Digitaal voorzien van overzicht, kennis en integrale duiding  Vergroten van de informatiepositie van de gemeente Amsterdam

 Excellente en eenduidige digitale dienstverlening aan (kwetsbare) Amsterdammers  Digitaal re-integratie faciliteren  Verhogen van participatie mogelijkheden

 Vergroten van de toegang tot up-todate managementinformatie  Bieden van een eigentijdse digitale werkplek  Bieden self-service inzichten op o.a. financieel, juridisch en P&O domein

 Meer datagedreven strategisch advies t.b.v. beleid en uitvoering  Optimalisatie en voorspellende control processen  Inzicht-gedreven toezicht en handhaving  Data-gebaseerd personeelsbeleid

Elk cluster voert deze digitale strategieën op eigen tempo uit, waarbij het gebruiken van inzichten op basis van een toekomstvaste en schaalbare infrastructuur in het hart van de primaire processen ligt

8

De gemeente Amsterdam neemt een leidende rol in het veilig en betrouwbaar gebruik maken van Cloud technologie Opslag op fysieke servers in gemeentegebouwen is niet houdbaar op lange termijn

• Het vereist zeer brede set van schaarse competenties die heel weinig organisaties kunnen opbouwen, zoals cybersecurity (“continu boven het niveau van hackers zitten”) en onderhoud

De gemeente Amsterdam neemt een leidende rol in de afwegingen voor Cloudoplossingen Maximale controle

Maximaal schaalvoordeel

Per applicatie- en datatype wordt de afweging gemaakt welke technische oplossing wordt gekozen Cloud beslisboom

• Het heeft heel beperkte mogelijkheden om capaciteit op en af te schalen

• Doordat meerdere servers fysiek in een gemeentegebouw staan, creëert extra risico’s met betrekking tot betrouwbaarheid (bijv. brand, overstroming)

Voor elke applicatie en dataset wordt de afweging gemaakt tussen maximale controle en maximaal schaalvoordeel. Inrichting voldoet aan de Algemene Verordening Gegevensbescherming (AVG) en andere relevante wet- en regelgeving

1 Alle genoemde nieuwe technische oplossingen zorgen voor in de regel voor een betere beveiliging, doordat marktpartijen gebruik maken van de laatste technologische ontwikkelingen op het gebied van beveiliging. 2 In lijn met de Algemene Verordening Gegevensbescherming (AVG) kan opslag en verwerking van gegevens enkel in landen plaatsvinden waarvan de Europese commissie heeft vastgesteld dat zij een adequaat niveau 9 van gegevensbescherming hanteren. Hieronder vallen o.a. alle landen van de EU.

Amsterdamse koers

Amsterdam kiest voor een hybride IT landschap waarin (public) Cloud selectief wordt ingezet op basis van toegevoegde waarde N.b. Deze beslisboom is een moment opname, en zal continue herijkt worden. Vraag bij het CIO office voor de meest recente versie.

1 Een vraag is geïdentificeerd

1

2 Stel vast dat de beoogde Cloud

2

voor een nieuwe of bestaande applicatie

Nieuwe vraag

Risico- en compliance overweging

oplossing en bijbehorende provider(s) aan de risico- en compliance eisen van de gemeente kunnen voldoen

Geschiktheid voor Cloud

applicatie voor Cloud adoptie op basis van toegevoegde waarde

Nee

Ja

3 3 Bepaal de geschiktheid van een

Kan de Cloud provider voldoen aan de risico- en compliance eisen van de gemeente?

Is er expliciete vraag naar snelle uitrol van nieuwe functionaliteit en capaciteit? Is integratie met andere applicaties belangrijk? Is het gebruik van de applicatie variabel gedurende het jaar?

Nee

Ja

4 4 Bepaal het meest geschikte service- en implementatiemodel op basis van de karakteristieken

Servicemodel / implementatiemodel

Betreft het een direct in de markt verkrijgbare functionaliteit?

Is het cluster/domein team voldoende volwassen?

SaaS

Is er een technische eis van het software pakket om de software op Cloud technologie te realiseren?

Ja Nee

Kunnen we de vraag vormgeven o.b.v. de Public Cloud platform standaarden?

Ja

Ja

Nee

Public PaaS (Azure)

Nee Ja, met minimaal maatwerk

Public IaaS (Azure)

Nee

Ja

Hosting (TAB en Hosting)

10 Scope van het Cloud Competence Center

Terug naar de inhoudsopgave

Een tiental gemeentelijke Cloud principes geven richting aan het gebruik en de adoptie van Cloud diensten Aspect Cloud adoptie Technologische volwassenheid

Gemeentelijke Cloud gebruik en adoptie principes* #1 Public Cloud is het voorkeursmodel bij alle vernieuwingsvraagstukken #2 We gebruiken volwassen technologie waar het kan, vernieuwende technologie waar het moet

Investeringsstrategie

#3 Cloud adoptie doen we om (toegevoegde) waarde creatie te realiseren

Applicatie architectuur

#4 Cloud adoptie vindt plaats op basis van volledig Cloud-native en service oriented applicatiearchitecturen

Applicatie leveringsmodel

#5 Commodity functionaliteit wordt als SaaS-dienst afgenomen, PaaS en IaaS worden gebruikt voor maatwerk oplossingen

Infrastructuur architectuur

#6 Er wordt zoveel mogelijk gebruik gemaakt van een generieke platformarchitectuur

Inkoop aanpak

#7 Cloud diensten worden centraal ingekocht en beheerd en kunnen naar decentrale behoeften worden aangepast

Leverancier strategie

#8 Er wordt gestart met één provider voor IaaS en PaaS diensten

Outsourcing strategie

#9 Amsterdam investeert niet in eigen centrale capabilities voor platform operations

OpenSource

#10 We passen direct het ‘OpenSource, tenzij’ beleid toe voor applicaties in de Cloud ten behoeve van het delen van artifacts tussen gemeentes en met burgers. Voor de Cloud platform componenten doen we dit zodra onze volwassenheid dit toelaat

Data privacy en security

Randvoorwaarde: Amsterdam borgt ten eerste de veiligheid en bescherming van de data in de Cloud by design en past ten tweede het Open Data beleid toe op basis van de dataclassificatie

11

Amsterdam ontwikkelt eerst haar organisatorisch en technisch fundament voordat ingezet wordt op actieve migratie

Plateau 1: Leren en proberen Amsterdam is op verschillende domeinen aan het experimenteren met Cloud. Zowel SaaS adoptie als het gebruik van verschillende Cloud platforms door individuele teams. Amsterdam bouwt hiermee vaardigheden en ervaringen op.

Plateau 2: Cloud fundament Amsterdam heeft haar Cloud fundament stevig neergezet: Cloud als omgeving voor bepaalde applicaties en data, op domeinen waarbij hier duidelijke toegevoegde waarde voor is. Amsterdam heeft niet alleen de technische basis gerealiseerd, maar ook de organisatorische basis. Amsterdam kan effectief regie voeren (technisch en strategisch), adopteert solutions effectief en heeft mechanismen en modellen om in control te blijven op het gebied van financiën en risico’s.

2022-2025

Plateau 3: Nieuw evenwicht Amsterdam heeft stappen gemaakt in volwassenheid, die het mogelijk maken het volume van applicaties en data die landen op de Cloud omgevingen op te schalen. In 2023 wordt een strategische keuze gemaakt over het wel of niet actief migreren van de traditionele on-premise en TAB/Hosting omgevingen naar de Cloud omgevingen.

2020-2022

2015-2020 Managed Defined Ad-hoc 12

BIJLAGEN

13

Begrippenkader

De Cloud zorgt er voor dat we gegevens en toepassingen niet allemaal meer lokaal hoeven op te slaan

Vijf kernkarakteristieken

We definiëren het begrip “Cloud” als volgt: De Cloud is een netwerk van externe servers die aan elkaar zijn gekoppeld en als één ecosysteem fungeren. De servers zijn ontworpen voor het schaalbaar en elastisch opslaan en beheren van gegevens, het uitvoeren van toepassingen of het leveren van content of services, zoals streaming video's, webmail, kantoorsoftware of sociale media. In plaats van dat u bestanden en gegevens van een lokale computer of pc haalt, opent u deze online vanaf een apparaat met een internetverbinding.

1

Toegang van het internet

Diensten worden geleverd door gebruik van internet identifiers,formaten en-protocollen en zijn beschikbaar via standaardmechanismen die het gebruik door heterogene devices (bijv. Mobiele telefoons, tablets, laptops en werkstations) bevorderen.

2

(Zelf) bediening op aanvraag

Een consument kan indien nodig eenzijdig rekencapaciteit verschaffen, zoals servertijd en netwerkopslag, zonder tussenkomst van elke serviceprovider

3

Schaalbaar en elastisch

Diensten kunnen (automatisch) worden op- en afgeschaald in overeenstemming met de vraag (denk aan het automatisch bijschakelen van extra webservers indien een webshop druk bezocht wordt)

4

Gebruik van een “pool” van servers

Meerdere klanten maken gebruik van een ‘pool’ van gedeelde servers, waarbij verschillende fysieke en virtuele resources dynamisch worden toegewezen om schaalvoordelen te realiseren.

5

Meten (en betalen) o.b.v. gebruik

Diensten worden gemeten op gebruik (middels KPI’s) om verschillende directe betalingsmodellen mogelijk te maken.

14

Begrippenkader

Cloud kent verschillende verschijningsvormen. Zo zijn er drie verschillende dienstverleningsmodellen… De drie Cloud dienstverleningsmodellen

Traditioneel “on-premise” datacenter

Infrastructure as a Service (IaaS)

Platform as a Service (PaaS)

Software as a Service (SaaS)

Amsterdam maakt gebruik van haar eigen fysieke infrastructuur van de provider en installeert daarop eigen applicaties en bepaald zelf het besturingssysteem. Afhankelijk van de invulling (traditioneel, colocatie of hosting) kan een deel van fysieke laag in beheer zijn door een derde partij

Amsterdam maakt gebruik van een fysieke Cloud infrastructuur van de provider en installeert daarop eigen applicaties en virtuele machines (VM) en bepaald zelf het besturingssysteem. Amsterdam beheerd de fysieke laag niet maar heeft wel de controle over besturing-systeem, opslag en geïmplementeerde applicaties.

Amsterdam kan ontwikkelde of verworven applicaties implementeren op de Cloudinfrastructuur zonder de onderliggende Cloudinfrastructuur, inclusief netwerk, servers, besturingsystemen of opslag te hoeven beheren. Er hoeft bijvoorbeeld geen eigen database server ingericht te worden maar er kan direct een (te ontwikkelen of ontwikkelde) database geplaatst te worden.

Amsterdam gebruikt een applicatie die draait op de Cloudinfrastructuur van de provider. De applicaties zijn toegankelijk vanaf verschillende devices via bijvoorbeeld een webbrowser. De applicatie wordt als dienst afgenomen en voor het gebruik wordt een contract afgesloten. Amsterdam beheert of controleert de onderliggende Cloudinfrastructuur niet, m.u.v. toepassingsconfiguratie-instellingen.

Data

Data

Data

Data

Applications

Applications

Applications

Applications

Middleware

Middleware

Middleware

Middleware

Operating System

Operating System

Operating System

Operating System

Virtualization

Virtualization and CMP

Virtualization and CMP

Virtualization and CMP

Servers and Storage

Servers and Storage

Servers and Storage

Servers and Storage

Network

Network

Network

Network

Data Center

Data Center

Data Center

Data Center

Zelf in beheer

Door iemand anders in beheer

15

Begrippenkader

…en zijn er vier verschillende implementatie of “deployment” modellen te onderkennen Public Cloud De Cloudinfrastructuur is opengesteld voor publiek gebruik waarbij er geen sprake is van exclusief maar generiek gebruik. De infrastructuur bevind zich bij de Cloudprovider. Dit wordt typisch gefactureerd als een Pay Per Use-model. Beperkte doorlooptijd en complexiteit zijn de drijvende krachten achter public Cloud implementaties.

Private Cloud

De Cloudinfrastructuur wordt exclusief beschikbaar gesteld voor één enkele organisatie. De infrastructuur kan eigendom zijn, beheerd en geëxploiteerd worden door de organisatie, een derde partij of een combinatie daarvan. Private Clouds bieden ruimte voor eigen eisen geavanceerde beveiliging, maar die ook weer eisen stellen aan de provider om de software en infrastructuur te kopen en te onderhouden, wat de kostenbesparingen beperkt.

Community Cloud De Cloudinfrastructuur is exclusief voor een specifieke groep of organisatie met dezelfde belangen (zoals missie, beveiligingseisen, beleid). De infrastructuur kan eigendom zijn, beheerd en geëxploiteerd worden door één of meer organisaties die onderdeel zijn van de community, een derde partij of een combinatie hiervan. Beweegredenen hiervoor kunnen reguleringsvereisten zijn, bijvoorbeeld de noodzaak dat informatie in een bepaald land wordt opgeslagen. Het belangrijkste idee achter de community Cloud is om gebruik te maken van de voordelen van public Cloud, terwijl alleen gebruikers die aan het beleid voldoen toegang hebben, vergelijkbaar met private Cloud. . Hybrid Cloud De Cloudinfrastructuur is een combinatie van twee of meerdere onderscheiden Cloud-infrastructuren, private, community en public. De unieke entiteiten blijven maar zijn wel met elkaar verbonden door gestandaardiseerde- of maatwerk technologie die data- en applicatie portabiliteit mogelijk maakt. Hybride Cloudservices combineren meerdere services om hun algehele capaciteit of capaciteit te vergroten wanneer dat nodig is, waardoor snel opschalen en downscalen van resources on demand mogelijk is en zonder overtollige resources in rustige periodes.

16

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#1 Public Cloud is het voorkeursmodel bij alle vernieuwingsvraagstukken

1.

Public Cloud is het voorkeursmodel bij alle vernieuwingsvraagstukken Principe

Applicaties worden door middel van Public Cloud aangeboden wanneer dit toegevoegde waarde heeft in termen van vereiste wendbaarheid en schaalbaarheid van de applicatie. Nieuwe applicaties zijn bij voorkeur Cloud gebaseerd, bestaande applicaties worden alleen gemigreerd naar of vervangen door Cloud-native toepassingen als dit waarde toevoegt.

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … generieke applicaties waar mogelijk afneemt als een SaaS-dienst  … nieuwe applicaties bij voorkeur op een PaaS-omgeving ontwikkelt en indien dat niet mogelijk is op een IaaS omgeving  … lifecycle momenten van bestaande applicaties (bijvoorbeeld versie upgrades, hardware vervanging) gebruikt om te evalueren of er een case for change bestaat voor migratie naar een Cloud omgeving

Niet  … geen nieuwe applicaties ontwikkelt in de on-premises omgeving  … geen nieuwe software pakketten, services en ontwikkelplatformen in gebruik neemt die niet gedurende de lifecycle richting de Cloud gemigreerd kunnen worden  … geen bestaande applicaties naar public Cloud migreert die niet Cloudnative zijn

17

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#2 We gebruiken volwassen technologie waar het kan, vernieuwende technologie waar het moet

2.

We gebruiken volwassen technologie waar het kan, vernieuwende technologie waar het moet Principe

Amsterdam is een snelle volger in het gebruik van innovatieve technologieën. Waar het belang van innovatie zwaarder weegt dan eisen aan stabiliteit en beveiliging is het gebruik van innovatieve technologieën mogelijk, daar waar stabiliteit van dienstverlening en beveiliging van gegevens belangrijk zijn worden volwassen technologieën gebruikt

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … de afweging maakt of een applicatie kritiek is voor de dienstverlening van de gemeente en data bevat die op basis van de classificatie aan minimum beschermingseisen moet voldoen  … open staat voor innovatieve technologieën die (op termijn) waarde toevoegen voor de gemeente en de dienstverlening aan inwoners  … investeert in het opbouwen van kennis van nieuwe technologieën die mogelijk van waarde kunnen zijn voor de gemeente  … investeert in het opbouwen van ervaring van technologieën die richting een volwassen staat toe groeien die direct van waarde zijn voor de gemeente

Niet  … zich niet afhankelijk maakt van technologieën waarvan onvoldoende duidelijk is of deze voor langere termijn worden ondersteund

18

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#3 Cloud adoptie doen we om (toegevoegde) waarde creatie te realiseren

3.

Cloud adoptie doen we om (toegevoegde) waarde creatie te realiseren Principe

Adoptie van Cloud toepassingen hoeft niet alleen te leiden tot beheersing en optimalisatie van ITkosten voor de gemeente, er is ook ruimte om te investeren wanneer dit een duidelijke toegevoegde waarde heeft voor de gemeente. Dit betekent dat dit onderdeel moet zijn van de business case, in lijn met de i-strategie.

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … bij iedere vorm van Cloud adoptie een evaluatie maakt van de impact op de kosten en de mogelijkheden die ingezet kunnen worden om deze kosten te optimaliseren  … bij een verwachte stijging van de kosten of in geval van een investering die niet vanuit de IT-kosten impact wordt terugverdiend de mogelijkheid openhoudt om door te gaan als blijkt dat het gebruik van Cloud toepassingen aantoonbaar toegevoegde waarde heeft voor de gemeente en haar inwoners  … voor investeringen een eigenaar koppelt aan de realisatie van de toegevoegde waarde

Niet  … niet investeert in Cloud adoptie als dit geen gunstig effect heeft op de beheersing en optimalisatie van IT-kosten en er geen aantoonbare toegevoegde waarde is

19

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#4 Cloud adoptie vindt plaats op basis van volledig Cloud-native en service oriented applicatiearchitecturen

4.

Cloud adoptie vindt plaats op basis van service oriented applicatiearchitecturen Principe

Nieuwe applicaties worden Cloud-native ontwikkeld. Om van de voordelen van Cloud te profiteren worden applicaties eerst volledig Cloud-native gemaakt voordat zij naar de Cloud migreren. Op dit moment kiest Amsterdam er voor om niet te investeren in het Cloud-native te maken van bestaande applicaties.

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … applicaties, die op basis van hun vereisten (wendbaarheid, schaalbaarheid) in Cloud worden ontwikkeld, ontwerpt op basis van service oriented applicatiearchitecturen  … deze applicaties zodanig ontwikkelt dat ze optimaal gebruik kunnen maken van functionaliteiten zoals die door de Cloud leverancier worden aangeboden (Cloud-native)  … eisen stelt aan haar SaaS leveranciers op het gebied van Cloud-native functionaliteiten ten behoeve van integraties in het gehele Amsterdamse landschap (autorisatie, data integratie, etc.)

Niet  … niet bestaande applicaties Cloud-native te maken middels re-architecting of refactoring  … geen monolithische applicaties as-is naar een Cloud omgeving migreert (lift & shift)  … geen nieuwe applicaties in een Cloud omgeving ontwikkelt die een monolithische applicatiearchitectuur hebben

20

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#5 Commodity functionaliteit wordt als SaaS-dienst afgenomen, PaaS en IaaS worden gebruikt voor maatwerk oplossingen

5.

Commodity functionaliteit wordt als SaaS-dienst afgenomen, PaaS en IaaS worden gebruikt voor maatwerk oplossingen Principe

Indien de functionele vraag van de gemeente ingevuld kan worden met standaard pakketsoftware wordt deze als SaaS-dienst afgenomen en niet als pakketsoftware die on-premise of in IaaS wordt uitgerold. Voor maatwerksoftware wordt bij voorkeur PaaS gebruikt

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … zoveel mogelijk gebruik maakt van een PaaS omgeving voor software die als maatwerk wordt ontwikkeld voor de gemeente. Indien er geen geschikte PaaS omgeving voorhanden is kan een IaaS omgeving worden gebruikt  … SaaS-diensten afneemt voor alle als standaardpakket beschikbare software, om op die manier zoveel mogelijk te standaardiseren en technische restschuld te voorkomen  …een beslisboom gebruikt om applicaties en workloads op de juiste infrastructuur te laten landen

Niet  … geen maatwerkoplossing gaat bouwen als er standaard pakketsoftware voorhanden is

21

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#6 Er wordt zoveel mogelijk gebruik gemaakt van een generieke platformarchitectuur

6.

Er wordt zoveel mogelijk gebruik gemaakt van een generieke platformarchitectuur Principe

Bij het gebruik van PaaS diensten wordt zoveel mogelijk gebruik gemaakt van de PaaS-diensten die de primaire public Cloud provider kan bieden in plaats van gespecialiseerde PaaS-platformen die geschikt zijn voor specifieke toepassingsgebieden

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … gebruik maakt van de generieke PaaS-diensten van de primaire public Cloud provider  … voor specifieke platformtoepassingen (bijv. Low-code) onderzoekt of deze met ondersteuning van de leverancier kunnen worden gehost op de primaire public Cloud omgeving van de gemeente  … privacy-by-design ook bij PaaS dienstverleningen hanteert  … dit principe herbekijkt wanneer er stappen in volwassenheid zijn gezet

Niet  … niet direct de optie kiest om nieuw te ontwikkelen applicaties op een gespecialiseerd PaaS-platform onder te brengen

22

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#7 Cloud diensten worden centraal ingekocht en beheerd en kunnen naar decentrale behoeften worden aangepast

7.

Cloud diensten worden centraal ingekocht en beheerd en kunnen naar decentrale behoeften worden aangepast

Cloud inrichtingskeuzen waar het principe invloed op heeft:

Principe Applicatie eigenaren zijn verantwoordelijk voor het verantwoord gebruiken van centraal ingekochte (lead buyer) en aangeboden Cloud diensten op basis van een service catalogus, die kunnen worden aangepast op basis van decentrale behoeften

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … één contract sluit met leverancier(s) van Cloud diensten om zo gunstig mogelijk in te kopen  … Cloud diensten vanuit één service catalogus aanbiedt aan de clusters  … rekening houdt met behoeften van clusters bij de inrichting van de service catalogus

Niet  … generieke Cloud diensten en functionaliteit buiten de lead buyer om inkoopt ten behoeve van het bewaken

23

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#8 Er wordt gestart met één provider voor IaaS en PaaS diensten

8.

Er wordt gestart met één provider voor IaaS en PaaS diensten Principe

Om voldoende ervaring op te doen en de investeringen in een Cloud foundation te beperken wordt gestart met één provider voor IaaS en PaaS diensten. Pas als er op basis van volumes, functionele behoeften en/of vermindering van vendor lock-in kan worden overgegaan naar multi-Cloud. SaaSdiensten worden van meerdere providers betrokken

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … voor IaaS en PaaS diensten één hyperscale Cloud provider contracteert (de reeds gemaakte keuze is het Microsoft Azure platform)  … SaaS diensten bij meerdere providers kan betrekken  … periodiek evalueert of het werken met één provider voor IaaS en PaaS nog aansluit bij de behoeften

Niet  … geen Cloud diensten voor IaaS en PaaS inkoopt bij een andere dan de primaire provider

24

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#9 Amsterdam investeert niet in eigen centrale capabilities voor platform operations

9.

Amsterdam investeert niet in eigen centrale capabilities voor platform operations Principe

Kennis, ervaring en capaciteit voor het ontwikkelen en beheren van diensten in de Cloud wordt voornamelijk uitbesteed. Enkel die kennis die nodig is om de regie te kunnen voeren en de architectuur te laten passen binnen de overall IT architectuur wordt intern opgebouwd. Dit principe is in lijn met de ICT sourcing inrichting.

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … het beheren van Cloud omgevingen uitbesteed aan een managed services provider  … competenties opbouwt om architectuur en regie omtrent Cloud gebruik vorm te kunnen geven  … het is aan de IV’s zelf verder hoe de ontwikkelactiviteiten georganiseerd worden.

Niet  … niet zwaar gaat investeren in de ontwikkeling van interne technische Cloud competenties

25

Terug naar de inhoudsopgave

Cloud gebruik en adoptie principes

#10 We passen direct het Open Source, tenzij beleid toe voor applicaties in de Cloud. Voor de Cloud platform componenten doen we dit zodra onze volwassenheid dit toelaat 10.

We passen direct het OpenSource, tenzij beleid toe voor applicaties in de Cloud. Voor de Cloud platform componenten doen we dit zodra onze volwassenheid dit toelaat Principe

Ook binnen het Cloud domein passen we het OpenSource beleid toe op applicatief niveau. De combinatie van het Microsoft Azure Cloud platform met de voorkeur voor Cloud-native op PaaS, beperkt in eerste instantie de mogelijkheden om OpenSource componenten in het Cloud platform toe te passen. Bij toegenomen volwassenheid kan, hetzij via Multi-Cloud, hetzij via OpenSource componenten op IaaS, het gebruik van OpenSource Cloud platform componenten worden gefaciliteerd. Zie ook de platform componenten, voorzieningen en diensten verdeling op slide 39.

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … bij applicaties in die we hosten in de Public en Private Cloud zoveel mogelijk gebruik maakt van OpenSource code en tools  … op Public Cloud platform niveau in eerste instantie de geboden functionaliteiten van Microsoft Azure en bijbehorende marketplace gebruikt  … in samenspraak met ontwikkelaars bepaald tot op welke hoogte Azurenative bouwblokken (zoals appservices) gebruikt worden  … dit principe herijkt op het moment dat het Cloud fundament voldoende volwassen is om ook IaaS diensten te beheren of naar een Multi-Cloud opzet over te schakelen

Niet  … niet zwaar gaat investeren in de ontwikkeling van interne technische Cloud competenties

26

Terug naar de inhoudsopgave

Cloud principes

Randvoorwaarde: Amsterdam borgt ten eerste de veiligheid en bescherming van de data in de Cloud by design en past ten tweede het Open Data beleid toe op basis van de dataclassificatie R

Amsterdam borgt ten eerste de veiligheid en bescherming van de data in de Cloud by design (data wordt in cloud bewaard en beheerd) en past ten tweede het Open Data beleid toe op basis van de dataclassificatie Principe

Veiligheid en bescherming van de data wordt ook in de Cloud geborgd. In lijn met het open data beleid van de gemeente wordt ook data in de Cloud open toegankelijk wanneer dit op basis van dataclassificatie mogelijk is. De dataclassificatie is expliciet onderdeel van de Cloud beslisboom.

Cloud inrichtingskeuzen waar het principe invloed op heeft:

1. 2. 3. 4. 5. 6. 7.

Service modellen (X-as-a-Service) Implementatiemodellen Financieringsmechanismen Adoptie domeinen Cloud leverancier / partner ecosysteem Cloud Operating Model Migratie aanpak

Dit betekent dat Amsterdam… Wel  … veiligheidsmaatregelen voor elke type infrastructuur genomen en continue herijkt worden  … duidelijke evaluatie criteria opstelt betreffende data opslag, beveiliging en exit mogelijkheden bij het selecteren van SaaS dienstverlening. Ook worden duidelijke afspraken en kaders (GIBIT) worden afgesproken met de public Cloud leverancier  … de juiste controls betreffende integratiemogelijkheden en het beschikbaar stellen van data worden geïmplementeerd voor de verschillende type infrastructuren (privacy-by-design)  … er duidelijk gecommuniceerd worden over mogelijkheden en onmogelijkheden van Cloud gebruikt  … authorisatiebeheer formaliseert en aansluit op de Cloud inrichting

Niet  … niet privacy en gegevensbescherming als een puur technische aangelegenheid beschouwd  … niet alleen op (technische) Disaster Recovery gefocust wordt maar Business Continuity Management processen vanuit een ketenperspectief ingericht worden

27