"Parsed text" is een vooraf gedefinieerde eigenschap. Deze eigenschap is van te voren gedefinieerd (ook bekend als een speciale eigenschap) en komt met extra beheersprivileges, maar kan worden gebruikt net als elk andere door de gebruiker gedefinieerde eigenschap.
A
Korte Beschrijving
Data die gegenereerd wordt rond de fysieke locaties van mobipunten via API ontsluiten naar het bredere palet aan mobiliteitsplatformen in Vlaanderen.
Projectkader:
De mobipunten vormen een belangrijke sleutel in het Vlaamse mobiliteitsbeleid. Ook in het brede netwerk van open informatie in Vlaanderen is een rol voor deze mobipunten weggelegd. Naast het feit dat de mobipunten een ruimtelijke referentie hebben, kunnen zij ook dienen als ankerpunt voor aanvullende data. Realtime vervoersinformatie, de aanwezigheid van mobiliteitsopties en -diensten alsmede automatisch gegenereerde data vanuit sensoren kunnen worden gerelateerd aan de fysieke locaties van mobipunten. Dit creëert tal van mogelijkheden tot integraties met algemene reisplanner-toepassingen, planmakers bij lokale overheden, et cetera. Concreet wordt er gewerkt aan een API om de volgende mobipunt-gerelateerde data te ontsluiten:
Regel in ongenummerde lijst (Anonieme) Gebruikersdata: Lokale algemene gebruikersstatistieken, beoordelingen, resultaten van bevragingen, …
Regel in ongenummerde lijst Lokale data: Lokaal verkregen data betreffende vervoersaanbod, aanwezige diensten, toeristische informatie, lokale bijzonderheden, ...
Regel in ongenummerde lijst Sensordata: Optionele aanwezigheid van verschillende typen sensoren die kunnen ondersteunen bij het directe gebruik (cf parkeergelegenheid) alsmede input kunnen vormen voor lokaal onderzoek of specifieke problematieken (luchtkwaliteit, …).
Bestand:VLOKA-Traject-Mobipunten.pdf
Beschrijving Architectuur
Lessons learned +
Een " API -first" benadering vertrekt van de definitie van de functionaliteiten van een project of component door eerst de APIs te definiëren die deze functionaliteit aanbieden. De API is de basismanier om de functionaliteiten te gebruiken, en laat ook toe om deze functionaliteiten duurzaam aan te bieden zodat deze door meerdere klanten kunnen gebruikt worden. Dit is in tegenstelling tot een menselijke interface (zoals bijvoorbeeld een grafische applicatie), die het niet gemakkelijk maakt om de functionaliteiten door software toepassingen te laten gebruiken. API-first is een belangrijke strategie, maar vereist een specifieke aanpak. Een API is niet alleen de software interface, maar komt ook met contracten en moet voldoen aan heel wat karakteristieken om bruikbaar te zijn. Zo zijn REST-APIs tegenwoordig standaard, en wordt bijvoorbeeld Swagger gebruikt als documentatie. +
API-led
API-led connectiviteit is een methodische manier om gegevens met applicaties te verbinden via herbruikbare en doelgerichte API's. Deze API's zijn ontwikkeld om een specifieke rol te vervullen: het ontsluiten van gegevens uit systemen, het samenbrengen van gegevens in processen of het opzetten van ervaringen.
Wanneer iedereen in de organisatie gebruik maakt een API-led connectiviteit aanpak, zorgt dat ervoor dat iedereen ook direct toegang krijgt tot de beste API’s om applicaties en projecten op te leveren middels discovery, self-service en hergebruik. API-led connectiviteit is niet alleen afhankelijk van *drie categorieën (experience, process en system API’s) *herbruikbare API's om nieuwe services en mogelijkheden samen te stellen, maar decentraliseert en democratiseert ook de toegang tot gegevens uit de organisatie. Centrale IT produceert herbruikbare API's en ontgrendelt daarbij belangrijke systemen, waaronder legacy-applicaties, databronnen en SaaS-apps. Centrale IT en andere teams kunnen deze API's vervolgens hergebruiken en informatie op procesniveau samenbrengen. Vervolgens kunnen app-ontwikkelaars al deze herbruikbare API's makkelijk terugvinden in onze marktplaats genaamd Exchange en hergebruiken waardoor er op de experience laag API's en uiteindelijk de eindtoepassingen ontstaat. Deze API-led benadering verhoogt de flexibiliteit, snelheid en productiviteit.
Wanneer iedereen in de organisatie gebruik maakt een API-led connectiviteit aanpak, zorgt dat ervoor dat iedereen ook direct toegang krijgt tot de beste API’s om applicaties en projecten op te leveren middels discovery, self-service en hergebruik. API-led connectiviteit is niet alleen afhankelijk van drie categorieën (experience, process en system API’s) herbruikbare API's om nieuwe services en mogelijkheden samen te stellen, maar decentraliseert en democratiseert ook de toegang tot gegevens uit de organisatie. Centrale IT produceert herbruikbare API's en ontgrendelt daarbij belangrijke systemen, waaronder legacy-applicaties, databronnen en SaaS-apps. Centrale IT en andere teams kunnen deze API's vervolgens hergebruiken en informatie op procesniveau samenbrengen. Vervolgens kunnen app-ontwikkelaars al deze herbruikbare API's makkelijk terugvinden in onze marktplaats genaamd Exchange en hergebruiken waardoor er op de experience laag API's en uiteindelijk de eindtoepassingen ontstaat. Deze API-led benadering verhoogt de flexibiliteit, snelheid en productiviteit.
Waarom is API-led connectiviteit belangrijk?
API-led connectiviteit is een belangrijke integratiestrategie omdat de technologieën die [[::Category:Organisaties| Organisaties]] gebruiken om met hun klanten, werknemers en partners in contact te komen drastisch zijn veranderd. De convergentie van technologieën als IoT, SaaS, big data, social, mobiel en API's bieden krachtige nieuwe tools waarmee [[::Category:Organisaties| Organisaties]] meer kunnen doen: nieuwe inkomstenstromen kunnen ontgrendelen, hun klanten beter begrijpen en sneller kunnen innoveren. Om dat succesvol te doen, moeten ze echter wel deze nieuwe technologieën kunnen integreren. Traditioneel worden deze integraties gedaan via point-to-point verbindingen, op een ad hoc manier, wanneer een project dat vereist. Dit leidt tot gecompliceerde en broze verbindingen die vatbaar zijn voor storingen en die veel IT-tijd en middelen vergen om onderhouden te worden.
Bovendien is de frequentie waarmee deze nieuwe verbindingen of integraties veranderen ook toegenomen. Terwijl het database-schema van een kernsysteem in een bank slechts op jaarbasis veranderend, kunnen de vereisten van de toepassingen voor online en mobiel bankieren die op die systemen zijn aangesloten, wekelijks, dagelijks of zelfs elk uur veranderen. De snelheid van deze veranderingen kan niet worden opgevangen door traditionele point-to-point-integratiemethoden. Een andere benadering is hiervoor vereist: API-led connectiviteit.
Hoe vermindert API-led connectiviteit de werklast van IT?
API-led connectiviteit speelt een belangrijke rol bij het verminderen van de werklast van IT. Dit komt doordat IT vaak de taak heeft om deze nieuwe technologieën te implementeren en de nodige wijzigingen aan te brengen, om legacy-systemen te onderhouden (en hun verbindingen met andere systemen). Ze moeten steeds en sneller projecten opleveren en hun middelen blijven vaak constant of groeien niet in dezelfde grootorde. Wat uiteindelijk resulteert in, wat wij noemen, de IT-delivery gap:
Hoe wordt API-led connectiviteit mogelijk gemaakt?
API-led connectiviteit biedt een benadering voor het verbinden en beschikbaar stellen van API’s. In plaats van integraties op te zetten op een point-to-point manier, wordt elke API een beheerde, moderne API, die makkelijk vindbaar is voor andere in de organisatie, zonder de controle te verliezen.
De API's die worden gebruikt in een API-led benadering van connectiviteit vallen in drie categorieën:
Syteem API's - Deze hebben toegang tot de kernsystemen en zorgen ervoor dat de complexiteit of eventuele wijzigingen geen impact hebben op de gebruiker. Dit zorgt er ook voor, dat eenmaal gebouwd, gebruikers toegang kunnen krijgen tot gegevens van deze kernsystemen zonder dat ze het onderliggende systeem moeten leren kennen en zo kunnen ze deze API's gemakkelijk hergebruiken in meerdere projecten.
Process API's - Deze API's werken samen met en geven vorm aan gegevens binnen een systeem of enkele systemen (het opsplitsen van gegevenssilo's); en worden hier gemaakt zonder afhankelijk te zijn van de kernsystemen waaruit dee gegevens afkomstig zijn, evenals de front-end kanalen via welke de gegevens worden geleverd.
Experience API's - Experience API's zijn het middel waarmee gegevens opnieuw kunnen worden geconfigureerd, zodat ze op een makkelijker manier kunnen worden geconsumeerd door de beoogde doelgroep. Dit allemaal vanuit een gemeenschappelijke gegevensbron, in plaats van afzonderlijke point-to-point integraties voor elk kanaal in te stellen. Een Experience API wordt meestal gemaakt met de API-first design principes, waarbij de API is ontworpen met de specifieke gebruikerservaring in gedachten.
Door API's op deze manier te bouwen en te organiseren, en ze vervolgens vindbaar en beschikbaar te stellen voor de organisatie via self-service. Maakt het mogelijk voor andere teams in de organisatie om deze API's opnieuw samen te stellen en aan te passen naar de veranderende behoeften van het team of het deel van de organisatie.
Hoe zou API-led connectiviteit werken in mijn organisatie?
API-led connectiviteit is een cruciaal om de ‘IT-delivery gap’ te dichten. Laten we het voorbeeld nemen van een IT team dat een nieuwe webapp moet ontwikkelen om direct inzicht te geven aan vertegenwoordigers over de orderstatus en ordergeschiedenis van hun klanten. Laten we voor dit voorbeeld aannemen dat de klantgegevens in SAP en in Salesforce zitten; de inventaris gegevens in SAP; en ordergegevens in SAP e-commerce systeem.
Traditioneel zou dit worden opgezet met een point-to-point-integratiebenadering, het IT-team verzameld de klantgegevens uit SAP en Salesforce dmv custom code. Vervolgens worden de geaggregeerde klantgegevens verder gecombineerd met ordergegevens uit het e-commercesysteem om zowel de orderstatus als de ordergeschiedenis te produceren - met opnieuw custom code. Vervolgens worden deze twee gegevensbronnen aan elkaar gekoppeld via een webapp-API.
Dit project kan als een succes worden beschouwd; het werd op tijd opgeleverd, binnen budget en het heeft de juiste functionaliteiten. Maar een paar weken later eist het verkoopteam, dat vaak onderweg is, dat deze functionaliteit beschikbaar wordt gesteld op hun mobiele telefoons. Het IT-team moet nu dus opnieuw vanaf nul beginnen. De ontwikkelaars die de app bouwen, kunnen niet verder zonder dat zij toegang krijgen tot de juiste gegevens.
Hoewel de meeste ontwikkelaars weten dat een point-to-point-integratiestrategie, een kortzichtige benadering is, rechtvaardigen ze dit gezien de intense tijdsdruk. Vaak wordt dit probleem zelfs groter bij her samenwerken met consultants, omdat zij weinig geneigd zijn om op lange termijn na te denken. Omdat verandering iets constant is geworden, wordt een point-to-point integratiestrategie over tijd erg duur of bijna onmogelijk. Zoals hieronder te zien is, begint het bekende "spaghetticode" -patroon vorm te krijgen.
Wanneer IT-teams echter een API-led aanpak gebruiken, kunnen ze alles wat ze gebouwd hebben voor het eerste project (Web app) hergebruiken voor de mobile app. Want er zijn nu herbruikbare API’s gemaakt op basis van systeem en proces-API's, waardoor al het werk dat nodig is om ze opnieuw te bouwen, wordt geëlimineerd.
Het maken van de mobiele app is dus een kwestie van de verschillende systemen op elkaar laten aansluiten. Dit maakt het ook veel gemakkelijker om te innoveren en nieuwe services toe te voegen. Zoals in dit voorbeeld, het toevoegen van informatie over de verzendstatus. Op vrijwel dezelfde manier waarop de orderstatus en de ordergeschiedenis werden opgezet. Dit bespaart tijd, geld, middelen en zorgt ervoor dat projecten sneller kunnen worden opgeleverd.
Zoals u kunt zien, gebruikt API-led connectiviteit enkele van de principes van een service georiënteerde architectuur. De API-led connectiviteit benadering stelt ontwikkelaars in heel de organisatie in staat herbruikbare services samen te stellen en te hergebruiken om projecten te bouwen die zij nodig achten, in plaats van de top-down, zwaargewicht dictaten van traditionele SOA-benaderingen. De methode waarop deze middelen in een organisatie worden gebruikt, is net zo belangrijk voor de API-led connectiviteit benadering als de middelen zelf.
Wat zijn de zakelijke voordelen van API-led connectiviteit?
Een API-led connectiviteit benadering helpt niet alleen met het op tijd opleveren van uw huidige IT-projecten, het zorgt er ook voor dat u dmv het bouwen van herbruikbare middelen bij uw volgende projecten, tijd en geld zult besparen. Er wordt een infrastructuur gecreëerd die future-proof is.
Gemiddeld zien we dat de toegenomen flexibiliteit en snelheid die wordt geboden door API-led connectiviteit ertoe leidt dat projecten 3-5x sneller worden opgeleverd en de teamproductiviteit verhoogt met 300% in vergelijking met andere integratiemethodes.
API-led
API-led connectiviteit is een methodische manier om gegevens met applicaties te verbinden via herbruikbare en doelgerichte API's. Deze API's zijn ontwikkeld om een specifieke rol te vervullen: het ontsluiten van gegevens uit systemen, het samenbrengen van gegevens in processen of het opzetten van ervaringen.
Wanneer iedereen in de organisatie gebruik maakt een API-led connectiviteit aanpak, zorgt dat ervoor dat iedereen ook direct toegang krijgt tot de beste API’s om applicaties en projecten op te leveren middels discovery, self-service en hergebruik. API-led connectiviteit is niet alleen afhankelijk van *drie categorieën (experience, process en system API’s) *herbruikbare API's om nieuwe services en mogelijkheden samen te stellen, maar decentraliseert en democratiseert ook de toegang tot gegevens uit de organisatie. Centrale IT produceert herbruikbare API's en ontgrendelt daarbij belangrijke systemen, waaronder legacy-applicaties, databronnen en SaaS-apps. Centrale IT en andere teams kunnen deze API's vervolgens hergebruiken en informatie op procesniveau samenbrengen. Vervolgens kunnen app-ontwikkelaars al deze herbruikbare API's makkelijk terugvinden in onze marktplaats genaamd Exchange en hergebruiken waardoor er op de experience laag API's en uiteindelijk de eindtoepassingen ontstaat. Deze API-led benadering verhoogt de flexibiliteit, snelheid en productiviteit.
Wanneer iedereen in de organisatie gebruik maakt een API-led connectiviteit aanpak, zorgt dat ervoor dat iedereen ook direct toegang krijgt tot de beste API’s om applicaties en projecten op te leveren middels discovery, self-service en hergebruik. API-led connectiviteit is niet alleen afhankelijk van drie categorieën (experience, process en system API’s) herbruikbare API's om nieuwe services en mogelijkheden samen te stellen, maar decentraliseert en democratiseert ook de toegang tot gegevens uit de organisatie. Centrale IT produceert herbruikbare API's en ontgrendelt daarbij belangrijke systemen, waaronder legacy-applicaties, databronnen en SaaS-apps. Centrale IT en andere teams kunnen deze API's vervolgens hergebruiken en informatie op procesniveau samenbrengen. Vervolgens kunnen app-ontwikkelaars al deze herbruikbare API's makkelijk terugvinden in onze marktplaats genaamd Exchange en hergebruiken waardoor er op de experience laag API's en uiteindelijk de eindtoepassingen ontstaat. Deze API-led benadering verhoogt de flexibiliteit, snelheid en productiviteit.
Waarom is API-led connectiviteit belangrijk?
API-led connectiviteit is een belangrijke integratiestrategie omdat de technologieën die [[::Category:Organisaties| Organisaties]] gebruiken om met hun klanten, werknemers en partners in contact te komen drastisch zijn veranderd. De convergentie van technologieën als IoT, SaaS, big data, social, mobiel en API's bieden krachtige nieuwe tools waarmee [[::Category:Organisaties| Organisaties]] meer kunnen doen: nieuwe inkomstenstromen kunnen ontgrendelen, hun klanten beter begrijpen en sneller kunnen innoveren. Om dat succesvol te doen, moeten ze echter wel deze nieuwe technologieën kunnen integreren. Traditioneel worden deze integraties gedaan via point-to-point verbindingen, op een ad hoc manier, wanneer een project dat vereist. Dit leidt tot gecompliceerde en broze verbindingen die vatbaar zijn voor storingen en die veel IT-tijd en middelen vergen om onderhouden te worden.
Bovendien is de frequentie waarmee deze nieuwe verbindingen of integraties veranderen ook toegenomen. Terwijl het database-schema van een kernsysteem in een bank slechts op jaarbasis veranderend, kunnen de vereisten van de toepassingen voor online en mobiel bankieren die op die systemen zijn aangesloten, wekelijks, dagelijks of zelfs elk uur veranderen. De snelheid van deze veranderingen kan niet worden opgevangen door traditionele point-to-point-integratiemethoden. Een andere benadering is hiervoor vereist: API-led connectiviteit.
Hoe vermindert API-led connectiviteit de werklast van IT?
API-led connectiviteit speelt een belangrijke rol bij het verminderen van de werklast van IT. Dit komt doordat IT vaak de taak heeft om deze nieuwe technologieën te implementeren en de nodige wijzigingen aan te brengen, om legacy-systemen te onderhouden (en hun verbindingen met andere systemen). Ze moeten steeds en sneller projecten opleveren en hun middelen blijven vaak constant of groeien niet in dezelfde grootorde. Wat uiteindelijk resulteert in, wat wij noemen, de IT-delivery gap:
Hoe wordt API-led connectiviteit mogelijk gemaakt?
API-led connectiviteit biedt een benadering voor het verbinden en beschikbaar stellen van API’s. In plaats van integraties op te zetten op een point-to-point manier, wordt elke API een beheerde, moderne API, die makkelijk vindbaar is voor andere in de organisatie, zonder de controle te verliezen.
De API's die worden gebruikt in een API-led benadering van connectiviteit vallen in drie categorieën:
Syteem API's - Deze hebben toegang tot de kernsystemen en zorgen ervoor dat de complexiteit of eventuele wijzigingen geen impact hebben op de gebruiker. Dit zorgt er ook voor, dat eenmaal gebouwd, gebruikers toegang kunnen krijgen tot gegevens van deze kernsystemen zonder dat ze het onderliggende systeem moeten leren kennen en zo kunnen ze deze API's gemakkelijk hergebruiken in meerdere projecten.
Process API's - Deze API's werken samen met en geven vorm aan gegevens binnen een systeem of enkele systemen (het opsplitsen van gegevenssilo's); en worden hier gemaakt zonder afhankelijk te zijn van de kernsystemen waaruit dee gegevens afkomstig zijn, evenals de front-end kanalen via welke de gegevens worden geleverd.
Experience API's - Experience API's zijn het middel waarmee gegevens opnieuw kunnen worden geconfigureerd, zodat ze op een makkelijker manier kunnen worden geconsumeerd door de beoogde doelgroep. Dit allemaal vanuit een gemeenschappelijke gegevensbron, in plaats van afzonderlijke point-to-point integraties voor elk kanaal in te stellen. Een Experience API wordt meestal gemaakt met de API-first design principes, waarbij de API is ontworpen met de specifieke gebruikerservaring in gedachten.
Door API's op deze manier te bouwen en te organiseren, en ze vervolgens vindbaar en beschikbaar te stellen voor de organisatie via self-service. Maakt het mogelijk voor andere teams in de organisatie om deze API's opnieuw samen te stellen en aan te passen naar de veranderende behoeften van het team of het deel van de organisatie.
Hoe zou API-led connectiviteit werken in mijn organisatie?
API-led connectiviteit is een cruciaal om de ‘IT-delivery gap’ te dichten. Laten we het voorbeeld nemen van een IT team dat een nieuwe webapp moet ontwikkelen om direct inzicht te geven aan vertegenwoordigers over de orderstatus en ordergeschiedenis van hun klanten. Laten we voor dit voorbeeld aannemen dat de klantgegevens in SAP en in Salesforce zitten; de inventaris gegevens in SAP; en ordergegevens in SAP e-commerce systeem.
Traditioneel zou dit worden opgezet met een point-to-point-integratiebenadering, het IT-team verzameld de klantgegevens uit SAP en Salesforce dmv custom code. Vervolgens worden de geaggregeerde klantgegevens verder gecombineerd met ordergegevens uit het e-commercesysteem om zowel de orderstatus als de ordergeschiedenis te produceren - met opnieuw custom code. Vervolgens worden deze twee gegevensbronnen aan elkaar gekoppeld via een webapp-API.
Dit project kan als een succes worden beschouwd; het werd op tijd opgeleverd, binnen budget en het heeft de juiste functionaliteiten. Maar een paar weken later eist het verkoopteam, dat vaak onderweg is, dat deze functionaliteit beschikbaar wordt gesteld op hun mobiele telefoons. Het IT-team moet nu dus opnieuw vanaf nul beginnen. De ontwikkelaars die de app bouwen, kunnen niet verder zonder dat zij toegang krijgen tot de juiste gegevens.
Hoewel de meeste ontwikkelaars weten dat een point-to-point-integratiestrategie, een kortzichtige benadering is, rechtvaardigen ze dit gezien de intense tijdsdruk. Vaak wordt dit probleem zelfs groter bij her samenwerken met consultants, omdat zij weinig geneigd zijn om op lange termijn na te denken. Omdat verandering iets constant is geworden, wordt een point-to-point integratiestrategie over tijd erg duur of bijna onmogelijk. Zoals hieronder te zien is, begint het bekende "spaghetticode" -patroon vorm te krijgen.
Wanneer IT-teams echter een API-led aanpak gebruiken, kunnen ze alles wat ze gebouwd hebben voor het eerste project (Web app) hergebruiken voor de mobile app. Want er zijn nu herbruikbare API’s gemaakt op basis van systeem en proces-API's, waardoor al het werk dat nodig is om ze opnieuw te bouwen, wordt geëlimineerd.
Het maken van de mobiele app is dus een kwestie van de verschillende systemen op elkaar laten aansluiten. Dit maakt het ook veel gemakkelijker om te innoveren en nieuwe services toe te voegen. Zoals in dit voorbeeld, het toevoegen van informatie over de verzendstatus. Op vrijwel dezelfde manier waarop de orderstatus en de ordergeschiedenis werden opgezet. Dit bespaart tijd, geld, middelen en zorgt ervoor dat projecten sneller kunnen worden opgeleverd.
Zoals u kunt zien, gebruikt API-led connectiviteit enkele van de principes van een service georiënteerde architectuur. De API-led connectiviteit benadering stelt ontwikkelaars in heel de organisatie in staat herbruikbare services samen te stellen en te hergebruiken om projecten te bouwen die zij nodig achten, in plaats van de top-down, zwaargewicht dictaten van traditionele SOA-benaderingen. De methode waarop deze middelen in een organisatie worden gebruikt, is net zo belangrijk voor de API-led connectiviteit benadering als de middelen zelf.
Wat zijn de zakelijke voordelen van API-led connectiviteit?
Een API-led connectiviteit benadering helpt niet alleen met het op tijd opleveren van uw huidige IT-projecten, het zorgt er ook voor dat u dmv het bouwen van herbruikbare middelen bij uw volgende projecten, tijd en geld zult besparen. Er wordt een infrastructuur gecreëerd die future-proof is.
Gemiddeld zien we dat de toegenomen flexibiliteit en snelheid die wordt geboden door API-led connectiviteit ertoe leidt dat projecten 3-5x sneller worden opgeleverd en de teamproductiviteit verhoogt met 300% in vergelijking met andere integratiemethodes.
Aquafin zuivert rioolwater tot het weer de natuur in kan. Geen drinkwater dus voor de mens, maar wel voor vissen, vogels en amfibieën. Voor jou werken we aan een leefomgeving in harmonie met water. Dat betekent proper water in stadskernen, waarlangs het aangenaam wonen en wandelen is. Maar ook een duurzame omgang met regenwater, om droge bodems te helpen voorkomen en de gevolgen van zware buien te beperken.
Meer information over Aquafin kan je vinden op de Aquafin website en op de Aquafin wikipedia pagina . +
Het Agentschap Wegen en Verkeer (AWV) is wegbeheerder van zo´n 7000 km gewest- en autosnelwegen en ruim 7700 km fietspaden. Wij werken elke dag aan een betere mobiliteit en doen dat samen met verschillende partners.
Missie & visie
Het Agentschap Wegen en Verkeer wil dé toonaangevende, toekomstgerichte wegbeheerder zijn voor alle weggebruikers. We zijn de motor van veilige, betrouwbare en duurzame infrastructuur en verkeersafwikkeling. Verkeersveiligheid komt bij ons steeds op de eerste plaats.
We geven de mobiliteit van morgen vorm door:
oplossingsgericht de krachten en expertise te bundelen met onze partners
rekening te houden met risicoanalyses bij het bepalen van prioriteiten
duidelijke voorstellen te formuleren naar beleidsmakers en lokale besturen
sterk asset management uit te voeren
kwaliteit te leveren bij elk nieuw project en bij het beheer van bestaande infrastructuur
oog te hebben voor het comfort van elke weggebruiker
in te spelen op innovatie en digitalisering
Meer informatie over AWV kan hier gevonden worden. +
+++ Deze pagina is in opmaak/ontwikkeling +++
Doelgroep en doel
Inleiding
Een OSLO standaard heeft een fase van publieke review. In gezamenlijke VLOCA-OSLO trajecten communiceren we ook gezamenlijk via onze beschikbare kanalen over de start van de publieke review van de datastandaard. In VLOCA is het doel om een community op te zetten rondom die use case, die de gecreëerde architectuurstandaard beheert. Continue verrijking ervan is cruciaal: de wereld staat immers niet stil na het opleveren van een eerste architectuurmodel.
Voorstel voor een Kennishub pagina van deze deliverable[edit source]
Introductie (waar gaat het over?)
Beschrijving van de standaard
Beschrijving van het proces en de bijhorende termijnen
Beschrijving over hoe geïnteresseerde partij zelf kan bijdragen
Aanpak bij het ontwikkelingen van deze deliverable[edit source]
Noot: Het “organiseren van een publieke review” is stap 6 van onderdeel 2 “ontwikkelen van een specificatie” in een OSLO proces. Meer informatie over het OSLO proces kan hier gevonden worden. Deze deliverable sluit dus aan bij stap 6 van onderdeel 2.
Stap 1: Opmaken en afstemmen basiscommunicatie met OSLO team
Stap 2: Communiceren over de publieke review, via de verschillende VLOCA kanalen, wat minstens het volgende omvat:
Informatie over de standaard, het proces en de termijnen
Connectie van de standaard naar het VLOCA-OSLO traject
Informatie over hoe de feedback op de standaard kan meegegeven worden
Informatie over de mogelijkheid om de standaard ook in de toekomst nog verder te laten evolueren +
+++ Deze pagina is in opmaak/ontwikkeling +++
Doelgroep en doel
Inleiding
Elk thema dat we aanraken verdient zijn eigen plek op de kennishub. Het platform wordt gebruikt als co-creatieplatform waar alle experten samen werken aan een correcte beschrijving van het thema. We doelen om per thema een aantal aspecten in de schijnwerper te zetten:
de probleemstelling,
de huidige mogelijkheden
de innovatie die op komst is
hoe kiezen tussen mogelijkheden
de VLOCA hulpmiddelen +
Totale aanvoer AEEA per park in kg +
VLOCA, de Vlaamse Open City Architectuur, is een initiatief van het Agentschap Binnenlands Bestuur van de Vlaamse Overheid.
Onze hulp aan lokale besturen start bij het scherpstellen van duidelijke, verstaanbare use cases en loopt door tot de aanbestedingsfase van het project. We vormen 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 stimuleren we de ontwikkeling van herbruikbare bouwblokken, standaarden en normen die van Vlaanderen één grote interoperabele slimme regio kunnen maken. De opgedane kennis en ervaring wordt ontsloten via een kennishub waarop onder andere draaiboeken, architectuurcomponenten en modellen ter beschikking gesteld worden voor alle andere lokale besturen en stakeholders.
Welkom op de Vlaamse Open City Architectuur Kennishub
Wat wil VLOCA bereiken?
De doelstelling van de Vlaamse Open City Architectuur (VLOCA) is tweeledig. Enerzijds wil VLOCA in co-creatie met lokale besturen, kenniscentra, bedrijven, en burgerorganisaties een gedragen referentiekader, dat bestaat uit principes , concepten en architectuurcomponenten, tot stand brengen. Dit moet gaandeweg leiden tot een beheersbare open city architectuur voor slimme steden en gemeenten. Anderzijds is het de bedoeling om bovenstaande resultaten door te vertalen naar draaiboeken voor aanbestedende (lokale) overheden. Deze draaiboeken moeten hen ondersteunen om nieuwe smart city initiatieven uit te rollen, conform de Vlaamse Open City Architectuur.
Wat is het doel van de VLOCA Kennishub?
De VLOCA Kennishub brengt jou en andere betrokkenen samen om co-creatie te vereenvoudigen en mee te denken over standaarden, principes en technische specificaties. De concrete en praktische informatie om open city architectuur & bijhorende projecten uit te bouwen vind je hier terug.
Hoe willen we dit aanpakken?
We nodigen geïnteresseerde lezers uit om deze architectuur mee vorm te geven via co-creatie op de VLOCA Kennishub, vanuit de eigen ervaring en expertise. Het uitbouwen van een gemeenschappelijke open city architectuur wordt zo een incrementeel innovatief proces. Hier kunnen gebruikers lezen hoe actief kan bijdragen worden. Op deze pagina hebben we een eerste aanzet gegeven van een blauwdruk van de referentie architectuur. Het co-creatie proces zal geleidelijk aan rijker gestoffeerd worden. Nieuwe iteraties worden via de nieuwsbrief en op het VLOCA portaal gecommuniceerd. Meer informatie over hoe gebruikers zelf kunnen bijdragen kan gevonden worden onder de tab Werkwijze .
Hoe is de VLOCA Kennishub georganiseerd?
VLOCA is georganiseerd volgens een Kennismodel zoals weergegeven in de figuur hierboven. De basisprincipes en doelstelling van VLOCA zijn beschreven in het VLOCA Charter . De opbouw en uitwerking van VLOCA start vanuit VLOCA Use Cases. Dit zijn Trajecten die een brede maatschappelijke relevantie hebben en een belangrijke rol kunnen spelen in het creëren van een open city architectuur. Voor iedere VLOCA Use Case kunnen architecturale vereisten en Randvoorwaarden opgesteld worden. We gaan in een VLOCA Use Case evolueren van functionele naar architecturale behoeften. De VLOCA Use Cases en bijhorende vereisten en randvoorwaarden zijn toegankelijk via de tab Trajecten . Om aan de architecturale behoeften te voldoen wordt via deze VLOCA Use Cases een Architectuur gedefinieerd, dewelke bouwlagen , componenten en systeemeigenschappen bevat. Deze architecturale informatie en andere technische termen zijn terug te vinden onder Termen & Concepten . VLOCA functioneert uiteraard in een breder ecosysteem. Dit ecosysteem omvat organisaties die standaarden zullen opzetten en beheren. Deze standaarden worden onder meer gebruikt in het opzetten van een architectuur om tegemoet te komen aan de architecturale behoeften. De organisaties en bijhorende standaarden zijn terug te vinden onder de tab Ecosystemen .
This is a property of type Text .
The allowed values for this property are:
Burgers
Kennisinstellingen
Overheden
Industrie +
Agoria baant het pad voor alle technologisch geïnspireerde bedrijven in België die door de ontwikkeling of toepassing van innovaties vooruitgang in de wereld nastreven en die samen ruim 310.000 werknemers vertegenwoordigen.
De acties, dienstverlening en standpunten van Agoria gaan over:
Human capital & education
Digitalisering
Society
Regelgeving & finance
Maakindustrie
Klimaat, milieu & energie
Marktontwikkeling
Infrastructuur
Meer informatie over Agoria kan hier gevonden worden alsook op de Agoria wikipedia pagina . +
De Algemene verordening gegevensbescherming (AVG) is een Europese verordening (dus met rechtstreekse werking) die de regels voor de verwerking van persoonsgegevens door particuliere bedrijven en overheidsinstanties in de hele Europese Unie standaardiseert.
Sinds 25 mei 2018 is de Algemene verordening gegevensbescherming (AVG) van toepassing. Dat betekent dat in de hele Europese Unie (EU) dezelfde privacywetgeving geldt. De AVG is ook wel bekend onder de Engelse naam: General Data Protection Regulation (GDPR).
Lees ook:
https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_nl
https://nl.wikipedia.org/wiki/Algemene_verordening_gegevensbescherming +
Template:Documentation subpage
Template:High-use
Template:Caution
This is a generic template for handling the horizontal alignment of elements on a page. Use the template like this:
Template:Tlx +
Alle deliverables
VLOCA traject Deliverable Versie Aankondiging start publieke review Andere Beschrijving Aanmaak co-creatie pagina op de kennishub Andere Beschrijving Architectuurstandaard Andere Beschrijving Bestekteksten Beschrijvende teksten Beschrijving Conformiteitsmodel Conformiteitsmodel Beschrijving Data Governance Model Data governance model Beschrijving VLOCA-model V0.1 Lokale Open Data Economie (LODE) – Brugge Lokale Open Data Economie (LODE) VLOCA-Model V0.1 VLOCA-model V0.1 Slimme stadsdistributie – Hasselt Slimme stadsdistributie VLOCA-Model V0.1 Circulaire economie: Repair cafés VLOCA-model V0.2 Circulaire economie: Repair cafés VLOCA-Model V0.2 VLOCA-model V0.2 Lokale Open Data Economie (LODE) – Brugge Lokale Open Data Economie (LODE) VLOCA-Model V0.2 VLOCA-model V0.2 Het potentieel van urban mining voor de bouwsector Het potentieel van urban mining & BIM voor de bouwsector VLOCA-Model V0.2 VLOCA-model Ondersteuning retail binnenstad activatie Datagestuurde handelskern VLOCA-Model V0.1 Stakeholderanalyse Slimme stadsdistributie Stakeholderanalyse V0 Voorbeeld architectuurtekening Slimme stadsdistributie TA-Tekening V0 Visualo VLOCA-model V0.2 Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) VLOCA-Model V0.2 VLOCA-model V0.2 Mobiliteitsbudget voor burgers – Hasselt Mobiliteitsbudget voor burgers VLOCA-Donut V0.2 VLOCA-model V0.1 Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform VLOCA-Model V0.1 VLOCA-model V0.2 Slimme stadsdistributie – Hasselt Slimme stadsdistributie VLOCA-Model V0.2 VLOCA-model V1.0 Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform VLOCA-Model V1.0 Roadmap Regionaal plugable incentiveringsplatform – Geel V0 VLOCA-model V1.8 Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform VLOCA-Model Co-creatie Vereistenmodel Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform Vereistenmodel V0 Vereistenmodel VISUALO Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) Beschrijvende teksten V0 VLOCA-model V0.1 Smart Innovation Factory – Mechelen Smart Innovation Factory VLOCA-Model V0.1 VLOCA-model V0.1 Mobiele Sensor Units – Roeselare Mobiele Sensor Units VLOCA-Model V0.1 VLOCA-model V0.1 Machine Learning as a Service (MLaaS) – Roeselare Machine Learning as a Service (MLaaS) VLOCA-Model V0.1 Visualo VLOCA-model V0.1 Veelzijdige InfoSchermen voor Updates en Acties van Lokale Ondernemers (VISUALO) VLOCA-Model V0.1 VLOCA-model V0.1 Het potentieel van urban mining voor de bouwsector Het potentieel van urban mining & BIM voor de bouwsector VLOCA-Model V0.1 VLOCA-model V0.1 Slimme Markten – Hasselt Slimme Markten VLOCA-Model V0.1 VLOCA-model V0.1 Mobiliteitsbudget voor burgers – Hasselt Mobiliteitsbudget voor burgers VLOCA-Donut V0.1 Architectuurtekeningen Regionaal plugable incentiveringsplatform – Geel Regionaal plugable incentiveringsplatform Andere V0 Prioriteringsoefening Regionaal plugable incentiveringsplatform – Geel V1.0 Informatienoden Informatiearchitectuur Beschrijving Marktanalyse Marktanalyse Beschrijving Oproep tot deelname Andere Beschrijving Opstart werkgroep beheer architectuur van de use case Andere Beschrijving Stakeholder interview Andere Beschrijving Stakeholderanalyse Stakeholderanalyse Beschrijving Technische Architectuur tekeningen TA-Tekening Beschrijving Testimonial Andere Beschrijving Traject charter Traject charter Beschrijving Use case prioritering Use case prioritering Beschrijving Use case roadmap Use case roadmap Beschrijving VLOCA Draaiboeken Draaiboeken Beschrijving VLOCA Talk Andere Beschrijving VLOCA assessment VLOCA-Assessment Beschrijving VLOCA donut VLOCA-Donut Beschrijving VLOCA-Model VLOCA-Model Beschrijving Vereistenmodel Vereistenmodel Beschrijving
Wie is AIOTI
AIOTI is een Europese organizatie opgericht vanuit de Europese Commisssie in 2015 met als doel om de dialoog en interactie tussen Europese IoT spelers te versterken, en zo bij te dragen tot een dynamische Europees IoT ecosysteem om de snelheid van IoT adoptie te vergroten.
Enkele recente IoT & smart city inzichten
Deze 2 blogs geven een mooie evolutie van IoT-enabled steden en hun uitdagingen in de laatste 2 jaar :
In deze blog [1] een beschrijving gegeven van IoT-enabled cities met 3 prioriteiten voor (2018)
Cross-domein (economisch schaalbare) toepassingen zullen essentieel zijn voor een duurzame verdere ontwikkeling van IoT binnen slimme steden
De industrie moet oplossingen brengen voor IoT platformen om data schaalbaar uit te wisselen
IoT platformen moeten schalen voor stream processing (inclusief video)
En meer recent [2] (2020) werden volgende inzichten gegeven ivm IoT-enabled smart cities en hun state-of-the-art:
Data delen en integratie zijn de belangrijkste uitdagingen die moeten opgelost worden door standaard Organisaties en regulatoren. Voorbeelden zijn SAREF (een ontologie voor het voorstellen van kennis over slimme toepassingen) en NGSI-LD (een standaard API voor het delen van data verzamelingen)
Veerkrachtige steden moeten het gat tussen IoT en publieke veiligheid dichten
Kunstmatige Intelligentie moet binnen slimme steden ethisch zijn en rekening houden met de sociale impact
Stedelijk "generatief" ontwerp zal bepalen hoe steden zullen evolueren. Een voorbeeld hiervoor zijn stedelijke digital twins.
AIOTI & Smart Cities
IoT speelt een steeds voornamere rol in slimme steden. Binnen AIOTI zijn er verschillende werkgroepen. In de context van VLOCA bespreken we kort 2 werkgroepen rond IoT standaardisatie en Smart Cities. De werkgroepen worden weergegeven in [3]
AIOTI WG03 : IoT Standaardisatie
Deze werkgroep heeft heel wat rapporten gepubliceerd [4]
Daarbij werd een High Level Architecture gedefinieerd in [5] met definitie van een Netwerk Laag, een IoT laag en een Applicatie laag, en hun interacties. De IoT laag focust op de schaalbare ontsluiting van IoT data door middel van een voorstelling van een "ding" met zijn semantische metadata. Bovendien is er aandacht aan "device management", ontdekken van devices, locatie,... Identificatie van de "dingen", applicaties en diensten, communicatie, data, locatie, protocol en gebruiker is daarbij een belangrijk element. Bevondien wordt er dieper ingegaan op het uitrollen van deze architectuur en verbanden met andere functionele modellen (van bijvoorbeeld OneM2M en RAMI 4.0).
Er werden ook nog papers gepubliceerd rond semantische interoperabilitiet in samenwerking met andere (standaardisatie) Organisaties en bedrijven. In [6] wordt het belang van semantische interoperabiliteit uitgelegd, en worden ook aanbevelingen gedaan voor semantische interop Standaarden door het gebruiken van ontologieen .
AIOTI WG08 : Smart Cities
Deze werkgroep heeft aanbevelingen gedaan voor grote Smart City piloot projecten. Daarbij ligt de focus op de echte noden en problemen van de vraagzijde (burgers en steden) en wat de uitdagingen en technologieen zijn aan de aanbod zijde. Daarbij zijn de sleutel succes factoren schaalbaarheid en repliceerbaarheid door interoperabiliteit in de data laag, duurzaamheid vanuit economisch en sociaal perspectief en een hefboomeffect voor het locale digitale leven en digitale economie in Europese steden.
In 2015 werd er een rapport [7] met aanbevelingen gepubliceerd voor het opzetten van large scale (IoT) piloot projecten.
Een belangrijk kenmerk van IoT in stedelijke context, is de nood aan de combinatie van data uit verschillende domeinen ( Cross-Domain ) om smart city toepassingen mogelijk te maken. In 2018 werd hiervoor een rapport [8] gepubliceerd met technieken voor het repliceren van smart city toepassingen. Deze technieken zijn dan ook relevant in een Open [[::Category:Open_Smart_City_Architectuur| Smart City Architectuur]] en hier worden er een aantal opgelijst :
definieren en delen van goede praktijken
oplijsten van gemeenschappelijk en veel voorkomende (Cross-Domain) use cases
interoperabiliteit als sleutel principe
een platform benadering
zoveel mogelijk gebruik van verticale en horizontale Standaarden
De aanbevelingen van dit document zijn :
Steden moeten horizontaal denken voor hun aankoop processen wegens de groeiende nood aan cross-domain toepassingen
Het delen van inzichten en ervaring tussen steden zijn de sleutel tot het beter begrijpen van de kosten en baten van deze toepassingen
Een horizontale benadering gaat in wezen over een robuste data infrastructuur om dit toe te laten.
↑ https://aioti.eu/2793-2/
↑ https://aioti.eu/iot-enabled-smart-cities-and-communities-here-to-stay-and-grow/
↑ https://aioti.eu/working-groups/
↑ https://aioti.eu/aioti-wg03-reports-on-iot-standards/
↑ https://aioti.eu/wp-content/uploads/2018/06/AIOTI-HLA-R4.0.7.1-Final.pdf
↑ https://aioti.eu/wp-content/uploads/2018/06/AIOTI-HLA-R4.0.7.1-Final.pdf
↑ https://aioti.eu/wp-content/uploads/2017/03/AIOTIWG08Report2015-Smart-Cities.pdf
↑ https://aioti.eu/wp-content/uploads/2018/06/AIOTI-WG08-Smart-City-Replication-Guidelines-Part-1-Cross-Domain-Use-Cases-V1.0-with-new-logo.pdf