Afwegingskader primair DMS-component i.r.t. Common Ground

Samenvatting

• De meeste DMSen zijn een monolithische applicatie en voldoen niet aan Groeipact afspraken (basisgedachte A, pagina 3);

• De Documenten API moet uitgebreid worden om te voorzien in alle mogelijkheden om functies in bovenliggende applicaties mogelijk te maken;

• De mindset voor het gebruik van objecten in plaats van documenten is er nog niet;

• Advies is om Documenten API te gebruiken in een registratie component (zoals Open Zaak).

Inleiding

Documenten spelen een belangrijke rol bij de informatiehuishouding van gemeenten. Er zijn inkomende documenten (bijv. een klacht van een inwoner) en uitgaande documenten (bijv. een antwoord van de gemeente).

Officieel wordt gesproken van “informatieobjecten”. Een informatieobject kan een fysieke brief zijn, of een e-mail, een bijlage, een foto, etc. inclusief bijbehorende meta-gegevens, zoals de taal, auteur, aanmaakdatum, etc. Tegenwoordig wordt bijna alles gedigitaliseerd dus fysieke documenten worden meestal zo snel mogelijk omgezet naar digitale versies: een bestand.

De term “document” moet in dit document gezien worden in de breedste zin, en wordt als synoniem gebruikt voor “informatieobject”, of de combinatie van “bestand” en “meta-gegevens”.

De hoofdvraag: Hoe kan het beste document registratie en ontsluiting plaatsvinden om zo goed mogelijk te voldoen aan de behoeften van de inwoner en medewerkers, aan wetgeving en aan Common Ground principes?

Korte geschiedenis

Vroeger waren er kasten vol met documenten, netjes in ordners, voorzien van een nummer, datum en omschrijving. Met de intrede van het digitale tijdperk zijn de documenten vervangen door bestanden, ordners door mappen, en kasten door Document Management Systemen (DMS).

Het DMS nam een vrij centrale rol in. Het was de plek waar je alles kon zoeken en vinden, en door alle documenten en mappen kon bladeren.

Met de introductie van zaakgericht werken, werd de zaak het centrale knooppunt. Een zaak bevat de document-overstijgende meta-gegevens, zoals de zaakstatus, betrokkenen, etc. en maakte processen inzichtelijker. In DMSen werd deze gedachte gevolgd door een deel van de zaak gegevens te kopiëren naar de map waar al deze documenten in zaten (StUF-ZDS).

De centrale rol van DMSen verschoof daardoor naar zaaksystemen. De markt reageerde, en DMSen werden een soort zaaksystemen, en zaaksystemen kregen documentfuncties. Documenten en Zaken waren met elkaar verweven. Als 1 systeem niet beide functies had, kon als brug tussen beide systemen ook CMIS worden gebruikt. Dit was zelfs onderdeel van de StUF-ZDS documentatie.

Door de Common Ground beweging, nieuwe privacy wetgeving, meer hergebruik, betere marktwerking, de wens voor meer transparantie en uiteraard ook het doel om te komen tot betere dienstverlening, evolueerde StUF-ZDS naar ZGW API’s.

In de ZGW API’s werden een aantal vragen gesteld: Waarom moesten documenten perse aan een zaak hangen? Was het nog wel nodig, of wettelijk gezien wel toegestaan, door een bak aan documenten te zoeken? Waarom werd een besluit eigenlijk altijd een PDF terwijl het besluit een vast gestructureerde tekst is? Waarom werden er überhaupt nog PDFs gemaakt en niet enkel gestructureerde data opgeslagen? Ook landde het besef dat je, in de context van zaakgericht werken, niet enkel documenten archiveert maar juist hele zaken.

De ZGW API’s bevatte daarom o.a. een separate Documenten API: Herbruikbaar voor alles wat met documenten te maken had. Met een optionele koppeling naar zaken via de Zaken API, of eigenlijk met een optionele koppeling naar wat maar nodig is. Zo kon je net zo goed “Objecten” met gestructureerde gegevens koppelen aan een zaak, in plaats van een PDF.

