Een native ATS-integratie en middleware lossen hetzelfde probleem op, maar op een andere manier. Bij een native integratie koppelen twee systemen rechtstreeks met elkaar via een vooraf gebouwde verbinding. Middleware vormt juist een tussenlaag die gegevens tussen meerdere systemen vertaalt, routeert en controleert. Een native koppeling is vaak eenvoudiger als het om één stabiele verbinding gaat. Middleware wordt interessanter wanneer een organisatie veel HR- en recruitmentapplicaties gebruikt, processen over meerdere systemen lopen en centraal beheer belangrijk wordt.
Wat is een native ATS-integratie?
Een native integratie is een directe koppeling tussen het ATS en een andere applicatie. Denk aan een HR-systeem, agenda, assessmentplatform of onboardingoplossing. De verbinding is meestal specifiek ontworpen voor die twee systemen.
De kennisbank over essentiële ATS-koppelingen laat zien dat een recruitmentlandschap uit meerdere toepassingen kan bestaan. Een directe koppeling is aantrekkelijk wanneer de gegevensstroom overzichtelijk is en beide systemen langdurig onderdeel van het landschap blijven.
Een native integratie kan bijvoorbeeld een aangenomen kandidaat rechtstreeks vanuit het ATS naar het HRIS sturen. De koppeling weet welke velden aan elkaar gekoppeld zijn en welke status de overdracht activeert.
Voordelen van een directe koppeling
Een directe integratie heeft meestal weinig technische tussenlagen. Dat kan voordelen hebben:
- de gegevensstroom is relatief eenvoudig te volgen;
- er zijn minder componenten die beheerd moeten worden;
- de implementatie kan sneller zijn als de koppeling al bestaat;
- fouten zijn vaak direct te herleiden tot een van beide systemen;
- de functionaliteit sluit meestal aan op een concreet proces.
Voor een organisatie met een klein aantal toepassingen kan dit voldoende zijn. Een aparte integratielaag toevoegen terwijl er slechts één of twee eenvoudige koppelingen nodig zijn, kan onnodige complexiteit opleveren.
Waar zitten de beperkingen?
Een directe koppeling wordt lastiger wanneer steeds meer systemen met elkaar moeten communiceren. Stel dat een ATS gekoppeld is aan een HRIS, assessmenttool, agenda, datawarehouse, onboardingplatform en e-signingoplossing. Ieder van die verbindingen heeft eigen logica, authenticatie, foutafhandeling en beheer.
Wanneer vervolgens het ATS wordt vervangen, moeten veel directe koppelingen opnieuw worden aangepast. Dat vergroot de afhankelijkheid van de bestaande architectuur.
Ook kunnen dezelfde gegevens in meerdere koppelingen anders worden vertaald. Het begrip ‘afdeling’ kan bijvoorbeeld in de ene koppeling een code zijn en in een andere koppeling vrije tekst. Zonder centrale afspraken ontstaat snel een landschap met verschillende definities.
Wat doet middleware?
Middleware is software die tussen applicaties staat. In plaats van dat ieder systeem rechtstreeks met ieder ander systeem praat, communiceren systemen met de integratielaag. Die laag kan gegevens ontvangen, transformeren en doorsturen.
De Europese Commissie beschrijft interoperabiliteit niet alleen als een technisch vraagstuk, maar ook als een combinatie van organisatorische, semantische en technische afstemming. Dat principe is ook bruikbaar bij recruitmentarchitectuur. Een koppeling werkt pas goed wanneer systemen niet alleen verbonden zijn, maar ook dezelfde betekenis aan gegevens geven.
Middleware kan bijvoorbeeld een kandidaatrecord vanuit het ATS ontvangen, een afdelingscode omzetten naar de structuur van het HRIS en daarna alleen de noodzakelijke velden doorsturen.
Middleware als centrale verkeersregelaar
Een integratielaag kan verschillende taken uitvoeren:
- gegevens tussen formaten omzetten;
- velden uit verschillende systemen mappen;
- berichten naar meerdere bestemmingen sturen;
- fouten centraal registreren;
- berichten tijdelijk vasthouden wanneer een systeem niet beschikbaar is;
- toegang en authenticatie centraal beheren;
- monitoren of gegevensstromen goed blijven werken.
Dat maakt middleware vooral interessant wanneer dezelfde gegevens meerdere systemen moeten bereiken.
Een nieuwe medewerker kan bijvoorbeeld vanuit het ATS eerst naar de integratielaag gaan. Die stuurt vervolgens basisgegevens naar HR, start een onboardingproces en levert beperkte informatie aan een rapportageomgeving.
API’s blijven belangrijk
Ook wanneer middleware wordt gebruikt, zijn API’s vaak de technische basis. De integratielaag gebruikt de API van het ATS en de API’s van andere toepassingen.
De OpenAPI Specification is een leveranciersneutrale standaard om HTTP-API’s te beschrijven. Goede API-documentatie helpt daarom zowel bij directe koppelingen als bij middleware.
In het kennisartikel Hoe werkt een API-koppeling met een ATS? staat dat authenticatie, logging, foutafhandeling en versiebeheer onderdeel van het ontwerp moeten zijn. Middleware neemt die verantwoordelijkheden niet weg, maar kan ze wel centraliseren.
Wanneer kies je voor native?
Een directe integratie ligt voor de hand wanneer:
- er maar enkele koppelingen nodig zijn;
- de gegevensstroom eenvoudig is;
- de systemen langdurig samen gebruikt worden;
- weinig transformaties nodig zijn;
- de directe koppeling goed gedocumenteerd en beheersbaar is.
Een voorbeeld is een organisatie die alleen het ATS met het HRIS wil verbinden. Als de overdracht uit een beperkt aantal velden bestaat en de koppeling stabiel is, kan middleware weinig extra waarde toevoegen.
Wanneer is middleware logischer?
Middleware wordt aantrekkelijker wanneer:
- veel systemen met elkaar verbonden zijn;
- dezelfde data naar meerdere bestemmingen moet;
- gegevensformaten sterk verschillen;
- centraal toezicht op integraties nodig is;
- systemen regelmatig vervangen worden;
- de organisatie integratielogica onafhankelijk van één applicatie wil beheren.
Grote organisaties kunnen daarmee voorkomen dat een volledig netwerk van losse point-to-pointverbindingen ontstaat.
Denk aan beheer en afhankelijkheid
Middleware vermindert sommige afhankelijkheden, maar introduceert ook een nieuwe component. Als de integratielaag uitvalt, kunnen meerdere processen tegelijk stoppen.
Daarom moeten monitoring, capaciteit, beveiliging, logging en herstel goed geregeld zijn. De organisatie moet ook weten wie verantwoordelijk is voor wijzigingen in datamapping en proceslogica.
Een directe koppeling kan eenvoudiger zijn, maar maakt organisaties soms afhankelijker van specifieke systeemcombinaties. Middleware biedt meer flexibiliteit, maar vraagt meer architectuur en beheer.
Vergelijk op totale complexiteit
Kijk bij de keuze niet alleen naar implementatiekosten. Vergelijk ook:
- aantal huidige en toekomstige koppelingen;
- hoe vaak applicaties veranderen;
- hoeveel transformaties nodig zijn;
- wie integraties kan beheren;
- hoe fouten worden gemonitord;
- hoe kritisch het recruitmentproces is;
- hoe makkelijk gegevensstromen later aangepast kunnen worden.
De juiste keuze is dus niet automatisch ‘native’ of ‘middleware’. De architectuur moet passen bij de omvang en veranderlijkheid van het landschap. Een kleine organisatie kan uitstekend werken met enkele directe integraties. Een complex recruitmentlandschap kan juist baat hebben bij een centrale integratielaag die voorkomt dat iedere applicatie rechtstreeks met alle andere systemen verbonden raakt.
