Wat is Open Data Architectuur

“Open Data” is een aanduiding voor de verzameling interne gegevens die een organisatie extern op internet publiceert voor vrij hergebruik. En met “Open Data Architectuur” (ODA) bedoelen we het principe dat je publicatie en hergebruik van gegevens als basis neemt voor de inrichting van de hele informatievoorziening van een organisatie, niet alleen extern, maar ook intern.

In dat laatste geval betreft ’open’ niet de vrije toegang van buiten een organisatie tot interne data, maar de vrije toegang van binnen een organisatie tot data die in interne IT-systemen zit. ‘Vrij’ betekent dan niet toegang zonder de benodigde rechten, maar toegang zonder de specifieke protocollen vanuit de interne processen te moeten gebruiken.

 

extern en intern perspectief op Open Data

Extern en intern perspectief op Open Data

 

Dit concept, vrije toegang van het ene systeem tot de data van een ander systeem, is in het huidige IT denken vaak nog controversieel. Met de intentie om de complexiteit van IT beheersbaar te houden, passen we nog steeds de principes toe van information hiding uit de jaren ’70, van encapsulation uit de objectoriëntatie en van ontkoppeling van services en gegevensstructuren uit het SOA gedachtengoed. Dat wil zeggen we (ver)stoppen data in een systeem, en staan alleen dát systeem toe die data te manipuleren om zo de correcte toepassing te kunnen borgen van allerlei verplichte bedrijfs- en procesregels (“invariants” in IT jargon).

 

Nieuw paradigma

De ironie van de geschiedenis wil dat de IT ontwikkelingen vandaag de dag juist vragen om de data in onze systemen zoveel mogelijk ópen te stellen.

Informatievoorziening overstijgt hoe langer hoe meer de formele grenzen van een organisatie. Cloud, social media, mobile, the internet of things (IoT), het gebeurt voornamelijk ‘buiten’. De regie over contactmomenten, opinievorming en kennis van producten en diensten verschuift van de organisatie naar de individuele eindklant. Organisaties moeten niet meer alleen hun eigen processen managen maar ook die van de waardeketens waar ze deel van uitmaken en die van de “communities” rond hun producten. Daarbij is IT steeds meer de alles verbindende factor.

Kortom, de scope van de informatievoorziening van een organisatie wordt groter, en raakt een groter wordend aantal diverse partijen met ieder hun eigen belangen en dynamiek. De mogelijkheden om de bijbehorende IT in z’n geheel centraal te plannen, ontwerpen en te runnen worden navenant kleiner. We hebben daarom nieuwe paradigma’s nodig om informatievoorziening verder op te delen in hanteerbare brokken. Open Data Architectuur (ODA) is zo’n paradigma. De verdeling tussen gegevensproductie en gegevensconsumptie staat daarbij centraal.

 

Open Data

Even terug naar Open Data. Het concept van Open Data zelf staat los van het ODA architectuurparadigma. Open Data is ontstaan in het verlengde van de publicatie van openbare informatie op webpagina’s. Gewone webpagina’s zijn leesbaar voor mensen, maar om de gepresenteerde informatie geautomatiseerd te verwerken, zijn moeizame en niet heel betrouwbare technieken als webscraping meestal het enige middel. Voor openbare instellingen zoals overheden, bibliotheken en musea is dat onbevredigend. Zij vinden dat de informatie die ze publiceren ook softwarematig herbruikbaar moet zijn. Daarom zetten ze de betreffende gegevens niet alleen in tekst, maar ook in een gestructureerd formaat – en dus eenvoudig “machine readable” – op internet.

