Drie best practices voor het duurzaam koppelen van systemen

Het koppelen of integreren van systemen heeft een nieuwe wereld van kostenbesparingen, automatiseringen en procesverbeteringen geopend sinds dat we allemaal meer in de cloud zijn gaan werken. Het beeld dat in het verleden ligt zijn de logge IT systemen die binnen de eigen muren draaiden en de handige IT-er die daar rondliep met allerlei maatwerk programmaatjes om systemen aan elkaar vast te knopen. Sinds de opkomst van 'Software as a Service (SaaS)' zijn er standaarden voor data uitwisseling ontstaan, zoals open API's, gezamenlijk met veilige protocollen voor authenticatie. Hierdoor hoef je niet meer met maatwerk programma's bestanden heen en weer te schuiven in de onderste lagen van de IT systemen, maar kan je op een duurzame en veilige manier systemen aan elkaar koppelen, gebaseerd op marktstandaarden. En nu al die systemen ook in de cloud draaien, kan je die integratie op afstand en in een stabiele omgeving opzetten en hoef je het niet langer in eigen beheer te houden.

Toch liggen er voldoende risico's op de loer als je systemen gaat integreren. Na verloop van tijd wordt het functioneren van bedrijfsprocessen afhankelijk van deze integraties en kan het voor hoge kosten en tumult in de organisatie leiden als er in zo'n integratie iets mis gaat. Omdat wij met Harmonizer inmiddels vaker met dit bijltje hebben gehakt, vonden wij het tijd om de belangrijkste principes die wij hanteren met de wereld te delen. Dit doen we ook vooral om men zich ervan bewust te maken wat er bij komt spelen om een goed functionerende koppeling in te richten. Of je nu zelf een maatwerk koppeling gaat ontwikkelen, of dat je dit met een gestandaardiseerde dienst zoals Harmonizer doet, de volgende best practices zijn van essentieel belang:

Veiligheid en data management

Met de dreiging van cyberaanvallen en opkomst van data privacy regelgeving, staat dit onderwerp hoog op de agenda van bijna iedere organisatie. Uiteraard is er niet één manier om dit te adresseren en moet je de maatregelen afzetten tegen de risico's. De volgende uitgangspunten zijn op basis van onze ervaring altijd van belang:

• Infrastructuur: Een koppeling is veelal een programma dat gegevens uitwisselt tussen twee API's. Dit zal dus ook ergens op een server moeten draaien. Omdat de koppeling op zichzelf vaak niet als een primair systeem in de organisatie benoemd is, wordt deze nog wel eens vergeten. Voor de stabiliteit en veiligheid is het echter belangrijk om dezelfde vereisten te stellen aan de infrastructuur van de koppeling als dat van de systemen die gekoppeld worden. Bijvoorbeeld wie heeft er toegang tot deze server? Hoe wordt deze beheerd en beveiligd? Wordt er periodiek een security audit op uitgevoerd? Dit zijn vragen die ook voor een koppeling gesteld moeten worden.
• Authenticatie: Binnen de huidige marktstandaarden is er nog veel keuzemogelijkheid als het gaat om authenticatie. Een van de veiligere methoden op dit moment is bijvoorbeeld het toepassen van OAuth in combinatie met een zeer sterke private key (bijv. JWT token). Houdt er daarnaast rekening mee dat de koppeling feitelijk toegang krijgt tot twee systemen en denk na wat de gevolgen zouden kunnen zijn als er iemand ongeautoriseerd toegang zou krijgen tot de omgeving waarbinnen de koppeling draait. Het is dan van belang dat er bijvoorbeeld gebruik wordt gemaakt van sterke encryptie technieken om ervoor te zorgen dat de inloggegevens voor de systemen niet open en bloot te bekijken zijn. Ook moet de toegang tot beide systemen snel in te trekken zijn om eventuele gevolgen te beperken. Een goed gebruik is ook, mits het systeem dit toelaat, de reikwijdte van de toegang te beperken tot enkel de gegevens die nodig zijn voor de correcte werking van de desbetreffende koppeling.
• Data opslag minimalisatie: Een koppeling zou feitelijk zelf alleen moeten dienen als doorgeefluik en zelf geen gegevens op moeten slaan. Als dit wel gebeurd, dan vergroot dit alleen maar het risico dat gegevens naar buiten kunnen lekken. Tevens vereist de AVG onder andere dat je de verwerking en opslag van persoonsgegevens tot het minimale beperkt. Mocht het echt noodzakelijk zijn om gegevens tussentijds op te slaan, zorg dan dat deze versleuteld worden en direct verwijderd worden zodra ze niet langer nodig zijn voor het functioneren van de koppeling.

Monitoring

Wij zien helaas nog vaak bij maatwerk koppelingen dat er een piepsysteem gehanteerd wordt. Namelijk, een bedrijfsproces loopt in de soep omdat een automatische data koppeling niet langer goed functioneert. Op dat moment gaan alle alarmbellen af en wordt er geld noch moeite gespaard om de koppeling weer werkend te krijgen. Vaak zijn er simpele redenen waardoor dit gebeurd. Bijvoorbeeld omdat er in één van de gekoppelde systemen iets is veranderd of omdat het account waar de koppeling gebruik van maakt is verlopen. Om dergelijke problemen voor te zijn, is het belangrijk om na te denken over hoe de koppeling gemonitord wordt en wie hiervoor verantwoordelijk is.

Monitoring betekent dat ten eerst iedere fout of issue welke binnen de koppeling plaatsvindt gelogd wordt en gerapporteerd wordt aan een centraal meldpunt. Dit meldpunt zorgt ervoor dat er binnen een korte termijn onderzoek wordt uitgevoerd om de impact van het issue vast te stellen om het vervolgens op te lossen voordat het tot procesverhindering leidt. Ten tweede dient monitoring te worden toegepast om geautomatiseerde 'checks & balances' uit te voeren op de koppeling. Zo kan je bijvoorbeeld controles uitvoeren of de data welke de koppeling te verwerken krijgt aansluit met de verwachtingen die je daarover hebt. Zo kan je nagaan of alle gegevens attributen altijd aanwezig zijn en of ze het juiste formaat hebben. Als er dan iets in het bronsysteem veranderd dat een wijziging in datastructuur tot gevolg heeft, dan kan je daar direct op acteren. Tevens kan je bij het geautomatiseerd wegschrijven van gegevens, achteraf controleren of de gegevens ook in correcte vorm aanwezig zijn in het doelsysteem.

Governance

Omdat een koppeling op de achtergrond draait, is deze makkelijk te vergeten. Echter, wie spreek je aan op het moment dat er problemen ontstaan met de koppeling? Of wie kan ervoor zorgen dat er aanpassingen gedaan worden om aan te sluiten op veranderende processen? Bij een maatwerk koppeling zien we vaak de situatie waarin de ontwikkelaar van de koppeling de organisatie verlaten heeft of niet meer te identificeren is. Maak daarom op zijn minst de volgende afspraken:

• Stel vast wie de functioneel beheerder is van de koppeling. Dit kan bijvoorbeeld ook de manager zijn van de afdeling die gebruik maakt van het resultaat van de koppeling. Deze persoon/afdeling zal fungeren als het eerste aanspreekpunt bij problemen of verzoeken om wijzigingen en is in staat hiervoor een oplossing te coördineren.
• Stel vast wie technisch verantwoordelijk is voor de koppeling. Dit kan bijvoorbeeld de interne IT afdeling of een externe partij zijn die de koppeling heeft ontwikkeld en/of onderhoudt.
• Stel een Service Level Agreement (SLA) op. Hierin maar je praktische afspraken over de beschikbaarheid van de koppeling met de technische verantwoordelijke van de koppeling, maar ook over de wijze waarop er omgegaan dient te worden met wijzigingsverzoeken of problemen en de tijdsspanne waarbinnen deze opgelost dienen te worden.

Koppeling as as Service

Zoals je hierboven hebt kunnen lezen is het implementeren van een koppeling meer dan alleen programmaatje dat data van A naar B verplaatst. De juiste expertise en middelen moeten binnen de organisatie beschikbaar zijn om een koppeling veilig, stabiel en betrouwbaar de kunnen laten functioneren op de lange termijn. Om deze reden hebben we bij Harmonizer het concept 'Koppeling as a Service' uitgevonden. Hierbij kan je binnen een handomdraai gebruik maken van onze best practices op het gebied van koppelingen en zorgen wij voor alle benodigde maatregelen en waarborgen.