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.

Mask Group 1

Starten met systeemintegratie

Als organisatie werk je met een visie en langetermijndoelen. Daar hoort ook een flexibele infrastructuur bij die klaar is voor de toekomst. Daarom is het goed om eerst je applicatielandschap volledig in kaart te brengen en te ontdekken of jouw IT-landschap klaar is voor de cloud.

 

Blauwdruk van bedrijfsprocessen en datastromen

Hoe zitten jouw bedrijfsprocessen in elkaar en door welke systemen en applicaties worden die ondersteund? Het is namelijk belangrijk om de architectuur te ontwerpen rondom je bedrijfsvoering en niet vanuit je backend-applicaties. Je maakt dan veel gerichtere keuzes welke koppelingen er nodig zijn. Bovendien krijg je inzicht in wat de rol is van een systeem en kun je andere 'rommel’ in je IT-landschap opruimen.

Breng ook de te ontsluiten data in beeld: welke gegevens moeten waarheen en waarom? Waar wordt data opgeslagen? Pas wanneer je  inzicht hebt in je datastromen, applicaties en systemen kun je van start met het ontwikkelen van API’s (Application Programming Interfaces). Uiteindelijk is een Service-Oriented Architecture (SOA) een goed streven. Hierbij ontwerp je dus de koppelingen op basis van bedrijfsprocessen en niet op basis van de applicaties die je hebt draaien. Op die manier voorkom je dat je afhankelijk wordt van de applicaties die je gebruikt en ontstaat er een gestructureerde en efficiënte infrastructuur.

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.

Rectangle 3

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.

 

Rectangle 4

Van SOAP naar REST: een technische casestudy van een grote Nederlandse verzekeringsmaatschappij

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.

Rectangle 5

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.

Rectangle 7

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. 1. Implementeer een integratielaag: het beheer en de recovery van data heb je dan op een universele manier ingeregeld.

  2. 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. 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.

Rectangle 8

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.

Rectangle 9

Download ons stappenplan en krijg in 5 stappen meer grip op jouw applicatieketen

Over het Frank!Framework

Met meer dan 30 ervaren integratiespecialisten houden we ons al vanaf 2003 bezig met complexe en minder complexe integratievraagstukken. Enterprise-, data- en systeemintegratie verzorgen we met ons Frank!Framework: een gratis Open Source-framework met kant-en-klare-integratieoplossingen voor betaalbare systeemintegratie.

 

Open Source zonder vendor lock-in

Iedere ontwikkelaar kan met ons (gratis) Frank!Framework aan de slag, omdat het een Open Source-oplossing is. Er is dus geen sprake van een vendor lock-in. Het framework bestaat uit meer dan 100 integratiecomponenten voor veelgebruikte bedrijfs- en cloudapplicaties en deze bouwstenen kun je eenvoudig zelf configureren en koppelen zonder te programmeren. Het Frank!Framework is continu in ontwikkeling. Wanneer nieuwe componenten gereed zijn, worden die beschikbaar gesteld voor alle gebruikers, zodat iedereen daarvan kan profiteren. Op die manier geven we weer iets terug aan de developerscommunity.

 

Betaalbare dienstverlening

De bouwblokken zijn een laagdrempelige manier om data en systemen te integreren. Dat  scheelt een heleboel kosten! Onze integratiespecialisten zijn bijvoorbeeld beschikbaar vanaf €70,00 per uur, terwijl een Java-programmeur al snel tussen de €100,00 en €150,00 per uur kost. En omdat de technische laag losstaat van de functionele laag, kan iemand met functionele kennis gewoon zelf een koppeling maken. Daar heb je dus geen kostbare programmeurs voor nodig.

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.

Gratis adviesgesprek inplannen!

Wil je graag meer weten over wat wij en ons Frank!Framework voor jouw organisatie kunnen betekenen? Of wil je liever sparren over een specifiek integratievraagstuk? Plan dan gratis en vrijblijvend een (digitaal) adviesgesprek in met een van onze integratiespecialisten. We denken graag met je mee en verzorgen een demo op maat.