Hand Boe K Architect U Ur Amsterdam

Colofon
Dit handboek is door de Adviesgroep Architectuur opgesteld. Aan het

handboek is door de volgende mensen meegewerkt (in alfabetische
volgorde):
Arris Oliemans (DAB/GVI) Kees Duits (SHI)
Cees Wiering (SHI) Loren Kruseman (Ordina)
Dick Grasboer (OGA) Mohamed Abalhaj (SHI)
Dries Bartelink (BDA/CO) Marijke Oosterbroek (FBA)
Erik Fray (Stadsdeel Noord) Menno Gmelig Meijling (SHI)
Frans Smit (GAA) Monique Jelmorini (DBGA)
Fred Haverkamp (DAB) Peter van Bosheide (DMO)
Geert Wind (BDA/CO) Peter van Leeuwen (BDA/BMO)
Gertjan Kock (DBGA) Platform Informatiebeveiliging
Hans Bosma (Ordina) Raymond van Erkel (DPG)
Hans Eggels (DWI) Rigina Christiaans (IBA)
Jan Leuven (SHI) Robert Jan Prenger (DMO)
Jeroen de Vries (Stadsdeel de Ron Blankers (SHI)
Baarsjes) Siepie Ebbes (DWI)
Jorden Spijker (Stadsdeel Osdorp) Stan Oei (Stadsdeel Centrum)
Josine van der Voort (DPG) Willem Schoonbeek (BDA/CO)
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: wschoonbeek@bda.amsterdam
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 achtergrond-
document 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 informatie-
voorziening 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 organisatie- en
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 beoordelings-
of 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 informatie-
laag 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;
• 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 her-

ontwerp 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.
de inrichting 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
de belangrijkste processen? hebben we daarvoor de kennis en de

menskracht in huis?
• wie wordt verantwoordelijk voor de besturing van ketenprocessen?
laag 3: informatie 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” internet-
aansluitingen 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?
Definitief Bestuursdienst
Inhoudsopgave
1 Inleiding...........................................................................................................................................1
1.1 Aanleiding.........................................................................................................................................1
1.2 Waarvoor dient de architectuur? ......................................................................................................2
1.3 Hoe kunt u dit Handboek gebruiken?...............................................................................................3
1.4 Leeswijzer.........................................................................................................................................4
2 De Amsterdamse visie op architectuur........................................................................................1

2.1 Van ongeduld naar actie door samenwerking en architectuur ........................................................1
2.2 Vertaling programma- en bestuursakkoord......................................................................................2
2.3 Balans nodig tussen snelheid en samenhang..................................................................................3
2.4 De gefaseerde ontwikkeling van onze architectuur .........................................................................4
2.5 De reikwijdte van het Handboek Architectuur ..................................................................................5
2.6 Het Amsterdamse architectuurraamwerk.........................................................................................6
3 Grondslagen ...................................................................................................................................1
3.1 Inleiding ............................................................................................................................................1
3.2 Algemene grondslagen ....................................................................................................................1
3.3 Grondslagen organisatiearchitectuur ...............................................................................................1
3.4 Grondslagen procesarchitectuur ......................................................................................................2
3.5 Grondslagen informatiearchitectuur .................................................................................................2
3.6 Grondslagen applicatiearchitectuur..................................................................................................2
3.7 Grondslagen infrastructuurarchitectuur............................................................................................2
4 Organisatiearchitectuur.................................................................................................................1
4.1 Inleiding ............................................................................................................................................1
4.2 Grondslagen ...................................................................................................................................13
4.3 Modellen .........................................................................................................................................14
4.4 Standaarden ...................................................................................................................................25
4.5 Beheer ............................................................................................................................................27
4.6 Beveiliging ......................................................................................................................................29
4.7 Conclusies ......................................................................................................................................30
5 Procesarchitectuur.........................................................................................................................1
5.1 Inleiding ............................................................................................................................................1
5.2 Grondslagen ...................................................................................................................................11
5.3 Modellen .........................................................................................................................................12
5.4 Standaarden ...................................................................................................................................15
5.5 Beheer ............................................................................................................................................17
5.6 Beveiliging ......................................................................................................................................18
5.7 Conclusies ......................................................................................................................................19
6 Informatiearchitectuur ...................................................................................................................1
6.1 Inleiding ............................................................................................................................................1
6.2 Grondslagen .....................................................................................................................................4
6.3 Modellen ...........................................................................................................................................5
6.4 Standaarden ...................................................................................................................................16
6.5 Beheer ............................................................................................................................................18
6.6 Beveiliging ......................................................................................................................................19
6.7 Conclusies ......................................................................................................................................21
7 Applicatiearchitectuur ...................................................................................................................1
7.1 Inleiding ............................................................................................................................................1
7.2 Grondslagen .....................................................................................................................................4
7.3 Modellen ...........................................................................................................................................5
7.4 Standaarden ...................................................................................................................................22
7.5 Beheer ............................................................................................................................................26
7.6 Beveiliging ......................................................................................................................................29
7.7 Conclusies ......................................................................................................................................30
8 Infrastructuurarchitectuur .............................................................................................................1
8.1 Inleiding ............................................................................................................................................1
8.2 Grondslagen .....................................................................................................................................4
8.3 Modellen ...........................................................................................................................................5
8.4 Standaarden ...................................................................................................................................17
8.5 Beheer ............................................................................................................................................19
8.6 Beveiliging ......................................................................................................................................20
8.7 Conclusies ......................................................................................................................................22
9 Architectuurorganisatie en -proces .............................................................................................1

9.1 Inleiding ............................................................................................................................................1
9.2 Architectuurorganisatie.....................................................................................................................1
9.3 Architectuurproces ...........................................................................................................................6
9.4 Standaarden ...................................................................................................................................13
9.5 Beheer ............................................................................................................................................14
9.6 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 2. Stroomlijning van werkprocessen
werkprocessen De logica van de organisatie is niet langer dominant. De burger aan het
stuur vraagt om stroomlijning en (soms) herontwerp van processen.
3) delen van informatie en 3. Het delen van informatie en ICT-middelen
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.
veel initiatieven gestart: Binnen Amsterdam zijn we hard op weg om dit tot een succes te maken. De
van ongeduld naar actie 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.
roep om samenhang: Nu de Andere Overheid binnen Amsterdam meer en meer realiteit begint te
architectuur 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 ICT-
infrastructuur om te komen tot een architectuur voor het concern Amsterdam.
Het vormt tegelijk ook één van de pijlers van het Meerjarenplan
Informatiemanagement.
1.2 Waarvoor dient de architectuur?
bestemmingsplan voor Een architectuur geeft op hoofdlijnen weer hoe de verschillende componenten
toekomstige organisatie en initiatieven in de organisatie en de informatievoorziening in elkaar grijpen,
en informatievoorziening 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.
architectuur bevat Dit klinkt allemaal nog abstract. Wat vinden we concreet in dat
grondslagen, modellen, ‘bestemmingsplan’? Om het simpel te zeggen bevat dit handboek
standaarden, beheer en 1 richtinggevende en kaderstellende uitspraken (grondslagen)
beveiliging 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 Hoe kunt u dit Handboek gebruiken?
doelgroep: professionals Dit handboek is geschreven voor iedereen die professioneel betrokken is bij de
rond Andere Overheid vormgeving van de Andere Overheid. Denk daarbij aan het top- en
middenmanagement, procesvernieuwers, projectleiders, architecten,
systeemontwikkelaars en ICT-beheerders.
doelen 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
en begrijpelijke taal 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.
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
2 De Amsterdamse visie op
architectuur
2.1 Van ongeduld naar actie door samenwerking en

architectuur 3
de noodzaak 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 In de visie van Amsterdam kan dit in onze stad alleen succesvol gebeuren
concern 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
architectuur als Om deze samenwerking te ondersteunen is inzicht in de samenhang nodig,

noodzakelijke voorwaarde 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
Beleidsvisie
INFORMATIE
Afstemming met bedrijfsbeleid
BELEID Bedrijfsmodel
richten
Globaal bedrijfsinformatiemodel
Beleidsrealisatierichtlijnen
INFORMATIE- Model van informatievoorziening

Architectuurplannen
ARCHITECTUUR
inrichten
Lange-termijnplan
Middellange-termijnplan
INFORMATIE- Korte-termijnplannen
PLANNING
Systeemontwikkeling of –aanschaf uitvoeren

gebruik, exploitatie en onderhoud
UITVOERING
Bron: Meerjarenplan Informatiemanagement
informatiebeleidsplan, De vertaling van het programma- en bestuursakkoord en de betekenis voor de

architectuur en planning 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
ontwikkelaars met samenhang vergt reflectie op het functioneren van de organisatie en de
oogkleppen 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.
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 Zowel snelheid als samenhang zijn essentieel voor een efficiënte en effectieve
vindt balans tussen inzet van ICT en beide worden ook steeds belangrijker. Slaat de balans door
snelheid en samenhang 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 De gefaseerde ontwikkeling van onze architectuur
‘bescheiden’ instrument: Architectuur is in de Amsterdamse visie een middel om de juiste balans te

een eerste stap 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 De nadruk van deze eerste versie ligt op het faciliteren en stimuleren van
samenwerking en BRI 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.
toetskader voor nieuwe Het handboek is bedoelt als toetskader en richtlijn voor nieuwe ontwikkelingen,
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.
2-4
ontwikkeling: meeliften De Amsterdamse architectuur is verder geen statisch product. De architectuur

met belangrijke zal continue aan verandering onderhevig zijn; het is nooit ‘af’. Dat zou ook niet
verandertrajecten 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.
ontwikkeling: investeren in Met deze eerste versie van de architectuur zetten we een belangrijke eerste
en inbedden van werken stap. Tegelijkertijd zal dit een nutteloze stap blijken als we niet zorgdragen
onder architectuur 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 1. De architectuur beschrijft de gewenste situatie van onze organisatie-
2011 en 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.
niet alleen ICT 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.
alleen 3. De architectuur beperkt zich tot gemeenschappelijke voorzieningen
gemeenschappelijke De architectuur bevat alleen grondslagen, modellen en standaarden voor de
voorzieningen en gemeenschappelijke organisatie en informatievoorziening binnen het concern
koppelvlakken 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
5
Er is een klein aantal uitzonderingen in Hoofdstuk 8 . Deze zijn expliciet benoemd in de tekst.
2-5
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.
Niet volledig 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 Het Amsterdamse architectuurraamwerk
standaard voor In Amsterdam kennen we een standaard voor het opbouwen en beschrijven van
beschrijven architectuur 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-, mid- en 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 ICT-
standaardisatie 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 ICT-
standaarden 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 ICT-
variaties 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
3 Grondslagen
3.1 Inleiding
richtinggevende Grondslagen (ook wel ‘principes’ genoemd) zijn richtinggevende en

uitspraken 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.
16 belangrijkste Er zijn wel honderden grondslagen te verzinnen. We hebben ervoor gekozen

