Nous sommes une petite société d'administration d'avantages sociaux très spécialisée avec une collection de logiciels extrêmement utile et robuste, certains écrits en COBOL mais la plupart en BASIC. Deux consultants à plein temps ont entretenu et amélioré ce système en plus de 30 ans. Inutile de dire qu'ils prendront bientôt leur retraite. (L'une d'entre elles espère désespérément prendre sa retraite depuis plusieurs années, mais elle est fidèle à une faute et persiste donc malgré l'insistance de son mari pour que le golf soit prioritaire.)

Nous avons commencé la conversion vers un système développé par l'une des trois seules entreprises du pays qui offrent le type de logiciel que nous utilisons. Nous pensons maintenant que, bien que cette entreprise soit théoriquement capable d'achever le processus de conversion, elle n'a pas les ressources pour le faire en temps opportun, et nous en sommes venus à croire qu'elle ne sera pas en mesure d'offrir le type de service dont nous avons besoin pour fonctionner notre affaire. (Il n'y a rien de tel que de pouvoir fixer ses propres priorités et avoir le pouvoir d'allouer ses ressources comme bon lui semble.)

Le matériel n'est pas un problème - nous pouvons émuler très efficacement sur des serveurs modernes. Si COBOL et BASIC étaient des langages modernes, nous serions prêts à prendre le risque de trouver des remplaçants pour nos consultants actuels.

Il semble qu'il devrait y avoir un modèle commercial pour une entreprise de support informatique qui se concentre sur des plates-formes héritées comme celle-ci et fournit le talent de programmation et de développement logiciel pour soutenir un système comme le nôtre, éliminant de nos dos les risques de trouver le bon talent de programmation et le travail de convaincre les jeunes programmeurs qu'ils peuvent avoir une carrière productive et enrichissante, en partie dans un vieux langage non sexy comme BASIC.

En bref, en tant que responsables non informatiques, comment gérer au mieux cette transition?

Il peut sembler "qu'il devrait y avoir un modèle commercial pour une entreprise de support informatique qui se concentre sur les plates-formes héritées comme celle-ci", mais personnellement, je pense que c'est juste un vœu pieux de votre part car cela "résoudrait" les défis auxquels vous êtes confronté en un abattre en plein vol.

Rester coincé dans des environnements anciens n'est pas la voie à suivre. Et pour ma part, je ne parierais pas la vie d'une entreprise à essayer de rester coincé en trouvant une entreprise qui, pour l'instant, serait prête à faire ce que vous ne pouvez apparemment pas faire.

Ce n'est donc pas une réponse à la question que vous avez posée, mais des conseils sincères sur la façon d'avancer tout en minimisant les risques de migration.

Lire "Comment survivre à une réécriture de fond en comble sans perdre la raison"

Ne commettez pas l'erreur d'un long projet de migration sans réel résultat pendant longtemps. Lire "Comment survivre à une réécriture de fond en comble sans perdre la raison"

Je ne saurais trop insister sur la façon dont les conseils de cet article m'ont aidé à résoudre / aborder des problèmes similaires après m'être brûlé en faisant ce genre de projets à l'ancienne.

Configurer des tests automatisés

Si vous ne l'avez pas déjà mis en place (pourquoi jamais?), Demandez à vos programmeurs actuels de créer un faisceau de test automatisé pour vos applications.

La suite de tests automatisés devrait couvrir tous les domaines fonctionnels de vos applications. Il documenterait les spécifications de travail actuelles dans les règles "when_X_then_Y" des cas de test individuels. Cela aidera à la fois à empêcher les modifications de votre code actuel de casser les fonctionnalités existantes et à prendre en charge toute migration vers un nouvel environnement.

Comme vous traitez avec COBOL et BASIC, la suite de tests devrait probablement être au niveau des tests d'intégration: travailler sur un ensemble "fixe" de fichiers d'entrée / bases de données et vérifier les fichiers de sortie / le contenu de base de données modifié de programmes spécifiques (COBOL) et / ou applications. Pour les parties BASIC de votre logiciel, cela peut signifier ajouter des paramètres de ligne de commande pour leur permettre d'exercer certaines fonctions sans intervention (G) UI, ou obtenir un outil de test automatisé basé sur (G) UI.

Isoler les calculs et autres algorithmes

Même Cobol prend en charge la notion de sous-programmes appelables à partir d'un programme principal. Isolez tous les calculs d'importation et autres algorithmes dans des programmes ou modules distincts. Le but est de créer une bibliothèque de programmes / modules / tout ce qui fait le travail de grognement isolé de tout ce qui rassemble les entrées et crée les sorties.

Adaptez le faisceau de test pour les tester à la fois dans vos anciennes applications et de manière isolée. Cela garantira que le travail que vous effectuez sur l '"ancien" code pour faciliter la migration vers un nouvel environnement introduira le moins d'erreurs possible.

Lancer un nouvel ensemble d'applications dans un environnement "actuel"

Ne convertissez pas votre code actuel. Convertir une langue en une autre signifie imposer les contraintes de l'ancien environnement au nouveau. Le résultat est souvent moins que souhaitable (lire: le résultat sera terrible et une douleur à maintenir). Émigrer. Prenez le temps de configurer vos applications dans le nouvel environnement d'une manière considérée comme la meilleure pratique pour cet environnement.

Obtenez de nouveaux programmeurs, bien familiarisés avec l'environnement de votre choix, pour le faire. Faites-en une priorité dès le premier jour pour isoler tous les calculs et algorithmes importants dans des classes et / ou des packages séparés et les cacher derrière les interfaces. Utilisez l'injection de dépendance (le type d'injection de dépendance DIY le moins cher fera l'affaire) pour indiquer à votre nouvelle application les classes à instancier / utiliser pour effectuer les calculs.

C'est de toute façon un bon moyen de faire les choses et dans votre cas, cela vous permettra de migrer ces parties importantes au cas par cas. Il masquera également les subtilités de l'appel des programmes de base et / ou cobol des fonctions d'appel dans le nouvel environnement.

N'allez pas plus loin que la configuration des applications et peut-être la configuration de la fonction d'entrée / sortie la plus importante qui utilise un calcul de votre "bibliothèque" COBOL / BASIC.

Intégrez votre "bibliothèque" COBOL / BASIC

Découvrez comment appeler votre "bibliothèque" COBOL / BASIC à partir de votre nouvel environnement. Cela peut impliquer la configuration de fichiers de paramètres ou de tables de base de données, l'exécution d'un programme COBOL / BASIC qui encapsule la bibliothèque COBOL / BASIC que vous avez configurée précédemment. Si vous avez de la chance, votre version de BASIC peut permettre la création de DLL pouvant être appelées directement.

Implémentez la classe dans votre nouvel environnement qui appellera la "bibliothèque" COBOL / BASIC et testez-la en utilisant les mêmes tests que ceux qui se trouvent dans le faisceau de test de l'ancien environnement, mais maintenant sous la forme de tests unitaires dans le nouvel environnement .

Oui, cela signifie "dupliquer" les tests, mais c'est un filet de sécurité dont vous ne voulez pas vous passer. Ne serait-ce que parce que ces tests unitaires serviront plus tard de tests pour vérifier l'implémentation de vos calculs et algorithmes lors de leur migration vers votre nouvel environnement.

Mais encore une fois: n'allez pas plus loin que l'ajout des tests unitaires pour les calculs utilisés par le plus important de l'étape précédente.

Développer les nouvelles applications dans les itérations

Développez les nouvelles applications en répétant les deux étapes précédentes pour toutes les fonctions de vos anciennes applications. Continuez à ajouter ces tests unitaires qui vérifient les calculs au faisceau de test de vos nouvelles applications. Utilisez la suite de tests d'intégration pour vérifier que les fonctions migrées fonctionnent de la même manière que vos anciennes applications.

Migrer la bibliothèque principale en itérations

Et enfin migrez les calculs et algorithmes dans votre "bibliothèque" COBOL / BASIC, en les réimplémentant dans votre nouvel environnement. Encore une fois, faites-le de manière itérative en utilisant les tests (unitaires) pour garder votre santé mentale.

Il semble que cette application soit «essentielle» à votre entreprise. Dans les cas où un système ou un processus est ce qui EST votre entreprise, c'est un cas pour avoir votre propre solution personnalisée.

Vous y avez fait allusion. Malheureusement, étant donné le temps que vous avez passé depuis la mise à jour de vos technologies, ce sera une entreprise extrêmement difficile.

Je recommanderais l'un des deux itinéraires.

1. Dotez un groupe informatique de développeurs / chefs de projet / QE / opérations et développez votre système de manière incrémentielle, comme indiqué dans la réponse plutôt technique ci-dessus. Ce sera cependant exceptionnellement cher.
2. Plutôt qu'un fournisseur standard, recherchez un consultant en développement personnalisé qualifié. Ce groupe gérera toutes les ressources pour développer votre nouveau système, puis vous pourrez le faire entrer en interne avec un petit personnel que l'option 1 pour continuer. Cette option présente un ensemble de risques différent, cependant, la sélection d'un bon fournisseur peut être très difficile pour les non-techniciens. Ils peuvent également présenter un risque très élevé avec des dépassements de coûts, etc. Pour atténuer cet itinéraire, utilisez votre personnel existant pour créer un ensemble très détaillé d'exigences (du point de vue de l'utilisateur) pour votre offre. Demandez également des offres à prix fixe.

Bonne chance, vous avez environ 20 ans d'héritage à surmonter. Ce ne sera pas bon marché, facile ou propre.

Plutôt que de rechercher une entreprise pour maintenir votre logiciel hérité ou pour une entreprise de réécrire votre logiciel hérité, recherchez une entreprise pour fournir un service continu de système d'administration des avantages sociaux. Externaliser les problèmes de décision de réécrire ou non le logiciel, le calendrier à définir, la ou les langues ou les outils à utiliser.

Oui, les coûts évidents de cette approche peuvent dépasser les coûts évidents de l'embauche de nouveaux programmeurs mais, de votre propre aveu, vous êtes un responsable non informatique et il est facile de prévoir des scénarios dans lesquels vous prenez des décisions qui coûtent finalement votre entreprise plus cher que le coûts évidents de l'externalisation.