Integratie

Versie door Rdb (overleg | bijdragen) op 14 okt 2018 om 14:05 (Fix link)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)

Dit hoofdstuk beschrijft een visie op de integratie van applicaties op basis van diensten voor gegevensuitwisseling, identity management en business process management. Daarnaast wordt ingegaan op open data en de rol ervan in het onderwijs.

Gegevensuitwisseling

Zoals beschreven in de architectuurprincipes zou de informatievoorziening zoveel mogelijk geïntegreerd moeten zijn voor gebruikers. Dit zorgt ervoor dat zij zich maximaal kunnen richten op hun eigen taken. Om dat mogelijk te maken is het noodzakelijk dat applicaties met elkaar integreren, bij voorkeur op basis van open standaarden. Omdat applicaties in de praktijk in veel gevallen nog niet zover gestandaardiseerd zijn dat zij hun “stekker” in het “stopcontact” van andere applicaties kunnen stoppen is integratie-infrastructuur noodzakelijk. Een dergelijke infrastructuur zorgt ervoor dat gegevens tussen applicaties kunnen worden uitgewisseld.

Een algemeen streven bij het integreren van applicaties is om de koppeling van de applicaties zo los mogelijk te maken, zodat ze ook los van elkaar kunnen veranderen of vervangen kunnen worden. Een algemeen patroon daarbij is het gebruik van een canonical datamodel. Een dergelijk gegevensmodel is onafhankelijk van een specifieke applicatie en zou moeten worden afgestemd op organisatiebrede gegevensdefinities. De integratie-infrastructuur zorgt ervoor dat de gegevens van zowel de zendende als de ontvangende applicaties vertaald worden naar dit canonical datamodel, zodat zij geen kennis hoeven te hebben van elkaars datamodel. Omdat het zelf definiëren van een canonical datamodel veel inspanning kost is het algemene advies om gebruik te maken van standaarden die (delen van) een dergelijk model definiëren. Omdat wereldwijde standaarden zoals IMS veelal generiek zijn wordt er door EduStandaard gewerkt aan (Nederlandse profielen van) onderwijsspecifieke standaarden.

Veel instellingen hebben stappen gezet voor het inrichten van een integratie-infrastructuur door het implementeren van een Enterprise Service Bus (ESB). Dit is een generieke oplossing die in staat is een groot aantal integratiescenario’s op te lossen. Het belangrijkste dat een ESB doet is het routeren en vertalen van berichten tussen applicaties. Het is dus vooral gericht op bericht-gebaseerde communicatie en het aanroepen van services (service-georiënteerde architectuur). Het is belangrijk om te beseffen dat er een aantal integratiescenario’s zijn waarbij de inzet van een ESB minder voor de hand ligt. Denk met name aan scenario’s waarbij gegevens in bestandsvorm, in bulk, periodiek, of met externe partijen moeten worden uitgewisseld of als de gegevensuitwisseling onderdeel is van een bedrijfsproces (zie ook Figuur 1). Daarnaast is er ook een grensvlak met identity management (zie verderop in dit hoofdstuk), waar meer specifieke oplossingen voor bestaan. Tenslotte is de inzet van een ESB niet automatisch gerechtvaardigd als er al standaard “stekkers” en “stopcontacten” aanwezig zijn in de te koppelen applicaties, zowel op technisch als op inhoudelijk niveau (betekenis).

Hoofdstuk7 figuur1.png
Figuur 1 Integratie-architectuur (ook beschikbaar in PDF)

Tabel 1 geeft vanuit verschillende perspectieven weer wat de meest logische integratie-oplossing is gegeven de karakteristieken van een specifieke gegevensuitwisseling. Zo is het belangrijk om te weten of er gestructureerde of ongestructureerde gegevens worden uitgewisseld, wat voor transactie wordt ondersteund met de gegevensuitwisseling, of er geïntegreerd wordt binnen of buiten de organisatie, of er een bedrijfsproces in de integratie zit en of de integratie herbruikbaar is. Een plus (+) in de tabel geeft aan dat een bepaalde integratie-oplossing de voorkeur heeft. Een O geeft aan dat een integratie-oplossing wel gebruikt kan worden maar niet de voorkeur heeft. Een min (-) geeft aan dat een bepaalde integratie-oplossing niet gebruikt kan worden of dat het niet verstandig is deze te gebruiken.

Hoofdstuk7 tabel1.png
Tabel 1 Beslistabel voor het bepalen van de meest geschikte integratie-oplossing

