Steeds meer klantcontactafdelingen stappen over naar de cloud. Wie zich oriënteert op vervangingsalternatieven voor een bestaande on premise oplossing, stuit niet alleen op nieuwe contactcenterapplicaties, maar ook op een nieuw gedachtegoed, nieuwe ontwikkelmethoden en nieuwe werkwijzen. Cloudnative applicaties nemen hierbij een belangrijke rol in.Â
TechUpdate is de rubriek op Ziptone over opkomende technologie, relevant voor klantcontact. In kort bestek leggen we uit wat het is, hoe het werkt, waarom het relevant is, wat de valkuilen zijn en vragen we de mening van de lezer: Hot or Not?
Wat is het
Cloud-native is de benaming voor de aanpak waarbij applicaties specifiek worden ontwikkeld op basis van cloudtechnologie en voor gebruik in een cloudomgeving. Het is in veel opzichten de tegenhanger van traditionele software, die als statisch geheel op basis van een licentieovereenkomst op een server in je eigen computerruimte wordt gezet en daarna via een intern netwerk beschikbaar wordt gesteld voor eindgebruikers. Cloudnative applicaties (complete toepassingen, maar ook mobiele apps of API’s) worden ontwikkeld in de cloud en zijn bedoeld voor gebruik in de cloud. Met cloud wordt hier bedoeld de publieke cloud, dus bijvoorbeeld AWS of Microsoft Azure.
Hoe werkt het
Een cloudnative applicatie wordt meestal ontwikkeld binnen een cloudgebaseerd ontwikkelplatform. Daarbij worden andere programmeertalen gebruikt dan bij traditionele on premise software – denk aan zoals HTML, CSS, Java, JavaScript, .Net, PHP en Python. Ontwikkelaars van cloudnative software maken gebruik van moderne technologieën zoals API’s, containers, microservices en kubernetes. Deze technologieën zijn modulair van karakter: ze werken met bouwblokken die op verschillende plekken in de cloud aanwezig kunnen zijn.
Cloudnative ontwikkelaars werken veelal volgens moderne werkwijzen zoals DevOps (bij de ontwikkeling werken ontwikkelaars en beheerders nauw samen), Agile en Continuous Integration en Continuous Deployment (CI/CD), waardoor teams flexibel kunnen inspelen op veranderingen.
Daarnaast draaien de cloudnative onderdelen en apps op hardware die losstaat van de omvang van het gebruik van de applicatie. Wanneer een organisatie het gebruik van een cloudnative applicatie wil opschalen, heeft dat geen gevolgen voor de onderliggende hardware waar de applicatie draait. Sterker nog, op- en afschalen (door middel van extra rekenkracht of opslagcapaciteit in te zetten) verloopt vaak geautomatiseerd. Bij een on premise applicatie zal een beheerder zelf extra hardware moeten bijplaatsen. Door hun opzet zijn cloudnative apps bovendien altijd up-to-date en beschikbaar en zijn zaken als security steeds vaker ingebouwd (SecOps).
Waarom is het relevant
1. (Snel) veranderende omgevingen zoals contactcenters hebben baat bij snelle ontwikkelmethoden. Customer service draagt bij aan het onderscheidend vermogen van organisaties. Nieuwe technologie moet snel kunnen worden gebouwd en geïmplementeerd en voor iedereen (klanten en medewerkers) beschikbaar zijn. Denk aan nieuwe functionaliteit zoals betaalplatformen, employee engagement oplossingen, nieuwe contactkanalen of toepassingen op het gebied van analytics. Ook zijn cloudnative apps door hun ontwerp en bouwwijze gemakkelijk aan te passen, te koppelen en te integreren.
2. Tijdens de coronapandemie hebben contactcenters versneld moeten overstappen op werken vanuit huis. Dat betekent dat applicaties locatie-onafhankelijk moeten kunnen werken. Cloudgebaseerde applicaties zijn hiervoor geschikt ‘by design’. Het ligt voor de hand dat rondom kernapplicaties zoals het contactcenterplatform en de CRM-suite andere toepassingen dan ook cloudnative moeten zijn.
3. Snel kunnen op- en afschalen wordt voor veel bedrijven steeds belangrijker. De volatiliteit en onzekerheid in onze economie nemen toe. Cloudnative apps zijn bij uitstek ontworpen om flexibel te kunnen inspelen op sterk wisselende workloads. Bovendien worden er eigenlijk geen on premise applicaties meer gebouwd en verkocht. De bestaande on premise applicaties – denk aan traditionele grote contactcenterplatformen – hebben vaak al een cloudvariant en zullen geleidelijk worden uitgefaseerd.
Even opletten
1. Soms wordt gedacht dat het migreren van on premise applicaties naar de cloud voldoende is om te komen tot een ‘cloudgebaseerd’ applicatielandschap. Zoals gezegd zijn de talen en architectuur van beide soorten applicaties verschillend; er bestaat dus niet zoiets als zo maar verplaatsen. Voor contactcenterplatformen geldt regelmatig dat niet de migratie naar de cloud, maar de integratie daarna met andere toepassingen (CRM, WFM, QM) de meeste tijd kost.
2. Wie wil beginnen met cloud-native softwareontwikkeling, moet beseffen dat hier meerdere veranderingen voor nodig zijn. Zo moet er een ontwikkelplatform worden gekozen, ga je idealiter aan de slag met nieuwe ontwikkelmethoden en zijn er meestal nieuwe ontwikkelcompetenties nodig. Bekend verschijnsel hierbij is dat een cloudnative ontwikkelteam veel harder gaat dan de rest van de organisatie, waardoor er aansluitingsproblemen ontstaan en soms het ontwikkelteam moet wachten op de organisatie voordat nieuwe functionaliteit kan worden getest en/of uitgerold. Ook moet er op een andere manier naar security gekeken worden; bestaande beveiligingstools bieden niet voldoende veiligheid en de risico’s nemen toe.
3. Veelgemaakte denkfout is dat ‘de cloud’ beter, sneller en vooral goedkoper is. Wanneer ontwikkelteams aan de slag gaan met cloudnative projecten, zijn de kosten anders gestructureerd en niet per definitie lager dan bij de ontwikkeling van on premise software. In tegendeel, doordat teams (op niet altijd voorspelbare wijze) gebruik maken van allerlei clouddiensten bij hun ontwikkelwerk, kunnen de kosten gemakkelijk uit de hand lopen.