OOV Architectuur

Category:Bedrijfsarchitectuur
 __NOTOC__
==Architectuurprincipes==
===Wat zijn architectuurprincipes?===
Architectuurprincipes zijn richtinggevende uitspraken, op basis van strategie, beleid of bijvoorbeeld wetgeving. Door veranderingen of vraagstukken te toetsen aan deze architectuurprincipes weten we of de oplosrichting van veranderingen conform het beleid van de strategie van de verandering is of – waar noodzakelijk – dat hier bewust en weloverwogen van afgeweken wordt. Dit wordt ‘comply or explain genoemd’.
Architectuurprincipes worden omschreven door een krachtig, makkelijk te onthouden ‘statement’, een rationale (waarom is dit principe belangrijk?), implicaties (wat betekend dit nu concreet, wat zijn de gevolgen, waar moeten we rekening mee houden?) en waarvan toepassing een bronvermelding.
In zowel overkoepelende referentiearchitecturen (NORA en GEMMA) als zusterarchitecturen (VeRa [04]) zijn reeds de nodige architectuurprincipes gedefinieerd die in dit domein (her)gebruikt kunnen worden (deze hiërarchie is gevisualiseerd in de plaat in paragraaf 2.2). Daarnaast zijn er aanvullende principes, specifiek voor het domein openbare orde en veiligheid, die volledig beschreven worden.
===Nederlandse Overheid Referentie Architectuur (NORA)===
De NORA is de basisreferentiearchitectuur voor alle overheidsorganisaties. Dochterarchitecturen, voor specifieke overheidsdomeinen, bouwen hier op voort voor hun specifieke domein.
 Principe NORA BP08
 Afnemers kunnen erop vertrouwen dat informatie niet wordt misbruikt.
 Bron
 http://noraonline.nl/wiki/Vertrouwelijk
 Opmerking
 De dienstverlener garandeert dat informatie alleen toegankelijk is voor bevoegde personen en alleen wordt gebruikt voor het doel waarmee zij is verzameld.
 Principe NORA AP07
 De dienst maakt gebruik van de landelijke bouwstenen e-overheid.
 Bron
 
 
 http://noraonline.nl/wiki/Gebruik_de_landelijke_bouwstenen
 http://noraonline.nl/wiki/Bouwstenen
 
 
 Opmerking
 De basisregistraties zijn hier een voorbeeld van
 Principe NORA AP13
 Alle gebruikte informatieobjecten zijn afkomstig uit een bronregistratie.
 Bron
 http://noraonline.nl/wiki/Bronregistraties_zijn_leidend
 Opmerking
 Uitgangspunt is dat er binnen de overheid voor ieder informatie-object een unieke bron bestaat.
 Principe NORA AP14
 Bij gerede twijfel aan de juistheid van informatie, meldt de dienstverlener dit aan de verantwoordelijke bronhouder.
 Bron
 http://noraonline.nl/wiki/Terugmelden_aan_bronhouder
 Principe NORA AP15
 Het doel waarvoor informatie wordt (her)gebruikt is verenigbaar met het doel waarvoor deze oorspronkelijk is verzameld.
 Bron
 http://noraonline.nl/wiki/Doelbinding_(AP). Zie ook VeRa BP1
 Opmerking
 
 
 Het doel waarvoor informatie wordt uitgevraagd, is vastgelegd en getoetst door bevoegde instanties;
 In samenwerkingsrelaties is vooraf bepaald wat het gemeenschappelijke doel van de samenwerking is en of alle deelnemers in het kader hiervan informatie mogen delen, bijvoorbeeld over personen.
 
 
