3 questions à poser lors de la migration de Desktop vers le Web

Les cadres Web modernes étant de plus en plus fréquents, les responsables du développement et des produits ont du mal à savoir quand se mettre à jour et mettre à jour leurs applications héritées, quelles sont les bonnes raisons de la transition et comment passer sans créer de pandemonium. Cet article vise à définir des règles générales que toute personne peut suivre pour assurer une mise à niveau sans heurts à la fois à ses équipes de développement et à leurs utilisateurs.

Les applications Web ayant connu une renaissance au cours de la dernière décennie, de nombreuses personnes et entreprises se demandent quelle est la voie à suivre. de l'action est, et hésitent à sauter dedans, de peur qu'ils ne répètent les erreurs des réécritures passées. Dans cet article, nous discuterons des questions à poser, des coches à cocher et du chemin à suivre pour simplifier la compréhension d'un effort impliqué.

Pourquoi faisons-nous cela (à nouveau)?

Pour de nombreuses entreprises, le passage à Internet semble être quelque chose qu'ils devraient faire plutôt que quelque chose dont ils ont besoin . C'est-à-dire qu'ils voient le mouvement moderne du Web dans le monde du développement et ne veulent pas être laissés pour compte, mais n'ont pas complètement analysé le besoin dans leur sphère particulière. Comprendre les raisons de votre déménagement, puis évaluer votre situation, aideront à déterminer si un besoin existe réellement.

Concurrence

L'un des principaux moteurs de l'amélioration des logiciels est l'influence du marché – la complaisance à innover est un moyen rapide de perdre du marché. partager. Si vos concurrents disposent d'une application plus moderne, plus disponible et plus conviviale pour soutenir leur activité, vos revenus en ressentiront l'impact. C’est évident avec les applications externes qui ont un effet direct sur les revenus: une application Web a une barrière d’entrée inférieure à celle d’une application de bureau. Si vos utilisateurs peuvent ouvrir un navigateur et commencer à utiliser le produit d’un concurrent en quelques secondes, vous perdrez votre confiance. les clients qui accordent de l'importance à la facilité d'utilisation par rapport aux autres mesures. Pour les applications internes, les impacts ne sont pas aussi perceptibles: le vieillissement des applications internes affectera à terme la productivité et l'efficacité, ce qui affectera les revenus par le biais de coûts plus élevés. L'excuse "cela fonctionne toujours et nous ne pouvons pas nous permettre de le remplacer" rattrapera finalement votre organisation alors que votre concurrence met en œuvre des outils et des processus plus rationalisés.

Matériel

Le matériel vieillissant peut ralentir le Web et les ordinateurs de bureau. les applications, mais les modifications importantes apportées aux applications Web sont filtrées via un système relativement cohérent qui répartit le traitement nécessaire au travail effectué. Les logiciels de bureau, en raison du traitement qui se produit de manière inhérente directement sur la machine d'un utilisateur, représentent une charge plus importante et deviennent plus sensibles aux limites de la vitesse du processeur, de la mémoire vive et du lecteur de données. De ce fait, les mises à niveau des logiciels de bureau peuvent rendre ce matériel obsolète, alors que les nouvelles versions d'applications Web peuvent concentrer leurs besoins de calcul accrus sur le serveur, limitant ainsi le traitement sur le navigateur. Il en résulte des applications qui peuvent fonctionner même sur des machines à spécifications assez basses, augmentant ainsi le pool de clients potentiel.

Base d'utilisateurs

Les employés distants, qu'ils soient permanents ou qui s'aventurent assez souvent sur le terrain, peuvent avoir leur efficacité est réduite par les logiciels de bureau, soit par des mises à jour obligatoires ou par des problèmes de flux de travail, soit tout simplement par le fait qu’elles ne sont pas locales sur un ordinateur capable d’exécuter ce dont ils ont besoin. Ce point rejoint les deux motivations précédentes, ces trois raisons pouvant aboutir à une perte de productivité. En ce qui concerne les clients externes, toutefois, une migration vers le Web ouvre une voie plus facile à la transition vers un modèle Logiciel en tant que service (SaaS).

Current Technology

Logiciel de bureau, tant interne et externes, peuvent souffrir de l’obsolescence des cadres sous-jacents dans lesquels ils ont été écrits. Il est de plus en plus difficile de trouver des développeurs qui se souviennent encore du langage ou de la plate-forme – ou pire encore, d'essayer de trouver une personne disposée à l'apprendre pour la prendre en charge – à mesure que le temps passe. Même si vous avez le personnel nécessaire pour prendre en charge des applications plus anciennes, lorsque de nouvelles applications (écrites dans des cadres modernes) sont ajoutées à leur charge de travail, la résolution des bugs et le support général deviennent de plus en plus difficiles, car les membres de l’équipe commencent à avoir à partager leur temps entre leurs plates-formes, ce qui leur fait perdre un temps précieux. temps dû à la montée en puissance. La plupart des logiciels plus anciens ont également tendance à être écrits de manière inefficace, devenant un effort disparate des équipes de développeurs qui se sont succédé. Les performances peuvent souffrir de manières qui ne peuvent pas être corrigées sans une réécriture complète en raison de l'architecture (ou de son absence).

Qu'est-ce que cela va faire pour nous?

Nous avons exposé les raisons pour lesquelles nous souhaitons passer à Maintenant, réfléchissons à ces raisons en termes d’avantages pour l’entreprise.

Appareils et performances

Les applications Web permettent l’accès à partir de n’importe quel appareil, sans nécessiter de réseau privé virtuel, ce qui permet de la plupart des systèmes d'exploitation, qu'ils soient de bureau ou mobiles. La motivation de notre matériel ci-dessus devient une opportunité d'augmenter considérablement le nombre de périphériques que vous pouvez prendre en charge, avec les tablettes et les téléphones entrant dans l'équation pour des flux de travail spécifiques. Cela peut augmenter l'audience des applications externes, car les utilisateurs sont plus susceptibles d'utiliser votre logiciel s'ils peuvent y accéder depuis un plus grand nombre d'emplacements et avec tout le matériel dont ils disposent lorsqu'ils en entendent parler. Pour les utilisateurs internes, les applications Web leur permettent d’être plus réactifs lorsque des urgences surgissent ou lorsque vous souhaitez offrir une plus grande flexibilité quant à leur lieu de travail et à leurs utilisations. La migration d'une application interne vers le Web nécessite de déplacer vos données dans un formulaire plus accessible, ce qui vous permet de placer vos données dans une configuration distribuée. Cela réduira le temps de latence des bureaux qui ne disposent pas des informations auxquelles ils ont besoin d'accéder.

Déploiement et flexibilité

Avec les applications Web, les tracas de déploiements programmés, volontaires ou forcés en masse font désormais partie du passé. Une fois que l'application a été certifiée pour la publication via des tests internes, elle peut instantanément être activée. Cela bénéficie à la fois des corrections de bugs et des nouvelles fonctionnalités, permettant de résoudre les problèmes urgents en un temps réduit et offrant plus de flexibilité et d’immédiateté pour les nouvelles fonctionnalités. Si des déploiements plus petits sont souhaités, il devient plus facile de déterminer le groupe d'utilisateurs ayant accès, en accordant un autre niveau de test pour les nouvelles fonctionnalités. De plus, la structure inhérente aux applications Web modernes permet de mieux respecter les meilleures pratiques, ce qui facilite le passage futur de la technologie frontale en cas de besoin.

Comment y arriver?

Si vous avez posé les questions ci-dessus et que les réponses semblent résoudre les problèmes qui affectent actuellement votre organisation, il est essentiel de déterminer un plan d'attaque approprié pour vous assurer que cette réécriture est bien faite et bien faite.

Définir une approche

Les deux Les options disponibles pour toute personne migrant une application sont de la convertir dans son ensemble ou de la déplacer pièce par pièce. Les deux approches ont leurs avantages et leurs inconvénients, examinons-les de manière approfondie

L’approche privilégiée consiste à procéder de la sorte dans l’ensemble. Compte tenu de l'importance et de la valeur d'un processus UX approprié gagnant en visibilité et en reconnaissance au sein de la communauté du développement au cours de la dernière décennie, il est fort probable que l'application de bureau actuelle n'a pas été conçue pour une utilisation conviviale. De plus, la simple migration de l'interface utilisateur de bureau en l'état entraînera une expérience médiocre dans la plupart des cas (en fonction de la complexité et de la conception actuelle de l'application existante). La conception d'un flux de travail d'application par flux de travail empêche les concepteurs et les développeurs de planifier à l'avance et de créer une architecture cohérente. Préfacer votre développement avec un processus UX complet de recherche utilisateur, de conception d'interaction, de conception visuelle et de test d'acceptation utilisateur vous permettra de créer une application offrant une grande facilité d'utilisation et une grande utilité, avec une apparence et une convivialité modernes.

sont assez évidentes – un processus de conception prendra beaucoup de temps (encore une fois, en fonction de la taille et de la complexité de l'application), aucun code développé n'étant produit jusqu'à son achèvement. Si votre organisation est pressée par le temps, cette méthode ne fonctionnera probablement pas, malheureusement.

L'autre option consiste à migrer l'application pièce par pièce. Cette méthode présente les avantages suivants: elle permet d’obtenir des produits plus rapidement, offrant ainsi une visibilité accrue aux parties prenantes. Avec des versions plus rapides, les utilisateurs peuvent fournir des commentaires rapidement et souvent, qui peuvent ensuite être intégrés dans les processus de l'équipe de conception. Cette approche permet également de gérer plus facilement des défis techniques imprévus, car ces obstacles peuvent être résolus avec une refonte sans s’être engagés sur un chemin plus long. Enfin, la principale raison et l'avantage de cette option est: le budget. Entre la planification, l'estimation et la génération de revenus, un plan de conception et de développement agile dynamisera ces trois catégories. Demander un budget pour des sections plus petites et distinctes d'une application devient plus facile à mesure que les estimations deviennent plus précises et que les versions plus rapides permettent aux applications internes de rendre les utilisateurs plus efficaces, tandis que les applications externes peuvent commencer à générer des ventes.

Les inconvénients de cette approche sont fondamentalement tous. des pros listés pour l’autre option: l’équipe UX n’aura pas incorporé l’intégralité de l’application lors du processus de conception et l’équipe de développement n’aura pas eu la possibilité de créer une architecture basée sur une compréhension complète des processus requis. Les deux applications (le poste de travail et l'application Web qui vont bientôt être remplacés) devront être prises en charge et maintenues, avec des bases de code, des langages, des plates-formes et des frameworks très différents les uns des autres, nécessitant un temps de montée pour basculer entre les deux. [19659027] Analyse d'architecture

Quelle que soit l'approche choisie, l'une de vos premières étapes consiste à analyser votre application actuelle. L'évaluation de la difficulté de cette migration dépend de la fidélité de vos développeurs, tout au long de l'historique de votre application, aux meilleures pratiques en matière d'ingénierie logicielle. Si votre couche de présentation est purement une interface utilisateur – seuls les éléments avec lesquels vos utilisateurs interagissent directement, avec des comportements, une logique métier, un accès aux données, etc. sont clairement divisés en couches distinctes – votre chemin sera alors simple et itératif, avec un effort relativement réduit, et avec une architecture qui ne changera pas.

Cependant, la plupart des gens savent que ce n'est pas le cas. Séparer la logique des niveaux auxquels il appartenait à l’origine (ou créer ce niveau en premier lieu) est ce qui dominera vos efforts. Connexions à la base de données, logique métier permettant de déterminer les valeurs dans une liste déroulante dans le code-behind, dépendances des bibliothèques de calcul et fonctions utilitaires dans la couche de présentation – autant d’indices d’un logiciel à couplage élevé, qui représentent la majeure partie du temps que vous passerez pendant le processus. migration.

Un client Web ne peut pas (et ne devrait pas) ouvrir une connexion de base de données à votre magasin de données. La logique métier doit figurer dans son propre calque et si les règles changent, vous ne devriez pas avoir à passer au crible le code spécifiant la taille et la couleur des boutons. C'est l'état commun des logiciels de bureau et le principal obstacle à surmonter lors de la migration vers une nouvelle technologie. Pour créer un plan de réarchitecture, le principe de base est que tout code d'élément non visuel doit être déplacé, derrière un service, dans un utilitaire ou disponible via un contrôleur.

Hybridation

Notre objectif n'est pas pour réécrire l’ensemble de l’application, mais uniquement les parties qui ne respectent pas les règles établies par les meilleures pratiques. Le résultat final doit être une page Web qui affiche (et éventuellement génère) des éléments visuels, en s’appuyant sur un serveur principal pour la liaison des données avec ses contrôles. L'une des premières étapes de la migration de votre application consiste à déplacer votre couche intermédiaire ou à en créer une à partir de zéro et à la rendre accessible via des services Web. Elle vous permettra de créer une application hybride avec des interfaces de bureau et Web. [19659002] Si la distribution dans le nuage fait partie de votre feuille de route ou de votre liste de sujets d’investigation, c’est l’opportunité parfaite. Le choix d'utiliser le cloud par rapport à un déploiement sur site se résume à la quantité de contrôle que vous souhaitez sur la sécurité de votre application et de vos données. Les serveurs de nuage peuvent être utilisés pour l'application, les données ou les deux, et peuvent être adaptés en fonction des besoins. Si les problèmes de sécurité nécessitent que toutes les données soient hébergées et contrôlées par votre entreprise, le passage de l'application elle-même à un modèle distribué générera tout de même des avantages en termes de performances, en fonction de vos besoins en termes de données.

La validation a lieu à la fois sur le client. et serveur, en fonction de votre domaine. Une validation simple (champs obligatoires, valeurs numériques, longueur, etc.) peut avoir lieu côté client, tandis que la validation par rapport aux règles de gestion doit être gérée via une requête asynchrone au serveur. Si vous ne gérez pas cela dans une collection séparée de validateurs, ils devront être déplacés du calque de votre présentation.

Une fois que l'application principale est correctement séparée des contrôleurs répondant aux requêtes du navigateur, vous pouvez modifier le code dans votre application de bureau pour les utiliser. Cela vous permettra de faire des progrès en ajoutant des fonctionnalités à votre application Web sans avoir à abandonner complètement votre solution existante.

Facteur de forme et conception frontale

Une fois l’arrière-plan et le niveau intermédiaire correctement architecturés, vous devrez décision sur les facteurs de forme (ordinateur de bureau / tablette / téléphone) que vous souhaitez traiter. Cette application est-elle destinée uniquement aux utilisateurs de bureau? Existe-t-il des flux de travail qui pourraient être rendus utilisables sur un périphérique plus petit? Existe-t-il des cas d'utilisation qui plus se révèlent utiles sur une plate-forme mobile?

Une fois que vous avez fait votre choix, l'équipe de conception peut commencer à créer des structures filaires pour tous les types de formulaire que vous souhaitez. Nous avons sélectionné, en notant que la tablette et le téléphone ne doivent pas toujours suivre le même design ni adhérer au même ensemble de limitations. Il y a une raison pour laquelle je l'ai répertoriée comme "ordinateur de bureau contre tablette contre téléphone" et non pas "ordinateur de bureau contre mobile" – les distinctions peuvent faire une grande différence, à la fois en termes de conception et de développement.

À propos des efforts de développement, en utilisant n'importe lequel Un des nombreux cadres réactifs disponibles n’est pas (toujours) la solution pour le réduire. La conception adaptative et les cadres disponibles sont davantage axés sur le développement de sites Web, pas sur le développement d'applications Web. Vous pouvez réduire le temps nécessaire pour créer des éléments spécifiques, mais vous pouvez également utiliser ce temps pour vous assurer que les conceptions sont correctement redistribuées selon différentes résolutions, tailles d'écran et paramètres de densité, ce qui entraîne une surcharge de test beaucoup plus importante que nécessaire.

Conclusion

Nous avons passé en revue une directive générale sur le passage de la technologie de bureau au Web moderne, en posant des questions clés sur les raisons pour lesquelles nous devrions envisager cette idée, quels en sont les avantages et quels sont les plus logiques. la voie à suivre pourrait être. Les environnements de développement sont extrêmement variés et présentent des défis uniques. Le conseil présenté ici n’est donc pas présenté comme une solution, mais plutôt comme un guide que tout le monde peut utiliser pour effectuer un contrôle de cohérence avant une conversion longue et coûteuse.