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
Eerste pagina
Eerste pagina
Vorige pagina
Vorige pagina
Volgende pagina
Volgende pagina
Laatste pagina
Laatste pagina

In de nieuwe GEMMA is functionaliteit geïntroduceerd voor het werken met taken: een takenbeheercomponent en een Takenregistratiecomponent. Ik vraag me af wat het werken met taken toevoegt t.o.v. het zaakgericht werken. Het bijhouden / tonen / etc. van werkvoorraad is een functie die thuishoort in de zakenafhandelcomponenten. Als losse component voegt het alleen extra complexiteit toe die niet nodig is.

Kbrouwer (overleg)22 jun 2016 10:55

De generieke functies “registreren en delen van taken” en “beheren van werkvoorraad” zijn in 2015 in GEMMA 2 geïntroduceerd om taken uit verschillende applicaties te kunnen samenvoegen en middels één taakbakje te kunnen ontsluiten naar de medewerkers. Na rijp beraad hebben we besloten deze functies (en bijbehorende componenten) inderdaad te laten vervallen. Het idee van één integrale werkvoorraad per medewerker laten we hiermee los. Werkvoorraad is dan te vinden in het zakenafhandelcomponent. Maar ook in een vergunningencomponent, subsidiecomponent etc. omdat het aantal procesondersteunende systemen waarmee een gemiddelde medewerker zal werken in de meest e gevallen beperkt zal blijven, wegen de kosten en inspanning van het ontsluiten van taken uit de diverse applicaties naar één centraal taakbakje inderdaad niet op tegen de voordelen en hebben we dus besloten deze functies en componenten te laten vervallen.

Tineke (overleg)23 nov 2016 11:22
 

Versturen van berichten door afsprakenbeheercomponent

De Afsprakenbeheercomponent heeft een applicatiefunctie voor het versturen van berichten. Het is volgens mij geen goed idee om dit soort applicatiefuncties per component in te richten, het is immers geen triviale functionaliteit, er moet rekening worden gehouden met het voorkeurskanaal van de klant, de goede sjablonen / vormgeving moet worden gebruikt, etc. Het versturen van berichten moet daarom worden gedaan door een component 'Outputmanagement', zie ook de reactie van Eelco Hotting hieronder. Deze component komt al voor in een eerdere versie van de GEMMA en bestond daarin alleen uit de applicatiefunctie 'aanmaken en afdrukken van documenten'. In de nieuwe component Outputmanagement horen daarnaast ook functies als: bevragen Berichtenbox, verzenden via Berichtenbox, verzenden via E-mail, etc. De afsprakenbeheercomponent (en andere componenten) moeten dan naast 'beheren van afspraken' alleen nog een functie 'genereren van berichten m.b.t. afspraken' hebben die gebruik maakt van Outputmanagement om het bericht te versturen.

Kbrouwer (overleg)22 jun 2016 10:58

De archiefregistratiecomponent wordt gedefinieerd als een digitale bewaarplaats voor blijvend te bewaren informatieobjecten. Er is echter ook een categorie informatieobjecten die niet blijvend maar wel gedurende zeer lange tijd bewaard moeten worden. Denk aan naturalisatiebesluiten (110 jaar voor BCG-vaccinatiegegevens, 40 jaar voor de gegevens van personeel dat in aanraking is geweest met gevaarlijke stoffen, etc. ). In die langdurige periode spelen dezelfde problemen m.b.t. digitale duurzaamheid als bij blijvend te bewaren informatieobjecten. De archiefregistratiecomponent zou daarom gedefinieerd moeten worden als 'digitale bewaarplaats voor langdurig te bewaren informatieobjecten'.

Kbrouwer (overleg)22 jun 2016 10:59

OK. Goed punt. Beschrijving en toelichting hierop aangepast.

Tineke (overleg)23 nov 2016 11:21
 

Pleidooi voor Outputmanagementcomponent (incl. Specificatie Documentcreatie versie 2.0)

In GEMMA bestond de referentiecomponent ‘Output-management’. Omschrijving: “Systeem voor ondersteuning bij aanmaken en afdrukken van documenten”.

In GEMMA 2 is deze component verdwenen. Het aanmaken van documenten vinden we terug in de “documentcreatiecomponent”.

Naar mijn mening is een Outputmanagementcomponent nodig:

  • Met de komst van multi-channel input neemt ook de noodzaak voor multi-channel output toe. Er is momenteel geen referentiecomponent voorzien die hierover de regie heeft. Denk aan documenten die naar printer of juist berichtenbox moeten, documenten die meerdere eindbestemmingen hebben etc. Momenteel is het alleen de DCV die een sturende rol heeft, op de referentiecomponentenplaat terug te vinden als 'zakenafhandelcomponent' etc. Alleen meer geavanceerde software kan dit waarmaken. De hiervoor benodigde functionaliteit kan beter worden gecentraliseerd in een generieke ‘Outputmanagementcomponent’. (Wellicht onder ‘gedeelde generieke functionaliteit / functie ‘Routeren en transformeren van berichten’).
  • De specificatie Documentservices biedt weinig houvast, het lijkt niet onder architectuur ontwikkeld. Zo'n beetje alle denkbare oplossingen zijn toegelaten binnen de GEMMA, afgaande op het huidige document met 5 extensies en 4 optionele functionaliteiten. Het zou goed zijn om onder GEMMA 2 te zorgen voor een versie 2 van de specificatie, waarin o.a. het volgende wordt geregeld:
    • Schrappen van extensie #4 en #5
    • Schrappen van optionele functionaliteit #2 en #4. Specifiek het schrappen #2 is noodzakelijk om een coherent geheel met de rest van GEMMA 2 te vormen.
    • Verplaatsen van de overgebleven extensies en optionele functionaliteit naar de standaard, dit zijn de functies die de referentiecomponent minimaal dient in te vullen.
    • Schets van de context binnen de architectuur
    • Introductie van Outputmanagement, waar bestemming(en) en drager(s) van documenten wordt bepaald vóórdat de DCA wordt aangeroepen. Outputmanagement bepaalt op basis van businessrules en input uit verschillende bronnen (o.a. ZRC en Berichtenbox) in welke vorm de DCA bepaalde content moet gieten, en waar het resultaat vervolgens heen gaat.

Het geheel aan applicatiecomponenten betrokken bij Documentcreatie moet worden voorbereid op ontwikkelingen als de Wet Open Overheid, denk aan de mogelijkheid om in sjablonen te markeren welke delen van een document door de DCA gecensureerd worden in een openbare/publieke versie.

EHotting (overleg)31 mei 2016 17:43

Dit is naar mijn idee een belangrijke component. Ik ondersteun het voorstel om deze component toe te voegen.

Patrick Castenmiller (overleg)20 jun 2016 16:27
 

Ja, goed idee, ondersteun ik ook.

Kbrouwer (overleg)22 jun 2016 11:22

OK. Outputmanagementcomponent is terug. De verwarring zat hem in de oude omschrijving: die leek enkel op documentcreatie gefocust. Definitie: “Component voor het routeren van de output van processen naar het (de) juiste kana(a)len.” Toelichting: ”Output van een proces kan een brief, een beschikking of een andersoortig document zijn. Afhankelijk van de kanaalvoorkeur van klant of ketenpartner en de inrichting van de gemeente, moeten deze berichten per e-mail, berichtenbox of printer gestuurd worden. Door hiervoor één generiek component te voorzien, hoeven procesondersteunende systemen deze logica niet in te bouwen. Indien er een document gemaakt moet worden volgens een bepaald format, dient hiervoor de documentcreatiecomponent te worden gebruikt. Functie: Formatteren en routeren van procesoutput Definitie: Functionaliteit voor het routeren van procesoutput (berichten, documenten) naar diverse kanalen, zoals berichtenbox, e-mail of printer.

Deelfuncties: Formatteren van procesoutput Routeren van procesoutput naar e-mail Routeren van procesoutput naar printer Routeren van procesoutput naar berichtenbox (burgers en bedrijven)

Tineke (overleg)23 nov 2016 11:20
 
 

'Inzien loggegevens' in Mijngemeente-component

De Mijngemeentecomponent zou ook functionaliteit moeten bieden voor het inzien van loggegevens uit de loggingcomponent. Hiermee moeten burgers kunnen inzien door welke organisatie of welk organisatieonderdeel en in welk proces hun gegevens zijn gebruikt. Dit stelt ook eisen aan de manier waarop in de loggingcomponent gegevens worden geregistreerd omdat mogelijk niet alle gelogde gegevens in aanmerking komen voor publicatie, denk aan fraude-onderzoeken e.d.

Kbrouwer (overleg)22 jun 2016 11:28

Op zich een idee dat we van harte ondersteunen. We zien echter ook de complicaties met het loggen van gegevensgebruik vanuit fraude-onderzoeken etc. Dit willen we eerst nog wat dieper uitzoeken (samen met gemeenten) alvorens de functie al in de architectuur op te nemen. Volgend jaar gaan we o.a. met het aspect beveiliging en privacy aan de slag. Wellicht dat we het hierin kunnen meenemen

Tineke (overleg)23 nov 2016 11:19
 

Volgens de beschrijving gaat het bij de referentiecomponent "Registreren en delen van kerngegevens" om "Functionaliteit voor het registreren van contactmomenten en afspraken". Dat lijkt me niet correct.

Daarnaast wordt de functionaliteit uitgewerkt in twee componenten, de Medewerkerregistratiecomponent en de Bedrijven- en instellingencomponent. Volgens mij zijn er meer kernregistraties, in het ruimtelijk domein een heel rijtje maar ook rond de sociale zekerheid. M.a.w. er is functionaliteit nodig voor het registreren en delen van kerngegevens maar die is breder dan alleen medewerkers en bedrijven / instellingen.

Kbrouwer (overleg)22 jun 2016 10:56

Oeps. Beschrijving aangepast.

Het begrip kernregistratie is in het katern verbinden beschreven en heeft hierdoor een plaats gekregen op de hoofdplaat. Eens dat er meerdere kernregistraties zijn. De cocreatie heeft echter geen uitgebreider beeld opgeleverd, dus dit zal in de toekomst moeten worden aangevuld. Deze kunnen een plaats krijgen onder “Registreren en delen van kernregistraties” met hun eigen functie en eigen referentiecomponent. Op de informatiearchitectuurplaat met referentiecomponenten miste de Bedrijven- en instellingencomponent.

Mocht nu blijken dat het aantal kernregistraties zo groot wordt dat het de plaat wat begint te domineren, dan vinden we daar een oplossing voor.

Tineke (overleg)23 nov 2016 11:18
 

Onder patroon ‘Dienstverlening naar klanten’ staat “Aanvraag van producten en diensten via een e-Formulierencomponent. Dit component verzorgt het voorinvullen van al bekende (basis)gegevens en stelt klanten in staat om producten en diensten mee aan te vragen.”. Dit suggereert dat er één component is die alle eFormulieren (voor alle domeinen) ondersteunt. Een andere oplossing is dat er componenten per domein zijn die de eFormulieren voor dat domein ondersteunen en een sterke(re) integratie hebben met de componenten voor de afhandeling van dat formulier. Wij zien steeds vaker dat het invullen van een formulier niet los staat van het verwerken ervan (in verschillende componenten) maar dat het invullen en verwerken van en formulier stappen zijn in een proces dat door één (applicatie) component wordt ondersteund. Door te voorkomen dat formulieren moeten worden overgedragen, wordt de kans op een volledige en juisten invulling en verwerking vergroot. KING zou hier ook de optie moeten geven om e-Formulieren vanuit de taakspecifieke componenten (applicaties) aan te bieden in plaats van een afzonderlijk component.

