Hoe maak ik een architectuurplaat voor mijn eigen gemeente.

Transcriptie

1 Hoe maak ik een architectuurplaat voor mijn eigen gemeente.

2 Inhoud 1 Inleiding Ontstaan van de GEMMA IA platen met een midoffice structuur Basisplaat Basisplaat Basisplaat Structuur en spelregels Te stellen vragen bij het maken van een eigen plaat Voorkom misverstanden De midoffice in de GEMMA-platen is (g)een organisatorische eenheid De midoffice is (g)een applicatie Kiezen tussen een midoffice- of een servicegerichte architectuur Basismateriaal en meer informatie Auteur: KING Datum: 2010 Versie:

3 1 Inleiding Gemeenten staan voor de uitdaging om hun dienstverlening aan burgers en bedrijven te verbeteren en daarnaast te zorgen voor een efficiënte interne organisatie. Daarvoor is het nodig de eigen informatiehuishouding te vernieuwen en aan te sluiten op landelijke e-overheidvoorzieningen. Gemeenten staan daarbij voor inrichtingskeuzen. Welke gegevens en functionaliteit (informatiefuncties) heb ik nodig? Wat regel ik met eigen informatiesystemen? En wat haal ik van elders door aan te sluiten op landelijke voorzieningen en systemen bij ketenpartners? KING kan niet de lokale details invullen, maar ondersteunt gemeenten wel met oplossingsrichtingen die zijn vastgelegd in GEMMA, de GEMeentelijke Model Architectuur. GEMMA is de landelijke referentiearchitectuur voor het inrichten van zowel de bedrijfsprocessen van gemeenten als de informatievoorziening. GEMMA bestaat uit meerdere architectuurproducten. Daarvan is de GEMMA Informatiearchitectuur (GEMMA IA) de referentie voor de gemeentelijke informatievoorziening. De GEMMA IA is gebaseerd op landelijk beleid en andere voor gemeenten relevante ontwikkelingen zoals de visie van de commissie Jorritsma (de gemeente als meest nabije overheid voor burgers en bedrijven), zaakgericht werken en het aansluiten op landelijke basisregistraties. Met het volgen van de GEMMA IA bij de inrichting van de informatiehuishouding kiest een gemeente voor een richting die daaraan invulling geeft. Omdat in de GEMMA IA oplossingen op hoofdlijnen al zijn uitgewerkt, scheelt dat de denkwerk. Daarnaast leidt het volgen van de GEMMA IA tot standaardisatie, waardoor de eigen informatievoorziening beter zal aansluiten op die van ketenpartners en op de landelijke e- overheidvoorzieningen. Aldus wordt een belangrijke voorwaarde ingevuld voor samenwerking van de gemeente met andere partijen binnen de overheid. Dat is belangrijk om als gemeente invulling te geven aan haar rol van meest nabije overheid, en in de toekomst meer dan nu een vooruitgeschoven post te worden van de rest van de overheid. Omdat de GEMMA IA ontwikkelingen en bijbehorende oplossingsrichtingen zichtbaar maakt, en dat vooral op hoofdlijnen doet, helpt het gemeenten om op een beheersbare manier sturing te geven aan noodzakelijke vernieuwingen. Doel en Doelgroep Dit document legt uit hoe een gemeente op basis van de inhoud van de GEMMA IA eigen architectuurplaten kan maken voor het voeren van de juiste discussies over te maken keuzes. De doelgroep van dit document bestaat primair uit afdelingshoofden ICT, informatiemanagers, coördinatoren I&A, beleidsmedewerkers informatievoorziening, adviseurs I&A, informatiearchitecten en systeemontwerpers. Maar in principe is de inhoud interessant voor allen die bij een gemeente actief meedenken over het thema elektronische overheid, de vernieuwing van de informatievoorziening en te maken keuzes. 3

4 De inhoud van de GEMMA IA De GEMMA IA beschrijft de bekende gemeentelijke midofficearchitectuur en bevat begrippen en concepten, modellen, principes en standaarden. De modellen in deze architectuur hebben de vorm van architectuurplaten. Deze zijn als basisplaten op drie niveaus beschikbaar: 1. met informatiefuncties op hoofdlijnen, ook wel het conceptuele niveau genoemd; 2. met informatiefuncties op detailniveau; 3. met concrete systemen (voor gemeenten) en (landelijke) voorzieningen. Waarom architectuurplaten? Een architectuurplaat is vooral een krachtig communicatiemiddel. Het ondersteunt de discussie in de fase van nadenken over ambities, ontwerpen en afstemmen. En als een plaat definitief is en is vastgesteld, maakt het op een visuele en toegankelijke manier zichtbaar waar een organisatie naar toe wil, in dit geval met het inrichten van de eigen informatiehuishouding. Opzet van dit document Dit document geeft een toelichting op het ontstaan van de gemeentelijke midofficearchitectuur en de bestaande GEMMA Informatiearchitectuurplaten. Daarbij beschrijft het de spelregels voor het lezen en maken van de platen. Ook worden vragen weergegeven die een gemeente zich moet stellen bij het maken van eigen informatiearchitectuurplaten. Tevens wordt ingegaan op lastige thema's waarover soms misverstanden ontstaan, om af te sluiten met verwijzingen naar meer informatie. 4

5 2 Ontstaan van de GEMMA IA platen met een midoffice structuur Eind 2002 publiceerde het ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) het rapport Architectuur elektronische overheid. Het hierin opgenomen advies, dat werd benoemd als 'Niet kantelen, maar koppelen' leidde tot het ontstaan van de gemeentelijke midofficearchitectuur. Daarin zorgt een elektronische midoffice (geen organisatorische afdeling) voor de verbinding tussen de informatiesystemen van de vakafdelingen in de backoffice met de elektronische dienstverlening aan burgers en bedrijven in de frontoffice. Dit concept is destijds uitgewerkt in gemeentelijke basisplaten, waarvan in deze handreiking de nieuwste versies zijn opgenomen. Deze platen worden besproken in de hierna volgende paragrafen. 2.1 Basisplaat 1 Basisplaat 1 schetst op hoofdlijnen een inrichting voor in principe elke gemeente (terwijl de overige platen details laten zien waaruit gemeenten - bewust en selectief (!) - kunnen kiezen). Figuur 1: Basisplaat 1 Het gemeentelijke deel van basisplaat 1 (de bovenste helft) toont de informatiefuncties op hoofdlijnen die elke gemeente in enigerlei vorm nodig heeft. Hoe een gemeente dat concreet invult, dus hoe zwaar en uitgebreid en met welke systemen, hangt af de ontwikkelingsfase waarin een gemeente zich bevindt en de ambities en mogelijkheden van de gemeente. Een andere belangrijke factor, vooral bij vernieuwing en aanschaf van software, is de al bestaande omgeving. 5

6 De onderste helft van de plaat staat voor de externe omgeving en toont de informatiefuncties op hoofdlijnen op landelijk niveau en bij ketenpartners. 2.2 Basisplaat 2 Basisplaat 2 toont, nog steeds op functioneel niveau, meer details. De getoonde functies zijn deels mogelijke varianten, waaruit gemeenten bewust en selectief moeten kiezen. Zo kan een gemeente de generieke informatiefunctie Zakenbeheer, die in de brede betekenis van de functies staat voor het beheren, besturen en bewaken van zaken, lichter en zwaarder invullen; dit afhankelijk van haar ambities en de ontwikkelingsfase waarin de gemeente zich bevindt. Bij alleen het geautomatiseerd registreren van zaken worden gegevens over een zaak geautomatiseerd vastgelegd en ontsloten. Maar de besturing en bewaking vindt, met gebruikmaking van deze gegevens, nog handmatig plaats (a in figuur 2). Meer geavanceerd is een oplossing met geautomatiseerde werkstromen, waarbij het werk overigens nog wel door mensen wordt uitgevoerd (human workflow automation, oftewel optie b). En nog een stap verder komen we op het niveau van geautomatiseerde aansturing van procesuitvoering door geautomatiseerde systemen, een variant overigens die gemeenten in de praktijk nu nog maar voor weinig producten en zaaktypen kunnen toepassen (optie c). Combinaties van deze opties, dus functies, komen overigens ook voor. a b c Figuur 2: basisplaat 2 6

