Onder de noemer ‘low-code’ hoeft er tegenwoordig een steeds kleiner deel van de software echt geprogrammeerd te worden. Dat varieert van api’s om verschillende (cloud)softwarecomponenten te ontsluiten, frameworks waar alleen nog businesslogica nodig is als input, tot platforms zoals Mendix, OutSystems en ThinkWise waarmee functionaliteit als Lego in elkaar is te zetten. Al deze vormen van low code zorgen ervoor dat nieuwe software steeds sneller is te produceren. Voor de bedrijfskundige rekenaars is low-code een interessante ontwikkeling, want het zou kunnen betekenen dat de prijs van softwareontwikkeling fors omlaag kan en de rekenmodellen er flink anders uit komen te zien.
Hard dalen
Vooralsnog zien we de prijs nog niet zo hard dalen als je zou verwachten op basis van de productiviteitsverbetering die de verschillende low-codeoplossingen beloven. Kennelijk is alleen minder code kloppen nog geen garantie voor lagere prijzen. Die had Versteeg overigens niet beloofd. Om dat waar te maken, moet de low-code worden aangevuld met oplossingen om ook het ontwerpen en testen van nieuwe software efficiënter te maken. Dat blijkt één van de grote uitdagingen voor de komende jaren.
Een nog veel groter issue is om de verhouding tussen de kosten voor run & change in het applicatiedomein de juiste kant op te krijgen. Deze blijven al sinds de woorden van Versteeg in de buurt van de 80:20 hangen. Als we die verhouding naar 20:80 krijgen, wordt software pas echt serieus goedkoper. Wij blijven de score bijhouden. Wie verzint de list om dat voor elkaar te krijgen?
Door: Frank Vogelezang, senior benchmarking consultant it bij Metri It Benchmarking
(Deze bijdrage is afkomstig uit Computable Magazine, editie 01/2018.)
Reacties
Hi Frank, leuk artikel. Mis alleen Betty Blocks in je opsomming. Belangrijk onderdeel van Low-code is ook de opkomst van de Citizen Developer, méér mensen die software kunnen bouwen! Dat zien mensen soms nu ook niet gebeuren, benieuwd hoe we hier over 9 jaar naar kijken ;)
Low-code blijkt in de praktijk toch erg tegen te vallen. Zodra maar een klein beetje van de standaard templates moet worden afgeweken, moet men meteen diep in de javascript en/of css code duiken. Niet echt aan te raden voor niet programmeurs en bovendien niet zo positief voor de productiviteit en onderhoudbaarheid. Daarnaast verwacht ik dat het beheer van grotere applicaties door meerdere teams ook nog een grote uitdaging zal blijken te zijn.
De markt is inderdaad flink aan het groeien Frank: Wij maken met QNH groeicijfers op dit gebied met Betty Blocks van vele honderden procenten per jaar, en die lijn zet zich voort! Het ontwerpen, testen en beheren van Betty Blocks-applicaties heeft een nieuwe dimensie gekregen. De business analist kan direct zelf aan de slag: van userstory naar ready-to-test is het soms letterlijk een paar uur werk, meestal met de business op een stoel naast de bouwer. Zowel het ontwerpen als het testen, zeker in de no-code variant van Betty Blocks, is dan extreem functioneel gericht: heldere requirements bepalen en goede userstories opstellen is nu het leeuwendeel van het werk, en ja, ook nog steeds onderschat, daar zit nu de ruimte voor efficiëntieverbetering. Scrumteams zonder developers, wie had dat gedacht: van C# naar no-#. Het (technisch) beheer van het platform Betty Blocks is daarbij nihil, puur gericht op functionele wijzigingen en bestaat in de praktijk gewoon uit verdere uitbreiding van het gebruik van Betty in de organisatie. Voor de rekenaars van Total Cost of Ownership een openbaring...!
Leuk artikel, waarmee je de spijker op zijn kop slaat. Het feit dat je met weinig code software kunt maken zegt op zichzelf nog vrij weinig over de totale tijd die in een project gaat zitten. Zoals John ook al aangeeft, wordt er in de praktijk veel extra code geschreven binnen de low-code platformen. Die code is lastiger te testen en te onderhouden en kost daarmee ook veel tijd en dus geld.
Uiteindelijk is het voor testen de vraag of het niet mogelijk is om het te elimineren, in elk geval het technische deel. Een no-code platform kan dit voor elkaar krijgen, omdat de oplossingsruimte bekend is. Er kan dan gegarandeerd worden dat wat je met het platform maakt, altijd werkt.
Zodra dat het geval is, kunnen er heel wat uren minder worden besteed binnen een project. Daarnaast is natuulijk nog de vraag waarom de business nog op een stoel naast een bouwer moet zitten, zoals Chris schrijft. Als het platform eenvoudig genoeg is, kan de business het zelf. Dan kunnen programmeurs, waar toch al een enorm tekort aan is, zich met andere applicaties bezig houden. Op die manier winnen pas echt aan productiviteit.