Second opinion migratieplan infrastructuur samenwerkende gemeenten

Second opinion migratieplan infrastructuur samenwerkende gemeenten

Rapport bij project , versie 1.0

Dit rapport is geschreven in opdracht van J. v.d. Drift door Richard Sitters van bv M&I/Partners . Amersfoort, oktober 2011

Inhoudsopgave 1

Inleiding

3

2

Huidige plan vormt solide basis voor dit moment.

4

3

Aanbeveling voor volgende stappen

6

4 4.1 4.2

Doelarchitectuur biedt een solide basis Active/passive datacenter topologie de aanbevolen weg Uitgangspunten – ontwerpprincipes zijn juist

7 7 9

5 5.1 5.2

Migratiescenario’s – veel voordelen bij een snelle migratie Snelle migratie – het snelst naar de doelarchitectuur Gefaseerde migratie

6 6.1 6.2

Overige observaties 14 Borging van doelstellingen - regievoering door vastleggen van doelstellingen op elk niveau 14 PvE voor de doelarchitectuur – de werkgroep kan een voorschot doen 15

7 7.1 7.2

Bijlagen Bijlage 1 – Regiematrix - doelen en meetinstrumenten Bijlage 2 – PvE checklist

Second opinion migratieplan infrastructuur samenwerkende gemeenten Versie 1.0 oktober 2011

11 11 12

16 16 16

Pagina 2 van 17

1

Inleiding

De afgelopen drie jaar hebben de gemeenten de Bilt, Soest, Baarn, Bunnik, Utrechtse Heuvelrug en Wijk bij Duurstede voorbereidingen getroffen om te komen tot een samenwerking op ICT gebied. In juli 2012 zal een besluit worden genomen over de gemeentelijke samenwerking. Ten behoeve van de samenwerking heeft een werkgroep een migratieplan opgesteld hoe de ICT infrastructuur in de nieuwe samenwerking eruit moet komen te zien. In de migratie naar de nieuwe situatie zijn vier fasen (platforms genoemd) te onderscheiden. Gedurende fase 1 (ook wel platform 1) wordt de organisatorische samenwerking bestendigd. In fase 2 gaat het om de opbouw van de huisvesting van een gemeenschappelijk, centraal datacenter inclusief de verbindingen. In fase 3 wordt een optimalisatie van de hardware voorzien door het delen van hardware. In fase 4 wordt de gestandaardiseerde werkplek ingevoerd en verdere optimalisatie voorzien, zoals applicatiedeling et cetera. Voorafgaand, en ten behoeve van de bestuurlijke goedkeuring over de samenwerking, is M&I/Partners gevraagd een onafhankelijk oordeel over het migratieplan te geven, meer specifiek op de technische infrastructuur (alleen de “harde” of “koude” kant van de IT). Biedt de doelinfrastructuur en de weg ernaar toe een goede basis voor de gemeentelijke samenwerking op ICT gebied? Dit rapport presenteert onze bevindingen en conclusies van ons onderzoek. Het rapport is in z.g. piramide vorm geschreven. D.w.z. dat wij eerst de conclusies en aanbevelingen presenteren. De toelichting volgt daarna.


Pagina 3 van 17

2

Huidige plan vormt solide basis voor dit moment.

Voor het nemen van een bestuurlijke beslissing over de ICT samenwerking biedt de doelarchitectuur en het migratieplan zoals die er nu liggen een voldoende solide basis. De gepresenteerde infrastructuur oplossing (doelarchitectuur) is de juiste om te komen tot effectieve en efficiënte ICT samenwerking, waarbij de kwaliteit van dienstverlening kan worden geborgd en de infrastructuur is voorbereid op nieuwe ontwikkelingen. Voor de continuïteit van de bedrijfsvoering is een redundante infrastructuur, waarbij op twee fysiek gescheiden locaties een datacentrum en SAN infrastructuren worden ingericht (zoals die ook in de het migratieplan wordt gepresenteerd) noodzakelijk. Er zijn in de datacenter topologie een aantal mogelijke varianten, waarvan de z.g. active/passive inrichting de meest voor de hand liggende is (meest eenvoudig te beheren en kosten effectief). De keuze welke bedrijfsapplicaties tijdens een storing moeten blijven werken (alle applicaties, of alleen een deel ervan) is mede bepalend voor de kosten van de inrichting. De grootste voordelen van ICT samenwerking in termen van kostenbesparingen en beheerinspanning zijn te verwachten vanaf fase 3, wanneer hardware is gestandaardiseerd en wordt gedeeld, en vooral wanneer bedrijfsapplicaties worden gedeeld en geharmoniseerd. Er zijn twee mogelijke manieren voor de realisatie van de doelarchitectuur. Een snel migratie scenario en een gefaseerde invoering. Een snelle migratie levert veel voordelen op met betrekking tot de beoogde doelstellingen van de samenwerking, maar er zijn desinvesteringen die in de keuze een rol kunnen spelen. Er is goed een overzicht van infrastructuur hard- en software beschikbaar welke als uitgangspunt kan worden genomen voor het bepalen de hoogte van de desinvesteringen. Voor het vervolgtraject zijn een aantal specifieke acties aan te bevelen. Er zijn een aantal specifieke acties met betrekking tot het migratietraject, maar ook een paar acties die betrekking hebben op de regievoering en de meeste impact hebben. Deze laatste noemen we hier: 1) Opstellen van een programma van eisen en wensen (PvE) Om de architectuur verder uit te werken en te kunnen implementeren is een PvE noodzakelijk. Door het opstellen van een PvE ontstaat duidelijkheid over wat er geboden wordt en kan een kosteninschatting worden gemaakt. Ook is een PvE nodig voor een aanbestedingstraject. In plaats van deze top-down op te stellen, kan het proces worden versneld door de ICT afdeling een “voorschot” te laten geven voor het PvE. De gemeenten kunnen hierop reageren. 2) Borgen van de doelstellingen van de samenwerking. Doelstellingen zijn op dit moment nog niet SMART uitgewerkt. Dat geldt voor elk niveau: organisatorische doelen – welke doelen stellen we aan de ICT samenwerking, de ICT beleidsdoelen, de ICT architectuur uitgangspunten, de ICT processen en ontwerpprincipes. Daarnaast zouden meetinstrumenten moeten worden gedefinieerd om te meten of de doelen op elk niveau worden behaald. Door de doelstellingen op over verschillende niveaus aan elkaar te relateren ontstaat de mogelijkheid regie te houden over de kosten van de ICT en kunnen verwachtingen van de samenwerking worden gemanaged.


Pagina 4 van 17

Ook zijn de randvoorwaarden waaraan de samenwerking en beoogde ICT architectuur moet voldoen nog niet helder vastgelegd (bijvoorbeeld beveiliging). Deze zijn nodig omdat die bepalend zijn voor het ontwerp van de architectuur.


Pagina 5 van 17

3

Aanbeveling voor volgende stappen

In het rapport zijn een aantal te nemen acties benoemd welke kunnen worden opgepakt na de bestuurlijke goedkeuring voor de ICT samenwerking. Deze hebben we hier op een rijtje gezet. Ze zijn niet in volgorde van tijd gesorteerd. 1. Bepaal de keuze welke bedrijfsapplicaties tijdens een storing moeten blijven werken (alle applicaties, of alleen een deel ervan). Dit is mede bepalend voor de kosten van de inrichting van de datacenters. 2. Inventariseer welke applicaties “sessie awareness” ondersteunen en dus voor hot-standby geschikt zijn (alleen van toepassing wanneer hot-standby een eis is). 3. Maak een keuze tussen een snelle migratie of een gefaseerde migratie. Breng de kosten van desinvesteringen in kaart. 4. Indien er gekozen wordt voor een gefaseerde overgang, onderzoek dan het optimale moment waarop IT componenten zouden kunnen worden gemigreerd en zet die af tegen de te behalen voordelen (Dit onderzoek kan in tijd wat worden uitgesteld). 5. Maak doelstellingen meer SMART, en stel een regiematrix op. 6. Stel een PvE op. Laat de ICT werkgroep met een voorstel komen.


Pagina 6 van 17

4

Doelarchitectuur biedt een solide basis

Ten behoeve van de ICT samenwerking definieert de doelarchitectuur de gemeenschappelijke inrichting van ICT infrastructuur. Onder ICT infrastructuur vallen de volgende IT componenten: Netwerkinfrastructuur (verbindingen en netwerk componenten als routers, switches etc), serverruimten, serverhardware, aansturingssoftware (OS, virtualisatiesoftware), backoffice applicaties (zoals mail, databases, ERP systemen), werkplek hard- en software en beheer tooling.

4.1

Active/passive datacenter topologie de aanbevolen weg

Voor de inrichting van de datacenter topologie zijn een aantal varianten mogelijk. De keuze voor twee infrastructuren (datacenters plus SAN), op twee fysiek gescheiden locaties in een active/passive inrichting is het meest eenvoudig in te richten, te beheren en dus aan te bevelen. Daarnaast is er een keuze of in de fallback locatie alle, of alleen de bedrijfskritische applicaties worden gespiegeld en welke dat dan zijn (aanbeveling volgende stap). Alle verbindingen en infrastructuur dienen dubbel te zijn uitgevoerd; enkelvoudige uitvoering is vanwege continuïteitseisen en -wensen geen optie. Er zijn meerdere opties voor de inrichting van de datacentra 1) Active/passive configuratie 2) Loadsharing configuratie a. Verdeling van gebruikers over verschillende datacenters b. Verdeling van applicaties over verschillende datacenters In alle varianten moeten verbindingen van gemeenten met de datacentra, tussen de data centra onderling en tussen de datacentra en de SANs redundant zijn. Het netwerk moet zijn ingericht om te zorgen voor omschakelen bij uitval van verbindingen of van één van de datacenters. Active/passive configuratie Er is sprake van twee gelijksoortige infrastructuren op twee locaties. Alle gebruikers van alle gemeenten werken in principe alléén op het actieve infrastructuur. Bij uitval van deze locatie is de fallback locatie in staat om de diensten en informatievoorziening voort te zetten, en switchen gebruikers om naar de fallback locatie. Wanneer men kiest voor de active/passive topologie is de fallback locatie een z.g. “schaduw” datacenter. Er moet een keuze worden gemaakt of alle applicaties, of alleen de bedrijfskritische applicaties op de fallback locatie worden gespiegeld (en welke applicaties bedrijfskritisch zijn). Wanneer alléén voor bedrijfskritische applicaties wordt gekozen, dan kan de fallback locatie kleiner worden gedimensioneerd in termen van aantallen servers en vloeroppervlak. Dit scheelt in server hardware kosten, operating system licentiekosten, licentiekosten voor bedrijfsapplicaties, kosten voor huisvesting en energiekosten1. De keuze hangt af van de eisen en wensen van de gemeenten. Op dit moment heeft de gemeente Soest al haar applicaties gespiegeld op haar eigen locale fallback locatie. Maar dat geldt niet voor de

1

Het kostenaspect valt buiten de scope van deze opdracht, maar kosten zijn nog niet in kaart gebracht.


Pagina 7 van 17

