Projet Future Systems

Le projet Future Systems (FS) est un projet de recherche et développement entrepris par IBM au début des années 1970. Il visait à introduire une ligne informatique nouvelle orientée spécifiquement sur la simplification du développement d'applications - afin essentiellement d'en accélérer la croissance, et donc celle de ses ventes. Ce projet a été abandonné en 1975, bien que certaines de ses idées aient été utilisées ensuite pour le système 38, puis l'AS/400, en particulier la principale : l'espace d'adressage unique (à ne pas confondre avec la mémoire virtuelle).

Jusqu'à la fin des années 1960, IBM tirait son revenu et ses profits du matériel. Logiciel et services de support, considérés comme aide à la vente, n'étaient en effet pas facturés. Seuls les matériels figuraient au tarif, mais leurs prix couvraient aussi les coûts des logiciels et des services.

D'autres fournisseurs avaient commencé à offrir des matériels compatibles, principalement des périphériques comme des unités de bande et de disques magnétiques, à des prix significativement inférieurs à ceux d'IBM, réduisant ainsi la base sur laquelle il était possible de récupérer le coût des logiciels et des services. Au début de 1971, après que Gene Amdahl eut quitté IBM pour créer sa propre entreprise (Amdahl Corporation) proposant des unités centrales compatibles IBM, une "taskforce" interne IBM (projet Counterpoint) concluait que la prise en charge sans contrepartie de tous les frais de logiciel par IBM ne pouvait que favoriser la compétitivité des unités centrales et autres produits d'une concurrence n'ayant aucun de ces coûts à supporter. Il fallait donc facturer les logiciels.

Cela était d'autant plus vrai que les coûts des matériels informatiques étaient en diminution constante tandis que ceux de programmation et d'exploitation^[1], iraient, eux, en augmentation (bien que partiellement pondérés par une large extension de la base installée). L'amélioration du seul rapport performance/coût des machines ne conduisait donc pas nécessairement au développement des ventes. Une nouvelle architecture réduisant coûts de développement et d'exploitation améliorerait en revanche largement la croissance d'IBM, puisqu'aidant les utilisateurs à développer davantage d'applications chaque année.

L'idée d'un espace d'adressage unique combinant mémoire centrale et espace disque mettant fin pour le programmeur au souci de jongler entre la mémoire centrale et le disque (phases et overlays) était séduisante. Celle de laisser au système le soin de gérer cela de façon plus logique que la mémoire virtuelle en tirant parti des caractéristiques d'accès s'imposa.

IBM était par ailleurs attaquée juridiquement :

• pour sa position dominante
• pour sa politique d'inclusion gratuite du logiciel et des services avec le matériel, ce qui pouvait être jugé comme de la concurrence déloyale envers les sociétés de service et quelques entreprises de logiciel; cela donnait donc un motif d'abandonner cette gratuité^[2].

Toute politique de vente liée devait donc s'appuyer sur des arguments techniques solides et défendables juridiquement.

En mai-juin 1971, une "task force" internationale fut réunie à Armonk par John Opel, alors vice-président d'IBM. Sa tâche était d'explorer la faisabilité d'une nouvelle ligne d'ordinateurs. Ceux-ci rendraient obsolètes les compatibles, mais pour le coup aussi la ligne existante d'IBM. Cette "task force" conclut que le projet pouvait être accepté par le marché, mais - sans surprise - uniquement si la réduction annoncée des coûts de développement, exploitation et maintenance des logiciels d'application était suffisamment massive pour justifier cette révolution.

La direction d'IBM décida d'entreprendre le projet en confirmant les objectifs suivants :

• rendre obsolètes tous les ordinateurs existants, y compris ceux d'IBM, en exploitant pleinement les techniques logicielles et matérielles du moment ^{[réf. nécessaire]},
• réduire fortement les coûts de développement et d'exploitation des applications,
• regrouper autant qu'il était possible les offres d'IBM (matériels, logiciels et services).

Le projet FS prenait également en compte les problèmes suivants pressentis par IBM :

• les imprimantes à impact ne pourraient rapidement plus suivre les débits d'information; les délais pour en changer les chaînes d'impression (48 caractères pour la vitesse, 64 ou 96 caractères pour la richesse du jeu); les changements de bandes-pilote ou de préimprimés introduisaient encore des délais supplémentaires.
• la technique des écrans se séparait trop brutalement en écrans texte abordables et d'usage facile d'une part et écrans graphiques très coûteux et complexes à mettre en œuvre d'autre part; les besoins intermédiaires (graphiques de gestion) n'avaient pas de réponse et c'était là qu'allait se porter la demande;
• les télécommunications relevaient de bricolages spécifiques et non compatibles entre eux.
• un terminal (écran ou machine à boule) était attaché à une application donnée et complexe à rattacher à une autre; même quand ce rattachement était possible, il demandait à chaque fois des compétences spécifiques différentes;
• les questions de polices de caractères (en particulier APL) n'étaient pas gérées de façon automatique, ni même cohérente sur l'ensemble de la chaîne de traitement : c'était là encore à l'utilisateur de s'en occuper, et de signaler son action au système - la détection n'étant pas automatique.
• les délais de montage et démontage des bandes magnétiques bloqueraient de plus en plus les systèmes
• l'organisation hiérarchique des fichiers conduirait à des inefficacités croissantes en termes de maintenance à mesure qu'on dépasserait la dizaine de milliers de fichiers^[3].
• les systèmes existants n'incorporaient pas la notion de migration automatique d'un document entre supports sans perte d'identité comme le fait pourtant n'importe quelle administration (bureau, armoire, transmission entre services, salle d'archives...).

Le projet Future Systems (FS) fut lancé officiellement en septembre 1971, à la suite des recommandations de la "task force" du deuxième trimestre 1971^[4]. Par la suite, plusieurs autres projets de recherche dans divers sites d'IBM fusionnèrent avec le projet ou lui furent associés.

Pendant toute sa durée, le projet FS se déroula dans des conditions de sécurité et de confidentialité très strictes. Le projet était divisé en nombreux sous-projets affectés à des équipes différentes. La documentation était découpée de la même façon en nombreux éléments, et l'accès à chaque document était soumis à vérification de la réalité du besoin réel par un organisme central du projet. Chaque document faisait l'objet d'un suivi et pouvait être rappelé à tout moment.

Une conséquence était que la plupart des personnes qui travaillaient sur le projet n'en avaient qu'une vue extrêmement fragmentaire, limitée à ce qu'ils devaient en savoir pour produire la contribution qu'on attendait d'eux. Certaines équipes travaillaient même pour le projet sans le savoir. Cela explique pourquoi, quand ils sont amenés à définir ce qu'était FS ou pourquoi le projet a été abandonné, la plupart des gens donnent une réponse très partielle, qui ne mentionne que la partie du projet FS qui entre dans leur domaine de compétence.

La mobilisation fut grande : "le projet FS a mobilisé 2 500 personnes. Ses responsables avaient des droits de tirage sur le personnel de toutes les unités IBM. J'avais un travail à Paris et on m'en a sorti du jour au lendemain pour m'envoyer à New York. Pour vous montrer la foi qu'on avait dans IBM, je n'ai pas entendu dire que quelqu'un ait refusé cette mobilisation, ni l'ait regrettée"^[5]

Trois implémentations de l'architecture FS étaient prévues : le modèle de haut de gamme était conçu à Poughkeepsie (État de New York), où étaient produits les ordinateurs les plus puissants d'IBM ; le modèle de milieu de gamme était conçu à Endicott (État de New York), qui était responsable des ordinateurs de milieu de gamme ; le plus petit modèle était conçu à Rochester (Minnesota), qui avait la responsabilité des ordinateurs d'entrée de gamme.

Une gamme continue de performances pouvait être obtenue en faisant varier le nombre de processeurs par système à chacun des trois niveaux d'implémentation.

Au début de 1973, la direction d'ensemble du projet, ainsi que les équipes responsables des couches les plus externes communes à toutes les implémentations furent regroupées au laboratoire ASDD de Mohansic, à mi-chemin entre les sièges d'Armonk/White Plains et Poughkeepsie.

Un principe essentiel de FS était celui de la mémoire à un seul niveau ("single-level store") qui prenait la relève de l'idée de mémoire virtuelle en l'étendant à la totalité des données, temporaires ou persistantes. Cela rendait invisible au programmeur une quelconque différence entre accès à une base de données, à un fichier ou à un objet en mémoire. La mémoire de travail, les fichiers et les bases de données étaient accessibles de façon uniforme à travers une généralisation de la notion d'adresse (on prévoyait au départ une adresse généralisée de 6 octets). Les développeurs n'avaient donc pas à se soucier de la localisation physique des objets auxquels ils accédaient, mais uniquement de leur type et de leur nom, ce qui devait faciliter la programmation et réduire les coûts de développement de logiciel.

La réalisation de ce principe demandait que le mécanisme d'adressage, qui est au cœur de la machine, incorpore un système complet de gestion de la hiérarchie des mémoires et des parties importantes d'un système de gestion de bases de données, qui jusque-là étaient réalisées sous forme de logiciels extérieurs à la machine proprement dite.

Un autre principe était l'utilisation d'instructions de haut niveau très complexes réalisées sous forme de microcode. Par exemple, une des instructions, CreateEncapsulatedModule, était un éditeur de liens complet^{[réf. nécessaire]}. D'autres instructions étaient conçues pour supporter les structures de données et les opérations des langages de programmation de haut niveau tels que FORTRAN, COBOL et PL/I. En réalité, FS était conçu comme l'ordinateur à jeu d'instruction complexe (CISC) ultime^[6]

Une autre façon de présenter la même idée est de dire que tout l'ensemble des fonctions qui auparavant étaient réalisées sous forme de circuits, de logiciel système, de logiciel de bases de données, et plus encore, étaient maintenant considérées comme faisant partie d'un seul système intégré, chacune des fonctions élémentaires étant implémentée dans l'une des nombreuses couches allant des circuits au logiciel conventionnel. Plusieurs couches de microcode et de code étaient prévues, quelquefois désignées par les termes de millicode et de picocode. Selon la personne qui parlait, la notion même de "machine" pouvait varier depuis les seules fonctions réalisées sous forme de circuits (pour le spécialiste des matériels) jusqu'à la totalité des fonctions offertes aux utilisateurs, indépendamment de leur réalisation (pour les architectes système).

Le plan d'ensemble prévoyait aussi un "contrôleur universel" pour traiter principalement les opérations d'entrée-sortie en dehors du processeur principal. Ce contrôleur universel devait avoir un jeu d'instructions très limité, réduit aux instructions nécessaires aux entrées-sorties. Il annonçait ainsi le concept d'ordinateur à jeu d'instructions réduit (RISC).

Sur cette idée, John Cocke, un des principaux concepteurs des premiers ordinateurs IBM, lança un projet de recherche destiné à concevoir le premier ordinateur RISC. Ce fut la puce 801, qui servit à la fois de micromachine pour l'IBM 9370 (série 370) et de processeur natif à l'IBM 6150 (PC/RT). Par la suite, l'architecture RISC, qui au sein d'IBM évolua vers l'architecture Power et PowerPC, demandant nettement moins de circuiterie, devait se montrer non seulement plus rapide, mais beaucoup moins chère à réaliser et capable en théorie de cadences d'horloge bien supérieures. Dans la pratique, Apple abandonnera plus tard ces processeurs, parce que ne montant pas suffisamment en fréquence, pour utiliser des Intel : ce fondeur avait en effet conçu son Pentium et les générations suivantes avec ses propres circuits RISC comme micromachine d'un CISC, à la manière du 9370, mais en intégrant le tout à l'intérieur même du Pentium.

Les raisons de l'abandon du projet en 1975 sont mal connues. À cause du cloisonnement mis en place pour préserver la sécurité, les raisons invoquées dépendent de l'interlocuteur, qui met en avant les difficultés rencontrées dans le domaine avec lequel il est familier.

Quelques raisons citées sont:

• les performances décevantes avec la technologie de l'époque comparées à celles des systèmes 370 et compatibles.
• la complexité du jeu d'instructions, qui était jugé "incompréhensible" par de nombreux développeurs d'IBM^{[réf. souhaitée]}.
• le coût pour les clients de la migration depuis leurs anciens systèmes. En effet, afin de laisser aux architectes le maximum de liberté pour définir un système vraiment révolutionnaire, la facilité de migration n'avait pas été incluse dans les objectifs initiaux, mais devait être traitée après coup par les aides logicielles.

Vers la fin du projet, il apparaissait que le coût de migration de la masse des investissements des clients dans des applications écrites en assembleur et en COBOL serait souvent supérieur au coût d'acquisition d'un nouveau système. De plus, la modification des habitudes s'avérait telle que la coexistence obligatoire pendant plusieurs années des deux systèmes serait une source de coûts énormes pour le constructeur comme pour ses clients.

En réalité, la réussite du projet nécessitait un grand nombre de percées dans tous les domaines, allant de la conception et de la fabrication des circuits jusqu'au marketing et à la maintenance, en passant par l'architecture et toutes les formes de logiciel. S'il était concevable que chacun des problèmes pris isolément soit résolu, la probabilité qu'ils puissent tous l'être dans les délais et de façon mutuellement compatible était pratiquement nulle, surtout compte tenu des nombreux débats internes quant aux différentes voies de solution envisageables.

Les développements de FS furent plus onéreux que prévu. Des concepts qui nous sont aujourd'hui familiers n'existaient alors même pas, et les découvrir a impliqué beaucoup d'essais, de fausses pistes et de tâtonnements.

Pour les 370, les retombées les plus immédiates furent :

• une imprimante à laser nommée 3800 (les préfixes étaient en 38 parce qu'on supposait que la nouvelle série allait se nommer 380; le plan de nommage fut modifié quand Amdahl sortit sa série 470), qui avait des caractères programmables. Les premiers modèles ne travaillaient qu'en mode texte (avec possibilité toutefois d'utiliser jusqu'à quatre polices simultanées), mais des modèles graphiques devinrent rapidement disponibles. Vitesse : 215 pages par minute^[7]. Résolution : 240 points par pouce dans chaque sens. Coût : 3 millions de francs français de l'époque;
• un robot de stockage « à nid d'abeille » nommé 3850, qui était un système de stockage magnétique ne demandant strictement aucune présence humaine et fonctionnait en 24x365;
• des terminaux à caractères programmables qui furent d'abord le 3278 PS (monochrome), puis le 3279 PS (couleur) et pouvaient afficher des graphiques de gestion et autres;
• le logiciel GDDM (Graphical Data Display Manager);
• le migrateur automatique de fichiers HFS (Hierarchical File System), qui fut porté sous MVS.

De tous les laboratoires, Poughkeepsie était le moins handicapé par la reprise de l'existant, puisqu'il fabriquait des systèmes d'entrée de gamme. Il lança donc sa propre unité, le Système 38. Celui-ci déconcerta un peu par ses concepts inhabituels, mais fut suivi d'un successeur nommé AS/400 qui connut un succès plus fort qu'attendu, et resta jusqu'à la fin des années 1990 un des fers de lance d'IBM. Seul problème : la gamme devait être étendue par le haut, les utilisateurs d'AS/400 n'étant pas enthousiastes du tout pour repasser au 370 et à ses successeurs.

• Un mouvement fatal à IBM : "IBM est restée aveugle à la transformation du marché qui a suivi l’introduction des nouvelles technologies microinformatiques, et s’est crispée sur les grands systèmes centralisés. Au même moment, le cycle de relance périodique de l’innovation contre la bureaucratie grippait, en partie à cause d’un accès de timidité consécutif à l’échec du projet Future Systems (FS)" (...) "La bataille FS n’a jamais été livrée sur le marché, et n’a été « perdue » que par décision d’IBM, qui a renâclé devant les risques apocalyptiques de l’entreprise"...

• Le moment traçable du dérapage "Regardons [les phases] identifiées par Mills et Friesen. Les phases d'innovation [chez IBM] apparaissent en 1952, 1963, 1980 et 1990, donc avec des intervalles de 11, 17 et 10 ans.Où est le pic d'innovation qu'on pouvait attendre en 1974, peu après l'arrivée de Frank Cary à la présidence in 1972 ? Il est facile de l'identifier : c'est l'épisode FS avorté"...

• Portail de l’informatique