Naast dat belangrijk is om de meest geschikte integratie-oplossing te kiezen is ook de keuze voor de te gebruiken integratiestandaard belangrijk. Zoals eerder aangegeven is EduStandaard verantwoordelijk voor het bepalen van onderwijsspecifieke standaarden. Los van deze onderwijsspecifieke standaarden zijn er allerlei technische integratiestandaarden die relevant zijn en waar een keuze voor moet worden gemaakt (zie ook Figuur 1). De karakteristieken die bepalen welke integratie-oplossing het meest voor de hand ligt zijn ook bruikbaar om te bepalen welke integratiestandaard het meest passend is. Tabel 2 geeft vergelijkbaar met de vorige tabel middels plus, O en min tekens aan welke standaard het best passend is in verschillende situaties.

Hoofdstuk7 tabel2.png
Tabel 2 Beslistabel voor het bepalen van de meest geschikte integratiestandaard

Identity management

Identity management [23] is sterk gerelateerd aan integratie. Een belangrijk deel ervan gaat namelijk over het uitwisselen van identiteitsgegevens. Dit heet ook wel “provisioning” en dat is functionaliteit die typisch deel uitmaakt van een identitymanagementsysteem. Hiermee ontstaat er een overlap met wat een ESB doet; deze kan namelijk ook identiteitsgegevens uitwisselen. Alhoewel dit praktisch gezien kan, is het in veel gevallen niet verstandig. Zo bevat een identitymanagementsysteem standaard functionaliteit voor het matchen en synchroniseren van identiteiten en zijn er vaak standaard connectoren voor applicaties beschikbaar. Ook is het uitwisselen van wachtwoordgegevens met een ESB onverstandig omdat dit de beveiliging kan compromitteren. Het is wel belangrijk om te beseffen dat identiteitsgegevens zoals aanwezig in een identitymanagementsysteem een ander doel hebben dan administratieve gegevens over een persoon in bijvoorbeeld een personeelssysteem. De eerste hebben vooral tot doel om toegang tot systemen te faciliteren. De tweede om de administratieve processen te ondersteunen.

Een andere belangrijke gerelateerde component is een authenticatieproxy, die gebruikt wordt om de daadwerkelijke authenticatie uit te voeren en ervoor zorgt dat Single Sign On over applicaties heen gerealiseerd kan worden. Deze authenticatieproxy haalt de noodzakelijke gegevens uit de directory server die door het identitymanagementsysteem is “geprovisioned” met identiteitsinformatie. Op sectorniveau is hiervoor SURFconext ontwikkeld door SURFnet. Deze component zorgt ervoor dat authenticaties over de grenzen van onderwijsinstellingen heen mogelijk zijn. Gebruikers kunnen met het account dat zij bij een instelling hebben gebruik maken van diensten die worden aangeboden door andere instellingen of leveranciers. Applicaties zouden bij voorkeur zelf geen authenticatie meer uitvoeren maar vertrouwen op dit soort generieke authenticatiefunctionaliteiten. Daarnaast maakt SURFconext het mogelijk om groepsinformatie te delen over de grenzen van instellingen heen. Dit is een belangrijke functionaliteit aangezien hierdoor gebruikers van verschillende instellingen en organisaties met elkaar kunnen samenwerken.

Het registreren van gebruikers in het identitymanagementsysteem is niet voor alle gebruikersgroepen evident. De algemene stelregel is dat instellingen identity provider zijn voor mensen die ze niet-anonieme functionaliteit in meer dan één applicatie willen aanbieden. Voor gebruikers die dus maar toegang hebben tot één applicatie of alleen (anoniem) de website benaderen is de registratie in het identity management systeem niet logisch. Denk bijvoorbeeld aan prospects of alumni die mogelijk slechts heel beperkt toegang hebben, bijvoorbeeld alleen tot een forum of alumni-site. Voor groepen waarmee je als instelling wel een relatie onderhoudt maar waarvoor de instelling geen identiteitsgegevens beheert ligt het gebruik van een social network account (zoals Facebook of LinkedIn) voor de hand. Het beheer van de identiteitsgegevens is dan feitelijk uitbesteed aan een externe partij die beter in staat is deze actueel te houden. In het algemeen moet met de inzet van social networkaccounts voorzichtig worden omgegaan omdat het validatieproces veelal minder geavanceerd is en daarmee het vertrouwen in de identiteit laag. Het is dan ook verstandig om toegang voor dit soort accounts te beperken tot gepersonaliseerde selecties van informatie met een laag vertrouwelijkheidsniveau. Denk bijvoorbeeld aan het raadplegen van (publiek beschikbare) roosterinformatie.