Termen

• Document Alias voor Informatieobject, t.b.v de leesbaarheid.

• Document Registratie Component (DRC) Een implementatie van de Documenten API als “werkende software”.

• Documenten API Een API om documenten te registreren en te ontsluiten, volgens de VNG API standaard voor Zaakgericht Werken (ZGW API’s)

• Informatieobject De naam voor een document in de breedste zin: Gegevens en meta-gegevens. Praktisch gezien zitten gegevens altijd in een bestand (eventueel na inscannen). Elk informatieobject is van een bepaald informatieobjecttype.

• Informatieobjecttype Het type informatieobject. Typisch verwacht je bepaalde type informatieobject bij een zaak van een bepaald zaaktype. Ter illustratie: Het zaaktype “klacht indienen” kan het (inkomende) informatieobjecttype “klachtformulier” bevatten, en het (uitgaande) informatieobjecttype “antwoordbrief”. Een informatieobjecttype is niet enkel binnen zaken relevant en kan tevens meer dan enkel documenten beschrijven, maar ook projecten, trajecten, kaarten, e.d.

• Open Zaak Een implementatie van alle ZGW API’s als productiewaardige software.

• Zaakgericht Werken API’s (ZGW API’s) De VNG API standaarden om zaken en document te registeren en ontsluiten. De ZGW API’s bestaan uit:

  • Zaken API

  • Documenten API

  • Catalogi API

  • Besluiten API

  • Autorisaties API

  • Notificaties API

Praktijk

Even vooropgesteld: Een document is een bestand en meta-gegevens. Het bestand wordt opgeslagen op een bestandssysteem op een harde schijf. De meta-gegevens van een document worden opgeslagen in een database, die zich ook weer op een (niet perse dezelfde) harde schijf bevind.

Termen zoals cloudopslag, blob storage, volume-mounts, netwerkschijven, network-attached storage, zijn allemaal varianten van een harde schijf.

Hieronder staan de combinaties die vergeleken worden:

Open Zaak

Open Zaak bevat o.a. de Documenten API. Standaard worden documenten direct opgeslagen als bestand op de harde schijf, en meta-gegevens in de database. Open Zaak combineert de functionaliteit van een aantal componenten, omdat deze sterk met elkaar verbonden zijn: DRC, ZRC (Zaakregistratiecomponent), BRC (Besluitregistratiecomponent), ZTC (Zaaktypecatalogus) en AC (Autorisatie-component).

Open Zaak met CMIS-koppeling

Met de CMIS-koppeling worden documenten nog steeds opgestuurd naar en ontsloten via, de Documenten API van Open Zaak. Open Zaak registreert echter het document (dus het bestand en de meta-gegevens) volledig via CMIS in het externe systeem, zoals bijvoorbeeld een DMS.

Document Registratie Component (geen bestaande software)

Een DRC is enkel een Documenten API. Open Zaak kan worden geconfigureerd als enkel DRC door alle andere API’s uit te schakelen. Voor zover bekend bestaat er geen “pure” DRC. Er is wel een referentie-implementatie maar deze is niet geschikt voor productie.

DMS met Documenten API

Een applicatie voor het beheer van documenten, gecombineerd met een Documenten API voor registratie en ontsluiting van de documenten. Let wel dat dit een systeem is met een API, en dus niet 2 verschillende componenten in verschillende lagen.

Voor- en nadelen

Performance

	Open Zaak	Open Zaak + CMIS	DRC	DMS + Documenten API
Responsetijden	Snel	Traag	Snel	Snel
Gecombineerde zoekquery (handelings-gedreven API’s)	Mogelijk	Mogelijk maar via netwerk / traag	Mogelijk maar via netwerk / traag	Mogelijk maar via netwerk / traag

Common Ground

	Open Zaak	Open Zaak + CMIS	DRC	DMS + Documenten API
Groeipact (A): Gegevens scheiden	Ja	Ja	Ja	Nee
Groeipact (B): Meervoudig gebruik	Ja	Ja	Ja	Ja
Eenmalige vastlegging bij de bron	Ja, als Open Zaak als bron wordt gezien.	Ja, als Open Zaak als bron wordt gezien.	Ja, als DRC als bron wordt gezien.	Ja, als DMS als bron wordt gezien.
Component gebaseerd	Ja, mogelijk	Ja, mogelijk	Ja	Deels

Functies

Met een DMS zijn verschillende functionele behoeften in te vullen. Dat komt enerzijds omdat een DMS met een achterdeur iets kan wat een andere applicaties niet kunnen: Directe de bestanden lezen zonder gelimiteerde API ertussen. Anderzijds omdat een DMS een UI-applicatie is in combinatie met een register.

	Open Zaak	Open Zaak + CMIS	DRC	DMS + Documenten API
Aanmaken	Ja	Ja	Ja	Ja
Bewerken	Ja	Ja	Ja	Ja
Samen bewerken	Ja	Ja	Ja	Ja
Raadplegen	Ja	Ja	Ja	Ja
Zoeken (in de inhoud)	Nee, niet in standaard	Nee, niet in standaard	Nee, niet in standaard	Mogelijk, mits in DMS
Anonimiseren	Ja, middels aparte app	Ja, middels aparte app	Ja, middels aparte app	Ja, mits in DMS of middels aparte app
Publiceren	Ja, middels aparte app	Ja, middels aparte app	Ja, middels aparte app	Ja, mits in DMS of middels aparte app
Archiveren	Ja, middels aparte app	Ja, middels aparte app	Ja, middels aparte app	Ja, mits in DMS of middels aparte app
Clusteren / Groeperen / Labelen	Nee, niet in standaard	Nee, niet in standaard	Nee, niet in standaard	Ja, mits in DMS

Overige

	Open Zaak	Open Zaak + CMIS	DRC	DMS + Documenten API
Bestanden toevoegen zonder documenttype	Nee	Nee	Nee	Mogelijk, maar niet via Documenten API
Archiefparameters bij document opslaan	Nee	Nee	Nee	Mogelijk, maar niet via Documenten API

Vragen en antwoorden

Vraag: Hoe zijn de responsetijden bepaald en gebaseerd op welk onderzoek of argumenten is dit dan gedaan?

Antwoord: Hoewel er diverse performance tests zijn gedaan door de jaren heen (die dit ook aantonen), is deze tabel op basis van feedback uit de praktijk alsmede het eenvoudige feit dat meer netwerk verkeer nu eenmaal trager is dan minder netwerk verkeer.

Vraag: Er wordt aangegeven dat gecombineerde queries via openzaak snel zijn maar dat het nu nog niet kan, dus hoe kan je dit dan aangeven?

Antwoord: Zie hierboven. Een gecombineerde query vergt minder netwerk verkeer en minder separate calls, en geeft dus snellere response tijden.

Vraag: Wat is nu daadwerkelijk het advies? En wat ga je doen als het nog 3 jaar duurt voordat het allemaal is uitgedacht en geïmplementeerd?

Antwoord: Stappen zetten om de Documenten API uit te breiden maar deze nu toch al te gaan gebruiken zodat er meer druk komt om de API specificatie van de Documenten API uit te breiden, en behoeftes duidelijk worden uit de praktijk.

Vraag: “Bij voorkeur zou een DMS enkel een UI laag zijn bovenop een willekeurige Documenten API,” Volgens mij is dit de omgekeerde wereld. DMS en UI hebben juist niets met elkaar te maken. CMIS is een API laag bovenop een DMS zodat er geen afhankelijkheid is van een bepaald product (specifieke DMS)

Antwoord: Een DMS is opslag en UI (beheer van documenten, mappen, kunnen zoeken). De Common Ground gedachte trekt deze uit elkaar. Dat een DMS een CMIS endpoint aanbiedt doet hier niets aan af.

Conclusie

Achtergrond

Om de hoofdvraag te beantwoorden ontleden we deze in 3 delen:

Hoe kan voldaan worden aan de behoeften van inwoners en medewerkers?

Voor dit onderdeel kijken we vooral naar performance en functies. Qua performance kan Open Zaak waarschijnlijk de beste resultaten geven, mits er daadwerkelijk gecombineerde queries gesteld kunnen worden. De standaard laat dat nu nog niet toe. Hierdoor zullen Open Zaak, een DRC en een DMS ongeveer even snel zijn in theorie. De combinatie met CMIS zal altijd trager zijn.

Wat functies betreft heeft het DMS duidelijk een streepje voor. Vooral zoeken is een veelgevraagde functie, los van wetgeving of privacyregels.

Voldoen aan wetgeving

Door gebruik te maken van de Documenten API kunnen in ieder geval de juiste classificaties rondom zichtbaarheid en archivering via de zaak worden opgegeven. Op documenten die niet via de Documenten API komen, is dat minder zeker. Dit laatste is mogelijk bij een DMS en niet bij Open Zaak of een DRC.

Voldoen aan Common Ground principes

Een DMS combineert een register en een UI om bepaalde zaken mogelijk te maken die niet kunnen op API niveau. Hiermee voldoet een DMS die, vanuit gebruikersperspectief bepaalde functies heeft, eigenlijk nooit aan het groeipact. Een DMS dat is opgesplitst in een UI en een Documenten API zou wel voldoen maar heeft dan weer bepaalde functies niet omdat deze niet mogelijk zijn via de Documenten API.

Gecombineerde queries kunnen uitvoeren t.b.v. performance, over meerdere APIs heen, maakt de herbruikbaarheid gevoelsmatig wat minder. De Documenten API komt vaster te zitten aan de Zaken API. Ook is het maar de vraag of het nu echt meer performance oplevert: Als zowel de Documenten API en de Zaken API worden uitgebreid en het expand-principe hanteren, zouden er slechts 2 calls nodig zijn, wat anders eventueel met 1 call opgelost kan worden.

Een DMS biedt een aantal voordelen door meer functionaliteit te bieden dan een enkel een Documenten API. Het beste is om de beoogde voordelen ook mogelijk te maken via de Documenten API en dus een aantal aanpassingen te maken op de VNG API standaard voor Zaakgericht Werken, waar deze API onder valt.

Advies

Alles wijst er op dat als de specificatie van de Documenten API wordt verbeterd, dat alle product-richtingen beter gaan scoren. Voor Open Zaak en een DRC simpelweg omdat de API kan voorzien in de technische koppeling om functionele behoeften in te vullen. Een DMS zou deze behoeften dan ook in een UI kunnen weergeven. Bij voorkeur zou een DMS enkel een UI laag zijn bovenop een willekeurige Documenten API, zodat er geen functie-afhankelijkheid komt op een bepaald product.

Concreet zou de Documenten API moeten worden uitgebreid met:

• Expand-functies, binnen de API, zodat je alle gegevens in 1x binnen kan halen;

• Meer filter functies t.b.v. veel voorkomende lijsten in documenten;

• Vrije labels en/of categorieën kunnen koppelen aan documenten t.b.v. ordening en weergave als mappen;

• Zoek-functie om door documenten heen te zoeken, eventueel gescoped tot een zaak, of ander gekoppeld object (dit is puur vanuit de praktijk maar in de toekomst onwenselijk); UPDATE: Ondertussen is via GPP Woo een zoeken middels indexatie toegepast. Dit zou een opmaat kunnen zijn naar integratie van zoeken in de Documenten API.

Als deze aanpassingen zijn gedaan kan in principe alles wat nodig is, voor zover in dit document genoemd, mogelijk gemaakt worden.