grondslagen 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 17-
opgesomd. In Bijlage 4 worden de grondslagen nog verder toegelicht, met de
reden waarom en de implicaties.
Selectie argumenten 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 Grondslagen infrastructuurarchitectuur
grondslag 5.1 De infrastructuur is schaalbaar, betrouwbaar en gebaseerd op open

standaarden.
3-2
4 Organisatiearchitectuur
4.1 Inleiding
principes Op deze laag gaat het over de bestuurlijke en organisatorische uitgangs-

punten, 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, informatie-
verstrekking, gegevensverwerking);
• producten (materiële zaken, roerende en onroerende goederen, gebruiks-
en 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 Architectuur van de organisatie
de architectuur 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
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”.
plan van aanpak 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 profit-
bedrijven 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 HRM-
functie.
De hierboven geschetste principes kunnen worden aangevuld met een

dienstverlenings- of marketingconcept. Daarin is naast afspraken over
serviceniveaus en klantbejegening, de stijl van Amsterdam, opleidings-
vereisten 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 non-
profit, 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

die onderling en met haar omgeving nauw samenwerken om resultaten te
boeken.

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 De omgeving van de gemeente
landelijk 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 Burger@Overheid.nl 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, e-
mail, 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: Burger@Overheid.nl (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 één-
loketgedachte 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
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 ICT-
aangelegenheden. 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 regie-

functie op de ICT
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 De veranderingsorganisatie
programmasturing 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-,
mid- en 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.

gemeente na één-loket en
multichannel
[Bron: EGEM]
4 - 22

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.

technische mid office als
eindoplossing
[Bron: EGEM]
4.3.8 De organisatie van de gemeenschappelijke voorzieningen
samenwerking 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 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
Tabel 4.1
(NORA) en de insteek van een servicegerichte architectuur
Richtlijnen
3. Wanneer het concern, een dienst, een bedrijf of een stadsdeel wil afwijken
organisatiearchitectuur
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 Toelichting Bron

Uniforme standaarden standaard
organisatiearchitectuur ASL Beheerstandaard voor applicatie Voorstel Adviesgroep
beheer. Architectuur
BISL Beheerstandaard voor functioneel Voorstel Adviesgroep
GIBN Gemeentelijke GIBN: B&W besluit 18
juni 2002
InformatiebeveiligingNorm
Update GIBN 2005:
gebaseerd op de landelijke Code
B&W besluit 5 april
voor Informatiebeveiliging
2005
Handboek Het Handboek Architectuur en de Voorstel Adviesgroep
Architectuur bijlagen zijn standaarden voor de Architectuur
gemeenschappelijke
informatievoorziening en ICT
beschreven.
ITIL Beheerstandaard voor technisch Voorstel Adviesgroep
Programma Antwoord is het Front office van de B&W besluit 11-2004.
Antwoord gemeente voor telefonie en Instemming
internet. gemeenteraad 15-12-
2004, 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 B&W besluit, 08-03-
naar alle gemeentelijke 2005 en instemming
organisaties gemeenteraad 22-06-
2005.
B&W besluit, 11-07-
2006, Notitie ‘Van
ongeduld naar actie’,
Asscher, Van
10
Poelgeest
Servicehuis ICT Het Servicehuis ICT is de B&W besluit, 08-03-
gemeentelijke organisatie voor ICT 2005 en instemming
ondersteuning (technisch en gemeenteraad 22-06-
functioneel beheer en 2005.
ontwikkeling). B&W besluit, 11-07-
2006, Notitie ‘Van
ongeduld naar actie’,
Asscher, Van
11
Poelgeest
Servicehuis Het Servicehuis Personeel B&W besluit, 29-11-
Personeel ondersteunt alle gemeentelijke 2005.
organisaties bij het uitvoeren van
personeelsbeheer
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
Programma BRI is de standaard voor de centrale stad. Stadsdelen worden uitgenodigd om mee te doen.
11
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 CO
partners van de gemeente Informatievoorziening
Model 4.2 Belangrijkste Stuurgroep CO
landelijke initiatieven Informatievoorziening
Model 4.3 Burger@Overheid Burger@Overheid
BurgerServiceCode
Model 4.4 Thematische Programma Programma Dienstverlening
indeling diensten en Dienstverlening
producten
Model 4.5 Stuurgroep CO
Organisatiestructuur Informatievoorziening
gemeente Amsterdam
Model 4.6 De regie-functie Stuurgroep CO
Tabel 4.3 Beheer op de ICT Informatievoorziening
modellen Model 4.7 EGEM EGEM
Organisatietypologie
volgens EGEM: front-,
mid- en back office
Model 4.8 Stap 0: de EGEM EGEM
uitgangssituatie
gemeente na één-loket en
multichannel
organisatorische mid
office als tijdelijke
oplossing
technische mid office als
eindoplossing
4 - 27
Nr. en naam Eigenaar / beslisser Beheerder

standaard
ASL SHI ASLFoundation
BISL Stuurgroep ASLFoundation
Informatievoorziening
GIBN Stuurgroep CO/Informatiebeleid
12
Handboek Architectuur Stuurgroep Adviesgroep Architectuur
Tabel 4.4 Beheer
ITIL SHI Office of Government
standaarden
Commerce (UK)
Programma Antwoord Stuurgroep Stuurgroep Dienstverlening
Dienstverlening
Programma BRI Stuurgroep BRI Stuurgroep BRI
Servicehuis ICT Raad van Deelnemers Dagelijks Bestuur
Servicehuis ICT Servicehuis ICT
Servicehuis Personeel Raad van Deelnemers Dagelijks Bestuur
Servicehuis Personeel Servicehuis Personeel
Personele ? Concern Organisatie
functiegebouw
12
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. GIBN- Titel paragraaf

paragraaf
2.1 Beleidsdocument voor informatiebeveiliging
2.2 Informatiebeveiligingsplan
2.3 Aanvullende maatregelen
3.1 Verantwoordelijksheidsniveaus binnen het concern Amsterdam
3.2 Toewijzing verantwoordelijkheid voor informatiebeveiliging
3.4 Verantwoordelijkheden diensttakoverstijgende
(informatie)systemen (DOIS)
3.5 Contracten met derden
5.1 Voorwaarden tewerkstelling vast personeel
5.2 Voorwaarden tewerkstelling tijdelijk personeel
Tabel 4-5 Relevante
5.3 Kwetsbare functies
paragrafen GIBN
5.4 Bevoegdheden personeel
5.5 Huisregels
5.6 Opleiding en communicatie
6.1 Toegangsbeheersing vestiging(en)
6.2 Servicetaken
6.7 Clear desk en clear screen beleid
6.9 Telewerken
7.3 Bescherming programmatuur en gegevens
7.5 Netwerkbeheer
8.1 Gedocumenteerd beleid voor toegangsbeveiliging
10.5 Uitbesteding ontwikkeling van (informatie)systemen
11.1 Naleving van informatiebeveiligingsbeleid en –plan
11.2 Naleving van wettelijke voorschriften
4.6.2 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-, mid- en 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.
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.
conclusies
organisatiearchitectuur
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 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.
5-2
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 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.
methodisch kader 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-, mid-
en 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 Ketenbenadering
klantgerichtheid 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.
• 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
5-6
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 informatie-
voorziening (DIV) en de archivering, dan ontstaat het volgende beeld.
Het digitale entrepot 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 - 10
5.2 Grondslagen

5 - 11
5.3 Modellen
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 Het hoofdproces Dienstverlening
procesplaat 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 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 beoordelings- of
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).
5 - 12
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 NORA-
decompositiemodel 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.
Over deze detailschema’s wordt goed nagedacht in EGEM-verband.

EGEM
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

5.3.4 Beheren

5.3.5 Besturen

5.3.6 Ondersteunen

5 - 14
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
Tabel 5.1
eindverantwoordelijkheid heeft voor het leveren van de dienst aan de
Richtlijnen
burger of het bedrijf.
procesarchitectuur
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.
Er gelden geen standaarden op het niveau ‘uniform’.
5.4.4 Afspraken
5 - 16
5.5 Beheer
Tabel 5-2 Beheer Nr. en naam model Eigenaar Beheerder

modellen Model 5.1: Hoofdprocesplaat Programma Dienstverlening Programma
van Diesntverlening Dienstverlening
5 - 17
5.6 Beveiliging
5.6.1 GIBN

organisatiearchitectuur opgenomen. Veel beveiligingsmaatregelen zijn
procedures en daarmee onderdeel van een proces.

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
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
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
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.
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
conclusies
dienstoverstijgende ketenprocessen en de inrichting van
procesarchitectuur
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
6 Informatiearchitectuur
6.1 Inleiding
kwaliteit en De informatiearchitectuur geeft de opbouw en samenhang weer van de

beschikbaarheid 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
zaakdossier en één communiceren met de Amsterdamse overheid. Ongeacht de wijze van
zakenmagazijn 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.
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

architectuurlagen 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
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:

Amsterdamse gegevens huishouding
grondslag 3.2 Gegevens worden éénmalig vastgelegd en meervoudig gebruikt.
kaders.

betrouwbaar digitaal contact en zorgvuldige elektronische archivering.
6-4
6.3 Modellen
6.3.1 Gemeentelijke informatiehuishouding
Org.spec. Org.spec.
admin A admin B
Gemeentelijke Informatiehuishouding
Gemeentelijk Informatiemodel
Kernadmin. Kernadmin.
X Y
registraties
Personen Adressen Topografie
Basis
Model 6.1: Gemeentelijke
Landelijk domein
informatiehuishouding
Bedrijven Gebouwen Percelen
Kernadmin.
Z Concerndomein
Org.spec. Organisatiespecifiek Org.spec.

admin C admin D
domein
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
Gebouwen
Adres
7 Adressen
Natuurlijk
Model 6.2: Zes
persoon Personen
basisregistraties
(conceptueel) Niet natuur- Bedrijven
lijk persoon
Percelen
Perceel
Topografie
Kaart
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 BASISREGISTRATIE GEOGRAFISCH
BASISADMINISTRATIE ADRESSEN KERNBESTAND
(Personen) (Adressen) (Topografie)
topografie (groot/
natuurlijke kleinschalig),
adressen
personen lucht- en
cycloramafoto’s
Model 6.3: Zes
basisregistraties met
Geo en Vastgoedinformatie
DBGA
beheerders BASIS BEDRIJVEN BASIS GEBOUWEN KADASTRALE
REGISTER REGISTER REGISTRATIE
(Bedrijven) (Gebouwen) (Percelen)
niet-natuurlijke
verblijfsobjecten
personen
percelen
panden
vestigingen
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 GEO-
GEMEENTE
OBJECTEN
GEMEENTELIJKE
OPENBARE WOONPLAATS
RUIMTE
ligt in
ligt in
betreft 1 of meer
OPENBARE
RUIMTE
ligt aan
WIJK
ADRESSEERBAAR
Model 6.4: Objectenmodel OBJECT
AANDUIDING
van stelsel van is correspondentie-adres van
BUURT
gemeentelijke SUBJECT
14
basisgegevens is hoofd- of nevenadres van
NIET-NATUURLIJK
PERSOON
BENOEMD GEBOUWD
TERREIN OBJECT
bepaalt NATUURLIJK
verblijfs- PERSOON
adres van
hoort bij
ligt in
bepaalt hoofd- (en neven-)adres(sen) van
MAATSCHAPPE-
zonder verblijfsobject ligt in LIJKE ACTIVITEIT
PAND
VESTIGING
KADASTRALE
ONROERENDE ZAKELIJK RECHT
ZAAK
[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 Overzicht kernadministraties
Tabel 6-1 Overzicht Kern- Bevat: Eigenaar: Status:

kandidaat administratie
kernadministraties Bestuursinformatie Dossiers en Bestuursdienst/ Voorstel
documenten betrokken
(Andreas) bij de besluitvorming directie BMO Adviesgroep
van het College van Architectuur
B&W,
Raadscommissies en
de Gemeenteraad.
Bouwprojecten en PM PM Voorstel
woningregistraties Adviesgroep
(BWT) Architectuur
Erfpacht Juridische, financiële OGA/ Voorstel
en vastgoedgegevens
met betrekking tot Bureau Erfpacht Adviesgroep
Erfpachtrech-ten Architectuur
(inclusief digitaal
dossier)
Handhavings- PM PM Vastgesteld door
gevens SG BRI als
kernadministratie
Onderwijs en Inhoudelijke informatie DMO/Onderwijs Vastgesteld door
over jongeren van 0-23
jeugd jaar die noodzakelijk is SG BRI als
voor het uitvoeren van kernadministratie
het Amsterdamse
jeugdbeleid.
Het gaat hierbij om
(verbeterde) gegevens
uit LAS/Erisa over o.a.
school, opleiding,
verzuim, Cito- en
basisschooladvies
Informatie Gegevens van DMO/Servicedesk Voorstel
nieuwkomers en
inburgerings- oudkomers over de Team I&A Adviesgroep
trajecten (Edisa) voortgang van hun Architectuur
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.
Werknemer- PM PM Voorstel
gegevens (P-net) Adviesgroep
Architectuur
Woningbouw- Het Basisbestand OGA Vastgesteld door
bevat deze informatie
locaties over de SG BRI als
woningbouw(locaties) kernadministratie
binnen de gemeente
Amsterdam. Het gaat
met name om
6 - 10
planning, voortgang,
aantallen woningen(en
differentiatie) en de
betrokken partijen
Woonprojecten PM PM Voorstel
(BWV) Adviesgroep
Architectuur
Zakenmagazijn PM PM Voorstel
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.
16
Model 6.6: GFO Zaken
[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).
17
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.
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 meta-
informatie 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
6.4 Standaarden
6.4.1 Richtlijnen
1. Binnen de informatiearchitectuur volgt Amsterdam waar mogelijk landelijke

Tabel 6-2
modellen.
Richtlijnen
2. Landelijke modellen worden zo nodig aangevuld met extra gegevens. Hier
informatiearchitectuur
moet wel een krachtige argumentatie voor zijn.

binnen de informatiearchitectuur.
Tabel 6-3 Nr. en naam Toelichting Bron
informatiearchitectuur BSN Uniek persoonsnummer dat als Ministerie van BZK, Wet
nummer gelijk is aan het algemene bepalingen
sofinummer. Het heeft echter BSN (behandeling 08-
een ander wettelijk kader 2006)
waardoor een breder gebruik
mogelijk is.
CAR Handreiking Catalogus Voorstel Adviesgroep
Authentieke Registraties, de Architectuur
landelijke richtlijn voor
datamodellering
Dublin Core Set gegevenselementen die Voorstel Programma
samen een gangbare Digitaal
internationale standaard Informatiebeheer/GAA
vormen. De Dublin Core wordt
beschouwd als een handzame,
bondige standaard waarin de
meest essentiële
gegevenselementen voor
digitale informatie zijn
gebundeld
GBS Gemeentelijk B&W besluit 9 november
bevolkingssysteem van DPG is 2004
de standaard voor
persoonsgegevens
PDF Standaard voor images / B&W besluit 9 november
beelden 2004
Stuf 2.x 19 Standaard Uitwisseling Voorstel Adviesgroep
Formaat voor Architectuur
binnengemeentelijk
berichtenverkeer
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 VastgoedRegistratie B&W besluit 9 november

Amsterdam van GVI is de 2004
standaard voor
vastgoedgegevens
In onderstaande tabel zijn de bandbreedte standaarden opgenomen die gelden

binnen de informatiearchitectuur.
Nr. en naam Toelichting Bron
standaard
Tabel 6-4
ITU T4 òf ITU T6 Standaard voor images / beelden B&W besluit 9
Bandbreedte
met gebruik van compressie november 2004
standaarden
PDF òf SGML òf XML Standaarden voor B&W besluit 9
vergezeld van een tekstbestanden / -documenten november 2004
stylesheet (XSL, CSS)
6.4.4 Afspraken
In onderstaande tabel zijn de afspraken standaarden opgenomen die gelden

binnen de applicatiearchitectuur.

standaard
Verplichte metadata bij Een uniek ID, creatiedatum, Voorstel Programma
creatie en beheer versie, archiefvormer, status en Digitaal
Tabel 6-5 bestand statushistorie Informatiebeheer/GAA
Afspraken standaarden Verplichte metadata auteur(-s), verwijzing(-en) naar Voorstel Programma
informatiearchitectuur indien relevant voor de Basisregistratie(-s), verwijzing(- Digitaal
informatie waar ze en) naar dossier(-s), Informatiebeheer/GAA
betrekking op hebben publicatiedatum(-s),
wijzigingsdatum(-s),
inzagerechten
6 - 17
6.5 Beheer

Model 6.1: Gemeentelijke PM PM
informatiehuishouding
Model 6.2: Zes PM PM
basisregistraties
(conceptueel)
Model 6.3: Zes PM PM
Tabel 6-6 Beheer beheerders
modellen Model 6.4: Objectenmodel EGEM EGEM
van stelsel van
gemeentelijke
basisgegevens13F
Model 6.5: Het EGEM EGEM
zaakdossier
(objectenmodel)
Model 6.6: GFO Zaken15F EGEM EGEM
Model 6.7: Digitaal Programma Digitaal Programma Digitaal
informatiebeheer Informatiebeheer/GAA Informatiebeheer/GAA
Nr. en naam Eigenaar Beheerder

standaard
BSN Ministerie van BZK Ministerie van BZK
CAR Ministerie van BZK Ministerie van BZK
Dublin Core Dublin Core initiative Programma Digitaal
Informatiebeheer/GAA
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 Ministerie van BZK Ministerie van BZK
vergezeld van een
stylesheet (XSL, CSS)
Stuf 2.x 20 EGEM EGEM
Verplichte metadata bij Programma Digitaal Programma Digitaal
creatie en beheer Informatiebeheer/GAA Informatiebeheer/GAA
bestand
Verplichte metadata Programma Digitaal Programma Digitaal
indien relevant voor de Informatiebeheer/GAA Informatiebeheer/GAA
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

informatiearchitectuur opgenomen. Deze eerste uitwerking is totstandgekomen
in samenwerking met het Platform Informatiebeveiliging, de verder uitwerking
zal ook gezamenlijk ook worden opgepakt.

paragraaf
Tabel 6-8 Relevante 4.1 Inventarisatie van informatie in bedrijfsmiddelen
paragrafen GIBN 4.2 Classificatie van informatie en bedrijfsmiddelen
10.4 Digitale handtekening
Kader: Bijzondere aandacht voor privacy nodig binnen

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
wijze ter beschikking worden gesteld, voor andere dan de gespecificeerde

doeleinden, behalve met toestemming van de betrokkene of op basis van
een wettelijk voorschrift.
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.
6. Het Openness Principle
Er dient openheid te worden gegeven over ontwikkelingen, praktijken en
beleid in relatie tot persoonlijke gegevens.
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.
8. 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.
Verdere uitwerking vindt nog plaats in samenwerking met het Platform

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 4. Binnen de informatiearchitectuur volgt Amsterdam zo veel mogelijk de

informatiearchitectuur 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
7 Applicatiearchitectuur
7.1 Inleiding
applicaties: hebben De applicatiearchitectuur richt zich op functionele aspecten van de

betrekking op informatiehuishouding. Het beschrijft de functionaliteit van applicaties (ook
bedrijfsprocessen 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 De invulling van de applicatiearchitectuur wordt mede bepaald door

ontwikkelingen 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
1) ketenprocessen 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 In de informatiearchitectuur geldt de grondslag van ‘éénmalige opslag,

kernadministraties 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. ICT-

middelen - 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

applicatielandschap kan ingericht om deze ontwikkelingen te ondersteunen. We zien de volgende
ontwikkelingen niet belemmeringen:
ondersteunen • 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).
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 Over de oplossingsrichting bestaat consensus. Amsterdam moet toewerken
architectuur 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 Een éénduidig gezicht en een éénduidig geluid in de communicatie met

presentatiefuncties 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).
2) openheid & Applicaties dienen open te worden ingericht voor hun omgeving, zodat zij
gemeenschappelijke kunnen worden geïntegreerd met andere applicaties (= verbeterde
integratievoorzieningen 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.
3) gemeenschappelijke Vanuit architectuur is het uitgangspunt dat applicaties of onderdelen daarvan