John Rooijakkers (overleg)9 jun 2016 07:58

Vanuit het aanbieden van applicaties kan het logisch zijn om een eformulier direct vanuit het taakspecifiek informatiestysteem aan te bieden. Als patroon is dit minder gewenst, omdat de functie afbakening minder scherp wordt (en dit is juist een doel van de GEMMA). Het is volgens mij ook niet per definitie noodzakelijk dat er slechts 1 formulierenapplicatie is die de formulierencomponent invult; zeker als gedacht wordt aan de "generieke functionaliteit voor burgers en bedrijven", al dan niet binnende "specifieke functies voor de domeinen"

In het patroon spelen meer componenten een rol; ook de zaakregistratie is in dit kader van belang. Juist de volledige interactie van de componenten moet door de applicaties goed worden ingevuld.

nb. bij 1 relatie in het patroon staat geen beschrijving: van servicebuscomponent naar "taak specifiek informatiesysteem". betekent deze relatie dat ook hier de "aanvraag product of dienst" ka worden doorgezet of moet deze altijd via de "zakenregistratiecomponent" lopen.

Patrick Castenmiller (overleg)20 jun 2016 15:28

De relatie tussen taak specifiek informatiesysteem en servicebuscomponent is verwijderd. Dit moet inderdaad via de zakenregistratiecomponent lopen. Ook is de notificatierouteringscomponent toegevoegd.

Tineke (overleg)23 nov 2016 11:12
 

In de gemeentelijke markt wordt inderdaad regelmatig gekozen voor silo-oplossingen, vaak SaaS, waarbij de hele silo van user interface naar persistente data binnen één oplossing wordt aangeboden. Dat is contra Service Oriented Architecture.

Ik ben het eens dat eFormulieren niet zouden moeten worden ingevuld door een enkele applicatie, echter om diametraal tegenovergestelde reden. Ik verwacht dat aan de kant van de user interface meer diversiteit nodig gaat zijn dan kan worden geboden met de beschreven component eFormulieren: de inhoud van de formulieren wordt bepaald in de laag eronder, de user interface verschilt afhankelijk van kanaal, plaats, tijd, device van gebruiker/ambtenaar.

EHotting (overleg)20 jun 2016 19:53
Bewerkt door auteur
Laatste bewerking: 22 jun 2016 20:48

@EHotting: Bedoel je dat de beschrijving van de component moet worden aangepast waardoor een meer dynamische invulling hiervan mogelijk is.

Patrick Castenmiller (overleg)22 jun 2016 20:17

Ik vraag me af of het een apart aan te wijzen component zou moeten zijn. Elk modern platform voor het bouwen van een user interface biedt mogelijkheden voor het dynamisch ophalen van data uit een achterliggende database.De eFormulierencomponent biedt een vanuit oogpunt architectuur bekeken nogal willekeurige verzameling functionaliteit:Authenticeren klant, Vertalen behoefte naar productvraag(?), Ondersteunen vraag-antwoord dialoog(?), Indienen aanvraag en tonen ontvangstbevestiging. De component wordt daarmee heel specifiek ingevuld, en snoept bovendien een stukje af van de 'Websitecomponent', waar blijkbaar alleen statische content mee gepubliceerd mag worden. Ik ben er nog niet over uit wat de juiste oplossing is.

EHotting (overleg)22 jun 2016 20:31

Zoals het nu is beschreven bevat de component dus een "klant-uitvraag-en-behandelproces (tot het punt dat de vraag kan worden afgehandeld)" voor een specifiek kanaal. Als ik het goed begrijp benoem je de mogelijkheid de 'bedrijfslogica' uit de component te halen, waardoor deze logica ook binnen andere kanalen toe te passen is (hergebruik). Authenticatie klant is ook een functie die binnen verschillende kanalen aan te roepen is (hergebruik).

Patrick Castenmiller (overleg)22 jun 2016 20:47

