peterboer
commented
4 years ago 
Closed peterboer closed 4 years ago
peterboer
commented
4 years ago
petercuret
commented
4 years ago @peterboer Hier is een beschrijving van de huidige applicaties, gevolgd door een voorstel van een plan van aanpak.
Op dit moment zijn we nog afhankelijk van BWV en de sync die relevante data overhevelt naar een database die we vanuit TOP kunnen aanspreken.
ZAKEN Wonen wordt nu ontwikkeld, daarbij is in de eerste (exploratie) fase een verbinding gemaakt met Open Zaak en functionaliteit ontwikkeld om data uit te wisselen met Open Zaak.
Ook wordt in ZAKEN Wonen nu functionaliteit ontwikkeld die dichter bij de businessprocessen van wonen staan. Denk aan uitwisseling van notities tussen gebruikers, logische wisselingen van stadia, gebruiksvriendelijke interfaces voor het beheren van zaken, etc. Deze functionaliteit wordt niet ondersteund door Open Zaak, en moet zelf ontwikkeld worden. Dat is ook de focus van het FIXXX traject waar we in zitten.
Open Zaak wordt nu in de prototypefase als Docker container binnen het ZAKEN Wonen repo gedraaid.
De Hitkans wordt geïmporteerd als library in de TOP backend, en is afhankelijk van de BWV database.
Momenteel wordt gebruik gemaakt van de KPN Grip authenticatie service. Vanuit de frontend loggen gebruikers in via GRIP. De backend zorgt er voor dat er een gebruiker in de Django backend aangemaakt wordt met informatie uit het gebruikersbestand van Grip/ADW. Dit wordt door zowel TOP als ZAKEN Wonen gebruikt.
De bedoeling is dat we straks BWV kunnen uitfaseren, en helemaal over kunnen naar ZAKEN Wonen. Daarbij zal het nodig zijn om een aantal tabellen uit te faseren door APIs. De rest gaat mee naar ZAKEN Wonen.
| Uitgefaseren door APIs | Mee naar ZAKEN Wonen |
|---|---|
| bwv_benb_meldingen -> (SIA / DECOS JOIN) | bwv_hotline_bevinding |
| bwv_vakantieverhuur -> (SIA / DECOS JOIN) | bwv_medewerkers |
| bwv_vakantieverhuur_annuleren -> (SIA / DECOS JOIN) | import_stadia |
| bwv_hotline_melding -> (SIA) | import_wvs |
| bwv_personen -> (BRK) | |
| bwv_personen_hist -> (BRP/BRK) | |
| bwv_woningen -> (BRK) | |
| import_adres -> (BAG) |
ZAKEN Wonen wordt verder ontwikkeld, waarbij de focus gelegd wordt op de business processen en de eisen die vanuit het gebruikersonderzoek naar boven komen. De eerder genoemde tabellen zullen hier een plek vinden. Ook de verbindingen naar de genoemde APIs zullen gemaakt worden. De afhankelijkheid van BWV zal zo langzaam afgebouwd kunnen worden. TOP en ZAKEN Wonen zullen dan met REST via elkaars (en andere) APIs kunnen verbinden.
Open Zaak heeft vooraal waarde als het gemeentebreed ingezet wordt. Daarom zal het als een service binnen Amsterdam gedraaid moeten worden. Hierdoor kunnen meerdere afdelingen/applicaties er op aansluiten, en kan er informatie uitgewisseld worden tussen die verschillende afdelingen. Ook kan er gebruik gemaakt worden van Open Zaak notificaties, waarbij geabonneerd kan worden op mutaties van de informatie in Open Zaak.
Hierdoor kan ZAKEN Wonen bijvoorbeeld informatie over zaken naar Open Zaak pushen, en abonneren op notificaties van de Wonen catalogus. De koppeling tussen zaken van beide systemen kan gedaan worden via een UUID, een unieke identifier die in beide systemen aan dezelfde zaak gekoppeld kan worden.
Het ontwikkelen van deze synchronisatie heeft alleen zin zodra er genoeg draagvlak is voor Open Zaak, en zodra die als service binnen Amsterdam gedraaid wordt.
De Hitkans module heeft een afhankelijkheid van de BWV database. De bedoeling is dat het CTO team de module als service gaat opzetten, die met een API te bereiken is. De data over zaken die nu uit BWV komt, zal uit de Open Zaak API of ZAKEN Wonen API komen.
Momenteel is de keuze van authenticatieleverancier nog niet duidelijk. Zodra er hier meer over bekend is, kunnen we overstappen naar deze nieuwe provider. Aangezien de huidige Grip authenticatie geïmplementeerd is dit momenteel niet van hoge prioriteit.
peterboer
commented
4 years ago @petercuret tnx. nemen we ff mee sprint 4 in, overleggen we hem ook even met de architecten van de gemeente.
petercuret
commented
4 years ago @peterboer @xavierbloemen conclusies uit de meeting met Johan gisteren:
Een optie is om helemaal geen afhankelijkheid te hebben van de implementatie open-zaken. Dit omdat de afhankelijkheid niet past binnen ons traject van agile development. Indien wij nieuwe functionaliteit nodig hebben moeten we die eerst aanvragen als standaard, waarna deze pas op de open-zaken backlog terecht komt om geïmplementeerd te worden. Vaak betreft het functionaliteit die eerst gevalideerd moet worden door gebruikersonderzoek, en mogelijk weer veel veranderd.
In het geval dat we deze optie kiezen kunnen we er voor zorgen dat onze eigen API's wel zoveel mogelijk aansluiten op de standaarden voor 'Zaakgericht Werken'. Deze worden vastgelegd in de gemma-zaken repository. Hierdoor behouden we het uiteindelijke doel van de standaarden: namelijk dat andere applicaties die ook rond dit ecosysteem gebouwd zijn nog goed aansluiten op onze applicatie. Met deze aanpak moeten we wel goed documenteren wat maatwerk is, en wat onderdeel is van de standaarden.
Verder zou het raadzaam zijn om meer aansluiting te zoeken met de open-zaak/zaakgericht werken community. Bijvoorbeeld door middel van het bijwonen van hun calls/events etc. Hierdoor krijgen we van beide kanten een betere beeld over wat mogelijk en nodig is.
Deliver a drawing that outlines the way we use the different systems and which explains the (loosely) coupled dependency of Open Zaak vs. our application (TOP + Zaken Backend/Front-end). This we can use to explain our set-up to programm architect/datapunt