Informatiearchitectuur

Gemeente Zaanstad

Foto: George W. Hart

1

Inhoud1 Inleiding ............................................................................................................ 3 2 Samenvatting en leeswijzer ..................................................................................... 3 3 Wat is informatiearchitectuur en waarom is het nodig? .................................................... 4 4 Overzicht van de principes voor de informatiearchitectuur ................................................ 6 5 Indeling architectuurdocument volgens model conform NORA ........................................... 13 6 Proces om te komen tot informatiearchitectuur ........................................................... 14 7 Uitgangspunten vanuit het informatiebeleid ................................................................ 15 8 Bedrijfsarchitectuur ............................................................................................. 16

8.1 Organisatie .................................................................................................. 16 8.2 Diensten en producten .................................................................................... 18 8.3 Processen .................................................................................................... 20

9 Informatiearchitectuur ......................................................................................... 23 9.1 Applicaties ................................................................................................... 24 9.2 Berichten, gegevens, informatieuitwisseling ........................................................... 26

10 Technische architectuur ...................................................................................... 27 10.1 Technische Componenten ............................................................................... 33 10.2 Gegevens opslag (Data laag) ............................................................................ 35 10.3 Netwerk .................................................................................................... 36

2

1 Inleiding

Doel document De informatiearchitectuur beschrijft de samenhang tussen de visie op dienstverlening, de bedrijfsprocessen en de daarbij benodigde informatievoorziening. De informatiearchitectuur geeft regels voor applicaties, gegevens en techniek.

Doelgroep Doelgroep van dit document is: GMT, MT’s, stuurgroep digitaliseren, afdelings- en sectorhoofden, medewerkers PIO, IBZ, ICT, gegevensbeheerders, applicatiebeheerders

Auteur(s) Afdelingen PIO, IBZ, ICT (T. Uleman, G.J. Timmerman, B. Smit, R. Tromp, G.J. Doves, F. Kerkhoven, R. Harmsma)

Bronnen Naast de Nederlandse overheids referentiearchitectuur (NORA) is gebruik gemaakt van teksten en plaatjes van architectuurdocumenten van andere gemeenten, o.a. gemeente Amsterdam.

Versiebeheer Versie Datum Opmerkingen0.7 Okt 07 Indeling in lagen: omgeving,

processen/bedrijfsvoering, informatie/applicaties, gegevens, technische infrastructuur

1.4 Febr 08 Indeling in 9 vlakken, input van architectuur handboek Amsterdam benut

2.0 Apr 08 Aanvullingen met technische architectuur, aanvullingen met principe-hoofdstuk

2.3 Apr 08 Tekstuele wijzigingen2.4 Juli 08 Naar aanleiding van review: lijst van definities,

samenvatting, verwijzingen verhelderd, plaatjes vergroot, opstellen separate populaire versie

2.8 Okt 08 m.n. tekstuele aanpassingen

2 Samenvatting en leeswijzer

Werken onder informatiearchitectuurEr is samenhang tussen processen in de organisatie en de ICT middelen die de processen ondersteunen: Werkprocessen bepalen de inrichting van applicaties en gegevensregistraties. De technische infrastructuur van computers en netwerk sluit daarop aan. Dit betekent dat de “eigenaren” van de genoemde zaken goed met elkaar moeten afstemmen, zodat de ICT aan de eisen van de organisatie blijft voldoen. Omgekeerd zijn er vanuit de ICT-kant ook eisen, om de continuïteit van werkprocessen en efficiëncy in ICT-beheer te waarborgen. Het is daarom zinvol om afspraken te maken over de ontwikkelingen in die nodig zijn in het applicatielandschap en de gegevensstromen. Dit heet ‘werken onder informatiearchitectuur’.

OntwikkelingenDe ontwikkelingen in de organisatie op het gebied van dienstverlening zijn basis voor architectuurbeslissingen, te weten:

• de vorming van het klantcontactcentrum, • de realisatie van nieuwe digitale diensten en • samenwerking met andere organisaties

Zij leiden samen met doelen van het Rijk (o.a. de inrichting van basisregistraties en keuzes voor open standaarden) en efficiencydoelen van de gemeente tot keuzes voor applicaties, gegevensuitwisseling en techniek. De gemeente Zaanstad kiest voor de applicaties van Govunited voor de ondersteuning van dienstverlening. Verder kiest de gemeente voor de inzet van gemeentebrede generieke applicaties, als dat mogelijk is, boven vakspecifieke applicaties.

3

Uitgangspunten (principes)De uitwerking van de verschillende onderdelen van de informatiearchitectuur (organisatie, informatie, techniek) leidt tot een aantal uitgangspunten voor verdere ontwikkelingen. Deze uitgangspunten zijn in grote lijnen:

• zorg voor betrouwbaarheid in gegevensuitwisseling• kies voor open standaarden bij gegevensuitwisseling• gebruik messaging systemen voor gegevensuitwisseling• gebruik zoveel mogelijk generieke applicaties; hergebruik reeds aanwezige functionaliteit

in applicaties• hergebruik gegevens uit de basisregistraties• standaardiseer in techniek

LeeswijzerHoofdstukken 3 tot en met 7 zijn algemene hoofdstukken waarin de noodzaak voor architectuur wordt aangegeven (hoofdstuk 3), de indeling van het document is toegelicht (hoofdstuk 5), het proces om te komen tot architectuur (hoofdstuk 6). Hoofdstuk 4 bevat principes waaraan nieuwe ontwikkelingen moeten voldoen. Deze principes komen uit de latere hoofdstukken 8, 9 en 10 waarin achtereenvolgens de bedijfs-, informatie- en technische architectuur is uitgewerkt.

3 Wat is informatiearchitectuur en waarom is het nodig?

Definitie Een informatiearchitectuur is een samenhangende visie van een organisatie op haar bestaande en gewenste informatievoorziening. De informatiearchitectuur laat de elementen van de informatievoorziening en hun samenhang zien, incl. de bedrijfsarchitectuur en de ICT architectuur. In begrijpelijke taal: welke informatie is nodig bij processen, nu en in de toekomst? Welke applicaties en gegevens gebruiken we daarbij? En wat is de benodigde techniek? De informatiearchitectuur gaat hier op hoofdlijnen op in.

Doelen architectuur

De informatiearchitectuur is een stuurinstrument om businessdoelen te bereiken. Het is een referentie bij het nemen van beslissingen over nieuwe applicaties en benodigde investeringen. Dit draagt bij aan het gecontroleerd uitvoeren van veranderingen in de informatievoorziening. De informatiearchitectuur geeft inzicht in de samenhang tussen bedrijfsdoelstellingen, processen en techniek. Dit architectuurdocument bevat ook meer algemene definities, deze zijn opgenomen om dezelfde taal te spreken.

Risico’s bij ontbreken

Zonder informatiearchitectuur zijn er risico’s:• Applicaties overlappen elkaar in functionaliteit (zo hebben we meerdere

kadastrale registraties en op verschillende plaatsen documentenopslag). Dubbelingen geven verwarring over de ware bron en is uiteraard inefficiënt in beheer

• Er kunnen zich ongewenste investeringen voordoen in applicaties of koppelingen tussen applicaties omdat nieuwe ontwikkeling onvoldoende aansluiten op hun omgeving. Denk aan een nieuwe applicatie die niet goed aansluit op de bestaande infrastructuur.

• Er is gebrek aan innovatie (we hebben nu bijvoorbeeld geen geavanceerd documentair informatiesyteem dat aan de eisen van gebruikers voldoet). Vernieuwingen zijn moeilijk te sturen en op elkaar af te stemmen

Afbakening In dit document is vooral aandacht voor de dienstverleningsprocessen en hun gevolgen voor de applicaties en gegevens. Andere gemeentelijke processen (zoals bedrijfsvoering) zijn nog niet uitgewerkt. De reden hiervoor is dat we verwachten dat juist in de dienstverlening de grootste veranderingen in de informatiearchitectuur zullen optreden. Dit neemt niet weg dat de i-architectuur

4

later uitgebreid kan worden voor de overige gemeentelijke processen.

Model

Het model toont de plaats van de informatiearchitectuur ten opzichte van informatiebeleid en informatieplanning (zoals dienst i-plannen en masterplanning van i-projecten). De informatiearchitectuur geeft concrete grondslagen, modellen en standaarden, beheerprocedures, een beschrijving van de inrichting van de informatievoorziening en de bouwkundige kaders waarbinnen gewerkt moet worden. Op basis van het informatiebeleid en de architectuur wordt vanuit de twee invalshoeken (inrichten en richten) een informatieplanning opgesteld om de cruciale informatie- en ICT-voorzieningen te realiseren (uitvoeren).

INFORMATIEPLANNING

UITVOERING

INFORMATIE BELEID

INFORMATIEARCHITECTUUR

BeleidsvisieAfstemming bedrijfsbeleidGlobaal bedrijfinformatiemodelBeleidsrealisatierichtlijnen

Model van informatie-voorziening, Architectuurplan

Middellange termijnplannenKorte-termijnplannen zoals dienst i plannen

systeem aanschaf, gebruik, exploitatie en onderhoud

Inrichten

Richten

Uitvoeren

5

4 Overzicht van de principes voor de informatiearchitectuur

Dit is geen managementsamenvatting, maar een overzicht van alle architectuurprincipes die in de gemeente Zaanstad gelden. De principes zijn in het document nader toegelicht, met uitzondering van enkele. Niet alle principes zijn meetbaar, sommige geven alleen richting aan. De principes kun je hiërarchisch ordenen, zie daarvoor de afbeelding op pagina 11. Algemene principes

Principe A1, Optimale dienstverlening (zie pagina 15, paragraaf Uitgangspunten vanuit het informatiebeleid)StatementBij de dienstverlening wordt het digitale kanaal optimaal ingezet. (*, zie Reden)Gegevens van burgers en bedrijven worden hergebruikt en niet opnieuw uitgevraagd.Ongeacht het kanaal dat de burger gebruikt is het antwoord hetzelfde.RedenGemeente Zaanstad voldoet hiermee aan landelijke eisen en streeft op deze wijze invulling na van klantgerichtheid en verbetering van dienstverlening. (*) Het digitale kanaal voor dienstverlening is goedkoper dan balie- of telefoniecontacten. De gemeente mag er echter niet voor kiezen uitsluitend het digitale kanaal te gebruiken en andere kanalen te sluiten, omdat alle groepen in de samenleving in staat moeten zijn contact te hebben met de gemeente.ImplicatiesZowel organisatie, processen als systemen voor dienstverlening dienen naadloos op elkaar aan te sluiten en onderling van elkaars status en communicatie op de hoogte te zijn.

Principe A2, Efficiency (zie pagina 15, Uitgangspunten vanuit het informatiebeleid)StatementInzet van generieke applicaties boven specifieke applicaties die slechts één product ondersteunen.Samenwerking met andere organisaties om oplossingen te delenHergebruik van componenten uit processen en applicaties waar mogelijk.RedenStreven naar oplossingen met zo laag mogelijke kosten.ImplicatiesGenerieke applicaties met niet geheel volledige functionaliteit prevaleren boven vakapplicaties met 100% functionaliteit.Processen en applicaties dienen modulair te zijn opgebouwd. De processen en applicaties moeten schaalbaar zijn.

Principe A3, Aansluiting op standaards (zie pagina 15, Uitgangspunten vanuit het informatiebeleid)StatementGegevensuitwisseling gebeurt volgens actuele open standaardsDe gemeente Zaanstad sluit aan op de Nederlandse Overheids ReferentiearchitectuurRedenUitwisseling van data onderling is bij gebruik van open standaarden altijd gewaarborgd. Open standaarden bieden toegang tot een zo breed mogelijke markt.ImplicatiesNieuwe applicaties moeten voldoen aan deze eis. Bij keuze tussen vakapplicatie met 100% functionaliteitsdekking, maar geen gebruik open standaarden en applicatie met beperkte functionaliteitsdekking maar wel gebruik open standaarden prevaleert de laatste.

Principe A4, Betrouwbaarheid (zie pagina 15, Uitgangspunten vanuit het informatiebeleid )StatementVolledigheid van gegevensuitwisseling is gewaarborgd.RedenNa eenmalige aanlevering kan de burger erop vertrouwen dat zijn actuele gegevens in alle werkprocessen worden gebruikt, dus in alle relevante applicaties zijn verwerkt.Implicaties

6

Inregelen processen om volledigheid te waarborgen; steeksproefgewijze controles op volledigheid.

Bedrijfsarchitectuurprincipes

Principe B1, KCC als single point of contact (zie pagina 16, Organisatie)StatementHet gemeentelijke front office groeit naar één loket voor de gehele overheidAlle klantcontacten vinden plaats in KCC Het KCC zorgt voor een integraal antwoord. RedenHiermee wordt invulling gegeven aan het nagestreefde niveau van dienstverlening. De basis hiervoor is de gemeentelijke Visie op Dienstverlening in 2015 en de landelijke ontwikkeling De gemeente heeft Antwoord.ImplicatiesAlle communicatie en distributiekanalen komen samen bij het KCC of worden vanuit het KCC geregisseerd. Het KCC is verantwoordelijk voor de juistheid, volledigheid en consistentie van de klantcontacten. Het KCC regisseert de procesintegratie naar de back-office.

Principe B2, Transparant (zie pagina 16, Organisatie)StatementBurgers en bedrijven kunnen zichzelf op de hoogte stellen van status, inhoud en afhandeling van hun aanvragen. RedenInvulling van de optimale en efficiënte dienstverlening.Implicaties Alle producten/diensten moeten via een persoonlijke internetpagina (dat gevoed wordt via een WFM-systeem) volgbaar zijn.

Principe B3, Ketensamenwerking (zie pagina 16, Organisatie, Ontwikkeling 2 Samenwerking met andere organisatie)StatementBackoffices en externe partijen leveren (deel)producten aan het gemeenschappelijke overheidsloket (KCC). Processen gaan over organisatiegrenzen heen.RedenInvulling van dienstverlening vereist samenwerking met ketenpartners. Samenwerking met ketenpartners kan de efficiëntie vergroten.ImplicatiesProcessen en infrastructuren moeten zowel functioneel als technisch koppelbaar zijn.

Principe B4, Processen generiek inrichten (zie pagina 20, Processen)Het streven is om producten en diensten zoveel mogelijk met standaard processen te leveren. Dossiervorming is bijvoorbeeld als generiek onderdeel aan te roepen bij elke stap die een document of statuswijziging oplevert.RedenEfficiency in beheer. ImplicatiesProcessen modulair opbouwen zodat onderdelen hergebruikt kunnen worden. De modulaire inrichting van applicaties moet hieruit volgen.

Informatiearchitectuurprincipes

Principe I1, Generieke applicaties inzetten (zie pagina 15, Uitgangspunten vanuit het informatiebeleid)Inzet van generieke applicaties heeft de voorkeur boven specifieke vakapplicaties.Reden

7

Efficiencyvoordeel.ImplicatiesDaar waar dit mogelijk is, worden de backoffice applicaties die nu nog bij dienstverlening zijn ingezet en slechts één product ondersteunen, uitgefaseerd. Nb Voor complexe processen bijvoorbeeld Burgerzaken, Belastingen, Werk & Inkomen is dat niet mogelijk.

Principe I2, Hergebruik van basisgegevens (zie pagina 15, 26, Berichten, gegevens, informatieuitwisseling)Gegevens die opgenomen zijn in de basisregistraties worden hergebruikt (eenmalig bijhouden, meervoudig gebruiken). RedenKlantgerichtheid. Klant hoeft gegevens slechts eenmaal aan te leveren.ImplicatiesApplicaties die basisgegevens gebruiken moeten in staat zijn met open standaarden gegevens uit te wisselen.

Principe I3, Aanmelden van applicaties alleen volgens het “single-signon” principeAls applicaties beschikken over een beveiligingstructuur, moet deze volgens het “single-signon” principe kunnen werken. Dit betekent dat de applicatiegebruikers die op het zaanstad domein zijn aangemeld, aan de hand van de gebruikte aanmeld gegevens ook toegang krijgen tot de applicatie zonder dat men nogmaals moet aanmelden.RedenEfficiency in beheerImplicatiesApplicaties moeten kunnen koppelen met directory service.

Principe I4, Gebruik het generieke WFM (zie pagina 24, Applicaties)Bij informatie uitwisseling van het Back-office naar het front-office waarbij ook het WFM wordt aangepast, geldt de onderstaande voorkeur:

1. De uitwisseling naar het generieke WFM mag alleen plaatsvinden volgens het standaard uitwisselingformaat.

2. Als de applicatie beschikt over een eigen WFM, is het toegestaan om de front office vanuit dit WFM aan te passen. Dit is alleen toegestaan volgens het standaard uitwisselingformaat.

RedenStatus van producten is inzichtelijk voor de klant (ook over organisatiegrenzen heen)ImplicatiesApplicaties leveren status informatie via open standaard.

Technische architectuurprincipes