Het mooie aan serviceorientatie is dat je op verschillende manieren tot goede services kunt komen. Voor- en achterkant door 1 leverancier/applicatie laten bedienen hoeft niet strijdig te zijn met servicegericht werken. In de praktijk hebben verschillende componenten, ook een neutrale eFormuliercomponent, bestaansrecht. Ik zie net als John de ontwikkeling dat naarmate je wilt dat intakes specifieker en slimmer worden je steeds meer, van oudsher vooral binnen 'backoffice applicaties' opgeborgen, taakspecifieke functionaliteit nodig hebt. GEMMA 2 zet daarin juist goede stappen door begrippen als front/mid/back niet meer te gebruiken maar het te hebben over generieke functionaliteit. Idealiter worden alle applicaties netjes opgeleverd met maximale integratie via services. De praktijk is dat er ook genoeg situaties zijn waarin dat niet nodig is om goed te voldoen aan bestaande businessbehoeften. In antwoord op John zijn vraag hoeft er van mij dus niks nieuws bij, maar is het wel belangrijk (net als bij andere componenten overigens) duidelijk te maken dat onderscheiden van componenten niet betekent dat je in alle gevallen die componenten nodig hebt.

Ad Gerrits (Nijmegen) (overleg)29 jun 2016 13:42
 

Klopt, de functie authenticatie klant komt op meerdere plaatsen voor. Er zijn nog meer van deze erg generieke functies: hier gaan we in een volgende ronde nog een elegante oplossing voor zoeken.

Tineke (overleg)23 nov 2016 11:16
 
 
 

De functionaliteit van de e-formulierencomponent is wat herzien. Beheren van e-formulieren (functionaliteit voor gemeente) is erbij gekomen. Toeleiden naar het juiste formulier is overgeheveld naar de functie “publiceren van gemeentelijke producten en diensten”. Een vraag-antwoorddialoog is wel de functionaliteit die een e-formulier biedt, dus die functionaliteit is behouden. De websitecomponent hebben we hernoemd in webcontentpublicatie- en beheercomponent. Daarmee worden dus diverse soorten content geaggregeerd en gepubliceerd. De nieuwsbrievencomponent stond hier ten onrechte; die is verwijderd (versturen van nieuwsbrieven is iets heel anders). Publiceren van producten en diensten is een hoofdfunctie geworden. De sociale-mediacomponent is wel erg specifiek; die wordt misschien in het dienstverleningsdomein terug opgenomen. En tonen van geografische content hebben we wegelaten. Indachtig “Geo in GEMMA”: “Geo–content is ook gewoon content”.

Tineke (overleg)23 nov 2016 11:15
 

In het patroon hebben we nu een “productaanvraagcomponent” toegevoegd. Dit is een component die voor verschillende domeinen anders ingevuld kan worden, maar niet als vereiste meekrijgt om functionaliteit voor het zelf definiëren van formulieren te bieden. Deze component zal ook terugkomen in de domeinarchitectuur dienstverlening.Voor prefill en indienen van een productaanvraag gaan wel dezelfde standaarden gelden.

Tineke (overleg)23 nov 2016 11:04
 

Ontbreken van applicatiecomponenten als implementeerbare eenheden voor (samenwerkende) gemeenten

Wij missen een logische (en wellicht zelfs een geadviseerde) groepering van referentiecomponenten in de informatiearchitectuur tot applicatiecomponenten (cq applicatie suites). Indien referentiecomponenten in verschillende combinaties door de markt worden aangeboden, is het voor gemeenten nagenoeg onmogelijk om een goede samenhangende informatievoorziening te realiseren. Dit geldt met name voor de informatievoorziening binnen een domein. De informatie-uitwisseling tussen verschillende domeinen is veelal gebaseerd op RSGB en RGBZ gegevens en hiervoor voldoen de nu reeds geboden koppelvlakken veelal. De informatie-uitwisseling tussen referentiecomponenten binnen één domein is veelal afhankelijk van domein specifieke gegevens en koppelvlakken waarbij generieke koppelvlakken niet voldoen en de vereiste specifieke koppelvlakken ontbreken. In onze visie zou gestreefd moeten worden naar een “best of suite” benadering binnen de gemeentelijke domeinen. Dit vereist dat de referentiecomponenten binnen ieder domein logisch en eenduidig moeten worden gegroepeerd tot een (minimaal) aantal applicatiecomponenten waardoor tevens het noodzakelijke aantal (veelal complexe) koppelvlakken tussen verschillende referentiecomponenten (feitelijk: applicatiecomponenten) binnen hetzelfde domein wordt geminimaliseerd.

