Informatiearchitectuur

Het definiëren van applicatieve functies is één van de eerste stappen bij het opstellen van een informatiearchitectuur. Een applicatieve functie is een zelfstandige eenheid functionaliteit. Het modulaire karakter is belangrijk: een applicatieve functie is een afgebakend geheel aan functionaliteiten, dat als zodanig vervangen kan worden. De kracht van applicatieve functies is dat specifieke en generieke functionaliteiten apart benoemd worden. De meeste software biedt specifieke en generieke functionaliteit in één pakket aan (bijvoorbeeld workflow- en documentmanagement in één pakket voor het afhandelen van vergunningsaanvragen). Het risico is dat bij de aanschaf van dergelijke software overlap in functionaliteit in de organisatie ontstaat. Ook bestaat de kans dat een en hetzelfde gegeven op meerdere plekken ingevoerd en beheerd moet worden. Het definiëren van applicatieve functies is een eerste stap in het ontwarren van de ‘spaghetti’ aan applicaties in een organisatie.

Het bedrijfsfunctiemodel is het beginpunt geweest voor een analyse van de applicatieve functies van veiligheidsregio’s. Dit heeft een applicatielandschap opgeleverd dat veiligheidsregio’s kunnen vergelijken met hun eigen landschap. Blijkt daar dat meerdere applicaties één applicatieve functie afdekken, dan is applicatiesanering een optie. Zijn er gaten zichtbaar, dan is er mogelijk een (latente) behoefte van de organisatie niet ingevuld.

De applicatieve functies geven ook (ont)koppelpunten van applicaties aan, ze maken zichtbaar waar koppelvlakken liggen. De meeste veiligheidsregio’s hebben nu een applicatielandschap met een zogenaamde ‘spaghettistructuur’. Op organische wijze zijn er steeds meer applicaties in gebruik genomen zonder dat is gekeken naar een logisch verband met het gebruik ervan binnen een specifiek toepassingsgebied overeenkomstig een bedrijfsfunctie. Hierdoor ontstaan er dubbelingen in functionaliteit omdat individuele korpsen ieder hun eigen systemen hebben waarmee een applicatieve functie wordt ingevuld. Bovendien is er in dit proces vaak slechts beperkt gekeken naar hergebruik van functionaliteit en het generiek ter beschikking stellen van gegevens.

De kracht van het benoemen van applicatieve functies ligt in de ontvlechting van de verschillende bedrijfsfuncties en is daarmee de basis voor eenduidig gebruik van functionaliteit, één van de inrichtingsprincipes van de NORA. Ook ligt dit aan de basis van een ander inrichtingsprincipe van zowel de NORA als het IBV, namelijk het hergebruik van gegevens.

Functioneel applicatielandschap

Een functioneel applicatielandschap geeft aan op welke wijze een applicatieve functie wordt ingevuld en welke relaties er tussen applicatieve functies zijn. Een applicatieve functie verbeeldt een samenhangende set functionaliteit die geleverd dient te worden. Een informatiesysteem (softwarepakket / applicatie) bevat uiteindelijk één of meerdere applicatieve functies. Iedere Veiligheidsregio kan eigen informatiesystemen aanschaffen (zelf ontwikkelen of aankopen) om invulling te geven aan deze applicatieve functies. Applicatieve functies zeggen niet welke informatiesystemen een Veiligheidsregio moet aanschaffen, maar wel welke functionaliteit via (delen van) informatiesystemen aanwezig moet zijn. Doordat op deze manier het applicatielandschap wordt ingericht, is het eenvoudiger om per bedrijfsfunctie de gebruikte informatiesystemen te vervangen of uit te besteden overeenkomstig het gekozen groeipad binnen de bedrijfsfunctie.

Het verbinden van bedrijfsfuncties gebeurt door het beschrijven van processen. Op dezelfde manier worden applicatieve functies aan elkaar verbonden met informatiestromen (gegevensuitwisseling). Zowel de processen als de gegevensuitwisseling komen uitgebreid aan bod in een volgende versie van de VeRA.

Applicatieve functies[bewerken]

In [| Overzicht applicatieve functies] zijn de applicatieve functies van veiligheidsregio’s getekend in relatie tot de bedrijfsfuncties en daarmee in relatie tot de domeinen van de basisarchitectuur voor overheidsorganisaties. In de tekst wordt per functie een definitie gegeven.


Een metafoor   
Een stad bestaat uit wijken, in deze wijken staan vervolgens weer bouwwerken. De manier waarop een stad wordt ingedeeld gebeurt zeer doordacht via streekplannen en bestemmingsplannen. Afstanden tussen industriële bebouwing en woonwijken zijn juridisch vastgelegd en moeten gerespecteerd worden. Wie wil er nu ook in zijn tuin zitten terwijl er veertig meter verderop een fabriek staat te ronken? De mogelijkheden (functionaliteit) die een gebiedsfunctie biedt aan de stad wordt dus ingevuld door het type bouwwerk. Een fabriek, huis of recreatiegebied bieden immers andere mogelijkheden aan de inwoners van de stad. Allerlei verschillende soorten bouwwerken die een woonfunctie hebben, laten complete woonwijken ontstaan. Daar tegenover staan de industrieterreinen waar zich grote productiebedrijven bevinden en allerlei groothandels. Ook de inwoner van Nederland die van rust, schoonheid, ontspanning en natuur houdt wordt niet vergeten. Er bestaan mooie recreatiegebieden waar voor iedereen wat wils is. De wandelaar, kampeerder, visser en watersporter, ze komen allemaal aan hun trekken.
De functionaliteit die een applicatieve functie biedt kan vergeleken worden met een gebiedsfunctie: iedere applicatieve functie biedt de medewerker een set functionaliteit zodat specifieke bedrijfsmatige werkzaamheden uitgevoerd kunnen worden.

Net zoals gebiedsfuncties staan ook applicatieve functies niet op zichzelf. Verschillende functies werken samen of zijn afhankelijk van elkaar. De mobiliteit tussen gebiedsfuncties wordt ingevuld door een vervoersplan. Samenwerking tussen applicatieve functies gebeurt door uitwisseling van informatie.

Besturende applicatieve functies

Besturende functies geven weer hoe de organisatie zichzelf richting geeft, bijstuurt en ontwikkelt. Binnen de besturende laag is er één applicatieve functie geïdentificeerd, namelijk management informatie.

Managementinformatie

Functionaliteit waarmee gegevens worden geanalyseerd en de resultaten worden gepresenteerd in een zodanige vorm dat het management ondersteund wordt bij de besturing van de organisatie en bij het afleggen van verantwoording over haar functioneren. Het gaat dus om het genereren van stuur- en verantwoordingsinformatie ter ondersteuning van het besluitvormingsproces van het management of ten behoeve van landelijke statistieken (bijvoorbeeld CBS). De term Business Intelligence wordt ook vaak gebruikt voor deze applicatieve functie.

Primaire applicatieve functies

Primaire functies hebben betrekking op het feitelijke werk van de organisatie. Deze functies leveren een directe bijdrage aan de producten en diensten van een organisatie. Met andere woorden, deze functies leveren primair de toegevoegde waarde van de organisatie.

Secundaire applicatieve functies

Secundaire functies zijn de zogenaamde PIOFACH-functies. Deze functies ondersteunen de overige functies en kunnen worden gezien als generieke functies die in elke willekeurige organisatie zijn te herkennen.

Referentiecomponenten[bewerken]

Met de VeRA referentiecomponenten worden de typen softwarepakketten (of applicaties) gedefinieerd van een veiligheidsregio. Een referentiecomponent is een type applicatiecomponent. De ArchiMate definitie van een applicatiecomponent is: Een modulair, zelfstandig inzetbaar en vervangbaar deel van een systeem, dat zijn functionaliteit aanbiedt via goed gedefinieerde interfaces. Applicatiecomponenten stellen functionaliteit beschikbaar, die gebruikt wordt om de applicatiediensten mee te leveren.

Een referentiecomponent wordt daarbij gedefinieerd als:

 De ArchiMate definitie van een applicatiecomponent is: Een modulair, zelfstandig inzetbaar en vervangbaar deel van een systeem, dat zijn functionaliteit aanbiedt via goed gedefinieerde interfaces. Applicatiecomponenten stellen functionaliteit beschikbaar, die gebruikt wordt om de applicatiediensten mee te leveren  

Toepassing van referentiecomponenten in de VeRA

Referentiecomponenten zijn de elementaire bouwblokken waarmee het veiligheidsregio applicatielandschap wordt beschreven. In dit landschap worden de softwarepakketten beschreven door één of meerdere referentiecomponenten te bundelen.

In koppelvlakstandaarden worden de referentiecomponenten gebruikt om de systeemgrenzen waartussen gegevens worden uitgewisseld vast te leggen. Referentiecomponenten die gegevens/berichten met elkaar moeten kunnen uitwisselen, moeten allebei dezelfde koppelvlakstandaard ondersteunen. In de VeRA wordt voorgeschreven welke standaarden voor een referentiecomponent verplicht danwel aanbevolen zijn.

Klik op de link voor een Overzicht_referentiecomponenten van een veiligheidsregio.

Toepassing van referentiecomponenten in de Softwarecatalogus

In de softwarecatalogus registreren veiligheidsregio's hun productportfolio en geven per pakket aan voor welke referentiecomponent(en) het pakket geschikt is. Veiligheidsregio's registreren in de softwarecatalogus hun applicatielandschap en geven per pakket aan waar welke referentiecomponent(en) zij het pakket gebruiken. De referentiecomponent wordt in de softwarecatalogus gebruikt als de sleutel voor het verbinden van de het softwareaanbod aan het gebruik.

Klik op de link voor een koppeling naar de Softwarecatalogus van de Veiligheidsregio's: https://softwarecatalogusvr.nl/

Gegevens[bewerken]

In het volgende deel van het applicatielandschap worden gegevensgroepen van veiligheidsregio’s benoemd, onderverdeeld naar basisregistraties, externe gegevensbronnen, eigen kernregistraties en interne gegevensbronnen.

De gegevens in basisregistraties worden eenmalig ingevoerd. Daarna worden deze gegevens door de gehele overheid gebruikt. Externe gegevens die niet vervat zijn in het Stelsel van Basisregistraties worden aangeduid met externe gegevensbronnen. De gegevens in een kernregistratie worden ook eenmalig ingevoerd maar daarna worden deze gegevens door de gehele Veiligheidsregio gebruikt. De gegevens van een interne gegevensbronnen worden alleen door één organisatie-eenheid gebruikt.

Basisregistraties

Om haar werk te doen heeft de overheid gegevens nodig die zijn vastgelegd in ongeveer 30.000 verschillende registraties. Basisregistraties zorgen ervoor dat gegevens minder versnipperd en eenvoudiger beschikbaar zijn. Steeds alle gegevens die bij elkaar horen op één plek verzamelen; dat is in essentie een basisregistratie. Uiteindelijk zullen losse basisregistraties gaan functioneren als één logisch, samenhangend geheel: het Stelsel van Basisregistraties. Dit stelsel zorgt dat bij het beantwoorden van een vraag of het oplossen van een probleem direct alle relevante gegevens uit verschillende registraties bij elkaar kunnen komen. Basisregistraties zijn bij wet vastgelegd en overheidsorganisaties zijn of worden verplicht ze te gebruiken, afhankelijk van het ontwikkelstadium van de basisregistratie.

Er zijn dertien basisregistraties:

GBA – Gemeentelijke Basisadministratie persoonsgegevens (wordt BRP) (Gemeenten)

• NHR – Nieuwe Handelsregister (Kamer van Koophandel NL)

• BAG – Basisregistratie Adressen en Gebouwen (Gemeenten, Kadaster)

• BRT – Basisregistratie Topografie, met de Top10NL topografie (Kadaster)

• BRK – Basisregistratie Kadaster (percelen, eigendom) (Kadaster)

• BRV – Basisregistratie Voertuigen (kentekenregistratie) (RDW)

• BRI – Basisregistratie Inkomens (SZW)

• WOZ – Basisregistratie Onroerende Zaken (waardebepaling) (Gemeenten)

• RNI – Registratie Niet-Ingezetenen (wordt BRP) (Gemeenten)

• BGT – Basisregistratie Grootschalige Topografie (vh. GBKN) (400+ bronhouders)

• BRO – Basisregistratie Ondergrond (voorheen ook wel DINO) (TNO)

Niet alle basisregistraties zijn voor alle VeRA bedrijfsfuncties van even groot belang. Aangezien het werk zich vaak concentreert rond de vraag “Waar is het en wat is daar?” zijn vooral de locatiegebaseerde basisregistraties van belang. Dat betreft: de BAG, de BRT, de BRO, de WOZ en de BGT (in ontwikkeling). Verder wordt ook het Nieuwe Handelsregister (NHR) steeds belangrijker om de juiste instelling/ organisatie op de kaart te kunnen vinden.

Locatiegebaseerde basisregistraties zijn in het algemeen beschikbaar via de Publieke Dienstverlening op de Kaart¹ en te vinden in het bijbehorende Nationaal Georegister² . Enkele basisregistraties bieden ruimte voor zgn. sectorale ‘plus-lagen’, dus ook voor de OOV. Dit biedt ruimte om OOV-specifieke kenmerken in een basisregistratie geborgd te krijgen. Een voorbeeld vormen de complexe ondergrondse objecten (tunnels, treintunnels) die niet standaard in de BGT zitten, maar wel in de BGT OOV+ laag. Op landelijk niveau is de OOV-sector vertegenwoordigd in het BGT gebruikerspanel.

¹PDOK, www.pdok.nl

²Zie www.nationaalgeoregister.nl. Voor het zien van de data is een GIS viewer vereist

Externe gegevensbronnen

Hier gaat het om externe gegevens die niet vervat zijn in het Stelsel van Basisregistraties. Hieronder vallen (niet volledig):

• Luchtfoto’s loodrecht (uit de Landelijke Aanbesteding Beeldmateriaal);

• 3D-foto’s (uit de Landelijke Aanbesteding Beeldmateriaal);

• Wegen, hetzij uit het NWB (RWS) of externe bronnen zoals OpenStreetMap *;

• Actuele Hoogtekaart Nederland (thans AHN2, 0,5x0,5m) (RWS/ Waterschappen) *;

• De risicokaart (IPO/Bij12) **;

• Locaties Bluswaterwinpunten, w.o. Brandkranen (Vewin en haar leden);

• De Natura2000 gebieden *;

• De WAS sirenepalen (LFR/Siemens);

• Het Antenneregister (Telecommasten) (Dienst Antenneregister) *;

• De Hydrografie (vaarwegen, dieptelijnen, betonning) (RWS/ Defensie) ***;

• ProRail spoorelementen (ProRail);

• CBS Wijken, buurten en demografische gegevens (CBS) *;

• Postcodegebieden (PostNL);

• Locaties Cultureel Erfgoed (Rijksdienst voor het Cultureel Erfgoed) *;

• De Bewegwijzering, m.n. de ANWB Paddenstoelen (RWS Bewegwijzeringdienst) *;

• Landelijk Register locaties Kinderopvang en Gastoudergezinnen *.

In de verdere ontwikkeling van de VeRA zal gekeken worden naar welke externe gegevensbronnen noodzakelijk zijn voor welke bedrijfsfuncties. Van belang daarbij is dat niet alle externe gegevensbronnen ‘zomaar’ beschikbaar zijn, d.w.z. niet alles is ‘open data’. Bij bronnen die ten tijde van de publicatie van VeRA2 wél open data zijn, is dat aangegeven met één sterretje *. Deze bronnen worden landelijk ter beschikking gesteld via het Programma Geo van het Veiligheidsberaad. Voor de bronnen met meer sterretjes geldt:

(**) De publieke versie van de Risicokaart is open data, maar de professionele versie niet. De professionele versie is voor de hulpdiensten kosteloos beschikbaar.

(***) Vaarwegen en betonning (RWS) zijn open data, maar de bathymetrie (iso-dieptelijnen van de Dienst Hydrografie van Defensie) niet.

Voor datasets die niet open data zijn, zullen convenanten moeten worden afgesloten met de eigenaar/beheerder van de registratie. Dit wordt zoveel mogelijk op landelijk niveau (Veiligheidsberaad/ IFV) gedaan. Elke veiligheidsregio kan nog steeds de data regionaal verkrijgen, verrijken en gebruiken, maar het convenant hoeft maar één keer afgesloten en beheerd te worden. Binnen het Veiligheidsberaad start vanaf 2015 een landelijk programma Geo dat onder andere dergelijke convenanten zal organiseren en beheren.

