Moge de beste technologie winnen!

Voor het eigenlijke gevecht van start gaat, kan het uiteraard geen kwaad nog eens te definiëren waarover beide experts precies de degens kruisen.

Microservices: ruimte voor experiment

Peter De Kinder: “Met een technologie als microservices kun je een businessprobleem aanpakken door businessprocessen op te delen in geïsoleerde domeinen die elk een deel van zo’n businessproces afdekken. Daarbij kunnen microservices binnen dat domein volledig autonoom functioneren en onafhankelijk van alle andere domeinen evolueren. Daardoor kun je een microservice snel wijzigen en aanpassen. Je kunt microservices ook heel makkelijk combineren, tot je de meest optimale structuur voor je oplossing hebt gevonden. Zo kun je eigenlijk bijna van een trial-and-error-methode spreken.”
 
“Daarin schuilt voor mij ook de toegevoegde waarde van microservices: het is de vervulling van een belofte die het SOA-architectuurmodel (Service Oriented Architecture) ons aan het begin van deze eeuw al bracht. Te weten: dat je IT-systemen met elkaar kunt laten communiceren, totaal onafhankelijk van de technologische keuzes die je maakt – of hebt gemaakt. Microservices zijn ‘agile’ en heel snel in productie te zetten. Zo reduceren ze de time-to-market om nieuwe toepassingen in te voeren. Dankzij microservices kun je als organisatie kort op de bal spelen, op elk niveau.”

Robotic Process Automation: operationele efficiëntie

Tom De Maeyer: “Bij RPA kun je met software activiteiten en processen die zich in verschillende applicaties afspelen, laten nabootsen door een zogenoemde digital worker of virtual agent, de robot uit de naam dus. En wel op exact dezelfde manier als menselijke medewerkers dat doen. Die robots integreren meestal met de presentatielaag van de architectuur – concreet: met de schermen van de applicaties – al kunnen ze ook met de andere architectuurlagen spreken. Dat maakt dat er geen aanpassingen aan de onderliggende systemen nodig zijn, waardoor je heel snel kunt schakelen.”
 
“Wat mij in eerste instantie in RPA aantrok, was de vaststelling dat zelfs de succesvolste projecten voor procesautomatisering vaak een wrange nasmaak achterlieten. Telkens weer stelde zich de vraag: waarom moet dat allemaal zo lang duren? En waarom moet dat de organisatie zoveel geld kosten? Bij RPA vielen die vragen voor het eerst weg en noteerde ik een groot, meetbaar succes, vooral in zeer complexe IT-omgevingen die over vele jaren waren opgebouwd. Soms hadden die ook al een aantal fusies ondergaan, wat een kluwen opleverde dat heel moeilijk aanpasbaar was of alleszins veel geld kostte. In zulke gevallen biedt RPA een aantrekkelijke, laagdrempelige toegang om het menselijke potentieel te ontsluiten dat wordt verspild aan inefficiënte processen die steunen op archaïsche systemen. Door die eerdere succeservaringen ben ik ervan overtuigd geraakt dat weinig bedrijven het zich vandaag nog kunnen permitteren om RPA als technologie links te laten liggen. En dat het wel degelijk een middel is om heel snel toegevoegde waarde voor je organisatie te creëren. Kortom, RPA is misschien niet altijd hét antwoord op de puzzel, maar is naar mijn mening wel altijd een element in de puzzel.”

Eerste ronde: heeft de technologie voldoende maturiteit?

P. De Kinder: “Wat is oud? In de IT-sector kun je vijf jaar als een eeuwigheid bestempelen. Als ik me niet vergis, zijn microservices officieel in het leven geroepen in 2011. Maar de term – of een vergelijkbare term – dateert zeker al van 2005. Het microservice-concept vloeit immers voort uit een meer pragmatische benadering van de klassieke SOA-aanpak. Daaruit hebben we heel wat lessen kunnen trekken, met name over hoe het niet moet. En die lessen hebben we vervolgens meegenomen in de ontwikkeling van microservices. Als in een perfecte storm zijn verschillende disciplines en ontwikkelingen in het IT-landschap – ik denk maar aan het werken met events, domain-driven design en het opkomen van cloudmogelijkheden – op een gegeven moment samengevloeid in dat nieuwe concept. Dat was een natuurlijke evolutie. Microservices zijn zo op heel korte tijd erg matuur geworden. Vandaag staan ze voor een manier van werken die voor heel wat businessproblemen een oplossing kan bieden.”
 
T. De Maeyer: “RPA lijkt misschien een vrij nieuw gegeven, maar dat komt omdat robotica pas de laatste jaren, sinds pakweg 2014, zo’n hoge vlucht heeft genomen. In feite bestaat RPA al sinds het begin van deze eeuw. In die periode zijn ook de grote spelers op de markt gekomen. Het is wel een markt die nog sterk in beweging is en aan een zekere consolidatie toe is. Vandaag zijn er nog heel veel partijen in het speelveld. Dat neemt niet weg dat de meeste producten intussen wel al matuur zijn. Waarmee ik bedoel: met de beveiliging en de schaalbaarheid zit het goed, ook de auditeerbaarheid en traceerbaarheid zijn onder controle en er bestaan voldoende integratiemogelijkheden met andere pakketten of andere onderdelen van de architectuur. Bovendien is niet alleen de technologie zelf matuur, maar zijn ook de kennis en expertise in de markt sterk toegenomen. Er zijn momenteel al heel wat grote RPA-implementaties die aanzienlijk succes hebben opgeleverd.”

Tweede ronde: biedt de technologie voldoende toepassingsmogelijkheden?

T. De Maeyer: “RPA is in alle departementen en industrieën toepasbaar. Wel is het zo dat je RPA het best inzet bij de meest gestandaardiseerde processen die de grootste volumes te verwerken hebben en vrij repetitief zijn. RPA wordt ook heel vaak ingezet op cyclische activiteiten waarvoor je typisch een beroep doet op tijdelijke werkkrachten. In veel organisaties is dat een ‘sweet spot’ voor RPA-potentieel. Het is nu eenmaal zo dat robots dynamisch kunnen inspelen op een wisselende werkbelasting of wisselende volumes. Verder zijn de selectiecriteria voor RPA helemaal niet complex. Zodra een proces volledig te beschrijven is aan de hand van ondubbelzinnige beslissingsregels, kan een robot die taken in principe overnemen. En als je daar in een organisatie naar begint te zoeken, vind je eigenlijk overal wel potentieel. Het is soms ronduit schrijnend om vast te stellen welke archaïsche processen er nog met verouderde tools worden uitgevoerd.”
 
P. De Kinder: “Toegegeven, een project met microservices is iets complexer dan een doorsnee RPA-implementatie. Maar dat is een ‘trade-off’ of een compromis dat je maakt om aan flexibiliteit en wendbaarheid te winnen en uiteindelijk ook met een robuustere oplossing te eindigen. Daarbij kun je met microservices dezelfde graad van automatisatie bereiken als met RPA. Alleen gebeurt dat vanuit een andere insteek: terwijl RPA een proces beschouwt als een opeenvolging van verschillende activiteiten, die je stap na stap moet realiseren, maken microservices abstractie van dat proces en bekijken ze het eerder als een reeks van business events die plaatsvinden, zoals een bestelling, betaling of levering. En die op hun beurt ook weer zogenoemde componenten gaan ‘triggeren’. Zo kan de registratie van een nieuwe klant of prospect bijvoorbeeld een marketingactie in gang zetten.”

Derde ronde: is de technologie voldoende rendabel?

T. De Maeyer: “Elke organisatie heeft wel een idee van wat ze meer zou moeten doen dan wat ze vandaag al doet. En ik denk dat RPA daar heel wat middelen voor kan helpen vrijmaken. Met RPA kun je in de gemiddelde backoffice-omgeving heel gemakkelijk ongeveer twintig procent werklastvermindering realiseren. Stel je eens voor dat je die extra werkkracht die zo vrijkomt, op strategische initiatieven kon inzetten: op het bedenken van nieuwe producten, bijvoorbeeld, of op de ontwikkeling van nieuwe markten. Dat is een opportuniteit die je als organisatie gewoon niet kunt negeren. Bovenop de vier à vijf weken ontwikkeltijd die je bij een RPA-project moet voorzien, zijn ook de onderhoudskosten heel beperkt. Als je een robot helemaal opnieuw moet schrijven, ben je 20 à 25 dagen kwijt. Maar vaak is er slechts één applicatie gewijzigd en kijk je aan tegen een aanpastijd van enkele uren tot hoogstens enkele dagen. Komt daarbij dat één persoon ongeveer 30 à 35 robots kan onderhouden.”
 
P. De Kinder: “Standaardtoepassingen zoals een boekhoudpakket schrijf je beter niet met microservices. Misschien, tenzij je actief bent in de financiële sector, zal je boekhoudpakket zo goed als zeker geen differentiërende factor voor je business zijn. Microservices zijn bij uitstek geschikt voor de systemen die wel het verschil helpen maken, doordat ze toelaten om heel snel in te spelen op veranderingen in de markt of in je eigen organisatie. Door ervoor te zorgen dat je kort op de bal kunt spelen, helpen microservices je de winst te maximaliseren. De grote sterkte van microservices is dat, als ze er eenmaal staan, het heel eenvoudig is om nieuwere versies ernaast te plaatsen die speciale functies kunnen afhandelen of bepaalde services vervangen. Dat maakt het erg eenvoudig om een breed scala aan services naast elkaar te draaien. Het concept van DevOps laat ontwikkelaars bovendien toe hun eigen code ook in productie te onderhouden. Zo kunnen ze de operationele ondersteuning bieden om de services die zij zelf hebben geschreven, ook zelf te onderhouden.”

Conclusie: zijn RPA en microservices complementaire technologieën?

P. De Kinder: “Het lijkt mij dat RPA en microservices twee sterke technologieën of oplossingen voor verschillende problemen zijn. Als we het over procesautomatisering hebben, denk ik dat je je eerst de vraag moet stellen hoe sterk de processen in de toekomst nog gaan veranderen. Hebben we het over processen die vrij stabiel zijn en waarbij een snelle implementatie vereist is? Doe het dan met RPA, ze zullen veel sneller in productie zijn dan dat ooit met microservices het geval zal zijn. Zit je echter met processen die om de haverklap veranderen, in een industrie of een markt die constant in beweging is en waar je dus zeer kort op de bal moet kunnen spelen? Dan zou ik eerder voor microservices opteren, omdat zij je de wendbaarheid geven om snel in te spelen op de veranderingen die op je afkomen.”
 
T. De Maeyer: “Ik deel de mening dat microservices waarschijnlijk een goede oplossing zijn voor ‘core’ IT-systemen, waarbij wendbaarheid cruciaal is. Maar ik denk dat je ook de vraag moet stellen: hoe lang kan ik op die oplossing wachten? Hoeveel wil ik erin investeren? En hoe diepgravend of ingrijpend mag die wijziging voor mijn organisatie en mijn IT-landschap zijn? In het antwoord op die vragen zijn zeker ook heel goeie argumenten voor RPA te vinden.”