Aanvullend hierop: Onder het kopje ‘Naamgeving Referentiecomponenten’ wordt het volgende gesteld: “Een systeem moet alle functionaliteit (en toegewezen standaarden) behorende bij een referentiecomponent invullen om 'GEMMA compliant" te zijn.”. Dit betekent dat als leveranciers ervoor kiezen om meerdere referentiecomponenten te bundelen in een Suite, toch alle koppelvlakken die zijn bedacht om referentiecomponenten onderling te verbinden moeten implementeren en certificeren om Gemma compliant te kunnen worden. Terwijl onze boodschap nou juist is om de klant een eenvoudig, overzichtelijk, beheersbaar en betaalbaar applicatielandschap aan te bieden.

John Rooijakkers (overleg)9 jun 2016 07:48

Daar ben ik het niet mee eens. In de praktijk zijn suites historisch gegroeide complexe samenstellingen van functionaliteit die zeer moeilijk in z'n geheel te vervangen zijn en gemeentes afhankelijk maken van leveranciers. Het doel van referentiecomponenten is nou juist de introductie van logische functionaliteiten die door verschillende leveranciers geleverd kunnen worden. Daarmee worden concurrentie en marktwerking bevorderd en kunnen gemeentes de regie op hun informatievoorziening weer terugkrijgen. De (her)introductie van complete suites met hun interne verkleffing staat daar haaks op. Niet doen dus. Anders komen we nooit van dit soort verhalen af: [artikel NRC - Gegijzeld door de softwareboer]

Kbrouwer (overleg)22 jun 2016 13:13

Ik begrijp deze reactie, maar het aantal verschillende referentie componenten is evenredig met het aantal te definiëren en implementeren koppelvlakken tussen deze componenten. Zie ook mijn opmerking: "De informatie-uitwisseling tussen referentiecomponenten binnen één domein is veelal afhankelijk van domein specifieke gegevens en koppelvlakken waarbij generieke koppelvlakken niet voldoen en de vereiste specifieke koppelvlakken ontbreken". Het is maar zeer de vraag of gemeenten functioneel beter (en goedkoper) af zijn in een dergelijke situatie.

John Rooijakkers (overleg)4 jul 2016 09:07
 