Eigen kernregistraties

Kernregistraties zijn interne gegevensverzamelingen die voor meervoudig gebruik in aanmerking komen. Deze gegevens worden gebruikt in verschillende applicatieve functies. Door verwijzing naar een gegeven uit een kernregistratie kunnen verschillende applicatieve functies aan elkaar gerelateerd worden. Binnen de veiligheidsregio’s kunnen de volgende kernregistraties worden geïdentificeerd:

• Incidenten: betreft de set aan basiskenmerken van een incidentmelding;

• Personeel: betreft de set aan basiskenmerken van een medewerker, zowel vast als tijdelijk en extern (inhuur);

• Materieel: betreft de set aan basiskenmerken van materieel die gebruikt wordt voor de hulpverlening;

• Objecten: betreft de set aan basiskenmerken van objecten in de openbare ruimte waarop verschillende werkzaamheden betrekking kunnen hebben (zoals bereikbaarheidskaarten, vergunningen, incidenten, etc.);

• Eigen locaties: betreft de set aan basiskenmerken over de vestigingslocaties van brandweerkazernes, ambulanceposten, meldkamers, alsmede de locaties van directe ketenpartners zoals politie, gemeenten, Defensie, KNRM, Reddingsbrigade, Justitie (Rechtbanken en penitentiaire locaties), waterschappen e.d.;

• Zorgcontinuïteit: betreft de set aan basiskenmerken over de zorgaanbieders en zorginstellingen (verminderd zelfredzame personen). Deze OOV kernregistratie staat in de praktijk bekend als “De Witte Kaart” en wordt beheerd door GGD/GHOR Nederland;

• Natuurbrandrisico: betreft de set aan basiskenmerken van natuurgebieden in termen van vatbaarheid voor natuurbrand;

• Budgetten: betreft de set aan basiskenmerken voor de financiële vastlegging van de werkzaamheden

• Documenten: betreft een set aan basiskenmerken van een document plus het document zelf. Een document is een verzameling gegevens vastgelegd op een gegevensdrager zoals bijvoorbeeld papier of digitaal bestand;

• Relatie: betreft een set aan basiskenmerken van een persoon of organisatie waarmee de Veiligheidsregio een zakelijke relatie heeft. Relaties kunnen gekoppeld zijn aan GBA en aan NHR;

• Organisatie-eenheid: betreft een set aan basiskenmerken van een organisatie-eenheid (groep binnen een organisatie die een gezamenlijk doel nastreeft);

• Zaak: betreft een set aan basiskenmerken van een zaak. Een zaak is een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden;

• Inzet: betreft een set aan basiskenmerken van een gerealiseerde inzet van hulpverleners en sleutelfunctionarissen (in verband met uitbetaling, vakbekwaamheid).

Eigen kernregistraties worden dus door de veiligheidsregio’s zelf beheerd. Ook dit gebeurt bij voorkeur op landelijk niveau, onder het motto: landelijk wat kan, regionaal waar het moet.

Interne gegevensbronnen

Bij interne gegevensbronnen gaat het om de data die vastgelegd worden in de processystemen. Bij deze gegevens wordt meervoudig gebruik niet ondersteund. De vastgelegde data zijn dus zeer specifiek voor een bepaalde bedrijfsfunctie.

Geografische informatie

Strikt genomen behoort ‘geografische informatie’ geen eigen paragraaf te hebben, omdat geografische informatie al verweven zit in de typen gegevensbronnen zoals hierboven beschreven. Echter, gezien (a) het belang van ‘de kaart’ in het OOV werk en (b) de oogst van de VeRA Geo workshops uit 2013, wordt hier toch enige ruimte besteed aan geografische informatie, in termen van principes en uitgangspunten.

1. Er is geen strak onderscheid tussen ‘geografische informatie’ en ‘niet geografische informatie’. Geografische informatie kan gedefinieerd worden als alle gegevens die wenselijk zijn om een kaartbeeld betekenisvol te maken. Dat verschilt per bedrijfsfunctie. Voorbeeld: voor de GHOR in de bedrijfsfunctie “netwerkmanagement” is De Witte Kaart administratieve informatie; in de bedrijfsfunctie ‘op- en afschaling’ wordt diezelfde Witte Kaart (via LCMS) ineens geografische informatie. Dezelfde gegevens worden in die bedrijfsfunctie op een kaartbeeld getoond.

