OOV Inleiding

Category:Bedrijfsarchitectuur
__NOTOC__
==Totstandkoming==
In de gemeentelijke adviesgroep informatievoorziening is het initiatief ontstaan om een eerste sessie te organiseren over de domeinarchitectuur openbare orde en veiligheid (zie [10]). In deze sessie hebben de gemeenten Breda, Eindhoven en Tilburg zich uitgesproken een voorstel voor deze domeinarchitectuur te willen maken. Dit voorstel is bij de productmanager van de GEMMA neergelegd die zich ook achter dit initiatief heeft geschaard.
Het initiatief heeft geresulteerd in een werkgroep bestaande uit de gemeenten Breda, Eindhoven, Tilburg en Hoorn, KING, RIEC Zeeland, West en Oost Brabant, de kamer van koophandel, twee externe experts op het domein en een externe architect. De werkgroep heeft een lijst met knelpunten opgesteld die de gemeenten in dit domein ervaren. De werkgroep komt elke vier weken bijeen om te bespreken welke knelpunten opgepakt worden en bespreekt de resultaten van de uitgewerkte knelpunten. De uitgewerkte knelpunten vindt u terug in hoofdstuk 3 en de knelpunten die wel benoemd zijn, maar nog niet zijn uitgewerkt vindt u terug in de bijlage ‘openstaande knelpunten’. 
Naast deze domeinarchitectuur ontwikkelt KING samen met partners in het gemeentelijk domein nog een viertal domeinarchitecturen te weten de domeinarchitecturen ‘bedrijfsvoering’, ‘dienstverlening’, ‘ruimte’ en ‘sociaal’. Deze domeinarchitecturen beschrijven primair het taakveld en de benodigde applicatieve ondersteuning hierin. Dit deel van de architectuur van het veiligheidsdomein wordt in hoofdstuk 4 beschreven.
Naast de leden van de werkgroep zijn er gesprekken gevoerd met de informatiebeveiligingsdienst (IBD) van VNG en een kennishouder van de referentiearchitectuur van de veiligheidsregio’s (VeRa, zie [04]). Raakvlakken met deze kennisdomeinen zijn ook opgenomen in dit rapport in hoofdstuk 2. Eind 2016 is de eerste versie van dit rapport aan de productmanager GEMMA aangeboden.
==Opdracht==
Het, samen met de betrokken gemeentes en KING, schrijven van een voorstel voor een domeinarchitectuur Openbare orde en veiligheid
De domeinarchitectuur moet de gemeentes helpen bij het beantwoorden van organisatie- en informatievraagstukken op het gebied van het beschermen van de integriteit van de gemeente, de bescherming tegen misbruik van overheidsvoorzieningen en -vergunningen en het vervolgens gericht kunnen handhaven [05]. De domeinarchitectuur geeft inzicht en overzicht op basis waarvan besluiten genomen kunnen worden. Ook helpt de domeinarchitectuur om verzuiling tegen te gaan.
De werkgroep - vooralsnog bestaande uit KING, de gemeenten Breda, Eindhoven en Tilburg - zal het voorstel bij KING en de betrokken gemeenten indienen. De nadruk ligt op het onderdeel veiligheid. 
==Scope==
De scope van deze domeinarchitectuur is in de werkgroep van 14-09-2016 geformuleerd als:
In scope:
* Besturing en monitoring van de veiligheid;
* Publiek en privaatrechtketens;
* Milieudelinquenten;
* Vastlegging en kwaliteitscontrole van de informatie;
* Raakvlakken met taken en bevoegdheden in het sociale domein;
* Signalen, beleid, indicatoren, handhaving en de terugkoppeling van handhaving.
Buiten scope:
* Rampenbestrijding - alleen de relatie met de VeRa wordt vastgelegd;
* Bestuur – in de werkgroep is besloten dit aspect vooralsnog buiten beschouwing te laten; we spreken daarom over de domeinarchitectuur ‘openbare orde en veiligheid’.
==Werkgroep==
De werkgroep voor dit project bestaat uit de onderstaande leden. Opdrachtgever is Theo Peters (productmanager GEMMA).
* Kwaliteitsinstituut Nederlandse Gemeenten* Gemeente Breda* Gemeente Eindhoven* Gemeente Tilburg* Gemeente Hoorn* RIEC Zeeland, West en Oost Brabant* Adviseur criminaliteit/integrale veiligheid* Adviseur privacy* Kamer van Koophandel
==Leeswijzer==
Het rapport is een bundeling van de resultaten van de werkgroep. Via de inhoudsopgave kan gericht gezocht worden op specifieke onderwerpen.
* Hoofdstuk 2 geeft de context van het domein openbare orde en veiligheid en beschrijft de raakvlakken met gerelateerde architecturen, relevante artikelen en andere partijen in en met dit domein;
* Alle beschreven knelpunten zijn als separate artikelen terug te vinden in hoofdstuk 3. Alle onderkende, nog niet beschreven knelpunten zijn terug te vinden in de bijlage van dit rapport;
* Hoofdstuk 4 beschrijft de typische architectuur instrumenten: architectuurprincipes, het bedrijfsfunctiemodel en de referentiecomponenten.
Aangezien er verschillende auteurs hebben meegewerkt aan dit rapport kan het taalgebruik verschillen. Verwijzingen naar de literatuurlijst in de bijlage worden weergegeven als [xx] waarbij ‘xx’ het volgnummer van de referentie in de bijlage is.
De context en het gebruik van deze architectuur is beschreven in een handreiking (zie [16]).
==Samenvatting==
Het taakveld van de gemeente in het domein architectuur en veiligheid raakt het een groot deel van het gemeentelijke taakveld. We kunnen openbare orde en veiligheid dan ook zien als een integraal aspect van het gemeentelijk taalveld. In het bijzonder komt de samenwerking met partners als de veiligheidsregio’s, de politie, burgerinitiatieven en vele andere partijen terug. Ook springen de taken op het gebied van data-analyse in het oog. Enerzijds liggen hier grote kansen in het verbeteren van het opsporen van criminele activiteiten, anderzijds moeten we waken dat we voorkomen dat burgers het slachtoffer van discriminatie en stigmatisering worden.
Ook blijken de bevoegdheden en de doelmatigheid in het taakveld een bijzonder complex issue. Wat mogen de verschillende partners – en in het bijzonder de gemeente – in het veiligheidsdomein? Hier valt geen eenduidig antwoord op te geven, maar de verschillende onderwerpen die in deze domeinarchitectuur behandeld worden geven wel de nodige handvatten en leidraden hoe hier mee opgegaan kan worden. In de deze versie van de domeinarchitectuur zijn de volgende knelpunten beschreven:
* Context van het veiligheidsaspect 
* Een korte introductie op het Internet of Things
* Een korte introductie op social listening
* Bevoegdheden rechtmatig gebruik van informatie
* Gebruik basisregistraties en terugmelding word niet goed ingezet
* Het gemeentelijk veiligheidsdomein is nog een silo
De inzichten die zijn verkregen zijn ook uitgewerkt in architectuurmodellen. Samen met de architectuurmodellen uit de domeinen sociaal, ruimtelijk, dienstverlening en bedrijfsvoering wordt hiermee per domein een verdieping in de generieke gemeentelijke referentiearchitectuur gemaakt.
Hoewel niet alle genoemde knelpunten bij de oplevering van de eerste versie van deze domeinarchitectuur zijn beschreven, hebben de uitgewerkte knelpunten en de discussies hierover in de werkgroep een beter inzicht in het domein gegeven. Deze inzichten worden dan ook gebruikt in projecten die op onderdelen hiervan verder gaan zoals het VIK-project. In navolging van dit project doen we de onderstaande aanbevelingen:
# Werk de onderstaande knelpunten uit. Dit kan als los vraagstuk worden opgepakt of binnen de scope van nieuwe of lopende projecten worden opgepakt:
#* Social Listening (zie paragraaf 2.4)
#* Internet of things (zie paragraaf 2.3)
# Haak aan bij de interviews die worden afgenomen i.h.k.v. het project ‘VNG-visie informatie en veiligheid op lokaal niveau’ – dit kan het beeld aanscherpen van de gebruikte informatie en de terugkoppeling van potentieel foute informatie;
# Werk de nog openstaande knelpunten uit – al dan niet in vervolgprojecten. Van de meeste knelpunten is een nadere omschrijving gegeven in de bijlage.
#* Omgaan met teveel signalen
#* Vaststelling identiteit, rechten ontleend aan het BSN-stelsel
#* Landelijke aanpak, gemeentegerichte benadering wordt misbruikt
#* Hoe gaan we om met de gegevens in het veiligheidsdomein?
#* Opsporingsmethoden nog voldoende? Hoe mag je data inzetten?
#* Voorkomen perverse prikkels
#* Losse registraties andere partijen
#* Wildgroei aan ICT-oplossingen
#* Hoe om te gaan met andere privacy data in sociale media.
#* Wat zijn de opsporingsmethoden en technieken die we mogen gebruiken?
#* Welke oplossingen zijn er al?
#* Risico-indicatoren zou je kunnen gebruiken?
#* Welke patronen/best practices zijn er?
#* Overzicht signalen per partij
#* Bepalen informatieclassificatie o.b.v. bedrijfsvoering of veiligheidsaspect
#* Opstellen benodigde informatie (business objecten)
#* Opstellen motivatoren (wetten, gemeentelijke taken, etc.)
#* Opstellen benodigde functies (rollen) en competenties
# Werk de benodigde functionaliteit van de referentiecomponenten uit in de modellen (applicatiefuncties);
# Positioneer deze architectuur als een aspectarchitectuur (in plaats van domeinarchitectuur) aangezien de scope genieriek en overkoepelend over de domeinen is;
# Breng het informatielandschap in kaart door de gebruikte bedrijfsobjecten te beschrijven en deze te relateren aan de bedrijfsfuncties. Dit geeft een globaal inzicht voor welke taken, welke informatie nodig is.
# Breng alle partijen in kaart die een rol hebben in dit domein. Breidt hiervoor de bestaande architectuurmodellen uit, bijvoorbeeld door de bedrijfsfuncties te relateren aan de partijen die hier een rol in hebben.