In het algemeen noem je gegevens Open Data als ze voldoen aan een aantal voorwaarden voor laagdrempelig hergebruik.

  • commercieel
    Er worden geen of maximaal redelijke productiekosten gevraagd voor de gegevens.
  • juridisch
    Het betreft niet privacy-gevoelige gegevens, zonder rechten van derden, en er bestaan geen beperking t.a.v. het soort hergebruik (b.v. commercieel hergebruik of het samenvoegen met andere datasets).
  • technisch
    Publicatie gebeurt in in een gestructureerd formaat, en met open standaarden: b.v. door geen Excel te gebruiken (daar heb je een licentie voor nodig), maar CSV-bestanden.

Overigens gaat het bij publiceren en afnemen van Open Data niet alleen om bestanden. Er zijn een aantal manieren waarop Open Data gedeeld kan worden:

  • embedded op een webpagina
    In webteksten kun je voor de lezer onzichtbare annotaties toevoegen waardoor een zoekmachine (of andere software) ‘ziet’ wat de betekenis van de betreffende woorden is. De titel van een film, een geografische plaatsaanduiding of wat dan ook.
  • met file transfer
    Bestanden met alleen of voornamelijk gestructureerde informatie worden op een website gezet en kunnen worden afgenomen met FTP, door het downloaden vanaf internet pagina’s of via het versturen van attachments in email.
  • via een API
    Een API is een soort loketfunctie op een systeem waarlangs andere systemen elektronisch informatie kunnen uitwisselen. Met een API die je via internet kunt benaderen (een Open API, ook wel Public of Web API genoemd) kan afnemende software zo specifieke subsets opvragen van de Open Data in een systeem.

De (beoogde) voordelen van Open Data liggen vooral in het publieke domein voor de hand.

  • Transparantie en democratische controle
  • Participatie en publiek-private samenwerking
  • Verbeterde en nieuwe producten en diensten
  • Verbeterde efficiëntie van overheidsdiensten
  • Innovatie, en daarmee economische groei

Deze voordelen zijn inmiddels mede aanleiding geweest tot diverse bestuurlijke initiatieven op dit gebied. Zo was daar de Digital Agenda van eurocommissaris Neelie Kroes (2010), het Open Government Partnership (OGP): een internationaal platform voor landen die hun overheden meer “open, accountable en responsive” willen maken (2011), het Open Government Initiative van president Obama (2013) en het Actieplan Open Overheid van minister Plasterk (2013).

Ook steeds meer commerciële organisaties – zoals b.v. openbaar vervoerbedrijven – stellen belangrijke data open. De commerciële drijfveer om Open Data te publiceren is dezelfde als bij traditionele publicatie op internet: bekendheid en conversie. Zorgen dat potentiële klanten je producten en diensten kunnen vinden, beoordelen en afnemen.

 

Informatieketens

Op basis van jouw Open Data kunnen allerlei derde partijen snel, simpel en goedkoop websites en apps in de markt zetten die deze gegevens op een voor de eindgebruiker handige manier presenteren. Achterliggende gedachte is hier dat je als bedrijf in de huidige complexe informatieketens onmogelijk even goed kunt zijn in het ondersteunen van álle schakels daarin. Het registreren en beheren van brongegevens in een primair proces is heel wat anders dan het garanderen van reactietijden, performance en beschikbaarheid, wat weer heel wat anders is dan het optimaliseren van user experience etcetera. Kortom, weet als (IT-)organisatie waar je core business ligt in de huidige hyperconnected maatschappij en laat de rest over aan partners.

Een mooi voorbeeld daarvan is de informatieketen in het OV. Vervoerders zoals de NS leveren hun reisinformatie aan bij de door het Ministerie van Infrastructuur en Milieu aangestelde onafhankelijke NDOV-loketten. Deze loketten leveren die informatie dan weer door aan tientallen afnemers die er apps voor reizigers mee maken. Zo heb je naast NS- en 9292-reisplanners ook allerlei apps als Go About, Mobile Ninja of TimesUpp. Je hebt daarbij dan niet alleen trein- en businformatie, maar ook file-, P&R en parkeerinformatie in dezelfde app.

Dat laatste is overigens een belangrijk aspect bij het gebruik van Open Data: het kunnen koppelen van gegevens uit verschillende bronnen.

