Gaining Speed Yet Losing Altitude - S1:A1

S1:A1 - Snelheid vs Kwaliteit

Voor veel bedrijven is het cruciaal om continu nieuwe releases live te zetten. Dat vraagt om supersnel software ontwikkelen, die per direct de klantvraag adresseert. Low-code platformen maken dit voor steeds meer organisaties en toepassingen werkelijkheid. Maar, de snelheid van low-code ontwikkeling vraagt, nóg meer dan ‘vroeger’, wel om adequate QA- en testoplossingen. Hoe sneller je figuurlijke low-code vliegtuig vliegt, hoe belangrijker het is de juiste maatregelen te nemen om geen hoogte te verliezen.

In de serie Gaining Speed Yet Losing Altitude bespreken we steeds een low-code kwaliteitsuitdaging en de maatregelen die je kunt nemen.

Zo haal je het maximale uit je low-code platform

De wereld om ons heen digitaliseert razendsnel. Dat merkt vrijwel iedere organisatie. Het belangrijkste gevolg van die digitalisering is de snelheid van verandering. En dat is precies waar veel organisaties mee worstelen. Vooral organisaties die sterk afhankelijk zijn van (maatwerk) software om hun bedrijf draaiende te houden. En wie is dat tegenwoordig niet?

De uitdaging

Eén van de belangrijkste uitdagingen waarmee deze organisaties (en vooral hun ontwikkelteams) worden geconfronteerd, is de snelheid van verandering. Die is zó hoog en de functionele en technische requirements veranderen zó snel dat het bijna onmogelijk is om bij te blijven. Iedereen die ooit deel uitmaakte van een agile en/of DevOps ontwikkelteam weet dat dit een enorme uitdaging oplevert. Ontwikkelteams met tekort aan snelheid kunnen niet langer voldoen aan de behoeften van de business, het vertrouwen in nieuwe digitale oplossingen neemt af en de business kan de efficiëntie en effectiviteit van concurrenten niet meer bijbenen.

Gelukkig heeft elk digitaal probleem ook een digitale oplossing. En die oplossing ligt al enkele jaren in het toenemende gebruik van low-code platforms. Low-code platforms zoals Mendix en OutSystems beloven én realiseren een 7 to 10 keer hogere software ontwikkelsnelheid. Dat klinkt mooi. Met low-code gaat je ontwikkelsnelheid omhoog, kun je de behoeften van de business sneller leveren en is het ontwikkelteam weer op het goede spoor. Iedereen blij, of toch niet?

Helaas gaat snelheid in low-code vaak gepaard met verminderde kwaliteit en/of verhoogde risico's. Het resultaat: software met bugs, moeilijk te onderhouden (snel technical debt) en soms zelf onveilig of niet compliant. Met andere woorden, we hebben snelheid én kwaliteit nodig. Je hebt vast wel eens gehoord van de uitspraak: ‘als je de controle hebt, rijd je te langzaam’. Prima voor bepaalde bedrijfsprocessen of formule 1, maar niet aan te raden voor softwareontwikkeling van kritische bedrijfsprocessen.

Als je bijvoorbeeld heel snel software kunt bouwen, dreigt ook het ontstaan ​​van wat we de ‘applicatiejungle’ noemen. Vooral voor organisaties die low-code gebruiken is dit een serieus risico. Dat komt omdat deze platforms uitgaan van het principe dat de business en development als één geheel samenwerken. Bij deze manier van werken stelt de business requirements op en begint development direct met implementeren. In sommige gevallen bouwt de business zelf hun applicaties, ook wel ‘citizen development’ genoemd.

Hoewel deze manier van werken voordelen heeft, vormt het ook een serieus risico. Als low-code ontwikkeling en de kwaliteit ervan niet goed gemanaged wordt zit je, voor je er erg in hebt, met een hele reeks middelmatige applicaties. Bovendien gaat de logica in je applicatielandschap verloren en verlies je feitelijk de controle over de integrale kwaliteit van je applicaties.

De oplossing

Hoe kun je snelheid en kwaliteit hebben en daarmee optimaal gebruik maken van je low-code platform? Ken je het gezegde 'Alle goede dingen bestaan in drieën'?

De eerste stap is kwaliteitsbewustzijn. Zowel de business als de ontwikkelaars moet je er bewust van maken dat het bouwen van software van hoge kwaliteit loont. Dit betekent namelijk dat:

• je software minder bugs bevat waardoor de gebruikers tevreden zijn
• je software eenvoudiger te onderhouden en aan te passen is. Hierdoor kun je nieuwe requirements nog sneller implementeren
• je software veiliger is, en daar wordt iedereen blij van

Met andere woorden: kwaliteit moet onderdeel worden van je software requirements.

De tweede stap is kwaliteitsinvestering. Ook al is iedereen het eens over het belang van kwaliteit, het blijkt vaak een uitdaging om daadwerkelijk tijd, geld en andere middelen te besteden aan het waarborgen van de kwaliteit van je software. Daarom moet kwaliteit een vast onderdeel worden van je ontwikkelcyclus. Dit betekent dat teamleden tijdens de sprints tijd moeten krijgen voor QA en testen. Dat ze de tools moet hebben om objectief inzicht te krijgen in de kwaliteit van de software die wordt ontwikkeld. Als teams die ruimte niet krijgen in een sprint, omdat ze zich moeten concentreren op het creëren van (nieuwe) functionaliteit, dan slaat de balans door naar ‘snelheid’ en gaat deze ten koste van ‘kwaliteit’. En als dat gebeurt, ben je terug bij af.

De derde stap is kwaliteitsautomatisering. Eén van de QA-maatregelen die teams nemen, is het uitvoeren van handmatige code reviews en testen. Op zich een goede zaak, want er wordt aandacht besteed aan kwaliteit. Het heeft echter ook een paar nadelen:

• Allereerst zijn deze handmatige beoordelingen vaak erg tijdrovend en worden ze vaak uitgevoerd door senior teamleden. Deze teamleden zijn eigenlijk te duur om hun tijd aan hier aan te besteden. Hun expertise kan vaak beter worden gebruikt voor complexere uitdagingen op het gebied van softwareontwikkeling en architectuur.
• Ten tweede is het aantal uren in een dag beperkt. Zelfs de meest ervaren expert kan in een review slechts een fractie van de totale applicatie bekijken. Met andere woorden, hij of zij kan zich alleen concentreren op elementen die van cruciaal belang zijn, waardoor veel potentiële risico’s buiten beeld blijven.
• Hetzelfde geldt voor testen. Testen is een cruciaal onderdeel van je kwaliteitscontrole. Doe je dit volledig handmatig, dan kost het veel tijd en geld. Controleer je (delen van) de software niet, dan voldoet deze mogelijk niet aan de functionele vereisten en moet deze steeds opnieuw worden gewijzigd door je ontwikkelteam. Hierdoor verdwijnt het snelheidsvoordeel dat low-code platforms bieden volledig.

Gelukkig kun je code reviews en testen ook automatiseren met gespecialiseerde tooling. Ontwikkelteams de juiste tools geven waarmee ze kwaliteit kunnen testen, bewaken en borgen zonder hun eigen leven moeilijker te maken.

Hoe Omnext helpt het maximale uit low-code te halen

Een van de tools waarmee organisaties hun ontwikkelteams kunnen uitrusten, is het Omnext Fit Test-platform van Valori. Dit platform is 10 jaar geleden door Omnext ontwikkeld en in de afgelopen 5 jaar geoptimaliseerd voor low-code. Het stelt teams in staat om volledig geautomatiseerde software-analyses uit te voeren op hun low-code applicaties.

Tijdens de geautomatiseerde analyse controleert het platform low-code applicaties tegen platform specifieke (bijvoorbeeld Mendix of OutSystems) best practices en de ISO-25010 richtlijn voor software kwaliteit zoals Onderhoudbaarheid, Betrouwbaarheid, Prestaties en Beveiliging.

Het platform heeft een dashboard met risico-indicatoren die een algemene status van de kwaliteit van de applicatie geven. Daarnaast ze je precies waar de risico’s zich binnen de applicatie bevinden. Met het Omnext Fit Test kunnen managers en teamleiders gemakkelijk de kwaliteit van hun applicaties volgen en het biedt ook praktische hulp voor ontwikkelaars om potentiële risico's en technical debt aan te pakken.

Wil je meer weten? Neem contact op met Omnext via contact@omnext.com

Bezoek www.omnext.com voor meer informatie

Omnext is een Valori solution

Over de auteur

Bryan de Vries is Chief Commercial Officer bij Omnext. Hij is verantwoordelijk voor business en product development en partnerships. Bryan heeft een sterke focus op de low-code oplossingen van Omnext en adviseert organisaties over software kwaliteitsvraagstukken.