ontwikkeling en beheer met een generiek karakter waar mogelijk onder gemeenschappelijke
aansturing worden gebracht. Bij de besluitvorming hierover kunnen overigens
ook andere factoren een rol spelen.
4) standaardisering Functies worden zodanig ingericht dat zij voldoen aan internationale,
functies 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
architectuur heeft voor de applicatiearchitectuur. Om succesvol te zijn is het noodzakelijk dat
consequenties voor alle ook de proces-, informatie en infrastructuurarchitectuur worden aangepast
architectuurlagen aan de eisen van een service gerichte architectuur.
7-3
7.2 Grondslagen

applicatiearchitectuur:
hergebruikt.

componenten.
7-4
7.3 Modellen
7.3.1 Typologie applicatielandschap
Presentatielaag
Integratielaag
Model 7.1 Typologie

applicatielandschap
(globaal)
De laag dom einen
Datalaag
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.
Hieronder worden deze lagen één voor één langsgelopen, in een aantal
gevallen in meer detail.
Presentatie
P ost B a lie T e le fo o n E - m a il In te r n e t 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
U itw is s e le n b e r ic h t e n
Integratie
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 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 egevens-
Z a k e n m a g a z ijn
m a g a z ijn e n
Model 7.2 Typologie

applicatielandschap:
P r o c e s g e n e r ie k e P r o c e s g e n e r ie k e P r o c e s g e n e r ie k e
uitwerking presentatielaag f u n c t ie s f u n c t ie s f u n c t ie s
Domeinen
Ondersteunende
Ondersteunende
Ondersteunende
Management
Management
Management
functies
functies
functies
functies
functies
functies
P r o c e s s p e c if ie k e P r o c e s s p e c if ie k e P r o c e s s p e c if ie k e
f u n c t ie s f u n c t ie s f u n c t ie s
B e la s t in g e n / E r f p a c h t W e r k e n In k o m e n M a a t s c h a p p e lijk e O n t w ik k e lin g
Data
B a s is r e g is t r a tie s K e r n a d m in is tr a tie s
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 A u th e n tic e re n R e g is s e re n
s e rvic e s & a u to ris ere n p ro c e s s e n
Model 7.3 Typologie

Toegang
applicatielandschap: G e g e ve n s
m a g a z ijn e n v e rle n e n
Zaken
m a g a z ijn R e g is tre re n
re g is tra tie s zaken
uitwerking integratielaag
A fh a n d e le n
A a n vra g e n d
e A a n vra g e n d
e
B a s is re g is tra tie e n
k e rn a d m in is tra tie s
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 Stadsdeel

A B
Vastgoed Personen 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 Dienst 3 Dienst 4 Dienst 5 Stadsdeel Stadsdeel

A B
Basis- Kernadmini-
Vastgoed Personen Bedrijven registratie X stratie 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 Stadsdeel

A B
Servicebus
Basisre- Kernadmini-
Vastgoed Personen Bedrijven gistratie X stratie Y
Functie Architectuurlaag
1. Uitwisselen berichten
2. Beheren services Infrastructuurarchitectuur
Tabel 7-1 Uitwerking
3. Authenticeren en Autoriseren
functies integratielaag
4. Toegang verlenen tot
registraties
Applicatiearchitectuur
5. Registreren zaken
6. Regisseren processen
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.
Om tot één Servicebus Amsterdam te komen die alle zes genoemde

integratiefuncties levert adviseert de Adviesgroep Architectuur om een stap-
voor-stap benadering te volgen: van een dunne bus naar een dikke bus met de
functies 1 t/m 4 als prioriteit.
Presentatie
P ost B a lie T e le fo o n E - m a il In te r n e t C hat
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 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
Integratie
B e h e r e n s e r v ic e s A u t h e n tic e r e n & a u t o r is e r 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 egevens-
m a g a z ijn e n
Model 7.4 Typologie

uitwerking laag domeinen fu n c t ie s f u n c t ie s f u n c t ie s
Domeinen
Ondersteunende
Ondersteunende
Ondersteunende
Management
Management
Management
functies
functies
functies
functies
functies
functies
P r o c e s s p e c if ie k e P r o c e s s p e c if ie k e P r o c e s s p e c if ie k e
f u n c t ie s f u n c t ie s f u n c t ie s
B e la s t in g e n / E r f p a c h t W e r k e n In k o m e n M a a t s c h a p p e lijk e O n t w ik k e lin g
Data
B a s is r e g is t r a tie s K e r n a d m in is tr a tie s
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
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.
Presentatie
P o st B a lie T e le fo o n E - m a il In te rn e t 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 ta tie in t e g r a tie B e h e e r fu 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 to r is e r 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 tr e r e n z a k e n
G egevens-
m a g a z ijn e n
Model 7.5 Typologie

uitwerking datalaag f u n c t ie s fu n c t ie s fu n c tie s
Domeinen
Ondersteunende
Ondersteunende
Ondersteunende
Management
Management
Management
functies
functies
functies
functies
functies
functies
P r o c e s s p e c ifie k e P r o c e s s p e c ifie k e P r o c e s s p e c if ie k e
fu n c tie s f u n c tie s f u n c t ie s
B e la s tin g e n / E r f p a c h t W e r k e n In k o m e n M a a ts c h a p p e lijk e O n tw ik k e lin g
Data
B a s is r e g is tr a tie s K e r n a d m in is tr a tie s
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
Presentatie
P ost B a lie KTAeNle
A fo
Co Cn EK -m
A NaAil InLte
o krn
e te t Chat
R e sp o n se
(A n tw o o rd ) (A n tw o o rd ) A ’d a m
K a n a le n
lo k e t A ’d a m P o rta a l W e b in a b o x
A tla s A ’d a m A ’d a m P lu g a n d p la y
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 ta tie in te g r a tie B e h e e r f u n c t ie s
Integratie
A A A s e rv e r BEA W LI
T o e g a n g v e r le n e n r e g is t r a tie s R e g is tr e r e n z a k e n
G egevens- P a ra p lu KANA CC
D iv a
Z a k e n m a g a z ijn O ra c le (A n tw o o rd )
m a g a z ijn e n
Model 7.6 Typologie
uitwerking alle lagen P r o c e s g e n e r ie k e P r o c e s g e n e r ie k e P r o c e s g e n e r ie k e
fu n c tie s f u n c t ie s fu n c tie s
Domeinen
D o c u m e n tu m D o c u m e n tu m D o c u m e n tu m
Ondersteunende
Ondersteunende
Ondersteunende
Management
Management
Management
functies
functies
functies
functies
functies
functies
reports
reports
reports
Crystal
Crystal
Crystal
P-net
P-net
P-net
H e rm e s NUS_O P E R IS A
P r o c e s s p e c if ie k e P r o c e s s p e c ifie k e P r o c e s s p e c if ie k e
f u n c t ie s fu n c tie s fu n c t ie s
Data
GBS
VRA P -n e t
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 In te rn e t
K a n a le n 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 v e n s m a g a z ijn e n G e g e v e n s m a g a z ijn e n

Model 7.7 Het huidige
versnipperde
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
applicatielandschap
P ro c e s g e n e rie k e fu n c tie s P ro c e s g e n e rie k e fu n c tie s P r o 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
M a n a g e m e n t fu n c t
fu n c tie s
fu n c tie s
fu n c tie s
P r o c e s s p e c ifie k e fu n c tie s P r o c e s s p e c ifie k e fu n c tie s P r o c e s s p e c ifie k e fu n c tie s
GVI DPG DMO
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
Presentatie
P ost B a lie KTAeNle
A fo
Co Cn EK -m
A NaAil InLte
o krn
e te t Chat
R e sp o n se
(A n tw o o rd ) (A n tw o o rd ) A ’d a m
K a n a le n
lo k e t A ’d a m P o rta a l W e b in a b o x
A tla s A ’d a m A ’d a m P lu g a n d p la y
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 ta tie in te g r a tie B e h e e r f u n c t ie s
Integratie
A A A s e rv e r BEA W LI
T o e g a n g v e r le n e n r e g is t r a tie s R e g is tr e r e n z a k e n
G egevens- P a ra p lu KANA CC
D iv a
Z a k e n m a g a z ijn O ra c le (A n tw o o rd )
m a g a z ijn e n
Model 7.8 Het huidige

applicatielandschap (in
typologie) fu n c tie s f u n c t ie s fu n c tie s
Domeinen
D o c u m e n tu m D o c u m e n tu m D o c u m e n tu m
Ondersteunende
Ondersteunende
Ondersteunende
Management
Management
Management
functies
functies
functies
functies
functies
functies
reports
reports
reports
Crystal
Crystal
Crystal
P-net
P-net
P-net
H e rm e s NUS_O P E R IS A
P r o c e s s p e c if ie k e P r o c e s s p e c ifie k e P r o c e s s p e c if ie k e
f u n c t ie s fu n c tie s fu n c t ie s
Data
GBS
VRA P -n e t
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?
Presentatie
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
U itw i s s e l e n b e r ic h t e n
Integratie
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 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 l e n e n r e g is t r a t ie s R e g is tre re n z a k e n
G egevens- Z a k e n m a g a z ijn
m a g a z ijn e n
Model 7.9 Het
toekomstige
applicatielandschap: wat
generiek
Domein
kan gemeenschappelijk?
P ro c e s g e n e rie k e G e n e r ie k e m a n a g e m e n t G e n e r ie k e
fu n c tie s f u n c t ie s o n d e r s t e u n e n d e f u n c t ie s
Domeinen
P r o c e s s p e c i f i e k e 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 P r o c e s s p e c i f ie k e f u n c t i e s
B e la s tin g e n / E rfp a c h t W e rk e n In k o m e n 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
Data
B a s i s r e g is t r a t ie s K e r n a d m in i s tr a ti e s
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
organisatie- en 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 organisatie- en 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 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
Tabel 7.2
wijze waarop deze wordt gebruikt (inrichting) geüniformeerd.
Richtlijnen applicaties
4. Processpecifieke voorzieningen voldoen in elk geval aan een aantal open
algemeen
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.
7. Integratie vindt plaats binnen één platform. Integratie van applicaties in

Tabel 7.3
verschillende domeinen vindt alleen plaats via het platform en niet
Richtlijnen voor integratie
rechtstreeks.
23
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 Bandbreedte Uniforme

standaarden standaarden
Algemene,
infrastructurele functies 8 9
Integratiefuncties 8 9
Presentatiefuncties 8 9
Functies voor
Tabel 7-4
secundaire
bedrijfsprocessen
8 9
Richtlijn voor
standaardisering Procesgenerieke ict-
gemeenschappelijke
functies
functies inclusief
management en 8 9
ondersteuning
Processpecifieke
functies voor primaire
bedrijfsprocessen
8 9
Unieke functies 9
Legenda
8 = Huidige situatie
9 = Gewenste situatie
In Bijlage 16 wordt verder ingegaan op een resulterende standaard inrichting

per applicatie.

binnen de applicatiearchitectuur.
Tabel 7-5 Nr. en naam Standaard voor Bron
Applicatiearchitectuur Amsterdam.xsd Schema Syntax voor Voorstel
Basisregistraties Adviesgroep
Architectuur
BPEL Procesorkestratie Voorstel
Adviesgroep
Architectuur
BPMN Procesmodellering Voorstel
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
Adviesgroep
Architectuur
Documentum Document management systemen B&W-besluit 9
november 2004
GFO-2006, GFO Objectenmodel, objectenmodel van Voorstel
Zaken stelsel van gemeentelijke Adviesgroep
basisgegevens resp. zaken Architectuur
HTML Ontwikkeltaal Presentatielaag Voorstel
Adviesgroep
Architectuur
P-net personeels- en salarisadministraties B&W-besluit 9
van alle gemeentelijke organisaties november 2004
SOAP Service aanroep bij Voorstel
berichtuitwisseling Adviesgroep
Architectuur
StUF 25 Berichtenspecificatie Voorstel
Adviesgroep
Architectuur
UDDI Service register Voorstel
Adviesgroep
Architectuur
WSDL Service beschrijving Voorstel
Adviesgroep
Architectuur
WS-Reliability Betrouwbaarheid van Voorstel
berichtuitwisseling Adviesgroep
Architectuur
WSRP Presentatie Voorstel
Adviesgroep
Architectuur
WS-Security Webservice beveiliging Voorstel
Adviesgroep
Architectuur
XML Ontwikkeltaal Gegevensopslag en Voorstel
uitwisseling Adviesgroep
Architectuur
XML Schema Schema Syntax Voorstel
Adviesgroep
Architectuur
XQUERY Data Queries Voorstel
Adviesgroep
Architectuur
XSLT XML Transformatie Voorstel
Adviesgroep
Architectuur
25
Zie hoofdstuk Informatie
7 - 24
7.4.3 Bandbreedte
In onderstaande tabel zijn de standaarden opgenomen die gelden binnen de

applicatiearchitectuur.
standaard
Tabel 7-6
Exact, Fis4all, Civision, preferente financiële pakketten B&W-besluit 9
Standaarden
OneWorld en Decade november 2004
J2EE (Java), .Net Ontwikkelomgeving Voorstel
bandbreedte
Adviesgroep
Architectuur
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 ICT-
standaarden 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 ICT-
variaties 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
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.

Model 7.1 Typologie Adviesgroep Adviesgroep Architectuur
applicatielandschap Architectuur
(globaal)
applicatielandschap: Architectuur
uitwerking presentatielaag
uitwerking integratielaag
uitwerking laag domeinen
Tabel 7-7 Beheer Model 7.5 Typologie Adviesgroep Adviesgroep Architectuur
modellen applicatielandschap: Architectuur
uitwerking datalaag
Adviesgroep Adviesgroep Architectuur
Model 7.6 Typologie Architectuur
uitwerking alle lagen
Model 7.7 Het huidige Adviesgroep Adviesgroep Architectuur
versnipperde Architectuur
applicatielandschap
Model 7.8 Het huidige Adviesgroep Adviesgroep Architectuur
applicatielandschap (in Architectuur
typologie)
Model 7.9 Het toekomstige Adviesgroep Adviesgroep Architectuur
applicatielandschap: wat kan Architectuur
gemeenschappelijk?
7 - 26
Nr. en naam Eigenaar Beheerder

standaard
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 EGEM/GBO EGEM/GBO
Zaken
HTML W3C W3C
Tabel 7-8 Beheer
J2EE (Java) Sun Sun
standaarden
.Net Microsoft Microsoft
26
P-net SHP SHP
SOAP W3C 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
SHP = Servicehuis Personeel
27
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

informatiearchitectuur opgenomen.

paragraaf
4.1 Inventarisatie van informatie en bedrijfsmiddelen
4.2 Classificatie van informatie en bedrijfsmiddelen
Tabel 7-9 Relevante
paragrafen GIBN
10.1 Beveiligingseisen voor (informatie)systemen
10.3 Cryptografische 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
uitgangspunten
authenticatievoorzieningen rechtstreeks toegang verkrijgen tot
beveiliging
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 ‘Trust-
relatie’ 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

7 - 29
7.7 Conclusies
1. De applicatiearchitectuur is nauw gerelateerd aan de

conclusies infrastructuurarchitectuur. De scheiding tussen beiden verschuift:
applicatiearchitectuur 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 organisatie- en 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.
29
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.
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
32
33
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.
7 - 32
8 Infrastructuurarchitectuur
8.1 Inleiding
infrastructuur: drager van Van oorsprong wordt de infrastructuur vooral gedefinieerd in technische
architectuur 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 Zoals we ook in Hoofdstuk 7 hebben gezien is het onderscheid tussen de
‘infrastructuur’ 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.
Huidige infrastructuur Als we naar de huidige infrastructuur kijken valt op dat er (net als in het
ondersteunt nog applicatielandschap) een grote verscheidenheid is aan lokale, dienstgebonden
onvoldoende ‘koppelen en netwerken. Dit maakt het lastig om het uitgangspunt ‘koppelen en kantelen’ te
kantelen’ en implementeren en een service gerichte architectuur te ondersteunen. Om goed
servicegerichtheid 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 We hebben in Hoofdstuk 4 gezien dat we een overheid willen zijn die
belangenafwegingen • 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

integratievoorzieningen gemeenschappelijke infrastructurele voorzieningen voor integratie. Deze
integratievoorzieningen moeten een plaats krijgen in de gemeenschappelijke
netwerken.
2) gemeentebrede Bij de implementatie van de gemeenschappelijke integratievoorzieningen zal

infrastructuurarchitectuur ‘onder architectuur’ gewerkt moeten worden.
37
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 E-
net 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

infrastructuurarchitectuur:

standaarden.
8-4
8.3 Modellen
8.3.1 Domeinstructuur E-net en beveiligingsdomeinen
Model 8.1 Domeinen E-

net (1)
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 Beveiligings-

niveaus
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 Beveiligingsdomein E-net domein

WBP en risicoklasse 0 Publiek Publiek
domeinenindeling risicoklasse 1 Basis Basis
risicoklasse 2 Select 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 E-
net 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 E-

net (2)
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 data-
infrastructuur. 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 niet-
dienstgebonden). Over het algemeen worden deze netwerken gehost door
GetronicsPinkRoccade/ASP4All (zie kader).
• De middelste laag geeft de ‘datatransportlaag’ weer van de Enet-
datainfrastructuur. 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 A u th e n tic e re n R e g is s e re n
s e rvic e s & a u to ris ere n p ro c e s s e n
Model 8.4 Uitwerking

Toegang
functies integratielaag G e g e ve n s
m a g a z ijn e n v e rle n e n
Zaken
m a g a z ijn R e g is tre re n
re g is tra tie s zaken
(detail)
A fh a n d e le n
A a n vra g e n d
e A a n vra g e n d
e
B a s is re g is tra tie e n
k e rn a d m in is tra tie s
Functie Architectuurlaag
1. Uitwisselen berichten
2. Beheren services Infrastructuurarchitectuur
Tabel 8-2 Uitwerking
3. Authenticeren & Autoriseren
functies integratielaag
4. Toegang verlenen tot
registraties
5. Registreren zaken
6. Regisseren processen
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 AM-
server) 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
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:
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 AM-
service. 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 Dataopslag
Model 8.7 Dataopslag PM voor volgende versie.
[Bron: PM]
8.3.5 Dataverwerking
Model 8.8 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 Standaard werkplek
Model 8.9 Standaard PM voor volgende versie.

werkplek
[Bron: PM]
8 - 16
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
Tabel 8.3
applicatie wordt ook de wijze waarop deze wordt gebruikt (inrichting)
Richtlijnen infrastructuur-
geüniformeerd.
architectuur
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.

binnen de infrastructuurarchitectuur.
Nr. en naam standaard Toelichting Bron
DigID Landelijke GBO.Overheid

authenticatievoorziening
voor burgers en
bedrijven.
41
E-net (netwerk) Datacommunicatie- B&W-besluit 9
infrastructuur voor november 2004
informatie-uitwisseling
Tabel 8-4 tussen gemeentelijke
Uniforme standaarden organisatie onderling en
infrastructuurarchitectuur met de ‘buitenwereld’
Hosting Schijfruimte voor de PM
opslag van bestanden
Werkplek Standaard PM
werkplekfunctionaliteit
I AM-service De gemeenschappelijke B&W-besluit 9
42
authenticatievoorziening november 2004
TCP / IP Netwerkprotocollen Voorstel
Adviesgroep
Architectuur
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

Model 8.1 Domeinen E-net Stuurgroep SHI
(1) Informatievoorziening
Model 8.2 Beveiligings- Stuurgroep SHI
niveaus Informatievoorziening
Model 8.3 Domeinen E-net Stuurgroep SHI
(2) Informatievoorziening
Model 8.4 Uitwerking Stuurgroep SHI
functies integratielaag Informatievoorziening
(detail)
Tabel 8-5 Beheer
Model 8.5 I AM-service Stuurgroep SHI
modellen
startsituatie: Informatievoorziening
Model 8.6 I AM-service Stuurgroep SHI
groeiscenario: Informatievoorziening
Model 8.7 Dataopslag Stuurgroep SHI
Model 8.8 Dataverwerking Stuurgroep SHI
Model 8.9 Standaard Stuurgroep SHI
werkplek Informatievoorziening
Nr. en naam standaard Eigenaar / beslisser Beheerder

DigID ?? GBO.Overheid
Tabel 8-6 Beheer E-net SHI SHI
standaarden Hosting PM PM
Werkplek PM PM
I AM-service SHI SHI
43
TCP / IP ?? IETF
43
Internet Engineering Task Force (IETF) ontwerpt, test en implementeert (technische) internetstandaarden waaronder TCP/IP.
8 - 19
8.6 Beveiliging
8.6.1 GIBN

informatiearchitectuur opgenomen.

paragraaf
6.3 Toegang computer- en datacomponenten
Tabel 8-7 Relevante
6.4 Bewegwijzering computerruimten
paragrafen GIBN
6.5 Verwijderen apparatuur en gegevensdragers
6.6 Datakluizen
6.8 Beveiliging van (mobiele) apparatuur
6.9 Telewerken
8.4 Toegangsbeveiliging voor netwerken
10.3 Cryptografische beveiliging
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 beveiligingsrisico-
klassen.
• 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

44
RADIUS / token
8 - 21
8.7 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
conclusies infrastructuur-
• generieke software (applicaties voor kantoorautomatisering en
architectuur
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
9 Architectuurorganisatie en -
proces
9.1 Inleiding
niet alleen papier, ook Zoals in Hoofdstuk 2 aangehaald is dit Handboek van weinig waarde zonder
doen! 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
Eigenaar
Deelarchi-
Deelarchi tectuur 1
tectuur 1
Stuurgroep
Inf.voorz.
Eigenaar
Deelarchi-
Deelarchi tectuur 2
tectuur 2
Adviesgroep Concern-
Architectuur organisatie
Model 9.1 Handboek
architectuur
Architectuurorganisatie
Eigenaar
Deelarchi-
Deelarchi tectuur 3
tectuur 3
Lokaal
Lokale Lokale Lokale
architect architect architect
Lokale stadsdeel X Lokale dienst Y Lokale bedrijf Z
architectuur x architectuur y architectuur Z
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 47
V V - - V
Informatie-
Tabel 9-1 Architectuur:, voorziening
Rollen, taken en 2)
verantwoordelijkheden Adviesgroep A A A
architectuur
3) 48 49 50
BO C C C C
Directie CO
4) Eigenaren
deelarchitec - BO - - A+BO+T
turen
5) Lokale 51
- - BO A+BO+T A+BO+T
architecten
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.
48
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.
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 Planning-&
toetsing Controlcyclus
Lokaal
Confirmeren
aan referentie
architectuur
Aantonen nood-
zaak afwijking
Lokale
Architecten Publiceren
jaarstukken
Model 9.2 Toetsen van de
architectuur
Rapportage
Zoeken naar
conformiteit
Concern
Adviesgroep Monitoren
Architectuur architectuurtraject
Concern-
organisatie
Integrale meting
bedrijfsvoering
Externe
auditor
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 ICT-
projecten. 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 ICT-

projecten 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.
Derde lijn
Eerste lijn
Tweede lijn
Adviesgroep
Lokale Architectuur
Architect Concern-
organisatie
Eigenaar
Deelarchi-
tectuur
Advisering
op eigen
initiatief Ongevraagd
Niet beant- advies SG
Architectuur
woordbaar
Vragen
Model 9.3 Adviseren over Beantwoordbaar
architectuur Advies
Architectuur Niet beant-
Architectuur
woordbaar
Vragen Vragen SG Advies SG
Beantwoordbaar
Advies
Architectuur
Vragen
Advies
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 BEHEERPROCES
Architectuur Vastgestelde
Model 9.4 Ontwikkelen en (-gedeelten) architectuur(-versie)
beheren van architectuur in ontwikkeling
(cyclus)
ONTWIKKEL-
PROCES Analyse
verschillen
Impact programma’s +
overige ontwikkelingen
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 Uitwerking Goedkeuring
Wijziging
Voorstel voor
Informatiebeleid
aanpassen
of strategie Rapportage
Verwerken
commentaar
Architect
Wijziging dienst
informatieplan Uitwerken
voorstel
Model 9.5 Ontwikkelen en

beheren van architectuur
(detail) Terugkoppeling
Adviesgroep Uit een project Beoordelen Aanpassen Publiceren
Architectuur
Architectuur
Stuurgroep Besluitvorming
Inf.voorz.
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. Aanleiding
2. Voorbereiding
3. Uitwerking
4. 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 Informatie-
voorziening (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 organisatie- en/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.

binnen de organisatiearchitectuur.
Nr. en naam standaard Toelichting Bron
Referentiearchitectuur/Handboek Het samenhengend Voorstel

Architectuur geheel van de Adviesgroep
organisatie-, proces-, Architectuur
informatie, applicatie- en
infrastructuurarchitectuur
met hierin opgenomen
per architectuur de
geldende modellen en
Tabel 9-2 standaarden.
Uniforme standaarden ArchiMate Een architectuurtaal ArchiMate Forum
architectuurorganisatie en en visualisatie-
proces technieken 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.
9.4.4 Afspraken
9 - 13
9.5 Beheer

Model 9.1 Stuurgroep CO/Informatiebeleid
Architectuurorganisatie Informatievoorziening
Model 9.2 Toetsen van Stuurgroep CO/Informatiebeleid
de architectuur Informatievoorziening
Tabel 9-3 Beheer Model 9.3 Adviseren Stuurgroep CO/Informatiebeleid
modellen over architectuur Informatievoorziening
Model 9.4 Ontwikkelen Stuurgroep CO/Informatiebeleid
en beheren van Informatievoorziening
architectuur (cyclus)
Model 9.5 Ontwikkelen Stuurgroep CO/Informatiebeleid
en beheren van Informatievoorziening
architectuur (detail)
Nr. en naam Eigenaar / beslisser Beheerder

standaard
Tabel 9-4 Beheer Referentiearchitectuur Stuurgroep CO/Informatiebeleid
standaarden /Handboek Informatievoorziening
Architectuur
Archimate Stuurgroep Telematica Instituut
9 - 14
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.
5. Diensten, bedrijven en stadsdelen zijn zelf verantwoordelijk om zich aan

conclusies dit Handboek Architectuur te houden. De verantwoordelijkheid voor de
architectuurorganisatie en 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-, mid- en 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 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-7 Beheer standaarden ....................................................................................18
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 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 9-1 Architectuur:, Rollen, taken en verantwoordelijkheden .................................4
Tabel 9-2 Uniforme standaarden architectuurorganisatie en proces..........................13
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 EGEM
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, Word-
documenten, PDF-files, audio en/of video) moet zodanig beschikbaar
worden gesteld zodat per contenttype specifieke bewerkingen mogelijk zijn.
Channel management
Bijlagen - 2
Database-server Technische voorziening die gegevensopslag, structuur en ontsluiting

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. Archimate
Gegevens Een geformaliseerde representatie van de beschrijving van een object
Geïntegreerde user Meerdere applicaties naast elkaar, individueel bepaald, presenteren

interface
Bijlagen - 3
Gemeenschappelijke
integratievoorzieningen
Generiek
Generieke functie
GFO zaken 2002 Gemeentelijk Functioneel Ontwerp ‘Zaken’ EGEM
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
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
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.
Sturen Sturen & Inrichten

Richtinggevend IV (wat?) IV-organisatie(hoe?)
3.2 3.4 3.3
Sturend 7.2 Planning 7.3 Financieel 7.4 Behoefte 7.5 Contract

& Control Management Management Management
4.3 Functionaliteiten
Gebruiksbeheer Beheer
4.2 4.4
4.5
Uitvoerend
Technisch Beheer Applicatiebeheer

6 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 wat hoe

Richtinggevende
processen
eigenaar
Sturende
processen
functioneel gegevensbeheer
beheer appl. gebruikersondersteuning

functionaliteitenbeheer
der beheer
applicatiebeheer
der
technisch
technisch beheer
beheerder
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.
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 De beheeractiviteiten
RICHTINGGEVEND
3.2 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 BISL
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
omringende organisaties plaats.

FUNCTIONEEL BEHEER
4.2 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.
UITVOEREND
5 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.
STUREND
7.2 Planning & Control BISL
7.3 Financieel management BISL
7.4 Behoeftemanagement BISL
7.5 Contractmanagement BISL
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
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.
Hoofdstuk 1 Inleiding
Hoofdstuk 2 Informatiebeveiligingsbeleid en - plan
2.1 Beleidsdocument voor informatiebeveiliging
2.2 Informatiebeveiligingsplan
2.3 Aanvullende maatregelen
Hoofdstuk 3 Organisatie van de informatiebeveiliging
3.1 Verantwoordelijkheidsniveaus binnen het concern
3.2 Amsterdam
Bijlagen - 16
3.3 Toewijzing verantwoordelijkheid voor

3.4 informatiebeveiliging
3.5 Rapporteren beveiligingsincidenten
3.6 Verantwoordelijkheden diensttakoverstijgende
(informatie)systemen (DOIS)
Contracten met derden
Contracten met interne afnemers
Hoofdstuk 4 Classificatie en beheer van informatie en
4.1 bedrijfsmiddelen
4.4 Beheer van informatie en bedrijfsmiddelen
Verwerking van persoonsgegevens
Hoofdstuk 5 Personele beveiligingseisen
5.1 Voorwaarden tewerkstelling vast personeel
5.2 Voorwaarden tewerkstelling tijdelijk personeel
5.4 Bevoegdheden personeel
5.5 Huisregels
5.6 Opleiding en communicatie
Hoofdstuk 6 Fysieke beveiliging
6.2 Servicetaken
6.3 Toegang computer- en datacomruimten
6.4 Bewegwijzering computerruimten
6.5 Verwijderen apparatuur en gegevensdragers
6.6 Datakluizen
6.7 Clear desk en clear screen beleid
6.8 Beveiliging van (mobiele) apparatuur
6.9 Telewerken
Hoofdstuk 7 Beheer van communicatie- en bedieningsprocessen
7.1 Beheerprocedures en verantwoordelijkheden
7.2 Acceptatie van nieuwe versies van systemen
7.4 Registratie en rapportage
7.5 Netwerkbeheer
Hoofdstuk 8 Logische toegangsbeveiliging
8.1 Gedocumenteerd beleid voor toegangsbeveiliging
8.2 Beheer van toegangsrechten
8.3 Controle op toegangsrechten
8.4 Toegangsbeveiliging voor netwerken
8.7 Bewaking van de toegangsbeveiliging
Hoofdstuk 9 Continuïteitsmanagement
9.1 Proces van continuïteitsmanagement
9.2 Relatie met nood- en ontruimingsplan
Hoofdstuk 10 Ontwikkeling en onderhoud van systemen
10.1 Beveiligingseisen voor (informatie)systemen
Bijlagen - 17

Hoofdstuk 11 Naleving
11.1 Naleving van informatiebeveiligingsbeleid en -plan
11.2 Naleving van wettelijke voorschriften
11.3 Beoordeling van de naleving
Bijlagen - 18
Bijlage 4 Grondslagen
4.1 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 wet-
en 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.
• Ook zal zij goed in de gaten moeten houden wat de implicaties zijn van nieuwe of
gewijzigde standaarden op de bestaande situatie.
4.2 Grondslagen organisatiearchitectuur

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.

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.
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.

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 Grondslagen procesarchitectuur
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.
Bijlagen - 21
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 Grondslagen informatiearchitectuur

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.
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.
• 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.

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
• 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.
4.5 Grondslagen applicatiearchitectuur
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.
• 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.

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).

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 Grondslagen infrastructuurarchitectuur

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 - heeft
gebruikt
tenis
zorgt voor
start van
voert uit
Proces Organisatie-
bewerkt eenheid
Wisselt uit
ondersteunt
Informatie -
object
biedt
bewerkt Bericht Applicatie
bevat wisselt service
uit
realiseert
gebruikt
heeft
Applicatie
Applicatie
functie
draait op
verbonden
door
Apparaat Netwerk
Bron: Adviesgroep Architectuur
Metamodel Amsterdamse architectuur

(voor verklaring der tekens: zie de Archimate concepten hieronder. Voor
verklaring der termen: zie bijlage Terminologie)
Bijlagen - 28
Specialisation
Process/
Meaning Actor
function
Composition
Aggregation
Assignment
Value Process Role
Realisation
Triggering
Product Used by
Function Component
Flow
Access
Object Association
Activity Collaboration
Junction
provided Group
Representation Service Interface required
symmetric
Artifact Event Node
System System
Device
Interaction software software
Communication
Network
path
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 & ICT-
infrastructuur (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 opdrachtgever-

opdrachtnemerschap 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 diensttak-
directeuren 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 meerjaren-
perspectief. 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 Bestuurs-

commissie 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 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 & ICT-
infrastructuur, elektronische
loketten en de vorming van Shared
Service Centers maken een goede
bestuurlijke verankering noodzakelijk. Met de commissie Informatie-
Voorziening (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.
doel en taken 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 privacy-
wetgeving, 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 informatie-
huishouding wanneer de situatie dit vraagt maar de belangen van
gemeentelijke organisaties uiteenlopen.
B&W → Cie IV 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&W-

besluit:
• 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 portefeuille-
verdeling 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 Informatie-
Voorziening 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 stadsdeel-
secretarissen op ad hoc-basis aanschuiven als er onderwerpen zijn die ze
aanspreken of waar ze iets over willen inbrengen.
staf wethouder 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.
Bijlagen - 36
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 vergader-
frequentie 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 bestuurlijk-

ambtelijke 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 : College van Burgemeester en Wethouders

Van : P. Oosterlaken (DJZ), A. Eurelings en H. Gels (CO)
Datum : 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 stadsdeel-

secretarissen 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 portefeuillehouder bedrijven B&W + (3-5) DB leden Stadsdelen
DB drie directeuren stadsdeelsecretaris+directeur
bedrijf+directeur dienst
Raad van acht directeuren stadsdeelsecretarissen en directeuren van
Deelnemers 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 ICT-
diensten.
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
ANDER ANDER
INGESCHREVEN
NIET- BUITENLANDS BUITENLANDS
INGEZETENE NIET-NATUURLIJK
INGEZETENE NATUURLIJK NIET-NATUURLIJK
PERSOON
PERSOON PERSOON
is eigenaar van
heeft nadere adresaanduiding in
PARTNER-
OUDER-KIND-
RELATIE
RELATIE
PERSOONS-
FUNCTIONARIS
OVERIGE
RELATIE
heeft als correspondentie- of aanschrijvingsadres

verblijft in of op
HUISHOUDEN MAATSCHAPPE-
LIJKE ACTIVITEIT
heeft postadres in
WOONPLAATS heeft postadres in
heeft als
correspond
entie-adres
VERBLIJFS- AUTHENTIEK NUMMER-

VESTIGING
OBJECT TERREIN AANDUIDING
bepaalt
OVERIG nevenadres
van
GEBOUWD OVERIG TERREIN OVERIG ADRES
OBJECT
bepaalt
BENOEMD TERREIN hoofdadres
van
ADRESSEERBAAR
GEBOUWD OBJECT OBJECT AANDUIDING
bepaalt nevenadres van
[Bron: EGEM]
Bijlagen - 44
Basisregistratie Vastgoed
OPENBARE DETAILLERING ADRESSEN, GEBOUWEN EN TERREINEN

RUIMTE
ADRESSEERBAAR OBJECT AANDUIDING
OVERIGE
ADRESSEERBAAR NUMMER-
OBJECT AANDUIDING
AANDUIDING
officieel adres
officieel adres
locatie-adres
straatadres
nevenadres hoofdadres hoofdadres nevenadres
OVERIG
VERBLIJFS-
GEBOUWD STANDPLAATS LIGPLAATS OVERIG TERREIN
OBJECT
OBJECT
AUTHENTIEK TERREIN
GEBOUWD OBJECT BENOEMD TERREIN
hoort bij ligt in
PAND
[Bron: EGEM]
DETAILLERING KADASTRALE ONROERENDE ZAKEN EN RECHTEN

KADASTRALE ONROERENDE ZAAK heeft als voornaamste zakelijk gerechtigde
KADASTRAAL APPARTEMENTS-
ZAKELIJK RECHT SUBJECT
PERCEEL RECHT
ligging filiatie 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
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
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: fsmit@gaaweb.nl;
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
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 democratie-
theoretisch 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 Amsterdamse

hulpmiddel product
Kanalen
Post Kanaal waarmee de aanvrager (burger) per Postregistratie,

post een vraag kan stellen of een Dossieropslag
product/dienst kan aanvragen. Er bestaat in dit
geval geen direct contact tussen de burger en
de ambtenaar (stateless, asynchrone
communicatie).
Balie 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.
Telefoon Kanaal waarmee de aanvrager (burger) in Aspect Antwoord
telefonisch contact met een ambtenaar van de
gemeente een vraag kan stellen of een
E-mail Kanaal waarmee de aanvrager (burger) per e- Kana Response Antwoord
mail 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).
Internet Kanaal waarmee de aanvrager (burger) MmBase, Loket
interactief via een webformulier op de WebOS, Amsterdam
internetpagina van de gemeente een aanvraag SmartSite,
voor een gemeentelijke dienst kan invoeren. Iprox, Kode,
Het is daarnaast ook mogelijk dat de burger Portaal
toegang heeft tot zijn eigen electronisch loket
(mijnLoket) waarin bijvoorbeeld de status van
zijn/haar aanvraag kan worden gevolgd.
Chat Kanaal waarmee de aanvrager (burger) in -
direct contact via chat met een ambtenaar van
de gemeente een vraag kan stellen of een
Ondersteunen
Klant
Afspraken Maakt het mogelijk een beschikbaar tijdstip als BAVAK
maken afspraak te selecteren waarbij rekening wordt
gehouden met de agenda's van de
behandelende medewerkers.
Beslisboom Een hiërarchie van vragen die de gebruiker Kode Loket
doorlopen naar de juiste beslissing leidt. Maakt het Amsterdam
mogelijk webformulieren of vragen op
webformulieren te selecteren.
Betalen Een functionaliteit die het mogelijk maakt het Credit card, Ogone,
verschuldigde bedrag) aan de rechthebbende Ideal Binnenhavengel
te doen toekomen. d
Debateren via Bulletin Board Viadesk
internet
Bijlagen - 55

hulpmiddel product
Publiceren Oracle, Atlas
geografische Mapguide Amsterdam
informatie
Kennisbank De representatie van kennissystemen in de Verity
ontsluiten vorm van een beslisboom of een verzameling
(ongestructureerde) gegevens met een
(geavanceerde) zoekfunctie.
Nieuws Abonneren op signalering van meest recente Nieuwsbriefedit
abonneren nieuwsitems or
Publiceren BEA Weblogic Portaal
ongestructure Portal Server Amsterdam
erde content
Publiceren Opvragen van openbare documenten door de Verity Bestuursinform
bestuursbeslui aanvrager zelf én het versturen van de atie on line
ten openbare informatie aan de burger door een
ambtenaar
Raadplegen Overzicht van alle gemeentelijke producten en Verity Loket
productcatalo diensten. Deze producten en diensten kunnen Amsterdam
gus zowel door de burger als door de ambtenaren
binnen de gemeente worden geraadpleegd.
Geautomatise Maakt het mogelijk om allerlei informatie die de Aspect Antwoord
erde klant via de website kan opvragen óók via de
Telefonische telefoon kan opvragen, menu-gestuurd,
Informatie volledige geautomatiseerd
Verstrekking
Telefoongids Registratie en publicatie van lijst van Zoek een
medewerkers plus contactgegevens collega…
Webformulier Een (HTML) formulier op het inter- of intranet. Mapguide Atlas
Deze webformulieren kunnen worden Amsterdam,
gegenereerd, gepubliceerd en gevolgd. Bestemmingspl
an
Classificeren
klantvraag
Uniformeren De aanvragen zoals deze via de kanalen zijn
klantvraag 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.
Vastleggen De geuniformeerde gegevens worden
klantprofiel vastgelegd bij het profiel van de klant
Bepaal Routering van de vraag naar de juiste
Prioriteit personen en/of afdelingen. Daarbij kan
eveneens de prioritering van afhandeling
worden vastgelegd.
Aanvullen Beoordelen en indien nodig aanvullen van de
klantbeeld gegevens van de aanvrager. Dit wordt meestal
bereikt door gegevens uit de
kernadministraties te verzamelen.
Completeren Op basis van het bekende klantprofiel van de
aanvraag 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 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 Meerdere applicaties naast elkaar, individueel Enterprise Portaal
presenteren bepaald, presenteren Content Amsterdam
Bijlagen - 56

hulpmiddel product
Management (BEA Weblogic
Portal Server)
Verzamelen Content (statische informatie met bijbehorende Portlets Portaal
content metagegevens, die kan bestaan uit een Amsterdam
combinatie van tekst, afbeeldingen, HTML, (BEA Weblogic
Word-documenten, PDF-files, audio en/of Portal Server)
video) moet zodanig beschikbaar worden
gesteld zodat per contenttype specifieke
bewerkingen mogelijk zijn
Zoeken Aan de hand van een zoekcriterium informatie Zoekmachine Verity
content terugvinden. Hierbij worden vaak meerdere
contentbronnen en applicaties doorzocht. De
zoekmachine indexeert hiertoe informatie uit
de verschillende contentbronnen.
Beheerfunctie
s
Redigeren Andreas; DIV;
dossiers Walvis; DECOS
Redigeren Hiermee kan de content van een website MmBase, Web-in-a-box;
teksten worden onderhouden, beheerd en WebOS, Plug-and-Play
gepubliceerd zonder dat technische kennis SmartSite, Iprox
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.
Afhandelen MS Outlook,
email Kana Response
Ontwerpen Voordat een formulier gepubliceerd wordt moet Kode
formulier het ontworpen worden. Ontwerp en publicatie
wordt vaak gedaan m.b.v. een
formulierensysteem.
Beheren
gebruikerslijst
Uitwisselen Het op een betrouwbare wijze verzenden,
berichten 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).
Basiscommun Tussen alle Amsterdamse gemeente- LAN, WAN E-net
icatie instellingen 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.
Koppelen Het regelen van de informatieoverdracht Adapter BEA Weblogic
tussen een integratievoorziening en de daarop Integration
aangesloten applicaties en systemen o.b.v. het
afgesproken berichtenprotocol.
Routeren Het plaatsen van berichten in een wachtrij (= Broker BEA Weblogic
tussentijdse opslag) , waarna de berichten in Integration
een bepaalde volgorde naar de bestemde
applicatie(s) worden verzonden.
Abonnemente Het vastleggen dat applicatie X geïnteresseerd Broker BEA Weblogic

ndienst is om bij een bepaalde gebeurtenis in Integration
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.
Bijlagen - 57

hulpmiddel product
Splitsen en Het combineren van verschillende Broker BEA Weblogic
filteren abonnementen om deze vervolgens te splitsen Integration
en te filteren tot enkelvoudige gebeurtenis-
checks bij de leverende applicaties.
Transformatie Het vertalen van één berichtenformaat (van de Broker BEA Weblogic
en translatie verzender) naar een ander berichtenformaat Integration
(van de ontvanger), waarbij de betekenis
(semantiek) dezelfde blijft. Bij translatie is
sprake van het vertalen van een dataformaat
naar een ander dataformaat.
Validatie Het beoordelen of de berichten juist, Broker BEA Weblogic
betrouwbaar en onweerlegbaar zijn. Dit staat Integration
ook bekend als transactie management.
Beveiligen Beveiliging tegen oneigenlijk gebruik van Broker
bericht berichten en de gegevens daarbinnen
Beheren Het uitwisselen van diensten tussen
services overheidsorganisaties en tussen overheid en
burger en bedrijfsleven, op basis van een
beschrijving van services die kunnen worden
afgenomen
service- Het beschikbaarstellen en onderhouden van Service Bus
registratie een centrale bibliotheek van services
(gids)
service (SLA) Het bewaken van de dienstverlening zoals die Service Bus -
management in een SLA is vastgelegd
service Operationeel management, waaronder het Service Bus -
monitoring loggen van berichten, nodig voor foutherstel,
beheer- en management informatie
Authenticeren Het proces waarbij een computer of applicatie
& autoriseren 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.
Registreren Het vastleggen van gebruikersnamen en I AM-server Active Directory
gebruikers bijbehorende passwords
Identificeren Identiteit controleren aan de hand van DigiD
I AM-server
gebruiker gebruikersnaam en password
Authenticeren Nagaan of een gebruiker, andere computer of Active
I AM-server
applicatie daadwerkelijk is wie hij beweert te Directory, DigiD
zijn
Autoriseren Het verlenen van toestemming voor gebruik Per applicatie Diverse
van een applicatie of service voor een
gebruiker met een bepaalde rol
Regisseren Het gecoordineerd aansturen van processen in
processen 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.
Proces- Het grafisch weergeven van een proces, zodat Business BEA Weblogic
modelleren uiteindelijk code in software gegenereerd kan proces Integration
worden. management
Procesregels Het 'opschrijven' van bedrijfsregels, zodat Business BEA Weblogic
vastleggen uiteindelijk code in software gegenereerd kan proces Integration
worden. management
Proces- Signaleren dat alle processen en Business BEA Weblogic
monitoring en terugkoppelingen verlopen binnen de proces Integration
bewaking vastgestelde tijdsgrenzen en zonodig management
escaleren/alarmeren
Proces inzage Het on line bekijken van de procesvoortgang. Business BEA Weblogic
proces Integration
management
Simuleren Het nabootsen van een proces o.b.v. het Business BEA Weblogic
vastgelegde procesmodel en -regels. proces Integration
management
Bijlagen - 58

hulpmiddel product
Toegang Om eenmaal aangeleverde (gestructureerde)
verlenen gegevens toegankelijk te houden voor alle
Registraties 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.
Distribueren Het distribueren van de basis- en Distributie- Paraplu / Diva
basis- en kerngegevens die op meerdere plekken binnen mechanisme
kerngegevens de gemeente wordt gebruikt en die de
gemeente centraal beheert. Distributie kan op
basis van een kennisgeving en/of
vraag/antwoord plaatsvinden.
Gegevens- Een kopie van de basis- en kerngegevens die Database Paraplu / Diva
magazijn alleen zijn te raadplegen, ten bate van de
gemeentebrede distributie en toegang.
Registreren Een zaak is een samenhangende hoeveelheid
zaken 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.
Kanalen De klant kan zijn vraag via verschillende Post, scannen,
ingangen stellen. Het proces Kanalen verwerkt telefoon,
de verschillende vraagvormen tot een uniforme webformulier
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.
Classificeren Na binnenkomst van een geüniformeerde
klantvraag 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.
Assisteren en Dit proces helpt de klant bij het beantwoorden -
informeren van zijn/haar vraag. Hiertoe staan
klant verschillende hulpmiddelen ten dienste, zoals
zoekfunctionaliteit, een productencatalogus,
een geleide zoekprocedure (vraagtrechter) etc.
Registreren Er wordt beoordeeld of er voldoende informatie -

zaak 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.
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
Bijlagen - 59

hulpmiddel product
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.
Behandelen In dit proces worden Primaire Processen (of -
zaak 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.
Zakenmagazij In het zakenmagazijn worden op centraal
n 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.
Procesgenerie
ke
functionaliteit
Beheren Personen, Bedrijven, Adressen, Percelen, Oracle GBS, VRA

Basisregistrati Gebouwen, Kadaster
es
Vastleggen Ongestructeerde data (documenten, beelden) Documentum Andreas
dossiers
Uitwisselen
gegevens
Sturen Staffware
werkproces
Geografische CAD Microstation
Informatie
Digitaal
archiveren
Management
functies
Rapporteren On line rapportage, schriftelijke rapporten Crystal Reports
Management
Business Operational sql
Intelligence Data Store,
Datawarehouse
, Datamart, ETL
Sturen Kennisdeling MS Office,
Projecten Viadesk
Ondersteunen
de functies
Personeel Salarisadministratie P-net
Informatie Helpdesk Topdesk; Limon
Juridische Afhandelen bezwaar en beroep; afhandelen KIM; Octopus;
zaken klacht BEB
Organisatie Administratieve Organisatie MAVIM; Protos
Financiën Financiële administratie Exact; FIS4all;
Civision;
Bijlagen - 60

hulpmiddel product
OneWorld;
Decade
Administratie
Huisvesting /
facilitair
Processpecifi
eke
functionaliteit
Ondersteunen Kantoorautomatisering MS Office

werkplek
Beheren Wegen (gladheid); Parkeergebouwen; ERP Epovision;
werkvoorraad Monumenten; Objectbeheer; Werkbeheer Planon; AMIS;
verlichting; Verkeersvoorzieningen; OBIN; OBS;
Wegopbrekingen; Kunstwerken; ASVV2004;
Verkeerslichten; Groenvoorzieningen; SCS; KIS; VBS;
Binnenwaterbeheer BBA
Behandelen Leerlingadministratie; Uitkeringen; ERISA; NUS-
zaak / Bouwvergunningen; Milieuvergunningen; OP; SVIS /
klantadministr Erfpacht; Belastingen; Vergunningen; BWT Systeem;
atie Horecavergunningen Stramis; EBS/
Hermez; Taxi;
Systeem
Horeca
Bijlagen - 61
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 referentie-

architectuur 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 Assisteren en BPM

Classificeren
Registreren
klantvraag
Klant Zaken
klant
gegevens dossier FO orkestratie
Product Zaaktype Openbare

catalogus catalogus informatie Registreren Beheren BO orkestratie
zaak zaak
Basisgegevens Behandelen zaak (Behandeldiensten)

B
Basis Kern
registraties registraties Legacy
Services
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
Toegang verlenen tot
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
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
Algemene, infrastructurele functies

Gemeenschappelijke
functies Integratiefuncties
Presentatiefuncties
Functies voor secundaire

bedrijfsprocessen
Procesgenerieke ict-functies inclusief

management en ondersteuning
Specifieke Processpecifieke functies voor primaire

bedrijfsprocessen
functies
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
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 applicatie-
eigen (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 Standaard Beheerorganisatie

Ontwikkelomgeving J2EE Sun?
.Net Microsoft
Presentatielaag HTML
Applicatielaag
Gegevensopslag en uitwisseling XML

Document opslag en uitwisseling ODF OASIS
Bijlagen - 72
Bijlage 17 Integratiearchitectuur:
Berichtenuitwisseling
In deze bijlage worden berichtuitwisselingsfuncties, zoals die in een berichten-

of 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
Registreren zaken
Toegang tot registraties

afspraken
leverende
applicatie
applicatie
vragende
Authenticeren & autoriseren
Beheren services services
Abonnementen Bericht Bericht Beveiliging

dienst transformatie validatie
Wachtrij / routering
adapter Berichten uitwisseling
berichtenbus adapter
netwerk netwerk
(ontleend aan EGEM)
Bijlagen - 75
Bijlage 18 Architectuurorganisatie:
Omschrijving
architectenrol
In deze bijlage zijn vooreeld funtiebeschrijvingen opgenomen van de

functionele en technische architectenrol.
Functioneel architecten rol

Omschrijving 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
Bijbehorende functie Senior adviseur middelen
Taken • 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)
Vereisten • 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
Omschrijving 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
Bijbehorende functie (Senior) adviseur middelen
Taken • Stelt de technische architectuur op en onderhoudt deze
Bijlagen - 76
• 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
Vereisten • 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 Voorbereidingsfase Realisatiefase Overgangsfase

Beslissen Resources
over project ter beschikking
Lijnmanager initatief stellen
Vaststellen Opstellen Borgen

Opstellen Vaststellen Vaststellen
Project Overdrachts project
startnotitie projectplan eindresultaat
opdracht document resultaat
Opdrachtgever
Maken Organiseren Opleveren

Maken Voortgangs
projectopdracht Project Start Up Project
projectplan bewaking
Projectleider resultaat
Maken Advisering
Controleren
Advisering Project nazorg
projectresultaat
architectuur 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

Hand Boe K Architect U Ur Amsterdam

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hand Boe K Architect U Ur Amsterdam

Uploaded by

Copyright:

Available Formats

Colofon

Dit handboek is door de Adviesgroep Architectuur opgesteld. Aan het

Dit gedrukte exemplaar wordt u aangeboden door Concern Organisatie,

Oplage: 250 exemplaren

Het college van B&W en de stadsdeelbesturen willen tot betere en

De wil om samen zaken aan te pakken is er. Niet alleen bij de

Tegelijk biedt het Handboek ook overzicht van en inzicht in de samenhang

Dit Handboek heeft u nogal wat te bieden: een gemeenschappelijke taal,

Maarten van Poelgeest

aanleiding Reeds in 2004 zijn voorstellen gedaan om de aansturing van de gemeentelijke

de noodzaak Waarom een architectuur? Omdat we zonder een gemeenschappelijke visie

management issue? En waar gaat het dan om bij die

communicatie Voor het (her)ontwerp van bedrijfsprocessen en bijvoorbeeld de organisatie

de samenhang Om onderscheid te kunnen maken tussen de

gegevens delen Als we bijvoorbeeld, op het niveau van de organisatiedoelstellingen, een

Samenvattend kan de betekenis en de noodzaak van een architectuur van de

samenhang • in de architectuur brengen we tot uiting hoe in Amsterdam de politieke

communicatie • een architectuurmodel kan ons helpen om aan te wijzen waar de

Een artist impression van de architectuur

laag 1: organisatie Het verhaal in grote lijnen. De

laag 2: proces Voor onze processen ligt daar

business alignment Er is een samenhang tussen de organisatielaag en de proceslaag. Op

laag 3: informatie Bij het uitvoeren van de

laag 4: applicatie De gegevens uit de basisregistraties zijn

laag 5: infra Op de onderste

channelmanagement Op naar de organisatielaag. De interactie met de klant kan via meerdere

zaakdossier De derde categorie betreft de zaakgegevens, benodigd voor een adequate

Zo’n model laat zien hoe nauwkeurig de onderlinge relaties van de

infrastructuur Database en functionaliteit samen noemen we een applicatie of een systeem.

Het fenomeen mid office

De redenering verloopt grosso modo via de volgende stappen:

• leidend zijn in ieder geval de business-doelstellingen:

• dat kan alleen maar met een

• vervolgens moet er natuurlijk een naadloze aansluiting zijn van de front

• vroeger was dat eenvoudig, één-op-

• dan moet er dus een voorziening

• die voorziening kan organisatorisch

• de organisatorische kant moet vooral tot uitdrukking komen in het her-

• de technische kant moet een vertaling krijgen in de informatie-huishouding

voor de komende tijd. De moeilijkheid zit erin om die overeenstemming over

vraagstukken De belangrijkste management issues voor de komende tijd zijn:

besluitvorming In een apart document (Management besluiten Architectuur) worden deze

laag 1: organisatie De belangrijkste kwesties op het niveau van de organisatie zijn:

De grote vraagstukken op deze laag zijn:

de belangrijkste processen? hebben we daarvoor de kennis en de

De actuele vraagstukken zijn:

laag 4: applicatie Op de applicatielaag hebben (open) standaarden en voorzieningen op het

De belangrijkste vragen zijn:

2 De Amsterdamse visie op architectuur........................................................................................1

9 Architectuurorganisatie en -proces .............................................................................................1

1) burger aan het stuur 1. De burger aan het stuur

onder meer: architectuur. Vanuit de concrete aanbevelingen uit het

1.2 Waarvoor dient de architectuur?

Model 1.1 Voorbeeld van een model

3 concrete afspraken (standaarden, beheer en beveiliging)

In hoofdstuk 2 lichten we de opbouw en reikwijdte van de architectuur van

1.3 Hoe kunt u dit Handboek gebruiken?

doelen De achterliggende doelstelling van de architectuur is om bij te dragen aan de

opbouw handboek Het handboek is als volgt opgebouwd:

Vanaf hoofdstuk 4 duiken we de inhoud in. Hoofdstuk 3 bevat een overzicht

Hoofdstuk 9 tenslotte beschrijft de wijze waarop de architectuur in de toekomst

expliciet stil bij de organisatie, rollen en verantwoordelijkheden rond de

2.1 Van ongeduld naar actie door samenwerking en