IKEA, vele lopen weg met hun meubels. Althans, met het bouwpakket… Ze lopen er mee weg, zowel letterlijk als figuurlijk. Anderen vinden het juist vreselijk. Maar zelfs vele ‘haters’ die shortcuts in de showroom nemen, hebben bewondering voor het IKEA-concept. Maar wat is het IKEA-concept? En wat heeft dit met data-integratie te maken?
Economieles
Misschien kennen sommige het nog van economieles; de drie strategieën van Porter. Dit zijn verschillende manieren waarmee bedrijven competitief kunnen zijn in de markt. Dit kan op kosten, differentiatie (bijvoorbeeld door goede service/kwaliteit) of focus.
IKEA’s concept valt moeilijk onder één van de drie te plaatsen. Het wil scherpe prijzen bieden, maar tegelijkertijd ook design, kwaliteit en service. IKEA heeft wellicht niet de allerhoogste kwaliteit, maar het kan zich bij hoge omzetten eenvoudigweg niet permitteren als bijvoorbeeld alle keukenkastjes het snel begeven.
IKEA zelf spreekt 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 alle bedrijfswebsites is dat weinigzeggend. Meer heb je aan dit artikel op Frankwatching.
Bij IKEA gaat het dus niet alleen om kosten en service, maar vooral om de psychologie van de klant en hoe je die een totaalervaring geeft.
Als je zoals in het artikel naar deze ervaring kijkt, blijkt dat alles en dan echt ook alles doordacht is. Van het softijs tot de IKEA-tas (lekker groot) en van Småland tot de Zweedse gehaktballetjes. IKEA blijft steeds verder aan zijn concept schaven, want klanten zijn natuurlijk niet gek.
Verschillende concepten
Een aantal unieke aspecten van IKEA concept zijn een showroom waar volledige woon- of slaapkamers staan opgesteld. Klanten kunnen even lekker zitten, liggen, keuken kastjes open en dicht zetten zonder dat er een verkoper in de nek hijgt. Vervolgens kan je aan het einde de gewenste item gelijk meenemen en thuis zelf in elkaar zetten. En in elkaar zetten is dan ook echt makkelijk.
IKEA is natuurlijk niet alleen op de markt, ze concurreren met meer traditionele concepten. Deze sluiten vaak dichter aan bij Porters strategieën. Bijvoorbeeld een meubelzaak die hoge kwaliteit meubelen levert, samen met de klant de inrichting ontwerpt en deze thuis aflevert en installeert. Denk aan Eijerkamp. Zij gaan uit van een differentiatie strategie.
Aan de andere kant van het spectrum staan de Doe-Het-Zelf zaken. Hornbach wil bijvoorbeeld scherpe prijzen en laat de klant zelf alles bouwen precies zoals die zelf wilt. De klant, als hij of zij de vaardigheden bezit, kan alles op maat maken precies zoals hij of zij voor ogen heeft en is dan uiteindelijk het goedkoopste uit.
Traditionele integratie markt
Wat heeft het hele verhaal over meubelconcepten nu in godsnaam met data-integratie te maken? Eigenlijk heel veel. In deze markt zie je dat traditioneel dezelfde strategiën worden gevolgd als bij Porter, maar dat er nieuwe IKEA-achtige concepten in opkomst zijn.
De allereerste integratieproducten in de jaren negentig zaten met name in de differentiatie hoek. Zij wilden zich onderscheiden van applicatie producten met diens beperkte integratiemogelijkheden. Centraal kwam middleware te staan.
De verkoop ging nog heel traditioneel. De leverancier kwam bij de klant een demonstratie geven van de belangrijkste functionaliteit. Was de klant geinteresseerd dan ging het vervolgens in gesprek over hoe die de software wilde inzetten. Door sales technici werd vervolgens een implementatieplan voor de inrichting uitgewerkt.
Doel van een nieuwe inrichting was het scheiden van de applicatielaag van de integratielaag. Dit had weer het doel om data barrièrevrij en betrouwbaar door de organisatie te laten lopen. Zulke integraties draaien op het integratie platform. De integratielaag is dus een verzameling van integraties boven op dit platform.
Om een integratie platform door een organisatie in te 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 integratie capabilities gesproken.
Tot deze nieuwe software op de markt kwamen 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 maatwerk applicaties worden ontwikkeld.
Een traditioneel platform
Omdat er steeds meer applicaties en integraties ontstonden werd er gezocht naar een snellere en meer uniforme manier om te koppelen. Allereerst ontstonden dus de ESB’s (Enterprise Services Bus). In het eerst decenium van deze eeuw werden ze mateloos populair. Bij een ESB verwerken 1 of meerde services de data en vormen samen de integratie. Dit kunnen bijvoorbeeld 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 (custom services). Vrijwel alle ESB’s, zoals Tibco, Sonic, Websphere, Webmethods en Oracle Fusion, zijn Java gebaseerd. BizTalk (.Net) en InterSystems (C) zijn enkele van de uitzonderingen.
De ESB software werd vaak uitgebreid met een broker die als transportlaag fungeerde. 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 integratie suite (soms hier en daar nog wat aangevuld met wat maatwerk en tools). Zo’n suite bundelt meerdere producten samen. Doordat deze integration suites 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 daarom.
Samengevat bouwden software vendors op basis van code (meestal Java) integratie modules die samen een integration suite vormen. Partners van de leveranciers en klanten maakten hier een integratie platform van. Daarop bouwden en draaien klanten de integraties.
Open source integratieplatform
De complexiteit, kennis en kosten zijn in de loop van de jaren een steeds groter issue geworden. Een ander nadeel van integratiepakketten is dat de softwareleveranciers soms lastig de technologische ontwikkelingen kunnen bijbenen. Dus wellicht zijn de queueing broker en ESB capabilities sterk ontwikkelt, maar API en streaming broker niet (of andersom).
Veel tech-reuzen hebben daarom niet gekozen voor integratiesuites, maar hebben zelf tooling en frameworks ontwikkeld. Bijvoorbeeld de volgende brokers:
- Kafka (Oorspronkelijk ontwikkelt bij LinkedIn)
- Pulsar (Oorspronkelijk ontwikkelt bij Yahoo)
- ActiveMQ (Oorspronkelijk ontwikkelt bij Fuse/Red Hat)
- RocketMQ (Oorspronkelijk ontwikkelt bij Ali Baba)
- TubeMQ (Oorspronkelijk ontwikkelt bij Tencent)
Vaak zijn deze software tools en frameworks moderner en geavanceerder dan de modules in de software suites. Veel van deze initiatieven zijn overgegaan naar open source projecten. Alle 5 genoemde brokers vallen bijvoorbeeld tegenwoordig onder de Apache Foundation. Hiermee zijn deze open source tools en framework breed toegankelijk geworden.
Open source stichtingen als de Apache Foundation, the Eclipse Foundation en 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 integratie platform samenstelt en de integraties ontwikkelt moet echt weten wat hij doet. Anders krijg je al snel halve oplossingen voor het programma “Help, mijn man is IT’er?”.
In de software laag is de integratie suite daarbij vervangen door open source integratie tools en frameworks. Als je het goed doet bieden deze open source software ook veel mogelijkheden. Bedrijven zijn vrij om zelf de tools en frameworks te kiezen in plaats van een hele suite bij één leverancier. Als er iets niet werkt, kunnen ze hetzij volledig zelfstandig, hetzij in samenwerking met het upstream project een patch indienen.
Verschillende bedrijven zoals Red Hat hebben gekozen verschillende Apache Projecten te bundelen en commercieel beschikbaar te stellen. 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. Daarnaast bieden ze support en trainingen.
Doordat er voor elke integratie capability een ander open source tool of framework wordt gebruikt, kan de integratielaag makkelijker evalueren. Als bijvoorbeeld de broker verouderd is dan wissel je die om, maar laat je andere capabilities intact.
Moderne integratie teams
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 1 suite)
- Het integratieplatform wordt verwacht dichter bij de business te staan.
Het eerste is vooral low-level, terwijl de tweede vooral low-code is. Het is een enorme uitdaging om beide dichter bij elkaar te brengen. Dus EN een goed platform op te zetten EN veel integraties op te leveren.
Traditioneel moesten integratiespecialisten al relatief veel tijd besteden aan het opzetten/schalen/onderhouden van het platform. Doordat er tegenwoordig een veeltal 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 tooling die wordt aangeboden is daarnaast vaak zeer beperkt en zeer technisch van insteek.
Aan de andere kant wordt er verwacht dat er sneller integraties kunnen worden opgeleverd, en dat andere teams ook meer zelf op het integratie platform kunnen doen. Dit levert een spagaat op voor veel integratieteams die aan de ene kant een stabiel en betrouwbaar platform willen leveren met voldoende capabilities, evenals ook snel en flexibel nieuwe integraties te kunnen opleveren.
Hybride Integration platform
Open source biedt dus een uitstekende basis voor een goed integratie platform. Het is echter lastig om een hybride integratie platform te maken die in de verschillende capabilities voorziet.
Daarom is er niet alleen een beweging, zoals Red Hat doet om open source tooling en frameworks te bundelen, maar om het integratie platform makkelijker samen te stellen en hier eenvoudiger integraties op te kunnen maken.
De showroom van dit concept is de cloud. In plaats dat je met verkopers en consultants gaat spreken of zelf in elkaar zet, kan je in de cloud verschillende trials van integratie functies uitproberen. Zo kan je verschillende brokers met elkaar vergelijken en uitproberen welke bij je past. Het idee is ook dat je precies betaalt zoveel als je nodig hebt (Pay by use).
De verschillende integratie capabilities worden dus niet als één suite gekocht, 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 die sterk lijkt op die van IKEA!
Een voorbeeld integratieplatform á la IKEA:
De broker en iPaas staan gewoonlijk alleen in de cloud, terwijl de gateways ook On Premisse kunnen staan.
Helaas moet gezegd worden dat Cloud vrijwel een net zo’n groot labyrinth vormt als IKEA zelf. De route en welke kosten erbij komen zijn serieuze valkuilen. Net als bij IKEA is het gevaar dat je met veel meer en heel andere dingen de showroom uitloopt als je oorspronkelijk van plan was. Daarnaast gaat het hybride platform niet alleen over de cloud, maar juist ook om cloud en on premisse met elkaar te verbinden.
Een extra laag
Ten slotte is er ook nog de ontwikkeling ontstaan dat ontwikkelaar en andere IT’ers met deze tools zelf integraties kunnen bouwen. AmazonMQ, wat gebaseerd is op de open source broker ActiveMQ, biedt niet alleen het voordeel dat het 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 vermarkt als iPaas, integration Platform as a service. Voorbeelden van iPaas producten zijn Dell Boomi, Red Hat Fuse Online (Syndesis) en Dovetail. Laatste twee zijn gebaseerd op Apache Camel, Apache ActiveMQ en andere open source technologiën.
Deze zogenoemde iPaas (integration Platform as a Service) 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 cloud diensten geldt dat ze gebaseerd zijn op open source frameworks en tools.
Doordat integraties in deze low-code tools in de browser ontwikkeld worden, is de developer flow ook anders. En omdat deze eenvoudiger te integreren zijn, wordt ook wel niet meer gesproken over system integrators, maar over citizen integrators. Overeenkomstig met citizens developers bij low-code platforms.
De oude en de nieuwe developer workflow:
Boven is de oude workflow om integraties te ontwikkelen. De developer installeerde 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 werden deze gepushed naar een version control system (bijv. Subversion of 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 deployen deze met één druk op de knop. Op de achtergrond is vaak nog een soortgelijke flow als de traditionele aan het werk, maar deze is geabstraheert van de ontwikkelaars.
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 integratie platform combineert deze lagen zodat alle capabilities beschikbaar en eenvoudig benaderbaar zijn. Samengevat vormen open source, cloud en low-code een nieuwe manier voor organisaties om een integratie platform te bouwen.
Raymond Meester
Integration Consultant & DevOps
