De discussie op deze pagina is gearchiveerd. Dit betekent dat de functionaliteit op deze pagina niet werkt. Voor de huidige discussiemogelijkheden, ga terug naar de vorige pagina.

Aan deze wiki wordt momenteel gewerkt. Het kan zijn dat tijdens deze werkzaamheden links niet werken of dat sommige views niet of onvolledig getoond worden.

Cocreatie GEMMA 2 Referentiecomponten/Archief 2016

Als u wil mee discussiëren, gebruik dan deze pagina. Kijk op de pagina uitleg forumfunctionaliteit, om te zien hoe de forumfunctionaliteit werkt. De discussie gaat over het onderwerp dat start bij de pagina: Inleiding informatie- en applicatie-architectuur, Informatie- en applicatie-architectuur

Nieuw onderwerp starten

Inhoud

OnderwerpAntwoordenLaatste wijziging
Digitale Handtekeningcomponent mist op de referentiecomponentenplat123 nov 2016 11:55
Beheren versus Registreren en delen123 nov 2016 11:54
Documentenregistratiecomponent; waar staan de files?223 nov 2016 11:53
Zaaktypenbeheer in het Zakenregistratiecomponent?223 nov 2016 11:52
naamgeving bedrijfsfuncties Ontwikkeling223 nov 2016 11:52
Generieke applicatiefunctie Klantcontacten123 nov 2016 11:51
Van aanvraag tot betaling/levering, meer aandacht voor "ondersteunende" processen als integraal onderdeel van het klantproces - inclusief berichten123 nov 2016 11:50
Ontsluiten geo-informatie domeinspecifiek of generiek?223 nov 2016 11:50
Geografisch-informatiecomponent (GIS) ?323 nov 2016 11:49
"Aanleveren van statistische informatie" en "Aanleveren van verantwoordingsinformatie" - bouwsteen SBR ? Waar "minder slim" aanleveren?123 nov 2016 11:49
Inconsequente indeling van componenten naar soort functionaliteit123 nov 2016 11:47
Aanvullen/ corrigeren van aanvragen binnen generieke functionaliteit voor burgers/bedrijven?223 nov 2016 11:45
Inconsequent gebruik van begrippen123 nov 2016 11:40
'Registreren en delen van kerngegevens' is inconsequent gedefinieerd123 nov 2016 11:39
Gegevensmagazijncomponent niet bedoeld voor 'opslaan basisgegevens' 123 nov 2016 11:38
Waar is giraal betalen?123 nov 2016 11:38
Onscherpe begrenzingen functionaliteit823 nov 2016 11:37
Onderscheid tussen functionaliteit voor burgers/bedrijven, gemeente en ketenpartners.523 nov 2016 11:34
Onlogische splitsing van referentiecomponenten Servicebuscomponent en Digikoppelingcomponent223 nov 2016 11:24
Naamgeving Zaakregistratiecomponent t.o.v. Gegevensmagazijncomponent223 nov 2016 11:24
Eerste pagina
Eerste pagina
Vorige pagina
Vorige pagina
Volgende pagina
Volgende pagina
Laatste pagina
Laatste pagina

Digitale Handtekeningcomponent mist op de referentiecomponentenplat

Als aftrap voor de cocreatie:

zie de deelplaat op http://gemmaonline.nl/index.php/Cocreatie:Gemma/doc/applicatiefunctie/beheren_van_documenten Hierop staan twee referentiecomponenten, maar op de hoofdplaat: http://gemmaonline.nl/index.php/Cocreatie:Gemma/doc/model/informatiearchitectuur_met_referentiecomponenten is de digitale handtekeningcomponent vergeten.

Jeffrey Gortmaker (KING) (overleg)20 apr 2016 23:34

Component is toegevoegd op de plaat. Tevens “Digtaal ondertekenen van documenten” gepromoveerd tot hoofdfunctie.

Tineke (overleg)23 nov 2016 11:55
 

De tekst onder dit kopje op deze pagina eindigt vrij abrupt met een halve zin. EHotting (overleg) 13 mei 2016 22:17 (CEST)

13 mei 2016 22:17

Zin aangepast. Na integratie cocreatie-deel wordt tekst vermoedelijk herschreven.

Tineke (overleg)23 nov 2016 11:54
 

Documentenregistratiecomponent; waar staan de files?

Een interessante discussie is of de files opgeslagen moeten worden in het documentenregistratiecomponent of slechts (een deel van) de metadata en een verwijzing naar de vindplaats van het document. Als alle systemen (frontoffice, generiek zaaksysteem, taakspecifieke systemen, collaboratie-omgevingen, etc.) hun digitale documenten moeten afdragen naar een centraal magazijn, dan ontstaan er zeer grote datastromen en heb je een enorme storage nodig op het systeem dat invulling geeft aan dit referentiecomponent.

