4. Informatiearchitectuur

Informatiearchitectuur: applicatie(landschap)

Code

Principe/Toelichting

Status

P4.1.1

Koppelvlakken minimaliseren en standaardiseren: Het onderbrengen van functionaliteit in verschillende applicaties vindt alleen plaats als voor het koppelvlak tussen die applicaties standaarden aanwezig zijn. Onderbouwing

Zonder standaarden geen heldere koppelvlakken. En zonder heldere koppelvlakken heeft het geen zin om functionaliteiten te scheiden.

Implicatie:

Daar waar mogelijk worden koppelvlakken gecombineerd. ODT heeft geen eigen servicebus waarover alle koppelingen worden gefaciliteerd. Binnen de VTH-Applicatie wordt hiervoor gebruik gemaakt van de geïntegreerde servicebus van de leverancier. Van hieruit worden de koppelingen gefaciliteerd met landelijke koppelingen en koppelingen met gekoppelde componenten.

Voor de koppeling met de landelijke voorzieningen vanuit de VTH-Applicatie wordt Centraal Aansluitpun t gebruikt om de koppelingen te combineren.

Voor het uitwisselen van data voor management informatie geldt dat hiervoor een apart principe P4.1.5.1

P4.1.2

Kanalen scheiden van processen: Kanaalontvangst en kanaalverzending zijn gescheiden van de generieke opbouw van het proces. Onderbouwing

Elk kanaal kent een specifieke organisatie, handelingen en systemen. Deze dienen per kanaal geconfigureerd te worden. Daarna vindt de stap van ontvangst plaats. Hierin vindt registratie plaats van de zaak, de dienstafnemer (eindklant of opdrachtgever) en wordt de zaak de organisatie ingebracht. In het kanaal post vinden specifieke handelingen plaats (postsortering, scanning, character recognition) die heel anders zijn dan de handelingen in de kanalen e-mail (alleen routeren naar de processtap ontvangst) en telefonie (telefoonnotitie vastleggen en deze routeren naar de processtap ontvangst). Het is zaak in de processtap “Ontvangst” de kennis te concentreren die zorgt dat de zaak juist wordt geregistreerd en wordt uitgezet in de organisatie. Hetzelfde geldt voor uitgaande informatie.

PETRA

P3.3.3

P4.1.3

Besturing en ondersteuning modulair maken: In een applicatie is de besturing van de uitvoering gescheiden van de ondersteuning van de uitvoering. De applicatie houdt daar rekening mee in haar modulaire opbouw. Onderbouwing

Dit volgt uit het principe ‘1 ding in 1 doos’ (modulariteit). Vermenging van besturing en inhoud leidt tot logge, inflexibele en dure systemen. Scheiding geeft de flexibiliteit om onderdelen van de functionaliteit (modules van applicaties) wel of niet te gebruiken. De modulaire opbouw van zo’n applicatie draagt ook bij aan het helder definiëren van koppelvlakken die nodig zijn om de besturingsinformatie of de uitvoeringsinformatie uit te wisselen als dat nodig is (besturingsinformatie wil je bijvoorbeeld uitwisselen als je een integraal klantbeeld wilt opbouwen of informatie wilt verstrekken over de status van de dienstverlening). 

Implicaties

Het vraagt om een modulaire opbouw van applicaties. Het vraagt om het gebruik van gestandaardiseerde gegevens voor de externe koppelvlakken.

PETRA

P4.1.16

P4.1.4

Zaken en projecten scheiden: Zaken en projecten vragen om eigen functionaliteit die door verschillende applicaties worden ondersteund. Onderbouwing

Het onderscheid tussen een zaak en een project is wezenlijk.

Een zaak wordt uitgevoerd volgens de definitie van een zaaktype, dit standaardiseert de uitvoering van alle zaken die van dat type zijn, het definieert de processtappen, de wettelijke termijn en de dossiervorming. De focus ligt daarbij op beheersing van de uitvoering. De besturing ligt in de dagelijkse leiding.

Projecten worden niet gerubriceerd naar projecttype. Alle projecten kennen in de basis dezelfde fasering, mits de omgevingsdienst een werkwijze voor projectmatig werken hanteert. Daarbinnen is elk project uniek en kent een eigen tijdelijke organisatie.

Implicaties

Een werkwijze voor projectmatig werken afspreken. Aan de hand daarvan vaststellen of een aparte projectadministratie noodzakelijk is. Op basis van een eerste inventarisatie is gebleken dat er momenteel geen behoefte is aan een aparte projectadministratie en dat projecten ook als zaak worden gezien.

Dit houdt in dat er een apart zaaktype: Project Uitvoeren  zal komen waaronder projecten geregistreerd gaan worden voor verantwoording.

