13. Het IKEA-concept
De veranderde rol van het integratieplatform
Aleksandra had grootste plannen voor de kantine met ontspanningsruimte. Nu vallen de kosten van de hele bouw een beetje tegen. Ze hakt de knoop door:
“Nou, dan maar naar de IKEA en dan zetten we het zelf wel in elkaar. Dan hebben we een leuk Zweeds design, en valt het nog binnen budget. Handen uit de mouwen!”
De kosten van de data integraties lopen inmiddels ook aardig op. De hele opzet vergt behoorlijk wat specialisme. “Kunnen we dat ook niet gewoon op de IKEA-manier doen?”, vraagt Aleksandra zich hardop af.
Maar wat is het IKEA-concept? En hoe zou je dit kunnen toepassen op data integratie?
Economieles
Misschien herinner je het nog van economie: de drie strategieën van Porter. Dit zijn verschillende manieren waarmee bedrijven competitief kunnen zijn in de markt. Dit kan op kosten, differentiatie (service/kwaliteit) of focus.
IKEA’s concept valt moeilijk onder één van deze drie te plaatsen. Het bedrijf wil scherpe prijzen bieden, maar tegelijkertijd ook design, kwaliteit en service. IKEA heeft wellicht niet de allerhoogste kwaliteit, maar het kan zich bij hun hoge omzetten eenvoudigweg niet permitteren dat bijvoorbeeld alle keukenkastjes het snel begeven.
IKEA spreekt zelf van “een breed scala aan goed ontworpen, functionele woninginrichtingsproducten aanbieden, tegen prijzen die zo laag zijn dat zoveel mogelijk mensen ze kunnen betalen”. Maar zoals op vrijwel alle bedrijfswebsites zijn zulke teksten weinigzeggend. Meer heb je aan het volgend artikel:
In het artikel wordt gesteld dat het bij IKEA het niet alleen om kostenbeheersing en service gaat, maar vooral om de psychologie van de klant en hoe je die een totaalervaring geeft.
Als je naar deze ervaring kijkt, blijkt dat alles en dan ook echt alles doordacht is. Van het softijs tot de IKEA-tas (lekker groot) en van de kinderopvang Småland (‘Milan wil opgehaald worden’) tot de Zweedse gehaktballetjes. IKEA blijft steeds verder aan zijn concept schaven, want klanten zijn natuurlijk niet gek.
Verschillende concepten
Een voorbeeld van de unieke aspecten van het IKEA-concept vormen de showrooms waar volledige woon- of slaapkamers staan opgesteld. Klanten kunnen daar even lekker zitten, keukenkastjes open en dicht doen en tussen de potten en pannen rommelen. Alles zonder dat er een vervelende verkoper in de nek hijgt. Aan het einde van de ronde kunnen ze de gewenste items gelijk meenemen en thuis zelf in elkaar zetten. En het in elkaar zetten is dan ook echt makkelijk.
IKEA is natuurlijk niet alleen op de markt, het bedrijf concurreert met meer traditionele concepten. Deze sluiten vaak beter aan bij Porters bedrijfsstrategieën. Bijvoorbeeld een meubelzaak die meubelen van hoge kwaliteit levert, samen met de klant de inrichting ontwerpt en die thuis aflevert en installeert. Denk aan Eijerkamp. Zij gaan uit van een differentiatiestrategie waar klanten een hoge service en kwaliteit krijgen.
Aan de andere kant van het spectrum staan de Doe-het-zelf-zaken. Hornbach bijvoorbeeld wil scherpe prijzen voeren en laat de klant zelf alles bouwen, precies zoals die het zelf wil. De klant, als hij of zij de vaardigheden bezit, kan alles op maat maken zoals hij of zij voor ogen heeft en is dan uiteindelijk het goedkoopste uit.
Wat heeft deze economieles over meubelconcepten nu in godsnaam met data integratie te maken? Eigenlijk heel veel. In deze markt zie je namelijk ook dat traditioneel dezelfde strategieën van Porter worden gevolgd, maar dat er ook nieuwe IKEA-achtige concepten in opkomst zijn.
De traditionele integratiemarkt
De allereerste integratieproducten in de jaren negentig zaten met name in de differentiatiehoek. Zij waren ontwikkeld ter onderscheiding van applicatieproducten met hun beperkte integratiemogelijkheden. Centraal kwam middleware te staan.
De verkoop van middleware ging nog heel traditioneel. De leverancier kwam eerst bij de klant een demonstratie geven. Was de klant geïnteresseerd dan ging het er vervolgens over hoe de klant de integratiesoftware wilde inzetten. Door sales-technici werd vervolgens een implementatieplan voor de inrichting uitgewerkt.
Het doel van een nieuwe inrichting was het scheiden van de applicatielaag van de integratielaag. Dit had weer als doel data barrièrevrij en betrouwbaar door de organisatie te laten lopen. Zulke integraties draaien op het integratieplatform. De integratielaag is dus een verzameling van integraties boven op dit platform.
Om een integratieplatform door een organisatie in te kunnen zetten is er natuurlijk wel software nodig. Eind jaren negentig zijn de meeste integratiepakketten ontstaan. Zij bundelden meerdere integratiefuncties in één suite.
Een integratiefunctie kan bijvoorbeeld “transport” door middel van een broker zijn of “integration patterns” via een ESB. Wanneer een integratiefunctie is geïmplementeerd in een integratieplatform wordt op organisatieniveau ook wel van integration capabilities gesproken.
Tot deze nieuwe software op de markt kwam waren de meeste koppelingen point-to-point met behulp van scripts, adapters of andere programmatuur. Er werd vooral rechtstreeks vanuit code gewerkt. Eigenlijk net zoals er nu nog veel maatwerkapplicaties worden ontwikkeld.
Een traditioneel platform
Omdat er steeds meer applicaties en integraties ontstonden werd er gezocht naar een snellere en uniformere manier om te koppelen. Allereerst ontstonden de ESB’s (Enterprise Services Bus). In het eerste decennium van deze eeuw werden ze mateloos populair. Bij een ESB verwerken één of meerdere services de data en vormen deze samen de integratie. Dit kan een mapping, routing of filter service zijn.
Op een ESB zijn services zoveel mogelijk herbruikbaar en configureerbaar. Ook werd het in de meeste software mogelijk om zelf services in code te schrijven. Vrijwel alle ESB’s, zoals Tibco, Webmethods en Oracle Fusion, zijn Java-gebaseerd. BizTalk (.Net) en InterSystems (C) zijn enkele van de uitzonderingen die niet van Java gebruik maken.
De ESB-software werd vaak uitgebreid met een broker die als transportlaag fungeert. Later werden SOAP services, API’s, Connectors etc. ook door de pakketten ondersteund. Zo kregen deze integration suites steeds meer modules (capabilities).
Een traditioneel integratieplatform is gebaseerd op een zogenoemde integratiesuite (soms hier en daar nog wat aangevuld met maatwerk en tools). Zo’n suite bundelt meerdere producten. Doordat deze integratiesuites steeds meer capabilities kregen, zijn deze pakketten steeds zwaarder, duurder en complexer geworden.
Bij enterprise organisaties zijn desondanks redelijk wat succesvolle implementaties geweest, maar andere organisaties vermeden deze pakketten vanwege de hoge kosten en complexiteit.
Samengevat bouwden software vendors op basis van code (meestal Java) integratiemodules die samen een integrationsuite vormen. Partners van de leveranciers en klanten maakten hier een integratieplatform van. Daarop bouwden en draaiden klanten de integraties.
Open source integratiesoftware
De complexiteit, kennis en kosten van traditionele integratiesuites zijn in de loop van de jaren een steeds groter issue geworden. Een ander nadeel van integratiepakketten is dat de softwareleveranciers soms moeilijk de technologische ontwikkelingen kunnen bijbenen. Dus wellicht zijn de message broker en ESB capabilities sterk ontwikkeld, maar de API en streaming broker capabilities niet (of net andersom).
Veel techreuzen hebben daarom niet gekozen voor integratiesuites, maar hebben zelf tooling en frameworks ontwikkeld. Bijvoorbeeld de volgende brokers:
· Kafka (oorspronkelijk ontwikkeld bij LinkedIn)
· Pulsar (oorspronkelijk ontwikkeld bij Yahoo)
· RocketMQ (oorspronkelijk ontwikkeld bij Ali Baba)
· TubeMQ (oorspronkelijk ontwikkeld bij Tencent)
Deze software tools en frameworks zijn vaak moderner en geavanceerder dan de modules in de integratiesuites.
Veel van deze initiatieven zijn overgegaan naar open source projecten. Alle hierboven genoemde brokers vallen tegenwoordig bijvoorbeeld onder de Apache Foundation. Hiermee zijn deze open source tools en het framework breed toegankelijk geworden.
Get Raymond Meester’s stories in your inbox
Join Medium for free to get updates from this writer.
Open source-stichtingen als de Apache Foundation, de Eclipse Foundation en de Linux Foundation zijn de bouwmarkten van de digitale wereld geworden. Dezelfde reserveringen voor doe-het-zelf-projecten gelden hier dan ook. Degene die de keuzes maakt, het integratieplatform samenstelt en de integraties ontwikkelt moet echt weten wat hij doet. Anders krijg je al snel halve oplossingen, rijp voor het programma ‘Help, mijn man is IT’er’.
Open source integratieplatform
In de softwarelaag is de integratiesuite vervangen door open source-integratietools en frameworks.
Als je het goed doet biedt deze open source software veel mogelijkheden. Bedrijven zijn vrij om zelf de tools en frameworks te kiezen in plaats van een hele suite bij één leverancier af te nemen. Als er iets niet werkt, kunnen ze hetzij volledig zelfstandig, hetzij samen met het open source-project een patch indienen.
Verschillende bedrijven zoals Red Hat hebben ervoor gekozen verschillende Apache Projecten te bundelen en commercieel beschikbaar te stellen. De integratiesoftware Red Hat Fuse bestaat bijvoorbeeld uit:
· Apache Camel (ESB Framework)
· Apache ActiveMQ (Broker)
· Apache CXF (Webservices)
Red Hat garandeert dat de versies goed met elkaar werken en biedt regelmatig patches aan. Daar bovenop bieden ze nog documentatie, support en trainingen.
Doordat er voor elke integratie capability een andere open source tool of framework wordt gebruikt, kan de integratielaag makkelijker evalueren. Als bijvoorbeeld de broker verouderd is dan wissel je die om voor een andere open source broker, maar laat je andere capabilities intact.
Moderne integratieteams
Moderne integratieteams, die traditioneel zowel de integraties leveren als het platform opstellen, hebben tegenwoordig te maken met:
- opbouw van het integratieplatform op basis van meerdere frameworks en tools (in plaats van één suite)
- de business die sneller applicaties wil integreren
Het eerste is vooral low-level, terwijl voor het tweede juist low-code nodig is. Het is een enorme uitdaging om beide dichter bij elkaar te brengen. Dus én een goed platform op te zetten én veel integraties op te leveren.
Traditioneel moesten integratiespecialisten al relatief veel tijd besteden aan het opzetten en onderhouden van het platform. Doordat er tegenwoordig een hoop open source tools, frameworks en cloud services worden gebruikt, is dit nog moeilijker geworden.
De open source-projecten bieden dus wel heel krachtige en flexibele software, maar het is lastiger hier één platform van te maken. De management tools die worden aangeboden voor het beheer zijn daarnaast vaak zeer beperkt en zeer technisch van insteek.
Aan de andere kant wordt er dus door de business verwacht dat er sneller integraties kunnen worden opgeleverd, en dat andere teams ook meer zelf op het integratieplatform kunnen doen. Dit levert een spagaat op voor veel integratieteams die aan de ene kant een stabiel en betrouwbaar platform willen leveren en aan de andere kant snel en flexibel nieuwe integraties willen doorvoeren.
Kortom: er wordt van een modern integratieplatform verwacht dat het de service en kwaliteit van een Eijerkamp levert, maar dat er ook nog steeds doe-het-zelf-mogelijkheden zijn.
Hybride Integration platform
Open source biedt dus een uitstekende basis voor een goed integratieplatform. Het is echter lastig om een hybride integratieplatform te maken dat in de verschillende capabilities voorziet.
Daarom is er niet alleen een beweging om open source tools en frameworks te bundelen, zoals Red Hat doet, maar ook om het integratieplatform makkelijker samen te stellen en hier eenvoudiger integraties op te kunnen maken.
De showroom van dit concept is de cloud.
In plaats van dat je met verkopers en consultants spreekt of de software zelf in elkaar zet, kun je in de cloud verschillende trials van integratiefuncties uitproberen. Zo kun je bijvoorbeeld verschillende brokers met elkaar vergelijken en proberen welke bij je organisatie past. Het idee is dat je precies betaalt voor wat je nodig hebt (Pay per use).
De verschillende integratie-capabilities worden dus niet als één suite verkocht, maar als aparte modules gekozen. Deze kunnen zowel technologisch als van leverancier van elkaar verschillen. Alle zijn direct door de eindgebruiker zelf te gebruiken. Een concept dat sterk lijkt op dat van IKEA!
Een voorbeeld integratieplatform à la IKEA:
Helaas moet gezegd worden dat cloud providers vrijwel een net zo’n groot labyrint vormen als IKEA zelf. De route en bijkomende kosten zijn serieuze valkuilen. Net als bij IKEA is het gevaar dat je met veel meer en heel andere items de showroom uitloopt dan je oorspronkelijk van plan was. Daarnaast gaat het hybride integratie platform niet alleen over de cloud, maar juist ook om de verbinding van de cloud en on premise (zie hoofdstuk Cloud Integratie).
Een extra laag
Tenslotte is er ook nog de trend ontstaan dat ontwikkelaars en andere IT’ers met deze tools zelf integraties bouwen. AmazonMQ, dat gebaseerd is op de open source broker ActiveMQ, biedt niet alleen het voordeel dat het door Amazon gehost wordt, maar ook dat er middelen voor de configuratie en security van de broker beschikbaar zijn.
In sommige gevallen wordt bovenop open source frameworks een heel low-code integratieplatform gebouwd, meestal op de markt gebracht als iPaaS (Integration Platform as a Service). Voorbeelden van iPaaS-producten zijn Dell Boomi, Red Hat Fuse Online en Dovetail. De laatste twee zijn gebaseerd op Apache Camel, Apache ActiveMQ en andere open source technologieën.
Deze zogenoemde iPaaS richten zich voornamelijk op de ESB-functionaliteit, terwijl bijvoorbeeld Azure Service Bus, Amazon SQS of AmazonMQ zich op de broker functionaliteit richten. Voor al deze clouddiensten geldt dat ze gebaseerd zijn op open source frameworks en tools.
De nieuwe workflow
De nieuwe IKEA-programmatuur stelt minder-technische medewerkers in staat om integraties zelf samen te stellen. Net zoals je bij IKEA niet met allerlei verschillende gereedschap hoeft te werken, heb je niet meer allerlei ontwikkelaarstools nodig. De workflow is heel direct.
De oude en de nieuwe developer workflow:
In de tradionele workflow installeerde de ontwikkelaar de “Developer Version” van een integratie suite op zijn laptop. Deze bestond vaak uit een Eclipse IDE met een plugin voor de ontwikkeling van de integraties voor die suite. De integraties werden vervolgens op de laptop ontwikkeld en getest. Daarna werd de code of configuratie gepushed naar een version control system (bijv. Git) en gebouwd door een build server (bijv. Jenkins). Tenslotte werden ze gedeployed op de integratieserver.
In de nieuwe workflow loggen ontwikkelaars (de zogenoemde citizens integrators) direct in via de browser. Daar maken ze de integratie en rollen die met één druk op de knop uit. Op de achtergrond is vaak nog een soortgelijke flow als de traditionele aan het werk, maar deze is geabstraheerd van de ontwikkelaars.
De uitgang
De nieuwe wijze van het samenstellen van het integratieplatform heeft tot een nieuw concept geleid. Er is een extra laag bijgekomen, die voor hosting en management zorgen:
Een echt hybride integratieplatform combineert deze lagen zodat alle capabilities beschikbaar en eenvoudig benaderbaar zijn.
Samengevat vormen open source, cloud en low-code een nieuwe manier voor organisaties op een IKEA-achtige manier hun integratielaag te bouwen.