Principe T1, Standaardisatie van platforms (zie pagina 31 De diversiteit in uitvoeringsplatforms worden zoveel mogelijk beperkt in het kader van kostenreductie en efficiëntie in beheer.StatementWe streven naar het minimaliseren van de technische diversiteit in de uitvoeringsplatforms. Diversiteit in middleware, database management systemen, (netwerk) operatingsystemen, transactiebehandeling enz. dient te worden geminimaliseerd en beheerst.RedenLimiteren van het aantal te ondersteunen componenten zal onderhoud vereenvoudigen en kosten reduceren (efficiëncy). Implicaties

• Technologiekeuzes worden beperkt door de mogelijke keuzes als vastgelegd in ‘Normen en Standaards’ van ICT.• We verwelkomen technologische vooruitgang en mogelijkheden en zullen de platformarchitectuur aanpassen als compatibiliteit met de informatiearchitectuur en verhoging van operationele efficiëntie of gevraagde mogelijkheden zijn aangetoond.

Principe T2, Samenwerkende technologie op basis van standaarden (zie pagina 27 e.v.)

8

StatementSoftware en hardware moeten voldoen aan gedefinieerde standaarden die samenwerking en uitwisseling tussen en van gegevens, applicaties en technologie ondersteunen. Van toepassing kunnen de industrie of open standaarden zijn. Bij gelijk gebleken geschiktheid worden open standaarden gebruikt. RedenStandaarden voorzien in consistentie en helpen bestaande ICT-investeringen te beschermen, kosten te reduceren en promoten leveranciersonafhankelijkheid. Interoperabiliteitsstandaarden ondersteunen samenwerken van de componenten en is een vereiste voor zaken als ketenintegratie.Implicaties

• Relevante standaarden worden gevolgd tenzij er enkele dwingende redenen zijn in de bedrijfsvoering om een niet-standaard oplossing te gebruiken. • De bestaande platformen moeten geïdentificeerd en gedocumenteerd worden.

Principe T3, Infrastructuur ontwerp/wijzigingen beschouwen in relatie tot alle lagen (zie pagina 27 e.v.)

StatementBij het ontwerpen of wijzigingen op infrastructuur componenten wordt de impact bepaald op alle vlakken in het Nora architectuur model. Als methode voor het (her) ontwerpen van infrastructuur componenten wordt gebruik gemaakt van het Buildingblock model.RedenHet Buildingblock model geeft structuur aan het ( modulair) ontwerpen van het infrastructuur landschap waarbij functionaliteit, techniek en kwaliteits attributen duidelijk worden onderscheiden.Implicaties

De business (architecten), IT specialisten en informatie Informatie architecten zijn ieder verantwoordelijk voor onderdelen uit het Nora negenvlaks model en betrokken bij het achritectuurontwerp.

Principe T4, Gebruik midoffice (middleware) technologie om logische grenzen af te bakenen in de ICT infrastructuur m.b.t. de back office en front office (zie pagina 26)StatementOp messaging en message broker gebaseerde middleware technologieën worden gebruikt om logische grenzen te ontwikkelen en te onderhouden tussen frontoffice en backoffice applicaties. Denk hierbij aan de scheiding tussen applicaties en databases binnen een N-Tier architectuur.RedenOp messaging en message broker gebaseerde middleware technologieën zijn de aangewezen methoden om applicaties te verdelen in discrete delen (gegevens-, logica- en presentatielaag) en deze te distribueren over verschillende platforms.ImplicatiesApplicaties dienen een gelaagdheid in een gegevens-, logica- en presentatielaag te hebben (3- tier)

Principe T5 Gebruik schaalbare midoffice componenten en producten (zie pagina 27 e.v.)StatementDe onderliggende midoffice technologie infrastructuur en producten dienen schaalbaar te zijn in capaciteit en functionaliteit om te kunnen voldoen aan de veranderende eisen die gesteld worden aan de bedrijfsvoering en de technologie.RedenHet gebruik van schaalbare componenten en producten bevordert het hergebruik van de componenten en producten.ImplicatieKan initiële kosten van ontwikkeling en exploitatie verhogen.

9

Principe T6, Gebruik op messaging gebaseerde middleware om te koppelen tussen systemen onderling en tussen legacy systemen (zie pagina 27 e.v.)StatementOm koppelingen te kunnen maken tussen legacy systemen onderling of tussen legacy systemen en client/server of Internet applicaties is op messaging gebaseerde middleware de aanbevolen methode.RedenHet feit dat alleen op basis van messaging (berichtenverkeer) gecommuniceerd wordt met andere systemen houdt in dat het eenvoudiger is om nieuwe applicaties toe te voegen. Dit kunnen nieuwe webapplicaties zijn, maar ook eventuele backoffice systemen. Hierdoor wordt het ook mogelijk om met toeleveranciers of eventueel collega-gemeentes of andere overheden op basis van messaging te communiceren. Implicaties

• De veelgebruikte methode van “screen scraping” wordt niet ondersteund.• De meer geavanceerde technieken zoals genoemde messaging vragen meer inspanning om de gewenste resultaten te behalen dan de meer eenvoudige technieken als “screen scraping” en koppelingen op database niveau.• Daar waar systemen gegevens moeten uitwisselen met de front-end applicaties, moeten ze echter wel een messaging interface hebben of krijgen.• Bij messaging dient extra aandacht te worden besteed aan beveiliging en autorisatie.• Koppelingen op databaseniveau worden niet meer tot stand gebracht, tenzij er geen alternatieven voorhanden zijn.

Principe T7, Gebruik op open standaards gebaseerde mainstream technologie t.b.v. midoffice componenten en oplossingen (zie pagina 27 e.v.)

StatementMidoffice produkten en oplossingen dienen zoveel mogelijk industry proven te zijn en te vallen onder mainstream technologieën. Eerste voorkeur wordt gegeven aan produkten die zich houden aan industrie standaards en open architectuur. Indien mogelijk wordt voor open standaards en ‘non proprietary’ gekozen.RedenOpen (industrie) standaard protocollen en interfaces minimaliseren de afhankelijkheid tussen applicaties en platform architectuur en vereenvoudigen de support en beheer van een gedistribueerde omgeving. De keuzes voor proprietary systemen kunnen in de toekomst leiden tot hogere wisselkosten naar een open standaard of andere standaard.Het gebruik van op open standaards gebaseerde mainstream technologieën kan rekenen op de beschikbaarheid van een groot aantal externe specialisten, trainingen, informatie bronnen en technische ondersteuning.Implicaties• Kan een snellere vervanging in de life cycle van de huidige midoffice betekenen om een

grotere uniformiteit te verkrijgen.

Principe T8, Gebruik asynchrone communicatie

StatementAsynchrone communicatie (asynchrone messaging) dient gebruikt te worden indien mogelijk.Reden Asynchrone communicatie biedt meer flexibiliteit dan synchrone communicatie. Door het gebruik van asynchrone communicatie kan er prioriteit gegeven worden aan berichten bestemd voor de verschillende systemen volgens een procesbeschrijving. Een groot bijkomend voordeel van asynchrone communicatie is dat de systemen niet direct afhankelijk zijn van onderlinge beschikbaarheid. Berichten worden pas verstuurd op het moment dat de

10

bestemmingsapplicatie toegankelijk is. Indien een van de betrokken backoffice systemen niet beschikbaar is, leidt dit niet tot stagnatie in de andere systemen. Met andere woorden: voor de eindgebruiker is het systeem altijd beschikbaar. Ook tijdens uren (bijv. ‘s avonds) dat normaal gesproken de bestaande systemen gesloten waren. ImplicatiesHet op asynchrone wijze koppelen van systemen biedt het grote voordeel dat de diverse systemen los van elkaar blijven opereren, en dus onafhankelijk van elkaar kunnen worden beheerd, doorontwikkeld etc. Communicatie tussen systemen vindt alleen plaats op basis van berichtenuitwisseling. Zolang er op dit gebied goede afspraken worden gemaakt (middels XML standaarden) leidt een aanpassing in een systeem niet tot aanpassingen in andere systemen.

Principe T9, Gebruik gemeentelijke gegevens definitie- en bericht uitwisselingsstandaards (zie pagina 26)StatementHet gebruik van gemeentelijke gegevens definitie- en bericht uitwisselingsstandaards bevordert de integratie met de verschillen systemen en de keten integratie.RedenGemeenten hebben behoefte aan het snel doorontwikkelen van bericht uitwisselingsstandaarden. Dit betreft zowel standaard uitwisselingsformaten als sectormodellen. Na afronding van StUF2 dienen de sectormodellen te worden vertaald naar XML en het GFO-basisgegevens te worden aangepast tot een actueel objectenmodel voor een samenhangend stelsel van basisregistraties. ImplicatiesDe doorontwikkeling van deze standaarden gebeurt landelijk (o.a. via Egem)

Principe T10, Gebruik zoveel mogelijk één access control component binnen de reeds bestaande beveiligings architectuur

StatementDe midoffice componenten dienen gebruik te maken van access controls t.b.v. identificatie, autorisatie die binnen de ICT -beveiligingsinfrastructuur al beschikbaar zijn gesteld.RedenHet gebruik van de access controls t.b.v. identificatie, autorisatie die binnen de ICT -beveiligingsinfrastructuur al geïmplementeerd zijn voorkomt inconsistenties en daarmee beveiligingslekken. Tevens wordt hiermee voorkomen dat dubbel werk wordt uitgevoerd i.v.m. het beheer van een extra identificatie en autorisatie mechanisme. Belangrijk voordeel van voorgestelde opzet is dat alle internettoegang via een enkele ingang wordt geregeld. Dit houdt in dat de beveiligingsinspanningen zich ook hierop kunnen concentreren en niet zijn verspreid over meerdere systemen.Implicaties• Midoffice componenten fungeren als ‘geleiders’ voor beveiligings en acces control

informatie• Authenticatie en autorisatie zijn een functionaliteit van andere netwerk of infrastructuur

services. • Toegang voor burgers vanuit internet vereist extra aandacht. De gebruikte identificatie

module DigiD biedt de mogelijkheid om de identiteit van de klanten (via internet) te verifiëren. De identificatie wordt uitgevoerd door een externe partij (DigiD). Alleen het resultaat van de identificatie wordt in de vorm van het sofi-nummer of BSN via een SSL verbinding geretourneerd. De daarbij behorende gebruikersrechten kunnen eventueel worden vastgelegd in een Internet Directory, een LDAP V3 compliant server.

Doelen/middelen diagramDe principes op onderliggende lagen vloeien voort uit principes op ‘hogere’ lagen in de informatiearchitectuur.

11

12

5 Indeling architectuurdocument volgens model conform NORA

Model

Bovenstaand model is overgenomen uit de Nederlandse Overheids Referentiearchitectuur (NORA). Het model is bruikbaar om relevante aspecten in beeld te brengen bij architectuurwijzigingen. De 9 vlakken hebben relaties met de omliggende vlakken. In dit document worden op verschillende plaatsen tabellen getoond om de relatie tussen verschillende vlakken weer te geven. Voorbeelden:

- Welke afdelingen hebben een rol in de levering van diensten&producten - Welke applicaties hebben een rol in de uitvoering van processen.

Bij wijzigingen in één van de vlakken is het zinvol om naar de gevolgen in de andere vlakken te kijken. Bijvoorbeeld het nieuwe product Omgevingsvergunning heeft invloed op processen en organisatie, maar ook op berichtenverkeer, gegevensopslag en applicaties. Op hun beurt hebben applicaties en berichtenverkeer invloed op de technische architectuur. Om deze reden is het belangrijk dat business en IT met elkaar in gesprek zijn!

Aan de hand van het model is dit architectuurdocument ingedeeld.Met een klein overzicht is steeds de plek in het model aangegeven:

(organisatie)

Let op: de middelste laag (informatiearchitectuur) heeft dezelfde titel als dit gehele document.

Architectuur

organisatiediensten

& productenProcessen

medewerkers& applicaties

berichten & gegevens

informatie-uitwisseling

Technischecomponenten

Gegevens-opslag

Netwerk

Bedrijfs-architectuur

Informatie-architectuur

Technischearchitectuur

Wie? Wat? Hoe?

13

6 Proces om te komen tot informatiearchitectuur

Uitgangspunt De basis voor het opstellen van de informatiearchitectuur vormen:• De visie op dienstverlening van de gemeente Zaanstad “De gemeentelijke

dienstverlening van morgen realiseren we vandaag”, juli 2007• De visie op dienstverlening van de Vereniging Directeuren Publiek, te

weten “De gemeente heeft Antwoord”. Deze visie is opgesteld met VNG en het Contact centrum overheid (CCO). Zie Www.antwoord.nl

• De Nederlandse overheids referentiearchitectuur (NORA). Zie www.e-overheid.nl

• Referentiemodel Stelsel gemeentelijke basisgegevens van Egem. Zie www.egem.nl

Waarom eigen architectuur?

Als er al goede referentie-documenten zijn, waarom stelt de gemeente dan een eigen informatiearchitectuur op? De Landelijke architectuur is van een hoger abstractieniveau, wij maken de vertaling naar de Zaanse situatie.

Proces De architectuur is tot stand gekomen in overleg tussen afdelingen PIO, IBZ, ICT. Afdelingshoofden van dienst Publiek hebben input gegeven over de werkwijze van het klantcontactcentrum.

Communicatie Communicatie over informatiearchitectuur verloopt in mondelinge overleggen, presentaties, via intranet en via dit architectuurdocument.

Besluitvorming Het GMT stelt de informatiearchitectuur vast.

Actualiseren De informatiearchitectuur wordt eenmaal per jaar geactualiseerd op basis van nieuwe ontwikkelingen.

Spanningsveld Om samenhang in de informatiearchitectuur te behouden en zoveel mogelijk volgens standaards te werken moet vaak ingeleverd worden op snelheid. De (interne) klant vraagt om een snelle oplossing en wil niet wachten op generieke oplossingen. Toch wordt geduld gevraagd in de wetenschap dat een snelle oplossing op termijn niet altijd de beste oplossing (lees: meest efficiënte oplossing) voor de organisatie is.

14

7 Uitgangspunten vanuit het informatiebeleid

Uitgangspunten Vanuit het informatiebeleid gelden de volgende uitgangspunten:

• De gemeente Zaanstad wil de dienstverlening aan burgers en bedrijven optimaliseren. Het digitale kanaal wordt daarbij zo optimaal mogelijk ingezet. Gegevens van burgers en bedrijven die al bekend zijn worden hergebruikt en niet opnieuw uitgevraagd. Ongeacht het kanaal dat de burger gebruikt (internet, telefonie, balie) is het antwoord hetzelfde.

• De gemeente wil efficiënt werken. Vanuit dit oogpunt zullen we generieke applicaties zoveel mogelijk inzetten, en vakspecifieke applicaties indien mogelijk uitfaseren. We werken samen met andere overheden en organisaties, zodat we oplossingen kunnen delen en hergebruiken. Medewerkers van de gemeente worden zo goed mogelijk gefaciliteerd in hun werk om efficiency en medewerkertevredenheid te vergroten. Bijvoorbeeld op het gebied van vindbaarheid van documenten en het gebruik van eenduidige werkstroombesturing.

• De gemeente Zaanstad sluit zich aan op landelijke standaards. Dit betekent dat uitgangspunten uit de Nederlandse Overheidsreferentiearchitectuur (NORA) gelden. Ook geldt het uitgangspunt dat de gegevensuitwisseling binnen de gemeente en met externe partijen volgens actuele open standaards gebeurt.

Specifieke uitgangspunten voor informatiearchitectuur

Uitgangspunten voor informatiearchitectuur:

• Efficiency in de informatiearchitectuur: Het gebruik van standaardapplicaties is doorgaans goedkoper en beter beheerbaar dan maatwerkapplicaties. Het gebruik van applicatie-suites heeft voorkeur boven losse applicatie vanwege de verwachte beheer-efficiency. Het beheer van onderdelen van suites kost minder inspanning dan het beheer van losse applicaties.

• Er is geen actief beleid om over te stappen op Open Source software. Bij het kiezen van nieuwe applicaties (bij vervanging of nieuw benodigde functionaliteit) is het wel raadzaam om ook open source software te betrekken in het selectieproces om na te gaan of dit een goedkoper alternatief kan bieden. Met ingang van 2010 moet elke gemeente een implementatie strategie voor Open Source software hebben. Dit is kabinetsbeleid onder de naam Nederland Open in Verbinding.

• In een applicatie dienen de lagen voor presentatie, logica en database gescheiden te zijn. Op deze wijze kunnen applicaties gebruik maken van dezelfde diensten die op verschillende lagen worden aangeboden

• De gegevensuitwisseling moet gegarandeerd zijn bij uitval van applicaties of netwerkcomponenten, dwz dat berichten worden bewaard totdat bevestiging van ontvangst is teruggekomen.

15

8 Bedrijfsarchitectuur

UitgangspuntenBedrijfs-architectuur

De bedrijfsarchitectectuur beschrijft de organisatie, de processen en producten/diensten. Het uitgangspunt van de bedrijfsarchitectuur is dat deze wordt ingericht vanuit het klantperspectief: de burgers en bedrijven. De klanten wensen een open en transparante overheid, ze zijn zelfredzaam (customer self service), willen direct het juiste (digitale) loket vinden en willen professioneel geholpen worden.

Burgers en bedrijven willen via alle kanalen in contact treden met de overheid : via email, telefoon, internet en post. Ongeacht welk kanaal moet de overheidsorganisatie op eenduidige wijze haar diensten verlenen.

In Nederland zijn ongeveer 1600 overheidsorganisaties. Een belangrijk uitgangspunt van de Nora is dat burgers niet doorverwezen worden van de ene naar de andere overheidsorganisatie. Een burger meldt zich bij 1 overheidsorganisatie. Deze overheidsorganisatie draagt er zorg voor dat eventuele deelproducten van andere overheidsorganisaties verzameld worden en als 1 eindproduct geleverd worden aan de burger.

8.1 Organisatie

Hierna volgen enkele belangrijke ontwikkelingen in de organisatie die van invloed zijn op de informatiearchitectuur

Ontwikkeling 1: KCC

De inrichting van het klantcontactcentrum (KCC) is een invulling van de landelijke visie ‘De gemeente geeft Antwoord’. Deze ontwikkeling stelt eisen aan het ontwerp van de informatiesystemen. Het KCC zorgt ervoor dat:1. Burgers en bedrijven hun vraag via alle kanalen (internet, e-mail,

telefoon, post, balie) kunnen stellen en onafhankelijk van het gekozen kanaal het zelfde antwoord krijgen.

2. Burgers en bedrijven de verschillende kanalen door elkaar kunnen gebruiken en desondanks reeds verstrekte gegevens nooit voor een tweede keer hoeven te verstrekken.

3. Burgers en bedrijven zich via ieder kanaal op de hoogte kunnen stellen van de status, voortgang en inhoud van de afhandeling van hun aanvragen.

4. Burgers en bedrijven een integraal antwoord krijgen op hun (aan)vraag.5. Burgers en bedrijven bij de gemeente ook vragen kunnen stellen over

informatie en diensten van andere overheden dan gemeenten.6. Burgers en bedrijven niet op de hoogte hoeven te zijn van de producten

en processen van de overheid in het algemeen en de gemeente in het bijzonder om toch altijd de gewenste diensten geleverd krijgen.

7. Burgers en bedrijven niet langer hoeven te wachten op hun antwoord/oplossing dan strikt noodzakelijk.

Alle klantcontacten vinden plaats in het KCC1.

Om de verantwoordelijkheid voor het leveren van antwoorden en oplossingen voor burgers en bedrijven te kunnen nemen zal het KCC regie voeren en de backoffice afdelingen aanspreken op levering van deelproducten (services)

1 Als een backofficemedewerker een klant te woord staat, dan acteert hij op dat moment als een medewerker van het klantcontactcentrum

16

en/of serviceafspraken maken. Eenvoudige producten zullen in het KCC “klaar terwijl u wacht” worden geproduceerd. Voor de levering van de onderdelen van complexere producten maakt het KCC serviceafspraken met de Backoffice afdelingen.

Dit betekent dat in het KCC straks meer medewerkers nodig zijn, die bovendien andere competenties hebben dan die nu gevraagd worden in de Frontoffice afdelingen. Naast de kunst om met klanten om te gaan, zullen mensen in het KCC aanwezig moeten zijn die zich gespecialiseerd hebben op verschillende productgroepen (beleidsterreinen) van de gemeente.

Vanzelfsprekend stelt de ontwikkeling van KCC ook eisen aan de informatie die in het KCC beschikbaar moet zijn.

Backoffice t.o.v. KCC

Door de intrede van het KCC hebben de backoffice afdelingen geen klantcontacten meer, zij kunnen zich dan ook richten op het toepassen van hun specialistische kennis en vaardigheden en het gebruik van hun specifieke applicaties. Als in specifieke gevallen contact nodig is tussen enerzijds een burger of bedrijf en anderzijds een medewerker van een backoffice afdeling, dan heeft dit contact plaats onder regie van het KCC.

Eenvoudige producten die nog in de backoffice worden geproduceerd, zullen verhuizen naar het KCC.

De backoffice afdelingen leveren deeloplossingen en antwoorden aan het KCC, waarvoor specialistische kennis en vaardigheden nodig zijn die niet van een KCC-medewerker verwacht kunnen worden. De backoffice afdelingen leveren hun deeloplossingen en antwoorden in de vorm van geformaliseerde diensten (“services”) aan het KCC. Eenzelfde situatie is er bij deelproducten van externe partijen, denk aan een advies van Brandweer of toestemming van Provincie.

Ontwikkeling 2: Samenwerking met andere organisaties

De komende jaren zal de samenwerking met andere (overheids)organisaties groeien vanuit de visie dat er voor de klant “no wrong door” is. Samenwerking tussen organisaties roept ook de vraag op naar de regie of besturing over deketen. Om dit helder te maken, moet een onderscheid gemaakt worden naar drie rollen:

- De verantwoordelijkheid voor de aan de klant te leveren dienst;- De regie of besturing van de ketensamenwerking;- De uitvoering

Klantcontactcentrum

Onderwijs

Parkeren

Bouwen

Belastingen

Bedrijven

Openb.werken

Soc. Dienst

Burgerzaken

ambtenaar

Kap vergunningen

Uittreksels

burger

bedrijf

Backoffice

Klantoriëntatie Koppelpunt Vakspecialisatie

17

In het volgende schema zijn de varianten getekend. De keuze die de organisatie maakt is van invloed op de procesinrichting en daarmee op de informatiearchitectuur.

Keten- en procesbesturing

8.2 Diensten en producten

Definitie van een dienst (NORA): Een dienst is het resultaat of effect van een afgeronde inspanning die de overheid op basis van wettelijke taken levert en waarmee in een behoefte van een burger of bedrijf wordt voorzien. Een product is het resultaat van een dienstverlening.

Principes voor diensten en producten

De NORA (de overheidsreferentiearchitectuur) geeft principes voor diensten en producten:

TransparantieOverheidsorganisaties bieden op transparante wijze nauwkeurig omschreven diensten aan. Diensten moeten SMART beschreven worden.

KwaliteitTot de kwaliteitsindicatoren van een (combinatie)dienst behoren op zijn minst: juistheid, volledigheid doorlooptijd, rechtmatigheid. Per dienst wordt een normbewerkingstijd en een daarvan afgeleide kostprijs vastgesteld (aanbeveling). Diensten van de overheid die via verschillende kanalen worden geleverd moeten hetzelfde resultaat voor de afnemer van de dienst opleveren

Werkwijze/OrganisatieDienstverlening gaat over organisatiegrenzen heen. Organisaties in het publieke domein verlenen hun diensten via ten minste de volgende kanalen: Internet, telefoon, post en balie. Bij de overheid bent u nooit aan het verkeerde adres: “no wrong door”. Organisaties in het publieke domein attenderen burgers en bedrijven op voor hen relevante diensten (proactieve dienstverlening). Kanalen bieden gelijke diensten en werken gelijkvormig.

In de gemeente Zaanstad is in het Burgerhandvest de kwaliteit van dienstverlening

18

vastgelegd. De producten- en dienstencatalogus geeft de beschrijvingen aan van de dienstverlening. De producten en diensten worden aangeboden middels het digitaal loket en de daarmee geïntegreerde applicaties voor dienstverlening, te weten het zakenmagazijn, gegevensmagazijn en workflowsysteem van Govunited.

Nb Uitzondering is op dit moment DKD (Digitaal klantdossier). Deze ontwikkeling loopt vóór op de Govunited ontwikkelingen.

Services Meer en meer worden diensten niet slechts door de gemeente geleverd, maar werken meerdere (overheid)organisaties en/of organisatieonderdelen van de gemeente samen om uiteindelijk één dienst of combinatiedienst aan een burger of bedrijf te kunnen leveren. Men zou kunnen zeggen dat organisaties via onderlinge leveringen ‘deeldiensten’ met elkaar uitwisselen. Deze ‘deeldiensten’ worden in de NORA ‘services’ genoemd, gebaseerd op het uitgangspunt van de service georiënteerde architectuur (Service Oriented Architecture ofwel SOA). Bij SOA moet niet alleen gedacht worden aan koppeling tussen applicaties maar ook aan mens-mens en mens-applicatiekoppelingen.

In de SOA leveren afdelingen/organisaties services aan andere afdelingen/organisaties. Een service is:

- voorziet in een behoefte;- duidelijk omschreven (specificaties)- gemakkelijk te vinden- herbruikbaar

De definitie van een service is (NORA): Een service is het resultaat van een afgeronde inspanning die een organisatie, medewerker of applicatie op basis van wettelijke taken of onderling gemaakte afspraken levert en waarmee in een behoefte van een of meer andere organisaties, medewerkers of applicaties wordt voorzien.

Organisaties leveren via services samen diensten aan burgers en bedrijven.

19

8.3 Processen

Processen geven op het niveau van bedrijfsarchitectuur het ‘hoe’ aan. Het resultaat van een proces is een dienst, product of service. Elke processtap moet waarde toevoegen en tot een vooraf bekend resultaat leiden. In meer formele termen wordt binnen de NORA een proces als volgt gedefinieerd:Een proces is een geordende reeks van (in-)direct waarde toevoegende handelingen en oordelen door mens of machine gericht op een bekend resultaat.

Het ‘bekende resultaat’ kan zijn (een bijdrage aan) een dienst of product aan een klant of (een bijdrage aan) een service ten behoeve van een organisatie, ambtenaar of applicatie.

Sommige processen kunnen met moderne informatietechnologie geheel door computers worden uitgevoerd. Denk bijvoorbeeld aan het doen van de melding openbare ruimte via de website van de gemeente Zaanstad: Aan dit proces komen bijna geen mensenhanden meer te pas. Andere processen zijn moeilijk te automatiseren, zoals het uitvoeren van een bouwtechnische inspectie. In de praktijk zullen processen veelal deels door mensen en deels door computers worden uitgevoerd.

Principes voor processen

Het streven van de Gemeente Zaanstad is om de producten/diensten zoveel mogelijk met standaard processen (generieke processen) te leveren. Het voordeel hiervan is dat voor meerdere producten met eenzelfde proces geleverd kunnen worden. Een standaard vergunningsproces kan bestaan uit de volgende stappen:

• Aanvragen• Accepteren• In behandeling nemen• Optioneel: advies vragen• Afhandelen

Componenten uit de procesinrichting en processturing zijn in dat geval herbruikbaar. Denk aan managementrapportages en de inrichting van het workflowsysteem. Voorbeeld: Het product bouwvergunning uit het volgende schema kan met het generiek proces voor vergunning geleverd worden. Met datzelfde proces kan ook de uitwegvergunning gerealiseerd worden.

20

GENERIEK PROCES

Vergunning

Document

PRODUCT/DIENST

Bou

wve

rgunnin

g

Inri

t- o

f uit

weg

verg

unnin

g

Inte

gral

e ev

enem

ente

nve

rgunnin

g

Rio

olaa

nsl

uit

verg

unnin

g

Sloo

pve

rgunnin

g

Stan

dpla

atsv

ergu

nnin

g

Eige

n v

erkl

arin

g ri

jbew

ijs

Kop

ie v

an e

en W

OZ

aansl

ag

Bew

ijs

van in lev

en z

ijn

Uit

trek

sel/

afsc

hri

ft b

urg

erlijk

e st

and

WO

Z-ta

xati

ever

slag

enzo

voor

t

BWT

Dis

za

Dis

za

Dis

za

, BW

TDis

Dis

za

PIV

GO

UW

PIV

PIV

GO

UW

KLANTCONTACT BURGERZAKEN X X X X X XKLANTCONTACT VERGUNNINGEN X X X X WERK, PARTICIPATIE & INKOMEN WERKPOORT INFORMATIEVERZORGING X X X X X XGEMEENTEARCHIEF X X BELASTINGEN X X X X X X X X BOUW&MILIEUVERGUNNINGEN X X X CENTR. FINANCIELE ADMIN GEO INFORMATIE ZAANSTAD X VERKEER X X HAVENS & VAARWEGEN enzovoorts

Relatie tussen organisatie, processen en producten

Toelichting: in voorgaand schema zijn de afdelingen uitgezet tegen producten. Het betreft slechts een deelverzameling van de afdelingen en een klein deel van de diensten&producten Met kruisjes is aangegeven welke afdelingen een (deel)bijdrage leveren aan de uiteindelijke totstandkoming van het product.

ServicesDe kruisjes van de backoffice-afdelingen zijn te beschouwen als de services welke verleend worden aan de frontoffice-afdelingen. Een servicegeorienteerde organisatie beschrijft deze deeldiensten en streeft naar zoveel mogelijk hergebruik van deze deeldiensten.

De ontwikkeling van het KCC zal een verschuiving veroorzaken in werkzaamheden tussen de frontoffice-afdelingen en backofficeafdelingen. Een doelstelling van het KCC is om 80% van de aanvragen direct in de frontoffice af te handelen.

Relatie tussen processen en applicaties

Net zoals er generieke processen zijn voor meerdere producten, zo kunnen we dit doorvertalen naar de benodigde functionaliteiten (in applicaties). Met generieke applicaties zijn we in staat om de producten en diensten te leveren. Het volgende schema laat dit principe zien.

21

ROL BURGER PROCESSEN COMPONENTEN

Rol burger Hoofdproces

Web

publ

icat

ie (

CM

S)

Prod

uct

en d

iens

tenc

atal

ogus

(PD

C)

Wor

kflo

wm

anag

emen

t (W

fM)

Doc

umen

tair

e in

form

atie

(D

MS)

Pers

oonl

ijke

inf

orm

atie

pagi

na (

PIP)

Web

inta

ke

Zake

nmag

azij

n

Geg

even

smag

azij

n

Geg

even

suit

wis

selin

g (b

roke

r)

GEO

-inf

o

Tool

s vo

or s

amen

wer

king

Klant Verlenen vergunningen

Beleid X X X

Uitvoering X X X X X X X X X (X) X

Handhaving X X X X X (X) X

Bezwaar X X X X X X X X X

Klant Verstrekken subsidies

Beleid X X X

Uitvoering X X X X X X X X

Verantwoording X X

Klant Reis & indentificatie documenten

Onderdaan Heffen en innen belastingen

Beleid X X X

Uitvoering X X X X X X X X

Bezwaar X X X X X X X X

Kwijtschelding X X X X X X X

Klant Verstrekken uitkeringen Etc.

Gebr opb. ruimte Beheren&ontwikkelen opb. ruimte

Klant Bieden maatsch. ondersteuning

Onderdaan Regelgeven & Handhaven

Het voorgaand schema toont de rol van de burger, de hoofdprocessen en functionaliteiten.

Bij de processen is de benodigde functionaliteit aangegeven. De kolom PDC t/m geo-info wordt voor een groot deel gedekt voor de functionaliteit welke GovUnited gaat leveren. Sharepoint dekt de functionaliteit van samenwerkingstools. Het beleidproces wordt b.v. meerdere keren genoemd (evenals Handhaven, Bezwaar, Verantwoording). Echter, vanuit informatie-architectuur gezien kan dit als 1 proces beschouwd worden (eenmaal inrichten; meerdere keren gebruiken). Ten aanzien van het proces ‘uitvoering’ zal er voor meerdere producten/diensten gebruik

22

gemaakt moeten worden van backoffice-applicaties. Andere producten kunnen geleverd worden zonder backoffice-applicatie. Deze producten/diensten worden ook wel applicatieloze producten genoemd.

Principes voor processen

Vergelijkbare processen worden op een generieke wijze beschreven en ingericht. Voor de levering van producten en diensten gebruiken we zoveel mogelijk de generieke applicaties. Dit is mogelijk wanneer het proces uitsluitend generieke functionaliteit gebruikt zoals webintake, workflow en documenten.

Daar waar dit mogelijk is, worden de backoffice applicaties die nu nog bij dienstverlening zijn ingezet, uitgefaseerd. Nb Voor complexe processen bijvoorbeeld Burgerzaken, Belastingen, Werk & Inkomen is dat niet mogelijk.

Processen zijn zodanig ingericht dat functiescheiding gewaarborgd is (onder meer met het oog op informatiebeveiliging).

Dossiervorming vindt plaats gedurende het proces, bij elke stap die een document of een statuswijziging oplevert

Processen zijn zo ontworpen dat ze via services koppelbaar zijn (handmatig danwel geautomatiseerd). De architectuur van diensten en processen is ontworpen op basis van het ‘van-klant-tot-klant’ principe. Organisatie- of afdelingsgrenzen zijn daarbij ondergeschikt aan het belang van een gestroomlijnde dienstverlening.

9 Informatiearchitectuur

De overheidsreferentiearchitectuur geeft een schema voor de opbouw van informatiesystemen die nodig zijn tussen de gekantelde frontoffice en de backoffice applicaties (welke meestal vakspecifiek zijn). De bedrijfsarchitectuur gaat uit van één aanspreekpunt voor de klant, één transparant loket. Technisch opereren de backofficeapplicaties nog als gesloten, niet geïntegreerde systemen. Om dit op te lossen wordt berichtenverkeer en gegevensopslag gerealiseerd tussen FO en BO. Zodat het KCC op eenduidige manier juist en volledig de klant te woord staat.

Hierna volgt het model van die nieuwe informatiearchitectuur.

23

9.1 Applicaties

Gelet op het principe om zoveel mogelijk generieke functionaliteit te gebruiken in generieke applicaties voor de dienstverlening, volgt hierna een opsomming van de aanwezige relevante applicaties.

PDC Een productdienstencatalogus (PDC) biedt functionaliteit voor het beschrijven en ontsluiten van groepen producten en diensten. De catalogus bevat een overzicht van de beschikbare producten met bijbehorende productbeschrijvingen, procedures, doorlooptijd en kosten. Onderdeel van de beschrijving is de doorverwijzing (link) naar het bijhorende webformulier in het webintakesysteem.

Webintake Webintakefunctionaliteit betreft het kunnen creëren, publiceren, invullen en verwerken van electronische formulieren. Webintakeformulieren zijn niet alleen via internet in gebruik door burgers/bedrijven maar ook in het klantcontactcentrum: baliemedewerker of telefonie medewerker vult elektronisch formulier samen met de klant in.

Digitaal Loket Het Digitaal Loket biedt functionaliteit voor elektronisch betalen en elektronische identificatie (landelijke standaard: DigiD).

Gegevens-magazijn

Het gegevensmagazijn, ook wel datawarehouse of operational data store (ODS) genoemd, dient voor de opslag van kopieën van gestructureerde gegevens uit het backoffice. Hierbij worden in feite twee typen onderscheiden: het gegevensmagazijn in enge zin bevat uitsluitend basisgegevens uit de basisregistratie, terwijl een gegevensmagazijn in brede zin allerlei gestructureerde gegevens kan bevatten.Het gegevensmagazijn in enge zin is gebaseerd op EGEM’s Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens (RSGB),. Zaanstad maakt een kopieslag van de registraties van natuurlijk personen, niet-natuurlijke personen, adressen bouwobjecten, grondobjecten kadastrale objecten en medewerkers. Naast de basisregistraties omvat een gegevensmagazijn in brede zin andere

24

gegevens uit achterliggende backoffices, bijvoorbeeld gegevens die een burger zou willen opvragen naar aanleiding van een WOZ-aanslag. Het gegevensmagazijn wordt ingezet voor prefill van webformulieren. Het gegevenmagazijn zal ook geografische gegevens bevatten. Op deze manier kan een burger gepersonaliseerd gegevens uit de eigen buurt verkrijgen.

Zakenmagazijn Het zakenmagazijn bevat unieke zaak- en daaraan gerelateerde klant- en statusgegevens. Deze procesgegevens worden in het zakenmagazijn geschreven door klanten, medewerkers of applicaties. Hiermee kan (over de grenzen van afdelingen én alle gemeentelijke applicaties heen) t.b.v. zowel interne als externe klanten inzicht geven worden in de doorlooptijd van afhandeling van de zaak en daarmee ook in de kwaliteit van uitvoer van het proces.

Het zaakmagazijn maakt een goede dossiervorming bij de bron mogelijk (naast inkomende en uitgaande post ook email en telefoonnotities).

Informatie uit het zakenmagazijn kan door burgers en bedrijven via de PIP geraadpleegd worden.

WorkflowManagement

Workflowmanagement (WFM) betreft functionaliteit voor het aansturen van werkstromen tussen applicaties en/of mensen. Met WfM worden de werkstromen binnen de organisatie als het ware op elektronische wijze geformaliseerd en kunnen taken worden toebedeeld aan medewerkers op basis van de aan hen toegewezen rollen. Er kan managementinformatie gegenereerd worden over doorlooptijden van producten, het opsporen van de bottlenecks e.d. Bij een WfM-proces kan de opeenvolging van taken worden gemodelleerd, met zowel seriele als parallelle stappen die door medewerkers kunnen worden uitgevoerd. Voor processen, bestaande uit een opeenvolging van dergelijke stappen, kunnen minimale en maximale doorlooptijden worden aangegeven waarbij er een signaal is bij afwijkingen. Statusinformatie kan handmatig of automatisch worden bijgewerkt, zodat klanten de status van hun aanvraag kunnen volgen.

Er wordt zoveel mogelijk gestreefd naar de inzet van generieke workflow i.v.m. het kunnen hergebruiken van processtappen, overall regie vanuit één punt (regierol KCC).

De processtappen moeten tot een minimum worden beperkt, zonder dat de toepasbaarheid wordt beperkt. Dit resulteert in overzichtelijkheid en mogelijke toepasbaarheid voor andere processen.

Document management

Een Document Management system (DMS) biedt functionaliteit ten behoeve van het invoeren, opslaan, archiveren en ontsluiten van documenten binnen een organisatie. Het systeem bewaakt de toegang tot bepaalde documenten en verzorgt versiebeheer. Papieren documenten kunnen gescand worden en ingevoerd worden in het DMS. Tevens kunnen elektronische documenten direct vanuit de kantoorautomatisering of de webintake ingevoerd worden.

25

9.2 Berichten, gegevens, informatieuitwisseling

Basisregistraties Er zijn (komen) landelijke authentieke basisregistraties voor:

- Personen (GBA – bijhouding door gemeente)- Niet natuurlijke personen (bijhouding KVK)- Kadaster (bijhouding door Kadaster)- Gebouwen (BAG: BGR – bijhouding door gemeente)- Adressen (BAG: BRA (bijhouding door gemeente))- WOZ (bijhouding door gemeente)- Kentekenregistratie (Rijksdienst voor het Wegverkeer)- Inkomens (Uitkeringsinstantie Werknemers Verzekeringen,

Rijksbelastingdienst)- Topografie - Grootschalige Basis Kaart Nederland- Ondergrond en Bodem- Niet ingezetenen

Het gebruik van gegevens uit de basisregistraties door alle andere applicaties zowel in Backoffice, als in Midoffice en Frontoffice is verplicht. Het is niet toegestaan in vakapplicaties gegevens bij te houden die beschikbaar zijn in basisregistraties.

Zolang de wettelijke basisregistraties nog niet operationeel zijn werkt de gemeente al wel zo goed mogelijk als ware de genoemde basisregistraties al aanwezig. Zo is het intern in de werkprocessen mogelijk om de GBA gegevens te gebruiken in plaats van deze zelf bij te houden.

Broker Een broker regelt electronisch berichtenverkeer bijvoorbeeld vanuit een webintakesysteem naar de juiste backoffice applicatie(s). De broker bevat de volgende functionaliteiten:

- Business process management (BPM) om processen te kunnen regisseren. - Adapters om te kunnen koppelen met applicaties - Transformatie en translatie om berichten te kunnen omvormen en

vertalen van en naar het specifieke formaat voor de backoffice applicatie

- Faciliteiten om betrouwbaar en veilig berichtenverkeer te ondersteunen

Om te kunnen communiceren met een broker moet de applicatie waarmee gegevens worden uitgewisseld aan eisen voldoen.

Technische eisen:- De opzet van de systeem architectuur (presentatielaag

businesslogicalaag, data laag)voldoet aan de eisen van een 3 tier architectuur .

- Berichtuitwisseling vindt plaats op basis open uitwisseling standaarden die binnen Zaanstad zijn geaccepteerd en vastgelegd.

- Maatwerk adapters worden niet geaccepteerd. Bij uitzondering op deze regel geldt dat deze adapters moeten communiceren via een wereldwijd geaccepteerde standaard.

26

Functionele eisen:

De Broker moet beschikken over de volgende functionaliteiten:Basisfuncties Connectoren en protocolinformatie

LoggingAutorisatieBeveiliging en privacy

Berichtenfuncties Store en ForwardPublish / subscribeBerichtvalidatieBerichtaggregatie

Servicefuncties ServicechoreografieZorgt voor de juiste volgorde van het uitvoeren van de serviceServicepublicatieServiceorkestratieHet toekennen van de juiste serviceverzoeken aan de juiste applicatie of aanvrager.

• Gebruik op messaging gebaseerde middleware om te koppelen tussen systemen onderling en tussen legacy systemen.Het feit dat alleen op basis van messaging (berichtenverkeer) gecommuniceerd wordt met andere systemen houdt in dat het eenvoudiger is om nieuwe applicaties toe te voegen. Dit kunnen nieuwe webapplicaties zijn, maar ook eventuele backoffice systemen.

• Gebruik gegevens definitie- en bericht uitwisselingsstandaards die binnen zaanstad zijn vastgelegd en geaccepteerd.

• De communicatie moet dusdanig zijn geconfigureerd dat er geen berichten verloren kunnen gaan.

• Gebruik één access control component binnen de bestaande beveiligings architectuur.

10 Technische architectuur

‘Infrastructuur, dat is toch gewoon ‘ijzer’? Hoe moeilijk kan dat zijn?

Een, nog steeds, vaak gehoorde kreet. Toch is het infrastructuurvak complexer dan aan de buitenkant lijkt. Er is een overvloed aan vindingen en nieuwe standaarden en er komen steeds meer mogelijkheden bij. Het is dus de kunst om innovatie te benutten terwijl de daarbij horende valkuilen zoveel mogelijk worden vermeden. Er moet ook grip komen op de al ontstane complexiteit, zodat infrastructuurvoorzieningen effectiever kunnen worden uitgenut. Voor de ICT organisatie een toenemende uitdaging.

Op zoek dus naar stuurmanskunst die het mogelijk maakt innovatie efficiënt en doeltreffend te benutten zodat de IT infrastructuur beter bijdraagt aan de bedrijfsvoering in zijn geheel en innovatie stimulerend werkt in plaats van remmend.

Hoe? Door (verdere) ontwikkeling van de technische architectuur methodisch ‘aan te vliegen’’.

27

Plaats van de infrastructuur Architectuur binnen de ICT architectuur

De technische architectuur is de (fysieke) basislaag van de informatiearchitectuur. De technische architectuur wordt sterk bepaald door de hogere architectuurlagen vooral de, applicatiearchitectuur. Andere invloeden op de technische architectuur zijn technologische ontwikkelingen.Met betrekking tot de NORA is vooral het communicatie aspect van belang. De inzet van machines, platformen en netwerkvoorzieningen liggen buiten het NORA domein en zijn door de organisatie vrij te bepalen

Infrastructuur Architectuur: Definitie NORA

De technische architectuur beschrijft het samenstel van machines, opslagvoorzieningen en netwerkcomponenten vanuit technologische optiek. Het is een middel om de uitwisseling van informatie tussen applicaties te kunnen verwezenlijken, als uitwerking van de dienstgerichte architectuur (Service Oriented Architecture) De technische architectuur bestaat uit drie aspecten:

• Systeem: de technische componenten (‘cliënts’, ‘servers’ ) en logische systemen (‘middelware’)

• Gegevensopslag: de technische representatie van gegevens • Netwerk: zorgt voor fysieke transport van data.

Modulaire opbouw infrastructuur

.

De moderne, service gerichte applicatie infrastructuur stelt steeds hogere eisen aan alle facetten van de technische infrastructuur waar het gaat om:

- Aanpasbaarheid (adaptability) - Schaalbaarheid (scalability)

- Beschikbaarheid (availability) - Veiligheid (security)- Beheerbaarheid (managebility) - Afrekenbaarheid

(acountability)

Infrastructuur componenten met kwaliteitsattributen

Naast bovengenoemde kwaliteitsattributen dient de infrastructuur beter aan te sluiten bij bedrijfsprocessen en dient wendbaar, efficiënt en beheersbaar te zijn. Randvoorwaarden bij het bereiken van deze doelen is een modulaire opbouw en uitwisselbaarheid van infrastructuur componenten .

Door Infrastructuur functionaliteit te ontwikkelen op basis van ‘Building Blocks’ is de gewenste aansluiting te realiseren. Het gebruiken van het bouwblokkenmodel heeft een drieledig doel:

- Het model helpt bij het gestructureerd en modulair ontwikkelen en beschrijven van het infrastructuur landschap waarbij functionaliteit, kwaliteitsattributen en techniek duidelijk worden onderscheiden.

- Het model levert herbruikbare architectuurproducten op, omdat het een modulaire infrastructuurontwikkeling stimuleert. Er ontstaat uiteindelijk een bibliotheek met standaard infrastructuur voorzieningen (bouwblokken).

- Het bouwblok model is een geschikt hulpmiddel bij het ontwerpen van informatiesystemen volgens de SOA architectuur.

Bij het ontwerpen volgens de bouwblok methode zijn verschillende ’spelers’ betrokken:

- Businessarchitecten en Informatiearchitecten voor het bepalen van de gewenste bedrijfsarchitectuur en informatiearchitectuur.

- specialisten met kennis van de technische infrastructuur voor specificatie

28

van de elementen binnen een bouwblok.- Beheerders voor wensen en eisen vanuit de beheeromgeving.- Service level managers voor wensen en eisen vanuit de klantomgeving.Principe: Als methode voor het ontwerpen van infrastructuur componenenten wordt het Buildingblock model gehanteerd.

Voorbeeld bepaling definitie werkomgeving, bouwblok en kwaliteitsattributen

Voorbeelden bouwblok in onze huidige infrastructuur

Voorbeeld 1: Standaard werkplekHet huidige principe van werkplek beheer voldoet in technische zin aan het bouwblok principe. De standaard werkplek is opgebouwd uit de componenten:

Standaard PC Standaard basis image (besturingssysteem XP + standaard software

componenten. Standaard uitrol mechanisme (Altiris software en Acive directory). Standaard beheer mechanisme (beveiliging en gebruik policies).

Voorbeeld 2: Netilla remote toegang voorziening Gemeente Zaanstad heeft een standaard voor remote toegang voor gebruikers die vanuit een externe locatie op het netwerk van gemeente Zaanstad willen werken. De standaard remote toegang voorziening is opgebouwd uit de volgende componenten:

Standaard hardware (Netila toegangs gateway, Netilla authenticatie token) Standaard citrix omgeving voor eindgebruikers. Standaard beheermechanisme (beveiliging en gebruik poicies)

Voorbeeld 3: Virtuele server (VMWare)Het serverpark van gemeente Zaanstad is ‘gevirtualiseerd’. Dit betekent dat op één fysieke server meerdere ‘virtuele servers’ draaien. De virtuele servers zijn als standaard bouwcomponent ingericht en zijn voor meerdere toepassingen inzetbaar en snel beschikbaar te stellen. De virtuele server bestaat uit de volgende componenten:

Standaard hardware (dit is de basis server) Standaard software inrichting (besturingssysteem + beheersoftware) Standaard beheermechanisme (authenticatie, beveiliging en gebruik

policies)

Bovengenoemde voorbeelden zijn bouwblokken met als toepassingsgebied technische infrastructuur.

29

Huidige technischearchitectuur

Gelaagdheid

Inrichting technische infrastructuurDe technische architectuur is qua inrichting sterk ’technology driven’ en wordt voor een groot deel bepaald door de bovenliggende techniek van applicaties. Feitelijk wordt de topologie bepaald door de applicatieleveranciers. Er gelden de volgende standaarden op het gebied van:- Server topologie en systeemsoftware. (RS6000 Pseries met AIX, HP Intel

server platform met Windows 2003) - Database managementsystemen (Oracle v9 en v10, SQl server 2005)- Storage: HP SAN.- Netwerktopologie (LAN, WAN) netwerkprotocollen (TCP/IP v4) active

netwerk componenten (Cisco, Blue Coat), Netilla.- Werkplek hardware (HP pc platform)- Rand apparatuur (printers, plotters van HP en Océ)

ICT streeft een beperking van het aantal platforms na met als doel kosten te besparen en beheerinspanning zoveel mogelijk te beperken. Met de migratie van OneWorld naar het Unix platform is de diversiteit aan serverplatforms teruggebracht van drie naar twee. Op het gebied van database management wordt zoveel mogelijk gestandaardiseerd naar Oracle of SQL server.

Principe: De diversiteit in uitvoeringsplatforms worden zoveel mogelijk beperkt in het kader van kostenreductie en efficiëntie in beheer.

Gelaagdheid : presentatielaag / businesslogica / dataopslagNieuwe applicaties moeten een goede logische scheiding hebben tussen genoemde 3 lagen. Op dit moment is dit bij 75% van de applicaties nog niet het geval.

De huidige applicatie-infrastructuur is met name cliënt-server based ingericht. Veel applicaties zijn nog niet “voldoende open” om via ‘Webservices’ informatie uit te wisselen.Van een klassieke cliënt server architectuur naar service ingerichte architectuur gaat geleidelijk, afhankelijk van applicatie ontwikkeling door leveranciers.De technische infrastructuur moet beide architecturen ondersteunen.

De belangrijkste ontwikkelingen richting SOA zijn waarneembaar bij frontoffice toepassingen en uitwisseling met externe organisaties. De ontwikkeling rond Gov United is een eerste stap richting SOA

De huidige technische infrastructuur van gemeente Zaanstad is in de basis gereed voor een SOA. De cliënt, server en data lagen zijn in de technische infrastructuurreeds gescheiden. Deze opzet maakt de infrastructuur tevens schaalbaar.

koppelingenIn de huidige backoffice applicatie omgeving zijn veel applicatie-applicatie koppelingen aanwezig. Het gaat vaak om maatwerk koppelingen door leveranciers speciaal ontwikkeld. Dit is in het kader van onderhoud en beheer, uitwisseling met andere systemen niet gewenst.

Architectuur naar de toekomst

Service Oriented Architecture (SOA) is de opvolger van de Cliënt Server Architectuur. Businessapplicaties zoals ERP systemen (OneWorld) worden op afstand aanroepbaar gemaakt door delen van de applicatie aanroepbaar te maken in de vorm van web services. De web services worden vervolgens opgeslagen in een bibliotheek, een webservice repository. Deze webservice repository vervangt de ‘server’ in de oude cliënt-server architectuur. Als nieuwe ‘cliënt ‘ fungeert het Business Process Management Systeem (BPMS) ook wel Enterprise Service bus genoemd. Soa Architectuur bestaat uit drie lagen:

30

• Laag 1: Het BPMS dit is de laag die bepaalt welke Webservices wanneer worden ‘afgespeeld’en hoe de Webservices onderling moeten samenwerken.

• Laag 2: De Webservice Repository (Bibliotheek )• Laag 3: De Business Applicaties

Model SOA architecture / Cliënt-server.

De SOA architectuur maakt het mogelijk dat alle componenten, op functioneel niveau, hun diensten aanbieden door gebruikt te maken van web services. De centrale bus (service bus) zorgt voor de connectiviteit tussen de verschillende diensten.

Een aantal voordelen van Service Oriented Architecture t.o.v. Client server model:

Door de evolutie van internet als gemeenschappelijk e-business platform en , eenduidig, gezicht naar de klant is er behoefte aan platform onafhankelijke integratie van processen over organisatie grenzen heen (bijv GovUnited).

Klantgericht werken vereist een procesgedreven netwerk van losse relaties tussen gebruiker, softwarecomponenten, procescomponenten en hardware.

Flexibiliteit is nodig om snel te kunnen reageren op bewegingen vanuit de markt, wetgever of technologische ontwikkelingen.

Principe: Bij het ontwerpen van nieuwe informatie systemen dient uitgegaan te worden van de SOA Architectuur.

Technologische ontwikkelingen

Er is een start gemaakt om ook backoffice systemen op een moderne wijze te koppelen. Een voorbeeld is de implementatie van DDS4all waarmee een aantal backoffice applicaties gekoppeld worden en onderlinge gegevensuitwisseling via een ‘midoffice’(High level uitwisseling)mogelijk maakt alsmede een koppeling ‘naar buiten’ (VOA). Voorheen waren er wel koppelingen tussen een aantal applicaties maar dan vooral middel een propriety interface (low level koppeling

De ontwikkelingen rond GovUnited waarbij gemeente Zaanstad een groot pakket

31

Normen en standaarden

functionaliteit afneemt bij een Application Service Provider (ASP) met koppelingen naar de backoffice is een ontwikkeling van een nieuwe orde. Infrastructuur technisch stel dit eisen aan:

- koppelingen met de back officeapplicaties de backoffice applicaties moeten in staat zijn om op basis van berichten uitwisseling te koppelen aan de midoffice.

- beschikbaarheid van netwerk (WAN) een deel van de functionaliteit wordt bij een ASP (application service provider) ondergebracht. De verbindingen tussen gemeente Zaanstad en de ASP heeft een hoge beschikbaarheids eis

- Securiy (authenticatie, encryptie enz) het koppelen met een ‘vreemde’ partij over een (publiek) netwerk stelt eisen aan beveiliging.

- Beheer een deel van de infrastructuur wordt door ‘derden’ beheerd. Afstemming van beheerprocessen is noodzakelijk.

Dit zijn ontwikkelingen die de komende jaren een grote invloed hebben op het beschikbaar stellen, gebruik en beheer van het applicatie landschap. Gezien de opmars van de SOA architectuur een noodzaak om infrastructuur ontwikkeling een goede reference architectuur ( architectuur ter beoordeling van wijzigingen) te hebben. Aansluitend op Informatie Architectuur ontwikkelt de afdeling ICT een reference architectuur voor de technische lagen uit het Nora model. De reference architectuur is een detaillering van de technische architectuur, bestemd voor ICT technici. Daanaast worden de geldende normen en standaarden geactualiseerd. Uitgangspunten bij het bepalen van (nieuwe) standaarden zijn:

De standaarden voor soft- en hardware ondersteunen samenwerking en uitwisseling tussen en van gegevens, applicaties en infrastructuur.

De standaarden voor hard- en software moeten voldoen aan industrie en/of open standaarden. Bij gelijk gebleken geschiktheid gaat de voorkeur uit naar open standaarden.

Afwijking van bovenstaande punten is alleen mogelijk als een dwingende reden in de bedrijfsvoering om een niet standaard oplossing vraagt (bijvoorbeeld: de functionele toepassing is niet binnen de geldende standaarden te verkrijgen/realiseren). In dat geval beslist het GMT op advies van het CAB.

Ontwikkelingen, Toekomstige situatie.

Met de bouw van het nieuwe stadhuis is er gelegenheid om infrastructureel te anticiperen op ontwikkelingen voor de komende jaren. Een groot deel van de netwerk infrastructuur wordt vernieuwd en er is een uitwijklocatie ingericht bij de brandweer. Met het ontwerp van de nieuwe infrastructuur is reeds een start gemaakt vanuit de technische invalshoek.

32

10.1 Technische Componenten

De technische componenten, ook wel oneerbieding ‘ijzer’ genoemd, bestaan uit cliënts, middelware, en servers. Samen met network en storage vormtdit de fysieke laag van de infrastructuur.

Application Server

Integration

Database

Network

Server Hardware / OS

Storage

API

Presentation

Man

age

me

nt

security

Huidige situatie Achitectuur en samenhang

Het serverpark is onderverdeeld in drie platformen, HPserver (intel) platform, het IMB RS6000 platform en AS400 (wordt uitgefaseerd).PC sever platform Functie: Domein sever (directory service), file en print server, web server (IIS, OAS), Logic server en database server (SQL).Omvang: 50 fysieke servers (90 gevirtualiseerd)

RS6000 platformFunctie: Database server voor Oracle applicatie databases.Omvang: 6 servers (na consolidatie 4)

De werkplek hardware is gestandaardiseerd naar HP pc omgeving (Fat Cliënt).

In het huidig architectuurmodel is het als volgt ingericht:Cliënt tier PC platformWebserver tier PC server platformLogic tier PC server platformData tier RS6000 (Oracle) , PC server (SQL server)

Centrale opslag

Gemeenste Zaanstad gebruikt voor centrale opslag van data twee platformen: RS6000 voor Oracle databases en een HP SAN voor userdata en SQL data. Het streven is dat met de vervanging/uitbreiding van het SAN ook de Oracle databases naar het SAN verplaatst worden. Dit biedt flexibiliteit binnen de opslag- infrastructuur. Voordelen van een SAN boven traditionele opslag (DAS) media zijn hoge performance en betrouwbaarheid.

33

Lopende ontwikkelingen

Integratie en consolidatie

In het kader van flexibiliteit , beschikbaarheid en schaalbaarheid zijn een aantal voorzieningen getroffen binnen de technische infrastructuur:

- Consolidatie midrange het uitfaseren van het AS400 platform (lopend project) en terugbrengen van het aantal RS600 platformen (lopend project)

- Gebruik van VM ware (virtuele servers) voor het Windows 2003 platform

Toekomstige ontwikkelingen

Naast consolidatie en software matige maatregelen is in het kader van de infrastructuur ontwikkelingen van het nieuwe stadhuis ook aandacht voor verdere hardware consolidatie op het PC server platform d.m.v. Blade-server technologie (het samenvoegen van meerdere server in een behuizing) in het kader van beschikbaarheid flexibiliteit en vooral schaalbaarheid. Dit is op dit moment in onderzoek in het kader van invulling van het ‘Flexwerk concept’.

Op het RS6000 platform is begonnen met virtualisatie van het serverpark (LPAR) met als doel de beschikbaarheid van de het ondersteunde Orcale platform te garanderen en een flexibeler gebruik van systeem resources mogelijk te maken.

Kwaliteitsattributen Technische componenten

Midrange:- Aanpasbaarheid NU: De Unix omgeving is (nog) niet gevirtualiseerd.

Aanpasbaarheid beperkt zich tot aanschaf van nieuwe systemen of uitbreiding van de bestaande systemen.TOEKOMST: Virtualisatie Unix severs (nieuwe server OneWorld is een eerste stap in die richting.

- Beschikbaarheid NU: De beschikbaarheid bestaat uit uitwijk naar een andere server (testomgeving) bijcalamiteiten. TOEKOMST: De Unix servers worden dubbel uitgevoerd(geclusterd).

- Beheerbaarheid NU: platform afhankelijke tools voor beheerTOEKOMST: Generieke beheertoolset (APPmanager)

- Schaalbaarheid NU: De opslag is nu systeem afhankelijk. TOEKOMST: De Unix systemen worden gekoppeld aan het SAN en zijn qua opslag capaciteit goed schaalbaar.

- Veiligheid NU: de systemen staan op het LAN en zijn voldoende beveiligd.

- Afrekenbaarheid n.v.t.

PC-server platform

34

- Aanpasbaarheid NU: Het PC server platform is gevirtualiseerd. Aanpasbaarheid beperkt zich tot aanschaf van nieuwe systemen of uitbreiding van de bestaande systemen.TOEKOMST: Virtualisatie uitbreiden en schaalbare hardware (Blade server technologie) invoeren.

- Beschikbaarheid NU: Uitwijk naar andere omgeving middels VM ware software mogelijk TOEKOMST: geen ontwikkelingen.

- Beheerbaarheid NU: platform afhankelijke tools voor beheerTOEKOMST: Generieke beheertoolset (APPmanager)

- Schaalbaarheid NU: Opslag via SAN dus goed schaalbaar. TOEKOMST: Schaalbaarheid m.b.t. de hardware door toepassen van blade server technologie.

- Veiligheid NU: de systemen staan op het LAN en zijn voldoende beveiligd.

- Afrekenbaarheid n.v.t.

Werkplek systemen (pc’s)- Aanpasbaarheid NU: De werkpleksystemen zijn standaard uitgevoerd en

beperkt uitbreidbaar.TOEKOMST: Invoering ander werkplekconcept in het kader van ‘Flexwerken’ (wordt nader uitgewerkt).

- Beschikbaarheid NU: Uitwijk naar andere werkplek mogelijk door huidig werkplek concept. TOEKOMST: Zie aanpasbaarheid.

- Beheerbaarheid NU: platform afhankelijke tools voor beheerTOEKOMST: Generieke beheertoolset (APPmanager)

- Schaalbaarheid n.v.t. - Veiligheid NU: werkplekken afdoende ‘dichtgetimmert’ voor

interne toepassing.TOEKOMST: in het kader van Flexwerken (ook buiten het LAN) concept voor beveiliging opstellen (wordt nader uitgewerkt in het kader van het nieuwe stadhuis).

- Afrekenbaarheid NU: modulair (per pc) volgens ZBB.TOEKOMST: Volgens ZBB?

10.2 Gegevens opslag (Data laag)

35

Application Server

Integration

Database

Network

Server Hardware / OS

Storage

API

Presentation

Mana

gemen

t

security

Definitie: De laag binnen de 3 (4)- tier architectuur die de daadwerkelijke opslag, mutatie en verwijdering van gegevens afhandelt (RDBMS). Doel: Het scheiden van gegevensbewerking een de gegevensopslag, met als

voordeel dat de invloed van wijzigingen in de bovenliggende architectuur lagen.

Opslag typen Data is onder te verdelen in de volgende categorieën:- Gestructureerde data (opgeslagen in database architectuur)- Semi gestructureerde data (bijv. file en mail archivering systemen).- Ongestructureerde data ( opgeslagen op serverniveau)- Topografische data (opgeslagen in een database architectuur

Standaardisatie Voor gestructureerde dataopslag kennen we twee standaarden op database management niveau:Oracle (grote toepassingen) en SQL server (kleine toepassingen)Voor semi gestructureerde data gaat het om propiety system voor file en email archivering. Voor ongestructureerde data hanteren wij de volgende standaarden:

- Office documenten: PDF (half open standaard). ODF (open standaard)- Voor plaatjes: Jpeg, TIFF (open standaarden Gif (Gesloten standaard)- Voor topgrafische data Oracle (Spatial) database.

Statement: Het streven is maximaal twee RDBMS systemen te hanteren als standaard (Oracle en SQL server) uit het oogpunt van beheersbaarheid en kosten.

10.3 Netwerk

De netwerklaag beschrijft de Local Area Network (LAN) services, Wide Area Network services, Internet toegang, en Netwerkprotocol standaarden

36

Application Server

Integration

Database

Network

Server Hardware / OS

Storage

API

Presentation

Manage

ment

security

Local Area Network

Het LAN van gemeente Zaanstad vormt de verbinding tussen eindgebruiker (cliënts) en servers. Het gemeentelijk netwerk is een gerouteerd netwerk en gestandaardiseerd op de protocollen TCP/IP v4 en OSPF.

Wide Erea Network

Het WAN verbindt het lokale gemeentelijk netwerk met externe (trusted) partijen w.o. Brandweer. Gemeente Wormerland e.d. De lan omgevingen worden gekoppeld middels Dark Fiber (eigen glasvezelverbindingen) of via EVPN (glasverbinding als dienst afgenomen). Externe partijen worden gekoppeld via een Cisco Firewall (dubbel uitgevoerd i.v.m. redundantie)

DMZ Het DMZ LAN geeft ‘Trusted parties’ toegang tot het LAN van gemeente Zaanstad.

Securiy De keerzijde van toepassing van SOA is de beveiliging. Het is altijd makkelijker een gesloten systeem te beveiligen dan een open. De huidige beveiligings maatregelen bestaan uit:

• Firewall aan de grensen van het LAN• User authenticatie middels een Radius server en Autenticatie (Active

Directory)• Toepassing Proxy server.• Barracuda als relay agent• Anti Virus /anti spyware detectie

Ontwikkelingen DE ontwikkelingen op fucioneel niveau (SOA) architectuur brengt met zich mee dat er meer LAN-WAN verkeer gaat ontstaan voor o.a. berichten verkeer (webservices). Dit vraag om herziening/uitbreiding van het arsenaal aan beveiliging maatregelen aan de grenzen van het LAN.

Maatregelen:• Invoering van TCP/IPv6 • Toepassen van encriptie mogelijkheden, bij voorkeur gebaseerd op open

uitwisseling standaarden (Secure XML)• Afspraken met de trusted party m.b.t. beheer van gezamenlijk domein.

Definities en verklaring van afkortingen

BAG Basisregistratie Adressen en Gebouwen, dit is een landelijke authentieke gegevensregistratie over adressen, verblijfsobjecten en panden.

BGR Basisgebouwenregistratie, registratie van verblijfsobjecten en panden binnen de BAG

37

GBA Gemeentelijke basisadministratie, dit is een authentieke registratie van personen.

KCC Klantcontactcentrum, de plek waar alle eerste klantcontacten plaatshebben. Dit is een organisatie-ontwikkeling op basis van de visie De gemeente geeft Antwoord. Zie ook www.antwoord.nl

Middleware Middleware omvat de systeemsoftware die de informatie-uitwisseling regelt tussen de cliënt-software en de software die de bedrijfsgegevens beheert. Vaak gaat het om gedistribueerde systemen en meerdere platforms. Het bouwen van middleware vraagt om diepgaande kennis van de problemen van communicatie, synchronisatie en distributie. Er steken verschillende concepten achter middleware-oplossingen.De middleware zorgt ervoor dat toepassingen ontwikkeld kunnen worden voor verschillende platforms en dezelfde manier van gegevenstoegang kunnen gebruiken onafhankelijk van waar deze gegevens zich bevinden.De middleware is een laag software en bevindt zich tussen de toepassingslaag en de communicatie- en besturingssoftware:toepassingmiddlewarecommunicatie- enbesturingssoftware

NORA Nederlandse Overheids Referentie Architectuur, zie: http://www.e-overheid.nl/atlas/referentiearchitectuur/Overheidsorganisaties leveren een bijdrage aan de e-overheid. Daarbij is het van belang principes vast te leggen over de wijze waarop samengewerkt kanworden, processen naadloos aan elkaar kunnen worden gekoppeld en gegevens kunnen worden uitgewisseld. De principes zijn terug te vinden in de NORA.

platform Een platform is een basis waarop software ontwikkeld wordt, bijvoorbeeld JAVA, .net, Windows.

SOA Service Oriented Architecture, zie toelichting onder paragraaf 8.2, onder Services

ZBB Zero based budgetting, verwijst hier naar interne verrekenmethodiek

38

39