7 2.3 Basisplaat 3 Basisplaat 3 is een plaat op het niveau van concrete systemen. Na keuzes op functioneel niveau, is dit een plaat dat het denken over aan te schaffen software - op basis van functionele behoeften en keuzen ondersteunt. Het onderste deel van de plaat toont - in een geclusterde vorm - algemene of sectorale e-overheidvoorzieningen op landelijk niveau. Figuur 3: basisplaat 3 7

8 Een van basisplaat 3 afgeleide plaat is de plaat in figuur 4. Deze plaat toont in het onderste landelijke deel de in het NUP opgenomen e-overheidvoorzieningen. In het gemeentelijke deel van de plaat komen die voorzieningen terug op een plaats waar de functies van deze voorzieningen, na aansluiting, voor de gemeente beschikbaar komen. Zo vinden we DigiD daar terug in de frontoffice en de functionaliteit van landelijke dossiervoorzieningen komen in de midoffice beschikbaar. De afgeleide plaat met ingetekende landelijke voorzieningen is meer dan de andere platen een nog niet uitgekristalliseerde plaat. Nader inzoomen op de architectuur van de afzonderlijke landelijke voorzieningen zal, of zou, ongetwijfeld leiden tot nieuwe inzichten en het hier en daar bijstellen van de positionering van die voorzieningen in de plaat. Figuur 4: basisplaat met NUP onderdelen 8

9 3 Structuur en spelregels In de GEMMA basisplaat staan de bovenste drie kolommen voor de interne inrichting van de gemeentelijke informatiehuishouding. Via de interne verbindingsfunctie en een landelijke infrastructuur is die interne omgeving verbonden met sectorale voorzieningen in ketens en overheidsbrede voorzieningen op landelijk niveau (zoals bijvoorbeeld de basisregistraties). De belangrijkste spelregels voor het vullen van op GEMMA gebaseerde gemeentelijke informatiearchitectuurplaten zijn: De frontofficekolom in het gemeentelijke deel van de plaat bevat de functies en oplossingen voor het aannemen en uitvoeren van de klantcontacten. Daarnaast komen hier de verschillende kanalen binnen waarlangs burgers, bedrijven en instellingen contact hebben met de gemeente. De backofficekolom bevat alle sectorspecifieke oplossingen op afdelingsniveau. De midofficekolom bevat alle generieke sectoroverstijgende functies en oplossingen die beschikbaar moeten zijn voor de gehele gemeentelijke organisatie. Ook positioneren we hier de centrale verbindingsfunctie (technisch gezien in de vorm van een zogenoemde broker) die informatiesystemen binnen en buiten de organisatie onderling koppelt. De platen op de al genoemde niveaus 1 (conceptueel of functioneel op hoofdlijnen) en 2 (functioneel op detailniveau) worden gevuld met informatiefuncties. Wanneer de nadruk ligt op gegevensopslag wordt daarbij soms het symbool van een cilinder gebruikt (platen niveaus 2 en 3). Wel gaat de GEMMA IA er vanuit dat vrijwel elk informatiesysteem bestaat uit een combinatie van een gebruikersinterface (de presentatielaag), functionaliteit en gegevens. In de GEMMA IA-platen worden informatiesystemen over het algemeen niet naar deze onderdelen uitgesplitst; niet in de platen op functioneel niveau en niet in de platen die concrete (mogelijke) systemen tonen. Zo'n uitsplitsing naar onderdelen speelt geen rol bij de spelregels voor het vullen van de kolommen in de platen. Anders gezegd: het zijn slechts de regels zoals hierboven in het kader geformuleerd, die bepalen wat in welke kolom wordt geplaatst. Aldus opgezet kan met de platen goed het gemeentelijke migratieverhaal worden verteld: - ontsluiten gegevens in de backoffice voor gebruik in de mid- en de frontoffice; - het standaardiseren van aanvankelijk sectorspecifieke informatiefuncties tot generieke functies die in de midoffice beschikbaar voor gebruik door de gehele organisatie. 9