Mklerks (overleg)19 mei 2016 13:52

Al bij GEMMA1 werd gesteld dat in de digitale wereld het begrip "dossier" meer de functie van een index dan van een bewaarplaats had. In de baseline GEMMA Baseline Informatiehuishouding Gemeenten werd echter geadviseerd om bij archivering elders opgeslagen documenten bij voorkeur lokaal op te slaan. Logisch, gelet op het vaak ontbreken van garanties dat elders opgeslagen documenten blijvend toegankelijk blijven. Voor de generieke 'documentenregistratiecomponent' geldt volgen mij min of meer hetzelfde. De informatiearchitectuur schrijft niet voor hoe de opslag fysiek plaats moet vinden. Gelet op het doel om documenten toegankelijk te houden zal in veel situaties lokale opslag nog de voorkeur (moeten) hebben. Maar bijv. in situaties waarbij via landelijke (bijv. basis)registraties geborgd wordt dat documenten blijvend toegankelijk zijn zou verwijzing ook een optie kunnen zijn. Opmerking: hoeveelheid storage mag geen argument zijn; in vergelijking met wereldspelers zijn we als hele Nederlandse overheid samen nog klein Opmerking: bij de Archiefregistratiecomponent wordt het helemaal noodzakelijk om duurzame opslag te borgen waarbij lokale opslag voor de hand ligt (en ik verwacht dat gemeenteoverschrijdende eDepot-achtige oplossingen de benodigde functionaliteit gaan leveren).

Ad Gerrits (Nijmegen) (overleg)19 mei 2016 17:06

Voorlopig bedoelen we hiermee de opslagfunctionaliteit van documenten zoals nu door een DMS wordt geboden (naast andere DMS-functies die we hier dus niet bedoelen). Dus ook de fysieke opslag. Dat is ons inziens niet zo heel anders als er nu gewerkt wordt, waarbij er ook documenten uit veel verschillende bronnen in een DMS worden opgeslagen.

Tineke (overleg)23 nov 2016 11:53
 
 

Zaaktypenbeheer in het Zakenregistratiecomponent?

Bij het referentiecomponent Zakenregistratiecomponent wordt o.a. de functionaliteit "◦Aanmaken, delen, verwijderen en wijzigen van zaaktypen " genoemd. Deze hoort echter m.i. alleen onder het referentiecomponent Zaaktypecataloguscomponent te staan.

http://gemmaonline.nl/index.php/Cocreatie:Gemma/doc/applicatiecomponent/zakenregistratiecomponent

Mklerks (overleg)19 mei 2016 13:33

Terechte opmerking. Wat mij betreft nog wenselijker: - benoem "Registreren en delen van zaaktypen" als applicatiefunctie binnen gedeelde 'Gedeelde generieke functionaliteit' (met 'zaaktyperegistratie component')(zaaktypen zijn niet alleen voor zaakregistratie van belang) - benoem 'Beheren zaaktypegegevens' als generieke gemeentelijke informatiefunctie (met 'Zaaktypebeheercomponent' wat m.i. beter is dan 'Zaaktypecataloguscomponent')

Ad Gerrits (Nijmegen) (overleg)19 mei 2016 17:23

Eens. Functionaliteit “registreren en delen” van zaaktypen enkel aan “zaaktypecataloguscomponent” gehangen en gepromoveerd tot hoofdfunctie.

Tineke (overleg)23 nov 2016 11:52
 
 