Maar ligt daar niet juist de achilleshiel van IT? Meerdere ‘unieke’ voorkomens, onverenigbare datamodellen en dubbelzinnige definities zorgen in de regel voor hoge kosten van integratieprojecten en voor aanzienlijke afbreekrisico’s bij Business Intelligence-initiatieven. Hoe regel je dat dan ook nog eens op www-schaal?

 

Linked Data

Om die horde te nemen is er een nieuwe set datastructuren en best practices ontstaan die we Linked Data noemen. In plaats van klassieke tabelstructuren (waarvan de definities op elkaar moeten aansluiten als je de betreffende gegevens wilt koppelen), gebruikt Linked Data zogenaamde triples. Een triple kun je zien als een geïsoleerde rij ID + kolom ID + celwaarde van een relationele tabel. Relaties tussen triples (zeg maar: het database-schema) die worden ook met triples aangegeven. Je kunt triples opslaan in een “graph database” en queryen met SPARQL (vergelijkbaar met SQL).

In triple formaat – met de Resource Description Framework (RDF) standaard – maak je dus alle datastructuren ‘compatibel’. Bovendien worden rijen gekoppeld aan unieke resource identifiers (URI’s) en worden kolommen (attributen) zoveel mogelijk gedefinieerd op basis van wereldwijde standaard vocabulaires zoals schema.org. Minimale kans op dubbelzinnigheid dus.

Daarnaast kun je met talen als SKOS en OWL een semantisch model opstellen, een geheel aan relaties tussen vocabulaires en de objecten van triples, ook als die uit verschillende bronnen komen. Zo kun je betekenissen van en afhankelijkheden tussen gegevens uit verschillende bronnen aan elkaar relateren. Dat noemen we semantische integratie.

Op deze manier koppel je met Linked Data ‘producenten’ en ‘consumenten’ van Open Data, zonder dat die elkaar hoeven te kennen. Geen afstemming over service definities of canonieke data modellen, zolang je datamodel gebaseerd is op bekende vocabulaires. Bovendien is de Linked Data publicatie-infrastructuur transparant voor wijzigingen in het datamodel van de gepubliceerde gegevens, dus ook bij doorontwikkeling van de aangeboden gegevensset is er minimale afstemming nodig tussen producent en afnemers.

 

Architectuur

OK. Over naar het architectuurverhaal. Een belangrijk aandachtsgebied van IT-architectuur is de samenstelling van een IT-landschap uit componenten. Los van de functionele eisen (alle componenten samen moeten de totale gevraagde functionaliteit kunnen leveren) zit daar ook een generiek aspect aan. De indeling in componenten (hoeveel, welke, hoe gekoppeld) bepaalt de robuustheid, flexibiliteit en total cost of ownership (TCO) van het IT-landschap. Een handige indeling betekent flexibele, robuuste en goedkope IT.

Bij het ontwerpen van zo’n indeling kun je een aantal overwegingen als leidraad gebruiken. Een klassieke, intrinsieke overweging is die van high cohesion en low coupling van Constantine. Simpel gezegd: zorg dat functionaliteiten die veel met elkaar te maken hebben, in dezelfde component zitten en zorg dat er tussen verschillende componenten minimale afhankelijkheden bestaan. Het toepassen van deze principes bevordert overzicht en inzicht, testbaarheid en onderhoudbaarheid (fixes, uitbreiding, vervanging).

Een recentere, extrinsieke overweging is die van pace layering van Gartner. Het idee hier is dat organisaties uiteenlopende eisen kunnen stellen aan de verschillende functionaliteiten van hun informatievoorziening. Dat vanwege uiteenlopende prioriteit, urgentie, budgettering, governance en afschrijvingstermijnen. Het is handig om functionaliteit die op dit niveau verschilt (met name qua levenscyclus), ook in verschillende applicaties onder te brengen. Soms zul je dan applicaties daarvoor op moeten knippen.

Dat resulteert voor Gartner dan in de volgende pace layers:

  • Systems of Record (lange en stabiele levenscyclus)
  • Systems of Differentiation (relatief veel wijzigingen)
  • Systems of Innovation (snel uitrollen, snel vervangen)

Het uiteindelijke doel van dit soort architectuuroverwegingen is “plug ’n play”: het snel, betrouwbaar en goedkoop kunnen uitbreiden of aanpassen van een IT-landschap. Ondersteunende architectuurpraktijken zijn

  • hergebruik van al bestaande functionaliteit
  • loose coupling: het zodanig inrichten van de koppelingen tussen applicaties dat je wijzigingen in de ene door kunt voeren met minimale wijzigingen in de andere applicaties.

 

SOA

Deze architectuurpraktijken werden in belangrijke mate gefaciliteerd door de opkomst van Service Oriented Architecture (SOA) en webservices zo’n vijftien jaar geleden. Met SOA hoef je de interne werking van een te koppelen applicatie niet meer te kennen, maar kun je uitgaan van afgesproken servicecontracten die het communicatiegedrag van zo’n applicatie functioneel vastleggen. Webservice standaarden zoals SOAP definiëren dan de onderliggende technische protocollen en formaten. En met een enterprise service bus (ESB) als infrastructuur kun je de kwaliteit van je koppelingen centraal beheren. Hierdoor is plug ’n play op technisch niveau eenvoudig mogelijk geworden.

 

integratie tussen legacy systemen

Integratie tussen legacy systemen

 

klassieke SOA integratie

Klassieke SOA integratie

 

Maar op functioneel niveau laat SOA voor hergebruik en loose coupling nog wel wat te wensen over. Om gegevens uit te kunnen wisselen met een andere applicatie moet je de (web)services van die applicatie kennen. Je hebt dan per service de naam, parameters, en een goed begrip nodig van de functie van de service. Dat is vaak een drempel voor hergebruik. Bij de afnemende applicatie moet je namelijk nogal wat analyse- en ontwerpinspanning doen om die services daadwerkelijk aan te kunnen roepen.

In de context van Enterprise Application Integration (EAI) – dus binnen dezelfde organisatie – is dat meestal te overzien, maar soms is die inspanning een belangrijk struikelblok voor het realiseren van koppelingen met SOAP-webservices of (andere) ESB-gebaseerde communicatie.

  • Als analyse van servicedefinities te tijdrovend is of praktisch belemmerd wordt door ontoereikende documentatie of ontbrekende afstemming met de (IT-)organisatie die de service levert.
  • Als het aantal te koppelen applicaties te groot is om alle bijbehorende servicedefinities te kunnen analyseren. Transparantie en standaardisatie is een voorwaarde voor schaalbaarheid van koppelingen. Een aardig voorbeeld van zo’n situatie is het CitySDK project, dat toeristische apps ondersteunt die in principe moeten kunnen werken met de Open Data van alle (!) Europese steden.

Ook op het gebied van loose coupling kent SOA nog uitdagingen.

  • De transformatie van datastructuren wordt vastgelegd (gecodeerd of geconfigureerd) in de koppelingsinfrastructuur.
  • Onzorgvuldig ontworpen services kennen vaak nogal wat procesmatige randvoorwaarden (“pre-“ en “postcondities”) waar je als afnemer rekening mee moet houden. Dit wordt in de hand gewerkt als er sprake is van centrale bedrijfsprocessturing, al dan niet gefaciliteerd door tooling als BPM (Business Process Management) ‘bovenop’ de ESB.

Je creëert zo functionele afhankelijkheden, waardoor services niet transparant zijn voor wijzigingen. Functionele uitbreiding of aanpassing van een applicatie betekent dan bijkomende investeringen in de afnemende ESB, applicaties en apps.

 

API

Gelukkig zie je tegenwoordig een beweging naar transparantere, meer schaalbare en flexibelere koppelingen. Die beweging wordt gedreven door een drietal trends.

Eén daarvan is de ontwikkeling van client platforms. De client is tegenwoordig meestal geen gewone webbrowser meer maar rich client, web application, native app of Rich Internet Application (RIA). Je publiceert daar geen html-pagina’s voor, maar wisselt gegevens uit via een API. Mooi meegenomen: de back end software achter de API is onafhankelijk van het specifieke platform of device waar de client op draait. Daarnaast willen allerlei social media en andere websites met elkaar koppelen – op een gebruikersvriendelijker manier dan via linkjes. Dat kan met API’s. En een derde trend: er wordt steeds meer IT-functionaliteit in de cloud gezet. Ook hier bieden API’s de noodzakelijke koppelingen.

SOAP is al lang geen best practice meer voor dit soort koppelingen. Tegenwoordig is dat eerder Representational State Transfer (REST). REST gebruikt standaard internet (http-)methoden als “get” en “post” om gegevens te lezen respectievelijk weg te schrijven. Dat maakt REST makkelijk te begrijpen en te gebruiken en daarbij heel schaalbaar.

Verder bevat de van de server ontvangen gegevensset (de “representation”) alle informatie die een client nodig heeft om het (client)applicatieproces naar een volgende processtap (“state”) te sturen. Daarvoor geeft de server een aantal hyperlinks mee in de uitgelezen gegevensset. De client kan daar vervolgens één van kiezen om een nieuwe “get” op uit te voeren. De client software hoeft zo dus niet op de hoogte te zijn van het verwerkingsproces aan de kant van de server. Dit principe heet Hypertext As The Engine Of Application State (HATEOAS).

Intussen worden REST API’s ook veel gebruikt voor publicatie van Open Data. En er is inmiddels een W3C standaard in de maak voor een Linked Data REST API: het Linked Data Platform (LDP).

 

Open Data Architectuur

REST en Linked Data zijn dus voor de hand liggende technieken voor het uitwisselen van informatie over organisaties heen. Maar ook binnen de grenzen van een organisatie kan ‘publicatie’ en hergebruik van interne data nuttig zijn: om de informatievoorziening flexibeler, robuuster en goedkoper maken.

 

ODA integratie

ODA integratie

 

Deze zienswijze noemen we het ODA paradigma.

Dit paradigma staat haaks op het principe van information hiding. Door toepassing van RDF datastructuren is een datamodel niet meer door externe incompatibiliteit strak gebonden aan een specifieke applicatie. Data is daarmee geen uitvoeringskwestie meer die je door een separation-of-concerns gedachte ‘in de black-box’ wilt stoppen. Ook de noodzaak van encapsulation, het strak koppelen van data aan de logica die de invariants bewaakt, is twijfelachtig geworden. Tegenwoordig overstijgt informatievoorziening organisaties, alle met verschillende regels en processen. Data is het enige dat wordt gedeeld, het is de enige ‘invariant’.

ODA gaat dus over integratietechnieken voor informatie-uitwisseling binnen of tussen organisaties. Het zegt niets over privacy of beveiliging van de uitgewisselde gegevens. ODA gaat ervan uit dat identiteits- en toegangscontrole op een gangbare manier geregeld is.

Praktische uitvoering van ODA is gebaseerd op de volgende drie principes.

 

ODA-principe 1

geen aannames over de aard van mogelijk hergebruik

Elke applicatie publiceert zijn relevante bedrijfsgegevens op een OpenData manier: ongefilterd, onbewerkt, niet vertraagd, geaggregeerd of getransformeerd, dus met het schema van het lokale domeinmodel. Andere applicaties kunnen deze gegevens – mits met de benodigde autorisatie – consumeren voor hun eigen soort hergebruik (inclusief replicatie). Doe dus geen aannames over hoe een afnemer de data gepresenteerd of gemanipuleerd zou willen hebben, maar lever “ruwe” data en basale operaties!

