Le coût annuel d'un mainframe dans un budget défendable

Le coût annuel d'un mainframe n'est pas le montant d'une facture de matériel. Il empile des contrats, des mesures de capacité, des obligations de personnel, des frais d'exploitation et des provisions pour risque qui réagissent différemment quand la charge change. Regroupez-les dans un taux moyen et votre dossier de migration sera mauvais: les économies paraîtront miraculeuses ou la machine semblera impossible à quitter.

J'ai vu des analyses de coûts échouer parce que la finance demandait un prix unique par MIPS et que l'ingénierie en fournissait un. Les MIPS peuvent décrire une capacité relative de processeur, mais les principales factures logicielles ne sont pas simplement des MIPS multipliés par un tarif public. Un modèle utile part de chaque facture et contrat, identifie le facteur qui pilote chaque ligne, puis demande si le déplacement d'une charge modifie vraiment ce facteur.

Il n'existe pas de tarif universel honnête

Un budget annuel de mainframe exige des postes séparés, car chacun réagit à un événement différent. Un logiciel tarifé à la capacité peut suivre un pic mesuré sur quatre heures. La maintenance matérielle peut rester fixe jusqu'au retrait de la machine. Les dépenses de personnel ne changent que lorsque les responsabilités et les astreintes changent. Une allocation de datacenter peut rester comptabilisée après la libération de l'espace.

Séparez au minimum ces postes:

• Les logiciels tarifés à la capacité, notamment ceux dont le prix suit les MSU ou une autre mesure de capacité.
• Les logiciels fixes ou par paliers, dont les licences annuelles, le support et les produits tarifés par classe de machine ou environnement.
• L'achat ou la location du matériel, la maintenance, le stockage, le réseau et les périphériques.
• Les équipes, le support externe, les installations, la reprise après sinistre, les opérations de sécurité et la conformité.

N'allouez pas tous ces coûts aux applications avec le même dénominateur. La consommation CPU peut convenir à un logiciel et être absurde pour le stockage, un support externe ou un spécialiste qui passe son temps à coordonner les mises en production. Choisissez un facteur qui explique l'existence de la dépense: contribution au pic, stockage occupé, tickets traités, environnements utilisés ou effort dédié. Laissez un coût partagé non alloué si toute répartition inventerait une précision absente.

Le premier livrable doit être un registre des contrats, pas un grand total. Pour chaque ligne, notez le fournisseur, le produit, la durée, la date de renouvellement, la métrique de facturation, le minimum engagé, le palier actuel, la condition de résiliation et la source probante. Nommez un responsable capable de défendre l'interprétation. Une cellule intitulée «logiciels mainframe» ne dit pas quelle dépense baisse lorsqu'une charge déménage.

Les MIPS estiment la capacité mais reproduisent rarement la facture

MIPS signifie millions d'instructions par seconde, mais ce n'est ni une unité stable de travail métier ni la monnaie générale des factures IBM. Les mélanges d'instructions diffèrent. Les nouvelles générations de processeurs accomplissent davantage de travail utile pour une capacité nominale donnée. Les traitements batch riches en I/O, les transactions, la compression, Java et les bases de données sollicitent la machine autrement. Un nombre de MIPS sans source ni méthode de mesure est une étiquette, pas une preuve.

Les entreprises utilisent pourtant les MIPS pour planifier, car ils donnent une échelle familière. Certains fournisseurs les emploient aussi par tranches contractuelles. Le nombre reste donc pertinent, mais pas universel. Demandez si chaque valeur correspond à la cote d'une machine, à un usage observé, à un pic, à une moyenne ou à une tranche contractuelle. Ces valeurs ne sont pas interchangeables.

Le raccourci dangereux ressemble à ceci:

annual mainframe cost = total MIPS x assumed price per MIPS

Cette formule masque les engagements minimums, les paliers logiciels, les moteurs spécialisés, les machines de développement, le stockage et le personnel. Elle suppose aussi que le MIPS suivant coûte autant que le premier. Les contrats rendent souvent cette hypothèse fausse. Une petite hausse peut franchir un palier; une baisse modérée peut ne rien économiser tant que le plancher ou la tranche ne change pas.

Utilisez plutôt les MIPS comme contrôle de cohérence. Si un inventaire affirme qu'une application consomme la moitié du parc alors que les rapports issus de SMF montrent une part bien plus faible des processeurs généralistes, examinez le périmètre. L'estimation peut inclure du travail de base de données et de middleware affecté ailleurs, ou la mesure peut omettre des batchs soumis sous un autre identifiant. Ce débat est utile parce qu'il révèle les responsabilités. Multiplier un total MIPS incertain par un tarif tout aussi incertain ne fait qu'ajouter un symbole monétaire à l'incertitude.

La facturation MSU suit les mesures et les contrats

Une MSU, ou million service units, mesure une capacité employée dans la tarification des logiciels mainframe IBM. Elle est plus proche du mécanisme de facturation que les MIPS, mais elle n'est toujours pas un prix. Le montant dépend du produit, du modèle tarifaire, de la machine éligible, du contrat, du pays, du niveau engagé et de l'usage déclaré. Méfiez-vous de tout tarif universel par MSU.

Dans de nombreux accords en sous-capacité, les équipes suivent la moyenne glissante sur quatre heures, souvent nommée R4HA. Workload Manager enregistre la consommation de service et Sub-Capacity Reporting Tool transforme les données pertinentes en rapports servant à facturer les logiciels éligibles. La documentation SCRT d'IBM exige des données complètes et valides pour la période déclarée. Une période manquante ne prouve pas une charge gratuite. C'est un défaut de rapport qui peut influer sur son acceptation ou son calcul.

Le métier confond souvent trois valeurs:

• La demande instantanée indique aux exploitants ce qui se passe maintenant.
• Une moyenne glissante lisse cette demande sur la fenêtre définie.
• La valeur facturée applique les règles d'éligibilité et du contrat à la capacité déclarée.

Les confondre crée des économies imaginaires. Supprimer un job hors de la fenêtre de pic peut réduire les heures CPU et l'électricité sans modifier le prix du logiciel. Supprimer une charge pendant le pic peut encore ne rien changer si une autre devient le nouveau pic, si un minimum s'applique ou si le produit reste nécessaire sur la machine.

Construisez une vue des contributions au pic à partir des intervalles sous-jacents. Pour chaque produit et partition logique, enregistrez l'heure du maximum mensuel, les charges actives dans cette fenêtre, les MSU déclarées, le plancher ou palier contractuel et la prochaine limite économique inférieure. Testez ensuite le retrait de la charge sur toute la série temporelle. Ne soustrayez pas la moyenne MSU d'une application au pic déclaré. Les pics se déplacent.

Les moteurs spécialisés compliquent aussi le calcul. Une charge éligible sur zIIP ou une autre capacité spécialisée peut changer l'économie, mais ne supprime ni les logiciels voisins, ni le stockage, ni l'exploitation, ni la capacité de repli. Documentez les charges éligibles, leur lieu d'exécution réel et le comportement en cas de contention ou de bascule. L'éligibilité est une propriété technique; le résultat facturé est une propriété contractuelle. Il faut les deux.

La chaîne de reporting mérite sa propre réconciliation. Faites correspondre chaque central processor complex et LPAR aux identifiants des machines du rapport, puis chaque produit facturé aux emplacements où il est licencié et utilisé. Vérifiez que développement, test, reprise et production reçoivent le bon traitement tarifaire. Une LPAR absente de l'inventaire applicatif peut contribuer à la facture; une application répertoriée sur une LPAR peut ne pas employer le produit.

Conservez les enregistrements d'intervalle bruts des mois modélisés. Un maximum mensuel sans les intervalles voisins ne montre pas l'effet d'un job déplacé, terminé plus tôt ou lancé un autre jour. Pour la charge candidate, rejouez le calcul sur chaque intervalle en retirant seulement la consommation que vous pouvez lui attribuer. Recalculez la moyenne glissante et cherchez le nouveau maximum. Cela reste une estimation, car les règles des produits et contrats se placent au-dessus des données, mais elle vaut mieux que la soustraction d'une moyenne annuelle à un seul pic.

Ce rejeu révèle aussi le déplacement de charge. Supposons qu'une clôture produise le pic du mardi et qu'un envoi de relevés soit à peine inférieur le jeudi. Retirer la clôture ne produit pas une économie égale à toute sa contribution du mardi. Le jeudi devient le nouveau maximum; seule la différence entre les deux pics peut modifier le niveau mesuré. Si les deux restent dans la même tranche contractuelle, la facture immédiate peut ne pas changer.

Demandez au gestionnaire des actifs logiciels le droit d'usage et la facture, pas seulement la liste des produits des programmeurs système. Un produit installé peut être gratuit selon un accord, facturé dans une suite, soumis à un minimum ou inclus dans un contrat plus large. À l'inverse, un composant secondaire dans l'inventaire du code peut porter son propre support ou prix d'usage. Les clauses d'achat décident de ce qui peut être résilié; la découverte technique décide si la résiliation est sûre. Aucune équipe ne peut remplir seule la ligne.

La capacité de développement et de test demande un traitement séparé. Les équipes allouent souvent tout le coût hors production selon le CPU de production, alors qu'une application souvent livrée peut consommer bien plus de test que sa part de production. Notez les environnements dédiés, les produits qui doivent y être licenciés, la conservation des données de test et les droits actifs ou de secours en reprise. Une migration peut supprimer la charge de production tout en gardant une image de test pour l'historique des incidents, les demandes fiscales ou une bascule ultérieure.

Ne prenez pas les tarifs catalogue pour des factures. Ils peuvent expliquer la forme d'une métrique, mais les accords négociés, forfaits, plafonds et minimums déterminent la dépense réelle. Si l'accès aux contrats est restreint, placez le modèle sous les mêmes contrôles au lieu de le remplacer par une estimation publique. Une vue de direction expurgée peut montrer les catégories et dates de retrait, tandis que le détail contrôlé conserve fournisseurs et prix.

Les devises et périodes comptables peuvent également fausser les comparaisons. Normalisez les monnaies avec la méthode approuvée par la finance, rattachez le support prépayé à sa période et distinguez les taxes du revenu fournisseur si le dossier les traite autrement. Rapprochez les avoirs et ajustements ponctuels au lieu de choisir discrètement un mois favorable. La vue sur douze mois doit expliquer chaque différence notable entre valeur annuelle du contrat, factures payées et grand livre.

Enfin, attribuez un niveau de confiance à chaque affirmation, pas au classeur entier. Une clause de résiliation signée peut donner une forte confiance dans l'économie de licence. Une baisse du pic déduite d'étiquettes de charge incomplètes reste peu fiable jusqu'à une meilleure mesure. Une sortie matérielle dépendant de trois migrations futures est conditionnelle. Placez les preuves manquantes et leur responsable à côté de chaque ligne incertaine. Les décideurs acceptent l'incertitude quand ils voient sa source et le travail nécessaire pour la lever.

Le coût matériel dépasse le bon de commande

Il comprend l'achat ou la location, la maintenance fournisseur, les disques et bandes, le réseau, la capacité des installations, les pièces et le second site. Certaines entreprises possèdent le processeur et paient une maintenance croissante. D'autres renouvellent via un financement. La présentation comptable change, mais l'obligation de paiement garde une durée et une condition de sortie.

Une mise à niveau du processeur peut faire passer le logiciel à une tranche supérieure alors que la charge métier change peu. Inversement, déplacer la charge peut ne créer aucune économie pendant le bail ou si une configuration réduite viole les exigences de résilience. Séparez l'amortissement comptable de la trésorerie évitable. L'amortissement peut continuer après la décision; un renouvellement de maintenance peut être évité.

Les installations exigent des données mesurées, pas du folklore. Utilisez l'électricité mesurée si possible, les frais contractuels de surface et de cage, l'allocation du refroidissement, les interventions sur site et la reprise. Ne placez pourtant pas l'énergie en tête du dossier. Dans beaucoup de parcs, les logiciels et les compétences rares dominent. L'énergie compte surtout si le départ permet de fermer ou réduire réellement un engagement immobilier.

Notez la première date de retrait pour chaque coût physique. Si la machine héberge douze systèmes et que vous en migrez un, ni le châssis, ni la maintenance, ni le site de reprise ne changent forcément. Voilà pourquoi l'économie d'une application diverge souvent de la trésorerie du parc.

Le spécialiste coûteux assume souvent plusieurs métiers

Le coût humain ne se calcule pas en comptant les développeurs COBOL et leurs salaires. Les personnes difficiles à remplacer couvrent souvent le contrôle de production, JCL, les ordonnanceurs, RACF, CICS ou IMS, la reprise Db2, la performance, le stockage, les livraisons, les incidents et des connaissances jamais documentées. Un nom dans l'organigramme peut cacher cinq rôles opérationnels.

Décomposez le personnel par capacité. Pour chacune, notez le titulaire, le remplaçant, l'effort hebdomadaire prévu, l'astreinte, la dépendance externe et le système qui l'exige encore. Vous révélerez le risque de concentration sans inventer une valeur financière pour le «savoir tribal». Vous éviterez aussi de comptabiliser un salaire entier comme économie alors que la personne exploitera le remplacement, soutiendra une autre charge ou restera jusqu'au retrait.

Traitez pareillement les prestataires et forfaits fournisseurs. Un forfait peut être résiliable seulement au renouvellement. Un spécialiste peut couvrir plusieurs applications. Un infogérant peut facturer une équipe minimale ou une tour de services. Lisez le contrat de service et le préavis avant de déclarer un montant variable.

Je déconseille de prendre le coût d'un recrutement de remplacement comme coût humain annuel du mainframe. L'approche plaît parce que le risque de retraite existe et qu'un recruteur peut fournir un chiffre élevé. Elle est fausse parce qu'une embauche d'urgence hypothétique n'est pas la dépense actuelle. Gardez deux colonnes: trésorerie récurrente du personnel et exposition chiffrée de transition ou de résilience. Un conseil peut décider avec les deux; il ne peut auditer une prime de peur mélangée.

Ne supposez pas que la migration supprime immédiatement ces personnes. Leur savoir gagne en importance pendant les tests de parité et la bascule. Ensuite, le meilleur choix peut être de les garder comme responsables du domaine tout en supprimant l'astreinte liée à l'ancienne infrastructure. L'économie peut venir de contrats non renouvelés, d'une astreinte réduite ou de postes non remplacés plutôt que de licenciements.

Chaque ligne de la facture d'une charge exige une preuve

Une facture défendable rattache chaque montant alloué à une source et qualifie son comportement. Commencez par douze mois de factures et de rapports afin de conserver clôture annuelle, pic saisonnier et support annuel. Rapprochez le total du grand livre avant d'affecter un centime aux applications.

Employez un tableau de cette forme:

cost_id,annual_cash,billing_driver,contract_floor,renewal_date,workload_share,removal_trigger,evidence
SW001,REDACTED,product_peak_msu,REDACTED,YYYY-MM-DD,measured,lower_tier_at_renewal,SCRT_report
HW004,REDACTED,fixed_lease,full_term,YYYY-MM-DD,shared,lease_end,signed_contract
LAB007,REDACTED,dedicated_effort,none,YYYY-MM-DD,time_study,role_reassigned,staffing_plan

Masquez les montants dans les exemples, mais exigez les valeurs réelles dans le modèle contrôlé. La colonne utile est removal_trigger. Elle force l'analyste à nommer l'événement qui change la trésorerie: palier inférieur accepté au renouvellement, licence résiliée, bail terminé, machine retirée, support réduit ou poste non remplacé. «Application migrée» suffit rarement.

Classez ensuite chaque ligne parmi quatre comportements: évitable avec cette charge, évitable seulement après le départ d'un groupe, fixe jusqu'à une date, ou conservée après migration. Calculez deux fois. La vue charge montre la consommation économique; la vue trésorerie montre les factures et salaires réellement modifiés. Les deux sont légitimes, mais seule la seconde finance le dossier.

Un calcul simple rend l'écart visible:

run-rate allocation = annual cash x workload share
year-1 cash saving = annual cash x removable share x active fraction of year
net year-1 effect = year-1 cash saving - migration cash cost - overlap cost
steady-state saving = terminated and resized annual obligations

Ne placez pas la réduction de risque estimée dans les économies de trésorerie. Suivez le risque d'arrêt, l'effort d'audit, la complexité de reprise et la concentration des compétences comme facteurs de décision avec responsables et preuves. Si vous les monétisez, exposez séparément probabilité et impact.

Avant approbation, demandez à la finance, aux opérations de plateforme, aux achats et au responsable applicatif de signer les lignes qu'ils comprennent. Les achats trouvent les pièges de renouvellement. Les opérations trouvent les dépendances partagées. Le responsable trouve les batchs et interfaces absents. La finance empêche une allocation de passer pour une dépense supprimée.

Une migration ne supprime un contrat qu'après ses dépendances

Une migration peut supprimer licences applicatives, demande de capacité, croissance du stockage, fenêtres batch, couverture des spécialistes et engagements matériels. Chacun disparaît à une date différente. Une prévision sûre utilise une échelle de dépendances, pas un pourcentage du parc entier.

Cartographiez d'abord tout le périmètre: transactions, jobs planifiés, transferts, impression, procédures de base, règles de sécurité, scripts d'exploitation, rapprochements et consommateurs aval. Déplacer un frontal alors que le registre reste dans Db2 ne supprime ni la base ni son exploitation. Réécrire un batch qui soumet encore trois jobs JCL de clôture ne supprime pas l'ordonnanceur.

Identifiez ensuite le seuil de coût résiduel de chaque ressource partagée. Un produit disparaît seulement quand sa dernière charge quitte la LPAR. Les bandes peuvent rester pour la rétention réglementaire. La machine de reprise peut être dimensionnée sur le plus grand service restant. Les circuits peuvent servir d'autres systèmes. Une séquence de portefeuille peut donc créer plus de valeur qu'un choix fondé uniquement sur le coût apparent.

Planifiez enfin le travail d'arrêt. Archivez selon la règle approuvée, retirez identités et jobs, stoppez les flux, prouvez la reprise du remplacement, mettez à jour les procédures, envoyez les préavis et éliminez correctement le matériel. Une charge sans trafic peut encore coûter et échouer à un audit.

CodeHero réécrit tout le code ancien en Go, Rust et TypeScript, puis vérifie le comportement par un harnais de parité face au trafic de production enregistré. La livraison peut ainsi tenir en moins de 30 jours, mais les préavis, la rétention et les dates de sortie des services partagés déterminent encore quand le coût annuel baisse.

Plusieurs coûts survivent sur la nouvelle plateforme

La migration change la structure des coûts, elle ne supprime pas l'ingénierie de production. Le remplacement exige calcul, bases, stockage, observabilité, sauvegardes, sécurité, support, gestion des incidents, reprise et personnes connaissant les règles métier. Mettre ces postes à zéro relève de la plaidoirie, pas de l'analyse.

Les factures cloud demandent la même discipline. Séparez capacité de base, pointes, base gérée, transfert réseau, rétention des sauvegardes, hors-production et support. Ne comparez pas un coût mainframe complet à une simple estimation de machines virtuelles. Incluez l'exploitation parallèle pendant la vérification et le stockage temporaire des transferts.

Certaines tâches deviennent moins chères grâce à un marché du travail et des outils plus courants. D'autres se déplacent. La politique RACF devient politique d'identité et d'accès. La surveillance SMF peut devenir journaux, métriques et traces. Sauvegarde et reprise Db2 deviennent celles de Postgres. Nommez le nouveau responsable de chaque contrôle avant de retirer l'ancien.

La marge de performance demeure aussi. Les mainframes gèrent des charges mixtes transactionnelles et batch avec des contrôles mûrs. Le remplacement doit tenir latence, débit, fenêtre de clôture et reprise observés sous une demande réelle. Dimensionnez-le avec les traces de production et les tests, pas avec le nombre de lignes source. Moderniser l'architecture peut réduire le gaspillage, mais le budget doit retenir la capacité prouvée.

Fixez la référence avant de demander des offres. Figez le périmètre du parc, les douze mois et le traitement des services partagés. Listez tout renouvellement de processeur, contrat, déménagement ou changement d'effectif prévu sans migration. Sinon le projet s'attribue des économies déjà prévues ou subit une hausse que la plateforme actuelle aurait aussi connue.

Présentez au moins trois vues temporelles. La vue engagée contient les obligations encore fixes. L'année de sortie reflète les résiliations partielles et le parallèle. Le régime stable commence après la fin de l'ancienne production, de la reprise, de la rétention et du support. Datez chaque vue. Un chiffre annuel sans calendrier suppose discrètement que toute économie débute le premier jour.

Pilotez la sortie par des jalons plutôt que par une date de bascule optimiste. La bascule du trafic en est un. La sortie financière peut aussi exiger un cycle complet, des résultats rapprochés, un test de reprise accepté, la fin du délai de retour, des données archivées, les accès retirés, le service accepté et le préavis reçu. Donnez à chaque jalon un responsable et une preuve. S'il glisse, le modèle doit déplacer l'économie associée.

La période de parité a besoin de son propre budget. Les deux plateformes peuvent traiter les mêmes cas enregistrés ou réels pendant que les équipes comparent les résultats, analysent les écarts et prouvent l'exploitation. Comptez le calcul et le stockage en double, les extractions, les tests, les corrections et les personnes qui acceptent l'équivalence. Ne cachez pas cette dépense temporaire dans un pourcentage de contingence; rattachez-la au plan de vérification et aux cycles attendus.

Définissez une règle pour les exceptions restantes. Un remplacement qui traite presque tout mais renvoie les cas rares au mainframe conserve la dépendance qui bloque l'arrêt. Comptez leur fréquence, trouvez la règle métier et choisissez de l'implémenter, de la retirer avec approbation ou d'exécuter un processus manuel borné. Un repli indéfini peut maintenir toute une chaîne de licences et de support.

Après la bascule, comparez les factures aux prévisions pendant plusieurs cycles. Confirmez que pics déclarés, paliers, volumes de support, stockage, circuits et prestataires ont changé comme prévu. Fermez les commandes et renouvellements automatiques plutôt que d'attendre qu'un service inutilisé cesse de facturer. Notez l'écart par ligne afin que la migration suivante repose sur le comportement observé, pas sur un autre pourcentage générique.

L'approbation finale doit nommer le propriétaire des coûts résiduels. Si une application part mais qu'un produit partagé reste, l'économie ne peut apparaître dans son dossier puis de nouveau dans celui du parc. Tenez un registre central des montants revendiqués, réalisés et encore résiduels. Il évite le double comptage et aide à grouper les prochaines charges autour des dépendances coûteuses.

La décision repose sur la trésorerie supprimable et une date

Le dossier d'investissement doit montrer trois totaux: la dépense annuelle actuelle, le régime stable du remplacement et la trésorerie de transition. Ajoutez un calendrier des obligations qui prennent fin. Les économies retardées deviennent visibles et le chevauchement de la première année ne disparaît pas dans un chiffre annualisé.

Testez les hypothèses capables d'inverser la décision: pic logiciel inchangé, bail impossible à rompre, produit conservé pour une autre application, capacité de remplacement supérieure, rétention plus longue et période parallèle supplémentaire. Si le dossier ne marche que lorsque tous les coûts partagés disparaissent le jour de la bascule, il ne marche pas.

La décision n'est pas uniquement financière. Un parc peut justifier une migration parce que les délais de changement, le risque de reprise ou la concentration des compétences bloquent l'activité, même si l'économie de première année reste modeste. Dites-le clairement. Ne cachez pas des raisons stratégiques dans des coûts évités inventés.

Ouvrez le dossier d'approbation avec le registre des contrats, la vue des pics fondée sur SCRT, la carte des capacités, le périmètre des charges et le tableau des déclencheurs de retrait. Ces cinq éléments donnent aux directions technique et financière une base contestable. Quand chaque économie a un responsable, un déclencheur et une date, le coût annuel cesse d'être une dispute fondée sur le folklore des MIPS et devient un plan exécutable.