Colofon. Oplage: 250 exemplaren

Colofon

Dit handboek is door de Adviesgroep Architectuur opgesteld. Aan het handboek is door de volgende mensen meegewerkt (in alfabetische volgorde): Kees Duits (SHI) Arris Oliemans (DAB/GVI) Loren Kruseman (Ordina) Cees Wiering (SHI) Mohamed Abalhaj (SHI) Dick Grasboer (OGA) Marijke Oosterbroek (FBA) Dries Bartelink (BDA/CO) Menno Gmelig Meijling (SHI) Erik Fray (Stadsdeel Noord) Monique Jelmorini (DBGA) Frans Smit (GAA) Peter van Bosheide (DMO) Fred Haverkamp (DAB) Peter van Leeuwen (BDA/BMO) Geert Wind (BDA/CO) Platform Informatiebeveiliging Gertjan Kock (DBGA) Raymond van Erkel (DPG) Hans Bosma (Ordina) Rigina Christiaans (IBA) Hans Eggels (DWI) Robert Jan Prenger (DMO) Jan Leuven (SHI) Ron Blankers (SHI) Jeroen de Vries (Stadsdeel de Siepie Ebbes (DWI) Baarsjes) Stan Oei (Stadsdeel Centrum) Jorden Spijker (Stadsdeel Osdorp) Willem Schoonbeek (BDA/CO) Josine van der Voort (DPG) Yvette de Adelhart Toorop (SHI)

Dit gedrukte exemplaar wordt u aangeboden door Concern Organisatie, afdeling Informatiebeleid. Verbeteringen en suggesties zijn welkom en kunnen worden doorgegeven aan: Willem Schoonbeek Telefoon: 020 – 552 3061 Email: [email protected] Oplage: 250 exemplaren

DISCLAIMER Het Handboek Architectuur (Handboek) is bestemd voor interne doeleinden. Aan de inhoud van het Handboek is uiterste zorg besteed. Het is echter mogelijk dat de inhoud van deze Handboek verouderd, incompleet en/of incorrect is. Aan de inhoud van dit Handboek kunnen door derden dan ook geen rechten worden ontleend. De gemeente Amsterdam kan niet aansprakelijk worden gehouden voor de (directe als ook indirecte) gevolgen van het gebruik, op welke wijze dan ook, van de hierin aangeboden informatie. De gemeente Amsterdam geeft geen enkele garantie noch aanvaardt zij enigerlei aansprakelijkheid met betrekking tot de inhoud, data, adviezen, verklaringen, software, producten of ander materiaal in dit Handboek. De disclaimer en de inhoud kunnen zonder nadere aankondiging op ieder gewenst moment wijzigen. Alle intellectuele eigendomsrechten op de in het Handboek verstrekte informatie, inclusief beeldmerken, logos, fotomateriaal, komen toe aan de gemeente Amsterdam. Niets uit de teksten of grafische voorstellingen in het Handboek mag zonder schriftelijke toestemming van de gemeente Amsterdam openbaar worden gemaakt/verstrekt aan derden, vespreid en/of verveelvoudigd.

Handboek Architectuur

Gemeente Amsterdam Adviesgroep Architectuur

Voorwoord

Het college van B&W en de stadsdeelbesturen willen tot betere en snellere onderlinge samenwerking komen. Dit om stadsbrede prioriteiten aan te pakken, de dienstverlening voor de Amsterdammer verder te verbeteren, het voortijdig schoolverlaten gezamenlijk aan te pakken, de openbare ruimte beter te beheren en regels te vereenvoudigen. Dit vormt de kern van de in juli 2006 door het college van B&W uitgebrachte notitie ‘Van ongeduld naar actie: voorstellen voor versnelling’. De wil om samen zaken aan te pakken is er. Niet alleen bij de bestuurders, maar ook op ambtelijk niveau. Dat heb ik de afgelopen maanden zelf ervaren in contacten met medewerkers van diensten, bedrijven en stadsdelen. De grote uitdaging is om deze wil om te zetten in concrete resultaten, om het vervolgens ook samen te doen. Dit Handboek Architectuur laat zien dat dit kan. Het draagt voor mij op twee manieren bij aan versterking van de samenwerking tussen de centrale stad en de stadsdelen: via de inhoud en het proces.

Inhoud Effectieve samenwerking is alleen mogelijk wanneer de betrokkenen met elkaar kunnen communiceren. Dit Handboek biedt een gemeenschappelijke taal om te communiceren over de Amsterdamse organisatie en informatievoorziening. Zo zorgen we dat iedereen hetzelfde verstaat onder veel gebruikte, maar vaak moeilijk grijpbare termen als het ‘hoofdproces Dienstverlening’, ‘basisregistraties’ of ‘Antwoord’. Tegelijk biedt het Handboek ook overzicht van en inzicht in de samenhang van de opbouw van de Amsterdamse organisatie en informatievoorziening. Daarmee is het een onmisbaar achtergronddocument voor iedereen die zich bezig houdt met de organisatie en informatievoorziening. Om eerlijk te zijn, zijn er bij mij ook ‘kwartjes gevallen’ waardoor ik de samenhang tussen bijvoorbeeld verschillende initiatieven zoals Beter Presteren, het programma Basisregistraties en ICT-infrastructuur en het Servicehuis ICT beter ben gaan zien! Tenslotte geeft het Handboek ook een gezamenlijk kader voor ons toekomstig handelen. De in het Handboek opgenomen grondslagen en standaarden zijn concrete afspraken die we met elkaar hebben gemaakt. Deze afspraken zijn ook bestuurlijk vastgesteld door de stadsbrede Commissie Informatievoorziening waarin zowel bestuurders namens de stadsdelen als leden van B&W zitten. Deze afspraken zijn daarmee leidend voor het toekomstig handelen van iedereen die professioneel actief is in de Amsterdamse organisatie en informatievoorziening.

1



Dit Handboek heeft u nogal wat te bieden: een gemeenschappelijke taal, overzicht en inzicht in de samenhang en afspraken voor de toekomst.

Proces Dan het proces. De wijze waarop het Handboek tot stand is gekomen is voor mij een schoolvoorbeeld van hoe we effectief van ongeduld naar actie kunnen komen. Het proces typeer ik met de volgende steekwoorden: een bottom-up benadering; ruimte voor professionals; projectmatig werken; pragmatisme door een focus op de dingen die nu echt belangrijk zijn; en het gericht werken aan draagvlak door actieve betrokkenheid van stadsdelen, diensten en bedrijven. Door deze manier van werken was het voor de Commissie Informatievoorziening klip en klaar dat dit Handboek vastgesteld moest worden. Met de eerste versie van dit Handboek hebben we een prachtige eerste mijlpaal bereikt voor betere samenwerking op het terrein van de Amsterdamse organisatie en informatievoorziening. Ik hoop dat het ook u zal helpen in uw werk. En laten we samen op eenzelfde wijze doorwerken aan de implementatie en verdere uitwerking van deze architectuur!

Maarten van Poelgeest Voorzitter Commissie Informatievoorziening

2



Managementsamenvatting

Nut en noodzaak aanleiding

Reeds in 2004 zijn voorstellen gedaan om de aansturing van de gemeentelijke ICT concernbreed op orde te brengen, onder meer door de instelling van een Commissie en Stuurgroep InformatieVoorziening, de oprichting van een Servicehuis ICT en de vormgeving van informatiemanagement en programmamanagement op diverse niveaus in het concern. Ondertussen zijn er diverse initiatieven gestart zoals Antwoord, de organisatieateliers, het programma Basisregistraties en ICT-infrastructuur (BRI) en het Meerjarenplan Informatiemanagement. Met deze ontwikkeling om de gemeentelijke ICT te organiseren neemt de roep toe om samenhang bij ontwerp, ontwikkeling, implementatie en beheer van de processen en de geautomatiseerde systemen.

de noodzaak

Waarom een architectuur? Omdat we zonder een gemeenschappelijke visie en een gedeelde blauwdruk van de gemeentelijke organisatie en informatievoorziening niet (meer) kunnen voldoen aan wat van ons verwacht wordt. Daarbij gaat het, van buiten naar binnen redenerend, om drie drijfveren. Burgers en bedrijven verlangen een overheid die niet naar de bekende weg vraagt, die klantgericht is, zich niet voor de gek laat houden, die weet waar ze het over heeft, die haar zaken op orde heeft en die niet meer uitgeeft dan nodig is. De gemeentelijke diensten en stadsdelen hebben behoefte aan overzicht, samenhang en toetsingskaders op het terrein van informatievoorziening en ICT. En ten slotte is, heel concreet, de concernbrede architectuur een van de randvoorwaarden voor de realisatie van het programma BasisRegistraties & ICT-infrastructuur.

Andere Overheid

Het Handboek Architectuur is, als uitdrukking van de concernbrede samenwerking, van doorslaggevend belang voor de realisatie van die Andere Overheid. We hebben ons stellig voorgenomen de dienstverlening en de handhaving te verbeteren, en meer te doen tegen lagere kosten. We volgen de ambities die op landelijk niveau expliciet zijn gemaakt in een BurgerServiceCode.

management samenvatting - 1



management issue?

En waar gaat het dan om bij die architectuur? Om techniek waarschijnlijk, want het is tenslotte ICT, en dus niet interessant voor het management? Ooit was dat misschien zo, maar die techniek is inmiddels niet meer neutraal. De inrichting van de informatiehuishouding bepaalt de kwaliteit van de business. Dienstverlening en handhaving zijn volledig afhankelijk geworden van ICT. In een informatie-architectuur wordt de verbinding gelegd tussen de vereisten van de organisatie en de primaire processen enerzijds en de mogelijkheden en de beperkingen van de techniek anderzijds: de business alignment.

koppelen en delen

In het handboek staat hoe we Amsterdam willen inrichten: koppelen en delen, samenwerking en samenhang. We kunnen onze business-doelstellingen alleen halen als we met één loket naar buiten treden, processen delen, gegevens delen en middelen delen. En om alle organisaties op elkaar aan te sluiten zijn er voorzieningen “in het midden” nodig om de processen te regisseren en de gezamenlijke gegevens onderling uit te wisselen.

communicatie

Voor het (her)ontwerp van bedrijfsprocessen en bijvoorbeeld de organisatie van de dienstverlening is het nodig een gezamenlijke taal en gemeenschappelijke beelden ter beschikking te hebben. Architectuur is daarvoor het aangewezen instrumentarium. Een architectuurmodel maakt de dialoog mogelijk tussen organisatieontwerpers en ICT-specialisten, het geeft handvatten voor materiedeskundigen en toetsingskaders voor beslissers. Architectuur is dus een handreiking voor het management om zich erin te verdiepen, en een uitnodiging aan (proces)ontwerpers om de ICT-ers er in een vroeg stadium bij te betrekken.

de samenhang

Om onderscheid te kunnen maken tussen de technische en de meer organisatiegerichte aspecten kent vrijwel elk architectuurmodel een indeling in lagen of niveaus. Het is vervolgens de kunst om de samenhang en de onderlinge afhankelijkheid van de verschillende niveaus zo goed mogelijk in beeld te brengen. Een uitgangspunt op het ene niveau moet op mogelijke consequenties voor de andere lagen beoordeeld kunnen worden.

gegevens delen

Als we bijvoorbeeld, op het niveau van de organisatiedoelstellingen, een burger slechts één keer naar zijn gegevens willen vragen, dan betekent dat het een en ander voor de wijze waarop we onze dienstverlening inrichten: we moeten de processen zo ontwerpen dat we elkaars gegevens kunnen delen. Op het niveau van de informatie moeten we derhalve kunnen beschikken over één unieke identificatie: het burger service nummer. En dat nummer moeten we ten slotte in de applicaties en de systemen implementeren.




één keer inloggen

Een ander voorbeeld, van onder naar boven redenerend. In de infrastructuur bouwen we een faciliteit in om de authenticatie en de autorisatie te regelen van alle gebruikers van de concernsystemen (de zogenaamde I AM-server). Deze technische voorziening is noodzakelijk omdat we op het niveau van de uitvoerende processen niet telkens opnieuw willen inloggen maar in alle omstandigheden door de systemen herkend en bediend willen worden (single sign on).

model met vijf lagen

In het Amsterdamse vijflagenmodel wordt zo veel mogelijk geïntegreerd wat landelijk of internationaal reeds is vastgesteld. Het model wordt gebruikt als kapstok voor de beelden en de platen, de teksten en de uitleg. Er is expliciet aandacht voor de grondslagen, voor de (gewenste) standaards, voor het beheer en voor de beveiliging. Per laag kan de detaillering verschillen, maar in elk geval moet er, om ook het management voor de zaak te winnen, een uiteenzetting zijn die buitengewoon laagdrempelig en toegankelijk is. Samenvattend kan de betekenis en de noodzaak van een architectuur van de informatievoorziening als volgt worden benoemd:

samenhang

•

in de architectuur brengen we tot uiting hoe in Amsterdam de politieke uitgangspunten, de business-doelstellingen, de ontwikkelingen en trends, en de gemeentelijke installed base met elkaar samenhangen in termen van IST en SOLL;

communicatie

•

een architectuurmodel kan ons helpen om aan te wijzen waar de knelpunten zitten in de informatiehuishouding, wat de aandachtspunten zijn, de verschillen van mening, de zwarte gaten en de witte vlekken;

plan van aanpak

•

en op grond daarvan kan een architectuurmodel het referentiekader bieden voor een planmatige of programmatische benadering van de gemeentelijke ICT; een plan van aanpak is in ieder geval de logische vervolgstap.

Een artist impression van de architectuur laag 1: organisatie

Het verhaal in grote lijnen. De redenering start, als vanzelfsprekend, bij de burger en de ondernemer. Het is onze uitdrukkelijke wens de klant niet meer van het kastje naar de muur te sturen maar een organisatie te zijn die open is en transparant. De klant weet ons te vinden, kan ons gemakkelijk bereiken, wordt vriendelijk te woord gestaan en professioneel geholpen. Hij is zelfredzaam, niet meer zelf op zoek naar het juiste loket: elk loket is juist. En als de dienstverlening ook digitaal zou kunnen, is die ook daadwerkelijk digitaal beschikbaar. Alleen nog naar het stadsdeelkantoor of het dienstloket als dat echt niet anders kan.




laag 2: proces

Voor onze processen ligt daar de uitdaging, we moeten beter presteren. Recentelijk is een indeling in een zestal gemeentelijke hoofdprocessen in zwang geraakt. Vier primaire processen, waaronder dienstverlening en handhaving, die elk bestuurd en ondersteund moeten worden. In aparte bijeenkomsten worden die processen opnieuw ontworpen.

business alignment

Er is een samenhang tussen de organisatielaag en de proceslaag. Op organisatieniveau is aan de orde wat we willen leveren en op welke manier we dat arrangeren, op procesniveau vragen we ons af hoe we die dienstverlening dan het beste kunnen inrichten. De bovenste twee lagen van het architectuurmodel zijn daarmee gekarakteriseerd. Voor het volledige beeld is het goed de redenering door te zetten naar de drie lagen die daaronder komen, om de verbinding te maken met de vereisten die deze organisatieen procesdoelen stellen aan de informatievoorziening en de techniek van de ICT, kortom om de business alignment te maken.

laag 3: informatie

Bij het uitvoeren van de processen is informatie benodigd over de klant, de zaak en het product. Een aantal gegevens is bij vrijwel elk klant-contact vereist en daarom vastgelegd in zogenaamde basisregistraties. Er is op landelijk niveau een zestal gedefinieerd: persoonsgegevens en bedrijven, adressen, gebouwen, bedrijven, percelen en topografie.

laag 4: applicatie

De gegevens uit de basisregistraties zijn inmiddels goed gedefinieerd en gestandaardiseerd, maar moeten doorgevoerd worden in alle gemeentelijke applicaties en systemen. Dat is gemakkelijker gezegd dan gedaan. Zo moeten we in Amsterdam een slordige 150 persoonsadministraties terugbrengen tot één basisregistratie.




laag 5: infra

Op de onderste laag van het model, die van de technische infrastructuur, gaat het erom alle systemen fysiek met elkaar te verbinden. En open te stellen voor elkaar en, waar nuttig en noodzakelijk, voor de buitenwereld. Een en ander met de grootste zorg voor de beveiliging.

de vijf lagen

We kunnen de resultaten tot nu toe projecteren in het vijflagenmodel. Links in deze artist impression geven de illustraties aan waar het in de betreffende laag om gaat. In het midden wordt vervolgens gaandeweg geschetst wat de samenhang is tussen de verschillende lagen. In het handboek worden deze abstracte beelden vervolgens vertaald in concrete modellen, diagrammen, definities, schema’s en toelichtingen. De hoofdstukindeling volgt de vijf lagen van dit architectuurmodel.




vanuit het proces

We gaan één stap dieper in op het model. In principe moet een redenering op elke laag kunnen starten, ter illustratie wordt onderstaand de proceslaag als startpunt genomen. Dat begint met een inrichting op het hoogste abstractieniveau. Voor het proces dienstverlening kan dat er bijvoorbeeld als volgt uitzien.

voortgangsbewaking

Elk dienstverleningsproces begint met het te woord staan van de klant, de aanvraag wordt op de een of andere manier geregistreerd en het verzoek wordt in behandeling genomen. Vaak zal er sprake zijn van een beoordelingsof beslissingsmoment in de procedure en als alles goed gaat wordt het gevraagde op tijd en naar tevredenheid van de klant geleverd. Dat laatste, de bewaking van de voortgang van het proces, is cruciaal voor de eerder geformuleerde ambitie met betrekking tot de klanttevredenheid. Hier start de discussie over de zogenoemde mid office, die hieronder nader wordt toegelicht.

channelmanagement

Op naar de organisatielaag. De interactie met de klant kan via meerdere kanalen geschieden. In de eerste plaats is er het fysieke loket, de balie, en de traditionele communicatie via de gewone post. Daar zijn andere, elektronische kanalen naast gekomen: de website Amsterdam.nl, de correspondentie via email, het digitale loket en het telefonische contact center (Antwoord/14020). De vraag is aan de orde welke producten en diensten wij bij voorkeur via welk kanaal aan de man willen brengen. We moeten aan channel management gaan doen.




informatie

En dan vanuit de proceslaag naar beneden: welke informatie is benodigd bij de uitvoering van de processen? De gegevens waarover het in de informatielaag gaat, kunnen in drie categorieën worden verdeeld.

basisregistraties

In de eerste plaats gaat het om de zes basisregistraties, het hart van de gegevenshuishouding. Deze zijn in vrijwel elke fase van het primaire proces benodigd, dus zowel in de front en de mid office als in de back office.

bedrijfsgegevens

Ten tweede gaat het om gegevens die specifiek zijn voor de aard van het product of de dienst: inkomens- en vermogenspositie (DWI), WOZ-gegevens van de eigenaar van het onroerend goed (DBGA), in-, door- en uitstroom van leerlingen (DMO), erfpacht op het perceel (OGA), kenteken van de auto (Stadstoezicht), enzovoort. Deze gegevens worden vanwege de hoedanigheid met name in de back office gebruikt.

zaakdossier

De derde categorie betreft de zaakgegevens, benodigd voor een adequate bewaking van de voortgang van het proces, en daarmee specifiek voor de mid office. Steeds sterker dient zich de behoefte aan de vereiste gegevens in een apart zaakdossier te registreren. Het zogenaamde datamodel van deze zaakgegevens is een van de meer technische diagrammen die in het handboek zijn opgenomen.




Zo’n model laat zien hoe nauwkeurig de onderlinge relaties van de gegevensveldjes zijn gedefinieerd en hoe de verbindingen met de andere categorieën lopen. applicaties

De gegevens zijn hiermee op papier bepaald maar moeten nog wel in techniek worden omgezet. Op de applicatielaag spreken we van databases. Verder is er functionaliteit benodigd om deze databases te beheren en te bewerken.

SGA en webservices

Van oudsher is sprake van systemen waarin functionaliteit en database exclusief voor elkaar zijn bestemd (rechts in de afbeelding), maar onderlinge uitwisseling en meervoudig gebruik van functionaliteit (links in de afbeelding) wordt steeds belangrijker, de zogenaamde Service Gerichte Architectuur (SGA). De applicatie hoeft zelfs niet eens meer in huis te draaien maar kan via internet worden aangeboden (webservices).




infrastructuur

Database en functionaliteit samen noemen we een applicatie of een systeem. De systemen draaien gewoonlijk in een lokaal netwerk (LAN), dat weer is gekoppeld aan een grotere ring (WAN). Deze infrastructuur heet in Amsterdam E-NET en is ingedeeld in verschillende domeinen met een toenemende mate van beveiliging. Extra voorzieningen (Amsterdam.nl en Portaal Amsterdam) zorgen voor de presentatie op het web. Om de uitwisseling van gegevens en services mogelijk te maken wordt aan een gemeenschappelijke Service Bus Amsterdam gewerkt.

heen en weer

Het verhaal dat bij de burger begint, is zo uiteindelijk vertaald in techniek. Behalve van boven naar beneden kan de redenering ook andersom lopen. Op die manier ontstaat er consistentie in de beelden en een toetsing aan de praktijk. De architectuur is een levende, dynamische systematiek om grip te krijgen op de werkelijkheid.

ist en soll?

De vraag is aan de orde welke situatie in het handboek wordt beschreven, de feitelijke of de gewenste. Daar is geen eenduidig antwoord op te geven, in de eerste plaats omdat de ICT-omgeving voortdurend in beweging is en ten tweede omdat dit per organisatieonderdeel kan verschillen. In principe biedt het handboek echter een referentiearchitectuur en gaat het derhalve in de meeste gevallen om de SOLL-situatie.




Het fenomeen mid office mid office?

Het vijflagenmodel kan houvast bieden bij discussies die op gemeentelijk maar ook op landelijk niveau (EGEM) worden gevoerd over trends en al dan niet gewenste ontwikkelingen. Over bepaalde kwesties bestaat volledige overeenstemming: de noodzaak van basisregisters bijvoorbeeld of het burger service nummer. Maar er zijn ook onderwerpen waarover de meningen verschillen: gaat het zaakdossier er komen en wat is dat precies: een mid office?

apart onderdeel?

In het eerdere model van het proces dienstverlening zijn de vijf deelprocessen zo gerangschikt dat daar een organisatorische indeling aan gekoppeld kan worden. Het contact met de klant bij de aanvraag en de levering van dienst of product is het werk van de front office. De behandeling en eventuele beslissing gebeurt door de specialisten in de back office. De bewaking van het proces gebeurt van oudsher door de betrokken medewerkers zelf. Werkimpulsen worden aan collega’s doorgegeven door het papieren dossier op het bureau te leggen of in het postvakje te deponeren, of door middel van digitale varianten daarop. In die overdracht, in het toezicht op de gang van zaken en in de toenemende onderlinge afhankelijkheid doen zich problemen voor. Een apart organisatieonderdeel, een mid office, zou belast kunnen worden met de voortgangsbewaking, de gegevensuitwisseling en de statusmelding. Maar dat zou ook geheel door de techniek kunnen worden opgelost. De redenering verloopt grosso modo via de volgende stappen: •

leidend zijn in ieder geval de business-doelstellingen: de klant ordentelijk te bedienen, zorgvuldig, professioneel, digitaal waar mogelijk, fysiek waar gewenst;

•

dat kan alleen maar met een multichannel front office, een zekere mix van fysieke en digitale kanalen waarmee het contact met de klant wordt onderhouden, met als eis dat via elk kanaal dezelfde kwaliteit wordt geboden en een vraag overal hetzelfde antwoord oplevert;

•

vervolgens moet er natuurlijk een naadloze aansluiting zijn van de front office met de back office;



de inrichting


•

vroeger was dat eenvoudig, één-opéén, elke dienst en elk stadsdeel zijn eigen loket aan de voorkant voor het eigen werkpakket aan de achterkant; maar anno nu willen we dat de gezamenlijke front office van 30 diensten plus 14 stadsdelen in principe alle ruim 500 gemeentelijke producten levert vanuit misschien wel even zovele back offices (M keer N);

•

dan moet er dus een voorziening komen om die aansluiting optimaal te laten verlopen: het uitzetten van de vraag, het bewaken van de voortgang en het terugleveren van het resultaat;

•

die voorziening kan organisatorisch van aard zijn (mensen, procedures) of technisch (computers) of beide, maar zal in ieder geval het aantal relaties reduceren (M plus N);

•

de organisatorische kant moet vooral tot uitdrukking komen in het herontwerp van de primaire processen en de eventuele (her)inrichting van de organisatie;

•

de technische kant moet een vertaling krijgen in de informatie-huishouding en de systemen: maak de basisgegevens voor iedereen beschikbaar en creëer een integratie- en uitwisselingsplatform.

Als we de voorziening waarvan hier sprake is voor het gemak even mid office noemen, dan gaat de discussie erom of die mid office organisatorisch of technisch vorm moet krijgen, of dat parallel kan, uit- of infaserend, wat leidend moet zijn en wat volgend. Hoe dan ook gaat het om keuzes met verstrekkende consequenties.

Management issues speerpunten

Het handboek geeft een doorkijk naar de toekomst en biedt daarmee houvast voor de langere termijn. In het vijflagenmodel kan vrij eenvoudig aangegeven worden wat de belangrijkste onderwerpen zullen zijn




voor de komende tijd. De moeilijkheid zit erin om die overeenstemming over de langere termijn te vertalen naar concrete acties voor morgen. De speerpunten van de onderste drie lagen kunnen tot op zekere hoogte geadresseerd worden door de ICT-ers, voor de twee bovenste lagen is de samenspraak met ontwerpers en organisatieontwikkelaars vereist en daarmee het engagement van het management. vraagstukken

De belangrijkste management issues voor de komende tijd zijn: • het bepalen van het ontwikkelpad voor het mid office, • waaronder valt: de ontwikkeling van de Servicebus Amsterdam, • alsmede de ontwikkeling van één zaakdossier. En om dit mogelijk te maken: • de inrichting van de organisatie en de financiering rond gemeenschappelijke voorzieningen; • ervoor zorgen dat (hoofd)processen op een uniforme wijze worden vastgelegd; het bevorderen van het (her)ontwerp van processen; • het maken van afspraken over de mate en snelheid van standaardisatie, van onder andere applicaties en infrastructuur.

besluitvorming

In een apart document (Management besluiten Architectuur) worden deze vraagstukken vertaald naar concrete besluiten die worden voorgelegd aan de Stuurgroep respectievelijk de Commissie InformatieVoorziening. Op grond daarvan zal er een migratieplan moeten komen waarin deze besluiten nader worden uitgewerkt. Een deel van de uitwerking zal terugkomen in het Informatiebeleidsplan dat in de loop van 2007 verschijnt. De onderstaande vragen die op elk van de afzonderlijke lagen spelen, moeten in de loop van de tijd in deze plannen worden beantwoord.

laag 1: organisatie

De belangrijkste kwesties op het niveau van de organisatie zijn: • hoever willen we gaan met het bevorderen van digitale dienstverlening als substituut voor de fysieke? en gaan we echt aan channel management doen? • hoe gaan we onze organisatie (inclusief besluitvorming en financiering) structureel inrichten zodanig dat we de dingen die we graag gemeenschappelijk willen doen ook daadwerkelijk samen kunnen doen? • hoe organiseren we de implementatie van deze architectuur op korte termijn en waar halen we de middelen (mensen, geld) vandaan?

laag 2: proces

Een goede architectuur op de proceslaag is van cruciaal belang. Van alle goede bedoelingen om de burger aan het stuur te laten, basisregistraties te gaan benutten en te besparen door de inzet van slimme ICT gaat niets terecht komen als we niet onze processen herontwerpen. Duidelijk is dat Beter Presteren het kader moet vormen. Maar met het benoemen van de zes hoofdprocessen en het aanwijzen van proceseigenaren in een kernteam zijn we er niet. Processen moeten worden herontworpen en tot op een hoog detailniveau in kaart worden gebracht volgens een standaard methodiek en een service gerichte architectuur: Organisaties verlenen elkaar (elektronische) services waarmee de diensten aan burgers worden geassembleerd. De grote vraagstukken op deze laag zijn: • hoe gaan we ervoor zorgen dat er versnelling komt in het (her)ontwerp van




• laag 3: informatie

de belangrijkste processen? hebben we daarvoor de kennis en de menskracht in huis? wie wordt verantwoordelijk voor de besturing van ketenprocessen?

Op de informatielaag is het management actief betrokken bij het programma Basisregisters & ICT-infrastructuur (BRI). Naast de zes wettelijke verplichte basisregisters draagt ook een aantal “kernadministraties” bij aan de doelstellingen van eenmalige invoer, meervoudig gebruik. De ontwikkeling van zaakdossier en klantdossier heeft daarbij de grootste prioriteit. En daarbij zijn standaards voor registratie en bewaring van digitale documenten een vereiste. De betrokkenheid en de expertise van het Gemeentearchief op dit Digitale Informatiebeheer is erg belangrijk. De actuele vraagstukken zijn: • welke gegevenssets onderscheiden buiten de basisregistraties om en welke komen in aanmerking als kernadministratie? en wat is dat dan precies: een kernadministratie? wat zijn de criteria? • hoe komen we tot één gemeenschappelijke voorziening voor het zaakdossier, resulterend in één zakenmagazijn? handhaven we de bestaande parallelle ontwikkeling van diensten, kiezen we voor samenwerking of wijzen we één partij aan?

laag 4: applicatie

Op de applicatielaag hebben (open) standaarden en voorzieningen op het gebied van integratie de grootste prioriteit: een Service Bus Amsterdam als gemeenschappelijke integratievoorziening, Portaal Amsterdam als de concerntoepassing voor de presentatie en Paraplu respectievelijk Diva als de standaardtoepassingen voor de basisregisters Personen en Vastgoed. De belangrijkste vragen zijn: • waar halen we het geld vandaan voor een gemeenschappelijke integratievoorziening? en hoe zit het met de financiering van de rest van het gemeenschappelijke? • hoe dwingend willen we zijn bij het bevorderen van standaardisatie? wanneer moeten we aan de standaarden voldoen? staan we uitzonderingen toe? • hoever willen we gaan met ‘gemeenschappelijkheid’? welke functies worden wanneer in gemeenschappelijke ontwikkeling en beheer gebracht en gaan we dat dan ook organiseren?

laag 5: infra

Op de laag van de infrastructuur moet het management betrokken zijn bij beveiligingskwesties en verdergaande uniformering. De bestaande tweedeling van lokale en centrale netwerken moet worden opgeheven, “eigen” internetaansluitingen zijn uit den boze, er moet een gemeenschappelijke voorziening komen voor identificatie, authenticatie en autorisatie (een I AM-server). En verder kan het beheer van de infrastructuur, technisch en logisch, beter worden belegd. Er spelen soortgelijke vragen als op de applicatielaag: • hoever willen we ook hier gaan met ‘gemeenschappelijkheid’? • hoever gaan we in onze standaardisering?


Handboek Architectuur Definitief

Gemeente Amsterdam Bestuursdienst

Inhoudsopgave 1 1.1 1.2 1.3 1.4

Inleiding...........................................................................................................................................1 Aanleiding.........................................................................................................................................1 Waarvoor dient de architectuur? ......................................................................................................2 Hoe kunt u dit Handboek gebruiken?...............................................................................................3 Leeswijzer.........................................................................................................................................4

2 2.1 2.2 2.3 2.4 2.5 2.6

De Amsterdamse visie op architectuur........................................................................................1 Van ongeduld naar actie door samenwerking en architectuur ........................................................1 Vertaling programma- en bestuursakkoord......................................................................................2 Balans nodig tussen snelheid en samenhang..................................................................................3 De gefaseerde ontwikkeling van onze architectuur .........................................................................4 De reikwijdte van het Handboek Architectuur ..................................................................................5 Het Amsterdamse architectuurraamwerk.........................................................................................6

3 3.1 3.2 3.3 3.4 3.5 3.6 3.7

Grondslagen ...................................................................................................................................1 Inleiding ............................................................................................................................................1 Algemene grondslagen ....................................................................................................................1 Grondslagen organisatiearchitectuur ...............................................................................................1 Grondslagen procesarchitectuur ......................................................................................................2 Grondslagen informatiearchitectuur .................................................................................................2 Grondslagen applicatiearchitectuur..................................................................................................2 Grondslagen infrastructuurarchitectuur............................................................................................2

4 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Organisatiearchitectuur.................................................................................................................1 Inleiding ............................................................................................................................................1 Grondslagen ...................................................................................................................................13 Modellen .........................................................................................................................................14 Standaarden ...................................................................................................................................25 Beheer ............................................................................................................................................27 Beveiliging ......................................................................................................................................29 Conclusies ......................................................................................................................................30

5 5.1 5.2 5.3 5.4 5.5 5.6 5.7

Procesarchitectuur.........................................................................................................................1 Inleiding ............................................................................................................................................1 Grondslagen ...................................................................................................................................11 Modellen .........................................................................................................................................12 Standaarden ...................................................................................................................................15 Beheer ............................................................................................................................................17 Beveiliging ......................................................................................................................................18 Conclusies ......................................................................................................................................19

6 6.1 6.2 6.3 6.4 6.5 6.6 6.7

Informatiearchitectuur ...................................................................................................................1 Inleiding ............................................................................................................................................1 Grondslagen .....................................................................................................................................4 Modellen ...........................................................................................................................................5 Standaarden ...................................................................................................................................16 Beheer ............................................................................................................................................18 Beveiliging ......................................................................................................................................19 Conclusies ......................................................................................................................................21



7 7.1 7.2 7.3 7.4 7.5 7.6 7.7

Applicatiearchitectuur ...................................................................................................................1 Inleiding ............................................................................................................................................1 Grondslagen .....................................................................................................................................4 Modellen ...........................................................................................................................................5 Standaarden ...................................................................................................................................22 Beheer ............................................................................................................................................26 Beveiliging ......................................................................................................................................29 Conclusies ......................................................................................................................................30

8 8.1 8.2 8.3 8.4 8.5 8.6 8.7

Infrastructuurarchitectuur .............................................................................................................1 Inleiding ............................................................................................................................................1 Grondslagen .....................................................................................................................................4 Modellen ...........................................................................................................................................5 Standaarden ...................................................................................................................................17 Beheer ............................................................................................................................................19 Beveiliging ......................................................................................................................................20 Conclusies ......................................................................................................................................22

9 9.1 9.2 9.3 9.4 9.5 9.6

Architectuurorganisatie en -proces .............................................................................................1 Inleiding ............................................................................................................................................1 Architectuurorganisatie.....................................................................................................................1 Architectuurproces ...........................................................................................................................6 Standaarden ...................................................................................................................................13 Beheer ............................................................................................................................................14 Conclusies ......................................................................................................................................15



1

Inleiding

1.1

Aanleiding

Andere Overheid

Burgers en bedrijven verlangen een andere, beter functionerende overheid. Een overheid die niet naar de bekende weg vraagt, die klantgericht is, zich niet voor de gek laat houden, die weet waar ze het over heeft, die haar zaken op orde heeft en die niet meer uitgeeft dan nodig is. Dit is geen modegril, maar vormt een structurele trend die al jaren zichtbaar is bij overheidsorganisaties op alle niveaus.

drie kernpunten

Het vormgeven van deze Andere Overheid vergt een transformatie. Op het hoogste abstractieniveau gaat het hierbij om drie dingen:

1) burger aan het stuur

1. De burger aan het stuur De overheid is gemakkelijk te vinden, 7*24 uur bereikbaar, klantvriendelijk en professioneel. Burgers en bedrijven zijn zelfredzaam (customer self service) en zijn vrij zelf te kiezen via welk kanaal en loket zij communiceren met hun overheid. 2. Stroomlijning van werkprocessen De logica van de organisatie is niet langer dominant. De burger aan het stuur vraagt om stroomlijning en (soms) herontwerp van processen. 3. Het delen van informatie en ICT-middelen We delen informatie die in meerdere werkprocessen wordt gebruikt. Omwille van betrouwbaarheid en efficiëntie slaan we deze informatie op één plek op. De basisregistraties zijn hiervan het ultieme voorbeeld. Bij het gebruik van ICT reduceren we dubbelwerk en dubbele voorzieningen door samenwerking.

2) stroomlijning van werkprocessen 3) delen van informatie en ICT-middelen

veel initiatieven gestart: van ongeduld naar actie

roep om samenhang: architectuur

Binnen Amsterdam zijn we hard op weg om dit tot een succes te maken. De afgelopen jaren zijn binnen (samenwerkende) stadsdelen, diensten en bedrijven diverse initiatieven gestart zoals Beter Presteren, het contact center Antwoord, de organisatieateliers, de oprichting van een Servicehuis ICT, het programma Basisregistraties en ICT-infrastructuur en de professionalisering van het informatiemanagement. Het college van B&W heeft 11 juli 2006 de voorstellen uit notitie Van ongeduld naar actie aangenomen. De voorstellen gaan over betere en snellere samenwerking tussen de centrale diensten en de stadsdelen. Het bestuurs- en bedrijfsvoeringsakkoord tussen stadsdelen en centrale stad op 12 december is hier uit voortgekomen. Tevens is het principebesluit voor de instelling van een stads MT genomen en een referentiekader met principes voor organisatieverandering vastgesteld. Nu de Andere Overheid binnen Amsterdam meer en meer realiteit begint te worden met concrete initiatieven, neemt tegelijk de roep om samenhang bij ontwerp, ontwikkeling, implementatie en beheer van processen en geautomatiseerde systemen toe. Het antwoord op vragen over samenhang is

1-1



onder meer: architectuur. Vanuit de concrete aanbevelingen uit het Vooronderzoek Shared Service Organisatie ICT 1 is daarom het initiatief genomen in het kader van het Programma Basisregistraties en ICTinfrastructuur om te komen tot een architectuur voor het concern Amsterdam. Het vormt tegelijk ook één van de pijlers van het Meerjarenplan Informatiemanagement.

1.2 bestemmingsplan voor toekomstige organisatie en informatievoorziening

architectuur bevat grondslagen, modellen, standaarden, beheer en beveiliging

Waarvoor dient de architectuur?

Een architectuur geeft op hoofdlijnen weer hoe de verschillende componenten en initiatieven in de organisatie en de informatievoorziening in elkaar grijpen, zowel functioneel als technisch. Een architectuur beschrijft op samenhangende wijze een gewenste situatie. Dit Handboek Architectuur vormt daarmee het bestemmingsplan voor de toekomstige organisatie en informatievoorziening van Amsterdam. We kijken daarbij circa 4 jaar vooruit. Dit klinkt allemaal nog abstract. Wat vinden we concreet in dat ‘bestemmingsplan’? Om het simpel te zeggen bevat dit handboek 1 richtinggevende en kaderstellende uitspraken (grondslagen) bijvoorbeeld “De gemeente Amsterdam opereert consistent, als één concern, als integraal onderdeel van de overheid” of “Gegevens worden éénmalig opgeslagen en meervoudig gebruikt” 2 beschrijvende platen (modellen) bijvoorbeeld een typologie van een organisatie met een front, mid en back office

Model 1.1 Voorbeeld van een model 3

concrete afspraken (standaarden, beheer en beveiliging) bijvoorbeeld “De Gemeentelijke Basisadministratie (GBA) van de Dienst Persoonsgegevens is de standaard voor persoonsgegevens” of “het Servicehuis ICT is de beheerder van E-net”

In hoofdstuk 2 lichten we de opbouw en reikwijdte van de architectuur van Amsterdam verder toe.

1

de

Collegebesluit B&W, 22 juni 2004, 2004/8386: 3 ronde Ombuigingen (voorstel) cluster 4 Shared Service Concept. Waarin besloten is om informatiemanagement en programmamanagement in te voeren. Met architectuur als onderdeel van informatiemanagement.

1-2



1.3 doelgroep: professionals rond Andere Overheid

doelen

Hoe kunt u dit Handboek gebruiken?

Dit handboek is geschreven voor iedereen die professioneel betrokken is bij de vormgeving van de Andere Overheid. Denk daarbij aan het top- en middenmanagement, procesvernieuwers, projectleiders, architecten, systeemontwikkelaars en ICT-beheerders. De achterliggende doelstelling van de architectuur is om bij te dragen aan de realisatie van de Andere Overheid. Meer concreet kan het handboek door de professionals als ‘Zwitsers zakmes’ worden gebruikt voor de volgende doelen 2: Handwijzer Het handboek is een handwijzer voor het vormgeven van de gemeentelijke organisatie. Het biedt een set van principes voor alle stadsdelen, diensten en bedrijven bij het (her)inrichten van processen. Nieuwe programma’s en projecten kunnen dit handboek als vertrekpunt voor ontwikkeling en ontwerp gebruiken. Toetsings- en besluitvormingskader Bestaande programma’s, projecten, organisaties en voorzieningen voor de Andere Overheid kunnen het handboek gebruiken als middel en kader om hun huidige situatie te toetsen. In handen van (EDP-)auditors biedt het handboek tevens een referentiekader om te kunnen meten of de ontwikkelingen, inhoudelijk gezien, volgens het uitgestippelde beleid verlopen. Positionering Programma’s, projecten en organisaties kunnen het handboek gebruiken als landkaart en daarmee hun eigen positionering in het veld bepalen. Instrument voor sturing en risicobeheersing De realisatie van de Andere Overheid in Amsterdam is geen eenvoudige opgave. Het gaat om een groot aantal organisaties die met elkaar dienen samen te werken en een groot aantal generieke componenten, waarop veel organisaties moeten gaan aansluiten. Er is sprake van faseverschillen en ongelijke dynamiek. Deze factoren stellen hoge eisen aan de stuurmanskunst van de beleidsmakers en beleidsverantwoordelijken. Met dit handboek wordt het besturen van de inhoudelijke aspecten van de organisatie en informatievoorziening beter mogelijk. Het gebruik van het handboek leidt verder tot het vroegtijdig onderkennen van conflicterende ontwikkelingen binnen de Andere Overheid, zodat een tijdige bijsturing door de beleidsverantwoordelijken mogelijk wordt. Instrument voor ondersteuning inkoop Het handboek biedt een set van principes en uitgangspunten die als kader gehanteerd kunnen worden bij het opstellen van specificaties voor software en hardware ten behoeve van aanbesteden, uitbesteden en inkoop.

2

Bron: NORA, versie 1.0. NORA staat voor Nederlandse Overheids Referentie Archictectuur, het handboek voor architecten met ontwerpprincipes van de e-overheid. De ontwikkeling van NORA is een onderdeel van het ICTU programma Architectuur Elektronische Overheid. ICTU is een stichting opgericht door het ministerie van Binnenlandse Zaken en Koninkrijksrelaties en de Vereniging voor Nederlandse Gemeenten. Het doel van ICTU is de overheidsdoelstellingen op ICT-gebied optimaal te realiseren door samenwerking tussen overheden.

1-3



1.4

Leeswijzer

gebruik de index

Niet elke passage in dit handboek zal voor iedereen even interessant zijn. Een manager is vanuit zijn functie in andere dingen geïnteresseerd dan bijvoorbeeld een systeemontwikkelaar. Het handboek is dan ook te vergelijken met een encyclopedie. Het is meer een naslagwerk dan een leesboek dat je van A tot Z leest. Iedereen zoekt en vindt (hopelijk) waar hij behoefte aan heeft. In het handboek zijn veel kruisverwijzingen opgenomen naar gerelateerde onderwerpen zodat de zoeken vindtocht zo kan worden voortgezet.

architectuur in duidelijke

Dit laat onverlet dat juist bij een architectuur de ‘samenhang der dingen’ van groot belang is. Om deze samenhang te tonen is een uitgebreide managementsamenvatting opgenomen. Ook beginnen alle inhoudelijke hoofdstukken met een inleiding. Dit alles zo veel mogelijk in duidelijke en begrijpelijke taal. Ideaal dus voor geïnteresseerde bestuurders, managers en mensen die voor het eerst te maken krijgen met architectuur.

en begrijpelijke taal

opbouw handboek

Het handboek is als volgt opgebouwd: Hoofdstuk 2 is een introducerend hoofdstuk voor professionals die dit handboek voor het eerst onder ogen krijgen. Het beschrijft de visie van Amsterdam op architectuur en geeft de opbouw en reikwijdte van de architectuur weer. Dit gebeurt aan de hand van een architectuurraamwerk dat als basis wordt gebruikt in dit handboek. Dit raamwerk kent vijf lagen: 1. Organisatiearchitectuur 2. Procesarchitectuur 3. Informatiearchitectuur 4. Applicatiearchitectuur 5. Infrastructuurarchitectuur Vanaf hoofdstuk 4 duiken we de inhoud in. Hoofdstuk 3 bevat een overzicht van de grondslagen. De hoofdstukken 4 t/m 8 bevatten de verschillende modellen en standaarden voor de vijf onderscheiden lagen van de architectuur. Ook wordt hier ingegaan op het beheer en beveiliging van de architectuur. Hoofdstuk 9 tenslotte beschrijft de wijze waarop de architectuur in de toekomst verder zal worden ontwikkeld, beheerd en toegepast. Daarbij staan we

1-4



expliciet stil bij de organisatie, rollen en verantwoordelijkheden rond de architectuur. Achterin het handboek is een Lijst van modellen en tabellen en een Index opgenomen. Bij dit handboek horen verder vele Bijlagen. Deze bevatten meer gedetailleerde uitwerkingen van grondslagen, modellen, gemeenschappelijke applicaties en geven achtergrondinformatie. Dit is voer voor specialisten die nog verder de diepte in willen.

1-5


de noodzaak


2

De Amsterdamse visie op architectuur

2.1

Van ongeduld naar actie door samenwerking en architectuur 3

Waarom een architectuur van de Amsterdamse organisatie en informatievoorziening? Omdat we zonder een goede verbinding tussen de vereisten van de organisatie en de primaire processen enerzijds en de vormgeving van de informatievoorziening anderzijds (business alignment) niet kunnen leveren wat van ons verlangd wordt. Burgers en bedrijven verlangen een overheid die niet naar de bekende weg vraagt, die klantgericht is, zich niet voor de gek laat houden, die weet waar ze het over heeft, die haar zaken op orde heeft en die niet meer uitgeeft dan nodig is. Een Andere Overheid dus of zoals we het Amsterdamse Beter Presteren en Van ongeduld naar actie noemen. Zoals we in Hoofdstuk 1 hebben gezien komt de transformatie naar Beter Presteren en de Andere Overheid in de kern neer op: • De burger aan het stuur • Stroomlijning van werkprocessen • Het delen van informatie- en ICT-middelen Van ongeduld naar actie.

samenwerking in het concern

architectuur als noodzakelijke voorwaarde

In de visie van Amsterdam kan dit in onze stad alleen succesvol gebeuren wanneer we concernbreed samenwerken op allerlei niveaus, zoals: • Samenwerking tussen stadsdelen en centrale stad • Samenwerking tussen diensten, bedrijven en stadsdelen onderling • Samenwerking binnen diensten, bedrijven en stadsdelen • Samenwerking op het niveau van het topmanagement, middenmanagement en de werkvloer • Samenwerking tussen organisatieontwerpers en informatici Om deze samenwerking te ondersteunen is inzicht in de samenhang nodig, een gemeenschappelijke taal en een bestemmingsplan voor de realisatie van de Andere Overheid inclusief gemaakte afspraken. Dit komt samen in architectuur. In onze visie is werken onder architectuur een noodzakelijke voorwaarde om de Andere Overheid te realiseren.

3

Idealiter bouwt de architectuur voort op een vastgesteld concernbreed informatiebeleidsplan. Aan het informatiebeleidsplan wordt momenteel gewerkt en voor de zomer 2007 verwacht.

2-1



2.2

Vertaling programma- en bestuursakkoord

INFORMATIE BELEID

INFORMATIEARCHITECTUUR

Beleidsvisie Afstemming met bedrijfsbeleid Bedrijfsmodel Globaal bedrijfsinformatiemodel Beleidsrealisatierichtlijnen

richten

Model van informatievoorziening Architectuurplannen

inrichten INFORMATIEPLANNING

Lange-termijnplan Middellange-termijnplan Korte-termijnplannen

Systeemontwikkeling of –aanschaf gebruik, exploitatie en onderhoud

uitvoeren

UITVOERING

Bron: Meerjarenplan Informatiemanagement informatiebeleidsplan, architectuur en planning

De vertaling van het programma- en bestuursakkoord en de betekenis voor de informatievoorziening en ICT wordt beschreven in het informatiebeleidsplan. Het informatiebeleidsplan beschrijft hoe we de informatievoorziening kunnen gebruiken (richten) en stelt functionele kaders (als een integraal onderdeel van het organisatiebeleid). De belangrijkste pijlers in het informatiebeleidsplan voor de komende periode zijn de acht thema’s uit het programma- en bestuursakkoord: voortijdig schoolverlaten, jeugdzorg, invoering Wet Maatschappelijke Ondersteuning (WMO), overlast van jeugdgroepen, geweld achter de voordeur (huiselijk geweld), economische ontwikkeling, dienstverlening en regelgeving/handhaving, In het verlengde hiermee is het handboek architectuur een hulp- en communicatiemiddel en een toetskader gericht op gebruik door professionals die zich bezighouden met de organisatie en informatievoorziening. Het geeft via concrete grondslagen, modellen, standaarden en beheerprocedures een beschrijving van de inrichting van informatievoorziening en de ‘bouwkundige’ kaders waarbinnen gewerkt moet worden (inrichten). Op basis van het informatiebeleid en de architectuur wordt vanuit de twee invalshoeken (inrichten en richten) een (informatie)planning opgesteld met programma’s en projecten om de cruciale informatie- en ICT-voorzieningen te realiseren (uitvoeren).

2-2



2.3

Balans nodig tussen snelheid en samenhang 4

perfecte architectuur?

Bestaat er zoiets als een perfecte architectuur? Nee. Bij het vormgeven van de Andere Overheid lopen we voortdurend aan tegen een spanning tussen enerzijds snelheid en anderzijds samenhang.

samenhang vs.

Architectuur geeft structuur, een rode draad en vastigheid. Het verkrijgen van samenhang vergt reflectie op het functioneren van de organisatie en de informatievoorziening. Dat betekent onderzoek, afstemming en planning. En dat kost tijd, zoals ook samenwerken tijd kost. Aan de andere kant vraagt de roep om een Andere Overheid door burgers, ondernemers en politici om snelheid. Er bestaat dan ook een continu spanning tussen snelheid en samenhang bij het realiseren van businessdoelen door ICT-oplossingen.

ontwikkelaars met oogkleppen

Wie snel wil zijn, heeft geen tijd om met anderen af te stemmen of plannen te maken (“quick & dirty ontwikkelaars”). Wie omgekeerd verder kijkt dan het (eigen)belang van dit moment, zal niet altijd de snelste weg naar zijn doel bewandelen.

een goede architectuur vindt balans tussen snelheid en samenhang

Zowel snelheid als samenhang zijn essentieel voor een efficiënte en effectieve inzet van ICT en beide worden ook steeds belangrijker. Slaat de balans door naar snelheid, dan rijzen de kosten de pan uit, weten partners niet meer van elkaar waar ze mee bezig zijn, blijken belangrijke gegevens onvindbaar en zal uiteindelijk de burger die vragen heeft van het kastje naar de muur worden gestuurd. Slaat de balans door naar samenhang, dan loopt de organisatie het risico prachtige producten en diensten op de markt te zetten, maar te laat wanneer de burgers en bedrijven er geen behoefte meer aan hebben of ze zijn achterhaald door nieuwe ontwikkelingen. Kader: Is architectuur een hype? De geschiedenis laat zien dat de relatie tussen bedrijfsprocessen en de informatievoorziening in de loop der jaren fundamenteel is gewijzigd. Hierin moet ook de opkomst van ‘architectuurdenken’ worden geplaatst. In de jaren ’70 en ’80 van de vorige eeuw veranderden bedrijfsprocessen

4

Deels ontleend aan DYA; snelheid en samenhang in business en ICT-architectuur, Sogeti Nederland B.V.

2-3



ongeveer elke zeven jaar. De tijd die nodig was om de ondersteuning hiervan door de informatievoorziening tot stand te brengen kon dat tempo redelijk bijhouden. Vanaf de jaren ‘90 veranderen bedrijfsprocessen echter steeds sneller. Het aanpassen van de informatievoorziening begint daarop achter te lopen. Tegelijkertijd zien we in deze periode ICT steeds dieper doordringen in de haarvaten van de organisatie en daarmee steeds belangrijker worden. Waar voorheen ICT slechts één van de hulpmiddelen was om businessdoelen te bereiken, is het inmiddels voor alle gemeentelijke onderdelen van cruciaal belang geworden. Ook voor de realisatie van het beleid is ICT onontbeerlijk. Daarbij zien we ook een steeds verdergaande integratie van organisaties met elkaar, met hun ‘leveranciers’ (bijv. andere overheden) en hun ‘klanten’ (bijv. burgers en bedrijven). Leverancier, klant en organisatie vormen als het ware een netwerk waarbij leverancier en klant directe invloed hebben op de interne processen van de organisatie. Dit alles wordt mogelijk gemaakt door ICT. Deze toenemende vervlechting leidt tot vraagstukken als het delen van gegevens, het koppelen van applicaties en het verbinden van bedrijfsprocessen tussen organisaties. Samenhang en samenwerking zijn nodig om dit succesvol te doen. Architectuur is daarbij een cruciaal hulpmiddel en geen hype.

2.4 ‘bescheiden’ instrument: een eerste stap

De gefaseerde ontwikkeling van onze architectuur

Architectuur is in de Amsterdamse visie een middel om de juiste balans te vinden tussen snelheid en samenhang bij het realiseren van de Andere Overheid. Het is geen doel op zich, maar nadrukkelijk een instrument. Het is een bescheiden ‘Zwitsers zakmes’ voor de professional in de informatievoorziening. Waarom bescheiden? Het werken onder architectuur staat in Amsterdam –net als bij veel andere organisaties- in de kinderschoenen. In juli 2005 is een start gemaakt toen vanuit de Stuurgroep Basisregistraties en ICT-Infrastructuur het initiatief is genomen tot een concernbrede Adviesgroep Architectuur. De eerste versie van dit handboek vormt het resultaat van ruim één jaar denken, praten over en ontwikkelen van architectuur. Daarmee zetten we een forse eerste stap, niets meer en niets minder.

nu: nadruk op stimuleren samenwerking en BRI

toetskader voor nieuwe ontwikkelingen

2-4

De nadruk van deze eerste versie ligt op het faciliteren en stimuleren van samenwerking door het bieden van inzicht en overzicht, en het aanreiken van richtlijnen en standaarden die primair zijn gericht op (de ontwikkeling van) gemeenschappelijke voorzieningen voor de gemeente Amsterdam en het programma Basisregistraties en ICT-voorzieningen in het bijzonder. Het handboek is bedoelt als toetskader en richtlijn voor nieuwe ontwikkelingen, projecten en vervanging van bestaande systemen. In het handboek zijn standaarden en richtlijnen opgenomen om de samenwerking vorm te kunnen geven. De architectuur is richtinggevend, maar het is voorstelbaar dat bij het realiseren van een specifieke business doelstelling (bijvoorbeeld bij uitzonderlijk veel tijdsdruk) bewust wordt afgeweken van de architectuur. Wel lijkt het redelijk om de bewijslast te leggen bij de partij die wil afwijken. Zie Hoofdstuk 9 voor de uitwerking van de architectuurorganisatie en –proces.


ontwikkeling: meeliften met belangrijke verandertrajecten

ontwikkeling: investeren in en inbedden van werken onder architectuur


De Amsterdamse architectuur is verder geen statisch product. De architectuur zal continue aan verandering onderhevig zijn; het is nooit ‘af’. Dat zou ook niet efficiënt zijn. In onze visie vindt het werken onder architectuur zijn rechtvaardiging in het bereiken van de businessdoelen. Het ontwikkelen van de architectuur moet dan ook gestuurd worden door die businessdoelen. Anders ontstaat de vage situatie van “het bedrijven van architectuur om de architectuur”. Deze eerste versie van de architectuur is ontstaan vanuit de businessdoelen in het programma Basisregistraties en ICT infrastructuur. In onze visie moet de architectuur zich verder ontwikkelen door nadrukkelijk mee te liften op belangrijke verandertrajecten binnen de gemeentelijke organisatie. Met deze eerste versie van de architectuur zetten we een belangrijke eerste stap. Tegelijkertijd zal dit een nutteloze stap blijken als we niet zorgdragen voor een goede organisatorische inbedding van architectuur in de organisatie (zie ook Hoofdstuk 9 ). Om het werken onder architectuur inhoud te geven zullen de architectuurprocessen ingericht en voldoende middelen (mensen en geld) toegewezen moeten worden. Daar ontbreekt het nu nog aan in Amsterdam. De komende jaren zal hierin flink geïnvesteerd moeten worden.

2.5

De reikwijdte van het Handboek Architectuur

Zoals boven aangegeven is dit handboek geen wondermiddel. Hieronder staan een aantal uitspraken die aangeven wat de in dit handboek beschreven architectuur wel en niet is en doet. gewenste situatie circa 2011

niet alleen ICT

alleen gemeenschappelijke voorzieningen en koppelvlakken

5

1. De architectuur beschrijft de gewenste situatie van onze organisatieen informatievoorziening rond 1 januari 2011. Het is een zogenaamde ‘tomorrow-architectuur’, wat wil zeggen dat het een gewenste situatie beschrijft. Daarbij wordt circa 4 jaar, dat wil zeggen tot circa 2011, vooruit gekeken. We zeggen bewust ‘circa 4 jaar’ omdat dit nogal kan verschillen afhankelijk van bijvoorbeeld de uitgangssituatie, de complexiteit en de prioriteit die het management eraan wil geven. En sommige zaken zijn (gelukkig) ook al goed ingericht. 2. De architectuur richt zich op meer dan alleen informatievoorziening en ICT. Het is een zogenaamde ‘enterprise architectuur’ De architectuur gaat niet alleen over informatievoorziening en techniek, maar richt zich ook op de koppeling met het zogenaamde businessdomein (bedrijfsprocessen en de organisatie). Dit is noodzakelijk omdat de realisatie van de overheid vraagt om samenhang en samenwerking op alle niveaus: de business kan niet zonder ICT en vice versa. De uitwerking van het businessdomein is op een hoger abstractieniveau dan de uitwerking van de informatievoorziening. 3. De architectuur beperkt zich tot gemeenschappelijke voorzieningen De architectuur bevat alleen grondslagen, modellen en standaarden voor de gemeenschappelijke organisatie en informatievoorziening binnen het concern Amsterdam 5. De architectuur beschrijft derhalve niet de organisatie en informatievoorzieningen op het niveau van individuele diensten, bedrijven en stadsdelen (of daarbinnen van werkeenheden). De koppelvlakken met

Er is een klein aantal uitzonderingen in Hoofdstuk 8 . Deze zijn expliciet benoemd in de tekst.

2-5


Niet volledig


concernvoorzieningen vallen wel binnen de scope van de architectuur. Diensten, bedrijven en stadsdelen zullen daarom wel aan de standaarden voor deze koppelvlakken moeten gaan voldoen. De beperking tot concernvoorzieningen laat onverlet dat onderdelen van de architectuur (bijvoorbeeld grondslagen, standaarden) ook voor diensten, bedrijven en stadsdelen bruikbaar kunnen zijn. 4. De architectuur is niet volledig Deze eerste versie van de architectuur is niet volledig. Het bevat alleen die elementen die cruciaal zijn voor de realisatie van de Andere Overheid (en meer specifiek het programma BRI) en zaken die ‘op de plank lagen’ en zo makkelijk in de architectuur konden worden ‘gehangen’. Verdere uitwerking van de architectuur wordt gedaan vanuit het perspectief van de zes hoofdprocessen uit Beter Presteren. Met de komende jaren als insteek de thema’s uit het programma- en bestuuursakkoord: voortijdig schoolverlaten, jeugdzorg, invoering Wet Maatschappelijke Ondersteuning (WMO), overlast van jeugdgroepen, geweld achter de voordeur (huiselijk geweld), economische ontwikkeling, dienstverlening en regelgeving/handhaving. Dit betekent niet dat bijvoorbeeld de WMO in het handboek wordt opgenomen maar wel bijvoorbeeld herbruikbare en generieke onderdelen zoals: servicebus en zakenmagazijn. Op basis van het informatiebeleidsplan en de architectuur wordt een planning opgesteld van projecten om een aantal cruciale gemeenschappelijke voorzieningen te realiseren.

2.6 standaard voor beschrijven architectuur

Het Amsterdamse architectuurraamwerk

In Amsterdam kennen we een standaard voor het opbouwen en beschrijven van architecturen in de vorm van een architectuurraamwerk. Dit raamwerk deelt een architectuur inhoudelijk op in vijf (horizontale) lagen en vijf (verticale) kolommen (zie Tabel 2-1) 6. Het vormt het ‘skelet’ voor de architectuur in dit handboek en is ook de standaard voor nog op te stellen Amsterdamse architecturen. Het lagenmodel is vooral een hulpmiddel om de gedachten te ordenen en samenhang inzichtelijk te maken.

architectuurraamwerk

Tabel 2-1 Amsterdamse architectuurraamwerk Dit raamwerk bevat daarmee de gangbare en essentiële onderdelen die het 6

Het architectuurraamwerk dat de basis vormt van de Nederlandse OverheidsReferentie Architectuur (NORA) is ingedeeld in 3 lagen: bedrijfs-, informatie- en technische architectuur, de kolommen: wie, wat en hoe en de generieke dimensies beheer en beveiliging. In NORA en het Amsterdamse raamwerk komen dezelfde onderdelen terug, de indeling is alleen verschillend.

2-6



‘werken onder architectuur’ praktisch en overzichtelijk maken. Belangrijker is dat het raamwerk op zichzelf ook een ‘taal’ vormt waarmee het mogelijk is om in Amsterdam over architectuur met elkaar te communiceren en samen te werken. Hieronder lichten we de verschillende lagen en kolommen kort toe. 2.6.1

Vijf horizontale lagen

organisatiearchitectuur

De organisatiearchitectuur richt zich op het ‘wie’ en ‘wat’ van de gemeente Amsterdam. Uit welke organisaties bestaat het concern, hoe verhouden deze zich tot elkaar, welke relaties zijn er met de buitenwereld en wat zijn de diensten die zij aan burgers, bedrijven en elkaar leveren? Een kernelement in dit onderdeel is de wijze waarop de zogenaamde front-, miden back office zijn georganiseerd.

procesarchitectuur

De procesarchitectuur richt zich op het "waar en wanneer" ofwel de processen waarmee de in de organisatiearchitectuur onderscheiden diensten worden voortgebracht. De zes hoofdprocessen van de gemeente Amsterdam vormen hiervoor het kader.

informatiearchitectuur

De informatiearchitectuur heeft betrekking op de inrichting van de informatiehuishouding van de e-overheid. Hierbij gaat het om alle informatie, niet slechts om dat wat geautomatiseerd is. De informatiearchitectuur richt zich op de informatie zelf en de betekenis daarvan (het "wat") en de uitwisseling van informatieberichten (het "waar en wanneer"). De basisregistraties staan centraal in deze laag.

applicatiearchitectuur

De applicatiearchitectuur richt zich op de functionele aspecten van de informatiehuishouding oftewel de applicaties (het “welke applicatie doet wat”). Vroeger was een applicatie één gesloten brok software voor één proces. Het ontwikkelt zich steeds meer naar kleine, samenwerkende softwarecomponenten die elkaar zogenaamde services bieden. In deze laag wordt de vormgeving van applicaties beschreven om een zogenaamde service gerichte architectuur te ondersteunen.

infrastructuur-architectuur

De infrastructuurarchitectuur beschrijft het samenstel van machines, opslagvoorzieningen, netwerkcomponenten en generieke applicaties. Het is een middel om de uitwisseling van informatie tussen applicaties te kunnen verwezenlijken, als uitwerking van de servicegerichte architectuur. Een kernelement op deze laag is E-net. Aan elk van de lagen is een apart hoofdstuk besteed. 2.6.2

Vijf verticale kolommen

Elk van de vijf architectuurlagen bevat een vaste set van onderdelen. Hieronder zijn deze kort beschreven. Elk hoofdstuk dat een architectuurlaag beschrijft bevat vijf paragrafen waarin deze onderdelen terugkomen. grondslagen

Grondslagen zijn richtinggevende en kaderstellende uitspraken voor de inrichting van de architectuur.

2-7



modellen

Modellen zijn platen oftewel (vereenvoudigde) visuele weergaven van onderdelen van de architectuur.

standaarden

Standaarden zijn afspraken of normen die binnen de architectuur van kracht zijn. Er zijn vier basisvormen van standaarden: 1. Richtlijnen Dit zijn algemene geformuleerde richtinggevende uitspraken over (de mate van) standaardisering. 2. Afspraken Het betreft hier een set basisafspraken waaraan iedereen zich committeert. Los van dit ‘minimum’ is er vrijheid voor elke organisatie om zijn eigen invulling te geven. Een goed voorbeeld is de Gemeentelijke Informatiebeveiligingsnorm (GIBN). 3. Bandbreedte standaarden Hierbij is er een beperkt aantal opties waaruit een organisatie een keuze kan maken. Voor financiële pakketten kunnen organisaties bijvoorbeeld kiezen tussen Exact, Fis4all, Civision, OneWorld en Decade 4. Uniforme standaarden Hierbij is er één verplichtende norm voor alle organisaties. Zo is centrale E-net infrastructuur de uniforme standaard voor de verbinding tussen lokale infrastructuren. Een belangrijk uitgangspunt van dit handboek is dat standaardisering integraal op alle lagen moet worden toegepast (zie kader). Het is dus meer dan alleen technische standaardisering (bijvoorbeeld één pakket). Standaardisatie is net als architectuur geen doel op zich. Standaarden moeten zinvol en haalbaar zijn. Dit kan worden bepaald door het laten opstellen van een businesscase. Standaarden komen zo via een zorgvuldig proces tot stand. In het kader van architectuur is het van groot belang om de komende periode het standaardisatiebeleid verder te ontwikkelen op basis van de notitie ICTstandaardisatie 7. Kader: Met de keuze voor één pakket nog geen standaardisering Standaardisering wordt meestal geassocieerd met de keuze voor één pakket voor een bepaalde functie die gemeentebreed wordt toegepast. Dit is niet juist. Zonder aanvullende standaardisering op proces en inhoud kan een dergelijk besluit zelfs contraproductief werken, ook in het geval dat een dergelijk besluit concernbreed wordt toegepast. Dat maakt standaardisering behalve een onderwerp voor informatici ook een organisatorisch onderwerp. Het organisatorische vermogen van de gemeente Amsterdam om tot standaardisering van processen en inhoud te komen is meer bepalend dan de vraag of architecten één of meerdere pakketten tot standaard kunnen benoemen. In Hoofdstuk 7 komt dit terug. Er zit ook een juridische en aanbestedings kant aan het verhaal van pakket c.q. applicatiestandaardisatie. Het vaststellen van gemeentebrede ICTstandaarden is in beginsel een bevoegdheid van het college van B&W en de

7

Een belangrijke stap in van het standaardisatiebeleid is door het college van B&W op 9 november 2004 gezet. In de vastgestelde notitie ICT-standaardisatie zijn enkele basisprincipes voor standaardisatie benoemd plus een aantal standaarden.

2-8



stadsdeelbesturen. In 2004 heeft het College bijvoorbeeld haar voorkeur uitgesproken voor een reeks van bedrijfsvoeringapplicaties (waaronder: Exact, Fis4all, Civision, ONe World, Decade en Documentum) om het aantal ICTvariaties die binnen de gemeente Amsterdam worden gebruikt, terug te dringen. Bij de selectie en inkoop van producten, waaronder bedrijfsvoeringapplicaties, is de gemeente Amsterdam verplicht zich te houden aan de geldende aanbestedingsregels. Het gewenste product moet zo objectief mogelijk worden beschreven. Het noemen van merknamen (zoals Exact, Fis4all etc.) is in beginsel niet toegestaan. Welk merk uiteindelijk daadwerkelijk wordt ingekocht en concernbreed zal worden gebruikt is op dit moment niet te zeggen. Hiertoe dient het resultaat van de aanbesteding te worden afgewacht. beheer

Binnen elke laag is voor de modellen en standaarden vastgelegd wie erover gaat (eigenaar) en wie het onderhoudt (In beheer). Eigenaren van modellen en standaarden zijn verantwoordelijk voor het organiseren en (laten) uitvoeren van het beheer. Er valt nog veel te winnen voor de gemeente door het goed organiseren van de rollen eigenaar en beheerder. In het handboek worden hier verschillende voorstellen voor gedaan. Voor zowel het onderscheid tussen eigenaar en beheerder als een uiteenzetting van functioneel, applicatie als technisch beheer op met name applicatieniveau wordt verwezen naar het ‘Raamwerk voor beheer’ 8 (zie Bijlage 2).

Beveiliging

Het beleid voor informatiebeveiliging binnen de gemeente is vastgelegd in de Gemeentelijke InformatiebeveiligingsNorm (GIBN). De GIBN is een samenhangend geheel van maatregelen van procedurele, organisatorische, fysieke, technische en juridische aard. Het raakt aan: • algemeen beveiligingsbeleid (bijv. deuren, kluizen, toegangscontrole) • personeelsbeleid (bijv. screening, opleiding en functietypering) • organisatiebeleid (bijv. functiescheiding) • informatiebeleid (bijv. standaardisering en ‘proven technology’) • privacybeleid (bijv. correct gebruik van persoonsgegevens) • juridisch beleid (bijv. afbreukrisico’s bij privacyschendingen, clausulering in overeenkomsten met derden, Third Party Mededelingen) Het doel van de GIBN is het behoud van: • continuïteit en beschikbaarheid (voorkomen van uitval van systemen), • integriteit en betrouwbaarheid (gegevens zijn juist, actueel en volledig) • exclusiviteit en vertrouwelijkheid (onbevoegden kunnen geen kennis nemen van informatie die een organisatie onder zich heeft)

8

Raamwerk voor beheer, versie 0.2, Irene Verschuur, ICT Beheergroep Amsterdam. Het Raamwerk voor beheer is een eerste concept en wordt momenteel verder ontwikkeld.

2-9



Per laag is aangegeven welke paragrafen uit de GIBN van toepassing zijn. Zonodig zijn ook aanvullende richtlijnen of uitgangspunten opgenomen. In volgende versies van de architectuur dient dit onderdeel nog verder verdiept te worden met name gelet op de verdergaande proces- en ketenaanpak.

2 - 10


richtinggevende uitspraken

16 belangrijkste grondslagen

Selectie argumenten


3

Grondslagen

3.1

Inleiding

Grondslagen (ook wel ‘principes’ genoemd) zijn richtinggevende en kaderstellende uitspraken voor een architectuur. Grondslagen vormen daarmee ook de basis voor de architectuur van de gemeente Amsterdam. De grondslagen vormen de eerste verticale dimensie van het Amsterdamse architectuurmodel. Er zijn wel honderden grondslagen te verzinnen. We hebben ervoor gekozen om ons te beperken tot de belangrijkste 9. Op alle vijf lagen van de architectuur (organisatie, proces, informatie, applicatie en infrastructuur) komen we grondslagen tegen. Daarnaast onderscheiden we drie algemene grondslagen die op alle lagen betrekking hebben. Hieronder zijn deze –in totaal 17opgesomd. In Bijlage 4 worden de grondslagen nog verder toegelicht, met de reden waarom en de implicaties. De keuze van de hier genoemde grondslagen is gemaakt tijdens workshops, hierbij is gekeken welke grondslagen in de Amsterdamse situatie richting geven en werkbaar zijn en op concensus konden rekenen.

3.2

Algemene grondslagen

grondslag 0.1

De gemeente Amsterdam ontsluit publieke informatie, maakt zichtbaar wat zij doet, welke besluiten ze neemt, welke gegevens zij heeft en gebruikt en hoe zij werkt.

grondslag 0.2

De gemeente Amsterdam voert haar taken uit volgens de wet en volgt bestaande en aangekondigde weten regelgeving.

Grondslag 0.3

De gemeente Amsterdam confirmeert zich aan de landelijke (overheids) standaarden.

3.3

Grondslagen organisatiearchitectuur

grondslag 1.1

De gemeente Amsterdam organiseert zichzelf in los gekoppelde onderdelen die onderling en met hun omgeving nauw samenwerken om resultaten te boeken.

grondslag 1.2

De gemeente Amsterdam opereert dichtbij burgers en bedrijven en maakt wederzijds contact laagdrempelig.

grondslag 1.3

De gemeente Amsterdam opereert consistent, als één concern, als integraal onderdeel van de gehele overheid.

9

In de Nederlandse Overheids Referentie Architectuur (NORA) staan heel veel grondslagen. Veel van deze grondslagen zijn ook van toepassing op de architectuur van de gemeente Amsterdam zoals beschreven in dit handboek.

3-1


grondslag 1.4


Communicatiekanalen kunnen door elkaar heen worden gebruikt.

3.4

Grondslagen procesarchitectuur

grondslag 2.1

Processen worden ingericht als onderdeel van complete ketens. Deze zijn ontworpen vanuit de behoefte van burgers, bedrijven en overige belanghebbenden in de samenleving.

grondslag 2.2

Vergelijkbare processen worden in Amsterdam op één en dezelfde wijze beschreven en ingericht.

3.5

Grondslagen informatiearchitectuur

grondslag 3.1

De basisregistraties en kernadministraties vormen een verplichte bron van de Amsterdamse gegevenshuishouding

grondslag 3.2

Gegevens worden éénmalig opgeslagen en meervoudig gebruikt.

grondslag 3.3

Gegevens worden ontsloten met maximale transparantie binnen de wettelijke kaders en volgens de privacy pricipes.

grondslag 3.4

De gemeente Amsterdam garandeert vertrouwelijkheid van gegevens, betrouwbaar (digitaal) contact en zorgvuldige (elektronische) archivering.

3.6

Grondslagen applicatiearchitectuur

grondslag 4.1

Applicaties zijn modulair opgebouwd zodat functies kunnen worden hergebruikt.

grondslag 4.2

Applicaties zijn gebaseerd op open standaarden en platform onafhankelijk.

grondslag 4.3

De gemeente Amsterdam maakt maximaal gebruik van standaard componenten.

3.7 grondslag 5.1

3-2

Grondslagen infrastructuurarchitectuur

De infrastructuur is schaalbaar, betrouwbaar en gebaseerd op open standaarden.



4

Organisatiearchitectuur

4.1

Inleiding

principes

Op deze laag gaat het over de bestuurlijke en organisatorische uitgangspunten, de business-doelstellingen, de inrichtingsprincipes en de wijze waarop een en ander organisatorisch kan of moet worden vormgegeven. Het is niet een complete of consistente beschrijving van een organisatieblauwdruk. De modellen en principes zijn bedoeld om richting te geven, trends aan te wijzen en de consequenties van ICT-ontwikkelingen tot uitdrukking te brengen.

koppel & kantelen

Een van die principes is: niet kantelen maar koppelen. De overheidsbrede architectuur NORA pleit daar sterk voor. Kantelen betekent dat de verticale organisatiestructuur fundamenteel op de schop moet en horizontaal wordt ingericht. Koppelen houdt in dat de oplossing gezocht wordt in het met elkaar verbinden van de organisatieonderdelen met behulp van slimme ICT. De waarheid ligt ongetwijfeld in het midden, de bewegingen beïnvloeden elkaar over en weer. Koppeling is op de kortere termijn de aangewezen weg en moet hoe dan ook gebeuren, de kanteling zal zich gaandeweg voltrekken als gevolg van het ketengerichte herontwerp van de primaire processen. De vernieuwing van de organisatiearchitectuur voltrekt zich langs drie lijnen: 1. een verdere professionalisering van de digitale front office; 2. de inrichting van een mid office; 3. de ontwikkeling en het beheer van de gemeenschappelijke voorzieningen.

4-1



1. digitalisering

De laatste jaren is met name de digitale dienstverlening sterk verbeterd. Trends daarbij zijn het creëren van eenduidige en enkelvoudige ingangen (no wrong door), het bevorderen dat klanten zelf een groter aandeel krijgen in de dienstverlening (customer self service) en het benutten van de meest efficiënte kanalen (channel management). De gemeente Amsterdam omarmt als vanzelfsprekend de landelijke BurgerServiceCode.

2. mid office

We kunnen onze business-doelstellingen alleen halen als we met één loket naar buiten treden, processen delen, gegevens delen en middelen delen. En om alle organisaties op elkaar aan te sluiten zijn er voorzieningen “in het midden” nodig om de processen te regisseren en de gezamenlijke gegevens te ontsluiten. Als we de voorziening waarvan hier sprake is voor het gemak even mid office noemen, dan gaat de discussie erom of die mid office organisatorisch of technisch vorm moet krijgen, of dat parallel kan, uit- of infaserend, wat leidend moet zijn en wat volgend.

3. samenhang

Op alle lagen van de architectuur ontstaat meer samenwerking en samenhang. Dit vergt aanpassing en organisatie van de gemeenschappelijke voorzieningen en de financiële middelen. 4.1.1

Gemeentewet

De raison d’être van elke gemeente ligt vast in de Gemeentewet en andere landelijke regelingen. Binnen de gemeente is de toepassing nader uitgewerkt in de vorm van gemeentelijke verordeningen. Zoals alle regelgeving staan deze onder invloed van maatschappelijke en politieke ontwikkelingen. rollen

De gemeente vervult de haar opgelegde maatschappelijke taken vanuit vier verschillende basisrollen: • bestuurder (lokaal bestuur); • ontwikkelaar (stadsontwikkeling, economische ontwikkeling, openbare scholen, cultuurraad); • uitvoerder (dienstverlening, handhaving, regelgeving); • producent (water, afvalverwerking, infrastructuur). Die rollen worden dagelijks ingevuld door de stadsdelen, diensten en bedrijven. In veel gevallen heeft de gemeente een monopolie, zodat burgers en bedrijven geen keuze hebben in leverancier. Dat plaatst de gemeente voor de opgave om - meer dan in het bedrijfsleven – de doelmatigheid en doeltreffendheid van haar activiteiten continu actief te bewaken.

4-2


output


Overeenkomstig deze basisrollen is de output van de gemeente in te delen in vier basiscategorieën: • sturing (het geven van impulsen, richtingen en doelen); • ontwikkelingswerken (ontwerpen, adviezen, cursussen, trainingen, opleidingen, innovaties); • diensten (uitvoering, onderhoud, administratie, vervoer, informatieverstrekking, gegevensverwerking); • producten (materiële zaken, roerende en onroerende goederen, gebruiksen verbruiksartikelen). Deze output kent vele vormen, die op verschillende manieren zijn in te delen en te presenteren. Beschrijvingen zijn opgenomen in een aantal verschillende overzichten (zie paragraaf 4.3 ).

hoofdprocessen

Om een structurele verbeterslag te maken in deze output is in Amsterdam, op basis van de ambitie tot Beter Presteren, een indeling in zes hoofdprocessen geadopteerd (zie hoofdstuk 5 ).

verordening

De Gemeentewet kent aan de gemeenten grote vrijheid toe met betrekking tot de organisatie van het ambtelijk apparaat (inclusief de rol van de gemeentesecretaris). Ingevolge artikel 159 van de Gemeentewet is de raad verplicht een organisatieverordening vast te stellen. Hierin wordt de interne organisatie en structuur van het eigen ambtelijk apparaat geregeld.

kerntaken

De ondersteuning van het college van Burgemeester en Wethouders (B&W) en Gemeenteraad is een kerntaak van het ambtelijk apparaat. Het zwaartepunt ligt daarbij bij het College en de individuele portefeuillehouders. De ondersteuning van de Raad neemt een veel kleinere plaats in. In de praktijk is de invloed van het ambtelijk apparaat groter dan van een ‘ondersteuner’ verwacht mag worden. Op veel dossiers is de uitvoering gedelegeerd aan ambtenaren, inclusief het onderhouden van externe contacten bij het beleidsvormingsproces. De recente hausse in de interactieve beleidsvorming lijkt die rol nog versterkt te hebben. Het ambtelijk apparaat heeft veel ruimte bij de uitvoerende taken van de gemeentelijke handhavingstaken en de dienstverlening aan de burger.

de organisatie

De gemeente Amsterdam heeft behalve de belangrijke Verordening op de Stadsdelen niet een afzonderlijke verordening met betrekking tot de ambtelijke organisatie. Wel zijn er in het recente verleden notities over dit onderwerp bestuurlijk vastgesteld (onder andere Beter Presteren en Samen Sterker Besturen) en zijn er in veel afzonderlijke documenten, bijvoorbeeld bij reorganisaties, uitspraken te vinden over de organisatorische invulling. 4.1.2

de architectuur

Architectuur van de organisatie

Een redelijk complexe organisatie zoals de gemeente is een levend sociaal organisme, waarin alle betrokkenen doorlopend de balans moeten bewaren tussen wat dwingend nodig is, wat het onderling overleg behoeft en wat in

4-3



vrijheid kan worden besloten. Het werken met organisatiearchitectuur gaat ervan uit dat alle betrokkenen uit inzicht en professionaliteit ‘vrijheden’ inleveren omwille van de meerwaarde die dat meebrengt voor de doelbewuste onderlinge samenwerking. De toepassing van organisatiearchitectuur is geen eenmalige opgave. de cultuur

De heersende interne organisatiecultuur is daarbij een belangrijke en soms zelfs bepalende factor. Dat geldt ook voor de gemeente Amsterdam, en misschien zelfs in sterkere mate gelet op de vrijheidslievende mentaliteit die cultuurhistorisch aan de Amsterdammers wordt toegeschreven.

het beheer

Tijdens de inventarisatie gedurende de periode waarin de eerste versie van dit handboek tot stand is gekomen heeft de Adviesgroep Architectuur geen gremium of afdeling aangetroffen die verantwoordelijk is voor de ontwikkeling en het beheer van de gemeentelijke organisatiearchitectuur. Sinds begin 2005 is er binnen de Bestuursdienst de directie Concern Organisatie, die recent het onderwerp organisatieontwikkeling op concernniveau ter hand heeft genomen. Hierbij aansluitend ligt het voor de hand deze directie de verantwoordelijkheid toe te kennen voor het beheer van dit hoofdstuk. 4.1.3

Externe ontwikkelingen

de burger centraal

De samenleving verandert en gemeenten veranderen mee. Hun rol en positie wijzigt daardoor. Niet alleen efficiency maar ook klantgerichtheid vormen belangrijke doelen in de eigentijdse gemeentelijke dienstverlening. Op dit vlak zijn er belangrijke door de rijksoverheid gestimuleerde ontwikkelingen, waarvan de consequenties niet alleen voor het ambtelijk apparaat maar ook voor het gemeentelijk bestel in ruimere zin aanzienlijk zullen zijn. Het gaat hierbij om de verwezenlijking van de één-loket-gedachte. Niet langer de op politiek-bestuurlijke logica gebaseerde sectorale indeling, maar de wensen en verlangens van de burgers zijn in deze benadering het belangrijkste structurerende element.

dichter bij de burger

Er is tevens een duidelijke tendens waar te nemen naar het wijkgewijs organiseren van die loketten, waar de burger voor de verschillende gemeentelijke diensten terecht kan. In het verlengde van deze wijkgeoriënteerde dienstverlening ligt de meer politiek-inhoudelijke zorg voor de directe leefomgeving. Vanwege de letterlijk zeer geringe afstand tot de individuele burger is ook hier een wijkgewijze organisatie in opkomst.

Andere Overheid

De bottom line staat verwoord in de missie van het landelijke programma Stroomlijning Basisgegevens: de Andere Overheid. Een overheid die niet naar de bekende weg vraagt, die klantgericht is, zich niet voor de gek laat houden, die weet waar ze het over heeft, die haar zaken op orde heeft en die niet meer uitgeeft dan nodig is. Een overheid met de burger aan het stuur, vernieuwde processen en slim en gedeeld gebruik van informatie en ICT.

de BSCode

Veel is bekend over wat de belangrijkste doelgroep, de burger, van de overheid wil. In de BurgerServiceCode (zie paragraaf 4.3 ) is dit compact vastgelegd. De BurgerServiceCode is een door burger@overheid ontwikkeld model, geschreven vanuit het perspectief van de burger. De code bevat tien

4-4



normen waaraan de klantcontacten moeten voldoen. Elke norm is tweezijdig geformuleerd: als een recht van de burger met een daarbij behorende plicht van de overheid. Wat overigens niet wil zeggen dat burgers geen plichten hebben. De burger is immers niet alleen de klant van overheidsdiensten maar ook de gebruiker van collectieve voorzieningen, de onderdaan die regels moet naleven en de staatsburger in het politieke proces. De code is zowel bestemd voor de burger als voor de overheid. De burger kan de overheid aanspreken op de kwaliteit van de klantcontacten. De overheid kan de code gebruiken om haar informatie, diensten en interactie op orde te brengen. 4.1.4

Interne ontwikkelingen

Beter Presteren

Naast externe factoren is er ook intern veel dynamiek. De gemeente Amsterdam komt er meer en meer achter dat de huidige manier van werken en organiseren doelmatiger kan en moet. Zie daartoe de discussies rondom Beter Presteren, Samen Sterker Besturen, het Bestuursakkoord en het Bedrijfsvoeringsakkoord.

programmaakkoord

In deze documenten maar ook in het Programakkoord 2006-2010 “Mensen maken Amsterdam” staan een aantal belangwekkende uitspraken die richtinggevend kunnen zijn voor de architectuur: • “Snelle dienstverlening en een faciliterende overheid zijn nodig.” • “Een open stad, een open bestuur, een open geest.” • “… verbetering ketenaanpak van maatschappelijke opvang …” • “Het huidige stelsel met veertien stadsdelen en daarnaast een centraal gemeentebestuur functioneert goed (…). Toch kan het stelsel, dat op stadsdeelniveau gebiedsgeoriënteerd is en op centraal niveau vakinhoudelijk, op sommige punten beter functioneren.” • “Dit College wil voor enkele politiek urgente onderwerpen de stadsdelen voorstellen nieuwe vormen van bestuur te introduceren gebaseerd op samenwerking en grotere besluitvaardigheid (…). Het College streeft ernaar om in een nieuw bestuursakkoord met de stadsdelen af te spreken welke onderwerpen worden gekozen. Daarnaast zal een aantal hoofdprocessen zoals handhaving en dienstverlening binnen de gemeente herontworpen worden, zodanig dat de dienstverlening aan Amsterdammers over vier jaar aanzienlijk is verbeterd.”

versnelling

Ook de in juli 2006 door het College van B&W vastgestelde notitie “Van ongeduld naar actie: voorstellen voor versnelling” doet een aantal belangwekkende richtinggevende uitspraken die gevolgen hebben voor diensten en bedrijven: • “De programma’s BRI en Servicehuis ICT zijn (de facto) de verplichte standaard of zullen deze leveren (voorzover die standaarden nog in ontwikkeling zijn) voor de centrale stad. De ambtelijke Stuurgroepen InformatieVoorziening en BRI worden gemandateerd om onder leiding van de Gemeentesecretaris de hoe-vraag in te vullen met dien verstande dat fundamentele verschillen van mening en beslissingen die niet binnen de bestaande budgettaire kaders vallen ter besluitvorming aan het college van B&W worden voorgelegd. Het college van B&W nodigt de stadsdelen uit zich aan te sluiten bij het BRI-programma en het Servicehuis ICT en de

4-5



•

•

plan van aanpak

daaraan gekoppelde ICT-standaarden.” “Antwoord en de digitale dienstverlening worden gemeentebreed ingevoerd. Een ambtelijk programmadirecteur (met een kleine programmaorganisatie) wordt aangesteld met als opdracht een rendabele business case dienstverlening op te stellen.” “De Gemeentesecretaris krijgt de opdracht om een aantal meer en minder vergaande opties met voor- en nadelen uit te werken met betrekking tot de vorming van een stads-MT”.

Eind 2006 heeft de gemeentesecretaris op verzoek van het college van B&W een Visie op besturing en inrichting van de centrale stad gegeven. In deze notitie wordt onder andere een referentiekader geschetst met principes voor de dienstverlening, de positionering, de besturing en de ordening. Op basis daarvan kunnen concrete voorstellen voor organisatiewijzigingen worden opgesteld. 4.1.5

Het fenomeen Mid Office

mid office

Over de mid office bestaat veel discussie. Moet die er komen? Is die er eigenlijk al? Waar dan? Blijkbaar is een onderscheid tussen een organisatorische en een technische mid office nuttig. Maar hebben we het dan niet toch over hetzelfde? We kunnen alleen beter presteren als we met één loket naar buiten treden. Dan zijn er voorzieningen “in het midden” nodig om de processen te regisseren en elkaars gegevens te kunnen gebruiken.

bricks&clicks

Voor een beter begrip is het goed het office-begrip in een historische context te plaatsen. Een halve eeuw geleden zag de wereld er, vanuit een organisatiekundig perspectief, tamelijk eenvoudig uit: organisaties waren van baksteen, handelingen en transacties gingen op papier. De dienstverlening was kleinschalig, alle medewerkers deden alles, het klantcontact verliep zo ongeveer één-op-één. De introductie van computers is van grote invloed geweest voor deze orde. De digitalisering is baksteen en papier gaan verdringen: van bricks naar clicks.

organisatorisch

Op enig moment is er een scheiding aangebracht tussen alles wat met de klant te maken had en wat moest zorgen voor de productie. De begrippen front office en back office ontstonden. De specialisten in de back office waren duur en moesten zich op hun eigenlijke taak kunnen concentreren. Het te woord staan van klanten in de front office was een vak apart en vereiste andere vaardigheden en kwaliteiten.

4-6



Aanvankelijk voltrok zich deze beweging bescheiden (de bank kreeg een aantal loketten), vervolgens schoot die enigszins door (de banken sloten ongeveer een derde van hun filialen en contant geld opnemen bij een loket was er niet meer bij) om ten slotte een zeker evenwicht te bereiken (eenvoudige transacties graag zelf doen via internet, maar voor een hypotheek van harte welkom in de spreekkamer). technisch

Het betreft hier een aantal voorzieningen van organisatorische aard, maar daarnaast heeft deze scheiding ook een technische kant. In de beschouwing hieronder worden deze telkens apart belicht maar het gaat in feite om twee kanten van dezelfde medaille. En met technisch wordt dan voornamelijk bedoeld: wat met behulp van ICT mogelijk is geworden. Het voorbeeld van de banken is erg illustratief. Het begon met de elektronische toegang tot het saldo, de digitale verstrekking van informatie. Vervolgens werd ook interactie mogelijk (vragen, berichten, aanvragen) en daarna heuse transacties (mutaties, betalingen). De klant is een (groot) deel van de handelingen zelf gaan doen (customer self service).

van 1x1 naar MxN

Deze ontwikkeling heeft zich inmiddels over vrijwel de gehele linie, bij profitbedrijven maar ook in non-profit-organisaties, voltrokken. Geleidelijk dient zich echter een nieuw probleem aan, door globalisering of schaalvergroting, of daar waar grotere organisaties aan het kantelen zijn geraakt van verticale kokers naar horizontale afstemming. Aan de voorkant is het aantal kanalen waarmee de klant wordt bediend toegenomen en tot volle wasdom gekomen. Naast fysiek loket en klassieke post gaat het om digitaal loket, contact center en emailcorrespondentie. Aan de achterkant is de noodzaak doorgedrongen, en zijn de mogelijkheden ontstaan, te ontkokeren en de producten of diensten meer integraal aan te bieden. De vroegere één-op-één verhouding tussen front en back office is daarmee fors aan het compliceren.

4-7



en van MxN

In Amsterdam is deze ontwikkeling in volle gang. Tot voor kort had elke dienst en elk stadsdeel zijn eigen loket aan de voorkant voor het eigen werkpakket aan de achterkant. Maar nu willen we graag dat de gezamenlijke front office van 30 diensten plus 14 stadsdelen in principe alle ruim 500 gemeentelijke producten levert vanuit misschien wel even zovele back offices (M keer N). Dan moet er dus een voorziening komen om die aansluiting optimaal te laten verlopen: het uitzetten van de vraag, het bewaken van de voortgang en het terugleveren van het resultaat.

naar M+N

Dat kan organisatorisch van aard zijn of technisch, maar zal in ieder geval het aantal relaties moeten reduceren (M plus N). Die voorziening is mid office gaan heten omdat het de koppeling en de afstemming moet verzorgen tussen de front office en de back office. In de twee bovenste lagen van het architectuurmodel worden de organisatorische consequenties gedocumenteerd, in de drie onderste lagen gaat het om de technische gevolgen.

aparte dienst?

De organisatorische kant kan tot uitdrukking komen door van de mid office een aparte eenheid te maken met een verantwoordelijkheid voor de verdeling van het werk naar de verschillende back offices, de regie op de voortgang, de registratie van de afwikkeling en de coördinatie van het gehele traject van dienstverlening. Een en ander sterk ondersteund door de techniek. De technische kant bestaat uit een aantal voorzieningen om de verdeling en de bewaking te faciliteren. Om de toegankelijkheid van gemeenschappelijke gegevens mogelijk te maken is er een integratie- en uitwisselingsplatform nodig. Verder moet er een zaakdossier en een klantdossier komen om de voortgang te bewaken, de registratie te verzorgen en statusmeldingen te kunnen doen.

drie tendensen

De historische ontwikkeling wordt afgerond met een blik naar voren. Het laat zich aanzien dat de technische mid office de organisatorische op enige termijn nagenoeg overbodig gaat maken. De techniek gaat zo intelligent en betrouwbaar worden dat menselijke bemiddeling steeds minder noodzakelijk wordt. Dat is één.

4-8



De medewerker in de organisatorische front office gaat zich steeds meer bedienen van dezelfde digitale front office die de klant ter beschikking staat. Het onderscheid gaat wegvallen tussen de interne en externe voorzieningen om transacties uit te voeren. Dat is twee. Onderdelen van de productie in de back office zullen door verdergaande digitalisering verschuiven naar de technische mid office. De productie van uittreksels en parkeervergunningen, de meldingen openbare ruimte, de eenvoudige WOZ-aanslagen, voor misschien wel 80% van deze “lichte” producten is menselijke bemoeienis of tussenkomst op termijn niet echt meer noodzakelijk. De klant bedient zichzelf wel. En dat is drie. 4.1.6

Organisatie- & inrichtingsprinicpes

De regel van Pareto, althans een enigszins vrije interpretatie daarvan, luidt als volgt. In een organisatie moet slechts 20% van de energie (mensen, middelen, activiteiten) besteed worden aan 80% van de markt, namelijk aan precies die klanten die zichzelf (al dan niet digitaal) gemakkelijk redden of aan die producten die zich eenvoudig laten verstrekken, om tegelijkertijd 80% van de tijd te kunnen besteden aan slechts 20% van de klanten die daar om uiteenlopende redenen om vragen, omdat het een oudere betreft of iemand met een taalachterstand, omdat het om een complexe aangelegenheid gaat of een moeilijk geval. De mogelijkheden die ICT biedt om die lichte categorie van 80% te bedienen worden nog volstrekt onvoldoende benut waardoor te weinig capaciteit overblijft om de zware 20% kwalitatief goed af te handelen. Kortom: licht doen wat eenvoudig kan, zwaar inzetten op wat ingewikkeld is. Bij banken, reisbureaus, verzekeringsbedrijven en internet-winkels is met succes een gedeelte van de benodigde transactie-inspanning verlegd naar de kant van de klant (omdraaiing van de registratie). Die vult van te voren zijn eigen gegevens en uit- of aanvraag alvast elektronisch in, een inspanning die eerder door de leverancier verricht moest worden. Daar zitten twee voordelen aan: het bespaart capaciteit in het productieproces van de leverancier, en het bevordert de kwaliteit van de gegevens. De gemeente Groningen laat bijvoorbeeld burgers, en vooral studenten, hun eigen verhuizing digitaal doorgeven. Waarom niet de gebruiksvergunningen voor bedrijfspanden op deze manier verstrekken? Of de aanvragen in het kader van de WVG? Of de

4-9



hondenbelasting, de WOZ-gegevens, het uittreksel, het rijbewijs, de bouwvergunning, de uitkering? Dit concept van customer self service (CSS) laat zich als volgt samenvatten. De organisatie is zo ingericht dat de klant zoveel mogelijk (eerst) zelf kan doen. Daartoe behoort in ieder geval het opgeven van de persoonlijke gegevens. Eenvoudige informatievragen of lichte producten worden verder volledig digitaal afgehandeld, dus zonder verdere tussenkomst van dure professionals. Misschien wel 50% van de klantcontacten kan zo worden afgedaan. Komt de klant er zelf niet uit, dan komt die automatisch terecht in een hoogwaardig call center dat op basis van de verstrekte gegevens beschikt over de gehele portfolio van de klant in kwestie. Ten minste nog eens 30% van de vragen wordt daarmee effectief beantwoord. Als het probleem nog ingewikkelder is, wordt contact tot stand gebracht met een expert in de back office, waar dus slechts 20% van de vragen terechtkomt. Dit concept leent zich ook voor interne toepassingen. Zo kan de organisatie ervoor kiezen dat de medewerkers hun eigen personele gegevens up to date houden en allerlei aanvragen en regelingen in de personele sfeer zoveel mogelijk zelf afhandelen. Deze toepassing heet employee self service (ESS) en kan leiden tot grote besparingen op of kwaliteitsverbeteringen van de HRMfunctie. De hierboven geschetste principes kunnen worden aangevuld met een dienstverlenings- of marketingconcept. Daarin is naast afspraken over serviceniveaus en klantbejegening, de stijl van Amsterdam, opleidingsvereisten en prijs/kwaliteitsverhoudingen, ook in een model voorzien waarin enerzijds het totale assortiment aan producten en diensten is uitgelijst (van “licht” naar “zwaar”) en anderzijds de beschikbare distributiekanalen.

4 - 10



De confrontatie van deze twee leidt tot een dienstverleningsmatrix waarin de combinaties zo worden gemaakt dat de Pareto-regel optimaal wordt toegepast terwijl de toegankelijkheid van de dienstverlening door achterstandsgroepen maximaal gegarandeerd blijft. Dit wordt bereikt door middel van channel management: de lichtere producten worden bij voorkeur digitaal aangeboden, de zwaardere dienstverlening blijft (professioneel) mensenwerk. Als het goed is, ontstaat zo een matrix waarin de kruisjes vooral in de linkerboven- en de rechterbenedenhoek staan. Licht doen wat eenvoudig kan, zwaar inzetten op wat ingewikkeld is. In nevenstaande grafiek is het perspectief geschetst van investeringen in elektronische transacties. Naast de kosten voor de infrastructuur van traditionele transacties (papier, baksteen, face to face) is inmiddels fors geïnvesteerd in een elektronische infrastructuur (intranet, internet, e-net). Schoorvoetend worden de eerste gemeentelijke producten nu ook digitaal aangeboden. Het uitnutten van de geïnvesteerde waarde lukt echter pas goed als op veel grotere schaal elektronische transacties de klassieke vervangen. Het kruisje indiceert de Amsterdamse situatie: het momentum voor een grote stap voorwaarts. De kwestie van deze daadwerkelijke substitutie is belangrijk. Veel verworvenheden en best practices bij diensten en stadsdelen hebben nog niet geleid tot het gelijktijdig stoppen van de papieren of analoge procesgang. Er komt alleen maar bij, en er gaat nog onvoldoende af. Een goed voorbeeld daarvan zijn de papieren nieuwsbrieven; er is inmiddels prima instrumentarium

4 - 11



beschikbaar voor een volledige digitalisering daarvan inclusief mailingfaciliteiten. Eén kanttekening is belangrijk. Wat in het bedrijfsleven wel kan (bijvoorbeeld: geen geldopname meer bij fysieke bankloketten), ligt bij de overheid genuanceerder: totdat ook de laatste burger digitaal vaardig is, moeten alle producten analoog én digitaal aangeboden worden. Dat hoeft echter niet te betekenen dat je niet het één kunt aanmoedigen en het ander min of meer kunt matigen. Naast de verbetering van de dienstverlening aan de klanten heeft deze digitalisering ook een zekere besparingspotentie. De duurste vorm van klantcontact is het fysieke loket. Vergaande vormen van customer self service zijn zonder meer goedkoper. Een niet geheel wetenschappelijk verantwoord beeld geeft het volgende staatje: • bezoek aan fysiek loket: €35,• bericht in vrije vorm: ? • bericht via een webformulier: €3,50 • telefoontje vrije vorm: ? • telefoontje naar contact center: €3,50 • self service met digitaal loket: €0,35 Ten slotte nog één trendmatige ontwikkeling. Over de volle linie, profit en nonprofit, zijn de klassieke verticale structuren aan het opbreken ten gunste van horizontale samenwerking en uitbesteding. Organisaties trekken zich terug op hun kerncompetenties en doen zoveel mogelijk de was de deur uit. De mogelijkheden daarvoor zijn: insourcing (FBA, PMB, IBA), outsourcing (GVB), shared services (ICT en HRM), en verregaande vormen van samenwerking met elkaar (afvalinzameling, BRI, dienstverlening, handhaving) of met ketenpartners (Waternet, GovUnited). Al dan niet (politiek) gestuurd, deze verschuiving is in volle gang en onstuitbaar. Een paar functies zijn voor elke organisatie onvervreembaar: directie en management, de capaciteit en kwaliteit om beleid te maken, en het vermogen om regie te voeren. Alles wat daaronder komt, is in principe vervreembaar. De bandbreedte wordt gevormd door het alleen uitbesteden van ondersteunende functies tot aan het volledig outsourcen van de primaire processen. De gemeente Ten Boer gaat hierin het verst: alles onder de gemeentesecretaris wordt uitbesteed aan grote broer Groningen.

4 - 12



4.2

Grondslagen

grondslag 1.1

De gemeente Amsterdam organiseert zichzelf in los gekoppelde onderdelen die onderling en met haar omgeving nauw samenwerken om resultaten te boeken.

grondslag 1.2

De gemeente Amsterdam opereert dichtbij burgers en bedrijven en maakt wederzijds contact laagdrempelig.

grondslag 1.3

De gemeente Amsterdam opereert consistent, als één concern, als integraal onderdeel van de gehele overheid.

grondslag 1.4

Communicatiekanalen kunnen door elkaar heen worden gebruikt.

4 - 13



4.3

Modellen

In deze paragraaf komt de structuur van de omgeving en van de interne organisatie van de gemeente aan de orde. Bij de interne organisatiestructuur is er een onderscheid tussen de staande organisatie (going concern) en de veranderingsorganisatie. Verder gaat het over producten en diensten en de organisatie van de mid office. 4.3.1 landelijk

De omgeving van de gemeente

De externe positie: Amsterdam in overheidsland; de verbindingen met landelijke organisaties als EGEM, ICTU, ICTAL

Model 4.1 Belangrijkste partners van de gemeente

PM Plaat met belangrijkste partners (op niveau organisaties) (voorbeeld onderdelen rijk, gemeenten, uitvoeringsorganisaties, VNG) van gemeente Amsterdam. PM toelichting op de plaat. Model 4.2 Belangrijkste landelijke initiatieven

PM Plaat met belangrijkste initiatieven (projecten, programma’s, beleidslijnen) rond Andere Overheid binnen Rijk en VNG, o.a. GovUnited. PM toelichting op de plaat. de BSCode

De BurgerServiceCode is een door [email protected] ontwikkeld model, geschreven vanuit het perspectief van de burger. De code bevat tien normen waaraan de klantcontacten moeten voldoen. 1. Keuzevrijheid contactkanaal Als burger kan ik zelf kiezen op welke manier ik met de overheid zaken doe. De overheid zorgt ervoor dat alle contactkanalen beschikbaar zijn (balie, brief, telefoon, email, internet).

2. Vindbare overheidsproducten Als burger weet ik waar ik terecht kan voor overheidsinformatie en -diensten. De overheid stuurt mij niet van het kastje naar de muur en treedt op als één concern. Model 4.3

3. Begrijpelijke voorzieningen

BurgerServiceCode

Als burger weet ik onder welke voorwaarden ik recht heb op welke voorzieningen. De overheid maakt mijn rechten en plichten permanent inzichtelijk.

4. Persoonlijke informatieservice Als burger heb ik recht op juiste, volledige en actuele informatie. De overheid levert die actief, op maat en afgestemd op mijn situatie.

5. Gemakkelijke dienstverlening Als burger hoef ik gegevens maar één keer aan te leveren en kan ik gebruik maken van pro actieve diensten. De overheid maakt inzichtelijk wat zij van mij weet en gebruikt

4 - 14



mijn gegevens niet zonder mijn toestemming.

6. Transparante werkwijzen Als burger kan ik gemakkelijk te weten komen hoe de overheid werkt. De overheid houdt mij op de hoogte van het verloop van de procedures waarbij ik ben betrokken.

7. Digitale betrouwbaarheid Als burger kan ik ervan op aan dat de overheid haar digitale zaken op orde heeft. De overheid garandeert vertrouwelijkheid van gegevens, betrouwbaar digitaal contact en zorgvuldige elektronische archivering.

8. Ontvankelijk bestuur Als burger kan ik klachten of meldingen en ideeën voor verbeteringen eenvoudig kwijt. De overheid herstelt fouten, compenseert tekortkomingen en gebruikt klachten om daarvan te leren.

9. Verantwoordelijk beheer Als burger kan ik prestaties van overheden vergelijken, controleren en beoordelen. De overheid stelt de daarvoor benodigde informatie actief beschikbaar.

10. Actieve betrokkenheid Als burger krijg ik de kans om mee te denken en mijn belangen zelf te behartigen. De overheid bevordert participatie en ondersteunt zelfwerkzaamheid door de benodigde informatie en middelen te bieden.

[Bron: [email protected] (versie 2.1)] 4.3.2

Producten en diensten

Er bestaan voor de producten en diensten die de gemeente levert verschillende typeringen en indelingen die variëren van 200 tot een kleine 600 producten: • de zogenaamde longlist van Cebeon en de shortlist van Anderson, Elfers & Felix, opgesteld in het kader van het landelijke IV3; • de jaarlijkse begroting en jaarrekening van de gemeente respectievelijk de gemeentelijke organisaties; • in het kader van het BTW-Compensatiefonds zijn de meeste outputvormen geïnventariseerd en fiscaal gerubriceerd; • het model-DSP, ontstaan vanuit de achtergrond van digitaal informatiebeheer en documentaire informatieverzorging (DIV); sinds 1 januari 2004 zijn overheidsinstellingen verplicht te beschikken over een Documentair Structuur Plan (DSP); de Sdu Uitgevers en VHIC hebben daarom, samen met de deelnemende gemeenten, het model-DSP voor gemeenten ontwikkeld; zie ook www.model-dsp.nl; • de themastructuur (burger)loket is, zoals de naam reeds doet vermoeden, met name gericht op de indeling van het fysieke loket; • de productencatalogus, zoals de VIND-catalogus en PIGA in Amsterdam, is vooral bedoeld voor webtoepassingen en zoekfaciliteiten; deze Vraaggerichte INteractieve Dienstencatalogus is ontwikkeld om vraaggerichte en geïntegreerde dienstverlening volgens de éénloketgedachte te ondersteunen; de beheerder is SDU Uitgevers, BPI;

4 - 15



• •

Product en Contain Organisatie en Advies, zie daarvoor www.productencatalogus.nl; en ook de VNG-thesaurus kan als een productindeling worden gezien.

Het producten- en dienstenaanbod van de gemeente zal over de tijd bezien redelijk stabiel zijn. Wel verandert de aard van de wijze waarop de producten worden geleverd. Er vindt een geleidelijke substitutie plaats van traditionele dienstverlening door digitale varianten. het ene loket

In Loket Amsterdam is een aantal van deze indelingen gecombineerd en vertaald in een aantal logische en overzichtelijke ingangen voor het gehele gemeentelijk scala aan informatie, producten en diensten (zie Model 4.4). Via welk kanaal de klant ook binnenkomt, de vraag wordt in zo weinig mogelijk stappen beantwoord. Duidelijk is dat de (on)mogelijkheden van internet het model hebben geïnspireerd.

Model 4.4 Thematische indeling diensten en producten

[Bron: Adviesgroep Architectuur] Het model kent een zevental ingangen: • thema (wonen, werk en inkomen), • doelgroep (ondernemer, burger), • levensfase (geboorteaangifte, trouwen, overlijden), • lijst met antwoorden op veelgestelde vragen (FAQ), • zoeken op trefwoord, • topografische ingang (de Atlas van Amsterdam), • een gepersonaliseerd domein waarin de klant volledig zelf bepaalt waarin

4 - 16



hij met name is geïnteresseerd: Mijn Amsterdam.

4.3.3

De organisatiestructuur van de gemeente Amsterdam

Model 4.5 Organisatiestructuur gemeente Amsterdam

[Bron: Adviesgroep Architectuur] stad en stadsdelen

Model 4.5 geeft een schets van de organisatie van het concern Amsterdam. Het college van B&W gaat over de ongeveer 30 diensten van de centrale stad. Een groot aantal bevoegdheden is overgedragen aan de 14 stadsdelen, hetgeen is vastgelegd in de Verordening op de stadsdelen. De niet overgedragen bevoegdheden zijn expliciet genoemd in de zogenaamde A-lijst. De Dagelijks Besturen van de stadsdelen zijn verantwoordelijk voor het aan hen gegeven mandaat op basis van deze Verordening. De Gemeenteraad en de Stadsdeelraden controleren in het huidige duale regime het college van B&W c.q. de Dagelijkse Besturen. De Raad en de Deelraden hebben het budgetrecht, dat wil zeggen dat ze de begrotingen vaststellen of wijzigen. Aan de onderkant van het plaatje staan de diensten, bedrijven en stadsdelen.

diabolo-model

Een stadsdeel is een zelfstandige organisatie van de gemeente, genoemd in de Verordening op de stadsdelen, met een eigen stadsdeelraad en stadsdeelbestuur, waarvan de grenzen territoriaal zijn aangegeven. De stadsdelen zijn ingericht volgens het diabolo-model dat in gemeenteland gebruikelijk is. De secretaris is daarbij de verbindende schakel: lid van het College en directeur van het ambtelijk apparaat. De organisatie is ingericht volgens het sectorenmodel: “hard”, “zacht”, middelen. De ICT-afdeling valt onder het sectorhoofd middelen. Het hoofd van het team heet (in de meeste gevallen) de I&A-coördinator.

wethoudersmodel

De centrale stad is, vooralsnog, ingericht volgens het wethoudersmodel. In afwijking van hetgeen gebruikelijk is bij andere gemeenten is de Gemeentesecretaris niet de hiërarchische baas van de diensttakken. De dienstdirecteuren ressorteren rechtstreeks onder een wethouder en rapporteren daaraan. 4 - 17



De Gemeentesecretaris is tevens directeur van de Bestuursdienst. De gemeentesecretaris rapporteert aan de Burgemeester. De directies van de Bestuursdienst ressorteren als staf onder de burgemeester en de wethouders. De Gemeentesecretaris heeft de opdracht gekregen om een aantal meer en minder vergaande opties met voor- en nadelen uit te werken met betrekking tot de vorming van een stads-MT. de Bestuursdienst

De Bestuursdienst is als dienst een bijzondere organisatie. Deze dienst vervult een centrale coördinerende en controlerende rol tussen het gemeentebestuur, de stadsdelen, diensten, bedrijven en servicehuizen, vooral op de beleidsterreinen financieel/fiscaal, personeel, juridisch, organisatie, informatie en huisvesting. In deze rol bewaakt de dienst op hoofdlijnen de eenheid van beleid, het proces van bestuurlijke besluitvorming, de beleidsinhoudelijke en bedrijfsmatige aansturing van de gemeentelijke organisatie.

diensten

Een dienst is een zelfstandige organisatie van de gemeente die in opdracht van het college van B&W aan burgers en bedrijven bepaalde diensten verleent, producten levert of ontwikkelingswerkzaamheden verricht, en die overwegend wordt bekostigd uit de middelen die het college van B&W en de Raad aan de dienst ter beschikking stellen.

bedrijven

Een bedrijf is een zelfstandige organisatie van de gemeente die in opdracht van het college van B&W aan burgers en bedrijven diensten verleent, producten levert of ontwikkelingswerkzaamheden verricht en daarmee eigen inkomsten genereert en die overwegend zelf zorgdraagt voor financiële dekking. Het Afval Energie Bedrijf is hiervan een voorbeeld. Dit zijn bedrijven die basisvoorzieningen leveren aan de inwoners van Amsterdam. Een aantal gemeentebedrijven is in de afgelopen jaren verzelfstandigd, zoals het energiebedrijf (Nuon), het kabelbedrijf (UPC) en het Gemeentelijk Vervoerbedrijf (GVB), omdat de gemeente deze activiteiten niet langer tot haar kerntaken rekent.

facilitaire bedrijven

Een facilitair bedrijf is een zelfstandige organisatie van de gemeente die, onder bestuur van de portefeuillehouder, facilitaire diensten verleent, producten levert of ontwikkelingswerkzaamheden verricht uitsluitend voor andere gemeentelijke organisaties (en dus niet aan derden). Voorbeeld: het Faciltair Bedrijf Amsterdam (FBA).

servicehuizen

Een servicehuis is een zelfstandige organisatie van de gemeente die, onder collegiaal bestuur van de deelnemende organisaties, facilitair diensten verleent, producten levert of ontwikkelingswerkzaamheden verricht uitsluitend voor andere gemeentelijke organisaties (en dus niet aan derden). Voorbeelden: het Servicehuis Personeel (SHP) en het Servicehuis ICT (SHI).

4 - 18



4.3.4

De organisatie van de ICT-functie

de ICT-functie

Nagenoeg alle diensten en bedrijven hebben een eigen ICT-afdeling met een hoofd ICT. Gaandeweg worden deze taken overgedragen en ondergebracht bij het Servicehuis ICT. Elke dienstdirecteur rapporteert aan de eigen wethouder, ook over ICTaangelegenheden. Daarnaast is er een coördinerend wethouder ICT die voor het concern (maar in ieder geval voor de centrale stad) de beleidskaders aangeeft en een toetsende rol heeft.

bestuurlijke gremia

Er is een bestuurlijk overleg van Burgemeester en Stadsdeelvoorzitters (het Praesidium). Daarnaast zijn er bestuurlijke overleggen van portefeuillehouders P&O, ICT, Financiën, Onderwijs & Welzijn, enzovoort. Het Bestuurlijk Overleg Informatievoorziening (BOI) is momenteel onderdeel van het stadsdeelvoorzittersoverleg.

ambtelijke gremia

Er zijn diverse ambtelijke overleggen. Het ICT-platform is het informele overleg van hoofden ICT en I&A-coördinatoren. De stadsdelen hebben daarnaast het I&A-coördinatorenoverleg.

de Cie IV

Er is sinds kort een Commissie InformatieVoorziening (Cie IV), een formeel bestuurlijk-ambtelijke adviescommissie voor alle ICT-aangelegenheden van het concern Amsterdam. Het concerndenken heeft de behoefte gecreëerd aan een platform voor alle diensttakoverstijgende ICT-aangelegenheden alsmede een voorziening om de bestuurlijke betrokkenheid te formaliseren. In deze Commissie zijn zowel stadsdelen als de centrale stad vertegenwoordigd. Formeel heeft deze Cie IV een adviserende rol aan het college van B&W en de Dagelijkse Besturen van stadsdelen, de praktijk zal echter zijn dat deze zware commissie de facto besluitvormend is.

Model 4.6 De regiefunctie op de ICT

[Bron: Adviesgroep Architectuur]

4 - 19



de SG IV

Er is verder een Stuurgroep InformatieVoorziening (SG IV), de formele ambtelijke tegenhanger van de Cie IV. Een Klankbordgroep InformatieVoorziening van ICT-materiedeskundigen completeert deze lijn. Deze SG IV voert de regie over de concernbrede ICT-ontwikkelingen en fungeert als opdrachtgever van een aantal ICT-gerelateerde programma’s, zoals de Basisregistraties & ICT-infrastructuur (BRI), de Informatie-Beveiliging (IB) en het Digitaal InformatieBeheer (DIB). Ook de Adviesgroep Architectuur valt rechtstreeks onder de SG IV.

de rollen

In zekere zin kunnen SG IV en Cie IV worden gezien als de Amsterdamse pendant van het landelijke programma De Andere Overheid. Het is zinvol de rollen te expliciteren die de verschillende partijen vervullen. Voor de diverse stuurgroepen (met uitzondering van de SG IV) is die meteen duidelijk: de aansturing van het betreffende programma.

de AA

De rol van de Adviesgroep Architectuur laat zich karakteriseren door: • het gevraagd en ongevraagd adviseren van de SG (en daarmee de Cie) IV op alle onderwerpen die een relatie met het Handboek Architectuur, waarin de samenhang in de organisatie en de informatievoorziening is weergegeven, (kunnen) hebben; • het toetsen van concernplannen en -ontwikkelingen aan het Handboek Architectuur; o.a. voor de ICT-gerelateerde programma’s als Antwoord; • de (verdere) inhoudelijke ontwikkeling van het gedachtegoed van het Handboek Architectuur.

de KB IV

De rol van de KlankBordgroep IV is: • de inhoudelijke voorbereiding van de vergaderingen van de SG (en daarmee de Cie) IV; • het adviseren op de geagendeerde onderwerpen voorzover die nog niet van een concernbrede toets zijn voorzien; • als referentiekader dienen: de doelstellingen uit het programakkoord en Beter Presteren, en het Informatiebeleidsplan.

de SG IV

De rol van de SG IV is: • het volgen en bewaken van de concernbrede ontwikkelingen op het terrein van ICT-gerelateerde organisatieontwikkelingen; de regierol; het biedt diensten, stadsdelen en programma’s een platform voor legitimering en afstemming van activiteiten en projecten; • het aansturen van ICT-gerelateerde programma’s als opdrachtgever; • de (inhoudelijke) voorbereiding van de vergaderingen van de Cie IV; • hoeder en bewaker van de O&I-kaders; als referentiekader daarbij dienen het Informatiebeleidsplan en het Handboek Architectuur.

de Cie IV

De rol van de Cie IV ten slotte is: • de borging en de bestuurlijke legitimering van de ICT-gerelateerde organisatieontwikkelingen; • het vaststellen van de plannen en de voorstellen uit de SG IV; • het creëren van draagvlak bij het bestuur van stad en stadsdelen met betrekking tot de genomen beslissingen; • het adviseren van het college van B&W en de Dagelijkse Besturen van de stadsdelen over ICT-gerelateerde organisatieontwikkelingen.

4 - 20



4.3.5 programmasturing

De veranderingsorganisatie

Voor het ontwikkelen, voorbereiden en implementeren van veranderingen werkt de gemeente met programma’s en projecten. Voor de invulling daarvan worden bestuurlijke commissies, bestuurlijke teams, stuurgroepen, programmateams, projectgroepen, werkgroepen, coördinatiegroepen, klankbordgroepen en adviesgroepen in het leven geroepen. Dit betreft in de meeste gevallen activiteiten met een tijdelijke karakter. Het onderscheid tussen programma’s en projecten is vaak nogal arbitrair. In het algemeen gelden voor programma’s de volgende kenmerken: • concern- of gemeentebrede werking, • meerjarige doorlooptijd, • doelen niet scherp omlijnd, • projecten en activiteiten worden onderweg gedefinieerd, gestart, gerealiseerd en beëindigd, • resultaten zijn nauwelijks of niet afdwingbaar. Voorbeelden van dergelijke programma’s zijn: Dienstverlening, Handhaving & Regelgeving en BasisRegistraties & ICT-infrastructuur (BRI). De programma’s, en soms ook grote projecten, worden in de loop der tijd qua samenstelling en structuur regelmatig aangepast aan de omstandigheden. 4.3.6

Opdrachtgeverschap en opdrachtnemerschap

PM wordt later uitgewerkt. 4.3.7

De organisatie van de mid office

Model 4.7 Organisatietypologie volgens EGEM: front-, miden back office

[Bron: EGEM] Ook EGEM hanteert het onderscheid in front office, mid office en back office.

4 - 21


ontwikkeling


In de navolgende afbeeldingen is de visie van EGEM op de ontwikkeling van het mid office gegeven.

Model 4.8 Stap 0: de uitgangssituatie

[Bron: EGEM] EGEM onderscheidt in het veranderingsproces drie stappen waarin de organisatie(s) zich aanpassen en zich voorbereiden op de gewenste situatie. Uiteindelijk groeien gemeenten in de visie van EGEM toe naar een mid office dat met name technisch is. Dit gaat via een tussenstap met een tijdelijk organisatorisch mid office.

Model 4.9 Stap 1: de gemeente na één-loket en multichannel

[Bron: EGEM]

4 - 22



Model 4.10 Stap 2: de organisatorische mid office als tijdelijke oplossing

[Bron: EGEM] het Antwoord

Het huidige Amsterdamse contact center Antwoord is een voorbeeld van zo’n tijdelijke constructie. In Antwoord bevinden zich naast front office- ook mid office-functies, bijvoorbeeld de kennisbank voor de beantwoording van standaard (telefonische) vragen; voor specifiekere vragen wordt er doorverbonden met de back office. Deze constructie is tijdelijk omdat de informatie-uitwisseling tussen back office en mid office geautomatiseerd kan worden. Pas als dat gebeurt, ontstaat het voorlopige eindbeeld: het technische mid office waarin alle informatie van alle werkprocessen toegankelijk is. Het toekomstige contact center gaat net als de buitenwereld het elektronisch loket gebruiken.

Model 4.11 Stap 3: de technische mid office als eindoplossing

[Bron: EGEM] 4.3.8 samenwerking

De organisatie van de gemeenschappelijke voorzieningen

Een van de kernboodschappen van de architectuur is dat we meer moeten samenwerken en meer gemeenschappelijk moeten gaan doen. Dit geldt voor zowel de proces-, informatie-, applicatie- als infrastructuurarchitectuur. Om dit succesvol te kunnen doen zal ook de organisatiearchitectuur hierop ingericht moeten worden in termen van structuren, rollen en verantwoordelijkheden, mensen, middelen en cultuur.

4 - 23



randvoorwaarden

Hoe en in welke mate we de gemeenschappelijkheid moeten gaan organiseren is een belangrijke vraag voor het management. De leden van de Adviesgroep Architectuur constateren in elk geval het volgende: 1. er zijn eerste stappen gezet op het terrein van de gemeenschappelijkheid, 2. maar de organisatorische randvoorwaarden voor het implementeren van deze architectuur zijn anno 2007 nog onvoldoende ingevuld.

1. het begin is er

Concernsamenwerking op het gebied van ICT is nog jong en sterk in ontwikkeling. De afgelopen jaren is een start gemaakt met gemeenschappelijk beleid, gemeenschappelijke ontwikkeling en gemeenschappelijk beheer rond ICT. Een aantal illustraties.

beleid

Het gemeenschappelijke beleid ligt vast in drie in november 2004 door B&W vastgestelde beleidsnotities: • het Statuut van de Informatievoorziening, • de nota Standaarden, • het Beleid voor Grote ICT-projecten. Daarnaast is het beveiligingsbeleid vastgelegd in de Gemeentelijke InformatieBeveiligingsNorm, de GIBN. In 2007 komt er een gemeentelijk Informatiebeleidsplan en wordt het privacybeleid en het beleid grote ICT projecten herijkt.

beheer

Er is een aantal initiatieven rond beheer. Zo ondersteunt het Servicehuis ICT (SHI) diensten en stadsdelen in de uitvoering van beheer en hanteert daarbij de in dit handboek beschreven beheermodellen. De afdeling e-Government onderdeel van het SHI voert belangrijke onderdelen uit van het functioneel beheer van een portfolio aan presentatievoorzieningen en de afdeling E-net Regie is verantwoordelijk voor het beheer van de datacommunicatie infrastructuur.

2. randvoorwaarden

De organisatorische randvoorwaarden voor implementatie zijn nog onvoldoende ingericht. Dit betreft niet alleen de structurele inbedding van gemeenschappelijk beleid, ontwikkeling en beheer. Ook op korte termijn is de huidige organisatie (in termen van structuren, mensen en middelen) niet ingericht om snel te starten met de implementatie van deze architectuur. PM Dit punt wordt in 2007 nog verder uitgewerkt door de Adviesgroep Architectuur in een aparte notitie. In volgende versies van dit Handboek zal dit aspect verder moeten worden uitgewerkt.

4 - 24



4.4

Standaarden

In deze paragraaf vindt u –naast specifieke standaarden voor de organisatiearchitectuur- ook een aantal meer algemene richtlijnen voor de architectuur 4.4.1

Tabel 4.1 Richtlijnen organisatiearchitectuur

Richtlijnen

1. Amsterdam volgt landelijke standaarden en doet mee aan landelijke initiatieven in het kader van de elektronische overheid 2. Amsterdam volgt de Nederlandse Overheids Referentie Architectuur (NORA) en de insteek van een servicegerichte architectuur 3. Wanneer het concern, een dienst, een bedrijf of een stadsdeel wil afwijken van een landelijke of gemeentelijke standaard, geldt het principe van de ‘omgekeerde bewijslast’: men moet aantonen dat het noodzakelijk is af te wijken. 4.4.2

Uniforme standaarden

In onderstaande tabel zijn de uniforme standaarden opgenomen die gelden binnen de organisatiearchitectuur. Tabel 4.2

Nr. en naam standaard

Toelichting

Bron

Uniforme standaarden organisatiearchitectuur

ASL

Beheerstandaard voor applicatie beheer.

Voorstel Adviesgroep Architectuur

BISL

Beheerstandaard voor functioneel beheer.

GIBN

Gemeentelijke InformatiebeveiligingNorm gebaseerd op de landelijke Code voor Informatiebeveiliging

Voorstel Adviesgroep Architectuur GIBN: B&W besluit 18 juni 2002 Update GIBN 2005: B&W besluit 5 april 2005


Het Handboek Architectuur en de bijlagen zijn standaarden voor de gemeenschappelijke informatievoorziening en ICT beschreven.


ITIL

Beheerstandaard voor technisch beheer.


Programma Antwoord

Antwoord is het Front office van de gemeente voor telefonie en internet.

B&W besluit 11-2004. Instemming gemeenteraad 15-122004, gemeenteraad 13-04-2005, aansluiting stadsdelen. Notitie ‘Van ongeduld naar actie’, Asscher, Van Poelgeest, B&W

4 - 25



11-07-2006 Programma BRI

Ontsluiting van de basisregistraties naar alle gemeentelijke organisaties

B&W besluit, 08-032005 en instemming gemeenteraad 22-062005. B&W besluit, 11-072006, Notitie ‘Van ongeduld naar actie’, Asscher, Van 10 Poelgeest

Servicehuis ICT

Het Servicehuis ICT is de gemeentelijke organisatie voor ICT ondersteuning (technisch en functioneel beheer en ontwikkeling).

B&W besluit, 08-032005 en instemming gemeenteraad 22-062005. B&W besluit, 11-072006, Notitie ‘Van ongeduld naar actie’, Asscher, Van 11 Poelgeest

Servicehuis Personeel

Het Servicehuis Personeel ondersteunt alle gemeentelijke organisaties bij het uitvoeren van personeelsbeheer

B&W besluit, 29-112005.

4.4.3

Bandbreedte standaarden

Er gelden geen standaarden op het niveau ‘bandbreedte’.

4.4.4

Afspraken

Er gelden geen standaarden op het niveau ‘afspraken’.

10 11

Programma BRI is de standaard voor de centrale stad. Stadsdelen worden uitgenodigd om mee te doen. Servicehuis ICT is de standaard voor de centrale stad. Stadsdelen worden uitgenodigd om mee te doen.

4 - 26



4.5

Beheer

Nr. en naam model

Eigenaar

Beheerder

Model 4.1 Belangrijkste

Stuurgroep Informatievoorziening

CO CO

landelijke initiatieven


Model 4.3

Burger@Overheid

Burger@Overheid

Programma Dienstverlening



CO

partners van de gemeente Model 4.2 Belangrijkste

BurgerServiceCode Model 4.4 Thematische indeling diensten en producten Model 4.5 Organisatiestructuur gemeente Amsterdam Model 4.6 De regie-functie op de ICT


CO

Tabel 4.3 Beheer modellen

Model 4.7

EGEM

EGEM

EGEM

EGEM

EGEM

EGEM

EGEM

EGEM

EGEM

EGEM

Organisatietypologie volgens EGEM: front-, miden back office Model 4.8 Stap 0: de uitgangssituatie Model 4.9 Stap 1: de gemeente na één-loket en multichannel Model 4.10 Stap 2: de organisatorische mid office als tijdelijke oplossing Model 4.11 Stap 3: de technische mid office als eindoplossing

4 - 27


Tabel 4.4 Beheer standaarden

12



Eigenaar / beslisser

Beheerder

ASL

SHI

ASLFoundation

BISL


ASLFoundation

GIBN

Stuurgroep 12 Informatievoorziening

CO/Informatiebeleid



Adviesgroep Architectuur

ITIL

SHI

Office of Government Commerce (UK)

Programma Antwoord

Stuurgroep Dienstverlening

Stuurgroep Dienstverlening

Programma BRI

Stuurgroep BRI

Stuurgroep BRI

Servicehuis ICT

Raad van Deelnemers Servicehuis ICT

Dagelijks Bestuur Servicehuis ICT

Servicehuis Personeel

Raad van Deelnemers Servicehuis Personeel

Dagelijks Bestuur Servicehuis Personeel

Personele functiegebouw

?

Concern Organisatie

De GIBN is in 2002 vastgesteld door het college van B&W, maar het lijkt logisch dat de Stuurgroep Informatievoorziening in de toekomst beslist over wijzigingen en daarmee ook eigenaar/beslisser wordt.

4 - 28



4.6

Beveiliging

4.6.1

GIBN

In onderstaande tabel zijn de relevante paragrafen uit de Gemeentelijke Informatiebeveiligingsnorm (GIBN, versie 2.0 april 2005) voor de organisatiearchitectuur opgenomen. De GIBN is in 2002 vastgesteld door het het college van B&W en in 2005 is een update vastgesteld. De GIBN geldt voor diensten en bedrijven en geldt ook voor de stadsdelen. Nr. GIBNparagraaf 2.1 2.2 2.3 3.1 3.2 3.4

Tabel 4-5 Relevante paragrafen GIBN

3.5 5.1 5.2 5.3 5.4 5.5 5.6 6.1 6.2 6.7 6.9 7.3 7.5 8.1 10.5 11.1 11.2 4.6.2

Titel paragraaf Beleidsdocument voor informatiebeveiliging Informatiebeveiligingsplan Aanvullende maatregelen Verantwoordelijksheidsniveaus binnen het concern Amsterdam Toewijzing verantwoordelijkheid voor informatiebeveiliging Verantwoordelijkheden diensttakoverstijgende (informatie)systemen (DOIS) Contracten met derden Voorwaarden tewerkstelling vast personeel Voorwaarden tewerkstelling tijdelijk personeel Kwetsbare functies Bevoegdheden personeel Huisregels Opleiding en communicatie Toegangsbeheersing vestiging(en) Servicetaken Clear desk en clear screen beleid Telewerken Bescherming programmatuur en gegevens Netwerkbeheer Gedocumenteerd beleid voor toegangsbeveiliging Uitbesteding ontwikkeling van (informatie)systemen Naleving van informatiebeveiligingsbeleid en –plan Naleving van wettelijke voorschriften

Aanvullingen op de GIBN

De GIBN is gericht op organisaties en doet geen uitspraken over de informatiebeveiliging rond organisatie overstijgende gemeenschappelijke voorzieningen. PM Verdere uitwerking vindt nog plaats in samenwerking het Platform Informatiebeveiliging.

4 - 29



4.7

Conclusies

1. Amsterdam wil een Andere Overheid worden, dat wil zeggen een overheid die …. • niet naar de bekende weg vraagt; • klantgericht is; • zich niet voor de gek laat houden; • weet waar ze het over heeft en • haar zaken op orde heeft en niet meer uitgeeft dan nodig is. 2. Amsterdam onderschrijft de Burger Service Code en handelt ernaar. 3. Bij de inrichting van de organisatie hanteren we het onderscheid tussen front-, miden back office. 4. De vernieuwing van de organisatiearchitectuur voltrekt zich langs drie lijnen: • een verdere professionalisering van de digitale front office; • de inrichting van een mid office; • de ontwikkeling en het beheer van de gemeenschappelijke voorzieningen.

conclusies organisatiearchitectuur

5. De Amsterdamse front office wordt verder geprofessionaliseerd door toepassing van de principes van channel management en customer self service. Dit impliceert dat er substitutie wordt gestimuleerd van dure, analoge dienstverlening naar goedkopere digitale dienstverlening. 6. In Amsterdam moet een mid office worden ontwikkeld. Er moeten richtinggevende besluiten genomen worden over het precieze ontwikkelpad en de inrichting ervan, o.a. de verhouding tussen een technisch en een organisatorisch mid office. 7. De organisatie rond gemeenschappelijke ontwikkeling en beheer is, ondanks een aantal eerste stappen, anno 2007 nog onvoldoende ingericht. Dat geldt ook voor de financiering. 8. De Stuurgroep en de Commissie InformatieVoorziening zijn hét gremium voor besluitvorming over concernbrede informatievoorziening en ICT (inclusief deze architectuur). 9. Amsterdam volgt landelijke standaarden en doet mee aan landelijke initiatieven in het kader van de elektronische overheid. 10. De programma’s BRI, Antwoord en Servicehuis ICT zijn (de facto) de verplichte standaard of zullen deze leveren (voorzover die standaarden nog in ontwikkeling zijn) voor de centrale stad. Stadsdelen zijn uitgenodigd zich aan te sluiten. 11. Alle diensten, bedrijven en stadsdelen conformeren zich aan (de standaarden in) deze architectuur. Bij afwijking geldt het principe van de ‘omgekeerde bewijslast’.

4 - 30



5

Procesarchitectuur

5.1

Inleiding

beter presteren

In dit hoofdstuk gaat het over de processen in de organisatie. De ontwikkeling naar een Andere Overheid die Beter wil Presteren veronderstelt een vergaand herontwerp van de primaire processen. Kernbegrippen daarbij zijn: van buiten naar binnen denken, ketenbenadering, modulariteit, flexibiliteit en wendbaarheid van de organisatie(onderdelen).

process redesign

Recentelijk is een indeling in een zestal hoofdprocessen in zwang geraakt: dienstverlenen, regelgeven & handhaven, ontwikkelen & ordenen, beheren, besturen en ondersteunen. Dit hoogste abstractieniveau in het procesdenken, gedocumenteerd in zogenoemde (hoofd)procesplaten, moet stapsgewijs worden uiteengerafeld en vertaald in detailschema’s en concrete werkinstructies. En daarbij hoort ook de benodigde aanpassing van de informatievoorziening en de ICT. Zover zijn we echter nog lang niet: er is heel weinig concreet materiaal beschikbaar. Maar een goede procesarchitectuur is buitengewoon belangrijk voor de realisatie van de bestuurlijke ambities. In dit hoofdstuk wordt een raamwerk en een ontwikkelrichting gegeven. In paragraaf 5.3 staat een eerste exercitie voor het hoofdproces dienstverlenen.

5-1



processturing

De sturing op processen is in Amsterdam het leidende principe aan het worden bij de innovatie en de ontwikkeling van de organisatie. In navolging daarvan laat ook het architectuurmodel met de vijf lagen zich het best begrijpen als de redenering start vanuit de primaire processen (laag 2). Het herontwerp van het proces is enerzijds de basis voor de (verdere) vormgeving van de organisatie (laag 1: front office, mid office, multichannel) en anderzijds het aanknopingspunt voor de inrichting van de informatievoorziening (laag 3: basisregistraties, kernadministraties, klanten zaakdossier) en de doorvertaling naar de ICT-lagen daaronder.

servicegericht

In de procesarchitectuur is een onmiskenbare trend aanwezig om het ontwerp te baseren op afgebakende deelproducten, deelprocessen of deeldiensten: de zogenoemde services. Een service is een afgerond pakket van activiteiten dat door een bepaalde organisatie wordt uitgevoerd en waarvan het resultaat door een andere organisatie kan worden opgepikt ter vervulling van de eigen functie. Een dergelijke Service Gerichte Architectuur (SGA) is door deze modulariteit veel flexibeler en makkelijker te onderhouden.

wendbaarheid

Het startpunt van een vernieuwende, toekomstgerichte architectuur is het bestaan van een behoefte. Een van de bepalende behoeftes is de mogelijkheid om in de toekomst sneller te kunnen inspelen op veranderingen. Alleen een nieuwe architectuur neerzetten is niet genoeg, een continu proces van breed ingestoken verbeteringen is de toekomst. De organisatorische aspecten van deze SGA hebben een tegenhanger in de techniek: de ICT wordt steeds meer modulair, gestandaardiseerd en webbased. Een service definiëren we daarom als “het resultaat van een afgeronde inspanning die een ambtenaar of applicatie op basis van wettelijke taken of onderling gemaakte afspraken levert en waarmee in een behoefte van een of meer andere ambtenaren of applicaties wordt voorzien.”

ketenbenadering

5-2

Hiermee is ook de kern gegeven van wat ketensamenwerking of een ketenproces wordt genoemd: niet langer denken vanuit de verticale kokers, maar een horizontale resultaat- en klantgerichte benadering. Organisaties maken onderling afspraken om elkaar te helpen met het verlenen van diensten aan burgers en bedrijven. De onderlinge hulp bestaat uit services: elke organisatie levert vanuit zijn kernfunctie services aan andere organisaties. De organisatie die als eerste en laatste schakel in deze keten van dienstverlening optreedt, kan op basis van een reeks services het uiteindelijke product of de dienst leveren.



ketenregie

Deze tendens naar modulariteit en specialisatie heeft een nieuw probleem aan de orde gesteld: wie voert de regie over de gehele keten? En om te kunnen regisseren is overdracht en gezamenlijk gebruik van informatie vereist.

digitalisering

En ten slotte komt in dit hoofdstuk een aantal trendmatige ontwikkelingen op het gebied van de werkprocessen ter sprake: de toenemende digitalisering van zowel document als workflow. Van out of process naar in process. 5.1.1

Denken in processen

In een model van de NORA wordt het abstracte “proces” via een stapsgewijze decompositie afgepeld tot op het concrete niveau van de enkelvoudige handeling: ketenproces

is een geordende reeks bedrijfsprocessen die doorverschillende organisaties wordt uitgevoerd met als doel om via één organisatie een (combinatie van) dienst(en) te leveren aan een burger of een bedrijf;

bedrijfsproces

is een geordende reeks werkprocessen die binnen één organisatie wordt uitgevoerd met als doel om een (combinatie van) dienst(en) te leveren aan een burger, bedrijf of een andere organisatie;

werkproces

is een geordende reeks van processtappen die binnen één organisatorische eenheid in een organisatie worden uitgevoerd met als doel een specifieke bijdrage (prestatie) te leveren aan een dienst die uiteindelijk wordt geleverd aan een burger, een bedrijf of een andere organisatie;

processtap

is een geordende reeks handelingen die ononderbroken wordt uitgevoerd door één mens of machine binnen één bedrijfsfunctie;

handeling

is de kleinst mogelijke eenheid van werk, uitgevoerd door één persoon of machine op één plek op één moment (eenheid van tijd, plaats en handeling).

In Amsterdam is er, ter aanvulling op dit model, nog een andere manier van kijken, het denken in hoofdprocessen: hoofdproces

methodisch kader

is een van de verschillende gezichten die de gemeente heeft voor de burger: klant (dienst-verlenen), onderdaan (regelgeven & handhaven), gebruiker van de openbare ruimte (beheren), partner (ontwikkelen & ordenen); daarnaast: besturen en ondersteunen.

Processen bestaan in hun eenvoudigste vorm dus uit elkaar opvolgende handelingen. Bijvoorbeeld: vul in dit vakje de voorkeur van de cliënt in. Het resultaat van de afzonderlijke handeling is vooraf bekend. De handelingen

5-3



kunnen worden uitgevoerd door mensen of door computers. Door het clusteren van handelingen ontstaan processtappen. Bijvoorbeeld: vul het formulier en de juiste bijlagen in. Door het bundelen van processtappen ontstaan werkprocessen. Bijvoorbeeld: beoordeel het recht op een subsidie voor cliënt X. Op het hoogste niveau van afzonderlijke organisaties spreken we over bedrijfsprocessen. Bijvoorbeeld: het bedrijfsproces van de Informatie Beheer Groep is het toekennen van studiefinanciering. Wanneer organisaties samenwerken kunnen we spreken van ketenprocessen. Bijvoorbeeld: het aan het werk helpen van iemand door CWI, UWV en Reïntegratiebedrijf. Door processen op deze wijze in samenhangende componenten te delen, ontstaat een belangrijk methodisch kader voor de procesarchitectuur. In paragraaf 5.3.1 is een voorbeeld uitgewerkt. 5.1.2

Servicegerichtheid

diensten

Alle hoofdprocessen zijn er op de een of andere manier op gericht om uiteindelijk een dienst als output te leveren. In deze architectuur wordt (net als in de NORA) de term ‘diensten’ gereserveerd voor “het resultaat van een afgeronde inspanning die de overheid op basis van wettelijke taken heeft geleverd waarmee in een behoefte van een burger of bedrijf wordt voorzien of op een gebeurtenis wordt gereageerd”. Het resultaat kan een product zijn.

services

Meer en meer worden diensten niet slechts door één organisatie geleverd, maar werken meerdere (overheids)organisaties samen om uiteindelijk één dienst 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 deze architectuur, conform de eerdere definitie, services genoemd. In nevenstaand model is dat met een eenvoudig voorbeeld aangegeven. De dienst (of het eindproduct) die aan de burger of het bedrijf verleend wordt, kan opgebouwd zijn uit onderliggende services, zonder dat de klant daar iets van merkt. In het voorbeeld is elke organisatie ideaaltypisch ingericht volgens front-, miden back office.

5-4



de samenhang

Vervolgens wordt een uitvergroting van dit plaatje gemaakt om de samenhang aan te geven tussen enerzijds diensten, producten en services en anderzijds de eerdere decompositie in keten-, bedrijfs- en werkprocessen. Het onderstaande model vereist enige studie maar kan verhelderend werken.

services in de keten

In het model wordt een dienst (of eindproduct) geleverd als resultaat van het ketenproces van de drie organisaties A, B en C. In de legenda staat dit aangegeven met een viertal diagonale streepjes in de benedenhoek. Elk van de drie organisaties heeft haar eigen bedrijfsproces, aangeduid met drie streepjes in de hoek. Op hun beurt zijn de bedrijfsprocessen opgebouwd uit werkprocessen, aangeduid met twee streepjes. De werkprocessen van de organisaties B en C leveren een aandeel of bijdrage, een service, aan de totstandkoming van de dienst die uiteindelijk door organisatie A wordt geleverd. In de processtappen (één streepje) worden tussentijdse contacten gelegd en interne leveranties aangevraagd c.q. verstrekt. Services zijn er op alle niveaus. In het voorbeeld leveren organisaties B en C een substantiële bijdrage aan de uiteindelijke dienst door echte tussenproducten te verstrekken. Maar een service kan ook in een detail zitten, bijvoorbeeld een gegevensverstrekking uit een basisregistratie, of in een simpele generieke functie, bijvoorbeeld de afhandeling van een elektronische betaling. 5.1.3

klantgerichtheid

Ketenbenadering

Met de begrippen ketenproces en ketenbenadering wordt de noodzaak aangegeven niet langer te denken vanuit de verticale kokers, maar een horizontale resultaat- en klantgerichte benadering na te streven. Kenmerkend voor een ketenproces is het afdelings- of organisatieoverstijgende karakter. Niet de inspanning van een (deel)organisatie is leidend, het gaat om het

5-5



eindresultaat van de totale (keten)dienstverlening aan de klant. Ketenpartners kunnen dus de medewerkers zijn van een andere organisatie, maar ook de collega’s van een andere afdeling, dienst of stadsdeel. informatie en regie

In deze ketenbenadering zijn twee aspecten van belang: de overdracht of het gezamenlijk gebruik van informatie en de mogelijkheid de gehele keten te regisseren en te bewaken.

één dossier

In de eerste plaats is de uitwisseling en de overdracht van informatie tussen de verschillende ketenpartners, tijdens maar ook na afloop van een (deel)proces, essentieel. Dat pleit voor het aanleggen van één klant- of zaakdossier waarin alle relevante gegevens worden ondergebracht en waaruit elke geautoriseerde partij kan putten op het moment dat dat nodig is. Het zaakdossier als een kernadministratie. Zie hiervoor hoofdstuk 6.

eindverantwoordelijk

In de tweede plaats moet er regie gevoerd kunnen worden over de subtrajecten van de ketenpartners heen. Dat vereist allereerst een instantie die dat doet, maar verder gaat het wederom om de beschikbaarheid van informatie om te kunnen monitoren en volgen, zowel op het niveau van het individu als van de doelgroep(en).

scenario’s

Met name op overdrachtspunten tussen organisaties moeten er goede afspraken zijn over wat er aan informatie en verantwoordelijkheden wordt overgedragen. Hier voor zijn meerdere oplossingen denkbaar.

5-6

•

Leverancier van de dienst is de regisseur. De organisatie die de dienst levert, voert de regie. Dit betreft dan ook de regie over de levering van services vanuit andere organisaties.

•

Overdracht van regie. De organisatie die de dienst levert, draagt de verantwoordelijkheid voor (delen van) de uitvoering die door andere



organisaties wordt gedaan, ook – al dan niet tijdelijk – over aan die andere organisaties. •

Een gezamenlijke regie-organisatie. Alle organisaties binnen een samenwerkingsverband richten gezamenlijk een regie-organisatie in. Deze voert dan dus de feitelijke procesregie over de keten.

Het bovenstaande model geeft een beeld van de drie genoemde vormen van ketenbesturing. Het laat zien dat de procesarchitectuur weer rechtstreeks gekoppeld is aan de organisatiearchitectuur. In de NORA wordt een expliciet voorkeur uitgesproken voor de eerste vorm: “Als gevolg van de hoge prioriteit die aan de kwaliteit van de dienstverlening wordt gegeven, is het verstandig de organisatie die de dienst aan burger en bedrijf levert, verantwoordelijk te maken voor het functioneren van de gehele keten, die nodig is om de dienst te kunnen leveren. Dit impliceert dat deze organisaties in beginsel per dienst dergelijke ketenafspraken zullen maken, maar uiteraard zal bundeling van ketenafspraken voor de hand liggen. Dat wil zeggen: de eindverantwoordelijke organisatie kan in één bestuurlijke overeenkomst met meerdere overheidsorganisaties afspraken maken voor een groot aantal services.” 5.1.4

Digitalisering van document en workflow

drie digitale trends

Er is een aantal trendmatige ontwikkelingen op het gebied van de werkprocessen waarneembaar die vooral van invloed zijn op het domein van de digitale duurzaamheid en de documentaire informatievoorziening. Het gaat hierbij met name om de toenemende digitalisering van twee aspecten van het proces: het document en de workflow. Hieronder wordt deze ontwikkeling, voor het betere inzicht, in drie afzonderlijke trends beschreven maar er is sprake van een sterke inhoudelijke relatie.

1. werk in uitvoering

De eerste trend luidt: van out of process naar in process (een typering van prof. Wouter Keller). Of in hedendaags Nederlands: van “werk uit handen” naar “werk in uitvoering” (typering van schrijver dezes). Het gaat hier om de verschuiving die plaatsvindt van activiteiten, die in eerdere fases van ontwikkeling buiten het eigen werkproces plaatsvonden, naar de werkplek en de uitvoerende zelf.

exit typekamer

Het beste voorbeeld ter illustratie is de ontwikkeling van de tekstverwerking. In vroegere tijden moest een werkproces, dat vaak uit meerdere deelprocessen bestaat, tijdelijk worden onderbroken omdat een deel van het werk, het uittypen van in klad gemaakte aantekeningen of het concept van een brief, door een ander organisatieonderdeel, de typekamer, moest worden uitgevoerd. De draad werd pas weer opgepakt als het resultaat op papier terugkwam bij de proceseigenaar. De komst van computers en tekstverwerkers heeft aan deze praktijk een definitief einde gemaakt: iedere professional typt nu zelf zijn tekst als integraal onderdeel van zijn werk.

5-7



VAN: werk uit handen

NAAR: werk in uitvoering

De trend is nu dat langzamerhand meer activiteiten onderdeel gaan uitmaken van het eigen werkproces. De lezer kan zijn of haar eigen begrip van deze materie testen door na te gaan in hoeverre de volgende deelprocessen (nog) out of process zijn of reeds geïntegreerd: telefoneren (inmiddels volledig in process), mobiel telefoneren (nooit out of process geweest), webpublicatie (nog nagenoeg volledig out), postregistratie (out), internet-gebruik (in), DIV (out), archiveren (out), agenderen (raakt in), vergaderen (nog steeds out). De trend is nu dat langzamerhand meer activiteiten onderdeel gaan uitmaken van het eigen werkproces. De lezer kan zijn of haar eigen begrip van deze materie testen door na te gaan in hoeverre de volgende deelprocessen (nog) out of process zijn of reeds geïntegreerd: telefoneren (inmiddels volledig in process), mobiel telefoneren (nooit out of process geweest), webpublicatie (nog nagenoeg volledig out), postregistratie (out), internet-gebruik (in), DIV (out), archiveren (out), agenderen (raakt in), vergaderen (nog steeds out).

2. digitaal doorgeven

De tweede trend is dat de “estafette van papier” plaatsmaakt voor een “digitaal doorgeefluik”. In onderstaande afbeeldingen is wederom een werkproces geschetst in een viertal deelprocessen. Bijvoorbeeld: aanvraag, behandeling, beslissing, uitkering. Of: beleidsvoorbereiding, behandeling in B&W, behandeling in de Commissie, behandeling in de Raad. VAN: estafette van papier

5-8



NAAR: digitaal doorgeefluik

Was het ooit zo dat het werk aan elkaar werd doorgegeven met behulp van het fysieke, papieren dossier, tegenwoordig is nagenoeg elke overdracht digitaal. Of huiselijker: de volgende collega ging pas aan het werk als het fysieke dossier daadwerkelijk op zijn bureau of in zijn IN-bakje belandde. Het dossier was tevens de werkimpuls. Gaandeweg werd het dossier steeds meer digitaal en lag het voor de hand de collega ook een elektronische kopie te zenden. Eerst gebeurde dat nog parallel, én een papieren dossier én een digitale versie, heel gebruikelijk is nu alleen de laatste methode van overdracht. Een papieren afdruk wordt nog steeds gemaakt maar die is voor eigen gebruik. Het elektronische document wordt leidend. De digitale infrastructuur die dit mogelijk maakt, kan natuurlijk nog veel meer. Ook de bewaking van het proces, de voortgang, de signalering van de werkvoorraad, de beheersing van de workflow, de computer is daar uitermate geschikt voor. De trend is dus een toenemende digitalisering van het document, van de werkimpuls en van de workflow. 3. alles voor elkaar

De derde trend laat zich kenmerken door de verschuiving van “ieder voor zich” naar “alles voor elkaar”. De eigenaar van de eerste processtap maakt een digitaal document aan, bewaart dit op zijn eigen harde schijf (C:) en stuurt een kopie door aan de collega die de volgende stap moet maken. Voor eigen gebruik wordt natuurlijk een papieren afdruk bewaard van het betreffende stuk. De collega gaat ermee aan de slag, brengt een paar wijzigingen of aanvullingen aan in het document, slaat de nieuwe versie op op de eigen harde schijf en geeft het dossier wederom door aan de volgende. En even een afdrukje voor het eigen archief. Aan het eind van het gehele proces bestaan er van het document talloze versies, zowel op papier als digitaal. De toenemende digitalisering brengt een geheel nieuw probleem met zich mee: het versiebeheer. VAN: ieder voor zich

5-9



NAAR: alles voor elkaar

Versiebeheer

Daar hebben we het volgende op gevonden. Aangezien toch iedereen op hetzelfde netwerk is aangesloten (via LAN, WAN of internet), wordt van meet af aan het document op een gedeelde netwerkschijf (F:) aangemaakt waarbij een handige applicatie zorgdraagt voor het beheer van de versies: oorspronkelijke eigenaar, datum concept, datum eerste wijziging, naam bewerker, enzovoort. Zo kan iedereen erbij en weet je altijd wat de laatste versie van het document is. Als we deze drie trends nu samen nemen (zoals in Andreas is gebeurd) en beoordelen op de consequenties hiervan voor de documentaire informatievoorziening (DIV) en de archivering, dan ontstaat het volgende beeld.

Het digitale entrepot

5 - 10

Het archief is van oudsher ingericht als allerlaatste schakel van elk proces: vijf jaar dynamisch, daarna statisch archief. De archiefdiensten hebben naast het klassieke papieren depot inmiddels voorzieningen getroffen om ook digitale opslagmedia te bewaren, het digitale depot, maar uit de illustratie hierboven komt duidelijk de samenvattende trend naar voren: de archieffunctie verschuift van “aan het eind” naar “meteen al en gaandeweg”, een digitaal entrepot. Kenners zullen opmerken dat de archieffunctie blijkbaar vroeg of laat geïntegreerd zal raken in het primaire proces (in process).



5.2

Grondslagen

grondslag 2.1

Processen worden ingericht als onderdeel van complete ketens. Deze zijn ontworpen vanuit de behoefte van burgers, bedrijven en overige belanghebbenden in de samenleving.

grondslag 2.2

Vergelijkbare processen worden in Amsterdam op één en dezelfde wijze beschreven en ingericht.

5 - 11



5.3 ateliers

In aparte bijeenkomsten, de zogenoemde organisatieateliers, worden de (hoofd)processen opnieuw ontworpen. Dat begint met een inrichting op het hoogste abstractieniveau: de (hoofd)procesplaat. Er is nog weinig concreet materiaal beschikbaar. 5.3.1

procesplaat

Modellen

Het hoofdproces Dienstverlening

Onderstaande afbeelding voldoet weliswaar niet helemaal aan die specificaties maar is een goede illustratie van het hoofdproces dienstverlenen.

Model 5.1: Hoofdprocesplaat van Diesntverlening

[Bron: Programma Dienstverlening] processchema

5 - 12

Mede op grond van dit plaatje kunnen we een meer formeel schema maken van het bedrijfsproces. Elke dienstverlening begint met het te woord staan van de klant, de aanvraag wordt op de een of andere manier geregistreerd en het verzoek wordt in behandeling genomen. Vaak zal er sprake zijn van een beoordelingsof beslissingsmoment in de procedure en als alles goed gaat wordt het gevraagde op tijd en naar tevredenheid van de klant geleverd. Dat laatste, de bewaking van de voortgang van het proces, de regie op de keten, is cruciaal voor de klanttevredenheid. Dit processchema kan van toepassing zijn op nagenoeg alle gemeentelijke dienstverlening. Uit de ordening van de stapjes blijkt een voorkeur voor een indeling naar activiteiten die rechtstreeks met het klantcontact te maken hebben (front office), die door de vakspecialisten worden uitgevoerd (back office) en die de koppeling en afstemming tussen beide verzorgen (mid office).



detailschema’s

Op elk van de deelprocessen kan nader ingezoomd worden. Door dat voor elk onderdeel te doen kan het proces volledig worden uitgedetailleerd. Het NORAdecompositiemodel kan gebruikt worden om deze detaillering te structureren. Het bedrijfsproces uit het voorbeeld bestaat uit vijf werkprocessen: aanvragen, behandelen, beslissen, leveren en bewaken. In het werkproces aanvragen zitten drie processtappen: classificeren, registreren en assisteren. Het classificeren van de klantvraag bestaat ten slotte uit een aantal handelingen: identificeren, aanvullen klantbeeld en voorsorteren.

proces & informatie

Merk op dat in deze detailschema’s ook wordt aangegeven welke gegevens benodigd zijn bij een procesonderdeel. Daarmee wordt de verbinding gelegd tussen de proceslaag en de informatielaag. Hieronder nog twee voorbeelden: het assisteren van de klant en het registreren van de zaak.

EGEM

Over deze detailschema’s wordt goed nagedacht in EGEM-verband. Amsterdam volgt deze uitwerkingen en draagt daar ook aan bij.

5 - 13



5.3.2

Regelgeven en Handhaven

Vanuit het kernteam Beter Presteren zijn er nog geen procesmodellen beschikbaar voor dit proces. Dit moet in een volgende versie van deze architectuur worden opgenomen. 5.3.3

Ontwikkelen en ordenen


Beheren


Besturen


Ondersteunen

Vanuit het kernteam Beter Presteren zijn er nog geen procesmodellen beschikbaar voor dit proces. Dit moet in een volgende versie van deze architectuur worden opgenomen.

5 - 14


Tabel 5.1 Richtlijnen procesarchitectuur


5.4

Standaarden

5.4.1

Richtlijnen

De volgende richtlijnen uit NORA worden door de gemeente Amsterdam in elk geval overgenomen 13 1. Processen zijn zo ontworpen dat ze via services koppelbaar zijn. 2. 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. 3. De procesarchitectuur is gebaseerd op de volgende decompositie: hoofdproces, ketenproces, bedrijfsproces, werkproces, processtap of handeling. 4. De besturing van ketenprocessen wordt gelegd bij de organisatie die de eindverantwoordelijkheid heeft voor het leveren van de dienst aan de burger of het bedrijf. 5. Een bedrijfsproces is opgesplitst in een invoer-, een verwerkings- en een uitvoerproces (zie kader). 6. Processen dienen te worden beschreven op basis van algemeen geaccepteerde en open standaarden, zoals Business Process Modelling Notation (BPMN). Door BPMN als modelleertaal te gebruiken wordt er voorgesorteerd op de generatie van executeerbare procesdefinities in Business Execution Language (BPEL) formaat. Zie Tabel 7-5. 7. Processen dienen zodanig te worden ontworpen dat functiescheiding gewaarborgd is (onder meer met het oog op informatiebeveiliging en privacybecherming). Kader: Opsplitsing bedrijfsproces in invoer- verwerkings- en uitvoerproces Invoerproces Dat deel van een bedrijfsproces dat begint wanneer gegevens vanuit een bron wordt ontvangen en eindigt wanneer aan de bron wordt vermeld dat de invoer inhoudelijk verwerkt zal worden. Verwerkingproces Dat deel van een bedrijfsproces dat begint op basis van een trigger vanuit het invoerproces en eindigt met het doorgeven van een trigger aan het uitvoerproces. Uitvoerproces Dat deel van een bedrijfsproces dat berichten die inhoudelijk gereed zijn daadwerkelijk naar de bestemming (burger, bedrijf, organisatie) brengt, eventueel gebundeld (combinatiediensten). Deze driedeling is vrijwel onontkoombaar om op adequate wijze meerdere, samenwerkende kanalen te kunnen ondersteunen, een goede aansluiting te kunnen maken met andere overheidsorganisaties en een goede aansluiting te hebben op de applicatiearchitectuur. Met name de wens voor dienstverlening

13

De formulering van sommige richtlijnen is iets aangepast om ze beter op de Amsterdamse situatie toe te spitsen.

5 - 15



via meerdere kanalen, maakt een dergelijke driedeling tot een noodzaak. Triggers en informatie kunnen immers via meerdere kanalen binnen komen, maar moeten binnen hetzelfde werkproces opgepakt kunnen worden. Vervolgens moet vanuit één werkproces meer meerdere kanalen ingezet kunnen worden richting burgers en bedrijven. Kortom: een multichannel strategie maakt ontkoppeling van invoer (kanalen), verwerking (proces) en uitvoer (kanalen) noodzakelijk. Kader: waarom een standaard voor procesbeschrijvingen? Naarmate binnen de overheid processen meer en meer aan elkaar worden gekoppeld, is een uniforme beschrijving ervan meer noodzakelijk. Ook zien we dat processen meer door middel van softwareapplicaties worden uitgevoerd. Procesbeschrijvingen en applicatiebeschrijvingen moeten naadloos in elkaar overlopen. Vanuit de softwareontwikkeling wordt daarom aangedrongen op een universele manier van procesbeschrijven. Processen zijn tenslotte aan veranderingen onderhevig en moeten daarom goed beheerd worden (versiebeheer). Door processen op een uniforme manier te beschrijven worden mogelijkheden voor hergebruik van processen beter zichtbaar. De modelleringsstandaard dient in elke geval de volgende functionaliteit te kunnen bevatten: • Beschrijving van de reactie op een voor het proces relevante trigger. • Beschrijving van taken en de volgorde waarin de taken moeten worden uitgevoerd (inclusief eventuele compenserende acties en iteraties) • Beschrijving van business rules die de procesflow bepalen. De procesontwerpen dienen de verschillende rollen te beschrijven, onder aanduiding van de autorisatie van de betreffende rol (het zogenaamde Role Based Acces Control). Daarom zijn in Tabel 5.1 ook concrete richtlijnen opgenomen over procesbeschrijven (BPMN) en de beschrijvingsmethode (BPEL) hoe deze geautomatiseerd worden uitgevoerd. 5.4.2


Er gelden geen standaarden op het niveau ‘uniform’. 5.4.3



5.4.4

Afspraken


5 - 16



5.5

Beheer

Tabel 5-2 Beheer

Nr. en naam model

Eigenaar

Beheerder

modellen

Model 5.1: Hoofdprocesplaat



van Diesntverlening

5 - 17



5.6

Beveiliging

5.6.1

GIBN

In onderstaande tabel zijn de relevante paragrafen uit de Gemeentelijke Informatiebeveiligingsnorm (GIBN, versie 2.0 april 2005) voor de organisatiearchitectuur opgenomen. Veel beveiligingsmaatregelen zijn procedures en daarmee onderdeel van een proces. Nr. GIBNparagraaf

Titel paragraaf

3.3

Rapporteren beveiligingsincidenten

3.4

Verantwoordelijkheden diensttakoverstijgende (informatie)systemen (DOIS)

3.5

Contracten met derden

4.3

Beheer van informatie en bedrijfsmiddelen

4.4

Verwerking van persoonsgegevens

5.3

Kwetsbare functies

7.1

Beheerprocedures en verantwoordelijkheden

Tabel 5-3 Relevante

7.2

Acceptatie van nieuwe versies van systemen

paragrafen GIBN

7.3

Bescherming programmatuur en gegevens

7.5

Netwerkbeheer

7.6

Formele uitwisseling van informatie

8.2

Beheer van toegangsrechten

8.3

Controle op toegangsrechten

8.5

Toegangsbeveiliging voor werkstations

8.6

Toegangsbeveiliging in (informatie)systemen

8.7

Bewaking van de toegangsbeveiliging

9.2

Relatie met nood- en ontruimingsplan

9.3

Veiligstelling programmatuur

10.2

Test en acceptatie van (informatie)systemen

11.3

Beoordeling van de naleving

5.6.2


De GIBN is gericht op organisaties en doet geen uitspraken over de informatiebeveiliging rond organisatie overstijgende gemeenschappelijke voorzieningen. PM Verdere uitwerking vindt nog plaats i.s.m. het Platform Informatiebeveiliging.

5 - 18



5.7

Conclusies

1. Processturing is in Amsterdam een leidend principe, maar behoeft nog ontwikkeling en uitwerking. Een degelijke procesarchitectuur is een noodzakelijke voorwaarde voor het realiseren van de Andere Overheid (en daarmee van deze architectuur). Deze versie van het handboek vertoont grote gaten in de procesarchitectuur. De komende jaren moet hier flink in worden geïnvesteerd. 2. Processen worden ontworpen vanuit de behoefte van burgers, bedrijven en overige belanghebbenden in de samenleving. Dat is de reden dat de zes hoofdprocessen uit Beter Presteren leidend zijn bij de invulling van de procesarchitectuur.

conclusies procesarchitectuur

3. Amsterdam wil toewerken naar een service gerichte architectuur. Dat geldt dus ook voor de inrichting van de procesarchitectuur. Daartoe wordt een strategie gevolgd met als hoofdlijnen: • herontwerp van processen (met prioriteit voor belangrijke dienstoverstijgende ketenprocessen en de inrichting van basisregistraties); • standaardisatie van processen; • modulaire opbouw van processen (waarbij processen tot het niveau van handelingen worden ‘opgeknipt’). 4. Bij het ontwerp van ketenprocessen maken we onderscheid (van abstract naar gedetailleerd) in hoofdprocessen, ketenprocessen, bedrijfsprocessen, werkprocessen, processtappen en handelingen. 5. De besturing (en daarmee de regie) van ketenprocessen wordt in principe belegd bij de organisatie die de eindverantwoordelijkheid heeft voor het leveren van de dienst aan de burger of het bedrijf. 6. Elk proces kent een eigenaar en een beheerder. De procesarchitectuur voor de hoofdprocessen wordt onder de verantwoordelijkheid van het kernteam Beter Presteren ontworpen.

5 - 19


kwaliteit en beschikbaarheid


6

Informatiearchitectuur

6.1

Inleiding

De informatiearchitectuur geeft de opbouw en samenhang weer van de belangrijkste informatiebronnen en –stromen die Amsterdam kent.

informatie cruciaal

De kwaliteit en beschikbaarheid van informatie is cruciaal voor verbetering van dienstverlening en stroomlijning van processen. Het ‘no wrong door’ principe vereist beschikbaarheid van dezelfde informatie, ongeacht de locatie. Kanaalonafhankelijkheid betekent dat dezelfde informatie (en antwoorden) ongeacht het communicatiekanaal beschikbaar moeten zijn. ‘Eenmalige opslag, meervoudig gebruik’ vereisen heldere afspraken over gegevens (lokaal en landelijk) en heldere afspraken over relaties tussen gegevens en beheer van gegevens. strategie:

De strategie voor de inrichting van de informatiearchitectuur kent vier prioriteiten: 1. Implementeren van wettelijke afspraken rond basisregistraties 2. Benutten van potentie van kernadministraties 3. Het toewerken naar één standaard voor een zaakdossier en één zakenmagazijn. 4. Standaardisering

1) basisregistraties

De basisregistraties stroomlijnen de gegevens die intensief worden gebruikt in meerdere beleids-, uitvoerings- en handhavingsketens. We kennen op dit moment zes landelijke basisregistraties voor Personen, Bedrijven, Adressen, Gebouwen, Percelen en Topografie. Zoals aangegeven in Hoofdstuk 4 en 5 kunnen burgers en bedrijven via meerdere kanalen de door de overheidsorganisaties gevraagde gegevens aanleveren. Deze gegevens worden geregistreerd in speciaal daarvoor opgezette basisregistraties. De gegevens worden dan beschikbaar gesteld aan andere overheidsorganisaties die ervan gebruik mogen (en moeten) maken. Zo voorkomen we dat verschillende overheidsorganisaties steeds dezelfde gegevens bij burgers en bedrijven uitvragen.

6-1



Er gelden landelijke en wettelijke afspraken over de gegevens binnen deze basisregistraties. In deze concernarchitectuur van Amsterdam volgen we deze afspraken. Dat geldt ook voor de afspraken rond het Burger Service Nummer (BSN) die nauw samenhangen met de basisregistratie Personen. 2) kernadministraties

Buiten de wettelijke basisregistraties zijn er andere administraties binnen het concern Amsterdam die we intensief gebruiken en bijdragen aan de doelstellingen als kostenbesparing en verbetering van de dienstverlening en handhaving. Dit zijn de zogenaamde kernadministraties. Ook voor de kernadministraties geldt het principe van ‘éénmalige opslag, meervoudig gebruik’. Voorbeelden zijn de kernadministraties “Onderwijs en jeugd”, “Bestuursinformatie” en het zogenaamde “Zakenmagazijn”.

3) een standaard

Bij een klacht of een vraag kan een burger via meerdere kanalen communiceren met de Amsterdamse overheid. Ongeacht de wijze van communicatie zal een burger eenduidig geïnformeerd willen worden over status en voortgang van de klacht of vraag. Voor zowel de burger als voor de uitvoerende organisaties geldt dat direct inzichtelijk moet zijn wat de voortgang van de behandeling is en welke andere vragen en/of klachten aan deze persoon gekoppeld zijn. Per vraag of klacht noemen we deze informatie een zaakdossier, meerdere zaakdossiers van een burger vormen tezamen een klantendossier. Voor de informatievoorziening betekent dit dat er gebruik gemaakt moet worden van één, voor het gehele concern toegankelijk, zakenmagazijn waarin de informatie van de verschillende zaakdossiers te vinden is. In zo’n zaakdossier moet de vraag of klacht eenduidig vastgelegd worden, de basisinformatie direct gekoppeld zijn, de status en voortgang van de zaak zichtbaar gemaakt kunnen worden en een digitaal dossier gekoppeld kunnen worden.

zaakdossier en één zakenmagazijn

Met name voor het hoofdproces dienstverlening is het hebben van een standaard zaakdossier en zakenmagazijn van cruciaal belang. Amsterdam volgt hierbij zo veel mogelijk op landelijk niveau ontwikkelde modellen. 4) standaardisering

Om informatie te kunnen uitwisselen zijn afspraken nodig over de vorm en taal waarin dit wordt gedaan. Standaardisering dus. Een goed voorbeeld is standaardisering op het terrein van digitaal informatiebeheer. Als stadsdelen en diensten op een eigen manier informatie zou registreren en archiveren, wordt het bijna onmogelijk om informatie terug te vinden en te ontsluiten voor geïnteresseerden. Een Andere Overheid vereist standaardisering op allerlei terreinen.

samenhang met andere

De keuzes in de informatiearchitectuur zijn van invloed op hoger- en lagergelegen architectuurlagen. Met name het principe van ‘éénmalige opslag, meervoudig gebruik’ is bepalend voor de vormgeving van alle hoofdprocessen. In deze processen wordt immers intensief gebruik gemaakt van basisregistraties, kernadministraties en het zaakdossier. Ook zal in deze processen het digitaal informatiebeheer verankerd moeten worden. Ook op de lager gelegen architectuurlagen heeft de informatiearchitectuur impact. De applicatie- en infrastructuurarchitectuur zullen onbelemmerde gegevensuitwisseling mogelijk moeten maken binnen de randvoorwaarden die

architectuurlagen

6-2



de Gemeentelijke InformatieBeveligingsNorm (GIBN) stelt. Rond het delen van persoonsgegevens is extra aandacht nodig voor privacybescherming.

6-3



6.2

Grondslagen

De volgende uitspraken zijn richtinggevend en kaderstellend voor de informatiearchitectuur: grondslag 3.1

De basisregistraties en kernadministraties vormen een verplichte bron van de Amsterdamse gegevens huishouding

grondslag 3.2

Gegevens worden éénmalig vastgelegd en meervoudig gebruikt.

grondslag 3.3

Gegevens worden ontsloten met maximale transparantie binnen de wettelijke kaders.

grondslag 3.4

De gemeente Amsterdam garandeert vertrouwelijkheid van gegevens, betrouwbaar digitaal contact en zorgvuldige elektronische archivering.

6-4



6.3

Modellen

6.3.1

Gemeentelijke informatiehuishouding

Personen Model 6.1: Gemeentelijke

Adressen

Topografie

Landelijk domein

informatiehuishouding

Bedrijven

Kernadmin. Z

Org.spec. admin C

Gebouwen

Concerndomein Organisatiespecifiek domein

Percelen

Gemeentelijk Informatiemodel Basis registraties

Kernadmin. Y

Kernadmin. X

Gemeentelijke Informatiehuishouding

Org.spec. admin B

Org.spec. admin A

Org.spec. admin D

[Bron: Adviesgroep Architectuur] In Model 6.1 is zichtbaar dat we binnen de gemeentelijke informatiehuishouding drie niveaus onderscheiden: 1. Basisregistraties Dit is de kern waarin de zes wettelijke basisregistraties zijn genoemd (zieparagraaf 6.3.2 ) 2. Gemeentelijk informatiemodel Waarin naast de basisregistraties ook de zogenaamde kernadministraties zijn opgenomen (zie paragraaf 6.3.3 ). 3. Gemeentelijke informatiehuishouding Het gemeentelijk informatiemodel plus de organisatiespecifieke administraties. Het onderscheid tussen ‘concern’ en ‘organisatiespecifiek’ is hiermee ook zichtbaar. De basisregistraties en kernadministraties vormen tesamen ‘het gemeentelijk informatiemodel’ van het concern Amsterdam. In het gemeentelijk informatiemodel worden de registraties, kernadministraties, entiteiten, relaties en gegevenselementen gemodelleerd en beschreven.

6-5



Kader: Nadere beschouwing van de kernadministraties Basisregistraties en kernadministraties behoren beiden tot het gemeentelijk informatiemodel. Door middel van het eenmalig vastleggen en meervoudig gebruiken van gegevens dragen ze beiden bij aan concerndoelstellingen als kostenbesparing en verbetering van de dienstverlening en handhaving. Het verschil met basisregistraties is echter dat kernadministraties: • niet gebaseerd zijn op landelijke wetgeving; • niet altijd een weergave van registers zijn; • niet per definitie een samenhangend stelsel vormen en • niet per definitie landelijk uitgewisseld worden. De stand van zaken Dat er binnen de gemeentelijke informatiehuishouding sets gegevens zijn die kunnen voldoen aan de kenmerken ‘eenmalige vastlegging meervoudig gebruik’ is helder. Deze gegevenssets zitten echter veelal nog verborgen in bestaande toepassingen. Hoe komen we tot kernadministraties Een eenduidige vaststelling van de kernadministraties vereist een nadere uitwerking van het gemeentelijk informatiemodel: • welke informatie wordt in welk gemeentelijk proces gebruikt • waar is sprake van meervoudig gebruik van gegevens • wat is de relatie tussen deze gegevens en het stelsel van basisregistraties • welke criteria maken een administratie tot kernadministratie • welke eisen stellen we aan kernadministraties. Minimaal kun je stellen dat de modellen ingepast moeten worden in het gemeentelijk informatiemodel.Ook zou een kernadministratie onafhankelijk moeten zijn en niet afhankelijk van één primair proces. Pragmatiek in de uitvoering Langdurige discussies over criteria voor kernadministraties, definities en grensgevallen is niet de benadering die we kiezen. Een aantal knelpunten is duidelijk, de ontwikkeling van administraties om deze knelpunten op te lossen is noodzakelijk (zaak/klant dossiers, jeugd en onderwijsadministraties, etc.) In die zin kan, zolang de criteria niet vastgesteld zijn, beter gesproken worden van kandidaat-kernadministraties. De kandidaat kernadministraties De benoemde kandidaat-kernadministraties kunnen nog niet beoordeeld worden als volwaardig kernadministratie. In de opsomming zijn namen van toepassingen of toepassingsgebieden benoemd. De potentiële kernadministratie heeft veelal betrekking op een deel van de gegevens binnen deze toepassingen: de kerngegevens. Van kerngegevens naar kernadministraties Door een gezamenlijke verdere uitwerking van het gemeentelijk informatiemodel en een verdere ontwikkeling van de kandidaat-administraties volgend aan dit model kunnen we de stap maken van kerngegevens naar kernadministraties: duidelijke afspraken over inhoud en kwaliteit van de administraties, afspraken in de keten bron-beheerder-afnemer (als bij de basisregistraties) en technische faciliteiten om de kernadministraties te ontsluiten en distribueren. 6-6



6.3.2

Zes basisregistraties Gebouw

7

Adres Adressen

Natuurlijk persoon

Model 6.2: Zes basisregistraties (conceptueel)

Gebouwen

Niet natuurlijk persoon Perceel Kaart

Personen

Bedrijven

Percelen

Topografie

[Bron: Adviesgroep Architectuur] De kern van het gemeentelijk informatiemodel wordt gevormd door het geïntegreerd stelsel van zes basisregistraties: Personen, Bedrijven, Adressen, Gebouwen, Percelen en Topografie. Elk van deze registraties is een weergave van een register. Ze vormen een samenhangend stelsel en worden landelijk uitgewisseld. Het gebruik van de basisregistraties wordt wettelijk verplicht gesteld. In Model 6.2 is op een eenvoudige manier zichtbaar gemaakt hoe deze zes basisregistraties onderling verweven zijn. Door eenduidige identificatie van de gegevens in de registraties, de logische samenhang van de gegevens én de koppeling van de registraties kan vanuit meerdere zoekingangen altijd de meest actuele informatie gevonden worden. Vanuit de zoekingang ‘persoon’ kan bijvoorbeeld doorgekoppeld worden naar de bijbehorende vastgoedinformatie. Vanuit een topografische kaart kan bijvoorbeeld de gebouwen en adressen en de daar woonachtige personen worden gevonden. Kader: Het Burger Service Nummer en de relatie met basisregistraties Het Burger Service Nummer (BSN) is een uniek identificerend persoonsnummer voor iedereen die een relatie heeft met de Nederlandse Overheid. Dit zijn alle personen die zijn ingeschreven in de Gemeentelijke Basisadministratie Persoonsgegevens (GBA), of in het Register Niet Ingezetenen (RNI). Het is hetzelfde nummer als het huidige Sofi-nummer, maar het BSN krijgt een breder gebruik. Met andere woorden: het nummer is hetzelfde, het wettelijk kader is anders. Alle overheidsorganisaties en organisaties met een maatschappelijke functie, zoals zorgen onderwijsinstellingen, gaan het BSN gebruiken in de communicatie met en over burgers. Persoonsgebonden gegevens kunnen met het BSN doelmatig en betrouwbaar uitgewisseld worden binnen de overheid en tussen overheid en burgers. Zo verbetert de dienstverlening, kan de bedrijfsvoering efficiënter worden ingericht en is fraude effectiever te bestrijden. De wetgeving Basisregistraties en de wet rond het BSN komen in uitvoering bij elkaar: BSN is het identificerende kenmerk voor de uitwisseling van

6-7



persoonsgebonden gegevens en wordt om die reden als authentiek gegeven opgenomen in de basisregistratie Personen. Vanuit het programma BSN moeten wij het BSN nummer als identificerend gegeven opnemen in de administraties, vanuit de wet Basisregistraties moeten wij gebruik maken van de Basisregistratie Personen (met daarin het BSN). In de uitvoering betekent dit dat een koppeling aan de Basisregistraties direct ook het gebruik van BSN inhoudt. DPG GEMEENTELIJKE BASISADMINISTRATIE (Personen)

BASISREGISTRATIE ADRESSEN (Adressen)

natuurlijke personen

adressen

Model 6.3: Zes basisregistraties met beheerders

GEOGRAFISCH KERNBESTAND (Topografie)

topografie (groot/ kleinschalig), lucht- en cycloramafoto’s

Geo en Vastgoedinformatie DBGA BASIS BEDRIJVEN REGISTER (Bedrijven)

BASIS GEBOUWEN REGISTER (Gebouwen)

niet-natuurlijke personen

verblijfsobjecten

vestigingen

panden

KADASTRALE REGISTRATIE (Percelen)

percelen

[Bron: Adviesgroep Architectuur] In Model 6.3 is zichtbaar wat de officiële benaming is van de zes basisregistraties, wie de beheerder is en wat de belangrijkste objecten per registratie zijn. Kader: Objecten, relaties en attributen in een objectenmodel Een objectenmodel bestaat uit de volgende onderdelen: • Objecten: een object is een "tastbaar" iets dat deel uitmaakt van het gegevensmodel. Voorbeelden hiervan zijn: openbare ruimte, adres, pand of natuurlijk persoon. • Relaties: een relatie geeft het verband weer tussen twee of meer objecten, zoals "een adres is hoofd- of nevenadres van een gebouwd object". • Attributen: een attribuut is een eigenschap van een object of relatie. Zo heeft een natuurlijke persoon (onder andere) een voornaam, een achternaam en een sofi-nummer. Een objectenmodel toont de objecten in normaalvorm, visualiseert de cardinaliteit en optionaliteit van de relatie, en is in overeenstemming met onderliggende attributenmodellen. Een attributenmodel bevat de objectnaam, de primary key en per attribuut bijvoorbeeld de naam, type en lengte, omschrijving en domein(waarden).

6-8



GLOBAAL OBJECTENMODEL STELSEL VAN GEMEENTELIJKE BASISGEGEVENS

OVERIGE GEOOBJECTEN

GEMEENTE

GEMEENTELIJKE OPENBARE RUIMTE

betreft 1 of meer

ligt aan

OPENBARE RUIMTE

WIJK

ADRESSEERBAAR OBJECT AANDUIDING

Model 6.4: Objectenmodel van stelsel van

is correspondentie-adres van

BUURT

gemeentelijke basisgegevens

ligt in

ligt in

WOONPLAATS

SUBJECT

14 is hoofd- of nevenadres van

BENOEMD TERREIN

NIET-NATUURLIJK PERSOON

GEBOUWD OBJECT

bepaalt hoofd- (en neven-)adres(sen) van

zonder verblijfsobject ligt in

PAND

KADASTRALE ONROERENDE ZAAK

NATUURLIJK PERSOON

ligt in

hoort bij

bepaalt verblijfsadres van

MAATSCHAPPELIJKE ACTIVITEIT

VESTIGING

ZAKELIJK RECHT

[Bron: EGEM] In Model 6.4 is het objectenmodel van het stelsel van gemeentelijke basisgegevens weergegeven. De kern van het objectenmodel wordt gevormd door de objectenmodellen van de Basisregistraties van Adressen en Gebouwen (de BAG: BRA en BGR), de Basisregistratie Personen (BRP), de Basisregistratie Ondernemingen en Andere Organisaties (het NHR oftewel Nieuw Handelsregister) en de Basisregistratie Kadaster (de BRK). De adressen, gebouwen en terreinen enerzijds en personen en vestigingen anderzijds worden in separate schema’s verder gedetailleerd in Bijlage 8. De basisregistratie Bedrijven is, ten tijde van deze versie van het handboek, nog in ontwikkeling. Het model hiervan wordt in een volgende versie van het handboek opgenomen. Tot die tijd is nadere informatie te verkrijgen bij de beheerder van de basisregistratie Bedrijven: DBGA.

14

Amsterdam hanteert nog wel een eigen uitbreiding op dit model.

6-9



Amsterdam hanteert het referentiemodel van EGEM als uitgangspunt met een eigen uitbreiding hierop; het referentiemodel is bedoeld voor alle gemeenten en bevat geen Amsterdam-specifieke objecten, attributen en relaties. De uitwerkingen van de objectmodellen in attributenmodellen en de beschrijvingen van de objecten en de attributen zijn niet opgenomen in dit handboek, maar zijn beschikbaar bij de basisregistratiehouders. 6.3.3 Tabel 6-1 Overzicht kandidaat kernadministraties

Overzicht kernadministraties

Kernadministratie Bestuursinformatie (Andreas)

Bouwprojecten en woningregistraties (BWT) Erfpacht

Handhavingsgevens Onderwijs en jeugd

Informatie inburgeringstrajecten (Edisa)

Werknemergegevens (P-net) Woningbouwlocaties

6 - 10

Bevat:

Eigenaar:

Status:

Dossiers en documenten betrokken bij de besluitvorming van het College van B&W, Raadscommissies en de Gemeenteraad. PM

Bestuursdienst/ directie BMO


PM

Juridische, financiële en vastgoedgegevens met betrekking tot Erfpachtrech-ten (inclusief digitaal dossier) PM

OGA/ Bureau Erfpacht

Voorstel Adviesgroep Architectuur Voorstel Adviesgroep Architectuur

Inhoudelijke informatie over jongeren van 0-23 jaar die noodzakelijk is voor het uitvoeren van het Amsterdamse jeugdbeleid. Het gaat hierbij om (verbeterde) gegevens uit LAS/Erisa over o.a. school, opleiding, verzuim, Cito- en basisschooladvies Gegevens van nieuwkomers en oudkomers over de voortgang van hun inburgering traject. Specifiek wordt in het cliënt volgsysteem de voortgang van de taal opleiding en de voortgang van de maatschappij oriëntatie van de betrokkene vastgelegd. PM

DMO/Onderwijs

Het Basisbestand bevat deze informatie over de woningbouw(locaties) binnen de gemeente Amsterdam. Het gaat met name om

OGA

PM

Vastgesteld door SG BRI als kernadministratie Vastgesteld door SG BRI als kernadministratie

DMO/Servicedesk Team I&A


PM

Voorstel Adviesgroep Architectuur Vastgesteld door SG BRI als kernadministratie



Woonprojecten (BWV) Zakenmagazijn

planning, voortgang, aantallen woningen(en differentiatie) en de betrokken partijen PM

PM

PM

PM

Voorstel Adviesgroep Architectuur Voorstel Adviesgroep Architectuur

[Bron: Adviesgroep Architectuur] Kernadministraties zijn administraties die veel gebruikt worden door verschillende partijen binnen het concern Amsterdam en waarvoor het principe van ‘éénmalige opslag, meervoudig gebruik’ geldt. Welke administratie wel en welke niet tot kernadministratie wordt benoemd is in zekere zin arbitrair. De Adviesgroep Architectuur stelt voor om de Tabel 6-1 opgenomen administraties tot kandidaat kernadministratie te benoemen. De belangrijkste consequentie hiervan is dat voor deze administraties het principe van ‘éénmalige opslag, meervoudig gebruik’ gaat gelden. Een aantal van deze administraties is reeds door de Stuurgroep BRI aangewezen als kernadministratie. In Tabel 6-1 is verder aangegeven welke organisatie binnen het concern primair verantwoordelijk is. Vaak is dit de organisatie waar de gegevens zich bevinden. Deze organisatie zal ook verantwoordelijk moeten worden voor het opstellen van de benodigde modellen (zie kader). Kader: Hoe te komen tot uitwerking van de kernadministraties? De uitwerking van deze kernadministraties (in de vorm van modellen en standaarden) is niet opgenomen in deze versie van het Handboek Architectuur. De beheerders en ontwikkelaars van deze registraties (zie Tabel 6-1) zal verzocht moeten worden om deze aan te leveren voor de volgende versie. Deze modellen moeten in elk geval voldoen aan de in dit handboek beschreven standaarden en moeten specifiek inzicht geven in de relatie tussen en met de basisregistraties de andere kernadministraties.

6 - 11



6.3.4

Het zaakdossier

Model 6.5: Het zaakdossier (objectenmodel)

[Bron: EGEM 2002] De informatievoorziening binnen het concern moet zodanig ingericht zijn dat een burger via alle kanalen van de front office zijn vraag of klacht kan aangeven. Binnen de front office worden, na opgave van zijn of haar identificatie, alle relevante basisgegevens als adres en persoonsgegevens direct opgehaald en hoeft alleen de relevante vraag of klacht informatie ingevoerd te worden. Ongeacht het kanaal van de front office en ongeacht de uitvoerende back office organisatie moet de burger er op kunnen vertrouwen dat de kwaliteit van afhandeling en communicatie in alle gevallen hetzelfde is. Voor zowel de burger als voor de uitvoerende organisaties geldt dat direct inzichtelijk moet zijn wat de voortgang van de behandeling is en welke andere vragen en/of klachten aan deze persoon gekoppeld zijn 15. Voor de informatievoorziening betekent dit dat er gebruik gemaakt moet worden van één, voor het gehele concern toegankelijke, zakenadministratie. Dit wordt het ‘zakenmagazijn’ genoemd. De zaakdossiers worden opgeslagen in dit (virtuele) zakenmagazijn (zie kader), één van de kernadministraties van het concern. In het zaakdossier moet de vraag of klacht eenduidig vastgelegd worden, moet de basisinformatie direct gekoppeld zijn, moet de status en voortgang van de zaak zichtbaar gemaakt kunnen worden en moet een digitaal dossier gekoppeld kunnen worden. De wenselijkheid van één zaakdossier en één zakenmagazijn is op landelijk niveau erkend en in 2002 zijn vanuit de EGEM modellen opgesteld voor deze registratie. In Model 6.5 is het objectenmodel voor het zaakdossier weergegeven. In Amsterdam is nog geen zaakdossier beschikbaar. Dit moet er wel gaan komen. Bij de ontwikkeling dient de laatste versie van het EGEM zaakdossier door alle organisaties als uitgangspunt te worden genomen om te voorkomen dat we 15

Een ‘zaak’ wordt niet per definitie door een burger geinitieerd. Ook waar de gemeente het initiatief neemt tot communicatie (via bijvoorbeeld een aanslag of een aanschrijving die voortkomt uit een beschikking) wordt een zaak aangemaakt.

6 - 12



straks zaakinformatie niet kunnen uitwisselen. Kader: Het verschil tussen zaakdossier, klantendossier en zakenmagazijn Er worden nogal eens wat termen door elkaar gebruikt. In deze architectuur definiëren we een zaakdossier als de registratie van een complex van handelingen gericht op één bepaald doel. De aanvraag van een burger van een uittreksel uit het bevolkingsregister vormt dus één zaak met één dossier. In Model 6.5 is weergegeven hoe een standaard zaakdossier is opgebouwd. Een klantendossier gaat verder. Het bundelt alle (historische en lopende) zaken van één klant. Simpel gezegd: een klantendossier bevat alle zaakdossiers van één klant. Een zakenmagazijn vormt een systeem waarin alle zaakgegevens met bijbehorende documenten en metadata worden vastgelegd en bewaard. Simpel gezegd: een zakenmagazijn bevat alle afzonderlijke zaakdossiers.

Model 6.6: GFO Zaken

16

[Bron: EGEM] In Model 6.6 is het zogenaamde Gemeentelijk Functioneel Ontwerp ‘Zaken’ (hierna: GFO Zaken) van EGEM uit 2002 weergegeven. Het vormt een verdere uitwerking van Model 6.5. waarbij ook de relaties naar de basisregistraties is aangegeven 17. Het GFO Zaken schrijft de minimale set van gegevens voor (met definities en technische specificaties) die als standaard geldt om centraal de basiskenmerken van een ‘zaak’ te kunnen verzamelen en gegevens over de ‘zaak’ te kunnen halen uit verspreide informatiesystemen. 16

Dit model wordt nog aangepast (zie voetnoot hieronder). Het GFO zaken 2002 is nog niet volledig aangepast aan de laatste ontwikkelingen rond de modellering van de overige basisregistraties. Naar verwachting vindt deze aanpassing in de tweede helft van 2006 plaats.

17

6 - 13



Het GFO Zaken definieert een ‘zaak’ als een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en een gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden. Het GFO Zaken ontsluit en koppelt op een centraal punt de basisinformatie die op een zaak betrekking heeft: • de lopende en afgesloten procedures (zaken); • de status van procedures; • het subject (de burger, het bedrijf) dat het verzoek heeft gedaan; • de betrokkenen; • de actor (het organisatieonderdeel, de medewerker) die het verzoek behandelt; • de stap in de procedure, waarmee de link naar het proces wordt gelegd; • de gekoppelde objecten en • het daarop betrokken adres. 6.3.5

Digitaal informatiebeheer

Werkproces

Digitale informatie Metadata: • Elementen • Waarden • Syntax • Classificaties

Model 6.7: Digitaal informatiebeheer

Bestanden: • Tekst, Spreadsheet, Database,Beeld, Audio, Audiovisueel, Interactief

Digitaal informatiebeheer

TIJD

[Bron: Programma Digitaal Informatiebeheer] In Model 6.7 is eenvoudig de kern van digitaal informatiebeheer weergegeven. Werkprocessen produceren informatie die bewaard moet worden. Tevens hebben ze informatie nodig die is vastgelegd in andere werkprocessen. In de

6 - 14



digitale wereld bestaat die informatie uit bestanden. Er zijn gegevens nodig om de informatie in bestanden goed te kunnen bewaren en terug te kunnen vinden. Die gegevens noemen we metadata. Bij bestanden onderscheiden we de volgende vormen: tekst, spreadsheet, database, beeld, audio, audiovisueel en interactief. Voor metadata moeten afspraken gemaakt worden over de volgende aspecten: elementen, waarden, classificaties en syntax. Digitaal informatiebeheer zorgt ervoor dat informatie goed bewaard blijft waardoor ze bruikbaar is en blijft voor werkprocessen. Standaardisering is van cruciaal belang voor digitaal informatiebeheer. Het richt zich op de kenmerken van digitale informatie: bijvoorbeeld welke metainformatie leggen we vast of welke bestandstypes hanteren we. De weten regelgeving en afspraken rond digitaal informatiebeheer zijn van oudsher voornamelijk gericht op de archieffunctie. Het gaat echter verder. Ontwikkelingen als digitale dienstverlening en basisregistraties hebben grote invloed op standaarden voor digitaal informatiebeheer en dwingen ons verder te kijken dan de archieffunctie (zie ook kader). In dit handboek is een eerste stap gezet 18 voor de standaardisering van digitaal informatiebeheer (zie paragraaf 6.4 en Bijlage 10). Deze stap is gericht op het registreren en bewaren van digitale informatie. Deze zijn van toepassing op digitaal gecreëerde, procesgebonden informatie die bewaard moet worden vanwege weten regelgeving en/of andere concernbelangen. De standaarden beschrijven naast algemene uitgangspunten standaarden voor metadata (bijvoorbeeld minimaal verplichte velden), gegevenselementen (bijvoorbeeld opbouw identificering documenten naar organisatie en volgnummer) en bestandsformaten (bijvoorbeeld PDF en XML voor tekstdocumenten.) Kader: Koppelen van digitaal dossier aan het zaakdossier Een goed voorbeeld van de noodzaak tot standaardisering van digitale informatie is het koppelen van een digitaal dossier aan een zaakdossier. In een volgende versie van dit handboek moet daarom een objectenmodel opgenomen worden met daarin de relatie tussen de ongestructureerde data (gedigitaliseerde documenten) en het zaakdossier. Ook is het wenselijk dan een aantal standaarden vast te stellen voor de metadata.

18

Standaarden voor Digitaal Informatiebeheer worden vanuit het programma ‘Digitaal Informatiebeheer“ in samenwerking met de Adviesgroep Architectuur opgezet

6 - 15


Tabel 6-2 Richtlijnen informatiearchitectuur


6.4

Standaarden

6.4.1

Richtlijnen

1. Binnen de informatiearchitectuur volgt Amsterdam waar mogelijk landelijke modellen. 2. Landelijke modellen worden zo nodig aangevuld met extra gegevens. Hier moet wel een krachtige argumentatie voor zijn. 6.4.2



In onderstaande tabel zijn de uniforme standaarden opgenomen die gelden binnen de informatiearchitectuur. Nr. en naam Toelichting Bron standaard

informatiearchitectuur

BSN

Uniek persoonsnummer dat als nummer gelijk is aan het sofinummer. Het heeft echter een ander wettelijk kader waardoor een breder gebruik mogelijk is.

Ministerie van BZK, Wet algemene bepalingen BSN (behandeling 082006)

CAR

Handreiking Catalogus Authentieke Registraties, de landelijke richtlijn voor datamodellering


Dublin Core

Set gegevenselementen die samen een gangbare internationale standaard vormen. De Dublin Core wordt beschouwd als een handzame, bondige standaard waarin de meest essentiële gegevenselementen voor digitale informatie zijn gebundeld

Voorstel Programma Digitaal Informatiebeheer/GAA

GBS

Gemeentelijk bevolkingssysteem van DPG is de standaard voor persoonsgegevens

B&W besluit 9 november 2004

PDF

Standaard voor images / beelden


Stuf 2.x 19

Standaard Uitwisseling Formaat voor binnengemeentelijk berichtenverkeer


Tabel 6-3

19

StUF is het Standaard Uitwisseling Formaat voor het uitwisselen van binnengemeentelijke berichten. De standaard specificeert zelf geen concrete berichten, maar is een zogenaamde template-definitie: een globale structuur voor berichten die sectoronafhankelijk is, waarmee concrete berichten gedefinieerd kunnen worden. StUF is een gestandaardiseerde manier om een willekeurig Entiteit-Relatie-model van een toepassingsgebied binnen de gemeente om te zetten naar berichten. In Amsterdam geldt StUF 2.04 als standaard. Voor o.a. versiebeheer is in Amsterdam een StUF-platform opgericht waaraan aanleverende partijen en afnemers deelnemen (zie Viadesk). Zie ook Bijlage 9.

6 - 16



VRA

6.4.3

Tabel 6-4 Bandbreedte standaarden informatiearchitectuur

VastgoedRegistratie Amsterdam van GVI is de standaard voor vastgoedgegevens



In onderstaande tabel zijn de bandbreedte standaarden opgenomen die gelden binnen de informatiearchitectuur. Nr. en naam Toelichting Bron standaard ITU T4 òf ITU T6

Standaard voor images / beelden met gebruik van compressie


PDF òf SGML òf XML vergezeld van een stylesheet (XSL, CSS)

Standaarden voor tekstbestanden / -documenten


6.4.4

Afspraken

In onderstaande tabel zijn de afspraken standaarden opgenomen die gelden binnen de applicatiearchitectuur.

Tabel 6-5 Afspraken standaarden informatiearchitectuur


Toelichting

Bron

Verplichte metadata bij creatie en beheer bestand

Een uniek ID, creatiedatum, versie, archiefvormer, status en statushistorie


Verplichte metadata indien relevant voor de informatie waar ze betrekking op hebben

auteur(-s), verwijzing(-en) naar Basisregistratie(-s), verwijzing(en) naar dossier(-s), publicatiedatum(-s), wijzigingsdatum(-s), inzagerechten


6 - 17



6.5

Tabel 6-6 Beheer modellen

Beheer

Nr. en naam model

Eigenaar

Beheerder

Model 6.1: Gemeentelijke informatiehuishouding

PM

PM

Model 6.2: Zes basisregistraties (conceptueel)

PM

PM

Model 6.3: Zes basisregistraties met beheerders

PM

PM

Model 6.4: Objectenmodel van stelsel van gemeentelijke basisgegevens13F

EGEM

EGEM

Model 6.5: Het zaakdossier (objectenmodel)

EGEM

EGEM

Model 6.6: GFO Zaken15F

EGEM

EGEM

Model 6.7: Digitaal informatiebeheer

Programma Digitaal Informatiebeheer/GAA



Eigenaar

Beheerder

BSN

Ministerie van BZK

Ministerie van BZK

CAR

Ministerie van BZK

Ministerie van BZK

Dublin Core

Dublin Core initiative


GBS

DPG

DPG

VRA

GVI

GVI

ITU T4 òf ITU T6

Ministerie van BZK

Ministerie van BZK

Tabel 6-7 Beheer

PDF

Ministerie van BZK

Ministerie van BZK

standaarden

PDF òf SGML òf XML vergezeld van een stylesheet (XSL, CSS)

Ministerie van BZK

Ministerie van BZK

Stuf 2.x 20

EGEM

EGEM

Verplichte metadata bij creatie en beheer bestand



Verplichte metadata indien relevant voor de informatie waar ze betrekking op hebben



20

StUF is het Standaard Uitwisseling Formaat voor het uitwisselen van binnengemeentelijke berichten. De standaard specificeert zelf geen concrete berichten, maar is een zogenaamde template-definitie: een globale structuur voor berichten die sectoronafhankelijk is, waarmee concrete berichten gedefinieerd kunnen worden. StUF is een gestandaardiseerde manier om een willekeurig Entiteit-Relatie-model van een toepassingsgebied binnen de gemeente om te zetten naar berichten. In Amsterdam geldt de laatste vastgestelde versie van Stuf 2.x als standaard. In april 2006 is StUF versie 2.04 vastgesteld. Zie ook Bijlage 9.

6 - 18



6.6

Beveiliging

6.6.1

GIBN

In onderstaande tabel de relevante paragrafen uit de Gemeentelijke Informatiebeveiligingsnorm (GIBN, versie 2.0 april 2005) voor de informatiearchitectuur opgenomen. Deze eerste uitwerking is totstandgekomen in samenwerking met het Platform Informatiebeveiliging, de verder uitwerking zal ook gezamenlijk ook worden opgepakt. Nr. GIBNparagraaf

Titel paragraaf

Tabel 6-8 Relevante

4.1

Inventarisatie van informatie in bedrijfsmiddelen

paragrafen GIBN

4.2

Classificatie van informatie en bedrijfsmiddelen

7.6

Formele uitwisseling van informatie

10.3


10.4

Digitale handtekening

Kader: Bijzondere aandacht voor privacy nodig binnen informatiearchitectuur Gemeentebrede samenwerking op basis van het delen van persoonsgegevens vereist een gemeentebrede samenwerking op het gebied van privacybescherming: een adequate privacybescherming is een kwaliteitsaspect voor een goede informatiehuishouding. Dit geldt niet alleen voor de basisregistratie Personen maar voor alle administraties waar persoonsgegevens worden gebruikt. In aanvulling op de GIBN dient er in de informatiearchitectuur bijzondere aandacht te zijn voor privacy, waarbij het van belang is dat de verschillende gemeentelijke verantwoordelijken gelijke normen hanteren met betrekking tot privacy. Naast de Wet GBA voor de basisregistraties is de Wet bescherming persoonsgegevens (Wbp) van toepassing. De Wbp verplicht de verantwoordelijke tot optimale transparantie bij het gebruik van persoonsgegevens. Waar en hoe worden persoonsgegevens verkregen, opgeslagen en gebruikt? Voor welk doel worden persoonsgegevens verzameld en wat is de relevantie ten opzichte van dit doel? De transparantie en de vraag of de privacy al dan niet in het geding is wordt bepaald aan de hand van een achttal principes: 1. Het Collection and Distribution Limitation Principle Dit beginsel geeft aan dat er beperkingen moeten gelden ten aanzien van het verzamelen en distribueren van persoonlijke gegevens. 2. Het Data Quality Principle Dit beginsel bepaalt dat persoonlijke gegevens relevant moeten zijn voor het doel waarvoor ze bedoeld zijn te worden gebruikt. 3. Het Purpose Specification Principle Het doel waarvoor gegevens worden verzameld moet worden aangegeven op, of voorafgaande aan het moment van het verzamelen van de gegevens. 4. Het Use Limitation Principle Persoonlijke gegevens mogen niet verstrekt worden, of op een andere

6 - 19



5.

6.

7.

8.

wijze ter beschikking worden gesteld, voor andere dan de gespecificeerde doeleinden, behalve met toestemming van de betrokkene of op basis van een wettelijk voorschrift. Het Security Safeguards Principle Persoonlijke gegevens moeten worden beschermd op basis van redelijke beveiligingsnormen tegen verlies, ongeautoriseerde toegang, vernietiging, gebruik, verandering of verstrekking van deze gegevens. Het Openness Principle Er dient openheid te worden gegeven over ontwikkelingen, praktijken en beleid in relatie tot persoonlijke gegevens. Het Individual Participation Principle Een persoon moet het recht hebben om van een verantwoordelijke te weten te komen of gegevens over hem of haar worden verwerkt. Het Accountability Principle De verantwoordelijke is verantwoordelijk om zich te houden aan maatregelen voor het uitvoeren van deze beginselen.

Bovenstaande principes worden in 2007 nader uitgewerkt naar een nieuw privacybeleid voor de gemeente Amsterdam. Een uitgebreide versie van deze principes zijn te vinden in bijlage 12. 6.6.2


Verdere uitwerking vindt nog plaats in samenwerking met het Platform Informatiebeveiliging.

6 - 20



6.7

Conclusies

1. Het gemeentelijk informatiemodel van het concern Amsterdam bestaat uit zes basisregistraties en enkele kernadministraties; 2. De basisregistraties (Personen, Bedrijven, Adressen, Gebouwen, Percelen en Topografie) vormen een samenhangend stelsel en het gebruik is wettelijk verplicht. Het vormt dan ook de standaard in Amsterdam. 3. De volgende administraties worden als kandidaat kernadministraties beschouwd waarvoor net als bij de basisregistraties de grondslag ‘éénmalige opslag, meervoudig gebruik’ geldt: a. Bestuursinformatie (Andreas) b. Bouwprojecten en woningregistraties (BWT) c. Erfpacht d. Handhaving e. Onderwijs en jeugd f. Opleidingen nieuwkomers (Edisa) g. Werknemergegevens (P-net) h. Woningbouwlocaties i. Woonprojecten (BWV) j. Zakenmagazijn De beheerders en ontwikkelaars van deze registraties dienen deze uit te werken voor de volgende versie van het handboek. conclusies informatiearchitectuur

4. Binnen de informatiearchitectuur volgt Amsterdam zo veel mogelijk de landelijke modellen. Daar waar nodig worden de landelijke modellen aangevuld. 5. Uitwisseling met de basisregistraties en kernadministraties vindt plaats volgens het standaard uitwisseling formaat StUF 2.x. 6. De ontwikkeling van een concernbreed zakenmagazijn heeft prioriteit. Het informatiemodel voor dit zaakmagazijn wordt opgezet conform de landelijk standaard (GFO-Zaken). 7. Met het oog op eenduidige informatie naar de burger wordt het GFO Zaken niet alleen op concernniveau, maar ook op niveau van stadsdelen, diensten en bedrijven gebruikt. 8. Er zijn standaarden benoemd voor o.a. het uitwisselen van berichten, basisregistraties, digitaal informatiebeheer en datamodellering. 9. Er dient een objectenmodel te komen (inclusief standaarden) voor het digitaal dossier. 10. Concernsamenwerking rond persoonsgegevens in zowel kernadministraties als de basisregistratie Personen vereist eenduidige normen en een duidelijke verdeling van verantwoordelijkheden op het gebied van privacybescherming.

6 - 21


applicaties: hebben betrekking op bedrijfsprocessen


7

Applicatiearchitectuur

7.1

Inleiding

De applicatiearchitectuur richt zich op functionele aspecten van de informatiehuishouding. Het beschrijft de functionaliteit van applicaties (ook wel ‘systemen’ in de volksmond) om processen te ondersteunen. Er is dan ook een directe relatie tussen enerzijds de applicatiearchitectuur en anderzijds de proces- en informatiearchitectuur. De applicatiearchitectuur is daarnaast ook nauw gerelateerd aan de infrastructuurarchitectuur. Deze laatste bevat namelijk naast ‘harde’ ICT-middelen (zoals pc’s en servers) ook applicaties. Het verschil zit ‘m erin dat de applicaties binnen de infrastructuurarchitectuur niet op een specifiek proces betrekking hebben. Ze zijn generiek. Denk daarbij bijvoorbeeld aan software voor tekstverwerking of e-mail. In de praktijk zien we de scheiding tussen de applicatie- en de infrastructuurarchitectuur verschuiven: functies rond datacommunicatie en dataopslag - die oorspronkelijk deel uit maakten van systemen rond één bedrijfsproces - worden generiek en verschuiven zo naar de infrastructuurarchitectuur.

vier dominante ontwikkelingen

1) ketenprocessen

De invulling van de applicatiearchitectuur wordt mede bepaald door ontwikkelingen op de andere architectuurlagen. De vier meest dominante ontwikkelingen zijn: • Stroomlijning van ketenprocessen • Ontsluiting van basisregistraties en kernadministraties • Vergroting flexibiliteit van ICT • Verhoging efficiëntie van inzet ICT Binnen concernverband worden afzonderlijke deelprocessen veel directer in verband gebracht met de ketenprocessen waarvan ze in feite onderdeel uitmaken. De afzonderlijke deelprocessen van het hoofdproces Dienstverlenen (intake, behandelen, leveren) verlopen bij een aantal processen over meerdere schijven. Dit leidt uiteindelijk tot één gemeentelijk product dat voor de klant een toegevoegde waarde heeft, zoals de levering

7-1



van een rolstoel. 2) basisregistraties en kernadministraties

In de informatiearchitectuur geldt de grondslag van ‘éénmalige opslag, meervoudig gebruik’ voor basisregistraties en kernadministraties. Deze moeten overal beschikbaar zijn binnen processen en systemen (applicaties) waar zij relevant zijn. Dit kan in de vorm van raadpleegbare informatie, maar ook als onderdeel van dataverzamelingen die in specifieke deelprocessen waardevol zijn.

3) flexibiliteit

De dynamiek op alle lagen van de architectuur vraagt om flexibiliteit. ICTmiddelen - zowel applicaties als de onderliggende infrastructuur - dienen flexibel inzetbaar zijn zodat zij kunnen meebewegen met deze dynamiek.

4) efficiëntie

“Niet meer uitgeven dan nodig” is het doel. Binnen de applicatie- en infrastructuurarchitectuur liggen kansen om deze te realiseren.

huidige

Het huidige Amsterdamse applicatielandschap is er nog niet volledig op ingericht om deze ontwikkelingen te ondersteunen. We zien de volgende belemmeringen: • Verticale inrichting Applicaties zijn op dit moment per organisatie (dienst, bedrijf, stadsdeel) ingericht en daarbinnen per probleemveld of behoefte. Deze vorm van inrichting wordt ook wel ‘verticale silo’s’ of ‘eilandautomatisering’ genoemd. • Monolitische inrichting Informatiesystemen zijn ingericht als monolithische blokken oftewel ze vormen één homogeen geheel. Daarmee zijn ze gesloten voor de omgeving en bijna onmogelijk ‘op te hakken’ in verschillende deeloplossingen. • Versnipperde inrichting De praktijk is dat er per probleemveld of behoefte naar een nieuwe oplossing wordt gezocht. Het aantal oplossingen is hiermee op dit moment zeer gevarieerd en we missen schaalvoordelen (door overlap in type oplossingen).

applicatielandschap kan ontwikkelingen niet ondersteunen

Deze problematiek is overigens niet uniek voor Amsterdam. Ze is nationaal en internationaal zichtbaar bij grote organisaties in de publieke en private sector. naar een service gerichte architectuur

Over de oplossingsrichting bestaat consensus. Amsterdam moet toewerken naar een zogenaamde service gerichte architectuur, zoals ook in Hoofdstuk 5 aangegeven: een architectuur waarbinnen processen zijn opgedeeld in componenten en de techniek (applicaties en infrastructuur) meer en meer op een standaard manier wordt ingevuld. De technische bouwblokken behoren daarbij niet langer exclusief tot een bepaalde applicatie, maar kunnen van verschillende kanten worden aangeroepen. De belangrijkste gevolgen van deze strategie voor de inrichting van de applicatiearchitectuur zijn: 1. Integratie van presentatiefuncties; 2. Openheid bij de inrichting van applicaties en gemeenschappelijke

7-2



integratievoorzieningen; 3. Gemeenschappelijke ontwikkeling en beheer van applicaties; 4. Standaardisering van functies; 5. Modulaire opbouw van applicaties. 1) integratie presentatiefuncties

2) openheid & gemeenschappelijke integratievoorzieningen

3) gemeenschappelijke ontwikkeling en beheer

4) standaardisering functies

Een éénduidig gezicht en een éénduidig geluid in de communicatie met burgers, bedrijven en instellingen is nodig. Dit vergt aanpassing van de applicatiefuncties voor de front office, ongeacht het kanaal waarlangs communicatie plaatsvindt (internet, email, telefoon, balie). Applicaties dienen open te worden ingericht voor hun omgeving, zodat zij kunnen worden geïntegreerd met andere applicaties (= verbeterde interoperabiliteit). Verder worden applicaties ondersteund door gemeenschappelijke voorzieningen voor integratie. Er moet een zogenaamde Servicebus Amsterdam komen om het in Hoofdstuk 4 beschreven uitgangspunt van ‘koppelen’ technisch te ondersteunen. Vanuit architectuur is het uitgangspunt dat applicaties of onderdelen daarvan met een generiek karakter waar mogelijk onder gemeenschappelijke aansturing worden gebracht. Bij de besluitvorming hierover kunnen overigens ook andere factoren een rol spelen. Functies worden zodanig ingericht dat zij voldoen aan internationale, nationale en Amsterdamse standaarden.

5) modulaire opbouw

Applicaties worden in (standaard) modules of componenten verdeeld, die onafhankelijk van elkaar flexibel kunnen worden ingezet.

service gerichte

Het toewerken naar een service gerichte architectuur is niet iets exclusiefs voor de applicatiearchitectuur. Om succesvol te zijn is het noodzakelijk dat ook de proces-, informatie en infrastructuurarchitectuur worden aangepast aan de eisen van een service gerichte architectuur.

architectuur heeft consequenties voor alle architectuurlagen

7-3



7.2

Grondslagen

De volgende uitspraken zijn richtinggevend en kaderstellend voor de applicatiearchitectuur: grondslag 4.1

Applicaties zijn modulair opgebouwd zodat functies kunnen worden hergebruikt.

grondslag 4.2

Applicaties zijn gebaseerd op open standaarden en platform onafhankelijk.

grondslag 4.3

De gemeente Amsterdam maakt maximaal gebruik van standaard componenten.

7-4



7.3

Modellen

7.3.1

Typologie applicatielandschap

Presentatielaag

Integratielaag

Model 7.1 Typologie applicatielandschap (globaal)

De laag dom einen

Datalaag [Bron: Adviesgroep Architectuur] Bij de inrichting van het Amsterdamse applicatielandschap kijken we naar de bedrijfsmatige (functionele) aspecten van de applicaties. We onderscheiden op functioneel niveau vier verschillende lagen (zie Model 7.1): 1. de presentatielaag 2. de integratielaag 3. de laag domeinen 4. de datalaag In de presentatielaag zijn alle functies ondergebracht die te maken hebben met de interactie tussen gemeente en de ‘buitenwereld’, waaronder samenwerkingspartners, burgers en ondernemers. Ook de interne medewerkers wordt als (doel)groep daarin meegenomen. Dit wordt ook wel met de front office geïdentificeerd. De integratielaag bevat functies die het mogelijk maken om gegevens te kunnen uitwisselen tussen de lagen presentatie, domeinen en data. Dit wordt ook wel met de mid office geïdentificeerd. Een applicatiedomein is makkelijk te vereenzelvigen met (op organisatieniveau) een dienst of stadsdeel of (op infrastructuurniveau) een netwerk van een deelnemer in de E-net infrastructuur. Binnen het Amsterdamse applicatielandschap wordt met de laag domeinen echter gedoeld op functies binnen de inhoudelijke domeinen (beleidsterreinen) waar de gemeente zijn primaire processen heeft geconcentreerd. In de referentie-

7-5



architecturen van onder andere NORA en EGEM (zie Bijlage 13) worden deze domeinen meestal aangeduid als back office. In de datalaag worden de basisregistraties en kernadministraties beschikbaar gesteld aan de overige applicatielagen. Dit kan rechtstreeks naar de laag domeinen of via de integratielaag.

P ost

B a lie

T e le fo o n

E - m a il

In te r n e t

Presentatie

Hieronder worden deze lagen één voor één langsgelopen, in een aantal gevallen in meer detail. C hat

K a n a le n

O n d e r s te u n e n k la n t

C la s s ific e r e n k la n t v r a a g

P r e s e n t a tie in t e g r a t ie

B e h e e r f u n c t ie s

B e h e r e n s e r v ic e s

A u t h e n t ic e r e n & a u t o r is e r e n

Integratie

U itw is s e le n b e r ic h t e n

R e g is s e r e n p r o c e s s e n

T o e g a n g v e r le n e n r e g is t r a t ie s

R e g is t r e r e n z a k e n

G egevensm a g a z ijn e n

Z a k e n m a g a z ijn

Model 7.2 Typologie applicatielandschap:

B e la s t in g e n / E r f p a c h t

P r o c e s s p e c if ie k e f u n c t ie s W e r k e n In k o m e n

B a s is r e g is t r a tie s

Domeinen

functies

Ondersteunende

functies

Management

functies

functies

Ondersteunende

P r o c e s g e n e r ie k e f u n c t ie s

P r o c e s s p e c if ie k e f u n c t ie s M a a t s c h a p p e lijk e O n t w ik k e lin g

K e r n a d m in is tr a tie s

Data

P r o c e s s p e c if ie k e f u n c t ie s

Management

functies

functies

Management

P r o c e s g e n e r ie k e f u n c t ie s Ondersteunende


uitwerking presentatielaag

[Bron: Adviesgroep Architectuur] Presentatie is een verwijzing naar de visuele presentatie van een applicatie die een gebruiker op zijn beeldscherm ziet. De wijze waarop de klant contact heeft met de gemeente hoeft uiteraard niet beperkt te zijn tot communicatie via een beeldscherm. Ook bij een balie (baliescherm), post (inscannen) en telefoon (voice response) is er sprake van ICT-ondersteuning. Deze onderdelen van de presentatielaag worden omschreven als kanalen. In Model 7.2 zijn deze kanalen op de bovenste rij in de presentatielaag weergegeven. Achter de kanalen wordt een aantal functies ingericht, die bedoeld zijn om het contact met de gebruiker te ondersteunen. In Model 7.2 zijn de volgende functies onderscheiden: • Ondersteunen klant: het informeren van de klant; • Classificeren klantvraag: het verzorgen van de intake van de klant; • Presentatie integratie: het verzorgen van een eenduidige presentatie (vorm en inhoud) aan de klant; • Beheerfuncties: het aanpassen van inhoud en vorm door de beheerder van de presentatievoorziening 21. 21

Dit is dus een functie die niet op een klant gericht is, maar op een beheerder.

7-6



In Bijlage 12 zijn de kanalen en functies verder uitgewerkt. Amsterdam kent al diverse voorzieningen gericht op één of meer specifieke kanalen en/of functies. De gewenste situatie is echter nog niet bereikt (zie kader). Kader: De noodzaak van een éénduidig gezicht en een éénduidig geluid De huidige ‘eilandautomatisering’ in Amsterdam maakt dat de elektronische dienstverlening aan Amsterdamse burgers en bedrijven versnipperd is. Dit ondanks het feit dat er de afgelopen jaren al veel is verbeterd en het gebruik van gemeenschappelijke voorzieningen toeneemt. Toch heeft elk organisatieonderdeel vaak nog een eigen loket als schil rond de eigen applicaties aangelegd. Dit is niet goed voor de kwaliteit van de dienstverlening. Het leidt bijvoorbeeld tot: • verschillen in toegankelijkheid en bereikbaarheid van onderdelen van het concern Amsterdam; • overlap in de externe communicatie met Amsterdammers; • aanbod- in plaats van vraaggestuurde dienstverlening: de Amsterdammer kan nog onvoldoende zelf ‘aan het stuur zitten’ en niet overal naartoe ‘rijden’ omdat er nog geen verbindingswegen zijn. Om dit te doorbreken is een éénduidig gezicht en een éénduidig geluid aan burgers, bedrijven en instellingen nodig. De buitenwereld moet met de gemeente kunnen communiceren, onafhankelijk van de interne procesinrichting van het concern en dat betekent: • Eén loket gedachte, met meerdere kanalen naar de klant, maar met één gezicht vanuit het perspectief van dienstverlening; • Eenmalige informatieaanlevering, met de mogelijkheid van regie over eigen persoonsgegevens; • Eenmalige registratie: basisregistraties en kernadministraties • Eenmalige aanmelding en authenticatie (het zogenaamde single sign on) bij communicatie met de overheid. Dit vergt aanpassing van de presentatielaag in de applicatiearchitectuur van het concern Amsterdam. Dit laat onverlet dat er al een aantal gemeenschappelijke presentatievoorzieningen is dat hierbij zeer bruikbaar is: Amsterdam.nl www.amsterdam.nl vormt meer en meer het centrale informatieportaal van de gemeente. We zien steeds meer dat Amsterdamse organisaties er de voorkeur aan geven hun publieksinformatie binnen een thematisch gedeelte van www.amsterdam.nl te ontsluiten boven organisatiespecifieke profilering. Deze trend moet verder worden versterkt. Intranet Amsterdam Voor binnengemeentelijke informatie-uitwisseling en samenwerking is er een interne informatieportaal, Intranet Amsterdam. Wat nog ontbreekt is een mechanisme om de uitwisseling vanuit lokale intranetten te faciliteren met de informatieportaal en andersom.

7-7



Loket Amsterdam Loket Amsterdam is de naam van het internetloket van de gemeente Amsterdam. Via dit loket (een onderdeel van www.amsterdam.nl en onderdeel van de stadsdeel websites) kunnen burgers en ondernemers informatie vinden over gemeentelijke producten en kunnen veel producten ook direct worden aangevraagd met behulp van digitale formulieren. Het Loket biedt hulp bij het invullen, bijvoorbeeld door niet-relevante vragen over te slaan. Digitaal verstuurde formulieren komen automatisch terecht bij de afdeling die de aanvraag afhandelt en het Loket houdt de status van afhandeling bij. Diensten of stadsdelen kunnen zelf een deel van de informatie die gepubliceerd is op het Loket aanpassen en actualiseren. Portaal Amsterdam Portaal Amsterdam is een softwarevoorziening die ‘achter de schermen’ zorgt voor vraaggerichte, gebruiksvriendelijke en goed beheerbare informatieportalen, zoals Amsterdam.nl, Intranet en Loket Amsterdam. Portaal Amsterdam faciliteert de ontwikkeling van themaportalen tegen beperkte inspanningen met hergebruik van zowel informatie als techniek. Portaal Amsterdam bundelt informatie en systemen en past de presentatie aan binnen de context van de gebruiker, intern of extern. Portaal fungeert als het ware als schakel tussen bepaalde frontoffice en backoffice applicaties. Gebruikers zien een eenduidige presentatie voor zich en kunnen daarbinnen meerdere systemen raadplegen en gebruiken. Themaportalen kunnen algemeen van opzet zijn (“Verhuizen”) of specifiek op een persoon en een onderwerp (Mijn WOZ-belastingen). Antwoord Antwoord biedt een toegankelijke, herkenbare en eenduidige dienstverlening via diverse beschikbare kanalen voor alle Amsterdammers, namens de gehele gemeentelijke organisatie. Antwoord is goed bereikbaar via telefonie, internet en e-mail. In een later stadium komt hier de balie bij. Antwoord beantwoordt uiteindelijk 80% van de binnenkomende informatievragen. Voor de behandeling van klachten, meldingen en meer ingewikkelde vragen wordt gerouteerd naar de juiste organisatieonderdelen.

7-8



A a n vra g e n d e A a n vra g e n d e

A a n vra g e n

U itw is s e le n b e ric h te n

B e h e re n s e rvic e s

A u th e n tic e re n & a u to ris ere n

R e g is s e re n p ro c e s s e n


G e g e ve n s m a g a z ijn e n

Toegang v e rle n e n re g is tra tie s

Zaken m a g a z ijn

R e g is tre re n zaken

uitwerking integratielaag

A fh a n d e le n


B a s is re g is tra tie e n k e rn a d m in is tra tie s

[Bron: Adviesgroep Architectuur] Integratie bestaat uit een samenstel van applicatieve en infrastructurele componenten met als doel om datacommunicatie tussen informatiesystemen tot stand te brengen. Integratie is een leidend thema in gemeentelijke en landelijke architecturen van NORA en EGEM. Zie Bijlage 13 voor een beschrijving van de landelijke ontwikkelingen. “Niet kantelen, maar koppelen” is een van de strategische speerpunten van NORA waarmee tot uitdrukking komt dat samenwerking tussen overheidsorganisaties niet direct hoeft te leiden tot structuurveranderingen maar ook kan worden benaderd vanuit integratie. Kopplen geldt sowieso ook voor de architectuur van het concern Amsterdam. Wel is het zo dat in Amsterdam ook kantelingen worden doorgevoerd om daadwerkelijk verbeteringen in dienstverlening en handhaving te kunnen bereiken. Integratiefuncties ondersteunen op verschillende niveaus zoals processen (bijv. tijdsbewaking, monitoring), informatie (verschillen in semantiek en syntax), applicaties (koppelen van zeer uiteenlopende systemen op een beveiligde en stabiele manier) en infrastructuur (locatie onafhankelijk werken). Integratie is dus geen zuiver technische oplossing binnen de applicatiearchitectuur, maar strekt zich uit over alle architectuurlagen. Voor een duidelijke afbakening van de in deze applicatiearchitectuurlaag terugkerende begrippen als proces, service, applicatie en bericht verwijzen wij naar Bijlage 1, waar deze begrippen nader worden gedefinieerd. In Model 7.3 is zichtbaar welke hoofdfuncties in de integratielaag van de applicatiearchitectuur terugkomen: 1. Uitwisselen berichten; 2. Beheren services; 3. Authenticeren en Autoriseren; 4. Toegang verlenen tot registraties; 5. Registreren zaken;

7-9



6. Regisseren processen. De eerste functie is dé verbindende schakel bij de communicatie. Dat is de reden waarom deze functie rondom de overige functies in de vorm van een hoefijzer is weergegeven. Deze zes functies samen worden ook aangeduid als de ‘integratievoorziening’ of de ‘Servicebus Amsterdam’ Kader: De noodzaak van een servicebus Aan een gemeenschappelijke integratievoorziening is in Amsterdam behoefte. Een simpel voorbeeld laat dit zien. In een situatie waarin een beperkt aantal diensten en stadsdelen elk van één of enkele basisregistraties gebruik gaat maken met open applicaties valt goed te werken. Dit is de situatie waarmee nu gewerkt wordt. Dienst 1

Dienst 2

Dienst 3

Stadsdeel A

Stadsdeel B

Personen

Vastgoed

Bedrijven

Na verloop van tijd zullen steeds meer diensten en stadsdelen met veelal gesloten applicaties moeten gaan communiceren met alle basisregistraties. Bovendien zal het aantal basisregistraties en kernadministraties toenemen. De oorspronkelijk nog overzichtelijke situatie dijt uit naar een onoverzichtelijke wirwar aan verbindingen en transformaties. Een stelsel van bilaterale afspraken begint dan een chaotisch spinnenweb te worden. Om dat te voorkomen wordt een servicebus geïntroduceerd.

Dienst 1

Dienst 2

Vastgoed

Dienst 3

Personen

Dienst 4

Bedrijven

Dienst 5

Stadsdeel A

Basisregistratie X

Stadsdeel B

Kernadministratie Y

Ook in de NORA is integratie van informatiesystemen een centraal thema. NORA positioneert de servicebus als centraal concept voor integratie binnen overheidslagen, tussen overheid en externe groepen en tussen overheidslagen onderling. De benadering die wordt voorgesteld, is dat GBO.Overheid zorgt voor een landelijke overheidsservicebus, die weer moet

7 - 10



aansluiten op Europees niveau en op bijvoorbeeld het bedrijfsleven. Ook om in de pas te lopen met deze landelijke ontwikkeling is de realisatie van een servicebus nodig in Amsterdam.

Dienst 1

Dienst 2

Dienst 3

Dienst 4

Dienst 5

Stadsdeel A

Stadsdeel B

Servicebus

Vastgoed

Tabel 7-1 Uitwerking functies integratielaag

Personen

Bedrijven

Functie 1. Uitwisselen berichten 2. Beheren services 3. Authenticeren en Autoriseren 4. Toegang verlenen tot registraties 5. Registreren zaken 6. Regisseren processen

Basisregistratie X

Kernadministratie Y

Architectuurlaag Infrastructuurarchitectuur


In Tabel 7-1 is aangegeven dat de zes hoofdfuncties in de integratielaag verdeeld zijn over de applicatie- en infrastructuurarchitectuur. De functies 1 t/m 3 zijn algemeen van karakter. Ze vormen in feite een extra functie bovenop de datacommunicatie van het netwerk. Ze worden daarom beschouwd als infrastructurele voorzieningen. In paragraaf 8.3.2 worden deze functies toegelicht. De functies 4 t/m 6 daarentegen vormen functionaliteit die een beheerder of gebruiker direct ervaart en direct ondersteuning biedt. Ze zijn als het ware gekoppeld aan een specifieke handeling. Daarmee zijn het functies binnen de applicatiearchitectuur. Deze lichten we hieronder toe. Ad 4. Toegang verlenen tot registraties Toegang tot de registraties gaat in de eerste plaats over de toegang tot de basisregistraties en kernadministraties. De applicaties die registraties distribueren - zoals Paraplu en Diva - maken deel uit van de integratievoorziening. Ze verlenen toegang tot registraties aan een afnemer: een afnemende organisatie met of zonder afnemende applicatie(s). Dit doen ze (nu nog) middels een directe koppeling met de afnemer. Als er een Servicebus Amsterdam is, kunnen ze functioneren als een onderaannemer van de servicebus voor de berichtenuitwisseling. De servicebus functioneert dan als de verbindende logische schakel. De applicaties die de registraties distribueren, wisselen berichten uit met de afnemer. De afnemer regelt vervolgens zelf de verwerking van de berichten, conform de procedurele afspraken die daarover zijn gemaakt met de

7 - 11



registratiehouder. Alle berichten die worden ontvangen, moet de afnemer doorgeven naar het juiste proces en de juiste applicatie. In het volgende kader en in Bijlage 12 is dit verder uitgewerkt. Ad 5. Registreren zaken Een zaak omvat alle binnenkomende informatievragen en verzoeken van externe klanten. Alle zaken worden binnen één centraal zakenmagazijn geregistreerd en over meerdere (dienstverlenings)processen heen bijgehouden. In een zakenmagazijn wordt voor iedere specifieke zaak een dossier geopend. Daarin wordt precies bijgehouden hoe het met de zaak staat (wanneer contact geweest is met wie, deadline levering), zodat onder meer de front office direct aan de klant kan laten weten wanneer bijvoorbeeld de dienst geleverd wordt. De gegevens die door de klant zijn ingebracht (Burger Service Nummer, verzoek) worden aangevuld met beschikbare basisgegevens en klantgegevens uit eerdere contacten. Vanuit een zaakdossier wordt de vraag direct afgehandeld of doorgezet naar de behandelaars. Ook de routering naar het behandelende organisatieonderdeel en de terugkoppeling van de status en het resultaat van de behandeling, wordt in het zaakdossier opgeslagen. Ad 6. Regisseren processen Sommige berichten moeten door meer dan één back office worden verwerkt. Zo moet bijvoorbeeld een adreswijziging van een burger worden verwerkt in allerlei systemen. Er is daarom een functie nodig die zorgt voor de regie van verschillende deelactiviteiten dat wil zeggen de bewaking en aansturing over het gehele (keten)proces heen, van startpunt tot en met afronding. Dit wordt ook wel Business Process Management (BPM) genoemd. Procesregie vindt bij uitstek plaats wanneer sprake is van meerdere partijen, meerdere systemen, meerdere medewerkers en handelingen die dan wel geautomatiseerd dan wel handmatig worden uitgevoerd. Procesregie is ook noodzakelijk bij het raadplegen van gegevens uit meerdere registraties (zie bij ‘ad 4’). Stelt de applicatie van een afnemer een samengestelde vraag aan twee of meer registraties, dan kan deze functie de beantwoording van de vraag regisseren. De regie vindt plaats op basis van gelijkwaardigheid (choreografie) of hiërarchie (orkestratie). In het kader is aangegeven welke voorzieningen we nu al hebben binnen de integratielaag van de applicatiearchitectuur. Kader: Wat is er in Amsterdam al aan gemeenschappelijke integratievoorzieningen? Voor Amsterdam vormt integratie een relatief nieuw terrein. Er zal een flinke slag gemaakt moeten worden om te komen tot het eindbeeld van een architectuur met een Servicebus Amsterdam die alle zes genoemde integratiefuncties levert (zie ook paragraaf 8.3.2 ). Wel is zichtbaar dat eerste stappen zijn gezet. Ad 4. Toegang verlenen tot basisregistraties Amsterdam beschikt over een gemeenschappelijke oplossing voor het distribueren en ontsluiten van de basisregistratie Personen: Paraplu. Idem voor de basisregistratie Vastgoed: Diva. Paraplu en Diva beschikken over een

7 - 12



eigen gegevensmagazijn en koppelen (nu nog) direct met afnemers. Als er een Servicebus Amsterdam is, kunnen ze functioneren als een onderaannemer van de servicebus voor de berichtenuitwisseling. De servicebus functioneert dan als de verbindende logische schakel. In Bijlage 14 worden Paraplu en Diva nader toegelicht. Ad 5. Registreren zaken Amsterdam kent nog niet één gemeenschappelijke oplossing voor de registratie van zaakgegevens. Binnen een aantal grote organisaties (DMO, DWI, Antwoord) zijn er wel plannen om een zakenmagazijn te creëren in 2006. In de Pilot Broker van DMO worden verder ervaringen opgedaan die voor een generieke inrichting van een zakenmagazijn kunnen worden meegenomen. Het is wenselijk toe te werken naar één gemeenschappelijke voorziening voor alle dienstverlening. Ad 6. Regisseren processen Amsterdam kent nog geen generieke oplossingen voor procesregie. Bij DMO loopt in de tweede helft van 2006 een ‘Pilot Broker’ waarbij procesregie in de WMO-keten een grote rol speelt. In de Pilot worden generieke herbruikbare onderdelen ontwikkeld en ervaringen opgedaan die vanaf 2007 ook bij de besturing van andere ketenprocessen kunnen worden ingezet.

P ost

B a lie

T e le fo o n

E - m a il

In te r n e t

Presentatie

Om tot één Servicebus Amsterdam te komen die alle zes genoemde integratiefuncties levert adviseert de Adviesgroep Architectuur om een stapvoor-stap benadering te volgen: van een dunne bus naar een dikke bus met de functies 1 t/m 4 als prioriteit.

C hat

K a n a le n

O n d e r s t e u n e n k la n t


P r e s e n t a tie in t e g r a t ie



A u t h e n tic e r e n & a u t o r is e r e n

Integratie




R e g is t r e r e n z a k e n




B e la s t in g e n / E r f p a c h t

B a s is r e g is t r a tie s

P r o c e s s p e c if ie k e f u n c t ie s W e r k e n In k o m e n

Domeinen

functies

Ondersteunende

functies

Management

functies

Ondersteunende


P r o c e s s p e c if ie k e f u n c t ie s M a a t s c h a p p e lijk e O n t w ik k e lin g


Data


functies

Management

functies

functies

Management

P r o c e s g e n e r ie k e f u n c t ie s Ondersteunende

P r o c e s g e n e r ie k e fu n c t ie s

uitwerking laag domeinen

[Bron: Adviesgroep Architectuur] Met domeinen wordt gedoeld op inhoudelijke domeinen (beleidsterreinen)

7 - 13



waar de gemeente zijn primaire processen heeft geconcentreerd. Dit wordt ook wel de back office genoemd. De domeinen zijn in Model 7.4 van deze architectuur ingedeeld in vier functionele clusters: Processpecifieke functies Dit zijn functies die ontstaan ter ondersteuning van specifieke bedrijfsprocessen die uniek zijn binnen de gemeente. Het gaat vrijwel altijd om functies waarbij de inhoud van het proces in de functie is verweven, zoals het registreren van erfpachtbelasting of de vaststelling van het recht op bijstandsuitkering. Procesgenerieke functies Dit zijn functies die in meerdere, zo niet alle bedrijfsprocessen voorkomen. Een goed voorbeeld is het beheer van werkstromen. In de meeste processen speelt een combinatie van werkverdeling en tijdsbewaking een rol. Deze kunnen daarom generiek ondersteund worden met zogenaamde work flow management functies. Hetzelfde geldt bijvoorbeeld voor functies voor documentbeheer. Ondersteunende functies Dit zijn alle functies die ten bate staan van het hoofdproces Ondersteunen. Het worden ook wel secundaire of bedrijfsvoeringsprocessen genoemd en aangeduid met de afkorting PIJOFAH. Strikt genomen vormen zij een bijzondere vorm van procesgenerieke functies. Voorbeelden zijn functies op het gebied van financiële boekhouding of personeelsadministratie. Managementfuncties Ook dit zijn een bijzondere vorm van procesgenerieke functies. Het is functionaliteit voor het verzamelen, aggregeren, interpreteren en weergeven van informatie ten behoeve van management en bestuur. Managementinformatie is gebaseerd op de informatie die in de primaire processystemen is opgeslagen. Een voorbeeld is dat vanuit een workflow functie de doorlooptijden over alle geregistreerde behandelprocessen wordt bijgehouden en gepresenteerd inclusief gemiddelden en afwijkingen van de afgesproken doorlooptijden Kader: De noodzaak van standaarden in de laag domeinen Applicaties zijn nu in hoofdzaak ‘organisatiegebonden’. Elke gemeentelijke organisatie in Amsterdam is vrijwel autonoom in de keuze van applicaties, hoe die zijn ingericht en wie ze mogen gebruiken. En over het algemeen bevinden ze zich ook in de infrastructuur van de betreffende organisatie. Feitelijk vormt de applicatiehuishouding van een dienst nu een gesloten domein, met eigen regels en standaarden. Binnen zo’n domein zijn applicaties redelijk op elkaar afgestemd en afstemming met applicaties van derden gebeurt voornamelijk op ad-hoc basis. Het voordeel van deze autonomie is dat elke organisatie applicaties kan gebruiken die het best aansluiten op de interne bedrijfsvoering en die ‘passen’

7 - 14



P o st

B a lie

T e le fo o n

E - m a il

In te rn e t

Presentatie

in de ‘eigen’ infrastructuur. Maar de autonomie leidt ook tot versnippering. Verschillende diensten gebruiken voor dezelfde functionaliteit verschillende applicaties. Soms zijn er zelfs binnen één organisatie meerdere oplossingen voor dezelfde functie. Ook in geval van het gebruik van dezelfde applicaties verschilt de inrichting nogal eens per dienst. Deze versplintering brengt extra kosten met zich mee en bemoeilijkt de uitwisseling van gegevens. Het realiseren van een Andere Overheid vraagt om samenwerking tussen concernonderdelen. Meer standaardisering in de laag domeinen is daarvoor een noodzakelijke voorwaarde.

C hat

K a n a le n



P r e s e n ta tie in t e g r a tie

B e h e e r fu n c t ie s



A u t h e n t ic e r e n & a u to r is e r e n



R e g is tr e r e n z a k e n




B e la s tin g e n / E r f p a c h t

P r o c e s s p e c ifie k e f u n c tie s W e r k e n In k o m e n

B a s is r e g is tr a tie s

Domeinen

functies

Ondersteunende

functies

Management

functies

Ondersteunende

functies

Management

P r o c e s g e n e r ie k e fu n c tie s

P r o c e s s p e c if ie k e f u n c t ie s M a a ts c h a p p e lijk e O n tw ik k e lin g


Data

P r o c e s s p e c ifie k e fu n c tie s

functies

functies

Management

P r o c e s g e n e r ie k e fu n c t ie s Ondersteunende


uitwerking datalaag

[Bron: Adviesgroep Architectuur] In de datalaag worden de basisregistraties en kernadministraties beschikbaar gesteld aan de overige applicatielagen. In de toelichting op Model 7.3 en in paragraaf 6.3.2 en 6.3.3 is hier al uitgebreid bij stilgestaan.

7 - 15


P ost

B a lie

A NaAil EK -m R e sp o n se (A n tw o o rd )

KTAeNle A fo Co Cn (A n tw o o rd )

InLte o krn e te t

Presentatie


Chat

A ’d a m

K a n a le n lo k e t A ’d a m A tla s A ’d a m

P o rta a l A ’d a m



W e b in a b o x P lu g a n d p la y

P r e s e n ta tie in te g r a tie


BEA W LI

A A A s e rv e r




T o e g a n g v e r le n e n r e g is t r a tie s

Model 7.6 Typologie


Integratie



P a ra p lu D iv a


KANA CC (A n tw o o rd )

O ra c le

W e r k e n In k o m e n

functies

M a a ts c h a p p e lijk e O n tw ik k e lin g

GBS VRA


P-net

P r o c e s s p e c if ie k e fu n c t ie s

P -n e t


Data


E R IS A


Domeinen

NUS_O P


reports

Crystal

functies

Management

functies

P-net

Ondersteunende

reports

P-net

H e rm e s

Crystal

D o c u m e n tu m

functies

D o c u m e n tu m

Management

D o c u m e n tu m

functies


Ondersteunende


reports


Crystal

functies

Management

uitwerking alle lagen

Ondersteunende

applicatielandschap:

[Bron: Adviesgroep Architectuur] In Model 7.6 zijn de uitkomsten van de voorgaande modellen samengenomen. Dit model vormt de uitgewerkte typologie van het applicatielandschap. In Bijlage 12 zijn de functiegroepen en onderliggende functies verder uitgewerkt.

7 - 16



7.3.2

Het huidige applicatielandschap

P o st

E -m a il

K a n a le n

In te rn e t

K a n a le n

K a n a le n

G e g e v e n s m a g a z ijn e n



G e g e ve ns u itw is s elin g

G e g e ve n s u itw is s elin g

G e g e ve n s u itw is s e lin g

Model 7.7 Het huidige versnipperde



GVI

DPG

O n d e r s te u n e n d e fu n c tie s

P r o c e s g e n e rie k e fu n c tie s

M a n a g e m e n t fu n c t

P ro c e s g e n e rie k e fu n c tie s O n d e r s te u n e n d e fu n c tie s

O n d e r s te u n e n d e fu n c tie s


P ro c e s g e n e rie k e fu n c tie s


applicatielandschap


DMO

[Bron: Adviesgroep Architectuur] Op dit moment is er van een gemeenschappelijke inrichting van zowel presentatie, integratie als data geen sprake. Integendeel, zoals in de inleiding is aangegeven, ziet het huidige applicatielandschap er “versnipperd” uit zoals weergegeven in Model 7.7. ‘Vertaling’ van bovenstaande weergave naar de typologie uit Model 7.6 leidt tot een weergave zoals in Model 7.8.

7 - 17


P ost

B a lie

A NaAil EK -m R e sp o n se (A n tw o o rd )

KTAeNle A fo Co Cn (A n tw o o rd )

InLte o krn e te t

Presentatie


Chat

A ’d a m

K a n a le n lo k e t A ’d a m A tla s A ’d a m

P o rta a l A ’d a m



W e b in a b o x P lu g a n d p la y

P r e s e n ta tie in te g r a tie


BEA W LI

A A A s e rv e r




T o e g a n g v e r le n e n r e g is t r a tie s G egevensm a g a z ijn e n

Integratie



P a ra p lu D iv a


KANA CC (A n tw o o rd )

O ra c le

Model 7.8 Het huidige

W e r k e n In k o m e n

functies

M a a ts c h a p p e lijk e O n tw ik k e lin g

GBS VRA


P-net

P r o c e s s p e c if ie k e fu n c t ie s

P -n e t


Data


E R IS A


Domeinen

NUS_O P


reports

Crystal

functies

Management

functies

P-net

Ondersteunende

reports

P-net

H e rm e s

Crystal

D o c u m e n tu m

functies

D o c u m e n tu m

Management

D o c u m e n tu m

functies


Ondersteunende


reports


Crystal

functies

Management

typologie)

Ondersteunende

applicatielandschap (in

[Bron: Adviesgroep Architectuur] In Model 7.8 is (zonder volledig te zijn 22) aangegeven dat er anno 2006 al diverse oplossingen in gebruik zijn die één of meer van de in Model 7.6 onderscheiden functies kunnen vervullen. Daarbij wordt duidelijk dat veel van deze voorzieningen elkaar aanvullen (bijvoorbeeld Portaal, Paraplu, Loket Amsterdam, Antwoord) en er nauwelijks overlap is. Tegelijkertijd dient aangetekend te worden dat het nog geen (algemeen aanvaarde) concernoplossingen zijn en dat ‘meerdere bakstenen nog geen gebouw vormen’. Ook wordt er in bepaalde (cruciale) functies rond integratie nog niet voorzien. Sommige van de oplossingen worden gemeenschappelijk beheerd (bijvoorbeeld Portaal), maar de meeste oplossingen vallen onder de verantwoordelijkheid van één of meer organisatieonderdelen. Van een gemeenschappelijke inrichting van zowel de presentatie-, integratie- en datalaag is nog geen sprake. Of dat mogelijk en wenselijk is staat in de volgende paragraaf. Antwoord is in deze context te zien als de rudimentaire aanzet tot het gemeentelijk zakenmagazijn in de integratielaag op concernniceau.

22

Zo worden bijvoorbeeld bij DBGA Filenet (procesgenerieke functie) en Cognos (management functie) gebruikt.

7 - 18


7.3.3

Het toekomstige applicatielandschap: wat kan gemeenschappelijk?

P ost

B a lie

T e le fo o n

E - m a il

In t e r n e t

Chat

K a n a le n

O n d e r s t e u n e n k la n t

C la s s i fi c e r e n k l a n t v r a a g

P r e s e n t a t ie in t e g r a t ie

B e h e e rfu n c tie s

Presentatie


B e h e r e n s e r v ic e s A u th e n tic e re n & a u to ris e re n T o e g a n g v e r l e n e n r e g is t r a t ie s

Model 7.9 Het


R e g is s e r e n p r o c e s s e n R e g is tre re n z a k e n


Integratie

U itw i s s e l e n b e r ic h t e n

P r o c e s s p e c i f i e k e f u n c t ie s B e la s tin g e n / E rfp a c h t

B a s i s r e g is t r a t ie s

G e n e r ie k e m a n a g e m e n t f u n c t ie s

P r o c e s s p e c if i e k e f u n c t ie s W e rk e n In k o m e n

G e n e r ie k e o n d e r s t e u n e n d e f u n c t ie s

P r o c e s s p e c i f ie k e f u n c t i e s M a a t s c h a p p e l ij k e O n t w ik k e l in g

K e r n a d m in i s tr a ti e s

generiek

P ro c e s g e n e rie k e fu n c tie s

Domeinen

kan gemeenschappelijk?

Data

applicatielandschap: wat

Domein

toekomstige

[Bron: Adviesgroep Architectuur] In Model 7.9 is met een arcering aangegeven welke functies binnen welke lagen van het Amsterdamse applicatielandschap gemeenschappelijk gebruikt kunnen worden. Het betreft dus de functies die de mogelijkheid in zich hebben om gemeenschappelijke ontwikkeld en beheerd te worden. Wat opvalt is dat alleen de processpecifieke functies binnen de laag domeinen buiten het gemeenschappelijk domein blijven. Wat in de praktijk wel en niet gemeenschappelijk wordt, is bij uitstek een opgave voor het management en ook een uitvloeisel van de keuzes in de organisatieen procesarchitectuur (zie kader). Heldere keuzes over onder meer de organisatie en aansturing van de vraag en het aanbod van gemeenschappelijke voorzieningen zijn daarbij noodzakelijk. Want één ding is duidelijk: een service gerichte architectuur met veel gemeenschappelijke functies is in Amsterdam niet te realiseren zonder dat ook op de andere architectuurlagen aan de eisen hiervan wordt voldaan. Los van de randvoorwaarden op hoger (en lager) gelegen lagen van de architectuur onderscheiden we binnen de applicatiearchitectuur de volgende randvoorwaarden voor gemeenschappelijke ontwikkeling en beheer: 1. Van generieke functies moet gemeenschappelijk bepaald worden wat de gewenste functionaliteit (op detailniveau) is in alle bedrijfsprocessen waarin de functie wordt toegepast; 2. Elke generieke functie moet vanuit het proces goed identificeerbaar zijn en als los gekoppelde component of service worden afgebakend; de functie dient ook te voldoen aan open standaarden; 3. In elke generieke functie wordt alleen voorzien door louter een beperkt aantal technische (software)voorzieningen die daarmee dus als standaard 7 - 19



gelden; 4. Die technische voorziening moet zodanig van aard zijn en zodanig zijn ingericht dat deze tegelijkertijd in meerdere procesfuncties kan worden benut; 5. De technische voorzieningen voldoen aan een minimumniveau van kwaliteitseisen (voor bijvoorbeeld beschikbaarheid en schaalbaarheid), zeker in het geval van toepassing in bedrijfskritische processen.

Kader: De noodzaak van heldere en veelomvattende keuzes rond gemeenschappelijke voorzieningen Besluitvorming over wat gemeenschappelijke voorzieningen zijn is helaas geen simpele architectuurkeuze binnen de applicatiearchitectuur. Het is direct gekoppeld aan keuzes die binnen de organisatieen procesarchitectuur moeten worden gemaakt. Ook moeten daarbij interne ontwikkelingen binnen de gemeente Amsterdam en externe ontwikkelingen binnen de overheid als geheel in ogenschouw worden genomen. Een aantal kernvragen om dit te illustreren: Hoe organiseren we gemeenschappelijk de vraag naar generieke functies en hoe sturen we dit aan? Het programma BRI is een Amsterdams voorbeeld hoe dit zou kunnen, maar er zijn meer opties denkbaar. Hoe organiseren we vervolgens het aanbod van het gemeenschappelijke? In het kader van het Servicehuis ICT wordt dit onderzocht, maar er zijn ook andere initiatieven zoals een gemeenschappelijke ontwikkelorganisatie voor de overheid (GovUnited) en samenwerkingsverbanden zoals die van DWI met ketenpartners. Daarbij speelt ook de vraag welke van de huidige Amsterdamse voorzieningen (die nu soms onder de verantwoordelijkheid van één organisatie vallen) gemeenschappelijk gemaakt worden. Hoe kunnen we het geheel van vraag en aanbod in een transparant en werkbaar model aansturen? Hierbij speelt bijvoorbeeld ook de vraag hoe gemeentebreed informatiemanagement en deze architectuur daarin zijn ingebed. Willen we aansluiten bij landelijke initiatieven en zo ja, bij welke wel en welke niet? In EGEM-verband zijn er bijvoorbeeld initiatieven voor de gemeenschappelijke aanbesteding van een servicebus. Doen we hier aan mee of varen we een andere koers? Heldere keuzes over de organisatie van de vraag en het aanbod, de aansturing van het geheel, de rol die Amsterdam landelijk wil spelen en het tempo waarin een en ander moet gebeuren zijn noodzakelijk om tot de verdere uitwerking en implementatie van een service gerichte architectuur te komen. Deze keuzes zijn zo veelomvattend en ingrijpend dat de Adviesgroep Architectuur hier nu geen concrete voorstellen voor kan en wil doen. Eerst zijn richtinggevende uitspraken van het bestuur en management nodig op basis waarvan deze architectuur verder kan worden uitgewerkt. Dit laat onverlet dat in de ogen van de Adviesgroep Architectuur de richting die Amsterdam op moet helder is. Een Andere Overheid vraagt om een service gerichte architectuur waarbinnen gemeenschappelijke functies centraal staan. De landelijke architectuur (NORA) stuurt hier ook onmiskenbaar op aan.

7 - 20



Kijkend naar het huidige applicatielandschap (zie Model 7.8) is zichtbaar dat er al een aantal voorzieningen is dat gemeenschappelijke functies kan vervullen en naar alle waarschijnlijkheid (deels) herbruikbaar zal zijn in een service gerichte architectuur. Het sluit ook goed aan op de trend die binnen Amsterdam zichtbaar is, een trend naar meer samenwerking en gemeenschappelijkheid. Denk daarbij bijvoorbeeld aan de programma’s BRI, en Dienstverlening (Antwoord) en de start van Servicehuizen. We zullen echter verder moeten gaan om deze service gerichte architectuur te realiseren. Aan de andere kant moeten de diensten, bedrijven en stadsdelen het tempo ook kunnen bijbenen. Dit pleit voor een stap-voor-stap benadering waarbij interoperabiliteit (het koppelen) een eerste stap is. Vervolgens kunnen eerst die functies gemeenschappelijk worden ‘gemaakt’ waar vanuit de processen (top-down) de sterkste behoefte ligt en/of de grootste efficiencyvoordelen (bottom-up) liggen. Hier ligt dus een belangrijke opdracht voor het management om een heldere koers uit te zetten.

7 - 21



7.4

Standaarden

Gemeenschappelijke voorzieningen worden in elk geval gestandaardiseerd. Standaardisatie, middels open standaarden, van gemeenschappelijke voorzieningen is een randvoorwaarde voor succes als het gaat om integratievoorzieningen (/koppelvlakken). 7.4.1

Tabel 7.2 Richtlijnen applicaties algemeen

Richtlijnen

1. Gemeenschappelijke voorzieningen worden in elk geval gestandaardiseerd. Tabel 7-4 vormt daarvoor een richtsnoer. 2. Standaardisering vindt op een zo hoog mogelijk niveau plaats 23. Dat wil zeggen dat uniforme standaarden de voorkeur genieten boven bandbreedte standaarden die weer de voorkeur genieten boven afspraken. 3. Gemeenschappelijke voorzieningen kennen uniforme standaarden voor de keuze van de applicaties. Naast de keuze voor de applicatie wordt ook de wijze waarop deze wordt gebruikt (inrichting) geüniformeerd. 4. Processpecifieke voorzieningen voldoen in elk geval aan een aantal open standaarden (zieTabel 7-5), ter bevordering van de interoperabiliteit en de mogelijkheid tot integratie. 5. Applicaties worden ingericht in minstens drie lagen (presentatielaag, applicatielaag, gegevenslaag), zijn webenabled en ondersteunen webservices. 6. Een applicatie die een functie vervult die naar zijn aard uniek is (bijvoorbeeld het meten van hoogtebouten of het registreren van verkeersborden) wordt beschouwd als uniforme standaard. Kader: Wanneer zijn we over op de standaarden? Zeggen dat je gaat standaardiseren is makkelijk, het vervolgens ook doen is een stuk lastiger. Er zal duidelijkheid moet komen over het einddoel en de snelheid van standaardisatie. Willen we uiteindelijk naar uniforme standaarden voor alle ICT (applicaties en infrastructuur) of zijn op bepaalde terreinen bandbreedte standaarden ook goed? Willen we dat over 3, 6 of 10 jaar hebben bereikt? Deze afwegingen zijn uitermate complex. De kosten en baten zullen ook niet gelijk verdeeld zijn over de diensten, bedrijven en stadsdelen. Dit zijn geen keuzes die je even bij architecten neerlegt. Het vergt integrale afwegingen en bestuurlijk lef om niet alleen te roepen dat standaardisering belangrijk is, maar het ook te doen.

Tabel 7.3 Richtlijnen voor integratie

23

7. Integratie vindt plaats binnen één platform. Integratie van applicaties in verschillende domeinen vindt alleen plaats via het platform en niet rechtstreeks.

Standaardisatie is geen doel op zich. Standaardisatie komt voort uit de bedrijfsdoelstellingen en eventueel hiermee gepaard gaande onderbouwing door business cases.

7 - 22



8. De richtlijn ‘WS-I Basic Profile’ van de Web Services Interoperability Organisation (WS-I) wordt gevolgd voor de implementatie van (open) standaarden 24. Geen standaard

Afspraken

Algemene, infrastructurele functies Integratiefuncties

secundaire Tabel 7-4

bedrijfsprocessen

Uniforme

standaarden

standaarden

8

9

8

9 9

8

Presentatiefuncties Functies voor

Bandbreedte

8

9

Richtlijn voor standaardisering

Procesgenerieke ict-

gemeenschappelijke

functies inclusief

functies

management en

8

9

ondersteuning Processpecifieke functies voor primaire bedrijfsprocessen

8

9 9

Unieke functies Legenda

8 9

= Huidige situatie = Gewenste situatie

In Bijlage 16 wordt verder ingegaan op een resulterende standaard inrichting per applicatie. 7.4.2



In onderstaande tabel zijn de uniforme standaarden opgenomen die gelden binnen de applicatiearchitectuur. Nr. en naam Standaard voor Bron standaard


Amsterdam.xsd

Schema Syntax voor Basisregistraties


BPEL

Procesorkestratie


BPMN

Procesmodellering

Voorstel

Tabel 7-5

24

De open standaarden ontwikkelen zich in de tijd en er worden regelmatig nieuwe versies van een standaard gepubliceerd. Om een goede interoperabiliteit te waarborgen heeft de Web Services Interoperability Organisation (WS-I) een richtlijn voor het implementeren van de verschillende standaarden beschreven. De richtlijn heet de ‘WS-I Basic Profile’.

7 - 23




25

Zie hoofdstuk Informatie

7 - 24

Documentum

Document management systemen

B&W-besluit 9 november 2004

GFO-2006, GFO Zaken

Objectenmodel, objectenmodel van stelsel van gemeentelijke basisgegevens resp. zaken


HTML

Ontwikkeltaal Presentatielaag


P-net

personeels- en salarisadministraties van alle gemeentelijke organisaties


SOAP

Service aanroep bij berichtuitwisseling


StUF 25

Berichtenspecificatie


UDDI

Service register


WSDL

Service beschrijving


WS-Reliability

Betrouwbaarheid van berichtuitwisseling


WSRP

Presentatie


WS-Security

Webservice beveiliging


XML

Ontwikkeltaal Gegevensopslag en uitwisseling


XML Schema

Schema Syntax


XQUERY

Data Queries


XSLT

XML Transformatie




7.4.3

Bandbreedte

In onderstaande tabel zijn de standaarden opgenomen die gelden binnen de applicatiearchitectuur. Nr. en naam Toelichting Bron standaard

Tabel 7-6 Standaarden Applicatiearchitectuur bandbreedte

Exact, Fis4all, Civision, OneWorld en Decade

preferente financiële pakketten


J2EE (Java), .Net

Ontwikkelomgeving


Kader: Juridische en aanbestedingskant van standaardisatie Er zit ook een juridische en aanbestedings kant aan het verhaal van pakket c.q. applicatiestandaardisatie. Het vaststellen van gemeentebrede ICTstandaarden is in beginsel een bevoegdheid van het college van B&W en de stadsdeelbesturen. In 2004 heeft het College bijvoorbeeld haar voorkeur uitgesproken voor een reeks van bedrijfsvoeringapplicaties (waaronder: Exact, Fis4all, Civision, ONe World, Decade en Documentum) om het aantal ICTvariaties die binnen de gemeente Amsterdam worden gebruikt, terug te dringen. Bij de selectie en inkoop van producten, waaronder bedrijfsvoeringapplicaties, is de gemeente Amsterdam verplicht zich te houden aan de geldende aanbestedingsregels. Het gewenste product moet zo objectief mogelijk worden beschreven. Het noemen van merknamen (zoals Exact, Fis4all etc.) is in beginsel niet toegestaan. 7.4.4

Afspraken Er gelden geen standaarden op het niveau ‘afspraken’.

7 - 25



7.5

Beheer

Deze paragraaf wordt in volgende versies aangescherpt door de Adviesgroep Architectuur. Daarbij zal ook worden meegenomen in hoeverre bestaande diensttakoverstijgende systemen / concernsystemen moeten worden opgenomen.


Nr. en naam model

Eigenaar

Beheerder

Model 7.1 Typologie applicatielandschap (globaal)



Model 7.2 Typologie applicatielandschap: uitwerking presentatielaag



Model 7.3 Typologie applicatielandschap: uitwerking integratielaag



Model 7.4 Typologie applicatielandschap: uitwerking laag domeinen



Model 7.5 Typologie applicatielandschap: uitwerking datalaag





Model 7.7 Het huidige versnipperde applicatielandschap



Model 7.8 Het huidige applicatielandschap (in typologie)



Model 7.9 Het toekomstige applicatielandschap: wat kan gemeenschappelijk?



Model 7.6 Typologie applicatielandschap: uitwerking alle lagen

7 - 26


Tabel 7-8 Beheer standaarden



Eigenaar

Beheerder

Amsterdam.xsd

GVI, DPG, DBGA

GVI, DPG, DBGA

BPMN

BPMI

BPMI

BPEL

OASIS

OASIS

Documentum

GAA

GAA

Exact, Fis4all, Civision, OneWorld en Decade

??

??

GFO-BG (GBR), GFO Zaken

EGEM/GBO

EGEM/GBO

HTML

W3C

W3C

J2EE (Java)

Sun

Sun

.Net

Microsoft 26

P-net

SHP

SOAP

W3C

Microsoft SHP W3C

StUF 27

EGEM

EGEM

UDDI

OASIS

OASIS

WSDL

W3C

W3C

WS-Reliability

W3C

W3C

WSRP

W3C

W3C

WS-Security

W3C

W3C

XML

W3C

W3C

XML Schema

W3C

W3C

XQUERY

W3C

W3C

XSLT

W3C

W3C

Kader: Kansen voor beter beheer Amsterdam kent 30 diensten, 7 bedrijven en 14 stadsdelen. Elk van deze organisatie-onderdelen kent een relatief zelfstandige managementverantwoordelijkheid. De directeuren van concernonderdelen en stadsdeelsecretarissen zijn verantwoordelijk voor de eigen lokale netwerken en informatievoorziening. De stadsdelen, diensten en bedrijven hebben veel vrijheid bij het inrichten hiervan. Op het niveau van applicaties zien we dat zo zogenaamde eilandautomatisering is ontstaan. Historisch gezien is dit verklaarbaar en er zijn ook voordelen aan. Er kan namelijk maatwerk worden geleverd aan integrale managers en snel gereageerd worden op ad-hoc vragen. De eilandautomatisering heeft echter ook een keerzijde. Schaalvoordelen worden gemist en het vormt een zware belemmering voor het realiseren van de doelstellingen van de Andere Overheid. Vanuit het oogpunt van architectuur is daarom een koerswijziging nodig richting gemeenschappelijkheid en standaardisering. Deze koerswijziging biedt ook kansen voor de kosten en de kwaliteit van het beheer. De eilandautomatisering maakt dat het beheer op dit moment ook 26 27

SHP = Servicehuis Personeel Zie hoofdstuk Informatie paragraaf 6.4.2

7 - 27



versnipperd is ingericht met grote kwaliteitsverschillen. Via professioneel gemeenschappelijk beheer is hier dus nog winst te boeken. In Amsterdam wordt al gemeenschappelijk beheer uitgevoerd door het Servicehuis ICT: 1. ondersteuning aan diensten en stadsdelen in de uitvoering van functioneel beheer en hanteert daarbij de in dit handboek beschreven beheermodellen; 2. en de uitvoering van belangrijke onderdelen van het functioneel beheer van een portfolio aan presentatievoorzieningen.

7 - 28



7.6

Beveiliging

7.6.1

GIBN

In onderstaande tabel zijn de relevante paragrafen uit de Gemeentelijke Informatiebeveiligingsnorm (GIBN, versie 2.0 april 2005) voor de informatiearchitectuur opgenomen.


Nr. GIBNparagraaf

Titel paragraaf

4.1

Inventarisatie van informatie en bedrijfsmiddelen

4.2


7.3

Bescherming programmatuur en gegevens

8.6

Toegangsbeveiliging in (informatie)systemen

9.3

Veiligstelling programmatuur

10.1

Beveiligingseisen voor (informatie)systemen

10.2


10.3

Cryptografische beveiliging

7.6.2

uitgangspunten beveiliging


In aanvulling op de GIBN kunnen gelden de volgende uitgangspunten op het gebied van beveiliging voor de applicatiearchitectuur: 1. Applicaties worden op basis van het belang c.q. de gevoeligheid van dataopslag en -verwerking ingedeeld in drie beveiligingsrisicoklassen (ACAM): a. laag/publiek b. middel/basis c. hoog/concern 2. Van individuele applicaties mogen de gegevens- en de applicatielaag binnen de applicatie niet door gebruikers rechtstreeks worden benaderd. Een gebruiker krijgt alleen toegang tot de applicatie via de presentatielaag. De presentatielaag roept vervolgens de applicatielaag aan en die roept weer de gegevenslaag aan. Alleen beheerders mogen met extra authenticatievoorzieningen rechtstreeks toegang verkrijgen tot applicatielaag en gegevenslaag. 3. Als regel worden de gegevenslagen van meerdere systemen nooit direct aan elkaar gekoppeld. De applicatielaag is verbonden met een integratievoorziening die de datacommunicatie tussen de systemen orkestreert. 4. Voor toegang tot en gebruik van een concernapplicatie is gebruik van de centrale authenticatievoorziening vereist.Zie ook paragraaf 8.3.3 5. I AM service is gebaseerd op ‘role-based acces’ en netwerken een ‘Trustrelatie’ met elkaar hebben. Op informatieniveau, dat er versleuteling plaatsvindt van het BSN-nr, oftewel zoeken op BSN-nr. mag nooit rechtstreeks kunnen. Verdere uitwerking vindt nog plaats in samenwerking met het Platform Informatiebeveiliging.

7 - 29



7.7

conclusies applicatiearchitectuur

Conclusies

1. De applicatiearchitectuur is nauw gerelateerd aan de infrastructuurarchitectuur. De scheiding tussen beiden verschuift: bepaalde applicatiefuncties worden generiek en schuiven zo naar de infrastructuurlaag. 2. Er zijn vier dominante ontwikkelingen die de invulling van de applicatiearchitectuur sterk bepalen: • Stroomlijning van ketenprocessen (procesarchitectuur) • Ontsluiting van basisregistraties en kernadministraties (informatiearchitectuur) • Vergroting van flexibiliteit van ICT (organisatiearchitectuur) en • Vergroting efficiëntie van inzet ICT (organisatiearchitectuur) 3. Het huidige applicatielandschap is er nog niet volledig op ingericht om deze ontwikkelingen te ondersteunen. De belangrijkste belemmeringen zijn dat • elke dienst, bedrijf en stadsdeel zijn eigen inrichting van het applicatielandschap kent; • applicaties één homogeen geheel vormen en daarmee niet op zijn op te hakken in deeloplossingen; • applicaties veelal niet open zijn. 4. Amsterdam wil toewerken naar een service gerichte architectuur. Dat geldt dus ook voor de inrichting van de applicatiearchitectuur. Daartoe wordt een strategie gevolgd met als hoofdlijnen: • Integratie van presentatiefuncties • Meer openheid en gemeenschappelijkheid rond integratievoorzieningen • Meer gemeenschappelijke ontwikkeling en beheer • Standaardisering van functies • Modulaire opbouw van applicaties 5. Het functionele landschap van Amsterdam valt uiteen in vier lagen: de presentatielaag, de integratielaag, de laag domeinen en de datalaag. 6. De presentatielaag dient aangepast te worden aan de eisen die aan de front office (zie hoofdstuk 4 ) worden gesteld. 7. Voor de integratielaag dient er één integratievoorziening te komen met (op termijn) de volgende functies: a. Uitwisselen van berichten; b. Beheren services; c. Authenticeren & autoriseren; d. Toegang verlenen tot registraties; e. Registreren zaken; f. Regisseren processen.

7 - 30



Deze integratievoorziening wordt de Servicebus Amsterdam genoemd. De Servicebus Amsterdam wordt de komende jaren ‘pilotmatig’ opgebouwd met de cursief gemarkeerde functies als prioriteit 28. Het doel is om binnen de integratielaag de toegang tot basisregistraties en kernadministraties uiteindelijk te laten plaatsvinden via het ‘uitwisselen van berichten’. 8. Er moet standaardisering komen van applicaties in de back office (de laag domeinen). Het management dient zich uit te spreken over het tempo en de mate waarin dit moet gebeuren 29. 9. Een blik op het huidige applicatielandschap leert dat • voorzieningen elkaar veelal aanvullen (bijvoorbeeld Portaal, Paraplu, Loket Amsterdam, Antwoord); • er nauwelijks overlap is van concernvoorzieningen; • er voor enkele cruciale functies in de integratielaag nog geen oplossingen zijn. 10. Portaal Amsterdam is de gemeenschappelijke toepassing die gebruikt wordt voor de functie presentatie integratie. Voor het verlenen van toegang tot registraties zijn Paraplu en Diva de gemeenschappelijke standaard toepassingen voor de basisregistratie Personen respectievelijk de basisregistratie Vastgoed. 11. Er wordt gestreefd naar een concernbreed zakenmagazijn. Als dat niet lukt dan is elke organisatie binnen de gemeente Amsterdam verantwoordelijk voor de ontwikkeling van een eigen zakenmagazijn 30. Daarnaast heeft de ontwikkeling van een concernbreed zaakdossier prioriteit. Zie conclusie 6 in Hoofdstuk 6 . 12. De volgende functies lenen zich voor gemeenschappelijke ontwikkeling en beheer: • Alle functies binnen de presentatielaag • Alle functies binnen de integratielaag • Procesgenerieke functies, generieke managementfuncties en generieke ondersteunende functies binnen de laag domeinen • Alle functies binnen de datalaag Of deze functies daadwerkelijk in gemeenschappelijke ontwikkeling en beheer worden gebracht is een vraagstuk voor het management en mede afhankelijk van keuzes in de organisatieen procesarchitectuur. Gemeenschappelijke voorzieningen rond de integratielaag hebben prioriteit.

28

In jargon wordt dit ook wel “de ontwikkeling van een dunne naar een dikke bus” genoemd. Concreet gaat het daarbij om vragen als: Wanneer moeten we aan de standaarden voldoen? Staan we uitzonderingen toe? Gelden standaarden alleen bij vervanging of aanpassing van systemen of gaan we ook bestaande systemen aanpassen? 30 Als hier –om wat voor redenen dan ook- niet voor wordt gekozen zullen op termijn, langs het pad der geleidelijkheid, de verschillende zakenmagazijnen moeten worden geïntegreerd tot één gemeenschappelijke voorziening voor alle dienstverlening. 29

7 - 31



13. Indien besloten wordt tot gemeenschappelijke ontwikkeling en beheer moet aan een aantal randvoorwaarden 31 worden voldaan binnen de applicatiearchitectuur. 14. Het management in Amsterdam zal leiderschap moeten tonen door richting te geven aan de wijze waarop gemeenschappelijkheid binnen de applicatiearchitectuur vorm moet krijgen. Dit is nauw gerelateerd aan de vormgeving van de organisatiearchitectuur. 15. Standaardisering binnen de applicatiearchitectuur moet krachtig ter hand worden genomen. Dit handboek biedt daarvoor het kader. Het management dient zich uit te spreken over de mate van ‘dwingendheid’ 32 Het management dient zich uit te spreken over het tempo en de mate waarin dit moet gebeuren 33. 16. Standaardisering binnen de integratielaag heeft prioriteit. Dit betekent concreet dat: • Bij vervanging of aanpassing van systemen moet worden aangesloten op de in dit handboek gedefinieerde open standaarden 34. • Bestaande applicaties, die nog niet geschikt zijn voor service gerichte architectuur, adapters ontwikkelen zodat ze kunnen ‘praten’ met de Servicebus Amsterdam 35. 17. Er liggen kansen voor kostenbesparing en kwaliteitsverbetering door meer gemeenschappelijk te gaan beheren. 18. Het beheer van de gemeenschappelijke Servicebus Amsterdam moet worden belegd bij één (centrale) organisatie met voldoende mandaat en geld. De specifieke beheertaken en organisatorische inbedding moeten zo spoedig mogelijk worden geregeld.

31

Deze randvoorwaarden zijn in paragraaf 7.3.3. genoemd Concreet gaat het daarbij om vragen als: Wanneer moeten we aan de standaarden voldoen? Staan we uitzonderingen toe? Gelden standaarden alleen bij vervanging of aanpassing van systemen of gaan we ook bestaande systemen aanpassen? 33 Concreet gaat het daarbij om vragen als: Wanneer moeten we aan de standaarden voldoen? Staan we uitzonderingen toe? Gelden standaarden alleen bij vervanging of aanpassing van systemen of gaan we ook bestaande systemen aanpassen? 34 Dit betekent dat elk systeem dat Amsterdam vanaf heden selecteert, voldoet aan deze open standaarden, mits het systeem gegevens of services uitwisselt met andere systemen. Indien een systeem dit niet ondersteunt neemt de leverancier een aparte voorziening in zijn offerte hiervoor op. 35 Hiervoor moet per systeem een adapter worden ontwikkeld die gebruik maakt van web services. Het betreft hier allereerst alleen de systemen die gegevens uitwisselen met de basisregistraties en de kernadministraties. 32

7 - 32


infrastructuur: drager van architectuur


8

Infrastructuurarchitectuur

8.1

Inleiding

Van oorsprong wordt de infrastructuur vooral gedefinieerd in technische termen en gaat het om bekabelingssystemen, verbindingen, hardware (servers, pc’s, printers) en daarop draaiende besturingssoftware. In deze visie is er bijna geen oog voor de relatie met ‘hogere’ architectuurlagen. Sterker nog, de infrastructuur werd gezien als een losstaand iets, een noodzakelijk kwaad. Tegenwoordig wordt de technische infrastructuur niet meer los van de andere lagen gezien. Het is de ‘onderste’, dragende laag van de architectuur, waarvan de inrichting sterk bepaald wordt door hogere architectuurlagen. Soms werkt het echter ook andersom en is de techniek bepalend. Zo kunnen we ons geen Andere Overheid voorstellen zonder internettechnologie.

brede definitie van ‘infrastructuur’

Huidige infrastructuur ondersteunt nog onvoldoende ‘koppelen en kantelen’ en servicegerichtheid

Zoals we ook in Hoofdstuk 7 hebben gezien is het onderscheid tussen de applicatie- en infrastructuurlaag aan het vervagen. In dit hoofdstuk hanteren we een brede invulling van de infrastructuur. Dat wil zeggen dat niet alleen de hardware en de besturingssoftware eronder valt, maar ook gestandaardiseerde applicaties met duidelijk generieke kenmerken en scherp afgebakende functies. De brede invulling houdt ook in dat het er niet alleen eisen worden gesteld aan de ‘gemeenschappelijke’, maar ook aan lokale, dienstgebonden infrastructuren 36. Als we naar de huidige infrastructuur kijken valt op dat er (net als in het applicatielandschap) een grote verscheidenheid is aan lokale, dienstgebonden netwerken. Dit maakt het lastig om het uitgangspunt ‘koppelen en kantelen’ te implementeren en een service gerichte architectuur te ondersteunen. Om goed te koppelen is het ten eerste nodig dat de lokale infrastructuren voldoen aan

36

Hoewel we een brede invulling voorstaan bevat deze versie van het handboek nog niet alle onderdelen. Deze versie richt zich hoofdzakelijk op de bestaande gemeenschappelijke onderdelen, onder regie van E-net, en de nieuwe infrastructurele functies op het gebied van beveiliging en integratie. Hier ligt de grootste behoefte. De architectuur van lokale, dienstgebonden infrastructuren die onder het Servicehuis ICT vallen volgt later in 2006.

8-1



de Gemeentelijke Informatiebeveiligingsnorm (GIBN) en de voorwaarden voor een basisaansluiting op de gemeenschappelijke E-net-datainfrastructuur. Dit is echter niet voldoende. Om tot echte samenwerking over de grenzen van de lokale infrastructuren heen te komen ligt het voor de hand de gemeenschappelijke infrastructuur te versterken. Niet alleen door functies van een nieuwe Servicebus Amsterdam daarin op te nemen, maar ook door bepaalde zaken die nu in alle lokale infrastructuren apart zijn ingericht gemeenschappelijk aan te pakken. De infrastructuur moet zelf ook in termen van services gezien gaan worden. Denk bijvoorbeeld aan de services ‘authenticeren’ en ‘printen’. Het is veel efficiënter om deze als één service aan te bieden vanuit de infrastructuur dan dat ze in elke afzonderlijke applicatie als functie moeten worden verwerkt. In deze infrastructuurarchitectuur wordt dit uitgewerkt, te beginnen met de authenticatieservice 37. complexe belangenafwegingen

We hebben in Hoofdstuk 4 gezien dat we een overheid willen zijn die • niet naar de bekende weg vraagt, • klantgericht is; • zich niet voor de gek laat houden; • weet waar ze het over heeft en • haar zaken op orde heeft en • niet meer uitgeeft dan nodig is. Dit vergt complexe belangenafwegingen in de infrastructuurarchitectuur want eisen en wensen lijken elkaar soms tegen te spreken. Enerzijds moet de infrastructuur veilig en stabiel zijn, aan de andere kant open en flexibel. En tegelijk moet de infrastructuur betaalbaar en beheerbaar blijven. Deze eisen en wensen vragen behalve om nieuwe technieken ook om een nieuwe kijk op de architectuur van de infrastructuur waarbij met name de verhouding tussen maatwerk en standaarden en gemeenschappelijke en dienst/stadsdeelgebonden opnieuw wordt bepaald.

strategie

Om de infrastructuur de dragende laag te laten zijn van de Andere Overheid is het nodig de infrastructuur daarop aan te passen. De strategie voor de infrastructuurarchitectuur kent de volgende hoofdlijnen: 1. Gemeenschappelijke integratievoorzieningen; 2. Gemeentebrede infrastructuurarchitectuur; 3. Standaardisering; 4. Modulaire opbouw.

1) gemeenschappelijke

Net als in de applicatiearchitectuur moeten we toewerken naar gemeenschappelijke infrastructurele voorzieningen voor integratie. Deze integratievoorzieningen moeten een plaats krijgen in de gemeenschappelijke netwerken.

integratievoorzieningen

2) gemeentebrede infrastructuurarchitectuur 37

Bij de implementatie van de gemeenschappelijke integratievoorzieningen zal ‘onder architectuur’ gewerkt moeten worden.

In deze infrastructuurarchitectuur wordt nadrukkelijk voortgebouwd op de architectuurschets uit het rapport “De gemeente veilig op één lijn”, dat de basis voor het huidige E-net vormt. Zoals de titel aangeeft staan in het rapport twee zaken centraal: samenwerking en beveiliging. Bij de realisatie van E-net is in eerste instantie de nadruk gelegd op beveiliging. In dit Handboek wordt dit aangevuld met een verdere uitwerking van hoe de samenwerking kan worden versterkt.

8-2



3) standaardisering

De infrastructurele voorzieningen worden zodanig ingericht dat zij voldoen aan (open) standaarden. Indien mogelijk wordt gebruik gemaakt van open source.

4) modulaire opbouw

Infrastructurele voorzieningen worden in (standaard) modules of componenten verdeeld, die onafhankelijk van elkaar flexibel kunnen worden ingezet.

we zijn al op weg

Deze strategie bouwt voort op een al ingezette lijn. Het E-net netwerk en de Enet hosting infrastructuur zijn al bijna volledig conform deze architectuur tot stand gekomen. Leidraad daarbij is de indeling in zogenaamde ‘beveiligingsdomeinen’. Domeinen verschillen in niveaus van beveiliging en service wat leidt tot een afweging tussen beveiliging en andere kwaliteitsaspecten versus kostenbeheersing. Verder vormt de transformatie naar een gemeenschappelijke inrichting van de lokale infrastructuren één van de belangrijkste doelstellingen van het Servicehuis ICT.

8-3



8.2

Grondslagen

De volgende uitspraken zijn richtinggevend en kaderstellend voor de infrastructuurarchitectuur: grondslag 5.1

8-4

De infrastructuur is schaalbaar, betrouwbaar en gebaseerd op open standaarden.



8.3

Modellen

8.3.1

Domeinstructuur E-net en beveiligingsdomeinen

Model 8.1 Domeinen Enet (1)

[Bron: Adviesgroep Architectuur] De ontwikkeling van E-net is gebaseerd op het rapport ‘De gemeente veilig op één lijn’. E-net vormt allereerst de verbindende schakel tussen de lokale netwerken (LANs) van de verschillende gemeentelijke organisaties. Behalve deze schakelfunctie voor dataverkeer biedt het inmiddels ook enkele gemeenschappelijke voorzieningen voor diensten en stadsdelen zoals hosting (schijfruimte voor de opslag van bestanden). Een zeer belangrijk aspect in de opzet van E-net is de definitie van verschillende domeinen: Publiek, Basis en Concern. In Model 8.1 zijn deze aangegeven met de drie gekleurde circels.

8-5



Model 8.2 Beveiligingsniveaus

[Bron: Adviesgroep Architectuur] We kennen dus binnen E-net domeinen. Deze domeinen zijn weer gebaseerd op het beveiligingsmodel zoals dat in ‘De gemeente veilig op één lijn’ is gepresenteerd. In dat model is het “E-net concerndomein” het zwaarst beveiligde en daarmee moeilijkst toegankelijke gebied, vergelijkbaar met een schatkamer. Dit correspondeert met het beveiligingsdomein ‘Select’ (zie kader). Het “E-net publiek domein” echter is een openbaar gebied, open voor iedereen, overal en altijd. Dit correspondeert met het beveiligingsdomein ‘Publiek’. Daartussen is het “E-net basisdomein” vergelijkbaar met een normaal kantoor van een gemeentelijke organisatie. Dit correspondeert met het beveiligingsdomein ‘Basis’. In Model 8.2 is deze driedeling zichtbaar via de drie verticale kolommen. De pijlen naar links en naar rechts laten zie dat er een soort trade-off plaatsvindt tussen toegankelijkheid aan de ene kant en beveiliging aan de andere kant. Tabel 8-1 Risicoklassen WBP en domeinenindeling

WBP risicoklasse 0 risicoklasse 1 risicoklasse 2

Beveiligingsdomein Publiek Basis Select

E-net domein Publiek Basis Concern

De domeinindeling van E-net met de drie beveiligingsdomeinen Publiek, Basis en Select is - om het nog ingewikkelder te maken - ook weer gerelateerd aan bepaalde risicoklassen voor beveiliging zoals gedefinieerd in de Wet Bescherming Persoonsgegevens. In Tabel 8-1 is dit aangegeven. Bij het bepalen van wat tot welke beveiligingsdomein gerekend moet worden gaat het overigens niet alleen om persoonsgegevens. Ook andere criteria zoals het belang van bepaalde informatie of applicatie voor een proces spelen

8-6



daarbij een belangrijke rol. De uiteindelijke vertaling van een concrete casus over de verschillende E-net en beveiligingsdomeinen kan overigens best ingewikkeld zijn. De basisregistraties zijn bijvoorbeeld zo belangrijk dat zij tot het beveiligingsdomein Select gerekend moeten worden. Dit hoeft echter niet te betekenen dat een applicatie als Paraplu geheel in het concerndomein van Enet geïmplementeerd moet worden. De server met de database waarin persoonsgegeven zijn opgeslagen hoort daar thuis, maar de server met de eigenlijke applicatie (de zogenaamde business logic) en de presentatiefunctie past beter in het ‘E-net basisdomein’. En wanneer een applicatie ook via internet voor burgers en bedrijven beschikbaar wordt gesteld moet de presentatiefunctie van de applicatie op een server in het ‘E-net publiek domein’ draaien. Kader: Verwarrende termen? Concerndomein en Select De naam concerndomein als onderdeel van de E-net infrastructuur blijkt in de praktijk tot de nodige verwarring te leiden. Het lijkt het deel van de infrastructuur waarin de zogenaamde ‘concernapplicaties’ thuishoren. Ook wordt het woord ‘concern’ gebruikt als aanduiding voor het geheel van gemeentelijke organisaties. In dit hoofdstuk wordt de naam concerndomein alleen nog gebruikt in de betekenis als ‘E-net concerndomein’, dat wil zeggen als aanduiding van het zwaarst beveiligde deel van de gemeenschappelijke data-infrastructuur. In meer algemene zin, ter aanduiding van een bepaald beveiligingsniveau wordt in dit hoofdstuk verder gesproken over het beveiligingsdomein ‘Select’, een nieuwe term. Een nieuwe term kan natuurlijk ook weer verwarring oproepen, maar er zit wel logica achter. Op het eerste gezicht lijkt de nieuwe term weinig toe te voegen: ‘E-net concerndomein’ en ‘Select’ lijken uitwisselbaar. Toch is er wel degelijk een onderscheid: het E-net concerndomein is te zien als een concrete invulling van het Selectdomein in de gemeenschappelijke infrastructuur. In de lokale infrastructuren kunnen echter ook delen bestaan die geen deel uitmaken van het concerndomein, maar die wel voldoen aan de normen van het Selectdomein. Een vierde domein in E-net? In het ontwerp van E-net is er, naast de drie genoemde domeinen, nog sprake van een vierde domein: het E-net beheerdomein. Dit domein is echter niet gerealiseerd. De bedoeling van dit vierde domein was er voor te zorgen dat netwerkbeheerders wel ‘overal bij kunnen komen’, zonder dat dit afbreuk zou doen aan de uit oogpunt van beveiliging vereiste scheiding tussen de verschillende domeinen.

8-7



Model 8.3 Domeinen Enet (2)

[Bron: Adviesgroep Architectuur] E-net kent drie domeinen en deze zijn nauw gerelateerd aan verschillende beveiligingsniveaus. Een stap verder kan er ook nog onderscheid gemaakt worden tussen dienstgebonden en niet-dienstgebonden netwerken. In Model 8.3 zijn in drie verticale kolommen de E-net domeinen met corresponderende beveiligingsdomeinen opgenomen. In elke kolom zijn daarbij de verschillende E-net-onderdelen en lokale netwerken getekend: Het ‘E-net publieke domein’ is het domein dat open staat voor de buitenwereld. Servers in netwerken die tot dit domein behoren zijn direct vanaf internet te benaderen. Ook is het publiek domein bedoeld als enige uitgang vanuit het E-net basisdomein naar internet. • Het E-net basisdomein is in de data-infrastructuur de verbindende schakel tussen de lokale netwerken van gemeentelijke organisaties. De lokale netwerken zijn allemaal aangesloten op het basisdomein van de datainfrastructuur. Rechtstreekse verbindingen vanuit de lokale netwerken naar de buitenwereld (‘achterdeuren’) zijn in de opzet van E-net niet nodig en ook niet toegestaan. Daarbij komt dat achterdeuren haaks staan op het ‘no wrong door’ principe uit Hoofdstuk 4 . • Het E-net concerndomein omvat de netwerken waarin informatie is opgeslagen die gekwalificeerd is als risicoklasse 2. Het concerndomein is zoals we hebben gezien de goedbeveiligde ‘schatkamer’ van Amsterdam. Typerend hierbij is dat er vanuit het E-net publieke domein of vanaf werkstations in het E-net basisdomein geen rechtstreeks dataverkeer is toegestaan met systemen in het concerndomein. De E-net domeinen zijn van elkaar gescheiden door zogenaamde firewalls, waarop bepaalde ‘beveiligingsregels’ zijn toegepast. Netwerken die zijn aangesloten op het ‘E-net publieke domein’ of het ‘E-net basisdomein’ zijn in de opzet van E-net enkel van elkaar gescheiden door zogenaamde access control lists. Dit zijn tabellen waarin staat naar of vanuit welk ander netwerk (op basis van een zogenaamde ip-range) dataverkeer wordt doorgelaten.

8-8



Onder andere vanwege het bestaan van aansluitingen van lokale netwerken op internet buiten E-net om (de zogenaamde ‘achterdeuren’) zijn door verschillende organisaties hun lokale netwerken door een firewall gescheiden van de gemeenschappelijke E-net data-infrastructuur, en daarmee van andere lokale netwerken. Volgens de architectuur van E-net zijn ‘achterdeuren’ niet nodig. Sterker nog, ze zijn volgens de voorwaarden voor aansluiting van een lokaal netwerk op het E-net Basis Domein niet toegestaan. Model 8.3 kent ook drie horizontale lagen:

•

•

•

De netwerken in de bovenste laag zijn dienstgebonden. Over het algemeen bevinden deze netwerken zich ook fysiek op de locatie van de dienst. Het kan echter ook zijn dat een dienstgebonden netwerk door een andere partij (bijvoorbeeld GetronicsPinkRoccade) gehost wordt. Dit betekent echter niet automatisch dat het een ‘gemeenschappelijk’ netwerk is (zie onder). De netwerken in de onderste laag zijn gemeenschappelijk (en dus nietdienstgebonden). Over het algemeen worden deze netwerken gehost door GetronicsPinkRoccade/ASP4All (zie kader). De middelste laag geeft de ‘datatransportlaag’ weer van de Enetdatainfrastructuur. De verbindingen worden beheerd door Colt en de domeinscheidingen door GetronicsPinkRoccade.

Kader: Gemeenschappelijke netwerken en de positie van de gemeenschappelijke integratievoorziening Behalve de lokale, ‘dienstgebonden’ netwerken zijn op de verschillende domeinen van het E-net netwerk ook een aantal gemeenschappelijke netwerken aangesloten. In Model 8.3 is dit aangegeven in de onderste horizontale laag. Deze gemeenschappelijke netwerken zijn nu ingericht op de lokatie Paalbergweg van Getronics PinkRoccade (GPR) en worden ook door GPR beheerd. Deze gemeenschappelijke netwerken worden onder meer gebruikt voor het delen van servers, software en beheerservices. Uit oogpunt van de architectuur van E-net is het om het even waar de gemeenschappelijke netwerken zijn ingericht en wie het beheer doet. Met de vorming van het Servicehuis ICT is er een organisatie die deze verantwoordelijkheid kan nemen. Het is ook mogelijk om lokale netwerken binnen één beveiligingsdomein tot één logisch geheel samen te voegen. Aan de andere kant is het binnen de architectuur van E-net ook mogelijk om de servers uit een aantal lokale netwerken over te hevelen naar een gemeenschappelijk netwerk. In potentie kunnen zelfs alle servers die nu in de lokale netwerken staan in of meerdere gemeenschappelijke netwerken een plaats krijgen. Werkstations en andere werkplekapparaten horen echter niet in zo’n gemeenschappelijk (basis-)netwerk thuis. Het spreekt bijna voor zich dat ook gemeenschappelijke integratievoorzieningen (zie paragrafen 7.3.1 en 8.3.2 ) zich in gemeenschappelijke netwerken bevinden, maar technisch is daartoe geen noodzaak. De vanzelfsprekendheid berust dan ook meer op praktische

8-9



gronden en beveiligingsredenen. Wanneer een gemeenschappelijke integratievoorziening in een lokaal netwerk wordt gesitueerd moet dat lokale netwerk daarvoor ook open staan. Hetzelfde geldt tot op zekere hoogte ook voor concernsystemen en andere gemeenschappelijke applicaties. 8.3.2

Integratie A a n vra g e n d e A a n vra g e n d e

A a n vra g e n

U itw is s e le n b e ric h te n

B e h e re n s e rvic e s

R e g is s e re n p ro c e s s e n

A u th e n tic e re n & a u to ris ere n

Model 8.4 Uitwerking functies integratielaag

G e g e ve n s m a g a z ijn e n

Toegang v e rle n e n re g is tra tie s

Zaken m a g a z ijn

R e g is tre re n zaken

(detail)

A fh a n d e le n


B a s is re g is tra tie e n k e rn a d m in is tra tie s

[Bron: Adviesgroep Architectuur]

Tabel 8-2 Uitwerking functies integratielaag

Functie 1. Uitwisselen berichten 2. Beheren services 3. Authenticeren & Autoriseren 4. Toegang verlenen tot registraties 5. Registreren zaken 6. Regisseren processen

Architectuurlaag Infrastructuurarchitectuur


Model 8.4 en Tabel 8-2 zijn eerder al in paragraaf 7.3 , Model 7.3 en Tabel 7-1 geïntroduceerd. Daar hebben we gezien dat de functies 1 t/m 3 van de integratielaag zich in de infrastructuurarchitectuur bevinden. Ze vormen in feite een extra functie bovenop de datacommunicatie van het netwerk en we beschouwen ze daarom als infrastructurele voorzieningen. Ze worden ook gezien als de basisfuncties van een servicebus, een communicatiesysteem tussen applicaties met de kwaliteiten om regie tussen services uit te kunnen voeren. Een andere naam voor servicebus is broker. Hieronder lichten we de functies van de Integratievoorziening toe, die betrekking hebben op de infrastructuurlaag, in Bijlage 17 worden de functies, die onderdeel uitmaken van de functie ‘Uitwisselen berichten’ toegelicht. Ad 1. Uitwisselen berichten Bij het uitwisselen van berichten gaat het om het routeren van het berichtenverkeer tussen 2 of meer applicaties, respectievelijk in een vragende

8 - 10



en een afhandelende rol. Er is bekend waar de applicaties zich bevinden die betrokken zijn in de berichtenuitwisseling. De berichtencentrale bepaalt welk type berichten moet worden verwerkt door welke aangesloten procesapplicaties en in welke volgorde. De manier waarop berichten worden uitgewisseld is gebaseerd op zogenaamde webservices. Cruciale functies daarbinnen zijn onder meer • de wachtrij oftewel het vasthouden van berichten totdat de ontvangende applicatie in staat is de berichten te ontvangen; • berichtenvalidatie oftewel het nagaan of berichten aan de juiste standaarden voldoen; • berichtentransformatie en -translatie oftewel het (zonodig) vertalen van berichten; • adapters oftewel de software die de informatieoverdracht tussen de broker en de verschillende applicaties regelt. Een adapter realiseert een extern koppelvlak met een applicatie, waarbij gestandaardiseerde (functionele en technische) protocollen worden gebruikt. Ad 2. Beheren services Naarmate er meer standaard webservices beschikbaar komen in Amsterdam, is het van belang dat bekend is wat deze webservices wel en niet zijn en kunnen. Via de functie ‘beheren services’ wordt deze informatie ontsloten en bepaald wat de meest geschikte service is voor het leveren van een bepaalde dienst. Via deze functie is onder meer de aard van een service te raadplegen, de standaarden waaraan deze voldoet, maar ook de service levels die de service kan bieden. Dit laatste gebeurt met behulp van de webstandaard UDDI (Universal Description, Discovery, and Integration) wat te vergelijken is met een bibliotheek waarin verwijzingen naar via het internet beschikbare webservices staan. Op basis van bedrijfsregels zoals Service Level Agreements (die ook apart staan opgeslagen als een set aan afspraken) wordt via deze functie vervolgens de meest geschikte service geselecteerd voor een bepaalde actie. Ad 3. Authenticeren & Autoriseren Basisregistraties en kernadministraties kunnen niet voor iedereen zo maar toegankelijk zijn. Het is noodzakelijk dat er binnen de integratievoorziening ook een functie is die zorgt dat deze toegang op een eenduidige en beveiligde manier tot stand komt. Voor de authenticatie (‘ben je wie je zegt te zijn’) en autorisatie (‘wat mag je’) wordt daarom binnen de integratievoorziening een aparte service gecreëerd. In Model 8.5 is de gemeenschappelijke voorziening (de zogenaamde I AMserver) beschreven die gebruikt wordt voor deze service. 8.3.3

Identiteitbeheer, authenticatie en autorisatie

Bij toegang verlenen tot registraties denken we in eerste instantie dat het nuttig is om toegang te verlenen tot basisregistraties en kernadministraties. Het regisseren van processen kan heel goed gebruikt worden voor de organisatie-overstijgende processen, bijvoorbeeld de publieksgerichte processen waarbij het Contact Center Amsterdam/Antwoord betrokken is. De ontsluiting en regie van interne bedrijfsprocessen moet buiten deze algemene voorziening om afgehandeld kunnen worden.

8 - 11



Model 8.5 I AM-service startsituatie: Synchronisatie identiteiten

[Bron: Adviesgroep Architectuur] Een belangrijke voorziening in de integratielaag van het applicatielandschap is een gemeenschappelijke service voor authenticatie en autorisatie. Deze service kan drie functies omvatten: 1. identificeren (wie ben je) 2. authenticeren (ben je wie je zegt te zijn) 3. autoriseren (wat mag je). Ad 1. Identificeren In een Andere Overheid hebben burgers en bedrijven via de front office toegang tot bepaalde informatie in de back office. Ook binnen het concern gaan we meer samen werken en informatie delen. Dit betekent niet dat iedereen overal maar toegang toe moet kunnen hebben. En op een veilige manier. Om dat te kunnen is het nodig om te weten wie toegang tot informatie zoekt oftewel wat de digitale identiteit (in de vorm van bijvoorbeeld een gebruikersnaam en wachtwoord) van iemand is. Dit wordt gedaan door een in de gemeenschappelijke infrastructuur een zogenaamde metadirectory in te richten. Dit is een soort ‘supertelefoonboek’ waarin de digitale identiteiten uit diverse ‘telefoonboeken’ (bijvoorbeeld van diensten en stadsdelen) met elkaar worden samengebracht en gesynchroniseerd. Deze metadirectory bevat dus een aantal gegevens van iedereen die bij wet of door een gemeentelijke organisatie gerechtigd is tot gebruik van bepaalde applicaties en informatie. Daarbij gaat het ruwweg om de volgende categorieën personen: 1. medewerkers van diensten en stadsdelen gemeente Amsterdam • ambtenaren • niet-ambtenaren 2. medewerkers bedrijven en instellingen • gevestigd in Amsterdam • gevestigd buiten Amsterdam

8 - 12



3. burgers • woonachtig in Amsterdam • woonachtig buiten Amsterdam • geboren in Amsterdam • geboren buiten Amsterdam Het kan zijn dat iemand tot meerdere hoofdcategorieën behoort (een burger kan ook medewerker van een dienst of een bedrijf zijn). Enkel in zo’n geval is een persoon geassocieerd aan meerdere digitale identiteiten. De digitale identiteiten worden voor de verschillende hoofdcategorieën hoofdzakelijk afgeleid uit verschillende (authentieke) administraties (bijvoorbeeld de Basisregistratie Personen). Vanuit de gemeenschappelijke metadirectory kunnen we identiteiten vervolgens synchroniseren naar andere directories en bestanden met gebruikersgegevens van bijvoorbeeld decentrale netwerken, mailsystemen en applicaties. Ad 2. Authenticeren Authenticeren is het controleren of iemand is wie hij zegt te zijn. Juridisch gezien wordt met het authenticeren de rechtsgeldigheid van het gebruik van een digitale identiteit door een persoon beproefd. Zeker bij transacties van burgers en bedrijven met de gemeente waarbij het digitaal loket wordt gebruikt is het van belang zeker te weten dat een digitale identiteit door een bepaalde persoon gebruikt wordt. Ten behoeve van authenticatie van niet-medewerkers (burgers, (medewerkers van-) bedrijven en instellingen) zal gebruik gemaakt worden van bestaande landelijke voorzieningen, met name DigID. Hiervoor zal de Amsterdamse gemeenschappelijke authenticatieservice aan de landelijke voorzieningen gekoppeld worden. Voor authenticatie van de eigen medewerkers zijn in de metadirectory de betreffende identiteiten voorzien van een wachtwoord; eventueel kan ook dit wachtwoord worden gesynchroniseerd. Ad 3. Autoriseren Autoriseren is het verlenen van rechten aan identiteiten. Daartoe worden per identiteit niet alleen algemene persoonsgegevens (naam, emailadres) vastgelegd, maar ook de rol(len). Afhankelijk van de rol worden autorisaties verleend. Rollen kunnen op verschillende manieren worden gedefinieerd, zowel in netwerk- of applicatietermen (“is gebruiker van ...”) als organisatie of procestermen (“is manager van afdeling x”, “is lid van OR”, “is salarisadministrateur”). Zoals we zullen zien vindt autorisatie voorlopig met name plaats op applicatieniveau. Dat wil zeggen dat beheerders van applicaties (vaak in opdracht van leidinggevenden) rechten toewijzen en dit niet op een centraal punt gebeurt. In Model 8.5 is de startsituatie weergegeven voor de I AM-service. In deze startsituatie worden identiteiten (netwerkaccounts) plus algemene autorisatiegegevens uit de directories van de lokale, dienstgebonden netwerken (de meest linker bol) gesynchroniseerd naar de gemeenschappelijke directory van de I AM-service (de middelste bol). Dit noemen we de identity directory van E-net. Vanuit deze identity directory kunnen identiteiten worden gesynchroniseerd naar user databases van applicaties (meest rechter bol).

8 - 13



Deze I AM-server wordt, in eerste instantie, ingezet als een aanvulling op dergelijke services die nu ook binnen de dienstgebonden netwerken bestaan. De I AM-service zal met name gebruikt worden bij toegang tot applicaties in de gemeenschappelijke netwerken en mogelijk dienstoverstijgend gebruikte applicaties die in een lokaal netwerk draaien. De I AM-service zal verder worden ingezet bij gebruik van E-net services zoals Remcon en de ReverseProxy-service 38. In potentie kan de authenticatie van netwerkgebruikers van lokale directories gebeuren aan de hand van gebruikersnaam en wachtwoord in de directory van de I AM-service, in plaats van aan de hand van de gebruikersnaam en wachtwoord in de lokale netwerkdirectory. Kader: Waarom één digitale identiteit? Op het niveau van een dienstgebonden netwerk hebben de meeste medewerkers van een dienst een ‘netwerkaccount’ en een ‘emailaccount’. Deze laatste is meestal gekoppeld aan het netwerkaccount. Daarnaast hebben de meeste medewerkers meerdere, aparte ‘accounts’ voor applicaties. De bron op basis waarvan zo’n account wordt ‘aangemaakt’ is meestal een formulier waarmee een leidinggevende aan de netwerk- dan wel applicatiebeheerder opdracht geeft ervoor te zorgen dat een medewerker bepaalde applicaties kan gebruiken, toegang krijgt tot bepaalde documentmappen of een postbus krijgt en kan mailen. Bij het gebruik van applicaties is er voor wat betreft authenticatie en autorisatie sprake van een zekere gelaagdheid. Eerst moet je je aanmelden op het netwerk en worden netwerkrechten verleend, onder andere om bepaalde applicaties te mogen starten. En om de applicatie echt te kunnen gebruiken moet je vervolgens inloggen op de applicatie waarbij wordt bepaald wat je ‘in’ de applicatie mag. Het is vrij eenvoudig per applicatie en per netwerk na te gaan welke rechten aan een account zijn toebedeeld. Indirect zijn accounts verbonden met een bepaalde personen (medewerkers). En het is een zeer arbeidsintensieve klus om per persoon te inventariseren welke applicatie- en netwerkautorisaties zijn toebedeeld. Zeker ‘bestaat’ een medewerker in de verschillende systemen onder diverse gebruikersnamen. En het kan zijn dat een persoon in meerdere dienstgebonden netwerken accounts heeft, bijvoorbeeld wanneer hij of zij voor meerdere gemeentelijke organisaties werkt of wanneer een (concern)applicatie van een andere dienst gebruikt moet kunnen worden. Op netwerken applicatieniveau leiden medewerkers dus een zeer gefragmenteerd bestaan. En ook het beheer van de accounts is versplinterd. Alleen al omwille van het gebruikersgemak is het gewenst dat de veelheid aan gebruikersaccounts worden gebonden aan digitale identiteiten, welke aan medewerkers gebonden zijn in plaats van aan netwerken of applicaties. Om tegemoet te komen aan de wens om maar één keer te hoeven inloggen is één 38

De genoemde E-net services Remcon en Reverse-Proxy zijn faciliteiten voor medewerkers om op een veilige manier via internet of een telefoonverbinding thuis of een andere plek te werken.

8 - 14



digitale identiteit per medewerker een belangrijke voorwaarde. Ook uit oogpunt van beveiliging en ‘business compliance’ is het gewenst dat de focus verlegt wordt van applicatie- en netwerkgebonden accounts naar medewerkers, en de organisaties waar ze deel van uitmaken. Niet alleen moet een gebruikersaccount herleid kunnen worden naar een medewerker, het is ook nodig dat er vanuit de organisatie, via de digitale identiteiten, goede controle mogelijk is op aan een medewerker verleende autorisaties.

Model 8.6 I AM-service groeiscenario: Synchronisatie identiteiten

[Bron: Adviesgroep Architectuur] Volgens het groeiscenario, zoals in Model 8.6 is weergegeven, worden identiteiten uit verschillende basis- en kernadministraties (P-net voor medewerkers, de basisregistratie Personen en de basisregistratie Bedrijven) gesynchroniseerd naar de gemeenschappelijke directory van de I AM-service. Dit is de middelste bol in het figuur. Vanuit deze metadirectory kunnen identiteiten ook worden gesynchroniseerd naar een aparte ‘Applicatie Autorisatie Directory’. In deze directory kunnen identiteiten worden geassocieerd aan autorisatieprofielen van verschillende applicaties. Het voordeel van zo’n directory is dat voor meerdere applicaties op één plaats kan worden vastgelegd welke autorisaties op applicatieniveau aan een identiteit (medewerker) zijn toegekend. Identiteiten kunnen vanuit de metadirectory ook gesynchroniseerd worden naar databases van bijvoorbeeld telefooncentrales en toegangscontrolesystemen van gebouwen. Kader: E-net en de I AM-service Door E-net Regie en Beheer wordt gewerkt aan de implementatie van de I AMservice. Deze voorziening in de gemeenschappelijke infrastructuur kan gezien worden als een eerste stap op weg een metadirectory. In eerste instantie

8 - 15



zullen alleen identiteiten van medewerkers van de gemeente Amsterdam in de directory van de I AM-service worden opgenomen. Identiteiten zullen worden ontleend aan de directories van de lokale infrastructuren. Ook de verspreiding van identiteiten vanuit de I AM-directory blijft voorlopig beperkt tot de applicaties die de I AM-service gebruiken bij authenticatie van gebruikers zoals weergegeven Model 8.5. 8.3.4 Model 8.7 Dataopslag

Dataopslag

PM voor volgende versie. [Bron: PM] 8.3.5

Model 8.8 Dataverwerking

Dataverwerking

PM voor volgende versie. [Bron: PM] Vanuit het oogpunt van architectuur is het wenselijk dat Amsterdamse applicaties zoveel mogelijk ondergebracht worden in gemeenschappelijke hostingfaciliteiten. Vergroting van het volume heeft voordelen in termen van inkoopvoordelen, efficiencyverhoging, verbetering van service levels (bijvoorbeeld door een gemeenschappelijke uitwijkomgeving) en deskundigheidsbevordering. Het Servicehuis ICT biedt gedeelde hostingfaciliteiten. Op initiatief van beide partijen wordt hiervoor een architectuur ontwikkeld die zal gaan gelden als gemeentebrede standaard. Dit wordt uitgewerkt in een volgende versie van het handboek. 8.3.6

Model 8.9 Standaard

Standaard werkplek

PM voor volgende versie.

werkplek

[Bron: PM]

8 - 16


Tabel 8.3 Richtlijnen infrastructuurarchitectuur


8.4

Standaarden

8.4.1

Richtlijnen

1. Gemeenschappelijke voorzieningen in de infrastructuur worden in elk geval gestandaardiseerd. 2. Standaardisering vindt op een zo hoog mogelijk niveau plaats. Dat wil zeggen dat uniforme standaarden de voorkeur genieten boven bandbreedte standaarden die weer de voorkeur genieten boven afspraken. 3. Alle functies die tot de infrastructuur worden gerekend 39 kennen uniforme standaarden voor de keuze van de applicaties. Naast de keuze voor de applicatie wordt ook de wijze waarop deze wordt gebruikt (inrichting) geüniformeerd. 4. De infrastructuur wordt zo ingericht dat open standaarden ondersteund worden. Niet-open standaarden worden alleen ondersteund als daartoe een dwingende noodzaak bestaat en er geen op open standaarden gebaseerde alternatieven bestaan. 5. Om de afhankelijkheid van leverancierseigen standaarden te verkleinen wordt aangesloten op mondiale-, landelijke-, branche en de facto Amsterdamse standaarden en op ‘open’ technische standaarden en/of open gegevensformaten en communicatieprotocollen 40 (zie ook kader). Kader: Business case Open Source Op 1 maart 2006 heeft de gemeenteraad een amendement aangenomen van het raadslid Marres naar aanleiding van de evaluatie en afronding Open Source pilots. De raad is van mening dat een actieve en participerende opstelling richting Open Source ontwikkelingen past bij Amsterdam als “ICT stad van Nederland”. Uitvoering van het amendement is niet mogelijk zonder verregaande samenwerking binnen de gemeente. In het amendement wordt het college van B&W gevraagd vóór de begroting 2007 met een business case te komen over hoe per 1 oktober 2008 om te gaan met het dan beëindigend contract met Microsoft voor kantoorautomatisering. Aan het college wordt gevraagd om bij alle diensten en stadsdelen een analyse te (laten) maken van de werkplekken, de functionaliteit en de af te spreken standaarden. Deze beschrijving is onderdeel van de businesscase. De directie Concern Organisatie pakt in de eerste fase de uitdaging op, de Raadscommissie ROW ontving nog vóór het zomerreces 2006 een (concept)plan van aanpak ten behoeven van een businesscase, dat na goedkeuring de basis vormt voor de businesscase "Open Software Strategie voor Amsterdam". Deze businesscase wordt voor de begroting 2007 ter besluitvorming aan het college van B&W aangeboden. De Businesscase Open Software Strategie bestaat uit drie pijlers:

39

Dit betreft niet alleen de bestaande functies die tot gemeenschappelijke voorzieningen zijn gedefinieerd in het kader van het Servicehuis ICT, maar ook nieuwe infrastructurele functies in het kader van integratie. 40 Bron: Nota ICT-standaardisatie, oktober 2004.

8 - 17



•

opstellen en beoordelen van een businesscase open standaarden en open source; • bewustwording over de voor- en nadelen van open standaarden en open source bij het bestuur en het ambtelijk apparaat; • mobiliseren van kennis over open standaarden en open source binnen de gemeente. Het zal duidelijk zijn dat de besluitvorming door de raad over de uitkomsten van de business case verwerkt zullen worden in een nieuwe versie van dit handboek. 8.4.2


In onderstaande tabel zijn de uniforme standaarden opgenomen die gelden binnen de infrastructuurarchitectuur. Nr. en naam standaard

Toelichting

Bron

DigID

Landelijke authenticatievoorziening voor burgers en bedrijven.

GBO.Overheid

Datacommunicatieinfrastructuur voor informatie-uitwisseling tussen gemeentelijke organisatie onderling en met de ‘buitenwereld’


Hosting

Schijfruimte voor de opslag van bestanden

PM

Werkplek

Standaard werkplekfunctionaliteit

PM

I AM-service

De gemeenschappelijke authenticatievoorziening

B&W-besluit 9 42 november 2004

TCP / IP

Netwerkprotocollen


E-net (netwerk)

41

Tabel 8-4 Uniforme standaarden infrastructuurarchitectuur

8.4.3


Er gelden op dit moment geen standaarden voor de infrastructuur op het niveau van ‘bandbreedte’. 8.4.4

Afspraken

Er gelden op dit moment geen standaarden voor de infrastructuur op het niveau van ‘afspraken’. 41

Aan het gebruik van E-net zijn voorwaarden verbonden. Deze zijn niet afzonderlijk in dit Handboek opgenomen, maar wel van toepassing. 42 In het betreffende B&W-besluit wordt deze voorziening benoemd als onderdeel van ‘Portaal Amsterdam’. Dit is verwarrend omdat –zoals we hebben gezien in hoofdstuk 7- Portaal als primaire functie ‘Presentatie integratie’ heeft. Daarom hanteren we de term ‘I AM-service’.

8 - 18



8.5


Beheer

Nr. en naam model

Eigenaar

Beheerder

Model 8.1 Domeinen E-net (1)


SHI

Model 8.2 Beveiligingsniveaus


SHI

Model 8.3 Domeinen E-net (2)


SHI

Model 8.4 Uitwerking functies integratielaag (detail)


SHI

Model 8.5 I AM-service startsituatie: Synchronisatie identiteiten


SHI

Model 8.6 I AM-service groeiscenario: Synchronisatie identiteiten


SHI

Model 8.7 Dataopslag


SHI

Model 8.8 Dataverwerking


SHI

Model 8.9 Standaard werkplek


SHI



Beheerder

DigID

??

GBO.Overheid

Tabel 8-6 Beheer

E-net

SHI

SHI

standaarden

Hosting

PM

PM

Werkplek

PM

PM

I AM-service

SHI

SHI

TCP / IP

??

IETF

43

43

Internet Engineering Task Force (IETF) ontwerpt, test en implementeert (technische) internetstandaarden waaronder TCP/IP.

8 - 19



8.6

Beveiliging

8.6.1

GIBN

In onderstaande tabel zijn de relevante paragrafen uit de Gemeentelijke Informatiebeveiligingsnorm (GIBN, versie 2.0 april 2005) voor de informatiearchitectuur opgenomen.


Nr. GIBNparagraaf

Titel paragraaf

4.1

Inventarisatie van informatie en bedrijfsmiddelen

4.2


6.1

Toegangsbeheersing vestiging(en)

6.3

Toegang computer- en datacomponenten

6.4

Bewegwijzering computerruimten

6.5

Verwijderen apparatuur en gegevensdragers

6.6

Datakluizen

6.8

Beveiliging van (mobiele) apparatuur

6.9

Telewerken

8.4

Toegangsbeveiliging voor netwerken

8.5

Toegangsbeveiliging voor werkstations

10.3

Cryptografische beveiliging

8.6.2


In de paragrafen 8.3.1 en 8.3.2 is naar voorgekomen dat er in de infrastructuurarchitectuur een aantal voorzieningen is rond beveiliging. Vandaar dat in aanvulling op de hiervoor genoemde artikelen uit de GIBN nog een aantal richtlijnen over de domeinstructuur van de infrastructuur, gebruikersregistratie, authenticatie en autorisatie worden genoemd. Domeinstructuur • De infrastructuur als geheel kent drie domeinen die voor een bepaald beveiligingsniveau staan, gerelateerd aan verschillende beveiligingsrisicoklassen. • De toegankelijkheid van een domein is omgekeerd evenredig aan het beveiligingsniveau. • Voor de infrastructuur als geheel zijn drie beveiligingsdomeinen gedefinieerd: Publiek, Basis en Select, die gerelateerd zijn aan de verschillende WBP beveiligingsrisicoklassen 1,2 en 3. • Elk gemeenschappelijk of dienstgebonden netwerk (LAN) of deelnetwerk (VLAN) binnen de totale infrastructuur wordt ingedeeld in één van de beveiligingsdomeinen. • De toegankelijkheid van een beveiligingsdomein, en daarmee van een (deel-)netwerk, is omgekeerd evenredig aan het beveiligingsniveau. Gebruikersregistratie • Gebruikers worden lokaal geregistreerd in de Directory service(s) van het lokale (basis-)netwerk en in de applicatie-userdatabases. Dit gaat volgens binnen de betreffende dienst geldende afspraken en procedures. • Gegevens over lokaal geregistreerde gebruikers worden (voor zover nodig) gesynchroniseerd naar de centrale directory service (I AM-server).

8 - 20



Authenticatie • Authenticatie van gebruikers bij toegang tot een lokaal basisnetwerk gebeurt aan de hand van naam+wachtwoord, zoals bekend in de lokale (netwerk-) directory service. • Authenticatie van gebruikers bij toegang tot het E-net concern domein gebeurt aan de hand van naam+wachtwoord, zoals bekend in de centrale directory (I AM-service). Indien nodig wordt gebruik gemaakt van zwaardere authenticatiemiddelen (o.a. software certificaten 44, biometrische identificatie). Autorisatie • Autorisatie van gebruikers voor gebruik van applicaties in een lokaal basisnetwerk gebeurt aan de hand van regels in de lokale (netwerk-) directory service. • Autorisatie van gebruikers voor gebruik van applicaties in het concern domein (centraal of decentraal) en in het basis domein gebeurt aan de hand van regels in de centrale (I AM-) directory service. Verdere uitwerking vindt plaats in samenwerking met het Platform Informatiebeveiliging.

44

RADIUS / token

8 - 21



8.7

conclusies infrastructuurarchitectuur

Conclusies

1. De scope van de infrastructuur omvat naast de ‘harde’ ICT-middelen (zoals servers, pc’s, switches en firewalls) ook • applicaties die de harde middelen simuleren en • generieke software (applicaties voor kantoorautomatisering en voorzieningen voor e-mail). Proces- en/of organisatiespecifieke applicaties worden níet tot de infrastructuur gerekend. 2. De infrastructuur van het concern is anno 2006 nog onvoldoende ingericht op het ondersteunen van een service gerichte architectuur. De eisen die gesteld worden aan de infrastructuur worden ook steeds hoger (bijvoorbeeld het verlenen van toegang tot gegevens door burgers in het kader van customer self service). 3. Voor versterking van de infrastructuurarchitectuur wordt een strategie gevolgd met als hoofdlijnen: • Het creëren van gemeenschappelijke integratievoorzieningen; • Het doorontwikkelen van een gemeenschappelijke architectuur voor lokale infrastructuren; • Het standaardiseren van infrastructuurvoorzieningen; • Het modulair opbouwen van infrastructuurvoorzieningen. 4. De architectuur van de ICT-infrastructuur is gebaseerd op de beveiligingsarchitectuur en domeinstructuur van E-net zoals verwoord in “De gemeente veilig op één lijn”. 5. De bestaande tweedeling tussen aan de ene kant lokale (dienstgebonden) netwerken en aan de andere kant centrale (gemeenschappelijke) netwerken wordt opgeheven, in de zin dat ze beide gehouden zijn aan hetzelfde architectuurregime en dezelfde standaarden. 6. Gebruik van ‘eigen’ internetaansluitingen vanuit lokale (dienstgebonden) netwerken (zogenaamde ‘achterdeuren’) is ten strengste verboden. Uitzondering hierop vormt het gebruik voor de uitvoering van noodzakelijk beheer. Om schending van deze regel uit te sluiten moeten sancties worden vastgesteld. 7. Er komt een gemeenschappelijke voorziening voor identificatie, authenticatie en autorisatie van medewerkers en relaties (zoals burgers en bedrijven) onder de noemer I AM-service. Deze I AM-service wordt gebruikt bij controle van toegang tot gemeenschappelijke als de lokale deelnemende netwerken inclusief de in deze netwerken aanwezige applicaties en informatie. Identiteiten in de directory van deze I AM-service worden primair ‘gehaald’ uit bestaande basisregistraties en kernadministraties. 8. Gemeenschappelijke voorzieningen (zoals de Servicebus Amsterdam en de I AM-service) worden opgenomen in centrale/ gemeenschappelijke netwerken.

8 - 22



9. Technische oplossingen in dienstgebonden netwerken waarvoor in de infrastructuur een gemeenschappelijk alternatief bestaat zijn niet acceptabel. 10. De infrastructuur wordt zo ingericht dat open standaarden ondersteund worden. Niet-open standaarden worden alleen ondersteund als daartoe een dwingende noodzaak bestaat en er geen op open standaarden gebaseerde alternatieven bestaan. 11. Het technisch beheer van de gemeenschappelijke èn dienstgebonden infrastructuur wordt onder één noemer gebracht bij het Servicehuis ICT. Het (logisch) beheer van de identiteiten en daaraan gerelateerde autorisaties ligt niet bij het Servicehuis ICT, maar bij een onafhankelijke (beheer-)organisatie. 12. Amsterdamse applicaties worden zoveel mogelijk ondergebracht in gemeenschappelijke hostingfaciliteiten. Het Servicehuis ICT zal hiervoor een architectuur ontwikkelen die zal gaan gelden als gemeentebrede standaard.

8 - 23


niet alleen papier, ook doen!


9

Architectuurorganisatie en proces

9.1

Inleiding

Zoals in Hoofdstuk 2 aangehaald is dit Handboek van weinig waarde zonder een goede organisatorische inbedding van architectuur binnen de gemeente. Simpel gezegd: niet alleen een architectuur op papier, maar ook onder architectuur gaan werken! Dit hoofdstuk beschrijft de architectuurorganisatie en -processen.

9.2

Architectuurorganisatie

De architectuurorganisatie beschrijft welke partijen betrokken zijn bij het werken onder architectuur en wat de rollen, taken en verantwoordelijkheden zijn van deze partijen. Concern Deelarchi tectuur 1

Eigenaar Deelarchitectuur 1

Stuurgroep Inf.voorz.

Model 9.1 Architectuurorganisatie

Handboek architectuur


Deelarchi tectuur 2


Concernorganisatie

Deelarchi tectuur 3


Lokaal

Lokale architectuur x

Lokale architect stadsdeel X Lokale architectuur y

Lokale architect dienst Y

Lokale architectuur Z

Lokale architect bedrijf Z

[Bron: Adviesgroep Architectuur] In Model 9.1 worden vijf partijen onderscheiden: 1. Stuurgroep Informatievoorziening Dit is de concernbrede Stuurgroep die gaat over de concernbrede informatievoorziening en ICT en het voorportaal vormt van de Commissie Informatievoorziening (zie ook paragraaf 4.3.4 ).

9-1



2. Adviesgroep Architectuur Dit is een concernbrede groep die bestaat uit architectuurspecialisten van diensten, bedrijven en stadsdelen. De groep is opgezet vanuit het programma BRI en heeft zich van daaruit geleidelijk aan ontwikkeld tot een concernbrede groep (zie kader). 3. Directie Concern Organisatie (CO) De directie CO is verantwoordelijk voor het concernbrede informatie- en ICT-beleid. Hieronder valt ook het beheer van het Handboek Architectuur inclusief de afstemming met eigenaren van deelarchitecturen. CO voert verder het secretariaat voor de Commissie en de Stuurgroep Informatievoorziening en zit de Adviesgroep Architectuur voor. 4. Eigenaren van deelarchitecturen Dit zijn de organisaties of personen die verantwoordelijk zijn voor de ontwikkeling en het beheer van onderdelen 45 van het concernbrede Handboek Architectuur. Deze eigenaren zijn werkzaam bij diensten, bedrijven of stadsdelen. 5. Lokale architecten Dit zijn de personen die binnen de verschillende diensten, bedrijven en stadsdelen verantwoordelijk zijn voor de lokale architectuur. Het onderscheid tussen het concerndomein en het ‘lokale’ domein is ook weergegeven in het model. De partijen 1 t/m 4 houden zich bezig met de concernarchitectuur. De lokale architecten zijn verantwoordelijk voor de lokale architecturen. Tenslotte geeft Model 9.1 weer dat er drie type architecturen worden onderscheiden: A. Handboek Architectuur Dit handboek, het wordt ook wel referentiearchitectuur genoemd. Het betreft een gemeenschappelijke architectuur, die de lokale architecturen overstijgt. B. Deelarchitecturen Dit zijn onderdelen binnen het Handboek Architectuur die op specifieke plaatsen worden beheerd. Zoals in de hoofdstukken 4 tot en met 8 is beschreven zijn er heel veel organisaties die het beheer voeren over bepaalde modellen en standaarden. C. Lokale architecturen Dit zijn de architecturen van diensten, bedrijven en stadsdelen met uitzondering van de gedeelten die de organisatie overstijgen en zijn vastgelegd in het Handboek Architectuur 46. Als het goed is sluiten de lokale architecturen (straks) naadloos aan op het Handboek Architectuur. 45

In de hoofdstukken 4 tot en met 8 is in de paragraaf ‘Beheer’ aangegeven welke organisaties verantwoordelijkheid zijn voor het beheer van de verschillende modellen en standaarden in dit Handboek Architectuur. 46 Dit laat onverlet dat in een document met een beschrijving van de lokale architectuur heel goed onderdelen van dit Handboek Architectuur kunnen zijn gebruikt of gekopieerd. Alleen kunnen deze onderdelen niet zo maar door een dienst, bedrijf of stadsdeel worden gewijzigd. In strikte zin valt dit dan ook niet onder de hier gebruikte definitie van ‘lokale architectuur’.

9-2



Buiten deze drie type architecturen zijn er nog twee andere architecturen die omwille van het overzicht niet in Model 9.1 zijn opgenomen, te weten: D. Lokale programma- en projectarchitecturen Dit zijn architecturen die gekoppeld zijn aan specifieke programma’s of projecten die een scope kennen die beperkt blijft tot de dienst, het bedrijf of het stadsdeel. Programma- of projectarchitecturen worden opgesteld wanneer er geen architectuur beschikbaar is of wanneer het project c.q. programma een impact heeft die verschillende architecturen doorkruist. De resultaten van een programma- of projectarchitectuur worden vaak na het programma of project geïntegreerd in de lokale architectuur. E. Organisatieoverstijgende programma- en projectarchitecturen Het verschil met D. zit hem in het organisatieoverstijgende karakter. Bij concernprogramma’s of projecten kunnen de resultaten van het programma of project ‘landen’ in het Handboek Architectuur. In Bijlage 19 wordt nader op op de rol van architecten in projecten ingegaan. Kader: De ontwikkeling van de Adviesgroep Architectuur De Adviesgroep Architectuur is in de zomer van 2005 opgezet vanuit het programma BRI. In het kader van dat programma werd de conclusie getrokken dat het programma alleen succes kon hebben wanneer onder architectuur gewerkt zou worden. De oorspronkelijke samenstelling bestond dan ook uit vertegenwoordigers van de BRI-deelnemers. In de loop van de tijd is de focus van de adviesgroep verlegd naar het concern als geheel. Aangezien het gebruik van basisregistraties een wettelijke verplichting is, kan geen enkel onderdeel binnen het concern zich hieraan onttrekken. De BRI-architectuur moest derhalve een breder draagvlak krijgen dan alleen de steun van BRI-deelnemers. Ook werd geleidelijk aan duidelijk dat BRI niet los kon worden gezien van andere relevante concernontwikkelingen op alle lagen van de architectuur. Deze verbreding van de scope vertaalde zich ook in de samenstelling van de adviesgroep. Stadsdelen gingen met een vertegenwoordiging meedoen en gedurende de ontwikkeling van dit Handboek hebben zich ook andere diensten aangesloten, bijvoorbeeld door te participeren in werkgroepen. Ook in de besluitvorming over dit Handboek is deze ontwikkeling zichtbaar. De Stuurgroep BRI was nog verantwoordelijk voor de besluitvorming over een tussenversie in september 2006. Daarna is de Adviesgroep Architectuur als het ware ‘verhangen’: waar het eerst rechtstreeks onder de Stuurgroep BRI hing, hangt het nu rechtstreeks onder de Stuurgroep Informatievoorziening. Via deze laatste Stuurgroep wordt het Handboek doorgeleid naar de Commissie Informatievoorziening waar het Handboek wordt vastgesteld. Op deze wijze is de adviesgroep die als uitvloeisel van een programma startte nu dus ingebed in de reguliere lijn. Dit zal op de volgende wijze gebeuren : • elke dienst, bedrijf of stadsdeel kan één vertegenwoordiger afvaardigen voor de Adviesgroep Architectuur;

9-3



• •

het aantal actieve leden van de Adviesgroep met het oog op de vergaderefficiëntie gemaximeerd wordt op 15 personen; wanneer blijkt dat er meer dan 15 geïnteresseerde vertegenwoordigers zijn, een rouleringssysteem wordt gehanteerd waarbij elk jaar maximaal 3 personen worden vervangen. A)

B)

C)

D)

E)

Handboek

Deel

Lokale

Lokale

Organisatie-

Architectuur

architectuur

architectuur

prog/project

overstijgend

architectuur

prog/project architectuur

1) Stuurgroep InformatieTabel 9-1 Architectuur:,

voorziening

Rollen, taken en

2)

verantwoordelijkheden

Adviesgroep

V

V

A

A

BO

C

-

BO

-

-

-

V

-

47

A

architectuur 3) Directie CO

C

48

C

49

C

50

4) Eigenaren deelarchitec

-

-

A+BO+T

A+BO+T

A+BO+T

turen 5) Lokale architecten

BO

51

Legenda bij Tabel 9-1 V = Vaststellen (besluiten) BO = Beheren & ontwikkelen A = Adviseren T = Toetsen C = Controleren (op naleving)

In Tabel 9-1 is aangegeven welke partij bij welk type architectuur welke rol speelt. Daarover kan nog het volgende worden gezegd. 1. Stuurgroep Informatievoorziening De Stuurgroep is eigenaar van het Handboek Architectuur. Ze besluit alleen over grote wijzigingen van het Handboek. ‘Besluiten’ is eigenlijk niet het goede woord. Formeel zijn het college van B&W en de besturen van stadsdelen die daarover besluiten. De Commissie Informatievoorziening heeft daarbij een zware adviserende rol. Het voorportaal voor de Commissie Informatievoorziening is de Stuurgroep Informatievoorziening. 2. Adviesgroep Architectuur; De Adviesgroep Architectuur kan over kleine en niet controversiële 47

Voor zover het gaat om concernprogramma’s en –projecten. Voor zover het gaat om de conformiteit met het Handboek Architectuur. 49 Voor zover het gaat om projecten die vallen onder het beleid Grote ICT-projecten. 50 Voor zover het gaat om projecten die vallen onder het beleid Grote ICT-projecten. 51 Lokale architecturen worden door het lokale management vastgesteld. 48

9-4



wijzigingen van het Handboek besluiten. Verder heeft de Adviesgroep een adviserende rol, gevraagd (op verzoek van bijvoorbeeld de Stuurgroep Informatievoorziening, diensten, programmaleiders of de Directie CO) of ongevraagd. Daartoe onderhoudt en verdiept de Adviesgroep haar kennis over (ontwikkelingen op het gebied van) architectuur. Concreet zijn de taken en verantwoordelijkheden van de Adviesgroep 52: • Beoordelen of de resultaten die uit projecten voortkomen inpasbaar zijn in het Handboek Architectuur en hierover adviseren; • Initiëren van en adviseren over wijzigingen in het Handboek Architectuur aan de Stuurgroep Informatievoorziening; • Adviseren over concrete architectuurvragen met implicaties voor het concern die aan de adviesgroep worden gesteld. 3. Directie Concern Organisatie (CO); Concreet zijn de taken en verantwoordelijkheden van de directie CO: • Voorzitten van de Adviesgroep Architectuur. • Voeren van het beheer over het Handboek Architectuur. • Voeren van de regie over de ontwikkeling en het beheer van deelarchitecturen. • Vormen van vraagbaak over het Handboek Architectuur • Toetsen van naleving van de architectuur (in het kader van de reguliere planning & control) Zo nodig schakelt de directie CO de Adviesgroep Architectuur in voor hulp en advies. 4. Eigenaren van deelarchitecturen De eigenaren van deelarchitecturen zijn verantwoordelijk voor de ontwikkeling en het beheer van ‘hun deel’ van het Handboek Architectuur. Ook zij kunnen een adviserende rol spelen. Concreet zijn de taken en verantwoordelijkheden: • Beslissen over de architectuur waar betreffende organisatie eigenaar van is onder de voorwaarde dat dit in lijn is met de rest van het Handboek Architectuur 53. • Ontwikkelen en beheren van de betreffende deelarchitectuur (inclusief het ontwikkelen en beheren van documentatie); • Adviseren over de betreffende deelarchitectuur. 5. Lokale architecten Lokale architecten ontwikkelen en beheren hun lokale architectuur. Ze hebben een belangrijke toetsende rol bij programma- en projectarchitecturen. Concreet zijn de taken en verantwoordelijkheden: • Ontwikkelen van een lokale architectuur die aansluit op het Handboek Architectuur. • Bewaken of ontwikkelingen binnen de eigen organisatie (bijvoorbeeld projecten of programma’s) in lijn zijn met het Handboek Architectuur en of deze voldoen aan de lokale architectuur.

52

Tot de vaststelling van de eerste versie van het handboek neemt de adviesgroep ook het voortouw bij het ontwikkelen van het Handboek Architectuur. Door in het handboek organisaties aan te wijzen die de verantwoordelijkheid voor de verdere ontwikkeling van deelarchitecturen op zich kunnen nemen, kan deze ‘ontwikkelrol’ geleidelijk aan worden losgelaten. 53 Als blijkt dat een voorgenomen wijziging van een deelarchitectuur niet past binnen het Handboek Architectuur zal de eigenaar samen met de directie CO moeten onderzoeken wat de consequenties zijn voor de rest van de architectuur. Zonodig wordt de Adviesgroep Architectuur betrokken voor advies.

9-5



Kader: Het benoemen en opleiden van lokale architecten Om een consistente overkoepelende architectuur werkend te krijgen dient elke gemeentelijke organisatie één of meerdere mensen verantwoordelijk te maken voor de lokale architectuur. Net zoals elke organisatie een informatiebeveiligingscoördinator kent, moet er dus ook een architect per organisatie komen. Afhankelijk van de organisatie kan dit ook één van de taakgebieden van een informatiemanager zijn (zie ook Meerjarenplan Informatiemanagement). De informatiemanager zorgt voor de alignment tussen busines en ICT, hierbij speelt zowel het ontwikkelen van de visie op de informatievoorziening en ICT (informatiebeleidsplan) een rol als de vertaling hiervan naar de inrichting met behulp van architectuur. Aanwijzen alleen is niet genoeg. Architectuur is een vak en opbouw en onderhoud van architectuurkennis is van groot belang. Daarbij komt dat voor effectieve concernsamenwerking het van belang is dat de Amsterdamse architecten ook dezelfde ‘taal’ gaan spreken en op een vergelijkbaar (minimum)kennisniveau komen (en blijven!). Hier kan opleiding een belangrijke rol spelen. Het voorstel is dan ook om in het kader van het Meerjarenplan Informatiemanagement vanuit het concern een standaard architectuur opleiding te organiseren. Deze opleiding wordt zo opgezet dat de kennis direct wordt toegepast in de concrete praktijk. Concreet betekent dit dat tijdens de opleiding gewerkt wordt aan het opstellen of uitbouwen van een lokale architectuur. Een nieuwe functie, opleiden ….. het komt misschien over als een last. Het zal echter op lange termijn een lust blijken: door onder architectuur te werken zal aanzienlijk kunnen worden bespaard!

9.3

Architectuurproces

In de vorige paragraaf zijn geregeld termen als ‘adviseren’, ‘ontwikkelen’ en ‘beheren’ gebruikt. Dit zijn voorbeelden van processen die spelen bij werken onder architectuur. Deze paragraaf beschrijft de belangrijkste architectuurprocessen die zich voordoen rond het Handboek Architectuur 54: • Het proces rond het adviseren over en toetsen van de architectuur • Het proces rond het ontwikkelen en beheren van de architectuur.

54

We zoomen dus niet in op processen rond deelarchitecturen en lokale architecturen. Voor die architecturen gelden in principe dezelfde soort processen.

9-6



9.3.1

Toetsen en adviseren

Interne toetsing Lokaal

Planning-& Controlcyclus

Confirmeren aan referentie architectuur

Aantonen noodzaak afwijking

Lokale Architecten

Publiceren jaarstukken

Model 9.2 Toetsen van de architectuur

Rapportage Zoeken naar conformiteit

Concern Adviesgroep Architectuur

Monitoren architectuurtraject

Concernorganisatie Externe auditor

Integrale meting bedrijfsvoering

[Bron: Adviesgroep Architectuur] Bij adviseren over en toetsen van architectuur gaat het feitelijk om eenzelfde soort vraag: in hoeverre past iets (bijvoorbeeld een nieuwe deelarchitectuur, projectarchitectuur of een lokale architectuur) in de referentiearchitectuur die in het Handboek Architectuur is vastgelegd? Onder toetsen wordt verstaan het beoordelen van de mate van conformiteit van deel-, project en lokale architecturen in het kader van de reguliere planning- & control instrumenten. Onder adviseren wordt verstaan het gevraagd en ongevraagd doen van uitspraken en geven van suggesties over de mate van conformiteit van deel-, project en lokale architecturen buiten de reguliere planning & control cyclus. Toetsen Deze architectuur is een wassen neus als we ons er met z’n allen niet aan gaan houden. Toetsing aan de architectuur is daarom gewenst zowel binnen diensten, bedrijven en stadsdelen als op concernniveau. Daarbij is het uitgangspunt dat diensten, bedrijven en stadsdelen zelf verantwoordelijk zijn om zich aan de architectuur te houden. De verantwoordelijkheid voor deze interne toetsing ligt bij de lokale architect.

9-7



Voor de toetsing op concernniveau verdient het de voorkeur om hiervoor geen nieuw toetsingsproces te ontwikkelen. Beter kan worden aangesloten bij de reguliere planning- & control cyclus. Hoe? Door architectuur als norm op te nemen in de Bedrijfsvoeringsverklaring (BVV) en in het bestaande beleid rond grote (ICT-) projecten. Audits en rapportage richtlijnen zijn belangrijke onderdelen van dit beleid (zie kader). Voor stadsdelen is de BVV geen instrument en kan naar een alternatief gezocht worden (bijvoorbeeld het bedrijfsvoeringsakkoord). De reguliere planning- en control rond de BVV is zo opgezet dat diensten bij de jaarrekening een verklaring afgeven over vastgestelde bedrijfsvoeringsnormen, de BVV. Eens in de 4 jaar wordt een dienst of bedrijf doorgemeten op deze normen, de Integrale Meting Bedrijfsvoering (IMB). Voor het onderdeel architectuur wordt deze audit door de directie CO uitgevoerd. Zo nodig wordt de Adviesgroep Architectuur geraadpleegd. Zoals in Hoofdstuk 2 aangegeven moet dit Handboek geen keurslijf zijn. Het is voorstelbaar dat bij het realiseren van een specifieke business doelstelling (bijvoorbeeld bij veel tijdsdruk) bewust wordt afgeweken van de architectuur. Wel geldt dan de omgekeerde bewijslast: de organisatie die wil afwijken moet aantonen dat dit nodig is. Verder zal blijken dat veel organisaties bij de vaststelling van deze eerste versie nog niet voldoen aan deze architectuur en tijd nodig zullen hebben om zich te conformeren. Hiermee moet rekening worden gehouden bij de toetsing. In de richtlijnen in paragraaf 9.4 komt dit ook terug. Samengevat: • Diensten, bedrijven en stadsdelen zijn zelf verantwoordelijk om zich aan de architectuur te houden. De verantwoordelijkheid voor de interne toetsing berust bij de lokale architect. • Toetsing op concernniveau loopt via de BVV/IMB en het beleid grote ICTprojecten. De Directie CO is hiervoor verantwoordelijk. Dit geldt alleen voor diensten en bedrijven. • Bij toetsing geldt de omgekeerde bewijslast • Diensten, bedrijven en stadsdelen moeten de tijd krijgen om naar deze architectuur toe te groeien. Kader: Beleid grote ICT projecten Op aandringen van de gemeenteraad is er beleid gekomen om grote ICTprojecten beter te beheersen. Grote ICT-projecten zijn projecten met een projectbudget groter dan de Europese aanbestedingsgrens met een aanzienlijke ICT component bestaande uit onder andere hardware, software en de hiervan afgeleide diensten. Het regelmatig laten uitvoeren van audits door een externe organisatie vormt een belangrijk onderdeel van het beleid. Deze audits vormen niet alleen een ‘vinger aan de pols’ ten behoeve van het college van B&W en de raad, maar kan juist ook voor de dienst een welkome aanvulling zijn voor het monitoren

9-8



van het project. De kosten van de audit mogen in (de aanvraag voor) het project-budget opgevoerd worden.

Concernorganisatie

Advisering op eigen initiatief

Niet beantwoordbaar

Architectuur Vragen

Derde lijn

architectuur

Tweede lijn

Eerste lijn

Model 9.3 Adviseren over

Lokale Architect

Adviesgroep Architectuur Eigenaar Deelarchitectuur Ongevraagd advies SG

Beantwoordbaar Advies

Niet beantwoordbaar

Architectuur Vragen

Architectuur Vragen SG

Advies SG

Beantwoordbaar

Advies

Architectuur Vragen Advies

[Bron: Adviesgroep Architectuur] Adviseren Het adviseren is niet gekoppeld aan de reguliere planning & control cyclus. Wel zijn bekende spelers betrokken. De belangrijkste adviseurs zijn: • De lokale architect • De directie CO • De Adviesgroep Architectuur • De eigenaren van deelarchitecturen Zoals uit Model 9.3 blijkt bestaat het proces adviseren uit de volgende onderdelen: • Architectuurvragen die ontstaan binnen diensten, bedrijven en stadsdelen (bijvoorbeeld bij de start van nieuwe projecten) worden zo veel mogelijk beantwoord door de lokale architect (1e lijn) • De lokale architect kan besluiten om de vraag door te verwijzen naar de directie CO (bijvoorbeeld omdat het een concernaangelegenheid betreft en of hij/zij de vraag niet kan beantwoorden). De directie CO fungeert dus als een soort tweedelijns helpdesk (2e lijn) • De directie CO kan - als zij er ook niet uitkomen - besluiten om de vraag door te geleiden naar de ‘echte specialisten’ in de vorm van eigenaren van deelarchitecturen of de Adviesgroep Architectuur (3e lijn). Daarnaast geldt voor architectuurvragen die ontstaan binnen de Stuurgroep Informatievoorziening dat deze worden behandeld door de Adviesgroep Architectuur. Deze komen binnen via de directie CO (die ook het secretariaat voert over de Stuurgroep Informatievoorziening). Verder kan de Adviesgroep Architectuur besluiten om de Stuurgroep Informatievoorziening ongevraagd te adviseren.

9-9



9.3.2

Ontwikkelen en beheren

Voorstel wijziging

Vastgestelde architectuur(-versie)

Architectuur (-gedeelten) in ontwikkeling

Model 9.4 Ontwikkelen en beheren van architectuur

BEHEERPROCES

(cyclus)

ONTWIKKELPROCES

Analyse verschillen Impact programma’s + overige ontwikkelingen

[Bron: Adviesgroep Architectuur] Ook de processen ontwikkelen en beheren van architectuur liggen in elkaars verlengde. Ontwikkeling om tot een nieuwe of verbeterde architectuur te komen. Beheer is het gecontroleerd en systematisch doorvoeren van wijzigingen op de architectuur. Het beheerproces is belangrijk omdat de organisaties erop moeten kunnen vertrouwen dat de uitgangspunten zoals die in de architectuur zijn genoemd, een zekere status en geldigheid hebben. Ontwikkelen en beheer vormen samen een continue cyclus (zie Model 9.4) Aanleiding

Voorbereiding

Wijziging Informatiebeleid of strategie

Uitwerking

Voorstel voor aanpassen

Goedkeuring

Rapportage Verwerken commentaar

Architect Wijziging dienst informatieplan

Uitwerken voorstel

Model 9.5 Ontwikkelen en beheren van architectuur (detail) Adviesgroep Architectuur

Terugkoppeling Uit een project

Stuurgroep Inf.voorz.

Beoordelen

Aanpassen Architectuur

Publiceren

Besluitvorming

[Bron: Adviesgroep Architectuur] In Model 9.5 is in meer detail te zien hoe het proces van ontwikkelen en beheren van architectuur eruit ziet. Het voorbeeld beperkt zich ook tot de ontwikkeling en beheer van het Handboek Architectuur. Er worden daarbij vier fasen onderscheiden:

9 - 10



1. 2. 3. 4.

Aanleiding Voorbereiding Uitwerking Goedkeuring

Ad 1. Aanleiding Grofweg zijn er drie aanleidingen te onderscheiden die een trigger vormen voor verdere ontwikkeling van de architectuur: a) Een wijziging van het beleid van een dienst, bedrijf of stadsdeel 55. In veel gevallen zal het gaan om een wijziging van het informatiebeleid (bijvoorbeeld vastgelegd in een informatieplan) van een dienst, maar het kan ook gaan om beleid rond de organisatie- of procesarchitectuur. Bij wijziging controleert de architect altijd wat de consequenties zijn voor het Handboek Architectuur (en de lokale architectuur). b) De terugkoppeling vanuit een programma of project Een programma of project dat werkt volgens de richtlijnen en kaders van het Handboek Architectuur kan gedurende de uitvoering van het project tegen dingen aanlopen. Zo kan bijvoorbeeld een richtlijn uit de architectuur niet duidelijk zijn of dat een nieuwe standaard wordt ontwikkeld. Het is van belang dat deze informatie teruggekoppeld wordt in de architectuur. c) Een wijziging van het concernbeleid Hiervoor geldt hetzelfde als bij a) alleen nu op het niveau van het concern. Deze drie aanleidingen kunnen leiden tot een globaal voorstel voor aanpassing van het Handboek Architectuur Ad 2. Voorbereiding Het voorstel voor aanpassing wordt beoordeeld door de Adviesgroep Architectuur op nut, noodzaak en wenselijkheid. Als het voorstel is beoordeeld en goedgekeurd kan de architect (dit zal afhankelijk van de situatie een lokale architect of deelarchitect zijn) het voorstel gaan uitwerken. Ad 3. Uitwerking De architect zal in de uitwerking aangeven wat de aanpassing van de architectuur precies behelst en wat de consequenties zijn voor grondslagen, modellen, standaarden, het beheer en de beveiliging. De architect legt deze uitwerking vervolgens voor aan de adviesgroep. Deze kan haar commentaar en aanbevelingen meegeven, die de architect tijdens de uitwerkingsfase meeneemt. Het eindproduct is een concept van een aangepast Handboek Architectuur en bijgewerkte documentatie. Ad 4. Goedkeuring Dit concept wordt ter goedkeuring voorgelegd aan de adviesgroep. De adviesgroep laat de aanpassing goedkeuren door de Stuurgroep Informatievoorziening (en zonodig de Commissie Informatievoorziening en het college 55

We gaan er hier vanuit dat belangrijke externe ontwikkelingen altijd een plaats krijgen in (wijziging van) beleid. De praktijk is natuurlijk minder zuiver. Duidelijk moet echter zijn dat belangrijke veranderingen “van buitenaf” verwerkt moeten worden in de architectuur.

9 - 11



van B&W en de stadsdeelbesturen). Na goedkeuring kan de nieuwe versie (zie kader) van de architectuur gepubliceerd en breed gecommuniceerd worden. Kader: Versiebeheer van architectuur Het versiebeheer van architectuurproducten is essentieel. Er worden daarbij nieuwe versies (bijvoorbeeld van versie 2.0 naar versie 3.0) en tussenversies (bijvoorbeeld van versie 2.1 naar versie 2.2.) onderscheiden. Het versiebeheer van dit Handboek Architectuur kennen de volgende richtlijnen: 1. Een wijziging van het concern informatiebeleidsplan leidt in de regel tot een nieuwe versie 56. 2. Een projectmatig aangepakte doorontwikkeling van de architectuur leidt tot een nieuwe versie 57. 3. Een wijziging van het (informatie)beleid van een dienst, bedrijf of stadsdeel met impact op het Handboek Architectuur leidt tot een tussenversie. 4. De terugkoppeling van een programma of project leidt tot een tussenversie. 5. Een tussenversie ontstaat ook als de aangebrachte wijzigingen in de (documentatie van) architectuur uiteindelijk toch worden afgekeurd door de Adviesgroep Architectuur 58. Een zelfde systematiek kan gehanteerd worden voor lokale architecturen en deelarchitecturen. Voor projectarchitecturen geldt in aanvulling nog de volgende richtlijnen: 6. Gedurende de uitvoering van een project of programma wordt met één en dezelfde versie van een architectuur gewerkt. 7. Na afronding van het project of programma wordt gecontroleerd of de projectarchitectuur nog voldoet. Zo nodig worden relevante wijzigingen in een nieuwe versie van de projectarchitectuur verwerkt en teruggekoppeld aan de lokale architect en/of Adviesgroep Architectuur. Zo kan bekeken worden of projectarchitectuur gevolgen heeft voor de lokale architectuur c.q. het Handboek Architectuur

56

We hebben gezien dat buiten het informatiebeleid ook ander concernbeleid impact kan hebben op de architectuur. Daarbij gaat het met name om beleid dat raakt aan de organisatieen/of procesarchitectuur. Het is aan de Adviesgroep Architectuur om te bepalen of dit moet leiden tot een nieuwe versie of een tussenversie. Zo nodig gaat dit in overleg met de Stuurgroep Informatievoorziening. 57 We kennen nu een eerste versie van de architectuur die nog niet compleet is. De komende jaren zal deze architectuur eerst projectmatig worden doorontwikkeld. 58 Op deze manier wordt een (historisch) overzicht opgebouwd van voorgestelde aanpassingen die het uiteindelijk niet gehaald hebben. Het spreekt voor zich dat na afkeuring van een bepaalde versie met de voorgaande versie wordt verder gewerkt.

9 - 12



9.4

Standaarden

9.4.1

Richtlijnen

Er gelden geen specifieke richtlijnen op dit terrein.

9.4.2


In onderstaande tabel zijn de uniforme standaarden opgenomen die gelden binnen de organisatiearchitectuur. Nr. en naam standaard

Toelichting

Bron

Referentiearchitectuur/Handboek Architectuur

Het samenhengend geheel van de organisatie-, proces-, informatie, applicatie- en infrastructuurarchitectuur met hierin opgenomen per architectuur de geldende modellen en standaarden.


ArchiMate

Een architectuurtaal en visualisatietechnieken die op een éénduidige manier de samenhang en relaties tussen de verschillende architectuurlagen in kaart helpt te brengen. En ter ondersteuning en verbetering van het architectuurproces.

ArchiMate Forum

Tabel 9-2 Uniforme standaarden architectuurorganisatie en proces

9.4.3



9.4.4

Afspraken


9 - 13



9.5

Beheer

Nr. en naam model Model 9.1 Architectuurorganisatie Model 9.2 Toetsen van

de architectuur Tabel 9-3 Beheer modellen

Model 9.3 Adviseren over architectuur Model 9.4 Ontwikkelen en beheren van

Eigenaar Stuurgroep Informatievoorziening Stuurgroep Informatievoorziening Stuurgroep Informatievoorziening Stuurgroep Informatievoorziening

Beheerder CO/Informatiebeleid


CO/Informatiebeleid


Beheerder


CO/Informatiebeleid


Telematica Instituut

CO/Informatiebeleid CO/Informatiebeleid CO/Informatiebeleid

architectuur (cyclus) Model 9.5 Ontwikkelen en beheren van

architectuur (detail)

Tabel 9-4 Beheer standaarden

9 - 14

Nr. en naam standaard Referentiearchitectuur /Handboek Architectuur Archimate



9.6

Conclusies

1. Amsterdam kent de volgende architectuurproducten : a. Handboek Architectuur b. Deelarchitecturen c. Lokale architecturen d. Lokale programma- en projectarchitecturen e. Organisatieoverstijgende programma- en projectarchitecturen. 2. Er is een Adviesgroep Architectuur die rechtstreeks onder de Stuurgroep Informatievoorziening ressorteert. De Adviesgroep representeert alle diensten, bedrijven en stadsdelen. De rollen, taken, bevoegdheden en wijze van representatie van deze Adviesgroep Architectuur zijn in dit Handboek vastgelegd. 3. Alle diensten, bedrijven en stadsdelen wijzen tenminste één persoon aan als architect. 4. Er komt vanuit het concern een standaard architectuur opleiding voor architecten.

conclusies architectuurorganisatie en

5. Diensten, bedrijven en stadsdelen zijn zelf verantwoordelijk om zich aan dit Handboek Architectuur te houden. De verantwoordelijkheid voor de interne toetsing berust bij de lokale architect.

-proces

6. Toetsing aan dit Handboek op concernniveau voor diensten en bedrijven gaat lopen via de bedrijfsvoeringsverklaring/integrale meting bedrijfsvoering en het beleid grote ICT-projecten. Bij toetsing geldt de omgekeerde bewijslast. 7. Diensten, bedrijven en stadsdelen moeten de tijd krijgen om naar deze architectuur toe te groeien. 8. Voor advisering over architectuur geldt een drietrapsraket: • de lokale architect vormt de 1e lijn • de directie CO vormt de 2e lijn • de Adviesgroep Architectuur en eigenaren van deelarchitecturen vormen de 3e lijn. 9. Het Handboek Architectuur wordt ontwikkeld en beheerd volgens het in dit Handboek beschreven proces. 10. Ter ondersteuning van de architectuurprocessen worden op concernniveau instrumenten (bijvoorbeeld templates, software) aangeschaft die aan alle organisaties beschikbaar worden gesteld.

9 - 15



Lijst van modellen

Model 1.1 Voorbeeld van een model ..........................................................................2 Model 4.1 Belangrijkste partners van de gemeente .................................................14 Model 4.2 Belangrijkste landelijke initiatieven ..........................................................14 Model 4.3 BurgerServiceCode..................................................................................14 Model 4.4 Thematische indeling diensten en producten ..........................................16 Model 4.5 Organisatiestructuur gemeente Amsterdam ............................................17 Model 4.6 De regie-functie op de ICT .......................................................................19 Model 4.7 Organisatietypologie volgens EGEM: front-, miden back office ............21 Model 4.8 Stap 0: de uitgangssituatie.......................................................................22 Model 4.9 Stap 1: de gemeente na één-loket en multichannel ................................22 Model 4.10 Stap 2: de organisatorische mid office als tijdelijke oplossing ...............23 Model 4.11 Stap 3: de technische mid office als eindoplossing ...............................23 Model 5.1: Hoofdprocesplaat van Diesntverlening ...................................................12 Model 6.1: Gemeentelijke informatiehuishouding.......................................................5 Model 6.2: Zes basisregistraties (conceptueel) ..........................................................7 Model 6.3: Zes basisregistraties met beheerders.......................................................8 Model 6.4: Objectenmodel van stelsel van gemeentelijke basisgegevens ................9 Model 6.5: Het zaakdossier (objectenmodel) ...........................................................12 Model 6.6: GFO Zaken .............................................................................................13 Model 6.7: Digitaal informatiebeheer ........................................................................14 Model 7.1 Typologie applicatielandschap (globaal)....................................................5 Model 7.2 Typologie applicatielandschap: uitwerking presentatielaag.......................6 Model 7.3 Typologie applicatielandschap: uitwerking integratielaag..........................9 Model 7.4 Typologie applicatielandschap: uitwerking laag domeinen......................13 Model 7.5 Typologie applicatielandschap: uitwerking datalaag................................15 Model 7.6 Typologie applicatielandschap: uitwerking alle lagen ..............................16 Model 7.7 Het huidige versnipperde applicatielandschap ........................................17 Model 7.8 Het huidige applicatielandschap (in typologie) ........................................18 Model 7.9 Het toekomstige applicatielandschap: wat kan gemeenschappelijk?......19 Model 8.1 Domeinen E-net (1)....................................................................................5 Model 8.2 Beveiligingsniveaus....................................................................................6 Model 8.3 Domeinen E-net (2)....................................................................................8 Model 8.4 Uitwerking functies integratielaag (detail) ................................................10 Model 8.5 I AM-service startsituatie: Synchronisatie identiteiten .............................12 Model 8.6 I AM-service groeiscenario: Synchronisatie identiteiten ..........................15 Model 8.7 Dataopslag ...............................................................................................16 Model 8.8 Dataverwerking ........................................................................................16 Model 8.9 Standaard werkplek .................................................................................16 Model 9.1 Architectuurorganisatie ..............................................................................1 Model 9.2 Toetsen van de architectuur ......................................................................7 Model 9.3 Adviseren over architectuur .......................................................................9 Model 9.4 Ontwikkelen en beheren van architectuur (cyclus) ..................................10 Model 9.5 Ontwikkelen en beheren van architectuur (detail) ...................................10

Lijst van modellen - 1



Lijst van tabellen

Tabel 2-1 Amsterdamse architectuurraamwerk .............................................................6 Tabel 4.1 Richtlijnen organisatiearchitectuur ..............................................................25 Tabel 4.2 Uniforme standaarden organisatiearchitectuur ...........................................25 Tabel 4.3 Beheer modellen ..........................................................................................27 Tabel 4.4 Beheer standaarden.....................................................................................28 Tabel 4-5 Relevante paragrafen GIBN.........................................................................29 Tabel 5.1 Richtlijnen procesarchitectuur .....................................................................15 Tabel 5-2 Beheer modellen ..........................................................................................17 Tabel 5-3 Relevante paragrafen GIBN.........................................................................18 Tabel 6-1 Overzicht kandidaat kernadministraties.......................................................10 Tabel 6-2 Richtlijnen informatiearchitectuur................................................................16 Tabel 6-3 Uniforme standaarden informatiearchitectuur.............................................16 Tabel 6-4 Bandbreedte standaarden informatiearchitectuur ......................................17 Tabel 6-5 Afspraken standaarden informatiearchitectuur ...........................................17 Tabel 6-6 Beheer modellen ..........................................................................................18 Tabel 6-7 Beheer standaarden ....................................................................................18 Tabel 6-8 Relevante paragrafen GIBN.........................................................................19 Tabel 7-1 Uitwerking functies integratielaag ................................................................11 Tabel 7.2 Richtlijnen applicaties algemeen.................................................................22 Tabel 7.3 Richtlijnen voor integratie............................................................................22 Tabel 7-4 Richtlijn voor standaardisering gemeenschappelijke functies ....................23 Tabel 7-5 Uniforme standaarden Applicatiearchitectuur.............................................23 Tabel 7-6 Standaarden Applicatiearchitectuur............................................................25 Tabel 7-7 Beheer modellen ..........................................................................................26 Tabel 7-8 Beheer standaarden ....................................................................................27 Tabel 7-9 Relevante paragrafen GIBN.........................................................................29 Tabel 8-1 Risicoklassen WBP en domeinenindeling .....................................................6 Tabel 8-2 Uitwerking functies integratielaag ................................................................10 Tabel 8.3 Richtlijnen infrastructuurarchitectuur...........................................................17 Tabel 8-4 Uniforme standaarden infrastructuurarchitectuur .......................................18 Tabel 8-5 Beheer modellen ..........................................................................................19 Tabel 8-6 Beheer standaarden ....................................................................................19 Tabel 8-7 Relevante paragrafen GIBN.........................................................................20 Tabel 9-1 Architectuur:, Rollen, taken en verantwoordelijkheden .................................4 Tabel 9-2 Uniforme standaarden architectuurorganisatie en proces..........................13 Tabel 9-3 Beheer modellen ..........................................................................................14 Tabel 9-4 Beheer standaarden ....................................................................................14

Lijst van tabellen - 1



Kruistabel: samenhang tussen de modellen

PM wordt in een volgende versie uitgewerkt.

Kruistabel: samenhang tussen de modellen - 1



Bibliografie


Bibliografie - 1



Index


Index - 1



Bijlagen

Bijlage 1

Begrippenlijst ..........................................................................................................................2

Bijlage 2

Beheer: Raamwerk..................................................................................................................7

Bijlage 3

Informatiebeveiliging: GIBN.................................................................................................15

Bijlage 4

Grondslagen ..........................................................................................................................19

Bijlage 5

Modellering ............................................................................................................................26

Bijlage 6

Organisatiearchitectuur: Organisatie van de informatievoorziening ..............................30

Bijlage 7

Organisatiearchitectuur: Advies voor besturingsmodel ..................................................40

Bijlage 8

Informatiearchitectuur: Objectmodellen Personen en Vastgoed.....................................44

Bijlage 9

Informatiearchitectuur: StUF Standaard Uitwisselings Formaat .....................................46

Bijlage 10

Informatiearchitectuur: Standaarden digitale informatiebeheer......................................48

Bijlage 11

Informatiearchitectuur: Principes gegevensbescherming ...............................................52

Bijlage 12

Applicatiearchitectuur: Applicatielandschap.....................................................................55

Bijlage 13

Applicatiearchitectuur: landelijke ontwikkelingen integratievoorziening.......................62

Bijlage 14

Applicatiearchitectuur: Toegang verlenen tot basisregistraties met Paraplu en Diva ..64

Bijlage 15

Applicatiearchitectuur: Gemeenschappelijkheid ..............................................................69

Bijlage 16

Applicatiearchitectuur: Standaard inrichting en ontwikkeling.........................................71

Bijlage 17

Integratiearchitectuur: Berichtenuitwisseling....................................................................73

Bijlage 18

Architectuurorganisatie: Omschrijving architectenrol .....................................................76

Bijlage 19

Architectuurorganisatie: Rol architect in projecten..........................................................78

Bijlagen - 1



Bijlage 1

Begrippenlijst

PM wordt in een volgende versie verder uitgewerkt. Begrip

Definitie

Bron

Andreas Apparaat

Een ICT-resource waarop applicaties ‘draaien’.

Applicatie

Een afgebakende eenheid software.

Applicatiefunctie

Een eenheid van activiteit die door een applicatie kan worden uitgevoerd

Applicatie-server

Technische voorziening die applicaties / bedrijfslogica en webpagina’s beschikbaar stelt. Standaard interface J2EE(?)

Attribuutmodel

PM voor werkgroep

Handboek 6.3.2

Authenticeren Authentieke registratie Autoriseren Back office

het back office vormt het hart van een organisatie waar zich, onzichtbaar voor de buitenwereld, de primaire (gegevensverwerkende) processen afspelen.

Bedrijfsobject

Een eenheid van informatie die van belang is vanuit een organisatorisch perspectief.

Bericht

Een combinatie van gegevens die in een ‘envelop’ worden uitgewisseld. (Bron: NORA)

Centrale

Content (statische informatie met bijbehorende metagegevens, die kan

contentverzameling

bestaan uit een combinatie van tekst, afbeeldingen, HTML, Worddocumenten, PDF-files, audio en/of video) moet zodanig beschikbaar worden gesteld zodat per contenttype specifieke bewerkingen mogelijk zijn.

Channel management

Bijlagen - 2

EGEM



Begrip

Definitie

Database-server

Technische voorziening die gegevensopslag, structuur en ontsluiting

Bron

mogelijk maakt. Datadictionary Datalaag Digitaal Informatiebeheer Document Management Domeinen EGEM

Kennisplatform voor gemeentelijke vraagstukken rond informatievoorziening, EGEM e-dienstverlening en organisatieontwikkeling

E-Government Employee self service E-net Entiteit

een entiteit kan worden gezien als een object, een "tastbaar" iets dat deel

Handboek

uitmaakt van het datamodel. Voorbeelden hiervan zijn: een auto, een

6.3.2

werknemer, een lied of een gebied. Entiteitenmodel

PM voor werkgroep

Handboek 6.3.2

ER-model Front office

het front office vormt de presentatielaag van een organisatie naar de

EGEM

buitenwereld toe; alle interactie met die buitenwereld speelt zich in het front office af.

Gebeurtenis

Iets dat gebeurt (intern of extern) en gedrag veroorzaakt.

Gegevens

Een geformaliseerde representatie van de beschrijving van een object

Geïntegreerde user

Meerdere applicaties naast elkaar, individueel bepaald, presenteren

Archimate

interface

Bijlagen - 3



Begrip

Definitie

Bron

Gemeentelijk Functioneel Ontwerp ‘Zaken’

EGEM

Gemeenschappelijke integratievoorzieningen Generiek Generieke functie GFO zaken 2002

schrijft de minimale set van gegevens voor (met definities en technische specificaties) die als standaard geldt om centraal de basiskenmerken van een ‘zaak’ te kunnen verzamelen en gegevens over de ‘zaak’ te kunnen halen uit verspreide informatiesystemen. GFO-BG 2006 GIBN Hosting faciliteit Identificeren

Identificeren of authenticeren houdt in dat wordt gecontroleerd of de persoon daadwerkelijk diegene is wie hij of zij beweert te zijn. Dit kan zowel een handmatig proces zijn (bijvoorbeeld de controle van een paspoort) als een geautomatiseerd proces. Meestal gebeurt dit door het aanloggen met een gebruikersnaam en wachtwoord, maar dit kan ook op basis van een token (bijvoorbeeld een smartcard) of op basis van biometrische kenmerken(bijvoorbeeld een vingerafdruk of een irisscan).

Informatieobject

Een geformaliseerde representatie van een object.

Integratielaag Interoperabiliteit Kanaal

De wijze waarop een organisatie communiceert met haar omgeving.

Kernadministratie Keten(proces)

Een ketenproces is een geordende reek bedrijfsprocessen die door verschillende organisaties wordt uitgevoerd met als doel om via één organisatie een (combinatie van) dienst(en) te leveren aan een burger of een bedrijf. (Bron: NORA)

Koppelen achterliggende

De koppeling van de front office met de back office, wordt in Amsterdam

applicaties

volgens dezelfde standaarden opgelost als de koppeling met de

Bijlagen - 4


Begrip


Definitie

Bron

basisgegevens.

Mid office

het mid office is een verzameling functionaliteiten die de processen en

EGEM

bijbehorende applicaties en gegevens in het front office en het back office met elkaar verbindt: een web intake systeem, een broker met adapters, een gegevensmagazijn en eventueel een apart zakenmagazijn.

Netwerk

Een (fysiek) communicatiemedium die apparaten verbindt.

NORA Object

Onderwerp van aandacht waarover informatiebehoefte bestaat

Objectmodel

PM voor werkgroep

Handboek 6.3.2

Organisatie-eenheid

Een organisatie-(onderdeel) of persoon.

OSOSS Portaal Amsterdam Presentatie integratie Presentatielaag Privacy Proces

Een proces is een geordende reeks van (in-)direct waarde toevoegende

NORA

handelingen en oordelen door een mens of machine gericht op een bekend resultaat. Product / Dienst:

De bijdrage die door een organisatie wordt geleverd aan haar omgeving.

Semantiek Service

Een externe eenheid van functionaliteit die door een applicatie wordt

Archimate

geleverd via gedefinieerde interfaces ten behoeve van het gebruik door andere applicaties Service Bus

Bijlagen - 5


Begrip


Definitie

Bron

Servicehuis ICT Standaardisatie van functies StUF 2.X Syntax XML XSD Zaak

een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en EGEM een gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden.

Bijlagen - 6



Bijlage 2

Beheer: Raamwerk

In de afzonderlijke hoofdstukken van dit Handboek Architectuur is in de beheerparagrafen een overzicht te vinden van eigenaren en beheerders van de onderscheiden modellen en standaarden in de architectuur. In deze bijlage is het ‘Raamwerk voor Beheer’ (Versie 0.2 juni 2006: I. Verschuur , ICT Beheergroep) opgenomen. Het geeft meer achtergronden bij en inzicht in de beheeractiviteiten die verricht moeten worden. Afhankelijk van de architectuurlaag verschillen namelijk de werkzaamheden.

2.1

Het raamwerk

Het raamwerk is gebaseerd op de standaardbeheermethoden Business Information Service Library (BISL), Application Services Library (ASL) en Information Technology Infrastructure Library (ITIL). Deze standaardmethoden zijn in elkaar geschoven, waarbij de richtinggevende en sturende processen van BISL zijn gecombineerd met de uitvoerende processen van BISL, ASL en ITIL. Daarnaast heeft er een vertaling plaatsgevonden naar de ‘taal’ binnen de gemeentelijke overheid in het algemeen, en die van Amsterdam in het bijzonder. Het raamwerk is daarmee goed toepasbaar geworden op de dagelijkse praktijk in Amsterdam.

Richtinggevend

Sturend

Sturen IV (wat?) 3.2

7.2 Planning & Control

3.4

Sturen & Inrichten IV-organisatie(hoe?) 3.3

7.3 Financieel 7.4 Behoefte Management Management

4.3 Gebruiksbeheer 4.2

7.5 Contract Management

Functionaliteiten Beheer 4.4

4.5 Uitvoerend

Technisch Beheer 6

Applicatiebeheer 5

Bron: ICT Beheergroep Amsterdam Onderstaand is het raamwerk voor beheer over het 5-lagen model voor architectuur gelegd met hierbij aangeven wie (eigenaar, beheerder), wat (welke laag) en hoe (beheeractiviteiten) belegd moet worden

Bijlagen - 7



wie eigenaar

functioneel beheer der

appl. beheer der

technisch beheerder

wat

hoe Richtinggevende processen Sturende processen gegevensbeheer gebruikersondersteuning functionaliteitenbeheer applicatiebeheer

technisch beheer

Bron: ICT Beheergroep Amsterdam In paragraaf 2.4 zijn de beheeractiviteiten die onderscheiden worden in het ‘Raamwerk voor Beheer’ kort beschreven. De nummers in de eerste kolom zijn de paragraafnummers en in de laatste kolom welke beheerstandaarden: BISL, ASL en ITIL van toepassing zijn.

2.2

Beheerorganisatie

Het beheer binnen de verschillende lagen kan vanuit een bestuurlijke invalshoek bekeken worden. Centraal staat daarbij de ‘zeggenschap’. Er wordt onderscheid gemaakt tussen de eigenaren en de beheerders van infrastructuren en informatiesystemen. Elke applicatie en elke infrastructuur kent een systeemeigenaar. De systeemeigenaar is verantwoordelijk voor de inzet en op zijn last wordt het beheerd. De beheerder is de organisatie die ervoor zorgdraagt dat het gebruik mogelijk is conform de functionele en prestatie-eisen, die met de eigenaar overeengekomen zijn. In onderstaand figuur is de verhouding tussen de diverse bij het beheer betrokkenen weergegeven.

Bron: ICT Beheergroep Amsterdam Amsterdam kent 30 diensten, 7 bedrijven en 14 stadsdelen. Elk van deze organisatie-onderdelen kent een relatief zelfstandige managementverantwoordelijkheid. De directeuren van concernonderdelen en

Bijlagen - 8



stadsdeelsecretarissen zijn verantwoordelijk voor de eigen lokale netwerken en informatievoorziening. De stadsdelen, diensten en bedrijven hebben veel vrijheid bij het inrichten hiervan. Hierdoor kan maatwerk worden geleverd aan integrale managers en snel gereageerd worden op ad-hoc vragen. De relatief grote vrijheid in Amsterdam heeft ook een keerzijde. De applicatieportfolio is op dit moment per organisatie (diensttak) ingericht en daarbinnen per probleemveld / behoefte. Deze vorm van inrichting wordt meestal ‘verticale silo’s’ of ‘eilandautomatisering’ genoemd. Een neveneffect daarbij is, dat ook het beheer versnipperd is ingericht met grote kwaliteitsverschillen. In Amsterdam worden op twee fronten wel al gemeenschappelijk beheer uitgevoerd: • ICT Beheergroep ondersteunt diensten en stadsdelen in de uitvoering van functioneel beheer en hanteert daarbij de in dit handboek beschreven beheermodellen; • Concernorganisatie / eGovernment voert belangrijke onderdelen uit van het functioneel beheer van een portfolio aan presentatievoorzieningen Als voorzieningen gemeenschappelijk in eigendom zijn en / of in gebruik, heeft dit ook een aantal gevolgen voor het beheer. Deze kan dan ook gemeenschappelijk worden ingericht volgens afgesproken beheerstandaarden, zie paragraaf 2.3.

2.3

Beheer: Standaarden

Er wordt ten behoeve van standaardisatie van Beheer van applicaties binnen Amsterdam gekozen voor de drie meest geaccepteerde methoden in Nederland: BiSL, ASL en ITIL. Deze drie methoden geven op een praktische manier invulling aan de driedeling in beheer van Looijen: • Functioneel beheer (BiSL) • Applicatiebeheer (ASL) • Technisch beheer (ITIL). Functioneel beheer Het functioneel beheer verzorgt namens de gebruikersorganisatie (de business) het instandhouden van de functionaliteit van een informatiesysteem, waarbij het systeem optimaal moeten blijven aansluiten op het bedrijfsproces. Enkele jaren geleden is voor het uitvoeren van deze taak de methode BiSL ontwikkeld. BiSL staat voor Business Information Services Library en is een framework voor functioneel beheer en informatiemanagement of anders gezegd voor de vraagkant van ICT beheer. Het volgende figuur geeft een overzicht van de BiSL-methode.

Bijlagen - 9



Bron: ASLfoundation Applicatiebeheer Het functioneel beheer uit de vorige paragraaf vertegenwoordigd de vraagkant van de ICT-organisatie. De aanbodkant wordt gevormd door het applicatiebeheer en het technisch beheer. Het applicatiebeheer is verantwoordelijk voor de instandhouding van de applicaties. Een methode om dit applicatiebeheer procesmatig uit te voeren is ASL. ASL staat voor Application Service Library en bestaat uit 6 clusters van processen, die net als bij BiSL plaats vinden op operationeel, tactisch en strategisch niveau. Hieronder is de methode ASL weergegeven:

Bijlagen - 10



Bron: ASLfoundation Technisch beheer Het technisch beheer zorgt voor het beschikbaar stellen en instandhouden van de infrastructuur waarop informatiesystemen draaien. Al gedurende lange tijd is de meest gebruikte methode op dit gebied ITIL. ITIL staat voor Information Technology Infrastructure Library en is in de jaren 80 ontwikkeld door de engelse overheid (CCTA). ITIL biedt een gemeenschappelijk kader voor alle activiteiten van de automatiseringsafdeling als onderdeel van de dienstverlening, gebaseerd op IT-infrastructuur. De activiteiten worden gegroepeerd in processen. ITIL onderscheidt hierbij vijf aandachtsgebieden: 1. Het zakelijk perspectief (Business perspective) 2. Levering en planning van IT-diensten (Service Delivery) 3. Ondersteuning van IT-diensten (Service Support) 4. Management van de infrastructuur (ICT Infrastructure Management) 5. Management van applicaties (Applications Management) In Nederland ziet men in ICT-organisaties vooral toepassing van de service delivery en de service support processen. Deze processen vinden respectievelijk plaats op het tactische en het operationele besturingsniveau. Op strategisch niveau kent ITIL processen met betrekking tot continuïteit, partnership & outsourcing, het overleven van wijzigingen en het aanpassen van de onderneming bij radicale veranderingen. Hieronder wordt een overzicht gegeven van de service delivery en service

Bijlagen - 11



support processen.

Bron:

2.4

3.2

De beheeractiviteiten RICHTINGGEVEND Sturen van de informatievoorziening

BISL

Het ‘sturen van de informatievoorziening’ richt zich op de toekomst van de informatievoorziening van de organisatie. Er zal gekeken moeten worden naar de veranderingen die er plaats vinden in de omgeving van de informatievoorziening: meer specifiek: de veranderingen in de organisatie, de veranderingen in de keten en de veranderingen in de technologie. Op basis daarvan wordt het informatiebeleid bepaald.

3.3

Sturen en inrichten van de IV Organisatie

BISL

‘Sturen en inrichten van de IV-organisatie’ richt zich op het organiseren van de rollen, taken en relaties betreffende het beheer en onderhoud van de informatievoorziening. Meestal zijn er meerdere partijen betrokken en een goede afstemming is noodzakelijk om een soepel lopende informatievoorziening te garanderen.

3.4

Informatiecoördinatie Bij de informatiecoördinatie gaat het om de afstemming tussen inhoud en inrichting. Daarnaast vindt hier de sturing op de afstemming tussen (het beleid en de inrichting) van de eigen informatievoorziening met die van

Bijlagen - 12

BISL



omringende organisaties plaats.

4.2

FUNCTIONEEL BEHEER Gebruiksbeheer

BISL

De processen uit het gebruikbeheer beschrijven de dagelijkse processen die er voor zorgen dat er een continue en optimale ondersteuning plaatsvindt bij het dagelijks gebruik van de informatievoorziening door de eindgebruikers. Deze processen richten zich op drie onderwerpen: De eindgebruikers De ICT-middelen De inhoud van de informatievoorziening: de gegevens.

4.3

Wijzigingbeheer

BISL

Bij het wijzigingbeheer gaat het erom te besluiten over de inhoud en planning van wijzigingen in de informatievoorziening. Wijzigingen betreffen niet de kleine aanpassingen die via het gebruiksbeheer worden gerealiseerd. Het wijzigingbeheer adviseert ook de eigenaar over de go/nogo van de transitie.

4.4

Functionaliteitenbeheer

BISL

Bij het functionaliteitenbeheer gaat het er om de informatievoorziening (blijvend) op de werkprocessen te laten aansluiten. Zowel de werkprocessen als de wensen ten aanzien van de informatievoorziening zijn niet statisch: dit proces zorgt ervoor dat die wensen en veranderingen geëxpliciteerd worden en hun vertaling krijgen in een wijziging van de informatievoorziening.

4.5

Transitie

BISL

Het proces Transitie is gericht op de daadwerkelijke effectuering van de wijzigingen die hiervoor zijn voorbereid. Deze wijzigingen betreffen: de organisatie (werkprocessen en ondersteunende middelen); de informatievoorziening; de uitvoerders van de beheertaken (functioneel, applicatie en technisch beheer) - de documentatie van de informatievoorziening en werkprocessen.

5

UITVOEREND Applicatiebeheer

ASL

Applicatiebeheer is verantwoordelijk voor de instandhouding van de applicatieprogrammatuur. Het is dus de partij die het softwarematige deel van de informatievoorziening onderhoud. Daar waar functioneel binnen de bestaande mogelijkheden van de applicatie opereert, zorgt het applicatiebeheer voor uitbreiding van de applicatie. Applicatiebeheerders doen dus aan programmeren en systeemontwikkeling. Dit kan zowel gepland (bij wijzigingen) als ad hoc (bij storingen).

Bijlagen - 13



De focus ligt op het onderhoud en de vernieuwing: het aanpassen van de software. De genoemde processen worden gestart vanuit het functioneel beheer: daar komt informatie over storingen vandaan (vanuit gebruiksbeheer) of worden de gewenste wijzigingen geformuleerd (vanuit wijzigingenbeheer). Ongeacht of het een storing of een wijziging betreft zullen alle processen worden doorlopen. Bij een storing zal dit echter sneller gebeuren dan bij een wijziging.

6

Technisch beheer

ITIL

Het technisch beheer zorgt voor het beschikbaar stellen en instandhouden van de infrastructuur waarop informatiesystemen draaien. Sinds jaar en dag is in Nederland (en daarbuiten) ITIL de standaard voor de inrichting van technisch beheer. ITIL staat voor Information Technology Infrastructure Library en de kern van het model wordt gevormd door de processen ‘Service Delivery’ en ‘Service Support’. Deze processen worden in dit hoofdstuk beschreven.

7.2 7.3 7.4 7.5

STUREND Planning & Control Financieel management Behoeftemanagement Contractmanagement De sturende processen zorgen ervoor dat hetgeen is bepaald ten aanzien van de eisen aan de informatievoorziening en de organisatie daarvan, ook daadwerkelijk wordt uitgevoerd binnen de kaders die daarvoor zijn gesteld. De sturende processen bewaken de activiteiten in termen van kosten en baten, behoeften, contracten en service levels en planning.

De ‘dagelijkse’ uitvoering van de sturende processen vindt veelal plaats door de organisaties die de uitvoerende processen voor hun rekening nemen, binnen de door de eigenaar gestelde grenzen en uitgangspunten. Deze grenzen worden meestal jaarlijks vastgesteld. Op gezette tijden leggen de uitvoerende organisaties verantwoording af aan de eigenaar, die daarop kan bijsturen.

Bijlagen - 14

BISL BISL BISL BISL



Bijlage 3

Informatiebeveiliging: GIBN

De Gemeentelijke InformatieBeveiligingsNorm (GIBN) 2005 is een interne gemeentelijke norm voor alle organisatieonderdelen van de gemeente Amsterdam, waarin de te hanteren richtlijnen voor informatiebeveiliging zijn neergelegd. De Code voor Informatiebeveiliging is gebruikt als referentiepunt voor het vaststellen van deze normenset. Voor de huidige herziene versie is gebruik gemaakt van de NEN-ISO/IEC 17799:2002 Uitgangspunten norm: • Het Concern Amsterdam bestaat uit een groot aantal stadsdelen, diensten en bedrijven van zeer uiteenlopende aard en grootte, die hierna worden aangeduid met ‘(gemeentelijk) organisatieonderdeel’. De eisen die gesteld worden aan de informatiebeveiliging, moeten per organisatieonderdeel gespecificeerd worden. De te treffen maatregelen moeten in overeenstemming zijn met deze eisen. • De basis van standaardisatie voor informatiebeveiliging wordt gevormd door de gemeenschappelijke normenset (‘wat’). Deze normen worden vervolgens door de organisatieonderdelen vertaald in passende, specifieke maatregelen (‘hoe’). Ieder organisatieonderdeel is op deze wijze verplicht expliciet een gemotiveerde uitspraak te doen over het gewenste beveiligingsniveau en zelf maatregelen te selecteren op basis van classificatie en risicoanalyse. • In een standaard norm kan slechts sprake zijn van generieke eisen. Ieder organisatieonderdeel moet voor zijn afzonderlijke (informatie)systemen steeds zelf de afweging maken of het algemene niveau van beveiliging voldoet, of aanvullende maatregelen nodig zijn.

3.1

Algemene oriëntatie en positionering

Informatiebeveiliging maakt onlosmakelijk deel uit van de bedrijfsvoering van een organisatie en haar directe en indirecte werkomgeving. Het is een samenhangend geheel van maatregelen van procedurele, organisatorische, fysieke, technische en juridische aard. Het raakt aan: • algemeen beveiligingsbeleid (bijv. deuren, kluizen, toegangscontrole) • personeelsbeleid (bijvoorbeeld screening, opleiding en functietypering) • organisatiebeleid (bijvoorbeeld functiescheiding) • informatiebeleid (bijvoorbeeld standaardisatie en ‘proven technology’) • privacybeleid (bijvoorbeeld correct gebruik van persoonsgegevens) • juridisch beleid (bijvoorbeeld afbreukrisico’s bij privacyschendingen, clausulering in overeenkomsten met derden, Third Party Mededelingen) Het doel van informatiebeveiliging is het behoud van: • continuïteit / beschikbaarheid (voorkomen van uitval van systemen), • integriteit / betrouwbaarheid (gegevens zijn juist, actueel en volledig)

Bijlagen - 15



exclusiviteit / vertrouwelijkheid (onbevoegden kunnen geen kennis nemen van informatie die een organisatie onder zich heeft)

3.2

Verantwoordelijkheid en bevoegdheid

Informatiebeveiliging is een primaire verantwoordelijkheid van de lijnverantwoordelijke portefeuillehouder of stadsdeelvoorzitter c.q. de directeur of de stadsdeelsecretaris. Met betrekking tot de ambtelijke organisatie is voor het nemen van operationele maatregelen de directeur c.q. de stadsdeelsecretaris volledig bevoegd. Dit geldt ook in geval van ketenafhankelijkheid bij diensttakoverstijgende (informatie)systemen. De gemeenteraad / stadsdeelraad c.q. (stadsdeel)raadscommissies dragen een specifieke bevoegdheid voor controle en toetsing en een algemene verantwoordelijkheid voor informatiebeveiliging.

3.3

Wettelijke basis

De wettelijke basis van informatiebeveiliging valt af te leiden uit Europese richtlijnen en landelijke weten regelgeving: • Wet computercriminaliteit • Wet bescherming persoonsgegevens (WBP) • Archiefwet • Databankenwet • Wet Elektronisch Bestuurlijk Verkeer • Wet GBA (Gemeentelijke Basis Administratie) Deze regelingen bevatten in het algemeen een resultaatsverplichting tot een passend niveau van informatiebeveiliging. Tevens moet rekening worden gehouden met de Telecommunicatiewet, de Wet Openbaarheid van Bestuur en de Politiewet. De gemeentelijke regelgeving met betrekking tot informatiebeveiliging is neergelegd in de vastgestelde Gemeentelijke Informatiebeveiligingsnorm (2002), de Privacyverordening, de Archiefverordening (1997), Besluit Informatiebeheer (1997) en het Statuut voor informatievoorziening (2004).

3.4

Opbouw hoofdstukken

Onderstaand hoofdstukken en paragrafen met de informatiebeveiligingsnormen zoals opgenomen in de GIBN. In het handboek zijn per laag beveiligingsparagrafen opgenomen met verwijzingen naar paragrafen uit de GIBN.

Bijlagen - 16

Hoofdstuk

1

Hoofdstuk

2 2.1 2.2 2.3

Hoofdstuk

3 3.1 3.2

Inleiding Informatiebeveiligingsbeleid en - plan Beleidsdocument voor informatiebeveiliging Informatiebeveiligingsplan Aanvullende maatregelen Organisatie van de informatiebeveiliging Verantwoordelijkheidsniveaus binnen het concern Amsterdam



3.3 3.4 3.5 3.6

Hoofdstuk

4 4.1 4.2 4.3 4.4

Hoofdstuk

5 5.1 5.2 5.3 5.4 5.5 5.6

Hoofdstuk

6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9

Hoofdstuk

7 7.1 7.2 7.3 7.4 7.5 7.6

Hoofdstuk

8 8.1 8.2 8.3 8.4 8.5 8.6 8.7

Hoofdstuk

9 9.1 9.2 9.3

Hoofdstuk

10 10.1

Toewijzing verantwoordelijkheid voor informatiebeveiliging Rapporteren beveiligingsincidenten Verantwoordelijkheden diensttakoverstijgende (informatie)systemen (DOIS) Contracten met derden Contracten met interne afnemers Classificatie en beheer van informatie en bedrijfsmiddelen Inventarisatie van informatie en bedrijfsmiddelen Classificatie van informatie en bedrijfsmiddelen Beheer van informatie en bedrijfsmiddelen Verwerking van persoonsgegevens Personele beveiligingseisen Voorwaarden tewerkstelling vast personeel Voorwaarden tewerkstelling tijdelijk personeel Kwetsbare functies Bevoegdheden personeel Huisregels Opleiding en communicatie Fysieke beveiliging Toegangsbeheersing vestiging(en) Servicetaken Toegang computer- en datacomruimten Bewegwijzering computerruimten Verwijderen apparatuur en gegevensdragers Datakluizen Clear desk en clear screen beleid Beveiliging van (mobiele) apparatuur Telewerken Beheer van communicatie- en bedieningsprocessen Beheerprocedures en verantwoordelijkheden Acceptatie van nieuwe versies van systemen Bescherming programmatuur en gegevens Registratie en rapportage Netwerkbeheer Formele uitwisseling van informatie Logische toegangsbeveiliging Gedocumenteerd beleid voor toegangsbeveiliging Beheer van toegangsrechten Controle op toegangsrechten Toegangsbeveiliging voor netwerken Toegangsbeveiliging voor werkstations Toegangsbeveiliging in (informatie)systemen Bewaking van de toegangsbeveiliging Continuïteitsmanagement Proces van continuïteitsmanagement Relatie met nood- en ontruimingsplan Veiligstelling programmatuur Ontwikkeling en onderhoud van systemen Beveiligingseisen voor (informatie)systemen

Bijlagen - 17



10.2 Hoofdstuk

Bijlagen - 18

11 11.1 11.2 11.3

Test en acceptatie van (informatie)systemen Naleving Naleving van informatiebeveiligingsbeleid en -plan Naleving van wettelijke voorschriften Beoordeling van de naleving



Bijlage 4

4.1

Grondslagen

Algemene grondslagen

De algemene grondslagen geven invulling aan de informatiebeginselen en zijn richtinggevend voor de inrichting van de verschillende niveaus van de informatie architectuur. grondslag 0.1

De gemeente Amsterdam ontsluit publieke informatie, maakt zichtbaar wat zij doet, welke besluiten ze neemt, welke gegevens zij heeft en gebruikt en hoe zij werkt. Reden: Voor de burger moet de werkwijze van de gemeente duidelijk en eenduidig zijn. Consistente informatie hierover moet altijd simpel beschikbaar zijn. Zo kan de burger zien of de gemeentelijke overheid zich aan zijn afspraken houdt. Implicaties: • Veel processen moeten volgbaar worden van buiten af. Er zal veel meer informatie via het internet beschikbaar moeten komen, denk hierbij aan proces informatie waarbij belanghebbenden inzicht krijgen in het verloop van bijv. vergunning aanvragen. • Dit betekent dat veel processen digitaal zullen moeten worden gemaakt. • Het moet voor de burger inzichtelijker worden hoe bepaalde processen binnen de gemeente verlopen. Ook dit werkt standaardisatie en versimpeling in de hand van vergelijkbare processen.

grondslag 0.2

De gemeente Amsterdam voert haar taken uit volgens de wet en volgt bestaande en aangekondigde weten regelgeving. Reden: Vanzelfsprekend moet de gemeente voldoen aan de door de overheid bepaalde weten regelgeving. Hierbij moeten we echter niet uitsluiten dat verbeteringen in overheidsprocessen kunnen leiden tot verandering in weten regelgeving Implicaties: • We voldoen aan de wettelijke vereisten van basisregistraties. • We moeten inventariseren wat de impact is van welke wetten, richtlijnen, verordeningen onze informatievoorziening raken, zoals: Archiefwet (kennis bij Gemeentearchief), Wet Bescherming Persoonsgegevens, Telecommunicatiewet, Wet op de Basisregistraties, WMO, Europese aanbestedingsrecht, Wet op de computercriminaliteit, Grondrechten, Databankenwet, Auteurswet, Rijksoctrooiwet, Wet Openbaarheid Bestuur, Mediawet Telecommunicatiewet, E-commerce Richtlijn, Richtlijn Elektronische handtekeningen, Kieswet, Arbowet, ARAR, Verordening op de stadsdelen, GIBN. • We moeten het zo organiseren dat nieuwe ontwikkelingen op juridische gebieden bekend raken bij de beheerder(s) van de architectuur (kennismanagement). • De Europese aanbestedingsregels leggen beperkingen op aan het kunnen hanteren van leveranciersstandaarden

Bijlagen - 19


grondslag 0.3


De gemeente Amsterdam confirmeert zich aan de landelijke (overheids) standaarden. Reden: Amsterdam staat niet op zichzelf en zal zich aanpassen aan alle landelijke standaarden. Aansluiting op landelijke projecten en voorzieningen moet hierdoor mogelijk zijn. Implicaties: • Dit betekent wel dat Amsterdam invloed zal willen hebben op het vaststellen van nieuwe standaarden, zij zal zich actief moet opstellen in gremia en projecten waar deze standaarden tot stand komen.

•

4.2 grondslag 1.1

Ook zal zij goed in de gaten moeten houden wat de implicaties zijn van nieuwe of gewijzigde standaarden op de bestaande situatie.

Grondslagen organisatiearchitectuur

De gemeente Amsterdam organiseert zichzelf in los gekoppelde onderdelen die onderling en met hun omgeving nauw samenwerken om resultaten te boeken. Reden: Het losknippen van de organisatie en de informatievoorzieningen om deze vervolgens in een netwerk met elkaar te verbinden biedt voordelen op het punt van flexibiliteit, schaalbaarheid, transparantie en een goede beheerbaarheid. In een steeds complexer wordende omgeving is dit van groot belang. Implicaties: • Er zal goed moeten worden gedefinieerd welke onderdelen hiervoor in eerste instantie voor in aanmerking komen. • Dit kan gelden voor zowel organisatie, processen, informatie, applicaties en infrastructuur. • Dit betekent het goed en generiek inrichten van de basisregistraties en de ontsluiting hiervan. • De aandacht in de architectuur zal vooral op de relaties tussen onderdelen liggen. Er zullen voorzieningen moeten worden getroffen die de samenwerking op verschillende niveaus ondersteunen of regelen, denk aan SSC’s. • Het gebruiken van algemeen geldende afspraken en open standaarden maakt hier deel van uit en zal moeten worden gedefinieerd.

grondslag 1.2

De gemeente Amsterdam opereert dichtbij burgers en bedrijven en maakt wederzijds contact laagdrempelig. Reden: De gemeente positioneert zich dichtbij de burger, bedrijf en andere belanghebbenden. Daardoor zijn er heldere wederzijdse verwachtingen. Implicaties: • Stadsdelen spelen een sleutelrol in front office, zie ook het rapport “Beter presteren” van Hiemstra en de Vries. • Klant normen of prestatie indicatoren nemen een steeds belangrijker plaats in. Het meten hiervan geeft inzicht in de effectiviteit van het contact.

grondslag 1.3

De gemeente Amsterdam opereert consistent, als één concern, als integraal onderdeel van de gehele overheid. Reden: Het mag voor de burger niet uitmaken hoe de gemeente zich georganiseerd heeft.

Bijlagen - 20



.Verder vormt de gemeente de ingang voor alle overheidsdienstverlening op haar grondgebied. Implicaties: • Producten die via verschillende kanalen worden aangevraagd, of vragen die gesteld worden moeten altijd op dezelfde wijze en met dezelfde randvoorwaarden worden afgehandeld. • Dit vraagt veel van de standaardisatie van processen (eenduidige inrichting), ook hier zal digitalisering vaak een belangrijke voorwaarde zijn om dit te bereiken. • Uitwisseling van gegevens met binnen- & buitengemeentelijke organisaties. • De wereld stopt niet en draait niet om Amsterdam. De gemeente organiseert zich als onderdeel van de gehele overheid. Burgers en bedrijven kunnen via de gemeente bij alle overheidsinformatie terecht. grondslag 1.4

Communicatiekanalen kunnen door elkaar heen worden gebruikt. Reden: Communicatie tussen burgers en bedrijven kan via meerdere kanalen verlopen. De kanalen worden zodanig ingericht en ondersteund dat het door elkaar heen gebruiken van de kanalen mogelijk is, zonder dat dit de voortgang van de processen hindert. Implicaties: • Dit principe impliceert dat kanalen op bepaalde punten met elkaar zijn verbonden, zodat meldingen die via het ene kanaal zijn ontvangen, ook bij het andere kanaal ‘bekend’ zijn. Omgekeerd dient het actualiseren van informatie over het ene kanaal parallel te verlopen met het actualiseren van de overige kanalen. • De digitale dienstverlening zal worden uitgebouwd. • Het is van groot belang dat back office systemen en front office systemen goed op elkaar aansluiten. • Alle organisaties die publiekscontacten voeren, beschikken concernbreed over dezelfde informatie, hebben dus dezelfde informatie bronnen. • De niet digitale kanalen zullen ook de nodige aandacht nodig blijven hebben, met name wat betreft de verbindingen met de overige kanalen. • De verschillen in inrichting tussen de kanalen van balie, post enerzijds en telefoon en internet anderzijds,dienen gelijk getrokken te worden, • De gemeente heeft het recht de klant te leiden naar het meest efficiënte kanaal, zolang daarmee de kwaliteit van de dienstverlening gewaarborgd is.

4.3 grondslag 2.1

Grondslagen procesarchitectuur

Processen worden ingericht als onderdeel van complete ketens. Deze zijn ontworpen vanuit de behoefte van burgers, bedrijven en overige belanghebbenden in de samenleving. Reden: Om een goede samenwerking en transparantie te verkrijgen is het van belang dat de processen worden gezien, ingericht en bestuurd als onderdeel van een keten. Hierbij worden de afhankelijkheden die er tussen processen bestaan, op zo’n wijze bestuurd dat de keten goed loopt. Implicaties: • Alle ketenpartners committeren zich aan de keten. • Het beheer van de keten is belegd bij een ketenregisseur • De financiering en de sturing van de keten zijn belegd.

grondslag 2.2

Vergelijkbare processen worden in Amsterdam op één en dezelfde wijze

Bijlagen - 21



beschreven en ingericht. Reden: Generieke processen kunnen op dezelfde manieren beschreven, ingericht en bestuurd worden. Dit verlaagt de complexiteit en verhoogd de inzichtelijkheid. Implicaties: • Dienstverleningsprocessen kunnen vaak op dezelfde wijze worden ingericht. (aanvragen / handelen / leveren), Dit geldt wellicht ook voor de andere hoofdprocessen • Er zullen gestandaardiseerde koppelvlakken worden gecreëerd, hierdoor neemt de transparantie van de overdracht van informatie toe. • Rollen bij ketenprocessen worden inrichtingsonafhankelijk beschreven, dus niet in termen van de partijen die er in de huidige inrichting bij betrokken zijn. • Er moet overeenstemming worden bereikt over generieke inrichtingsonafhankelijke procesmodellen voor de te onderscheiden processen. Hierbij moet zoveel mogelijk worden uitgegaan van reeds beschikbare uitwerkingen bij voorkeur op landelijk en anders op Amsterdams niveau.

4.4 grondslag 3.1

Grondslagen informatiearchitectuur

De basisregistraties en kernadministraties vormen een verplichte bron van de Amsterdamse gegevenshuishouding Reden: Bij het eenmalig vastleggen is het verplicht om de bestaande gemeentelijke basisregistraties en kernadministraties als bron te gebruiken. Implicaties: • Er goede afspraken moeten worden gemaakt wat waarvoor gebruikt gaat worden en door wie. Welke basisregistraties en kernadministraties we onderscheiden? • Welke kernadministraties er zijn moet worden vastgesteld. • De metabeschrijvingen (o.a. betekenissen en vastlegging) van de gegevens die het betreft worden als uitgangspunt beschouwd voor het gebruik van deze basisgegevens in afgeleide gegevens verzamelingen. • De kwaliteit van de gegevens wordt hierdoor nog belangrijker en zal hierdoor verbeteren.

grondslag 3.2

Gegevens worden éénmalig opgeslagen en meervoudig gebruikt. Reden: Gegevens (records, tekst, foto’s, enz.) zijn van gemeenschappelijk nut en worden dan ook (voorzover mogelijk en toegestaan) gedeeld door uiteenlopende interne en externe functies. Voor de kwaliteit en inzichtelijkheid is het van groot belang dat gegevens op maar één plek kunnen worden gewijzigd (vastgesteld), zij kunnen wel meerdere plekken worden gebruikt. Implicaties • Goede afspraken nodig over eigenaarschap en betekenis van de gegevens. • Het inrichten van de basisregistraties en kernadministraties op zo’n manier dat gegevens maar op één plek kunnen worden ingevoerd en gemuteerd. • Afwijkingen worden aan de bron teruggemeld en op één plek onderhouden. • Het laten voldoen van de gegevens uit de basisregistraties aan een van te voren gespecificeerd kwaliteitsniveau. • Registreren bij de basisregistraties van afwijkingen tussen de administratieve werkelijkheid en de maatschappelijke werkelijkheid met de aard van de afwijking en zolang de afwijking in onderzoek is.

Bijlagen - 22



•

Door middel van een door betrokkenen te onderhouden set van specifieke afspraken worden de (gemeenschappelijke) gegevens systematisch beschreven en toegankelijk gemaakt. • Er wordt maximaal aangesloten op de (object)-definities van de gemeentelijke standaard. • Bij de gegevens- en informatie-uitwisseling tussen de betrokken organisaties zullen bepaalde belangrijke gebeurtenissen die wijzigingen in gegevens tot gevolg hebben actief worden gepubliceerd (bijvoorbeeld een overlijden registreren in de basisregistratie persoonsgegevens. Dit kan grote implicaties hebben in processen die deze gegevens gebruiken in andere organisatie onderdelen, denk aan een lopende aanvraag). Consequenties voor de deelnemende diensten bij basisregistraties en kernadministraties: • Gezamenlijke verantwoordelijkheid: dienstoverschrijdend. Andere vormen van samenwerken, vertrouwen op elkaar maar ook werken met convenanten. • Intake – vastleggen – distribueren/koppelingen: wie is eigenaar waarvan. Voor de ontvanger moet het transparant zijn, er moeten wel heldere afspraken zijn • Informatiemodel: afnemer moet alle gegevens ontvangen zonder te weten wat van wie afkomt: transparantie • Één frontoffice voor vragen over basisregistraties. Consequenties voor ontvangende diensten: • Bij het in kaart brengen van organisatie specifieke werkprocessen in kaart brengen; waar gebruik je de basisregistratie gegevens? • Dit kan de werkprocessen beïnvloeden (herinrichting noodzakelijk?). • Informatiehuishouding wordt dan expliciet ( informatiemodel noodzakelijk). • De ondersteunende ICT systemen moeten worden aangepast. • Mogelijk organisatorische consequenties. grondslag 3.3

Gegevens worden ontsloten met maximale transparantie binnen de wettelijke kaders volgens de privacy principes. Reden: Gegevens worden ontsloten voor ambtenaren, burgers en bedrijven waarvoor ze relevant zijn en die ze mogen zien en gebruiken. De gemeente Amsterdam vraagt burgers en bedrijven niet opnieuw om gegevens die reeds bekend zijn bij de overheid Implicaties: • Goede afspraken over wie afnemer is. • Burgers en ondernemers krijgen via een beveiligde, persoonlijke internettoegang tot de gegevens waarvoor de gemeente Amsterdam verantwoordelijk is en die op hen betrekking hebben.

• •

grondslag 3.4

Informatiesystemen die voor specifieke bedrijfsonderdelen ontwikkeld zijn, worden opengezet voor informatiedeling binnen de gemeente Amsterdam. De privacy principes worden bij het gebruiken van informatie in acht genomen. Zie Bijlage 11.

De gemeente Amsterdam garandeert vertrouwelijkheid van gegevens, betrouwbaar (digitaal) contact en zorgvuldige (elektronische) archivering. Reden: Amsterdamse burgers kunnen ervan op aan dat de overheid haar digitale zaken op orde heeft. Gegevens worden ontsloten voor ambtenaren, burgers en bedrijven waarvoor ze relevant zijn en die ze mogen zien en gebruiken. Implicaties:

Bijlagen - 23



• • •

•

• • •

4.5 grondslag 4.1

Een goede en beheerbare generieke autorisatie structuur en autorisatie mechanismen (DigiD, Directory Services). Goede afspraken over voor wie wat bedoeld is (toegespitst op doelgebruik). Bij het openstellen van informatiesystemen geldt een stelsel van afspraken en voorzieningen die voldoen aan weten regelgeving en normen op het gebied van onder andere bescherming persoonsgegevens, informatiebeveiliging. Voor authenticatie en autorisatie van natuurlijke en niet-natuurlijke personen geldt een stelsel van gemeenschappelijke voorzieningen waarop alle opengestelde informatiesystemen zijn aangesloten (DigiD, Directory Services). Informatie wordt duurzaam digitaal opgeslagen en kan gemakkelijk worden teruggevonden. Er wordt gebruik gemaakt van duurzame digitale standaarden. Bij wijzigingen in deze standaarden (de techniek wijzigt snel op dit moment), dient de gemeente zorg te dragen voor een goede en tijdige conversie van digitale bestanden.

Grondslagen applicatiearchitectuur

Applicaties zijn modulair opgebouwd zodat functies kunnen worden hergebruikt. Reden: Door ook hier generiek te werken neemt de overzichtelijkheid en beheerbaarheid toe in een steeds complexere omgeving. Implicaties: • Indien bij ketenprocessen zoveel mogelijk functionaliteit binnen één lokatie en dus binnen de ondersteunende applicatie(-s) wordt gelegd en zo min mogelijk uitwisseling van (soorten) informatie tussen de applicaties wordt gerealiseerd, neemt de beheerbaarheid en flexibiliteit van deze applicaties en de beheerbaarheid van het geheel van applicaties toe. • Binnen één applicatie(module) wordt zoveel mogelijk samenhangende functionaliteit geconcentreerd waarbij naar zo weinig mogelijk informatie uitwisseling met andere applicaties wordt gestreefd. Dit is een belangrijk uitgangspunt bij het bepalen van wat een module bevat. • Maximale functionaliteit en zo min mogelijk (complexe) uitwisseling volgt ook uit het ontwerp van proces eenheden (notabene: er is een samenhang met het ontwerp van (keten)processen). • Bij het ontwikkelen van deze applicaties dient het hergebruik van componenten voorop te staan.

•

• • grondslag 4.2

De overdracht tussen de koppelvlakken van applicaties dient te gebeuren volgens gemeentelijke standaarden over de overdracht (StUFbg) en volgens open standaarden. Juridische consequenties zoals hergebruik / intellectueel eigendom moet van te voren duidelijk zijn. Kennisdeling is bij hergebruik erg belangrijk.

Applicaties zijn gebaseerd op open standaarden en platform onafhankelijk. Reden: Door het steeds veranderen van de techniek en de eisen die deze veranderingen met zich mee brengen, is het van groot belang dat de applicaties onafhankelijk zijn van specifieke technologiekeuzes en dat ze volgens open standaarden informatie kunnen uitwisselen.

Bijlagen - 24



Implicaties: • Het is veel belangrijker om de standaarden functioneel te bepalen in plaats van technisch. De techniek is onderhevig aan veranderingen. • Een applicatie moet kunnen werken op verschillende technologische platforms. • Een applicatie gebaseerd op één techniek moet informatie kunnen uitwisselen met een applicatie gebaseerd op een andere techniek. • Door uitwisseling van gegevens met andere dan gemeentelijke instanties verdient het aanbeveling om zoveel mogelijk aan te sluiten bij landelijke (overheid-) standaarden. • Er wordt gestreefd naar leveranciersonafhankelijkheid (open source is hier een optie). grondslag 4.3

De gemeente Amsterdam maakt maximaal gebruik van standaard componenten. Reden: Bij de keuze voor componenten wordt eerst gekeken naar zich bewezen hebbende producten Implicaties: • Kopen gaat voor ontwikkelen. • De standaard componenten kunnen, naar verwachting, op een meer prijseffectieve wijze worden ingezet. (Open) standaarden voorzien in consistentie en helpen bestaande ICT-investeringen te beschermen, kosten te reduceren en promoten leveranciersonafhankelijkheid. • Hergebruik van software heeft de voorkeur boven kopen, heeft de voorkeur boven maken. • Ook als gekozen wordt voor open source dient wel gestreefd te worden naar het bewijs van bruikbaarheid in overheidsland of elders.

4.6 grondslag 5.1

Grondslagen infrastructuurarchitectuur

De infrastructuur is schaalbaar, betrouwbaar en gebaseerd op open standaarden. Reden: Standaarden voorzien in consistentie en helpen bestaande ICT-investeringen te beschermen, kosten te reduceren en promoten leveranciersonafhankelijkheid. De schaalbaarheid en betrouwbaarheid zijn van essentieel belang voor de bedrijfsvoering die hier afhankelijk van is. Implicaties:

•

•

•

Naast leveranciers onafhankelijkheid is het wel van belang om te streven naar het minimaliseren van de technische diversiteit. Diversiteit in middleware, database management systemen, (netwerk) operating systemen, transactiebehandeling enz. dient geminimaliseerd en beheerst te worden. De kosten voor het in de lucht houden, actualiseren en verbinden van alternatieve technologieën zijn niet-triviaal. Limiteren van het aantal te ondersteunen componenten zal onderhoud vereenvoudigen en kosten reduceren. Er wordt gestreefd om het beheer zoveel mogelijk samen te doen.

Bijlagen - 25



Bijlage 5

Modellering

Deze bijlage dient als legenda bij de modellen in het Handboek Architectuur en tevens als richtlijn voor het verder modelleren in volgende versies van het Handboek. In het Handboek Architectuur wordt veel gebruik gemaakt van visualisaties. Er worden drie categorieën onderscheiden, van globaal op een hoog aggregatieniveau tot exact en gedetailleerd: 1. creatieve schetsen in freeformat tekeningen 2. globaal architectuurontwerp in powerpoint-modellen 3. domeinspecifiek architectuurontwerp in exacte modellen Per categorie worden kort belicht: • doel en functie van de visualisaties, • de eventuele modelleertaal die ze gebruiken, • de tool waarmee ze gemaakt worden en • voorbeelden uit het Handboek.

5.1

Creatieve schetsen in freeformat tekeningen

Doel en functie: • Doel: de lezer een snel overzicht en begrip geven van het ‘waarom’: helpen bij het bepalen van waarover het in het Handboek gaat. • De functie: is dan ook contextueel: het geven van een toegankelijke, symbolische weergave een deel van de werkelijkheid temidden van zijn omgeving, zonder de pretentie volledig of juiste te zijn. Essentiële zaken worden naar voren gebracht en elementen die op een bepaalde plek of moment minder belangrijk zijn, blijven onbelicht. Taal: • Gebruikte symbolen zijn concreet, beeldend en maken geen onderdeel uit van een bepaalde modelleertaal. Tooling: • Vrij keuze van tooling (bijvoorbeeld MS Paint met bitmaps als bestandsformaat). Voorbeelden: • Creatieve schetsen zijn in het Handboek te vinden bij alle algemene en inleidende stukken: het Architecture-mobile op de voorplaat, het 5-lagen Raamwerk en de vele tekeningen in de managementsamenvatting.

5.2

Globaal architectuurontwerp in powerpoint-modellen

Doel en functie: • Doel: duidelijkheid verschaffen over het ‘wat’ van de architectuur. • Functie: globaal architectuurontwerp heeft een conceptuele aard. Het

Bijlagen - 26



brengt op hoofdlijnen in kaart welke delen er worden onderscheiden in een aandachts-/probleemgebied en hoe deze zich ten opzichte van elkaar verhouden. Daarnaast kan het ook een technische aard hebben, in de zin van het weergeven welke oplossingen / toepassingen gebruikt kunnen worden in het aandachtsgebied. Taal: • De gebruikte symbolen zijn abstract, maar toegankelijk en begrijpelijk. • De modellen gebruiken niet een bepaalde architectuurtaal. In de modellen in Handboek versie 1.0 zijn wel reeds concepten van ArchiMate geïntroduceerd (zie de conceptentabel onderaan deze bijlage) Archimate zal na Handboek versie 1.0 wellicht breder worden gehanteerd als logische modelleertaal voor exacte modellen (niveau 3). Zodoende is de symboliek reeds op de laag van globaal architectuurontwerp geïntroduceerd (zie de ArchiMate symbolen onderaan deze bijlage. Tooling: • De modellen van het globaal architectuurontwerp worden in Powerpoint vervaardigd. Voorbeelden: • Voorbeelden van globaal ontwerp in powerpointmodellen zijn in vele hoofdstukken terug te vinden (ondermeer model Applicatielandschap en Architectuurproces- en organisatie).

5.3

Exact architectuurontwerp

Doel en functie: • Doel: eenduidige vastlegging van architectuurelementen op een gestandaardiseerde wijze. Op basis hiervan kan ontwikkeling, bouw en beheer van de organisatieinrichting, processen, gegevenshuishouding en systemen/infrastructuur plaatsvinden. • Functie: exacte (juiste en volledige) weergave van de structuur en relaties van elementen binnen architectuurdomeinen/-lagen. Hierin geldt een logische ordening. Taal: • De gebruikte symbolen zijn abstract en gedetailleerd. Voor ieder architectuurdomein/-laag gelden specifieke standaardtalen en methodieken zoals bijvoorbeeld ERD (entity relationship diagrams) voor de gegevenslaag. In latere versies van het Handboek wordt wellicht verder gewerkt aan het logisch integreren van de domeinspecifieke modellen in ArchiMate. Een metamodel is reeds gemaakt dat aansluit op de gebruikte architectuurelementen en lagen in het Handboek (zie metamodel onderaan deze bijlage). Tooling: • Bij iedere architectuurtaal horen tools waarmee in deze taal gemodelleerd kan worden. • Zo wordt voor procesmodellering bij de gemeente Amsterdam Mavim (UML) gebruikt.

Bijlagen - 27



•

Mocht in latere versies van het Handboek de taal ArchiMate verder worden toegepast, dan zal ook hiervoor een tool geselecteerd moeten worden.

Voorbeelden: • Modellen in de bijlage, zoals het Object- en entiteitenmodel in Bijlage 8. En onderstaand metamodel met ArchiMate is gemodelleerd. biedt Kanaal

Dienst realiseert Gebeur tenis

heeft

gebruikt zorgt voor start van Proces

bewerkt

voert uit

Organisatieeenheid

Wisselt uit ondersteunt

Informatie object bewerkt bevat

Bericht wisselt uit

Applicatie service

biedt

realiseert gebruikt

Applicatie functie

heeft Applicatie

draait op

verbonden door Apparaat

Bron: Adviesgroep Architectuur Metamodel Amsterdamse architectuur (voor verklaring der tekens: zie de Archimate concepten hieronder. Voor verklaring der termen: zie bijlage Terminologie)

Bijlagen - 28

Netwerk



Meaning

Process/ function

Specialisation Actor Composition Aggregation Assignment

Value

Process

Role Realisation Triggering

Product

Used by Function

Component Flow Access

Object

Association Activity

Collaboration

Service

Interface

Junction

provided Representation

Group

required symmetric

Artifact

Event

Interaction

Node

Device

System software

Network

Communication path

System software

Bron: Telin Archimate concepten

Bijlagen - 29



Bijlage 6

Organisatiearchitectuur: Organisatie van de informatievoorziening

In de B&W-vergadering van 22 augustus 2006 is de notitie ‘Organisatie van de InformatieVoorziening:bestuurlijke en ambtelijke lijnen / opdrachtgever & opdrachtnemer’ vastgesteld. In deze bijlage is integraal de tekst overgenomen van de notitie

1. Informatievoorziening en ICT aanleiding

De ontwikkelingen op het gebied van ICT, of beter de Informatievoorziening, zijn de afgelopen jaren groot geweest. De gemeentebrede samenwerking op het ICT-domein vraagt om een goede besluitvormingsstructuur, zowel bestuurlijk als ambtelijk. Deze notitie doet daartoe een voorstel en schetst maatregelen om de gewenste situatie te bewerkstelligen.

concern-denken

De ombuigingsoperatie heeft een aantal initiatieven opgeleverd die de samenwerking en de samenhang in het concern Amsterdam sterk hebben bevorderd. Zo wordt met het programma BasisRegistraties & ICTinfrastructuur (BRI) het fundament van de gemeentelijke ICT gelegd. En de vorming van Shared Service Centers zorgt voor organisatie en standaardisering van de basisvoorzieningen op het gebied van ICT en HRM. Deze ontwikkelingen dragen uiteindelijk bij aan het verbeteren van de primaire processen van de gemeente: dienstverlenen, handhaven, ontwikkelen & ordenen, en beheren.

de stuurgroep IV

Het concern-denken heeft tevens de behoefte gecreëerd aan een ambtelijk platform voor alle diensttak-overstijgende ICT-aangelegenheden alsmede een voorziening om de bestuurlijke betrokkenheid te formaliseren. Inmiddels is er een stuurgroep InformatieVoorziening (SG IV) die meelift op de orde en de logistiek van het programma BRI en iets dergelijks geldt ook voor het SSC ICT.

de commissie IV

Onlangs heeft de coördinerend wethouder ICT het groene licht gegeven voor de bestuurlijke pendant van de SG IV: de commissie InformatieVoorziening (Cie IV). Daarmee is het tijd om de gang van zaken, de samenstelling van de gremia, de agendering en de ondersteuning nog eens te herijken en de noodzakelijke voorzieningen te treffen. Het onderhavige document geeft daarvoor een handreiking.

model OG-ON

Getracht wordt aan de hand van een eenvoudig model de rollen en het opdrachtgeverschap te definiëren en de bestuurlijk-ambtelijke lijn. De programma’s BRI en SSC ICT worden gebruikt om de toepassing en de werking te illustreren. Dan volgt een invulling voor de organisatie van de

Bijlagen - 30



InformatieVoorziening.

2. Rollen: opdrachtgever en opdrachtnemer bestuur is OG

Voor alle programma´s en projecten moet expliciet kunnen worden benoemd hoe de bestuurlijke aanhaking is geregeld; het bestuur in enige hoedanigheid (college van B&W, individuele wethouder, bestuurlijk team, bestuurscommissie) zou in alle gevallen als opdrachtgever moeten fungeren van de grote(re) organisatieontwikkelingen.

ambtelijk ON/OG

Op ambtelijk niveau is er dan een opdrachtnemer nodig die de bestuurlijke wens honoreert. In veel gevallen zal het eerst verantwoordelijke ambtelijke niveau (meestal een stuurgroep, een directeur of een coördinerend organisatieonderdeel) alleen de aansturing van deze realisatie ter hand nemen en op zijn beurt als (gedelegeerd) opdrachtgever gaan fungeren van een partij die daadwerkelijk aan de slag gaat.

ON-uitvoerder

De uiteindelijke opdrachtnemer is vaak een programma manager, projectleider of afdelingshoofd die een substantieel aandeel levert aan de realisatie.

checklist

Naast de eenduidige regeling met betrekking tot dit opdrachtgeveropdrachtnemerschap moet duidelijkheid bestaan over de volgende onderwerpen: • de samenstelling van de bestuurlijke en ambtelijke gremia, met aandacht voor de betrokkenheid van de stadsdelen; • het karakter van de onderwerpen die in de betreffende gremia aan de orde komen, alsmede of die opiniërend, adviserend dan wel besluitvormend zijn; • het budget en de budgetverantwoordelijkheid; • de orde, het huishoudelijk reglement, de agenda en de wenselijkheid van een agendacommissie; • het secretariaat of het ondersteunende bureau en de wenselijkheid van een klankbordgroep of toetsclub; • de rapportagelijnen, frequentie, openbaarheid; • de communicatie, de verspreiding van informatie en documenten.

3. Het programma BRI Het model en de checklist worden nu ter illustratie toegepast op het programma BasisRegistraties & ICT-infrastructuur (BRI). Dit samenwerkingsverband van 9 diensten is, in het kader van de ombuigingsoperatie, op ambtelijk niveau tot stand gekomen maar is meteen voorzien van een bestuurlijke aanhaking: in een business model en plan van aanpak is met het College van B&W overeengekomen welke opbrengsten geleverd worden voor de gevraagde investeringen. B&W → Cie IV

De bestuurlijke opdrachtgever is dus B&W maar vanaf de daadwerkelijke start van de commissie Informatievoorziening zal het programma BRI aan of via dat gremium rapporteren. In termen van het model: de bestuurlijke opdrachtgever

Bijlagen - 31



van BRI is B&W, gedelegeerd aan de Cie IV. SG en PM

De ambtelijke opdrachtnemer is de stuurgroep BRI die de aanjaagfunctie heeft opgedragen aan de programma manager BRI. In het programmaplan BRI is de rol van de programmamanager uitputtend beschreven. Naast en onder deze partijen is een aantal voorzieningen getroffen om het een en ander te faciliteren. Zo heeft de PM een bescheiden secretariaat voor de verslaglegging en de distributie van stukken. Verder laat het bestuur zich adviseren door een onafhankelijke deskundige van een extern bureau die de opdracht heeft de voortgang kritisch te volgen.

de samenstelling

De samenstelling van de Cie IV komt later aan de orde. De stuurgroep BRI bestaat uit een kern van direct betrokken directeuren (DPG, DAB, DBGA, FBA, DWI, OGA, DMO, WMO, BDA, (DW) en CO), namelijk de diensttakdirecteuren die leverancier dan wel afnemer zijn van basisregistraties en de concerndirectie die verantwoordelijk is voor het gemeentebrede ICT-beleid. Daarnaast neemt een aantal functionarissen deel die een specifieke meerwaarde inbrengen: • de programma manager, qualitate qua; • de betrokkenheid van de stadsdelen wordt geborgd door de deelname van een stadsdeelsecretaris; • de directeur/kwartiermaker van het SSC ICT is de linking pin met de staande organisatie SSC ICT.

budget

In het business model van het bedrijfsplan BRI wordt een overzicht gegeven van benodigde investeringen en beoogde opbrengsten in een meerjarenperspectief. De budgetten zijn gealloceerd en worden door de stuurgroep aan partijen toegewezen op basis van (deel)plannen van aanpak. Een van de stuurgroep-directeuren treedt op als penningmeester.

de orde

Het samenstel van stuurgroep en werkgroepen functioneert inmiddels anderhalf jaar tot tevredenheid van betrokkenen. Er is een vergaderorde, een termijnagenda en -planning, een groot aantal goedgekeurde deelplannen, er zijn spelregels over aanlevertermijnen en rapportageverplichtingen. De orde en procedurele gang van zaken is goeddeels uitgeschreven in het programmaplan BRI.

agendaberaad

Vanaf het begin hebben drie leden van de stuurgroep, waaronder de voorzitter

Bijlagen - 32



en de penningmeester, tezamen met de programma manager een agendacommissie gevormd die de voorbereiding van de vergaderingen verzorgt en eventuele knelpunten in de voortgang van de activiteiten bespreekt. Dit agendaberaad wordt zo serieus genomen dat het de kenmerken van een dagelijks bestuur vertoont. toetsorgaan

De programmamanager coördineert de bijdrage van de verschillende werkgroepen die een deel van de productie leveren dan wel een toetsende rol hebben. Dit laatste is vooral belegd bij de werkgroep BRI, een toetsclub met een zeer brede samenstelling van ten minste alle deelnemende diensten. In feite gaan alle stukken voor de stuurgroep BRI vergezeld van een advies van deze werkgroep. De programma manager is niet verantwoordelijk voor de realisatie van de deelplannen; die vallen rechtstreeks onder de diensttakdirecteur. De leden van de werkgroep BRI zorgen ervoor dat die verantwoordelijkheid kan worden waargemaakt.

rapportage

De bestuurlijke opdrachtgever wordt met kwartaalrapportages op de hoogte gehouden van de voortgang, de stand van zaken en de eventuele knelpunten. De door het bestuur aangestelde externe adviseur rapporteert vooral op basis van risico’s. In principe zijn alle stukken van de stuurgroep openbaar.

communicatie

Veel aandacht wordt besteed aan de informatieverzorging en communicatie. Elke belangstellende wordt op de mailing list geplaatst en is daarmee verzekerd van de digitale toezending van agenda en stukken van de stuurgroep. In speciale bijeenkomsten, uitgebreide stuurgroepen en directeurenconferenties wordt voorlichting gegeven over het programma BRI, de beoogde resultaten en de mogelijkheden voor eventuele deelname.

4. Het Shared Service Center ICT I. In deze paragraaf wordt het model toegepast op het Shared Service Center ICT. Daarbij moet onderscheid gemaakt worden tussen de lijnorganisatie die op 1 januari 2006 tot stand is gekomen en die uitvoering geeft aan het besluit over de eerste tranche (I.), en het ontwikkelingstraject van de volgende tranches (II.). het SSC ICT

In de staande organisatie SSC ICT is een kwartiermaker/directeur belast met de transitie en de transformatie van mensen en middelen die in de eerste tranche uit de deelnemende organisatieonderdelen zijn overgekomen.

B&W → AB

Ten behoeve van de besturing van dit samen-werkingsverband van gemeentelijke diensttakken is artikel 83 van de Gemeentewet gebruikt voor de vorming van een Bestuurscommissie. Deze commissie bestaat uit een Algemeen Bestuur en een Dagelijks Bestuur. De bestuurlijke opdrachtgever is derhalve B&W die dit delegeert aan een AB.

Bijlagen - 33



DB en RvD

Het Dagelijks Bestuur van het SSC ICT is de ambtelijke opdrachtnemer. Dit DB wordt gerecruteerd uit de directeuren van de deelnemende diensttakken, respectievelijk de stadsdeelsecretarissen van de deelnemende stadsdelen. Het voltallige gezelschap vormt de Raad van Deelnemers.

directeur

Het DB op zijn beurt draagt de dagelijkse leiding en de regeling van alle door het SSC ICT uit te voeren werkzaamheden op aan een directeur.

de samenstelling

Het Algemeen Bestuur bestaat uit: • een lid van het College van B&W; • een lid van het Dagelijks Bestuur van elk stadsdeel dat deelneemt aan het SSC ICT. De Raad van Deelnemers bestaat uit: • de directeuren van de diensten respectievelijk de stadsdeelsecretarissen van de stadsdelen die deelnemen aan het SSC ICT. De door het Algemeen Bestuur op voordracht van de Raad van Deelnemers benoemde voorzitter van het Dagelijks Bestuur is tevens voorzitter van de Raad van Deelnemers. Aan de vergaderingen van het DB nemen ook deel: • de directeur/kwartiermaker van het SSC ICT, qualitate qua; • de topadviseur ICT namens de directie van CO, verantwoordelijk voor het concern ICT-beleid; • (op uitnodiging) de programmamanager SSC ICT.

budget

Het SSC ICT is een gemeentelijke diensttak met een begroting en een jaarplan. De verleende diensten worden in rekening gebracht bij de deelnemers.

de orde

Een en ander is uitputtend geregeld in het Instellingsbesluit Bestuurscommissie SSC ICT van 13 december 2005.

rapportage

De bestuurlijke opdrachtgever wordt met kwartaalrapportages op de hoogte gehouden van de voortgang, de stand van zaken en de eventuele knelpunten.

tranche 2 en 3

II. Het programma management voor de verdere ontwikkeling van het Shared Service Center (o.a. functioneel beheer, ontwikkeling, project-management) is een zaak die het hele concern aangaat en is daarom opgehangen aan de lijn van Cie IV en SG IV. De uiteindelijke opdrachtnemer is de programma manager SSC ICT die tranchegewijs de uitbouw en fasering begeleidt.

de samenstelling

De samenstelling van de Cie IV en de SG IV komen later aan de orde.De programma manager heeft enige (externe) ondersteuning georganiseerd en voert een strakke regie op de voortgang van de ontwikkeling. Via deelplannen wordt de stuurgroep IV om besluitvorming gevraagd.

budget

Het programma SSC ICT heeft een bescheiden ontwikkelbudget dat wordt beheerd door de programma manager. Het budget is op dit moment

Bijlagen - 34



ondergebracht bij de staande organisatie SSC ICT. rapportage

De rapportagelijn verloopt via de aangegeven lijnen van programma manager via SG IV naar Cie IV. Ook hier moeten kwartaalrapportages inzicht geven in de voortgang, de stand van zaken en de eventuele knelpunten.

5. De commissie en de stuurgroep InformatieVoorziening de aanloop

doel en taken

B&W → Cie IV

Op 27 september 2005 heeft B&W besloten tot het activeren van een bestuurlijk-ambtelijke commissie met zowel vertegenwoordigers van de centrale stad als van de stadsdelen om te komen tot afspraken voor concernbrede samenwerking in de informatievoorziening. Belangrijke ontwikkelingen als Antwoord, Basisregistraties & ICTinfrastructuur, elektronische loketten en de vorming van Shared Service Centers maken een goede bestuurlijke verankering noodzakelijk. Met de commissie InformatieVoorziening (Cie IV) en de daaraan gerelateerde ambtelijke stuurgroep InformatieVoorziening (SG IV) komt deze voorziening er. Hoewel de commissie de jure adviseert aan enerzijds het College van B&W en anderzijds aan de Dagelijkse Besturen van de stadsdelen is de verwachting dat vanwege de zwaarte van de commissie er de facto vrijwel altijd sprake zal zijn van een bindend advies. In het instellingsbesluit staat wat het doel is van de commissie: de ontwikkeling en de uitvoering van een samenhangend informatiebeleid binnen de gehele gemeente om te komen tot betere dienstverlening en betere handhaving tegen lagere kosten. De commissie heeft als taak het adviseren van het College van B&W en de Dagelijkse Besturen van de stadsdelen omtrent: • het ontwikkelen en onderhouden van een samenhangend informatie-beleid voor de gemeentelijke organisaties waaronder het vaststellen van standaarden en de informatie-architectuur, het naleven van privacywetgeving, het organiseren van een adequate informatiebeveiliging en het beheer en de verdere ontwikkeling van concernsystemen; • de uitvoering van dit informatiebeleid; • het beter benutten van ICT binnen gemeentelijke processen en de bijbehorende beleidsterreinen; • het maken van heldere keuzes op het terrein van de informatiehuishouding wanneer de situatie dit vraagt maar de belangen van gemeentelijke organisaties uiteenlopen. De bestuurlijke opdrachtgever van de concernbrede InformatieVoorziening is dus B&W, die dit delegeert aan de Cie IV, met dien verstande dat het College en de DB-en van de stadsdelen uiteindelijk formeel moeten besluiten.

Bijlagen - 35



de SG IV

De opdrachtnemer op ambtelijk niveau is de SG IV die zich laat bijstaan door een secretaris.

CO/IB

De uiteindelijke opdrachtnemer in dit model van de structurele situatie is de afdeling Informatiebeleid van de directie Concern Organisatie met een inhoudelijke betrokkenheid van het Management Team daarvan.

de samenstelling

Deelnemers aan de commissie InformatieVoorziening zijn volgens het B&Wbesluit: • de coördinerend wethouder ICT namens het college van B&W, voorzitter; • de Burgemeester; • een lid van het AB van het SSC ICT (valt in de huidige portefeuilleverdeling samen met de coördinerend wethouder ICT); • een portefeuillehouder ICT namens het stadsdeelvoorzittersoverleg; • een lid namens de stuurgroep InformatieVoorziening; • de gemeentesecretaris; • een stadsdeelsecretaris namens het stadsdeelsecretarissenoverleg; • de directeur Concern Organisatie; • de secretaris, qualitate qua. De samenstelling van de stuurgroep InformatieVoorziening is, om praktische redenen, vanaf de start in 2004 dezelfde geweest als die van de stuurgroep BRI. De eerste constituerende vergadering van de commissie InformatieVoorziening lijkt een goed moment deze samenstelling nog eens te herijken. De deelnemers (kunnen) zijn: • de directeur Concern Organisatie als voorzitter; • een drietal BRI-directeuren; • een tweetal niet-BRI-directeuren; • één of twee stadsdeelsecretarissen; • de kwartiermakend directeur van het SSC ICT; • de secretaris. Aan de vergaderingen van de SG IV mogen directeuren en stadsdeelsecretarissen op ad hoc-basis aanschuiven als er onderwerpen zijn die ze aanspreken of waar ze iets over willen inbrengen.

staf wethouder

Bijlagen - 36

Aparte aandacht verdient de positionering van de staf wethouder ICT. Het verdient aanbeveling deze niet als een apart gremium op te vatten maar de wethouder, zowel in diens verantwoordelijkheid als voorzitter van de Cie IV als die van portefeuillehouder, de eventuele agendering te laten bepalen van alle dossiers die zich aandienen. De wethouder heeft dan de keus tussen: • een dossier buiten de stafvergadering om op elektronische wijze te bespreken en eventueel door te (laten) geleiden naar B&W, Raadscommissie of Raad, zonder betrokkenheid van de Cie IV; • een dossier op de staf te bespreken en daarna, indien van toepassing, rechtstreeks naar B&W, Raadscommissie of Raad door te (laten) geleiden, zonder betrokkenheid van de Cie IV; • een dossier ter kennisgeving aan de Cie IV te zenden; • een dossier buiten de formele vergadering van de Cie IV om op elektronische wijze aan de leden te zenden met het verzoek om advies; • een dossier te agenderen voor een plenaire zitting van de Cie IV.



budget

Vooralsnog beschikt (de commissie en) de stuurgroep niet over financiële middelen . In lijn met de verantwoordelijkheid die de stuurgroep heeft is het wenselijk de beslissingsbevoegdheid over de betreffende gealloceerde middelen bij (commissie en) stuurgroep te beleggen. De financiële middelen m.b.t. programmanagement voor de verdere ontwikkeling van het SSC ICT (tranche 2 en 3) zijn op dit moment ondergebracht bij het SSC ICT.

de orde

Het is wenselijk een expliciet vergaderreglement (met zaken als vergaderfrequentie en het al dan niet accepteren van vervangers) op te stellen. Dit geldt ook voor de wijze waarop de gemeentelijke organisaties worden geconsulteerd bij belangrijke besluiten.

agendaberaad

De voorbereiding van de vergadering van de Cie IV vindt plaats onder leiding van de wethouder ICT in de staf vergadering. Zowel de SG IV als de SG BRI dragen agendapunten aan. Er moet een apart agendaberaad voor de SG IV komen.

toetsorgaan

Aangezien vrijwel alle zaken die aan de stuurgroep respectievelijk de commissie worden voorgelegd concernbrede aangelegenheden betreffen, moet elke kwestie standaard vergezeld gaan van een advies van de betrokken diensten en stadsdelen. Deze draagvlaktoetsing kan, onder regie van CO/IB, op verschillende manieren worden gemobiliseerd: via het ICT-platform, een clubje materiedeskundigen, een mailgroep of een specifieke conferentie. Elk nieuw beleid komt altijd in afstemming met de diensten en stadsdelen tot stand. In de aan de stuurgroep voorgelegde besluiten moet expliciet worden vermeld op welke wijze de concernpartners zijn betrokken.

communicatie

Het verdient aanbeveling eenzelfde openheid en transparantie te betrachten met betrekking tot de agenda en onderliggende stukken als in de BRI-lijn.

totaaloverzicht

De structurele voorziening voor IV is hiermee bepaald. Als ook de eerdere plaatjes met de programmatische (en dus tijdelijke) lijnen ernaast worden gezet, dan ziet het volledige schema er als volgt uit. Merk op dat ook de adviesgroep architectuur, die nu nog onder de stuurgroep BRI valt, in de “SOLL” situatie moet rapporteren aan de SG IV. Onder de Cie IV zou ook de stuurgroep Informatiebeveiliging moeten ressorteren. Het is mogelijk dat er in de toekomst behoefte is aan nieuwe stuurgroepen, maar het is ook denkbaar dat het betreffende onderwerp in dat geval als apart agendapunt aan de SG IV wordt gelaten.

6. Van IST naar SOLL In de voorgaande paragrafen is bij voorkeur de SOLL-situatie beschreven, de op dit moment meest wenselijke organisatie, geschetst tegen de achtergrond van de ontwikkelingen en de actualiteit. De huidige praktijk, de IST-situatie, wijkt daar op onderdelen van af. Hieronder wordt beschreven welke maatregelen of beslissingen genomen zouden moeten worden om de gewenste situatie te bewerkstelligen. de drie lijnen

De belangrijkste aanleiding is de noodzakelijke uiteenrafeling van de drie

Bijlagen - 37



sporen BRI, SSC ICT en IV. Nu de lijn van de InformatieVoorziening een bestuurlijke aanhaking gaat krijgen, wordt het tijd die ordentelijk te organiseren. de lijn BRI

De BRI-lijn is goed op orde en loopt gesmeerd. Een paar acties kunnen nog genomen worden: • de programmamanager heeft gaandeweg de taken van de secretaris overgenomen; de directie CO is met één vertegenwoordiger voldoende betrokken; • de overdracht van de verantwoordelijkheid voor de Adviesgroep Architectuur naar de stuurgroep IV; een geschikt moment daarvoor is de oplevering van de eerste versie van het Handboek Architectuur in juli van dit jaar;

de lijn SSC ICT

De lijn van de staande organisatie SSC ICT is met de Bestuurscommissie in principe goed geregeld en begint inmiddels volgens die orde te functioneren. Het DB vergadert eens in de drie weken. De nieuwe bestuurder wordt ingewerkt in diens AB-verantwoordelijkheid. De volgende acties zouden moeten worden genomen: • de vergadering van de Raad van Deelnemers moet een eigen identiteit gaan krijgen; het enige dat vooralsnog om praktische redenen gehandhaafd zou moeten blijven is het tijdstip en de locatie van de vergaderingen, namelijk direct aansluitend bij de BRI-stuurgroep; • het voorzitterschap van de vergadering zou opgepakt moeten worden door de formele functionaris die tevens voorzitter is van het DB (met dank aan de voorzitter van de SG BRI die deze taak er lange tijd bij heeft gedaan); • het DB moet daarbij gaan fungeren als agendaberaad van de vergaderingen van de RvD en het AB; • de rol van secretaris van het DB, de RvD en het AB is onvoldoende ingevuld; meest in aanmerking voor die rol komt de directeur SSC ICT of een lid van het DB; • het secretariaat (agenda, notulen, distributie van stukken, logistiek) is nu geregeld via de directie CO; dat zou belegd moeten worden bij het SSC ICT.

het programma

De verdere ontwikkeling van het SSC ICT is belegd bij een programma manager die in eerdere fases, en bij ontstentenis van de stuurgroep InformatieVoorziening, rapporteerde aan het Bestuurlijk Team Ombuigingen, aan de SG BRI en aan het DB van het SSC ICT. Inmiddels zijn de lijnen helder belegd. De volgende acties kunnen worden ondernomen: • het ontwikkelingsprogramma SSC ICT moet een duidelijke plaats gaan innemen op de agenda van de SG en eventueel Cie IV; bij de behandeling van stukken in de stuurgroep is de programma manager aanwezig; • het budgetrecht van het ontwikkelingsprogramma moet belegd worden bij de SG IV; op basis van deelplannen worden budgetten vrijgegeven.

de lijn IV

De structurele lijn van de InformatieVoorziening moet losgemaakt worden van de logistiek van het BRI-programma. Daarvoor zijn de volgende acties noodzakelijk:

Bijlagen - 38



•

• • •

•

•

• •

de definitieve samenstelling en de bemensing van de bestuurlijkambtelijke commissie moet worden geregeld; de wethouder is hierin de initiatiefnemer; de vergaderingen van de Cie IV moeten worden gepland en georganiseerd, een taak voor de secretaris; het verdient aanbeveling een expliciet reglement van orde te maken; de definitieve samenstelling en de bemensing van de ambtelijke stuurgroep moet worden geregeld; de directeur Concern Organisatie neemt hierbij het voortouw; de vergadering van de SG IV moet een eigen identiteit gaan krijgen; het enige dat vooralsnog om praktische redenen gehandhaafd zou moeten blijven is het tijdstip en de locatie van de vergaderingen, namelijk direct aansluitend bij de BRI-stuurgroep en de RvD SSC ICT; de voorzitter van de SG IV moet de vergaderingen daadwerkelijk gaan voorzitten (met dank aan de voorzitter van de SG BRI die deze taak er lange tijd bij heeft gedaan); de secretaris bemenst het secretariaat binnen de gelederen van CO; de stuurgroep Informatiebeveiliging onder voorzitterschap van de directeur DPG zou formeel opgehangen kunnen worden aan de Cie IV.

Bijlagen - 39



Bijlage 7

Organisatiearchitectuur: Advies voor besturingsmodel

Aan Van Datum

: : :

College van Burgemeester en Wethouders P. Oosterlaken (DJZ), A. Eurelings en H. Gels (CO) 18 februari 2005

Betreft

:

Advies Besturingsmodel Shared Service Organisaties

1.

Probleemstelling

In de Gemeente Amsterdam wordt in toenemende mate vorm en inhoud gegeven aan samenwerking tussen organisaties op diverse terreinen. Deze samenwerking krijgt op een aantal onderdelen een zodanig karakter dat er behoefte is om de samenwerking te formaliseren en dit in een passend juridisch kader vorm te geven. Dit betreft vooral de samenwerking die betrekking heeft op diensten én stadsdelen, of een aantal stadsdelen. Het huidige besturingsmodel voorziet niet in de mogelijkheid om intern vorm te geven aan één formele organisatie waarbij verschillende van deze bestuursorganen betrokken zijn. Op dit moment zijn er concrete initiatieven gaande op het gebied van huisvuilinzameling door een viertal stadsdelen, en samenwerking op het gebied van ICT, Financiën en P&O in de vorm van shared service organisaties. Ook zijn er momenteel vragen of de sturing van de dienstverlening van diensten zoals Stadstoezicht en Milieu en Bouwtoezicht vanuit een gezamenlijke verantwoordelijkheid voor stadsdelen en de centrale stad kan worden ingericht. Omdat in het kader van de besluitvorming inzake de shared service organisaties op korte termijn behoefte is aan een passend besturingsmodel is door JZ en CO bekeken welke mogelijkheden er thans zijn, en in hoeverre deze voldoen aan de gestelde uitgangspunten. 2.

Mogelijke oplossing

Service-centra betreffen samenwerkingsverbanden van diensten en stadsdelen. In dergelijke centra worden activiteiten en veelal ook medewerkers ondergebracht die tot dan toe behoorden tot de processen van diensten en stadsdelen. Het betreft derhalve een samenwerking binnen één rechtspersoon (de gemeente Amsterdam), waarbij verschillende bestuursorganen betrokken zijn, maar ook organisatieonderdelen die onder de verantwoordelijkheid van één bestuursorgaan vallen (diensttakken die vallen onder de verantwoordelijkheid van het college). Een aantal bekende samenwerkingsverbanden: • Een gemeenschappelijke regeling is wettelijk/juridisch binnen één gemeente

Bijlagen - 40



• •

niet mogelijk; Een diensttak onder verantwoordelijkheid van het college doet (te) weinig recht aan het samenwerkingsuitgangspunt van gedeelde verantwoordelijkheid tussen stadsdelen en ‘centrale’ stad; De oprichting van een externe rechtspersoon voldoet niet aan de wens om te komen tot een vorm van binnengemeentelijke samenwerking.

Tot op heden is het model van bestuurscommissie niet in gebruik bij de centrale stad, wel wordt het model door stadsdelen gebruikt in het kader van schoolbesturen. Een bestuurscommissie ten behoeve van de besturing van een (of meerdere) service-centra wordt ingesteld door een bestuursorgaan (het college) en opereert vervolgens op grotere afstand van het college dan een diensttak. Het college kan slechts beleidsregels (algemene aanwijzingen) aan de bestuurscommissie geven en kan zich niet op detailniveau met de commissie bemoeien. De samenwerking tussen de verschillende deelnemers wordt tot uitdrukking gebracht door het college de vertegen-woordigers van die deelnemers als lid van de commissie te laten benoemen en langs die weg te belasten met het (gezamenlijk) bestuur van het SSC. 3.

Voorgestelde oplossing: de bestuurscommissie

Indien een service-centrum werkzaam zal zijn voor diensten én stadsdelen wordt de bestuurscommissie ingesteld door het college. In geval het uitsluitend dienstverlening voor de stadsdelen betreft wordt de bestuurscommissie ingesteld door de stadsdelen. In het instellingsbesluit worden (na afstemming met de stadsdelen) onder meer de samenstelling van de commissie, de werkwijze van de commissie en de financiering van de commissie vastgelegd. Het beheer van het service-centrum wordt opgedragen aan de commissie en de commissie krijgt ook de bevoegdheid om ambtenaren te benoemen, overgedragen. Een andere bevoegdheid die kan worden overgedragen is de bevoegdheid om te beslissen tot privaatrechtelijke rechtshandelingen. De begroting en de rekening van de commissie zullen zoals gebruikelijk en wettelijk bepaald door de gemeenteraad moeten worden vastgesteld. Het college is (als instellend orgaan) verantwoording verschuldigd aan de raad voor hetgeen bij de bestuurscommissie gebeurt. In dat opzicht verschilt hij van de andere bestuursorganen. De activiteiten van een bestuurscommissie zullen in een algemeen en een dagelijks bestuur worden vormgegeven. In onderstaand model wordt dit schematisch weergegeven. Hierbij zijn een drietal varianten mogelijk: 1. algemeen én dagelijks bestuur wordt ingevuld door bestuurders 2. algemeen bestuur wordt ingevuld door bestuurders en dagelijks bestuur door topambtenaren 3. algemeen bestuur én dagelijks bestuur wordt ingevuld door topambtenaren Het belangrijkste criterium voor de keuze uit een van deze drie modellen is de mate waarin, qualitate qua, het onderwerp behoort tot de primaire aandacht van bestuurders.

Bijlagen - 41



Bestuurscommissie Algemeen Bestuur (B&W en stadsdelen) Raad van Deelnemers Dagelijks Bestuur

Directie Service Centrum De omvang van het Algemeen Bestuur is afhankelijk van het aantal deelnemers en van de invulling van het bestuur in termen van bestuurlijk of ambtelijk. Het Dagelijks Bestuur is klein van omvang, gedacht wordt aan ca drie leden. De Raad van Deelnemers biedt de mogelijkheid aan alle directeuren en stadsdeelsecretarissen van de participerende organisaties om het Dagelijks Bestuur te adviseren betrekkende de operationele sturing. Instelling van een Raad van Deelnemers is wenselijk in de situatie waarin gekozen wordt voor een bestuurlijk Algemeen Bestuur en een ambtelijk Dagelijks Bestuur.

Zoals reeds is gesteld wordt in het instellingsbesluit de gewenste invulling en taakverdeling opgenomen. In geval er meerdere service-centra zijn met dezelfde deelnemers/participanten is het vanuit proces- en doelmatigheids overwegingen raadzaam om slechts één algemeen bestuur te hanteren voor deze centra. 4.

Bestuurscommissie voor het SSC ICT en het SSC HR

In het geval van de oprichting van een SSC ICT en SSC HR, wordt geopteerd voor een bestuurscommissie waarbij zowel de bestuurlijke aandacht alsook de dagelijkse betrokkenheid van de participerende diensten en stadsdelen is gewaarborgd. Realisatie van beide service-centra betekent een complex veranderproces dat niet zonder risico’s is en derhalve ook bestuurlijke aandacht behoeft. Het SSC HR en het SSC ICT hanteren beide een ontwikkelingspad waarbij men geleidelijk in de tijd uitgroeit qua dienstverlening en het aantal deelnemende organisaties. Dit betekent dat de samenstelling van de bestuurscommissie ook in de tijd mee moet kunnen groeien. Uitgaande van de op dit moment participerende deelnemers komen we voor de korte termijn tot de volgende invulling van de bestuurcommisie voor het SSC ICT en het SSC HR:

Bijlagen - 42



Bestuurscie SSC ICT

Bestuurscie SSC HR

AB DB

portefeuillehouder bedrijven drie directeuren

Raad van Deelnemers

acht directeuren

B&W + (3-5) DB leden Stadsdelen stadsdeelsecretaris+directeur bedrijf+directeur dienst stadsdeelsecretarissen en directeuren van startgroep

Voor het SSC ICT geldt dat de Raad van Deelnemers, qualitate qua de leden van de Stuurgroep BRI, het opdrachtgeverschap vervullen in de rol van afnemer van ICTdiensten. Bij de definitieve besluitvorming door B&W betreffende de inrichting van beide shared service centra dient een uitgewerkt instellingsbesluit te worden voorgelegd, waarin onder meer de samenstelling van de commissie, de werkwijze van de commissie en de financiering van de commissie is vastgelegd.

Bijlagen - 43



Bijlage 8

Informatiearchitectuur: Objectmodellen Personen en Vastgoed

Basisregistratie Personen DETAILLERING SUBJECTEN EN VESTIGINGEN SUBJECT NATUURLIJK PERSOON

NIET-NATUURLIJK PERSOON

INGESCHREVEN PERSOON INGESCHREVEN NIET-NATUURLIJK PERSOON

FUNCTIONARIS

ANDER BUITENLANDS NIET-NATUURLIJK PERSOON

is eigenaar van

MAATSCHAPPELIJKE ACTIVITEIT

HUISHOUDEN

heeft postadres in

WOONPLAATS

heeft postadres in

heeft als correspondentie- of aanschrijvingsadres

verblijft in of op

heeft nadere adresaanduiding in

PARTNERRELATIE

ANDER BUITENLANDS NATUURLIJK PERSOON

OUDER-KINDRELATIE OVERIGE PERSOONSRELATIE

INGEZETENE

NIETINGEZETENE

heeft als correspond entie-adres

VERBLIJFSOBJECT

OVERIG GEBOUWD OBJECT

AUTHENTIEK TERREIN

OVERIG TERREIN

BENOEMD TERREIN

GEBOUWD OBJECT

[Bron: EGEM]

Bijlagen - 44

VESTIGING

bepaalt nevenadres van

NUMMERAANDUIDING

OVERIG ADRES bepaalt hoofdadres van

bepaalt nevenadres van

ADRESSEERBAAR OBJECT AANDUIDING



Basisregistratie Vastgoed DETAILLERING ADRESSEN, GEBOUWEN EN TERREINEN

OPENBARE RUIMTE

ADRESSEERBAAR OBJECT AANDUIDING OVERIGE ADRESSEERBAAR OBJECT AANDUIDING

NUMMERAANDUIDING

officieel adres officieel adres locatie-adres straatadres nevenadres

OVERIG GEBOUWD OBJECT

hoofdadres

VERBLIJFSOBJECT

hoofdadres

nevenadres

STANDPLAATS

LIGPLAATS

OVERIG TERREIN

AUTHENTIEK TERREIN BENOEMD TERREIN

GEBOUWD OBJECT hoort bij

ligt in

PAND

[Bron: EGEM] DETAILLERING KADASTRALE ONROERENDE ZAKEN EN RECHTEN heeft als voornaamste zakelijk gerechtigde

KADASTRALE ONROERENDE ZAAK

KADASTRAAL PERCEEL

ligging

APPARTEMENTSRECHT

ZAKELIJK RECHT

filiatie

SUBJECT

heeft aantekening van

heeft als vereniging van eigenaars heeft aantekening van

[Bron: EGEM] De objectmodellen zijn gebaseerd op het referentiemodel “Stelsel van Gemeentelijke Basisgegevens” van EGEM.

Bijlagen - 45



Bijlage 9

Informatiearchitectuur: StUF Standaard Uitwisselings Formaat

StUF is het Standaard Uitwisselings Formaat voor het uitwisselen van binnengemeentelijke berichten. De standaard specificeert zelf geen concrete berichten, maar is een template-definitie: een globale structuur voor berichten die sector-onafhankelijk is, waarmee concrete berichten gedefinieerd kunnen worden. StUF is een gestandaardiseerde manier om een willekeurig ER-model van een toepassingsgebied binnen de gemeente om te zetten naar berichten. StUF2 schrijft XML voor als opmaaktaal voor berichten. De syntax (structuur) van de berichten is formeel vastgelegd met behulp van een XML-schema (XSD). Het berichtenschema geeft aan welke entiteiten, attributen en relaties uit het GFO in de berichtentypen mogen worden opgenomen. Een voorbeeld van een berichttype is Kennisgevingbericht NATUURLIJK PERSOON. Berichttypen kunnen worden onderverdeeld in drie uitwisselingspatronen: 1. Kennisgeving: De zender deelt de ontvanger mede dat er in de werkelijkheid of in zijn representatie van de werkelijkheid iets is veranderd. 2. Synchroon vraag/antwoord: De zender vraagt aan de ontvanger informatie over zijn representatie van de werkelijkheid en krijgt direct een antwoord 3. Asynchroon vraag/antwoord: De zender vraagt aan de ontvanger informatie over zijn representatie van de werkelijkheid en verwacht het antwoord na verloop van tijd in een separaat proces te krijgen toegezonden. Deze uitwisselingspatronen voor berichten kunnen beschouwd worden als diensten (webservices) die een zendend of/en ontvangend systeem levert. In een WSDL file wordt gedefinieerd welke berichttypen er per dienst worden geleverd. StUF2 geeft invulling aan keuzes die bij de XML Schema’s worden gemaakt voor de stuurgegevens en de body (payload). Stuurgegevens zijn bijvoorbeeld het versienummer van StUF en het versienummer van Sectormodel. Alle beheerders van basisregistraties in de gemeente Amsterdam streven er naar hun gegevens volgens dezelfde versies van StUF, GFO en sectormodellen te leveren. Ze streven naar zo min mogelijk compatibiliteitsproblemen bij de invoering van verschillende versies. Er is binnen de gemeente Amsterdam een StUF-platform opgericht waaraan aanleverende partijen en afnemers deelnemen (zie Viadesk). StUF maakt het echter mogelijk met meerdere sectormodellen tegelijk te werken. Het sectormodel kan worden gezien als het geheel van ontwerpproducten die nodig zijn om systemen binnen een toepassingsgebied binnen de gemeente te koppelen. Voor de Basisgegevens is het sectormodel beschikbaar. Voor de andere sectoren zoals Zaken moeten de ontwerpers het sectormodel

Bijlagen - 46



specificeren. Dit wordt weergegeven in onderstaand figuur. EGEM heeft in april 2006 StUF versie 2.04 vastgesteld. Tegelijkertijd heeft EGEM een nieuwe versie vastgesteld van het sectormodel Basisgegevens: StUF-BG 2.04. Dit sectormodel is gebaseerd op een verouderd GFO voor Basisgegevens: GFO-BG 1998. Dit jaar wordt de publicatie verwacht van een nieuw GFO voor Basisgegevens: het Referentiemodel voor het Stelsel van Gemeentelijke Basisgegevens (GFO-BG 2006) en de bijbehorende berichtdefinities. GVI baseert de levering van Vastgoedgegevens op GFO-BG 2006, omdat GFO-BG 1998 strijdig is met de Catalogus voor de BAG. Op het moment dat GVI de koppeling in productie neemt, zal deze GFO zijn geformaliseerd. Wijzigingen ten gevolge van het nieuwe GFO-BG 2006 worden in Paraplu opgenomen voor de distributie van persoonsgegevens door DPG, als het sectormodel StUF-BG hierop is aangepast. EGEM werkt aan een nieuwe versie van de berichtdefinities, die gebaseerd is op GFO-BG 2006. StUF 2.04 is beschikbaar op de EGEM website. Daarvoor dient men zich in te schrijven op de StUF projectsite van EGEM: http://projecten.egem.nl/mmproject/simplepage.jsp?page=enroll. Na inschrijving ontvangt men van EGEM een emailbericht dat het aangemaakte account geactiveerd is. Vervolgens kan men via de StUF Community van EGEM de laatste versie van de StUF 2.04 standaard in PDF-formaat downloaden. Het sectormodel is ook beschikbaar op de EGEM website. Het sectormodel bestaat uit het bestand ‘BG0204.xsd’ waarin de mogelijke entiteiten, elementen en relaties zijn benoemd. Deze XSD is aangevuld met het document ‘Sectormodel StUF-BG 0105.doc’ waarin extra informatie is opgenomen, zoals voorgeschreven sorteringen, optionaliteit, kardinaliteit en extra gedefinieerde tabellen, en de WSDL file.

Zowel DPG als GVI beïnvloeden actief de landelijke ontwikkelingen richting een coherente standaard gebaseerd op GFO-BG 2006. Beide organisaties nemen deel aan de EGEM StUF werkgroep en de EGEM StUF Community en brengen regelmatig voorstellen in voor nieuwe ontwikkelingen ten aanzien van deze standaard. Bijlagen - 47



Bijlage 10 Informatiearchitectuur: Standaarden digitale informatiebeheer

Inleiding Deze standaarden zijn van toepassing op digitaal gecreëerde, procesgebonden informatie die bewaard moet worden vanwege weten regelgeving en/of andere concernbelangen. Zij zijn ook van toepassing op digitale reproducties die gelden, of in de toekomst hoogstwaarschijnlijk gaan gelden als wettelijk substituut. De standaarden zijn niet van toepassing op digitale reproducties die geen subsituut zijn of worden De standaarden beschrijven eisen die gesteld worden aan structuur, syntax en inhoud van metadata over digitale bestanden. Zij beschrijven ook welke bestandsformaten zijn toegestaan voor het bewaren van digitale informatie. De standaarden dienen als randvoorwaarde voor de inrichting van de digitale informatiehuishouding in het concern. De standaarden gaan niet over informatiebeveiliging en over het beheer van digitale bestanden en metadata. Het beschrijft ook niet technische zaken als ICT-systemen, conversietools etc. Uiteraard dienen de standaarden uitgebreid en gewijzigd te worden onder invloed van voortschrijdend inzicht, veranderende weten regelgeving, ondersteuning, organisatie binnen het concern, kennis binnen het concern en beschikbare middelen in het concern. Organisatie Het opstellen, vaststellen en publiceren van standaarden voor digitaal informatiebeheer zou een verantwoordelijkheid en bevoegdheid van het Gemeentearchief moeten zijn. Op dit moment is dit echter (nog) geen realiteit. Deze standaarden worden daarom samengesteld en vastgesteld door de programmamanager Digitaal Informatiebeheer i.s.m. de Adviesgroep Architectuur en het Gemeentearchief. De standaarden worden gepubliceerd in het Handboek Architectuur en op Viadesk (kennisgroep Document Management en Documentum). Contactpersoon voor samenstelling van de standaarden is Frans Smit, programmamanager Digitaal Informatiebeheer (mail: [email protected]; telefoon: 020-5720227).

Bijlagen - 48



1. Standaarden Algemene uitgangspunten 1. Standaarden voor het beheren van digitale informatie moeten passen binnen de kaders van relevante weten regelgeving en besluiten van de gemeente inzake informatie-architecturen en informatiebeveiliging 2. De standaarden moeten zoveel mogelijk aansluiten bij nationale en internationale standaarden (zoals ISO 23081) en best practices 3. De standaarden moeten dusdanig worden samengesteld dat het reëel is dat ze succesvol kunnen worden toegepast binnen de Gemeente Amsterdam 4. De standaarden moeten worden vastgesteld op 5 niveaus: gegevenselementen, waarden in die gegevenselementen, trefwoorden (basisregistraties en classificaties), syntax van de gegevens en bestandsformaten. 5. De standaarden dienen dusdanig beschreven en hanteerbaar te zijn dat ze gebruikt kunnen worden als basis voor audits en archiefinspecties. 6. Het praktisch toepassen van de standaarden moet zoveel mogelijk geschieden tijdens of zo snel mogelijk na creatie van het digitale bestand 7. Het toepassen van de standaarden moet zoveel mogelijk geautomatiseerd ondersteund worden door standaardapplicaties 2. Uitwerking per niveau Gegevenselementen 1. Voor de definitie van gegevenselementen wordt de Dublin Core 59 als uitgangspunt genomen. 2. In ieder geval zijn per bestand verplicht: een uniek ID, creatiedatum, versie, archiefvormer, status, statushistorie 3. Per bestand zijn verplicht indien relevant: auteur(-s), verwijzing(-en) naar Basisregistratie(-s), verwijzing(-en) naar dossier(-s), publicatiedatum(-s), wijzigingsdatum(-s), inzagerechten 4. Er moet nog nader worden vastgesteld welke andere velden uit Dublin Core verplicht worden gesteld en welke optioneel, bij welke bestandsformaten. Waarden in gegevenselementen 1. Het uniek ID is een numerieke serie van 12 cijfers en dient te zijn samengesteld uit een 3-cijferige code voor het betreffende concernonderdeel (de archiefvormer) en vervolgens een volgnummer van 9 cijfers. 2. Voor de overige waarden in verplichte gegevenselementen moeten in 2006 standaarden worden vastgesteld Trefwoorden, basisregistraties en classificaties 1. Documenten dienen geordend te worden naar het werkproces waarin ze zijn gecreëerd en/of gebruikt. Indien documenten niet te herleiden zijn naar een werkproces dan dienen zij geordend te worden naar de inhoud 2. Documenten die een relatie hebben met gegevens uit een of meer 59

Voor meer informatie over Dublin Core: http://webrichtlijnen.overheid.nl/handleiding/ontwikkeling/productie/metadata/dublin-core/

Bijlagen - 49



basisregistraties, dienen een verwijzing te hebben naar die gegevens. Syntax van gegevens 1. De syntax van gegevens dient dusdanig te zijn dat gegevens tussen concernonderdelen en concernapplicaties zoveel mogelijk geautomatiseerd uitgewisseld kunnen worden. 2. De syntax van gegevens mag door ieder concernonderdeel zelf worden samengesteld met als uitdrukkelijke randvoorwaarde dat ze bij levering aan andere concernonderdelen altijd voldoen aan een concernbreed geaccepteerd uitwisselingsformaat 3. Gegevensuitwisseling dient te geschieden aan de hand van een of meer nog vast te stellen geaccepteerde XML-formaten (met bijbehorend DTD) Bestandsformaten Algemeen 1. Bestandsformaten dienen gestandaardiseerd te worden met als uitgangspunt dat inhoud, vorm en/of functie van digitale informatie bewaard moeten worden. 2. Standaarden voor bestandsformaten dienen vervolgens vastgesteld te worden aan de hand van de status (in gebruik, niet meer veranderbaar), de ontstaansgeschiedenis (digitaal geboren dan wel digitale reproductie) en de bewaartermijn van een bestand. 3. Er moeten standaarden aanwezig zijn voor tekstverwerkingsbestanden, spreadsheets, databases, tekeningen, foto’s, audio, video en interactieve bestanden. 4. Voor een combinatie van bestanden die als een logische eenheid is samengesteld, zoals een e-mail met attachment, dient dat verband behouden te blijven. Tekstverwerking 1. Voor tekstverwerkingsbestanden moeten inhoud en vorm bewaard worden. 2. Geaccepteerde formaten zijn PDF en XML. Spreadsheets 1. Voor spreadsheets moeten inhoud en functie bewaard worden Databases 1. Voor databases moeten inhoud en functie bewaard worden. Tekeningen 1. Voor tekeningen moeten inhoud, vorm en functie bewaard worden. Foto’s 1. Voor foto’s moeten inhoud, vorm en functie bewaard worden. Audio en video 1. Voor audio- en videobestanden moeten inhoud en functie bewaard worden.

Bijlagen - 50



Interactieve bestanden Voor interactieve bestanden moeten de uitgangspunten nog vastgesteld worden.

Bijlagen - 51



Bijlage 11 Informatiearchitectuur: Principes gegevensbescherming

Onderstaand worden de 8 principes voor gegevensbescherming toegelicht. De principes zijn als volgt geordend: 1. Doelbinding en rechtmatigheid 1-4 2. beveiliging 5 3. transparantie 6, 7 4. algemeen 8 1. Het Collection and Distribution Limitation Principle Dit beginsel geeft aan dat er beperkingen moeten gelden ten aanzien van het verzamelen van persoonlijke gegevens en dat dergelijke gegevens op een eerlijke en rechtmatige wijze zijn verkregen, en indien van toepassing, met het in kennis stellen en de toestemming van de betrokkene. Naast beperkte verzameling is ook beperking in het distribueren mogelijk. In plaats van het toegang geven tot ruwe gegevens, kan men (eventueel met behulp van een intermediaire informatiemakelaar) geaggregeerde informatie verstrekken. De privacy wordt minder geschonden als men meldt dat een bepaald persoon minder dan 1500 euro per maand verdient, dan als men van elke persoon exact meldt wat hij waar verdiend heeft. 2. Het Data Quality Principle Dit beginsel bepaalt dat persoonlijke gegevens relevant moeten zijn voor het doel waarvoor ze bedoeld zijn te worden gebruikt, en dat de gegevens, voor zover nodig in relatie tot dat doel, juist, volledig en up-to-date zijn. Daartoe moeten kwaliteitsborgingsprocessen ingericht worden (systematische checks met de werkelijkheid, crosschecks met andere gegevens). Tot slot moet inzage en correctie mogelijk zijn, niet alleen van de gegevens, maar ook van het gebruik van de gegevens door specifieke overheidsorganisaties. 3. Het Purpose Specification Principle Het doel waarvoor gegevens worden verzameld moet worden aangegeven op, of voorafgaande aan het moment van het verzamelen van de gegevens. Het gebruik van de gegevens is beperkt tot het gebruik voor deze doeleinden of daarmee in overeenstemming zijnde doeleinden. Doelbinding geldt als belangrijk uitgangspunt. Daarvan uitgezonderd moeten evenwel de basisregisters worden. Basisregistraties zijn per definitie registraties die voor meerdere doeleinden gebruikt worden. De daarin opgenomen informatie moeten we zien als infrastructuur en is in wezen doelloos. Het vanuit gegevensbescherming te dienen belang moet zich niet richten op de aanleg van de basisregisters, maar op het gebruik van de registers in concrete processen van de overheid. We hebben kunnen constateren dat informatie verzamelen en vastleggen in

Bijlagen - 52



politieke en ontwikkelingsprocessen zoveel mogelijk anoniem moet gebeuren. Traceerbaarheid naar individuen is daar niet verstandig, vanuit democratietheoretisch oogpunt. Toegang tot deze processen moet mogelijk zijn zonder de identiteit vrij te geven. Het nagaan wie welke openbare informatie van gemeentelijke websites leest moet in principe niet mogelijk zijn. In de andere processen (dienstverlening, handhaving, beheer en bedrijfsvoering) is meer informatieverzameling nodig, maar dan kan dan gelogd worden wie welke informatie waarvoor gebruikt. 4. Het Use Limitation Principle Persoonlijke gegevens mogen niet verstrekt worden, of op een andere wijze ter beschikking worden gesteld, voor andere dan de gespecificeerde doeleinden, behalve met toestemming van de betrokkene of op basis van een wettelijk voorschrift. Deze limitering kan aanvullend sterk gedifferentieerd worden, door informatiebeschikbaarheid naar locatie, naar rollen en naar tijd in te perken. Deze differentiatie compenseert de tendens tot hergebruik van gegevens. 5. Het Security Safeguards Principle Persoonlijke gegevens moeten worden beschermd op basis van redelijke beveiligingsnormen tegen verlies, ongeautoriseerde toegang, vernietiging, gebruik, verandering of verstrekking van deze gegevens. Autorisaties kunnen verregaand gedifferentieerd worden. Gebruik van gegevens door ambtenaren kan gelogd worden. En identificatie van informatiegebruikers kan op een hoger niveau getild worden. Dit laatste kan bijvoorbeeld door de introductie van een single sign on te combineren met een Elektronische Identiteits Kaart met bijbehorende kaartlezer voor ambtenaren verplicht te stellen. 6. Het Openness Principle Er dient openheid te worden gegeven over ontwikkelingen, praktijken en beleid in relatie tot persoonlijke gegevens. Er moeten voorzieningen worden getroffen zodat het bestaan en de aard van persoonlijke gegevens kunnen worden medegedeeld, evenals de belangrijkste doelstellingen voor het gebruik van deze gegevens, en de identiteit en het adres van de verantwoordelijke. Daaraan valt toe te voegen dat op beschikkingen gemeld kan worden welke gegevens zijn gebruikt bij de totstandkoming van de beschikking. Ook kan het loggen van gegevens gebruikt worden om die informatie via een Persoonlijke Internet Pagina toegankelijk te maken voor burgers. Zij hebben dan niet alleen online inzage en correctierecht, maar kunnen ook zien wie welke gegevens waarvoor geraadpleegd heeft. 7. Het Individual Participation Principle Een persoon moet het recht hebben om van een verantwoordelijke te weten te komen of gegevens over hem of haar worden verwerkt. Indien dit het geval is moet deze persoon het recht hebben, om binnen een redelijke tijd, tegen redelijke kosten, op een redelijke wijze en op een begrijpelijke wijze hierover ingelicht te worden. Indien dit wordt geweigerd moet de persoon de reden worden gegeven waarom dit is geweigerd, en moet deze de mogelijkheid hebben hiertegen in beroep te komen. Aansluitend moet iemand de mogelijkheid hebben om bezwaar te maken tegen gegevens die over hem of haar worden verwerkt, en als dit bezwaar terecht is, om de gegevens te laten

Bijlagen - 53



vernietigen, te verbeteren of aan te vullen. 8. Het Accountability Principle De verantwoordelijke is verantwoordelijk om zich te houden aan maatregelen voor het uitvoeren van deze beginselen. Dit kan versterkt worden door de introductie van toezicht op gegevensbescherming en het introduceren van sancties bij gebleken schending daarvan. Ook kan van medewerkers gevraagd worden een privacyprotocol te ondertekenen en kunnen zij geschoold worden in beveiliging en professioneel omgaan met persoonsinformatie. Een uitwerking van de principes wordt voor wat betreft de basisregistratie Personen vastgelegd in het Dossier Afspraken en Procedures (DAP) voor alle betrokken partijen: de afnemende dienst, de Dienst Persoonsgegevens, de Registratiecommissie, de ACAM maar bijvoorbeeld ook de geïnteresseerde burger. Op de minisite basisregistratie Personen staan de meest recente versies van de verschillende onderdelen van de dossiers. De afspraken die de Dienst Persoonsgegevens en afnemers hebben gemaakt, geven in hun onderlinge samenhang een totaalbeeld van het gebruik van de basisregistratie Personen in Amsterdam. Het idee achter de DAP voor een transparante informatie-uitwisseling werkt alleen als ook de beheerders van de (toekomstige) kernadministraties vergelijkbare afspraken maken binnen de gemeente en met buitengemeentelijke partijen.

Bijlagen - 54



Bijlage 12 Applicatiearchitectuur: Applicatielandschap

In onderstaande tabel zijn de verschillende functies weergegeven met een definitie, een beschrijving van mogelijke technische hulpmiddelen/applicaties en de laatste kolom geeft aan in welk Amsterdamse oplossing dit momenteel beschikbaar is. Functiegroep

Functies

Definitie

Technisch hulpmiddel

Post

Kanaal waarmee de aanvrager (burger) per post een vraag kan stellen of een product/dienst kan aanvragen. Er bestaat in dit geval geen direct contact tussen de burger en de ambtenaar (stateless, asynchrone communicatie). Kanaal waarmee de aanvrager (burger) in direct contact met een ambtenaar van de gemeente een vraag kan stellen of een product/dienst kan aanvragen. Indien mogelijk wordt de burger direct geholpen. Kanaal waarmee de aanvrager (burger) in telefonisch contact met een ambtenaar van de gemeente een vraag kan stellen of een product/dienst kan aanvragen. Indien mogelijk wordt de burger direct geholpen. Kanaal waarmee de aanvrager (burger) per email een vraag kan stellen of een product/dienst kan aanvragen. Er bestaat in dit geval geen direct contact tussen de burger en de ambtenaar (stateless, asynchrone communicatie). Kanaal waarmee de aanvrager (burger) interactief via een webformulier op de internetpagina van de gemeente een aanvraag voor een gemeentelijke dienst kan invoeren. Het is daarnaast ook mogelijk dat de burger toegang heeft tot zijn eigen electronisch loket (mijnLoket) waarin bijvoorbeeld de status van zijn/haar aanvraag kan worden gevolgd. Kanaal waarmee de aanvrager (burger) in direct contact via chat met een ambtenaar van de gemeente een vraag kan stellen of een product/dienst kan aanvragen. Indien mogelijk wordt de burger direct geholpen.

Postregistratie, Dossieropslag

Maakt het mogelijk een beschikbaar tijdstip als afspraak te selecteren waarbij rekening wordt gehouden met de agenda's van de behandelende medewerkers. Een hiërarchie van vragen die de gebruiker naar de juiste beslissing leidt. Maakt het mogelijk webformulieren of vragen op webformulieren te selecteren. Een functionaliteit die het mogelijk maakt het verschuldigde bedrag) aan de rechthebbende te doen toekomen.

BAVAK

Amsterdamse product

Kanalen

Balie

Telefoon

E-mail

Internet

Chat

Aspect

Antwoord

Kana Response

Antwoord

MmBase, WebOS, SmartSite, Iprox, Kode, Portaal

Loket Amsterdam

-

Ondersteunen Klant Afspraken maken

Beslisboom doorlopen

Betalen

Debateren via internet

Kode

Loket Amsterdam

Credit card, Ideal

Ogone, Binnenhavengel d

Bulletin Board

Viadesk

Bijlagen - 55


Functiegroep


Functies Publiceren geografische informatie Kennisbank ontsluiten

Definitie

De representatie van kennissystemen in de vorm van een beslisboom of een verzameling (ongestructureerde) gegevens met een (geavanceerde) zoekfunctie. Abonneren op signalering van meest recente nieuwsitems

Nieuws abonneren Publiceren ongestructure erde content Publiceren Opvragen van openbare documenten door de bestuursbeslui aanvrager zelf én het versturen van de ten openbare informatie aan de burger door een ambtenaar Raadplegen Overzicht van alle gemeentelijke producten en productcatalo diensten. Deze producten en diensten kunnen gus zowel door de burger als door de ambtenaren binnen de gemeente worden geraadpleegd. Geautomatise erde Telefonische Informatie Verstrekking Telefoongids Webformulier

Maakt het mogelijk om allerlei informatie die de klant via de website kan opvragen óók via de telefoon kan opvragen, menu-gestuurd, volledige geautomatiseerd Registratie en publicatie van lijst van medewerkers plus contactgegevens Een (HTML) formulier op het inter- of intranet. Deze webformulieren kunnen worden gegenereerd, gepubliceerd en gevolgd.


Amsterdamse product

Oracle, Mapguide

Atlas Amsterdam

Verity

BEA Weblogic Portal Server

Nieuwsbriefedit or Portaal Amsterdam

Verity

Bestuursinform atie on line

Verity

Loket Amsterdam

Aspect

Antwoord

Mapguide

Zoek een collega… Atlas Amsterdam, Bestemmingspl an

Classificeren klantvraag Uniformeren klantvraag

Vastleggen klantprofiel Bepaal Prioriteit

Aanvullen klantbeeld

Completeren aanvraag

Identificeren

De aanvragen zoals deze via de kanalen zijn binnengekomen, worden geuniformeerd naar één en hetzelfde formaat. Dit maakt het mogelijk om de aanvraag in een volgende stap in een zelfde formaat binnen het gemeentelijk zakensysteem vast te leggen, te behandelen en de voortgang te volgen. Hieronder valt bijvoorbeeld het scannen van een (niet digitaal) poststuk. Hierdoor wordt het mogelijk dit document op te slaan in een electronisch (zaken)dossier. De geuniformeerde gegevens worden vastgelegd bij het profiel van de klant Routering van de vraag naar de juiste personen en/of afdelingen. Daarbij kan eveneens de prioritering van afhandeling worden vastgelegd. Beoordelen en indien nodig aanvullen van de gegevens van de aanvrager. Dit wordt meestal bereikt door gegevens uit de kernadministraties te verzamelen. Op basis van het bekende klantprofiel van de aanvrager, kunnen gegevens gegevens van de aanvrager zoals deze bekend zijn binnen de gemeentelijke administratie, worden voorgevuld. Te denken valt aan het voorvullen van persoons- en NAW gegevens op basis van het sofinummer of gemeentelijk A-nummer. Identificeren of authenticeren houdt in dat wordt gecontroleerd of de persoon daadwerkelijk diegene is wie hij of zij beweert te zijn. Dit kan zowel een handmatig proces zijn (bijvoorbeeld de controle van een paspoort) als een geautomatiseerd proces.

Presentatie integratie Eénduidig presenteren

Bijlagen - 56

Meerdere applicaties naast elkaar, individueel bepaald, presenteren

Enterprise Content

Portaal Amsterdam


Functiegroep


Functies

Verzamelen content

Zoeken content

Definitie

Content (statische informatie met bijbehorende metagegevens, die kan bestaan uit een combinatie van tekst, afbeeldingen, HTML, Word-documenten, PDF-files, audio en/of video) moet zodanig beschikbaar worden gesteld zodat per contenttype specifieke bewerkingen mogelijk zijn Aan de hand van een zoekcriterium informatie terugvinden. Hierbij worden vaak meerdere contentbronnen en applicaties doorzocht. De zoekmachine indexeert hiertoe informatie uit de verschillende contentbronnen.


Amsterdamse product

Management

(BEA Weblogic Portal Server) Portaal Amsterdam (BEA Weblogic Portal Server)

Portlets

Zoekmachine

Verity

Beheerfunctie s Redigeren dossiers Redigeren teksten

Afhandelen email Ontwerpen formulier

Hiermee kan de content van een website worden onderhouden, beheerd en gepubliceerd zonder dat technische kennis noodzakelijk is. Het systeem haalt content, structuur en vormgeving uit verschillende bronnen. De vormgeving is doorgaans vastgelegd in sjablonen (templates). De content wordt in de juiste vormgeving op de juiste plaats in de structuur gepubliceerd. Met behulp van een editor kunnen teksten worden gemaakt die rechtstreeks in het CMS kunnen worden gebruikt.

Voordat een formulier gepubliceerd wordt moet het ontworpen worden. Ontwerp en publicatie wordt vaak gedaan m.b.v. een formulierensysteem.

MmBase, WebOS, SmartSite, Iprox

Andreas; DIV; Walvis; DECOS Web-in-a-box; Plug-and-Play

MS Outlook, Kana Response Kode

Beheren gebruikerslijst Uitwisselen berichten

Basiscommun icatie

Koppelen

Het op een betrouwbare wijze verzenden, routeren, afleveren en loggen (en eventueel vertalen) van berichten tussen overheidsorganisaties en tussen overheid en burger en bedrijfsleven, op basis van een tussen 2 partijen overeengekomen berichtenprotocol (beschrijving van het gegevensdeel en de syntax van berichten die uitgewisseld worden). Tussen alle Amsterdamse gemeenteinstellingen en -ambtenaren moet onderling dataverkeer mogelijk zijn in een beveiligde omgeving, met een hoge beschikbaarheid en een goede performance. Dit netwerk regelt het pure transport, waarvan de ‘berichtuitwisseling’ gebruikmaakt. Het regelen van de informatieoverdracht tussen een integratievoorziening en de daarop aangesloten applicaties en systemen o.b.v. het afgesproken berichtenprotocol.

LAN, WAN

E-net

Adapter

BEA Weblogic Integration

Routeren

Het plaatsen van berichten in een wachtrij (= tussentijdse opslag) , waarna de berichten in een bepaalde volgorde naar de bestemde applicatie(s) worden verzonden.

Broker


Abonnemente ndienst

Het vastleggen dat applicatie X geïnteresseerd is om bij een bepaalde gebeurtenis in applicatie Y een bericht te ontvangen. Dit mechanisme staat bekend als publish & subscribe. Applicatie Y maakt kenbaar welke gebeurtenissen 'beschikbaar' zijn en applicatie X abonneert zich daarop.

Broker


Bijlagen - 57


Functiegroep


Functies

Definitie


Amsterdamse product

Splitsen en filteren

Het combineren van verschillende abonnementen om deze vervolgens te splitsen en te filteren tot enkelvoudige gebeurtenischecks bij de leverende applicaties. Het vertalen van één berichtenformaat (van de verzender) naar een ander berichtenformaat (van de ontvanger), waarbij de betekenis (semantiek) dezelfde blijft. Bij translatie is sprake van het vertalen van een dataformaat naar een ander dataformaat. Het beoordelen of de berichten juist, betrouwbaar en onweerlegbaar zijn. Dit staat ook bekend als transactie management. Beveiliging tegen oneigenlijk gebruik van berichten en de gegevens daarbinnen Het uitwisselen van diensten tussen overheidsorganisaties en tussen overheid en burger en bedrijfsleven, op basis van een beschrijving van services die kunnen worden afgenomen Het beschikbaarstellen en onderhouden van een centrale bibliotheek van services

Broker


Broker


Broker


Het bewaken van de dienstverlening zoals die in een SLA is vastgelegd Operationeel management, waaronder het loggen van berichten, nodig voor foutherstel, beheer- en management informatie Het proces waarbij een computer of applicatie nagaat of een gebruiker, andere computer of applicatie daadwerkelijk is wie hij beweert te zijn. Na de authenticatie vindt autorisatie plaats om na te gaan welke toegangsrechten de geauthenticeerde gebruiker, computer of applicatie heeft. Het vastleggen van gebruikersnamen en bijbehorende passwords Identiteit controleren aan de hand van gebruikersnaam en password Nagaan of een gebruiker, andere computer of applicatie daadwerkelijk is wie hij beweert te zijn Het verlenen van toestemming voor gebruik van een applicatie of service voor een gebruiker met een bepaalde rol Het gecoordineerd aansturen van processen in verschillende organisatieonderdelen, op zodanige wijze dat deze voor de (interne of externe) klant als één samenhangend proces wordt ervaren. Hier kan de vergelijking worden getrokken met een boodschappenbriefje voor verschillende overheidsloketten. Het grafisch weergeven van een proces, zodat uiteindelijk code in software gegenereerd kan worden. Het 'opschrijven' van bedrijfsregels, zodat uiteindelijk code in software gegenereerd kan worden. Signaleren dat alle processen en terugkoppelingen verlopen binnen de vastgestelde tijdsgrenzen en zonodig escaleren/alarmeren Het on line bekijken van de procesvoortgang.

Service Bus

-

Service Bus

-

I AM-server

Active Directory

Transformatie en translatie

Validatie

Beveiligen bericht Beheren services

serviceregistratie (gids) service (SLA) management service monitoring Authenticeren & autoriseren

Registreren gebruikers Identificeren gebruiker Authenticeren

Autoriseren

Regisseren processen

Procesmodelleren Procesregels vastleggen Procesmonitoring en bewaking Proces inzage

Simuleren

Bijlagen - 58

Het nabootsen van een proces o.b.v. het vastgelegde procesmodel en -regels.

Broker

Service Bus

I AM-server

DigiD

I AM-server

Active Directory, DigiD

Per applicatie

Diverse

Business proces management Business proces management Business proces management


Business proces management Business proces management


BEA Weblogic Integration BEA Weblogic Integration



Functiegroep


Functies

Toegang verlenen Registraties

Distribueren basis- en kerngegevens

Gegevensmagazijn Registreren zaken

Kanalen

Classificeren klantvraag

Assisteren en informeren klant

Registreren zaak

Beheren zaak

Definitie Om eenmaal aangeleverde (gestructureerde) gegevens toegankelijk te houden voor alle organisatieonderdelen (componenten) dient een eenduidige registratie plaats te vinden. Gaat het om de standaardoverheidsset van basisgegevens over personen en bedrijven dan spreekt men van Basisregistraties. In andere gevallen spreekt men van kernadministratiees. Het distribueren van de basis- en kerngegevens die op meerdere plekken binnen de gemeente wordt gebruikt en die de gemeente centraal beheert. Distributie kan op basis van een kennisgeving en/of vraag/antwoord plaatsvinden. Een kopie van de basis- en kerngegevens die alleen zijn te raadplegen, ten bate van de gemeentebrede distributie en toegang. Een zaak is een samenhangende hoeveelheid werk met een welgedefinieerde aanleiding en resultaat waarvan kwaliteit en doorlooptijd bewaakt moet worden. De gestructureerde (records) en ongestructureerde (documenten) gegevens van een zaak vormen samen een zakenmagazijn dat betrekking heeft op zowel de inhoud als het proces. De klant kan zijn vraag via verschillende ingangen stellen. Het proces Kanalen verwerkt de verschillende vraagvormen tot een uniforme klantvraag. Afhankelijk van de specifieke eigenschappen van het kanaal worden subprocessen uitgevoerd om de klantvraag te uniformeren. Het eindresultaat van het proces is een klantvraag in een uniform formaat, waardoor deze door de overige processen kunnen worden behandeld. Na binnenkomst van een geüniformeerde klantvraag worden alle voorbereidende werkzaamheden uitgevoerd voordat de klantvraag als zaak kan worden vastgelegd. Vragen met een formeel karakter worden doorgegeven aan het proces Registreren zaak. Klantvragen die betrekking hebben op een verzoek om assistentie of informatie of vragen, die niet geclassificeerd kunnen worden, worden door het proces Assisteren en informeren klant afgehandeld. Dit proces helpt de klant bij het beantwoorden van zijn/haar vraag. Hiertoe staan verschillende hulpmiddelen ten dienste, zoals zoekfunctionaliteit, een productencatalogus, een geleide zoekprocedure (vraagtrechter) etc. Er wordt beoordeeld of er voldoende informatie voorhanden is om de Zaak in behandeling te nemen. Tevens wordt een initiële toewijzing van een Zaaktype uitgevoerd d.m.v. de Zaaktype catalogus. Vervolgens wordt de geregistreerde Zaak in beheer genomen door het proces Beheren Zaak. Dit proces is primair verantwoordelijk voor het sturen en bewaken van de uitvoering van de Zaak. Hiertoe worden alle relevante Zaken regelmatig beoordeeld op geschiktheid voor het uitvoeren van een processtap in de totale Zaakafhandeling. Zaken, die zich hiervoor classificeren worden actief gemaakt en doorgestuurd naar Behandelen zaak. Behandelen Zaak is verantwoordelijk voor de terugmelding van statusinformatie aan Beheren Zaak. Beheren Zaak kan deze statusinformatie beschikbaar maken aan de


Amsterdamse product

Distributiemechanisme

Paraplu / Diva

Database

Paraplu / Diva

Post, scannen, telefoon, webformulier

-

-

-

Bijlagen - 59


Functiegroep


Functies

Behandelen zaak

Zakenmagazij n

Definitie


klant (via het proces Kanalen) en aan de interne organisatie (Behandelen Zaak). Een belangrijke rol is weggelegd voor Beheren Zaak in het bewaken van termijnen. Zaken, waarvan de termijn is verstreken, worden opnieuw aangeboden aan Behandelen Zaak. In dit proces worden Primaire Processen (of deelprocessen daarvan) afgehandeld. Na de afhandeling wordt statusinformatie teruggegeven aan Beheren Zaak. Als gevolg van de Behandeling van een Zaak moeten soms nieuwe Zaken worden gecreëerd. Hiertoe wordt een verzoek hiertoe gericht aan Beheren Zaak. Het proces Behandelen Zaak is zelf verantwoordelijk voor de beslissing of er in het geval van het starten van een nieuwe Zaak doorgegaan kan worden met de behandeling van de actuele Zaak of dat deze opgeschort moet worden. Verzoeken met opschorting worden zonodig via Beheren Zaak gerealiseerd. In het zakenmagazijn worden op centraal niveau alle relevante gegevens over een zaak opgeslagen en beschikbaar gesteld. Het gaat hierbij onder meer om informatie over de status van procedures, degene die een verzoek heeft ingediend, het organisatieonderdeel dat het verzoek behandelt en het moment van binnenkomst van de aanvraag. Een zakenmagazijn kan bestaan uit gestructureerde (records) en ongestructureerde (documenten) gegevens. In het laatste geval spreekt men ook wel van zakendossier.

Amsterdamse product

-

Procesgenerie ke functionaliteit Beheren Basisregistrati es Vastleggen dossiers Uitwisselen gegevens Sturen werkproces Geografische Informatie Digitaal archiveren

Personen, Bedrijven, Adressen, Percelen, Gebouwen, Kadaster

Oracle

GBS, VRA

Ongestructeerde data (documenten, beelden)

Documentum

Andreas

Rapporteren Management Business Intelligence

On line rapportage, schriftelijke rapporten

Sturen Projecten

Kennisdeling

Personeel

Salarisadministratie

P-net

Informatie

Helpdesk

Topdesk; Limon

Juridische zaken Organisatie

Afhandelen bezwaar en beroep; afhandelen klacht Administratieve Organisatie

KIM; Octopus; BEB MAVIM; Protos

Financiën

Financiële administratie

Exact; FIS4all; Civision;

Staffware CAD

Microstation

Management functies Crystal Reports Operational Data Store, Datawarehouse , Datamart, ETL

MS Office, Viadesk

Ondersteunen de functies

Bijlagen - 60

sql


Functiegroep


Functies

Definitie


Amsterdamse product

OneWorld; Decade Administratie Huisvesting / facilitair Processpecifi eke functionaliteit Ondersteunen werkplek Beheren werkvoorraad

Behandelen zaak / klantadministr atie

Kantoorautomatisering Wegen (gladheid); Parkeergebouwen; Monumenten; Objectbeheer; Werkbeheer verlichting; Verkeersvoorzieningen; Wegopbrekingen; Kunstwerken; Verkeerslichten; Groenvoorzieningen; Binnenwaterbeheer Leerlingadministratie; Uitkeringen; Bouwvergunningen; Milieuvergunningen; Erfpacht; Belastingen; Vergunningen; Horecavergunningen

MS Office ERP

Epovision; Planon; AMIS; OBIN; OBS; ASVV2004; SCS; KIS; VBS; BBA ERISA; NUSOP; SVIS / BWT Systeem; Stramis; EBS/ Hermez; Taxi; Systeem Horeca

Bijlagen - 61



Bijlage 13 Applicatiearchitectuur: landelijke ontwikkelingen integratievoorziening

13.1 NORA Opvallend gegeven aan alle landelijke referentie-architecturen is dat de integratie van informatiesystemen daarin een centraal thema is, dat geldt niet in de laatste plaats voor de Nederlandse Overheids Referentie Architectuur (NORA). NORA positioneert de Service Bus als centraal concept voor integratie binnen overheidslagen, tussen overheid en externe groepen en tussen overheidslagen onderling. De benadering die wordt voorgesteld, is dat bijvoorbeeld gemeenten zorgen voor een “intergemeentelijke” Servicebus, die aansluit op een landelijke Servicebus, die dan weer moet aansluiten op Europees niveau en op bijvoorbeeld het bedrijfsleven. NORA gaat wat dat betreft uit van verantwoordelijkheden op een zo laag mogelijk niveau, maar dan wel vanuit de centrale grondgedachte dat elk overheidsonderdeel opereert als deel uitmakend van een geheel overheidsfunctioneren. http://www.e-overheid.nl/atlas/referentiearchitectuur/ Voor het overige wordt NORA vooral aangeraden als zeer toegankelijke referentie voor de Amsterdamse architectuur en wordt een integrale samenvatting van het gehele document niet in dit Handboek opgenomen.

13.2 EGEM De Amsterdamse architectuur is geheel in lijn met de Midoffice referentiearchitectuur en het referentiemodel “Stelsel van Gemeentelijke Basisgegevens” van EGEM. Deze zijn tot stand gekomen met Voorhoedegemeenten, waaronder Amsterdam. Cruciaal in de Midoffice referentie-architectuur is het centraal positioneren van het Zakenmagazijn en alle functies die het gebruik van het Zakenmagazijn gestalte geven, zoals in onderstaand weergegeven afbeelding valt af te lezen. In het hoofdstuk 6 is hier bij stil gestaan. Het detailniveau aan functies rond Zaakregistraties is in dit referentiemodel een slag dieper uitgewerkt dan in dit Handboek het geval is, aangezien daarin het applicatielandschap op hoofdlijnen ingedeeld is. Dat maakt de indeling op zich niet minder relevant waar het op Zaakregistratie aan komt en vanuit dit Handboek verwijzen we dan ook graag naar de betreffende architectuur, waaraan Amsterdam ook zijn bijdrage heeft geleverd. Voor de context van dit Handboek zijn in de Amsterdamse vergelijkbare elementen herkenbare elementen als in de EGEM-referentieplaat, nl. Zaakregistratie / Zaakmagazijn; Generieke gegevens (Toegang tot registraties); Gemeentelijke Dienstenbus (Servicebus Amsterdam) en BPM (Regisseren processen).

Bijlagen - 62



Kanalen F

Gemeentelijke Dienstenbus

Generieke gegevens Klant gegevens

Zaken dossier

Assisteren en Registreren klant

Classificeren klantvraag

BPM

FO orkestratie M

Product catalogus

Zaaktype catalogus

Openbare informatie

Registreren zaak

Basisgegevens Basis registraties

Kern registraties

Beheren zaak

BO orkestratie

Behandelen zaak (Behandeldiensten) B Services

Legacy Taaksystemen

Landelijke Dienstenbus

http://www.egem.nl/

13.3 Overige programma’s Naast de genoemde NORA en EGEM, die beide programma’s zijn onder de vlag van ICTU, zijn er meer landelijke programma’s waar geprobeerd is mee rekening te houden, zoals: • Overheid.nl (landelijke taxonomie) • OSOSS (open standaarden, open source) • GBO.Overheid (landelijke overheidsservicebus) Amsterdam heeft ook aan die programma’s bijdragen geleverd daar waar nuttig en mogelijk. Tegelijkertijd moet rekening gehouden worden met een beperkt ‘absorptievermogen’ van iedere gemeente, hetgeen uiteindelijk ook voor de grootste gemeente van Nederland geldt.

Bijlagen - 63



Bijlage 14 Applicatiearchitectuur: Toegang verlenen tot basisregistraties met Paraplu en Diva

Inleiding In hoofdstuk 7 is ‘Toegang verlenen tot registraties’ één van de zes hoofdfuncties in de integratielaag van de applicatie- en infrastructuurarchitectuur. ‘Toegang verlenen tot registraties’ gaat in de eerste plaats over toegang tot de basisregistraties en kernadministraties. In deze bijlage wordt specifiek de huidige toegang tot de basisregistraties Personen en Vastgoed via Paraplu respectievelijk Diva nader toegelicht. Eerst in algemene termen en daarna per applicatie. Tot slot wordt een aantal afwegingen gegeven voor de inrichting van de gegevensmagazijnen en de keuze van berichtsoorten. Toegang tot basisregistraties en de servicebus functioneel bezien Toegang tot een basisregistratie is niet een doel op zich maar dient de processen die in het hoofdstuk 5 van dit Handboek zijn beschreven. De processen worden (her)ingericht op enerzijds het afnemen van gegevens uit de basisregistraties (uitwisselingsproces) en anderzijds het melden van geconstateerde afwijkingen tussen de administratieve en de maatschappelijke werkelijkheid (terugmeldproces). Processen worden verbonden met een registratie door gebruik te maken van berichtenverkeer. Gegevens worden opgevat als een product dat, ingepakt in een envelop, door de registratiehouder aan de afnemer wordt geleverd. Door het uitwisselen van berichten met een vooraf overeengekomen structuur en betekenis (zie Bijlage 10 over StUF), via een vooraf overeengekomen communicatieprotocol (SOAP) over een gezamenlijke infrastructuur (zie hoofdstuk 7 over Infrastructuur), voeren de applicaties van de afnemer en de registratiehouder een dialoog. Op functioneel niveau houdt dit in dat er door een afnemer (een afnemende organisatie met of zonder afnemende applicatie(s)) kennisgevingen worden ontvangen over de mutatie van een gegeven en/of dat de toestand van een gegeven wordt opgevraagd of geraadpleegd. De vraag die de applicatie van een afnemer stelt over een gegeven uit een basisregistratie wordt op synchrone of asynchrone wijze beantwoord, afhankelijk van de door de afnemer gewenste berichtsoort. De applicaties Paraplu en Diva verlenen (nu nog) toegang tot basisregistraties middels een directe koppeling met de afnemer. Als er een Amsterdamse servicebus is, kunnen ze functioneren als een onderaannemer van de servicebus voor de berichtenuitwisseling. De servicebus functioneert dan als de verbindende logische schakel. De servicebus kan tevens de faciliteit bieden om een bericht van een basisregistratiehouder naar meerdere geadresseerden

Bijlagen - 64



te verzenden (de abonnementendienst), mits wordt voldaan aan de eisen die een basisregistratie hier aan stelt. Dit is nu nog een functie die wordt aangeboden door de applicaties die de basisregistraties distribueren. De servicebus biedt een aantal kernfuncties (zie tabel 7-1) in aanvulling op de applicaties die de basisregistraties distribueren. Dit is bijvoorbeeld het geval bij het raadplegen van gegevens uit meerdere basisregistraties. Stelt de applicatie van een afnemer een samengestelde vraag aan twee of meer basisregistraties, dan kan de servicebus de beantwoording van de vraag regisseren. De servicebus kan ook een rol spelen bij het binnen de gemeente ondersteunen van meerdere versies van de StUF standaard en de daarbij gehanteerde sectormodellen. StUF gaat meer invulling geven aan service oriëntatie, waarna Paraplu en Diva services kunnen aanbieden met betrekking tot de toegang tot basisregistraties, die de servicebus kan bekend maken en beheren. Paraplu en Diva DPG en GVI hebben in 2004 besloten eigen distributievoorzieningen te ontwikkelen met de ontwikkelstappen: een koppeling van Diva naar Paraplu voor de levering van adresgegevens, en, uitgaande van de beschikbaarheid van een Amsterdamse servicebus, levering aan afnemers via een servicebus. Verschillen in inhoud (gegevenssoort en -structuur), regime (weten regelgeving voor privacy en beveiliging), functionaliteit (distributie van Geometrie en Topografie vereist specifieke functionaliteit) en aan te sluiten applicaties bij de afnemers hebben geleid tot de beslissing aparte distributiesystemen te ontwikkelen. De berichten en hun verzending voldoen aan de StUF-standaard. DPG en GVI hebben aanvullende afspraken gemaakt en gedocumenteerd over de aansluitspecificaties van de uitwisseling van administratieve basisgegevens die buiten de StUF-documentatie vallen. Paraplu DPG is verantwoordelijk voor het beheer en de distributie van de Basisregistratie Personen. DPG distribueert de persoonsgegevens met Paraplu. Paraplu is de implementatie bij DPG van CiVision Gegevensmakelaar van Getronics PinkRoccade. Kennisgevingen en Vraag / Antwoord distributie vindt plaats door middel van op StUF en Webservice standaarden gebaseerde automatische koppelingen. Paraplu ondersteunt alle mogelijke interactieprocessen die StUF02.04 definieert. Paraplu biedt ook enkele aanvullingen op de StUF02.04 standaard. De berichtsoorten worden in onderstaande figuur weergegeven. Het doel van deze figuur is niet om de berichtsoorten in onderlinge samenhang te laten zien.

Bijlagen - 65



Bron: DPG naar GPR Berichten van en naar Paraplu. Paraplu beschikt over een eigen gegevensmagazijn. Het gegevensmagazijn bevat alle basisgegevens voor Personen inclusief hun historie. De inschrijfgegevens van Personen worden er gekoppeld aan de Vastgoedgegevens die worden beheerd door GVI. Hierdoor is het mogelijk voor een afnemer om kennisgevingen te krijgen over de relaties tussen persoon en adres, en de toestand van de relaties tussen persoon en adres raadplegen. Paraplu handelt het raadplegen van gegevens middels een browser (‘Baliescherm’) af via een interne oplossing. Paraplu handelt het door een applicatie opvragen van gegevens af via een (synchrone of asynchrone) vraag/antwoord webservice. Paraplu geeft correcties en wijzigingen door in de vorm van verplicht over te nemen of informatieve kennisgevingberichten. Paraplu biedt voor het afhandelen van distributieregels voor persoonsgegevens een fijnmazig mechanisme waarbij lever-, afnemer- en raadpleegregels worden ingesteld. Diva GVI is verantwoordelijk voor het beheer en de distributie van vier basisregistraties: • De basisregistratie adressen Bijlagen - 66



• De basisregistratie gebouwen • De basisregistratie percelen (afkomstig van het Kadaster) • De basisregistratie topografie (kleinschalig en grootschalig) Daarnaast heeft GVI ook aanvullende gegevensverzamelingen zoals luchtfoto’s en cyclorama’s. Deze gegevens worden op verschillende manieren aan afnemers geleverd door middel van het distributiesysteem Diva: Distributie Vastgoed Amsterdam.

Externe applicaties

Atlas

Afnemers

Webservices Kennisgevingen

Vraag / antwoord

Leveringen

Magazijn Bron: Diva (GVI) In de distributielaag worden drie manieren van distributie gehanteerd: 1. Kennisgevingen: GVI stuurt mutatiemeldingen naar afnemers die deze verwerken in hun eigen gegevensbestanden. 2. Vraag/antwoord: een extern systeem vraagt op het moment dat het nodig is, gegevens op uit het magazijn en krijgt direct antwoord terug. 3. Levering van bestanden: verschillende media (CD-rom, FTP, gedrukte kaarten etc). Kennisgevingen en Vraag / Antwoord distributie vindt plaats door middel van op StUF en Webservice standaarden gebaseerde automatische koppelingen. GVI heeft in eerste instantie kennisgevingen ontwikkeld. Afwegingen bij de keuze van berichtsoorten De technologie van de applicaties die de basisregistraties distribueren is nieuw en complex, maar dat speelt geen rol bij de keuze voor de berichtsoorten kennisgeving en/of vraag/antwoord. Als een afnemer kennisgevingberichten ontvangt, wil de afnemer kunnen beschikken over een kopie van (een doelgebonden subset van) de gegevens uit de basisregistratie. Is er alleen sprake van raadpleging, dan is er veelal geen kopie van de gegevens uit de basisregistratie. Vanuit juridisch oogpunt is voor de basisregistraties een architectuur ideaal waarin een afnemer alleen maar de identificatie hoeft te registreren van personen en andere objecten in de basisregistraties en de werkprocessen gegarandeerd de authentieke gegevens uit de basisregistraties gebruiken. Bijvoorbeeld voor de Basisregistratie Personen één centrale database met persoonsgegevens en decentraal alleen de Burger Service Nummers. Juridisch ligt een kopie van (een doelgebonden subset van) de gegevens uit de basisregistratie moeilijk, want het is niet gegarandeerd dat werkprocessen de waarde uit de basisregistratie gebruiken. Binnen werkprocessen waar het

Bijlagen - 67



onacceptabel is dat de opslag van gegevens met vertraging de basisregistratie volgt, zouden de gegevens altijd opgehaald moeten worden uit de basisregistratie. Functioneel kan het verstandig zijn om basisgegevens voorlopig decentraal binnen werkprocesapplicaties vast te leggen. Anders gezegd: functioneel kunnen er redenen zijn waarom basisgegevens buiten de basisregistratie worden vastgelegd. Is de responstijd en de infrastructuur bijvoorbeeld voldoende voor de uitvoering van grote batchverwerkingen als het opleggen van belastingaanslagen? Hoe maak je rapportages waarbij centraal opgeslagen basisgegevens gecombineerd worden met bij de afnemer zelf opgeslagen (additionele) gegevens? Wanneer meer gegevens dan alleen de authentieke gegevens nodig zijn, dan dient ook een interne database geraadpleegd te worden. In plaats van twee verzoeken te doen, is het dan wel zo handig om ook de basisgegevens op te halen uit een eigen database. Dit totdat ook additionele gegevens worden gedistribueerd binnen de gemeente (met afspraken over kwaliteit, eigenaarschap et cetera). Functioneel kunnen er redenen zijn waarom geconstateerde afwijkingen buiten de basisregistratie worden geadministreerd. Voor de gemeente is het van belang zo snel mogelijk op de hoogte te zijn van de werkelijke situatie. Dit gaat het eenvoudigste als organisaties die het eerste geïnformeerd worden, de geconstateerde afwijkingen zelf administreren en vervolgens geautomatiseerd terugmelden naar de basisregistratie. Het is vervolgens aan de basisregistratie om gezaghebbend en met de nodige waarborgen omkleed vast te stellen dat de gegevens zijn gewijzigd en om daarna de op die gegevens geabonneerde afnemers hiervan op de hoogte te stellen. Praktische overwegingen bepalen welke basisgegevens en welke werkprocessen in aanmerking komen om voorlopig decentraal vast te leggen en in een aantal gevallen geconstateerde afwijkingen te administreren. Vervolgens dient dit ook juridisch afgedekt te worden. Wanneer een afnemer zelf basisgegevens (en daaruit afgeleide gegevens) blijft vastleggen, stelt de wetgeving voor persoonsgegevens een aantal eisen. Er zijn beveiligingseisen vastgelegd in de informatiebeveiligingsprotocollen Basisregistratie Personen. Deze zouden ook moeten gelden voor de kernadministraties waar persoonsgegevens worden gebruikt.

Bijlagen - 68



Bijlage 15 Applicatiearchitectuur: Gemeenschappelijkheid

Uitgangspunt is dat functies die een generieke kenmerken vertonen, een kans bieden voor gemeenschappelijke ontwikkeling en beheer 60. Of die kans ook daadwerkelijk wordt benut, hangt mede samen met organisatorische randvoorwaarden waarop aan het eind van deze bijlage wordt teruggekomen. Er kan onderscheid gemaakt worden tussen functies met zwakke generieke kenmerken, omdat de verbinding met een bepaald bedrijfsproces nog aanwezig is, en sterk generieke kenmerken, omdat ze in allerlei bedrijfsprocessen voorkomen en allerlei typen gebruik kennen. Van het eerste is sprake bij de procesgenerieke functies. Deze functies komen dus bij meerdere processen voor en zijn tot op bepaalde hoogte te isoleren van de overige functies, maar in de praktijk betekent dat wel een verandering die op technisch niveau in de applicaties doorwerkt: meerdere (standaard of maatwerk) oplossingen moeten dan te combineren zijn tot één geheel. Aan die randvoorwaarde wordt met de huidige software in Amsterdam lang niet altijd voldaan. In het geval van nieuwe inrichtingen zijn daarvoor grotere mogelijkheden aanwezig. Software met een infrastructureel karakter, zoals kantoorautomatisering of een personeelssysteem zijn evident van zeer generiek karakter en zijn om die reden in Amsterdam dan in gemeenschappelijk beheer ondergebracht en in verregaande mate gestandaardiseerd. In onderstaand diagram wordt die geleidelijke schaal getoond: Categorieën van ICT-functionaliteit Gemeenschappelijke functies

Algemene, infrastructurele functies Integratiefuncties Presentatiefuncties Functies voor secundaire bedrijfsprocessen Procesgenerieke ict-functies inclusief management en ondersteuning

Specifieke functies

Processpecifieke functies voor primaire bedrijfsprocessen Unieke functies

Zoals gezegd gaat het om een geleidelijke schaal: • De scheiding tussen procesgenerieke toepassingen en processpecifieke applicaties is in zekere zin willekeurig en hangt nauw samen met marktontwikkelingen. Functies als workflowmanagement, document management en integratie vormen vrijwel altijd een integraal onderdeel 60

Aan de hand van het inventariserend vooronderzoek naar tranche-2 SSC ICT van het gehele gemeentebrede applicatielandschap kan worden geverifieerd of dit model alles afdekt en voldoende handvatten biedt.

Bijlagen - 69



•

van primaire procesapplicaties. Om diverse redenen worden deze uit de specifieke oplossingen “uitgetild” en op een generieke wijze opgelost in een nieuw systeem, zo ontstaan workflow management systemen, document management systemen en integratievoorzieningen. Deze ontwikkeling zal zwaar doorzetten onder invloed van een servicegerichte architectuur, waarbij uiteindelijk een groot deel van de software “generiek” van opzet is. De scheiding tussen infrastructuur en applicaties verschuift met de loop der jaren. Functies die oorspronkelijk deel uitmaken van processpecifieke systemen en die gericht zijn op datacommunicatie en dataopslag, worden generiek van aard en verschuiven naar de infrastructuur.

Vertaald naar het applicatielandschap, zouden de clusters Presentatie, Integratie en Generieke functies de functies weergeven met een generiek kenmerk. In architectuurtermen, hebben generieke functies de mogelijkheid in zich gemeenschappelijk te worden ontwikkeld en beheerd.

Bijlagen - 70



Bijlage 16 Applicatiearchitectuur: Standaard inrichting en ontwikkeling

Standaard ontwikkelplatform Amsterdam spreekt de voorkeur uit voor de twee meest gangbare ontwikkelplatforms van dit moment: 1. Java 2 Enterprise Edition (J2EE) 2. .Net De voordelen zijn dat deze platforms beide een serie standaarden omvatten, ondermeer ter bevordering van informatiebeveiliging, integratie. Door de algemene beschikbaarheid van de standaarden en een grote keuze aan leveranciers die in een van beide of allebei de platforms kan leveren, vermindert de leveranciersafhankelijkheid. Standaarden per applicatie N-Tier (N>3) Elke applicatiesysteem dat door BRI wordt vernieuwd of vervangen, bestaat uit minstens drie lagen: Presentatie, Applicatie en Gegevens. De belangrijkste hoofdlijnen van het standaardisatiebeleid zijn in bijgaand overzicht samengevat, de genoemde producten per laag zijn voorbeelden:

Dataopslagfunctie De dataopslagfunctie heeft betrekking op de opslag van gegevens in een database. Gewoonlijk gaat het om gestructureerde data, maar bij gebruik van een document managementsysteem kunnen ook ongestructureerde data (documenten, emailberichten) in een database zijn opgeslagen. Bewerkingfunctie De bewerkingfunctie (business-logic functie) heeft betrekking op het ophalen, bewerken en opslaan van databasegegevens volgens procesafhankelijke regels.

Bijlagen - 71



Presentatiefunctie De presentatiefunctie heeft betrekking op tonen van gegevens aan- en invoeren van gegevens door een eindgebruiker. Authenticatiefunctie De meeste applicaties kennen een eigen authenticatiefunctie. Aan de hand van een applicatie-eigen userdatabase of –directory, waarin usernamen+wachtwoorden zijn opgeslagen, wordt de identiteit van de gebruiker van de applicatie geverifieerd. De authenticatiefunctie is een oneigenlijke applicatiefunctie. Bij voorkeur vindt authenticatie van gebruikers buiten de applicatie plaats, aan de hand van gegevens in een applicatie-onafhankelijke directory. Autorisatiefunctie De meeste applicaties kennen een eigen autorisatiefunctie. In een applicatieeigen (user)database of –directory zijn applicatie-autorisaties zijn opgeslagen. In de meeste gevallen wordt hierbij gebruik gemaakt van taakgerichte autorisatieprofielen. Door een medewerker aan een autorisatieprofiel te associeren worden voor de betreffende medewerker rechten ingesteld voor het opvragen, bewerken en opslaan van (bepaalde) gegevens. Het associëren van medewerkers aan een autorisatierol is een oneigenlijke applicatiefunctie. Bij voorkeur vindt associatie van medewerkers aan een autorisatieprofiel buiten de applicatie plaats, aan de hand van gegevens in een applicatie-onafhankelijke directory. Ontwikkelstandaarden samengevat Onderdeel Ontwikkelomgeving Presentatielaag

Standaard J2EE .Net HTML

Beheerorganisatie Sun? Microsoft

Applicatielaag Gegevensopslag en uitwisseling Document opslag en uitwisseling

Bijlagen - 72

XML ODF

OASIS



Bijlage 17 Integratiearchitectuur: Berichtenuitwisseling

In deze bijlage worden berichtuitwisselingsfuncties, zoals die in een berichtenof servicebus kunnen voorkomen, in meer detail toegelicht, inclusief een schematische weergave. Een deel van de teksten is afkomstig uit bijlage 16 (over service- en berichtenbussen) van de NORA-architectuur, versie 0.8 d.d. 31 maart 2006. Service- en berichtenbussen zijn een essentieel onderdeel bij de afhandeling van service- en berichtenverkeer. Bussen bieden meer of minder intelligente koppelfuncties tussen 2 of meer applicaties, respectievelijk in een vragende en een afhandelende rol. Zij zijn daarmee de verbindende logische schakel tussen bouwstenen in een gegevens-, proces- of service-gerichte architectuur. Bij een bus vormen de aangesloten bouwstenen een gemeenschap. De bus is de communicatieruggengraat van de gemeenschap. Wie zich aansluit is verbonden met alle andere aangesloten bouwstenen. Veel aansluitkosten zijn daarmee eenmalig en hoeven niet voor elke nieuwe communicatiepartner opnieuw te worden gemaakt. Iedere bus bevat één of meerdere koppelfuncties. Daarbij bestaan arme en rijke varianten, met een breed spectrum daartussen. Rijke bussen bieden veel koppelfuncties, zodat de aangesloten bouwstenen ze niet zelf hoeven uit te voeren. Daarmee worden de bouwstenen onderling onafhankelijker en de aansluitdrempel lager. Wel wordt de afhankelijkheid van de bus groter. In armere varianten worden nog veel koppelfuncties door de bouwstenen uitgevoerd en liggen de voor- en nadelen omgekeerd. We verdelen de mogelijke functies van een bus in twee groepen. Elke bus steunt op functies voor berichtenverkeer. In rijkere varianten kent een bus ook servicefuncties. Een bus met alleen berichtenfuncties noemen we een berichtenbus. Een bus met aanvullende servicefuncties noemen we een servicebus. De bouwstenen en de bus zijn verbonden via een netwerk. De bus is dus geen netwerk, maar ligt daarbovenop. Het netwerk regelt het pure transport, in een beveiligde omgeving, met een hoge beschikbaarheid en een goede performance. Uitwisselen berichten (basis berichtenfuncties) Adapters (connectoren) Vaak is het zo dat bouwstenen verschillende netwerkprotocollen willen gebruiken. In dat geval kan de bus deze heterogeniteit overbruggen door zelf aparte adapters (connectoren) te gebruiken voor verschillende protocollen en ze intern te vertalen. Logging Bussen zullen vaak het verkeer over de bus registreren, bijvoorbeeld voor reconstructie in geval van fouten, analyses en managementinformatie en onderbouwing in geval van misverstanden of conflicten (onherroepelijkheid). Beveiliging Bussen zijn generieke voorzieningen voor elektronisch verkeer. Dergelijk verkeer is vaak beveiligings- en privacygevoelig, zowel de uitwisseling als de Bijlagen - 73



logging. Voorzieningen voor beveiliging tegen oneigenlijk gebruik van berichten en de gegevens daarbinnen zijn dus noodzakelijk. Routering / Store & forward Om te voorkomen dat de bouwstenen alleen kunnen communiceren als daar beide tijd voor hebben, bieden bussen tussentijdse opslag van berichten (wachtrijen of “in- en outboxen”), net als bij e-mail. Ook verzorgen ze, op basis van een adressensystematiek, het transport tussen die out- en inboxen. De adresseringssystematiek en logistiek kan complex zijn, vooral als het bericht via tussenstappen getransporteerd wordt. Abonnementendienst (Publish/subscribe) Om te voorkomen dat de ene bouwsteen steeds moet polsen of er bij een andere bouwsteen iets gebeurd is, bieden veel bussen functies waarmee een bouwsteen zich op een gebeurtenis bij een andere bouwsteen kan abonneren. Elke keer dat die gebeurtenis optreedt, wordt de abonnementhouder volgens afspraak geïnformeerd. Berichttransformatie In het geval dat verzender en ontvanger verschillende wensen hebben ten aanzien van de berichtstructuur, kunnen zij de bus vragen het bericht te vertalen van het verzenderformaat naar het ontvangerformaat. Berichtvalidatie Vaak maken afspraken over berichtenstructuur en inhoud deel uit van de communicatieafspraken tussen bouwstenen. De bouwstenen kunnen van de bus vragen om te valideren of verzonden berichten conform deze afspraken zijn en, als ze dat niet zijn, het bericht te onderscheppen. Daarbij kan het gaan om de structuur van het bericht, maar ook over de geldigheid van de inhoud (bijvoorbeeld: weiger 30 februari als datum). Zo ontvangt de geadresseerde geen foute berichten. Berichtaggregatie De ontvanger kan de bus vragen om meerdere naar hem verzonden berichten als één bericht door te sturen. Mochten er servicefuncties in de bus zitten, kan dit als een speciaal geval van orkestratie worden gezien. Schematische weergave In onderstaande weergave worden de verschillende berichtenuitwisselingsfuncties in hun samenhang weergegeven. De aanvullende servicebus-hoofdfuncties, die ook in het schema zijn opgenomen, worden in paragrafen 7.3 en 8.3 van het handboek nader toegelicht en in Bijlage 12 in detail beschreven.

Bijlagen - 74


serviceverlening Regisseren processen

Toegang tot registraties

afspraken

Authenticeren & autoriseren Beheren services

Abonnementen dienst

services

Bericht transformatie

Bericht validatie

vragende applicatie

Registreren zaken

leverende applicatie


Beveiliging

Wachtrij / routering adapter

netwerk

Berichten uitwisseling berichtenbus

adapter

netwerk (ontleend aan EGEM)

Bijlagen - 75



Bijlage 18 Architectuurorganisatie: Omschrijving architectenrol

In deze bijlage zijn vooreeld funtiebeschrijvingen opgenomen van de functionele en technische architectenrol.

Omschrijving

Bijbehorende functie Taken

Vereisten

Omschrijving

Bijbehorende functie Taken

Bijlagen - 76

Functioneel architecten rol De functioneel architect heeft een brede kennis en ervaring op het gebied van de gemeentelijke organisatie, de producten en diensten van de gemeente en de bijbehorende processen, informatievoorziening en functionaliteit van applicaties. Met deze ervaring is de architect in staat de behoeften van de organisatie en de ondersteuning van ICT beter op elkaar af te stemmen. De architect weet daarnaast wat er speelt in de organisatie en kan met deze kennis geplande en lopende projecten beter (inhoudelijk) op elkaar afstemmen en prioriteren Senior adviseur middelen • Stelt de functionele architectuur op en onderhoudt deze • Verstrekt advies aan de opdrachtgever van een project met betrekking tot het rendement , de kosten en de haalbaarheid van het project en de positionering van het project in het geheel aan de hand van de architectuur • Stelt de projectarchitectuur op • Controleert de toepassing van architectuur richtlijnen en afspraken gedurende realisatie van het project • Is op de hoogte van ontwikkelingen in de omgeving (politiek, trends) • Brede kennis en ervaring op het gebied van de diensten van de provincie en de daarbij behorende processen, informatievoorziening, functionaliteit van applicaties • Uitstekende communicatieve vaardigheden • Beeldvormend, kan gemakkelijk een oplossing schetsen • Heeft gezag en is een inspirator • Kan omgaan met verschillende belangen en belangenconflicten • Kan belanghebbenden op het juiste moment inschakelen en betrekken • Kiest bewust positie in verschillende situaties Technisch Architect De technisch architect heeft een brede kennis en ervaring op het gebied van systemen, systeemsoftware, netwerken , beveiliging en technische standaarden. Met deze ervaring is de technisch architect in staat snel inzicht te bieden in de maak – en haalbaarheid van een projectvoorstel. De technisch architect bewaakt eveneens de samenhang en koppelingen tussen de verschillende systemen. In het geval van uitbesteding aan een leverancier zorgt de technisch architect voor het uniform (technisch) ontwerp en gebruik van (documentatie)standaarden zodat het beheer van systemen overzichtelijk blijft (Senior) adviseur middelen • Stelt de technische architectuur op en onderhoudt deze



• • •

Vereisten

• • • • • •

Ondersteunt de functioneel architect bij de oriëntatiefase en voorbereidingsfase van het project met betrekking tot de maak – en haalbaarheid daarvan Controleert de toepassing van architectuur standaarden gedurende de realisatiefase van het project Ontwikkelt documentatie en –ontwerpstandaarden voor gebruik bij systeemontwikkeling Is op de hoogte van technische ontwikkelingen brede kennis en ervaring op het gebied van systemen, systeemsoftware, netwerken , beveiliging en technische standaarden Goede analytische vaardigheden In staat om overzicht en samenhang te bewaken én op de hoogte van technische details daar waar nodig Uitstekende communicatieve vaardigheden Overtuigend

Bijlagen - 77



Bijlage 19 Architectuurorganisatie: Rol architect in projecten

In deze bijlage wordt kort beschreven wat de rol van de architect is binnen de verschillende projectfasen. Ontwikkelproces Fasering/stappen Oriëntatiefase

Lijnmanager

Voorbereidingsfase

Beslissen over project initatief

Opstellen startnotitie

Realisatiefase

Overgangsfase

Resources ter beschikking stellen

Vaststellen Project opdracht

Vaststellen projectplan

Vaststellen eindresultaat

Opstellen Overdrachts document

Borgen project resultaat

Opdrachtgever

Maken projectopdracht

Organiseren Project Start Up

Projectleider

Advisering

Maken projectplan

Voortgangs bewaking

Opleveren Project resultaat

Maken Project architectuur

Controleren projectresultaat

Advisering nazorg en correctie

Architect

Legenda

Activiteit volgens PMW

Nieuwe activiteit

Oriëntatiefase De architect speelt in de oriëntatiefase een belangrijke rol door de opdrachtgever (of gedelegeerd de projectleider) te adviseren over de positie die het project inneemt ten aanzien van andere lopende of nog te starten projecten. Ook kan de architect de opdrachtgever inzicht verschaffen in hetgeen reeds aanwezig is en hetgeen nog aangeschaft en geïmplementeerd moet worden. De architect levert op die manier een belangrijke bijdrage aan de projectopdracht en kan aangeven of het project rendabel is of niet. Voorbereidingfase In deze fase speelt de architect een belangrijke rol bij het opstellen van de projectarchitectuur. De projectarchitectuur bakent de scope voor het project af en geeft aan welke architectuur richtlijnen, normen en standaarden die van toepassing zijn op het project. Als een domeinarchitectuur beschikbaar is, dan gebruik de architect die als bron voor de afbakening. Ook geeft de projectarchitectuur aan voor het project of en op welke onderdelen er niet met de architectuur gewerkt wordt. Onder speciale omstandigheden, bijvoorbeeld als zich een extreem urgente situatie voordoet en de tijd beperkt is, kan er namelijk bewust een afwijkende oplossing gekozen worden. Bepaalde aspecten van de architectuur worden dan tijdelijk genegeerd op een gecontroleerde manier. Hetgeen is afgesproken in de

Bijlagen - 78



projectarchitectuur wordt door de projectleider nageleefd. In het plan van aanpak houdt de projectleider rekening met alle activiteiten die voortkomen uit de projectarchitectuur. Realisatiefase De architect controleert gedurende de realisatie aan de hand van de voortgangsrapportage én door middel van gesprekken met de projectuitvoerenden (proces / functioneel / technisch ontwerpers) of het project nog voldoet aan de afspraken van de projectarchitectuur. Overgangfase Tijdens de evaluatie van het project(verloop) komen ook de architectuur en de architectuurwerkzaamheden aan de orde.

Bijlagen - 79

Colofon. Oplage: 250 exemplaren

Recommend Documents