De naamgeving van de bedrijfsfuncties (http://gemmaonline.nl/index.php/GEMMA_Bedrijfsfuncties) in de categorie "ontwikkelen" vind ik niet zo gelukkig gekozen. Vaak gaat het over het ontwikkelen van beleid en niet over het ontwikkelen van wat er nu staat. Benoem wat je ontwikkelt, dus: "Ontwikkelen economisch beleid" in plaats van "Economische ontwikkeling" "Ontwikkelen beleid fysieke omgeving" in plaats van "leefomgeving ontwikkeling" "Ontwikkelen producten en diensten aanbod" in plaats van "Ontwikkeling dienstverlening" "Ontwikkelen beleid openbare orde en veiligheid " in plaats van "Openbare orde en veiligheid ontwikkeling" "Ontwikkelen sociaal beleid" in plaats van : sociale ontwikkeling"

Rindert Dijkstra (overleg)2 mei 2016 15:18

In de toelichting bij "Ontwikkeling" lees ik: "Ook het doorvoeren van de gewenste (organisatie)veranderingen maakt deze uit van deze functie." Het is dus meer dan alleen beleid. Overigens zou dat dan wel in de toelichting bij de afzonderlijke bedrijfsfuncties moeten worden toegevoegd omdat daar (muv Organisatieontwikkeling waar het andersom geldt) alleen over beleid wordt gesproken.

Ad Gerrits (Nijmegen) (overleg)19 mei 2016 17:29

Klopt. De naamgevingsconventie voor bedrijfsfuncties stelt dat dit een znw moet zijn, dus meestal eindigend op –ing. En het behelst meer dan enkel het opstellen van beleid, ook het implementeren daarvan maakt hier deel van uit.

Tineke (overleg)23 nov 2016 11:52
 
 

Generieke applicatiefunctie Klantcontacten

Klantcontacten worden in zowel gemeente- als domeinspecifieke applicaties vastgelegd. Gelet op het belang daarvan lijkt het me wenselijk om, naar analogie van bijv. zaken en documenten, daarvoor een generieke applicatiefunctie te benoemen. Die dan bijv. 'Registreren en delen van contactmomenten' kan heten (waarbij de nadruk wat mij betreft ligt op 'delen van' en minder op registreren). Het feit dat ze ook in RGBZ 2.0 een plek hebben gekregen geeft wel hoe belangrijk ze zijn (en niet alleen voor zaken overigens).
ps: Op GEMMA-online lees ik: "Vaststelling van het RGBZ 2.0, dat daarmee de status 'in gebruik' verkrijgt, vindt plaats in 2015" maar is dat wel gebeurd?

Ad Gerrits (Nijmegen) (overleg)19 mei 2016 17:52

De functie “beheren van klantcontacten” met bijbehorend relatiebeheercomponent (CRM) is opgenomen als generieke functionaliteit voor gemeenten. Niet als generieke gedeelde functionaliteit dus. Na rijp beraad hebben we gemeend geen functie/component in de generieke gedeelde functionaliteit op te nemen om de klantcontactmomenten uit de diverse systemen te integreren. Dan zouden we van al deze systemen een koppelvlak moeten eisen om klantcontactgegevens uit te wisselen. En het is maar de vraag in hoeverre een gemeentebreed beeld van alle klantcontacten wenselijk en nuttig is.

Tineke (overleg)23 nov 2016 11:51
 

Van aanvraag tot betaling/levering, meer aandacht voor "ondersteunende" processen als integraal onderdeel van het klantproces - inclusief berichten

Hoewel ik de scheiding tussen primaire en ondersteunende processen begrijp, kan de strikte scheiding ook leiden tot ICT-verkokering (naast een organisatorische/ procesmatige verkokering). Concreet zie ik dat terug in een zaaksysteem, de scope is vaak van "aanvraag" tot "beschikking", de klantbehoefte is echter een levering (parkeervergunning) of een betaling (uitkering of subsidie). Hierdoor ontstaan (onnodige) klantcontacten over de levering (wanneer klaar) of de betaling (op welke datum krijg ik ...), de functies van het bedrijfsvoeringsdomein (betalen/innen/ etc.) kunnen qua berichtenverkeer aanzienlijk worden gestandaardiseerd waardoor administratieve handelingen bij gemeenten worden beperkt (i.p.v. "kloppelingen") en zodat de burger via PIP/mijnoverheid of welke attenderingservice dan ook pro-actief geïnformeerd kan worden over de levering/betaling.

Vincent.pauw (overleg)25 mei 2016 13:52

Eens. Maar dit gaat over het inrichten van processen/zaaktypen en heeft geen impact op de informatiearchitectuur.

  • !Generieke applicatiefunctie
Tineke (overleg)23 nov 2016 11:50
 

Ontsluiten geo-informatie domeinspecifiek of generiek?

In de domeinarchitectuur voor ruimtelijk domein is onder GIS-component de functie 'ontsluiten basis en kerngegevens' opgenomen. Dat lijkt een generiek beschikbaar te stellen functie te zijn, onderdeel van de generieke lagen. Bijvoorbeeld nodig om een kaart(laag) in een zaakafhandelingssysteem te faciliteren.

Relschot (overleg)25 mei 2016 13:47

Eens, dit is een generieke functie, deel uit makend van registeren en delen van basisgegevens (gegevensmagazijncomponent), kerngegevens en gegevenssets. Het maakt niet uit om welk type gegevens het gaat, cijfers, letters, bedragen, plaatjes, geometrie, etc., het moet geregistreerd en gedeeld worden en daar is een component voor. Geen aparte componenten per type gegeven.

ArjanKloosterboer (overleg)29 mei 2016 22:58
 

In het ruimtelijk domein komt de Geografisch-informatiecomponent (GIS) voor. Ik vraag me af, is dit wel een component die we in de informatie-architectuur willen onderscheiden en zo ja, waarom specifiek voor het ruimtelijk domein?
M.i. moeten we deze component niet willen onderscheiden. Een GIS is een toolbox waarmee je van alles kunt. Pas door het toe te passen krijgt het betekenis voor een bedrijfsfunctie of bedrijfsproces. Daarop richten we de infoarchitectuur, toch? Een GIS zit m.i. in dezelfde hoek als een rapportgenerator, een tekstverwerker, een BI-tool e.d. Nuttig en noodzakelijk maar op een ander niveau in de architectuur. Bovendien, geografische functionaliteit zou van elke referentiecomponent (in elk domein) deel uit kunnen maken en niet specifiek gebundeld moeten zijn in één component. Lees Geo in GEMMA.
De tweede vraag is hiermee beantwoord.

ArjanKloosterboer (overleg)29 mei 2016 23:09

Om vergelijkbare redenen vraag ik me af of de component Computer-Aided Design (CAD) hier wel thuis hoort. Ik denk ook hierbij van niet. Benoem het toepassingsgebied waarvoor het in het ruimtelijk domein benut wordt en maak daar een component van. Bijvoorbeeld iets als Civieltechnisch tekenen.

ArjanKloosterboer (overleg)29 mei 2016 23:13

En dan hebben we nog de generieke GIS-viewercomponent. Ook maar weg, om vergelijkbare redenen? De gegevensmagazijncomponent verzorgt oa. het delen van gegevens. Maakt het dan uit of dat cijfers, letters, bedragen, coördinaten, plaatjes of ... zijn? Waarom nou weer voor dat ene type gegeven een aparte component? Verplaats ook de GIS-viewer naar het niveau 'tools' en zet het in waar nodig en/of nuttig.

ArjanKloosterboer (overleg)29 mei 2016 23:17

GIS viewercomponent is verwijderd. Naamgeving + definitie CAD component nemen we mee in de uitwerking van de domeinarchitectuur ruimte. De Geografisch-informatiecomponent (GIS) vervult in de architectuur de functie ‘beheren van ruimtelijke objecten”…verdere verdieping van wat daaronder valt volgt uit de domeinarchitectuur ruimte. Een niveau ‘tools’ bestaat niet in de GEMMA architectuur. Weglaten heeft als nadeel dat een component direct ook uit de softwarecatalogus is. Als we ook de “technische laag” in Archimate-termen zouden uitwerken, kunnen bepaalde componenten misschien verplaatst worden naar “system software” en op die manier wat scherper worden, maar nu kan dat nog niet.

Tineke (overleg)23 nov 2016 11:49
 
 
 

"Aanleveren van statistische informatie" en "Aanleveren van verantwoordingsinformatie" - bouwsteen SBR ? Waar "minder slim" aanleveren?

Hoewel ik natuurlijk WAT en HOE moet scheiden, wil ik een korte discussie starten vanuit de HOE.

Bij deze functies van aanleveren informatie ga ik uit van "slimme" aanlevering van informatie, anders is het een document.

De huidige beschrijvingen geven aan dat de gemeente "functionaliteit" beschikbaar gaat stellen om informatie aan te leveren. Het zou een logische stap zijn om aan te sluiten op SBR (als bouwsteen van e-overheid). Waardoor aanleverende partijen eenmalig hun bedrijfsadministratie (her)inrichten en meervoudig kunnen aanleveren aan de overheid. Het maken van aparte portalfunctionaliteit is mi. niet gewenst, vraagt immers om extra handelingen tov standaard/ geautomatiseerde verwerking (XBRL uitwisseling). De software ontwikkelaars in deze domeinen houden al rekening met SBR, er wordt al gewerkt aan de taxonomie, verbreding en verdieping staat in de roadmap. Een onderscheid tussen "statistisch" en "verantwoording" lijkt ook overbodig.

Echter, het voorbeeld (aanleveren verantwoordingsinformatie) gaat uit van "de besteding van ter beschikking gesteld budget". Ik denk dan vooral aan subsidies (valt daarmee in groep burgers en bedrijven en niet direct ketenpartners), waarbij ik niet verwacht dat instellingen/ verenigingen op een slimme manier (SBR) vanuit de administraties de informatie kunnen aanleveren (de uitvraag is bovendien erg specifiek per gemeente !).

Waar minder slim aanleveren? Er is dan toch ergens functionaliteit nodig om deze informatie aan de gemeente te leveren? Dusdanig dat de aanvrager de informatie kan koppelen aan de bestaande aanvraag (zie mijn andere post: http://www.gemmaonline.nl/index.php/Cocreatie_GEMMA_2_Referentiecomponten#Aanvullen.2F_corrigeren_van_aanvragen_binnen_generieke_functionaliteit_voor_burgers.2Fbedrijven.3F_420 ) of dusdanig dat de aanvrager een (vooringevuld) webformulier krijgt. De gemeente Houten doet dit al op papier op basis van historische gegevens (subsidie zonder moeite - VNG).

Vincent.pauw (overleg)30 mei 2016 09:46

Goede punten rondom SBR. Ook rondom het indienen van efacturen spelen dezelfde vragen. We doelen inderdaad op functionaliteit die de gemeenten aanbiedt voor gebruik door ketenpartners. Deze “beveiligd ketenpartner portaalcomponent” is inderdaad met name bedoeld voor gebruik door de “kleinere” ketenpartners, verenigingen, zorgverleners, … Degenen die zelf geen SBR ed. spreken, maar die de gemeente toch wil faciliteren met een portaal (al was het maar om de eigen poststroom in te perken).

Tineke (overleg)23 nov 2016 11:49
 

Inconsequente indeling van componenten naar soort functionaliteit

De archiefportaalcomponent waarmee een digitale collectie wordt ontsloten staat bij 'Generieke functionaliteit voor burgers/bedrijven'. De opendataportaalcomponent waarmee open data beschikbaar wordt gesteld staat bij 'Gedeelde generieke functionaliteit'.

Kbrouwer (overleg)8 jun 2016 16:30

Dat is bewust. Onderliggende aanname is dat een digitale archiefcollectie geraadpleegd wordt door personen. Daardoor dus in “functionaliteit voor burgers”. De datasets die middels een opendata portaal ontsloten worden zijn bedoeld voor gebruik in applicaties of apps van derden, dus is dat “gedeelde generieke functionaliteit”. Strikt genomen zou je kunnen spreken van een “open data portaal” (f voor burgers) en een “open data server” (gedeelde generieke f). Maar we hebben gekozen dit vooralsnog niet te doen. De portaalkant kan immers bestaan uit een simpele webpagina met URL’s naar de betreffende datasets.

Tineke (overleg)23 nov 2016 11:47
 

Aanvullen/ corrigeren van aanvragen binnen generieke functionaliteit voor burgers/bedrijven?

Aannames: De functie "aanvragen van producten en diensten" lijkt alleen uit te gaan van een initiële aanvraag van een burger of bedrijf De functie "tonen en bijwerken lopende zaken en mijn gegevens" lijkt alleen uit te gaan van het wijzigen van vastgestelde gegevens

Bij het beoordelen van aanvragen op ontvankelijkheid kan blijken dat gegevens of documenten ontbreken, er moet een mogelijkheid zijn om dit digitaal (gestructureerd) aan te leveren aan de gemeente en te relateren aan de lopende aanvraag. Andere oplossingen zijn suboptimaal (werken met codes, mailen van stukken, etc.). Het ontbreken van deze functie zorgt voor (onnodige) administratieve werkzaamheden bij de gemeente en suboptimale digitale dienstverlening richting de klant.

Ik verwacht dat, met oa de komst van de omgevingswet, er ook aan de kant van burgers en bedrijven er de behoefte bestaat voor een functie van "ondersteunen digitaal samenwerken". Zodat de klant, ook zonder een formele aanvraag, kan interacteren met de gemeente. Dit verwacht ik als aparte functie of als onderdeel van "ondersteunen van burgerparticipatie", dit lijkt echter alleen de scope van nieuw beleid/ peilen van meningen te hebben.

Vincent.pauw (overleg)24 mei 2016 10:16

Eens. "Ondersteunen digitaal samenwerken" hoort ook bij functionaliteit voor burgers/bedrijven te staan. Waarmee meteen de vraag kan worden gesteld of het dan ook niet terug moet komen als onderdeel van "gedeelde generieke functionaliteit".

Ad Gerrits (Nijmegen) (overleg)30 mei 2016 14:27

Eens m.b.t het aanvullen van aanvragen. Dat nemen we mee in de uitwerking van de domeinarchitectuur dienstverlening. We zijn niet akkoord met het toevoegen van “ondersteunen digitaal samenwerken” bij burgers en bedrijven. Specifieke vormen van samenwerken met burgers zijn o.a. het cocreëren van beleid. Daarvoor is aparte (specifieke) functionaliteit benoemd. Wil je om andere (niet benoemde) redenen samenwerken met burgers/bedrijven, dan is de kans groot dat ze niet in de rol van burger/bedrijf (“klant”) betrokken worden, maar als ketenpartner.

Tineke (overleg)23 nov 2016 11:45
 
 

In de referentiecomponenten worden begrippen soms inconsequent en door elkaar gebruikt:

- de component 'distribueren en synchroniseren van gegevens' levert functionaliteit voor het leveren van gegevens en signalen
- de component 'inwinnen en routeren van notificaties' levert functionaliteit voor het ontvangen en routeren van signalen
- de component 'routeren en transformeren van berichten' levert functionaliteit voor het transformeren en routeren van gegevens
Kbrouwer (overleg)8 jun 2016 16:08

Klopt. Signalen zoveel als mogelijk aangepast naar notificaties. “gegevens en signalen” onder “distribueren en synchroniseren..” aangepast naar “gegevens” In de omschrijving bij routeren en transformeren van berichten: “gegevens” veranderd in “berichten”

Tineke (overleg)23 nov 2016 11:40
 

'Registreren en delen van kerngegevens' is inconsequent gedefinieerd

In de beschrijving van de component 'Registreren en delen van kerngegevens' staat dat deze functionaliteit biedt voor het registreren en delen van contactmomenten en afspraken. Bij de subfuncties staat dat functionaliteit wordt geboden voor het aanmaken, etc. van medewerkergegevens en gegevens van bedrijven en instellingen.

Kbrouwer (overleg)8 jun 2016 16:17

Dat was een knip-en-plak foutje. Is inmiddels hersteld. Zie andere opmerking in deze lijst.

Tineke (overleg)23 nov 2016 11:39
 

Gegevensmagazijncomponent niet bedoeld voor 'opslaan basisgegevens'

(Wat is overigens de reden van 'registreren basisgegevens' op geaggregeerd niveau en 'opslaan gegevens' daaronder?)

Basisgegevens zitten in basisregistraties, in de groep Landelijke voorzieningen. Opslaan suggereert dat vanuit de gemeentelijke informatiesystemen basisgegevens worden opgeslagen in het gegevensmagazijn, dat lijkt me niet correct. Andersom is alleen sprake van een bufferfunctie - welke in de doelarchitectuur overigens geen plek zou moeten hebben.

EHotting (overleg)8 jun 2016 16:35

Terminologie op elkaar afgestemd. In het katern verbinden staat uitgewerkt dat een gegevensmagazijn enkel een kopie van de basisgegevens bevat en worden de nadelen daarvan benoemd. Omdat het gegevensmagazijn als ODS de komende tijd nog nodig zal blijven, hebben we ervoor gekozen het toch in de referentiearchitectuur op te nemen.

Tineke (overleg)23 nov 2016 11:38
 

Bij afrekenen van producten en diensten staan een online-betalingcomponent en een kascomponent voor de offline-betalingen. Ik mis daar functionaliteit voor de afhandeling van girale betalingen. En waar zit de functionaliteit voor de financiële afwikkeling, het financieel systeem?

Kbrouwer (overleg)8 jun 2016 16:38

De functie ‘Afrekenen van producten en diensten’ valt binnen generieke functionaliteit voor burgers en bedrijven. Dwz. Functionaliteit die de gemeente beschikbaar stelt om door burgers en bedrijven gebruikt te worden. Voor giraal betalen biedt de gemeente geen functionaliteit aan. Voor e-factureren dan weer wel, maar dan andersom. Die functie is opgenomen bij functionaliteit voor ‘ketenpartners’: “indienen van facturen en/of declaraties”. Deze functie staat bij ketenpartner, omdat deze functionaliteit (indienen van facturen) met name door bedrijven gebruikt zal worden in de rol van ketenpartner ipv. klant/afnemer van diensten.

Tineke (overleg)23 nov 2016 11:38
 

De indeling van subfuncties bij applicatiefuncties en functionaliteiten bij referentiecomponenten is niet altijd correct, sommige functies horen bij andere referentiecomponenten, etc. Zie hieronder voor voorbeelden.

Kbrouwer (overleg)8 jun 2016 15:57

Bijvoorbeeld: http://www.gemmaonline.nl/index.php/Cocreatie:Gemma/doc/applicatiecomponent/zakenregistratiecomponent

- aanmaken, etc van zaaktypen hoort bij de zaaktypecataloguscomponent
- aanmaken, etc van zaakdocumenten hoort bij de documentenregistratiecomponent
Kbrouwer (overleg)8 jun 2016 16:03

Zaakdocumenten hebben we laten vervallen. Documenten zijn documenten. Dat hoort inderdaad bij het documentenregistratiecomponent.

Tineke (overleg)23 nov 2016 11:36

Aanmaken etc van zaaktypen hebben we gepromoveerd naar hoofdfunctie met bijbehorend zaaktypecataloguscomponent (zie ene andere opmerking in deze cocreatie)..

Tineke (overleg)23 nov 2016 11:36
 
 

Incompleet:

Registreren en delen van kerngegevens wordt alleen aangeboden door Medewerkerregistratiecomponent. In de view Registreren en delen van kerngegevens is ook sprake van een Bedrijven en Instellingenregistratiecomponent.

Over de inhoudelijke juistheid denk ik overigens nog na, 'kerngegevens' suggereert een kernregistratie. HRM en CRM gegevens vallen niet onder definitie van kernregistratie, of zijn in ieder geval geen limitatieve opsomming van kernregistraties.

EHotting (overleg)8 jun 2016 16:19

Klopt. Bedrijven- en instellingenregistratiecomponent miste ten onrechte op de plaat. Is toegevoegd. Zie de andere opmerking over kernregistraties. De twee componenten hier zijn niet uitputtend. Deze kunnen worden aangevuld, maar de cocreatie-oogst was beperkt.

Tineke (overleg)23 nov 2016 11:37
 

Door het ontwikkelpad dat deze architectuur al doorlopen heeft, de betrokkenheid van verschillende mensen en wat technische redenen rondom export en toolmigratie kan het voorkomen dat in de cocreatie-versie ergens een relatie miste, of een functie verkeerd hing.

Onderstaande punten pakken we op. Als alles is verwerkt lopen we alles nog een keer na en is de architectuur in principe consistent. Al kunnen we nooit voorkomen dat we eens iets over het hoofd zien. Geef ons ene seintje via de ‘Denk mee!’ pagina en we zullen het herstellen.

Tineke (overleg)23 nov 2016 11:35
 

Onderscheid tussen functionaliteit voor burgers/bedrijven, gemeente en ketenpartners.

De informatiearchitectuur maakt expliciet onderscheid tussen “functionaliteit voor burgers/bedrijven”, “functionaliteit voor gemeente” en “functionaliteit voor ketenpartners”. Dit onderscheid zou niet tot uiting moeten komen in de functionaliteit, maar in de rollen en de bevoegdheden waarin deze functionaliteit wordt gebruikt. Binnen sociale wijkteams bestaat er nauwelijks nog onderscheid tussen de functionaliteit die wordt gebruikt door gemeentelijke medewerkers en medewerkers van de ketenpartners binnen het wijkteam. Ook het onderscheid tussen functionaliteit voor gemeenten en burgers/bedrijven vervaagt steeds meer. Grote voordelen in effectiviteit en efficiency kunnen worden behaald door alle betrokkenen gebruik te laten maken van dezelfde applicatiefuncties waarbij door (authenticatie en) autorisatie wordt bepaald welke functionaliteit aan een gebruiker wordt beschikbaar gesteld.

John Rooijakkers (overleg)9 jun 2016 07:44

Ik ben het er mee eens dat functies bij verschillende groepen terug kunnen komen. Neem bijvoorbeeld het volgen van de voortgang van zaken. Voor zowel de medewerker, de klant als voor een ketenpartner is dit relevant. De vraag is echter hoe je dit op een goede manier in de referentie architectuur beschrijft. In hoeverre is het hierbij mogelijk het als onderdeel van dezelfde functie te zien? Welke eisen stelt dit aan de component die de toegang tot informatie en informatiefuncties bepaald?

Patrick Castenmiller (overleg)20 jun 2016 15:43

"Ketenpartner" is als aanduiding van een groep personen en/of organisaties niet specifiek genoeg. Er zijn allerlei soorten ketenpartners. Wanneer een organisatie namens de gemeente de wettelijke taak van de gemeente uitvoert zou de daarvoor benodigde architectuur volledig binnen GEMMA moeten vallen. Wanneer de gemeente ketenpartner is in een keten die onder regie van een andere organisatie valt is daar ook functionaliteit voor nodig die een plekje in GEMMA verdient. Wanneer een ketenproces onder regie van de gemeente wordt uitgevoerd met behulp van ketenpartners die een zelfstandige publieke taak hebben (bijv: de provincie of brandweer bij omgevingsvergunningen) moet de daarvoor benodigde architectuur juist niet in GEMMA worden opgenomen. Nu staat het door elkaar.

Alle functies rond deze drie typen ketenpartners mogen in GEMMA volgens mij onder dezelfde noemer als 'functionaliteit voor gemeente', het onderscheid voegt niets toe.

Ik denk dat het wel goed is onderscheid te maken in functionaliteit voor de ambtenaar/ketenpartner (dienstverlener) enerzijds en burger/bedrijf (klant) anderzijds. De functionaliteit kan met dezelfde referentiecomponent worden ingevuld op basis van rollen, maar dat hoeft niet voorgeschreven te worden vanuit architectuur.

Mijn verwachting is dat, met scheiding van data en software, de software zich juist meer gaat toespitsen op het zo goed mogelijk ondersteunen van iedere rol, kleine taakspecifieke stukjes software die gebruik maken van een meer generieke laag bestaande uit BPMS en BRE. Softwarecomponenten zoals we die nu kennen gaan in rap tempo verdwijnen, een trend die sinds 2011 duidelijk zichtbaar is bij enterpises buiten de overheid.

EHotting (overleg)20 jun 2016 19:45

De functionaliteit voor ketenpartners is de functionaliteit die een gemeente beschikbaar stelt aan ketenpartners (om zaken met de gemeente af te kunnen handelen). Ketenpartners zijn bedrijven of instellingen waarmee een gemeente samenwerkt. Functionaliteit voor organisaties waaraan delen van wettelijke taken zijn uitbesteed vallen hier inderdaad niet onder.

Tineke (overleg)23 nov 2016 11:34
 

Het zijn –zeker in de referentiearchitectuur- zeker andere functies. Burgers/bedrijven en gemeenten mogen mbt. zaken andere zaken zien. Er gelden andere privacy- en beveiligingseisen en er worden vaak ook andere eisen gesteld aan de user-interface, manier van inloggen etc. We hebben er dus ook voor gekozen om dit in de referentiearchitectuur als aparte functies te modelleren.

Tineke (overleg)23 nov 2016 11:33
 

Tsja, dit is een onderwerp dat ook vorig jaar in de cocreatie al is langsgekomen. Over iedere indeling in de plaat valt wel iets te zeggen. En een lege plaat met alle functies door elkaar is niet erg overzichtelijk. Desalniettemin blijkt de huidige indeling erg herkenbaar. De rollen burgers/bedrijven (“klanten”), gemeente en ketenpartners zijn goed van elkaar te onderscheiden. De blauwe kolom bevat functionaliteit ten dienste van burgers/bedrijven die diensten van de gemeente afnemen (“klanten”). De groene kolom bevat functionaliteit voor de gemeente. Werkt een gemeente in een wijkteam erg intensief samen met partners in de stad, dan valt dat hier ook gewoon onder uiteraard. De functionaliteit voor ketenpartners is bedoeld voor ketenpartners waarmee een lossere relatie bestaat; ie. niet rechtstreeks op de systemen van de gemeente mogen werken. Het staat leveranciers overigens vrij om pakketten te leveren die op basis van rol alle drie de groepen functionaliteit leveren en daardoor dus .

Tineke (overleg)23 nov 2016 11:32
 

Onlogische splitsing van referentiecomponenten Servicebuscomponent en Digikoppelingcomponent

De splitsing van de referentiecomponenten ‘Servicebuscomponent’ en ‘Digikoppelingcomponent’ is niet logisch. Digikoppeling is een protocol, en zoals andere protocollen worden deze geïmplementeerd in een servicebus adapter. Digikoppeling heeft hierin geen andere positie dan andere protocollen die binnen gemeenten gebruikt worden zoals bijvoorbeeld FTP. Voorstel is om de assignment relatie met de functie 'Routeren en transformeren van berichten' (dit is namelijk geen taak van de DKA) te verwijderen en de Digikoppelingcomponent onderdeel te maken van de Servicebuscomponent.

Rolf.vandeursen (overleg)16 jun 2016 17:53

Eens, Digikoppeling behoeft geen eigen plek op de plaat.

EHotting (overleg)20 jun 2016 19:54
 

Eens. Een snelle blik in de SWC leert ons ook dat dit meestal wordt aangekruisd om te tonen dat een pakket dit protocol ondersteunt. Kan dus vervallen.

Tineke (overleg)23 nov 2016 11:24
 

Naamgeving Zaakregistratiecomponent t.o.v. Gegevensmagazijncomponent

Waarom is voor zaakgegevens gekozen voor de naam ‘Zaakregistratiecomponent’ en voor niet-zaakgegevens ‘Gegevensmagazijncomponent’? Het zijn toch beide magazijnen?

Rolf.vandeursen (overleg)16 jun 2016 17:55

Zaakregistratiecomponent vormt de authentieke bron voor zaakinformatie. Het wordt er in geregistreerd. Bij een gegevensmagazijn is dat als het goed is niet het geval, dat is slechts een buffer tussen een authentieke bron van de data en de functionaliteit.

EHotting (overleg)20 jun 2016 19:57

Eens met het antwoord van Eelco. Tov. een zakenmagazijn wordt de zakenregistratiecomponent anders gepositioneerd. Hierover verschijnt binnenkort een stuk op GEMMA Online.

Tineke (overleg)23 nov 2016 11:24
 
 
Eerste pagina
Eerste pagina
Vorige pagina
Vorige pagina
Volgende pagina
Volgende pagina
Laatste pagina
Laatste pagina