Laten we eerst beginnen met enkele definities
Als we kijken op Wikipedia, komen we uit bij de term "Software Modernization"
"Legacy modernisering, ook wel bekend als software modernisering of platform modernisering, verwijst naar de conversie, herschrijving, of porting van een legacy systeem naar moderne computer programmeertalen, architecturen (bijvoorbeeld microservices), software bibliotheken, protocollen of hardware platforms. Legacy-transformatie heeft als doel de waarde van de legacy-investering te behouden en uit te breiden door migratie naar nieuwe platformen, om te profiteren van het voordeel van de nieuwe technologieën." (Bron: Software modernization - Wikipedia))
Oké. Dat is een brede definitie. Als we kijken naar wat anderen hierover te zeggen hebben dan zien we al snel dat de algemene consensus over App Modernization is om je oplossing te vernieuwen, door gebruik te maken van modernere programmeertalen, platformen en software architecturen.
"Applicatiemodernisering is het proces waarbij bestaande legacy-applicaties worden gemoderniseerd op basis van hun platforminfrastructuur, interne architectuur en/of functies" (bron: Application Modernization: An Essential Guide | IBM)
En dan hebben we TechBeacon met een nog meer to-the-point definitie:
"Applicatiemodernisering is het proces waarbij oude applicaties, en de platformen waarop ze draaien, opnieuw 'nieuw' worden gemaakt door ze te vervangen of te updaten met moderne features en mogelijkheden die beter aansluiten bij de huidige bedrijfsbehoeften." (bron: App modernization 101: Understand your options—and how to get started | TechBeacon).
Er zijn wat kanttekeningen hier. Want, wat is legacy eigenlijk? Als we kijken naar de bovenstaande definities is er een grote veronderstelling dat de oplossing in kwestie "oud" is en niet veel TLC heeft gekregen. Hoewel er zeker oplossingen zijn die veel te lang verwaarloosd zijn, is dat meestal niet het geval. Natuurlijk heb je je oplossing in de afgelopen jaren ontwikkeld en waarde toegevoegd voor je klanten. Als je dat niet deed, hoe relevant ben je dan nog? Ja, sommige oplossingen veroorzaken een enorme afhankelijkheid van leveranciers, en niemand maakt zich zorgen dat klanten zullen vertrekken vanwege... deze afhankelijkheid. Maar, vergeleken met alle software die er is, is dat een niche markt.
We kunnen stellen dat je tot nu toe best wel aan modernisering hebt gedaan.
Wanneer is het nodig om je oplossing te moderniseren?
Dus, wanneer moet je echt moderniseren? Nou, laten we het er eerst over eens zijn dat het toevoegen van waarde aan je oplossing door de jaren heen niet echt moderniseren is. Ik zou zeggen als je wordt beperkt door de technologie stack, software architectuur of platform dat je gebruikt, dan is het tijd om te moderniseren. Laten we dit met een voorbeeld doen.
Leer meer over wat Intercept voor jou kan betekenen als het om Applicatie Modernisatie gaat
Het praktijkvoorbeeld
Je hebt een oplossing die draait op een Windows Server. Elke 3 maanden breng je een nieuwe versie van uw oplossing uit, verpak deze in een installer en verstuur deze naar de klanten. Zij kunnen dan de nieuwe versie installeren en voilà.
Dit gaat al vele jaren goed maar je hebt een aantal interne en externe eisen. Je hebt je bedrijf uitgebreid en je bedient nu klanten over de hele wereld. Bovendien wil je meerdere functies vaker aanbieden en niet meer een heleboel verschillende versies ondersteunen. Op dit punt ben je gebonden aan welke versie je klant installeert en of hij regelmatig de updates uitvoert. Ook bestaat het risico dat klanten een negatieve ervaring hebben vanwege prestatieproblemen op een platform en de infrastructuur die je niet kunt controleren. Het succes van je oplossing hangt sterk af van de IT-teams ter plaatse.
De oplossing
Goed... Dus laten we dit eens ontleden. Je hebt een aantal eisen:
- Klanten wereldwijd bedienen;
- Niet afhankelijk zijn van lokale IT-teams voor installatie en systeembeheer;
- Vaker nieuwe functies uitbrengen.
Laten we eens kijken naar een paar oplossingen.
We kunnen elke Virtuele Machine naar de Public Cloud verplaatsen (Azure, uiteraard). Dit kan resulteren in een paar machines per klant, maar dan heb je de leiding over de infrastructuur. Hiermee voorkom je afhankelijkheid van de IT Teams van de klant. Gooi er wat Azure Virtual Desktop bij en "Saasify" je Client/Server applicatie.
Dit zou een goede eerste stap zijn, maar je zal een hoop overhead hebben. Alhoewel, als we kijken naar de eerder genoemde definities dan zijn we hier het platform aan het moderniseren. We gaan van een on-premise oplossing naar een cloud-gehoste oplossing met veel meer mogelijkheden.
Dus... dat is één manier om het te doen, maar we vinken niet alle vakjes aan. Ook al kunnen we virtuele machines over de hele wereld inzetten, we hebben nooit iets geïmplementeerd om vaker nieuwe functies te versturen, en we hebben een hoop overhead.
Andere opties
Er zijn andere opties... Niet een paar, maar een heleboel. Wat als we het platform zouden moderniseren en van die virtuele machines af zouden stappen? We kunnen gaan voor App Services of de oplossing containeriseren. Wat als we momenteel een website draaien op IIS en MSSQL als een database? Misschien kunnen we die code een beetje herformuleren en het Microsoft Azure platform As A Service gebruiken.
We kunnen nog steeds voor dat single tenant scenario gaan en elke klant zijn eigen app service geven. Maar het is een stuk eenvoudiger om App Services te updaten vanuit een pijplijn in tegenstelling tot virtuele machines.
Zodra je het platform hebt gemoderniseerd, kun je gaan profiteren van nog meer voordelen van die Public Cloud. Dit is het moment waarop we echt kunnen beginnen met moderniseren tot gigantische proporties.
Waar met traditionele infrastructuur je ideeën misschien een beetje futuristisch waren, en je niet alles kon implementeren wat je klant wenste omdat het platform de beperkende factor was, kan je dat nu wel.
In feite, zodra je het platform gemoderniseerd hebt en je al die geweldige nieuwe functies wilt gebruiken, zal je snel leren dat je software architectuur een nieuwe beperkende factor kan zijn. En dat is het moment waarop je je gaat richten op het uitvoeren van veel ontwikkeling. Er zijn gevallen waar bedrijven besluiten om vanaf nul te beginnen en alles opnieuw op te bouwen naar een cloud native platform - waarbij ze alle tussenliggende stappen overslaan. Maar hier is een groot risico aan verbonden. Je zult veel ontwikkelcapaciteit toewijzen die je niet kan besteden aan de huidige oplossing en het platform, wat zelfs kan resulteren in minder toegevoegde waarde. Als je de financiële mogelijkheden en de tijd hebt, is het zeker een interessant traject om te volgen, maar ik zie het niet vaak gebeuren.
Om de vraag te beantwoorden: Wanneer moet je je oplossing moderniseren? Nou... Voordat een platform, software architectuur of technologie stack een beperkende factor wordt en je niet langer kunt bieden wat je klanten vragen. Je hoeft geen meerjarige roadmaps te maken, maar je moet wel je oplossing, je markt en je klanten begrijpen.
Leer meer over wat Intercept voor jou kan betekenen als het om Applicatie Modernisatie gaat.