‍Hardu råd til at omskrive din Windows-applikation?

Er du en Windows ISV, der lider af misundelse over web-native SaaS? Overvejer du at omskrive din(e) eksisterende Windows®-applikation(er), så du kan slutte dig til de seje børn, der leverer "moderne" applikationer? Tror du, at dine kunder ville foretrække at bruge en web-native applikation?

Ikke så hurtigt!

Hvis du har tænkt på at omskrive din Windows-applikation, er der en anden mulighed.

For det første, hvis din app er f.eks. 25 år gammel, betyder en omskrivning, at du vender ryggen til 25 års kode og fejlrettelser og hundredvis af funktioner, der er finpudset og forbedret på baggrund af input fra dine kunder og købere, med dusinvis af afhængigheder (sandsynligvis flere, men lad os være konservative), et gennemprøvet workflow og loyale kunder.

Hvis det ikke skræmmer dig, er her 12 grunde mere til at beholde din Windows-applikation.

Udfordringer med at omskrive Windows-applikationer

Personale: Du bliver sandsynligvis nødt til at ansætte et nyt udviklingsteam, indgå en kontrakt med et konsulentfirma eller omskole dit nuværende personale til at bygge en web-native app - samtidig med at du understøtter og forbedrer din nuværende Windows-app. Hvorfor er det sådan? De fleste udviklere af Windows-applikationer har ikke ekspertise eller omfattende erfaring med de programmeringssprog og UX-designtilgange, der kræves for at bygge webapps.

Ressourcer: At omskrive en Windows-applikation til en webapp kræver en betydelig investering i tid, penge og kvalificerede ressourcer. Budgetbegrænsninger og ressourcetilgængelighed kan være en udfordring, og det kan tage helt op til ti år at komme på markedet med en ny app til komplekse, funktionsrige Windows-applikationer.

Funktionalitetsparitet: Det er næsten umuligt at sikre, at den nye web-native applikation har samme funktionalitet som en etableret Windows-applikation. Du bliver nødt til at genimplementere funktioner, der er specifikke for Windows, og finde tilsvarende webbaserede løsninger, som måske ikke findes. Desværre vil du sandsynligvis ikke være i stand til at genskabe vigtige, vellidte funktioner, der opfylder eksisterende kunders forventninger.

UI/UX-tilpasning: Det kan være vanskeligt at tilpasse brugergrænsefladen og brugeroplevelsen fra et desktop-miljø til et web-miljø. Du bliver nødt til at overveje forskelle i responsivt design, navigation og brugerinteraktion.

Ydeevne: Webapps er underlagt netværksforsinkelser, browserbegrænsninger og varierende enhedsfunktioner. Kunder, der er vant til en indbygget Windows-apps ydeevne, vil opdage, at webapps ikke fungerer lige så godt, især de brugere, der arbejder eksternt.

Browserkompatibilitet: Det er besværligt at sikre kompatibilitet på tværs af browsere, fordi hver webbrowser har sine egne særheder og problemer med at overholde standarder.

Migrering af data: Det er utroligt komplekst at migrere data fra Windows-applikationen til den web-native app og samtidig opretholde dataintegritet og -konsistens. Du bliver sandsynligvis nødt til at konvertere dataformater, hvilket sætter dine data i fare for at gå tabt eller blive ødelagt.

Sikkerhed: Webapplikationer er udsat for forskellige sikkerhedstrusler, f.eks. cross-site scripting (XSS), cross-site request forgery (CSRF), SQL-injektion, uvaliderede omdirigeringer og videresendelser osv. Derudover skal du integrere din webapp med din identitetsudbyder eller implementere OAuth, SAML eller andre godkendelsesprotokoller for at muliggøre Single Sign-on og multifaktor-godkendelse.

Ældre afhængigheder: Hvis din Windows-applikation er afhængig af ældre teknologier eller afhængigheder, som ikke let kan overføres til nettet, skal du finde en alternativ løsning eller investere i specialudvikling, hvilket øger omkostningerne og forlænger time-to-market.

Integration med eksterne systemer/hardware: Hvis din Windows-applikation interagerer med eksterne systemer eller hardware, f.eks. sensorer, printere eller andet periferiudstyr, er det svært at sikre problemfri integration med disse komponenter i et webmiljø.

Test og kvalitetssikring: Det er ressourcekrævende at administrere og vedligeholde testsuiter til en web-native applikation.

Brugeruddannelse og -adoption: Hvis brugerne skal skifte fra en Windows-applikation til en web-native, kræver det uddannelse og dokumentation for at lette skiftet. Kunder, der er tilfredse med funktionerne i den eksisterende applikation, vil være meget tilbageholdende med at skifte.

{{CTAEMBED_IDENTIFIER}}

Hvad kan du gøre for at imødekomme markedets udfordringer?

Jeg talte for nylig med en respekteret, markedsledende ISV, som havde regnet på tidshorisonten og omkostningerne ved at omskrive deres flagskibs Windows-applikation som reaktion på et par nye webapps, der kom ind på deres marked. Et nyt web-native app-udviklingsteam ville have brug for mindst 5 år til at udvikle en web-app med bare en brøkdel af funktionaliteten i flagskibsapplikationen. I mellemtiden ville ISV'en være nødt til at beholde det eksisterende udviklingsteam til at vedligeholde og forbedre Windows-applikationen.

I bund og grund ville de fordoble antallet af udviklere i fem år for at få en moderne app med mindre end halvdelen af funktionaliteten i den app, de allerede havde. Mens ledelsesteamet absorberede denne knusende erkendelse, bidrog deres produktledelsesteam med undersøgelser, der viste, at deres kunder elskede den eksisterende applikations rige funktionalitet og var tilbageholdende med at ændre den.

Som man siger: "Hvis det ikke er i stykker, hvorfor så reparere det?"

Efter mere analyse indså ledelsen, at kerneproblemet med flagskibsappen ikke var appen, men hvordan de leverede den, dvs. på deres egen infrastruktur ved hjælp af Citrix. Det var dyrt. Det var komplekst at administrere. Det var langsomt. Den var ikke brugervenlig.

ISV'en besluttede at gå fra at bruge Citrix i deres infrastruktur til at bruge GO-Global i en offentlig sky. For det første blev deres driftsomkostninger straks reduceret. Endnu vigtigere var det, at de fandt ud af, at GO-Global i høj grad forbedrede deres kunders oplevelse med nemme logons, hurtig ydeevne og funktioner som Session Reconnection, som gør det muligt for brugere, der oplever et uventet netværksudfald, at vende tilbage til deres GO-Global-session i nøjagtig den tilstand, de forlod den i, efter at de havde autentificeret sig ved hjælp af den normale loginprocedure.

En anden fordel var muligheden for at implementere Single Sign-On og to-faktor-autentificering med langt mindre kompleksitet og omkostninger end med Citrix.

Hvis du vil gøre din applikation platformsuafhængig eller vil flytte til en SaaS-model, er det absolut muligt - uden omskrivning - ved at bruge GO-Global til at levere din Windows-applikation fra enhver sky til kunder, der befinder sig hvor som helst.

GO-Global er specialbygget til at udgive Windows-applikationer fra enhver sky - enkelt, nemt og omkostningseffektivt. Og når GO-Global implementeres på en hvilken som helst skytjeneste, udnytter den skytjenestens eksisterende infrastruktur og sikkerheds- og skalerbarhedsfunktioner til at levere høj funktionalitet med mindre kompleksitet og omkostninger.

At undgå en omskrivning af programmet betyder, at du:

• Bevar den rige funktionalitet, som dine kunder elsker og er afhængige af
• Eliminer risikoen for datakorruption, der er mulig ved konvertering af dataformater
• Bevar den brugeroplevelse, dine kunder allerede forstår
• Undgå at omkonfigurere appens integration med eksterne komponenter
• Afbryd behovet for at udforske alternative løsninger på eksisterende afhængigheder.
• Undgå at tvinge dine kunder til at tage en ny app i brug (når den gamle fungerede godt)

For at anmode om en demo, klik her; for en gratis 30-dages GO-Global prøveperiode, klik her.