Software die eindgebruikers goed ondersteunt is voor veel organisaties belangrijk om succesvol te zijn. Dit goed voor elkaar krijgen is een doorlopende uitdaging. Immers, de wensen van de eindgebruikers wisselen continu en er komen telkens nieuwe technieken bij waarmee software slimmer en beter kan worden gemaakt.
Voordat je het weet is het softwarepakket dat je hebt aangeschaft en aangepast aan jouw processen suboptimaal en blijkt dat een kleine aanpassing onevenredig veel tijd en geld kost. Dit geldt natuurlijk niet alleen voor pakketten, maar ook voor veel maatwerksoftware waarin onvoldoende is nagedacht over uitbreidbaarheid en aanpasbaarheid. Of misschien is er wel over nagedacht, maar zijn de benodigde wijzigingen zo groot dat het niet meer rendabel is om het aan te passen. Dit is het moment om de oude software te bestempelen als legacy en na te gaan denken over nieuwbouw.
Voorkom nieuwe legacy
Immers, je wilt toch niet tegen worden gehouden in de ontwikkeling van de organisatie doordat software dit bemoeilijkt? Dit zou het uitgangspunt moeten zijn. Echter moet een nieuw project niet na een jaar of twee ook als legacy software worden bestempeld. Dat is te kostbaar. Dus hoe dat te voorkomen?
Het volstaat niet om simpelweg een nieuw systeem te bouwen, met nieuwe technologie die beter aansluit op de bestaande processen. Het is nodig om zowel de organisatie als de software zo te maken dat deze kan evolueren naarmate te behoefte van eindgebruikers wijzigt. DevOps, continuous delivery, minimal viable product, design for change, fail fast, cloud en microservices architectuur. Dat zijn de termen die hierbij horen.
Ervaring van de eindgebruiker
Organisaties moeten zich natuurlijk wel afvragen of ze de investering om zelf nieuwe software te maken volgens bovenstaande principe kunnen en willen maken. Cultureel en financieel. Om dit te bepalen helpt het om te weten waar het competitieve voordeel van de organisatie zich bevindt. Waardoor probeert deze zich te onderscheiden en wat bepaalt dan de ervaring van de eindgebruiker.
Specifiek hiervoor is het logisch om de benodigde investering te doen en te gaan voor state-of-the-art maatwerk. Het is niet voor niks dat de website van uw bank voor internetbankieren er modern uitziet en continu wordt vernieuwd. Tegelijkertijd zijn de systemen die de betalingen verwerken vaak gebaseerd op stokoude technologie.
Mijn vuistregel is dat zolang de gebruiker optimaal bediend kan worden legacy misschien niet zo erg is. Dit ontslaat de afdeling ict natuurlijk niet van de plicht om in te schatten of onderhoudskosten, security risico’s en beschikbare kennis onder controle kunnen worden gehouden op de middellange termijn. Dit vereist inzicht in gespendeerde uren, aanwezige kennis in de markt of in de organisatie, zicht op hoe lang de software in de huidige staat nog bruikbaar is en welke alternatieven er zijn.
Economisch denken
Het kan bijvoorbeeld blijken dat de onderhoudskosten hoog zijn van een systeem, maar de eindgebruikers niet worden geraakt. Wellicht is een pakket, modelgedreven software of een SaaS-oplossing dan interessant. Dit type oplossing biedt vaak allerlei opties om business logica snel in te modelleren en te integreren met allerlei bestaande systemen. Zorg er dan wel voor dat voldoende bekend is wat de te vervangen legacy software precies doet. Op een later tijdstip erachter komen dat het uitschakelen niet gaat omdat bepaalde afhankelijkheden niet in de nieuwe oplossing ondergebracht kunnen worden is niet erg positief voor de beoogde kostenreductie.
Bedenk goed hoe dit risico te beperken. Dit kan door bijvoorbeeld het risico te delen met de leverancier, eerst de moeilijkste onderdelen in een proefomgeving te migreren en ervaringen van andere organisaties die vergelijkbare trajecten hebben uitgevoerd op te vragen.
Wanneer legacy te vervangen
Het blijft uiteindelijk een lastig besluit. Legacy software moet niet als belemmering werken in de bediening van de eindgebruiker en het vervangen van een systeem moet niet een nieuwe kostenpost opleveren doordat het uitzetten van de te vervangen omgeving complex blijkt. Cruciaal is dat er een duidelijke keuze wordt gemaakt.
Als een (deel van de) organisatie voor duurzaam vernieuwen gaat met maatwerk software, pas daar dan de cultuur en werkwijze zo aan dat continue verandering wordt omarmt. Dan voorkom je nieuwe legacy het beste. Vervang je software uit het perspectief van kostenreductie, zorg dan dat de business case echt goed is doorgerekend en oude systemen na oplevering echt uit kunnen.
“Legacy is de software die je vandaag ontwikkelt” aldus Paul Klint in 2012.
Er zijn heel veel factoren die maken dat je in een situatie terecht komt dat je technische of functionele schuld ineens zo groot is dat je niet zomaar even alles vernieuwt of vervangt. Dat kan technisch van aard zijn, b.v. geen ondersteuning meer van een platform of functioneel, b.v. wetgeving die drastisch op de schop gaat.
Probeer je software zo up-to-date mogelijk te houden, dan kun je deze disruptieve veranderingen met de minste kosten de baas. Maar het blijft een moeilijke en kostbare uitdaging is mijn ervaring.
Op het moment dat je nieuwe software gaat gebruiken weet je al dat deze niet tot het einde der tijden ondersteund en dus onderhouden blijft worden. Dus is het belangrijk om de ontwikkelingen goed bij te houden en te zorgen dat er op het meest gunstige moment kunt veranderen.
Wat de software ontwikkeling betreft is het helemaal hip om je software zo te ontwerpen dat deze moeiteloos bij te werken naar de laatste versie waarbij alles automatisch gaat.
Kijk maar naar de smartphone/tablet of gaming industrie waar wekelijkse zo niet dagelijkse micro patches voorbij komen.
Leen Blom schreef: “Er zijn heel veel factoren die maken dat je in een situatie terecht komt dat je technische of functionele schuld ineens zo groot is dat je niet zomaar even alles vernieuwt of vervangt.”
Het probleem is misschien wel dat we de implementatie van bedrijfsprocessen vaak bouwen op technische frameworks (zoals nu Spring en Akka heel actueel zijn). Wordt het gekozen framework obsolete (zoals bijv. met Seam gebeurt is) dan zitten we met de handen in het haar als het gaat om de implementatie van die bedrijfsprocessen.
Zou het niet zo moeten zijn dat we bedrijfsprocessen en frameworks veel meer los van elkaar moeten houden, zodat we ze onafhandelijk van elkaar kunnen vervangen als een van beide aan revisie toe is? Dan hoeven we de programmatuur met al die verstopte business rules niet te vervangen, bijv. als we besluiten de cloud in te gaan.