Alles over systeem-, enterprise- en dataintegratie.
Bedrijven starten vaak met het inrichten van één systeem, zoals een ERP-systeem, voor hun belangrijkste processen. Maar naarmate de organisatie groeit, ontstaat ook behoefte aan andere applicaties, bijvoorbeeld voor de HR- of marketingafdeling. Wanneer je alles aan elkaar blijft knopen, ontstaat er op een gegeven moment een wirwar van API's en andere integratiecomponenten die systemen en applicaties met elkaar verbinden. Een hell of a job om te onderhouden. Daarom delen we al onze best practices voor enterprise-, data- en systeemintegratie, zodat jij gestructureerd aan de slag kunt, met als resultaat: een integrale infrastructuur met systemen die naadloos samenwerken.
Inhoudsopgave
1. Starten met systeemintegratie
2. Van on-premises naar de cloud
3. Technische integraties met (REST) API's
5. Toepassen van een integratieframework
6. Het grootste voordeel van een integratieframework
7. Inrichten van je integratieframework
10. Uitgebreide beheeromgeving
11. Frank!Framework integreren in de verzekeringsmarkt
12. Low code platforms integreren
Van on-premises naar de cloud
Veel organisaties werken 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 mogelijk 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.
Technische integraties met (REST) API's
Nu je je IT-landschap in kaart hebt gebracht en hebt gecheckt of al je applicaties gereed zijn voor de cloud (mocht je die nog willen migreren), duiken we het technische gedeelte in: de API's. We vergelijken enkele protocollen met elkaar, zodat je daar een beter beeld bij krijgt en beter kunt selecteren wat past bij jouw behoeften.
(REST) API, SOAP en GraphQL: een vergelijking
Een API (Application Program Interface) is een koppeling tussen twee applicaties en zorgt ervoor dat gegevensuitwisseling mogelijk is. REST staat voor Representational State Transfer en wordt gebruikt om HTTP-services (webservices) te ontwikkelen, vaak met een OpenAPI-specificatie (OAS). Het grote verschil tussen API en REST API is dat een API specifiek voor een platform of applicatie is geschreven, terwijl een REST-service is gebouwd op de principes van HTTP en in theorie ook op andere protocollen kan werken. In ieder geval wil je een robuuste (REST) API bouwen die niet omvalt, hapert of trager wordt wanneer er bijvoorbeeld meer verkeer is naar je website.
SOAP en REST
Dan hebben we nog SOAP: een wat ouder protocol dat al een tijdje wordt gebruikt voor communicatie tussen webservices. Inderdaad, de voorloper van REST. In vergelijking met SOAP is REST simpeler 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. Daarom 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 objectenmodel.
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 objectenmodel 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 te vermijden wanneer je aan de slag gaat met applicatie-integratie met REST-API's.
Toepassen van een integratieframework
Koppelingen tussen systemen en applicaties beginnen met een API. Maar breiden je API's uit, dan wordt het tijd om na te denken over een integratieframework om die eerdergenoemde spaghetti van koppelingen te voorkomen.
Zelf bouwen versus integratieframework
REST API's kun je volledig zelf programmeren, maar tegenwoordig doet bijna niemand dat nog. Er zijn namelijk genoeg handige frameworks beschikbaar die je al een flink eind op weg helpen bij het programmeren. Zoals het Spring-framework voor het ontwikkelen van Java-software. Dat bestaat uit meerdere Open Source-libraries die bij elkaar horen en al zijn getest.
Een alternatief is een kant-en-klaar-integratieframework: een totaalpakket waarbij aan alle technische details, zoals security, performance en documentatie, is gedacht. Daardoor is er veel minder technische kennis nodig en bouw je koppelingen eenvoudig zelf. Waar je je voornamelijk op focust, zijn de functionele zaken. Hierdoor ben je met een kant-en-klaar-integratieframework veel productiever dan bijvoorbeeld met het Spring-framework.
Het grootste voordeel van een integratieframework
Een integratielaag 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 van 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 aan extra oplossingen.
• Of er goede support is. Het is vervelend wanneer je lang moet wachten op patches, feature-requests en een oplossing bij incidenten.
Inrichten van je integratieframework
Heb je vervolgens de keuze gemaakt om met een integratielaag aan de slag te gaan, dan is het belangrijk om alle processen goed in te richten. Je wilt natuurlijk niet dat er dubbele data ontstaat of dat gegevens zelfs verloren gaan. Over dataverlies lees je later meer, maar om duplicates te voorkomen, bestaan verschillende methoden waarmee je rekening kunt houden bij het inrichten van je integratieframework, zoals:- • Het exactly once uitvoeren van een verzoek. Wanneer een backend-applicatie niet in staat is om duplicates te vermijden, is de integratielaag dé plek om zo'n manco op te vangen. Daarom krijgt elk bericht een identifier mee. Daarmee kan worden gecontroleerd of een bericht met die specifieke identifier al is verwerkt of nog niet, zodat een verzoek exactly once wordt verwerkt.
- • Het zorgen voor guaranteed delivery. Je wilt namelijk dat berichten op de juiste manier worden verwerkt, zodat een aanvraag naar behoren wordt beantwoord. Het helpt dan ook wanneer je bij een REST API werkt met HTTP-codes, zodat de gebruiker én de ontwikkelaar feedback krijgen of beantwoording is gelukt of niet.
- • Het inregelen van queueing. Een queueing-applicatie slaat het bericht op totdat deze een bericht krijgt van de afnemende partij dat het bericht is verwerkt. Queueing maakt het mogelijk om data uit te wisselen met tussentijdse persistentie.
- • Het transactioneel verwerken van data. Hierdoor wordt een heel pakket aan data in één keer verwerkt en niet gedeeltelijk, wat weer de kans op duplicate data kleiner maakt.
Onderhoud en beheer
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 een dagtaak. Wanneer je dan in een glassbox werkt, inclusief een transparante beheeromgeving, helpt dat om je organisatie tegen dataverlies te beschermen.
Werk je in een blackbox of glassbox?
Transparantie is key voor een beheerder. Een IT-landschap dat zich in een blackbox bevindt, is veel lastiger te beheren vanwege het gebrek aan transparantie. 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 naar een glassbox-omgeving, waardoor ineens meetbaar wordt hoe jouw applicatieketen draait en wat potentiële bottlenecks zijn.
Dataverlies en recovery
Wanneer je er niet in slaagt om een data-integratie goed uit te voeren, loop je het risico op dataverlies. Ook uitval bij een externe partij, programmeerfouten in je eigen applicatie of een gebruikersfout, zijn oorzaken waardoor data verloren gaat. Gelukkig is het meestal zo dat niet al je data weg is, maar wel dat er een gedeelte ontbreekt. Dan is het prettig wanneer je je applicatielandschap zo hebt ingeregeld dat je die data snel kunt terughalen en weer opnieuw kunt aanbieden.
Drie tips om dataverlies te voorkomen:
-
1. Implementeer een integratielaag: het beheer en de recovery van data heb je dan op een universele manier ingeregeld.
-
2. Gebruik een error storage. Berichten waarvan het niet is gelukt ze te verwerken, worden vastgehouden in de error storage. Hiermee krijgt een beheerder inzicht in wat het probleem is en wat er misging, zodat het proces kan worden aangepast en verbeterd.
-
3. Werk met een audit trail. Met een audit trail is het mogelijk om een uniek bericht te volgen door je hele applicatieketen en daarbij het verwerkingsproces te monitoren.
Uitgebreide beheeromgeving
Een uitgebreide en transparante beheeromgeving helpt niet alleen om onverwerkte data te traceren, maar faciliteert de beheerder op nog vele andere 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 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.
Hoe integreer je low code platforms zoals Mendix en OutSystems in je organisatie
Volgens Gartner groeit de adoptie van low code platforms ieder jaar met 20%. Het is dan ook niet gek dat de meeste organisaties in enige vorm al gebruik maken van een platform zoals Mendix of OutSystems. Hier komt wel meer bij kijken dan het simpelweg aanschaffen van een licentie. Want hoe integreer je je low code platform met de rest van je systemen? In deze blog vertellen we je hoe je dit aanpakt..
Support-as-a-Service
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 gebruikmaken van een supportcontract? Dan kun je al vanaf €500,00 per maand bij ons terecht. De looptijd bepaal je zelf.
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 met 50% korting alle mogelijkheden. En je profiteert van onze integratiekennis zonder dat je direct ergens aan vastzit.