===Gemeentelijke model architectuur (GEMMA)===
 Principe GEMMA
 
 Opmerking
 Uitgangspunt is dat er binnen de overheid voor ieder informatie-object een unieke bron bestaat.
 Principe GEMMA
 
 Opmerking
 
 
 Er zijn duidelijke afspraken over gegevens die worden uitgewisseld met anderen zoals over doel, gebruikstermijn en de standaarden;
 Vermeende onjuistheden in gegevens worden teruggemeld aan de desbetreffende bronhouder van de gegevens.
 
 Principe GEMMA
 
 Opmerking
 Uitgangspunt is dat er binnen de overheid voor ieder informatie-object een unieke bron bestaat.
 Principe GEMMA Opmerking 
 Alle toegang tot autorisatie-objecten wordt expliciet geauthentiseerd en geautoriseerd, tenzij deze openbaar toegankelijk zijn;
 Informatiebeveiliging wordt ook geborgd in afspraken (en controle op naleving ervan) met samenwerkingspartners en leveranciers van diensten of IT-systemen;
 Alle toegang tot gevoelige gegevens wordt gelogd en regelmatig beoordeeld; Uitwisseling van gevoelige gegevens vindt niet in bulk plaats, maar is toegespitst op de vraag zodat het beperkt is tot wat noodzakelijk is.
 
Dit principe is omschreven op applicatiefunctie (autorisatie-object) niveau maar geldt evenzeer op aggregatieniveau in (bijvoorbeeld) big data omgevingen.
 
===Bijzondere principes openbare orde en veiligheid===
De onderstaande principes zijn door de werkgroep onderkend als specifiek voor het domein van openbare orde en veiligheid en bouwen voort op de overkoepelende architectuurprincipes van de NORA en GEMMA en/of sluiten aan op principes uit zusterarchitecturen zoals de VeRa.
 Principe OOV01
 De veiligheid van eigen medewerkers staat voorop bij het uitvoeren van hun taken.
 Rationale
 Medewerkers in het veiligheidsdomein lopen zowel persoonlijk als in hun functie (extra) risico’s als gevolg van hun werk. Het is belangrijk dat alle betrokkenen zich hier van bewust zijn. 
 Implicaties
 
 
 Er dient (extra) zorgvuldig omgegaan te worden met het verstrekken van namen en andere gegevens van functionarissen in dit domein;
 Medewerkers dienen bewust gemaakt te worden dat indien er een (dreigend) incident optreedt ze hun persoonlijke veiligheid voorop staat; 
 Bron
 Geen
 Principe OOV02
 Data-analyses zijn transparant, controleerbaar maar niet openbaar.
 Rationale
 Data-analyses – en in het bijzonder big data-analyses – bieden grote kansen voor de efficiency en effectiviteit van de processen in het gemeentelijk veiligheidsdomein. In tegenstelling tot het verzamelen van gegevens zijn er nog geen goede wettelijke kaders voor het combineren en analyseren van gegevens in een big data context. Big data toepassingen gaan uit van ongericht gebruik van gegevens. Dit kan leiden tot discriminatie, oneerlijke behandeling, ongerichte schending van de privacy van burgers en bruikbaarheid in rechtelijke zaken. De gemeentes moeten daarom kunnen aantonen hoe ze tot bepaalde signalen of conclusies zijn gekomen. Het openbaar maken van deze informatie leidt echter tot ondermijning en smoort de positieve bijdrage van big data-analyses in de kiem. De baseline informatiebeveiliging gemeenten Handreiking dataclassificatie – operationele variant baseline informatiebeveiliging gemeenten, v1.6.1, VNG-KING, Augustus 2016. Zie: https://www.ibdgemeenten.nl/wp-content/uploads/2016/08/20160803-Handreiking-dataclassificatie-1.6.1.pdf helpt deze informatie te beschermen. Dit staat wel op spanning met de wet open overheid (WOO) waarin juist transparantie wordt afgedwongen. Dit principe biedt, mede op basis van het rapport van de Wetenschappelijke Raad voor het Regeringsbeleid Rapport 95: Big Data in een vrije en veilige samenleving, Wetenschappelijke raad voor het regeringsbeleid, Den Haag. Zie http://www.wrr.nl/publicaties/publicatie/article/big-data-in-een-vrije-en-veilige-samenleving/, een handvat hoe om te gaan met deze uitdaging.
 Implicaties
 
 
 De gemeentes mogen gegevens zie ze in het kader van het uitvoeren van hun wettelijke taken mogen gebruiken, combineren en analyseren mits de doelbinding blijft bestaan (er mag dus geen sprake zijn van ‘function creep’ – het gebruik van gegevens anders dan voor het doel waarmee de data zijn verzameld [NORA AP15];
 De gemeentes hebben een zorgplicht met algemene vereisten voor de kwaliteit van de data en van de deugdelijkheid van de gehanteerde analysemethoden;
 Profielen, algoritmen en methoden die gebruikt worden bij data-analyses zijn goed beschreven en resultaten zijn verklaarbaar en reproduceerbaar; 
 De gemeentes moeten altijd duidelijk kunnen maken hoe zij tot bepaalde uitkomsten komen;
 De vertrouwelijkheid van de analyse profielen, algoritmen en methoden hebben een dataclassificatie ‘vertrouwelijk’ ;
 De analyses en conclusies moeten door een vertrouwde, onafhankelijke derde toezichthouder gecontroleerd kunnen worden (bijvoorbeeld ten behoeve van verantwoordenting naar de rechtelijke macht) zonder de inhoud openbaar te maken; 
 Big data projecten plannen vooraf een evaluatiemoment in.
 
 Bron
 
 
 WRR95 '
 Handreiking dataclassificatie 
 NORA AP15
 GEMMA 4
 Wet Open Overheid
 
 Principe OOV03
 Geautomatiseerde besluitvorming op basis van big data-analyses is niet toegestaan.
 Rationale
 Big data-analyses zijn per definitie algemene conclusies en structurele patronen. Zonder tussenkomst van een kennisfunctionaris mogen hier nooit besluiten uit worden genomen. Dit is wettelijk niet toegestaan en kan discriminatie en oneerlijke behandeling in de hand werken.
 Implicaties
 
 
 Profilering moet strak ingeregeld worden met lage foutmarges; 
 Semi-geautomatiseerde besluitvorming moet voorkomen worden – een functionaris zal altijd weloverwogen een besluit moeten nemen.
 
 Bron
 WRR95 
 Principe OOV04
 Gemeenten maken afspraken met partners om in het geval van rampen de informatiesluizen op te zetten. 
 Rationale
 In het geval van rampen mogen er geen vertragingen en/of belemmeringen zijn in de informatie-uitwisseling tussen de partners. Gemeenten moeten daarom samen met de partners afspraken maken dat in het geval van rampen de informatie-uitwisseling direct tot stand gebracht wordt.
 Implicaties
 
 
 De benodigde informatie dient in kaart gebracht te worden;
 Er dient een protocol afgesproken te worden met de betreffende partijen dat in het geval van rampen er direct toegang tot de informatie verkregen kan worden;
 Deze afspraken dienen juridisch getoetst te worden;
 Waar mogelijk dient de informatie-uitwisseling geautomatiseerd te worden.
 
 Bron
 Praktijk afspraken van de veiligheidsregio’s met partners.
==Wetten==
Dit onderdeel is in de context van het project ‘domeinarchitectuur openbare orde en veiligheid’ niet opgepakt. De werkgroep beveelt aan om de relatie tussen de taken en de wetten inzichtelijk te maken in een architectuurmodel. Dit geeft een eerste overzicht van de rechtvaardigen en doelbinding van de taken.
===Actoren en rollen===
Dit onderdeel is in de context van het project ‘domeinarchitectuur openbare orde en veiligheid’ niet opgepakt. De werkgroep beveelt aan om alle spelers in het domein openbare orde en veiligheid in kaart te brengen. Dit helpt om overzicht van het domein te krijgen en met welke partners er samengewerkt kan of moet worden.
==Bedrijfsfunctiemodel met subfuncties==
===Inleiding===
In de GEMMA bedrijfsarchitectuur staan bedrijfsfuncties centraal. 
Een bedrijfsfunctie is een beschrijving van de taken (functies) die een gemeente uitvoeren onafhankelijk van keuzes hoe deze uitgevoerd worden (zoals een procesbeschrijving).
Het bedrijfsfunctiemodel van de GEMMA geeft een overzicht van het gehele gemeentelijke takenpakket . Om dit model herkenbaar en goed bruikbaar te maken is er een hiërarchie in aangebracht. Op het hoogste niveau zijn er 8 groepen van functies te onderscheiden: sturing, klant- en keteninteractie en uitvoering. Elke groep bestaat uit generieke bedrijfsfuncties zoals producten en dienstenrealisatie, toezicht en handhaving etc.
===Model===
Het onderstaande model toont het generieke bedrijfsfunctiemodel van de gemeenten met daarop geprojecteerd de bedrijfsfuncties die belangrijk zijn voor het veiligheidsdomein. Specifieke functies zijn in oranje weergegeven, generieke functies die ook belangrijk zijn in het veiligheidsdomein zijn in licht-oranje weergegeven.
===Toelichting===
De bedrijfsfunctie data-analyse zoals deze nu beschreven is, is een eerste stap richting een informatieknooppunt. Dit concept wordt verder uitgewerkt in het VIK-project zie ook paragraaf 3.2.1 en voor meer details het VIK-project (zie [15]).
===Relatie partner- en ketenorganisaties===
De relatie met de bedrijfsfuncties van de veiligheidsregios is beschreven in paragraaf 2.2.3. Een deel van de functies uit deze domeinarchitectuur is hier sterk aan gerelateerd.
==Bedrijfsfunctiemodel met bedrijfsobjecten==
Dit onderwerp is in de context van het project ‘domeinarchitectuur openbare orde en veiligheid’ niet opgepakt. De werkgroep beveelt aan om het informatielandschap in dit domein uit te werken. Dit geeft een globaal inzicht waar, welke informatie gebruikt wordt en/of beschikbaar is.
==Bedrijfsfunctiemodel met Referentiecomponenten==
===Inleiding===
Voor het uitvoeren van bedrijfsfuncties wordt er vaak gebruikt gemaakt van ondersteunende softwarepakketten. Om gemeenten te ondersteunen in de keuze welke softwarepakketten geschikt zijn voor de ondersteuning van hun bedrijfsfuncties heeft KING een softwarecatalogus opgebouwd. De softwarecatalogus geeft invulling aan de referentiecomponenten die bedrijfsfuncties ondersteunen.
Referentiecomponenten zijn door KING beschreven voor zowel specifieke als generieke functionaliteit. Leveranciers van gemeentelijke informatiesystemen kunnen via hun softwareproducten één of meer referentiecomponenten realiseren. Bij de doorontwikkeling van de referentiecomponenten worden toevoegingen en wijzigingen getoetst op basis van de definitie en beoordelingscriteria.
In deze paragraaf wordt specifiek gekeken welke referentiecomponenten geïdentificeerd kunnen worden in het openbare orde en veiligheidsdomein. Deze zullen in de GEMMA worden opgenomen en zullen in de softwarecatalogus de softwarepakketten worden opgenomen die hier invullen aan geven.
===Applicatiecomponenten===
De referentiecomponenten die gebruikt worden ter ondersteuning van de bedrijfsfuncties zijn opgesomd in de onderstaande tabel.
Kandidaat referentiecomponenten die nog geen plaats hebben zijn opgenomen in de onderstaande tabel. Hiervan zal in een komende iteratie bepaald moeten worden of ze opgenomen moeten worden of afgevoerd.
 Referentiecomponent
 Definitie
 Opmerking
 Voorbeeld
 Cameratoezichtcomponent
 Component voor toezicht in de openbare ruimte met behulp van camera’s
 	
 	
 Gedwongen-opname-component
 	
 Valt binnen het sociaal domein
 Webtool gedwongen opname
	
 Bedrijfsobjecten component
 Inspectieview is een virtueel dossier voor inspecteurs om informatie over inspectieobjecten te raadplegen.	
 	
 Inspectieview 
===Model===
===Toelichting===
Voor de bedrijfsfunctie ‘gegevensanalyse’ worden verschillende informatiebronnen gebruikt. Deze worden in het model niet expliciet genoemd. De onderstaande lijst geeft een niet-limitatieve opsomming:
* Basisregistraties
* Kernregistraties
* Zaakregistratie
* Door derden aangeleverde informatie (bijvoorbeeld de politie)
* Data en/of signalen uit het ‘internet of things’ (zie paragraaf 2.3) en social listening (zie paragraaf 2.4)
* Etc.
==Applicatiefuncties met applicatiecomponenten==
===Applicatiefuncties===
Het bestaansrecht van applicaties is dat ze bepaalde functionaliteit aan een gebruiker bieden ten behoeve van het ondersteunen van een bedrijfsproces of -functie. Het model in dit hoofdstuk geeft aan welke applicatiecomponenten gebruikt worden voor welke (applicatie)functies.
===Model===