Integratie in een SaaS-landschap

SaaS-SaaS integratie

De hoeveelheid data die verwerkt wordt door lokale overheidsorganisaties neemt razendsnel toe. Dit komt o.a. doordat de computing power enorm is gegroeid, dat de opslag van data steeds minder duur wordt en dat organisaties steeds meer aandacht krijgen voor “data” als een belangrijke asset. Dit laatste betekent dat men “data” moet beheren over de totale levenscyclus: dus van ontwerp, opslag, gebruik, onderhoud en archiveren. Data zijn we gaan zien als een waardevol bezit (kapitaal) waarmee de organisatie waarde toevoegt.

Op allerlei manieren proberen data professionals grip te houden op een uitdijend landschap van applicaties en databases. Ketens waarin gegevens worden uitgewisseld worden langer, ook tussen verschillende organisaties. Organisaties hebben een diversiteit aan data- en integratie oplossingen geadopteerd, maar worden nu, enerzijds ten gevolge van het naar de cloud brengen van allerlei applicaties (het verSaaSen van het applicatielandschap) en anderzijds door de aanschaf van SaaS applicaties, geconfronteerd met de vraag hoe gaan we SaaS – SaaS applicaties data met elkaar laten uitwisselen (data- en applicatie-integratie)?

1 point-of-contact

Veel organisaties willen niet afhankelijk zijn van externe partijen om te begrijpen hoe SaaS applicaties gegevens met elkaar uitwisselen. Daarnaast willen veel organisaties de volledige regie in handen hebben en houden om de rol van data binnen de uit te voeren processen te optimaliseren rekening houdend met wet- en regelgeving.

De vraag die hierbij naar voren komt is of dit middels een organisatie eigen integratieplatform moet lopen of dat we dit over kunnen laten aan de leveranciers van de SaaS applicaties zelf. 

Hierbij is het interessant om in te zoomen op een aantal mogelijkheden van een eigen integratieplatform, namelijk: 

• Mogelijkheid tot actieve en permanente monitoring op de data uitwisseling (belangrijk bijvoorbeeld bij privacygevoelige data). 
• 1 Point-of-contact en potentieel meervoudig gebruik van data wordt op die manier zichtbaar en technisch mogelijk. 
• Wijzigingen aan de zijde van bronhouder of afnemer hoeven niet direct effect te hebben op de rest van de keten, het integratieplatform is in staat dit gat te dichten (ontkoppeling).
• Het integratieplatform biedt een gereedschapskist met allerlei centrale (integratie) functionaliteit op het gebied van data, zoals: transformeren (vertalen van bijv. StUF naar REST of vice versa), routeren, orkestreren (/choreograferen), loggen/auditen, monitoren, beveiliging.
• Mogelijkheid om in een (continue) veranderend IV landschap de transformatie/migratie te ondersteunen met eerder genoemde gereedschapskist (tijdelijke verbindingen, tijdelijke vertalingen, etc.).

Wel is het de vraag of het effectief en efficiënt is als iedere organisatie in een eigen integratie-voorziening moet voorzien. 

Loslaten of niet?

Veel SaaS-applicaties worden door hun software leverancier aangeboden met een als blackbox meegeleverd API-platform. Dit API-platform zorgt voor de connectiviteit naar buiten, naar ketenpartners. Deze oplossing biedt veel functionaliteit die het integratieplatform van de organisatie zelf ook biedt. Hier begint het dus te wringen in de hoofden van betrokkenen. Moet het integratieplatform van de organisatie er nu per sé tussen? Deze vraag is niet altijd makkelijk te beantwoorden. 

Belangrijk is in ieder geval om altijd te starten vanuit de voordelen (zoals 1 point-of-contact en ontkoppeling) die het integratieplatform van de organisatie kan bieden. Mocht het integratieplatform van de organisatie op geen enkel vlak voordelen bieden boven een route van SaaS-applicatie naar SaaS-applicatie sta dan toe dat de route direct van SaaS naar SaaS mag lopen (de keten wordt er tenslotte ook korter door!). 

In de praktijk zijn er veel voorkomende redenen om het integratieplatform van de organisatie niet in te zetten:

• Indien de uitwisseling van data plaatsvindt binnen 1 applicatie of suite;
• Indien het open data betreft (bijvoorbeeld het raadplegen van de  LV-BAG of de LV-BGT);
• Indien het eenmalige data uitwisseling betreft, dus van hergebruik door andere afnemers ook geen sprake is;
• Indien de uitwisseling van (bulk)data plaatsvindt voor het genereren van dashboards/rapportages vanuit Business Intelligence (BI). 
• En dan is er nog het kostenaspect: Indien de kosten van implementatie niet opwegen tegen de meerwaarde.

Tot slot, verantwoordelijkheid en onweerlegbaarheid bij data- en applicatie-integratievraagstukken is essentieel. Beide aspecten dienen altijd (dus zowel bij gebruik van het eigen integratieplatform als bij directie koppeling tussen SaaS-SaaS applicaties) te worden geborgd middels governance & beheer processen, ondersteund door tenminste Data Lever Overeenkomst(en), Service Level Overeenkomsten(en), monitoringsmogelijkheden en rapportages.

Bij diverse organisaties worden wij als (data) architecten gevraagd om advies te geven over data- en applicatie-integratie. We zien dat deze vraag steeds vaker gesteld wordt. Integratie is een belangrijk onderwerp binnen het grotere thema ‘Data Management’. Architectuur is essentieel om goed vorm te geven aan de inrichting van Data Management en dus ook aan de inrichting van data- en applicatie-integratie.