Alles over integratie

Goed, je wilt als bedrijf structuur aanbrengen in je systeemintegratie. Veel organisaties werken echter nog met een mix van on-premises systemen en online applicaties. Misschien wil je eerst met een of meerdere systemen naar de cloud migreren, voordat je aan data- en systeemintegratie begint. Of je cloud ready bent, hangt af van de vraag hoe flexibel jouw applicaties zijn. De cloud biedt namelijk het voordeel dat je systemen uit kunt zetten en extra reken- of opslagcapaciteit aan kunt schaffen als dat nodig is. Applicaties die hiermee flexibel kunnen omgaan, zijn geschikter voor de cloud.

Het is ook voordelig voor enterprise-, data- en systeemintegratie wanneer je werkt met cloud agnostic applicaties. Cloud agnostic betekent dat jouw applicatie altijd werkt, ongeacht het cloudplatform. Is dat niet het geval en ben je gebonden aan één cloudplatform, dan noemen we dat cloud native. Als je cloud agnostic bent, is het eenvoudiger om (open-source) data-integratietools te gebruiken. Uiteindelijk is het integreren van systemen altijd mogelijk, ongeacht of ze zich in de cloud bevinden of niet.

Dan hebben we nog SOAP: een wat ouder protocol dat al langer wordt gebruikt voor communicatie tussen webservices. Inderdaad, de voorloper van REST. In vergelijking met SOAP is REST eenvoudiger en moderner, waardoor de behoefte kan ontstaan om van SOAP naar REST te migreren. Een volledige migratie is redelijk complex, want SOAP is als een envelop met data, terwijl REST is opgebouwd uit resources in collecties. Dat betekent dat de functionele opbouw van je data verandert wanneer je volledig overgaat van SOAP op REST. Om dit op te lossen wordt vaak gekozen voor een integratiecomponent, waarop zowel de SOAP- als de REST-interfaces beschikbaar zijn.

Tot slot bestaat er nog GraphQL: een querytaal waarbij je specifiek aangeeft welke informatie je wilt hebben in de response. Terwijl REST een architectuurstijl is die een overzicht van data teruggeeft, ingedeeld in objecten. Het verschil is dat REST veel grotere pakketjes aan informatie ophaalt dan soms nodig is, terwijl GraphQL juist hele specifieke responses teruggeeft. Welke oplossing is dan beter? Dat is volledig afhankelijk of je een query-functionaliteit nodig hebt of werkt met een objectmodel.

Een 'one API fits all' bestaat niet

Helaas bestaat er niet één REST API voor al je koppelingen, want een REST API bouw je voor een specifieke afnemer. Dus voor een applicatie of eindgebruiker. Een API tussen applicaties werkt namelijk op een andere manier dan een API tussen een applicatie en eindgebruiker. Het verschil zit bijvoorbeeld in caching en autorisaties. Het is dus niet ongebruikelijk om voor een objectmodel meerdere API’s te hebben. Probeer wel te voorkomen dat je voor elke afnemer een point-to-point API ontwikkelt, anders verzand je al snel in een spaghetti van REST API’s. Probeer daarnaast deze vier valkuilen bij systeemintegratie te vermijden wanneer je aan de slag gaat met applicatie-integratie met REST-API's.

Een integratieframework kun je zien als een stekkerdoos, waaraan je al je systemen en applicaties koppelt via een stekker. Je kunt je voorstellen dat dat veel flexibiliteit biedt. Wanneer je een systeem wilt aanpassen of uitfaseren, trek je gewoon de stekker eruit, zonder dat dat grote impact heeft op de rest van je IT-landschap. Maar ook wanneer je een nieuwe applicatie wilt integreren, koppel je deze eenvoudig aan de integratielaag. Een integratieframework biedt dus enorm veel flexibiliteit om snel op- en af te schalen. Bovendien profiteer je van meerdere mogelijkheden, zoals het omgaan met granulariteit, flexibiliteit bij upgrades, orkestratie van requests en mapping voor bijvoorbeeld het omzetten van talen.

Waar moet je op letten bij de aanschaf van een integratieframework?

• Of de functionele laag is losgekoppeld van de technische laag. Hierdoor is het gemakkelijker om componenten op elkaar aan te sluiten of uit elkaar te halen.
• Of het een open-source framework is. Je hebt dan geen vendor lock-in, geen hoge licentiekosten en geen behoefte aan dure Java-programmeurs, wat wel het geval is bij Closed Source.
• Of je een verplichte subscription moet afnemen. Bij grote partijen als TIBCO, MuleSoft of WSO2 is dat vaak wel het geval. Dat betekent meestal dat hun open-source oplossing beperkte functionaliteiten heeft en je gaat betalen voor de hele suite met extra oplossingen.
• Of er goede support is. Het is vervelend wanneer je lang moet wachten op patches, feature-requests en een oplossing bij incidenten.

Een eenvoudig IT-landschap met een core-systeem en enkele aanvullende applicaties is nog goed te onderhouden. Maar zodra dat zich uitbreidt met meerdere interne en externe afnemers en het aantal API's toeneemt, wordt onderhoud en beheer van systeemintegraties een dagtaak. Wanneer je dan in een glassbox werkt, inclusief een transparante beheeromgeving, helpt dat om je organisatie tegen dataverlies te beschermen.

Transparantie is key voor een beheerder. Een IT-landschap dat zich in een blackbox bevindt, is veel lastiger te beheren vanwege het gebrek aan inzicht. Bij overeenkomstige incidenten in verschillende applicaties moet je steeds opnieuw het wiel uitvinden. Door een integratielaag toe te voegen, ga je een en ander standaardiseren, zoals het schrijven naar een queue, het uitlezen ervan en calls van webservices. Je transformeert als het ware naar een glassbox-omgeving, waardoor ineens meetbaar wordt hoe jouw applicatieketen draait en wat potentiële bottlenecks zijn.

Als beheerder wil je graag inzicht. Inzicht in de koppelingen die er zijn, en inzicht als er iets misgaat. Een integratieframework zoals Frank!Framework heeft een uitgebreide en beheeromgeving. Dit dashboard helpt niet alleen om onverwerkte data te traceren, maar faciliteert de beheerder op nog veel meer manieren. 

Je wilt natuurlijk goed kunnen monitoren of alle processen op de juiste manier verlopen. Daarvoor is een overzicht nodig van alle koppelingen binnen het integratieframework, want dan kun je precies nagaan of een bericht goed is afgeleverd of op de juiste manier is verwerkt. Het analyseren van berichtenstromen, is ook een onderdeel van een goede beheeromgeving.

Naast dat het interessant is om te weten dat er een uitwisseling van data is tussen twee applicaties, wil je ook terugzien hoeveel data er dan wordt uitgewisseld, hoe groot die berichten zijn en hoelang ze erover doen om door je hele applicatieketen te gaan. Gaat er iets fout? Dan geven error-logs aan wat er misging, zodat je berichten opnieuw kunt verzenden. Een juiste beheeromgeving stelt je in staat om 99 van de 100 problemen gewoon zelf op te lossen, zonder dat daar een programmeur voor nodig is.

Het Frank!Framework is een open-source integratieframework en is de basis voor integratie van bedrijfssystemen en applicaties. Simpel gezegd maakt het Frank!Framework dus makkelijker voor organisaties om allerlei systemen met elkaar te integreren, om zo werkzaamheden uit te breiden en te vergemakkelijken. In deze blog lees je de 5 manieren waarop het Frank!Framework het makkelijker maakt voor de verzekeraar.

Het Frank!Framework is open-source, en iedereen mag het gebruiken. Mocht je op een gegeven moment toch specialistische kennis nodig hebben, dan staan we voor je klaar.

Je kunt bij ons support afnemen voor elk denkbaar vraagstuk, zonder dat je hiervoor een aantal licenties moet hebben. Uiteraard ben je niet verplicht om support af te nemen. Zoals gezegd, kun je 99 van de 100 problemen zelf oplossen met behulp van de uitgebreide beheeromgeving van het Frank!Framework. Wil je toch graag gebruik maken van een supportcontract? We gaan graag met je in gesprek. De looptijd bepaal je zelf.

Lees meer over Frank as a Service

Proof of Concept 

Wij zijn natuurlijk al lang overtuigd van de kracht van ons integratieframework. Maar een Proof of Concept (PoC) is een laagdrempelige manier om te ontdekken of het Frank!Framework een antwoord is op jullie problemen en voldoet aan jullie wensen. Of het nu gaat om het koppelen van twee API's of het oplossen van jouw hoofdpijndossier, we gaan er graag mee aan de slag. Een hardnekkig vooroordeel is dat een PoC handenvol geld kost. Maar met het Frank!Framework is een Proof of Concept wél betaalbaar en ontdek je welke mogelijkheden er zijn. Profiteer van onze integratiekennis zonder dat je direct ergens aan vastzit.