IV.II: Afwegingskader... richtinggevend en normerend

Dit afwegingskader beschrijft de verplichte aansluitvoorwaarden waaraan applicaties moeten voldoen bij:

• Aanschaf van nieuwe applicaties;
• Vervanging van bestaande applicaties;
• Significante wijzigingen aan bestaande applicaties.

Het kader is gebaseerd op IRMA (Informatiehuishouding Raamwerk, Model en Afwegingskader) en geeft invulling aan het principe ‘informatiehuishouding by design’. Het afwegingskader is richtinggevend en normerend: applicaties moeten aantoonbaar voldoen aan deze voorwaarden, of afwijkingen gemotiveerd laten vaststellen door het bevoegde gezag.

Dit afwegingskader is van toepassing op:

• Alle applicaties waarin gemeentelijke informatie wordt gecreëerd, ontvangen, gebruikt, beheerd, gedeeld of opgeslagen;
• Alle informatietypen (documenten, data, dossiers, zaken), ongeacht vorm of drager;
• Zowel vakapplicaties, zaaksystemen, procesapplicaties als ondersteunende systemen.

Bij elke aanschaf of vervanging geldt als uitgangspunt: Gemeentelijke processen en informatiebehoeften zijn leidend, niet de applicatie. De applicatie moet aantoonbaar aansluiten op:

• De Informatieplattegrond;
• De bijbehorende processen;
• De informatieobjecten en hun levenscyclus.

Applicaties die deze uitgangspunten niet ondersteunen, zijn niet passend binnen IRMA.

De applicatie moet aantoonbaar ondersteunen dat informatie:

1. Toegankelijk is voor bevoegde gebruikers;
2. Vindbaar is, ook organisatiebreed en over tijd;
3. Betrouwbaar is (juist, volledig, navolgbaar);
4. Veilig wordt verwerkt en beschermd;
5. Duurzaam kan worden beheerd;
6. Herbruikbaar is binnen en buiten processen;
7. Volledig blijft gedurende de hele levenscyclus.

Indien één of meerdere eisen niet (volledig) worden ondersteund, moet expliciet worden gemotiveerd hoe risico’s worden gemitigeerd.

De applicatie moet voorzieningen hebben voor minimaal de volgende IRMA‑voorwaarden:

1. Metadata: ondersteunen van de gemeentelijke Minimale Metadataset;
2. Ordening: logische samenhang tussen informatieobjecten;
3. Context: behoud van relatie met proces, zaak of dossier;
4. Authenticiteit: aantoonbaarheid van herkomst en status;
5. Integriteit: bescherming tegen ongewenste wijziging;
6. Autorisaties: rol- en functiegebaseerde toegang;
7. Vernietiging: geautomatiseerde of ondersteunde vernietiging;
8. Openbaarheid: ondersteuning van openbaarheid en Woo‑verzoeke

Handmatige work‑arounds of afhankelijkheid van gebruikersdiscipline zijn onvoldoende.

De applicatie moet:

• Aantoonbaar zijn gepositioneerd op de Informatieplattegrond;
• Een helder verband hebben met: processen, informatieobjecten, bewaartermijnen en verantwoordelijken.

Zonder deze positionering is besluitvorming over aanschaf onvolledig.

De applicatie moet:

• De gemeentelijke Minimale Metadataset ondersteunen;
• Metadata bij voorkeur automatisch vastleggen;
• Metadata toepassen op zowel document‑ als zaak/dossierniveau.

Applicaties die metadata niet (volledig) kunnen ondersteunen, zijn alleen toelaatbaar als tijdelijke of gemotiveerde uitzondering.

De applicatie moet:

• Aansluiten op het gemeentelijke entiteits‑relatiemodel;
• Gebruikmaken van dezelfde semantiek en definities;
• Interoperabel zijn met andere applicaties.

Doel: applicaties “spreken dezelfde taal” / zijn semantisch interoperabel.

De applicatie moet passen binnen het federatieve architectuurmodel:

• Autonoom functioneren binnen de eigen scope;
• Samenwerken via standaarden (API’s, metadata, autorisaties);
• Informatie kunnen delen en verbinden over systeemgrenzen heen.
• Vendor lock‑in of gesloten datastructuren zijn strijdig met dit principe.

De applicatie moet de volledige levenscyclus van informatie ondersteunen:

• Creatie en ontvangst;
• Gebruik en beheer;
• Delen en openbaar maken (Woo);
• Vernietiging;
• Indien het een applicatie betreft die (mogelijk) te bewaren informatie bevat: overbrenging naar het Gemeentearchief.

Ontbreekt ondersteuning voor één van deze fasen, dan moet worden aangegeven hoe dit organisatorisch of technisch wordt opgelost.

Afwijkingen van dit afwegingskader zijn niet standaard toegestaan. Afwijkingen moeten derhalve:

• Expliciet worden benoemd;
• Gemotiveerd worden onderbouwd;
• Worden vastgesteld door het bevoegde gezag;
• Voorzien zijn van mitigerende maatregelen.

Tijdelijke afwijkingen moeten een einddatum of migratiepad bevatten.

Dit afwegingskader wordt toegepast bij:

• Projectstarts;
• Architectuur- en ontwerpkeuzes;
• Inkoop- en aanbestedingstrajecten;
• Gateway‑ en besluitvormingsmomenten.

Het kader fungeert als verplichte IRMA‑toets en voorkomt dat informatiehuishouding pas achteraf wordt “gerepareerd”.

Samengevat: