PB à OR. Downsizing, suite. (12/9/ 1990 je pense)
(j'ai réécrit une partie de ce que nous avions dit et ajouté d'autres idées. A suivre).
1. Sécurité
- les grands systèmes peuvent être considérés comme particulièrement fragiles contre certains types de risques
- sinistres naturels
- attaques de commando
- explosions nucléaires
- pannes ou sabotages réseau
- le stockage en bunker est facile à réaliser par recopie des différentes bases locales, avec des rythmes différentes selon le caractère plus ou moins critique des infos
- mirroring ou dataguarding permanent (disponible aujourd'hui sur micros avec dispositifs hardware, donc avec une perte de performance nulle)
- polling périodique (par exemple la nuit)
- tout ceci est encore facilité par la disponibilité de la fibre optique et du FDDI
- ce qui devient plus critique, en fait, c'est la sécurité du réseau, pour s'assurer que dans le pire cas de figure on saura toujours accéder, etc. mais ici les solutions en étoile autour d'un point central sont les pires; voir Rita
- les micros disposent de solutions de sécurité physique variés et bon marché : DAT, disques externes que l'on peut ranger en coffre fort; en outre, je connais un PDG qui conservent dans leur poche intérieure, sur disquette 3,5 pouce, certaines données hyper-confidentielles
2. Gestion des données
- ce problème est le plus intéressant de tous; il faudrait analyser plus précisément ce que tu en dis ("d'autant plus efficace que la machine est plus puissante, etc."); en effet, la méthode qui consiste à mettre tout en pagaille dans un vaste espace pour ensuite s'arracher les cheveux à le ranger... c'est le pompier qui allume l'incendie
Ce point pourrait probablement être analysé techniquement d'assez près (je crois qu'il y a des spécialistes à l'Inria), et chiffré.
- un des points critiques, c'est la gestion des accès disque; que ce soit sur grand ou petit système, il faut surtout une bonne organisation des données. ce point est certainement l'essentiel
malheureusement, cela oblige à réfléchir, alors que la solution mainframe classique permet de ne pas se poser de questions, ou de les laisser entre les mains des prêtres de l'informatique, gardiens du temple
Notons tout de même que, pour les très grandes applications, les plus grands mainframes ne sont de toutes façons pas assez puissants, et qu'il faut donc en avoir plusieurs, avec des problèmes assez complexes de parallélisme, etc. voir par exemple l'architecture générale d'Amadeus. Donc les partisans des MF ne peuvent pas prétendre avoir des solutions universelles.
Il faudrait certainement avoir de bons outils de gestion de données, bien combinés avec les outils de gestion de réseau.
3. Verrouillage par IBM.
Un poblo armado nunca verra vencido.
Si puissante soit la baleine, les petits poissons et les moyens requins ne lui permettront pas de bloquer indéfiniment la situation. Même avec la complicité des grands japonais.
4. Prix des logiciels
C'est un des grands atouts économiques du downsizing, car les logiciels grands systèmes sont beaucoup plus chers que sur les minis et micros. (voir mon papier sur EMC dans un prochain numéro).
Mais il faudrait pousser l'analyse un peu plus loin. Notamment quand il y a un grand nombre de terminaux (plusieurs milliers).
Le problème clé est la tarification des contrats multisites. IBM et les autres éditeurs peuvent, au moins pendant un certain temps, maintenir un écart artificiel entre le prix de revient et le prix de vente, mais ça ne devrait pas durer éternellement.
5. Maintenance
Il faut distinguer matériel et logiciel.
Pour le matériel, la dispersion aura de moins en moins d'inconvénients, car ce qui est réparti ce sont des machines standard et matériellement légères. La quasi totalité des pannes doit donc pouvoir être résolue par le transport sur un caddy d'une unité défaillante en remplacement, avec un gars de niveau bac capable d'enfoncer un connecteur mâle dans un connecteur femelle.
En outre, le MTBF des stations s'allonge, même pour les imprimantes, et il n'y a donc plus beaucoup à intervenir. Pour le logiciel, c'est par le réseau que s'effectueront tous les téléchargements et donc toutes les télémaintenances. De manière largement automatisée (cas typique actuel: téléchargement quotidien des fichiers et si nécessaire des programmes dans les milliers de TPE, terminaux de paiement électronique).
La gestion des logiciels nous ramène au même problème que la gestion des données: il faut avoir de bons outils de gestion des configurations, de télédiagnostic, tuning, etc. Ces outils sont déjà en partie disponibles. ou en cours de développement. Pour se agences de voyage, par exemple, Amadeus prévoit de gérer automatiquement tout le logiciel à distance.
6. Logique profonde
6.1. Répartition de la puissance
La loi de Moore (doublement de la puissance d'un chip tous les deux ans) et ses analogues économiques vont continuer de s'appliquer encore dix ou vingt ans.
Elle va plus profiter aux micros qu'aux mégas, parce plus la complexité s'élève, plus le bordel est difficile à gérer. Par conséquent, on va voir continuer à s'accroître rapidement la puissance installée sur chaque bureau, tant en Mips qu'en méga et giga-octets de mémoire.
Cette puissance sera bien plus grande que celle de l'ensemble des mainframes d'une grande entreprise. Cette puissance n'est utilisée qu'une partie de la journée. Huit heures par jour en théorie, mais il faut tenir compte des absences, vacances, réunions, etc. Mettons que chacun travaille environ six heures par jour à son poste. Donc: les trois quarts de cette énorme puissance est dormante.
Si l'on dispose des outils de gestion de réseau (voir plus haut). Il ne devrait pas être bien difficile de mobiliser à distance cette ressource qui est absolument gratuite.
6.2. Evolution des applications
Les applications de production, lot traditionnel des mainframes, ne se compliquent pas beaucoup dans leurs structures profondes (point à valider).
Le progrès se fait surtout dans l'interface avec l'utilisateur (Mac, Windows 3).
Par conséquent, avec un bon traitement coopératif, il n'y a pas à augmenter la puissance des systèmes centraux, bien au contraire, puisqu'une partie du travail de gestion des terminaux se trouve reporté sur les postes locaux.
Reste à réfléchir sur les applications à très forte charge graphique (CAO, DAO etc. et demain image animée et son). Mais les mainframes classiques ne sont pas faits pour ces applications là.
6.3. Les deux sens du mot "mainframe"
On est induit en erreur par deux significations différentes de "mainframe"
- de grosses machines
- des machine "principales", ou "centrales".
Le besoin de machines de grande puissance ne fait pas de doute. Mais
- certaines stations sont bien plus puissantes que les mainframes d'il n'y à guère
- les supercalculateurs sont plus puissants que les mainframes classiques.
Le besoin de grosse puissance (calcul numérique, c'est évident, mais aussi certaines bases de données), se résoudra avec des serveurs, qui ne sont pas des mainframes au deuxième sens du terme.
Machines principales: ici, c'est satisfaisant pour l'esprit et pour le salaire des informaticiens, mais il reste à prouver qu'il faut de telles machines.
Cas intéressant: le repository, qui par nature doit être central (à vérifier quand même). Mais il s'agit d'un outil de conception, et dont les bases ne sont a priori ni immenses (avec quelques gigas, on doit déjà avoir tous les méta-modèles de l'EDF), ni critiques en temps de réponse, puisqu'il ne s'agit pas de production.
6.4. SIP contre SIO
Axiome fondamental:
Le système d'information de l'organisation (entreprise et groupe quelconque) n'est pas la somme de celui de ses membres.
Corollaire:
Il y nécessité d'avoir, quelque part et d'une manière à préciser, une mémoire et une "conscience informatique" collective.
Et des spécialistes pour s'en occuper car il y a des problèmes techniques (structures de données, architectures de réseaux, etc.) très difficiles.
Cette fonction appelle des outils sophistiqués de gestion du système d'information: données, réseaux, sécurité... budgets. Mais la puissance nécessaire n'est pas forcément énorme. Et les stations de ces spécialistes se brancheront sur le réseau plutôt par le côté qu'au sommet.
Si l'on veut considérer le SIO comme une pyramide avec un sommet, ce n'est pas le SIP de l'informaticien qui viendra au sommet, mais l'EIS (Executive Information System). Et, qu'il s'agisse du DIO ou du PDG, ce n'est pas d'un 390 qu'ils ont besoin pour travailler.
Mort aux vaches.
Pierre. 12/9/90