Une migration certifiée par les tests pour les parcs de code SAS d'entreprise
Votre parc SAS fonctionne. Des milliers de programmes, de macros, de formats et de traitements planifiés ont été affinés au fil des années, et une grande part de ce qu'ils font n'est documentée nulle part ailleurs que dans le code lui-même. Déplacer cela vers une nouvelle plateforme, si compatible soit-elle, comporte un risque bien réel : quelque chose qui était juste devient subtilement faux, et personne ne s'en aperçoit avant que cela ne compte.
Jenner Professional Services élimine ce risque par une discipline simple. Avant de changer quoi que ce soit, nous constituons un relevé complet et exécutable de ce que fait votre système actuel. Nous utilisons ensuite ce relevé pour prouver, test après test, que le système migré fait la même chose.
Le résultat est une migration que vous pouvez valider sur des preuves plutôt que sur la confiance, et une suite de non-régression que vous conservez pour toujours.
Nous sommes experts de SAS, comme le démontre le fait d'avoir créé une implémentation complète de ce langage et de ce système. Mais migrer vers ce système n'est que l'une des voies que vous pouvez emprunter avec nous.
Nous pouvons mettre notre implémentation du code compatible SAS, et nos pratiques pilotées par les tests, au service d'une migration réussie vers Python ou R, vers Snowflake ou Databricks, ou vers d'autres solutions — y compris Siemens SLC.
Nous préconisons la migration vers Jenner parce qu'elle est à la fois plus rapide, moins complexe et moins coûteuse pour les entreprises qui disposent déjà d'une infrastructure SAS.
Jenner exécute le langage SAS, la quasi-totalité des procédures, le langage macro, les graphiques et un large éventail de connexions de données. Pour l'essentiel du code, migrer revient à pointer Jenner sur les mêmes programmes. Mais un parc de code d'entreprise ne se limite jamais au langage. C'est aussi tout ce que le langage touche :
autoexec.sas, fichiers de configuration, options système (ENCODING, LOCALE, YEARCUTOFF, VALIDVARNAME, FMTSEARCH, SASAUTOS), variables d'environnement, SYSPARM, ainsi que la taille et la durée de vie de la bibliothèque WORK.
Mots de passe intégrés aux instructions LIBNAME, chaînes encodées {SAS002}, identifiants présents dans les fichiers inclus par %include, tickets Kerberos ou SSO, et la question de savoir où tout cela devrait résider à la place.
Moteurs SAS/ACCESS pour Oracle, DB2, Teradata, SQL Server, Snowflake, Hive et d'autres ; SQL en pass-through explicite et implicite ; options de moteur qui influent sur les résultats (DBCOMMIT, READBUFF, INSERTBUFF, BULKLOAD) ; correspondance de types pour les dates, les décimaux et les NULL ; et les comportements qui ont changé sans bruit lorsque le SQL a été poussé vers la base plutôt qu'exécuté localement.
Chemins codés en dur, lettres de lecteur Windows face aux points de montage Linux, noms de fichiers sensibles à la casse, partages NFS et SMB, commandes FILENAME PIPE et X, SYSGET, et permissions de fichiers.
Catalogues de formats, macros compilées ou stockées, index, journaux d'audit, vues, bibliothèques SPDE, fichiers de transport, jeux de données chiffrés ou compressés, et jeux de données d'époque V6/V8 qui doivent être régénérés plutôt que copiés.
Blocs RSUBMIT de SAS/CONNECT, Grid, SAS/SHARE, Stored Processes, autorisation par le serveur de métadonnées, projets Enterprise Guide, traitements générés par DI Studio et actions CAS de Viya. Chacun a un équivalent sur la nouvelle plateforme, mais pas un équivalent identique.
LSF, Control-M, cron, dépendances entre traitements, conventions de codes retour, analyseurs de journaux qui recherchent un texte NOTE/WARNING/ERROR précis, logique SYSERR et SYSCC, et alertes FILENAME EMAIL.
Destinations ODS PDF, RTF, Excel et HTML, styles PROC TEMPLATE, tagsets, polices, pilotes de périphériques graphiques, et rapports que les consommateurs en aval analysent par position.
Arrondis en virgule flottante aux valeurs limites, collation de tri et ordre des ex æquo, flux de nombres aléatoires (RANUNI, RAND, STREAMINIT) non reproductibles d'une implémentation à l'autre, et procédures itératives dont le chemin de convergence peut différer dans la tolérance admise.
Variables non initialisées, remerging de PROC SQL, RETAIN implicite, avertissements de troncature considérés comme normaux, et comportements non documentés qui donnent aujourd'hui le bon résultat par accident.
Python via SASPy, R, clients Java et .NET via IOM, JDBC vers SAS/SHARE, Tableau et pandas lisant directement les fichiers .sas7bdat, et appels REST vers Viya.
Exigences de validation dans les secteurs réglementés (GxP, 21 CFR Part 11, gestion du risque de modèle), sécurité au niveau des lignes, traitement des données personnelles, journaux d'audit, et l'absence de gestion de versions dans bien des parcs SAS de longue date.
Aucun de ces points n'est inhabituel. Tous peuvent être identifiés à l'avance, et tous sont testables. C'est précisément l'objet du processus ci-dessous.
Nous inventorions le parc avant d'estimer la charge. Par une analyse automatisée de votre arborescence de sources, de vos ordonnancements et de vos journaux, nous produisons un graphe de dépendances des programmes, macros, formats, bibliothèques, fichiers externes et connexions aux bases, et nous identifions ce qui tourne réellement, ce qui est mort et qui en est propriétaire. Chaque catégorie ci-dessus est vérifiée et les constats sont notés selon l'effort de migration.
Un rapport d'inventaire et de risques accompagné d'une proposition à prix ferme pour les phases suivantes. Si vous décidez de ne pas poursuivre, le rapport vous reste acquis.
C'est la phase qui rend tout le reste fiable, et elle se déroule entièrement sur votre système SAS existant, avant toute migration.
Pour chaque programme concerné, nous construisons par analyse assistée par IA des tests de caractérisation : des spécifications exécutables de ce que le code fait aujourd'hui. Chaque test capture les entrées que consomme un programme — jeux de données, paramètres de macro, fichiers externes, extractions de bases, réglages d'environnement —, l'exécute sur votre installation SAS actuelle et enregistre tout ce qu'il produit : jeux de données de sortie, contenu du journal, codes retour, sorties ODS, état des variables macro, et effets de bord tels que fichiers écrits ou courriels envoyés.
C'est l'IA qui rend cela réalisable à l'échelle de l'entreprise. Lire dix mille programmes et déduire les cas limites que chacun traite n'est pas un travail pour des personnes soumises à une échéance. Produire les cas de test, les jeux d'essai et la logique de comparaison est exactement le type de travail volumineux et répétitif où les modèles actuels excellent, et chaque test généré est validé en l'exécutant contre le système qu'il décrit. Si un test ne passe pas sur votre SAS actuel, ce n'est pas un test de votre système et il est écarté.
Les règles de comparaison sont définies sortie par sortie. Les jeux de données sont comparés à l'identique par défaut ; des tolérances numériques sont déclarées explicitement là où la virgule flottante ou les procédures itératives rendent l'égalité bit à bit dénuée de sens ; les comparaisons de journaux sont structurelles plutôt que textuelles, si bien qu'une NOTE reformulée ne fait pas échouer un traitement alors qu'un nombre de lignes modifié, si. Les entrées non déterministes telles que la date du jour et les graines aléatoires sont maîtrisées, afin qu'un même test donne la même réponse n'importe quel jour. Lorsque les données de production ne peuvent pas servir aux tests, nous construisons des jeux d'essai masqués ou synthétiques qui empruntent les mêmes chemins de code.
Une suite de tests versionnée, à la couverture mesurée sur les programmes, les macros et les procédures, et une référence des résultats enregistrés depuis votre système actuel. Cette suite vous appartient. Elle est écrite pour s'exécuter sur Jenner, sur SAS et sur tout autre environnement qui parle le langage, et elle a de la valeur indépendamment de la migration : la plupart des parcs SAS n'en ont jamais eu.
Une fois la référence établie, la migration devient un exercice d'ingénierie assorti d'une définition claire de « terminé ». Nous déployons Jenner dans votre environnement, corrigeons les points d'environnement relevés en Découverte (chemins, bibliothèques, gestion des secrets, connexions aux bases, intégration à l'ordonnanceur) et exécutons la suite complète.
Chaque échec est classé dans l'une de quatre catégories :
Le code est correct et c'est Jenner qui a tort. Jenner livre de nouvelles versions chaque semaine ; les défauts découverts lors des migrations clients sont priorisés, et le test en échec rejoint définitivement la suite de non-régression de Jenner.
Un chemin, un identifiant, une connexion ou une option à régler. Corrigé et relancé.
Le code repose sur un comportement SAS non documenté. Nous vous montrons la ligne précise et le comportement précis, et vous choisissez entre modifier le code — le test prouvant que la modification est sans danger — ou faire en sorte que Jenner reproduise la particularité.
Le résultat diffère dans une tolérance déclarée, ou un message de journal est formulé différemment. Documenté et validé, jamais accepté en silence.
La suite est exécutée en continu à mesure que les problèmes sont corrigés : l'avancement est donc un chiffre et non une opinion, et les régressions sont détectées le jour même où elles sont introduites.
Un code migré dont la suite complète passe, ou dont chaque écart restant est tranché par écrit.
La certification est le dossier de preuves qui permet à votre sponsor, à vos auditeurs et à vos régulateurs d'accepter la migration.
Nous menons une période de fonctionnement en parallèle pendant laquelle les traitements de production s'exécutent sur les deux systèmes et les sorties sont comparées automatiquement selon les mêmes règles que la suite de tests. Le dossier de certification comprend l'inventaire, la suite de tests et sa couverture, la référence, les résultats de l'exécution finale, le traitement réservé à chaque écart, et la traçabilité de chaque exigence ou programme vers les tests qui le couvrent. Pour les clients réglementés, il est structuré pour soutenir une validation IQ/OQ/PQ et un audit.
Un dossier de certification signé et une recommandation go/no-go.
La bascule est planifiée autour de vos fenêtres de traitement par lots et de la date de renouvellement de votre licence SAS, avec un chemin de retour arrière testé. Les ordonnanceurs sont repointés, la supervision et les alertes sont confirmées, et l'environnement SAS est retiré selon votre calendrier.
La suite de tests continue de s'exécuter après la bascule. Comme Jenner livre chaque semaine, vous recevez chaque amélioration avec la même preuve que rien de ce dont vous dépendez n'a changé. Votre équipe est formée pour étendre la suite à mesure que le code grandit.
La production sur Jenner, un plan de retrait de SAS, et une suite de non-régression qui continue de travailler pour vous.
À prix ferme et de courte durée. Elle produit la proposition pour les phases suivantes, tarifée sur la taille et la complexité mesurées de votre parc plutôt que sur une estimation de celles-ci.
Livrées le plus souvent comme une mission unique à périmètre ferme, avec une réception par jalons adossée aux résultats de la suite.
Disponible en service annuel, une fois la suite de tests transmise et votre équipe formée pour l'étendre.
$1,000 – $21,000
Réalisables à distance dans la plupart des cas, pour une durée allant d'une semaine à un mois.
$52,000 – $405,000
Nécessitant une présence sur site et/ou une expertise métier avancée, pour une durée allant généralement de deux à six mois.
Tous les montants sont en dollars américains (USD).
Ces montants ne comprennent pas les frais de licence logicielle ; ceux-ci sont toutefois très simples et compétitifs. Voir la page des tarifs.
Contacter les services professionnelsEnvoyez-nous une description de votre environnement SAS — plateforme, nombre approximatif de programmes, produits utilisés, bases de données et ordonnanceurs — et nous cadrerons une mission de Découverte.