Open Data architectuur

Open data architectuur

Informatievoorziening overstijgt hoe langer hoe meer de formele grenzen van een organisatie. We hebben 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.

Joep Creusen

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 aanvraagprocedures vanuit de interne processen te moeten gebruiken (figuur 1). 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).

Figuur 1. Extern en intern perspectief op open data

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, het 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.

Concept open data

Even terug naar open data. Het concept van open data zelf staat los van het ODA-paradigma. 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 ten aanzien van het soort hergebruik (bijvoorbeeld commercieel hergebruik of het samenvoegen met andere datasets).

• technisch: publicatie gebeurt in een gestructureerd formaat, en met open standaarden: bijvoorbeeld 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 annotatiesFiguur 1. Extern en intern perspectief op open datatoevoegen 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 internetpagina’s of via het versturen van attachments in e-mail.

• 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, 2011) – een internationaal platform voor landen die hun overheden meer ‘open, accountable en responsive’ willen maken –, het Open Government Initiative van president Obama (2013) en het Actieplan Open Overheid van minister Plasterk (2013). Ook steeds meer commerciële organisaties, zoals bijvoorbeeld 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 et cetera. 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 openbaar vervoer. Vervoerders zoals de NS leveren hun reisinformatie aan bij de door het Ministerie van Infrastructuur en Milieu aangestelde onafhankelijke Nationale Databank Openbaar Vervoer (NDOV)-loketten.2 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 dan overigens niet alleen trein- en businformatie, maar ook file- 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, plus kolom-ID, plus 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 Format (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 ván, en afhankelijkheden tussen gegevens uit verschillende bronnen aan elkaar relateren. Dat noemen we semantische integratie.3Op deze manier koppel je met linked data ‘producenten’ en ‘consumenten’ van open data, zonder dat die elkaar hoeven te kennen. Geen afstemming over servicedefinities of canonieke datamodellen, 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.4 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.5 Het idee hier is dat organisaties uiteenlopende eisen kunnen stellen aan de verschillende functionaliteiten van hun informatievoorziening. Dat vanwege uiteenlopende prioriteit, urgentie, budgetering, 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 dan in verschillende 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 and 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 infrastructuurkun je de kwaliteit van je koppelingen centraal beheren. Hierdoor is ‘plug and play’ op technisch niveau eenvoudig mogelijk geworden (figuur 2a en 2b) .

Figuur 2a.  Integratie tussen legacysystemen

 

Figuur 2 b. 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-project6, 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 business process management (BPM) ‘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, webapplicatie, 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, te gebruiken en 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). Momenteel wordt ook veel open data gepubliceerd met REST API’s. 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 (figuur 3) . 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.7

Figuur 3. ODA-integratie

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.

 

ODA-principe 1: geen aannames over de aard van mogelijk hergebruik
Elke applicatie publiceert zijn relevante bedrijfsgegevens op een open data-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 Create, Read, Update en Delete (CRUD)-operaties op zijn eigen gegevens (op gerepliceerde gegevens alleen Read). Create, Update en Deleteoperaties 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 liefst 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, ontvangen, 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. Voor ODA is een generieke procesmanagercomponent (zeg maar: BPM-tooling) overigens duidelijk een antipatroon. Met dit principe kun je aan een applicatie de volgende kernverantwoordelijkheden toekennen ten aanzien van 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).
Figuur 4. Lifecycleprocessen in verschillende pace layers, zowel bij externe als interne consumptie, bijvoorbeeld: OV-informatie - reisplanners; administratie - datamarts; back-end - gebruikersinterface
 
ODA-principe 3: ontkoppelde governance
Elke applicatie gebruikt voor publicatie standaard internetprotocollen, 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-consumptielijn. Ideaal als je die weet te trekken langs de grens tussen verschillende pace layers (figuur 4) .
Dit principe legt – enigszins analoog aan het TOGAF Integrated Information Infrastructure Reference Model (III-RM)8 – 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 de levering 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.

 

 

Joep Creusen is integratiearchitect bij NS. Hij schrijft op eigen titel. E-mail: joep.creusen@planet.nl

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag