Développement progressif ou reconstruction des systèmes

Cela semble si tentant : commencez par faire table rase. Appliquez toutes les leçons apprises à une solution à construire à partir de zéro. Aucun compromis de la part des clients existants, et la mise en place du système parfait avec les derniers frameworks. Cependant, nous sommes convaincus que la reconstruction d'un système n'est pas le moyen d'offrir aux clients une solution durable. Stef Roskam, VP Engineering chez Otherside at Work, nous parle de notre vision de ce choix stratégique

"Il s'agit d'une décision consciente de se concentrer sur le développement progressif de la suite Xpert. Et non pas pour proposer aux clients une nouvelle « version 2 » après quelques années de construction. Nos clients l'apprécient également, car cela a une influence positive sur la continuité de nos services et sur la manière dont les nouvelles fonctionnalités sont mises à disposition.

Dans ce blog, nous expliquons pourquoi nous optons pour un développement progressif et ce que cela signifie pour nos clients.

Quelle est la différence entre la reconstruction et le développement progressif ?

Tout d'abord, clarifions ce que nous entendons par reconstruction et développement ultérieur progressif. Stef explique : « La reconstruction signifie qu'un système est entièrement reconstruit, l'ancien et le nouveau système étant complètement séparés l'un de l'autre. Cela signifie qu'il y a une transition difficile entre l'ancien et le nouveau système pour le client, souvent avec une nouvelle mise en œuvre, une migration et une formation approfondie des utilisateurs.

Le développement incrémentiel se concentre sur la reconstruction progressive ou la refactorisation du code existant. Cela signifie que nous réécrivons ou améliorons progressivement les parties obsolètes pour maintenir le système à jour. La principale différence, c'est qu'il n'y a pas de transition majeure et soudaine, mais que les changements se font progressivement.

Pourquoi Otherside at Work ne choisit pas de reconstruire

Pour nous, reconstruire n'est pas une bonne solution, Stef donne plusieurs raisons à cela :

• " La taille de la base de code : le succès d'un processus de reconstruction dépend en grande partie de la taille de la base de code. Une base de code de dix années-hommes est considérablement plus facile à reconstruire qu'une base de code de deux cents années-hommes.
• Coûts élevés et perte de clients : si vous choisissez de reconstruire, vous devez maintenir deux systèmes : l'ancien système et le nouveau système. Cela nécessite plus de personnel, et c'est tout simplement plus cher. Les clients devront également changer à long terme. Avec une plateforme comme Xpert Suite, cela nécessite beaucoup de temps de guidage. Par conséquent, il y a toujours des clients qui ne veulent pas ou ne peuvent pas faire le changement. Dans la pratique, vous constatez donc que les clients abandonnent lors d'un processus de reconstruction.
• Gel du code : Dans une reconstruction complète, le développement de nouvelles fonctionnalités doit souvent être arrêté pour l'ancien système, car toute l'attention et les ressources sont consacrées à la reconstruction. Cela signifie qu'un « gel du code » a lieu, ce qui signifie que les clients ne reçoivent pas de nouvelles fonctionnalités pendant une longue période. Dans un marché où de nouveaux développements sont constants, tels que les lois et règlements et les solutions d'IA, cela peut signifier que les clients sont laissés pour compte. Grâce à un développement supplémentaire, vous pouvez immédiatement mettre à disposition de nouveaux développements au sein de votre solution existante.
• Un nouveau code n'est pas toujours immédiatement meilleur : un code qui existe depuis 10 ans, par exemple, est « aguerri ». Le code a été testé sur de nombreux cas limites et ceux-ci ont été traités par des corrections de bogues. Le code est également souvent optimisé pour gérer la charge souhaitée. Vous souhaitez inclure ces propriétés dans votre nouveau code, mais elles ne sont pas toujours faciles à comprendre. Par conséquent, il y a de fortes chances que vous « jetiez » du bon travail et que vous fassiez des erreurs dans le nouveau code qui avaient déjà été résolues dans le code existant.

Avantages du développement incrémentiel

Otherside at Work opte pour un développement progressif, car cette stratégie offre un certain nombre d'avantages importants. Stef explique :

•  "Réduction des risques en cas de changement : dans le cadre du développement progressif, de nouvelles pièces sont mises en service étape par étape, de sorte que les éventuels problèmes deviennent immédiatement visibles et peuvent être résolus rapidement. Parfois, nous manquons des cas limites qui ne sont pas suffisamment informés et le code plus ancien n'est parfois pas facile à lire. Mais en raison de la méthode de travail progressive, ces risques sont moins importants qu'avec un big bang.
• Amélioration progressive pour le client : En se développant de manière incrémentale, les modifications sont mises en œuvre progressivement, ce qui signifie que les clients peuvent s'habituer plus facilement aux nouvelles fonctionnalités. En cas de petits changements, nous partageons les notes de version. En cas de changements majeurs, nous pouvons choisir de mettre en œuvre le changement progressivement en faisant d'abord tester certains utilisateurs. Si aucun problème ne survient ou s'il est résolu, tout le monde peut passer à autre chose. Cela rend le processus d'accoutumance beaucoup moins drastique.

Défis du développement incrémentiel

Bien que le développement incrémentiel offre de nombreux avantages, il présente également quelques défis. Tout d'abord, il est important que le logiciel soit conçu de manière modulaire. Les composants techniques doivent pouvoir être remplacés indépendamment les uns des autres. L'un des plus grands défis est l'intégration des anciennes et des nouvelles parties.

De plus, lors du développement incrémentiel, il faut tenir compte des modes d'utilisation existants de votre application et de ce que les utilisateurs apprécient ou non. Cela peut sembler un défi, mais c'est en réalité une "bénédiction déguisée". "Cela vous oblige à prendre en compte dès le début du processus l'application pratique de votre solution, ce qui n'est clair qu'une fois que les premiers utilisateurs commencent à l'utiliser dans le cadre d'une reconstruction complète. Le grand défi est donc de trouver le bon équilibre entre tenir compte des limitations pratiques et oser guider vos utilisateurs vers le changement."

Enfin, le développement incrémentiel nécessite discipline et cohérence pour garantir que la qualité du logiciel s'améliore progressivement. Stef explique : "Finalement, vous ne pouvez pas éviter de tout renouveler. Le développement logiciel d'il y a 20 ans n'est pas comparable à aujourd'hui, et les frameworks et plateformes utilisés deviennent obsolètes. Parfois, nous choisissons de ne refactorer qu'un module existant. Nous le faisons si le code existant est suffisamment proche de notre architecture cible. Si la qualité du code est insuffisante ou trop éloignée de l'architecture prévue, nous devons le réécrire. Finalement, nous renouvellerons tout de cette manière, mais cela se fera progressivement."

L'avenir de Xpert Suite
Xpert Suite est en plein développement. Stef parle de l'avenir : " Nous obtenons de plus en plus de services de domaine autonomes. Un service de domaine comprend le fonctionnement d'un domaine fonctionnel entièrement délimité, du backend au frontend. Cela rend les différentes parties fonctionnellement et techniquement plus petites et le logiciel est gérable indépendamment les uns des autres. Cela signifie que nous pouvons effectuer des mises à niveau plus rapidement et plus facilement, sans que cela n'affecte le reste du système. Ainsi, la vitesse de développement reste élevée et nous pouvons continuellement maintenir et développer notre package. 

Conclusion : à quoi les organisations doivent-elles faire attention chez leur fournisseur de logiciels
Grâce au choix du développement progressif, nous avons des clients qui peuvent utiliser le même logiciel depuis 15 ans, sans grandes migrations et tout le travail que cela implique. En même temps, ils peuvent utiliser de nouveaux modules d'IA et des logiciels qui sont entièrement à jour et utilisent les derniers frameworks.

Stef conseille aux organisations de bien examiner la réputation et l'approche d'un fournisseur de logiciels, surtout si le logiciel soutient le processus principal de leur entreprise. " Il est important de s'assurer que votre fournisseur est capable de renouveler et de maintenir le logiciel à long terme. Trop souvent, nous voyons des entreprises faire un choix basé sur la fonctionnalité actuelle et le prix, sans prêter attention au long terme ", dit Stef. "La question 'Voyons-nous encore ce fournisseur bien performer dans cinq ans ?' n'est pas toujours posée. Et alors, ce qui est bon marché peut coûter cher, car un grand projet de migration est nécessaire. "
Que devraient alors demander les organisations à un fournisseur ? "Le plus important est de demander comment la gestion du cycle de vie du logiciel est organisée. Et bien sûr, de s'intéresser au bilan prouvé dans ce domaine. Si un fournisseur a déjà opté pour une reconstruction, il est important de poser plus de questions à ce sujet ", déclare Stef.

Contact La Xpert Suite est un portail innovant, axé sur les données, pour la santé au travail et la sécurité sociale. Le portail est destiné aux employés, aux gestionnaires, aux professionnels des ressources humaines, aux médecins du travail, aux mandataires et aux assureurs. Chaque utilisateur reçoit un accès personnalisé qui est entièrement adapté à ses besoins spécifiques. Vous souhaitez en savoir plus sur la Xpert Suite ? Contactez-nous.