2. Enkele van de locatiegebaseerde basisregistraties kennen sectorale ‘plus-lagen’, zo ook voor de OOV sector. Het bekendste voorbeeld is de BGT, waar vele sectoren hun wensen hebben aangedragen voor hun sectorale ‘plus-laag’. Dergelijke sectorale inbreng wordt landelijk georganiseerd, via de landelijke Vakgroep Geo & Basisregistraties.

3. Het terugmelden van fouten (“bij gerede twijfel aan de juistheid”) geldt voor alle typen registraties. De hiervoor benodigde functionaliteit is echter veelal nog niet beschikbaar. Dit is belangrijk voor het behalen van het gewenste kwaliteitsniveau van de registraties en motivatie om de basisregistraties en kernregistraties te blijven gebruiken. Ook hieraan dient op landelijk niveau prioriteit te worden gegeven.

4. Geografische gegevens worden bij voorkeur zoveel mogelijk direct bij landelijke bronnen (PDOK, Geo4OOV) betrokken, tenzij beschikbaarheid/performance/storage/security redenen een regionale of lokale opslag vereisen. Dit fungeert dan als ‘cache’ van de bron.

5. Per bedrijfsfunctie kan geografische informatie worden bekeken, geanalyseerd en bewerkt (naast algemene functies zoals maken, beheren, delen, printen, en exporteren). In 2013 is in twee speciale Geo-workshops in kaart gebracht welke bedrijfsfuncties op welke wijze gebruik maken van Geo. Hieruit bleek dat bijvoorbeeld dat veel geo-analyses input vormen voor een volgend bedrijfsproces.

6. GIS vormt in technische zin een geheel van ICT (software en hardware), gegevens en methoden (workflow ondersteuning). In menselijke zin hoort daar ook nog de organisatie en de kennis en creativiteit bij. De VeRA stelt geen eisen aan GIS anders dan het algemene uitgangspunt dat open data en de facto open standaarden zoveel mogelijk worden ondersteund. De term de facto betekent ‘uit de praktijk’. Shapefiles bijvoorbeeld zijn strikt genomen geen open standaard, maar zijn in de praktijk wel een open standaard geworden en zijn dus toegestaan. Voorbeelden van andere toegestane formaten zijn: PostGIS, GeoJSON, SpatialLite, CSV, Excel, FGDB, KML, GeoTIFF, IMG, XYZ, en wat webservices betreft: WMS, WMTS, WFS, WCS, WMC, WPS. De actuele lijst met toegestane de facto standaarden wordt in een apart document gepubliceerd.

7. Op basis van de ‘bodemplaat’ wordt op landelijk niveau een koppeling gelegd tussen kaartlagen en het gegevensboek, zodat het opvragen van kaartlagen gebeurt met een term die onder beheer valt en zodat er een begrijpelijke legenda bij de gegevens gevoegd kan worden. 8. Iconen (pictogrammen) volgen de NEN 1414-plus standaard, voor zover mogelijk en relevant. Deze standaard is in beheer bij de landelijke NEN standaardisatiecommissie.

8. Iconen (pictogrammen) volgen de NEN 1414-plus standaard, voor zover mogelijk en relevant. Deze standaard is in beheer bij de landelijke NEN standaardisatiecommissie.

Typen gegevensuitwisseling

Koppelingen tussen applicaties kunnen heel divers zijn. Niet alleen in de functionaliteit of gegevens die worden uitgewisseld, maar vooral in de manier waarop die uitwisseling plaatsvindt. In deze diversiteit zijn wel standaardpatronen te herkennen. Dit worden ook wel integratiestijlen genoemd.

Om te voorkomen dat de complexiteit van koppelingen te groot wordt, is het noodzakelijk om te streven naar een beperkt aantal integratiestijlen, en een aantal afspraken te maken over de manier waarop die worden ondersteund. Zo kan de complexiteit worden verminderd en het beheer worden vereenvoudigd. De gewenste integratiestijlen zijn:

• Service of functieaanroep;

• Berichtuitwisseling;

• Bulkuitwisseling (minst gewenst).

Elk van deze integratiestijlen heeft bepaalde kenmerken en daarmee een bepaald toepassingsgebied waarvoor het bij uitstek geschikt is. Bulkuitwisseling is ten opzichte van de andere twee integratiestijlen minder gewenst. De actualiteit van de gegevensuitwisseling ligt lager en er wordt meer informatie uitgewisseld dan nodig is. De andere integratiestijlen vragen wel een modernere omgeving, waardoor bulkuitwisseling toch vaak als een ‘second-best’ oplossing wordt toegepast. Er zijn wel situaties, zoals de uitwisseling met een datawarehouse, waarvoor bulkuitwisseling wel geschikt is.


Service- of functieaanroep Deze integratiestijl houdt in dat een applicatie direct een service (of functie) van een andere applicatie aanroept.

Figuur 4.2. De service- of functieaanroep

Dit type koppeling is over het algemeen synchroon, wat betekent dat de applicatie afhankelijk is van de beschikbaarheid van applicatie B, en wacht op het resultaat van de service- of functieaanroep.

Figuur 4.3. Berichtuitwisseling

Voor dit type koppelingen is het concept van services het uitgangspunt, wat betekent dat applicaties bepaalde functies beschikbaar stellen als services. Technisch gezien kunnen deze services op verschillende manieren worden geïmplementeerd. De keuze is om hiervoor te standaardiseren op web services. Bij deze integratiestijl is het belangrijk om te allen tijde betrouwbare verbindingen te hebben.



Berichtuitwisseling Deze integratiestijl houdt in dat een applicatie een bericht stuurt naar één of meerdere andere applicaties. Deze integratiestijl is doorgaans asynchroon, wat betekent dat applicatie A het bericht verstuurt zonder op een antwoord te wachten. Vaak heeft het bericht de betekenis van het verzenden van een gebeurtenis (een event), waarop één of meerdere andere applicaties moeten reageren. Voor applicatie A is het alleen maar van belang dat het bericht correct verstuurd en ontvangen is. Wat de andere applicatie(s) ermee doen is voor applicatie A niet van belang. Het belangrijkste is hier, dat er standaardisatie van berichtstructuren mogelijk wordt door alle berichten als XML-berichten te definiëren.



Figuur 4.4. Bulkuitwisseling


Bulkuitwisseling Deze integratiestijl houdt in dat een verzameling gegevens, vaak periodiek, wordt uitgewisseld met een andere applicatie. Deze integratiestijl heeft het karakter van een export door applicatie A, gevolgd door een import door applicatie B. Het enige wat beide van elkaar nodig hebben is een gedeelde voorziening voor gegevensopslag waar beide gebruik van kunnen maken. Net als bij de berichtuitwisseling wordt gestandaardiseerd op XML, met de mogelijkheid om de berichtstructuren met behulp van XSDspecificaties te standaardiseren.

Standaarden voor gegevensuitwisseling

Geografische gegevensuitwisseling

Figuur 4.5. Algemeen Basismodel geo-informatie (NEN3610)

Er is door de geografische specialisten van de Veiligheidsregio’s gekozen voor het raamwerk van geografische standaarden dat valt onder de NEN 3610 dat in beheer is bij Geonovum. Onder deze familie van standaarden valt het overkoepelend informatiemodel IMGEO2 en de internationale standaard CityGML.

In figuur 4.5 wordt voor de sector openbare orde en veiligheid de sectorstandaard IMOOV vermeld. Deze sectorstandaard wordt binnen de VeRA voor geografie vervangen door IMGEO2. Binnen de VeRA kiezen we voor het IMGEO informatiemodel. De nieuwe versie van I-DBK voor de digitale bereikbaarheidskaart voldoet aan deze standaard. De DBK wordt daarmee onderdeel van de gehele objectenorganisatie van een regio. Een object bevat attributen met verschillende gebruiksdoeleinden en mate van detail. Onderdelen van dit stelsel zijn de uitwisselformaten WMS, WFS, WMC en WPS. Bij de vastlegging van de gegevens over objecten hebben BGT-plichtige bronbeheerders van de gehele infrastructuur (basisregistratie grootschalige topografie) vanaf 2016 de verplichting en de keuze om hun gegevens vast te leggen volgens het informatiemodel van de BGT standaard of conform IMGEO2. De Veiligheidsregio’s dienen er op aan te dringen dat men IMGEO2 hanteert met een grotere detaillering voor de relevante attributen van het object, zoals ventilatieopeningen van een tunnel.

Semantiek Semantiek betreft de manier om gegevens en kennis van labels (bv. trefwoorden, registers, nummers) te voorzien, zodat stukjes informatie koppelbaar en vindbaar worden. De belangrijkste bijdrage van semantiek is dat dit milde harmonisatie oplevert in plaats van brute standaardisatie. Moderne trefwoordkunde maakt gebruik van flexibele termenlijsten (taxonomieën en ontologieën) die variatie toelaten tussen kolommen of zelfs in zekere mate tussen Veiligheidsregio’s. Dit houdt in dat niet iedereen hetzelfde woord of symbool hoeft te gebruiken, maar voor de gebruiker ziet het er wel hetzelfde uit. Dit maakt semantiek bij uitstek het nieuwe ontwikkelgebied voor crisisbeheersing en voor de relatie tussen alle sectoren en ketenpartners.

Er wordt aangesloten bij een landelijk en een internationaal stelsel. Dit betreft enerzijds de aansluiting bij de intentie van de Nederlandse overheid om te bewegen naar een zo groot mogelijk aanbod van gegevens in het kader van ‘Open Linked Data’. Anderzijds betreft het de nauwkeurige omschrijving van begrippen, symbolen en de dilemma’s bij de definitie van deze begrippen dat dit alleen gefaciliteerd kan worden in een flexibel stelsel van naar elkaar verwijzende en goed onderhouden bibliotheken met gecontroleerde termen.

De standaarden voor Semantiek en Geografie worden aangegeven door het W3C, de NEN en Europese programma’s als INSPIRE. De veiligheidsregio’s hanteren hierbij RDF als standaard voor de uitwisselbaarheid van bibliotheken met gecontroleerde termen en symbolen. Deze standaard biedt de mogelijkheid voor het verbinden van termen aan URI’s (Unique resource identifier). Hiermee wordt een stelsel van onderlinge, flexibele en onderhoudbare termen mogelijk gemaakt. Hierbij is SKOS-XL (simple knowledge organization system - extended) de standaard voor het beheer en het redeneren met concepten.

Samenhang bedrijfsarchitectuur en informatiearchitectuur[bewerken]

Figuur 4.6. Verband tussen processen, bedrijfsfuncties en gegeven

In de voorgaande paragrafen zijn de applicatieve functies en de bijbehorende gegevens benoemd, en is beschreven op welke wijze gegevens uitgewisseld kunnen worden. Deze componenten van de referentiearchitectuur staan niet los van elkaar, er zijn verbanden te benoemen. Deze componenten van de informatie architectuur staan ook weer in verband met de eerder beschreven bedrijfsarchitectuur. In deze paragraaf wordt dit nader toegelicht.

In figuur 4.6 wordt het verband tussen de processen, de bedrijfsfuncties en de gegevens weergegeven. Binnen een proces worden er één of meerdere bedrijfsfunctie aangeroepen. Deze bedrijfsfuncties worden op hun buurt ondersteund door applicatieve functies. Deze kunnen generiek zijn, oftewel gebruikt worden door meerdere bedrijfsfuncties, of specifiek voor de bedrijfsfunctie. De data voor deze applicatieve functie worden geleverd binnen de applicatieve functie zelf (interne gegevensbron) of wordt middels een koppeling opgehaald uit externe databronnen.

Figuur 4.7. voorbeeld: 'verlenen van adviezen'.
Toelichting 
Dit concept is in figuur 4.7 uitgewerkt voor het proces ‘verlenen van adviezen’. Eén van de bedrijfsfuncties die hiervoor aangeroepen wordt is ‘advisering’. De bedrijfsfunctie advisering maakt gebruik van de generieke applicatieve functie ‘zaaksysteem’. Dit zaaksysteem maakt gebruik van interne en externe koppelingen om data op te halen vanuit het bevoegd gezag (OLO), vanuit interne gegevensbronnen (DMS koppelingen) en haalt via een geo proxy server GIS informatie op vanuit de basisregistraties en andere externe gegevensbronnen.
Deze pagina is voor het laatst bewerkt op 10 jan 2024 om 13:47.