Beslisregels
CONCEPT - Ruub van der Klip, Rutger Haagsma, Joeri Diederen
Last updated
CONCEPT - Ruub van der Klip, Rutger Haagsma, Joeri Diederen
Last updated
De overheid heeft als taak om rechtvaardig en consistent te handelen in haar besluitvorming. Uitlegbaarheid en transparantie over hoe besluiten en beslissingen tot stand zijn gekomen (ook na een aantal jaar) is essentieel. Daarvoor is inzage nodig in de toegepaste processen, beslisregels en gegevens.
Voor digitale afhandelprocessen leunt dit op geautomatiseerde toepassing van herbruikbare processen en beslisregels. Vanuit gemeentelijk perspectief heeft het de voorkeur de processen en beslisregels centraal bij te houden en executeerbaar aan te bieden. Een gemeente wil 'in control' zijn over de toepassing. Dat geeft:
Eenduidigheid in dienstverlening, doordat processen en beslisregels over meerdere digitale kanalen en softwareoplossingen op eenzelfde manier toegepast worden.
Privacy by design, één versie van de werkelijkheid voorkomt dat op verschillende plekken, verschillende processen en regels worden toegepast.
Transparantie en uitlegbaarheid, doordat centraal inzichtelijk is langs welke processen en beslisregels een besluit of dienstverlening tot stand is gekomen (ook in de tijd).
Effectiever onderhoud van applicaties. Het voorkomt onderhoud van dezelfde regels en processen binnen meerdere applicaties.
Mogelijkheid kleinere standaard business-services aan te bieden, bijvoorbeeld voor de berekening van de hoogte van een uitkering, zaak/dossiervorming, verificatie van ingevoerde gegevens (controle email adres of bankrekeningnummer).
De mogelijkheid om Burger inzage te bieden welke gegevens wanneer en door wie zijn gebruikt, regie op (eigen) gegevens.
Toekomstvastheid, doordat de beslismodellen uitwisselbaar en benaderbaar zijn bovenstedelijk, maar ook toepasbaar kunnen zijn in toekomstige AI oplossingen.
Vaak zijn er binnen het bestaande informatielandschap van gemeenten al toepassingen die 'onder de motorkap' al gebruik maken van een BP/DMN engine, maar deze zijn dan specifiek gebonden aan een dergelijke toepassing en niet inzetbaar voor andere doeleinden.
Ook binnen het Platform Dienstverlening is de beschikbaarheid van beslisregels noodzakelijk. Er worden complexe en component overstijgende beslisregels/logica toegepast. Dit vraagt om een structurele positionering van een voorziening voor executeerbare beslisregels. Voor BPM wordt vooral gebruik gemaakt van GZAC. Niet uitputtend is de behoefte:
Open Product: een catalogus en register waarin eigenschappen van gemeentelijke producten en diensten worden vastgelegd, waaronder verwijzingen naar beslisregels.
Open Formulieren: een component om verzoeken te verwerken, waarin logica wordt toegepast in relatie met beslisregels.
GZAC: een zaakafhandelcomponent waarin logica wordt verwerkt.
Open Inwoner Platform: een portaal dat op basis van eigenschappen van de ingelogde persoon en zijn of haar producten bepaalde acties laat zien.
Een beslisregel is “Een logisch of rekenkundig construct dat is gebaseerd op wet- en regelgeving of beleid en rechtstreeks sturing geeft aan de primaire taak van een uitvoeringsorganisatie”.
Een hulpmiddel om dit te realiseren, is het gebruik van gestandaardiseerde methoden voor het vastleggen en uitvoeren van beslisregels. Eén van deze standaarden is Decision Model and Notation (DMN), een wereldwijd erkende standaard voor het modelleren van beslissingen.
Beslisregels die in DMN zijn vastgelegd, kunnen eenvoudig (geautomatiseerd) worden gedeeld en hergebruikt. Dit vermindert de kans op fouten en maakt efficiëntere uitvoering van beleid mogelijk.
DMN maakt het mogelijk om complexe beslisregels op een visuele en begrijpelijke manier weer te geven. Het DMN-diagram laat in eenvoudige stappen zien hoe een beslissing tot stand komt. Dit bevordert niet alleen de transparantie naar burgers, maar maakt het ook voor beleidsmakers en uitvoerders duidelijk hoe regels worden toegepast. DMN biedt voordelen:
de beslistabellen worden onderhouden door domeinspecialisten, waardoor er geen vertaling nodig is van domeinspecialisten naar programmeurs.
de tabellen zijn eenvoudig te versioneren. Daardoor kunnen regels bijvoorbeeld bij een jaarovergang worden geintroduceerd, en blijven oude regels inzichtelijk en eventueel bruikbaar.
de tabellen zijn deelbaar tussen overheden, doordat het een standaard is.
de tabellen zijn leesbaar voor burgers.
Beslisregels zijn nodig op meerdere niveau's.
Landelijk. Regels op landelijk niveau kunnen in een landelijk gehost DMN-component worden aangeboden. Ze zijn via het principe 'HaalCentraal' te bevragen. Dit is het aandachtsgebied voor BZK en VNG (Theo Peters is hierop actief en er klinkt door dat het met 2 solutions wordt gedaan: Camunda en Avola).
Binnengemeentelijk. Regels op gemeentelijk niveau zijn relevant voor meerdere domeinen binnen een gemeente. Ze zijn centraal te bevragen en worden in een 'eigen' centrale BP/DMN-engine aangeboden. Gezien de samenwerking met andere gemeenten aan het platform Dienstverlening ligt het vraagstuk voor om ook op dit punt te komen tot een gezamenlijke inrichting van een generieke DMN engine.
DMN 'engines' zijn software oplossingen die de DMN-tabellen kunnen lezen en interpreteren. Ze fungeren als een 'vraag - antwoord' dienst binnen het ICT-landschap. Met een aanvraag met de juiste paramaters wordt realtime het antwoord verstrekt.
Voorbeelden van engines:
Red Hat Decision Manager
Flowable DMN
Uitgangspunten voor de keuze van een engine component zijn:
Nummer
Requirement
Omschrijving
1
Gebaseerd op DMN modellering. Versie 1.2 compliant.
We gaan ervan uit dat we werken met DMN als modelstandaard. DMN is een industrie standaard voor beslismodellen. Waarbij het model kan worden geëxecuteerd middels de Rule-Engine software. (M.a.w. model is software) Hiermee sluiten we aan op de ontwikkelingen binnen ICTU.
2
Versie beheer
Datum registratie/publicatie DMN model en geldigheidsperiode van het DMN model.
Binnen de Rule-Engine kan worden gewerkt met meerdere versies van een DMN model (bijv. bij indexering van normen per een bepaalde datum). En daarnaast moet o.b.v. een peildatum en tijd het juiste DMN schema kunnen worden aangeroepen. Zodat beslissingen altijd herleidbaar blijven naar een modelversie en zodat herbeoordelingen kunnen worden gedaan.
3
De Rule-Engine publiceert de service van een beslis of rekenmodel o.b.v. api.
Het is van belang de rule engine als een service component o.b.v. APi technologie te kunnen benaderen. Deze moeten stand-alone zijn van andere applicatie. Dus eigenlijk Rules as a Service (RaaS). Dit maakt dat deze RaaS vanuit verschillende applicaties kan worden aangeroepen.
4
DMN-modellen moeten leesbaar zijn
De DMN modellen moeten als beslistabellen in normale taal leesbaar zijn. Dit moet niet in programmeer taal worden opgebouwd. Maar in leesbare beslistabellen. Dit omdat de business analist(en) en de jurist(en) dit moeten kunnen toetsen. Hiermee voorkomen we uitgebreide testcycli.
Voorbeeld beslismodel.
5
De Rule-Engine biedt geautomatiseerd testen aan op valide DMN
Binnen de Rule Engine moet het mogelijk zijn om geautomatiseerd de DMN-modellen te kunnen testen op volledigheid en validiteit
6
Het onderhoud van de DMN-modellen en gepubliceerde API-services moet dynamisch worden ingericht
We moeten de DMN modellen snel kunnen aanpassen en kunnen publiceren. Zodat wet en regelgeving en evt. jurisprudentie snel kan worden verwerkt.
7
De Rule-Engine maakt alleen gebruik van geanonimiseerde data en verwijderd de aangeleverde data nadat het advies is geleverd
In DMN modellen wordt geen naar een persoon te herleiden data gevraagd. De Rule-Engine slaat tijdelijk de data op die wordt aangeleverd door de aanroepende applicatie. Zodra de hele DMN model is doorlopen en het advies wordt terug geleverd en ontvangen door de aanroepende partij (hand shake) wordt de data verwijderd in de Rule-Engine. De aanroepende applicatie logt het moment van aanroepen van de API-service en het moment van ontvangst van de advies rapportage. Zodat adviezen later herleidbaar zijn.
8
Open source tenzij Dit geldt én voor de sourcecode van de engine zelf, maar ook voor de daarin aangemaakte DMN regelset
Oplossingen binnen de landelijke samenwerking zijn bij voorkeur open source om - transparantie te bieden inde source code en levering en verbetering van de oplossing door derde partijen te stimuleren.
9
Afnemer onafhankelijkheid
Het beschikbaar stellen van de beslisregels is zoveel mogelijk onafhankelijk van de aanroepende applicatie (immers een service is op zich zelf autonoom).
10
DMN - engine is Haven compliant
Zodat deze past binnen een op Common Ground gebaseerde infrastructuur.
Uitgangspunten voor de keuze van de eindgebruikers interface zijn:
1
Het DMN model doorloopt een workflow voor goedkeuring
De tot standkoming van een DMN model wordt ondersteunt met een workflow, waarbij we van concept naar vastgesteld door Jurist gemeente naar publicatie definitief kan worden ondersteund. Hiermee worden validatie stappen vastgelegd en afgedwongen.
2
De resultaten van een beslistabel worden in het advies resultaat aan de service aanroepende applicatie in begrijpelijke taal gerapporteerd.
Aan het systeem dat een regelservice aanroept wordt het totale overzicht van de beslistabellen terug gerapporteerd als antwoord op de service aanroep. Hiermee kan aan de eindgebruiker die informatie worden getoond waarop een besluit is gebaseerd en dit kan dan ook gebruikt worden in beschikkingen en evt. individualisering van mogelijk recht op een regeling. Dit moet zijn in begrijpelijk taal.
3
De functionaliteit biedt geautomatiseerd testen aan
Binnen de functionaliteit moet het mogelijk zijn om de DMN-modellen te kunnen testen op de compleetheid en juistheid van het DMN-model.
4
Er moet een Rule-architectuur worden opgebouwd en onderhouden
Regelingen en haar beslistabellen zijn soms herbruikbaar in verschillende regelingen en ook kan er over regelingen heen een service vraag worden gesteld . Bijvoorbeeld waar heb ik recht op. Dit vraagt om ook een regelarchitectuur . Immers een goede structuur maakt hergebruik mogelijk en dit verlaagt de beheerlast. Denk bijvoorbeeld aan hergebruik van normen als minimumloon of postcode of leeftijdsgrenzen etc. bij een goede opzet kan een beslistabel dan in meerdere regelingen/berekening worden hergebruikt.
5
De DMN oplossing biedt een intuïtieve interface aan voor eindgebruikers om beslisregels te onderhouden, zodat de flow van het bouwen van de beslisregels los staat van de uitvoering in de engine. Alles DMN compliant.
Eindgebruikers (degene die regels maken en onderhouden) zijn medewerkers die verspreid zijn over een gemeentelijke organisatie. Dit zijn juristen, functioneel beheerders en medewerkers van publieke dienstverlening.
Eerste stand-alone DMN implementatie gedreven door Den Haag
Auteur: Kevin Kemkes
Op het Den Haag ZGW-platform is er een decision rules engine geïmplementeerd, de ZGW-DRE, die gebruik maakt van Decision Model and Notation (DMN), een gevestigde standaard voor het vastleggen van beslisregels (business-rules). De ZGW-DRE is een applicatie waar DMN-modellen centraal geplaatst kunnen worden voor technische implementatie. De modellen die beschreven zijn in de DMN-standaard worden geïmplementeerd binnen een business-rules engine. Daarmee is de ZGW-DRE een plek om business-rules te bevragen door verschillende externe applicaties tijdens het verwerken van informatie.
De DMN-standaard, voluit Decision Model and Notation, is ontwikkeld om een gemeenschappelijke taal te bieden voor zakelijke besluitvormingsprocessen. Deze standaard faciliteert de communicatie en begrip tussen IT-teams en business-users (in ons geval gemeentelijke medewerkers). DMN stelt organisaties in staat om business-rules op een visuele en gestructureerde manier vast te leggen. Het biedt een gestandaardiseerde notatie die gebruikmaakt van diagrammen die vergelijkbaar zijn met stroomdiagrammen. Deze diagrammen vertegenwoordigen business-rules en de logica daarachter op een manier die gemakkelijk te volgen is, zowel voor mensen die technisch onderlegd zijn als voor zij die dat niet zijn.
Meer informatie over DMN als standaard voor beslisregels (business-rules):
Een belangrijk voordeel van de implementatie van business rules in een centrale applicatie met business-rule engine is de ontkoppeling die ontstaat tussen de business rules en de applicaties die hier gebruik van maken. Business-users kunnen in deze architectuur de business-rules in DMN-formaat noteren en vast te leggen in de ZGW-DRE. Daarna kunnen externe applicaties de nieuwe business-rules bevragen zonder dat de code van de externe applicaties aangepast dienen te worden.
Voorbeelden van toepassingen omvatten:
Het bepalen van mogelijke (noodzakelijke) acties voor burgers betreffende parkeervergunningen, zoals verlengingen, wijzigingen of annuleringen, op basis van hun specifieke situatie en vergunningstype.
Het bepalen van relevante formulieren of acties binnen de gemeentelijke systemen gebaseerd op het type belastingaanslag, zoals bezwaar indienen, kwijtschelding aanvragen of aanvragen betalingsregelingen.
De ZGW-DRE bestaat uit de volgende technische componenten:
Camunda BPM Platform: Decision-rules engine, gebruikt voor het beheer van gemeentelijke processen en besluitvorming via DMN.
Keycloak: voor autorisatie en authenticatie, geïntegreerd met Camunda voor gebruikersbeheer.
Databaseconnectiviteit: Database systeem gebruikt voor het opslaan van proces- en besluitdata.
Liquibase: Verantwoordelijk voor het beheer van de database schema's, waarbij updates en wijzigingen op een gecontroleerde manier worden doorgevoerd voor met name autorisatietabellen.
Aliassen: Zaakgericht Werken Decision Rules Engine, ZGW Decision Rules Engine, ZGW-DRE.
ZGW-DRE De ZGW-DRE bestaat in de kern uit Camunda 7 (Run distributie) uitgerust met een plugin voor authenticatie en autorisatie doormiddel van Keycloak. In deze keten kunnen applicaties die gebruik maken van het ZGW-platform connectie maken met de ZGW-DRE via een REST API. De request van deze "externe" applicaties wordt geëvalueerd door de Business Rule Engine van Camunda. Deze "business rules" worden gedefinieerd door modellen in de DMN-standaard. Op basis van de inhoud in de request van de externe applicatie formuleert de business rule engine op basis van deze DMN-modellen een antwoord. Beheerders hebben alleen leesrechten op het inzien van DMN via de Camunda GUI.
Authenticatie en autorisatie gebeuren via een koppeling met Keycloak. Keycloak staat op zijn beurt koppelingen toe met veelgebruikte identity providers, zoals bijvoorbeeld Azure ENTRA ID (voorheen Azure AD) en vele anderen. Hiermee biedt de ZGW-DRE de mogelijkheid om flexibel gekoppeld te worden aan de meest gebruikelijke identity providers binnen onze organisaties.
DMN-repositories Binnen de ZGW-DRE is gekozen om de administratie van DMN-modellen uit te voeren via repositories op gitrepositories zoals GitHub. Beheerders van applicatieteams kunnen simpelweg DMN-files in XML-formaat in deze repositories committen, waarna pipelines deze repositories uitlezen via HTTPS en automatisch de modellen deployen in de business rule engine van de ZGW-DRE. Deze opzet is gekozen zodat we een zo simpel mogelijk mechanisme hanteren en ook de mogelijkheid bieden aan teams om gescheiden van elkaar hun DMN-modellen te persisteren en onderhouden.
Stakeholders die bijdragen met het uitbreiden van deze standaard:
Gemeenten: Den Haag
In de informatiekundige visie Common Ground komt dit ook tot uitdrukking in het vijflaagsmodel (). Daarin is een aparte laag opgenomen voor processen en bedrijfsregels.
Zie voor meer informatie:
Camunda open source (7) en proprietary (8)
Operaton
Drools
Kogito
Trisotech DMN
SAP DMN
Activiti DMN
Een goed voorbeeld hiervan is het gebruik van de ZGW-DRE voor het beheren van business-rules die gebruikt worden voor het Zaakafhandelcomponent (ZAC). Een business-user kan nu de beslisregels beheren door een DMN te genereren met gebruik van de , een desktop applicatie waarmee je DMN-bestanden kunt maken en bewerken in een GUI. Vervolgens kan deze DMN worden vastgelegd in de ZGW-DRE door deze in de juiste gitrepository te plaatsen, zonder dat de code die onder ZAC ligt aan te passen. Nadat de ZGW-DRE automatisch de DMN heeft ingeladen, kunnen de business-rules worden bevraagd door ZAC. Het is hierbij niet nodig om ZAC aan te passen.
Repository: Details van de Helm charts voor deze implementatie zijn te vinden op waar instructies voor implementatie beschikbaar zijn.
Helm charts ZGW-DRE op waar instructies voor implementatie beschikbaar zijn.
Camunda 7:
Camunda Keycloak Identity Provider Plugin:
Liquibase:
