In 2014 publiceerden we een research note over ‘Open Data’ naar aanleiding van de Europese richtlijn PSI (Public Service Information) van 2013 die van toepassing was in 2015 (1). 

Sindsdien verschenen of verschijnen nog steeds andere Europese wetgevingen. Deze nieuwe wetten doen niets af aan wat van toepassing was in 2014 (afgezien van enkele url’s uit de research note van 2014 die niet meer up-to-date zijn) maar verbreden aanzienlijk het toepassingsveld (2) ervan dat we in dit blogartikel gaan voorstellen.

We komen hier niet meer terug op de definitie van ‘open data’, op hun mogelijk betalende aard (minieme kosten van de terbeschikkingstelling van een webservice, bijvoorbeeld in het geval van de KBO en databases van ondernemingen in het algemeen) of op de kwestie van licenties. We verwijzen de lezer hiervoor naar de research note van 2014.

Deze nieuwe reglementeringen zagen het licht in een context waarin nieuwe case study’s als gevolg van de verspreiding van open data tot positief gebruik hebben geleid. Een voorbeeld is het besluit eind 2023 om meteorologische gegevens in Frankrijk openlijk te publiceren om onderzoek en uitwisseling tussen onderzoekers aan te sporen “De instantie zal nieuwe technische mogelijkheden voor API’s invoeren om gratis toegang te krijgen tot haar observatiegegevens, klimatologische gegevens en radargegevens” (zie link hierboven). Zo hebben we sinds 2014 aangetoond in welke mate de terbeschikkingstelling van dynamische meteorologische en geografische gegevens in de VS, samen met het gebruik van social media, ervoor zorgde dat de gevarenzones tijdens een orkaan geïdentificeerd konden worden en hoe getroffen personen in contact kwamen met mensen die hun hulp aanboden (onderdak, etc.). Onderstaand schema toont het ideale circuit van ‘open data’ gaande van de verzameling tot het gebruik van de gegevens.

Verder in dit blogartikel bekijken we:

• vier wetgevingen (een richtlijn en drie verordeningen)
• de uitdaging van kwalitatieve gegevens en de ROI van open data

Richtlijn PSI 2019 (van toepassing in 2021, omgezet in de Belgische wetgeving in december 2023)

Deze richtlijn impliceert de integratie van de volgende nieuwe elementen in het Belgisch koninklijk besluit:

• gratis publicatie en uitwisseling, bovenop de publicaties, van de gegevens die verzameld of geproduceerd worden tijdens onderzoeksactiviteiten en gebruikt als bewijselementen in het onderzoeksproces (variabele modaliteiten naargelang het al dan niet vertrouwelijke karakter van de gegevens, van de toepassing van de GDPR, …)
• aanmoediging van de verspreiding van gegevens met grote toegevoegde waarde, dit wil zeggen waarvan het hergebruik belangrijke voordelen biedt voor de samenleving, het milieu en de economie, met name vanwege hun geschiktheid voor het ontwikkelen van diensten met toegevoegde waarde en van toepassingen, en voor het scheppen van nieuwe, hoogwaardige en fatsoenlijke banen, en vanwege het aantal potentiële begunstigden van op basis van die datasets ontwikkelde diensten of toepassingen met toegevoegde waarde” (PSI 2019). Dit betreft onder andere de volgende toepassingsdomeinen: meteorologie, aardobservatie, milieu,…

• Publicatie van de broncode van de toepassingen van de overheidsdiensten (met uitzonderingen waarmee deze publicatie kan verboden worden, onder andere in het geval van hackrisico, voor algoritmes bedoeld voor de strijd tegen sociale of fiscale fraude, in geval van schending van intellectueel recht, GDPR en ook wat betreft uitwisselingen tussen politieke instellingen en de overheden, enz.)

Data Governance Act (30 mei 2022, van toepassing 9/2023)

In 2014 hebben we voorgesteld de term ‘closed data’ te gebruiken om open data aan te duiden die privé verwerkt worden binnen een gesloten informatiesysteem (bijvoorbeeld in de strijd tegen sociale fraude). In het kader van de DGA zouden we deze benaming kunnen toepassen op de gegevens uit de overheidssector die niet ter beschikking gesteld kunnen worden als open gegevens maar die hergebruikt zouden kunnen worden in een wettelijk kader en onder specifieke voorwaarden. We denken bijvoorbeeld aan medische gegevens waarvan hergebruik kan dienen voor onderzoek, wat in België geleid heeft tot de oprichting van het Health Data Agency (HDA).
Het doel van deze reglementering is om het onderzoek te bevorderen terwijl deze gegevens in een beveiligde context worden verspreid in lijn met het werk van Kristof Verslype over pseudonymisering. Om dit doel te bereiken, moet elke EU-lidstaat één informatiepunt opzetten om informatie over gegevens die door overheidsinstanties worden beheerd, door te geven aan een gemeenschappelijk Europees register (ERPD) en zo het hergebruik ervan te vergemakkelijken.
Op basis daarvan is het ook mogelijk om “data spaces” op te richten. Dit zijn omgevingen waarbinnen gegevens beveiligd en uitgewisseld worden naargelang de behoeften. 

Data Act (13 december 2023, van toepassing 9/2025)

Het doel hiervan is om gegevens te delen, voornamelijk uit de privésector, waarbij toegangs- en gebruiksrechten uitgeklaard worden alsook de uitwisselingen die kunnen plaatsvinden tussen ondernemingen en naar de eindgebruiker. In het geval van een smartwatch bijvoorbeeld zal de gebruiker toegang kunnen vragen tot de gegevens die bijgehouden worden door de ondernemingen die het product verschaffen en deze met derden kunnen delen (bijvoorbeeld voor een herstelling).

Interoperable Europe Act (13 mars 2024, d’application 01/2025)

Deze verordening betreft “de grensoverschrijdende interoperabiliteit van netwerk- en informatiesystemen die worden gebruikt voor het verlenen of beheren van overheidsdiensten in de Unie moet worden versterkt om overheidsdiensten in de Unie in staat te stellen samen te werken en overheidsdiensten over de grenzen heen te laten functioneren”. Dat betekent onder andere een verplichte evaluatie van de interoperabiliteit van de nieuwe diensten vanaf hun ontwerp (“interoperable-by-design public services“), zowel op functioneel als semantisch vlak. Dit impliceert ook de verplichting om broncode te publiceren van de overheidsinstellingen (behalve uitzonderingen, zie hoger). Er blijft een openstaand probleem opdat deze verordening operationele resultaten kan bieden voor het leven van de Europese burgers: de harmonisering van de wetgeving tussen de EU-landen.

De uitdagingen:  kwaliteit evalueren en ROI van de ‘Open data’ 

De kwaliteit van de ‘Open data’

Onderstaand schema toont duidelijk de uitdagingen van ‘Open data’ die in 2014 minder openlijk gespecificeerd werden door de EU-overheden. Verschillende domeinen moeten interageren in verschillende talen en in een internationale context. Het geheel evolueert op een verschillend tempo. Dit kan leiden tot kwaliteitsproblemen van de gegevens (fitness for use) (3) naargelang de min of meer georganiseerde omkadering van de verspreiding van open data. Bijvoorbeeld op het Belgische federaal platform voor open data dat deel uitmaakt van BOSA zijn de leveranciers van open data verantwoordelijk voor de kwaliteit, de beschrijving en de regelmatige updates van deze data. Natuurlijk is feedback vragen aan de gebruikers over de kwaliteit van de gebruikte open data een good practice die vaak voorgesteld wordt (dat is bijvoorbeeld het geval van de KBO in België wat betreft hun open data). Op Europees niveau zijn de leveranciers van gegevens ook verantwoordelijk en ondanks de publicatie van richtlijnen blijft de kwaliteit van het Europees portaal voor open data zeer variabel.

Bron : https://dataeuropa.gitlab.io/data-provider-manual/

Als het gaat over gegevenskwaliteit merken we op dat er verschillende barometers bestaan die onderling landen vergelijken op basis van kwaliteitscriteria: bijvoorbeeld een barometer in 2018 op internationaal niveau (W3C), of de UE Open Data Maturity Assessment, een jaarverslag dat, sinds 2015 en sinds de invoering van het Europees portaal voor open data, een maturiteitsgraad voor elk land toekent op basis van een verzameling ‘vragen-antwoorden’ waaraan een min of meer willekeurige score wordt verbonden. Er wordt eveneens een ‘fact sheet’ uitgewerkt per land (bijvoorbeeld in 2023 voor België).

De ROI van ‘Open Data’

Een andere openstaande vraag betreft  de ROI die soms zeer hoog ligt en zonder uitleg toegewezen wordt aan de Open Data. Hoewel we de kosten die te maken hebben met de verspreiding van kwaliteitsvolle open data wel kunnen inbeelden, vragen we ons af wat de voordelen zijn voor de verspreiders, zoals de federale overheid? Het onderzoek van F. W. Donker van de universiteit van Delft stelt een model voor op basis van concrete maar wel uiteenlopende heterogene waarnemingen.

Dit model stelt een lus met positieve retroactie voor (‘positieve spiraal’); als de overheid gratis en kwaliteitsvolle open data verspreidt, zullen deze gebruikt worden door onderzoekers of ondernemingen die op hun beurt nieuwe activiteiten gaan creëren, die op hun beurt op termijn een bron van belastingen en financiële inkomsten betekenen voor de Staat. Andere voorbeelden worden voorgesteld in een andere context. Op die manier “Costs can be saved when re-using open data instead of paying for the data that is commercially published. In the Netherlands for example, users were charged approximately €63-€68 million for using the datasets from PSI providers such as the Dutch Chamber of Commerce, the Cadastre, the CBS (the Dutch national statistics agency) in 2009-2010. As these datasets are now freely available, users can save themselves these costs. Moreover, more people and organisations can start to use this data as the financial barrier is now removed.“. De voordelen zijn dus duidelijk voor de gebruikers als de voorheen betalende open data nu gratis worden. De voorwaarde is dat de overheid over de middelen beschikt om kwaliteitsvolle data te verschaffen die up-to-date en gedocumenteerd zijn. Dat is helemaal niet evident aangezien er geen zekerheid is dat de nieuwe gegenereerde inkomsten toegekend zullen worden aan de dienst die de Open Data verspreidt.

We kunnen vaststellen uit deze verschillende evoluties dat de bedenkingen, praktijken en de wetgeving wat betreft open data steeds matuurder worden. Open data is een topic op zich dat serieus opgevolgd moet worden in het kader van het eGovernment en dat van de burgermaatschappij of privésector. 