Toelichting projectregistratie

In ODIE wordt vastgelegd of een project lokaal, regionaal of landelijk wordt uitgevoerd (conform de indeling van de uitvoeringsprogramma’s). Door dit onderscheid wordt het mogelijk om bestede uren en gerealiseerde projecten (efficiënt) te rapporteren ten opzichte van de uitvraag middels de uitvoeringsprogramma’s.

Daarnaast wordt in ODIE vastgelegd of een project t.l.v. het UP (uitvoeringsprogramma) wordt uitgevoerd of extern gefinancierd wordt. Door hier bij registratie onderscheid in aan te brengen, is het altijd inzichtelijk of projecten gerapporteerd moeten worden ten laste van het uitvoeringsprogramma of dat uren die zijn gemaakt op projecten extern gefactureerd moeten worden. In verband met dit onderscheid worden projecten altijd aangemaakt door iemand van Financiën (Teammanager Bedrijfsvoering & Control, Financieel Adviseur of Finance Trainee).

Daarnaast zijn er “overige projecten” waaronder directe zaken als accountmanager, coördinator en team admin worden geregistreerd. Hierdoor worden deze uren zoveel mogelijk rechtstreeks geschreven op een Bevoegd Gezag en worden de overige uren hiervan toegerekend aan de Bevoegde Gezagen. Aangezien deze werkzaamheden onder “Project overig” worden geregistreerd, vertroebelen deze niet het aantal lokale, regionale en landelijke projecten.

PETRA

P4.1.6

P4.1.5

Managementinformatie: Managementinformatie wordt via een tussenstap vastgelegd (in een gegevenspakhuis, bestaande uit een datalake en een datawarehouse).  De verschillende registraties die de bron vormen voor de KPI’s zijn de bron voor dit gegevenspakhuis. Uitwerking

De gewenste rapportages zijn vastgelegd in het rapportage producten boek . In het rapportage producten boek zijn de rapporten en de doelgroepen/rollen beschreven die toegang mogen tot de rapportages.

Het gegevenspakhuis bestaat uit meerdere lagen. Zie de technische uitwerking in hoofdstuk 5 .

Aanleveringen aan het gegevenspakhuis vindt bij voorkeur plaats via CSV aanlevering: De definitie van rapportages en KPI's leiden tot duidelijke registraties en dus ook tot te realiseren exports van data richting het gegevenspakhuis. Implicatie:

Door de exports te definiëren, is het duidelijk wat het koppelvlak is. Hiermee is bij vervanging van een component het ook relatief makkelijk om een zelfde export aan te leveren om de keten tot aan de rapportage werkend te houden. Door het vastleggen van de registratie van gegevens in de verschillende systemen en de registratie van de gewenste exports, heeft ODT ook altijd het ontwerp als referentie beschikbaar.

Vanuit Common Ground wordt ook meer aangestuurd op RESTfull API's, ook dit zijn geaccepteerde bronnen voor aanlevering, maar hebben (nog) niet de voorkeur voor de aanlevering naar het gegevenspakhuis.

De exports worden in de datasets gemarkeerd met export in de aanduiding. Alle exports die gemaakt worden, zijn ook als bron beschikbaar voor het gegevenspakhuis.

Informatiearchitectuur: applicatie(landschap) – de werkplek

Code

Principe/Toelichting

Status

P4.1.6

-----

U 3

Eén interface op de IT-werkplek: De gebruiker heeft via 1 interface toegang tot alle applicaties waartoe hij / zij is geautoriseerd. Dit ongeacht de wijze waarop de applicatie wordt geleverd (ASP, SaaS, ODT-systeem, gemeente-systeem, landelijk systeem). Onderbouwing

Voor de gebruiker moet het niet uitmaken of een applicatie intern of extern staat, en of de applicatie door de omgevingsdienst of door een andere partij wordt geleverd.

P4.1.7

-----

U 3

Centrale ontsluiting applicaties: ODT stelt de applicaties centraal beschikbaar aan de medewerker. De medewerker kan hiermee onafhankelijk van plaats, tijd en werkplek werken. 

Waarbij de voorkeursvolgorde uitgaat naar:

2. Centrale ontsluiting van applicaties, de voorkeur voor alle functionaliteiten die niet door webbased applicaties kunnen worden geleverd

3. Distributie naar de fysieke werkplek (via intune of zelf installatie)

Implicatie

De medewerker kan op elke standaard ODT IT-werkplek toegang krijgen tot de applicaties. De medewerker kan op een niet-ODT IT-werkplek toegang krijgen tot de applicaties mits het device aan enkele standaarden voor het koppelvlak voldoet (instellen van de browser of installatie van een client-applicatie om de centrale applicatieomgeving te kunnen benaderen).

P4.1.8

-----

U 3

Integrale werkplek: Applicaties die beschikbaar worden gesteld voor samenwerking in een dienstverleningsketen worden integraal ontsloten vanuit de werkplek van de medewerker. Onderbouwing

De informatie moet bereikbaar zijn. Daarom moeten de applicaties integraal worden ontsloten. Dit voorkomt dat een medewerker op meerdere omgevingen moet inloggen of telkens andere handelingen moeten uitvoeren om te komen bij de informatie die voor het uitoefenen van de functie nodig is.

Implicaties

De impact is groot. Er moeten hogere eisen worden gesteld aan de applicaties zodat deze voldoen (servicegericht, federatieve single-signon). Ook stelt het hoge eisen aan de processen die zorgen dat medewerkers worden geautoriseerd voor het gebruik van applicaties en informatie.

Er moet van worden uitgegaan dat dit niet in 1 keer, en zeker niet in de beginfase kan worden gerealiseerd, als medewerkers de applicaties bij de deelnemers moeten gebruiken. Dit moet zorgvuldig worden gecommuniceerd. Op dit moment (2021) wordt gewerkt aan de implementatie van een eigen HR en Financiele administratie. Hiermee is er geen noodzaak meer tot inloggen op een virtuele werkplek bij Almelo. Zodra de bodem licenties overgedragen zijn, voor de bodem informatie beheer taken, zijn alle applicaties vanuit de werkplek beschikbaar, zonder tussen stap op een gecentraliseerde omgeving bij een deelnemer of ketenpartener(Citrix. o.i.d.)

P4.1.9

Gegevens niet dubbel invoeren: Applicaties in een samenwerkingsomgeving zijn gericht op informatie-uitwisseling (het gegevensknooppuntconcept) en zijn niet gericht op gegevensopbouw die in de bronregistraties van de deelnemende partijen thuishoort. Onderbouwing

Voorkomen van dubbele opslag en onvolledige, vage dossiers. Eenmalige opslag, meervoudig gebruik. Gebruik van authentieke gegevens.

Implicaties

Duidelijke status geven aan samenwerkingsdossiers en hoe deze informatie uiteindelijk wordt geborgd (OLO, GIR). 

P4.1.10

-----

U 3

Voor elk devicetype 1 standaard: De ODT biedt de medewerker voor elk ondersteund devicetype (desktop, laptop, netbook / tablet / smartphone) 1 standaard. Voor deze standaard is het dienstverleningsniveau benoemd en bezegeld. Ondersteuning

Dit is om wildgroei te voorkomen en om 1 interface op de werkplek, centrale ontsluiting van de werkplek en de integraliteit van de werkplek te kunnen realiseren.

Implicatie

Dit vraagt om afspraken over standaardisatie en nadenken over bijvoorbeeld een enkel type device voor de uitvoering van een functie. (Een toezichthouder die met een tablet volledig zijn taken kan uitvoeren?)

P4.1.11

Ondersteuning dienstdevice: De omgevingsdienst zorgt volledig voor de ontsluiting van de dienstapplicaties op het dienstdevice. De omgevingsdienst geeft geen ondersteuning voor een niet-dienstdevice. Onderbouwing

De omgevingsdienst kan alleen verantwoordelijk zijn voor iets waar ze zeggenschap over heeft bezegeld.

P4.1.12

Geen ondersteuning niet-dienstapplicaties op niet-dienstdevice: Het ontsluiten van niet-dienstapplicaties op een niet-dienstdevice is geen verantwoordelijkheid van de omgevingsdienst.

Onderbouwing

De omgevingsdienst kan alleen verantwoordelijk zijn voor iets waar ze zeggenschap over heeft bezegeld.

P4.1.12a

Beperkte ondersteuning dienstapplicaties op niet-dienstdevice: Het ontsluiten van dienstapplicaties op een niet-dienstdevice wordt slechts beperkt ondersteund. Onderbouwing

Het moet mogelijk zijn voor externe inhuur om met eigen devices gebruik te maken van een aantal basisvoorzieningen van de ODT. Dit voorkomt een onnodige voorraad dienstdevices. 

Implicaties

Denk hierbij aan het krijgen van een e-mail en agenda account op een eigen device. Hiervoor zal ook een securitybeleid opgesteld moeten worden, wat wenselijk en niet wenselijk is. Het securitybeleid van gemeente Almelo wordt hierbij zo veel mogelijk gevolgd.

P4.1.13

Afspraken beschikbaarheid niet-dienstapplicaties: ODT maakt afspraken over de beschikbaarheid van de externe verbindingen voor de niet-dienstapplicaties op een dienstdevice op basis van een risicoanalyse. Onderbouwing

Aanname is dat dit soort niet-dienstapplicaties in het kader van Het Nieuwe Werken worden gebruikt en veelal webbased zijn (bijv. sociale media). De risicoanalyse moet uitwijzen of de applicatie een bedreiging vormt voor de IT -omgeving van de ODT. Afspraken worden gemaakt over het gebruik en de bandbreedte van de externe verbindingen. Omdat de applicatie niet van de ODT is kunnen over de beschikbaarheid van de applicatie zelf verder geen garanties worden gegeven.

Uitwerking

De werkplek is zo ingericht dat het mogelijk is gebruik te maken van niet-dienst applicaties. Hierop wordt in de praktijk ook geen ondersteuning aan geboden, dan wel best-effort.

R4.1.1

-----

R4.1.7

Applicatievirtualisatie: De omgevingsdienst past bij de ontsluiting van dienstapplicaties applicatievirtualisatie of applicatiecontainers toe. Onderbouwing

Virtualisatie verhoogt de beschikbaarheid van de applicaties doordat de applicaties elkaar minder kunnen beïnvloeden en doordat alleen dat beschikbaar wordt gesteld wat de gebruiker echt nodig heeft. Desktop virtualisatie wordt (nog) niet toegepast omdat deze oplossing hogere eisen stelt aan de centrale IT-infrastructuur, geen enkel gebruik maakt van de capaciteit op het device en (nog) onvoldoende marktconform is.

Uitwerking

Omgevingsdienst Twente heeft afgezien van de Microsoft Azure voorzieningen geen "eigen" servers. Ingekochte diensten worden op basis van Software as a Service ingekocht. Hierbij wordt uitgegaan dat leveranciers hun software in gerepliceerde en gevirtualiseerde omgevingen hebben gezet.

R 4.1.2

Software as a Service en Servervirtualisatie: De omgevingsdienst past bij de ontsluiting van dienstapplicaties het principe van Software as a Service toe. Software wordt zoveel mogelijk als dienst afgenomen van een leverancier. Indien dit niet mogelijk is dan wordt servervirtualisatie teogepast. Onderbouwing

Servervirtualisatie zorgt voor een hogere beschikbaarheid van het besturingssysteem waarop applicaties worden geleverd. Virtualisatie van de servers bespaart capaciteit in het serverpark, verhoogt de beschikbaarheid (snellere vervanging), vereenvoudigt uitbreiding van de OTAP-omgevingen en kan bij het juist toepassen van standaardisatie kosten besparen.

Uitwerking

Omgevingsdienst Twente heeft afgezien van de Microsoft Azure Active Directory geen "eigen" servers. Ingekochte diensten worden op basis van Software as a Service ingekocht. Hierbij wordt uitgegaan dat leveranciers hun software in gerepliceerde en gervirtualiseerde omgevingen hebben gezet.

R4.1.3

Overal 1 keer inloggen: De omgevingsdienst past bij het toegankelijk maken van dienstapplicaties federatieve single-sign-on toe. Onderbouwing

Dit vergroot het gebruiksgemak, vermindert het autorisatiebeheer, vermindert de kans op beveiligingsincidenten.

Implicatie

Dit heeft een grote impact.

Dit gaat alleen maar werken als de omgevingsdienst en de leveranciers afspraken maken over het gebruik van een federatieve oplossing voor de toegang tot de geautomatiseerde werkomgeving. Gebruikers maken immers gebruik van meerdere omgevingen.

Middels Microsoft Azure Active Directory wordt binnen Omgevingsdienst Twente de single-sign-on gerealiseerd. De Active Directory is de plek voor autorisatie tot groepen of rollen. Hierop wordt aangesloten voor het gebruik van individuele applicaties.

Bij kleine applicaties of leveranciers zonder koppelpunten op de SSO voorziening, zal de applicatie eigen inlegvoorziening worden gehanteerd.

Aangepast

08-04-2021

Informatiearchitectuur: gegevesverwerkinggegevensverwerking

Code

Principe/Toelichting

GM-BP1 GM-BP2 GM-BP3

Ten aanzien van het gegevensmanagement zijn de volgende basisprincipes benoemd in GEMMA en dienen als hoofdprincipes voor gegevensmanagement.:

• GM-BP1 - Gegevens zijn een bedrijfsmiddel en hebben waarde;
• GM-BP2 - Gegevens worden gedeeld;
• GM-BP3 - Gegevens worden conform wet- en regelgeving verwerkt.

Een onderverdeling naar soorten gegevens is verder in dit document gemaakt 

Informatiearchitectuur: applicatie(landschap)

Code

Principe/Toelichting

Status

P4.1.14

Gebruik authentieke gegevens: Elk authentiek gegeven wordt in 1 bronregistratie gecreëerd, gewijzigd en verwijderd. De applicaties zijn hiervoor uitgerust met services die alle benodigde bedrijfslogica gebruiken. Het authentieke gegeven mag door meerdere applicaties worden geraadpleegd. Ook hiervoor zijn services gedefinieerd die de applicaties kunnen gebruiken. Onderbouwing

Op het moment dat duidelijk is waar gegevens worden bijgehouden is het ook eenvoudiger om de informatie af te leiden die nodig is voor het genereren van managementinformatie en voor de uitwisseling met andere applicaties en andere partijen.

Implicaties

Het op orde hebben van het applicatielandschap en het gegevensobjectmodel zijn randvoorwaarden. Daarmee kan de confrontatie worden gemaakt tussen leverende bronregistraties en afnemende applicaties. Van elk gegeven dient te worden bepaald door welke applicatie dit gegeven wordt geleverd. Vervolgens dienen de services te worden gedefinieerd.

Een voorbeeld van toepassing is dat informatie die in het omgevingsdossier opgeslagen gaat worden, niet ook nog lokaal opgeslagen wordt binnen de ODT. Dit vraagt om afstemming over het beheer van de gegevens in het omgevingsdossier.

Uitwerking

ODT ontsluit de basisregistraties via de primair proces applicatie PowerBrowser  met behulp van koppelingen met het centraal aansluitpunt. De data in PowerBrowser wordt geverifieerd aan de hand van exports naar I-GO, waar een terugkoppeling plaatsvindt over de kwaliteit van de data en authentieke data, conform het model . Op deze manier is er ook een controle op de ingevoerde data of deze authentiek is.

Uitwerking toegevoeg

13-04-2021

P4.1.15

Gegevens worden vastgelegd in de applicatie die primair wordt gebruikt om het proces uit te voeren. Als die gegevens ook in andere applicaties nodig zijn dan wordt hier middels services voor gezorgd. Onderbouwing

Hiermee wordt voorkomen dat gebruikers dezelfde gegevens in meerdere applicaties moeten invoeren. De services zorgen ervoor dat de gegevens ook in andere applicaties beschikbaar zijn.

Noot: het begrip service moet hierbij breed worden opgevat. Dit kan in extremo ook een handmatige service zijn. Als er maar duidelijke afspraken zijn over de service.

Implicaties

Dit heeft grote impact en moet gezien worden als een lange termijn doelstelling. Lang niet alle applicaties zijn nu met behulp van services te ontsluiten.

In de meest simpele vorm bestaat de service toch uit het opnieuw invoeren van het gegeven. Dit moet dan zo efficiënt mogelijk worden afgesproken.

Als dit tot teveel extra werklast leidt dan moet een service worden gedefinieerd om de gegevens vanuit de ene applicatie beschikbaar te stellen aan de andere applicatie. Dit kan een dubbele opslag betekenen als het niet anders kan (bijvoorbeeld vanwege performance of om technische redenen). In alle gevallen moet de dubbele opslag gecontroleerd verlopen om fouten zoveel mogelijk te voorkomen. Hiervoor zijn dan beheersmaatregelen nodig. De uit te wisselen gegevens moeten worden gestandaardiseerd. Tevens zijn op organisatorisch niveau afspraken nodig over de kwaliteit van de gegevens. Via de services vindt immers ‘onder water’ wel overdracht van de gegevens plaats naar een ander proces.

P4.1.16

TIJDgebonden gegevenskenmerken vastleggen in applicaties voor de besturing van de uitvoering. Het betreft vooral het zaaksysteem. Eventueel worden ook aanvullende gegevens vastgelegd in een projectadministratie. Onderbouwing

Intern binnen een omgevingsdienst zullen deze applicaties in de besturing gebruik maken van deze TIJDgebonden gegevenskenmerken. Die registratie dient dan ook te worden gebruikt voor het genereren van de betreffende KPI’s. 

Implicaties

Inventariseren op welke wijze de TIJDgebonden gegevenskenmerken in deze applicaties kunnen worden vastgelegd zodat het efficiënt aansluit op de manier van werken.

Noot: het is niet zo dat alle TIJDgebonden gegevenskenmerken vastliggen in alleen besturende applicaties als het zaaksysteem en projectadministratie. Tijdbesteding zal door de besturende applicatie gedelegeerd zijn naar een tijdschrijfsysteem. Dit betekent dan echter dat het tijdschrijfsysteem gekoppeld moet zijn aan de zaak, het project.

P4.1.17

VOLUMEgebonden gegevenskenmerken registreren in de applicaties voor de ondersteuning van de bedrijfsvoering. Het betreft vooral de tijdregistratie (personele middelen – realisatie), personeelsadministratie (personele middelen – formatie en bezetting) en financiële administratie ( financiële(financiële middelen – begroting en realisatie, personele middelen in loonsom omgerekend – begroting en realisatie). Onderbouwing

Om planning en realisatie te kunnen vergelijken is het nodig te beschikken over een compleet beeld. Niet alle activiteiten van de medewerkers zijn zaakgericht of projectgericht. Ook is het zo dat de planning van de benodigde menskracht voor de uitvoering van zaken, projecten en adviezen niet per geval worden geraamd maar op een hoger aggregatieniveau (thema en wettelijk kader). Zaaksystemen en projectadministraties zijn daar niet op ingericht. 

Implicaties

Zorgen dat de applicaties zaaksysteem, tijdregistratie en financiële administratie gebruik maken van dezelfde classificaties. 

Als het efficiënter wordt gevonden om de realisatie toch in het zaaksysteem en / of projectadministratie vast te leggen dan dienen de applicaties dit via services gestandaardiseerd uit te wisselen.

P4.1.18

Een classificerend gegevenskenmerk wordt beheerd vanuit 1 applicatie en wordt gebruikt vanuit de andere applicaties die dat nodig hebben. Onderbouwing

Hiermee wordt voorkomen dat er verschillende definities ontstaan, wat ten koste gaat van de uitwisselbaarheid.

Implicaties

Het beheer van classificaties toewijzen aan applicaties.

P4.1.19

Metadataset standaardiseren: METADATERENDE gegevenskenmerken voor allerlei informatieobjecttypen (documenten, e-mailberichten, beeldmateriaal, etc.) worden benoemd in een metadataset. Deze metadataset wordt zoveel als mogelijk vastgelegd in de applicatie voor zaakmanagement (zaakgericht werken) en de applicatie voor projectmanagement (projectmatig werken). De applicaties voor dossiermanagement en archiefmanagement maken hiervan gebruik door verwijzing of overerving. Onderbouwing

Een deel van de metadata ontstaat in het behandelen van de zaak of in het uitvoeren van een project. Uitvoering van een project leidt tot een zaak. Ook na het afsluiten van het dossier is er een informatieplicht en een bewaarplicht. Metadatering zorgt er voor dat uitleen, bewaring, overdracht en vernietiging van dossiers ordentelijk verloopt. De gegevens van een zaak moeten dus beschikbaar blijven in het dossier en het archief.

Implicaties

De metadataset standaardiseren. De applicaties voor zaakmanagement, projectmanagement, dossiermanagement en archiefmanagement standaardiseren op het gebruik van de metadataset. Nagaan op welke wijze de metadataset van de zaak en het project duurzaam beschikbaar blijft voor dossiermanagement en archiefmanagement.

Voorgesteld wordt TMLO als basis te hanteren voor documenten in het primair proces

Aangepast

14-04-2021

De sturingsinformatie wordt uitgewisseld in de vorm van rapporten, volgens geldende open documentstandaarden, zonder intensief berichtenverkeer. Onderbouwing

Doordat de omgevingsdienst de informatie verzamelt en de uitwisseling een lage frequentie heeft (per kwartaal, per jaar) is uitwisseling van rapporten het meest efficiënt.

Implicaties

De informatie-uitwisseling vindt niet op systeem-systeem niveau plaats. De uitwisseling vindt plaats via open standaarden.

Vervallen

Vervangen door P4.3.2a

Verantwoordings-, sturings- en management informatie wordt op een centrale plek ontsloten en gedefinieerd. Onderbouwing

Door op een plek verantwoordings-, sturings- en management rapportages te definiëren, realiseren en aan te bieden ontstaat een eenduidige definitie van de beschikbare informatie en een enkele waarheid. Voor goede sturing en verantwoording is het van belang om dezelfde rapportage te hebben. Het hebben van verschillende definities, lijsten of rapporten om te kijken naar eenzelfde onderwerp leidt tot onduidelijkheid.

Implicaties

Verantwoording, sturing en management rapportages dienen middels een centrale aanpak in de organisatie te worden ontsloten. Ook is hiervoor een voorziening nodig om de rapportages beschikbaar te stellen. Vanuit verschillende bronnen dient data aangeleverd te worden met een vooraf gedefinieerd doel. De data kan alleen aangeleverd worden als deze in de systemen en processen beschikbaar is. Bij de inrichting van systemen dient er daarom ook nagedacht te worden over de sturen, verantwoording en rapportage behoefte, zodat deze ingeregeld kan worden.

Rapportages en management informatie binnen systemen kunnen ook gebruikt worden voor de dagelijks gebruik. Deze worden echter niet gebruikt voor formele verantwoording en sturing. (Denk hierbij aan overzichten openstaande zaken in de VTH-Applicatie zelf, of overzichten als "Mijn Zaken")

Uitwerking

Omgevingsdienst Twente beschikt over een ontwikkel, acceptatie en productie omgeving waarin in een aantal stappen van ruwe data naar rapportage wordt toegewerkt. Ruwe data wordt in eerste instantie verzameld in een data-lake. Middels transformatie wordt een datawarehouse opgebouwd met verschillende rapportage modellen. Deze modellen bevatten de daadwerkelijke data. De modellen zijn beschikbaar voor de rapportages. De rapportages worden beschikbaar gesteld aan rollen in de organisatie. Zie het hoofdstuk Realisatie Oxygen voor details

De rapportages worden vooraf gedefinieerd in het rapportage productenboek .

R 4.3.1

-----

P 3.3.1

Als zaakinformatie digitaal wordt uitgewisseld dan wordt hiervoor de standaard StUF gebruikt. Voor nieuwe ontwikkeling vanaf 01-04-2021 geldt R4.3.1a

PETRA P4.2.16

College Standaar-disatie

Aangepast

14-04-2021

Bij de ontwikkeling van nieuwe diensten en uitwisselingen worden de API Standaarden zaakgericht werken toegepast. Onderbouwing

Per 01-04-2021 heeft VNG het gebruik van de API Standaarden zaakgericht werken aangeduid met de indicatie 'Pas toe of leg uit'. De standaarden ook wel aangeduid met de ZGW API's, zijn tot stand gekomen om de Common Ground gedachte te ondersteunen. Voor nieuwe ontwikkelingen wordt hiervoor zoveel mogelijke aangesloten.

Implicaties

Leveranciers zullen niet direct de bestaande STUF koppelingen kunnen en willen vervangen door de ZGW API's. Daar waar aangestuurd kan worden op deze ontwikkeling zal Omgevingsdienst Twente dit vragen en aanmoedigen. Voor bestaande implementaties is R4.3.1 gebruikt.

R 4.3.2

-----

U 9

Als documenten in reviseerbare vorm worden uitgewisseld dan wordt hiervoor de standaard ODF gebruikt. Uitwerking

In de praktijk wordt vaak in de Microsoft Word Docx formaat uitgewisseld. Des gevraagd kunnen documenten wel omgezet worden naar ODF. In de praktijk hebben burgers, bedrijven en andere overheden een voorkeur voor Word Docx. Dit wordt wel opgeslagen in een Open XML Standaard.

PETRA

P4.2.12

College Standaar-disatie

R 4.3.3

-----

U 9

PETRA

P4.2.12

College Standaar-disatie

Vervallen

Vervangen door 4.3.4a

R4.3.4a

---

U9

Voor de uitwisseling met de landelijke bouwstenen wordt aangesloten in de volgende volgorde van voorkeur:

1. op het centraal aansluitpunt (via de VTH-Leverancier),
2. of via de Regionale voorzieningen zoals van het IT Platform Twente of de I-GO Samenwerking
3. of via de Gemeentelijke Gemeenschappelijke Infrastructuur (GGI)

Onderbouwing

ODT heeft geen eigen infrastructuur, servers, maar een "SaaS-Strategie" waarbij de diensten afgenomen worden van (commerciële) leveranciers. Voor het afnemen en uitwisselen van informatie wordt eerst gekeken naar landelijke voorzieningen, daarna regionale voorzieningen en als laatste lokale voorzieningen bij deelnemers.

R 4.3.5

-----

U 9

Vervallen

Vervangen door 4.3.5a

R4.3.5a

---

U9

Voor de uitwisseling voor federatieve single sign-on wordt de OpenID Connect standaard gebruikt.

Uitwerking

De Azure Active Directory wordt gebruikt met OpenID Connect uitwisselingen naar applicaties voor Single Sign-On

R 4.3.6

-----

U 9

Voor de uitwisseling van gegevens over producten en diensten wordt de standaard Samenwerkende Catalogi gebruikt. Uitwerking

In de praktijk is hier nog niet zoveel mee gedaan.Mede omdat er nog geen enkele omgevingsdienst zijn diensten in de Samenwerkende Catalogi heeft gepubliceerd.

Ontwikkeling

Voor de producten en diensten in de omgevingswet worden de ontwikkelingen van de imPDC in het Digitaal Stelsel Omgevingswet gevolgd.

Flexibiliteit in informatie-uitwisseling : De omgevingsdienst ondersteunt meerdere vormen van informatie-uitwisseling. Onderbouwing

De omgevingsdienst kent meerdere opdrachtgevers en moet daarnaast ook nog kunnen uitwisselen met collega omgevingsdiensten in verband met concentratietaken. Deze partijen hebben een verschillende vorm en ontwikkelingsniveau van digitalisering. Hierbij geldt wel dat in het kiezen en uitwerken van oplossingen, het uniformiteitsprincipe bovenaan staat. Daar waar een oplossing geboden kan worden die voor alle partijen bruikbaar is, gaat dat boven de keuze die voor een partij geoptimaliseerd wordt.

Implicatie

Met de partijen afspraken maken over de veilige manier van informatie-uitwisseling. Onderkende vormen zijn:

• Post
• E-mail
• sFTP-server, of een uitwisselingsapplicatie dat door de partijen waarmee gegevens worden uitgewisseld is aangemerkt als voldoende betrouwbaar. Voldoende betrouwbaar wil zeggen: de beveiligingsrisico's bij een correct gebruik zijn aanvaardbaar voor de gegevens die worden uitgewisseld. Elektronisch berichtenverkeer (voor partijen met een hoge digitaliseringsgraad en een intensief berichtenverkeer)
• Digi-koppelingen en REST-API's
• Via aangewezen bestandsuitwisselings-platformen
• • In Projecten of grotere teams kunnen hiervoor de SharePoint Sites of Team Sites worden ingezet
  • Voor onderlinge uitwisseling tussen medewerkers van Omgevingsdienst Twente en de buitenwereld kan OneDrive ingezet worden.

Gebruik nummering : Bij de uitwisseling van informatie worden minimaal de identificerende nummers uitgewisseld. Dit is van belang voor:

• Zaak
• Project
• Dossier
• Subject-rol en Subject
• Object.
• Product
• Activiteit

Onderbouwing

Hierdoor is informatie eenvoudig te relateren en kan er een relatie worden gelegd met de gegevens in de bron.

Implicatie

Afspraken maken over identificerende nummers. Met name voor zaken en dossiers is dit belangrijk omdat die op verschillende plaatsen ontstaan (bij omgevingsdienst en bij opdrachtgever). Voor objecten en subjecten altijd de identificerende nummers van de landelijke basisregistraties uitwisselen. De uitwisselingen zijn beschreven in de datasets .

Volg de Common Ground principes, voor de realisatie van nieuwe toepassingen, componenten en gegevensuitwisselingen. Onderbouwing

De Common Ground principes zijn er op gericht om componenten te ontwikkelen die voor andere ook herbruikbaar zijn. In het uitdenken van oplossingen binnen de omgevingsdienst is het denken in herbruikbare componenten essentieel om schaalgrote te realiseren. Daar waar oplossingen die gemaakt worden gedeeld kunnen worden met andere omgevingsdiensten, deelnemers of ketenpartners ontstaat schaalvoordeel. Omgevingsdienst Twente is te klein om te ontwikkelen vanuit een gedachte waarbij oplossingen alleen passend hoeven te zijn voor de dienst zelf.

Implicatie

Bij de realisatie van oplossingen is het handig om vooraf partners te vinden die mee willen ontwikkelen in de voorliggende uitdaging. Waar dat niet mogelijk is, ontwikkel met het vinden van partners in het achterhoofd.

Data voor management rapportage wordt van de bron naar de centrale voorziening gebracht via CSV bestanden of RESTfull-API's Onderbouwing

Door te werken vanuit de rapportage producten en diensten catalogus wordt vooraf bepaald welke informatie noodzakelijk is om opgenomen te worden in het rapportage model en dus geëxtraheerd uit de bronnen. De uitwisseling van deze informatie vindt in een zo plat mogelijke definitie plaats, zodat bij vervanging van een component, bij gelijkblijvende exports van data, de rapportage functionaliteit blijft werken.

Waar CSV niet mogelijk is, of waar er reeds RESTfull-API's beschikbaar zijn (zoals de ZGW-API's) kunnen deze gebruikt worden voor de ontsluiting van data. De keuze tussen deze twee methoden, zal afhankelijk zijn van performance en belasting.

Daar waar full-exports van data mogelijk zijn, wordt dit geprefereerd vanuit de datalake gedachte. Daar waar performance een issue is, kan gewerkt worden met incrementele exports.(in CSV)

Uitwerking

Alle exports zijn gedefinieerd in de datasets en gekenmerkt als exports. Bestanden worden veilig tussen systemen getransporteerd (conform 4.3.3)