L’IBM i : un « Future System de niche » ou un système du futur ? - Lettre RePeGlio


A l’occasion du 25ième anniversaire de l’IBM i, nous pensons qu’il est nécessaire de revisiter l’histoire du S/38 car comme dit le proverbe: « si tu veux savoir où tu vas, regardes d’où tu viens ». Le système S/38 ancêtre de l’AS/400 et de l’IBM i, est l’héritier d’aucun système connu (voir schéma). D’où la question centrale : pourquoi le management d’IBM a-t-il eu l’idée saugrenue de créer de toute pièce en 1975 un système propriétaire totalement incompatible, encore aujourd’hui, avec les mainframes et les moyens systèmes, aussi bien ceux d’IBM que ceux de la concurrence?

Cette énigme *extrêmement intéressante* a aiguisé notre curiosité. Nous avons mené une enquête pour nos lecteurs de la lettre RePeGlio. Commençons par écarter l’explication de Frank Soltis, à laquelle nous avons cru un moment mais qui nous parait raccourcie.

Frank Soltis tente de justifier les singularités de l’AS/400 par l’isolement de la ville Rochester dans le Minnesota. Le laboratoire de Rochester, dit-il, n’avait pas réussi à embaucher des diplômés de la côte Est, de sorte que les créateurs du S/38 ne connaissaient rien à l’architecture des ordinateurs et sont partis de ce fait d’une conception radicalement nouvelle. Toujours selon Frank Soltis, le S/38 ne serait pas une décision du management d’IBM mais aurait été créé à partir d’un budget supplémentaire car, ajoute Frank Soltis, il est plus facile de se faire pardonner après coup que de demander.

Cependant, il existe une autre version sur l’origine du S/38. Un petit Flash-back comme au cinéma s’impose:
    Au début des années 70, IBM avait financé un projet gigantesque appelé « Future System ». Ce projet ultra stratégique avait été conduit par le vice-président d’IBM de l’époque John Opel. Ce qui avait justifié ce projet était l’avenir très sombre que les experts prédisaient aux mainframes. A l’époque, tous les experts (envieux ?) prétendaient que les mainframes d’IBM étaient des dinosaures qui seraient inéluctablement balayés par les systèmes plus simples et beaucoup moins couteux de la concurrence. Le « Future System» avait justement pour vocation de simplifier l’architecture des mainframes et diminuer les coûts de fonctionnement de façon drastique en partant de concepts révolutionnaires (qui vous sont familiers), dont:
    • « single-level store » espace adressable unique ou mémoire virtuelle afin d’accéder aux objets et à la base de données de façon uniforme en faisant abstraction de la notion d’adresse.
    • Base de données intégrée.
    • Utilisation des API afin de rendre le software indépendant de la technologie.
   
Le projet « Future System » fut interrompu en 1975. Ce système qui devait remplacer les mainframes était incompatible avec les mainframes System/370 alors en usage. En effet pour migrer vers « Future System » les clients auraient dû réécrire les applications. Les objectifs étaient trop ambitieux pour les processeurs de l’époque. Surtout, la fin des mainframes, régulièrement annoncée comme étant inéluctable, n’eut jamais lieu. Contre toute attente, non seulement les mainframes ne furent pas inquiétés par les concurrents, mais au contraire les clients demandaient à IBM seulement des investissements dans les systèmes existants, ce qui fut fait, et non une rupture technologique majeure. (Comme les clients S/36 qui demandaient eux aussi la continuité, il fut proposé finalement une émulation 36 avec l’AS/400).



En 1975, selon nous, le management d’IBM a dû statuer entre deux impasses. En effet, abandonner « Future System » c’était perdre les investissements et compromettre l’avenir d’IBM. Cependant réaliser « Future System » mainframe aurait pu déstabiliser le marché existant qui n’était pas demandeur. Selon nous le management d’IBM a tranché pour une solution de transition, à savoir construire un système simplifié (bridé ?) pour PME, qui ne ferait surtout pas d’ombre aux mainframes, mais qui mettrait réellement en œuvre les concepts d’avant-garde « Future System ». Cette solution alternative avait l’énorme mérite de garder la technologie de rupture vivante, avec pour avantage une capacité de réactivité en cas de retournement du marché (allez savoir ce que peuvent manigancer en secret les concurrents dans les laboratoires?).