10 4 Te stellen vragen bij het maken van een eigen plaat. Platen ondersteunen te voeren discussies en zijn daar ook het resultaat van. Daarbij is het belangrijk de juiste vragen te stellen. Hieronder een aantal suggesties. 1. Hoe werkt mijn gemeente nu en hoe mijn gemeente in de toekomst werken? Denk aan Zaak- en procesgericht werken. Denk aan betere dienstverlening. Wat zijn de ambities en de mogelijkheden van de gemeente. Zijn of komen er samenwerkingsverbanden in beeld voor het uitvoeren van de primaire bedrijfs processen of voor het inrichten, beheren en gebruiken van de informatievoorziening? 2. Hoe willen wij dat vertalen naar een te vernieuwen informatiehuishouding? Met aandacht voor de interne informatievoorziening. Plus aandacht voor de informatievoorziening naar de burger (klantgerichte dienstverlening). 3. Welke gegevens en informatiefuncties moeten daarvoor beschikbaar zijn? De SOLL-situatie. 4. Hoe ziet de bestaande informatievoorziening van mijn gemeente eruit? Welke gegevens en informatiefuncties zijn al beschikbaar? Dus de IST-situatie. 5. Wat is het verschil (de gap) tussen de bestaande (IST) en gewenste (SOLL-)situatie? 6. Wat vergt dat aan nieuwe te implementeren informatiefuncties? 7. Wat biedt de softwaremarkt aan opties om die gewenste aanvullende functionaliteit in te vullen? Wat zijn belangrijke ontwikkelingen op de softwaremarkt? Wat zijn de toekomstvisies van potentiële leveranciers? Hoe wordt of blijf ik onafhankelijk van softwareleveranciers? Hoe voorkom ik zoveel mogelijk 1 een vendor-lockin? 1 Het streven naar leveranciersonafhankelijkheid moet geen absoluut karakter krijgen. Voor kleine gemeenten is het soms juist verstandig bepaalde zaken aan een softwareleverancier over te laten. Het accepteren van een zekere mate van afhankelijkheid kan dan onderdeel zijn van een goede en weloverwogen strategie. 10

11 Zijn de op de markt beschikbare systemen zoveel mogelijk voorzien van standaard koppelvlakken? 8. Welke systemen zou mijn gemeente daarvoor moeten aanschaffen en implementeren? Sluiten die systemen aan op de bestaande omgeving? En op de systemen van partners waarmee nu of in de toekomst wordt samengewerkt? Moet de bestaande software worden aangevuld? Of moet er ook software worden vervangen? Leidt dat tot het afschrijven van nog niet afgeschreven software? 9. Of, in de plaats van aanschaffen, op welke externe systemen kan of moet ik daarvoor aansluiten? Denk aan de landelijke e-overheidvoorzieningen? Denk ook aan de doelstellingen en termijnen zoals opgenomen in het NUP. Denk aan externe sectorale systemen bij ketenpartners. 10. Wat zijn de consequenties daarvan in termen van financiële middelen, implementatieinspanningen en veranderingen in de manier van werken? En is het haalbaar om dat allemaal met succes in te vullen. 11