Elke applicatie biedt dan ook een API met CRUD operaties op zijn eigen gegevens (op gerepliceerde gegevens alleen Read). Create, Update en Delete operaties worden niet direct uitgevoerd maar hebben het karakter van een “post” – een boeking – zodat de applicatie zelf de regie kan voeren over consistentie en compliance van zijn bedrijfsgegevens.

 

ODA-principe 2

maximale ontkoppeling van registratie/publicatie en (her)gebruik

Elke applicatie integreert hergebruikte data via semantische integratie en bijbehorende bedrijfsprocessen via zelfbeschrijvende processtappen. Hierdoor zal een wijziging in gepubliceerde datastructuur (Read) of registratieproces (Create, Update en Delete) transparant zijn voor de koppelingsinfrastructuur.

Zelfbeschrijvende processtappen worden zo mogelijk gerealiseerd door HATEOAS. In het geval van (her)gebruik door een UI component ondersteunt menselijke interpretatie het bedoelde zelfbeschrijvende karakter van de links in de geleverde representation. In andere gevallen is dat ingewikkelder en ligt HATEOAS niet voor de hand. Het alternatief is semantische modellering van de processtappen in het domeinmodel. Bijvoorbeeld in het proces voor een Create van een hypotheek kun je – naast de (gepasseerde) hypotheek zelf – een aangevraagde offerte, ontvangen offerte en ondertekende offerte modelleren. En die net als de hypotheek zelf dan vastleggen en als Open Data publiceren. Het is te verwachten dat voor semantische modellering van processtappen ook wereldwijde standaard vocabulaires zullen ontstaan. Een generieke process manager component (zeg maar: BPM tooling) is voor ODA overigens duidelijk een antipatroon.

Met dit principe kun je aan een applicatie de volgende kernverantwoordelijkheden toekennen t.a.v. zijn gepubliceerde data:

  • registratie en beheer (juistheid, volledigheid, tijdigheid, (interne) consistentie, compliance en persistentie)
  • publicatie (beschikbaarheid)

Al het overige – zoals performance, integratie, end-to-end procesmanagement en user experience – is aan de afnemer(s).

 

ODA-principe 3

ontkoppelde governance

Elke applicatie gebruikt voor publicatie standaard internet protocollen zoals REST en LDP. De interactie tussen gegevensproducent en gegevensconsument wordt daarmee vervolgens volledig ingericht alsof het om twee gescheiden (IT-)organisaties gaat. Dat wil ook zeggen: gescheiden software ontwikkelprocessen en -projecten, geen centraal CDM maar lokale semantische modellen, en separaat IT-beheer.

Dat creëert maximale ontkoppeling van (de levenscycli van) de applicaties aan beide kanten van de publicatie-consumptie lijn. Ideaal als je die weet te trekken langs de grens tussen verschillende pace layers.

 

life cycle processen in verschillende pace layers (links/rechts); zowel bij externe als interne consumptie

Life cycle processen in verschillende pace layers (links/rechts); zowel bij externe als interne consumptie, b.v.:

  • OV-informatie/reisplanners
  • administratie/datamarts
  • back-end/gebruikersinterface

 

Dit principe legt – enigszins analoog aan het TOGAF Integrated Information Infrastructure Reference Model (III-RM) – de basis voor het inrichten van informatieketens als logistieke ketens. Met producenten (Information Provider Applications), groot- en tussenhandel (Brokering Applications) en eindconsumenten (Information Consumer Applications). Zonder centrale planeconomie, maar met bilaterale contracten. De parallel tussen de levering van producten en van Open Data zal duidelijk zijn.

Maar een andere parallel is misschien nog interessanter. Die tussen autonome ketenpartijen en onafhankelijk IT-management per applicatie. Toekomstmuziek? Zeg het maar. Gedistribueerde governance is net als gedistribueerd eigenaarschap geen belemmering voor een integrale IT-visie. Het is er onderdeel van.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *