‘Wegwerp-oplossingen’ volwaardig alternatief voor ‘lange-termijn stabiele oplossingen’ ?

15 maart 2019

Soms hoor je iets, lees je iets, of maak je iets mee wat je beeldvorming bepaalt of beïnvloedt. Zo ook bij mij, voor wat betreft het ontwikkelen van ICT-oplossingen. Al merk je dat natuurlijk pas later, wijsheid komt met de jaren zullen we maar denken…

Een oud-collega schreef eens een blog over de verschillen tussen ontwikkelaars, van Cobol, C, tot en met Java en PHP aan toe. Hierbij was het duidelijk: De échte programmeurs ontwikkelen met de lange termijn in gedachten, toekomstbestendig, robuust, schaalbaar en herbruikbaar. Zoals bijvoorbeeld Java-ontwikkelaars, zij voelen zich vaak beter dan al die andere ontwikkelaars die ‘snelle en slordige (punt)oplossingen’ want zij ontwikkelen toekomstvast.

Een andere oud-collega van me, een echte Java-man van het eerste uur, had toekomstvast en herbruikbaar in zijn DNA getatoeëerd. Hij kon te vuur en te zwaard beargumenteren waarom Java de beste oplossingsrichting was en kon per OSI-lag uitleggen hoe en waarom. Maar op een dag kwam ik hem tegen en was hij helemaal om: Ruby on Rails, Python en Mendix stelden hem en zijn team in staat om zó snel oplossingen te ontwikkelen, dat Java in sommige gevallen zelfs geen optie meer was.

“Disposable” Software ?

Inmiddels hebben we tal van nieuwe, snelle ontwikkeltalen zien ontstaan. We hebben diverse low-coding platforms tot onze beschikking en een appje is razendsnel gebouwd. Echter ligt daarmee de wildgroei weer op de loer, zullen de toekomstbestendige ontwikkelaars denken. Maar toch blijft het zo dat sommige oplossingen nu eenmaal snel gebouwd of snel veranderd moeten kunnen worden, anders worden we ingehaald door nieuwe ontwikkelingen of door de concurrent.

“Disposable software” noem ik het inmiddels in mijn hoofd, wegwerpsoftware. Misschien wel heel passend in onze wegwerp-economie, en het eerste zaadje was geplant.

Geen ISDN in mijn huis

Een gek uitstapje misschien, maar ik heb privé nooit een ISDN-aansluiting genomen, want ik vond het maar een oplossing van niks. Ik was ervan overtuigd: daar gingen ze vast een véél betere oplossing voor vinden. En zo geschiedde: inmiddels delen we met z’n allen wifi, data, televisie en telefonie. Snelheid is bijna geen issue meer en bellen via WhatsApp gaat soms zelfs beter dan via de telefonielijn. ISDN is dit jaar overigens, na 30 jaar, (gelukkig) definitief verdwenen.

Ik gebruik dit voorbeeld wel eens voor RPA-oplossingen (eenvoudig gezegd: software die als een virtuele collega handelingen uitvoert, vaak in verschillende systemen). RPA is zeker een van de nieuwste hot-topics, maar “waarom met RPA tooling aan de slag gaan als je het ook gewoon goed, structureel en toekomstbestendig kunt automatiseren?” hoorde ik mezelf hardop zeggen. “RPA is net zoiets als ISDN, ook zo’n tussenoplossing”.

“Nou, omdat het zo ontzettend veel sneller, goedkoper en makkelijker is. En op korte termijn een probleem oplost, waardoor de business case zo gemaakt was”, hoorde ik mezelf antwoorden in mijn hoofd. En ik realiseerde me ineens, dat ik door mijn koppigheid over ISDN zelf ook vele jaren genoegen had genomen met een langzame internetverbinding en zelfs een tweede lijn had overwogen.

Wat heb ik nu hiervan geleerd, en wat kan ik ermee in mijn werk? Wat adviseer ik klanten nu als het gaat om ontwikkelingen als low-coding, RPA en maatwerk vs pakketten?

Duivelsdriehoek geeft overzicht

Duivelsdriehoek

Wat ik ervan geleerd heb is dat de duivelsdriehoek tijd – geld – kwaliteit ook hier weer een rol speelt. Dat maakt de keuze niet in één klap makkelijk, maar het denkproces wel overzichtelijker.

Tijd in de breedste zin van het woord beschouwend: hoe snel moet een oplossing gerealiseerd zijn? Hoeveel tijd kost het om iets te bouwen en/of te implementeren, en om te onderhouden? Hoe toekomstvast moet het zijn? En vanuit tijd in business-perspectief: wat is onze time-to-market? Hoe lang hebben we nog? Wanneer verwachten we de eerste veranderingen, etc. Kortom hoe belangrijk is tijd c.q. flexibiliteit.

Dan de afweging op basis van geld, waarbij zowel de investeringen als de ontwikkel- en exploitatiekosten meegenomen moeten worden, ofwel: wat is de te verwachten Total Cost of Ownership?

En dan kwaliteit als aspect voor afweging, waarbij het eigenlijk gaat om ‘de juiste match’: tussen verwachtingen en realiteit, tussen leverancier en klant en tussen oplossing en architectuur. Hoe is de oplossing te karakteriseren? Als System of Record? Als System of Differentiation, of zelfs als System of Innovation? Doet de oplossing wat ervan verwacht wordt? Welke functionaliteit wordt er standaard geleverd? Hoe is de match met de architectuur, met de organisatie en met de cultuur?

Follow the hype?

En dan terug naar de stelling die boven deze blog staat: Wegwerp-oplossingen volwaardig alternatief voor lange-termijn stabiele oplossingen. Zeker waar tijd en geld een belangrijke rol spelen, zou ik adviseren om de hypes serieus te overwegen. RPA en low-coding stellen beiden, al zijn ze van een hele andere orde, organisaties in staat om desgewenst snel, goedkoper en kwalitatief nog steeds goede oplossingen te bieden voor problemen die de organisaties echt dwars zitten. En ook om kansen te creëren die anders niet mogelijk zouden zijn. Misschien voor relatief korte termijn, maar wie weet hoe de wereld er over 3 of 5 jaar uitziet? Hoe toekomstbestendig kunnen we zijn als we de toekomst zo slecht kunnen voorspellen?

En zoals zo vaak geldt hier wellicht ook dat het niet een of/of keuze hoeft te zijn, maar waarschijnlijk een en/en situatie is. Dat dus wegwerp-oplossingen een mooie aanvulling zijn op toekomstbestendige oplossingen. Dat was misschien een betere stelling geweest, maar om die nu nog te gaan veranderen… 😉

Hier een keer over sparren? Neem contact met me op.

Auteur

Johan Burgemeester
Johan Burgemeester johan.burgemeester@qhuba.com - 06-22920736 - LinkedIn