Het team Data Quality bij Smals staat ter beschikking om u te helpen bij het evalueren en verbeteren van de kwaliteit van de gegevens: de lezer kan meer informatie vinden over het competentiecentrum op de website van Smals (FR en NL).

Referenties

(1) Isabelle Boydens, Open Data et eGovernment. Research Note, Brussel, Smals, nr. 33, april 2014, 23 pp. (link naar het verslag en de samenvatting).

(2) Irène Bouhadana, William Gilles, Open Data. Toegangsrecht en hergebruik van openbare informatie in de datamaatschappij. Parijs, LexisNexis, 08/11/2023.

(3) Isabelle Boydens, Gani Hamiti en Rudy Van Eeckhout, A service at the heart of database quality. Presentation of an ATMS prototype. In Le Courrier des statistiques, Parijs, INSEE, 2023, nr. 6, 11 p. (gepubliceerd op 2/10/2023). Link naar het artikel.

Isabelle Boydens(*) et Isabelle Corbesier(**) 

(*) Data Quality Expert, Research Team

(**) Data Quality Analyst, Databases Team

Dit bericht is een gezamenlijke bijdrage van Isabelle Boydens, Data Quality Expert bij Smals Research en van Isabelle Corbesier, Data Quality Analysts bij Smals, Databases Team. Dit artikel is geschreven onder hun eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.

En 2014, nous publiions une research note sur les “Open Data” suite à la parution de la directive européenne PSI (Public Service Information) 2013 applicable en 2015 (1). 

Depuis lors, d’autres législations européennes sont parues ou en cours de parution. Ces nouvelles lois n’invalident rien de ce qui était d’application en 2014 (mis à part certains url de la note de recherche de 2014 qui ne sont plus à jour) mais en élargissent considérablement le champ d’application (2) que nous présentons dans cet article de blog.

Nous ne revenons pas ici sur la définition des “open data”, sur leur caractère possiblement payant (coût marginal de la mise à disposition d’un service web, par exemple dans le cas de la KBO et des bases de données d’entreprise en général) ou sur la question des licences et renvoyons le lecteur pour cela à la research note de 2014.

Ces nouvelles règlementations se sont déployées dans un contexte où de nombreuses études de cas résultant de la diffusion d’open data ont donné lieu à des exploitations positives, par exemple fin 2023, la décision de la publication ouverte des données météorologiques en France en vue de stimuler la recherche et les échanges entre chercheurs “L’établissement mettra en place de nouvelles possibilités techniques d’accès par API à ses données d’observation, climatologiques et radar, sans aucun frais” (voir lien supra). Ainsi, dès 2014, nous avions montré combien la mise à disposition de données météorologiques et géographiques dynamiques aux USA, couplée à l’utilisation des réseaux sociaux, permettait en cas d’ouragan d’identifier les zones de danger et aux personnes en mesure de proposer leur aide (hébergement, etc) d’entrer en contact avec les personnes démunies. Le schéma suivant illustre le circuit idéal des “open data” depuis la collecte jusqu’à l’exploitation des données.

Dans la suite de cet article de blog, nous envisageons :

• 4 législations (une directive et 3 actes)
• le challenge de la qualité des données et du ROI des open data

Directive PSI 2019 (d’application en 2021, transposée dans la loi belge en décembre 2023)

Cette directive implique notamment l’intégration des éléments nouveaux suivants dans l’arrêté royal belge  :

• publication gratuite et échange, en plus des publications, des données recueillies ou produites au cours d’activités de recherche et utilisées comme éléments probants dans le processus de recherche (modalités variables en fonction du caractère confidentiel ou pas des données, de l’application du GDPR, …)
• encouragement de la diffusion de données à forte valeur ajoutée, c’est-à-dire “dont la réutilisation est associée à d’importantes retombées positives au niveau de la société, de l’environnement et de l’économie, en particulier parce qu’ils se prêtent à la création de services possédant une valeur ajoutée, d’applications et de nouveaux emplois décents et de grande qualité, ainsi qu’en raison du nombre de bénéficiaires potentiels des services et applications à valeur ajoutée fondés sur ces ensembles de données” (PSI 2019). Cela concerne notamment les domaines d’application suivants : météorologie, geospatial, environnement, … 

• Publication du code source des applications des administrations publiques (avec des exceptions qui permettent d’interdire cette publication, notamment en cas de risque de hacking, pour les algorithmes destinés à la lutte contre la fraude sociale ou fiscale, en cas de violation du droit intellectuel, du GDPR ou encore, en ce qui concerne les échanges entre les instances politiques et les administrations,…)

Data Governance Act (30 mai 2022, d’application 09/2023)

En 2014, nous avions proposé d’utiliser le terme “closed data” pour désigner des open data qui feraient l’objet d’un traitement privé au sein d’un système d’information fermé (par exemple, lutte contre la fraude sociale). Dans le cadre du DGA, nous pourrions appliquer cette dénomination aux données du secteur public qui ne peuvent pas être mises à disposition en tant que données ouvertes mais qui pourraient être réutilisées dans un cadre législatif et sous des conditions spécifiques. On pense par exemple aux données médicales dont la réutilisation permettrait de favoriser la recherche, ce qui a donné lieu en Belgique à la création de la Health Data Agency (HDA).
Le but de cette règlementation est de favoriser la recherche tout en diffusant ces données dans un contexte sécurisé, dans la ligne des travaux de Kristof Verslype sur la Pseudonymisation. Pour atteindre cet objectif, chaque État membre de l’UE est tenu de mettre en place un point d’information unique censé relayer les informations concernant les données gérées par les autorités publiques vers un registre européen commun (ERPD) et ainsi faciliter leur réutilisation.
Sur cette base, il est également possible de construire des “data spaces“, environnements au sein desquels les données sont sécurisées et échangées en fonction des besoins. 

Data Act (13 décembre 2023, d’application 09/2025)

L’objectif est ici de faciliter le partage des données, notamment du secteur privé, en clarifiant les droits d’accès et d’utilisation de celles-ci ainsi que les échanges qui peuvent avoir lieu entre entreprises et vers l’utilisateur final. Dans le cas d’une montre connectée par exemple, l’utilisateur pourra demander l’accès aux données détenues par les entreprises qui fournissent le produit, et pourra partager celles-ci avec des tiers (en vue d’une réparation par exemple).

Interoperable Europe Act (13 mars 2024, d’application 01/2025)

Cet acte concerne quant à lui “l’interopérabilité transfrontière des réseaux et des systèmes d’information qui sont utilisés pour fournir ou gérer des services publics dans l’Union, afin de permettre aux administrations publiques de l’Union de coopérer et de faire fonctionner les services publics par-delà les frontières”. Cela passe notamment par une évaluation obligatoire de l’interopérabilité des nouveaux services dès leur conception (“interoperable-by-design public services“), que ce soit au niveau fonctionnel ou sémantique. Cela implique également l’obligation de publier le code source des administrations publiques (sauf exceptions, voir plus haut). Une question ouverte subsiste afin que cet acte puisse donner des résultats opérationnels pour la vie des citoyens européens : l’harmonisation de la législation entre pays de l’UE.

Les challenges :  évaluer la qualité et le ROI des “open data” 

La qualité des “open data”

Le schéma suivant illustre bien les challenges soulevés par les “open data” qui avaient été moins ouvertement spécifiés par les autorités de l’UE en 2014. Il s’agit de faire interagir différents domaines, dans différentes langues et dans un contexte international, le tout évoluant à un rythme hétérogène. Cela peut mener à des problèmes de qualité de données (fitness for use) (3) en fonction de l’encadrement plus ou moins organisé de la diffusion des open data. Par exemple, sur la plateforme fédérale belge des open data, dépendant de BOSA, ce sont les fournisseurs des open data qui ont la responsabilité de la qualité de celles-ci, de leur description et de leur mise-à-jour régulière. Naturellement, demander aux utilisateurs un feed back concernant la qualité des open data utilisées constitue toujours une bonne pratique souvent proposée (c’est le cas de la KBO en Belgique, par exemple, s’agissant de leurs open data). Au niveau européen également, ce sont les fournisseurs de données qui sont responsables, et malgré la publication de guidelines, la qualité du portail européen des open data reste très variable.

S’agissant de la qualité des données, notons qu’il existe différents baromètres comparant entre eux des pays sur la base de critères de qualité; par exemple, un baromètre en 2018 au niveau international (W3C), ou l’UE Open Data Maturity Assessment, rapport annuel qui, depuis 2015 et la mise en place du Portail européen des données, attribue un niveau de maturité à chaque pays sur la base d’un ensemble de “questions-réponses” auxquelles sont associés un score de façon plus ou moins arbitraire. Une “fact sheet” est également élaborée par pays (par exemple en 2023, pour la Belgique).

Le ROI des “Open Data”

Une autre question ouverte concerne le ROI parfois très élevé attribué aux Open Data sans explication aucune de celui-ci. Si l’on imagine bien les coûts liés à la diffusion d’open data de qualité, quels sont les bénéfices pour les diffuseurs, tels que l’administration fédérale ? Les recherches de F. W. Donker de l’Université de Delft proposent un modèle sur la base d’observations concrètes mais forcément hétérogènes.

Ce modèle propose une boucle avec rétroaction positive (“cercle vertueux”) ; si l’administration diffuse des open data gratuites et de qualité, celles-ci seront utilisées par des chercheurs ou des entreprises qui, à leur tour, vont créer de nouvelles activités, lesquelles constitueront, à terme, des sources de taxes et rentrées financières pour l’État. D’autres exemples sont proposés, dans un autre contexte. Ainsi, “Costs can be saved when re-using open data instead of paying for the data that is commercially published. In the Netherlands for example, users were charged approximately €63-€68 million for using the datasets from PSI providers such as the Dutch Chamber of Commerce, the Cadastre, the CBS (the Dutch national statistics agency) in 2009-2010. As these datasets are now freely available, users can save themselves these costs. Moreover, more people and organisations can start to use this data as the financial barrier is now removed.“. Les bénéfices sont donc évidents pour les utilisateurs si les open data autrefois payantes deviennent gratuites, à condition que l’administration ait les moyens de fournir gratuitement des données de bonne qualité, bien mises à jour et documentées, ce qui est loin d’être évident puisque rien ne garantit que les nouveaux revenus générés seront attribués au service en charge de la diffusion des Open Data.

Nous pouvons conclure de ces différentes évolutions que la réflexion, les pratiques et la législation autour des open data sont devenues de plus en plus matures. Il s’agit d’un topic à part entière à suivre sérieusement dans le cadre de l’egovernement ainsi que dans celui de la société civile ou privée. 

La team Data Quality chez Smals est disponible pour toute aide en vue d’évaluer et d’améliorer la qualité des données : le lecteur trouvera plus d’information sur son centre de compétence sur le web site de Smals (FR  et NL).

Références

(1) Isabelle Boydens., Open Data et eGovernment. Research Note, Bruxelles, Smals, n° 33, avril 2014, 23 pp. (lien vers le rapport et l’abstract).

(2) Irène Bouhadana, William Gilles, L’Open Data. Droit d’accès et de réutilisation des informations publiques dans la société des données. Paris, LexisNexis, 08/11/2023.

(3) Isabelle Boydens., Gani Hamiti et Rudy Van Eeckhout., A service at the heart of database quality. Presentation of an ATMS prototype. In Le Courrier des statistiques, Paris, INSEE, 2023, n°6, 11 p. (publié le 2/10/2023). Lien vers l’article.

Isabelle Boydens(*) et Isabelle Corbesier(**) 

(*) Data Quality Expert, Research Team

(**) Data Quality Analyst, Databases Team

Ce post est une contribution collective d’Isabelle Boydens, Data Quality Expert chez Smals Research et d’Isabelle Corbesier, Data Quality Analysts chez Smals, Databases Team. Cet article est écrit en leur nom propre et n’impacte en rien le point de vue de Smals.

• “Key questions for the board” uit J.B. Mantas, Intelligent Approaches to AI
• Gartner toolkit: Selecting and Prioritizing AI Use Cases
• De Data Protection Impact Assessment template op gdpr.eu (geen officiële EU-publicatie)
• Het ontwerp van een Trustworthy AI Assessment list, in voorbereiding door de EU High Level Expert Group on AI
• Het overzicht tools voor ethiek van het Kenniscentrum Data&Maatschappij
• De Data Project Checklist van Fast.ai
• …

De ene vragenlijst is technisch, de andere descriptief, nog andere proberen zoveel mogelijk in cijfertjes te gieten. Dé ultieme checklist maken is onbegonnen werk, want veel hangt af van wie het doelpubliek is van de analyse: de projectleider vindt andere dingen belangrijk dan de CEO, de aandeelhouder of de eindgebruiker.

Goed beseffend dat nòg een extra vragenlijst dat probleem niet oplost, kunnen we het toch niet laten om zelf ook enkele overwegingen te lanceren die wij maken in ons werk bij overheidsdiensten. Zonder te claimen volledig te zijn, 5 kernvragen die wij ons vaak stellen:

1. Hoe zou je het probleem oplossen zonder AI?

Is er wel een goede usecase, en vereist die wel een AI-oplossing? Te vaak wordt AI voorgesteld als hét toverstokje dat alle problemen oplost vanuit het niets. Was dat maar waar: in het echte leven zijn AI-systemen moeilijk om goed geconfigureerd te krijgen, vragen ze constante opvolging en monitoring, en veel werkuren door specialisten. Een dure zaak, daarom kan het geen kwaad om eerst grondig na te gaan: wat is eigenlijk het probleem dat we willen oplossen? Is dat welgedefinieerd en goed afgelijnd? Wat is de situatie vandaag en waar willen we naartoe? Weegt de geschatte ROI van een AI-oplossing wel op tegen die van een aanpak met traditionele IT of zelfs manueel werk? Heb je die andere opties überhaupt overwogen?

2. Zijn de succescriteria (KPIs) goed gekozen, gedefinieerd en meetbaar?

Een enkel AI-systeem lost veelal een klein, welomschreven probleem op. Allerlei criteria kunnen aangewend worden om te meten of dat ook voldoende goed gebeurt: precisie en recall, de tijdspanne nodig voor de berekening, de reductie in manueel werk, … Wat men ook hanteert als KPIs, goede meetbaarheid en opvolgbaarheid zorgen voor gemakkelijker monitoren of kwantificeren van de resultaten. Juist meten is niet noodzakelijk gemakkelijk. Welke accuraatheid wordt verwacht van het AI-systeem, wat is “fout” en wat is “correct”? Bij die vergelijkingen mag men gerust de kanttekening toevoegen dat ook mensen fouten maken als zij dezelfde taak manueel zouden uitvoeren. Is er al eens gemeten hoe vaak dat gebeurt en wat de gevolgen daarvan zijn? Vanaf wanneer zou het AI-systeem ook effectief tot verbetering leiden in de praktijk?

3. Welke praktische beperkingen zijn er?

Elk bedrijf dat niet dezelfde cashpositie heeft als pakweg Amazon of Google, past best zijn verwachtingen inzake AI wat naar verhouding aan. Talent is schaars, zeker als iemand naast AI en data science ook nog vertrouwd moet zijn met projectmanagement en de praktische aspecten van softwareontwikkeling. Zelfs met wat geluk op HR-vlak, is technologische infrastructuur nog steeds niet gratis. De trial-en-error methodiek die de ontwikkeling van AI-systemen vaak kenmerkt, vergt een zekere financiële ademruimte – zeker bij toepassingen waarbij 1 iteratie van 1 trainingsproces al tot een aardige energiefactuur leidt. Daarnaast zijn er ook de ethische en legale beperkingen, bijvoorbeeld inzake gebruik van gevoelige gegevens. Veel van de software aan de basis van een AI-systeem zal van derde partijen afkomstig zijn, of gebruikmaken van open source componenten of een (public) cloud – wat risico’s met zich meebrengt aangaande stabiliteit, onderhoudbaarheid, ondersteuning op langere termijn, licentiëring, confidentialiteit van gegevens, …

4. Zijn er genoeg middelen voor deployment, monitoring, onderhoud?

Een AI-systeem bouwen is 1 ding, het in productie zetten is nog iets anders. Er moeten heel wat waters doorzwommen worden voordat een stuk code ontwikkeld op enkele laptops uiteindelijk klaar is om 24/7 blootgesteld te worden aan de buitenwereld. De extra overhead gevormd door CD/CI, backups, testing, code review, etc. is onmisbaar voor de langere termijn maar kost allemaal tijd en geld. AI-projecten zijn anders dan klassieke softwareprojecten in die zin dat het niet afgelopen is eens de software is opgeleverd. Integendeel, bij oplevering begint het pas, en start een fase van actieve monitoring die schier eindeloos kan zijn: blijft de software wel doen wat ervan verwacht wordt in de buitenwereld? Zeker als nieuwe data wijzigt van karakter, zal je vaak actief moeten bijsturen.

5. Hoe transparant is dat allemaal?

De GDPR legt beperkingen op aan systemen die automatisch beslissingen nemen: er moet altijd de mogelijkheid zijn om de beslissing te laten (her)bekijken door een mens (art. 22). In het gehele AI-beleid dat de EU hoopt te voeren is transparantie een sleutelwoord, waarmee de EU tracht zich te onderscheiden van andere grootmachten. Het kunnen uitleggen waarom een AI-systeem tot een bepaald resultaat komt is belangrijk voor die transparantie, maar is niet noodzakelijk evident wanneer de trainingsdata onoverzichtelijk groot is, misschien niet onder eigen beheer ligt, of wanneer het aantal parameters van het model onoverzichtelijk groot is. Je wil ook niet met je mond vol tanden staan als ooit een journalist of wakkere burger je voorschotelt: is er een ethische evaluatie en Data Privacy Impact Assessment gebeurd, en waar kan ik mijn data raadplegen en beslissen wat ermee gebeurt?

Praktisch

Veel analyses kunnen erg langdradig zijn, dagen in beslag nemen en leiden tot rapporten van 50 bladzijden die niemand achteraf nog leest. Ook is niet alles even relevant voor elke usecase: een AI die een keukenrobot aanstuurt heeft niet dezelfde KPIs of foutentoleranties als eentje die een pacemaker aanstuurt. Om het overzicht te bewaren kan het handig zijn om, voor de eigen usecases, de belangrijkste vragen uit verschillende analyses mee te nemen in een eigen assessment, waarvan de resultaten bijvoorbeeld in een grafiek zoals deze kunnen weergegeven worden:

Dit was uiteraard maar een greep uit de bedenkingen die men kan maken bij de start van een nieuw AI-project. Zulke denkoefening, vooraleer geld en middelen in de uitvoering te steken, is de investering meestal wel dubbel en dik waard.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Wat is RPA?

Robotic Process Automation (RPA) is een manier om (elektronische) processen te automatiseren op basis van de gebruikersinterface van bestaande toepassingen. Het is een volledig softwarematige manier van werken (er komen dus geen echte, fysieke robots bij kijken), waarbij een toepassing (de RPA oplossing) zal instaan voor het bedienen van andere, onderliggende applicaties. Een software robot, of kortweg “bot”, simuleert daarbij de muisclicks en toetsenbordaanslagen van een eindgebruiker. Je ziet dus als het ware het scherm vanzelf bediend worden en veranderen, alsof er een onzichtbare gebruiker aan het werk is met de muis en het toetsenbord.

RPA wordt vaak beschouwd als een onderdeel van het bredere AI. Of dit daadwerkelijk zo is, laten we in het midden, maar alleszins kunnen we zeggen dat de technologie in principe geen “echte” artificiële intelligentie bevat (in zoverre men deze kan definiëren). RPA is gebaseerd op regels en procedurele logica, typisch door de mens geprogrammeerd en zeker niet door de computer “uitgevonden” of op basis van heel veel data “geleerd“. Het is wel zo dat RPA vaak in combinatie met AI wordt gebruikt, doordat er b.v. in een bepaalde stap van het process een AI wordt aangeroepen om een bepaalde beslissing te nemen, of anderzijds omdat er b.v. een RPA bot wordt aangeroepen nadat een intelligente chatbot geconcludeerd heeft dat een klant een bepaalde procedure wenst te laten uitvoeren.

We kunnen dan nog het onderscheid maken op basis van wáár dit werk precies gebeurt. Enerzijds is het mogelijk de bot te installeren op een machine bij een eindgebruiker. Dit kan dan worden gebruikt om op bepaalde momenten een aantal acties automatisch en snel uit te voeren, tussen de bezigheden van de gebruiker door. Op die manier kan er bijvoorbeeld worden gezorgd dat moeilijk te automatiseren werk, waarbij de eindgebruiker bepaalde overdachte beslissingen moet nemen, manueel blijft, terwijl rechttoe rechtaan taken (die door de gebruiker als repetitief en vervelend kunnen worden bestempeld) door de robot worden overgenomen. Deze manier van werken wordt soms ook “attended RPA” genoemd.

Anderzijds hebben we dan “unattended RPA”. Hier zal de bot op een aparte pc worden geïnstalleerd (b.v. een virtuele machine op een server) om een aantal taken volledig automatisch, zonder supervisie, uit te voeren. Het zal dan gaan om taken die een zekere tijd in beslag nemen (of waarvan er grote hoeveelheden herhalingen moeten worden uitgevoerd) en die geen tussenkomst vergen van de eindgebruiker.

Hoe?

Hoe bouwt men zo een RPA bot precies? Typisch kunnen we aan de hand van een grafische notatie een sequentie van handelingen definiëren, waarbij we aangeven, aan de hand van bepaalde filtercriteria, welk schermelement we precies willen aansturen, en wat we er precies mee willen doen (via de muis of het toetsenbord). Ook flowcharts zijn daarbij een voorbeeldnotatie. Sommige RPA tools laten ook toe om een soort van opnamefunctionaliteit te gebruiken: de computer zal dan a.h.w. proberen na te bootsen wat je hem eerst manueel hebt voorgedaan.

Geschiedenis en Gelijkaardige zaken

RPA kan eigenlijk gezien worden als spirituele opvolger van “Integration at the Glass“. Ook deze technologie diende immers om zaken te automatiseren op UI niveau. De focus lag hierbij evenwel iets anders: men was meer op het integreren van onafhankelijke toepassingen gericht, onder toezicht van de eindgebruiker. Desalniettemin waren automatisaties reeds mogelijk. De huidige RPA tools zijn uiteraard wel geëvolueerd: men legt sterk de focus op automatisatie via een gebruiksvriendelijke tool en met ondersteuning voor meerdere soorten diagrammen, aan de hand waarvan het proces grafisch kan worden voorgesteld.

Daarnaast bestaan er reeds lange tijd allerlei scripting talen waarmee men taken kan automatiseren. Deze komen voor in verschillende vormen. Vooreerst zijn er de typische macro’s, zoals b.v. in Ms Excel, waarmee men binnen één toepassing zaken kan gaan automatiseren. Daarnaast zijn er echter ook meer algemene talen, waarmee men generische toepassingen kan bedienen. Een voorbeeld hier is AutoIt voor Windows, of de open source tool Selenium (waarin men met verschillende programmeer-talen kan werken), die zich vooral focust op het testen van webtoepassingen. RPA zal typisch zaken verenigen uit al deze soorten software: men biedt een zeer brede ondersteuning (zowel desktop als web), met opnamefunctionaliteit en een grafische manier om het proces weer te geven.

En de Toekomst?

RPA is verwant met Business Process Management (BPM). De P in beide acroniemen staat dan ook telkens voor “Process”. Het valt dus te verwachten dat beide soorten technologieën stilaan naar elkaar zullen toegroeien. Men zal dan totaaloplossingen krijgen voor het beheer van processen, waarin ruimte is om zowel de menselijke taken op te vangen, als om zaken op een automatische manier te doen, en dit in een ruimer kader, met inbegrip van beheer en orkestratie.

Daarnaast komt er ook steeds meer AI aan te pas in deze software suites. Ook dit zal dus meer en meer ‘normaal’ worden. Steeds vaker zal men “slimme” suggesties kunnen krijgen voor de volgende stap in een proces, of sterker nog: volledige processen zullen door het AI a.h.w. “ontdekt” en eventueel ook gestroomlijnd kunnen worden.

Voor- en Nadelen

Snelle ROI

Het grote voordeel van RPA is dat men zaken kan automatiseren zonder bestaande systemen te moeten aanpassen of integreren, wat typisch een moeilijke oefening is. Bovendien is de technologie vrij gebruiksvriendelijk en leidt ze snel tot resultaten. Men kan dus snel een goede Return on investment (ROI) bekomen. Daarnaast is het ook zo dat, eens een process door een robot wordt uitgevoerd, het steevast op dezelfde manier zal worden uitgevoerd. De consistentie zal hoger liggen dan bij uitvoering door menselijke werkers. Die laatste zijn trouwens typisch ook erg tevreden, want RPA neemt de “domme”, repetitieve taken van hen over, zodat ze zich kunnen focussen op het interessantere deel van hun takenpakket. Zogenaamde “power users”, op hun beurt, zijn soms ook in staat om zélf een RPA bot te ontwikkelen, dus de technologie zorgt zeker voor opportuniteiten. Ten slotte, indien een RPA robot faalt, kan er meestal worden overgeschakeld op een manuele uitvoering van het werk. De taak kan dus nog steeds worden uitgevoerd, zij het typisch trager. Dit kan men zien als een vorm van graceful degradation.

Nood aan Governance

Nadelen zijn er echter ook: RPA oplossingen zijn dikwijls slechts een tijdelijke stoplap, totdat er een oplossing ten gronde kan worden gevonden. Dit laatste zal inhouden dat men bestaande systemen beter zal integreren en gebruiksvriendelijker zal maken, waardoor bepaalde taken sowieso door de applicatie kunnen worden opgevangen. Het gebruik van RPA mag trouwens ook geen excuus worden om de software die ermee wordt aangestuurd, daarna niet meer te verbeteren. Sterk in verband hiermee is er bovendien nog een ander nadeel: de RPA robot is gevoelig voor veranderingen in de gebruikersinterface van onderliggende toepassingen: meestal zal hij niet meer functioneren en dus onderhoud nodig hebben, wanneer men in meer of mindere mate wijzigingen aanbrengt aan de gebruikte toepassingen. Daarnaast moet men ervoor uitkijken dat een wildgroei van RPA bots geen onoverzichtelijk kluwen wordt. Enterprise versies van RPA software, die orkestratie toelaten, zijn dan zeker geen overbodige luxe.

Besluit

RPA technologie kan in bepaalde gevallen soelaas brengen aan eindgebruikers die zich overstelpt zien met repetitief werk. De ROI is vaak sterk en de software om de robots mee te bouwen is matuur. Tegelijk moet men ook kritisch zijn in de keuze van use case. Het beste is om RPA enkel toe te passen daar waar men nog geen andere, meer fundamentele plannen heeft, op relatief korte termijn, om zaken te integreren of vervangen. Men moet er bovendien goed op letten RPA eerder chirurgisch in te zetten om de grootste pijnpunten aan te pakken, en geen wirwar van tientallen of honderden bots te creëren, die voor hun eígen onderhoudsproblematiek zorgen. Een goede tip kan zijn om reeds bij het invoeren van een RPA-oplossing ook al aan de zogenaamde phase-out te denken.

RPA zal tegenwoordig geregeld worden voorgesteld door externe consultancy bedrijven. Voor deze ondernemingen is de technologie namelijk ideaal: de ontwikkeling kan snel gebeuren en al gauw is een sterke ROI aan te tonen. Tegelijk moet men geen moeilijke integratieoefeningen oplossen en hoeft men zich in het algemeen geen grote zorgen te maken over reeds bestaande toepassingen (die men zelf niet heeft ontwikkeld). Deze hoeven enkel aangestuurd en niet aangepast te worden. Het is belangrijk dat de klant zich bewust is van het onderhoudsvraagstuk. Consultancy om RPA in te voeren kan zeker nuttig zijn, maar ook hier geldt: drinken met gezond verstand, (en met mate) !

Quick Review

Van UiPath, één van de marktleiders wat betreft RPA technologie, maakten we een Product Quick Review, die vind je hier. In de review bespreken we ook een tweetal voorbeelden van wat we er zoal mee kunnen automatiseren.

Nieuwe bevoegdheden incorporeren heeft grote gevolgen op organisatorisch, juridisch en ICT-vlak. Het brengt grote uitdagingen met zich mee, maar hierop gaan we niet dieper in. Dit artikel gaat over nieuwe informatieproblemen die ontstaan als gevolg van de herschikking. Het is niet de bedoeling om hier een oplossingsvoorstel aan te reiken, wel enkele minimale eigenschappen.

1: Moet u als burger zelf achterhalen wie verantwoordelijk is voor welke bevoegdheid?

Als een bevoegdheid niet volledig is overgedragen, dan zijn zowel de G&G als het federale niveau verantwoordelijk voor onderdelen van het proces. Wie als huisarts wil werken, bijvoorbeeld, moet zijn diploma laten erkennen door de G&G, een visum bekomen bij de FOD Volksgezondheid en een RIZIV-nummer bij… het RIZIV.

Idealiter zijn zulke processen volledig transparant voor de burger en hoeft deze geen rekening te houden met alle achterliggende complexiteit. Voor dit specifieke geval wordt trouwens in het kader van het project Cobrha+ gewerkt aan een volledige procesondersteuning. Het afleveren van een verblijfs- en werkvergunning (Single Permit) is een ander voorbeeld van een proces waarbij zowel de G&G als het federale niveau betrokken zullen zijn.

Procesondersteuning is nog maar de eerste stap van een oplossing. De burger moet ook kunnen achterhalen wie op welk moment zijn dossier behandelt. Een online statusopvolging voor de burger zou dus een deel van de oplossing moeten zijn.

2: U verhuist naar een ander landsdeel?

Wanneer een burger of een onderneming verhuist naar een ander landsdeel, kan het gevolg zijn dat lopende procedures worden stopgezet in het ene landsdeel, en eventueel herstart in het andere. Het zal daarbij wenselijk zijn dat de ‘oude gegevens’ worden overgemaakt aan de nieuwe instantie die zal instaan voor de opvolging van het dossier, of dat ze consulteerbaar worden gesteld. Het is zeer wenselijk om daarbij de continuïteit en de meeneembaarheid van rechten te garanderen.

3: U woont in Brussel?

Als inwoner van Brussel beslist u bijvoorbeeld zelf of u aansluit bij de Vlaamse Sociale Bescherming. Indien er vergelijkbare beschermingsmechanismes op vrijwillige basis ontstaan bij de overige G&G, dan is het risico reëel dat sommige personen helemaal nergens aangesloten zullen zijn, en dus geen enkele bescherming genieten. Typisch zullen dit niet de sterkste personen binnen de samenleving zijn.

Omgekeerd bestaat het risico dat inwoners van Brussel aansluiten bij meerdere beschermingsmechanismes. De kans is dan reëel dat deze personen meerdere tegemoetkomingen zullen ontvangen.

Doordat het overnemen van een bevoegdheid nu al grote uitdagingen met zich meebrengt, kunnen de voorgaande drie problemen typisch nog niet meteen aangepakt worden. Dit betekent ook dat het dus nog niet te laat is om generieke oplossingen uit te werken. Hierbij is het belangrijk dat burgers en ondernemingen géén hogere administratieve lasten moeten dragen. En dat zoveel mogelijk gestreefd wordt naar een geïntegreerde dienstverlening over de verschillende bestuursniveaus heen.

Een generieke oplossing kan de totale beheerskosten beperken. Tegelijk biedt een generieke oplossing meer garanties op de meeneembaarheid van de opgebouwde rechten. Dit vraagt loyauteit van alle betrokken instellingen. En het kan nooit de bedoeling zijn dat een generieke oplossing de mogelijkheid tot het voeren van een eigen beleid door de diverse overheden ook maar enigszins beperkt.

Op weg naar een oplossing?

Een oplossing moet hoe dan ook beslist en afgestemd worden door de vertegenwoordigers van alle betrokken bestuursniveaus. Hun voorstel zal volledig rekening moeten houden met de bevoegdheden en verantwoordelijkheden die nu aan elk bestuursniveau zijn toegekend.

Beheersprincipes: Wie zal er toezien op het beheer van de informatie-uitwisseling? Wordt er gewerkt met een beheerscomité? Wie wordt daarin vertegenwoordigd en wie zit het voor? Wat zijn de taken? Denk aan het bepalen van wie toegang krijgt tot welke informatie. Wie bewaakt de evolutie van het uitwisselingsplatform? Wie staat in voor de operationele werking? Deze vragen moeten een antwoord krijgen, wil men komen tot een goed functionerend samenwerkingsmodel. Principes kunnen worden vastgelegd in een samenwerkingsakkoord tussen alle betrokken partijen. Het kan niet de bedoeling zijn om een wildgroei aan beheerscomités te laten ontstaan. Wil men onnodige kosten vermijden en de garantie op een uniforme dienstverlening bieden, dan dient hun aantal beperkt te worden – bijvoorbeeld één comité per sector.

Principes over dossierbeheer en opvolging: Hoe verloopt de identificatie van dossiers? Organisaties kunnen fusioneren, zodat de hoofdzetel opeens in een ander landsdeel kan liggen. Dit zal een invloed hebben op de identificatie van oude en nieuwe dossiers.

Wanneer en hoe worden de ketenpartners op de hoogte gebracht van een nieuw dossier? Welke informatie moet centraal bijgehouden en decentraal ontsloten worden? Bij zoveel vragen is het belangrijk dat er één keer een referentie-oplossing wordt uitgewerkt, waarbij deze oplossing voor elke nieuwe informatiestroom wordt hergebruikt.

Een referentie-oplossing moet alle scenario’s in overweging nemen. Het is bijvoorbeeld niet voldoende om de genomen beslissingen consulteerbaar te stellen, maar ook de feitelijke gegevens die aan de basis lagen van de genomen beslissing. Het uitwisselen van feitelijke gegevens vermijdt – volgens het only once-principe – dat burgers of ondernemingen bij een verhuis naar een ander landsdeel eerder verstrekte informatie opnieuw moeten doorgeven.

Om de gegevensstromen te organiseren lijkt een centraal verwijzingsrepertorium een noodzaak. Zo weten we welke overheidsinstantie informatie heeft over welke persoon of organisatie. Het zal ook een rol spelen bij het actualiseren van de gegevens. Via het repertorium kan worden nagegaan wie er een melding moet krijgen van nieuwe informatie. Daarnaast is een verwijzingsrepertorium van groot belang bij een vrijwillige aansluiting, om na te gaan of iedere burger op zijn minst ergens verzekerd is, en eventueel dubbel verzekerd is.

De status van een dossier lijkt een gegeven dat best centraal wordt bijgehouden. Dit zou het gemakkelijker maken om onmiddellijk een zicht te hebben op de actuele situatie. Waar kan de burger terecht met vragen? Zeker voor processen over meerdere organisaties, lijkt het aangewezen om te voorzien in één aanspreekpunt.

Technische principes : Wat is de referentie-architectuur voor het uitwisselingsplatform? Welke basisdiensten worden door het uitwisselingsplatform ter beschikking gesteld? Minimaal is dit een publicatie-, consultatie-, notificatie- en subscriptiefunctie (subscriptie: aangeven voor welke wijzigingen men een notificatie wenst te ontvangen). Welk technisch formaat krijgen de uit te wisselen berichten? Het lijkt aangewezen om te vertrekken vanuit bestaande systemen en standaarden, die met een minimale aanpassing kunnen worden hergebruikt.

Dit lijstje is slechts een eerste, erg onvolledige aanzet. Voorstellen formuleren, is een oefening die in samenwerking met alle betrokken bestuursniveaus hoort te gebeuren. Het is geen eenvoudige oefening, maar ze kan vermijden dat voor elk project afzonderlijk een oplossing wordt uitgewerkt. Telkens een nieuwe oplossing uitwerken kost niet alleen veel tijd en geld, maar heeft ook als risico dat er sterk van elkaar afwijkende gegevensstromen ontstaan die de complexiteit enkel doen toenemen.

Avec, comme à l’habitude, sur des sujets aussi stratégiques, une tendance malheureuse à polariser les discussions. Cette polarisation n’a pas lieu d’être : chacune de ces approches a sa part de valeur ajoutée pour le projet.

Je vais m’attacher ici à les expliquer. Rapidement bien entendu – Nous sommes dans le cadre d’un blog.

Mais commençons par rappeler les définitions de broker et portal.

Broker vs. Portal

La définition d’un broker est un peu difficile à établir. Pour s’en convaincre il suffit de regarder les discussions sur différents forums qui s’intéressent à ce qui distingue un broker d’un enterprise service bus (ESB).
Faisons simple et considérons le broker comme un moyen de transférer des données via des messages dans le backend (la partie non visible par les utilisateurs).

Dans le cadre qui nous occupe, un portal peut être vu comme un site web destiné à agréger les accès à divers autres sites web sous-jacents. Un point d’accès central en quelque sorte.

Le projet

Sans le citer nommément, voici maintenant les fondamentaux du projet.

– des acteurs privés, fournisseurs de données, et des acteurs publics, consommateurs de données, avec chacun des besoins propres ;
– les fournisseurs de données sont plusieurs dizaines voire plusieurs centaines ;
– les consommateurs de données sont au nombre de 5 ;
– pour fournir les données, les fournisseurs de données doivent utiliser l’application de tiers (au nombre de 4) – ces tiers sont eux-mêmes fournisseurs d’une partie des données ;
– les consommateurs de données exploitent celles-ci à des fins de contrôle ;
– une obligation de résultats rapide.

La voie initialement choisie a consisté à mettre en place plusieurs bus de données en cascade pour transférer les données des fournisseurs vers les consommateurs.

La première difficulté rencontrée avec cette seule approche est d’arriver à mettre tous les acteurs d’accord sur les différents types de messages à prévoir et sur leur contenu, d’autant plus que les fournisseurs de données vivent le projet comme une obligation (ils doivent se soumettre aux obligations imposées).

Autre difficulté d’importance : les propriétaires des applications doivent chacun compléter leur application avec des écrans de capture pour collecter l’ensemble des données requises par tous les consommateurs. Il faut donc coordonner les efforts de 4 équipes de développement sur des fonctionnalités qui en fait ne constituent pas une valeur ajoutée pour leurs propriétaires (des acteurs du projet finalement gênés dans l’exercice de leur métier par ces obligations).

La difficulté est d’autant plus grande que les 5 consommateurs de données ont des besoins spécifiques. Il s’agit donc de gérer 5 x 4 relations entre partenaires.

Dans un tel contexte, il est évident que les maintenances corrective et évolutive posent de sérieux problèmes, en termes d’obtention des consensus sur les évolutions nécessaires des différentes applications et sur la gestion des plannings de réalisation et de tests. Les disponibilités sont en effet variables selon les acteurs, avec pour corollaire que de manière quasi permanente, au moins un des acteurs est attendu par tout ou partie des autres.

L’addition de toutes ces difficultés a conduit à un allongement considérable du projet.

Approche combinée Broker plus Portal

Après de longs mois de tergiversations multiples, la réflexion suivante s’est imposée : pourquoi ne pas faire en sorte que chacun des partenaires soit responsable de collecter les données dont il a seul l’usage.
Et d’ensuite les partager, via le broker, s’il s’avère que dans le cours du projet, en contradiction avec les analyses de départ, elles peuvent en intéresser d’autres.

Permettre à chacun de développer sa propre application web lui permettant d’obtenir les données qui lui sont propres (comprenez qui n’intéresse aucun des autres consommateurs de données), en complément au broker, a donc finalement été considéré comme une option intéressante.
Sous trois conditions :
– ne pas vouloir obtenir par ce canal une information déjà disponible par un autre canal, ce qui obligerait le fournisseur de la dite information à de l’encodage multiple (respect strict du principe “only once”) – donc, si l’information est déjà disponible via le broker, elle doit être récupérée par ce biais;
– mettre à disposition un seul point d’accès aux différentes applications web via la notion de portal ;
– ne pas obliger les fournisseurs de données à des login multiples (principe du “single-sign-on”).

Cette approche combinée broker plus portal concilie l’ indépendance des acteurs, gage de leur efficacité individuelle, et partage des données. L’approche permet en effet de réduire considérablement les besoins de concertation sur les développements à réaliser et simplifie également la gestion des plannings.

Comme annoncé en début de ce blog, sur base de ces quelques considérations, il est donc facile de conclure que broker et portal sont bien des approches complémentaires.

Un conseil à ce stade : dès le début du projet, établissez un diagramme de contexte complet, dans lequel vous faites apparaître les flux de données entre partenaires. En complément, établissez des fiches qui donnent le détail de ces flux. Vous prendrez ainsi immédiatement conscience de qui est vraiment intéressé par quelles données.

Aspects particuliers

Voyons maintenant quelques aspects particuliers.

Lors de l’échange de données entre partenaires, une problématique de première importance est incontournable : la gestion des anomalies. Sur ce point, le portal apporte son lot d’avantages, en évitant d’impliquer tous les intermédiaires dans cette gestion souvent complexe. En effet, grâce au portal les retours d’anomalies peuvent être gérés sans dépendances vis-à-vis des tiers qui gèrent le broker. La gestion des anomalies est un vaste sujet qui mériterait à lui seul un blog séparé (et bien plus encore).

L’utilisation du format XML, et la définition d’un format canonique pour les échanges, est aujourd’hui un must pour le succès du broker.

En nous appuyant sur les schémas XSD nous avons pu développer un outil de génération de cas de test qui nous a permis de tester rapidement nos développements, sans attendre que nos partenaires soient déjà à même de nous envoyer des messages. Cette initiative a permis de gagner énormément de temps en s’affranchissant de nombreuses dépendances temporelles dans le projet.

A titre d’information cet outil a été développé en s’inspirant de la philosophie des moteurs de règles (externalisation poussée des logiques d’alimentation des templates de messages sous la forme de règles). Il possède de ce fait un caractère générique non négligeable.

A l’issue de ce projet nous pouvons émettre la recommandation suivante : dans un projet d’intégration impliquant des partenaires multiples, obligés de collaborer mais avec des centres d’intérêts plutôt éloignés, il faut veiller à limiter au maximum les dépendances en matière de développement. C’est la meilleure garantie de rester maîtres des délais de réalisation, de maîtriser dans le temps l’évolution du système global et de garder les coûts de maintenance sous contrôle.

La combinaison broker plus portal aide grandement à satisfaire à cette stratégie.

S’agissant de l’approche portal, pour être complet et ne rien cacher des difficultés rencontrées, il nous faut encore ajouter que la mise en place d’un mécanisme de single-sign-on reste un exercice souvent difficile. La diversité des technologies utilisées par les différents partenaires et les différences de niveau de compétences sur le sujet expliquent cela.

In een vorige blog had ik het reeds over het uitbesteden van gemeenschappelijke zaken, nodig voor meerdere ondernemingen, applicaties & diensten, aan een derde, hierin gespecialiseerde partij. Hetgeen deze laatste partij doet, noemen we “horizontale dienstverlening”; men opereert namelijk in een horizontale markt.

Nu wil ik graag enkele voorbeelden geven van hoe de overheid hetzelfde zou kunnen doen via een data-centric eGovernment (bovenop de vele zaken die ze reeds doet, met b.v. sterke eID authenticatie, de G-Cloud, en het eHealth platform).

Een aantal voorbeelden:

1. Chipkaarten

   In diezelfde vorige blog vernoemde ik de voordelen die er zouden ontstaan indien we het beheer van chipkaarten zouden afzonderen bij één horizontale chipkaartenbeheerder, en alle gebruikers van deze kaarten dan hiervan gebruik zouden kunnen maken. In een vergevorderd stadium zou het zo in principe zelfs mogelijk worden dat we via één enkele chipkaart van allerlei diensten, aangeboden door verschillende bedrijven (overheid of privé) gebruik kunnen maken, en we dus niet met een veelheid van de plastieken ondingen in onze portefeuille zouden moeten rondlopen. Dergelijke dienstverlener zou zelfs via een SaaS platform ook aan kleine ondernemingen een paar opties kunnen geven om b.v. aan een bestaande QR code op de chipkaart van een persoon, een klantenkaart te koppelen. Kortom, “one card to rule them all“. Misschien zou de overheid dit kunnen aanbieden via de eID?

2. “Waar-woon-ik-as-a-Service”

   Een eenvoudig, maar krachtig voorbeeld van nuttige en toch min of meer private data, zijn adressen en adreswijzigingen. Wat als elke adreswijziging die iemand onderging, onmiddellijk door alle (overheids-)diensten, door de post, door koeriers, en eventueel door een resem andere belanghebbenden was geweten? Dit scenario werkt als volgt:

   1. De burger verhuist, en de nodige (fysieke) controles gebeuren.
   2. De gemeenteambtenaar voert dit gegeven in (Dit gegeven valt trouwens onder de noemer “civic moment“: een belangrijke gebeurtenis in de levensloop van een burger (of bedrijf), die een aantal administratieve gevolgen kan triggeren).
   3. Vanaf dan zijn deze gegevens (zowel het nieuwe adres als de adresverandering) automatisch beschikbaar voor alle overheidsdiensten die er sowieso recht op hebben. Dit is mogelijk via het opvragen van de gegevens (b.v. via REST APIs), maar evenzeer kunnen sommige applicaties onmiddellijk op de hoogte worden gebracht (via Events). Bijgevolg kunnen deze diensten dus automatisch eventuele veranderde rechten en plichten van de burger die van zijn adres afhangen, aanpassen, en uiteraard ook hun briefwisseling naar het nieuwe adres richten.

      

   4. Daarnaast kan de overheid, als data custodian (zo noemen we de horizontale dienst van het databeheer), ook een applicatie aanbieden aan de burger zelf, waar deze de mogelijkheid krijgt om applicaties van andere bedrijven toegang te geven tot deze gegevens. Dit zou een beetje kunnen werken zoals een Google of Facebook account: ook tot deze accounts kan men (beperkte en specifieke) toegang verlenen aan andere applicaties. De burger zou dus b.v. op die manier aan Bpost de toestemming kunnen geven om deze gegevens automatisch te ontvangen. Vanaf dan zou de post automatisch naar het nieuwe adres kunnen worden doorgestuurd. Sterker nog: men zou het zo kunnen regelen, dat men brieven kan versturen op naam (en/of eventueel een unieke identifier die een burger voor zichzelf kan genereren in de toepassing), en dat de post deze dan vanzelf aan het juiste adres levert. Op die manier zou men niet meer overal zijn échte adres moeten opgeven en verhoogt men dus zelfs de privacy van de burger.
   5. Ook andere koeriersbedrijven zouden op deze dienst kunnen intekenen en door de burger geauthenticeerd kunnen worden om gebruik te maken van diens door de service gekende adres. Ik wacht trouwens nog steeds op de mogelijkheid om een account te creëren bij een koeriersbedrijf en daarna niet meer mijn adres te moeten geven in elke aparte webshop die ik gebruik, maar gewoon te kunnen aanvinken dat mijn gekozen koerier mijn adres reeds kent!

   In het voorbeeld maakte ik abstractie van een eventueel apart correspondentie-adres, of het gebruik van meerdere adressen, maar deze zou men even goed door de burger zelf kunnen laten beheren in een centraal aangeboden toepassing.

3. Civiele “Half-Open” Data

   Naast het adres heeft de overheid nog een schat van andere informatie over haar burgers en bedrijven. We moeten uiteraard rekening houden met de privacy van dergelijke data, maar desalniettemin kan deze functie van Data Custodian worden uitgebreid met heel wat interessante mogelijkheden. (Ik verwees in de chipkaartenblog reeds naar het gescheiden beheer van gegevensnetwerken versus de applicaties die ervan gebruik maken. De vortex van enablers maakt dit reeds perfect mogelijk.)

   Men zou bijvoorbeeld automatisch rechten kunnen afleiden uit bepaalde situaties die burgers ondergaan (verlies van werk, fysiek letsel, …) indien deze gebeurtenissen (dit zijn Civic Moments en Events!) en hun corresponderende nieuwe gegevens snel en automatisch door alle nodige diensten werden opgevangen.

   In het voorbeeld van het fysiek letsel zou de burger aan een dokter de toestemming kunnen geven om gegevens i.v.m. langdurige werkonbekwaamheid automatisch door te sturen naar instanties die hiervoor uitkeringen betalen. Een gelijktijdig gevolg, met communicatie naar de Fod SZ, zou kunnen zijn dat de burger automatisch een parkeerkaart voor personen met een handicap zou krijgen toegestuurd.

   Deze, en nog vele andere mogelijkheden die ontstaan door de juiste data op het juiste moment op de juiste plaats te krijgen, tonen nogmaals aan dat data-centric IT meer dan ooit van belang is (en – niet te vergeten – data-centric security).

Digitale transformatie

Het eGovernment heeft onlangs reeds een fenomenale stap vooruit gezet als horizontale dienstverlener via de G-Cloud, die ervoor zorgt dat men op infrastructuur- en middlewarevlak synergieën kon creëren. Nu is stilaan het moment aangebroken om verder te beginnen denken: ook bovenop de infrastructuur, binnen en tussen applicaties en vooral door hergebruik van gegevens, ligt er nog een goudmijn van mogelijkheden op ons te wachten. In dergelijke context praat men momenteel dan ook graag over “Digital Transformation” (een evolutie die eigenlijk al heel lang gaande is).

Tot nu toe focuste deze trend zich binnen de overheid daarbij vooral op kostenbesparingen: hoe hetzelfde doen, maar dan op een efficiëntere manier? Dit is uiteraard nuttig, maar Digitale Transformatie gaat veel verder dan dat (ook volgens de blogosphere, en ook wanneer het specifiek over Cloud gaat). De ware kracht van deze trend mag niet verloren gaan in oeverloze discussies over hoe alles goedkoper kan, of hoe de bestaande zaken met de nieuwe technologie efficiënter kunnen worden gemaakt.

Ik durf hierbij zelfs Bob Lewis bij te treden: IT plannen moeten niet gedreven worden door de noden van de business, maar de business strategie moet gedreven worden door de nieuw beschikbare technologische mogelijkheden!

Welnu: de technologieën die een grote evolutie mogelijk maken, zijn gearriveerd. Laten we onze inspiratie de vrije teugels geven, en bedenken wat voor interessante diensten we nog kunnen bieden, aan zowel de ambtenaren van ons land, als aan zijn burgers en bedrijven.

Events

Heel veel zaken binnen een softwaresysteem kunnen worden gemodelleerd als een gebeurtenis, of Event: het aanklikken van een knop, het indrukken van een toets, het verbinden met een server, enz. Een bijzonder interessante vorm van gebeurtenissen zijn daarbij degene die ook op business niveau een betekenis hebben: het inloggen van een gebruiker, het versturen van een aanvraagformulier, het aanmaken van een nieuw record met gegevens, of zelfs het beschikbaar worden van een signaal komende uit een big data analytics platform.

Deze gebeurtenissen zijn er altijd, maar we besteden er niet altijd enorm veel aandacht aan: het verbinden van een server wordt simpelweg het oproepen van een hulpdienst vanuit een ander deel van het programma, de gegevens van een aanvraagformulier worden gewoon gecontroleerd en weggeschreven, het signaal wordt getoond op een dashboard, enz. We doen dus wel iets met de gegevens die samenhangen met het Event, maar we beschouwen het Event zelf niet als volwaardig concept. Eens voorbij, verliezen we dan ook het concept van iets dat zich afspeelt op een bepaald moment in de tijd. De betrokken gegevens worden weggeschreven, vaak als deel van een aggregaat, en de historische context en tijdsgebondenheid gaan verloren.

Wanneer we nu het Event wél gaan beschouwen als een object van eerste klasse (in het Engels ‘first class citizen‘), dan maken we er als het ware een tastbaar, vastgrijpbaar iets van. Het Event wordt als dusdanig “gereïficeerd” (‘écht gemaakt’). Wanneer we dit doen, dan spreken we van Event Driven Engineering. Dit is een brede tak binnen de Software Engineering, die zelf nog uit een aantal verschillende paradigma’s bestaat.

De twee meest eenvoudige van deze paradigma’s, het Publish/Subscribe mechanisme en het bredere concept Event Driven Architecture, zullen we verder uitdiepen in deze blog.

Publish/Subscribe

Het publish/subscribe mechanisme is al erg lang een gekende techniek binnen software-ontwerp, om subsystemen van elkaar los te koppelen.

Het mechanisme speelt zich af tussen drie partijen: de publisher (die een Event kan “publiceren”), de subscriber (die zich voor een event kan “onderschrijven”), en het Event systeem. Deze partijen kunnen verschillende vormen aannemen (van één welbepaald object binnen een applicatie, over subsystemen heen, tot verschillende en volledig op zichzelf staande applicaties of IT-systemen). Van publishers en subscribers kunnen er meerdere zijn. Van het Event systeem is er, althans wat de interacties rond minstens één welbepaalde soort Events betreft, slechts één.

Op een bepaald moment kan een subscriber het Event systeem contacteren om zijn interesse te uiten in een welbepaald Event. Vanaf dan is het zo dat, elke keer dit event voorkomt, de subscriber hiervan op de hoogte zal worden gebracht. Dit laatste gebeurt wanneer een publisher op zijn beurt het Event systeem inlicht over een door hem gegenereerd event. Dit laatste wordt ook wel “to fire an Event” genoemd: een Event wordt als het ware afgevuurd. De subscribers hebben dan de verantwoordelijkheid om het Event af te handelen (to “handle an Event”). Naast inschrijven, is het voor subscribers ook mogelijk zich opnieuw uit te schrijven voor een Event, een beetje zoals met een nieuwsbrief.

Het typische publish/subscribe scenario:

1. Een paar subscribers onderschrijven zich
2. Een publisher publiceert een event
3. Het Event komt terecht in het Event Systeem
4. Het Event wordt verspreid via het Event Systeem
5. Het Event bereikt alle subscribers

Voor het publish/subscribe mechanisme is het echter nog niet expliciet vereist om de events te reïficeren. Men kan ook gebruik maken van het principe van callbacks: de subscriber geeft aan wat hij wil dat er gebeurt, indien een bepaalde gebeurtenis voorkomt. De publisher kan dan via het event systeem aangeven dat iets gebeurd is, zonder verdere details te geven, en de callback wordt uitgevoerd. Daarnaast is het zelfs mogelijk dat er geen event systeem is, maar dat subscribers zich rechtstreeks tot publishers richten.

Indien we de Events echter expliciet modelleren, biedt dit mechanisme veel meer opties: publishers kunnen het Event dan verrijken met details over het gebeurde, en deze gegevens kunnen door de subscribers worden gebruikt om het Event beter af te handelen. Bovendien hebben we de optie om het Event voor later hergebruik op te slaan. Daarnaast krijgen we door het invoeren van een event systeem een vorm van indirectie, die toelaat dat publishers en subscribers elkaar niet meer te hoeven kennen.

Een typisch voorbeeld zien we bij de ondersteuning van Grafische User Interfaces (GUI). Grafische elementen zullen daar Events afvuren die door de eindgebruiker werden veroorzaakt (‘er werd op een knop geklikt’, ‘een veld werd ingevuld’, …). De achterliggende applicatiecode zal zich op deze Events hebben ingeschreven en er aldus op kunnen reageren om de applicatie (en GUI) aan te passen.

Event Driven Architecture

Binnen een Event Driven Architecture (EDA), hebben we ook publish/subscribe, maar dan op een veel grotere schaal. Meestal gaat het nu om communicatie tussen verschillende applicaties en systemen op een zo robuust mogelijke manier. Het Event systeem zal nu worden geïmplementeerd a.d.h.v. een BUS systeem, en we zullen het de Event Bus noemen.

EDA kan nuttig worden aangewend wanneer men een heel aantal applicaties heeft, die dezelfde of gerelateerde Business Events behandelen. Gebeurtenissen binnen één applicatie zullen daarbij vaak relevant zijn voor andere applicaties. De Event Bus zal binnen zo’n geheel de verantwoordelijkheid op zich nemen om een Event, door één applicatie gecreëerd, tot bij alle geïnteresseerde applicaties te krijgen. De applicaties hoeven van elkaars bestaan niet af te weten: het is voldoende dat ze van het bestaan van bepaalde Events afweten, en dat ze kunnen communiceren met de Event Bus.

Deze vorm van architectuur laat een grote loskoppeling toe van de betrokken systemen en applicaties, en zorgt er ook voor dat er snel gereageerd kan worden op voorkomende business events, zelfs op plaatsen waar, en op manieren waarop dit niet initiëel werd voorzien. Men kan zich namelijk inbeelden dat men, eens een bepaald Event bestaat en men weet dat het over de bus passeert, nieuwe ideeën kan krijgen om deze Events aan te wenden en erop te reageren, zowel in bestaande als nieuwe applicaties.

Communicatie via Events zal natuurlijk niet de enige communicatie zijn die er tussen verschillende systemen moet bestaan: soms heeft één systeem ook historische informatie nodig, die reeds lang via een andere applicatie is verwerkt en opgeslagen. Het eventuele event, indien het al zou bestaan, dat tot die informatie heeft geleid, is op dat moment natuurlijk reeds lang gepasseerd. Normaal gezien gaat dit echter altijd om read-only operaties. Hier moeten we dus, binnen het geheel van applicaties, nog iets voor voorzien (b.v. een collectie RESTful APIs). Communicatie die schrijfoperaties veroorzaakt, moet echter in principe altijd via Events kunnen worden gemodelleerd (wanneer er een gegeven moet worden aangepast, kan men desnoods deze wijziging op zich óók modelleren als een gebeurtenis).

Conclusie en Vervolg

De Event Driven Architecture is veelbelovend: het laat een sterk loskoppelen toe van de betrokken applicaties en systemen, wat het onderhoud van het softwarepark een stuk eenvoudiger maakt. Maar indien we de Events die op de bus binnenkomen permanent gaan bewaren en voor nog allerlei andere zaken gaan (her-)gebruiken, ontketenen we pas echt de kracht van Event Driven Engineering. Daarover meer in een volgende blog!

Containers, the name you know !

Het woord “Container” klinkt vele mensen, niet alleen in de bouw en scheepvaart, maar ook in de IT, reeds bekend in de oren. Het is dan ook, net zoals “Component“, een erg brede term, die binnen ons vakgebied wijd uiteenlopende implementaties kent. In ruime zin wil het uiteraard precies zeggen wat het woord betekent: “Een ding waar andere dingen in kunnen”.

Een paar voorbeelden:

• Containers als Abstract Data Type: binnen programmeertalen kunnen ze worden gebruikt om verzamelingen van andere waarden of objecten te bevatten en beheren (e.g. een Lijst of een Set).
• Containers zijn ook een andere naam voor Applicatieservers, of een specifiek deel ervan om servlets te hosten (de “Web Container“).
• Waar het in deze blog over gaat: Containers als Virtualizatie-middel op niveau van besturingssystemen (“Operating-system-level Virtualization“).

Containers are the new VM’s !

Wat is dat dan precies, die nieuwe Containers waar iedereen het over heeft? Zoals gezegd is het dus een soort van virtualizatietechniek op niveau van, t.t.z. binnen een besturingssysteem. En hier zit natuurlijk het verschil met Virtuele Machines, waarbij we virtualizatie hebben over besturingssystemen heen. Desondanks zorgt de technologie ervoor dat Containers en de erin aanwezige processen netjes van elkaar geïsoleerd blijven. Zoals op de figuur te zien is, hebben Containers het grote voordeel tegenover VM’s dat ze veel lichter zijn. Binnen een VM zal er altijd nood zijn aan een gast-besturingssysteem (“guest os”), dat, hoe klein ook, een deel van de bruikbare middelen van het systeem zal opslorpen. Containers dragen deze last niet. Voorlopig blijven VM’s koning van het datacenter, maar Containers zouden wel eens een coup kunnen plegen.

Containers zijn mogelijk dankzij de manier waarop de Linux kernel werkt (Microsoft kondigde echter al support aan voor Containers binnen Windows Server). Het isoleren van processen en het beperken van hun resource-gebruik is reeds heel lang mogelijk binnen Linux; er was echter een bedrijf als Docker nodig om een ecosysteem aan ondersteunende tools te creëren, om zo deze technologie van onder de grond te halen en recht naar de Cloud te katapulteren. Ondertussen is er trouwens al wat concurrentie in de Containermarkt.

Containers: build once; ship and run anywhere !

De technologie die de laatste tijd rond Containers is uitgebouwd en vooral door Docker en CoreOS is gepopulariseerd, laat toe om om een applicatie met alle nodige bibliotheken, bestanden en configuratie, in een pakketje te stoppen, en dit pakketje naar een Container ondersteunend platform te sturen om de applicatie te laten werken. Het is perfect mogelijk om in je eigen datacenter, of zelfs op één machine op je zolder, Containers te ondersteunen, net zoals in de public cloud. Het mooie is dat het niet uitmaakt waar de server zich bevindt: indien Containers ondersteund zijn, kan je je pakketje erop zwieren. Bovendien bestaan er al van heel veel applicaties standaard pakketjes (b.v. te vinden in de Docker Hub), en hoef je dus al vaak zelf niet meer veel werk te doen om iets te kunnen lanceren.

Containerpakketjes zijn ook heel flexibel uitbreidbaar: ze kunnen gelaagd worden opgebouwd, een beetje als een ajuin. Indien bijvoorbeeld iemand al een Node.js image heeft voorzien, kan je jouw node.js applicatie daarbovenop bouwen. Je hoeft dus niet telkens van nul te beginnen.

Ten slotte is het ook mogelijk je applicatie in meerdere pakketjes te stoppen: b.v. het applicatieve deel en de database apart. Je kan zo’n pakketje zelfs schalen, door het meermaals uit te rollen. Je kan b.v. het webgedeelte van je applicatie in één Docker Image stoppen, en tien maal uitrollen om alle front-end gebruikers aan te kunnen, terwijl je daarnaast b.v. maar één Docker Image uitrolt voor de database (handig als niet alle gebruikers steeds de database nodig hebben). Zo komt de droom van ultieme Modulariseerbaarheid (remember Components?) weer een stapje dichterbij.

CaaS, CPaaS, ContaaS ?

Via Docker en Containertechnologie kan men dus zeer snel applicaties of hun onderdelen uitrollen. Uiteraard wordt het al snel onoverzichtelijk wanneer men dit zomaar ad hoc gaat doen. Gelukkig zijn er reeds systemen ontwikkeld die het beheer van een Container-ondersteunend datacenter en de erop uitgerolde Containers goed ondersteunen. Google Kubernetes is er zo eentje, maar ook CoreOS is al jaren op deze markt actief. De Google Container Engine is een voorbeeld van Containers as a Service in de public cloud.

Momenteel worden zulke “CaaS” platformen meer naar voren gebracht als alternatief voor IaaS en PaaS. Ze vullen dan ook een unieke niche tussen de twee: IaaS werkt met VM’s en vergt veel meer configuratie en administratie, en PaaS is voor sommige gebruikers misschien te beperkend of gewoon een stap te ver qua niveau van ondersteuning. Dan biedt CaaS een gulden middenweg. De betere PaaS platformen maken ondertussen zelfs al gebruik van Containers!

Spijtig genoeg is CaaS vooralsnog geen officiële afkorting – althans niet voor Containers as a Service. De meest gebruikte betekenis van CaaS is Communication as a Service, maar Compiler, Commerce, Content, Crimeware en ja, zelfs Cloud as a Service (partner managed cloud) zijn kandidaten.  ContaaS bestaat allicht nog niet, maar klinkt wat ongelukkig. Ook Container Platform as a Service kunnen we niet afkorten als cPaaS, dit betekent reeds collaboration Platform-as-a-Service. Gezien echter het stijgende gebruik binnen het IT nieuws, zullen ook wij toch de terminologie CaaS hanteren.

Containers, Conclusie !

Containers zijn een bijzonder handige manier om applicaties uit te rollen en te modulariseren. Ze zijn momenteel sterk gehyped en, ondersteund door CaaS, zouden ze wel eens grote invloed kunnen hebben op de cloud, en op ons vak!

Dès l’origine sont donc apparus quelques grands principes fondamentaux en matière de qualité des bases de données : l’idée de “one best” (“meilleur relativement”) indique que la perfection est une “non valeur“. En effet, le concept de norme est intrinsèquement historique et évolutif (Boydens, I., L’océan des données et le canal des normes. In Annales des Mines, Paris, 2012). On se trouve toujours face à un arbitrage de type “coûts-bénéfices”, eu égard à une demande perçue, de là, le concept de “fitness for use” (“adéquation aux usages”).

Une comparaison entre production industrielle et production d’information permet de dégager, à la lumière de normes et d’exemples pratiques récents, plusieurs analogies et paradoxes dont découlent quelques “bonnes pratiques” opérationnelles en matière de gestion de la qualité des bases de données.

• Sur le plan financier et comptable, contrairement à un produit matériel, celui qui vend une information ne s’en dépossède pas… mais, au contraire, peut avoir intérêt à la “partager”

Alors que celui qui vend un produit matériel s’en dépossède, celui qui transmet une collection de données (laquelle peut être exploitée à des fins diverses par plusieurs utilisateurs simultanément, en mode “partagé”) ne s’en dépossède pas… En découlent les problèmes que pose la prise en compte de l’information en tant que “ressource” dans toute comptabilité à partie double : crédits et débits ne convergent pas et la mise en cohérence des comptes nécessite certains artifices. En outre, celui qui émet une information peut accroître son “stock de connaissance” moyennant un processus de feed-back relatif aux modes d’exploitation de celle-ci. Enfin, chaque unité d’information non redondante, contrairement aux objets émanant d’une production en série, est unique : on ne peut échanger la date de naissance d’un citoyen par celle d’un autre. Pour ces raisons, l’évaluation de la valeur monétaire de l’information n’est pas aisée.

Comme le sens de l’information est évolutif en fonction du contexte et des usages, plus celle-ci est partagée par un grand nombre d’utilisateurs avertis la contrôlant fréquemment, dans le cadre d’un suivi organisé, meilleure sera sa qualité. “Use it or lose it !” avance un adage en la matière : les silos d’information peu consultés deviennent souvent obsolètes et incomplets avec le temps (Boydens I., Informatique, normes et temps, Bruxelles, Bruylant, 1999). Un des derniers posts (30 juillet 2013) de l’excellent blog en “data quality” de Henrik Liliendahl Sørensen va dans ce sens : “On washing rental cars and shared data” .

Cette approche plaide pour les sources authentiques partagées, avec toutes les précautions qu’impliquent les contraintes du domaine d’application (confidentialité, force probante juridique et contrôle de l’intégrité, par exemple, dans le domaine de l’e-government).

Certains domaines d’application sont en effet particulièrement sensibles…  Si l’on se penche sur le cas de la récente Affaire Edward Snowden, le partage d’information qu’il a orchestré a peut-être permis d’améliorer la qualité des données (même si ce n’était sans doute pas l’objectif essentiel poursuivi), chaque partie concernée dans le monde ayant pu vérifier la validité des renseignements divulgués à propos du Programme Prism et, éventuellement, adapter ses propres données en conséquence … mais il en a apparemment coûté fort cher à l’intéressé qui, en ce 31 juillet 2013, semble toujours depuis un mois traqué et retranché dans une salle de transit à l’aéroport de Moscou…

• Il est préférable de livrer en retard un produit qui fonctionne plutôt que de livrer à temps un produit qui ne fonctionne pas… et il en va de même pour l’information

Cette “bonne pratique” est ancrée depuis longtemps dans la culture industrielle : ainsi peut-on stopper, avant livraison sur le marché, la production de vaccins ou médicaments dont on craint qu’ils soient potentiellement nocifs pour la santé, quitte à faire face à des pertes immédiates, lesquelles sont toutefois moindres que celles liées au risque encouru en cas de mise en production. Il en est de même dans le marché automobile où de grandes marques, telles Toyota, Honda, Nissan ou Fiat ont récemment rapatrié massivement des voitures potentiellement défectueuses (suite à des risques de problèmes d’airbag, de moteurs, de freins, …). Dans le domaine des systèmes d’information, cette pratique mériterait d’être généralisée, même si la pression des délais et le caractère immatériel des données ne permettent pas de mesurer facilement le terrible impact sur le réel que provoquent inévitablement, un jour ou l’autre, des données inadéquates aux usages (qu’il s’agisse de l’e-governement, des matières militaires, scientifiques, environnementales ou médicales).

• De l’analogie entre processus d’assemblage des produits en usine et processus de production de l’information : le “data tracking”

Il existe une réelle analogie entre le processus d’assemblage des produits en usine et celui des données au coeur d’un système d’information. Au sein des laboratoires d’AT&T, Thomas Redman a développé sur cette base la technique du “data tracking” en vue de détecter et d’éliminer structurellement à la source les causes de déformation de l’information, en particluier, la redondance, génératrice d’incohérences et d’anomalies fictives. Le “return on investment” d’une telle approche est important. On lutte ainsi contre le syndrôme de l’usine fantôme (ou “ghost factory“), désignant le temps et l’argent consacrés par une entreprise à produire des défauts et à les corriger. Dans le domaine de la sécurité sociale, nous avons adapté la technique du “data tracking” et nous l’avons appliquée au cas spécifique de l’e-government : “Améliorer la qualité de l’information : du “stemma codicum” au “data tracking“.

• De par son caractère intangible et immatériel, l’information empirique est évolutive et se transforme avec l’interprétation du réel observable qu’elle permet d’appréhender

Alors que le caractère défectueux d’un produit industriel se manifeste sous une forme tangible, on ne peut déduire sur la base d’une observation directe si l’information est correcte ou pas. Par exemple, un climat d’humidité peut rouiller une machine métallique et la production de cette dernière peut se réaliser dans des conditions relativement maîtrisées, en vue de prévenir les intrusions néfastes de l’environnement. Par contre, l’information empirique, sujette à interprétation dans le temps évolue dans un environnement ouvert et dynamique. Ce n’est parfois qu’au terme de plusieurs années qu’une inadéquation aux usages apparaît, dans les domaines administratifs, scientifiques ou militaires, lorsque l’information est un instrument d’action sur le réel.

Il en découle que les normes ISO en matière de qualité des données issues des normes industrielles ISO 9000, par exemple, ne sont pas toujours pertinentes. Ainsi, la récente norme internationale ISO 8000  propose, depuis 2009, un Master Data Vocabulary en vue d’améliorer la qualité des données en fournissant des listes de vocabulaire standardisé universel de référence pour assurer une modélisation uniforme de l’information. Le recours à un tel lexique est délicat en raison du caractère très volatile tant du langage naturel que des processus et des réalités représentés, cela dans tous les domaines empiriques qui sont par essence sujets à interprétations dans le temps et l’espace. Il en est de même de la récente norme ISO 25964 (2011) et (2013) en matière de conception de thésaurus. Celle-ci, en vue de faciliter l’interopérabilité sémantique dans le contexte multilingue du web, repose sur une distinction déterministe entre termes et concepts, comme si le langage était indépendant des réalités qu’il représente ! Une telle approche n’est pas totalement fructueuse sur le plan opérationnel (on lira à cet égard l’excellent mémoire de Laurence Maroye, “Norme ISO 25964-1 (2011) : apports et limites de la révision des lignes directrices pour la création et la maintenance des thésaurus“, sous la direction d’I. Boydens, Master en Sciences et Technologies de l’Information et de la Communication,  Université Libre de Bruxelles, juin 2013). Afin d’évaluer et d’améliorer la qualité des systèmes d’information non structurés et des bases de données, une autre approche reposant sur la prise en compte opérationnelle du processus interprétatif des données est indispensable, ainsi que nous l’avons montré, à titre d’exemple, dans le domaine de l’e-government (voir aussi : Boydens I., Documentologie. Bruxelles : Presses de l’Université Libre de Bruxelles, 11ème édition, année 2013-2014/1, 182 p.) .