Le titre fait deux revendications :
- La modernisation de l'ordinateur central est difficile.
- La modernisation de l'ordinateur central est amusante.
Mon but dans cet essai est de justifier ces affirmations. Si je réussis, j'espère persuader un petit nombre de gens techniques qui sont encouragés — plutôt que découragés — par d'énormes difficultés à nous rejoindre dans notre quête.
Pour commencer, je devrais expliquer de quoi je parle.
Lorsque vous pensez à un ordinateur central, vous imaginez probablement un terminal monochrome à écran vert. Depuis plus de quarante ans, ce texte brillant de phosphore est le battement constant de la finance mondiale.
Essentiellement, la modernisation de l'ordinateur central consiste à convertir une application logicielle ou une suite d'applications fonctionnant sur un ordinateur central en un système distribué moderne, tout en préservant le comportement, la justesse et les garanties opérationnelles.
Qu'est-ce qu'un ordinateur central? Par IBM, le plus grand fournisseur d'ordinateur central, -[ils] sont des serveurs de données qui sont conçus pour traiter jusqu'à 1 trillion de transactions web quotidiennement avec les plus hauts niveaux de sécurité et de fiabilité. Malgré l'essor du cloud computing, les ordinateurs centraux continuent de jouer un rôle essentiel dans l'infrastructure informatique, en particulier dans les industries plus traditionnelles qui ont un volume important de transactions critiques.
Sur la base d'un récent rapport d'IBM, 45 des 50 premières banques, 4 des 5 premières compagnies aériennes, 7 des 10 premiers détaillants mondiaux et 67 des sociétés Fortune 100 utilisent l'ordinateur central comme plate-forme de base. Lorsque vous faites glisser une carte de crédit à Londres ou retirez des pesos à Bogota, vous interagissez avec ces machines.
Pourquoi
Alors, pourquoi se moderniser ? Si les ordinateurs centraux sont si bons, pourquoi s'éloigner d'eux ? Les organisations prétendent avoir diverses raisons. Mais si vous vous tenez dans une salle d'opérations d'une grande banque aujourd'hui, vous verrez que cela se résume à deux points fondamentaux:
- Agilité. Le nombre de personnes qui connaissent encore le COBOL et les infrastructures bancaires de 40 ans diminue rapidement. Il est donc dangereux de modifier ces programmes, ce qui entraîne le gel de certaines parties d'une entreprise à temps. Une entreprise qui stagne finit par mourir, et donc l'agilité est l'antécédent à la survie.
- Coût. IBM détient un quasi-monopole sur le marché de l'ordinateur central. L'exploitation d'un seul ordinateur central peut coûter des millions de dollars par année. Bien qu'il ne s'agisse pas d'une rupture de marché pour tout le monde, de nombreuses entreprises s'écarteraient des contrats IBM coûteux s'il existait une voie claire et à faible risque pour le faire.
Ainsi, même s'il n'y a rien de mal avec les ordinateurs centrauxen soi, les conditions du marché et l'état du monde créent de forts vents arrière pour la modernisation loin d'eux, avec le marché de modernisation de l'ordinateur principal estimé à des centaines de milliards de dollars.
La modernisation de l'ordinateur central est difficile
La modernisation de l'ordinateur central est un problème terriblement difficile, car il s'agit d'une fusion de certains des problèmes les plus difficiles dans tous les domaines de l'informatique et du génie logiciel, tous à la fois.
Nous devons traiter simultanément des questions telles que l'état partagé implicite, le flux de contrôle non documenté, les limites transactionnelles non évidentes, les cas de bords numériques accumulés depuis des décennies et les garanties de cohérence distribuées que l'ordinateur central fournit implicitement. Les systèmes distribués ne le font pas.
C'est la réalité de l'héritage de l'écran vert : la modernisation Mainframe s'attaque à des décennies de dettes technologiques dans une langue que personne ne connaît (COBOL), écrite avant l'avènement de l'ingénierie logicielle moderne et de la programmation orientée objet. Les modèles sont absents, la documentation est douloureusement incomplète.
Considérez quelque chose d'aussi simple que les chiffres.
COBOL utilise généralement des formats décimals emballés comme COMP-3, qui codent l'arithmétique base-10 directement en mémoire pour garantir une précision exacte. Si vous migrez cette logique vers un type de point flottant cloud-natif, vous avez subtilement changé le comportement mathématique du système. Les flotteurs IEEE 754 sont des approximations de base-2, et des valeurs comme 0,1 ne peuvent pas être représentées exactement. Bien que chaque écart individuel soit minime, dans un système bancaire plus de millions de calculs quotidiens, l'erreur se compose.
Le système commence à créer ou à détruire involontairement de l'argent.
En théorie, et dans la pratique à cette échelle, aucune analyse statique ne peut pleinement caractériser le comportement d'un système aussi grand et vieux. Il y aura toujours des comportements qui ne se révèlent que sous les entrées réelles, les données réelles et le timing réel.
L'application cible doit capturer avec précision le "Ghost" dans le Shell de l'ordinateur central, y compris souvent ses défauts et bogues. Les applications en aval pourraient gérer des bogues connus de manière idiosyncratique, et la correction de ces bogues connus peut conduire à des catastrophes imprévues de second ordre et plus.
Comme nous l'avons mentionné dans notre billet sur l'effet Lindy, l'histoire est jonchée d'échecs à grande échelle de la modernisation traditionnelle axée sur l'homme. Nous devons nous efforcer de faire mieux.
Résoudre le problème difficile (est amusant)
Pour se moderniser en toute sécurité, nous devons démontrer – avec précision mathématique – que notre nouveau système se comporte exactement comme l'ancien. Pour cela, il faut créer une suite de tests fonctionnels sophistiqués qui reflète parfaitement la réalité.
Pour cela, nous devons considérer deux objectifs :
- La vue client : Pour toutes les entrées de production, le système cible génère-il exactement la même sortie que la source ?
- The Engineering View: Pouvons-nous écrire la suite de test d'une manière qui crée une spécification claire et compréhensible pour les agents d'IA à partir de laquelle créer l'application cible?
Un humain peut raisonner sur une voie d'exécution à la fois. Ce problème exige un raisonnement d'environ des millions de personnes. L'espace d'état est trop grand, les interactions trop subtiles, et la boucle de rétroaction trop lente pour l'intuition humaine seule. Ce qu'il nous faut, ce n'est pas plus de code d'écriture de mains, mais un système qui peut explorer les possibilités, absorber les contraintes, et itérer à une vitesse aucune équipe d'humains ne peut correspondre. Mais ce système est seulement aussi bon que la réalité, il est contraint d'obéir.
La frontière
C'est la frontière où le rôle de l'ingénieur passe du code d'écriture à la conception des contraintes qui définissent la réalité.
Chez Hypercubic, nous croyons que c'est la capacité de limiter la réalité pour l'IA agentique qui est la compétence déterminante de la prochaine décennie d'ingénierie logicielle.
Nous découvrons encore la bonne façon de construire ces contraintes. Il nécessite un raisonnement sur les invariants de haut niveau comme la préservation de l'équilibre, tout en traçant des comportements de bas niveau comme les commandes de fichiers I/O ou les relevés de transaction. Il couvre l'analyse de code statique, les graphiques de flux de données dynamiques et les transactions de commande sur les systèmes distribués massivement.
La plupart des logiciels d'ingénierie d'aujourd'hui implique de coller ensemble des API bien documentées ou des boutons mobiles sur un écran. C'est un travail prévisible et sûr.
La modernisation de l'ordinateur central est le contraire. Il faut s'engager directement avec les fondements chaotiques et sans papiers de l'économie mondiale.
Nous atteignons enfin derrière cet écran vert brillant pour tirer la logique à la lumière du 21ème siècle.
Si l'idée de résoudre des problèmes qui sont théoriquement impossibles mais pratiquement nécessaires vous fait appel, nous voulons vous rencontrer.