Ervaring leert dat bij de implementatie van identity management bij hoger onderwijsinstellingen een volledige implementatie van Role Based Access Control [24] lastig is, gegeven de grote diversiteit aan rollen en autonomie van faculteiten. In de praktijk worden alleen basisrollen als student, medewerker en gast gedefinieerd. Gecombineerd met attribuutinformatie over opleiding en organisatie-eenheid lijkt in de praktijk voldoende uitdrukkingskracht voor autorisaties te bestaan. Meer informatie over de inzet van identity management in het hoger onderwijs kan worden gevonden in whitepapers die hier eerder vanuit SURFnet over zijn geschreven [23, 24].

Business process management

Business process management is ook sterk gerelateerd aan integratie. In het algemeen ontstaat de behoefte aan integratie doordat processen of processtappen dienen te integreren. Processen spelen zich af op allerlei niveau’s van abstractie. Op het hoogste niveau spreken we van ketenprocessen (die zelfs de grens van de organisatie kunnen overstijgen) en klant-tot-klant processen. Op het laagste detailniveau bestaan processen die voor de gebruikersorganisatie zelf geen betekenis meer hebben en slechts bestaan uit het aan elkaar rijgen van technische functies.

In het algemeen zijn business process management systemen specifiek ontworpen om processen te ondersteunen. Het algemene advies is dan ook om proceslogica te vermijden in een ESB. Hierdoor ontstaat er ook een nettere scheiding tussen integratielogica en proceslogica. Alleen de meest technische processen zouden eventueel nog middels een ESB kunnen worden ondersteund. Daarbij wordt de ESB wel minder schaalbaar omdat voor processen een procestoestand moet worden bijgehouden.

Het is belangrijk om te onderkennen dat er voor verschillende processen ook verschillende soorten van IT-ondersteuning wenselijk zijn [25]. Traditioneel werd vooral gesproken over “workflow-managementsystemen”, welke vooral gericht zijn op het verspreiden van werk naar mensen die dit kunnen uitvoeren via zogenaamde werkbakken. Later zijn “case management systemen” opgekomen als een meer moderne vorm van procesondersteuning, waarbij het dossier centraal staat en de volgorde van processtappen minder strikt voorgedefinieerd is [26]. Dit ligt dicht aan tegen wat ook wel “zaakgericht werken” [27] wordt genoemd en waarvoor specifieke “zaaksystemen” zijn ontwikkeld, met name in de gemeentemarkt. Deze categorie van systemen legt de nadruk op het bewaken van de status, kwaliteit en doorlooptijd van processen. Ze zijn met name gericht op het verhogen van de kwaliteit van dienstverlening en bieden ook niet altijd “workflowmanagement” voor het daadwerkelijk ondersteunen van het proces. Tenslotte zijn er ook specifieke business process management systemen die gericht zijn op het ondersteunen van technische processen (ook wel: orchestration). Het is dus belangrijk bij elk proces de juiste vorm van IT-ondersteuning te zoeken. Voor eenvoudige of meer dossiergerichte processen ligt de inzet van een zaaksysteem of case management systeem voor de hand. Meer complexe of gestandaardiseerde processen vragen om een workflow management systeem.

Open data

Een algemene ontwikkeling is dat gegevens steeds meer worden gedeeld. Bij open data stellen organisaties hun gegevens publiek beschikbaar zodat anderen daar toepassingen op kunnen baseren. Een deel van deze ontwikkeling vloeit voort uit een toenemend belang voor transparantie. Dit uit zich in formele wet- en regelgeving, maar ook in verwachtingen van burgers en bedrijven. Formele wet- en regelgeving gaat steeds meer inzicht vragen in de wijze waarop processen worden uitgevoerd. Ook vanuit de digitale agenda.nl wordt het beschikbaar stellen van open data door overheidsorganisaties gestimuleerd. Aan de andere kant draagt het delen van gegevens bij aan innovatie; het stelt anderen in staat om allerlei nieuwe toepassingen te creëren die van tevoren niet voorzien waren. Dit ligt in het hart van de doelstellingen van hoger onderwijs instellingen rondom valorisatie. In het hoger onderwijs manifesteert open data zich in het delen van de administratieve gegevens, maar ook in het delen van publicaties (open access), onderzoeksgegevens (open science) en onderwijsmateriaal (open educational resources). Ook DUO stelt gegevens als open data beschikbaar, veelal geaggregeerd en ontdaan van identificerende gegevens. Het gaat om gegevens over adressen van instellingen, inschrijvingen en jaarrekeningen van instellingen.

Open Data bestaat in verschillende vormen. Tim Berners Lee heeft het 5-sterren schema voor Open Data opgesteld (zie Figuur 2). In de meest eenvoudige vorm stellen organisaties data in documentvorm beschikbaar (1 ster). Een iets meer geavanceerde wijze is het beschikbaar stellen van de gegevens in een machine-leesbare vorm zoals een spreadsheet (2 sterren). Beter nog is als de gegevens in een leveranciersonafhankelijk formaat beschikbaar zijn, zoals bijvoorbeeld een comma-gescheiden bestand (3 sterren). Op het volgende niveau zijn gegevens uniek identificeerbaar via een URL en betekenisvol beschreven met RDF (4 sterren). Op het hoogste niveau zijn de gegevens ook gerelateerd aan andere gegevens op het (semantische) web (5 sterren). Als gegevens op dit niveau worden gepubliceerd dan zijn ze dus voor iedereen vindbaar, leesbaar en betekenisvol. Openbare gegevens zouden daarom eigenlijk gewoon beschikbaar moeten zijn op dit niveau.

Hoofdstuk7 figuur2.png
Figuur 2 5-sterren schema voor Open Data

Binnen het hoger onderwijs is er sprake van een specifieke vorm van open data: open onderwijsdata. Een aantal instellingen werkt hiertoe samen met SURFnet aan het beschikbaar stellen van veelgebruikte gegevens in het onderwijs. Hiermee kunnen derden web applicaties of mobiele applicaties ontwikkelen op basis van gegevens van de instelling. De focus ligt op het definiëren van een API, een technisch koppelvlak. De services in deze API worden typisch geïmplementeerd in de ESB van een instelling, maar zouden uiteindelijk ook door de leverancier van de bronapplicaties zelf kunnen worden aangeboden. In eerste instantie wordt de focus gelegd op het beschikbaar stellen van gegevens over roosters, tentamenroosters, cursussen, studievoortgang, cursusvoortgang, bibliotheekcatalogus, vrije computers/studieplekken, personalia, telefoonboek en nieuws.

De TU Delft heeft al langer ervaring met open onderwijsdata. In eerste instantie is de focus gelegd op publieke gegevens die ook via de website al ontsloten worden zoals onderwijsroosters, bibliotheekcatalogus, telefoonboek, nieuws en evenementen. Daarnaast worden ook bronnen ontsloten waarvoor authenticatie nodig is zoals individuele roosters, cijfers en studievoortgang. Deze gegevens zijn rechtstreeks afkomstig uit de back-office systemen van de universiteit. Er is daarom extra aandacht besteed aan de beveiliging van de gegevens zodat bijvoorbeeld studenten geen inzicht hebben in de studieresultaten van andere studenten. Mobiele applicaties die dit soort gegevens ontsluiten dienen daarom gebruik te maken van standaard faciliteiten van TU Delft voor het inloggen van gebruikers. Daarbij is een combinatie gemaakt tussen het OAuth2 protocol dat veel gebruikt wordt voor mobiele apps en SAML dat meer gericht is op enterprise identity management.

Figuur 3 laat de architectuur zoals gerealiseerd door de TU Delft zien. Hierin is zichtbaar dat er voor het opvragen van vertrouwelijke gegevens specifieke authenticatieproxies voor de OAuth en SAML protocollen zijn gerealiseerd voor het uitvoeren van authenticatie. Tevens weergegeven in de figuur is de gegevensuitwisseling tussen de verschillende componenten bij een eerste verzoek vanuit een applicatie voor het ophalen van gegevens. Het verzoek komt binnen via een zelfontwikkelde REST Gateway die aan de OAuth proxy vraagt of er al een token voor de gebruiker beschikbaar is. De eerste keer is dat nog niet het geval en zal de OAuth proxy gebruik maken van de SAML proxy voor het verkrijgen van een dergelijk token. Deze laatste maakt gebruik van de identiteiten zoals opgeslagen in de directory server van de TU Delft.

Na een succesvolle authenticatie kan de aanroepende applicatie overgaan tot het daadwerkelijk opvragen van gegevens. De REST Gateway zal deze opvragen via de ESB die de gegevens ophaalt uit de bronapplicatie. Omdat er nu een token beschikbaar is voor de gebruiker is de SAML proxy niet meer noodzakelijk. De REST Gateway verzorgt ook een vorm van caching en kan het interne Canonical Data Model vertalen naar een eenvoudiger extern gegevensmodel. Voor publieke gegevens zal de REST Gateway de OAuth proxy passeren, omdat dan geen authenticatie noodzakelijk is.

Hoofdstuk7 figuur3.png
Figuur 3 Architectuur open onderwijsdata TU Delft