Colofon. Oplage: 250 exemplaren

Transcriptie

1

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

3 Voorwoord Het college van B&W en de stadsdeelbesturen willen tot betere en snellere onderlinge samenwerking komen. Dit om stadsbrede prioriteiten aan te pakken, de dienstverlening voor de Amsterdammer verder te verbeteren, het voortijdig schoolverlaten gezamenlijk aan te pakken, de openbare ruimte beter te beheren en regels te vereenvoudigen. Dit vormt de kern van de in juli 2006 door het college van B&W uitgebrachte notitie Van ongeduld naar actie: voorstellen voor versnelling. De wil om samen zaken aan te pakken is er. Niet alleen bij de bestuurders, maar ook op ambtelijk niveau. Dat heb ik de afgelopen maanden zelf ervaren in contacten met medewerkers van diensten, bedrijven en stadsdelen. De grote uitdaging is om deze wil om te zetten in concrete resultaten, om het vervolgens ook samen te doen. Dit Handboek Architectuur laat zien dat dit kan. Het draagt voor mij op twee manieren bij aan versterking van de samenwerking tussen de centrale stad en de stadsdelen: via de inhoud en het proces. Inhoud Effectieve samenwerking is alleen mogelijk wanneer de betrokkenen met elkaar kunnen communiceren. Dit Handboek biedt een gemeenschappelijke taal om te communiceren over de Amsterdamse organisatie en informatievoorziening. Zo zorgen we dat iedereen hetzelfde verstaat onder veel gebruikte, maar vaak moeilijk grijpbare termen als het hoofdproces Dienstverlening, basisregistraties of Antwoord. Tegelijk biedt het Handboek ook overzicht van en inzicht in de samenhang van de opbouw van de Amsterdamse organisatie en informatievoorziening. Daarmee is het een onmisbaar achtergronddocument voor iedereen die zich bezig houdt met de organisatie en informatievoorziening. Om eerlijk te zijn, zijn er bij mij ook kwartjes gevallen waardoor ik de samenhang tussen bijvoorbeeld verschillende initiatieven zoals Beter Presteren, het programma Basisregistraties en ICT-infrastructuur en het Servicehuis ICT beter ben gaan zien! Tenslotte geeft het Handboek ook een gezamenlijk kader voor ons toekomstig handelen. De in het Handboek opgenomen grondslagen en standaarden zijn concrete afspraken die we met elkaar hebben gemaakt. Deze afspraken zijn ook bestuurlijk vastgesteld door de stadsbrede Commissie Informatievoorziening waarin zowel bestuurders namens de stadsdelen als leden van B&W zitten. Deze afspraken zijn daarmee leidend voor het toekomstig handelen van iedereen die professioneel actief is in de Amsterdamse organisatie en informatievoorziening. 1

4 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

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

6 management issue? koppelen en delen communicatie de samenhang gegevens delen 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. 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. 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. 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. 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. management samenvatting - 2

7 één keer inloggen model met vijf lagen 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). 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. management samenvatting - 3

8 laag 2: proces business alignment laag 3: informatie laag 4: applicatie 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. 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. 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. 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. management samenvatting - 4

9 laag 5: infra de vijf lagen 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. 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. management samenvatting - 5

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

11 informatie En dan vanuit de proceslaag naar beneden: welke informatie is benodigd bij de uitvoering van de processen? De gegevens waarover het in de informatielaag gaat, kunnen in drie categorieën worden verdeeld. basisregistraties bedrijfsgegevens zaakdossier 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. 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. 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. management samenvatting - 7

12 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). management samenvatting - 8

13 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 ist en soll? 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. 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. management samenvatting - 9

14 Het fenomeen mid office mid office? apart onderdeel? 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? 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; management samenvatting - 10

15 vroeger was dat eenvoudig, één-opéén, elke dienst en elk stadsdeel zijn eigen loket aan de voorkant voor het eigen werkpakket aan de achterkant; maar anno nu willen we dat de gezamenlijke front office van 30 diensten plus 14 stadsdelen in principe alle ruim 500 gemeentelijke producten levert vanuit misschien wel even zovele back offices (M keer N); dan moet er dus een voorziening komen om die aansluiting optimaal te laten verlopen: het uitzetten van de vraag, het bewaken van de voortgang en het terugleveren van het resultaat; die voorziening kan organisatorisch van aard zijn (mensen, procedures) of technisch (computers) of beide, maar zal in ieder geval het aantal relaties reduceren (M plus N); de organisatorische kant moet vooral tot uitdrukking komen in het herontwerp van de primaire processen en de eventuele (her)inrichting van de organisatie; de technische kant moet een vertaling krijgen in de informatie-huishouding en de systemen: maak de basisgegevens voor iedereen beschikbaar en creëer een integratie- en uitwisselingsplatform. 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 management samenvatting - 11

16 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 besluitvorming laag 1: organisatie laag 2: proces 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. 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. 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? 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 management samenvatting - 12

17 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 internetaansluitingen zijn uit den boze, er moet een gemeenschappelijke voorziening komen voor identificatie, authenticatie en autorisatie (een I AM-server). En verder kan het beheer van de infrastructuur, technisch en logisch, beter worden belegd. Er spelen soortgelijke vragen als op de applicatielaag: hoever willen we ook hier gaan met gemeenschappelijkheid? hoever gaan we in onze standaardisering? management samenvatting - 13

18

19 Definitief Bestuursdienst Inhoudsopgave 1 Inleiding Aanleiding Waarvoor dient de architectuur? Hoe kunt u dit Handboek gebruiken? Leeswijzer De Amsterdamse visie op architectuur Van ongeduld naar actie door samenwerking en architectuur Vertaling programma- en bestuursakkoord Balans nodig tussen snelheid en samenhang De gefaseerde ontwikkeling van onze architectuur De reikwijdte van het Handboek Architectuur Het Amsterdamse architectuurraamwerk Grondslagen Inleiding Algemene grondslagen Grondslagen organisatiearchitectuur Grondslagen procesarchitectuur Grondslagen informatiearchitectuur Grondslagen applicatiearchitectuur Grondslagen infrastructuurarchitectuur Organisatiearchitectuur Inleiding Grondslagen Modellen Standaarden Beheer Beveiliging Conclusies Procesarchitectuur Inleiding Grondslagen Modellen Standaarden Beheer Beveiliging Conclusies Informatiearchitectuur Inleiding Grondslagen Modellen Standaarden Beheer Beveiliging Conclusies...21

20 7 Applicatiearchitectuur Inleiding Grondslagen Modellen Standaarden Beheer Beveiliging Conclusies Infrastructuurarchitectuur Inleiding Grondslagen Modellen Standaarden Beheer Beveiliging Conclusies Architectuurorganisatie en -proces Inleiding Architectuurorganisatie Architectuurproces Standaarden Beheer Conclusies...15

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

22 onder meer: architectuur. Vanuit de concrete aanbevelingen uit het Vooronderzoek Shared Service Organisatie ICT 1 is daarom het initiatief genomen in het kader van het Programma Basisregistraties en ICTinfrastructuur om te komen tot een architectuur voor het concern Amsterdam. Het vormt tegelijk ook één van de pijlers van het Meerjarenplan Informatiemanagement. 1.2 Waarvoor dient de architectuur? bestemmingsplan voor toekomstige organisatie en informatievoorziening Een architectuur geeft op hoofdlijnen weer hoe de verschillende componenten en initiatieven in de organisatie en de informatievoorziening in elkaar grijpen, zowel functioneel als technisch. Een architectuur beschrijft op samenhangende wijze een gewenste situatie. Dit Handboek Architectuur vormt daarmee het bestemmingsplan voor de toekomstige organisatie en informatievoorziening van Amsterdam. We kijken daarbij circa 4 jaar vooruit. architectuur bevat grondslagen, modellen, standaarden, beheer en beveiliging Dit klinkt allemaal nog abstract. Wat vinden we concreet in dat bestemmingsplan? Om het simpel te zeggen bevat dit handboek 1 richtinggevende en kaderstellende uitspraken (grondslagen) bijvoorbeeld De gemeente Amsterdam opereert consistent, als één concern, als integraal onderdeel van de overheid of Gegevens worden éénmalig opgeslagen en meervoudig gebruikt 2 beschrijvende platen (modellen) bijvoorbeeld een typologie van een organisatie met een front, mid en back office Model 1.1 Voorbeeld van een model 3 concrete afspraken (standaarden, beheer en beveiliging) bijvoorbeeld De Gemeentelijke Basisadministratie (GBA) van de Dienst Persoonsgegevens is de standaard voor persoonsgegevens of het Servicehuis ICT is de beheerder van E-net In hoofdstuk 2 lichten we de opbouw en reikwijdte van de architectuur van Amsterdam verder toe. 1 Collegebesluit B&W, 22 juni 2004, 2004/8386: 3 de 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

23 1.3 Hoe kunt u dit Handboek gebruiken? doelgroep: professionals rond Andere Overheid Dit handboek is geschreven voor iedereen die professioneel betrokken is bij de vormgeving van de Andere Overheid. Denk daarbij aan het top- en middenmanagement, procesvernieuwers, projectleiders, architecten, systeemontwikkelaars en ICT-beheerders. 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

24 1.4 Leeswijzer gebruik de index architectuur in duidelijke en begrijpelijke taal opbouw handboek 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 zoek- en vindtocht zo kan worden voortgezet. Dit laat onverlet dat juist bij een architectuur de samenhang der dingen van groot belang is. Om deze samenhang te tonen is een uitgebreide managementsamenvatting opgenomen. Ook beginnen alle inhoudelijke hoofdstukken met een inleiding. Dit alles zo veel mogelijk in duidelijke en begrijpelijke taal. Ideaal dus voor geïnteresseerde bestuurders, managers en mensen die voor het eerst te maken krijgen met architectuur. 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

25 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

26

27 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 concern In de visie van Amsterdam kan dit in onze stad alleen succesvol gebeuren wanneer we concernbreed samenwerken op allerlei niveaus, zoals: Samenwerking tussen stadsdelen en centrale stad Samenwerking tussen diensten, bedrijven en stadsdelen onderling Samenwerking binnen diensten, bedrijven en stadsdelen Samenwerking op het niveau van het topmanagement, middenmanagement en de werkvloer Samenwerking tussen organisatieontwerpers en informatici architectuur als noodzakelijke voorwaarde Om deze samenwerking te ondersteunen is inzicht in de samenhang nodig, een gemeenschappelijke taal en een bestemmingsplan voor de realisatie van de Andere Overheid inclusief gemaakte afspraken. Dit komt samen in architectuur. In onze visie is werken onder architectuur een noodzakelijke voorwaarde om de Andere Overheid te realiseren. 3 Idealiter bouwt de architectuur voort op een vastgesteld concernbreed informatiebeleidsplan. Aan het informatiebeleidsplan wordt momenteel gewerkt en voor de zomer 2007 verwacht. 2-1

28 2.2 Vertaling programma- en bestuursakkoord INFORMATIE- ARCHITECTUUR INFORMATIE BELEID INFORMATIE- PLANNING Beleidsvisie Afstemming met bedrijfsbeleid Bedrijfsmodel Globaal bedrijfsinformatiemodel Beleidsrealisatierichtlijnen Model van informatievoorziening Architectuurplannen Lange-termijnplan Middellange-termijnplan Korte-termijnplannen richten inrichten UITVOERING Systeemontwikkeling of aanschaf gebruik, exploitatie en onderhoud uitvoeren Bron: Meerjarenplan Informatiemanagement informatiebeleidsplan, architectuur en planning De vertaling van het programma- en bestuursakkoord en de betekenis voor de informatievoorziening en ICT wordt beschreven in het informatiebeleidsplan. Het informatiebeleidsplan beschrijft hoe we de informatievoorziening kunnen gebruiken (richten) en stelt functionele kaders (als een integraal onderdeel van het organisatiebeleid). De belangrijkste pijlers in het informatiebeleidsplan voor de komende periode zijn de acht thema s uit het programma- en bestuursakkoord: voortijdig schoolverlaten, jeugdzorg, invoering Wet Maatschappelijke Ondersteuning (WMO), overlast van jeugdgroepen, geweld achter de voordeur (huiselijk geweld), economische ontwikkeling, dienstverlening en regelgeving/handhaving, In het verlengde hiermee is het handboek architectuur een hulp- en communicatiemiddel en een toetskader gericht op gebruik door professionals die zich bezighouden met de organisatie en informatievoorziening. Het geeft via concrete grondslagen, modellen, standaarden en beheerprocedures een beschrijving van de inrichting van informatievoorziening en de bouwkundige kaders waarbinnen gewerkt moet worden (inrichten). Op basis van het informatiebeleid en de architectuur wordt vanuit de twee invalshoeken (inrichten en richten) een (informatie)planning opgesteld met programma s en projecten om de cruciale informatie- en ICT-voorzieningen te realiseren (uitvoeren). 2-2

29 2.3 Balans nodig tussen snelheid en samenhang 4 perfecte architectuur? samenhang vs. ontwikkelaars met oogkleppen 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. Architectuur geeft structuur, een rode draad en vastigheid. Het verkrijgen van samenhang vergt reflectie op het functioneren van de organisatie en de informatievoorziening. Dat betekent onderzoek, afstemming en planning. En dat kost tijd, zoals ook samenwerken tijd kost. Aan de andere kant vraagt de roep om een Andere Overheid door burgers, ondernemers en politici om snelheid. Er bestaat dan ook een continu spanning tussen snelheid en samenhang bij het realiseren van businessdoelen door ICT-oplossingen. Wie snel wil zijn, heeft geen tijd om met anderen af te stemmen of plannen te maken ( quick & dirty ontwikkelaars ). Wie omgekeerd verder kijkt dan het (eigen)belang van dit moment, zal niet altijd de snelste weg naar zijn doel bewandelen. een goede architectuur vindt balans tussen snelheid en samenhang Zowel snelheid als samenhang zijn essentieel voor een efficiënte en effectieve inzet van ICT en beide worden ook steeds belangrijker. Slaat de balans door naar snelheid, dan rijzen de kosten de pan uit, weten partners niet meer van elkaar waar ze mee bezig zijn, blijken belangrijke gegevens onvindbaar en zal uiteindelijk de burger die vragen heeft van het kastje naar de muur worden gestuurd. Slaat de balans door naar samenhang, dan loopt de organisatie het risico prachtige producten en diensten op de markt te zetten, maar te laat wanneer de burgers en bedrijven er geen behoefte meer aan hebben of ze zijn achterhaald door nieuwe ontwikkelingen. Kader: Is architectuur een hype? De geschiedenis laat zien dat de relatie tussen bedrijfsprocessen en de informatievoorziening in de loop der jaren fundamenteel is gewijzigd. Hierin moet ook de opkomst van architectuurdenken worden geplaatst. In de jaren 70 en 80 van de vorige eeuw veranderden bedrijfsprocessen 4 Deels ontleend aan DYA; snelheid en samenhang in business en ICT-architectuur, Sogeti Nederland B.V. 2-3

30 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: een eerste stap Architectuur is in de Amsterdamse visie een middel om de juiste balans te vinden tussen snelheid en samenhang bij het realiseren van de Andere Overheid. Het is geen doel op zich, maar nadrukkelijk een instrument. Het is een bescheiden Zwitsers zakmes voor de professional in de informatievoorziening. Waarom bescheiden? Het werken onder architectuur staat in Amsterdam net als bij veel andere organisaties- in de kinderschoenen. In juli 2005 is een start gemaakt toen vanuit de Stuurgroep Basisregistraties en ICT-Infrastructuur het initiatief is genomen tot een concernbrede. De eerste versie van dit handboek vormt het resultaat van ruim één jaar denken, praten over en ontwikkelen van architectuur. Daarmee zetten we een forse eerste stap, niets meer en niets minder. nu: nadruk op stimuleren samenwerking en BRI toetskader voor nieuwe ontwikkelingen De nadruk van deze eerste versie ligt op het faciliteren en stimuleren van samenwerking door het bieden van inzicht en overzicht, en het aanreiken van richtlijnen en standaarden die primair zijn gericht op (de ontwikkeling van) gemeenschappelijke voorzieningen voor de gemeente Amsterdam en het programma Basisregistraties en ICT-voorzieningen in het bijzonder. Het handboek is bedoelt als toetskader en richtlijn voor nieuwe ontwikkelingen, projecten en vervanging van bestaande systemen. In het handboek zijn standaarden en richtlijnen opgenomen om de samenwerking vorm te kunnen geven. De architectuur is richtinggevend, maar het is voorstelbaar dat bij het realiseren van een specifieke business doelstelling (bijvoorbeeld bij uitzonderlijk veel tijdsdruk) bewust wordt afgeweken van de architectuur. Wel lijkt het redelijk om de bewijslast te leggen bij de partij die wil afwijken. Zie Hoofdstuk 9 voor de uitwerking van de architectuurorganisatie en proces. 2-4