Verouderde applicaties kunnen niet alleen een belastende kostenpost zijn, maar kunnen je organisatie ook beperken in groei en ontwikkeling en zelfs een veiligheidsrisico vormen. Om flexibel in te kunnen spelen op wat bedrijven en klanten vragen en om klaar te zijn voor de toekomst, zijn er een aantal scenario’s voor de modernisering van legacy-applicaties.
In deze scenario’s gaat het over significante aanpassingen of vervanging van verouderde software door moderne technologieën. Low-code kan hier een belangrijke bijdrage leveren.
1. Rearchitect
De software wordt deels hergebruikt maar wel verbeterd en aangevuld met nieuwe en betere onderdelen, ook wel ‘upcycle’ genoemd. De kern van de applicatie, met data en bedrijfslogica blijft ongewijzigd bestaan en wellicht gemigreerd naar moderne infrastructuur, zoals de cloud. Sommige functionaliteiten worden nieuw gebouwd en geïntegreerd met de bestaande kern. Een voorbeeld hiervan is een nieuwe verbeterde gebruikersinterface op een bestaande applicatie waarbij de gebruikersinterface met bijbehorende logica snel en effectief in low-code is te maken.
2. Rebuild
De applicatie wordt volledig opnieuw ontworpen en herschreven, maar de scope en specificaties worden grotendeels overgenomen. Daarmee wordt de applicatie met nieuwe technologie maar met vergelijkbare functionaliteit opnieuw opgebouwd.
3. Replace
Hierbij wordt de applicatie of belangrijke onderdelen ervan volledig vervangen door zoveel mogelijk, kant-en-klare ‘off the shelf’-software. In dit scenario worden gelijktijdig ook nieuwe requirements overwogen en meegenomen. Met deze kant-en-klare oplossingen is het vaak niet mogelijk om te voldoen aan alle oude en nieuwe eisen, een veel voorkomend voorbeeld hiervan is een migratie van SAP naar S/4Hana.
Moderniseren met low-code
Welke strategie je ook kiest voor het moderniseren van verouderde applicaties; weeg zorgvuldig je opties af en bedenk wat het beste past bij de situatie en behoeften van de organisatie. Een belangrijke keuze is ook op welke wijze je gaat moderniseren. Traditionele ontwikkelmethoden sluiten immers niet aan bij de snelheid en wendbaarheid die wordt gevraagd. Applicatieontwikkeling met een low-code platform doet dit wel. Gartner voorspelt zelfs dat in 2025 zo’n zeventig procent van de nieuw te realiseren software met low-code wordt ontwikkeld, waardoor het interessant is om de organisatie hierop voor te bereiden. De belangrijkste voordelen van low-code bij het moderniseren van verouderde applicaties zijn onder meer:
Snel en wendbaar
Het ontwikkelen met low-code is aanzienlijk sneller dan met traditionele ontwikkelmethoden. Daarnaast is het wendbaarder en levert het in kortere tijd ook betere software doordat het voldoet aan de strengste eisen voor compliance en beveiliging. Bovendien kunnen met low-code meerdere disciplines betrokken worden bij het bouwen van de software waarmee je niet langer volledig afhankelijk bent van de it-afdeling.
Inzetten van fusion teams
Moderne low-code-platformen faciliteren een samenwerking van teams die naast it-professionals bestaan uit mensen die kennis hebben die aansluit bij de zakelijke doelen die je probeert te bereiken. Dit worden ook wel fusion teams genoemd. Met deze werkwijze breek je niet alleen de interne silo’s af en is er minder capaciteit nodig van de it-afdeling, maar ontstaan ook oplossingen die beter aansluiten bij de praktijk. Gartner verwacht dat tegen 2026 minstens 80 procent van gebruikers van low-code platformen bestaat uit ontwikkelaars van buiten de traditionele it-afdelingen, ten opzichte van 60 procent in 2021.
Modern en secure by design
Low-code platformen zijn gebouwd op basis van moderne cloud-technieken waardoor integratie met andere oplossingen makkelijker wordt gemaakt. Zo kan ook een belangrijke bijdrage geleverd worden aan de ‘composable enterprise’. Hierbij kunnen onder meer modulaire elementen, al dan niet uit bestaande oplossingen, worden (her)gebruikt om de beste gebruikerservaring te creëren voor nieuwe workflows en processen. Verder bieden low-code platformen doorgaans standaard beveiligingsmaatregelen voor de infrastructuur- en platformlaag en op server- en applicatieniveau. De noodzakelijke updates worden verzorgd door de low-code leverancier. Verder kunnen beveiligingsinstellingen door organisaties worden geconfigureerd met specifieke richtlijnen, of vangrails om aan de behoeften en eisen van het bedrijf en de branche te voldoen.
Starten met legacy-modernisering
Legacy-modernisering is geen eenmalige activiteit. Het is een continu en langetermijnproces waar iedere organisatie mee te maken heeft. Het hebben van een low-code ‘practice’ en low-code platform kan hierbij helpen. Start snel met deze uitdaging en ga voor moderne oplossingen die waarde genereren voor de hele onderneming. Want elke dag dat je wacht, vergroot je het risico om verder achterop te raken.
Wat je ook met low code kunt doen is virtuele gebruikers van je legacy applicaties creëren. Als je die aan de voorkant gestandaardiseerde Rest-API hosts laat zijn, kun je niet zelden legacy onveranderd en toch compromisloos integreren met latere ontwikkelingen. Als je helemaal af moet dalen naar screen-scraping of andere vormen van robotic process automation is dat niet altijd heel fraai natuurlijk maar vaak is er nog wel iets van een ‘engine’. Bij oude code zie je soms niet terug waarom ze dingen op een bepaalde manier hebben gedaan en bij herbouw kom je daar dan door schade en schande pas achter. Vaak moet je dan in de nieuwe omgeving daar dan ook nog weer andere oplossingen voor bedenken. Als je relocatie van data kunt vermijden scheelt dat vaak erg veel werk en desinvestering.
ja Rob, met SSL proxy ervoor en dan aan internet hangen. Is het meteen cloud alleen met macro service architectuur 😉 Voorbeelden dat het gelukt is ? Foutafhandeling lijkt me lastig als de engine niet perfect is en “iets van een engine” klinkt niet perfect. En hoe ga je een blackbox debuggen als je niet precies weet wat de specificaties zijn. Als die wel duidelijk waren was herbouwen vast niet zo’n punt.
@Dino, klopt helemaal. Alleen hoef je van wat je aan internet hangt niet overal vandaan toegankelijk te hebben natuurlijk, alleen vanaf bekende ip-adressen. En dan weet je waarschijnlijk ook nog dat die SSL proxy weinig anders doet dan een t-sql scriptje pakken, de placeholders erin vervangt met waarden uit de sessiecontext, dat scriptje door sql-Server laat uitvoeren en vervolgens weer weggooit. Althans dat is wat er in z’n basale vorm gebeurt.
Voorbeelden waarvan? Van scriptjes die als virtuele clients naar legacy applicaties fungeren? Ja, allerlei. Onder andere naar alle ms-Office onderdelen via Office-Interop. Powershell scripts die API’s aanroepen. o.a. naar Flow/PowerAutomate met een paar honderd connectors naar allerlei legacy. Uiteraard aanroepen van stored procedures en user defined functions van databases van andere applicaties. Ook COM/DCOM natuurlijk en Managed Code Assemblies. Kortom, iets van een engine. O.a. Exact Globe en SAP BusinessOne. Of SOAP-clients naar Navision/Business Central. Verschillende uitwerkingen hebben we in het verleden voor of bij klanten in gebruik gehad. Sommige dingen hebben klanten nog in gebruik. Of bedoel voorbeelden dat we vanuit SQL-Server succesvol dat dergelijke API’s en scripts aanroepen/uitvoeren?
Dat je makkelijk api’s aan kan roepen geloof ik wel.
Die api’s verbinden met een engine met goede foutafhandeling lijkt me de uitdaging.
Maar ik dacht meer aan een mainframe app monoliet dan die overwegend MS zut waar jij mee werkt, maar er is inderdaad meer legacy.
En als je eenvoudig een api op de app zet, is die app misschien blijkbaar niet zo legacy 🙂
Op zich doet een ssl proxy alleen maar ssl proxien. Meestal termineren en weer opzetten.
Het ‘SOA done wrong’ van Jack door een laag erboven op te zetten gaat om een paradigma wat de complexiteit vergroot, denken in services terwijl het om de processen gaat heeft ervoor gezorgd dat we 30 jaar lang aan het achteruit automatiseren zijn. Want het nieuwe paradigma gaat om de kunstmatige intelligentie van geautomatiseerde beslissingmodellen. Een verandering in techniek voor een andere ontsluiting op laag 8 gaat om dezelfde beslissingsmodellen.
Nieuwe paradigma van een event-driven architectuur gaat tenslotte om de verbeterde netwerkcommunicatie met IoT die een automatisering van bedrijfsprocessen mogelijk maakt in plaats van een digitalisering van de administratieve processen. De RPA van eventhandlers is wat anders dan de export functie van een API als het om de beslissingsmodellen gaat. Door management by exception toe te passen in een event-driven architecture kunnen organisaties efficiënter werken en beter reageren op belangrijke gebeurtenissen die zich voordoen.
Bijvoorbeeld door het sturen op de kritieke aspecten van een systeem want legacy is een inhoudsloos begrip als de kosten en baten ervan niet gekwantificeerd zijn. Aangaande alle feedback-lussen in het systeemdenken zijn er tenslotte altijd de lineaire oorzaak-gevolg acties in de causale lussen van een ToC paradigma. Want investeren in een non-bottleneck is een desinvestering terwijl het niet investeren in een bottleneck een verlies is.
Inhoudsloos als kosten en baten niet gekwantificeerd zijn ?
En als je dan ingegrepen wordt, blijkt het achteraf elke keer duurder dan verwacht..
Je kunt ook prima sturen op fud, fomo of “anderen doen het ook” (dus moet wel goed zijn), “anderen doen het juist niet” (en daarom houden we voorsprong).
je kunt overal op sturen, net zoals je voor allerlei architectuur kunt kiezen.
Hoe weet je nou waar je bottleneck zit als je te maken hebt met een blackbox waar je geen afscheid van durft te nemen ?
Complexiteit vergroten, daar ben je zelf gezien je reacties niet zo vies van en ik heb die onmenselijke KI nog nooit over ons als laag 8 horen spreken 😉
@Dino, legacy als die waar jij op doelt was meestal in de negentiger jaren al een keer aan de beurt geweest. Er ging vrijwel altijd platformintegratie aan vooraf voor terminal- emulatie, bestandstoegang, crossing printing-queus e.d. Op gegeven momenten was er ten behoeve van dergelijke legacy altijd wel iets van een screen-grabber of een query tool van de fabrikant of een derde beschikbaar.
De uitdaging is inderdaad het 100% robuust te hebben en met goede foutafhandeling, ook op onbetrouwbare verbindingen. Door daarvoor platformfunctionaliteit te gebruiken (bedoeld voor grotere documenten maar net zo goed werkend op bestandjes van een regel) valt dat heel simpel te waarborgen.
Volgens de AI van Bing is laag 8 de gebruiker, de uiteindelijke ontvanger of zender van de data. Laag 8 wordt dus als grap gebruikt om te verwijzen naar problemen die niet gerelateerd zijn aan het OSI-model maar aan menselijke factoren, zoals politiek, organisatie of cultuur welke uiteindelijk van invloed zijn op de communicatie. Wat betreft het nieuwe paradigma van AI als event-processor/consumer blijkt deze makkelijker natuurlijke taal te kunnen verwerken dan sommige lezers. Laatste zin, eerste alinea van een andere ontsluiting in de voorgaande reactie gaat om het feit dat AI ook een event-producer kan zijn waarbij event-driven apps voor de notificaties zorgen.
Wachtrijen zijn een meetpunt in de keten als het om de Theorie of Contraint gaat, de bottleneck van printing-queus gaat meer om legacy in het proces zelf als ik kijk naar proces optimalisaties. De kosten-baten analyses van alle ETL batchverwerkingen in EDA architecturen zijn dan ook vooral een bedrijfsmatige afweging over de efficiëntie van de infrastructuur doordat relocatie van de data om centralisatie hiervan gaat. Uiteraard is mijn reactie niet meer dan een mening maar omdat laag 8 van het OSI-model door AI op een andere manier ICT gaat consumeren is een focus op de output van het verleden misschien niet de weg naar de toekomst.
ja, AI weet wat er met laag 8 bedoeld als jij erover begint.
net zoals wij allemaal, of juist omdat wij dat allemaal weten.
Wat kwantificeren betreft, hoeveel zou het kosten om steeds dezelfde fout te maken
als niet naar het verleden wordt gekeken, bijv door in iedere reactie onnodige complexiteit te introduceren.
Maar terug naar het artikel : upcycle composable enterprise met fusionteams of zoiets. En waarom ?
“Start snel met deze uitdaging en ga voor moderne oplossingen die waarde genereren voor de hele onderneming. Want elke dag dat je wacht, vergroot je het risico om verder achterop te raken.”
Vast ook “niet meer dan een mening”.