VisueelWikitekst
 
(10 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
 
<h2>{{#show:{{FULLPAGENAME}}|?SessieType # -}} </h2>Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de <b>technologie</b> die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we <b>hardware, software en hybride infrastructuur</b>. In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele <b>quadruple helix</b>.
 
<h2>{{#show:{{FULLPAGENAME}}|?SessieType # -}} </h2>Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de <b>technologie</b> die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we <b>hardware, software en hybride infrastructuur</b>. In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele <b>quadruple helix</b>.
  
−
De tweede thematische werkgroep vond plaats op 18 april 2024.
+
De tweede thematische werkgroep vond plaats op 23 mei 2024.
  
 
=== Context ===
 
=== Context ===
Regel 13: Regel 13:
  
 
==== VLOCA ====
 
==== VLOCA ====
−
VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. De hulp van VLOCA aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. VLOCA vormt op deze manier een duidelijke brug tussen de beleidsdoelstellingen van het lokale bestuur en de technische laag waarin de oplossingen beschreven en geïmplementeerd worden. We stellen de juiste vragen en verzamelen de noden en behoeften van alle stakeholders (lokale besturen, kenniscentra, bedrijven en burgerorganisaties). Door een gestructureerde aanpak en verwerking van deze informatie wordt de ontwikkeling van herbruikbare bouwblokken, standaarden en normen gestimuleerd die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuur componenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders.
+
VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. Meer informatie over VLOCA en onze werking kan je terugvinden op https://www.vlaanderen.be/lokaal-bestuur/digitale-transformatie/vloca/vloca-trajectbegeleiding-waarom.
  
 
== VLOCA-model ==
 
== VLOCA-model ==
Regel 88: Regel 88:
 
* Valkuilen en principes identificeren
 
* Valkuilen en principes identificeren
 
* Nadenken over verduurzaming ifv de keuze voor een bepaalde databron
 
* Nadenken over verduurzaming ifv de keuze voor een bepaalde databron
 +
In de onderstaande figuur wordt het proces weergegeven dat zich afspeelt binnen het dataplatform:
 +
[[Bestand:MM WG3 visual.jpg|geen|miniatuur]]
  
 
=== Oefening 1 ===
 
=== Oefening 1 ===
Regel 109: Regel 111:
  
 
==== Output ====
 
==== Output ====
 +
{| class="wikitable"style="background-color:#ffffff;font-size:90%"
 +
|-
 +
| Style="background-color:#FFFF00;"|Parameters
 +
|-
 +
|Hoeveelheid (voorspelde) neerslag in grafiek
 +
|-
 +
|Check of alle sensoren nog werken
 +
|-
 +
|Werking sensoren/ status batterij/GPS...
 +
|-
 +
| Style="color:#467886;"|<U>Iets zoals bij waterinfo VMM : https://www.waterinfo.be/Themas#item=overstroming/actueel</U>
 +
|-
 +
|Vullingsgraad van de poel (in kader van technisch onderhoud)
 +
|-
 +
|Zelfs over historische data moeten snelle queries mogelijk zijn
 +
|-
 +
|Performantie Queries
 +
|-
 +
|Alerts moeten op verschillende applicaties/devices mogelijk zijn en configureerbaar wie welke alerts krijgt. Elke stad kan zijn eigen configuratie hierin doen. Scheiding op tenant=stadsniveau? (je kunt niet in de data van een andere stad kunnen zien)
 +
|-
 +
|Scheidingslijnen : data governance => is dit relevant voor modderstromen ?
 +
|-
 +
|Rechtstreekse koppeling naar brondata met dashboardapplicaties zodat eigen dashboards met bijv. PowerBi makkelijk gemaakt kunnen worden en automatisch geupdated worden (read only). Dit wel met al de security vereisten: alleen eigen data kunnen zien, binnen een stad een hierarchie wie wat mag zien.
 +
|-
 +
|vaste dashboard, vs dynamische/self service dashboard, integratie in bestaande lokale dashboard
 +
|-
 +
|Stakeholder : Academici : Inzicht: vul- en ledigingscurves
 +
|-
 +
|Stakeholder : Academici : Inzicht: historische data
 +
|-
 +
|Stakeholder : Academici : Inzicht: makkelijk data kunnen downloaden voor verder onderzoek
 +
|-
 +
|Stakeholder : Academici : Maximale vulpeilen van buffers (of andere %) in grafiek
 +
|-
 +
|Rampcoördinatie: predictie van tijdstip van overlopen (+ aftelklok)
 +
|-
 +
|Rampcoördinatie: op kaart groen/geel/oranje/rood 
 +
|-
 +
| Technische teams : Onderhoud: datum laatste onderhoud (poelen & sensoren)
 +
|-
 +
|Technische teams : Onderhoud: percentage van oorspronkelijke buffercapaciteit die er nog is
 +
|-
 +
|Technische teams : Onderhoud:  bijhouden wie onderhoud heeft uitgevoerd
 +
|-
 +
|Lokale input interface van alle informatie bij het ruimen bvb. (feedback loop)
 +
|-
 +
|Landbouwers goed bij </U><U>betrekken</U>
 +
|-
 +
|Bodemvocht
 +
|-
 +
|Stakeholder
 +
|-
 +
|Jonge vs oudere generaties
 +
|-
 +
|Neerslag gegevens
 +
|-
 +
|Stakeholders: omwonenden goed bij betrekken
 +
|-
 +
|Als landbouwer toegang tot de volgende data: hoeveelheid grond die afgestroomd is, bodemvocht (via de sensoren), hoeveelheid neerslag die gevallen is, ... en dit allemaal overzichtelijk gepresenteerd in de tijd. Ook eventuele alerts (van het vollopen) gaan handig zijn voor hem
 +
|-
 +
|Overzicht van de statussen van de buffers op kaart (gekleurde puntjes bvb)
 +
|-
 +
|Mobiel toegankelijke website
 +
|-
 +
|Bedenking: mogelijkheid aansluiting met andere toepassingen (vb Sirio van sumaque of flood4cast van hyrdroportal) - deze tool moet niet allés zelf kunnen, focus op poelen
 +
|-
 +
|Data space ?
 +
|-
 +
|Dashboard dient te kunnen linken met datalake in de cloud, real time gevoed kunnen worden door IoT standaard technologie om metingen van de sensoren via fabrikant en globale protocollen tot in de omgeving te krijgen die het dashboard kan gebruiken, een service die OSLO compliant data publiceert van dezelfde bron is beter te gebruiken vanaf de service of de store. Dashboard dient geo selecties mogelijk te maken en kan native integreren met MS PowerBI, MS Excel en heeft open API. Parameters moeten niet beperkt zijn in type
 +
|}
  
 
==== Discussie ====
 
==== Discussie ====
 +
 +
# Neerslagdata en Sensoren:
 +
#* Een dashboard moet de hoeveelheid neerslag (verleden, heden, voorspellingen) tonen, met data van bijvoorbeeld het KMI.
 +
#* Er moet een alarmsysteem zijn om te controleren of sensoren nog werken, inclusief batterijstatus en GPS-locatie.
 +
#* Directe koppeling naar brondata is belangrijk, zodat de data eenvoudig te downloaden en te analyseren is, bijvoorbeeld via CSV-bestanden.
 +
# Operationeel Gebruik en Onderhoud:
 +
#* Het dashboard moet operationele rapporten kunnen genereren om de werking van sensoren te bewaken.
 +
#* Onderhoudsinformatie moet bijgehouden worden, inclusief de datum van het laatste onderhoud van zowel de sensoren als de poelen.
 +
#* Er moet een onderscheid zijn tussen dashboards voor operationele inzichten, technisch onderhoud en rampenbestrijding.
 +
# Configuratie en Toegang:
 +
#* Alerts moeten configureerbaar zijn per stad, zodat elke stad eigen instellingen kan beheren.
 +
#* Er moet een duidelijke scheiding zijn tussen data van verschillende steden (multi-tenant omgeving).
 +
#* Landbouwers moeten toegang krijgen tot relevante data (neerslag, bodemvocht, status van de buffers) en eventueel alerts voor overstroomrisico’s.
 +
# Gebruiksgemak en Toegankelijkheid:
 +
#* Het dashboard moet mobiel toegankelijk zijn, zodat gebruikers ter plaatse snel informatie kunnen inzien.
 +
#* Er moet rekening gehouden worden met de mogelijkheid om het dashboard te integreren met andere bestaande systemen en applicaties.
 +
# Predictiemodellen en Visualisatie:
 +
#* Het systeem moet rampcoördinatie ondersteunen door voorspellingen te doen over wanneer buffers zullen overlopen en visueel alarmeren (groen, oranje, rood).
 +
#* Het is belangrijk om visueel overzicht te hebben van de vul- en ledigingsfrequentie van de buffers, inclusief een aftelklok voor voorspelde overstromingen.
 +
# Data Governance en Technische Overwegingen:
 +
#* Er moet een flexibele data-architectuur zijn waarin data uit verschillende bronnen real-time kan worden geïntegreerd en geanalyseerd.
 +
#* De data moet Oslo-compliant worden gepubliceerd waar mogelijk, maar de ruwe data moet ook behouden blijven voor flexibiliteit en toekomstige integraties.
 +
# Samenwerking en Feedback:
 +
#* Het systeem moet het mogelijk maken om feedback van technische teams direct in te voeren, zodat onderhoud en andere acties goed gedocumenteerd worden.
 +
#* Academici en andere geïnteresseerden moeten ook toegang hebben tot de data voor verder onderzoek en inzicht.
  
 
=== Oefening 2 ===
 
=== Oefening 2 ===
Regel 122: Regel 219:
  
 
==== Output ====
 
==== Output ====
 +
 +
{| class="wikitable"style="background-color:#ffffff;font-size:90%"
 +
|-
 +
| Style="background-color:#FFFF00;"|Notificaties, communicatie en procesflow
 +
|-
 +
|Eerste melding: 75% vulling en neerslag voorspeld
 +
|-
 +
|Melding als poel overstort
 +
|-
 +
|Melding als poel aan schoonmaak toe is
 +
|-
 +
|Afhankelijk van voorspelde impact - voorbeeld poel in buurt van veel kritische infrastructuur 
 +
|-
 +
|- niet alleen burgemeester, maar ook noodplanambtenaar (via mail, whatsapp)
 +
|-
 +
|Een opt-in voor verschillende soorten meldingen (inschrijven wie wil)
 +
|-
 +
|GDPR
 +
|-
 +
|Status van afhandeling van alerts. Als er actie moet ondernomen worden, moet er kunnen aangeduid worden dat het ontvangen is en in verwerking door die persoon of dat team. Dus alerts leven ook op een desk waar status aanpassingen, comments en doorverwijzingen mogelijk zijn.
 +
|-
 +
|Burgemeester
 +
|-
 +
|Brandweer
 +
|-
 +
|De Lijn (als er bus passeert)
 +
|-
 +
|Omwonenden
 +
|-
 +
|Riool-beheerder
 +
|-
 +
|Valkuil: hoe spamming/te veel aan berichtjes vermijden.
 +
|-
 +
|bvb "be alert"
 +
|-
 +
|Proces ?
 +
|-
 +
|bvb "bin" (buurt informatie netwerken) via de politie
 +
|-
 +
|Ramp- coördinator
 +
|-
 +
|Technische dienst
 +
|-
 +
|Politie
 +
|-
 +
|Provincie
 +
|-
 +
|Ploeg van wacht als eerste contact bvb ?
 +
|-
 +
| Style="color:#467886;"|<U>Zou hiervoor standaard technologie gebruiken zodat je ontwikkeling en onderhoud minimaliseert. Je hoeft dan enkel configuratie te doen en je kan zowel emails, SMS, ... sturen als ook pompen aansturen of andere acties automatiseren. Bijvoorbeeld GeoEvent Server </U>
 +
|-
 +
|Alert voor stroomafwaarts liggende buurtbewoners indien kans op overlopen poel (en indien relevant natuurlijk)
 +
|-
 +
|Koppeling met BE-Alert
 +
|-
 +
|Afhankelijk van urgentie een ander kanaal. Niets is zo storend/ineffectief als een kanaal met overbodige alerts waar geen acties aan gekoppeld moeten worden.
 +
|-
 +
|Hoogdringend: gsm
 +
|-
 +
|Belangrijk maar geen onmiddellijke actie: email
 +
|-
 +
|Om in de achtergrond in de gaten te houden: dashboard specifiek voor monitoring
 +
|-
 +
|proces uittekenen wie krijgt wat wanneer en hoe (welke kanaal)?
 +
|-
 +
|Opsplitsing wie men op de hoogte brengt  in functie van evolutie  situatie metingen in poel.
 +
|}
  
 
==== Discussie ====
 
==== Discussie ====
 +
 +
# Proactieve Meldingen:
 +
#* Het systeem moet niet alleen reactief zijn maar ook proactief meldingen sturen bij gevaren, zoals modderstromen.
 +
#* Burgemeester en andere relevante personen moeten notificaties ontvangen via WhatsApp of SMS.
 +
# Contactinformatie en GDPR:
 +
#* Bepaal wie wanneer gecontacteerd moet worden.
 +
#* Overweeg hoe contactinformatie wordt bijgehouden en voldoe aan GDPR-regelgeving.
 +
# Meldingscriteria:
 +
#* Meldingen moeten gestuurd worden bij overschrijding van bepaalde drempelwaarden (bijvoorbeeld hoeveelheid neerslag).
 +
#* Verschillende soorten meldingen vereisen specifieke responsen, zoals schoonmaak van een overstortende poel.
 +
# Betrokkenen en Communicatiekanalen:
 +
#* Naast de burgemeester moeten ook noodplanningsambtenaren via mail of WhatsApp op de hoogte worden gesteld.
 +
#* Betrokkenen kunnen onder andere de technische dienst, brandweer, politie, en omwonenden zijn.
 +
#* Gebruik van bestaande systemen zoals BE-Alert en buurtinformatienetwerken.
 +
# Overdaad aan Informatie Vermijden:
 +
#* Voorkom dat er te veel informatie wordt gestuurd naar betrokkenen, wat kan leiden tot informatie-overload.
 +
#* Zorg voor duidelijke afspraken over wie wanneer verantwoordelijk is voor welke acties.
 +
# Opvolging en Statusbeheer:
 +
#* Het systeem moet de status van meldingen kunnen bijhouden (ontvangen, in verwerking, etc.).
 +
#* Gebruik een dashboard voor statusaanpassing, opmerkingen en doorverwijzingen.
 +
# Procesuitwerking:
 +
#* Werk een duidelijk proces uit voor wie wanneer welke melding ontvangt via welk kanaal (GSM voor dringende zaken, e-mail voor minder dringende zaken, dashboard voor monitoring).
 +
# Gebruik van Bestaande Technologie:
 +
#* Gebruik bestaande technologieën en platforms om meldingen te versturen en acties te automatiseren.
 +
#* Zorg voor koppelingen met databanken voor contactinformatie (bijv. burgemeesters) om configuratie te vergemakkelijken.
  
 
=== Oefening 3 ===
 
=== Oefening 3 ===
Regel 137: Regel 326:
  
 
==== Output ====
 
==== Output ====
 +
{| class="wikitable"style="background-color:#ffffff;font-size:90%"
 +
|-
 +
| Style="background-color:#FFFF00;"|Databeheer en gebruik
 +
|-
 +
|Bestaande IoT platformen
 +
|-
 +
|Zelf een dataplatform bouwen is overkill. Er zijn voldoende bestaande dataplatformen waar oa integratie met sensoren al aanwezig is alsook de storage koppelingen en de ontsluiting naar dashboards, LDES-server, etc...
 +
|-
 +
|opkuisen/validatie van de data is belangrijk (zowel door iemand met technische achtergrond in sensoren als lokale terreinkennis)
 +
|-
 +
|data altijd bijhouden (belangrijk academisch maar ook om te leren uit operationeel beheer)
 +
|-
 +
|Bestaande real time batch processing tools? 
 +
|-
 +
|<U>gevalideerde </U>data mee ontsluiten via bestaande platformen ? bv waterinfo waar info over GOG's staat  ? DOV met info over erosiepoelen en sedimentvangen, .... ? Zo kan je onderscheid maken tussen een operationaal platform dat real-time wordt gebruikt en archief met gevalideerde metingen via andere platform
 +
|-
 +
|Databeheer moet door één partij gebeuren dewelke enkel de relevante behoudt die voor toekomstige simulaties/gebeurtenissen bruikbaar zijn (goede data governance afspraken)
 +
|-
 +
|Kosten vs snelheid vs volume
 +
|-
 +
|Data verwijderen is niet nodig. Blobstorage is goedkoop. Enkel mss een strategie over snel toegankelijke data en historische offloading naar blob storage voor minder snel toegankelijke data
 +
|-
 +
|<U>operationeel </U>: realtime (snelheid belangrijk)
 +
|-
 +
|<U>inzichten</U> : belangrijk dat de data gevalideerd is (om zo tijdsreeksen te kunnen opmaken bvb)
 +
|-
 +
|Ruwe data van sensoren is wss onbruikbaar voor ambtenaar, meer nood aan al licht verwerkte en leesbare data. Bijv. al de sensoren die waterstand meten naar 1 datamodel mappen -> deze data beschikbaar stellen aan ambtenaar (aggregatie van de data, of standaardmodel, leesbare KPIs)
 +
|-
 +
|Bestaande scalable
 +
|-
 +
|Cloud gebaseerde data storage oplossingen? ? 
 +
|-
 +
|De meest relevante en éénduidige data bijhouden, zoals KMI bvb doet. => bundelen in front office
 +
|-
 +
|Gert Verstraeten
 +
|-
 +
|context data en metadata (bvb locatie)
 +
|-
 +
|modderpoel met zijn eigen 'id' krijgen die met de sensoren data meegestuurd worden
 +
|-
 +
|datastandaarden - afspraken, bijvoorbeeld tijdsnotatie, Mogelijkheid aanduiden kwaliteit van data (in plaats van gewoon verwijderen), 
 +
|-
 +
|niet gemakkelijk om door de techniekers te laten aanpassen
 +
|-
 +
|Historische semi-ruwe data (na een eerste verwerking naar standaard model)  is belangrijk voor AI dus mag niet gedelete worden.
 +
|-
 +
|Erosiepoelen zijn in de DOV gestockeerd (of alvast zeer veel)
 +
|-
 +
|GIS platformen gebruiken voor spatiale analyse , integratie met spatiale databases
 +
|-
 +
|Termen als Datawarehouses and Datalakes worden vernoemd. Ook Lakehouse bekijken? (best of breed ?) 
 +
|-
 +
|Denken dat een 'platform' een oplossing is. Kwestie van semantiek misschien eerder 'Data componenten oplossing'? 
 +
|}
 +
 +
{| class="wikitable"style="background-color:#ffffff;font-size:90%"
 +
|-
 +
| Style="background-color:#FFFF00;"|Functieprofielen/rollen
 +
|-
 +
|Data eigenaar
 +
|-
 +
|Data engineer
 +
|-
 +
|Data analist
 +
|-
 +
|Data scientist
 +
|-
 +
|Dashboard/ visualisatie expert
 +
|-
 +
|tegen hackers die alarmen uisturen of pompen laten starten
 +
|-
 +
|Cybersecurity expert
 +
|-
 +
|Dataplatform beheerder
 +
|-
 +
|DPO (enkel voor GDPR data natuurlijk)
 +
|-
 +
|Toegangs- en rollen-beheerder
 +
|-
 +
|Financieel verantwoordelijke
 +
|-
 +
|Technische architect
 +
|-
 +
|Product Owner, Implementatie ProjectManager, Data Scientist, 
 +
|-
 +
|Datamodel expert
 +
|-
 +
|Data strategist ?
 +
|}
  
 
==== Discussie ====
 
==== Discussie ====
 +
 +
# Data management: De discussie concentreerde zich op het belang van data management, inclusief data input, beheer, verwerking, en ontsluiting.
 +
# Data governance: De verantwoordelijkheid voor data, inclusief de vraag wie de eigenaar is, en het belang van goede data governance-afspraken.
 +
# Dataopslag en -beheer: Er werd gesproken over het bijhouden van historische data, het beheren van verschillende soorten data, en het gebruik van blob storage voor minder snel toegankelijke data.
 +
# Dataplatformen: Discussies omvatten het overwegen van bestaande dataplatformen versus het bouwen van een eigen platform, integratie met andere platforms, en de functionele en technische vereisten van een dataplatform.
 +
# Rollen en verantwoordelijkheden: Verschillende rollen werden besproken, waaronder data engineers, data scientists, data-analisten, en de rollen van een DPO (Data Protection Officer) en financieel verantwoordelijke.
 +
# Technische aspecten: De technische architectuur van het dataplatform, inclusief data warehouses, data lakes, en het concept van een 'lakehouse', werd behandeld.
  
 
=== Oefening 4 ===
 
=== Oefening 4 ===
Regel 156: Regel 441:
  
 
==== Output ====
 
==== Output ====
 +
{| class="wikitable"style="background-color:#ffffff;font-size:90%"
 +
|-
 +
| Style="background-color:#FFFF00;"|Valkuilen
 +
| Style="background-color:#FFFF00;"|Principes
 +
|-
 +
|Geen spaghetti integraties
 +
|
 +
|-
 +
|Goede afspraken duurzame databeheer (verantwoordelijkheid)
 +
|
 +
|-
 +
|teveel informatie die niet meteen begrijpbaar zijn voor de gebruiker: goede selectie maken van wat relevant is om te tonen aan elk doelpubliek + goede metadata beschrijving. 
 +
|
 +
|-
 +
|Zorg voor opleiding van eindgebruikers
 +
|
 +
|-
 +
|onderhoud van het materiaal - te lange periodes met 'no data' of met onrealistische data wegens problemen met de sensoren kunnen vertrouwen ondermijnen 
 +
|goede opvolging noodzakelijk - feedback van lokale terreinbeheerders cruciaal - niet louter een data/IT project
 +
|-
 +
| Colspan="2"|Niet opvolgen kosten/baten lange termijn. TCO zicht. Ook kijken naar waar kan waarde gegenereerd worden, en welke schadekosten zijn vermeden. Bijvoorbeeld zeggen we dat goede grond wegspoelt, nu vangen we die (deels) op maar wat doen we ermee? 
 +
|-
 +
| Colspan="2"|Afhankelijkheid van schaarse technische profielen op de markt 
 +
|-
 +
|
 +
|Inkomende data op platform moet een eerste validatie krijgen,zodat fouten al in begin van de pipeline opgemerkt worden  - Data quality checks : eerste lijn... 
 +
|-
 +
|
 +
|Mogelijke principe: reeds ontwikkelde bouwstenen hergebruiken+ configuratie off the shelf functionaliteit bestaande technologiën, low code no code configuratie (reeds zelf  ontwikkeld-bestaande + technologiën,), configueren  en developen  enkel als 'bijkomende' capability
 +
|-
 +
|
 +
|Budgetten ifv retour hele systeem. Als door monitoring grote schade kan worden voorkomen dan zullen de budgetten te verantwoorden zijn.
 +
|-
 +
|
 +
|Dashboards kunnen een tree hebben, dus van overzicht naar detail via enkele klikken. (drill downs, slice/dice) 
 +
|-
 +
|Na kantooruren geen service van dataplatform 
 +
|helpdesk 24/7 ? 
 +
|}
  
 
==== Discussie ====
 
==== Discussie ====
  
−
=== Oefening 5 ===
+
# Complexiteit van Dashboards: Te veel informatie op dashboards kan leiden tot verwarring en gebrek aan overzicht, waardoor gebruikers de gegevens niet goed begrijpen.
−
 
+
# Verantwoordelijkheid van Data: Juridische aspecten rondom verantwoordelijkheid voor data in het geval van problemen moeten duidelijk zijn om mogelijke problemen te voorkomen.
−
==== Instructies ====
+
# Budgetten en Leveranciersafhankelijkheid: Het beheer van budgetten en de afhankelijkheid van externe leveranciers zijn cruciale factoren die het succes van het project kunnen beïnvloeden.
−
Hoe kunnen we de oplossing verduurzamen?
+
# Datakwaliteit en Validatie: Het belang van datakwaliteit en het instellen van datavalidatieprocessen om fouten in de gegevens te voorkomen.
−
 
+
# Gebruikersacceptatie en Change Management: Het anticiperen op weerstand tegen verandering en het implementeren van effectief change management om ervoor te zorgen dat gebruikers het nieuwe systeem omarmen.
−
-Hoe houden we het budget onder controle?
+
# Technische Capaciteiten en Talent: De beschikbaarheid van technisch talent en de afhankelijkheid van schaarse technische profielen op de markt kunnen uitdagingen vormen voor het project.
−
 
+
# Duurzaamheid en Onderhoud: Het plannen van duurzame databeheerpraktijken en het garanderen van continuïteit en onderhoud van het systeem, inclusief het opzetten van serviceovereenkomsten en een helpdesk.
−
-Wat met ‘coverage’? Hoeveel sensoren heb ik nodig om een representatief beeld te krijgen? Is dit haalbaar en beheersbaar?
 
−
 
 
−
-Uitbesteden vs zelf data capteren
 
−
 
 
−
-Uitrol project in grotere regio
 
−
 
 
−
-Hoe bouwen we een business model op hiermee?
 
−
 
 
−
-Schaalbaarheid, rol van provincie, Vlaanderen. Wie heeft/beheerd zo’n platform?
 
−
 
 
−
==== Output ====
 
−
 
 
−
==== Discussie ====
 
  
 
==Opname en Miro bord==
 
==Opname en Miro bord==
  
 
=== Miro bord ===
 
=== Miro bord ===
−
Het Miro bord kan je consulteren via [https://miro.com/app/board/uXjVKT07vN8=/ deze link].  
+
Het Miro bord kan je consulteren via [https://miro.com/app/board/uXjVKGCe4NM=/ deze link].  
  
 
=== Opname ===
 
=== Opname ===
−
De opname van deze sessie is te bekijken via [https://www.youtube.com/watch?v=H53PO5FmqNA&ab_channel=PortaalVloca deze link].
+
De opname van deze sessie is te bekijken via [https://www.youtube.com/watch?v=KutaCxGU9Kg&ab_channel=PortaalVloca deze link].
  
−
{{Video|Url=https://www.youtube.com/embed/H53PO5FmqNA?si=gdmc9EzLONfehGlt""}}
+
{{Video|Url=https://www.youtube.com/embed/KutaCxGU9Kg?si=-Ro2Iea5wB5EDJb_""}}
  
 
==Volgende stappen==
 
==Volgende stappen==
 
Wat na deze werkgroep?
 
Wat na deze werkgroep?
 
#Verwerking van de input van de brainstorm oefening.
 
#Verwerking van de input van de brainstorm oefening.
−
#Verder onderzoek en voorbereiding van de volgende thematische werkgroep.
+
#Verder onderzoek en voorbereiding van de analyse.
−
#Publicatie op de Kennishub
+
#Publicatie op de Kennishub.
 
Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be<h2>Andere werkgroepen</h2>{{OverzichtWorkshops}}
 
Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be<h2>Andere werkgroepen</h2>{{OverzichtWorkshops}}

Huidige versie van 20 dec 2024 om 11:38

Technologie werkgroep

Deze thematische werkgroep richt zich op het identificeren en in kaart brengen van de technologie die nodig is om het traject technisch werkbaar te maken. Onder technologie verstaan we hardware, software en hybride infrastructuur. In deze werkgroep kijken we samen welke bouwstenen nodig zijn om tot de oplossing(en) te komen voor de use cases die tijdens de vorige werkgroepen werden gedefinieerd. De Werkgroep staat open voor deelname door de gehele quadruple helix.

De tweede thematische werkgroep vond plaats op 23 mei 2024.

Context

Initiatief

VERA werkt samen met verschillende lokale besturen en de provincie Vlaams-Brabant om het probleem van modderstromen als gevolg van bodemerosie aan te pakken. Meer dan 100 gemeenten in Vlaanderen ondervinden bodemerosie, wat aanzienlijke schade kan veroorzaken aan zowel private eigendommen als publieke infrastructuur. Door klimaatverandering, trends in de landbouw en verharding zal dit probleem naar verwachting in de toekomst verder versterkt worden. Op dit moment worden erosiepoelen gebruikt als oplossing. Deze poelen worden onderaan de helling aangelegd om modderstromen op te vangen en te voorkomen dat ze schade veroorzaken. Deze erosiepoelen zijn uitgerust met sensoren en overlopen, waardoor het water op een gecontroleerde en langzame manier kan wegstromen. De vraag die zich stelt, is of deze erosiepoelen effectief zijn. Er bestaat onzekerheid over hun capaciteit en functionaliteit, vooral in noodsituaties. Het is essentieel om dit op een kostenefficiënte manier te monitoren, met als doel zowel acute waarschuwingen bij rampen als proactieve oplossingen voor het probleem. Er wordt nagedacht over het gebruik van peilmeters of debietsensoren om de erosiepoelen te monitoren. Hiermee kan worden bijgehouden hoeveel water door de overlopen gaat. Hoewel dit geen exacte voorspellingen oplevert, biedt het wel inzicht in de hoeveelheid neerslag.

Het overkoepelende doel van het project is om een gecentraliseerd dataplatform op te zetten en een raamcontract te ontwikkelen voor de sensoren. De verzamelde data kunnen gedeeld worden met rioolbeheerders, landbouwers en verzekeringsmaatschappijen, omdat deze informatie waardevol kan zijn voor alle betrokken partijen.

VLOCA

VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid. Meer informatie over VLOCA en onze werking kan je terugvinden op https://www.vlaanderen.be/lokaal-bestuur/digitale-transformatie/vloca/vloca-trajectbegeleiding-waarom.

VLOCA-model

De start van elk VLOCA-traject begint bij een VLOCA-model:

ID Samenvatting Beschrijving
UC1 UC1: Sensoren Verschillende actoren willen verschillende types sensoren kunnen plaatsen en beheren (bv. onderhoudsplan).
UC2 UC2: Data Captatie Ik wil als gebruiker alle informatie correct binnenkrijgen (context, data, goede transmissie)
UC3 UC3: Dataplatform Ik wil als gebruiker een visualisatie zien van alle data zodat ik deze kan analyseren.Ik wil als gebruiker data kunnen toevoegen, aanpassen, delen en opslaan.
UC4 UC4: Dashboarding Ik wil als gebruiker een dashboard kunnen hanteren met KPI's (bv kleurencodes) die ik zelf kan beheren in functie van de data.
UC5 UC5: Message Center Ik wil als gebruiker via mijn tool contacten kunnen aanspreken, toevoegen, wijzigen en behandelen (messaging systeem).
UC6 UC6: Predictie Op basis van de verworven data wil ik modellen kunnen gebruiken om predicties uit te voeren zodat er tactisch advies gegeven kan worden.
UC7 UC7: Mitigatie Op basis van real time data en advies wil ik als lokaal bestuur kunnen reageren om de schade te minimaliseren (crisis management).
UC8 UC8: Preventie Als lokaal bestuur wil ik een overzicht krijgen van adviezen, acties en aanbevelingen om modderstromen te vermijden.
UC9 UC9: Advies Op basis van data van modderstromen wil ik dit kunnen analyseren, correlaties zien en advies verlenen.
UC10 UC10: Marktplaats ik wil als gebruiker data en datasciencemodellen kunnen aanbieden en verkrijgen.
UC11 UC11: ROI Business Modelling
UC12 UC12: Helpdesk Helpdesk - FAQ - Reviews

Tijdens deze werkgroep staan we stil bij use cases 2-5.

In de onderstaande figuur zie je een visuele voorstelling van dit VLOCA-model:

VLOCA-model MM visual.jpg

Brainstormsessie

Het doel en de aanpak van de brainstormsessie worden hieronder beschreven. Tevens wordt de uitkomst van de brainstorm hierin samengevat.

Doel

Het doel van de brainstormsessie is het volgende:

  • Zicht krijgen op de wensen mbt het dashboard
  • Zicht krijgen op de wensen mbt het message center
  • Inzicht krijgen in het data management
  • Valkuilen en principes identificeren
  • Nadenken over verduurzaming ifv de keuze voor een bepaalde databron

In de onderstaande figuur wordt het proces weergegeven dat zich afspeelt binnen het dataplatform:

MM WG3 visual.jpg

Oefening 1

Instructies

Bij deze oefeningen stonden we stil bij de volgende vragen:

Welke soort dashboards zijn interessant voor de verschillende doelgroepen? Welke parameters wil je kunnen monitoren? Hoe wil je dat je data gevisualiseerd wordt? Welke inzichten wil je krijgen? Wie heeft toegang tot het dashboard? Wie heeft welke rechten om wat te kunnen?

Voorbeeld:

-Als rampen coördinator wil ik toegang tot het regionaal dashboard

-Ik wil de waterstand van een bepaalde stroom kunnen zien

-Een rapport trekken over temperatuur

-Een visualisatie over luchtvochtigheid over een bepaalde periode

-Ik wil een melding zien wanneer een bepaalde waarde overschreden is

Output

Parameters
Hoeveelheid (voorspelde) neerslag in grafiek
Check of alle sensoren nog werken
Werking sensoren/ status batterij/GPS...
Iets zoals bij waterinfo VMM : https://www.waterinfo.be/Themas#item=overstroming/actueel
Vullingsgraad van de poel (in kader van technisch onderhoud)
Zelfs over historische data moeten snelle queries mogelijk zijn
Performantie Queries
Alerts moeten op verschillende applicaties/devices mogelijk zijn en configureerbaar wie welke alerts krijgt. Elke stad kan zijn eigen configuratie hierin doen. Scheiding op tenant=stadsniveau? (je kunt niet in de data van een andere stad kunnen zien)
Scheidingslijnen : data governance => is dit relevant voor modderstromen ?
Rechtstreekse koppeling naar brondata met dashboardapplicaties zodat eigen dashboards met bijv. PowerBi makkelijk gemaakt kunnen worden en automatisch geupdated worden (read only). Dit wel met al de security vereisten: alleen eigen data kunnen zien, binnen een stad een hierarchie wie wat mag zien.
vaste dashboard, vs dynamische/self service dashboard, integratie in bestaande lokale dashboard
Stakeholder : Academici : Inzicht: vul- en ledigingscurves
Stakeholder : Academici : Inzicht: historische data
Stakeholder : Academici : Inzicht: makkelijk data kunnen downloaden voor verder onderzoek
Stakeholder : Academici : Maximale vulpeilen van buffers (of andere %) in grafiek
Rampcoördinatie: predictie van tijdstip van overlopen (+ aftelklok)
Rampcoördinatie: op kaart groen/geel/oranje/rood 
Technische teams : Onderhoud: datum laatste onderhoud (poelen & sensoren)
Technische teams : Onderhoud: percentage van oorspronkelijke buffercapaciteit die er nog is
Technische teams : Onderhoud:  bijhouden wie onderhoud heeft uitgevoerd
Lokale input interface van alle informatie bij het ruimen bvb. (feedback loop)
Landbouwers goed bij betrekken
Bodemvocht
Stakeholder
Jonge vs oudere generaties
Neerslag gegevens
Stakeholders: omwonenden goed bij betrekken
Als landbouwer toegang tot de volgende data: hoeveelheid grond die afgestroomd is, bodemvocht (via de sensoren), hoeveelheid neerslag die gevallen is, ... en dit allemaal overzichtelijk gepresenteerd in de tijd. Ook eventuele alerts (van het vollopen) gaan handig zijn voor hem
Overzicht van de statussen van de buffers op kaart (gekleurde puntjes bvb)
Mobiel toegankelijke website
Bedenking: mogelijkheid aansluiting met andere toepassingen (vb Sirio van sumaque of flood4cast van hyrdroportal) - deze tool moet niet allés zelf kunnen, focus op poelen
Data space ?
Dashboard dient te kunnen linken met datalake in de cloud, real time gevoed kunnen worden door IoT standaard technologie om metingen van de sensoren via fabrikant en globale protocollen tot in de omgeving te krijgen die het dashboard kan gebruiken, een service die OSLO compliant data publiceert van dezelfde bron is beter te gebruiken vanaf de service of de store. Dashboard dient geo selecties mogelijk te maken en kan native integreren met MS PowerBI, MS Excel en heeft open API. Parameters moeten niet beperkt zijn in type

Discussie

  1. Neerslagdata en Sensoren:
    • Een dashboard moet de hoeveelheid neerslag (verleden, heden, voorspellingen) tonen, met data van bijvoorbeeld het KMI.
    • Er moet een alarmsysteem zijn om te controleren of sensoren nog werken, inclusief batterijstatus en GPS-locatie.
    • Directe koppeling naar brondata is belangrijk, zodat de data eenvoudig te downloaden en te analyseren is, bijvoorbeeld via CSV-bestanden.
  2. Operationeel Gebruik en Onderhoud:
    • Het dashboard moet operationele rapporten kunnen genereren om de werking van sensoren te bewaken.
    • Onderhoudsinformatie moet bijgehouden worden, inclusief de datum van het laatste onderhoud van zowel de sensoren als de poelen.
    • Er moet een onderscheid zijn tussen dashboards voor operationele inzichten, technisch onderhoud en rampenbestrijding.
  3. Configuratie en Toegang:
    • Alerts moeten configureerbaar zijn per stad, zodat elke stad eigen instellingen kan beheren.
    • Er moet een duidelijke scheiding zijn tussen data van verschillende steden (multi-tenant omgeving).
    • Landbouwers moeten toegang krijgen tot relevante data (neerslag, bodemvocht, status van de buffers) en eventueel alerts voor overstroomrisico’s.
  4. Gebruiksgemak en Toegankelijkheid:
    • Het dashboard moet mobiel toegankelijk zijn, zodat gebruikers ter plaatse snel informatie kunnen inzien.
    • Er moet rekening gehouden worden met de mogelijkheid om het dashboard te integreren met andere bestaande systemen en applicaties.
  5. Predictiemodellen en Visualisatie:
    • Het systeem moet rampcoördinatie ondersteunen door voorspellingen te doen over wanneer buffers zullen overlopen en visueel alarmeren (groen, oranje, rood).
    • Het is belangrijk om visueel overzicht te hebben van de vul- en ledigingsfrequentie van de buffers, inclusief een aftelklok voor voorspelde overstromingen.
  6. Data Governance en Technische Overwegingen:
    • Er moet een flexibele data-architectuur zijn waarin data uit verschillende bronnen real-time kan worden geïntegreerd en geanalyseerd.
    • De data moet Oslo-compliant worden gepubliceerd waar mogelijk, maar de ruwe data moet ook behouden blijven voor flexibiliteit en toekomstige integraties.
  7. Samenwerking en Feedback:
    • Het systeem moet het mogelijk maken om feedback van technische teams direct in te voeren, zodat onderhoud en andere acties goed gedocumenteerd worden.
    • Academici en andere geïnteresseerden moeten ook toegang hebben tot de data voor verder onderzoek en inzicht.

Oefening 2

Instructies

Wie wanneer contacteren? Welke type van communicatie gaan we hebben met de gebruikers en in welke scenario? Hoe verzamel je de contactpersonen? Hoe kan je een goede opvolging implementeren?

Voorbeeld:

·Contact persoon x moet gecontacteerd worden in geval een erosiepoel is overstroomd om efficiënte en snelle ontruiming te voorzien?

Output

Notificaties, communicatie en procesflow
Eerste melding: 75% vulling en neerslag voorspeld
Melding als poel overstort
Melding als poel aan schoonmaak toe is
Afhankelijk van voorspelde impact - voorbeeld poel in buurt van veel kritische infrastructuur 
Een opt-in voor verschillende soorten meldingen (inschrijven wie wil)
GDPR
Status van afhandeling van alerts. Als er actie moet ondernomen worden, moet er kunnen aangeduid worden dat het ontvangen is en in verwerking door die persoon of dat team. Dus alerts leven ook op een desk waar status aanpassingen, comments en doorverwijzingen mogelijk zijn.
Burgemeester
Brandweer
De Lijn (als er bus passeert)
Omwonenden
Riool-beheerder
Valkuil: hoe spamming/te veel aan berichtjes vermijden.
bvb "be alert"
Proces ?
bvb "bin" (buurt informatie netwerken) via de politie
Ramp- coördinator
Technische dienst
Politie
Provincie
Ploeg van wacht als eerste contact bvb ?
Zou hiervoor standaard technologie gebruiken zodat je ontwikkeling en onderhoud minimaliseert. Je hoeft dan enkel configuratie te doen en je kan zowel emails, SMS, ... sturen als ook pompen aansturen of andere acties automatiseren. Bijvoorbeeld GeoEvent Server
Alert voor stroomafwaarts liggende buurtbewoners indien kans op overlopen poel (en indien relevant natuurlijk)
Koppeling met BE-Alert
Afhankelijk van urgentie een ander kanaal. Niets is zo storend/ineffectief als een kanaal met overbodige alerts waar geen acties aan gekoppeld moeten worden.
Hoogdringend: gsm
Belangrijk maar geen onmiddellijke actie: email
Om in de achtergrond in de gaten te houden: dashboard specifiek voor monitoring
proces uittekenen wie krijgt wat wanneer en hoe (welke kanaal)?
Opsplitsing wie men op de hoogte brengt  in functie van evolutie  situatie metingen in poel.

Discussie

  1. Proactieve Meldingen:
    • Het systeem moet niet alleen reactief zijn maar ook proactief meldingen sturen bij gevaren, zoals modderstromen.
    • Burgemeester en andere relevante personen moeten notificaties ontvangen via WhatsApp of SMS.
  2. Contactinformatie en GDPR:
    • Bepaal wie wanneer gecontacteerd moet worden.
    • Overweeg hoe contactinformatie wordt bijgehouden en voldoe aan GDPR-regelgeving.
  3. Meldingscriteria:
    • Meldingen moeten gestuurd worden bij overschrijding van bepaalde drempelwaarden (bijvoorbeeld hoeveelheid neerslag).
    • Verschillende soorten meldingen vereisen specifieke responsen, zoals schoonmaak van een overstortende poel.
  4. Betrokkenen en Communicatiekanalen:
    • Naast de burgemeester moeten ook noodplanningsambtenaren via mail of WhatsApp op de hoogte worden gesteld.
    • Betrokkenen kunnen onder andere de technische dienst, brandweer, politie, en omwonenden zijn.
    • Gebruik van bestaande systemen zoals BE-Alert en buurtinformatienetwerken.
  5. Overdaad aan Informatie Vermijden:
    • Voorkom dat er te veel informatie wordt gestuurd naar betrokkenen, wat kan leiden tot informatie-overload.
    • Zorg voor duidelijke afspraken over wie wanneer verantwoordelijk is voor welke acties.
  6. Opvolging en Statusbeheer:
    • Het systeem moet de status van meldingen kunnen bijhouden (ontvangen, in verwerking, etc.).
    • Gebruik een dashboard voor statusaanpassing, opmerkingen en doorverwijzingen.
  7. Procesuitwerking:
    • Werk een duidelijk proces uit voor wie wanneer welke melding ontvangt via welk kanaal (GSM voor dringende zaken, e-mail voor minder dringende zaken, dashboard voor monitoring).
  8. Gebruik van Bestaande Technologie:
    • Gebruik bestaande technologieën en platforms om meldingen te versturen en acties te automatiseren.
    • Zorg voor koppelingen met databanken voor contactinformatie (bijv. burgemeesters) om configuratie te vergemakkelijken.

Oefening 3

Instructies

Hoe ga je data beheren/gebruiken eens dat je deze gecapteerd hebt via de verschillende databronnen? Hoe lang wil je de data bijhouden? Hoe vaak moet de data verzameld worden (frequentie)? Wie neemt de verantwoordelijkheid voor data? Hoe er voor zorgen dat data juist geïnterpreteerd wordt? Welke profielen/rollen zullen met de data werken? Hoe zorgen we voor continuïteit bij ingebruikname van bvb nieuwe sensoren?

Voorbeeld:

-De milieu ambtenaar die voorheen geen data had, wilt nu kunnen inloggen op het dashboard om de ruwe data te downloaden voor analyses te kunnen doen

-Je hebt een data ingenieur nodig van data captatie tot ontsluiten van de data

Output

Databeheer en gebruik
Bestaande IoT platformen
Zelf een dataplatform bouwen is overkill. Er zijn voldoende bestaande dataplatformen waar oa integratie met sensoren al aanwezig is alsook de storage koppelingen en de ontsluiting naar dashboards, LDES-server, etc...
opkuisen/validatie van de data is belangrijk (zowel door iemand met technische achtergrond in sensoren als lokale terreinkennis)
data altijd bijhouden (belangrijk academisch maar ook om te leren uit operationeel beheer)
Bestaande real time batch processing tools? 
gevalideerde data mee ontsluiten via bestaande platformen ? bv waterinfo waar info over GOG's staat  ? DOV met info over erosiepoelen en sedimentvangen, .... ? Zo kan je onderscheid maken tussen een operationaal platform dat real-time wordt gebruikt en archief met gevalideerde metingen via andere platform
Databeheer moet door één partij gebeuren dewelke enkel de relevante behoudt die voor toekomstige simulaties/gebeurtenissen bruikbaar zijn (goede data governance afspraken)
Kosten vs snelheid vs volume
Data verwijderen is niet nodig. Blobstorage is goedkoop. Enkel mss een strategie over snel toegankelijke data en historische offloading naar blob storage voor minder snel toegankelijke data
operationeel : realtime (snelheid belangrijk)
inzichten : belangrijk dat de data gevalideerd is (om zo tijdsreeksen te kunnen opmaken bvb)
Ruwe data van sensoren is wss onbruikbaar voor ambtenaar, meer nood aan al licht verwerkte en leesbare data. Bijv. al de sensoren die waterstand meten naar 1 datamodel mappen -> deze data beschikbaar stellen aan ambtenaar (aggregatie van de data, of standaardmodel, leesbare KPIs)
Bestaande scalable
Cloud gebaseerde data storage oplossingen? ? 
De meest relevante en éénduidige data bijhouden, zoals KMI bvb doet. => bundelen in front office
Gert Verstraeten
context data en metadata (bvb locatie)
modderpoel met zijn eigen 'id' krijgen die met de sensoren data meegestuurd worden
datastandaarden - afspraken, bijvoorbeeld tijdsnotatie, Mogelijkheid aanduiden kwaliteit van data (in plaats van gewoon verwijderen), 
niet gemakkelijk om door de techniekers te laten aanpassen
Historische semi-ruwe data (na een eerste verwerking naar standaard model)  is belangrijk voor AI dus mag niet gedelete worden.
Erosiepoelen zijn in de DOV gestockeerd (of alvast zeer veel)
GIS platformen gebruiken voor spatiale analyse , integratie met spatiale databases
Termen als Datawarehouses and Datalakes worden vernoemd. Ook Lakehouse bekijken? (best of breed ?) 
Denken dat een 'platform' een oplossing is. Kwestie van semantiek misschien eerder 'Data componenten oplossing'? 
Functieprofielen/rollen
Data eigenaar
Data engineer
Data analist
Data scientist
Dashboard/ visualisatie expert
tegen hackers die alarmen uisturen of pompen laten starten
Cybersecurity expert
Dataplatform beheerder
DPO (enkel voor GDPR data natuurlijk)
Toegangs- en rollen-beheerder
Financieel verantwoordelijke
Technische architect
Product Owner, Implementatie ProjectManager, Data Scientist, 
Datamodel expert
Data strategist ?

Discussie

  1. Data management: De discussie concentreerde zich op het belang van data management, inclusief data input, beheer, verwerking, en ontsluiting.
  2. Data governance: De verantwoordelijkheid voor data, inclusief de vraag wie de eigenaar is, en het belang van goede data governance-afspraken.
  3. Dataopslag en -beheer: Er werd gesproken over het bijhouden van historische data, het beheren van verschillende soorten data, en het gebruik van blob storage voor minder snel toegankelijke data.
  4. Dataplatformen: Discussies omvatten het overwegen van bestaande dataplatformen versus het bouwen van een eigen platform, integratie met andere platforms, en de functionele en technische vereisten van een dataplatform.
  5. Rollen en verantwoordelijkheden: Verschillende rollen werden besproken, waaronder data engineers, data scientists, data-analisten, en de rollen van een DPO (Data Protection Officer) en financieel verantwoordelijke.
  6. Technische aspecten: De technische architectuur van het dataplatform, inclusief data warehouses, data lakes, en het concept van een 'lakehouse', werd behandeld.

Oefening 4

Instructies

Welke zijn de valkuilen waar we volgens jou rekening mee moeten houden?

Formuleer enkele basisprincipes waaraan de oplossing moet voldoen

Voorbeeld:

•Te veel dashboarden waardoor je geen overzicht meer hebt

•Complexe dashboard

•Verantwoordelijkheid van data

Output

Valkuilen Principes
Geen spaghetti integraties
Goede afspraken duurzame databeheer (verantwoordelijkheid)
teveel informatie die niet meteen begrijpbaar zijn voor de gebruiker: goede selectie maken van wat relevant is om te tonen aan elk doelpubliek + goede metadata beschrijving. 
Zorg voor opleiding van eindgebruikers
onderhoud van het materiaal - te lange periodes met 'no data' of met onrealistische data wegens problemen met de sensoren kunnen vertrouwen ondermijnen  goede opvolging noodzakelijk - feedback van lokale terreinbeheerders cruciaal - niet louter een data/IT project
Niet opvolgen kosten/baten lange termijn. TCO zicht. Ook kijken naar waar kan waarde gegenereerd worden, en welke schadekosten zijn vermeden. Bijvoorbeeld zeggen we dat goede grond wegspoelt, nu vangen we die (deels) op maar wat doen we ermee? 
Afhankelijkheid van schaarse technische profielen op de markt 
Inkomende data op platform moet een eerste validatie krijgen,zodat fouten al in begin van de pipeline opgemerkt worden - Data quality checks : eerste lijn... 
Mogelijke principe: reeds ontwikkelde bouwstenen hergebruiken+ configuratie off the shelf functionaliteit bestaande technologiën, low code no code configuratie (reeds zelf  ontwikkeld-bestaande + technologiën,), configueren  en developen  enkel als 'bijkomende' capability
Budgetten ifv retour hele systeem. Als door monitoring grote schade kan worden voorkomen dan zullen de budgetten te verantwoorden zijn.
Dashboards kunnen een tree hebben, dus van overzicht naar detail via enkele klikken. (drill downs, slice/dice) 
Na kantooruren geen service van dataplatform  helpdesk 24/7 ? 

Discussie

  1. Complexiteit van Dashboards: Te veel informatie op dashboards kan leiden tot verwarring en gebrek aan overzicht, waardoor gebruikers de gegevens niet goed begrijpen.
  2. Verantwoordelijkheid van Data: Juridische aspecten rondom verantwoordelijkheid voor data in het geval van problemen moeten duidelijk zijn om mogelijke problemen te voorkomen.
  3. Budgetten en Leveranciersafhankelijkheid: Het beheer van budgetten en de afhankelijkheid van externe leveranciers zijn cruciale factoren die het succes van het project kunnen beïnvloeden.
  4. Datakwaliteit en Validatie: Het belang van datakwaliteit en het instellen van datavalidatieprocessen om fouten in de gegevens te voorkomen.
  5. Gebruikersacceptatie en Change Management: Het anticiperen op weerstand tegen verandering en het implementeren van effectief change management om ervoor te zorgen dat gebruikers het nieuwe systeem omarmen.
  6. Technische Capaciteiten en Talent: De beschikbaarheid van technisch talent en de afhankelijkheid van schaarse technische profielen op de markt kunnen uitdagingen vormen voor het project.
  7. Duurzaamheid en Onderhoud: Het plannen van duurzame databeheerpraktijken en het garanderen van continuïteit en onderhoud van het systeem, inclusief het opzetten van serviceovereenkomsten en een helpdesk.

Opname en Miro bord

Miro bord

Het Miro bord kan je consulteren via deze link.

Opname

De opname van deze sessie is te bekijken via deze link.


Volgende stappen

Wat na deze werkgroep?

  1. Verwerking van de input van de brainstorm oefening.
  2. Verder onderzoek en voorbereiding van de analyse.
  3. Publicatie op de Kennishub.

Feedback kan bezorgd worden aan laurien.renders@vlaanderen.be

Andere werkgroepen

WerkgroepType werkgroepDatumTijdLocatie
Business werkgroepBusiness werkgroep2024-02-2913u30-16u30Provinciehuis Leuven
Thematische werkgroep 1Data en informatie werkgroep2024-03-199u-12uTeams
Thematische werkgroep 2Functionele werkgroep2024-04-189u-12uTeams
Thematische werkgroep 3Technologie werkgroep2024-05-239u-12uTeams
Overgenomen van "https://vloca-kennishub.vlaanderen.be/index.php?title=VlocaSessie/69&oldid=11041"