Mbt de terminologie geldt dat referentiecomponent en applicatiecomponent op hetzelfde niveau zitten. Clusteren daarvan *binnen een referentiearchitectuur* in aanbevolen combinaties (collaboration/ 'suite') lijkt me niet wenselijk. Maar je kunt natuurlijk wel voorbeelden geven van vaker toegepaste combinaties. Bijv. met voor- en nadelen en praktijkervaringen van gemeenten. Het is zo sterk contextafhankelijk welke componenten het meest geschikt zijn voor een gemeente dat wel of niet kiezen voor een suite (en zo ja, welke) op basis van eigen gemeentelijke afwegingen plaats moet vinden (in het beste geval mbv een passende eigen, op GEMMA gebaseerde, gemeentelijke architectuur. Dus: niet in de GEMMA architectuur, wel vanuit KING handvatten geven voor dit type keuzen.

Ad Gerrits (Nijmegen) (overleg)29 jun 2016 13:00

Het staat ieder leverancier vrij om best of suite, best of breed of andere aanpak te kiezen. Het staat iedere gemeente ook vrij om een leverancier te kiezen. GEMMA is een referentiearchitectuur en daarmee willen we alle varianten kunnen ondersteunen. Iets als een aanbevolen groepering oid. zullen we dus niet in GEMMA opnemen. Wel willen we in 2017 enkele voorbeelden uitwerken over hoe je deze referentiearchitectuur kunt realiseren.

Overigens is de observatie dat meer referentiecomponenten tot meer koppelvlakken leiden voor wat betreft de referentiecomponenten die generieke gedeelde functionaliteit implementeren juist. Deze overweging nemen we dan ook me bij in het al dan niet definiëren van nieuwe referentiecomponenten.

Tweede reden dat we in referentiecomponenten denken is het vervangingsvraagstuk eenvoudiger te maken. Een softwarepakket dat bijvoorbeeld frontofficefunctionaliteit aanbiedt, maar niet de daarvoor binnen GEMMA gedefinieerde koppelvlakken ondersteunt is dus geen GEMMA conforme invulling van dat referentiecomponent. Gemeenten kunnen dan nog altijd kiezen voor dit component, maar krijgen zo een beter inzicht in de consequenties.

Tot slot: en er zijn specifieke koppelvlakken en mechanismen in ontwikkeling voor het uitwisselen van domeinspecifieke gegevens (productaanvraag koppelvlak/aanvullende elementen).

Tineke (overleg)23 nov 2016 11:02
 
 

Gegevensdistributiecomponent nog nodig naast de Servicebuscomponent?

Wat is het verschil tussen '... distributie van ... gegevens naar afnemende applicaties' en '... het routeren, transformeren en eventueel orchestreren van berichten tussen applicaties'? Het distribueren doe je toch m.b.v. berichten?
Een Servicebus biedt diverse functionaliteiten. M.i. is gegevensdistributie niet meer of minder dan één van deze functionaliteiten. Genoemd worden (bij distributie): Inwinnen van gegevens, Synchroniseren van gegevens, Configureren van abonnementen, Configureren distributieregels, Loggen van activiteiten, Distribueren van gegevens en Configureren van bronnen en afnemers. Abonnementen, distributieregels en configureren van bronnen en afnemers lijkt me typisch iets voor een Servicebus: dat moet je toch weten om de berichten goed te kunnen routeren en evt. transformeren? Loggen is al een onderdeel van een Servicebus. Synchroniseren, dat vindt plaat in de afnemende component. En inwinnen vindt plaats in de zendende component.
Tijd voor afscheid?

ArjanKloosterboer (overleg)29 mei 2016 23:32

In het katern verbinden is het verschil tussen een servicebuscomponent, gegevensdistributiecomponent en een gegevensmagazijn beschreven (http://www.gemmaonline.nl/index.php/KV2_Referentiecomponenten). Tevens is daar de mening van KING weergegeven ten aanzien van nut en noodzaak van een gegevensdistributiecomponent. Beantwoord dat je vraag?

Cocreatie2016 (overleg)30 mei 2016 08:34

Voor systeemintegratie bestaan twee grote scholen: ESB vs Distributed Publish/Subscribe (Data Distribution System). Heel GEMMA gaat in de richting van ESB. Er is in het huidige gegevenslandschap een aantal moeilijkheden te overwinnen die niet met ESB alleen kunnen worden opgelost, al lijkt met de beschrijving van het verschil in het katern verbinden (met o.a. "ESB heeft geen weet van de functionele betekenis van berichten, gegevensdistributiecomponent handelt berichten af op basis van de functionele betekenis en inhoud van berichten") te kort door de bocht. De gegevensdistributiecomponent gebruikt een niet al te complexe set van business-rules die (hoewel onwenselijk) ook prima in een Enterprise Service Bus ondergebracht zouden kunnen worden. Het onderscheid zit met name in de buffer die de GDC onderhoudt.

In een referentiearchitectuur zouden niet twee oplossingen naast elkaar moeten bestaan voor hetzelfde probleem. Als ik het Katern Verbinden goed lees neigt KING naar de ESB als systeem voor integratie in de referentiearchitectuur, en merkt daarbij op dat dit vooralsnog niet kan omdat niet alle basisregistraties / landelijke voorzieningen daar klaar* voor zijn. Vanzelfsprekend zullen niet alle leveranciers daar enthousiast over zijn. De huidige situatie laat echter ruimte voor beide systemen, in de platen met referentiecomponenten wordt geen voorkeur duidelijk. In mijn opinie zou het goed zijn aan te geven dat de ESB variant de voorkeur heeft, (meer specifiek wat KING de 'externe functionaliteit aanroep integratiestijl' noemt). Daarmee gaan we naar een architectuur waarbij data in de bron blijft en niet langer rondgepompt wordt.

- *) Onder het kopje 'Mening van KING' (http://www.gemmaonline.nl/index.php/KV2_Referentiecomponenten#Mening_van_KING) wordt o.a. gesteld dat alvorens de component overbodig verklaard kan worden alle basisregistraties eerst "Op een identieke manier met historie moeten omgaan". Ik neem aan dat hier wordt gedoeld op het concept van formele en materiële historie wat we kennen uit de BRP, dit zou inderdaad helpen. Het is goed dit expliciet te maken.

EHotting (overleg)1 jun 2016 00:28

Ben het eens met Eelco: binnen een referentiearchitectuur is het goed om helder aan te geven dat "de ESB variant" de voorkeur heeft.
In de notitie wordt helder beschreven een GEMMA-distributiesysteem met name "RSGB-gegevens door bronsystemen gevoed via StUF kennisgevingen distribueert (optioneel ook andere gegevens distribueren; implementatie hiervan is leverancier afhankelijk)." In de referentiearchitectuur zou ik een distributiesysteem, net zoals een ESB, neutraler beschrijven: een voorziening die (oa via buffering en inhoudelijke beoordeling adv regels) gegevens uit bronsystemen kan distribueren, waarbij dan aanvullend als eis geldt dat "RSGB/StUF" wordt ondersteund.

Ad Gerrits (Nijmegen) (overleg)8 jun 2016 12:22
 
 
 

Wordt de GEMMA informatiearchitectuur nog verder uitgewerkt, opdat deze bruikbaar is voor interne gesprekken en ook in aanbestedingen?

Ik heb met name nog wel vragen over de uitwerking van componenten en elementen tot het niveau dat we er iets mee kunnen (in interne gesprekken maar ook in aanbestedingen). Als voorbeeld de elementen zoals vermeld op http://gemmaonline.nl/index.php/Cocreatie:Gemma/doc/applicatiefunctie/duurzaam_opslaan_en_ontsluiten_informatieobjecten : waar vind ik het onderscheid tussen eisen t.a.v. “DMS/RMA” versus eisen t.a.v. “e-depot” ?

Cocreatie2016 (overleg)6 jun 2016 13:23

De GEMMA is het referentiekader dat een gemeente gebruikt om haar eigen architectuur te bepalen. Een gemeente zal de GEMMA altijd eerst moeten doorvertalen naar haar eigen situatie.

Voor wat betreft het onderwerp archivering is zeer recent een rapport gepubliceerd, waarin de functionele eisen verder worden uitgewerkt. Zie https://vng.nl/onderwerpenindex/cultuur-en-sport/archieven-en-musea/nieuws/eisen-aan-e-depotvoorzieningen. In het rapport staat een architectuurplaat waarmee verschillende varianten van een e-Depotvoorziening worden samengesteld uit GEMMA 2 referentiecomponenten. Het is aan de gemeente om te bepalen of één van deze varianten past in haar archiveringsbeleid of dat wellicht nog een variant ontbreekt.

Cocreatie2016 (overleg)6 jun 2016 14:25
 
Eerste pagina
Eerste pagina
Vorige pagina
Vorige pagina
Volgende pagina
Volgende pagina
Laatste pagina
Laatste pagina