De Nederlandse markt voor traditionele bedrijfssoftware stagneert. In 2019 is de groei amper drie procent en in 2020 wordt verdere stagnatie verwacht. Dat blijkt uit onderzoek naar de omzetontwikkeling van zeven softwarefabrikanten sinds 1996. Het goede nieuws is dat de markt voor low-code bedrijfssoftware juist enorm in de lift zit. Tijdens het eerste Low-code No-code Congres in Nederland mocht ik als keynote-spreker zowel hierover als over de gehele softwaremarkt vertellen.
De bedrijven die het in het onderzoek van AME Research worden besproken, zijn ADP Nederland, Afas, Exact, Unit4, SAP Nederland, Oracle Nederland en Visma|Raet. Dat de groei van deze traditionele softwarehuizen stagneert, kan ik wel verklaren. Hun innovatie wordt namelijk sterk afgeremd door de manier waarop zij hun software ontwikkelen. Dat kan tegenwoordig acht à tien keer sneller met een low-code platform.
Afkijken van andere industrieën
Met low-code zie ik veel gelijkenissen met andere high-tech industrieën, zoals de automotive en luchtvaartindustrie. Hier worden veel virtuele modellen gebruikt, bijvoorbeeld om nieuwe ontwerpen virtueel te toetsen, zodat er in de praktijk geen verassingen meer zijn. Cad-Cam is hier een goed voorbeeld van. Je maakt een digitaal ontwerp en kunt dat vervolgens uitvoerig evalueren en testen, waarna het tot een daadwerkelijk product wordt vervaardigd. Dit is in feite precies de werkwijze die we tegenwoordig met low-code hanteren, hetgeen bij traditionele softwareontwikkeling onmogelijk is.
Als gevolg van traditionele ontwikkeltechnieken is alle functionaliteit van software verankerd in soms miljoenen regels programmeercode. Die is complex en veroudert na verloop van tijd, waardoor die software periodiek opnieuw gebouwd moet worden. Zo gingen we van Dos naar Windows, het web, diverse mobiele platformen… En voor al die platformen moest software keer op keer op een zeer ambachtelijke manier herontwikkeld worden. Dit is niet alleen duur en risicovol. Het gebeurt tegenwoordig ook steeds vaker, omdat nieuwe technologieën en innovaties elkaar in deze tijden van digitale transformatie steeds sneller opvolgen. Er zijn dan ook steeds meer van deze softwareambachtslieden nodig, en die ontwikkelaars zijn er eenvoudigweg niet.
Afrekenen met de softwarepijn
Om hun ontwikkelsnelheid te verhogen, kiezen sommige bedrijven voor offshoring, waarbij je de ontwikkelcapaciteit voordeliger inkoopt in het buitenland. Je krijgt er dan echter wel een taalprobleem en culturele verschillen bij, en het ontwikkelproces blijft ambachtelijk. Eigenlijk koop je jouw probleem goedkoper in en dat is niet heel ambitieus. Een andere oplossing is het inzetten van pakketsoftware, maar ook dan blijven de processen ambachtelijk. Bovendien zijn er nauwelijks leveranciers van pakketsoftware die meer dan 20 jaar technologische ontwikkeling hebben overleefd. Verder heeft pakketsoftware als belangrijk nadeel dat je vaak voor talloze features betaalt, die je helemaal niet nodig hebt. De enige oplossing uit dit moeras van trage traditionele softwareontwikkeling is het automatiseren ervan. Dit is precies wat het doel is van modelgedreven low-code softwareontwikkeling. De functionaliteit van software wordt in visuele modellen vastgelegd en op basis daarvan komt automatisch software snel tot stand. Het ontwikkelproces gaat veel sneller doordat de wijzigingen in het model gedaan worden, en niet in complexe programmeercode.
Het enige waar je rekening mee moet houden, is dat automatiseren domein specifiek is. Je kunt immers ook geen vliegtuig bouwen in een autofabriek. Dus bedenk wel voor je gaat automatiseren; Welk low-code platform past bij mijn domein?
Low-code disruptief
De it heeft decennialang andere branches geautomatiseerd. Het bracht bedrijven absoluut verder, maar had soms wel grote gevolgen voor de werkzaamheden van medewerkers. Low-code is een stroming die ook disruptief is voor it zelf. Dat is zeker niet negatief alleen zullen experts eraan moeten wennen dat hun werk verandert en overigens vaak ook leuker wordt.
Feitelijk zouden we de wereld van ontwikkelaars moeten indelen in twee categorieën. De super schaarse technische ontwikkelaar zouden we moeten inzetten op het maken van low-code platformen en niet op het maken van een app. Dat zijn bijvoorbeeld de traditionele Java en C# programmeur.
De eindproducten worden vervolgens gemaakt door bedrijfskundige informatici of bedrijfskundigen. Die zijn minder schaars en worden bovendien tienmaal productiever. Dat geeft een enorme boost aan de capaciteit van softwarebouw. Daarnaast komt de business door low-code aan het stuur te zitten van het project. De typische ivoren IT-toren bestaat niet langer.
Positionering
Core systemen, zoals erp, zijn star en daarom bouwen bedrijven vaak oplossingen ernaast in Excel of Access om toch te krijgen wat ze nodig hebben. Het is volstrekt gangbaar dat een bedrijf met tienduizend medewerkers en een groot erp-pakket zoals SAP daarom heen maar liefst vijfhonderd tot duizend randapplicaties heeft. Meestal was dat initieel uiteraard niet de bedoeling, maar is het wel zo gegroeid in de loop der jaren. Om deze wildgroei aan apps tegen te gaan kan een low/now-code platform de oplossing zijn. Er zijn een aantal manieren waarop een organisatie low-code/no-code kan inzetten.
- No-code platformen – Daarmee kunnen bedrijven zelf eenvoudige apps maken zonder te programmeren. Dit levert vaak een haat-liefdeverhouding op met IT wat betreft de verantwoordelijkheid over deze apps met betrekking tot het beheer ervan.
- Low-code platformen – Daarmee maakt een softwareleverancier (en soms bedrijven zelf) apps op een ERP-applicatie. Deze apps kunnen wat groter en complexer zijn en hebben vaak een levensduur van enkele jaren. Ook bestaat de mogelijkheid om een System Integrator (SI) in te schakelen die op basis van jouw specificaties bedrijfssoftware ontwikkelt met een low-code ontwikkelplatform.
- Low-code voor core applicaties – Daarmee wordt een applicatie gebouwd die het traditionele core systeem daadwerkelijk vervangt. Hierbij is ook belangrijk dat deze applicatie automatisch over kan gaan naar nieuwe technologie omdat de levensduur decennialang is. Het gaat hier dus om een structurele oplossing, waarbij je vervolgens zelf een enorme flexibiliteit creëert om de software door te ontwikkelen en volledig naar je hand te zetten.
Voor de laatste optie moet je als organisatie wel een duidelijke visie voor ogen hebben wat je precies wilt. Voor de tweede optie geldt dat in mindere mate en voor de eerste optie niet tot nauwelijks. De bedrijven met zo’n duidelijke visie zijn vaak de bedrijven die het verschil in de markt willen maken en daarbij behoefte hebben aan een unieke onderscheidende applicatie.
Als je jouw core systeem wilt vervangen op basis van je eigen visie kan je dat uiteraard zelf doen. Dat kan al met een klein team van een paar personen en die hoeven niet eens programmeurs te zijn. Je kunt het ook uitbesteden aan een System Integrator.
Als je al beschikt over een pakket en dat wilt blijven gebruiken, kan het heel zinvol zijn je pakketleverancier te attenderen op low-code voor erp. Als zij namelijk tien keer sneller ontwikkelen (wat mogelijk is met low-code) heeft dat voor jou als klant direct het voordeel dat functionaliteit eerder beschikbaar komt en automatisch technologisch modern blijft.
Vraag om advies bij keuzestress
Er is nog een andere optie, en mijns inziens de slechtste: niets doen… Gewoon traditionele software blijven gebruiken en de low-code revolutie totaal negeren. Dan blijft alles bij het oude, terwijl de kosten voor het onderhouden en door ontwikkelen alleen maar stijgen. Ik zou dat zeker niet aanraden, want dan is er uiteindelijk maar één uitkomst: dat je bedrijf over een aantal jaren niet meer bestaat. Maar dat hoeft natuurlijk niet, want er zijn voldoende mogelijkheden om low-code toe te passen. De juiste keuze maken, is makkelijker dan je denkt. Zolang je jezelf maar goed laat adviseren!
Wil je meer te weten komen over mijn visie op low-code? Kijk dan eens naar dit gesprek met Digital Waves.
“De super schaarse technische ontwikkelaar zouden we moeten inzetten op het maken van low-code platformen en niet op het maken van een app. Dat zijn bijvoorbeeld de traditionele Java en C# programmeur.”
en opeens heb je de traditionele programmeur nodig. Blijkbaar kun je het platform zelf niet ontwikkelen met een lowcode systeem. Een C compiler bijv is daarentegen wel in C geschreven. Lowcode ofwel highlevel programmeren heeft nl nogal wat nadelen. Functioneel en wat performance betreft.
Goh, ik word weer helemaal teruggeworpen (in gedachten) naar de jaren 90 van de vorige eeuw.
3GL programmeertalen zijn dood! We moeten allemaal naar 4GL talen! Definieren en niet programmeren. Later werden het 5GL talen waar we naartoe moesten gaan.
Veel mensen, management voorop, probeerden daarna met standaard pakketten via standaard functie-templates een niet standaard situatie toch maar zo snel en goedkoop mogelijk in het systeem te proppen, met een niet of niet voldoende goede oplossing tot gevolg.
En omdat er X leveranciers waren van dit soort 4/5GL talen pakketten met elk hun eigen taaltje kreeg je een fijne vendor-lock-in (want natuurlijk genereer je geen code die dit zou voorkomen, maar gebruik je een eigen alleen door de leverancier te lezen blob).
Okay, dat werkt dus niet, dat is een vierkant in een cirkel proberen te prakken.
Dus in de vroege jaren 2000 kwamen de CRM pakketten om de hoek kijken, SAP, Afas, Exact, enfin de lijst is al eerder aangegeven. En dat was allemaal configureerbaar, module-based, flexibel etc., etc.) en zonder te programmeren kon je al heel snel je unieke bedrijfsprocessen modelleren. Geen noodzaak voor dure en langzame programmeurs die toch niet opleveren wat jij wilt, maar gewoon een opdracht neerleggen bij de leverancier die dankzij de grote customer-base die oplossingen snel kon produceren.
Nu komen we er kennelijk achter dat we een vierkant in een cirkel proberen te duwen en moet het allemaal anders.
Dus wat gaan we een 10tal jaar later maar doen? Laten we low-code programmeren en via definities de bedrijfsspecifieke processen en procedures. Dat is nieuw, dat is hip dat moeten we gaan doen, daar gaan we heel veel dure programmeurs niet meer voor nodig hebben (ik hoor de kudde jonge ambitieuze managers al aan stormen, met de opdrachten al in de kleine knuistjes terwijl ze al aan het onderhandelen zijn over de bonussen die ze gaan behalen met al die kostenbesparingen).
Hey, dat lijkt wel verdacht veel op de 4GL en 5GL oplossingen uit de jaren 90. Ik wacht wel weer op de standaardpakketten die gaan uitkomen om de boel weer uit handen te geven aan derden. Ondertussen verschaffen we in elk geval voldoende bezigheid voor al die verkopers en managers, gelukkig maar, je zou toch niet willen dat ze zich al te veel met echt werk gaan bemoeien, toch? (Ik lijk verdorie wel op Jacob Spoelstra).
Aan codegeneratoren (want daar hebben we het hier over) kleven zoveel nadelen dat je er niet aan zou moeten willen beginnen.
Ik vertegenwoordig weliswaar een ander platform (WEM.IO, #NoCode), maar Viktor heeft wel gelijk. #DigitaleTransformatie mbv #CitizenDevelopment wordt de eerstvolgende verandering/acceptatie om Legacy en Shadow IT gecontroleerd uit te faseren!
De nieuwe kleren van de keizer, versie 35.1
Ja, echt waar: Bij standaardsoftware moet je betalen voor alle features die je niet nodig hebt, want software is gemaakt van dure grondstoffen.
Het is daarom ook onbegrijpelijk dat er voor software nog geen recycling geregeld is.