Selon nous, le système S/38, connu sous le nom d’AS/400 et aujourd’hui IBM i, est issu du projet « Future System » tout simplement parce qu’il en revendique tous les concepts de base. De plus, notons que le Future System fut officiellement arrêté en 1975, date à laquelle le laboratoire Rochester a embauché des milliers de personnes des quatre coins d’IBM afin de créer la machine S/38 sortie en 1979. Comme par un « heureux hasard », la fin de l’un correspond au début de l’autre. Selon Gérard Dréan qui a travaillé au projet Future System, le S/38 n’est rien d’autre, je cite : « qu’un Future System de niche ».

Nous savons que le marché mainframe est surtout un immense marché captif de renouvellement. Les mainframes (hardware, services et stockage) représentaient en 2012 : 25% du chiffre d’affaires mais 40% des bénéfices d’IBM. Pas mal pour des systèmes dont l’architecture a été conçue dans les années 60 ! (avec d’énormes investissements cependant.) Nous comprenons pourquoi IBM souhaite brosser ce marché dans le sens du poil tout en gardant l’IBM i sous le coude (mais avec le risque de faire passer le S/38 et ses descendants pour une sorte d’épée de Damoclès suspendue au-dessus de la division la plus profitable, d’où peut-être les histoires à dormir debout du bon Docteur Soltis ?).

Dans le contexte des années 70, il était normal qu’une compagnie de la stature d’IBM investisse massivement en recherche et développement avec Future System pour contrer toute menace. Le retrait de Future System pour mainframe parait lui aussi fondé étant donné la stabilité tout à fait surprenante du marché mainframe. La création qui fait suite en 1975 du S/38 pour PME à partir des concepts Future System était audacieuse et avait du sens. Ce ne sont pas les clients IBM i qui s’en plaindraient. Ce fut rétrospectivement une décision pertinente.

Voici un simple avis d’un expert indépendant à prendre comme tel: si le Cloud Computing est LA rupture technologique du siècle, IBM pourrait bien ressortir l’IBM i étant donné son architecture multi-tenant natif intégré (mutualisation native entre utilisateurs dynamiquement connectés des fichiers + programmes depuis le S/38).

Tous les logiciels SaaS à la pointe du Cloud: Google Aps et SalesForce sont multi-tenant fichiers+programmes mais moyennant une expertise difficile à maîtriser (gestion des méta data par tenant) donc *un surcoût important* au niveau du développement des applications. Sur IBM i, il suffit de compiler le programme, l’IBM i fait le reste à l’exécution lorsque l’utilisateur ouvre une session et appelle le programme. Chaque session est un travail qui prend en charge les méta data associées à l’utilisateur.

Concrètement si un utilisateur lit à l’instruction 1000 la commande 00150 pendant qu’un autre utilisateur lit à la même instruction 1000, du même programme partagé, la commande 00789, les données des commandes 00150 et 00789, sont mémorisées à l’exécution respectivement dans des méta data associées aux deux travaux (utilisateurs). Cette gestion est automatique sur IBM i à l’exécution, alors que les méta data par utilisateur *sont à la charge du programmeur* pour les autres OS lorsque les développeurs se trouvent dans l’obligation d’écrire des programmes online multi-tenant (mutualisés) pour le Cloud.

Etes-vous d’accord si je vous dis que nous ouvrons/fermons des sessions dynamiques online avec un browser depuis plus de 30 ans ? Oui, ami lecteur, toutes nos applications RPG héritées depuis le S/38 sont multi-tenant natif fichiers+programmes. Autant dire que nos applications RPG valent potentiellement de l’or (or brut cependant). En fait Future System était un système génial trop en avance pour son époque. Cependant l’époque avance et nous rattrape...

Pour paraphraser Antoine de Saint-Exupéry : « Pour ce qui est de l’avenir, il ne s’agit pas de le prévoir, mais de le rendre possible. »

 Jean Mikhaleff/RePeGlio

Vous êtes libres de cliquer sur notre site : www.repeglio.com
Vous aimez l'IBM i? Vous êtes bienvenu :
Un commentaire? Abonner quelqu'un? Une question?  jean@repeglio.com

Aucun commentaire: