Artikel

De do's en don'ts van systeemintegratie

Integratie van systemen is in 2015 een actueel thema. Organisaties trachten steeds meer systemen met elkaar te koppelen zodat data tussen deze systemen met elkaar uitgewisseld kunnen worden.

Uiteindelijk hebben veel organisaties de wens om één bronsysteem te gebruiken voor alle identiteitgerelateerde data, zodat data niet nogmaals overgetypt hoeft te worden in andere systemen. Zelfs wanneer deze systemen zich buiten het netwerk bevinden (bv. in de cloud). Wanneer alle systemen aan elkaar worden gekoppeld, is van iedere identiteit in principe ook te achterhalen wat al zijn rechten en middelen zijn. En dat kan handig zijn voor audits. Bij het koppelen van systemen is het wel verstandig om een aantal do's en don'ts in acht te nemen. Welke dat zijn, leest u hieronder.

Don'ts:

Reken jezelf niet rijk. Want soms denk je veel winst te kunnen behalen met een koppeling, maar is het helemaal niet mogelijk om applicaties met elkaar te laten koppelen. Om precies te weten wat de koppelvlakmogelijkheden zijn van applicaties is het verstandig om een onafhankelijke specialist hier onderzoek naar te laten verrichten.

Wanneer je dat door de leverancier van de applicatie zelf laat doen, beland je in dure consultancy- en documentatietrajecten. Een onafhankelijke leverancier kan uitzoeken of er 'tot de poort' (basis provisioning, dus alleen het aanmaken, aanpassen en verwijderen van users) of 'achter de poort' (gedetailleerde provisioning, dus bijvoorbeeld het zetten van autorisaties binnen de applicaties) kan worden gekoppeld.

Neem bijvoorbeeld een Elektronisch Cliënten Dossier. Veel leveranciers van ECD's staan niet toe dat een derde partij de (functionele) autorisaties van medewerkers kan muteren. In plaats daarvan wordt er gewerkt met zogenaamde sjablonen. Dit sjabloon wordt gelezen door het ECD en bepaalt vervolgens welke (functionele) autorisaties de gebruiker binnen het ECD heeft. Dit heeft als voordeel dat er een directe koppeling met de applicatie is en dat het beheer van de functionele autorisaties binnen de applicatie blijft.

Alles koppelen? Wees voorzichtig
Koppel niet zomaar alles. Wanneer organisaties applicatiekoppelingen overwegen, hebben zij al gauw het idee dat alle systemen gekoppeld moeten worden. Het is echter verstandig om eerst na te gaan of er winst wordt behaald door de systemen aan elkaar te knopen, bv. tijdswinst.

Als het gaat om koppelen van systemen om het in-, door-, en uitstroomproces van identiteiten in het netwerk te automatiseren, is alleen veel (tijd)winst te behalen wanneer er een hoge mutatiegraad en populatie is. Ook wanneer slechts een klein deel van de populatie in een systeem zit opgeslagen, is een jaarlijkse import misschien wel veel goedkoper dan een geautomatiseerde koppeling.

Do's:

Maak een koppeling als tijdigheid een rol speelt. Als mutaties tijdig moeten worden doorgevoerd, bijvoorbeeld omwille van productiviteit of security, dan is een real-time applicatiekoppeling een must. Denk daarbij aan een flexwerker die invalt en toegang moet hebben tot bepaalde applicaties. Daarvoor kan middels een koppeling tussen het HR-systeem, roosterpakket en het netwerk real-time en automatisch een netwerkaccount worden aangemaakt.

Of wat te denken van een medewerker die op staande voet wordt ontslagen. Door een koppeling tussen het HR-systeem, pasjessysteem en netwerk kan ervoor worden gezorgd dat met één druk op de knop logische en fysieke toegang wordt uitgeschakeld.

Autorisatie
Zoek goed uit hoe autorisaties worden toegekend. Door het koppelen van applicaties is het ook mogelijk om aan identiteiten automatisch autorisaties binnen applicaties te verlenen, bijvoorbeeld op basis van informatie over de rol en functie van een medewerker uit het HR-systeem.

Het uitdelen en ontnemen van autorisaties binnen applicaties is een taak die normaal wordt uitgevoerd door een applicatiebeheerder. En de kennis die deze applicatiebeheerder bezit is vaak niet gedocumenteerd. Daarom is het nodig om zeer goed uit te zoeken en te documenteren hoe het proces van autorisatietoekenning nu verloopt en dit proberen te vervangen door business logica.

Ga daarbij echter niet zover dat je een RBAC (Role Based Access Control) model opzet. Dat is veel te uitgebreid. Maar probeer alleen voor de top in kaart te brengen welke rollen, functies en bijbehorende autorisaties er zijn.

Kosten
Kijk goed naar de kosten. In veel gevallen bieden applicaties standaard geen integratie met derde partij systemen, maar moet daarvoor een extra module worden aangeschaft. Zoek dus vooraf uit of er een licentie voor applicatie-integratie is, want zeker in tijden van bezuiniging wordt bij aanschaf van de oplossing deze module vaak wegbezuinigd.

User ID
Denk goed na over de sleutel ofwel de ID van de user. Welke sleutel ga je gebruiken, zodat alle aangesloten applicaties weten om welke identiteit het gaat? Dat kan een personeelsnummer zijn. Deze sleutel moet in ieder geval stabiel zijn en liefst nooit wijzigen. In ziekenhuizen komt het nog wel eens voor dat een personeelsnummer wijzigt. Dan is het dus beter om iets te bedenken dat voldoende stabiel is, bijvoorbeeld een combinatie van geboortenaam en geboortedatum/plaats.

Input en output
Ga na of de applicatie waarmee je wilt koppelen alleen informatie kan ontvangen of ook informatie kan versturen. Wanneer je wilt werken met een Enterprise Service Bus (ESB) is het namelijk belangrijk dat de ESB doorkrijgt welke wijziging heeft plaats gevonden. Wanneer een applicatie deze informatie niet kan geven, dan moet hier een oplossing voor worden gevonden. Een HR-systeem is een goed voorbeeld van een applicatie die niet event-based informatie kan sturen. Om belangrijke veranderingen uit een HR-systeem, zoals een in-, door,- of uitstroom van een medewerker, toch op een ESB te publiceren is een Identity & Access Management systeem als tussenlaag noodzakelijk.

Categorie:   
Auteur(s)
afbeelding van tseinen
Tjeerd Seinen
Tools4ever - Technisch Account Manager

Tjeerd Seinen als account manager werkzaam bij Tools4ever in Nederland. Hij beschikt over zowel een technische als commerciële achtergrond en hij is daardoor in staat om kansen in de markt om te zetten in functionaliteiten voor producten en consultancy diensten. Tjeerd heeft meer dan 20 jaar ervaring op het gebied van sales en softwareontwikkeling. Hij studeerde technische informatica aan de Hogeschool van Amsterdam. Daarnaast rondde hij de MBA-opleiding van het NIMBAS in Utrecht met succes af.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.