Kunje het je veroorloven om je Windows-toepassing te herschrijven?

Ben je een Windows ISV die lijdt aan web-native SaaS afgunst? Overweeg je een herschrijving van je bestaande Windows® applicatie(s) zodat je je kunt aansluiten bij de coole kinderen die "moderne" applicaties leveren? Denk je dat je klanten liever een web-native applicatie gebruiken?

Niet zo snel!

Als je erover hebt gedacht om je Windows-toepassing te herschrijven, is er nog een andere optie.

Ten eerste, als je app bijvoorbeeld 25 jaar oud is, betekent een herschrijving dat je 25 jaar code en bugfixes en honderden functies de rug toekeert, aangescherpt en verbeterd op basis van input van je klanten en kopers, met tientallen afhankelijkheden (waarschijnlijk meer, maar laten we conservatief zijn), een bewezen workflow en loyale klanten.

Als dat je niet afschrikt, zijn hier nog 12 redenen om je Windows-toepassing te behouden.

Uitdagingen voor het herschrijven van Windows toepassingen

Personeel: je moet waarschijnlijk een nieuw ontwikkelteam aannemen, een contract afsluiten met een adviesbureau of je huidige personeel omscholen om een web-native app te bouwen, terwijl je je huidige Windows app ondersteunt en verbetert. Waarom? De meeste ontwikkelaars van Windows-applicaties hebben geen expertise of uitgebreide ervaring in de programmeertalen en UX-ontwerpbenaderingen die nodig zijn voor het bouwen van webapps.

Hulpbronnen: Het herschrijven van een Windows-toepassing als webapp vereist een aanzienlijke investering in tijd, geld en ervaren resources. Budgetbeperkingen en de beschikbaarheid van resources kunnen een uitdaging vormen, en de tijd die nodig is om een nieuwe app op de markt te brengen kan oplopen tot tien jaar voor complexe Windows-applicaties met veel functies.

Gelijkwaardige functionaliteit: Ervoor zorgen dat de nieuwe web-native applicatie dezelfde functionaliteit heeft als een gevestigde Windows applicatie is zo goed als onmogelijk. Je zult functies die specifiek zijn voor Windows opnieuw moeten implementeren en gelijkwaardige webgebaseerde oplossingen moeten vinden die misschien niet bestaan. Helaas zul je waarschijnlijk niet in staat zijn om cruciale geliefde functies die voldoen aan bestaande klantverwachtingen opnieuw te maken.

UI/UX-aanpassing: Het aanpassen van de gebruikersinterface en gebruikerservaring van een desktopomgeving naar een webomgeving kan lastig zijn. Je moet rekening houden met responsive design, navigatie en verschillen in gebruikersinteractie.

Prestaties: Webapps zijn onderhevig aan netwerklatentie, browserbeperkingen en verschillende apparaatmogelijkheden. Klanten die gewend zijn aan de prestaties van een native Windows app zullen merken dat webapps minder goed presteren, vooral gebruikers die op afstand werken.

Browsercompatibiliteit: Zorgen voor cross-browser compatibiliteit is lastig en lastig omdat elke webbrowser zijn eigenaardigheden heeft en problemen met het naleven van standaarden.

Migratie van gegevens: Het migreren van gegevens van de Windows applicatie naar de web-native app met behoud van gegevensintegriteit en -consistentie is ongelooflijk complex. Je zult waarschijnlijk gegevensformaten moeten converteren, waardoor je gegevens het risico lopen op verlies of corruptie.

Beveiliging: Webapplicaties staan bloot aan verschillende beveiligingsrisico's, zoals cross-site scripting (XSS), cross-site request forgery (CSRF), SQL-injectie, ongeldige redirects en forwards, enz. Bovendien moet je je webapplicatie integreren met je identity provider of OAuth, SAML of andere authenticatieprotocollen implementeren om Single Sign-on en multifactor authenticatie mogelijk te maken.

Legacy afhankelijkheden: Als uw Windows-toepassing afhankelijk is van legacy-technologieën of afhankelijkheden die niet eenvoudig kunnen worden overgezet naar het web, moet u een alternatieve oplossing vinden of investeren in aangepaste ontwikkeling, waardoor de kosten hoger worden en de time-to-market langer duurt.

Integratie met externe systemen/hardware: Als uw Windows-toepassing interageert met externe systemen of hardware, zoals sensoren, printers of andere randapparatuur, is het moeilijk om een naadloze integratie met deze componenten in een webomgeving te garanderen.

Testen en QA: Het beheren en onderhouden van testsuites voor een web-native applicatie vergt veel middelen.

Training en adoptie van gebruikers: Om gebruikers over te laten stappen van een Windows applicatie naar een web-native applicatie zijn training en documentatie nodig. Klanten die tevreden zijn met de functies en functionaliteit van de bestaande applicatie zullen zeer terughoudend zijn om over te stappen.

{{CTAEMBED_IDENTIFIER}}

Wat kunt u doen om de uitdagingen van de markt aan te gaan?

Onlangs sprak ik met een gerespecteerde, marktleidende ISV die de tijdlijn en kosten had berekend die nodig waren om hun belangrijkste Windows-applicatie te herschrijven als reactie op een paar nieuwe webapps die hun markt betraden. Een nieuw web-native app ontwikkelteam zou minstens 5 jaar nodig hebben om een web app te ontwikkelen met slechts een fractie van de functionaliteit in de vlaggenschip applicatie. In de tussentijd zou de ISV het bestaande ontwikkelteam moeten behouden om de Windows applicatie te onderhouden en te verbeteren.

In wezen zouden ze hun aantal ontwikkelaars vijf jaar lang verdubbelen om een moderne app te krijgen met minder dan de helft van de functionaliteit van de app die ze al hadden. Terwijl het managementteam dit verpletterende besef in zich opnam, kwam hun productmanagementteam met onderzoek waaruit bleek dat hun klanten hielden van de rijke functionaliteit van de bestaande applicatie en niet graag wilden veranderen.

Zoals het gezegde luidt: "Als het niet kapot is, waarom zou je het dan repareren?

Na meer analyse realiseerde het managementteam zich dat het kernprobleem met de vlaggenschip-app niet de app was, maar de manier waarop ze die leverden, namelijk op hun eigen infrastructuur met Citrix. Het was duur. Het was complex om te beheren. Het was traag. Het was niet gebruiksvriendelijk.

De ISV besloot over te stappen van Citrix op hun infrastructuur naar GO-Global op een publieke cloud. Ten eerste werden hun operationele kosten onmiddellijk verlaagd. Belangrijker was dat ze ontdekten dat GO-Global de ervaring van hun klanten aanzienlijk verbeterde, met eenvoudige aanmeldingen, snelle prestaties en functies zoals Session Reconnection, waarmee gebruikers die te maken krijgen met een onverwachte netwerkstoring kunnen terugkeren naar hun GO-Global sessie in de exacte staat waarin ze die achterlieten na authenticatie via de normale aanmeldprocedure.

Een ander voordeel was de mogelijkheid om Single Sign-On en twee-factor authenticatie te implementeren met veel minder complexiteit en kosten dan met Citrix.

Als je je applicatie platformonafhankelijk wilt maken of wilt overstappen op een SaaS-model, is dat absoluut mogelijk - zonder te herschrijven - door GO-Global te gebruiken om je Windows-applicatie vanuit elke cloud te leveren aan klanten die zich overal bevinden.

GO-Global is speciaal gebouwd om Windows-toepassingen te publiceren vanuit elke cloud - eenvoudig, gemakkelijk en kosteneffectief. En wanneer GO-Global wordt ingezet op een cloudservice, maakt het gebruik van de bestaande infrastructuur en beveiligings- en schaalbaarheidsfuncties van die cloudservice om een hoge functionaliteit te leveren met minder complexiteit en kosten.

Een applicatie herschrijven vermijden betekent dat je:

• Behoud de rijke functionaliteit waar uw klanten van houden en op vertrouwen
• Elimineer het risico op gegevenscorruptie dat mogelijk is bij het converteren van gegevensformaten
• Behoud de gebruikerservaring die uw klanten al begrijpen
• Voorkom herconfiguratie van de integratie van de app met externe componenten
• Annuleer de noodzaak om alternatieve oplossingen te onderzoeken voor bestaande legacy-afhankelijkheden
• Vermijd dat je klanten gedwongen worden om een nieuwe app te gebruiken (terwijl de oude geweldig werkte)

Om een demo aan te vragen, klik hier; voor een gratis 30-dagen proefversie van GO-Global, klik hier.