gemeente Wijk bij Duurstede. Differentiatie tussen “alles of gedeeltelijk spiegelen” is niet mogelijk wanneer applicaties zijn geharmoniseerd en worden gedeeld. De snelheid waarmee de fallback locatie de dienstverlening kan overnemen, de gebruikers hun werk kunnen voortzetten en in welke mate zij een deel van de meest recent uitgevoerde werkzaamheden kwijt zijn, is afhankelijk of de fallback locatie een z.g. “hot standby” of “cold standby” is. In het eerste geval is er sprake van clustering van de totale datacenter configuratie; de SANs in beide locaties zijn geclusterd, er is sturing over beide locaties en de gehele configuratie is “sessie aware”. In dit geval kunnen de gebruikerssessies per direct of binnen zeer korte responstijd worden overgenomen door de fallback locatie. Zijn applicaties niet “sessie aware”, dan is er sprake van een cold standby. Omschakeltijden `zijn dan langer. Mogelijk gaat daarbij een deel van hun meest recent uitgevoerde mutaties verloren. Niet elke bedrijfsapplicatie is zondermeer “sessie aware” en dus geschikt voor een hot-standy configuratie. Het is bekend of men al in beeld heeft welke applicaties sessie aware zijn. Dit zal nader moeten worden onderzocht (aanbeveling volgende stap). “Hot standby” is complexer dan “cold standby”. Voor “hot standby” moeten specifieke voorzieningen in het datacenter en netwerk worden getroffen (automatische omschakeling van IP adressering, implementatie van sessie awareness houdt in dat gebruikerssessie statusinformatie in beide locaties wordt bijgehouden). Daar moet het ontwerp in voorzien. Loadsharing – verdeling van gebruikers In dit geval zijn gebruikers verdeeld over twee locaties, en zijn beide locaties actief. Op beide locaties draaien alle applicaties. Bij uitval van één locatie, schakelen gebruikers om naar de andere locatie. Hiervoor is SAN clustering een vereiste. De snelheid waarmee de dienst kan worden overgenomen door de andere locatie hangt af van hoe de clustering is geconfigureerd: hot standby of cold standby. Zie daarvoor de uitleg bij active/passive configuratie. Door het verdelen van de workload over twee locaties is het mogelijk om beide locaties kleiner te dimensioneren, onder de voorwaarde dat een teruggang in performance tijdens probleemtijden (alle gebruikers werken op één locatie) acceptabel is. In dat geval zijn er kosten besparingen mogelijk (zie active/passive configuratie voor een uitleg). Nadeel van deze variant is dat hij complexer is en lastiger is te beheren. Loadsharing – verdeling van applicaties Deze variant is niet beschreven in de migratiescenario’s. In dit geval draait een deel van de applicaties op de ene locatie, een ander deel op de andere locatie. Gebruikers werken gelijkertijd op beide locaties. In principe zijn alle denkbare verdelingen mogelijk. Zo zou je ervoor kunnen kiezen om bijvoorbeeld de bedrijfskritische applicaties op 1 locatie te concentreren, en de niet bedrijfskritische applicaties op de andere locatie. De niet bedrijfskritische locatie zou je dan minder robuust kunnen inrichten (minder robuuste apparatuur). Een andere variant zou kunnen zijn bijvoorbeeld de database servers op 1 locatie te concentreren, en de rest op de andere locatie. Second opinion migratieplan infrastructuur samenwerkende gemeenten Versie 1.0 oktober 2011

Pagina 8 van 17

Dezelfde replicatievraagstukken als bij de active/passive inrichting speelt hier ook, echter nu beide kanten op. Locatie A fungeert als fallback voor locatie B voor die applicaties die primair op locatie A draaien en vice versa. De inrichting en het beheer van deze configuratie is ook complexer dan het active/passive scenario.

4.2

Uitgangspunten – ontwerpprincipes zijn juist

De werkgroep ICT heeft een aantal ontwerpprincipes gedefinieerd voor de inrichting van de datacenters (inclusief de SANs). Deze moeten de doelstellingen voor ICT samenwerking ondersteunen. De ontwerpprincipes zijn logisch en juist. Achter elk principe hebben wij een opmerking geplaatst met onze observatie over die specifieke doelstelling. Ontwerpprincipes • Principe 1: Twee datacenters met gespiegelde infrastructuur Observatie M&I/partners: dit is een juist ontwerpprincipe. Twee datacenters zijn nodig om de continuïteit en beschikbaarheid te borgen. Afhankelijk van de keuze van de datacenter topologie is een volledige spiegeling of gedeeltelijke spiegeling nodig. •

Principe 2: eigen OTA Observatie M&I/Partners: een eigen test en acceptatie omgeving voor nieuwe (versies van) applicaties te kunnen testen en accepteren voor de productieomgeving is verstandig. Testen van nieuwe (versies van) applicaties op de productieomgeving levert risico op en kan de continuïteit van de bedrijfsprocessen in gevaar brengen. Men zou kunnen overwegen om de capaciteit voor deze OTA omgeving uit te besteden (outsourcing i.p.v. in eigendom). Dit omdat testen en acceptatie niet een continu proces is.

• •

Principe 3: eigen backup, restore en uitwijkfaciliteiten (back up voorziening/tape library op een derde locatie) Principe 4: Centrale data opslag (SAN), data replicatie over beide datacenters Observatie M&I/Partners m.b.t. principe 3 en 4: dit is nodig voor het bieden van de gevraagde continuïteit en beschikbaarheid. Zie ook paragraaf over de datacenter topologie voor nadere onderbouwing van duplicatie van SAN infrastructuur.

• •

Principe 5: Blade server technologie Principe 6: Server virtualisatie (VMWare) Observatie M&I/Partners m.b.t. principes 5 en 6. Toepassing van blad server technologie en server virtualisatie (beide moderne technologieën) leiden tot een hogere efficiëntie doordat de capaciteit van servers beter wordt benut. Daarbij is er tevens een hogere flexibiliteit: toevoegen van server capaciteit is eenvoudig(er) te realiseren dan bij het toepassen van standaard servers en het niet toepassen van virtualisatie.


Pagina 9 van 17

• •

Principe 7: Thin clients Principe 8: VDI (waarbij nog een keuze gemaakt zal dienen te worden welke leverancier Citrix, Vmware, Microsoft) Observatie M&I/Partners m.b.t. principes 7 en 8. VDI (Virtual Desktop Infrastructure) is een implementatie technologie waarmee thin clients kunnen worden gerealiseerd. Het leidt tot minder beheer op de desktop en minder kosten. Wanneer ook gekozen wordt voor fysieke hardware thin clients (dus niet een thin client op een PC) is het energieverbruik ook lager.

•

Principe 9: Applicatie virtualisatie (waarbij nog een keuze gemaakt zal dienen te worden welke leverancier Unidesk, Vmware, Microsoft, anders…) Observatie M&I/Partners m.b.t. principe 9: applicatie virtualisatie maakt het mogelijk om applicaties die voor een specifiek platform zijn ontwikkeld, nu ook op een ander platform te draaien. Hierdoor wordt hardware harmonisatie mogelijk, en dat is daardoor kosten efficienter.

•

Principe 10: VoIP Telefonie Observatie M&I/Partners m.b.t. principe 10: door het toepassen van VoIP kunnen gemeenten onderling goedkoper bellen. Er zijn geen telefoongesprekken via het openbare PSTN (Public Switched Telefony Network) nodig. Daarnaast opent VoIP de mogelijkheid om eenvoudiger telefonie te integreren met allerlei desktop applicaties (unified Communications). VoIP is een moderne technologie.

•

Principe 11: Windows + Oracle Observatie M&I/Partners m.b.t. principe 11: door de keuze voor één OS en DBMS is beheeroptimalisatie mogelijk (kennis concentratie). Windows en Oracle zijn z.g. “de facto” standaarden waarom veel applicaties kunnen draaien. Daarnaast draaien vele van de huidige applicaties al op die twee platformen.

•

Principe 12: Glasvezelverbindingen tussen gemeenten en datacenters en tussen de datacenters onderling Observatie M&I/Partners mbt principe 12: Glasvezel is nodig voor de gewenste performance en benodigde bandbreedte.


Pagina 10 van 17

5

Migratiescenario’s – veel voordelen bij een snelle migratie

De hoofdindeling in 4 migratie plateaus is logisch. Dit hoofdstuk gaat specifiek in op de migratie van IT componenten na het opbouwen van de centrale huisvesting: de migratie van de servers, software en bedrijfsapplicaties welke plaatsvindt gedurende plateau 3 en 4 van de migratie, en is daarmee een aanvulling op het migratieplan wat er nu ligt. In de praktijk zullen plateau 2, 3 en 4 gedeeltelijk parallel worden uitgevoerd, zoals dat al in het document “inventarisatie ICT infrastructuur RID Oost-Utrecht” is beschreven. Er zijn twee hoofdscenario’s voor het migreren van de individuele IT componenten van de ICT infrastructuur. Bij een snelle migratie wordt parallel aan de huidige server inrichting het nieuwe datacentrum volledig ingericht, gedimensioneerd op alle benodigde systemen. Vervolgens worden alle servers en software van de deelnemende gemeenten in korte tijd omgezet. De doorlooptijd wordt bepaald door de inspanning en de beschikbare menskracht en de doorlooptijd van een mogelijke aanbesteding. In de gefaseerde aanpak worden sommige servers en bedrijfsapplicaties snel gemigreerd, en anderen op een later moment. De snelle migratie aanpak levert qua beheer, hardware en applicatie harmonisatie het snelst voordeel op en de beoogde doelstellingen van de ICT samenwerking worden het snelst gerealiseerd. Maar dit gaat gepaard met desinvesteringen. De hoogte van de desinvesteringen kunnen ertoe leiden dat er gekozen moet worden voor een meer gefaseerde aanpak. De definitieve keuze is echter pas goed te bepalen wanneer de kosten goed in kaart zijn gebracht (aanbeveling volgende stap). De voorgestelde doelarchitectuur zoals besproken in vorig hoofdstuk (SANs, Datacenters en tussenliggende netwerken) kan beide scenario’s aan.

5.1

Snelle migratie – het snelst naar de doelarchitectuur

In een snel migratie scenario wordt parallel aan de huidige server inrichting het nieuwe datacentrum volledig ingericht, gedimensioneerd op alle benodigde systemen. Vervolgens worden in korte tijd alle servers en software van de deelnemende gemeenten in één traject, beheerst omgezet. De doorlooptijd wordt bepaald door alleen de benodigde inspanning en de beschikbare menskracht, en de doorlooptijd van een mogelijke aanbesteding. Kosten zijn in dit scenario ondergeschikt aan de doorlooptijd. Met een snel migratie scenario wordt de doelarchitectuur het snelst gerealiseerd, en daarmee zijn de voordelen en de beoogde ICT doelstellingen van de samenwerking ook het snelst bereikt. Het snel migratie scenario kent echter ook desinvesteringen. Zo zijn recentelijk nog nieuwe investeringen gedaan en contracten aangegaan voor de vernieuwing van bepaalde servers en applicaties. Bij een snelle migratie worden alle servers en applicaties in één kort traject gemigreerd en leidt dit dus tot desinvesteringen in hardware, software en mogelijk licenties (versnelde afschrijving of afkoopregelingen). Het overzicht “Samenvatting inventarisatie huidig aanp soest.xlsx” geeft een goed overzicht van de in gebruik zijnde ICT infrastructuur, hoe de financiering is geregeld en wanneer de contracten afloSecond opinion migratieplan infrastructuur samenwerkende gemeenten Versie 1.0 oktober 2011

Pagina 11 van 17

pen. Met behulp hiervan kunnen de desinvesteringen worden berekend. Voor die componenten waarvoor binnenkort de contracten verlopen is er geen desinvestering. Het snel migratie scenario realiseert het snelst de beoogde ICT doelstellingen doordat hardware- en werkplek harmonisatie nu snel kan worden ingezet. De hardware en werkplek harmonisatie levert namelijk beheervoordelen op: minder diversiteit aan hardware, en centralisatie van de hardware. Dit resulteert niet alleen in minder inspanning (hogere efficiency) maar is ook effectiever doordat kennisconcentratie mogelijk is (geen onderhoud verschillende systemen, achtervang en overdracht van werkzaamheden is makkelijker realiseerbaar, minder opleidingen).

5.2

Gefaseerde migratie

In de gefaseerde aanpak zullen sommige IT componenten (servers en bedrijfsapplicaties) snel worden gemigreerd, anderen op een later moment. De keuze wanneer welk IT component te migreren wordt bepaald door enerzijds de mate van urgentie (wanneer verlopen contracten) en waar al snel en eenvoudig voordeel valt te behalen (“low hanging fruit”) en anderzijds de grootte van desinvesteringen. De keuze wanneer welke server en applicaties te migreren is per applicatie verschillend. Financiële aspecten spelen hierin een rol, maar andere randvoorwaarden zijn ook belangrijk, zoals de maximale doorlooptijd. Bij een gefaseerde aanpak adviseren wij wel om een maximale migratietijd aan te houden van tussen de twee en drie jaar. Het overzicht “Samenvatting inventarisatie huidig aanp soest.xlsx” is een goede basis om te bepalen welke componenten snel, welke op middenlange termijn en welke nog “voorlopig nog niet” worden gemigreerd. 1. Snel te migreren Dit zijn alle componenten waarvan de contracten binnenkort of al zijn verlopen (must) of die reeds zijn afgeschreven. Daarnaast zijn er een aantal componenten die bij veel, of alle gemeenten reeds in gebruik zijn. Omdat de overlap voor deze componenten groot is, is er al sprake van applicatieharmonisatie, en zijn er grote voordelen te behalen deze snel te migreren (hardware harmonisatie; low hanging fruit. Deze keuze is optioneel). Een voorbeeld van dat laatste is de Oracle Database implementatie en de Exchange mail servers. Het is in ieder geval van belang om snel te starten met het SAN en VMware zodat er ook snel een goede gezamenlijke uitwijk kan worden gerealiseerd2. 2. Migratie op middenlange termijn Dit zijn alle componenten die niet tot de andere twee groepen behoren. Het moment om deze componenten te migreren is voor elk moment in principe verschillend en wordt bepaald door een afweging tussen de mate van desinvestering en de te behalen voordelen van migratie. Hiervoor is onderzoek nodig om het optimale moment te bepalen (aanbeveling volgende stap). 3. Voorlopig nog niet te migreren Dit zijn de componenten waarvoor migratie het moeilijkst is. Er zijn twee mogelijke redenen: 1) grote des-investeringen en 2) componenten met een andere architectuurgrondslag dan die is voorzien in de datacenters.

2

Los daarvan zal moeten worden bepaald voor welke van de applicaties/servers een uitwijk nodig is. Zie hoofdstuk 4


Pagina 12 van 17

De oorzaak van mogelijke desinvesteringen zijn mogelijk recentelijk afgesloten contracten (lease contract, onderhoudscontract, licenties etc) met mogelijke hoge afkoopsommen, componenten met een hoge restwaarde (afschrijvingstermijn nog niet verlopen) etc. Een voorbeeld van de eerste categorie is de SAP implementatie die op AS400 draait in de gemeente Utrechtse Heuvelrug (hiervoor is zeer recent nog een lease contract voor 7 jaar afgesloten). Componenten met een andere architectuurgrondslag kunnen niet eenvoudig geport worden naar de architectuur van het datacenter. Dit zijn applicaties die bijvoorbeeld onder een ander bedrijfssysteem draaien en welke niet zomaar geschikt zijn om op VM Ware onder Windows te draaien (VMWare/Windows is de server omgeving in het datacenter)3. Het huidige inzicht is nu dat het hier gaat om geen, of een zeer beperkt aantal applicaties waarvoor dit geldt. Het moment om deze componenten te migreren wordt bepaald door een afweging tussen de mate van desinvestering en de te behalen voordelen van migratie. Bij een gefaseerde migratie adviseren wij wel de migratietermijn maximaal twee of drie jaar te laten duren. Langer zou leiden tot verlies van momentum, en ook de voordelen en doelstellingen die worden beoogd met de ICT samenwerking laten dan lang op zich wachten. Voor die IT componenten waarvoor de contracten nog niet zijn verlopen, of nog niet in zijn geheel zijn afgeschreven zijn dan wel desinvesteringen gepaard. De hoogte daarvan zouden redelijk eenvoudig kunnen worden bepaald aan de hand van het reeds beschikbare inventarisatie overzicht.

Naast de keuze welk component wanneer te migreren speelt de vraag rondom “housing”: waar staan de componenten die nog niet zijn gemigreerd? Er zijn twee mogelijkheden: • De componenten worden fysiek overgebracht naar de datacenters (dit geldt voor de componenten op de huidige serverlocatie, en die op de huidige fallback locaties van de individuele gemeenten). • De componenten blijven in de huidige serverruimten op locatie staan. Voordeel van de eerste keuze is dat dit beheertechnisch voordelen oplevert vanwege de centralisatie (minder reizen tussen locaties en dus snellere responstijden bij incidenten waarvoor on-site aanwezigheid noodzakelijk is). Daarnaast voldoen de serverruimten in de nieuwe datacenters aan alle moderne eisen qua koeling, veiligheid etc. Bij centralisatie zijn investeringen in de serverruimten op de locaties niet nodig (bijvoorbeeld in de huidige serverruimte van Bunnik is extra koeling nodig. Dat is dan overbodig). Het overbrengen van fysieke componenten naar de nieuwe datacenters kan mogelijk risico’s met zich meebrengen (verhuizen van gevoelige computer apparatuur met de nodige kans op beschadigingen). Dit brengt ook herinrichtingskosten met zich mee (verbindingen, fysieke installatie). Daarom zo uje dit alleen moeten doen voor die IT componenten die nog langere tijd niet worden gemigreerd en in gebruik blijven (bv de AS400). Een aspect wat daarnaast moet worden onderzocht is of de serverruimten van de nieuwe datacenters fysiek voldoende ruimte hebben om alle hardware te housen van die servers die nog niet worden gemigreerd en gevirtualiseerd.

3

De meeste huidige applicaties zijn echter wel geschikt om onder VWMare/Windows te draaien.


Pagina 13 van 17

6

Overige observaties

Uit ervaring van M&I/Partners blijkt dat de doelstellingen die met ICT samenwerking worden beoogd, alleen worden behaald wanneer er goede regievoering is. Als die ontbreekt is het resultaat juist vaak een hoger kostenniveau, niet waargemaakte verwachtingen en ontevredenheid bij bestuurders en gebruikers. De mechanismen voor een goede regievoering beginnen met SMART doelstellingen, maar moeten verder worden uitgewerkt. Dat is op dit moment nog niet goed afgedekt. Het tevens nodig om voor de implementatie van een gemeenschappelijke voorziening helder de eisen en wensen vast te leggen. De eisen en wensen bepalen nl het kostenniveau van de implementatie. Een Programma van Eisen en Wensen (PvE) is nog niet aanwezig. Om snelheid te maken zou de werkgroep een voorstel kunnen doen welke door de deelnemende gemeenten vervolgens kan worden aangevuld en geaccordeerd.

6.1

Borging van doelstellingen - regievoering door vastleggen van doelstellingen op elk niveau

Gemeenten hebben verwachtingen (en dus doelstellingen) van de ICT samenwerking. Deze doelstellingen moeten uiteindelijk door de beoogde gemeenschappelijke voorziening, en het beheer daarover, worden gerealiseerd. Om die doelstellingen te borgen is een goede regievoering nodig, die 1) het mogelijk maakt om te meten of doelstellingen worden gehaald en 2) wanneer noodzakelijk kan bijsturen. Dit wordt mogelijk door de doelen SMART te uit te werken op elk van de volgende niveaus: organisatie doelen, ICT beleidsdoelen, ICT architectuur, ICT processen en ontwerpprincipes. Door de doelstellingen onderling over de verschillende niveaus aan elkaar te relateren ontstaat een duidelijke relatie tussen doelstellingen en genomen maatregelen. Daarnaast moeten op elk niveau meetinstrumenten worden gedefinieerd om te kunnen bepalen of de doelen worden behaald. Op deze wijze ontstaat de mogelijkheid regie te houden over de kosten van de ICT en kunnen verwachtingen van de samenwerking worden gemanaged. Tevens creëert dit meer houvast bij het opstellen van een programma van eisen en wensen voor de gemeentelijke samenwerking. Op dit moment zijn er wel doelstellingen gedefinieerd, maar nog niet op elk niveau. De doelstellingen zijn niet SMART uitgewerkt. Doelstellingen zijn niet over de verschillende niveaus aan elkaar gerelateerd. Ook zijn de meetinstrumenten niet gedefinieerd om te bepalen of de doelen worden behaald. Daarnaast zijn ook verschillende randvoorwaarden nog niet helder vastgelegd. Bijvoorbeeld: wat zijn de randvoorwaarden voor beveiliging? Deze zijn zeer bepalend voor de keuzes op ontwerpniveau. Het is dus van belang om ook de randvoorwaarden in kaart te brengen. In het bijlage 1 hebben wij een voorbeeld voor deze opdracht toegevoegd. Het dient als voorbeeld. Het is niet compleet en geeft een aantal voorbeelden om bovenstaande betoog te verhelderen.


Pagina 14 van 17

6.2

PvE voor de doelarchitectuur – de werkgroep kan een voorschot doen

Om de doelarchitectuur te kunnen implementeren is een PvE noodzakelijk. Daarnaast is bij een aanbesteding een PvE onontbeerlijk. Er is op dit moment nog PvE. Het is aan te bevelen om z.s.m. na het bestuurlijke fiat hier aan te beginnen. Door het opstellen van een PvE ontstaat duidelijkheid over wat er geboden wordt en kan een kosteninschatting worden gemaakt. Hoe specifieker wordt vastgelegd wat wordt geëist en gewenst, hoe beter het aanbod aansluit bij de verwachtingen. In het PvE moeten niet alleen functionele aspecten worden vastgelegd, maar ook niet-functionele aspecten voor zowel de architectuur (techniek) als het beheer. In bijlage 2 staat een lijst van te adresseren aspecten. In plaats van het PvE top-down op te stellen, kan het proces worden versneld door de ICT afdeling een “voorschot” te laten geven voor het PvE. De gemeenten kunnen hierop reageren.


Pagina 15 van 17

7

Bijlagen

7.1

Bijlage 1 – Regiematrix - doelen en meetinstrumenten

In bijgevoegd document “regiematrix – overzicht van doelen en controls” (aparte bijlage) is in de velden met zwart letterfont informatie opgenomen die in de verschillende beschikbare documenten terug te vinden is. Er zijn een aantal voorbeelden toegevoegd in rood letterfont. De toegevoegde velden zijn dan ook voorbeelden van mogelijke meetinstrumenten, doelwaarden etc.

7.2

Bijlage 2 – PvE checklist

Het PvE dient de volgende punten te adresseren • • • •

Scope Huidige situatie; hardware, applicaties, adressen van huidige verbindingen, bandbreedte & type verbinding, huidig verkeersaanbod) – voor een belangrijk deel al aanwezig Gewenste situatie – voor een belangrijk deel al aanwezig Eisen en wensen o Functionele eisen en wensen t.a.v. het netwerk Type verbindingen (bandbreedte, locaties etc) Architectuur (netwerk architectuur, IP adres schema, etc) Diensten over de verbindingen transportdiensten • Bv VPN, thuiswerk, datasych, e.d. Type verkeersondersteuning (QoS, prioritering etc) o Functionele eisen en wensen t.a.v. de servers o Non functionele eisen en wensen Beschikbaarheid (netwerk, verbindingen en per applicatie. Redundantie eisen) Performance (responsetijden/delay van het netwerk en applicaties) Beveiligingseisen Onderhoudbaarheid (maximale beheerlast in termen van uren-kosten/jaar) Flexibiliteitseisen aangaande • functionaliteit (basis/plus pakket) • capaciteit (netwerk capaciteit, server capaciteit) • Configuratie management o Eisen en wensen t.a.v. beheer Eisen en wensen mbt alle ITIL processen SLA niveaus Levertijden nieuwe verbindingen, nieuwe applicaties, uitlevertijden etc Monitoring (vwb beschikbaarheid, capaciteitsgebruik, performanceaspecten) Service rapportages Beheer tooling o Eisen en wensen t.a.v. migratie Duur


Pagina 16 van 17

Testplan en testen Tijdstip van uitvoering Acceptatievoorwaarden (oplever protocollen e.d.)

Bij een aanbesteding zou hieraan moeten worden toegevoegd: o

o o

Algemene eisen: denk aan eisen en wensen mbt Contract – toevoegingen mogelijk van type en aantal verbindingen, opzeggingen e.d. Certificering van organisatie en medewerkers • Rondom beveiliging • Beheer • Kwaliteit • Projecten organisatie Financiele zaken (bv alles specificeren in €, ex BTW etc) Facturering Marktconformiteitsclausule Onderaannemerschap en aanspreekpunten (penvoering) Prijzenblad Gunningsvoorwaarden (weging prijs v.s. inhoudelijke component)


Pagina 17 van 17

Second opinion migratieplan infrastructuur samenwerkende gemeenten

Recommend Documents