Koppelingen Beleid voor het koppelen van informatiesystemen
In opdracht van Status Versie Redactie Datum
Math Muijres (CIO) Jaap Bakker Concept 0.5 Mark Slooff 21-01-2010
Versie 0.1 0.2
Datum 11-11-2009 17-11-2009
0.3
15-12-2009
0.4
07-01-2010
0.5
21-01-2010
Versie 0.4
Datum 13-01-2010
Versie 0.1 0.2 0.3 0.4 0.5
Datum Diverse data 17-11-2009 05-01-2010 11-01-2010 21-01-2010
Versiebeheer Wijzigingen Hoofdleegstort versie Structurering document, focus aan brengen en verwijderd aanpak voor opstellen Business Case. Opmerkingen John van Eck verwerkt, waardoor de structurering van het document nog scherper is geworden. Daarnaast nog inhoudelijk aanscherpingen (3-lagenmodel en StUF). Opmerkingen Ton Mol verwerkt, hoofdstuk 7 toegevoegd. Beslisboom verplaatst naar bijlage 2. Opmerkingen van Jurn Raaijmakers over beslisboom verwerkt Goedkeuring Naam
Functie
BMO Distributielijst Naam Jaap Bakker, Jurn Raaijmakers, Alie Versteeg John van Eck, Ton Mol, Jaap Bakker Ton Mol BMO Via Mozaiek ter beschikking gesteld
2
Auteur Mark Slooff Mark Slooff
Mark Slooff
Mark Slooff
Mark Slooff
Status Goedgekeurd
Inhoudsopgave Inhoudsopgave ...................................................................................................... 3 1 Inleiding ......................................................................................................... 4 1.1. Aanleiding ............................................................................................... 4 1.2. Achtergrond ............................................................................................. 4 1.3. Doelstelling.............................................................................................. 6 1.4. Doelgroep................................................................................................ 7 1.5. Leeswijzer ............................................................................................... 7 1.6. Bronnen .................................................................................................. 7 2 Begrippenkader................................................................................................ 8 2.1. Koppeling ................................................................................................ 8 2.2. Kloppeling ............................................................................................... 8 2.3. Batch ...................................................................................................... 8 2.4. Bericht .................................................................................................... 8 2.5. ETL ......................................................................................................... 8 2.6. Webservice .............................................................................................. 9 2.7. SOA ........................................................................................................ 9 2.8. XML ........................................................................................................ 9 2.9. Enterprise Service Bus ............................................................................ 10 2.10. Overheid Service Bus........................................................................... 10 2.11. Standaard UitwisselingsFormaat (StUF) ................................................. 10 2.12. Forum Standaardisatie ......................................................................... 11 3 Een koppeling… .............................................................................................. 12 3.1. …tussen de zaak en het werkproces .......................................................... 12 3.2. …tussen leverancier van basis- of kernregistraties en afnemers .................... 12 3.3. …met een landelijke voorziening............................................................... 13 3.4. …met een ketenpartner ........................................................................... 14 4 Drie lagen ..................................................................................................... 15 5 Probleemschets .............................................................................................. 17 5.1. Geautomatiseerde koppeling, makkelijk gezegd ......................................... 17 5.1.1 Een koppeling is de oplossing?! ............................................................. 17 5.1.2 Definities ........................................................................................... 17 5.1.3 Verwachtingen .................................................................................... 18 5.2. Daarom StUF! ........................................................................................ 18 6 Implementatievormen .................................................................................... 20 6.1. Harde en Zachte koppelingen ................................................................... 20 6.2. Distributie of vraag/antwoord (push of pull) ............................................... 20 6.3. Spaghetti of Lasagne?! ............................................................................ 20 6.3.1 Spaghetti?.......................................................................................... 20 6.3.2 Lasagne! ............................................................................................ 21 7 Beleid ........................................................................................................... 22 7.1. Inhoud, logistiek en transport .................................................................. 22 7.2. Consequenties ....................................................................................... 22 7.3. Comply-or-explain .................................................................................. 22 Bijlage 1: Standaardenlijst .................................................................................... 23 Bijlage 2: Beslisboom ........................................................................................... 24 Inleiding .......................................................................................................... 24 Inhoud ............................................................................................................ 24 Logistiek .......................................................................................................... 25 Transport ......................................................................................................... 25
3
1 Inleiding 1.1. Aanleiding Er is een duidelijke ambitie binnen de overheid om integrale dienstverlening te verlenen, zodat het voor een burger of bedrijf niet relevant is hoe de organisatie (Gemeente, BV Overheid of SCD) dit verder georganiseerd heeft. Hierbij spelen 1-loket ontwikkelingen een belangrijke rol (Klant Contact Centrum, Overheid heeft antwoord, maar ook het serviceplein). Dit ene loket geldt niet alleen voor een enkel kanaal. De wens is tevens om ongeacht het kanaal een eensluidende afhandeling en antwoord/resultaat te verkrijgen. Dit betekent dat er een loskoppeling van de traditionele decentrale loketten van de processen naar gecentraliseerde loketten moet plaatsvinden. Dit heeft een aantal gevolgen. Het centrale loket moet ongeacht het kanaal op een zelfde wijze een aanvraag aanmaken, in uitvoering geven bij een specialist, het resultaat terugkrijgen en communiceren richting aanvrager. Hierbij is te allen tijd inzicht in de voortgang (status) gewenst. Een substantieel deel van de contacten hebben betrekking op de voortgang. We hebben voor zaakgericht werken gekozen om de ontkoppeling te realiseren tussen “klantproces” en werkproces. De afstemming tussen deze twee werelden kan handmatig maar ook geautomatiseerd plaats vinden. Naast bovengenoemde afstemming is er de ambitie om eenmalig gegevens te registreren en meervoudig te gebruiken. Zodat er niet naar de bekende weg gevraagd hoeft te worden. Er moet dan wel de beschikking zijn over die gegevens, die verzameld en geregistreerd worden op andere plekken (bijv. bij het Kadaster, RDW, enz.) Verder spelen er vragen om bijvoorbeeld financiele gegevens uit te wisselen tussen “reguliere” processystemen en het centrale financiële systeem en koppelingen met ketenpartners. De hoeveelheid aan koppelwensen en de verschillende manieren waarop een koppeling tot stand gebracht kunnen worden, betekent bij onvoldoende waarborgen een wirwar van koppelingen die moeilijk in stand te houden zijn. Dit document geeft richtlijnen voor de implementatie van koppelingen.
1.2. Achtergrond Koppelen begint een steeds belangrijkere rol te spelen in de huidige informatievoorziening. Uitspraken hierover doen is vanuit beheersoptiek erg wenselijk. In de Nederland Overheid Referentie Architectuur (NORA) wordt er van uitgegaan dat de overheid gaat werken volgens een Service Gerichte Architectuur (SGA), ookwel Service Oriented Architecture (SOA) inclusief gebruik van servicebussen. Hiermee wordt beoogd redundantie zoveel mogelijk in te perken, zowel op functioneel gebied als op gegevensgebied. Titel
Applicaties voeren services van slechts één functioneel domein uit.
4
Principenummer Beschrijving Toelichting
principe 6.1.1.2 Applicaties voeren services van slechts één functioneel domein uit. Voor elke dienst, die geleverd wordt aan burgers en bedrijven draagt één overheidsorganisatie de eindverantwoordelijkheid. In paragraaf 5.1 is daarnaast het principe besproken “Functies van organisaties zijn transparant”. Combinatie van deze principes levert het beeld op van helder gedefinieerde functionele domeinen, die via services met elkaar samenwerken aan de levering van producten en diensten aan burgers en bedrijven. De overheid als een netwerk, bestaande uit vele organen, die via koppelingen aan elkaar services verlenen. Het is duidelijk welke services een organisatie levert. Om dezelfde reden wordt geadviseerd om ook applicaties binnen organisaties ook slechts één bedrijfsfunctie te laten ondersteunen en deze door middel van services met elkaar samen te laten werken. Hiermee komen de eerder genoemde voordelen van de SGA ook volledig tot hun recht. Zodra dit principe wordt losgelaten verdwijnt de gewenste transparantie en bouwen we de probleemgevallen (spaghettistructuren) van de toekomst.
Titel Principenummer Beschrijving
Toelichting
Organisaties en applicaties werken samen op basis van services principe 6.1.1.3 Organisaties en applicaties die in verschillende functionele domeinen werkzaam zijn, werken met elkaar samen op basis van services. Dit principe is hierboven toegelicht. Ter aanvulling hierop kan gesteld worden dat dit principe niet alleen van toepassing is als het om elektronische dienstverlening gaat, maar dat dit ook wordt toegepast bij samenwerking op basis van andere communicatiekanalen (telefoon, post of persoonlijk contact).
De manier waarop intern gekoppeld gaat worden, staat niet voorgeschreven in bijvoorbeeld NORA. Het lijkt voor de hand liggend dat dit ook door middel van services gedaan gaat worden. Op dit moment ontbreken voldoende gestandaardiseerde koppelvlakken om dit ook daadwerkelijk breed in te voeren. In een aantal gevallen is het nog maar af te vragen of een geautomatiseerde koppeling rendabel is. In het document Architectuurprincipes Dienstverlening zijn voor koppelingen de onderstaande principes geformuleerd. Nummer: Afkomst: Principe:
AK-1 GEMMA Thema's en Kernprincipes Binnen de regio worden koppelvlakken/services op het niveau van zowel functionaliteit, gegevens en techniek volgens daarvoor vastgestelde internationale, landelijke en/of gemeentelijke standaarden gestandaardiseerd.
Motivatie:
Verre gaande standaardisatie brengt hoge besparingen met zich mee. Dit geeft een invulling aan het tot stand brengen van hoge mate van interoperabiliteit. Zie ook AG-4.
5
Nummer: Afkomst: Principe:
AK-2 GEMMA Thema's en Kernprincipes, NOiV Zowel interne als externe koppelingen (andere gemeenten, ketenpartners en landelijke voorzieningen) worden door middel van gestandaardiseerde koppelvlakken/services gedaan.
Motivatie:
Gestandaardiseerde koppelingen dringen de kosten terug bij realisatie en onderhoud van koppelingen. Belangrijke bijdrage aan interoperabiliteit tussen systemen.
Nummer: Afkomst: Principe:
AK-3 GEMMA Thema's en Kernprincipes Vanwege de groeiende afhankelijkheid door het gebruik van koppelingen worden deze koppelingen op een centrale plek bijgehouden.
Motivatie:
Het centraal brengen van het beheer van koppelingen heeft als voordeel dat de samenhang tussen systemen en impact bij eventuele wijzigingen goed ingeschat kunnen worden.
Nummer: Afkomst: Principe:
AK-4 CIO Op basis van een Business Case wordt bepaald of een koppeling ontwikkeld wordt. Hierbij geldt: • Een terugverdien periode van maximaal 2 jaar • Of een kwalitatief aantoonbare verbetering van de gegevensuitwisseling en/of dienstverlening De Business Case wordt door de CIO en CIO office beoordeeld en adviseert de opdrachtgever. De opdrachtgever bekostigt zowel de incidentele kosten als de structurele kosten.
Motivatie:
Het is belangrijk dat er een efficiënt werkende informatievoorziening komt/is binnen de Drechtsteden. Op basis van een kosten/baten-analyse wordt een goed inzicht gegeven in de effectiviteit van een gewenste koppeling. De termijn van twee jaar terugverdienperiode ligt opgesloten in het feit dat bij langere termijnen de kans dat een applicatie (grondig) wordt gewijzigd en de koppeling moet worden aangepast groot is. De verwachte levensduur van een koppeling in de praktijk is dus maximaal 2 jaar.
Binnen het programma IP&A is een pilot uitgevoerd om de bruikbaarheid van een servicebus te beproeven. Een servicebus wordt gebruikt als een intelligente intermediair tussen services. Service worden dan niet 1-op-1 gekoppeld, maar met de servicebus. Hiermee wordt het beheer van deze services eenvoudiger. In theorie maakt een servicebus het mogelijk om de ene service aan te passen zonder dat direct effect heeft op het andere koppelvlak. Door de servicebus te configureren kan deze het verschil opvangen.
1.3. Doelstelling Het doel van dit document is kaders te stellen en handreikingen te geven bij koppelingsvraagstukken en is een verdieping op de eerder genoemde principes.
6
1.4. Doelgroep De doelgroep van dit document bestaat uit de volgende rollen die een rol spelen op het informatie- proces- en automatiseringsterrein: • •
Projectleiders Adviseurs
1.5. Leeswijzer In hoofdstuk twee worden begrippen toegelicht zodat het document vanuit een gemeenschappelijk begrippenkader wordt gelezen. In hoofdstuk 3 wordt een verdieping gemaakt van de soorten koppelingen. In hoofdstuk 4 wordt een verdieping gemaakt in de problematiek van koppelingen. Hoofdstuk 5 beschrijft de verschijningsvormen van een koppeling. Hierbij wordt direct het voor- en nadeel aangegeven. In hoofdstuk 6 worden implementatievormen van koppelingen beschreven. Hoofdstuk 7 bevat de conclusie van de voorgaande hoofdstukken en geeft het daadwerkelijke beleid inclusief consequenties. In bijlage 1 is een lijst met standaarden opgenomen. Bijlage 2 beschrijft een beslisboom voor distributie van gegevens en een beslisboom voor vraag/antwoord berichten.
1.6. Bronnen De volgende bronnen zijn geraadpleegd en voor een deel overgenomen bij de totstandkoming van dit document: • • • • •
Nora 3.0 Strategie Katern GEMMA architectuurprincipes NORA 2.0 Cursus StUF EGEM-iteams StUF: De betekenis van berichten (Henri Korver)
7
2 Begrippenkader Een gemeenschappelijk begrippenkader is belangrijk. Hieronder staan een aantal belangrijke begrippen opgesomd.
2.1. Koppeling Een geautomatiseerde gegevensuitwisseling tussen twee systemen. Hierbij valt te denken aan gegevensuitwisseling tussen een backoffice en een onderdeel van de midoffice (of andersom), een backoffice en een ander backoffice, een midoffice met een landelijke voorziening, een backoffice met een landelijke voorziening en/of onderdelen van de front- en/of midoffice met elkaar. Er zijn altijd twee partijen bij een koppeling. Aan beide kanten van de koppeling zal iets geregeld moeten zijn. Bij de ene om te sturen en de andere om te ontvangen. Wanneer er twee richting verkeer geldt moet dit voor beide kanten gelden. We noemen dit ook wel een koppelvlak. Dit is een definitie hoe de ene kant iets verstuurd, de ontvangende kant heeft een definitie hoe deze iets ontvangt.
2.2. Kloppeling Een kloppeling is een handmatige koppeling tussen twee systeem waarbij de gegevens van het ene systeem wordt “overgeklopt” in het andere systeem. Dit is de meest basale manier van gegevensuitwisseling van het ene systeem naar het andere systeem. Wanneer er relatief weinig gegevens uitwisseling plaatsvindt is dit financieel gezien vaak een rendabele oplossing. Het nadeel is dat bij het overkloppen van gegevens tikfouten kunnen plaatsvinden en wordt het overkloppen door medewerkers als vervelend beschouwd.
2.3. Batch Een batch is een verzameling wijzigingen die in een totaalpakket wordt ontrokken aan een bronsysteem en aangeboden aan het doelsysteem. Bij een batch valt te denken aan het periodiek uitwisselen van gegevens tussen twee systemen. Bijvoorbeeld na afloop van elke dag worden de mutaties uit het ene systeem verzameld, in een bestand weggeschreven. Dit bestand wordt door een ander systeem opgepakt en ingelezen. Het nadeel van deze systematiek is dat het doelsysteem altijd een bepaalde tijd achterloopt op een ander systeem.
2.4. Bericht Een bericht is een afgeronde hoeveelheid informatie (met een begin en een eind) die van een verzender naar een ontvanger verstuurd wordt (Bron: Wikipedia). Vaak is een bericht een enkele wijziging die van het bronsysteem naar het doelsysteem wordt verstuurd. Meestal worden berichten direct na een wijziging in het bronsysteem verzonden naar het doelsysteem, zodat de afwijkingen tussen de systemen binnen een relatief kleine tijdseenheid zijn weggewerkt.
2.5. ETL ETL is de afkorting voor Extraction, Transformation and Load. De term ETL staat voor een groep technologieën die veelal gebruikt worden bij de koppeling tussen systemen,
8
waarbij er gestreefd wordt naar een minimale technische en semantische koppeling tussen de systemen. Het is een batchproces dat regelmatig gebruikt wordt. (Bron: Wikipedia). De inhoud van de stappen is als volgt: • Extract = leest data van een bron en pakt het gewenste pakket uit • Transform = Zet opgenomen data om, gebruik makende van regels, opzoektabellen of maakt combinaties van data van verschillende bronnen • Load = schrijft de data naar een gewenst doel
2.6. Webservice Een webservice kan omschreven worden als een interface van een systeem die toegankelijk is via standaard webprotocollen en waarbij wordt gecommuniceerd via XML zonder menselijke tussenkomst. Een webservice maakt het mogelijk om op afstand (meestal over het intranet of internet) vanaf een systeem een dienst op te vragen aan een andere systeem, bijvoorbeeld het maken van een berekening, het leveren van gegevens of het uitvoeren van een taak.
2.7. SOA Service-Oriented Architecture (SOA) is een architectuurmodel, geen technologie op zich. Centraal bestaat een SOA opgebouwd systeem service contracten. Hierbij is sprake van afnemers van diensten en leveranciers (Bron: Wikipedia). Kenmerkend voor de diensten (en contracten) is: •
•
•
• •
Een service is virtueel: de afnemer heeft geen weet van de implementatie van de dienst. De dienst is onafhankelijk van de afnemer. Scheiding van verantwoordelijkheid is expliciet vastgesteld. Voordeel hiervan is onafhankelijkheid van veranderingen van afnemer en leverancier. Voldoen aan het contract staat immers centraal; Een service is gestandaardiseerd: er is slechts één implementatie aanwezig van een verantwoordelijkheid. Voordeel is het rationaliseren van de standaard. Standaardiseren=massa, massa=kassa. De dienst wordt 'commodity' en eenvoudig te vervangen door een andere leverancier of goedkoper door een efficiëntieslag; Een service is modulair (vervangbaar) en compositioneerbaar. Standaard is niet flexibel. Flexibiliteit wordt bereikt door combineren (componeren) van standaards tot een nieuwe standaard; Een service is abstract: generiek, niet afgestemd voor 1 specifieke afnemer, maar op een doelgroep van afnemers; Losgekoppeld: afnemer en leverancier zijn maximaal onafhankelijk van implementatie van beide. Elke service is daarom autonoom. Er bestaat geen directe link of relatie tussen verschillende services. Services zijn zich ook niet van elkaar bewust.
In de NORA (Nederlandse Overheidsreferentie architectuur) wordt voor een groot deel uitgegaan van een Service-Oriented Architecture.
2.8. XML Extensible Markup Language (XML) is een standaard van het World Wide Web Consortium voor de syntaxis van formele markuptalen waarmee men gestructureerde gegevens kan weergeven in de vorm van platte tekst. Deze representatie is zowel
9
machineleesbaar als leesbaar voor de mens. Het XML-formaat wordt gebruikt om gegevens op te slaan en om gegevens over het internet te versturen (Bron: Wikipedia). XML-talen gebruiken zogenaamde elementen en attributen om gegevens te structureren. De XML-specificatie definieert de syntaxis van elementen, attributen en de andere structuren die in XML-bestanden kunnen voorkomen. De XML-specificatie legt echter geen namen vast voor deze elementen en attributen, precies omdat deze keuze afhangt van het doel van het XML-bestand.
2.9. Enterprise Service Bus Een Enterprise Service Bus (ESB) is een systeem waarmee de communicatie tussen de afnemers van diensten (“service”) en aanbieders hiervan, vereenvoudigd wordt. De ESB biedt hiertoe aan de kant van de aanvrager een met de aanvrager afgesproken interface aan, dit kan een webservice zijn, maar bijvoorbeeld ook een SMTP (e-mail) interface en tal van andere mogelijkheden. Aan de kant van de aanbieder zal de ESB via de interface die met de aanbieder is afgesproken communiceren. Zo kan het dus zijn dat een aanvrager van een dienst op een compleet andere wijze met de ESB communiceert dan de ESB met de aanbieder.
2.10.
Overheid Service Bus
In het geval van koppelingen met landelijke voorzieningen schrijft NORA het gebruik van de Overheid Service Bus (OSB) voor (comply-or-explain). De Overheidsservicebus verzorgt de logistieke kant van het berichtenverkeer en omvat standaarden om berichten juist te adresseren en veilig en betrouwbaar te kunnen verzenden. Dat betreft zaken als: • • • •
Naar welk adres moet een bepaalde serviceaanvraag gestuurd worden? Hoe kan de serviceaanbieder met zekerheid vaststellen wie de aanvrager is? Hoe kan zeker worden vastgesteld dat de inhoud van een bericht alleen maar door de juiste partijen kan worden bekeken? Hoe kan er vanuit worden gegaan dat een bericht is aangekomen, zonder dat de geadresseerde een inhoudelijk bericht hoeft terug te sturen?
Deze logistieke zaken handelt de Overheidsservicebus af aan de hand van informatie die op de 'envelop' van het bericht wordt geplaatst. De Overheidsservicebus bemoeit zich alleen met de 'envelop' en voert uit wat daar op staat: adres, aangetekend of niet, herhaald aanbieden, terugsturen naar afzender enzovoort.
2.11.
Standaard UitwisselingsFormaat (StUF)
StUF is een universele berichtenstandaard voor het elektronisch uitwisselen van gegevens tussen applicaties. Het domein van de StUF-taal omvat informatieketens tussen overheidsorganisaties (basisregistraties en landelijke voorzieningen) en gemeentebrede informatieketens en -functionaliteit. StUF is beschreven in XML en gebaseerd op geaccepteerde internetstandaarden. StUF staat op de lijst met open standaarden van het Forum Standaardisatie en is hiermee erkend als overheidsbrede open standaard. Binnen het toepassings- en werkingsgebied geldt het 'pas toe of leg uit'-regime. Meer informatie over StUF is te vinden op www.egem-iteams.nl/stuf.
10
2.12.
Forum Standaardisatie
Open standaarden bevorderen de digitale uitwisseling van informatie, oftewel interoperabiliteit. Met behulp van open standaarden vereenvoudigt de communicatie tussen (semi-)overheden onderling en tussen overheid, bedrijven en burgers. Ook vergroot het gebruik van open standaarden de onafhankelijkheid van softwareleveranciers. Het College en Forum Standaardisatie zijn de instellingen die adviseren over het gebruik van open standaarden.
11
3 Een koppeling… Dit hoofdstuk geeft een verdieping op soorten koppelingen die gewenst kunnen zijn, Hierbij valt te denken aan: 1. 2. 3. 4.
Een Een Een Een
koppeling koppeling koppeling koppeling
tussen de zaak en het werkproces tussen leverancier van basis- of kernregistraties en afnemers met een landelijke voorziening met een ketenpartner
3.1. …tussen de zaak en het werkproces Zoals al eerder aangegeven is een zaak klantgericht en een werkproces gericht op de correcte afhandeling door medewerkers. Een zaak gaat uit van statussen, een werkproces gaat uit van stappen. Een aantal afgeronde stappen kan leiden tot een statuswijziging van de zaak. Telefoon
Post
Web
Balie
Zaak Status 1
Status 2
Stap 1
Stap 4
Status 3
Status 4
Stap 6
Stap 7
Werkproces
Stap 2
Stap 3
Stap 5a
Stap 5b
Door de zaakgerichte aanpak is het ook mogelijk om integrale managementinformatie te verkrijgen. Om op zaakniveau te kunnen koppelen is het uitermate belangrijke te bepalen welke stappen in het proces leiden tot een statuswijziging. Verder is de inhoud van het eventueel terug te koppelen bericht naar de klant ook van groot belang.
3.2. …tussen leverancier van basis- of kernregistraties en afnemers Het is/wordt verplicht om gegevens uit de basisregistraties te gebruiken. Op deze manier wordt enkelvoudige registratie, meervoudig gebruik nagestreefd. Dit vanuit de optiek de burger/ondernemer niet naar de bekende weg te vragen, maar ook een overheid die zich niet voor de gek laat houden.
12
Per basisregistraties zijn op hoofdlijnen de volgende processen te onderkennen. De verschillende processen kunnen afhankelijk van de organisatorische inrichting bij diverse partijen belegd zijn.
Onderstaand een aantal voorbeelden met verschillende verantwoordelijken: Basisregistratie
Bronproces
Registratieproces
Personen (GBA) Adressen en Gebouwen (BAG)
Burgerzaken (Gemeente) Bouw en Wonen (Gemeente)
Kadaster
Kadaster
Burgerzaken (Gemeente) GEO-informatie (SCD), Bouw en Wonen (Gemeente) Kadaster
Landelijke beschikbaar stelling BZK VROM/Kadaster
Kadaster
Wanneer een afnemend proces een afwijking constateert is deze verplicht dit terug te melden. Voor het terugmelden is ook een landelijke voorziening ingericht. Naast de basisregistraties zijn er ook kernregistraties. Deze zijn in twee vormen te onderscheiden. De ene heeft een wettelijke basis en werkt eigenlijk op een zelfde manier als de basisregistraties. Denk hier bijvoorbeeld aan de Wet Kenbaarheid Publiekrechtelijke Beperkingen (WKPB). De andere vorm bestaat uit gegevens die veelvuldig in de regio gebruikt worden, maar niet zijn opgenomen in een basisregistratie. Denk hier bijvoorbeeld aan gegevens van medewerkers, afdelingen en financiën.
3.3. …met een landelijke voorziening Bij het gebruik van gegevens uit de basisregistratie is de landelijke voorziening al genoemd. Naast deze vorm van een landelijke voorziening zijn er meer te noemen. Denk bijvoorbeeld aan de Omgevingsloket Online. Hierbij wordt een zaak door middel van een externe trigger gestart. Dit willen we natuurlijk ook op een zelfde manier afhandelen en voortgang bewaken als voor andere zaken geldt.
13
3.4. …met een ketenpartner Doordat een groot aantal activiteiten in de afgelopen jaren verzelfstandigd of aan de markt toevertrouwd zijn, zijn ook op dit vlak ook veel raakvlakken. Hierbij valt bijvoorbeeld te denken aan onderhoud van het groen en grijs (stoepen, straten, enz.).
De organisatiegrens in het bovenstaande plaatje kan ook de grens van de eigen afdeling zijn in processen die afdelingsoverstijgend zijn.
14
4 Drie lagen Een koppeling tussen twee processen bestaat feitelijk uit drie lagen. Dit zijn: • • •
Inhoudelijk: Wat wordt er uitgewisseld en welke betekenis heeft het. Logistiek: Hoe komt het van A naar B. Transport: Over welk protocol gaat dat.
Op al deze niveau’s moeten er afspraken zijn om op een correcte manier informatie uit te wisselen. Onderstaande figuur geeft een voorbeeld hoe dit verder ingevuld zou kunnen worden.
15
In de onderste laag bevinden zich de transportprotocollen zoals TCP/IP. Daarboven bevindt zich de logistieke laag waarin de wereld (helaas) verdeeld wordt door twee concurrerende standaardenfamilies: de ebXML-familie afkomstig van OASIS en de WUSfamilie afkomstig van W3C. In de specificaties van de OverheidsServiceBus zijn deze internationale standaarden verder ingevuld en zodanig op maat gesneden dat beide families zo goed mogelijk kunnen samenwerken. In de bovenste laag bevinden zich de semantische standaarden die zich richten op de inhoud berichten waaronder ebXML, StUF en XBRL. We zien dat deze standaarden werken vanuit een domeinmodel van waaruit berichtschema’s worden afgeleid. Semantische berichtstandaarden beperken zich veelal tot een specifiek toepassingsgebied. Bijvoorbeeld ebXML is een standaarden-familie die ontstaan is in de zakelijke wereld en richt zich onder meer op orders en facturen. XBRL wordt gebruikt bij de uitwisseling van financiële (jaar)rapportages. StUF is ontstaan uit de ontsluiting van (overheids)systemen zoals het GBA voor persoonsregistratie. StUF richt zich dus hoofdzakelijk op de berichtuitwisseling tussen registratieve systemen waar wettelijke en juridische aspecten een rol spelen.
16
5 Probleemschets 5.1. Geautomatiseerde koppeling, makkelijk gezegd 5.1.1 Een koppeling is de oplossing?! Er wordt snel geroepen als een overdracht binnen een proces niet optimaal loopt dat er maar een koppeling moet komen. Of soms al direct bij een nieuw proces. Hierbij wordt voorbij gegaan aan de complexiteit van het maken van een koppeling en uiteindelijk het beheer. De grootste complexiteit in afstemming ligt met name op het inhoudelijke niveau. Als er bij de overdracht binnen het proces geen afstemming is over definities en verwachtingen, gaat een koppelingsproject alleen maar frustratie opleveren.
5.1.2 Definities De grootste oorzaak van problemen zit in de definities van gegevens. Deze worden vaak veroorzaakt door verschillen in wetgeving of door (verschillen in) inzichten van leveranciers. Voorbeelden hiervan zijn: •
•
In de BAG mag een straatnaam maximaal 80 karakters hebben, in de GBA is dit 25 (met de komst van de basisregistraties zal dit geleidelijk naar elkaar toegroeien). Het valt te begrijpen dat iets van 80 karakters niet zomaar in 25 gestopt kan worden. In het ene systeem wordt het adres in een aantal losse velden geplaatst ( straatnaam, huisnummer, huisletter, toevoeging) in andere gevallen staat dit in één veld.
In het proces worden dit soort dingen door menselijke interpretaties/inzichten opgelost, dit gaat bij een koppeling extra kosten met zich mee brengen of in sommige gevallen niet functioneren. Een voorbeeld van de definitieproblematiek op basis van een koppeling van nawgegevens: Versturende partij Gegeven Lengte opmerking Voornaam 40 karakters Tussenvoegsel 6 karakters 40 karakters Achternaam 80 karakters Straatnaam Numeriek Huisnummer 1 karakter Huisletter 5 karakters Toevoeging 30 karakters Woonplaats
Ontvangende partij Gegeven Lengte opmerking Naam 80 karakters Alle velden 50 karakters moeten Adres Postcode gevuld zijn 7 karakters Woonplaats 30 karakters
Om deze twee partijen met elkaar te laten praten moet er een vertaling plaatsvinden door gebruik te maken van een gemeenschappelijke taal.
17
Met de komst van de basisregistraties worden de definities steeds meer op elkaar afgestemd, maar afwijkingen zullen (voorlopig) blijven bestaan. In het geval van bijvoorbeeld managementinformatie op het gebied van personeel of financiën geldt nog een ander definitieverschil. In de leverende applicatie (bijv. het personeelsysteem) worden de losse verzuim gevallen geregistreerd of de “losse” uitgaven (financieel systeem). Als manager is het vaak interessanter om te weten wat het verzuimpercentage of wat het resterend budget is van een afdeling. Om tot dit hogere aggregatieniveau te komen is het noodzakelijk om berekeningen uit te voeren en gegevens aan elkaar te linken (naar organisatieonderdeel).
5.1.3 Verwachtingen Doordat gegevens geautomatiseerd aangeleverd worden, wordt er verwacht dat de leverende partij zijn/haar werk goed gedaan heeft en alle benodigde gegevens op de juiste manier (zowel kwalitatief als tijdig) gevuld zijn. De controle wordt bij een koppeling meestal minder goed uitgevoerd t.o.v. gegevensuitwisseling waar een handmatige actie aan verbonden is.
5.2. Daarom StUF! Het Standaard UitwisselingsFormaat (StUF) is de verbinding tussen componenten in de informatievoorziening. StUF is gericht op de standaardisatie van: • • •
Betekenis Structuur Syntax
StUF is de voorgeschreven open standaard in gemeentelijke ketens voor:
18
• • • • •
Het uitwissel en opvragen van Basisgegevens Binnengemeentelijke integratie Intergemeentelijke ketens Zaakgegevens van/naar burgers/bedrijven Gemeentelijke ketens waar geen XML-standaard is
De StUF familie is momenteel als volgt samengesteld:
StUF is gebaseerd op open standaarden van het W3C (XML en webservices), overheidsstandaarden (Gemeentelijk Functioneel Ontwerp BasisGegeven, Gemeentelijk Functioneel Ontwerp Zaken, RSGB) en past op de Overheids Service BUS (OSB).
19
6 Implementatievormen 6.1. Harde en Zachte koppelingen We spreken van een harde koppeling als twee systemen door middel van bijvoorbeeld een database link met elkaar verbonden zijn. Vaak zijn dit koppelingen die gebruikt worden bij applicaties van leverancier die geen eigen koppelingen willen of kunnen leveren. Er wordt hier direct in de gegevens van elkaar gekeken en/of gemuteerd. Het risico kan bij dit soort koppelingen redelijk hoog liggen. Daarnaast zijn deze relatief duur in beheer. Bij wijzigingen in het datamodel van de databases zal de koppeling moeten worden aangepast. Een speciale vorm hiervan zijn de zogenaamd ETL-procedures. Hierbij worden extracten gevormd van gegevens uit de ene database, vervolgens vertaald naar een ander formaat en ingelezen in de andere database. De laatste wordt vaak gebruikt bij het vullen van gegevensmagazijnen of koppelingen waarbij een verminderde actualiteit acceptabel is. Een ETL-procedure wordt nl. periodiek gestart (bijvoorbeeld 1x per dag). Een zachte koppeling grijpt niet direct in op de database en wordt vaak door een leverancier (mogelijk tegen meerkosten) geleverd. Dit soort koppelingen worden vaak als webservice geleverd, maar het kunnen ook gegenereerde bulk bestanden zijn die periodiek worden ingelezen. Bij webservice is er sprake van directe communicatie en hebben beide systemen nagenoeg dezelfde actualiteit. In het geval van de bulk bestanden is dit niet het geval en bepaalt de periodiciteit van het genereren van de bestanden en inlezen de actualiteit.
6.2. Distributie of vraag/antwoord (push of pull) Bij distributie is er sprake van een systeem die gegevens zendt naar een ander systeem. Hierbij valt te denken aan het versturen van wijzigingen in gegevens. Bijvoorbeeld een mutatie binnen de basisregistratie adressen en gebouwen moet verstuurd worden naar de landelijke voorziening. Er kan ook gedacht worden aan gegevens die via ETLprocedures naar een gegevensmagazijn verplaatst worden of was-wordt mutaties die in bestandvorm worden aangeleverd door het Kadaster. In het geval van vraag/antwoord gaat het om webservices waarbij de ene partij een vraag stelt die door de andere beantwoord moet worden. Bijvoorbeeld geef mij de nawgegevens van persoon met burgerservicenummer 12345678.
6.3. Spaghetti of Lasagne?! 6.3.1 Spaghetti? Het (terechte) angstbeeld bij koppelingen is het groot aantal 1-op-1 koppelingen tussen allerlei systemen. Met een beperkt aantal koppelingen is het beheer hier nog wel over te voeren, maar zodra dit gaat toenemen wordt dit steeds complexer. De 1-op-1 koppelingen hebben ook nog het nadeel dat wanneer de ene kant van de koppeling wijzigt dat de andere kant van de koppeling ook moet wijzigen. Wanneer er meerdere applicatie gebruik maken van deze koppeling en deze koppeling verandert betekent dat direct alle koppelingen moeten worden aangepast.
20
6.3.2 Lasagne! Een Enterprise Service Bus (ESB) is transportmechanisme waarmee de communicatie tussen de afnemers van diensten (“service”) en aanbieders hiervan, vereenvoudigd wordt.
Transport
De ESB biedt hiertoe aan de kant van de aanvrager een met de aanvrager afgesproken interface aan, dit kan een webservice zijn, maar bijvoorbeeld ook een SMTP (e-mail) interface en tal van andere mogelijkheden. Aan de kant van de aanbieder zal de ESB via de interface die met de aanbieder is afgesproken communiceren. Zo kan het dus zijn dat een aanvrager van een dienst op een compleet andere wijze met de ESB communiceert dan de ESB met de aanbieder. Door een servicebus te gebruiken worden aanbieder en vragen zo losgekoppeld dat de mogelijkheid ontstaat een service aan te passen zonder dat direct consequenties heeft voor de afnemers (zie voorbeeld bij spaghetti). In de servicebus is een mechanisme aanwezig die de oude vragers kan vertalen naar de nieuwe aanbieder. Het is zelfs mogelijk om deze smaken door elkaar te hebben. Dit betekent dat er een beter beheersbare omgeving ontstaat.
21
7 Beleid 7.1. Inhoud, logistiek en transport Het College Standaardisatie heeft een aantal standaarden als verplicht open standaard vastgesteld (comply-or-explain). Het Standaard UitwisselingsFormaat (StUF) is zo’n standaard en wordt gebruikt om gegevens te bevragen en uit te wisselen binnen gemeenten, tussen gemeenten onderling en tussen gemeenten en ketenpartijen. Dit vanwege de positie die gemeenten willen in nemen als toegangspoort tot de gehele overheid geldt dit dus voor veel (keten)processen. Het is daarom vanzelfsprekend dat binnen de Drechtsteden deze standaard wordt overgenomen voor het inhoudelijke niveau. Op logistiek niveau volgen we de standaarden zoals die ook door de overheidsservicebus (OSB) worden gehanteerd, te weten ebMS en WUS met http als communicatielaag. Op de transportlaag gebruiken we TCP/IP.
7.2. Consequenties Consequenties van de invoering van het bovenstaande beleid, zijn: Aspect Wat Waarom
Aspect Wat Waarom
Technisch De investering in een “service bus” oplossing om losse koppelingen te bewerkstelligen. Exponentiële toename van beheerlasten (spaghetti) voorkomen. Zie voor een nadere toelichting (paragraaf 6.3) Organisatorisch Oprichten van een kenniscentrum waar het beheer en de ontwikkeling van koppelingen plaatsvinden. Beperken van de kosten per koppeling door inzet van eigen personeel. Hierbij valt te denken aan: • Beheer van de service bus • Aanpassen en opzetten van (eenvoudige) nieuwe koppelingen. • Ondersteuning bij het opstellen van een programma van eisen bij nieuwe wensen • Prestatieafspraken maken en beheren rond koppelingen.
7.3. Comply-or-explain De gewenste situatie zal niet van vandaag op morgen gerealiseerd worden. Hiervoor is op dit moment nog veel ontwikkeling in zowel de markt als de leveranciers. Daarom geldt het comply-or-explain (voldoe-of-leg uit) principe voor dit beleid. Wanneer er sprake is van een afwijking wordt in bijlage 2 een stroomschema gegeven langs welke route er afgeweken kan worden. Dit altijd in overeenstemming met de CIO en CIO-office (explain).
22
Bijlage 1: Standaardenlijst Standaard
Eigenaar
Omschrijving
Meer informatie
GFO-Zaken
EGEM
http://www.egem-iteams.nl
Procesmodel Dienstverlening
EGEM
StUF
EGEM
Gemeentelijk Functioneel Ontwerp Zaken. De basis voor zaakgericht werken. Het procesmodel dienstverlening is een model hoe de dienstverlening binnen de gemeente op conceptueel niveau verloopt in samenhang met zaakgericht werken StUF is een universele berichtenstandaard voor het elektronisch uitwisselen van gegevens tussen applicaties. Het domein van de StUF-taal omvat informatieketens tussen overheidsorganisaties (basisregistraties en landelijke voorzieningen) en gemeentebrede informatieketens en functionaliteit.
OSB
RENOIR
Bijlage 2, http://www.egemiteams.nl
http://www.egem-iteams.nl/stuf
http://www.overheidsservicebus.nl
23
Bijlage 2: Beslisboom Inleiding In alle gevallen heeft de implementatie van de StUF-standaard de voorkeur. Deze standaard kent voor de verschillende domeinen eigen sectormodellen. Het gebruik van deze standaard maakt een verregaande standaardisatie van koppelingen mogelijk, wat uiteindelijk voor lagere beheerlasten gaat zorgen t.o.v. andere vormen van koppelingen. Onderstaand is per niveau (inhoudelijk, logistiek en transport) aangegeven wat beleid, voorkeur of gedoogoplossing is. Hierbij is de lijst met standaarden van het College en Forum Standaardisatie leidend.
Inhoud Inhoud
StUF
(inter)nationale Standaard
Nee
Ja
Nee Ja
Actuele of vorige versie
Nee
Ja
Beleid
Voorkeur
Gedoog
In het geval van de StUF-standaard willen we qua versies de verschillen niet te groot maken. De belangrijkste voorkeur gaat uit naar de huidige en de vorige versie van StUF. Wanneer het een nog oudere versie betreft wordt het een gedoogoplossing die zo snel mogelijk opgewaardeerd dient te worden. Wanneer er geen StUF-standaard voor handen is, wordt bepaalt of het om een andere (inter)nationale standaard gaat. Hierbij valt ondermeer te denken aan WMS/WFS (voor GEO-toepassingen) en XBRL (eXtensible Business Reporting Language Dit is een open standaard om financiële gegevens uit te wisselen via het internet). Wanneer het een eigengemaakt oplossing betreft wordt dit voorlopig gedoogd en indien mogelijk, de opdracht gegeven om over te gaan naar een (inter)nationale standaard.
24
Logistiek Logistiek
ebMS of WUS
Nee
Ja
Beleid
Gedoog
Op logistiek niveau hanteren we de standaarden ebMS en WUS. Dit is gelijk aan de standaarden voor de Overheids Service Bus. Bij uitzonderingen op deze standaarden moet er gedacht worden aan bijvoorbeeld bestandsoverdracht, e-mails, e.d. De vulling van een gegevensmagazijn wordt op dit moment met ETL-procedures gedaan. Hierbij wordt d.m.v. ETL-procedures gegevens geëxtraheerd, getransformeerd en in de doeldatabase geladen. Tijdens de transformatiefase is het mogelijk dat er nog berekeningen e.d. plaatsvinden. ETL-procedures kunnen gebruik maken van een database link om gegevens op te halen. Dit is de enige uitzondering waarbij gebruik gemaakt kan en mag worden van een databaselink. De vulling van het gegevensmagazijn moet op termijn ook d.m.v. gestandaardiseerde berichten gaan gebeuren.
Transport Logistiek
HTTP
Nee
Ja
Beleid
Gedoog
ebMS en WUS maken gebruik van http (standaard internet verkeer) als standaard voor transport. Bij uitzondering in het bovenliggend niveau betekent dit ook vaak een ander
25
manier van transport. Bijvoorbeeld FTP o.i.d. in het geval van bestandsoverdracht, SMTP bij e-mail of SQL*Net bij een directe databaselink.
26