12 5 Voorkom misverstanden 5.1 De midoffice in de GEMMA-platen is (g)een organisatorische eenheid Het begrip midoffice is destijds door de opstellers van het al genoemde BZK-rapport Architectuur elektronische overheid 'geleend' uit de wereld van organisatiestructuren. In die wereld staat de midoffice voor dat deel van de organisatie dat de frontoffice verbindt met de backoffice. In het genoemde BZK-rapport is het gebruikt als concept voor het met processen, informatievoorzieningen en communicatievoorzieningen verbinden van de front- met de backoffice 2. In de GEMMA informatiearchitectuur bestaat die midoffice daarom uit informatie- en communicatievoorzieningen (voor bijvoorbeeld de informatiefunctie Zakenbeheer en de communicatiefunctie Verbinden). De midoffice in de IA-platen moet daarom niet worden opgevat als een organisatorisch eenheid. Dat geldt overigens voor de gehele GEMMA-architectuur. GEMMA gaat onder andere over bedrijfsprocessen en de gemeentelijke informatiehuishouding, maar doet geen uitspraken over de organisatiestructuur van een gemeente. 5.2 De midoffice is (g)een applicatie De gemeentelijke midoffice en de zogenoemde midofficesuite worden vaak met elkaar verward. De midoffice binnen de GEMMA-architectuur is het concept om de back- en de frontoffice van een gemeente met elkaar te verbinden. Dit concept gaat pas werken wanneer het invulling krijgt op softwareniveau. Dit laatste kan op meerdere manieren. Dus een concept, maar meerdere varianten om het in te vullen en operationeel te maken. Een van de varianten bestaat uit de aanschaf van een geïntegreerde softwareoplossing van één leverancier in de vorm van een zogenaamde midofficesuite. Zo'n suite vult alle of in ieder geval een substantieel deel van de benodigde midofficefuncties in. De leverancier zorgt dat de verschillende onderdelen (de informatie- en verbindingsfuncties) van de suite goed op elkaar zijn afgestemd en samenwerken. Voor gemeenten die de integratieproblematiek van meerdere onderling te koppelen applicaties liever overlaten aan een leverancier, kan zo'n suite een goede oplossing zijn. Een andere variant om op softwareniveau invulling aan de midoffice te geven is de zogenoemde best of breedoplossing. Per in te vullen midofficefunctie schaft de gemeente dan de meest geschikte software aan. Het resultaat is dan een midoffice met meerdere applicaties van veelal verschillende leveranciers. De consequentie daarvan is dat de gemeente zelf de koppelingsproblematiek tussen de applicaties oplost of het oplossen ervan minstens coördineert. Discussies over de voor- en nadelen van een midofficesuite in een specifieke lokale situatie zijn dus belangrijk, omdat het gaat om de keuze van de juiste software. Waar zo'n discussie echter wordt opgevat als een discussie over de voor- en nadelen van het midofficeconcept, is helaas meestal sprake van een lastig misverstand. En wel omdat het midofficeconcept daarbij vaak juist het uitgangspunt is. En de terecht te voeren discussie dus gaat over voor- en nadelen van softwarevarianten. 2 Eigenlijk andersom, want het ging en gaat er vooral om om de backoffice met meerdere sectorale afdelingen en sectorspecifieke systemen en gegevens te ontsluiten naar en te verbinden met de nieuwe enkelvoudige (want één website voor de gehele organisatie) en klantgerichte frontoffice van de gemeente. 12

13 Overigens bestaat een andere softwarevariant eruit dat een gemeente gebruik maakt van zogenoemde ASP-software (Application Service Provider), ook wel SaaS genoemd (Software as a Service), die elders draait en via internet beschikbaar is. Het samenwerkingsverband GovUnited biedt dergelijke software aan, met als voordeel dat de gemeente zelf zich minder druk hoeft te maken over systeemintegratie (koppelen systemen) en het technisch beheer van systemen. Omdat dit document niet primair over de aanschaf van software gaat, gaan we hier niet verder op in. 5.3 Kiezen tussen een midoffice- of een servicegerichte architectuur Het midoffice concept van GEMMA verbindt de backoffice met de frontoffice, ontsluit gegevens in de backoffice op die manier naar de klanten en ontsluit die gegevens tevens naar de gehele organisatie. Dat kan een gemeente met verschillende oplossingen realiseren, ook met een servicegeoriënteerde architectuur (Service Oriënted Architecture oftewel SOA) of oplossingen die niet volledig servicegeoriënteerd zijn, maar wel kenmerken van zo'n architectuur vertonen. Wat is servicegerichte architectuur? In de kern houdt serviceoriëntatie in dat men interacties tussen partijen organiseert als diensten die aanbiedende partijen leveren aan vragende partijen. De vragende partijen bepalen zelf wat ze vragen en wat ze doen met de verkregen resultaten. Dit concept oftewel deze manier van denken en ontwerpen kan men toepassen op verschillende niveaus: 1. organisatieniveau. De werkprocessen worden georganiseerd als diensten van de organisatie en van organisatieonderdelen aan klanten en andere organisaties, maar ook als diensten tussen organisatieonderdelen; 2. het niveau van informatiesystemen. De functies van informatiesystemen zijn diensten die deze systemen leveren aan processen en aan andere systemen. Waar informatiesystemen modulair zijn opgezet en de organisatie deze modulair kan combineren, zijn ook de functies van en tussen de modules opgezet als diensten; 3. het interne niveau van informatiesystemen. Bij een volledige servicegeoriënteerde omgeving bestaat programmatuur ook intern uit services. Het denken in (in principe herbruikbare) services is dan doorgevoerd tot het niveau van softwarecomponenten op microniveau. Dat kan, maar hoeft niet gecombineerd te zijn met serviceoriëntatie op de hier benoemde niveaus 1 en 2. Soms namelijk kiest een softwareontwikkelaar er puur om eigen redenen van onderhoudbaarheid en flexibiliteit voor om zo de interne structuur van een informatiesysteem op te zetten; 4. serviceoriëntatie op het niveau van de onderliggende technologie (het fysiek opslaan van bits en bytes op een harde schijf is een dienst die kan worden aangeroepen, het verlenen van toegang tot een printer in het netwerk idem). Serviceoriëntatie in brede zin vraagt om invulling op elk van deze niveaus. Zo'n architectuur wordt georganiseerd op minimaal het niveau van de gehele organisatie. Op dat niveau wordt dan de standaardisatie, herbruikbaarheid, de vindbaarheid en het beheer van de services geregeld. Maar ook op het niveau van een sectorale keten of op het niveau van de landelijke samenwerking in het kader van de e-overheid kan men streven naar zo'n architectuur. Bij die architectuur hoort ook dat over alle diensten afspraken worden gemaakt en dat men die vastlegt in Service Level Agreements (SLA's), dus ook de afspraken over diensten tussen organisatieonderdelen dus binnen een organisatie. 13

14 Serviceoriëntatie en een midofficearchitectuur Omdat zo'n architectuur is gericht op het creëren van generieke en herbruikbare services zullen veel services dan een plek in de midoffice krijgen. In die midoffice treffen we tevens, indien beschikbaar, de servicecatalogus aan voor de vindbaarheid van services. Bij zo'n servicegeoriënteerde architectuur verdwijnt de midoffice dus niet, maar wordt deze juist meer en meer gevuld. Functionaliteit die voorheen verstopt zat in de backoffice, wordt generiek en komt in die midoffice beschikbaar voor de gehele organisatie. Uiteindelijk zal de backoffice dunner worden, maar nog wel steeds de resterende puur taakspecifieke functionaliteit bevatten. Koppelvlakken Het standaardiseren van berichten en koppelvlakken is een belangrijke stap richting serviceoriëntatie. Daarmee geeft een organisatie namelijk invulling aan één van de meest fundamentele principes voor het ontwerpen van een servicegeoriënteerde architectuur. Omgekeerd leiden de standaarden die nodig zijn voor het definiëren van services (functionaliteit plus afspraken over de betekenis van te leveren gegevens) tot de gewenste interoperabiliteit van systemen. Uiteindelijk gaat het om een combinatie van Gemma-standaarden (RSGB, RGBZ en StUF) en webservicestandaarden (WSDL, UDDI, SOAP, ebms en Digikoppeling), waarbij de GEMMAstandaarden zelf (StUF is helemaal geschikt voor serviceoriëntatie) dus al een belangrijke stap richting serviceoriëntatie vormen. De keuze voor SOA moet geen automatisme zijn Hoewel een volledig servicegeoriënteerde architectuur grote voordelen biedt in termen van standaardisatie, herbruikbaarheid, flexibiliteit (snel aanpassen van de informatiehuishouding aan veranderende behoeften) en duidelijkheid over wat partijen van elkaar kunnen verwachten, vraagt zo'n architectuur veel van een organisatie. Grote gemeenten die er voor kiezen en het goed en succesvol aanpakken verwachten er veel mee te winnen in termen van herbruikbaarheid, onderhoudbaarheid en flexibiliteit. Voor veel andere gemeenten zal het zelf opzetten en beheren van een gemeentebrede servicegeoriënteerde omgeving echter - om redenen van schaalgrootte, kennis en capaciteit - minder haalbaar zijn. Een gemeente die serieus aan de slag wil met een servicegeoriënteerde architectuur moet ook kiezen hoe grof of fijnmazig (granulariteit) men zo'n architectuur wil invullen. Een andere keuze betreft het technologieplatform (bijvoorbeeld tussen J2EE oftewel Java 2 Enterprise Edition of het.net-platform van Microsoft). Combineren kan wel, maar is lastiger en werkt soms minder goed dan een duidelijke keuze voor een van de twee platforms. En een gemaakte technologiekeuze heeft vervolgens consequenties voor de op de markt beschikbare informatiesystemen die men kan aanschaffen. Tenslotte is het zaak dat de gemeente nadenkt over wat men zelf wil doen, wat men wil overlaten aan de markt (standaard software) en wat men in opdracht wil laten uitvoeren door softwarebouwers, leveranciers en systeemintegrators. 14

15 Conclusie midoffice en SOA Er is geen sprake van een tegenstelling tussen een midoffice- en een servicegeoriënteerde architectuur. Gezien de complexiteit van een servicegeoriënteerde architectuur (en de hoge eisen die een succesvolle invulling van zo'n architectuur stelt aan een organisatie, is het voor het gemeentelijke veld wel een onderwerp dat om nuances vraagt. In dat verband is de hoe- en in welke mate-vraag voor de meeste gemeenten passender, dan een simpele keuze voor of tegen SOA. Anders gezegd: SOA is niet noodzakelijk, maar standaardisatie van koppelvlakken op basis van StUF en bij voorkeur de webservicesvariant wel. Dat laatste is een goede stap in de richting van een SOA. Het realiseren van verdergaande vormen van serviceoriëntatie kan heel zinvol zijn, maar zal altijd het resultaat moeten zijn van bewust te maken keuzes en inzicht in zowel de eisen die een succesvolle aanpak aan de organisatie stelt als de voordelen die dat kan opleveren. 15

16 6 Basismateriaal en meer informatie. Voor het maken van eigen platen kunnen gemeenten gebruik maken van basismateriaal waaronder een lege plaat zoals in figuur 5. De lege basisplaat is zowel in JPG-formaat als in het bronformaat van MS Visio beschikbaar. Zie voor meer informatie over GEMMA en voor elektronische versies van de platen de website van KING: en volg op die site de verwijzingen naar GEMMA en de onderdelen van GEMMA. Voor specifieke vragen kan men een sturen naar Figuur 5: lege basisplaat gemeentelijke informatiearchitectuur 16

17 Bezoekadres: Nassaulaan JS Den Haag Postadres: Postbus GK Den Haag T: F: