applicaties koppelen - ipaas oplossing

Technology 12.02.2021

Best-practices voor applicaties koppelen

Het koppelen van applicaties wordt doorgaans gezien als een technisch vraagstuk. Al snel wordt er bij integratie besproken over technieken als webservices en ESB’s. Maar integratie gaat in essentie niet over technologie. Het gaat erom een fundament neerleggen dat naar de toekomst toe een belangrijke bijdrage levert aan de bedrijfsdoelstellingen. Techniek is een middel, geen doel. En daarom is het koppelen van applicaties in de praktijk complex: juist door het verbinden van business en IT. In dit blogartikel vind je de 7 bewezen architecturen.

Bekijk ook onze dienst Connect Plus.

Waarom een architectuur?

Een architectuur is geen one-size-fits-all. Vanuit Broad Horizon beginnen we daarom altijd met het stellen van vragen. We willen weten wat de doelstellingen zijn en daarmee voorspellen we welke richting het bedrijf wil groeien. Een architectuur maken we dus op basis van business requirements, niet op basis van technologie.

Om de business requirements in korte tijd te doorgronden, beginnen we bij de kern. De waardepropositie van het bedrijf richting haar klanten. Waarom komen klanten daar? Wat vinden ze dat ze elders niet vinden? Wat maakt dit bedrijf uniek? En hoe kan IT daar een bijdrage aan leveren of het zelfs versterken? Diverse modellen kunnen hierbij helpen, zoals het Business Model Canvas. Door deze samen in te vullen komen in principe alle antwoorden naar voren. Vanuit het model kan gefilterd worden welke fundamentele eisen er aan IT worden gesteld.

Werken vanuit best-practises

Hoewel ieder bedrijf anders is en dus de requirements ook verschillen, kan er natuurlijk wel gebruik gemaakt worden van best-practises bij anderen. Soms om deze één op één toe te passen, maar vooral als referentie om vervolgens tot een eigen architectuur te komen. Onderstaand 7 scenario’s.

Scenario 1: Alles in één systeem

Hoewel dit het scenario is waar veel bedrijven ooit mee zijn gestart, lijkt het inmiddels een onrealistische utopie te zijn. Want hoe groot is de kans dat je één applicatie vindt die aan alle eisen en wensen voldoet? En waarom zou je dat willen als het koppelen van systemen tegenwoordig geen probleem meer zou moeten zijn?

Het voordeel van deze architectuur is echter enorm. Alle gegevens worden in één centraal systeem opgeslagen en bewerkt. Er is maar één versie van de werkelijkheid. Als ergens een wijziging plaatsvindt, dan hoeft dat maar op één plek. En als je ooit wilt upgraden naar een nieuwe versie, dan scheelt het een heleboel tijd in het testen.

De keuze om niet alles in één systeem te vangen biedt functioneel dus een voordeel. Maar daar wordt wel een prijs voor betaald. Zeker in bedrijfsomgevingen waar veel flexibiliteit van de systemen wordt gevraagd, dus waar veel aanpassingen zijn te verwachten, leiden koppelingen tot veel extra kosten en doorlooptijd.

Scenario 2: Eén systeem is leidend

De kracht van het eerste scenario is dat alle data centraal is opgeslagen en er maar één versie van de werkelijkheid is. Maar de beperking van alles in één systeem maakt het in de praktijk vaak onrealistisch. Al was het maar omdat ook externen zoals klanten en leveranciers vaak toegang tot informatie moeten krijgen en het niet gewenst is dat die direct tot het eigen systeem toegang krijgen.

Scenario 2 gaat ervan uit dat nog steeds één systeem centraal staat, maar dat andere systemen eraan zijn te koppelen. Denk aan een webshop, een portal en/of een mobiele app. Die functioneren dan als front-end voor een specifieke doelgroep, maar halen de gegevens uit het leidende systeem.

Dit scenario gaat er dus nog steeds vanuit dat er één versie van de werkelijkheid is. Er is echter geen integrale oplossing en er zullen dus koppelingen moeten worden ontwikkeld en onderhouden. Dit betekent dat mutaties in het datamodel, maar ook dat de complexiteit van de koppelingen meevalt omdat voor iedereen duidelijk is wat het leidende systeem is.

Het nadeel kan zijn dat daardoor het centrale systeem moet worden uitgebreid om data uit andere systemen te kunnen doorgeven die ver weg staan van het doel van het leidende systeem. Belangrijk daarom is vroegtijdig vast te stellen welke gegevensstromen er uiteindelijk worden verwacht.

Scenario 3: Het proces als basis, applicaties in hun comfortzone

In dit scenario is er geen sprake van één leidend systeem, maar wordt per proces bepaald welk systeem leidend is. Denk aan een CRM-systeem voor de front-office en een ERP-systeem voor de back-office.

Alle andere systemen worden dan aan één van deze systemen gekoppeld afhankelijk van bij welk proces ze thuishoren. Een scanningsapplicatie in het magazijn zal dan bijvoorbeeld worden gekoppeld aan ERP (logistiek), terwijl een module om nieuwsbrieven te versturen dan wordt gekoppeld aan CRM (marketing).

Dit scenario werkt goed wanneer het proces duidelijk en vastomlijnd is en wanneer daarin duidelijke afbakening kan plaatsvinden. Als de overlap van data en processen minimaal is, kan een dergelijk scenario sterk zijn doordat applicaties binnen hun comfortzone opereren.

Lastig wordt het indien de overlap van data wel groot is. Als het resultaat zou zijn dat alle klanten, alle artikelen, alle prijzen, alle orders, alle facturen, etc. in meerdere systemen moeten worden vastgelegd, dan betekent dat een uitgebreide en weinig flexibele koppeling.

Scenario 4: Best of breed

In dit scenario wordt ervan uitgegaan dat er veel verschillende systemen in gebruik zijn die onderling zullen overlappen qua datamodel en functionaliteit.

In dit scenario wordt niet geprobeerd om alle data in vaste systemen vast te leggen. Elk systeem krijgt in dit scenario een eigen taak en houdt zich aan zijn eigen scope. Het voordeel is dat er maximaal kan worden uitgegaan van standaard software en dat elke applicatie die iets bijdraagt aan de bedrijfsdoelstellingen kan worden ingezet.

Nadelige aan dit scenario is de complexiteit. Het opstellen en bijhouden van een goede architectuur is onontkoombaar. Aangezien de strategische waarde van IT voor veel bedrijven betekent dat het ook aan te raden is om in huis over de juiste competenties te beschikken om sommige zaken zelf in de hand te houden.

Scenario 5: Point-to-point

De meest bekende en pragmatische integratiewijze is point-to-point. Er wordt in kaart gebracht welke applicaties met elkaar gekoppeld moeten worden en deze worden stuk voor stuk ontworpen, gerealiseerd, getest en in gebruik genomen.

Wanneer het aantal koppelingen meevalt en de verwachting is dat dat in de toekomst ook zo zal blijven, dan is point-to-point een goede keuze (ook in scenario 2 en 3). Maar als het aantal koppelingen toeneemt, is het risico op zogenaamde spaghetti groot. Het overzicht raakt dan kwijt, fouten zijn niet meer te herleiden en veranderingen of upgrades van onderdelen zijn risicovol omdat de impact niet te overzien is.

Het nadeel van point-to-point is een gebrek aan overzicht over de algehele werking. Bij uitval krijg je vaak pas signalen vanuit je organisatie als er problemen zijn met de gegevensuitwisseling. Er is geen monitoring van alle werkende interfaces en dus geen proactief beheer.

Scenario 6: Message Broker

Wanneer er binnen een applicatielandschap veel koppelingen zijn, of zijn te verwachten, dan is een Message Broker van toegevoegde waarde. Een Message Broker wordt als spin in het web geplaatst en dient als doorgeefluik van berichten tussen applicaties. Elke applicatie is gekoppeld met de broker en er zijn geen directe onderlinge koppelingen.

Voordeel is dat er inzicht ontstaat. Op één plek zijn alle berichten te herleiden en fouten kunnen snel geanalyseerd worden. Bovendien maakt deze architectuur het eenvoudiger om applicaties te upgraden omdat slechts de koppeling met de broker hoeft te worden getest. Er ontstaat controle over het gehele landschap.

Scenario 7: Enterprise Service Bus

Een ESB lijkt in een aantal facetten op de Message Broker. Ook deze wordt tussen de applicaties gezet en regelt centraal de koppelingen. Het verschil met de broker is dat een ESB veel minder denkt vanuit berichten, maar wordt opgezet vanuit processen. Zo zal de ESB een functie NieuweKlant() ondersteunen waarop andere applicaties zich kunnen abonneren.

Bij een ESB worden het datamodel en de processen dus centraal gedefinieerd. Als applicatie hoef je niet te weten welke andere applicaties er in het landschap zijn, want je communiceert volgens vooraf opgestelde contracten met de ESB.

Nadeel van een ESB is dat deze vaak hele grote stukken maatwerk bevat. Een ESB wordt vaak veel groter en complexer dan vooraf gedacht. En als er processen wijzigen, moeten alsnog alle koppelingen worden getest. De ESB is op papier dus een ideale oplossing, maar geeft in de praktijk alsnog een groot aantal nadelen. En als een bedrijf al een kernsysteem heeft waarin vrijwel alle data en processen zijn ondergebracht (zoals een ERP-systeem), dan leidt een ESB tot onnodig veel redundante logica en lijkt scenario 2 beter toepasbaar.

Welke tool(s) kun je inzetten?

We zijn dit artikel gestart met de boodschap dat je niet te snel naar tools moet grijpen. Maar als de business doelstellingen helder zijn, de IT-vereisten zijn bepaald, en de architectuur is uitgewerkt dan is de vraag over de tools weer relevant.

Want op het gebied van integratie zijn veel mogelijkheden. Een ontwikkeling die we de laatste jaren steeds meer omarmen is iPaaS. Integration Platform as a Service (iPaaS) is een suite van clouddiensten die helpt om integraties tussen systemen, processen en data te versnellen. Vaak is het mogelijk om met een iPaas platform data uit verschillende bronnen (on-premise, cloud, Internet of Things) met elkaar te combineren. Daardoor zal data sneller en foutlozer in diverse systemen getoond worden.

Een iPaas moet nog wel connectie maken met alle onderlinge applicaties, maar de flexibiliteit hierbij is eindeloos groot. Denk aan de herbruikbaarheid van de techniek voor het maken van de koppelingen met individuele applicaties. Dit neemt niet weg dat afstemming met diverse partijen over het koppelvlak nodig blijft, maar de flexibiliteit is aanwezig.

Binnen Broad Horizon noemen we ons iPaaS platform Connect Plus: een schaalbaar, cloud integratieplatform (iPaas) voor gegevensuitwisseling op basis van Azure–technologie. Het platform biedt een constant overzicht van alle gegevens die zich bewegen tussen jouw verschillende bedrijfsapplicaties. Met Connect Plus kan je de transitie naar de cloud maken zonder dataverbindingen te breken.

Tot slot

Zoals we begonnen zijn, eindigen we. IT-integratie, maar eigenlijk IT in het algemeen, is in onze ogen altijd dienend aan de business. Dat betekent ook dat business requirements leidend zijn in het gehele proces. En omdat het geen one-size-fits-all oplossing betreft, is het elke keer weer opnieuw een zoektocht om tot de juiste keuzes te komen. Al kan je met een iPaaS oplossing ook alle kanten uit.

Connect Plus

Bekijk ook onze dienst Connect Plus – ons integration Platform as a Service. Connect Plus is een centrale hub die gegevensuitwisseling vereenvoudigt en complexiteit tussen diverse interfaces voorkomt. Met de iPaaS oplossing Connect Plus koppel je applicaties op de nieuwe manier aan elkaar. In plaats van point-to-point interfaces implementeren wij een op Azure gebaseerde centrale hub die datastromen vanuit verschillende systemen aan elkaar knoopt en met elkaar laten communiceren.