par Samy Mosimann
En route pour une expérience enrichissante...
Nous nous envolons par l'avion du matin en direction de Chicago, où nous arrivons
dans l'après midi. Après les formalités de police et de douane, nous nous dirigeons
vers la porte B33 où nous embarquerons sur l'avion de Rochester (MN). On y repère
rapidement les malades qui se rendent à la fameuse Clinique Mayo, ainsi que les
IBMers qui ont sorti leurs Thinkpad pour travailler en attendant le départ. Encore
une heure de vol et nous arrivons à destination. A Genève, il est passé minuit
!
Le lendemain matin, en route pour le Centre de test des laboratoires AS/400 de
Rochester, où nous sommes accueillis par Bill Larson, à la tête de l'équipe de
3 personnes qui va s'occuper de nous durant toutes les séances du “benchmark test”.
Notre équipe (le client) comprend 6 personnes dont un chef de projet, 1 programmeur
connaissant le langage C, un business-analyst (chargé de dérouler et de lancer
les menus), 1 créateur d'environnement. IBM Suisse a délégué 2 spécialistes dont
un chef de projet.
Le Centre de test de Rochester a été créé en 1993. Il a pour but de définir la
configuration optimale d'un AS/400 en tenant compte de l'environnement réel d'un
client, soit nombre d'utilisateurs, applications en transactionnel et en batch,
réserves de capacités nécessaires et temps de réponse requis, etc. Près de 500
“benchmark tests” ont déjà été effectués à Rochester. Pour information, un centre
identique existe à Santa Palomba (près de Rome en Italie) à l'usine où sont assemblés
les AS/400 pour l'Europe.
Près de 500 “benchmark tests” ont déjà été effectués à Rochester
Benchmark à Rochester!
Le lendemain matin, première réunion dite de “Bienvenue” et d’orientations générales.
On nous explique les procédures du benchmark. Les hypothèses et environnements
du test sont présentées et les responsabilités respectives (celles d’IBM et celles
du Client) sont déterminées de même que les objectifs attendus de ce test pour
aboutir en fin de compte à la signature d’un contrat.
Les environnements du test sont alors définis, à savoir: les besoins en matériels
et en logiciels, les types de communications (LAN-WAN-TCP/IP-APPC etc.), les profils
requis et les outils de simulation.
Les applications sont globalement définies de la manière suivante:
| Système A |
Système B |
||
| Application A | 35% | Application C | 25% |
| Application B | 20% | Application D | 20% |
| Développement | 10% | ||
| Travaux batch | 10% | Travaux batch | 20% |
| Mirroring | 5% | Mirroring | 5% |
| Système | 15% | Système | 15% |
| _________ | _________ | ||
| Total | 95% | Total | 85% |
Téléchargez cette ressource
Phishing : Match PKI Versus MFA
Au-delà des technologies de protection, les entreprises doivent s’appuyer sur des plateformes qui englobent tous les défis cyber liés à l’authentification des personnes et des machines, quels sont les avantages d’une Infrastructure à Clé Publique (PKI) vis-à-vis de la MFA ?
Les articles les plus consultés
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Cybersécurité Active Directory et les attaques de nouvelle génération
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- Les 6 étapes vers un diagnostic réussi
- Afficher les icônes cachées dans la barre de notification
Les plus consultés sur iTPro.fr
- IA : les PME devraient adopter des outils NoCode appropriés
- Guide des certifications Microsoft
- Transition vers le Cloud : l’approche stratégique pour répondre aux exigences de cybersécurité NIS 2
- Vers une meilleure qualité de données : l’IA vient en renfort
- Stimuler l’innovation durable grâce à la transformation numérique et aux principes ESG
