2011 11 18 11 42 15 Livreblanc Mainframe Web

Club des Responsables
d’Infrastructures et de Production
L’OBSERVATOIRE
des Directeurs
LIVRE BLANC
d’Infrastructures
et de Production
MAINFRAME
Enquête et Analyse de Tendances,
Maîtrise des coûts
Auteurs
Laurent Buscaylet, Frédéric Didier
Bernard Dietisheim, Bruno Koch, Fabrice Vallet
Assistance éditoriale : Renaud Bonnet Novembre 2011

Table
desmatières
Introduction 4
1. Positionnement et stratégie du « z » au sein de l’entreprise 6
1.1 Rôle du Mainframe dans le SI des adhérents du CRIP 6
1.2 Position du z vis-à-vis des plates-formes distribuées (Windows, Unix, Linux) 6
1.3 Spécificités sectorielles du z : Banque/Finance/Assurance vs Industrie 7
1.4 Stratégies d’évolution pour le z 9
2. Cartographie de la plate-forme z 11
2.1 Référentiels techniques 11
2.1.1 Serveurs 11
2.1.2 SAN & Réseau 12
2.1.3 Stockage 13
2.1.4 Sauvegardes 15
2.1.5 Architecture technique & Organisation 16
2.1.6 Sécurisation 19
2.2 Analyse et positionnement des fournisseurs de logiciels Mainframe 20
2.2.1 Fournisseurs Principaux 21
2.2.2 Fournisseurs Secondaires 22
2.3 Résultats de l’enquête 23
3. Maîtrise des coûts sur plate-forme z 28

3.1 Maîtriser ses coûts logiciels 28
3.1.1 Démarche contractuelle avec IBM 28
3.1.2 Stratégies à adopter avec les fournisseurs : approche globale ou coup par coup 30
3.1.3 Démarche contractuelle avec ISV : Modes de licence et de facturation 35
3.1.4 MLC : Maîtriser son niveau de facturation 37
3.1.4.1 La méthode de facturation IBM 37
3.1.4.2 Le problème du lissage des pointes de charge 41
3.1.4.3 Les méthodes et outils de maîtrise de la facture 41
3.1.4.4 Retours d’expérience et préconisations 44
3.1.4.5 Les autres leviers d’économies 50
3.2 Réduire ses coûts d’infrastructure 53

3.2.1 Regroupement et mutualisation d’infrastructures 53
3.2.2 Utilisation de moteurs spécialisés : zIIP, zAAP, IFL 57
3.3 Maîtriser ses coûts de Fonctionnement 59
3.3.1 Optimisation, performances et qualité des composants techniques et applicatifs 59
3.3.2 Capacity Management, outils et méthodes 63
4. Conclusion 74
5. Annexe : Glossaire des termes techniques et acronymes utilisés 75
A Propos du CRiP 79
PAGE 3
Intro
duction
Le Mainframe ? Mais que reste-t-il à dire du Mainframe ?
Avant tout qu’il est le plus moderne des dinosaures, et que même chaque année qui
passe renforce sa modernité. Ce bientôt quinquagénaire se tient au centre des ten-
dances du moment. Vous n’y croyez pas ?
Pourtant la virtualisation a vu le jour sur un Mainframe trente bonnes années avant

que les serveurs x86 ne s’y convertissent. La consolidation et la mutualisation sont
depuis bien longtemps deux de ses caractéristiques fondamentales. On y pratique
l’automatisation des opérations, l’orchestration des workloads et la gestion capacitaire
comme des évidences depuis deux décennies. On y exploitait des systèmes de stoc-
kage mutualisés en réseau et des outils de virtualisation de bandes avant l’invention
des acronymes SAN et VTL. Java y tourne de façon fiable depuis longtemps. Les PRA,
le fonctionnement en cluster, la réplication à distance y font figure d’évidences. La
haute disponibilité en constitue un composant intrinsèque. Un ensemble de qualités
qui explique que nombre de grandes entreprises continuent de lui confier le cœur de
leur activité.
Le monde distribué d’ailleurs ne cesse de s’inspirer de ce modèle, de l’imiter, de le ré-

inventer, d’en chercher des équivalences. Le plus souvent sous la forme du « presque
pareil » : en cherchant à offrir les mêmes modes de fonctionnement que le Mainframe,
sans réellement y parvenir. Regardez l’écart aujourd’hui encore entre la virtualisation
sur System z et ce qu’on trouve même de plus abouti sur plate-forme distribuée. Il se
réduit. Il reste énorme. Le Mainframe : à suivre.
Pourtant la plate-forme souffre d’une lourde défiance : les tarifs y passent pour exor-
bitants. Il y a dans cette critique une forme de distorsion cognitive, un problème de
vue. Machine hyper-consolidée, affichant des taux d’utilisation à faire pâlir un adminis-
trateur Unix (et s’évanouir de rage son collègue Windows), environnement par nature
global, son coût apparent, surtout en investissement logiciel, saute aux yeux des ges-
tionnaires qui n’en voient pas la contrepartie en termes d’administration et de facilité
d’exploitation. Ensuite, la comparaison s’effectue trop souvent entre déploiement sur
Mainframe, donc sur une infrastructure globale, et déploiement sur un ou quelques
serveurs x86. C’est une erreur aussi classique que la célèbre addition des choux et des
carottes, ou ici celle des choux de Bruxelles et des citrouilles. Car une fois l’application
montée en régime, installée sur une batterie de serveurs x86 qu’il faudra administrer,
sauvegarder, orchestrer, etc. qui coûtera réellement le moins cher ?
Reconnaissons aussi une spécificité peu attrayante du Mainframe : les licences et

contrats logiciels y sont d’une complexité byzantine. Difficile de s’y retrouver au milieu
d’une foule d’acronymes barbares cachant autant de différences subtiles : AWLC, IPLA,
ULC, IWP, zNALC, SzLC, EWLC et d’autres, n’en jetez plus. Les comprendre, les analy-
ser, suivre leurs évolutions, négocier pour en tirer le meilleur constitue quasiment un
emploi à plein temps. Déplorable situation, certes. Mais remarquez que là encore, le
monde distribué commence à copier : la virtualisation et les processeurs multi-cœurs
injectent dans la facturation des systèmes distribués une sérieuse dose de complexité.
Le vrai problème au fond tient peut-être moins au Mainframe qu’à la consolidation
et à la virtualisation qui créent des difficultés de comptage que ne connaissait pas la
glorieuse – mais défunte - époque du « un serveur, un OS, une application ».
PAGE 4
LiVRE BLANC
MAINFRAME : Maîtrise des coûts en environnement Mainframe
Ce Livre Blanc entend remettre les pendules à l’heure et prouver que les coûts sur Mainframe, cela
se maîtrise plus que cela ne se subit, qu’il existe des méthodes, des bonnes pratiques, des leviers,
et même des perspectives d’avenir pour conserver la main sur ces investissements. Et surtout
qu’on comprenne bien qu’ici maîtrise ne signifie pas réduction. Il ne s’agit pas de mettre la machine
au régime forcé, mais bien de la diriger dans le sens voulu, de piloter son évolution, d’optimiser le
rapport entre son coût et le service rendu, plutôt que d’en subir le poids financier.
Pour conduire à bien ce travail, nous avons commencé par faire un point, par indiquer où se trouvait
aujourd’hui le Mainframe dans nos entreprises, à quoi il servait, comment il s’intégrait avec le reste
de l’infrastructure. Ensuite, nous avons passé en revue les méthodes possibles de maîtrise des
coûts. Comme vous le verrez, elles ne manquent pas.
Nous avons souhaité que ce Livre Blanc soit un outil, qu’il porte des solutions pratiques. Insistons
donc sur un point : le vécu. Notre texte est issu de multiples réunions du Groupe de Travail Main-
frame-z/OS ainsi que des éléments collectés au cours de ses enquêtes. Tout ce qui suit vient de
l’expérience concrète des utilisateurs et a été d’abord débattu entre professionnels chevronnés de
la plate-forme. Chaque piste présentée a fait l’objet de démarches d’implémentation réelles qui
ont validé sa pertinence. Chaque commentaire, chaque nuance, chaque critique ou mise en garde
provient d’une difficulté rencontrée sur le terrain, d’un résultat inattendu, d’une heureuse surprise,
ou témoigne de l’écart entre le brio d’une idée et les complexités de sa mise en œuvre. Ce sont les
fruits de notre expérience que nous vous livrons.
Bonne lecture.
Les participants actifs du Groupe de travail Mainframe

Laurent Buscaylet PSA Peugeot Citroën
Frédéric Didier Crédit Foncier de France
Bernard Dietisheim Renault
Bruno Koch GCE Tech (Groupe Caisse d’Epargne) (Pilote du GT)
Fabrice Vallet PSA Peugeot Citroën
Les contributeurs au Groupe de Travail

Alexandre Babin La Banque Postale
Sandra Belinguier La Banque Postale
Romain Capron Matmut
Hervé Combey La Banque Postale
Thierry David i-BP
Marie-Françoise Dhiver Natixis
François-Xavier Ducreux i-BP
Pierre Fenaroli La Banque Postale
Patrice Rosier CNP
Hao Ung Hoi Air France
Jérôme Viguier Air France
Le Groupe de Travail Mainframe remercie

toutes les entreprises qui ont répondu à son enquête 2010
PAGE 5
1 POSITIONNEMENT ET STRATÉGIE DU « Z »
AU SEIN DE L’ENTREPRISE
1.1 Rôle du Mainframe dans le SI des adhérents du CRIP
La plate-forme Mainframe reste encore aujourd’hui au service du cœur de métier des en-
treprises. L’enquête de 2010 conduite par le Groupe de Travail auprès des membres du
CRIP révélait que tel était le cas chez quasiment tous les répondants, sauf un qui cantonnait
l’utilisation de son System z à des applications de gestion d’entreprise. Dans cette logique,
on constate aussi que le Mainframe fonctionne le plus souvent de façon intégrée aux autres
ressources informatiques (environnements distribués en particulier), à deux exceptions
près, qui le maintiennent comme une plate-forme isolée. Encore faut-il ajouter qu’une de
ces deux entreprises a l’intention d’intégrer son z au reste de ses moyens informatiques sur
la période 2012-2014. L’ensemble des répondants chez qui le Mainframe sert aujourd’hui
aux applications de cœur de métier considère que ce sera toujours le cas pour la période
2012-2014.
En termes de consommation moyenne calculée en MSU, la situation apparaît très nuan-

cée. Sur quinze répondants, 4 se situent entre 1 900 et 3 000 MSUs, ce qui en fait de gros
consommateurs. La grosse majorité se tient entre 200 et 500 MSUs. Un seul répondant
exploite moins de 50 MSUs (et dans son cas la plate-forme héberge tout de même environ
la moitié de ses applications).
Pour l’avenir prévisible, la tendance globale est à une augmentation de consommation. Pour
6 des répondants, cette augmentation se situera entre 5 et 15 % par an, et pour 3 autres en
dessous de 5 % mais en croissance tout de même. En comparaison, seules 3 entreprises
prévoient une réduction de la puissance utilisée, mais sans que cette régression excède 5 %
par an. 2 répondants prévoient de continuer à consommation constante. Il n’y a donc pas de
déchéance globale de l’utilisation de la plate-forme Mainframe : ceux qui en possèdent une
continuent à la faire fonctionner pour servir des besoins qui généralement augmentent.
Si on se penche cependant sur la position relative du Mainframe par rapport aux environne-
ments ouverts, la situation se montre sous un jour tout différent.
1.2 Position du z vis-à-vis des plates-formes distribuées

(Windows, Unix, Linux)
Le Mainframe risque-t-il de disparaître, victime de l’emprise croissante des systèmes dis-
tribués ? Nous distinguons deux tendances complémentaires à ce sujet qui montrent que
si les applications pur Mainframe se raréfient rapidement, les applications hybrides ne ré-
gressent que très lentement.
Cela n’étonnera personne : la part des applications strictement cantonnées à la plate-forme

Mainframe n’augmente chez aucun des répondants. Pour une majorité d’entre eux (6 sur 11
ayant fourni une réponse complète à cette question), la tendance est à la réduction, et l’un
d’entre eux se prépare même, à l’échéance 2014, à une disparition complète des applica-
tions pur Mainframe dans son SI. Trois répondants indiquent que la part des applications
Mainframe est restée et restera constante dans leur informatique sur la période 2006-2014,
PAGE 6
LiVRE BLANC
deux d’entre eux faisant fonctionner sur la plate-forme environ 60 % de leurs applications,
ce qui est énorme. Une moyenne globale sur les réponses complètes montre qu’entre 2006
et 2014, la proportion moyenne d’applications pur-Mainframe tombe de 28,6 % à 19,25 %.

Dans l’ensemble on assiste donc indéniablement à une réduction de la part des applications
fonctionnant exclusivement sur la plate-forme, alors que la part des applications s’exécu-
tant strictement en environnement distribué progresse.
Mais il est intéressant de relever que la part des applications de type mixte, s’exécutant par-
tiellement sur Mainframe et partiellement sur systèmes distribués aurait plutôt tendance
à rester constante, partant de 40 % sur la période 2006-2008 pour se stabiliser à 36 % sur
2009-2011 et 2012-2014. Signe que l’intégration du mainframe au SI se perpétue, et que le
z parvient à collaborer régulièrement avec les environnements distribués en faisant alors
office de serveur de données d’une part et de serveur middleware de l’autre.
Il nous a été très difficile d’obtenir des réponses à la question portant sur la proportion
du budget informatique et du temps d’activité (jours/hommes) alloués à l’environnement
Mainframe. Le manque de répondants ne nous permet pas de reprendre ces chiffres ici.
Cependant, les discussions internes au groupe de travail vont toutes dans le même sens :
le Mainframe demande plutôt moins d’investissement humain et moins de temps d’ad-
ministration que les environnements distribués. Il conserve pourtant globalement cette
image d’environnement coûteux. C’est que pour prouver son intérêt économique, le Main-
frame demande de ne pas se limiter à une approche unitaire des coûts, mais de prendre en
compte un nombre suffisant de paramètres, comme le temps consacré à l’exploitation, le
haut niveau de sécurité délivré, le niveau élevé d’occupation des ressources atteint, la faible
quantité de stockage qu’il nécessite.
Sur ce dernier point et à titre d’exemple, le Groupe de Travail Stockage du CRIP nous a four-
ni les chiffres suivants qui remontent à l’enquête de 2009 mais semblent encore valables :
parmi l’ensemble des répondants, 4 % de la volumétrie était affectée au Mainframe, contre
75 % au SAN et 21 % au NAS en environnement distribué. Chez les comptes possédant un
Mainframe, la répartition s’établissait en 13 % de stockage mainframe, contre 72 % SAN
et 15% NAS en environnement distribué. Si nous faisons le rapport avec la proportion des
applications fonctionnant dans chacun des environnements, le Mainframe se montre donc
particulièrement sobre en stockage.
A l’heure où les préoccupations énergétiques, mais aussi les problèmes d’occupation des
salles se multiplient, il faut rappeler que le Mainframe reste un champion de frugalité.
Un des membres du Groupe de Travail précise que l’activité Mainframe occupe dans son
entreprise 135 m² de salles informatiques sur un total de 4000 m², soit environ 3,5 % des
surfaces, mais exécute 25 % des applications. En termes d’énergie, ses installations main-
frame ne consomment « que » l’équivalent de deux fermes de calcul.
1.3 Spécificités sectorielles du z :

Banque/Finance/Assurance vs Industrie
En ce qui concerne les entreprises membres du CRIP, il existe deux positions tranchées
concernant la place, le rôle et le devenir de la plate-forme Mainframe selon les secteurs
d’activités.
PAGE 7
En résumé, le secteur Banque-Finance-Assurance n’envisage pas de remettre en cause
l’utilisation du Mainframe, et tend même à la renforcer, tandis que l’Industrie connaît plutôt
un mouvement de réduction ou de stabilisation des usages.
Il faut voir dans cette évolution une conséquence des exigences métiers différentes des uns
et des autres.
Dans le domaine Banque-Finance-Assurance, la manipulation transactionnelle de grandes

quantités de données clients reste le cœur de l’activité. En effet il importe que les don-
nées soient fortement centralisées, fréquemment sauvegardées, et maintenues dans une
perpétuelle intégrité. Dans ce contexte les capacités de la plate-forme Mainframe comme
serveur de données centralisé restent sans égales. De plus, les applications COBOL de
cœur de métier écrites pour certaines il y a une ou deux décennies déjà mais qui continuent
à évoluer restent bien ancrées sur la plate-forme. Cet état de fait conduit d’ailleurs à ins-
taller sur Mainframe de nouvelles applications dès lors qu’elles dépendent de l’accès aux
données qui y résident déjà. Il y a donc dans ces secteurs une réelle extension de l’usage.
D’autre part le Mainframe sert aussi à faire fonctionner des couches middleware (serveurs
d’applications) dès lors que là-encore les traitements font appel à des manipulations sur
les données centralisées.
Dans l’Industrie, les systèmes distribués prennent une place croissante. Les choix des DSI,
souvent soucieuses d’homogénéiser leurs parcs de machines, excluent le développement
de nouvelles applications en environnement Mainframe, même en ce qui concerne les fonc-
tions de cœur de métier, sauf en cas d’extensions de l’existant. On se trouve donc ici plutôt
dans un scénario de migration en douceur qui prévoit que lors d’une réécriture des appli-
cations, ou d’une adoption de progiciels en lieu et place de développements maison, le
déploiement ne se fera pas sur Mainframe. Nous constatons ici une volonté non pas de se
désengager de la plate-forme, puisque ces directions stratégiques peuvent s’accompagner
d’un entretien de l’existant et d’un renouvellement régulier de l’infrastructure, mais de ne
pas lui donner de nouvelles fonctions. Comme nous l’avons vu plus haut cela peut se tra-
duire chez certains adhérents du CRIP par une légère augmentation de la puissance utili-
sée, mais sans déploiement de nouvelles charges, un phénomène qu’un des participants au
Groupe de Travail qualifie de « mort annoncée » du Mainframe.
Ce phénomène se produit assez lentement, car il reste difficile de déplacer une application
qui consomme plusieurs centaines ou milliers de MIPS vers un environnement distribué,
et ceci en dépit des promesses des consultants. Les équipes Mainframes se voient parfois
obligées de mettre en évidence que le coût d’un désengagement à marche forcée serait
exorbitant. Comme le résume un participant « la durée de vie d’un DSI qui souhaite suppri-
mer le Mainframe est souvent moindre que la durée effective du désengagement ».
Ces évolutions posent en tout cas aussi la question des compétences. Tout le monde constate
qu’elles se raréfient. Pour certaines entreprises, les développements Mainframe se voient
abandonnés du fait de ce manque de compétences, d’autant plus que les ressources Linux
ou Windows sont moins chères et abondantes. Même dans les entreprises qui continuent à
se doter de compétences développeurs Mainframe, la pyramide des âges pose problème.
Les équipes vieillissent. Il est possible de réduire les impacts de cette évolution en privi-
légiant les outils et les environnements de développement modernes (Java en particulier)
afin de s’affranchir au maximum de la plate-forme. Mais cela laisse entière la question de
l’exploitation.
PAGE 8
LiVRE BLANC
1.4 Stratégies d’évolution pour le z
Le parc applicatif Mainframe reste important dans la majorité des grandes entreprises.
Cependant, les applications hébergées sur cette plate-forme vieillissent et leur renouvelle-

ment naturel est en cours. Compte tenu de la criticité de la plupart de ces applications, ce
renouvellement s’annonce délicat et il faut faire des choix stratégiques.
IBM semble conscient que de nombreuses entreprises se trouvent confrontées à ce tour-

nant et tente de relancer l’attractivité du Mainframe. Les offres techniques et commerciales
ne manquent pas, au contraire, leur nombre crée parfois de la confusion, mais sont-elles
assez différenciatrices et pertinentes pour convaincre les décideurs ?
IBM met l’accent en premier lieu sur ce qu’il appelle les « new workloads ». La plupart des
programmes Mainframe actuels sont écrits en COBOL et ne proposent qu’une interface
utilisateur limitée. A l’heure du Web 2.0 et des RIA (Rich Internet Applications, qui associent
un mode d’accès Web à des interfaces riches de type poste client lourd), ces technologies
n’ont plus d’avenir et doivent évoluer. Raison pour laquelle IBM mise sur l’exécution de ces
nouvelles applications pour faire perdurer la plate-forme.
Techniquement, le Mainframe reste en avance en termes de virtualisation, de scalabilité et

de robustesse. En revanche, son coût, toujours comparé à celui des plates-formes distri-
bués x86, s’avère être un frein. Les processeurs spécialisés Java, XML et DB2 limitent l’im-
pact financier que cette nouvelle charge engendre mais ne suffisent pas pour convaincre
les utilisateurs.
En août 2009, IBM présentait une nouvelle offre commerciale réservée à ces news workloads :
Solution Edition. Ce package financier intègre le matériel, le logiciel et la maintenance
alors que l’offre zNALC antérieure ne concernait que le logiciel. Cette offre semble com-
pétitive mais IBM la réserve à de nouveaux projets très ciblés (BI, SAP, GRC, etc.) avec
des ressources dédiées ce qui va à l’encontre des modes de fonctionnement propres à la
plate-forme Mainframe où la mutualisation des ressources constitue la règle, et le dédié
l’exception.
En 2011, une nouvelle offre de facturation mise cette fois-ci sur la co-localisation. Cette
offre permet d’exécuter des logiciels dits ”qualifiants“ – comme WebSphere – sur des par-
titions existantes hébergeant les moniteurs traditionnels comme IMS et CICS sans pour
autant accroitre leur facturation à la charge. Ces logiciels sont dits éligibles à l’ajustement
IWP (Integrated Workload Pricing). Cette évolution changera-t-elle la donne en autorisant
l’exécution de nouvelles applications Java sans augmenter la facturation à la charge du
Mainframe ?
IBM continue à investir dans la plate-forme Mainframe (qui contribue aussi bien à ses ventes
de matériels que de logiciels dans une proportion non-négligeable bien que jalousement
gardée secrète). En 2010, le constructeur a dévoilé une nouvelle génération de machines,
les zEnterprise. IBM y fait un pari sur lequel nous n’avons que très peu de recul.
La nouvelle machine zEnterprise a la capacité de faire cohabiter sur la même plate-forme

des technologies hétérogènes à savoir z/OS/PRSM (z196), AIX/Power et Linux/x86 (avec
zBX). Début avril 2011, IBM a fait part de son intention de faire aussi fonctionner Windows
sur x86 dans les extensions zBX. Le Mainframe se présente alors comme une plate-forme
PAGE 9
d’hyper-consolidation, capable de fonctionner comme un datacenter-in-a-box, ou, pour
adopter les obsessions du moment, comme un cloud-dans-un-Mainframe, un cloud ca-
pable de gérer une forte hétérogénéité.
Comme l’a souligné le groupe de travail, cette évolution ne pose pas seulement des ques-
tions technologiques (il faut valider les capacités réelles de la plate-forme), mais aussi des
questions politiques. En effet, zEnterprise reviendrait peu ou prou à donner le contrôle des
divers systèmes à l’équipe d’administration Mainframe. Une direction qui ne parait pas vrai-
ment à l’ordre du jour dans les entreprises.
De façon concrète, l’utilisation du Mainframe comme plate-forme de consolidation globale

se heurte parfois aux faits. Un des membres du GT travaille dans une entreprise qui pos-
sède deux datacenters, l’un pour le distribué, l’autre pour le Mainframe. Il a étudié l’apport
de Linux sur z et la possibilité de consolider les charges Linux dans son datacenter Main-
frame. Il en a conclu qu’il en tirerait peu de bénéfices car le datacenter Mainframe n’a pas
été conçu pour ce type de fonctionnement, et qu’une telle opération nécessiterait d’y rapa-
trier des infrastructures depuis le datacenter distribué. Finalement, la mise en place d’une
infrastructure de consolidation Linux dans le datacenter distribué semblerait plus logique.
Ce cas illustre le fait qu’il ne faut pas attendre d’évolution de tendance dans le sens d’un
retour au Mainframe, mais plutôt se préparer à ce que les autres plates-formes intègrent
progressivement un mode de fonctionnement qui les rapproche de celui du Mainframe.
On parle d’ailleurs de plus en plus souvent de Mainframe Unix ou de Mainframe x86 pour
qualifier des systèmes de forte taille (monolithiques ou distribués) présentant des taux de
virtualisation et de consolidation importants. Il existera donc à terme des systèmes Main-
frame-like, ou une « mainframisation » de l’informatique dans son ensemble. Ce à quoi un
des membres du Groupe de Travail répond « il n’est pas exclu que la tendance se renverse
car les promesses du distribué sont loin d’être opérationnelles et à force de vouloir imiter
le Mainframe les DSIs vont peut-être se demander pourquoi ne pas utiliser la version ori-
ginale. »
PAGE 10
LiVRE BLANC
2
CARTOGRAPHIE DE LA PLATE-FORME Z

2.1 Référentiels techniques
Attention : Les chiffres et données figurant dans ce qui suit proviennent essentiellement
d’une enquête réalisée en 2010 par le groupe de travail auprès des membres du CRIP
utilisateurs du Mainframe (15 sociétés).
2.1.1 Serveurs
Infrastructures
Au moment de l’enquête, les serveurs installés étaient en quasi-totalité de la dernière
génération alors disponible (z10). Le z196 a depuis lors fait une percée de 30 % sur
l’ensemble du parc installé.
Le z est donc une plateforme moderne sur le plan technologique. Les raisons en sont
principalement :
• Le souci d’investir de manière pérenne (i.e. : sur des plateformes récentes).
•L a non-évolutivité des serveurs de génération plus ancienne environ 5 ans après leur
début de commercialisation.
•L a prime à la nouvelle technologie au niveau de la facturation logicielle (« Technology
dividend ») sur le MLC : de 3 à 5 % d’une génération à une autre.
On notera que pour la technologie z196, cette prime au renouvellement technologique

prend la forme d’un nouveau système de facturation dénommé AWLC en remplacement
du classique VWLC. Tous calculs faits, le bénéfice pour le client est du même ordre que
celui constaté sur les générations précédentes, en dépit des annonces optimistes d’IBM
en la matière. Il faut aussi noter que l’ancien dispositif qui changeait le ratio MIPS/MSU
portait sur l’ensemble de la facturation des logiciels IBM (MLC + OTC) alors que le nou-
veau dispositif ne porte que sur le MLC.
Processeurs spécialisés
Ces processeurs absorbent certains types de traitements (DB2, Java, Linux) en franchise
de coût logiciels MLC. De plus, ils coûtent environ 5 fois moins cher à l’achat que les
processeurs classiques (voir chapitre 3.2.2 pour plus d’informations sur leur mode de
fonctionnement et leurs avantages).
Les processeurs zIIP (DB2 DRDA) sont les plus utilisés (par environ 50 % des utilisateurs),
suivis des processeurs zAAP (Java), plus rares. Quant aux processeurs IFL (Linux), ils
gardent un caractère « exercice de style », et aucun client (à une notable exception près)
n’a jusqu’ici franchi le pas de la mise en production sur des IFLs.
Au niveau mondial, IBM fait état de références nettement plus flatteuses : Environ 30 %
des clients Mainframe possèdent au moins un IFL (fin 2010). Mais le constructeur ne
précise pas si cet IFL est utilisé, en production, en test. Il existe néanmoins un retard
spécifiquement Français en la matière.
L’adjonction de processeurs spécialisés permet, pour un investissement modique de

« donner de l’air » aux processeurs classiques, et donc de différer des investissements
de croissance. Il s’agit donc de ce point de vue d’une bonne opération si la nature de la
production y est éligible.
PAGE 11
En revanche la baisse correspondante de la facture logicielle MLC n’est pas systéma-
tiquement au rendez-vous, car le déport d’activité sur des moteurs spécialisés peut
n’avoir que peu ou pas d’impact sur la pointe de charge génératrice de facturation, ou
(ce qui revient au même) révéler une seconde pointe de charge aussi haute que celle qui
a été déplacée. L’évolution des pointes de charge (rolling 4h) résulte d’un équilibre com-
plexe et fragile, dont les évolutions ne sont pas toujours faciles à anticiper.
Enfin, on observe une convergence des types de processeurs spécialisés : Les proces-
seurs zAAP disparaissent au profit des zIIP. Ces derniers permettent désormais d’ac-
cueillir indifféremment des traitements DB2 et java.
Architecture Sysplex
L’écrasante majorité des utilisateurs a adopté l’architecture Sysplex en mode « priceplex »,
ceci pour bénéficier de conditions tarifaires intéressantes au niveau de la facturation
logicielle IBM MLC (agrégation PSLC). Cette technique permet en effet de réduire cette
facture d’environ 30 % par rapport à une architecture classique.
Une alternative à cette architecture est parfois observée : un site monoserveur et un

site de repli avec un serveur contenant uniquement des processeurs de backup (CBUs).
Cette solution, si elle était impensable il y a quelques années, peut désormais présenter
nombre d’intérêts, compte tenu de la fiabilité accrue des équipements informatiques.
Cependant, elle peut poser des problèmes d’exploitabilité et notamment de gestion des
arrêts. Même si elle n’est pas pour l’instant la plus répandue, cette solution n’est certes
pas à écarter, d’autant qu’elle permet de bénéficier sans aucune condition préalable des
mêmes avantages tarifaires que l’architecture priceplex.
Les clients l’ayant mis en œuvre ont constaté une baisse du MLC d’environ 2 % par
simple effet de consolidation. Ce faible pourcentage n’est néanmoins pas à négliger, vu
le volume global de l’enveloppe budgétaire que représente le MLC chez les grands uti-
lisateurs. Cette architecture est donc intéressante sur le plan économique et de la sim-
plification technique qu’elle apporte. Il faut néanmoins être conscient de ses limitations
si on décide de l’adopter.
2.1.2 SAN & Réseau
Infrastructures
Deux fournisseurs d’équipements SAN se partagent le marché : Brocade et Cisco.
A l’inverse de ce qu’on observe sur d’autres plateformes (FcOE dans le monde distribué),
aucune innovation technologique majeure n’est au programme des constructeurs. Seule
l’augmentation des débits (8 Gb/sec actuellement, 16 Gb/sec annoncés) figure au calen-
drier.
Il y a fort à parier qu’à l’instar des évolutions du stockage, celles-ci apparaîtront plus tar-
divement dans le monde mainframe que sur d’autres environnements plus « à la mode ».
Il est également vrai que les architectures actuelles donnent entière satisfaction en
termes de performances, sur un environnement mainframe bénéficiant déjà par nature
d’un fort taux de consolidation.
Protocoles et connectique
La connectivité ESCON nettement en perte de vitesse au profit de FICON reste néan-
moins présente sur certains sites, et utilisée par certains vieux périphériques lents en-
core en service.
PAGE 12
LiVRE BLANC
En matière de protocoles réseau, SNA et les contrôleurs de communications type 3745
ont totalement disparu au profit du protocole TCP/IP et des cartes OSA.
2.1.3 Stockage

Infrastructures
Trois acteurs se partagent le marché du stockage Mainframe : HDS nettement en tête,
suivi par IBM et EMC².
Evolutions technologiques
En matière d’évolution technologique, les tendances généralement observées sont les
suivantes :
• Remplacement des disques 3,5 pouces 15 000 tpm par des 2,5 pouces 10 000 tpm,
moins chers pour des performances sensiblement équivalentes.
• Remplacement des disques Fiber Channel par des disques SAS.
• Le stockage hautes performances (SSD) fait son apparition, mais son prix (3 fois
plus élevé que le stockage classique) le relègue pour l’instant à des usages très
spécifiques et marginaux.
• En revanche, apparaissent des disques midrange de grande capacité (600 Go ou
plus) qu’on peut dédier à des usages peu exigeants et qui permettent de réduire le
coût global du stockage.
• Le tiering fait donc son apparition dans le monde Mainframe, mais tous les construc-
teurs s’accordent à dire que les solutions bas de gamme de type SATA ne sont géné-
ralement pas adaptées au stockage primaire Mainframe, plateforme trop exigeante
sur le plan des I/O, (exception faite peut-être de la migration DFHSM). Le stockage
Mainframe reste donc essentiellement du stockage haut de gamme.
Logiciels embarqués dans les baies de stockage

Ces logiciels sont essentiellement dédiés à la performance (PAV, HyperPAV) et à la sécu-
risation des données (copie synchrone ou asynchrone). L’usage de ces produits se géné-
ralise nettement. Les technologies PAV/HyperPAV sont désormais des incontournables
du stockage Mainframe. En revanche, selon les fournisseurs, les coûts de ces produits
deviennent non négligeables, et grèvent de façon significative le coût du stockage, tant
en matière d’investissement que de coûts de fonctionnement.
A contrario, ces coûts logiciels sont les plus facilement négociables et peuvent consti-
tuer des sources de différences de prix significatives entre les fournisseurs dès lors que
la palette des logiciels utilisée est importante.
Mutualisation avec d’autres environnements

Cette possibilité existe techniquement chez tous les constructeurs. Elle est néanmoins
encore assez peu répandue chez les utilisateurs. Citons quelques raisons à cela :
• Volumétrie du stockage Open sans rapport avec le stockage Mainframe
• Complexité d’administration et risques associés
• Gains économiques non déterminants
• Problèmes d’organisation des équipes.
A contrario, et alors que les baies de stockage open et Mainframe sont strictement iden-
tiques à l’exception de la connectique, on constate encore trop souvent un écart de prix au
Go très important entre le stockage du monde open et le stockage Mainframe nettement
plus dispendieux (stockage haut de gamme s’entend). Ceci résulte le plus souvent de la
PAGE 13
capacité ou non des directions Achats de faire pression sur les fournisseurs pour aligner
à la baisse les coûts entre les deux mondes. Ceci reste un axe important de réduction des
coûts pour les clients qui ne sont pas parvenus à cette harmonisation des prix.
Evolution de la géométrie du stockage Mainframe

La granularité et donc la géométrie du stockage a profondément évolué ces dernières
années vers des géométries plus capacitaires :
•L es antiques models 3 ont quasiment disparu, au profit des models 9 et surtout des
models 27 qui constituent la majorité du parc. On rencontre également de manière
très anecdotique des models 18.
• Les models 9 sont réservés à des usages spécifiques (disques systèmes par
exemple). Les models 54, d’apparition plus récente restent encore assez peu répan-
dus. Ils peuvent encore poser quelques problèmes de performances mineurs quand
les contrôleurs qui les hébergent ne sont pas de toute dernière génération. Néan-
moins, il est fort probable que leur usage va se généraliser, en dépit également de
leur capacité unitaire importante qui peut poser des problèmes aux exploitations
gérant de faibles volumétries de données.
La capacité des model 3 devenue au fil du temps bien trop faible au regard des besoins,
avait pour conséquences :
• Un nombre de volumes à gérer atteignant les limites du possible.
• L’augmentation des fichiers multi-volumes et multi-extends, et plus généralement
l’augmentation des incidents opérationnels liés au manque d’espace.
Aujourd’hui on peut dégager les quelques tendances suivantes :

• La réorganisation du stockage peut être envisagée idéalement lors du renouvelle-
ment des contrôleurs. Il reste néanmoins possible d’y procéder hors de ce cadre en
utilisant les produits de déplacement des données non-disruptifs du marché (IBM,
Innovation par exemple).
• La réorganisation physique doit s’accompagner d’une réorganisation logique de
la gestion des données (politique DFSMS), et notamment de la réorganisation des
pools de volumes. En outre, et du fait de la baisse de la granularité, les fonctionnali-
tés apparues au fil du temps dans DFSMS (ex : Storage group de débordement) sont
désormais d’un précieux secours.
• Enfin, il est souhaitable de n’avoir à gérer au maximum que deux géométries, ce qui
rend d’autant plus nécessaire la refonte de la politique de gestion logique DFSMS
mentionnée précédemment.
Cas particulier de l’EAV (Extended Address Volume) :

Cette nouvelle géométrie de stockage qui permettrait à l’extrême de ne voir l’ensemble
du stockage que comme un seul volume logique est encore très peu répandue pour les
raisons suivantes :
•T rès peu d’applications ne peuvent se contenter des géométries « classiques »,
et notamment des model 54. Le créneau de l’EAV est donc a priori très marginal
•B eaucoup de prérequis logiciels.
•M igration très lourde et non transparente.
•S ystème récent, peu de recul, ou de retour d’expérience.
PAGE 14
LiVRE BLANC
2.1.4 Sauvegardes
Infrastructures
Oracle (ex Sun/Storagetek) est l’acteur majeur du marché, suivi par IBM. Mais les

équipements en place vieillissent et les intentions de renouvellement sont nettement
perceptibles :
• IBM reste globalement stable et conservateur (Virtualisation sur disque + bande ou

disque intégral)
• Oracle souffre d’un déficit d’image lié à une politique commerciale controversée
sur d’autres secteurs du marché. Outre ce manque de confiance dans la relation
commerciale, il est souvent reproché à Oracle un manque de visibilité technique et
commerciale sur les évolutions de son offre. Néanmoins, ce fournisseur propose
une offre sérieuse et intéressante, assez semblable en termes de positionnement à
celle d’IBM.
• EMC2 fait une entrée sur le marché de la sauvegarde mainframe, en mettant l’ac-
cent sur des technologies novatrices telles que la déduplication (cf ce qui suit).
Ce constructeur ne propose qu’une solution de virtualisation sur disque.
• HDS n’est pas actuellement présent sur ce marché, mais devrait annoncer des
nouveautés fin 2011/Début 2012.
Evolutions technologiques
La virtualisation des dérouleurs associée à des caches de grande capacité est connue
depuis plusieurs années et continue d’exister. En outre, la technologie des bandes
virtuelles fait son apparition dans le monde mainframe. Il s’agit en fait de contrôleurs
disques SATA émulant des bandes de capacité variable.
Principaux avantages :
• Coût
• Elimination des problèmes de remplissage des supports physiques qui deviennent
de plus en plus capacitaires. La virtualisation n’en est que plus nécessaire.
• Suppression du ML1 DFHSM.
• Amélioration des temps de sauvegarde.
• Déduplication possible. De l’aveu même de ses plus chauds partisans, cette techno-
logie reste cependant moins intéressante sur le Mainframe que sur d’autres envi-
ronnements, de par la nature des données gérées. En tout cas, une analyse fine
des types de données est indispensable avant de se déterminer. En outre, il ne faut
pas perdre de vue qu’en cas de perte physique de données, la reconstruction des
données peut s’avérer plus problématique que pour un stockage classique, en dépit
des assurances des constructeurs. Il sera donc intéressant de suivre de près les
premières expériences dans ce domaine.
• Gain en espace au sol et en consommation énergétique.
Globalement les nouveaux systèmes quelle que soit la technologie retenue s’avèrent
plus simples à gérer du point de vue de l’utilisateur.
La percée de ces systèmes a été rendue possible grâce à l’évolution des technologies de
réplication à distance synchrones et surtout asynchrones. Ces techniques permettent
désormais de disposer, sur des sites distincts proches ou éloignés, de copies de sau-
vegardes sans l’obligation de transporter physiquement un média d’un site sur l’autre.
Ceci simplifie et fiabilise sensiblement les procédures de PRA. On trouvera ci-après un
schéma décrivant les architectures les plus communément rencontrées en la matière.
PAGE 15
Néanmoins, des systèmes basés sur les classiques supports physiques de type bande
poursuivent leur carrière, associés à des caches de grande capacité et à des dérouleurs
virtuels (ex : IBM, Oracle). Ils permettent d’obtenir des performances équivalentes aux
systèmes à bandes virtuelles. La capacité unitaire des bandes poursuit par ailleurs son
augmentation.
Ces systèmes restent compétitifs et même incontournables quand :

• Les medias amovibles sont indispensables pour des contraintes métiers ou de
sécurité.
• Les volumes de données sont importants (plusieurs milliers de To).
En outre, tous les systèmes proposent des dérouleurs virtuels en nombre suffisant (256),
de telle sorte qu’il devient moins nécessaire de recourir à des produits de mutualisation
des dérouleurs (ex : CA-MIM).
En conclusion, nous constatons que la technologie des bandes virtuelles propose des
innovations intéressantes qui permettent dans de nombreux cas de faire baisser les
coûts de la sauvegarde. Sur ces systèmes, proches de contrôleurs disques de milieu de
gamme, l’émulation des bandes se trouve conservée pour des raisons de compatibilité
avec les traitements existants. C’est la seule raison qui pour l’instant impose l’émulation
des supports bandes d’antan sur des systèmes en fait basés sur du stockage disque.
Pour combien de temps encore ?
2.1.5 Architecture technique & Organisation
Architecture technique
L’architecture la plus fréquemment rencontrée se compose de 2 datacenters en mode
campus (2 sites proches distants de moins de 20 km). Cette architecture permet de dis-
poser de systèmes de réplication synchrone des données entre les 2 sites ; ce qui assure
un très bon niveau de sécurité et de continuité de service.
PAGE 16
LiVRE BLANC
Certains clients disposent également de sites de secours éloignés (ex : 500 km du site
primaire). La réplication des données entre le(s) site(s) primaire(s) et le site de secours
s’effectue alors en mode asynchrone. Ces sites de secours sont en fait des sites de repli
inactifs en marche normale, et utilisables dans le cadre d’un PRA consécutif à la des-

truction totale ou partielle des sites primaires.
Les évolutions technologiques et économiques ont évidemment un impact sur les choix
d’architecture qui sont faits en la matière, principalement en matière de stockage et
sauvegarde. Citons principalement :
•D ans le cadre d’une architecture primaire composée de 2 sites proches, il était
généralement habituel de répartir les données sur les 2 sites de façon à minimiser
les flux inter-sites et ainsi la bande passante. Dans ce cas, les copies synchrones
des données étaient également réparties à l’inverse sur les 2 sites. On parlait de
copie synchrone croisée (fig 1).
La bande passante n’étant plus désormais un goulot d’étranglement, cette tech-

nique tend à disparaître, car elle complique inutilement les procédures de secours
en cas de perte du stockage primaire. De plus, elle est incompatible avec des solu-
tions de PRA automatisée telles que GDPS (IBM). En conséquence, il est désormais
communément admis que la meilleure solution consiste à dédier intégralement les
baies disques, soit au stockage primaire, soit à la copie synchrone (cf fig 2).
PAGE 17
Inconvénient : Cela oblige à aligner par le haut le dimensionnement des baies, sauf à
tolérer une légère dégradation des performances en mode PRA. Ce mode de fonctionne-
ment revient donc globalement plus cher.
• La copie synchrone s’est généralisée, et tend à être utilisée pour l’ensemble des
données. Ceci permet de simplifier sensiblement les procédures de gestion et de
secours, pour un surcoût relativement faible, compte tenu de la baisse des prix du
stockage.
• La virtualisation du stockage telle que mise en œuvre dans le monde distribué n’a
que peu d’intérêt sur la plateforme mainframe, principalement pour les raisons sui-
vantes :
-L es volumes de données sont considérablement plus faibles que dans le monde
distribué, et donc le nombre de contrôleurs disques également.
-L e Mainframe n’utilise essentiellement que des baies de disques haut de gamme.
Il n’est donc pas nécessaire de hiérarchiser des baies de niveaux de performances
différents derrière une couche de virtualisation.
-L ’accès aux données depuis un ou plusieurs Mainframes et depuis plusieurs par-
titions est natif et complètement standardisé : il est inutile d’ajouter une couche
supplémentaire d’abstraction.
•L a duplication asynchrone des sauvegardes tend à se généraliser, et remplace peu
à peu les classiques sauvegardes externalisées. Ceci a été rendu possible par la
baisse des coûts des équipements de sauvegarde et des coûts des liens télécoms,
ces réplications se faisant la plupart du temps sur des sites distants.
• D’une manière générale, la mutualisation des équipements Mainframe avec
d’autres plateformes est assez peu répandue, même si les composants de base,
notamment en matière de stockage sont identiques. Les économies réalisables par
ce type de mutualisation sont généralement assez faibles au regard des risques et
des contraintes qui en découleraient. Au surplus, les matériels mainframe ne sont
pas toujours compatibles, notamment en termes de connectique avec d’autres envi-
ronnements.
L’apparition des serveurs hybride zEntreprise modifiera peut-être quelque peu la
donne, mais en matière de stockage et sauvegarde, rien ne permet d’anticiper de
changement radical du paysage à court terme.
Datacenters
Les sites informatiques hébergeant une entreprise et ses filiales sont majoritaires.
On observe également une part significative d’entreprises mutualisant avec d’autres
leurs centres de calcul. Ceci pose évidemment des problèmes de sécurité, mais retient
l’attention de nombreux acteurs en raison des économies réalisables par la mutualisa-
tion des coûts d’un centre de calcul.
Infogérance : En avoir ou pas

La position des entreprises en la matière est essentiellement liée à une stratégie globale
de maîtrise de son système d’informations.
Le risque de perte de pouvoir dans un domaine considéré par certains comme essentiel
milite donc en faveur de la gestion directe, indépendamment de toute autre considération.
Au surplus, de bonnes performances dans les « Benchmarks » standards (type Compass)
enlèvent autant d’arguments à une solution d’infogérance (Aide-toi, le ciel t’aidera).Au
total, un peu plus de la moitié des entreprises choisissent cette dernière solution.
PAGE 18
LiVRE BLANC
Infrastructures en leasing ou investies ?
Même si elle n’est pas majoritaire, loin s’en faut, la location des infrastructures
Mainframe (re)devient une alternative intéressante pour certains clients. Elle relève
dans une certaine mesure de la même logique pluriannuelle prédictive en matière de

budget, à l’instar des contrats logiciels pluriannuels.
2.1.6 Sécurisation
Disponibilité continue & Haute disponibilité

La solution de disponibilité continue passe par l’architecture Sysplex. Mais celle-ci, bien
qu’utilisée quasiment par tous pour des raisons financières (priceplex, cf 2.1.1), l’est en
revanche beaucoup moins pour répondre à des besoins de disponibilité continue du fait de :
• La complexité de mise en œuvre et le montant du ticket d’entrée.
• Le surcoût de ressources induit par cette architecture (environ 10 %).
• La complexité de gestion dans la vie courante.
• Le surcoût global très important d’une telle solution par rapport à une solution
classique.
L’expérience prouve en outre qu’en cas d’incident majeur, les procédures de redémar-
rage ou de secours ne sont pas toujours correctement maîtrisées.
Tous ces facteurs constituent un frein à la mise en œuvre de cette solution, qui ne se
trouve déployée que lorsqu’un impérieux besoin s’en manifeste. En particulier, ce type
d’architecture se rencontre là où des besoins ou conditions business spécifiques sont
présents, par exemple pour un site de réservations en ligne.
Néanmoins, ce problème de surcoût et de complexité lié à des architectures cluster

existe sur toutes les plateformes. Le mainframe s’en tire très honorablement dans ce
domaine.
L’exigence de disponibilité continue se rencontre dans tous les secteurs d’activité, mais
concerne une minorité d’applications (ex : applications monétiques dans le secteur ban-
caire, logistiques dans le monde industriel, etc.)
Les architectures classiques restent néanmoins majoritaires, et assurent un service de
« haute disponibilité », rendu possible par :
•U ne réduction des pannes matérielles liée aux progrès constatés des 10 dernières
années en matière de fiabilité intrinsèque (MTBF).
•U ne augmentation du nombre des évolutions techniques réalisables dynamiquement
(i.e. : sans interruption de service).
Tout ceci permet une diminution sensible du nombre global d’arrêts pour maintenance
ou panne mineure (de l’ordre de 5 maximum par an).
PRA
Tout d’abord, nous constatons que toutes les entreprises interrogées disposent d’un
PRA, et prennent donc en compte la sécurité de leurs systèmes d’informations face à
des risques majeurs.
Les PRAs ont évidemment largement profité des évolutions technologiques et d’archi-
tecture évoquées en 2.1.6. Ils ont notamment gagné en fiabilité, en performance (RPO/
RTO) et en simplicité.
PAGE 19
Actuellement, la plateforme mainframe est sans doute une des meilleures en ce domaine
(elle sert même de modèle aux autres). Certaines architectures sont mêmes garanties
avec un RPO nul (avec deux sites en mode campus), et un RTO inférieur à une minute.
On peut faire néanmoins quelques remarques :

•L es durées d’indisponibilités constatées lors de tests PRA ou contractualisées par
le biais de SLA sont en retrait par rapport aux attentes des utilisateurs.
• Il reste nécessaire d’harmoniser les performances PRA des différentes plateformes.
A l’heure où les applications se trouvent le plus souvent réparties sur plusieurs
plateformes, quel intérêt , après la perte d’un datacenter, de redémarrer un main-
frame en 24h si d’autres composants applicatifs redémarrent eux en 5 ou 10 jours ?
• Enfin, si la quasi-totalité des entreprises organisent des tests de PRA pour vérifier
périodiquement la fiabilité des procédures, il convient de préciser que la perfor-
mance d’un PRA tient compte également de facteurs humains tels que :
- Entraînement et formation des personnels
- Prise en compte de la baisse de la performance en conditions de stress.
- Travail en équipe.
- etc.
Ces facteurs, quoique généralement pris en considération, ne figurent qu’à l’arrière-

plan des préoccupations. Pourtant, il y a peut-être là une marge importante de progrès
dans les performances d’un PRA.
Le secteur du transport aérien, où la formation et l’entraînement des personnels navi-
gants sont primordiaux et répondent à des exigences règlementaires fournit un notable
contre-exemple. Il a donc été tout naturel dans ce secteur d’en user de même pour les
personnels de production informatique.
2.2 Analyse et positionnement des fournisseurs de logiciels

Mainframe
Avertissement :
Les informations qui suivent synthétisent les réponses de 15 entreprises adhérentes au CRIP à
l’enquête effectuée au printemps 2010. Cette enquête portait sur les logiciels d’infrastructure
uniquement (OS, SGBD, moniteurs transactionnels, outils de supervision, etc.) et non sur les
logiciels applicatifs. Manque d’expérience dans l’exercice, manque de temps aussi, il apparait
que notre enquête a échoué à faire remonter certaines informations, en particulier concer-
nant les petits éditeurs et l’utilisation réelle de certaines technologies (famille IMS). Il faut donc
prendre ces informations avec la distance qui s’impose, en attendant une prochaine enquête qui
visera plus juste.
Contexte général
Pour mémoire, rappelons quelques éléments de contexte. Selon IDC, alors que le mar-
ché du matériel et des systèmes d’exploitation pour Mainframe s’élevait à 8,5 milliards de
dollars en 2009 (dont 3 milliards pour la zone géographique européenne), le logiciel repré-
sentait 24,5 milliards de dollars la même année. L’achat d’un euro de serveur Mainframe
entraîne donc l’achat de trois euros de logiciel environ.
IBM reste très discret sur la ventilation de ses revenus par lignes de produits. Cependant
IDC estimait, toujours en 2009, que le fournisseur contrôlait environ 40 % de ce marché lo-
giciel Mainframe, ce que notre enquête semble confirmer, IBM y arrivant largement en tête.
PAGE 20
LiVRE BLANC
Par ailleurs, ce marché logiciel a profondément évolué durant les années 90 avant de se
stabiliser et ceci pour plusieurs raisons :
•L e contexte technologique général : la montée en puissance de l’informatique distri-

buée a diminué la demande de solutions Mainframe.
• Le grand mouvement de fusions-acquisitions dans l’industrie du logiciel a réduit le
nombre de fournisseurs et étendu leurs gammes
• Le grand travail de consolidation effectué par les entreprises, soit pour rationaliser
leurs infrastructures, soit à l’occasion de fusions-acquisitions a réduit le nombre de
datacenters et d’entreprises utilisatrices, ce qui a mécaniquement limité l’usage et la
dispersion des comptes.
• Sous l’effet de la consolidation, les organisations clientes devenues plus importantes
ont souhaité s’adosser à de grands fournisseurs et ont accentué le phénomène de
concentration en limitant l’appel aux petits éditeurs. Ce qu’un client de taille modeste
osait faire en s’engageant auprès d’un petit fournisseur, les grandes structures ont
hésité à le faire en raison des risques inhérents aux petites structures : pérennité,
capacité à assurer le support, capacité à l’innovation, etc.
• La perception du risque lié aux petits éditeurs a été accentuée par l’accélération du
rythme d’évolution de la plate-forme imposé par IBM. En effet, à la fin des années
90, le constructeur a décidé de pratiquer un renouvellement rapide des versions de
certains de ses logiciels Mainframe, dont OS/390 qui devait évoluer tous les six mois.
Cet état de fait qui dura quelques années faisait porter une pression sur les éditeurs
logiciels, ne serait-ce que pour suivre ces innovations en apportant à leurs produits les
adaptations minimales nécessaires et en les requalifiant.
• Les modèles d’achats des grandes entreprises ont évolué en même temps, avec la gé-
néralisation des négociations globales pluri-annuelles. Elles visaient à apporter un le-
vier de négociation plus important, mais supposaient de s’adresser à des fournisseurs
dotés d’un catalogue suffisant pour que la démarche porte pleinement ses fruits. Nos
entreprises sont alors passées d’une logique d’achat ponctuel, isolé, en réponse à un
besoin précis, à une logique plus globale, moins dictée par des considérations tech-
niques, mais plutôt centrée sur la stabilité, la pérennité des solutions, là encore au
détriment des petits fournisseurs. Effet de bord de ces nouvelles stratégies d’achat :
elles ont conduit assez régulièrement à voir arriver dans les entreprises des logiciels
‘sur étagère’, des logiciels non-utilisés parce que dans ces négociations globales les
fournisseurs rajoutaient des produits dans l’espoir de se créer ensuite des revenus de
maintenance.
Tout ceci s’est traduit d’une part par la disparition d’un grand nombre d’éditeurs, d’autre
part par la création de quelques catalogues très étoffés par les rachats. Aujourd’hui le pay-
sage apparaît largement stabilisé, et solidement structuré autour de quelques ténors.
2.2.1 Fournisseurs Principaux
Nous pouvons distinguer trois catégories de fournisseurs : les trois qui possèdent une
offre très étendue et s’avèrent à peu près incontournables, ceux qui possèdent un cata-
logue conséquent mais plus spécialisé et enfin les acteurs de niche.
Les trois incontournables

On trouve dans cette catégorie IBM, CA et BMC. Historiquement présents dans le do-
maine, ils ont su constituer au fil du temps une offre très complète et occupent une
position de force.
PAGE 21
• IBM règne en maître sur les systèmes d’exploitation Mainframe à l’exception de
Linux qui ne représente qu’une activité marginale, mais aussi sur les moniteurs
transactionnels et les bases de données.
• CA possède une position forte dans les domaines de la sécurité et des outils
pour bases de données, du fait de son historique. Cependant, la sécurité reste un
domaine concurrentiel.
• BMC a surtout une assise solide dans le domaine de la supervision.
2.2.2 Fournisseurs Secondaires
Les spécialistes de taille importante

On trouve ici des éditeurs à présence internationale et de taille conséquente, mais plutôt
spécialisés sur deux ou trois domaines que largement polyvalents comme les précé-
dents.
•C
ompuware possède par exemple une forte emprise dans le secteur des outils
d’aide au développement – débugging, analyse de trace, analyse de performances,
création de jeux d’essais, manipulation de données, analyse d’incidents, etc. Après
avoir acquis le leadership dans ces domaines il y a déjà plusieurs années, l’éditeur a
su conserver et renforcer cette position, au point de se retrouver un temps presque
dépourvu de concurrents.
• ASG, bien que peu représenté dans notre enquête, possède un catalogue important
dans trois domaines : la supervision avec TMON, l’industrialisation de la production
avec le rachat des produits Cortex et l’aide au développement.
• Software AG : ce grand éditeur allemand pourtant bien implanté mondialement -

(second sur son marché, quatrième en Europe et dans le Top 25 mondial) - n’a ja-
mais percé en France. Il commercialise en particulier une base de donnes (Adabas)
et, un moniteur transactionnel (ainsi que l’environnement de développement asso-
cié), ce qui en fait un des très rares concurrents d’IBM sur ces produits.
Les acteurs de niche

Ils possèdent un ou quelques produits très ciblés et sont très bien implantés, mais avec
des domaines d’activité restreints.
• Axway : règne sur les transferts de fichiers Mainframe. En effet l’entreprise qui pos-
sédait Interpel (Pelican) a racheté CFT, soit les deux seuls produits du marché.
• Macro4 : a développé une concurrence à Compuware exclusivement dans le domaine

des outils d’aide au développement : debugging, analyse de trace, manipulation de
données.
• Infotel : cet éditeur se cantonne au domaine des bases de données, IMS et surtout
DB2, avec des outils d’aide à l’administration et de manipulation. Cet éditeur reste
de plus très franco-français.
PAGE 22
LiVRE BLANC
• Beta systems : éditeur reconnu dans les domaines de l’automatisation de la pro-
duction et de l’output management. Il est étonnant de ne pas le voir apparaître
dans notre enquête, même s’il se trouve traditionnellement plutôt implanté en Alle-
magne, en Suisse et dans les pays nordiques.

• RedHat et Suse-Novell : ces deux éditeurs de distributions Linux n’appartiennent
pas vraiment à la famille des spécialistes des environnements Mainframe mais pro-
curent avec la bénédiction d’IBM des versions spécifiques de leurs OS qui fonction-
nement sur plates-formes z.
• Syncsort : acteur uniquement actif dans les domaines du tri et de la manipulation de

données.
Bien qu’ils n’aient pas fait l’objet de cette enquête, nous devons aussi citer les logiciels
techniques associés aux composants d’infrastructure de stockage chez EMC² ou HDS
et de sauvegarde chez Oracle-Sun-Storagetek. Bien entendu présents sur Mainframe,
ces logiciels n’ont cependant qu’un ancrage relatif sur les plates-formes, puisqu’ils dé-
pendent entièrement des choix de matériels de stockage et de sauvegarde.
Notons enfin qu’il reste une population de petits éditeurs spécialisés qui jadis commer-
cialisaient des solutions assez répandues, et vivent désormais sur le parc installé.
Répétons notre avertissement : notre enquête a échoué à faire ressortir les petits édi-
teurs dont nous connaissons pourtant l’existence et l’utilisation des produits. Cela tient
à la façon dont nous avons travaillé, et à la mise en forme de notre questionnaire. Une
prochaine enquête permettra de faire le point sur ces fournisseurs, et de mettre en avant
ceux que nous avons oubliés.
2.3 Résultats de l’enquête

Par grandes catégories logicielles, sont utilisés chez les adhérents du CRIP par ordre d’im-
portance :
> Pour les Systèmes d’exploitation
1. I BM omniprésent avec ses multiples générations de systèmes d’exploitation

Mainframe,
2. RedHat avec son zLinux
3. Suse avec son zLinux
> Pour les Moniteurs transactionnels
IBM avec par ordre de popularité CICS, Websphere et IMS
Résultat peu surprenant. D’une part il y eut toujours peu de concurrents sur ce marché car
les produits y exigeaient un haut niveau de fiabilité et se montraient compliqués à dévelop-
per et à maintenir. D’autre part, IBM a littéralement balayé la concurrence en accélérant les
rythmes de ses mises à jour de produits et en investissant dans son propre environnement.
PAGE 23
> Pour les SGBD
1. IBM avec DB2

2. Software AG avec Adabas, cité une fois
IBM a totalement conquis ce domaine au point de ne plus compter qu’une concurrence très
marginale. Il y a 20 ans pourtant il existait plusieurs bases de données sur Mainframe, dont
Adabas, Datacom, IDMS et d’autres. Il ne reste quasiment plus que du DB2 – massivement –
des résidus d’IMS/DB (DL1) et quelques rares utilisateurs d’autres produits. A la fin des
années 80, IBM ne possédait pourtant pas de base de données relationnelle, il n’existait
pas de SQL IBM. Le constructeur a alors choisi de concurrencer Oracle et de se doter d’un
outil réellement compétitif avec DB2. En investissant largement pour développer DB2 sur
plate-forme z mais aussi sur l’ensemble des autres OS, et après des débuts difficile, la base
bien que chère a su conserver un différentiel technique avec des avantages en termes de
fonctionnalités, performances et robustesse. En réussissant ce pari technique, IBM a fait
disparaître la concurrence au fil des ans.
Nous avons été surpris de ne pas voir apparaître IMS/DB dans cette liste. Ce produit reste
utilisé, mais au titre d’un héritage historique, dans des entreprises qui souhaitent éviter les
coûts de portage, ou dans des cas spécifiques où la base hiérarchique se montre fonction-
nellement bien adaptée.
> Pour les ordonnanceurs
1. IBM avec TWS

2. BMC avec Control-M
3. CA avec CA7
Il subsiste une réelle concurrence dans le domaine des ordonnanceurs, avec de nombreux
acteurs crédibles possédant de bons produits dont certains largement diffusés. Il existe
d’ailleurs d’autres produits non-référencés ici mais assez populaires, comme CA Scheduler
ou Cortex d’ASG, et même des produits moins connus mais déployés.
> Pour la sécurité
1. IBM avec RACF

2. CA avec Top Secret et ACF2
Dans ce domaine, les deux fournisseurs IBM et CA sont notoirement en concurrence. Top
Secret est très populaire en France alors qu’ACF2 a plus de succès aux États-Unis. CA a
pris des parts de marché à IBM à une époque où RACF ne donnait pas satisfaction à ses
utilisateurs. Depuis IBM a rattrapé son retard, et repris des parts de marché à CA. Les deux
produits sont aujourd’hui techniquement très proches.
> Pour la supervision MVS z/OS
1. BMC avec Mainview for MVS

2. IBM avec Omegamon pour MVS et RMF
3. CA avec Sysview (cité une fois)
PAGE 24
LiVRE BLANC
Un autre secteur assez concurrentiel. BMC y reste le leader avec sa suite Mainview, héritée
de Boole & Babbage. Pendant longtemps IBM n’a pas investi dans ce domaine, considérant
qu’il suffisait de fournir des outils de base aux utilisateurs, qui pouvaient se tourner vers
des éditeurs tiers pour des logiciels plus sophistiqués. Finalement, IBM a changé d’avis et

racheté Candle, et en particulier la suite logicielle OmegaMon pour revenir sur ce marché.
CA possède quelques produits concurrents, mais cette activité, la supervision des perfor-
mances techniques, ne constitue pas leur cœur de marché.
> Pour la supervision CICS
1. BMC avec Mainview for CICS

2. IBM avec OmegaMon for CICS
3. ASG avec TMON CICS (cité une fois)
> Pour la supervision IMS
1. IBM avec OmegaMon for IMS

2. BMC avec Mainview for IMS
> Pour la supervision DB2
1. BMC avec Mainview for DB2

2. IBM avec OmegaMon for DB2
3. CA avec Insight (cité une fois)
4. ASG avec TMON DB2 (cité une fois)
Comme pour la supervision z/OS , on constate dans ces trois activités la forte présence de
BMC, au coude à coude avec IBM qui exploite désormais les produits de Candle. Il est assez
surprenant de voir si peu apparaître les outils TMON d’ASG alors qu’ils ont joui d’une large
diffusion il y a quelques années. ASG a probablement souffert de son statut de modeste
éditeur indépendant alors que se multipliaient les vagues de consolidation. De plus, ASG
procède depuis plusieurs années à des séries de rachats qui ont largement étendu son
offre vers les systèmes ouverts d’une part et vers le BSM de l’autre.
> Pour les outils DB2
1. C A avec la famille des Database Management Solutions for DB2 for z/OS (Platinum,
RC/Migrator-query-update, etc.)
2. IBM avec les DB2 Utilities/Tools et Optim (cité une fois)
3. Infotel avec Master-Util
Encore un marché très actif, dans lequel CA occupe une position de primauté depuis le
rachat de Platinum. IBM s’y est lancé il y a peu, et y reste faiblement représenté du fait de
la jeunesse de ses outils développés en interne. Infotel est un petit acteur franco-français.
BMC dispose d’une suite complète fonctionnellement équivalente à celle de CA, on s’étonne
de ne pas le voir apparaître ici.
PAGE 25
> Pour la supervision Réseaux
1. IBM avec NetView et OmegaMon for IP

2. BMC avec Mainview for IP
3. ServicePilot avec IPwatch for z/OS (cité une fois)
Le réseau est un des domaines dans lesquels IBM n’a jamais renoncé à fournir des outils
de supervision, ce qui explique la large représentation de NetView.
> Pour l’automatisation
1. IBM avec System Automation (et GDPS pour le PRA)

2. BMC avec Mainview AutoOperator
On retrouve ici deux des produits majeurs du marché, auxquels il faudrait ajouter par
exemple ceux de CA qui n’apparaissent pas dans notre enquête.
> Pour le développement
1. IBM avec dans l’ordre de popularité : COBOL, Assembleur, C, Java, FORTRAN, PL/1, QMF
2. Compuware avec Xpediteur et FileAid DB2 (cité une fois)
3. Macro4 avec TraceMaster (cité une fois)
4. Software AG avec Natural (cité une fois)
IBM fournit de façon logique les compilateurs et les langages pour sa plate-forme. On re-
trouve ensuite Compuware, le spécialiste des outils d’aide au développement qui possède
une suite complète. Macro4 a réussi à entrer sur ce marché avec une offre qui se voulait
directement concurrent de celle de Compuware, et ce à une époque où de nombreux clients
éprouvaient de graves difficultés commerciales avec cet éditeur devenu l’acteur quasiment
unique du domaine. Le positionnement opportuniste de Macro4 lui a donc bien réussi, et
a contribué à réinjecter de la concurrence dans ce secteur. Notons aussi qu’IBM recom-
mence à s’y intéresser depuis quelques années, et fournit lui aussi une suite logicielle com-
plète d’aide au développement, qui n’apparait pas dans cette liste, peut-être du fait de son
manque de maturité. La présence de Software AG s’explique par l’existence d’un utilisateur
Adabas dans les entreprises ayant répondu à notre enquête.
> Pour la gestion des configurations
1. CA avec Endevor
2. ASG avec CCC
3. IBM avec SCLM (cité une fois)
Sur ce marché, CA est le grand leader historique et dispose de l’un des seuls produits
existants. ASG se fait une place car cet éditeur se positionne très clairement dans les do-
maines de l’industrialisation de la production dont la gestion des configurations constitue
une branche. BMC n’a pas d’offre dans le domaine, et IBM y reste particulièrement faible.
> Pour le transfert de fichiers
1. Axway avec CFT, Interpel,

2. DDMS avec Tom
PAGE 26
LiVRE BLANC
Comme expliqué plus haut, Axway a acquis une position quasi hégémonique sur cette spé-
cialité par rachat des concurrents. L’historique TOM a presque disparu.
Synthèse : Stabilité

Constatons d’abord que tous les secteurs du logiciel pour Mainframe ne connaissent pas le
même dynamisme. Alors qu’un sujet comme l’administration des bases de données reste
en mouvement du fait des innovations technologiques continues apportées à DB2, des su-
jets comme la gestion des configurations, la sécurité ou la supervision bougent peu. Le
Mainframe est un marché mature, avec des produits bien installés, des pratiques rodées, et
qu’on ne change que rarement. De plus, la maturité des produits fait que les seules raisons
d’en changer tiennent en règle générale aux pratiques commerciales des éditeurs plutôt
qu’aux limitations techniques. Bref, il n’est pas rare que des produits soient en place depuis
15, 20 ou 25 ans, et perdurent car leur qualité et leur pertinence a été largement prouvée.
Un grand événement a pourtant menacé il y a quelques années ces équilibres. IBM affirmait
alors que si sa plate-forme souffrait de coûts prohibitifs, ce n’était pas de sa faute, mais de
celle des ISV indélicats qui facturaient beaucoup trop cher leurs outils. IBM a alors annoncé
vouloir développer, par acquisitions ou en interne, des lignes de logiciels dans les domaines
jusqu’ici non-couverts par ses soins pour relancer la concurrence et proposer aux clients
des solutions techniquement valides et financièrement performantes. Ainsi sont apparus
les outils d’aide au développement et d’administration des bases de données, tandis que
le rachat de Candle dotait le constructeur d’une offre dans le domaine de la supervision.
Quelques années plus tard, force est de constater que la pénétration de ces produits reste
faible, et surtout que les BMC, CA et Compuware n’en ont pas pour autant perdu leur place.
Là encore une preuve de la remarquable stabilité des parcs.
PAGE 27
3 MAÎTRISE DES COÛTS SUR PLATE-FORME Z
La cartographie a donc été dressée aux deux chapitres précédents. Nous avons identifié
le rôle du Mainframe, nous avons tracé le portrait technique de son environnement, nous
avons identifié son écosystème de fournisseurs : tous les acteurs sont en place.
Le long chapitre qui suit se divise en trois thèmes majeurs, dont découlent plusieurs fa-
milles de démarches :
• La maitrise des coûts logiciels

• La maitrise des coûts d’infrastructures
• La maitrise des coûts de fonctionnement
Ce découpage et ces thèmes sont le résultat des travaux du groupe, travaux conduits à
partir des expériences des uns et des autres, des pratiques mises en œuvre et de leurs
résultats et des sujets considérés comme importants (pour ne pas dire majeurs) pour la
maitrise des coûts.
Il existe certainement d’autres pratiques, d’autres thèmes. Le sujet reste vaste et d’actua-
lité. Nous ne doutons pas que chacun fasse preuve d’imagination et d’initiative au sein de
son entreprise.
Nous espérons cependant que les thèmes traités ci-dessous vous permettront d’envisager
de nouvelles pistes ou vous conforteront dans votre démarche.
3.1 Maîtriser ses coûts logiciels
3.1.1 Démarche contractuelle avec IBM
Il importe de bien connaître la palette des licences et contrats d’IBM. Une démarche
volontariste s’impose pour choisir les formules les mieux adaptées.
Rappelons que si chaque logiciel fait l’objet d’un modèle de facturation décrit dans une
licence, les contrats sont des accords tarifaires offrant des marges de négociation plus
importantes mais portant en principe sur plusieurs logiciels. Toutes les entreprises utili-
satrices possèdent des licences, toutes ne négocient pas de contrats. Parmi les contrats,
le plus en vue reste sans aucun doute ESSO (Enterprise Services and Software Options)
que nous allons aborder ici.
IBM a créé au fil des ans une jungle de modèles de licences et de contrats dans laquelle
s’égarent les utilisateurs (comme l’illustre le schéma ci-dessous). Opération dont on
peut soupçonner qu’elle vise à soutirer aux clients le maximum d’argent. Cette pratique
donne une mauvaise image de la plate-forme Mainframe, ce qui risque de pousser les
décideurs en entreprise à s’en séparer pour privilégier des modèles tarifaires plus com-
préhensibles, (notamment les licences dites libératoires du monde distribué, mais at-
tention, les récentes évolutions technologiques dans le monde distribué – virtualisation
en tête - rendent les modèles de licences qui s’y appliquent de plus en plus complexes).
De plus, cette façon de faire impose aux entreprises d’acquérir et de maintenir à niveau
PAGE 28
LiVRE BLANC
les compétences suffisantes pour traiter cette problématique tarifaire et faire vivre ces
contrats. Ce n’est pas toujours le cas : certaines entreprises peinent à développer et en-
tretenir ces compétences. Pourtant, tous les membres du Groupe de Travail s’accordent
pour dire qu’une analyse approfondie reste le seul moyen pour tirer son épingle du jeu.

Depuis les années 2000, la majorité des clients Mainframe a basculé dans le mode de
tarification dit « à la charge ». Le slogan IBM était alors “Pay only for what you need “.
Belle promesse. Ce type de facturation apparait en effet à première vue comme plus
favorable que ceux pratiqués auparavant, quand la seule puissance machine détermi-
nait le montant des licences. Et ce d’autant plus que les configurations ont largement «
explosé » en taille ces dernières années.
Néanmoins, tout n’est pas aussi rose que l’on pourrait le croire car cette facturation
dite MLC s’avère très complexe et subtile. Il faut impérativement se l’approprier pour
commencer à en tirer des bénéfices notables. Pour résumer la situation, tous les logi-
ciels évoqués au chapitre précédant et qui ne possèdent pas de concurrents directs (z/
OS, IMS, DB2, …) sont facturés en MLC (Monthly Licence Charge, mode location/mainte-
nance), et plus précisément en xWLC machine par machine (ou par groupe de machines
pour les clients éligibles à l’agrégation Sysplex PSLC). Il existe aussi d’autres types de
facturation à la charge MLC, tels zNALC et SALC, mais moins répandus.
Les chapitres suivants pointeront quelques astuces et recommandations pour maitriser

cette tortueuse facturation WLC voire même réduire visiblement le coût à la charge de la
plate-forme Mainframe.
Les autres logiciels, portant sur des fonctions théoriquement ouvertes à la concurrence,
sont facturés selon le modèle OTC (One Time Charge, mode achat/maintenance). Notre
« théoriquement » a son importance, car dans les faits, ce type de facturation se voit sou-
PAGE 29
vent encadré par un contrat global d’entreprise. Le plus connu parmi les clients sondés
est le contrat ESSO.
Le contrat ESSO, pluriannuel, se compose de plusieurs éléments facturables (selon les

modèles MLC, OTC, IPLA pour les logiciels distribués, etc.) et correspond à l’approche
globale que nous traiterons dans le chapitre suivant. Si effectivement, l’effet de masse
permet à l’entreprise d’obtenir une remise non négligeable, ce contrat peut devenir, au
final, très opaque et discutable. En particulier en ce qui concerne les avantages réels
qu’il apporte à la plate-forme Mainframe. En effet :
• La mise en concurrence des produits zOTC devient très délicate voir inutile au sein
d’un ESSO. En général dans cette situation, un produit zOTC IBM se verra remplacer
par un autre produit IBM IPLA du monde distribué alors que la finalité devrait être
de basculer simplement d’un produit z sur un produit concurrent, sans rajouter au
contrat ESSO un produit qui n’est pas forcément le plus adapté au besoin. D’autre
part, il devient alors très difficile de savoir combien coûte exactement un tel produit
dans ce contexte.
• Le plancher bas (Seuil) MLC est difficile à fixer car en le positionnant trop haut l’en-
treprise risque de payer plus que sa charge réelle et en le positionnant trop bas le
taux de remise cité plus haut ne sera pas assez important. La seule chose qu’ap-
porte ce plancher bas est en principe un budget déterminé à l’avance, sauf en cas
de surconsommation non maitrisable.
• Il ne fait aucun doute que les vrais bénéficiaires de cette remise sont surtout les pro-
duits IPLA du monde distribué même si effectivement les tarifs des produits zOTC
dans le cadre d’un ESSO se montrent très agressifs. Toutefois, le nombre de pro-
duits zOTC reste limité comparé à celui des produits MLC.
• Il est difficile de sortir d’ESSO sauf événement exceptionnel car les décideurs pré-
fèrent renégocier des avenants plutôt que de remettre en cause ce contrat par peur
de voir leur facture s’envoler surtout pour les logiciels distribués.
La phase de construction de ce contrat s’avère donc critique. Il faut négocier aussi

largement que possible dès le départ et ne pas attendre les avenants : clarification des
prix OTCs, ouverture au Sub-capping et révision à la baisse des produits OTCs, clauses
de sortie, être imaginatif sur la fixation du seuil MLC, etc.
Enfin, constatons tout de même qu’IBM a fait des efforts d’imagination contractuelle
ces dix dernières années sur le Mainframe et en particulier pour de nouveaux logiciels
comme WebSphere. L’avenant IWP peut, pour les clients WebSphere z/OS, s’avérer très
rentable et même concurrencer aisément la version distribuée de ce même logiciel, bien
que ce nouveau « paradigme » ait du mal à passer auprès des décideurs.
3.1.2 S
tratégies à adopter avec les fournisseurs : approche globale ou coup par coup
Les logiciels Mainframe se laissent décomposer en trois catégories : les logiciels mé-
tier ou applicatifs dont nous ne traiterons pas ici, les logiciels système IBM – systèmes
d’exploitation, moniteurs transactionnels et bases de données – dont il a été question
ci-dessus, et enfin les autres logiciels systèmes. Ces derniers peuvent provenir de dif-
férents types d’acteurs : d’IBM lui-même, de grands généralistes, d’acteurs globaux de
moindre importance ou encore d’acteurs de niche. Deux stratégies principales s’offrent
à l’entreprise-cliente dans ses rapports avec ces fournisseurs : la rationalisation du
nombre d’ISV ou la gestion de contrats multiples.
PAGE 30
LiVRE BLANC
A. L’Approche Globale
L’approche globale consiste à réduire au maximum le nombre de ses contrats et de ses

fournisseurs. On se retrouve alors avec des contrats importants en termes de montants

financiers et qui englobent un grand nombre de logiciels. Cette démarche peut aller
jusqu’à ne conserver qu’un ou deux fournisseurs. A cette fin, le client passe un appel
d’offre qui englobe le maximum de composants logiciels et de fonctionnalités attendues
et que le fournisseur devra couvrir : automatisation de la production, supervision, ges-
tion de la performance, gestion de données, etc. Charge à chaque fournisseur de couvrir
le plus large spectre possible des besoins exprimés.
Première conséquence d’une telle démarche : elle conduit à ne s’adresser qu’aux trois
fournisseurs possédant un vaste catalogue, soit BMC, CA et IBM. Eux seuls se mon-
treront en effet capables de répondre sur une grande proportion des demandes, et de
limiter la taille du complément à apporter. On se coupe ainsi de bon nombre d’autres
éditeurs.
Seconde conséquence : la stratégie consiste ici à jouer sur la massification du contrat

afin de créer un levier de négociations essentiellement financier. C’est une logique
d’acheteur, pas de technicien : la performance technique individuelle des composants
ne s’y trouve pas mise en avant. Il faut donc accepter dans ce genre de démarche de ne
pas posséder le meilleur logiciel du marché en termes de qualité technique dans chaque
catégorie mais de retenir ce que le fournisseur possède.
Intérêts de cette démarche

•D es leviers de négociations plus importants : plus on achète à un fournisseur plus
celui-ci accepte de faire des remises et des conditions favorables. La position de
l’acheteur est plus forte que dans une approche au cas par cas.
• Un effet mécanique de remise globale lié au volume.
• La possibilité de jouer sur des durées d’engagement importantes pour obtenir en-
core plus d’avantages.
• L’accès à des modes de facturation plus souples que dans une transaction au coup
par coup.
Une raison fréquente pour adopter ce type de démarche : elle constitue un moyen de
se prémunir contre l’augmentation des MIPS/MSU des plates-formes durant quelques
années. En effet, pendant longtemps ce type d’accord constituait la seule situation où
les fournisseurs acceptaient de faire un contrat indépendant de la puissance installée.
Pour l’entreprise, cela signifiait que la croissance de ses plates-formes ne pesait pas
sur ses coûts logiciels durant au moins trois ans, à l’issue desquels avait lieu un nou-
veau cycle de négociations et d’ajustements. Ce type d’accord s’avère particulièrement
intéressant dans des contextes de fusion de SI ou de plates-formes à l’occasion d’opé-
rations de rapprochement d’entités ou de fusions-acquisitions, car on se retrouve alors
avec de nombreuses plates-formes, une rationalisation logicielle à effectuer, et une
croissance de MSU non-maîtrisée puisque la fusion remet en cause l’ancien schéma de
capacity planning, que la croissance de la nouvelle entité n’est pas connue, etc. Ce type
d’accord assure un tunnel de protection contractuelle en attendant que les opérations
redeviennent mieux maîtrisées.
C’est aussi un modèle intéressant pour procéder à des changements de logiciel à l’inté-
rieur d’un catalogue fourni par un même éditeur. En effet, l’approche globale donne sou-
PAGE 31
vent accès à une grande partie du catalogue du fournisseur selon une logique d’échange
de logiciels. Là encore, cela convient bien à une situation de fusions-acquisition, ou pour
changer certains des logiciels installés. Par exemple un contrat avec le fournisseur
donne l’accès à 12 de ses logiciels. Si l’entreprise se dégage de l’un d’entre eux, elle
dispose d’un crédit pour en adopter un autre dans le catalogue. Pour l’éditeur ce principe
permet la fidélisation du client, pour le client, une souplesse et des économies accrues.
Contraintes et limites
Cet accord établi dans la durée ne permet pas l’adaptation « en temps réel » des coûts
logiciels à la situation de l’entreprise. En cas d’optimisations conduisant à une diminu-
tion de la puissance de la plate-forme, le contrat court tout de même jusqu’à sa fin, sans
ajustement, il faut donc prévoir cette situation pendant la phase de négociation, sujet
toujours délicat. Idem en cas d’élimination de logiciels appartenant au panier contrac-
tuel : l’entreprise continue à payer pour des logiciels non-utilisés mais faisant partie de
l’accord. L’effort fourni dans ces deux cas ne porte pas ses fruits avant la fin de la durée
du contrat. Pratique à double tranchant, ce type de contrat protège en période d’incerti-
tude car il fige la situation, mais la réactivité financière s’en trouve diminuée.
L’entreprise se retrouve très étroitement liée à son fournisseur, avec une grande quan-
tité de logiciels structurants venant du même éditeur. Il y a risque d’emprisonnement.
D’où ce corollaire : en concluant ce type de contrat, il importe toujours d’en préparer la
fin, et ce le plus tôt possible. Cette question possède des aspects à la fois contractuels
et techniques.
D’abord sur le plan contractuel, il faut se poser d’avance avec son fournisseur, et ce dès
la signature du contrat, la question de ce qui se passera au jour de la sortie, et négocier
les conditions de revalorisation éventuelle des coûts en fonction de l’évolution des MIPS/
MSU installés. Il faut aussi envisager les alternatives techniques à chaque logiciel, sa-
voir qu’en cas de problème l’appel à la concurrence reste possible. Ensuite, l’entreprise
se posera de nouveau la question de la fin de ce contrat 12 à 18 mois à l’avance. Que faire
? Rester sur ce type d’accord ? Aller voir chez les concurrents ? Il faut préparer cette
échéance et anticiper sur les conséquences d’un changement de choix contractuel et
technique. Si ces contrats ont eu aussi mauvaise réputation par le passé, c’est justement
que les utilisateurs n’anticipaient pas assez sur la fin, avec un gros risque de sortie avec
une note salée. Caricaturalement, avec un contrat de ce type sur trois ans, l’entreprise
passe 18 mois à mettre en place la plate-forme, et les 18 mois suivants à envisager les
moyens d’en sortir si jamais les relations avec le fournisseur se dégradent.
Il faut aussi bien apprécier la durée du contrat. Aujourd’hui, la durée courante est de
trois ans, ce qui constitue un bon rythme de négociations, mais il existe des contrats plus
longs, sur quatre ans, ce qui valorise plus la stabilité. Au-delà de quatre ans, il existe des
risques car le contexte de l’informatique de l’entreprise évolue très vite.
Enfin, dans une situation d’approche globale, il faut se demander si l’accord porte sur
des contrats d’acquisition ou de location de logiciel. Cette question pèse lourd : suis-je
propriétaire d’un logiciel pour lequel je paye une maintenance ou simplement locataire
d’un droit d’usage ? En mode acquisition l’accord porte sur le prix d’achat du paquet
logiciel et sur le taux de maintenance. A la fin du contrat, il y a réévaluation par logiciel
en fonction de l’évolution des MIPS et MSU, et accord sur une mise à jour du tarif. En
mode location, l’acheteur et l’éditeur s’entendent sur un droit d’usage, mais à la fin du
PAGE 32
LiVRE BLANC
contrat, il n’y a plus de logiciels. Dans le cas d’un achat, si l’entreprise décide de se
séparer de son fournisseur, les logiciels restent dans l’entreprise, et il est possible de
continuer à les utiliser sur un mode de maintenance simple, sans révision de puissance,
ou même sans maintenance le temps d’élaborer un plan de désengagement. En mode

locatif si la situation se dégrade, le logiciel disparaît. Le contrat en mode locatif a l’inté-
rêt de demander peu de sortie d’argent pour les entreprises à la trésorerie tendue, mais
l’entreprise se retrouve soumise à tout moment à la menace de changement de politique
contractuelle du fournisseur.

Dernière contrainte : ce type de contrat suppose d’entretenir de très bonnes relations,
régulières, avec le fournisseur, de beaucoup travailler avec lui durant le contrat, bien
avant la renégociation, et d’avoir une vraie gestion de la relation.
B. L’Approche au cas par cas
Traditionnelle et bien connue, cette approche (dite best of breed) consiste à effectuer
des appels d’offres et des benchmarks par zone fonctionnelle, et à choisir le meilleur
produit au meilleur prix. L’optimisation repose ici sur la mise en concurrence systéma-
tique des solutions du marché et des fournisseurs en fonction du besoin fonctionnel et
du coût. C’est une approche orientée produit plutôt que contrat et qui doit conduire à
choisir la solution qui correspond le mieux au besoin. L’entreprise accepte alors d’avoir
de nombreux fournisseurs, en sachant que les contrats ne sont pas très difficiles à suivre
en environnement z, et en tout cas bien moins complexes que sur plates-formes distri-
buées (qui imposent un suivi du nombre de processeurs, de cœurs, d’hyperviseurs et de
machines virtuelles, etc. et ce sur un parc souvent conséquent).
Avantages
• Bénéficier de la compétition permanente entre les fournisseurs qui les pousse à
adapter leurs prix. Attention cependant à ne pas pratiquer la fausse compétition en
n’achetant toujours que chez le même éditeur, car les concurrents s’en rendent très
vite compte et ne l’oublieront pas le jour où vous aurez besoin d’eux.
• Couverture fonctionnelle des produits la plus adaptée au besoin.
• Possibilité d’adresser tous les fournisseurs : majeurs, intermédiaires, de niche.
• Permet d’adapter le mode contractuel à chaque groupe ou type de logiciel. Dans
une approche globale , on relève d’un mode de licence homogène donc peu précis,
alors qu’au coup par coup on peut demander une licence au MSU, à la partition, ou
sur tout autre modèle optimisé selon l’usage.
• Bénéfice mécanique du désengagement de logiciels en cas de rationalisation : si
l’entreprise cesse d’utiliser un logiciel, elle ne le paye plus.
• Pas de remise en cause globale et violente dans le système d’information en cas de
problème contractuel, technique ou commercial avec un fournisseur. L’entreprise
ne se retrouve pas à devoir changer d’un coup quinze logiciels, mais se trouve plutôt
dans une démarche de renouvellement régulier de sa plate-forme technique. La
mise en place présente moins de complexité que dans un accord global où il arrive
de passer un ou deux ans à mettre en place l’ensemble des logiciels inclus dans le
contrat.
Inconvénients
• Obligation de gérer les relations avec de nombreux fournisseurs
• Leviers de négociation commerciaux moins importants que dans un contrat global.
PAGE 33
L’acheteur d’entreprise préfèrera toujours négocier sur de gros volumes qu’au coup
par coup. Les négociations sont plus techniques que contractuelles.
• Difficulté plus importante à maintenir une cohérence technique, en particulier en ce
qui concerne la cohérence de versions des logiciels avec z/OS et les grands sous-
systèmes. Sur z les entreprises adoptent rapidement les nouvelles versions de sys-
tème d’exploitation et des autres grands composants IBM, ce qui entraîne méca-
niquement des mises à jour de versions des autres logiciels. Avec un seul grand
partenaire, ce suivi se trouve facilité. Avec plusieurs fournisseurs, il faut consentir
un effort de maintien de la plate-forme en cohérence technique plus important, et
rester attentif à la cohérence technique des logiciels entre eux.
• Il arrive que certains éditeurs prennent du retard dans la livraison de nouvelles ver-
sions et mises à jour de leurs logiciels au point de freiner l’entreprise dans ses évo-
lutions. Les grands éditeurs ont généralement les moyens de se maintenir à niveau,
mais un éditeur de niche risque d’avoir plus de difficultés. Il faut donc faire atten-
tion au type d’interaction et d’intégration du logiciel vis-à-vis de z/OS et des grands
sous-systèmes. Plus le logiciel sera techniquement intégré au système, plus il fau-
dra que son fournisseur se montre réactif et en mesure de faire ces évolutions.
• La non-homogénéité du parc logiciel entraine une plus grande difficulté d’intégra-
tion technique et une multiplication des ergonomies. Cela s’avère particulièrement
vrai pour des logiciels d’industrialisation de l’exploitation. Donc on se prive par-
fois de synergies techniques et fonctionnelles à trop diversifier ses fournisseurs.
Par conséquent, dans ce type de démarche, il faut toujours penser à faire de petits
groupes d’applications packagées chez un même éditeur pour obtenir un peu d’ho-
mogénéité fonctionnelle, voire technique.
Ajoutons à titre de conclusion à ce chapitre qu’au-delà du choix entre ces deux straté-
gies, il existe des bonnes pratiques courantes à respecter :
Pratiquer la remise en concurrence régulière des fournisseurs. Il importe de signaler clai-

rement que le client ne se trouve pas pieds et poings liés avec un fournisseur, mais en
mesure d’en changer au besoin. Il faut parfois même aller jusqu’au bout de la démarche,
et savoir rompre des relations avec les fournisseurs au comportement nuisible, savoir
se montrer radical et accepter l’effort d’un travail de migration. Une telle décision coûte
des efforts en conduite du changement, en journées de projet technique et de formation,
mais les économies réalisées à la clé s’élèvent parfois à plusieurs millions d’euros par
an. Il faut en arriver là de temps en temps.
Autre bonne pratique malheureusement trop rare : il faudrait régulièrement tester des
logiciels et avoir une démarche permanente de création de Proof-of-concept, même hors
des périodes de fin de contrat ou de renouvellement de produits. Maintenir une bonne
connaissance du marché sur quelques grands composants en faisant des essais et des
tests réguliers évite de se retrouver dépourvu le jour du renouvellement venu, aide à
détecter des acteurs émergents, ou au contraire des produits en perte de vitesse. De fait,
cette attitude devient rare, et c’est dommage à la fois pour la démarche contractuelle et
pour la démarche technique.
L’approche globale a des limites évidentes. Aucun fournisseur ne couvre la totalité du

périmètre des besoins, soit qu’il manque un produit à son catalogue, soit qu’il en existe
un d’inutilisable. Une certaine diversification des fournisseurs est donc inévitable. Il faut
alors gérer un complément, ce qui n’a rien de gênant en soi, mais demande de faire bien
PAGE 34
LiVRE BLANC
attention à l’attitude des fournisseurs de ces compléments. Ceux-ci savent qu’ils ne fe-
ront qu’un faible volume d’affaires avec une entreprise déjà engagée dans une démarche
globale avec un de leurs concurrents, ce qui les pousse à durcir leur position commer-
ciale. Un fournisseur de niche s’en accommodera très bien, car ses ambitions ne vont

pas forcément au-delà, mais un gros éditeur concurrent va essayer de tirer le maximum
du peu de vente qu’il va réaliser. Il vaut donc mieux aller chercher les compléments chez
les petits éditeurs que chez les grands.
3.1.3 Démarche contractuelle avec ISV : Modes de licence et de facturation
En introduction, rappelons que le logiciel, bien plus que le matériel, laisse la part belle à
la négociation du fait de son modèle économique. En effet, une fois développé, un logiciel
ne coûte plus rien à fabriquer. Ses coûts de maintenance et d’évolution se trouvent pris
en charge par le parc installé, ce qui signifie que tout nouveau client apporte du revenu
additionnel au fournisseur. Il est donc largement possible de négocier, et même d’obte-
nir du logiciel gratuitement, l’éditeur se rémunérant sur la maintenance.
Rappelons ensuite une évidence : certaines charges ne doivent pas fonctionner sur en-
vironnement z. Les traitements qui consomment beaucoup de cycles CPU en particu-
lier. Par le passé, certaines entreprises faisaient fonctionner des applications de calcul
scientifique et technique (HPC) sur Mainframe. Le cycle CPU y coûtant cher, cela n’est
pas une bonne idée.
Faut-il acheter ou louer ? Concernant les logiciels, la tendance générale porte à consi-
dérer l’acquisition comme plus intéressante du fait des rythmes de renouvellement peu
rapides dans le domaine mainframe. Il s’agit d’usages qui durent dans le temps et où le
mode locatif perd de son intérêt du fait de son coût dans la durée. Même en mode achat,
il faudra vérifier que le contrat porte sur un droit d’usage perpétuel, y compris en cas
d’arrêt de maintenance. Cela dépend des contrats. Certains éditeurs considèrent qu’à
défaut du paiement de la maintenance, le doit d’usage disparaît.
Le problème des licences se laisse simplement résumer : l’environnement z se trouve

souvent pénalisé car centralisé par nature. Tous les logiciels s’appliquent donc à une
même plate-forme, et subissent l’effet des MIPS et MSU globaux, ce qui crée un effet de
masse initial. C’est souvent l’argument numéro un en faveur des plates-formes distri-
buées : au moment d’installer un logiciel, l’entreprise compare le coût d’acquisition sur
plate-forme z globale ou sur serveur isolé. Or le z souffre de cet effet de masse initiale,
là où un déploiement sur environnement distribué peut débuter à peu de frais, sur un
seul serveur de faible puissance. Tout le jeu de la négociation, et toute la créativité de
l’entreprise, consistent donc à imaginer des moyens de gommer cet effet. Car dans le
distribué, il existe bien entendu un piège : le ticket d’entrée reste peu onéreux, mais si le
logiciel se retrouve déployé sur un nombre significatifs de machines, les frais explosent,
et les difficultés de suivi et de gestion apparaissent.
Il faut faire preuve d’inventivité avec nos fournisseurs, d’où l’intérêt de travailler dans
la durée, et d’éviter de faire des ‘coups’ car cela ne constitue pas une position durable.
Sachons innover sur les modalités de licence et de facturation, explorer d’autres pistes
que le grand classique de la facturation au MSU installé sur la plate-forme, pénalisante
du fait du droit d’entrée élevé, mais aussi parce que l’évolution des MSU de la plate-
forme peut n’avoir aucun lien avec l’usage de ce logiciel.
PAGE 35
Nous pouvons distinguer quatre modèles :
1. L
es licences à l’usage ont été amenées par IBM avec un principe de facturation à la
consommation : on mesure l’activité du composant et la facture est proportionnelle à
cette activité. Au départ, l’entreprise s’engage pour un volume de MSU ou de MIPS, qui
constitue un sous ensemble des MSU de la plate-forme établi en estimant ce que peut
consommer le logiciel. Ensuite l’éditeur et le client se mettent d’accord sur les moda-
lités de mesure de l’usage réel : que s’agit-il de mesurer, à quel moment, de quelle
façon, à quelle fréquence ? Dans certains cas, le logiciel embarque son propre outil
de mesure. Parfois les possibilités de mesure de l’activité de certains composants
manquent techniquement. Ce modèle présente l’avantage d’éviter le paiement d’un
ticket d’entrée correspondant à la globalité des MIPS présents sur la plate-forme.
Cela évite, lors du rachat d’une entreprise, de devoir repayer sur la base de la capacité
globale. Lors de son apparition, ce mode de facturation a suscité beaucoup d’espoirs,
mais n’a pas totalement abouti aux résultats escomptés. Mode de facturation pratiqué
par exemple par Compuware pour les produits de la gamme Development Tools.
2. E
n l’absence d’outils de mesure, pour des logiciels techniques transversaux par
exemple, on pratique l’accord contractuel. Dans le cas d’un outil de développement
par exemple : sur une plate-forme de 20 000 MIPS, si l’entreprise estime son environ-
nement de développement à 2 000 MIPS, elle proposera une facturation sur ces 2 000
MIPS. On parle alors de cantonnement contractuel. Ce modèle s’applique bien à des
fonctions ou activités isolables, mais devient source de polémiques pour des fonctions
plus intégrées, plus noyées dans la masse de la plate-forme. Dans le cas du dévelop-
pement, mesurer la capacité des partitions dédiées n’est pas compliqué, mais dans
le cas d’une base de données associée à un applicatif donné qui n’occupe que 5 % des
capacités de la plate-forme, comment déterminer l’usage de ladite base de données ?
Il faut alors trouver des méthodes d’évaluation. Exemples : activités de développe-
ment et contextes transitoires de fusion-regroupement.
3. U
ne autre méthode consiste à effectuer du partitionnement : isoler les fonctions pour
éviter la globalisation des coûts. Un applicatif installé sur une partition isolée ne sera
facturé qu’au prorata de cette partition. Cette solution très pratique fonctionne beau-
coup mieux pour des applications d’entreprise que pour des logiciels techniques par
nature plus transversaux. C’est aussi une technique appréciée en cas de fusions de
SI pour éviter de payer ses licences sur la base de la globalité de la plate-forme. Cas
typique des progiciels applicatifs.
4. L
a dernière piste, aujourd’hui très peu utilisée, mais qu’il faut explorer : parvenir à
trouver des modèles de facturation basés sur des unités d’œuvre métier ou business
plutôt que sur des indicateurs techniques purement informatiques. Cette démarche
reste peu familière des utilisateurs, qui n’y pensent pas au cours de leurs négociations.
Par exemple pour un logiciel de sécurité, il s’agit d’établir une facturation à l’utilisa-
teur, et non pas au MIPS. De ce fait, si demain le nombre des utilisateurs augmente, la
facture fera de même de façon tout à fait légitime puisque le but est bien de protéger
l’utilisateur. Mais si il se produit une augmentation technique des MIPS, il n’y aura pas
d’augmentation car le service rendu ne changera pas. La difficulté consiste à trouver
l’unité d’œuvre associée à l’usage du produit ou à l’activité métier qui en découle,
ainsi que le moyen de mesurer, de rendre traçable et auditable cette unité. Il faut se
montrer imaginatif, créatif. Il s’agit de zones de discussion et de négociation avec les
PAGE 36
LiVRE BLANC
fournisseurs encore assez peu utilisées, car peu ancrées dans la culture traditionnelle
des informaticiens. Mais comme les responsables de Production se soucient de plus
en plus de l’impact métier de leur activité, ce type d’accord se trouve à l’ordre du jour.
On trouve à titre d’exemple quelques logiciels techniques facturés au nombre d’utili-

sateurs concurrents, au nombre de transactions CICS par an, au nombre d’établisse-
ments de l’entreprise.
3.1.4 MLC : Maîtriser son niveau de facturation
3.1.4.1 La méthode de facturation IBM
Généralités
En ce qui concerne leur facturation, les logiciels z/OS se répartissent en deux
grandes familles.
• Les logiciels investis dits zOTC (One Time Charge) que nous n’aborderons pas
plus en détail ici. Seule chose importante à retenir : bien négocier dès le départ
l’achat du logiciel en fonction des besoins réels de l’entreprise car ce type de
produit est généralement éligible au sub-capacity, ce qui signifie que l’entreprise
peut investir uniquement à proportion de la consommation réelle, et non de la
capacité du serveur.
• Les logiciels loués, sur la base de la facturation MLC (Monthly Licence Charge).
La plupart de ces logiciels sont éligibles à un mode de tarification à l’usage VWLC
(Variable Workload Licence Charge).
• Il existe également des produits loués à coût fixe (on parle de FLAT MLC). Ces
produits représentent en général de 3 à 5 % du montant de la facture totale de
l’entreprise utilisatrice, nous n’en dirons pas d’avantage à leur sujet.
Dans tout ce qui suit, nous nous intéresserons exclusivement aux produits éli-
gibles au VWLC, et qui constituent l’essentiel de la dépense logicielle.
Pour chaque logiciel de ce type, le montant à payer est calculé en fonction de l’acti-
vité des partitions sur lesquelles il fonctionne. Le système z/OS enregistre en per-
manence des informations de métrologie concernant la partition dans laquelle le
logiciel s’exécute, notamment :
• la consommation CPU (MIPS) à intervalles de temps définis qui peut servir au
capacity planning.
• la consommation MSU 4 heures (Millions of Service Unit 4H, aussi écrit MSU 4H)
qui sert de base à la facturation.
Quelle différence entre MIPS et MSU ?

Les MIPS mesurent la puissance de traitement d’un processeur, et les MSU me-
surent en quelque sorte « l’énergie informatique » consommée pour réaliser un
traitement.
Concrètement, un programme qui, en 1990, mettait une heure à s’exécuter sur une
machine de l’époque s’exécutera peut-être en 5 minutes sur un z196 de dernière
génération. Pourtant, il consommera exactement le même nombre de MSU sur
ces 2 machines.
Le ratio MIPS/MSU évolue à chaque nouvelle génération de matériels pour main-
PAGE 37
tenir cette mesure stable dans le temps. Elle est utilisée pour déterminer la puis-
sance consommée et facturable.
Métriques utilisées dans la facturation VWLC

Avec la facturation à l’usage VWLC, le niveau de facturation mensuel s’établit pour
chaque machine (CPC) sur le pic de la somme des consommations moyennes de
ses partitions. La période retenue est l’heure où cette somme atteint son niveau le
plus élevé dans le mois.
Mode de calcul
Pour chaque logiciel VWLC, on considère donc sur chaque serveur l’ensemble des
partitions sur lequel il fonctionne.
On dénomme R4Hs (Rolling 4 Hours) la moyenne mobile sur 4h de la consomma-

tion MSU de chaque partition.
La facture s’établit sur la valeur maximum atteinte dans le mois par la somme des
R4H des différentes partitions hébergeant le logiciel.
La formule ci-dessous résume cette méthode :
N.B. : Il s’agit du maximum de la somme des R4Hs, et non pas de la somme des maximums atteints
sur chaque LPAR, ce qui s’avérerait beaucoup plus désavantageux pour le client.
Dans ce cas, la valeur retenue est 900 MSU (et non pas 970), ce qui correspond au
maximum atteint par l’ensemble des partitions en période 3. Cette approche cor-
respond à la courbe verte dans le graphe ci-dessus (ensemble). Il y aura donc bien
plusieurs pointes en fonction du logiciel concerné
Cette opération est réalisée pour chaque serveur physique. Ensuite, les valeurs
PAGE 38
LiVRE BLANC
obtenues servent à établir une facture par serveur, ou en cas d’agrégation PSLC,
leur cumul sert à déterminer la base de facturation du logiciel.
Remarques

Les logiciels sont facturés à la consommation des partitions sur lesquelles ils
s’exécutent et non pas selon leur propre consommation, différence essentielle, et
qui conduit à des situations paradoxales. Par exemple, le moniteur transactionnel
CICS a une consommation CPU très raisonnable, et se trouve peu sollicité la nuit
pendant la période Batch. Pourtant, sur une machine qui atteint ses consomma-
tions maximales durant ces périodes (cas de nombre d’entre elles), sa facturation
se verra établie sur un MSU 4h généré la nuit par les traitements Batchs.
Comme a priori tous les logiciels ne sont pas installés sur toutes les partitions, il
convient de suivre l’évolution du max de la somme des R4Hs sur plusieurs groupes
de partitions.
Si pour le z/OS, il suffit de suivre l’ensemble des partitions, il faudra également

suivre le groupe des partitions hébergeant DB2, puis celui hébergeant IMS, et ainsi
de suite pour chaque produit.
Enfin, l’utilisation d’outils et de méthodes de maitrise de sa facture logicielle, tels

que décrits dans les chapitres suivants, aura une influence directe ou indirecte sur
la facturation de certains logiciels.
Il faut porter une très grande attention à la localisation des logiciels et il peut donc
être intéressant de concentrer certains logiciels sur un petit nombre de partitions.
Mais ceci risque de s’avérer antinomique d’une approche Sysplex et des objectifs
de disponibilité continue qui en découlent. Là encore, les priorités de l’entreprise
dicteront les choix.
Une grille de tarification fortement dégressive par tranches
Le rapport entre la première et la dernière tranche de facturation atteint environ

10 pour tous les produits.
PAGE 39
Voici un exemple de tarification en France du logiciel de base Z/OS sur un z196
(AWLC):
Level Level Level Level Level Level Level Level

Nom du produit Base
1 2 3 4 5 6 7 8
MSU min de la tranche 1 4 46 176 316 576 876 1316 1976
MSU max de la tranche 3 45 175 315 575 875 1315 1975 MAX
z/OS V1 Base en E 4 146 385 315 226 120 92 64 48 38
Notons que les seuils haut et bas de chacune des tranches (en MSUs) sont com-
muns à tous les produits VWLC. Les prix unitaires en revanche varient d’un produit
à l’autre. La première tanche est forfaitaire, que l’utilisateur possède 1, 2 ou 3
MSU, il paye toujours 4 146 € comme ticket d’entrée.
Cette dégressivité a pour conséquence de minimiser les coûts de fonctionnement

liés à un accroissement de puissance (ex : consolidations de datacenters). Réci-
proquement, elle minimise également les économies réalisées en cas de portage
d’une application sur une autre plate-forme, puisque dans les deux cas, on n’agit
que sur les MSUs marginaux : les moins chers.
Dans toute simulation économique de ce type, il faut se méfier de toute linéarisa-
tion des coûts abusive et hâtive. Il est donc indispensable de demander à IBM une
simulation de l’évolution des coûts. Eux seuls possèdent les données nécessaires
pour produire des chiffres fiables.
Métrologie
Tout ce qui précède montre clairement la nécessité de disposer d’une métrologie
des consommations CPU des partitions et des machines physiques, ainsi que de
l’évolution des R4Hs pertinents en fonction de la répartition des produits sur les
différentes partitions.
Le calcul de la facture mensuelle sur la base des rapports SCRT

Chaque mois, le client fournit à IBM un récapitulatif contenant, pour chaque
serveur et pour chaque produit éligible à la tarification VWLC, les valeurs de
consommations servant de base à l’établissement de la facture.
Ces valeurs se calculent selon le procédé expliqué ci-dessus. Pour chaque

heure dans le mois, les valeurs retenues de « billing » de chaque partition sont
additionnées. L’heure dans le mois représentant la somme la plus haute se voit
retenue.
Ci-dessous, un graphe représentant dans le mois, les « Billing » de chaque partition

empilés.
PAGE 40
LiVRE BLANC
Ici, la valeur la plus haute se situe le 28 juillet de 12 h à 13 h avec 767 MSU. Il
s’agira donc de l’heure de référence pour les calculs de facturation de toutes les
partitions.

Un produit éligible à la facturation WLC s’exécutant sur toutes les partitions du
CPC se verra facturé sur la base du « Billing » calculé le 28 juillet de 12H à 13H,
soit 767 MSU.
3.1.4.2 Le problème du lissage des pointes de charge
On voit donc à la lumière de ce qui précède que les pointes de charge exercent une
influence directe sur la facture logicielle (coûts de fonctionnement), mais aussi
sur le dimensionnement des serveurs achetés (investissements). Il paraît donc
intéressant à double titre de les gommer autant que faire se peut.
Idéalement, on pourrait imaginer pour ce faire une meilleure répartition dans le

temps des traitements (via l’ordonnanceur Batch) ; solution envisageable si la pointe
de charge est liée principalement à l’activité Batch. Mais sa mise en œuvre peut se
révéler longue et fastidieuse, car elle imposerait une revue générale du planning
de la production, et se heurterait à certaines contraintes métier incontournables.
Nous pensons qu’il faut néanmoins y recourir marginalement et dans les cas les
plus flagrants.
Pour l’activité transactionnelle, cette opération s’avère encore plus problématique,

car l’exploitant maîtrise rarement l’activité transactionnelle sur ses serveurs, et
doit souvent respecter des engagements de service.
La solution consiste donc à contraindre autoritairement la puissance disponible,

et c’est le principe de fonctionnement de tous les dispositifs du marché, que nous
passerons en revue dans ce qui suit.
La nature de l’activité (Batch ou TP) à l’origine de la pointe de charge conditionnera

parfois le choix des outils de limitation à mettre en œuvre :
> Autant une pointe de charge liée à l’activité Batch peut se réduire par des outils
simples et rudimentaires, autant des outils plus sophistiqués seront indiqués si
cette pointe découle de l’activité TP.
3.1.4.3 Les méthodes et outils de maîtrise de la facture
On décrira ici les principaux systèmes et outils existants, du plus simple au plus
évolué. Ils sont au nombre de 3 :
• Le softcapping (DC : Defined Capacity) : Agit sur une partition
• Le Group Capping Limit (GCL): Agit sur un groupe de partitions
•L e produit Autosoftcapping (ASC) : Agit sur un groupe de partitions et de
serveurs.
PAGE 41
Le soft capping
Depuis 2004, il est possible de limiter à une valeur arbitrairement choisie la
consommation lissée sur 4 heures de toute partition. Une nouvelle métrique est
ainsi prise en compte dans le calcul de la facturation WLC après activation du soft
capping. Il s’agit du « Defined Capacity » ou « DC ». Cette valeur, exprimée en
MSU, est positionnée via la console HMC au niveau de la partition. La ligne bleue
représente le DC dans le graphe ci-dessous.
Il indique la limite de facturation en « MSU » qu’on souhaite ne pas dépasser pour
la partition.
La somme des DC des partitions d’une machine représente la limite de facturation
en MSU de la machine.
> La règle du soft capping:
Quand le « R4H » (courbe verte) dépasse le « DC » (ligne bleue), le système limite

(cappe) la consommation instantanée « IMSU » (courbe rouge) au niveau du « DC ».
En conséquence, le calcul du SCRT retient non plus systématiquement la moyenne

« R4H » sur l’heure, mais la plus petite des moyennes « R4H » ou « DC ».
Dans le graphe ci-dessous, la courbe violette « Billing » montre un niveau de

facturation à 380 MSU (« DC ») alors que le « R4H » atteint 450 MSU.
Le soft capping est un dispositif statique et manuel, adapté à une partition

spécifique, mais non à une gestion d’ensemble.
Généralisation du soft capping : Le Group Capping Limit (GCL)

Une généralisation du dispositif précédent a vu le jour à partir du z9 et avec z/OS 1.8.
Il est désormais possible de définir des groupes de partitions auxquels on affecte
une valeur limite de consommation (en MSUs). Chaque partition consommant la
ressource CPU au sein du groupe en fonction notamment de son poids PR/SM.
Une façon basique d’utiliser ce dispositif consiste à définir un groupe isomorphe à

chaque serveur (i.e. : contenant toutes les partitions du serveur) et à lui affecter une
valeur de capping. On a ainsi un moyen simple et lisible de piloter la consommation
globale, et donc la facture qui en découle.
Néanmoins, l’interface de ce dispositif et son utilisation au quotidien restent
réservées à des spécialistes.
PAGE 42
LiVRE BLANC
Un outil évolué : Le produit AutoSoftCapping (ASC)
Depuis 2006, le produit « AutoSoftCapping » (ASC de la société zCostManagement)
apporte de la flexibilité dans le soft capping standard d’IBM, sur les différents
modèles de serveurs (z900, z9, z10, z196) et indépendamment des versions de

z/OS (à partir de 1.7).
Le principe consiste à rendre les « Defined Capacity » variables en les partageant

entre les différentes partitions (vases communicants). Un algorithme sophistiqué
contrôle ce partage, prend en compte le besoin de chaque partition, et leur assure
à chaque instant le maximum de disponibilité.
L’outil permet aussi de gérer des profils d’activité différents en fonction d’une
période (fin de mois, chaque mardi, etc…) et ainsi d’adapter les possibilités de
softcapping d’une partition au contexte.
Enfin, l’interface donne à différents utilisateurs (pilote, administrateur, ingénierie,

management, direction) une visibilité partagée et compréhensible du niveau de
soft capping en cours sur les différents serveurs d’un complexe z/OS.
AutoSoftCapping permet :
-D ’optimiser la répartition des ressources « MSU » entre les partitions. La
limite introduite par le soft capping standard devient ici variable en fonction
des besoins de la partition. Elle devient ainsi beaucoup moins pénalisante que
la limite fixe introduite par le soft capping de base. Avec AutoSoftCapping,
lorsqu’une partition n’atteint pas le plafond auquel elle a droit, elle autorise
les autres partitions à utiliser le quota de « MSU » dont elle n’a pas besoin.
-D e maîtriser la facturation. La somme des « Defined Capacity » est en
permanence contrôlée par AutoSoftCapping. Ceci permet de la maintenir à
un niveau inférieur au niveau nécessaire avec du soft capping simple, tout en
obtenant de meilleures performances.
-D ’avoir une vision simple et claire, en temps réel, du comportement des
partitions et du niveau de facturation, grâce à un « reporting » à base de
graphes et de tableaux simples, compréhensibles par tous, introduisant un
langage transversal à l’entreprise.
Eléments de comparaison entre ces différents outils

- Le soft capping et le group capping sont des outils intégrés à l’architecture
matérielle IBM, et donc utilisables sans coût supplémentaire. Le paramétrage
de ces produits est dynamique et accessible depuis la HMC en mode SOO
(Single Object Operation), à l’instar des poids PR/SM.
- Le produit AutoSoftCapping est lui bien plus automatisé, et fournit en outre
des tableaux de bords permettant un pilotage en temps réel et une gestion par
profils. Mais ce produit est payant.
- Il est généralement contre-productif et peu performant d’utiliser simultanément
plusieurs de ces dispositifs. Chacun choisira donc en fonction de ses objectifs,
de son budget, et de l’investissement humain qu’il accepte de consentir pour
gérer ce type de système. En particulier, les bonnes pratiques déconseillent
généralement d’utiliser ces produits en même temps que l’antique hardcapping
qui impose une limitation instantanée (et non moyennée) de la puissance
allouée. Ce dispositif était donc beaucoup plus contraignant. Son utilisation se
PAGE 43
trouve en général limitée à des cas très spéciaux, notamment quand il s’agit
de respecter des obligations contractuelles vis-à-vis de certains éditeurs de
logiciels.
3.1.4.4 Retours d’expérience et préconisations
Dispositif désormais classique, le softcapping n’appelle à ce titre aucune remarque

particulière. Nous nous focaliserons dans ce qui suit sur les autres procédés de
limitation.
Cas n°1 : Utilisation du Group Capping

Ce dispositif présente l’avantage de rendre encore plus prévisible le montant
mensuel du MLC, et de faire baisser en pratique jusqu’à 10 % le nombre de MSU
facturés chez certains clients.
Le gros inconvénient tient naturellement au risque de dégrader la qualité de
service et/ou de retarder la fin d’exécution de traitements stratégiques.
Tout le problème consiste donc à piloter le GCL de façon à faire baisser au maximum
la facture, sans pénaliser les enjeux métiers de l’entreprise.
Conditions du succès - prérequis

Comme on vient de le voir, le Group Capping limite autoritairement et globalement
la puissance disponible, sans possibilité de savoir qui sera pénalisé. Le Group
Capping met en fait artificiellement le serveur en situation de contrainte.
Pour éviter la catastrophe, il s’avère donc absolument indispensable d’avoir une

politique de gestion des priorités efficace et réaliste au niveau des partitions entre
elles comme au niveau des traitements entre eux au sein d’une partition.
En particulier, en cas de contrainte globale, les poids PR/SM des partitions non
prioritaires (ex : Développement, recette, …) doivent être suffisamment en dessous
de leur consommation habituelle, pour que ce soient celles-là (et non des partitions
de production) qui se trouvent pénalisées en priorité.
De même au niveau d’une partition, les volumes de traitement classifiés en
« Discretionnary » dans WLM doivent également être suffisants en volume, pour
que le système puisse faire des arbitrages clairs en cas de contrainte.
Une fois ces conditions remplies, la manière la plus efficace d’utiliser le Group
Capping consiste le plus souvent à définir un capping global pour l’ensemble des
partitions du serveur.
Le soft capping sur des partitions spécifiques devient dans ces conditions sans
intérêt (sauf exception, par exemple quand il s’agit de respecter certaines
obligations contractuelles vis à vis de certains éditeurs de logiciels, IBM y compris).
Il apporte une rigidité supplémentaire généralement contre-productive.
Enfin, il est indispensable de disposer d’outils de suivi journalier du R4H. Ceci

permet de mesurer l’impact du Group Capping lors de sa mise en œuvre, de voir
quand il intervient, et dans quelle mesure.
Les outils standards de métrologie mainframe du marché permettent de construire
des requêtes simples pour ce faire. On peut également construire des requêtes
directement à partir des enregistrements SMF, opération un peu plus laborieuse.
PAGE 44
LiVRE BLANC
Mise en œuvre
Comme il n’existe pas de modèle prédictif fiable en la matière, la seule façon de
procéder est une mise en œuvre par petits paliers successifs de manière réversible,
avec une surveillance vigilante. L’expérience prouve que si on procède de la sorte,

on se met pratiquement à l’abri de conséquences fâcheuses.
On peut par exemple démarrer la mise en œuvre durant une période d’activité
normale, à une valeur égale à la pointe de charge mensuelle habituelle, puis
baisser progressivement par palier de 5 MSUs.
Compléments & préconisations

La mise en œuvre du Group Capping conduit de facto à baisser le taux d’engagement
des serveurs.
Tel qu’il existe le GCL manque certes de souplesse et de dynamisme, mais possède
en l’état des fonctionnalités intéressantes. Une mise en œuvre basique moyennant
les quelques précautions décrites ci-dessus permet sans risques de faire un gain
minimal d’environ 5 % en MSU (voire plus en fonction de la situation initiale).
Cet outil démontre la possibilité de faire baisser la facture MLC, certes dans
des proportions assez faibles (mais non négligeables pour autant), de manière
totalement indolore.
C’est aussi un moyen simple et sans surcoût de se familiariser avec ces techniques.
On peut ensuite évoluer vers des outils plus sophistiqués, mais payants, si des
études complémentaires démontrent la rentabilité d’une telle démarche.
Cas n°2 : Utilisation d’AutoSoftCapping (ASC)

L’outil ASC se différencie de GCL sur les points suivants :
-L a distribution des MSU se fait en fonction des besoins instantanés de la
partition (et non en fonction de son poids PRSM).
-L e niveau de soft capping d’un serveur peut-être variable, compris entre une
valeur mini et maxi, contrairement à GCL qui n’accepte qu’une valeur fixe.
Ceci permet d’atteindre des gains plus significatifs.
-L ’outil dispose d’une interface web pour visualiser la situation en temps réel,
avec une profondeur de 36 heures (96 heures maximum).
-L es objectifs de soft capping et les définitions des partitions et des serveurs se
font par paramétrage du logiciel (et non depuis la console HMC qui nécessite
des droits d’accès et un profil particuliers).
-L ’outil gère plusieurs serveurs Mainframe à partir du même point focal.
-D es profils, adaptés au contexte, peuvent être définis et activés automatique-
ment selon un planning.
-E n fonction des situations rencontrées, des alertes peuvent être générées
dans des logs, et/ou adressées par mail et sms pour assurer une meilleure
réactivité et une meilleure gestion des situations contraintes.
-E nfin, un outil de simulation, disponible auprès du fournisseur, permet
d’identifier les gains potentiels en MSU. Il contribue surtout à une mise en
œuvre sereine et maîtrisée du soft capping.
PAGE 45
Avec un tel outil, deux modes de gestion du softcapping sont envisageables :
-m ode sans contrainte (pas de capping de partitions pendant les périodes de
charge)
-m ode avec contrainte (capping de partitions autorisé pendant les périodes de
charge)
Les gains obtenus avec ASC dépassent ceux réalisés avec GCL dans un contexte
identique et peuvent atteindre environ 12 à 15 % de MSUs.
Pour le mode sans contrainte, réalisable uniquement avec ASC, vous trouverez ci-
dessous un exemple de mise en œuvre.
Le softcapping sans contrainte

Ce mode de fonctionnement a pour objectif principal d’agir sur la partie MSU (et
donc la facturation) après les périodes de charge. Dans ce mode de fonctionnement,
la qualité de service est privilégiée (pas de contrainte sur les partitions). Le gain
obtenu se trouvera donc minimisé par rapport à un mode avec contrainte, mais il
reste néanmoins réalisable.
Le graphe ci-après montre le comportement d’un serveur z10 d’une capacité

d’environ 3 500 MSUs, sans softcapping, du 30 septembre au 2 octobre 2010
(période de pointe de facturation sur le mois de septembre).
Cette courbe se caractérise par les 3 points suivants :

(1) Le maxi R4H - 2 777 MSUs - se situe le 1er octobre à 12h15.
(2) La consommation (IMSU) chute rapidement et fortement dès 12h00 (fin activité TP).
(3) Avec ce comportement, le niveau de facturation, calculé par le processus SCRT, sera établi à 2 754 MSUs,
ce niveau est obtenu le 1er octobre sur la tranche horaire de 12H00.
PAGE 46
LiVRE BLANC
L’outil ASC, grâce à une gestion dynamique et variable du niveau de soft capping,
va nous permettre d’agir sur le comportement précédent.
En paramétrant dans l’outil des seuils de softcapping mini à 2 000 MSUs et maxi à

2 800 MSUs au niveau du serveur, nous obtenons le comportement suivant :
(1) Les niveaux de consommation (IMSU) ne sont pas modifiés. Le R4H reste donc inchangé.
(2) Avec la mise en œuvre du DC, certaines partitions seront cappées (DC < R4H). Mais leur niveau de
consommation (IMSU) restant inférieur au DC, le capping n’aura pas d’impact (capping sans contrainte).
(3) Avec la variation à la baisse du DC sur la période la plus élevée du R4H, le niveau de facturation descendra
à 2 545 MSUs. Ce qui correspond à la tranche horaire de 11h00. Cela représente une diminution de 209
MSU, soit - 7,5 % sur le niveau de facturation.
Ce mode n’est bien-sûr envisageable que si le profil d’activité de la machine s’y

prête. Si l’activité plafonne au maximum pendant 4 heures consécutives, il faudra
nécessairement passer au mode avec contrainte pour envisager un gain MSU. Ceci
générerait un capping fort sur les partitions de recette ou technique, sur la période
11h-12h. Dans ce cas de figure, l’obtention de gains supplémentaire se fera au
détriment du service.
Compléments & préconisations

Le soft capping, piloté avec l’outil ASC, permet d’envisager des modes d’utilisation
excédant ceux de GCL, et d’obtenir des gains supérieurs.
Quel que soit l’outil utilisé, la mise en œuvre du soft capping nécessite une ana-
lyse approfondie, une concertation avec ceux qui administrent les environnements
(technique, de recette et de production), et enfin un engagement et une volonté
forte de l’entreprise partagés par tous.
PAGE 47
Grâce à des outils de simulation disponibles avec ASC, il est possible d’exécuter
des scénarios de mise en œuvre de softcapping sur une période antérieure, d’affi-
ner le paramétrage des partitions et de la machine, d’identifier les impacts sur le
fonctionnement des partitions, et enfin de valoriser des économies réalistes de
MSU sur la facturation des logiciels MLC.
Ces outils permettent une mise en œuvre rapide et maîtrisée du soft capping.
Enfin, de tels outils sont obligatoires pour maitriser ses niveaux de consommation,
et respecter les prévisions ainsi que les engagements contractuels pris auprès de
certains fournisseurs majeurs.
Cas n°3 : Politique d’investissement

Certains clients choisissent d’investir dans des moteurs par anticipation sur une
période de 3 ans, lors de l’achat des serveurs. Cette durée correspond grosso
modo à la durée de vie d’une génération de serveurs.
Cette politique autorise de meilleures négociations tarifaires lors de l’achat avec

IBM. Dans chaque cas, et compte tenu des prévisions de croissance d’une part,
du taux de l’argent en vigueur dans chaque entreprise d’autre part, le calcul de
rentabilité d’une telle option mérite d’être effectué, et la stratégie adaptée en
conséquence.
Dans ce contexte, pour éviter d’augmenter la facture logicielle, les clients

choisissent de n’activer les moteurs dormants qu’au dernier moment et par
paliers, ou d’activer des partitions de couplage monopolisant ces moteurs qui,
dans ce cas, sont inaccessibles aux partitions z/OS.
Avec ASC et une gestion optimisée, il est possible de mettre à disposition des
moteurs supplémentaires tout en limitant et maitrisant son niveau de facturation
logicielle. L’utilisation des moteurs dormants crée du white space (ou réserve de
capacité) utilisé afin de bonifier les performances… tant que le seuil de R4H n’est
pas atteint. Ceci peut amener une modification des profils d’activité tant au niveau
du TP que du batch, et avoir des répercussions positives sur le profil d’activité et le
rendement de la machine.
Les possibilités de paramétrage d’ASC, avec la gestion de profils, permettent de

gérer avec une granularité fine les ajouts de capacité effectués à chaque début de
mois (fractionnement des MSUs apportés par un processeur).
Le graphe ci-dessous représente les résultats obtenus avec 2 serveurs z10 710
(soit 2 x 875 MSUs) sur lesquels 1 moteur supplémentaire a été activé. Le niveau
de soft capping, maitrisé par ASC, ayant progressé tous les mois conformément au
capacity planning.
PAGE 48
LiVRE BLANC
(1) Les gains réalisés sont quantifiables par la différence entre la consommation prévue sans ASC
(i.e. La capacité de la machine sans utilisation du softcapping) et la consommation retenue,
établie par SCRT dans le cadre du softcapping.
(2) Le cumul des gains réalisés permet de quantifier sur l’année le nombre de MSUs économisés
par l’utilisation du softcapping et d’ASC.
(3) La facturation liée à la consommation CPU du mois M sera réglée à M+2. Dans ce cas, la
consommation CPU relevée pour Novembre sera réglée en Janvier suivant.
(4) Upgrade (Ajout d’un processeur sur chacune des deux machines) projeté en Novembre
Enfin, dans le cas d’activation de moteurs supplémentaires, les économies et les

optimisations réalisées peuvent être amputées par des produits ISV dont les coûts
sont négociés à la puissance MIPS installée. Ceux-ci génèreront des surcoûts à
prendre en compte.
Synthèse sur le soft capping

Au terme de cette étude, nous pouvons mettre en évidence un certain nombre de
leviers d’économies. Tous ne sont évidemment pas applicables dans tous les cas.
Il appartiendra à chaque entreprise de déterminer en fonction de son contexte et
de ses objectifs propres les plus adaptés.
En préalable à toute démarche de capping, on retiendra néanmoins que

le système doit pouvoir faire des arbitrages clairs en cas de contention.
Pour cela, il est indispensable de disposer :
-A
l’échelle d’un serveur, d’une politique de gestion des poids PR/SM efficace
et nettement différenciée.
-A
l’échelle d’une partition ou d’un Sysplex, d’une politique WLM également
différenciée, ménageant notamment un volume suffisant de traitements arbi-
trables (discretionary).
PAGE 49
Ceci posé, il est toujours préférable de laisser au système un maximum de degrés
de liberté, et de mettre en œuvre des règles simples. En particulier, il n’est jamais
souhaitable de mettre en place des garde-fous complexes censés traiter des pro-
blèmes peut-être imaginaires et qui par suite se révéleront contre-productifs et ne
serviront à rien.
Les règles mises en place doivent se contenter de traduire techniquement des

objectifs généraux tels qu’un niveau global de consommation ou une priorisation
des grandes familles de traitements (ex : production vs pré-production…).
En termes d’outils, il faut retenir que :

-L
e soft capping à l’échelle d’une partition est facile à mettre en œuvre et
simple à appréhender. Il faut le voir comme un outil au service d’une politique
globale de capping existant par ailleurs.
-L
e Group Capping Limit (GCL) est l’outil le plus simple de mise en œuvre d’une
telle politique. Utilisé sans précaution particulière et sans optimisations réa-
lisées par ailleurs, il permet de gagner entre 5 % et 10 % des MSUs consom-
mées initialement. Son inconvénient est d’être statique, et d’une utilisation
certes simple, mais assez peu conviviale.
-L
e produit AutosoftCapping permet généralement d’espérer un gain de l’ordre
de de 12 à 15 % par rapport à la consommation sans capping. Il est plus dyna-
mique, plus automatisé, et offre des fonctionnalités intéressantes. Principal
inconvénient : à l’inverse des dispositifs précédents, il n’est pas gratuit, et une
étude technico économique s’impose donc avant de décider d’en faire l’acqui-
sition.
3.1.4.5 Les autres leviers d’économies
Comme expliqué depuis le début de ce chapitre 3.1.4, le modèle IBM de facturation

MLC à la consommation WLC favorise les gros consommateurs. Le prix au MSU
décroit au fur et à mesure que le nombre de MSU consommés croît. Les tranches
basses de consommation sont extrêmement pénalisantes.
Les optimisations évoquées jusqu’à présent portaient essentiellement sur la

pointe de facturation de la machine (R4H). Cette pointe concerne les logiciels, tels
z/OS, actifs sur toutes les partitions de la machine. Pour les autres logiciels pré-
sents uniquement sur certaines partitions, il sera également relevé une pointe
mensuelle R4H, très probablement différente de celle de la machine. L’état SCRT
donne le relevé de ces différentes pointes.
PAGE 50
LiVRE BLANC
Voici par exemple un extrait, partie « PRODUCT MAX CONTRIBUTORS » de l’état
SCRT du mois d’octobre 2010 d’un z10 717, qui donne les pointes produit par
produit :

Il convient ici d’analyser individuellement ces pointes et la facture qui en découle
pour déterminer de nouvelles actions d’optimisation.
Voici un exemple d’analyse d’une facture mensuelle VWLC pour deux z10 717 agré-
gés en Sysplex :
PAGE 51
Si on ne considère que la pointe de la machine dans son ensemble, soit un R4H à
2 197 MSUs, on risque de ne pas s’intéresser aux logiciels tels qu’IMS qui ne sont
présents que sur quelques partitions. Pourtant, dans notre exemple, nous consta-
tons qu’IMS, avec un R4H à 1 473 MSUs, représente 27 % de la facture globale, soit
plus que z/OS dont le R4H s’établit à 2 197 MSUs et qui représente 24 % de cette
facture.
Suite à cette analyse, voici un ensemble d’actions mises en œuvre afin de faire
baisser la facture sans impacter la consommation.
• Le regroupement des IMS et CICS sur quelques partitions fait baisser la pointe
R4H pour ces produits.
• L’arrêt des CICS ou des IMS la nuit sur les partitions de développement et de pré-
production fait passer la pointe R4H de nuit (profil d’activité Batch) à une pointe
moins forte de jour correspondant au profil d’activité TP.
• L’organisation du planning de montée de niveau des produits, en choisissant soi-
gneusement l’ordre et les dates de migration des différentes partitions, permet
de réaliser quelques économies compte-tenu des règles de facturation du SVC.
En effet, pendant la durée du SVC, le client paiera seulement la consommation
la plus élevée des deux versions au tarif de la nouvelle version. Prenons un cas
d’école pour une montée de niveau IMS V9 à IMS V10. Avant la montée de ni-
veau, le client paie 1 000 MSUs d’IMS V9 au tarif IMS V9 avec plusieurs partitions
contributrices. La migration se fait partition par partition. Au début de la montée
de niveau, le client aura 900 MSUs en IMS V9 et 100 MSUs en IMS V10. Il paiera
alors 900 MSUs au tarif IMS V10. En milieu de migration, il aura 600 MSUs en IMS
V9 et 400 MSUs en IMS V10, il paiera alors 600 MSUs au tarif IMS V10. En fin de
migration, il aura 100 MSUs en IMS V9 et 900 MSUs en IMS V10, il paiera alors
900 MSUs au tarif IMS V10.
• Etudier et choisir le type de tarification en fonction des logiciels utilisés. La tari-
fication zNALC permet, pour les logiciels Websphere DB2 , de diminuer globale-
ment le tarif. La tarification IWP, pour les logiciels comme Websphere, permet de
soustraire la consommation de celui-ci des partitions sur lesquelles il est actif.
Ceci évite de surfacturer les autres logiciels comme IMS ou CICS dans le cas où
leur pointe de consommation se produit de jour pendant le TP.
• Dans le cadre d’un Sysplex, il est aussi possible de spécialiser une (ou des)
partition(s) pour le TP avec les moniteurs associés et une (ou des) partition(s)
pour le Batch. Ainsi les MSU Batch ne viennent plus augmenter les MSU IMS,
CICS, MQ et Websphere qui ne sont actifs que sur la(les) partition(s) TP.
La combinaison des actions citées ci-dessus, associée notamment au déména-

gement d’un serveur en 2008, ont permis de baisser la facture d’un membre du
Groupe de Travail exploitant plus de 20 000 MIPS.
PAGE 52
LiVRE BLANC
L’Evolution de la facture annuelle MLC (base 100 en 2006) se traduit sur la période
2006 -2011 de la façon suivante :

3.2 Réduire ses coûts d’infrastructure
3.2.1 Regroupement et mutualisation d’infrastructures
Depuis maintenant plusieurs années, un mouvement de consolidation d’infrastructures

se produit. Mouvement particulièrement marqué dans le monde de la Banque et de l’As-
surance. Chaque nouvelle génération de serveurs permet de reculer les limites tech-
niques antérieures et offre, par la même occasion, de nouvelles possibilités dans cet
exercice.
De la plus simple à la plus extrême, vous trouverez ci-dessous les différentes démarches
mises en œuvre ainsi que les objectifs associés. Bien que ces méthodes se généralisent,
elles restent porteuses de transformations importantes aux niveaux technique, écono-
mique, et humain.
Hébergement à l’extérieur de l’entreprise (chez un hébergeur)

Cette démarche est appliquée, en général, par des entités de petite et moyenne taille.
Elle permet de bénéficier de l’effet de masse apporté par l’hébergeur. Elle se traduit par
une baisse des prix du matériel et des logiciels, et minimise certains coûts.
Pour la partie logicielle, on peut noter une baisse sur :

- Les logiciels MLC IBM, sous réserve de se trouver en configuration éligible à la tari-
fication PSLC et d’utiliser les mêmes versions de produits que les autres clients de
l’hébergeur.
- Les contrats des autres fournisseurs, si ceux-ci sont négociés par l’hébergeur avec
droit d’utilisation par les différents clients.
Pour la partie matérielle, les économies varient suivant le niveau de mutualisation. L’en-
treprise pourra conserver une infrastructure dédiée, mais l’acquisition en sera généra-
PAGE 53
lement négociée par l’hébergeur. Le client réalisera des économies complémentaires
sur ses coûts de fonctionnement (énergie, bâtiment, etc.) en raison de l’absence de ma-
chines dans ses murs, et de la suppression de son ou ses datacenters.
Si cette solution semble intéressante, elle impose tout de même de prendre en compte
quelques points structurants. Le plus significatif reste la perte d’autonomie. Le client n’est
plus référencé chez les fournisseurs en tant que client direct (support, facturation, etc.),
et cette transition n’est pas toujours simple à gérer.
Pour garantir les économies matérielles et logicielles, il sera nécessaire (voire indis-
pensable) de synchroniser ses évolutions techniques avec celles des autres clients de
l’hébergeur. L’hébergeur a un rôle important et même fondamental dans cette synchro-
nisation. Plus il y a de clients, et plus la problématique gagnera en complexité (montée
de version en simultané, utilisation des même produits, etc.). Il n’est pas toujours facile
d’être un « petit » client dans ce contexte. En cas d’écart important entre les clients, les
économies risquent d’être inférieures aux prévisions. La situation extrême consiste à
se voir imposer un choix technique pour des raisons de coûts financiers, et il peut être
difficile de supporter l’ensemble des coûts induits par un choix spécifique.
Enfin, n’oublions pas les coûts liés à l’hébergeur …
Consolidation interne à l’entreprise et mutualisation de serveurs

Cette démarche s’effectue en général dans les entreprises disposant de plusieurs data-
centers. Ces entreprises cherchent à valoriser les investissements déjà réalisés et à
optimiser le nombre de leurs datacenters.
Ici, la cible en nombre de datacenters peut varier :

- Consolidation sur 1 seul datacenter : cela correspond à une organisation en mode
bi-site par exemple pour assurer un niveau de continuité de service optimal. Le PRA
est alors réalisé à l’extérieur (prestation).
- Consolidation sur 2 datacenters (ou plus) : le PRA est assuré en interne de l’entre-
prise.
La première étape peut s’effectuer sans mutualisation de serveurs. Il s’agit d’une simple
consolidation de datacenters, avec transfert des serveurs sur le(s) site(s) cible(s). Les
économies se réalisent sur les coûts de fonctionnement des datacenters, ainsi que sur
les coûts immobiliers. En revanche, en l’absence de mutualisation des serveurs, il n’y
aura pas de gain sur la partie logicielle (maintien de facturations séparées), sauf à mon-
ter un priceplex regroupant les différents serveurs, (cf ci-dessous).
La mutualisation des serveurs reste la solution économiquement la plus intéressante.

Dans ce cas, il s’agit non seulement de regrouper ses serveurs en un même lieu, mais
surtout de profiter de ce regroupement pour diminuer le nombre de ces serveurs et
augmenter le niveau de mutualisation. Dans certains cas, la mutualisation des serveurs
peut néanmoins s’avérer médiocrement rentable et engendrer d’importants surcoûts
logiciels, liés au mode de facturation au serveur physique de certains logiciels (ex : pro-
duits Software AG). Dans un tel cas, seule la solution priceplex sans changement de
serveurs est applicable. Elle permet à la fois d’éviter de tels surcoûts et de faire baisser
d’environ 30 % le MLC IBM en bénéficiant de l’agrégation PSLC (on considère l’ensemble
des serveurs du priceplex comme un seul serveur sur le plan de la facturation, et on ne
paie donc qu’une seule fois les tranches MSU les plus chères).
PAGE 54
LiVRE BLANC
Pour aboutir à une mutualisation des serveurs, il peut s’avérer nécessaire de passer
par plusieurs étapes d’évolution de l’infrastructure existante, soit par upgrade, soit par
changement de serveurs. Cette dernière solution constitue aussi une opportunité pour
bénéficier de meilleures performances (nouvelle génération de serveurs) et obtenir des

économies supplémentaires sur la facture logicielle (technologie dividende, AWLC). Elle
nécessite néanmoins des investissements et entraine des coûts liés au projet de démé-
nagement.
Enfin, dans une configuration multiserveurs, il faudra disposer d’un Sysplex éligible à la
tarification PSLC. Si cela n’est pas obtenu naturellement à partir des différents Sysplex
et de l’activité des partitions, il faudra envisager la construction d’un Sysplex commu-
nément appelé « Sysplex de facturation (ou priceplex) ». Précisons que cette opération
borne strictement les écarts matériels et logiciels, et n’est généralement pas triviale à
mettre en œuvre. La mise en œuvre d’un Sysplex de facturation a des impacts en termes
d’architecture, d’organisation et d’exploitation, et induit une charge de mise en œuvre
conséquente.
En fonction des contraintes techniques, de la faisabilité d’interconnecter plusieurs Sys-

plex, des coûts et charges de mise en œuvre de ce type de projet, il peut donc être néces-
saire de passer par des configurations intermédiaires à base de groupes de serveurs (et
donc de plusieurs tarifications Sysplex), avant d’atteindre la situation idéale et optimale
(1 Sysplex de base éligible de facto à l’agrégation PSLC présent sur l’ensemble des ser-
veurs).
Consolidation à l’extrême
Nous avons vu dans les étapes précédentes que la mutualisation de serveurs nécessitait
la présence d’un Sysplex éligible à la tarification PSLC sur les différents serveurs pris en
compte dans cette tarification.
Avec l’augmentation des capacités des serveurs (env. 32 000 MIPS pour un z10, env.
53 000 MIPS pour un z196), une solution mono-serveur permet de s’affranchir des
contraintes d’éligibilité à la tarification PSLC. Celle-ci étant acquise d’office dans une
telle configuration, plus besoin de priceplex.
Cette solution mono serveur profite pleinement des effets de masse, surtout si les
pointes de charge des différentes partitions, réparties initialement sur plusieurs ser-
veurs, ne se produisent pas au même moment mais se retrouvent étalées. Le nombre de
MSUs facturé sera alors de facto inférieur à la configuration multi serveurs.
Par contre, il faut prendre en compte la perte de puissance engendrée par le nombre
croissant de moteurs au sein d’un même serveur (facteur de couplage). A besoin de
puissance identique, il faudra prévoir plus de moteurs dans une configuration mono ser-
veur que dans une configuration multi serveurs.
Enfin, ce type de configuration n’est envisageable que si elle répond aux exigences de
continuité de service (temps de redémarrage d’un serveur de backup et de bascule de
l’activité sur celui-ci). Il faut notamment préciser qu’une telle configuration est incom-
patible avec des exigences de disponibilité continue. La réponse ne peut être alors qu’un
Sysplex multiserveurs avec partage de données et partage de charge, complété éven-
tuellement par l’option GDPS ou un dispositif similaire.
PAGE 55
Il faut aussi prendre en considération les risques que présente le fait de choisir une
configuration qui va au plus près des limites des possibilités du système par son nombre
de moteurs et sa puissance. Peu courantes, ces configurations sont susceptibles de
générer quelques dysfonctionnements (en effet de telles configurations exceptionnelles
mettent en jeu des portions de code spécifique et peu sollicitées). Dans ce cas, les
corrections peuvent être aussi plus longues à obtenir en cas de problèmes.
Convergence de plates-formes
Après la consolidation de datacenters et la mutualisation de serveurs pour héberger plu-
sieurs systèmes d’information, l’étape suivante concerne la convergence même de ces
systèmes d’information. Cette convergence est rendue possible par les fusions d’entités
ayant les mêmes profils d’activité. Les cas sont fréquents dans le domaine bancaire,
mais ils existent aussi dans le monde de l’industrie.
La convergence peut se faire par le choix d’un système d’information cible et le trans-
fert des données et des utilisateurs vers ce système. Cette phase permet d’harmoniser,
d’épurer et de limiter le nombre de logiciels. Elle permet de bénéficier pleinement de
l’effet de masse. Elle facilite la mise en œuvre d’un Sysplex standard et éligible, de facto,
à l’agrégation PSLC.
Cas de mise en œuvre
Démarrés en 2007, les travaux réalisés sur les 5 années écoulées ont permis l’évolution
suivante :
Configuration Avril 2007
- 5 datacenters
- 8 serveurs
- 6 systèmes d’information
- 53 partitions
- Puissance unitaire des serveurs : de 568 MIPS à 7 500 MIPS
- Puissance totale : 24 138 MIPS
Configuration Avril 2011
- 1 datacenter
- 1 serveur actif avec 1 serveur de backup
- 2 systèmes d’information (+ 1 SI en hébergement)
- 30 partitions
- Puissance unitaire des serveurs : env. 30 000 MIPS
- Puissance totale : env. 30 000 MIPS
Tous les aspects évoqués précédemment ont été mis en œuvre :

- Consolidation de datacenters
- Mutualisation d’infrastructures
- Convergence de systèmes d’information
PAGE 56
LiVRE BLANC
Tout en intégrant l’accroissement d’activité de ces 5 années (soit environ 12 % par an),
l’augmentation de la puissance totale installée en MIPS n’a atteint que 20 % en 5 ans.
Enfin, en 5 ans, on constate une multiplication par quatre de la puissance unitaire des
serveurs.

Les économies réalisées sur la facturation logicielle dans ce cas de figure sont aussi à la
hauteur des espérances, et représentent une baisse de 50 % tout en intégrant l’accrois-
sement naturel de l’activité.
Avril 2007 Avril 2011

Nb de factures MLC 5 1
Nb de MSUs facturés (global) 2 737 2 282
Montant facturé HT/mois 100 50,35
(base 100)
Ceci résulte de plusieurs initiatives :

- Consolidation de SI diminuant le nombre d’environnements techniques, de dévelop-
pement et de recette
- Diminution sensible du nombre de partitions, meilleure utilisation des ressources
machines au profit de l’applicatif
- Consolidation extrême et mutualisation d’infrastructures permettant d’optimiser
l’utilisation des ressources avec des SI aux profils d’activité différents
3.2.2 Utilisation de moteurs spécialisés : zIIP, zAAP, IFL
En quelques années, le paysage logiciel Mainframe a considérablement évolué. Tout a

commencé avec l’intégration dans le noyau MVS des APIs Unix en 1994 (Open Edition
puis depuis 1998 Unix System Services) qui a permis à la plate-forme de s’ouvrir aux
nouvelles technologies et sans doute d’être encore en « compétition » aujourd’hui.
PAGE 57
Dans un premier temps, TCP/IP a changé la donne, au point d’avoir depuis supplanté le
réseau SNA. Ainsi, les échanges entre le Mainframe et le monde distribué devinrent plus
naturels, ce qui se traduisit par l’apparition des applications mixtes, avec notamment la
possibilité d’accéder depuis le réseau aux données DB2 via DRDA.
Ensuite, de nouveaux middlewares sont venus compléter les moniteurs traditionnels tels
qu’IMS et CICS. Le serveur d’application WebSphere reste le plus célèbre, et a ouvert au
Mainframe la porte des technologies Java et plus récemment celles de SOA, de XML et
du Web 2.0.
Malgré tout, le Mainframe garde encore son image de dinosaure. Le frein au dévelop-
pement de la plate-forme n’est pas intrinsèquement technique, mais plutôt financier.
En effet, ces nouvelles technologies consomment beaucoup plus de CPU que les envi-
ronnements dits Legacy. Cette augmentation est principalement due à l’utilisation du
langage Java, mais aussi du langage C/C++, couramment privilégié par les fournisseurs
pour développer leurs logiciels en lieu et place de l’assembleur. La dispersion des clients
Mainframe à travers le réseau s’avère aussi plus délicate à gérer que les simples termi-
naux 3270 des années 80.
Pour limiter « la casse », IBM a fait preuve d’imagination en sortant dans les années
2000 des processeurs spécialisés dans le traitement d’une partie de ces nouveaux types
de traitements. D’un point de vue général, ces processeurs ne constituent en fait qu’une
pratique commerciale inventive (et pas une prouesse technologique, il s’agit en fait de
processeurs z au microcode modifié), même si techniquement seul le dispatcher MVS
est capable de ce genre de gymnastique :
PAGE 58
LiVRE BLANC
Sans ces processeurs dont le TCA a été réduit par 4 environ par rapport aux proces-
seurs standards, il n’aurait pas été financièrement envisageable d’héberger de telles
nouvelles applications (DRDA, Web, …) sur Mainframe. Mais le plus important concerne
la facturation à l’usage des logiciels. Ces processeurs sont exonérés de « taxe » MLC ce

qui limite l’impact CPU global sur le système et les autres logiciels de la partition.
Les processeurs zAAPs sont principalement destinés aux workloads Java et prennent en
charge entre 40 % et 70 % de la consommation en fonction de la typologie de l’applica-
tion. Le ratio Java/DB2, facilement identifiable, devient à présent une métrique impor-
tante à prendre en compte lors des phases de tuning.
Les processeurs zIIPs quant à eux traitent une partie du workload DB2 (notamment envi-
ron 50 % des requêtes DRDA) mais restent aussi ouverts aux autres fournisseurs de
logiciels qui peuvent bénéficier de ce dispositif après accord d’IBM. CA, SyncSort , et
d’autres l’ont déjà fait même si la proportion de CPU s’exécutant sur zIIP pour ces logi-
ciels reste encore faible. En revanche, pour DB2 le gain financier n’a rien de négligeable,
ce qui explique l’adoption de cette solution par une large frange d’entreprises.
Néanmoins, l’impact financier de ces nouvelles applications reste visible. C’est pourquoi
IBM continue sur sa lancée et a sorti depuis l’arrivée du z196 deux nouvelles options
intéressantes :
• Techniquement, il est maintenant possible de consolider l’ensemble des workloads
(Java, DB2, …) sur les zIIPs grâce au zAAP on zIIP.
• Commercialement, un avenant AWLC appelé IWP permet de réduire considérable-
ment l’impact MLC de ces applications. Ce nouveau mécanisme SCRT autorise à
déduire la consommation engendrée par WebSphere sur les moniteurs classiques
IMS et CICS. Il s’agit d’une véritable avancée qui devrait permettre une extension de
l’emploi de ce serveur d’application sur Mainframe, environnement qui offre tou-
jours la qualité de service la plus évoluée ainsi que des performances très appré-
ciables surtout lorsque le serveur Websphere se trouve hébergé dans la même par-
tition que les données et moniteurs Legacy.
Côté logiciel, DB2 v10 offre de nouvelles perspectives grâce aux bases de données XML.
En effet, les requêtes seront alors traitées par les APIs XML natives à présent incluses
dans le noyau MVS, ce qui qui en plus d’améliorer les performances de 30 % déporte la
consommation sur zIIP.
3.3 Maîtriser ses coûts de Fonctionnement

3.3.1 Optimisation, performances et qualité des composants techniques
et applicatifs
“The fault, dear Brutus, is not in our stars, But in ourselves…”

William Shakespeare.
La démarche qualité tend à perdre de son importance depuis un certain nombre d’an-
nées, ceci pour des raisons diverses telles que perte de compétences des équipes, com-
pressions de personnel, prépondérance de la rapidité de mise en œuvre de projets à
calendriers contraints, etc, etc, etc ... Cette situation est assez paradoxale, car la baisse
constante de la qualité des développements, pour ne citer qu’elle, rendrait une telle
démarche plus que jamais indispensable actuellement.
PAGE 59
Néanmoins, on préfère souvent réaliser des investissements (matériels et logiciels) de
croissance, qui de surcroît grèvent les budgets de fonctionnement, plutôt que d’optimi-
ser l’existant.
Evidemment, il arrive que de bons techniciens réalisent ponctuellement des optimisa-

tions parfois spectaculaires, mais cette démarche n’est pas systématisée, et n’est mise
en œuvre qu’en situation de crise opérationnelle. Au surplus, ce travail ne se voit ni valo-
risé, ni reconnu comme il l’était par le passé. La tâche se complique encore quand des
fusions ou des regroupements de plusieurs entités interviennent, diluant encore plus les
compétences.
Le mode de fonctionnement décrit ci-dessus atteint parfois ses limites, notamment en

cas de contrainte budgétaire importante. Dans un tel cas, il importe de faire baisser les
coûts de fonctionnement et/ou de différer au maximum les investissements.
Une démarche qualité bien conduite répond à ce double objectif, mais elle ne va pas pour
autant de soi aux yeux des décideurs… L’idée vient donc naturellement de se faire ac-
compagner par une société spécialisée qui possède une solide expérience et de solides
références en la matière.
Principe de la démarche
Après une première campagne de mesures et d’analyses menées in situ par le presta-
taire, celui-ci se fait une idée précise des potentialités de gain qu’il a décelées chez le
client. Il se trouve alors en mesure de présenter une offre commerciale.
Après accord entre les deux parties, le prestataire mènera une mission de quelques
mois chez le client, et proposera un certain nombre d’optimisations. Le client aura alors
la liberté d’accepter ou de refuser ces propositions, en fonction du bénéfice escompté,
du risque induit, de la complexité de mise en œuvre ou de tout autre critère d’apprécia-
tion. Il est ensuite de la responsabilité du client de mettre en œuvre les optimisations
proposées. De manière annexe, le prestataire fournit si nécessaire les outils de mise en
œuvre et son assistance.
Le prestataire propose des optimisations tant sur le socle technique de base (sys-
tème d’exploitation et composants majeurs tels que DB2, IMS, CICS, Webs-
phere, DFHSM, etc.) que sur le parc applicatif. Les optimisations relatives au
parc applicatif sont généralement majoritaires, et le prestataire s’attache autant
que possible à ne proposer que des optimisations « faciles » à mettre en œuvre (i.e. :
n’induisant pas de profondes modifications du code applicatif). Il sait parfaitement que
de telles optimisations auraient toutes les chances d’être refusées du fait de leur risque
et de leur charge de mise en œuvre prohibitifs.
Montage du projet
La première difficulté rencontrée dans la mise en œuvre d’une telle démarche qualité
est bien de convaincre de son utilité et de sa rentabilité, par rapport à une solution de
croissance classique. En effet, une telle démarche, hors son coût intrinsèque, induit pour
les équipes techniques en général (système et applicative) une charge de travail supplé-
mentaire dont elles n’ont généralement pas besoin, et dont le coût n’est pas négligeable.
Il faut donc longuement expliquer, argumenter et convaincre de la nécessité et de la ren-
tabilité de la démarche. Un modèle économique original peut y contribuer, comme par
exemple la rémunération « au résultat » du prestataire choisi. Ce peut être à la fois un
gage du sérieux de celui-ci, et surtout une garantie de limitation du coût de la prestation.
PAGE 60
LiVRE BLANC
De plus, ces prestataires ont généralement une compétence, une expérience et des outils
(ex : Datamining) qu’il serait trop coûteux à un client de développer et de maintenir sur
ses ressources propres. Il y a donc là une vraie valeur ajoutée pour l’entreprise cliente.

Les principaux pièges à éviter et les facteurs clé du succès
Avant de démarrer la prestation : Aspects financiers et contractuels

-E tudier avec soin les contrats proposés par le prestataire, car le principe de la ré-
munération aux résultats peut se trouver assorti de clauses limitant son champ
d’application, et le vidant ipso facto de sa substance. Une bonne négociation s’im-
pose donc avant tout accord.
-P orter une extrême attention à l’évaluation des économies escomptées. Ne pas ou-
blier que la tarification MLC d’IBM possède un caractère fortement dégressif (d’un
rapport de 1 à 10 entre la première et la dernière tranche). Donc en cas de baisse
de la consommation MSU, les MSUs économisés seront les MSUs marginaux (les
moins chers). Il ne faut donc surtout pas se baser sur un prix moyen du MSU obtenu
par exemple en divisant la facture VWLC par le nombre de MSUs consommés. Une
telle linéarisation abusive peut conduire ensuite à de cruelles déconvenues, tant
dans l’évaluation des économies que dans le budget de la prestation.
Cet aspect est essentiel, car le prestataire anticipe les économies qu’il compte faire
réaliser à son client, et établit son prix en conséquence.
En conclusion sur ce point, il est essentiel de faire établir ou à minima valider par IBM
les simulations financières utilisées. Bien que juge et partie en la matière, IBM est
d’une certaine manière garant des chiffres qu’il annonce.
-C
as des clients liés à IBM par un contrat type ESSO : Dans un tel contrat, la dépense
MLC ne peut descendre en deçà d’une valeur minimale. Un tel dispositif peut limiter,
voire annuler l’impact financier d’une baisse de la consommation MSU. Il peut donc
être opportun de faire coïncider la prestation avec une échéance du contrat ESSO.
-L
e montage financier et le mode de rémunération du prestataire doivent rester
simple et lisible, et correspondre à la stratégie financière du moment.
Avant de démarrer la prestation : Aspects techniques

-S ur le plan pratique, il faut également dresser avec le prestataire un inventaire des
outils de mesure et de diagnostic dont il aura besoin. Il est nécessaire de vérifier
pour éviter toute mauvaise surprise que, soit ces outils existent d’ores et déjà chez
le client, soit le prestataire les a inclus dans sa prestation sans coût supplémentaire.
- I l est également important d’impliquer au plus tôt, et avant le démarrage de la

prestation tous les acteurs techniques côté client (Etudes et développement, mise
en production, équipes systèmes, équipes d’exploitation), afin qu’ils puissent prévoir
la charge de travail inhérente à cette démarche, et qu’ils participent activement à
sa mise en œuvre.
-R
éciproquement, il est essentiel que les intervenants du prestataire soient intégrés
et identifiables aisément dans la structure (et dans l’annuaire) de l’entreprise. En
cas d’incident (toujours possible), les circuits d’alertes seront ainsi raccourcis, ce
qui permettra de corriger plus rapidement et a minima de dédramatiser la situation.
Ceci est essentiel pour maintenir la crédibilité de la démarche.
PAGE 61
Au démarrage de la prestation
D’une manière générale, la prestation sera d’autant plus profitable que le client aura
d’une part une vue précise des problèmes de performances liés à sa production informa-
tique, vue associée à un corpus métrologique fiable et complet ; d’autre part des équipes
techniques compétentes et capables de dialoguer avec profit avec les consultants du
prestataire. En bref, plus la maturité de l’entreprise cliente sera grande en matière d’op-
timisation, plus profitable sera la démarche, surtout sur le long terme.
De même, une compréhension précise des principes de facturation du MLC IBM est ab-
solument indispensable côté client, afin de vérifier l’impact financier des optimisations
proposées, et de ne pas se tromper de cible.
Ceci posé, il convient de porter attention aux points suivants :

- Ne pas perdre de vue que le prestataire se focalisera sur les optimisations qui feront
prioritairement diminuer la facture. Ceci concorde dans la plupart des cas avec les
objectifs du client, mais ce dernier peut être amené à y apporter quelques nuances.
Un exemple : Une optimisation simple, mais détectée et proposée uniquement sur
un traitement impactant la pointe de charge, donc la facturation, peut être égale-
ment applicable à beaucoup d’autres traitements. Il appartiendra donc au client d’y
veiller et de généraliser en conséquence.
- Borner le champ d’investigations du prestataire. Pour ce faire, lui indiquer les chan-
tiers d’optimisations en cours ou à venir, et entrepris sans son concours. Il est infi-
niment plus rentable de le faire principalement travailler sur les sujets que le client
n’est pas capable de traiter sur ses ressources propres.
- Se mettre d’accord sur un procédé de mesure des gains, et en conserver la maîtrise.
- Exiger autant que faire se peut l’utilisation des outils métrologiques du client, de
préférence aux outils du prestataire. Les procédures et les outils employés seront
ainsi plus facilement maîtrisés et réutilisables par la suite.
Mise en œuvre et déploiement des optimisations

La rapidité de mise en œuvre des optimisations est essentielle, car l’impact financier
qui en découle influe directement sur la rentabilité du projet. De plus, elles peuvent
« donner de l’air » à une production déjà contrainte.
Pour cela, il est essentiel de s’assurer le concours actif des décideurs opérationnels,
ainsi que, comme il a déjà été mentionné de l’ensemble des équipes techniques.
Au fur et à mesure du déploiement des optimisations, il est indispensable de revoir à la

baisse le niveau de softcapping en fonction des gains observés sur la pointe. Faute de
quoi les gains ne se matérialiseront pas sur la facture, car les économies réalisées se
trouveront absorbées sans coup férir par ailleurs.
Nature des optimisations – Bilan technique

On peut classer en 3 grandes catégories les optimisations proposées :
- Celles que nous connaissons, mais que nous ne mettons pas en œuvre par manque
de temps, par négligence ou par laxisme. Ce sont malheureusement les plus nom-
breuses. La vraie valeur ajoutée du prestataire consiste alors à quantifier techni-
quement et financièrement les gains que nous pourrions en tirer, ainsi qu’à démys-
tifier une complexité supposée de réalisation.
PAGE 62
LiVRE BLANC
-C
elles que nous n’aurions pu trouver nous-mêmes, et pour lesquelles le prestataire,
de par son expérience chez d’autres clients et sa compétence possède une vraie
valeur ajoutée.

-T
out ce qui nous est dit de manière informelle en termes par exemple de bonnes
pratiques, mais qui ne peut faire l’objet d’optimisations concrètes. En revanche,
ces pistes doivent permettre au client d’organiser ultérieurement des chantiers à
plus long terme sur ces sujets. C’est souvent l’occasion de découvrir que certaines
sociétés facturent fort cher des prestations de migration, alors que ces migrations
peuvent être réalisées en fait assez facilement et sans bourse délier.
Globalement les optimisations obtenues se montrent à la hauteur des résultats

promis. Dans de très rares cas, il arrive que les résultats soient en deçà, d’où l’im-
portance de la métrologie, mais surtout de la compétence des équipes tech-
niques côté client, qui permettent d’argumenter d’égal à égal avec le prestataire.
Ces déconvenues, heureusement rarissimes répétons-le, sont liées à une analyse par-
fois un peu rapide du prestataire (erreurs dites de routine).
Bilan des gains

Chez tous les adeptes de cette démarche, on a observé une baisse de la consommation
MSU (et donc de la facture MLC) variable en fonction notamment de la croissance et de
la situation initiales, mais surtout un report des investissements de puissance habituels.
Le report généralement observé est d’un an.
Pérennité de la démarche
Les optimisations proposées mettent souvent en lumière des carences organisation-
nelles et techniques plus globales ou endémiques. Il appartient donc au client d’en tirer
toutes les conséquences, en corrigeant les dysfonctionnements constatés, mais aussi en
prenant les mesures pour que ceux-ci ne se reproduisent plus.
L’enjeu pour le client consistera ensuite à intégrer et pérenniser les bonnes pratiques
inculquées, et à les appliquer avec rigueur et détermination. Ceci peut nécessiter des
ressources (notamment humaines) supplémentaires qu’il lui appartiendra d’obtenir.
S’il n’y parvient pas, il devra faire appel de manière régulière à de telles prestations, de
manière à faire corriger par d’autres les dérives qu’il n’aura su corriger lui-même.
Mais en tout état de cause, la démarche qualité décrite ici, au-delà des bénéfices qu’elle
procure, constitue une occasion unique de réhabiliter, de relégitimer et de se réappro-
prier le champ d’expertise lié à la performance, à contre-courant de la tendance triste-
ment dominante.
3.3.2 Capacity Management, outils et méthodes
Le regroupement de datacenters, les consolidations d’infrastructures et la mutualisa-

tion d’IT réalisés ces dernières années ont considérablement modifié les caractéris-
tiques des serveurs mainframe.
- Augmentation de la capacité des serveurs installés (multipliée par 4 pour certains

utilisateurs).
PAGE 63
-A
ugmentation de la puissance totale installée en MIPS (10 % en moyenne par an).
Parallèlement aux évolutions de serveurs, les plates-formes et leurs partitions asso-

ciées, hébergées sur ces serveurs, évoluent aussi :
-A jout de plates-formes en cas de mutualisation de serveurs

- Suppression de plates-formes en cas de consolidation de Systèmes d’Information
Ces plates-formes utilisant des logiciels IBM facturés à l’usage (MLC), les évolutions et
les regroupements ont des répercussions sur les logiciels installés, leur niveau de fac-
turation mais aussi sur les types de contrats mis en œuvre (SRA, ESSO, OIO, …).
L’objectif majeur de ces évolutions est une recherche permanente d’optimisation des
coûts matériels et logiciels.
L’augmentation rapide et conséquente du Datacenter Mainframe, associée aux impacts
financiers sur les composants matériels et logiciels, a nécessité le développement de
métiers émergents tels que « Capacity Planner » et « Software Cost Planner ».
Pour pérenniser cette recherche de maitrise des coûts et des infrastructures, il faut
disposer d’un processus de Gestion de la Capacité Mainframe opérationnel qui intègre
l’ensemble des problématiques et des besoins.
Ce processus peut se matérialiser de la façon suivante :
Pour expliquer ce processus, vous trouverez ci-dessous un exemple de Capacity Mana-

gement mis en œuvre lors d’un projet de regroupement d’infrastructures et de consoli-
dation de SI.
Capacity Management : Le rôle et le périmètre

Une gestion complète de serveurs comprend en général la gestion de configuration, la
gestion des changements, la gestion des problèmes, la gestion des performances et la
gestion de la capacité.
Le rôle du processus présenté ici se limite à la gestion de la capacité et de la configura-

tion des serveurs mainframes. Il n’a pas vocation à traiter les autres points qui relèvent
plutôt de la responsabilité des équipes opérationnelles ou des entités qui gèrent et ad-
ministrent les plates-formes fonctionnant sur ces serveurs.
PAGE 64
LiVRE BLANC
Le processus est un élément fédérateur des différentes entités qui administrent et pi-
lotent des plates-formes et qui se trouvent dans l’obligation d’assurer des services à
leurs utilisateurs. Par contre, en aucun cas, la gestion de la capacité ne se substitue à la
gestion de la performance qui incombe à ces mêmes entités.

La gestion de capacité collecte annuellement les besoins en ressources des différentes
plates-formes, les événements marquants à venir justifiant de ces besoins, ainsi que le
taux de croissance à prendre en compte pour les années à venir.
A ce niveau, on peut regretter de ne pas disposer de liens avec le business plan de nos
utilisateurs. Il s’avère même relativement difficile de récupérer des indicateurs d’acti-
vité cibles qui peuvent pourtant justifier le besoin des entités et servir de repère en cas
d’évolution de comportement (tant à la hausse qu’à la baisse).
L’ensemble de ces éléments se voit ensuite consolidé pour établir, à partir d’une base
actualisée et correspondant au contexte actuel, des projections trimestrielles sur 3 ans
des besoins de ressources et définir les configurations de serveurs associées afin d’être
en capacité de répondre aux besoins.
Cette phase dite d’actualisation du Capacity Planning a lieu une fois par an,
en fin de 1er semestre.
En sortie d’actualisation, il nous est donc possible :
- D’afficher les projections et les évolutions à 3 ans (accompagnées des justificatifs et

des hypothèses de travail)
- De définir les configurations et les scénarios d’évolution des serveurs
- D’élaborer le budget d’investissement et de fonctionnement de l’année suivante, tant
au niveau des évolutions matérielles que de la facturation logicielle MLC d’IBM
PAGE 65
Ce procédé d’actualisation peut être rejoué durant l’année en cas de besoin exceptionnel
non identifié, ou de changement d’hypothèse de travail. Suivant les impacts, cela peut
engendrer des modifications de configuration, une évolution matérielle, et des modifica-
tions sur la facturation logicielle IBM.
Les informations issues de la Gestion de la capacité et les projections sur 3 ans servent
aussi régulièrement dans le cadre de renégociation de contrats logiciels, ou d’acquisi-
tion de nouveaux produits.
La gestion de la capacité s’appuyant sur des estimations, il est indispensable de mettre

en place un suivi régulier des comportements, et de rapprocher les constats des esti-
mations. Suivant les conclusions, il peut être nécessaire d’agir au niveau d’une par-
tition ou d’une plate-forme (en cas de dérive), de la configuration (redistribution des
ressources entre plates-formes) ou de déclencher une actualisation du plan de capa-
cité pour prendre en compte une évolution (à la hausse ou à la baisse) des besoins.
Ce dernier cas de figure peut avoir une incidence sur les budgets d’investissement ou de
fonctionnement de l’entreprise pour l’année en cours.
C’est l’ensemble de la démarche (processus, procédures, outils, suivi, …) qui constitue le

Capacity Management décrit ici et qui permet une maitrise optimale des coûts matériels
et logiciels du Datacenter Mainframe.
Capacity Management : Le fonctionnement du processus
Elaboration du Capacity Planning MIPS

La première étape consiste à élaborer un document recensant :
• Par plates-formes
- Les hypothèses d’évolution sur l’année suivante à minima
- Les taux de croissance
- Les faits marquants et leurs échéances sur l’année suivante (et au-delà lorsque
c’est possible)
• Par plates-formes et partitions associées

- La base de départ en MIPS
- Les besoins spécifiques en MIPS sur l’année suivante (et au-delà lorsque c’est pos-
sible). A défaut de besoin spécifique, le taux de croissance se verra appliqué
- Les besoins en mémoire par partition
A partir de ces éléments, il est donc possible d’actualiser les besoins en capacité MIPS
pour le 2ième semestre de l’année en cours et d’établir les projections trimestrielles
pour les 3 années suivantes.
Tableau des MIPS par plates-formes

PAGE 66
LiVRE BLANC
Histogramme des MIPS par plates-formes

Le détail des besoins de MIPS par partition est nécessaire pour élaborer ensuite la configuration PR/SM des
différents serveurs hébergeant ces partitions. Le même tableau est élaboré pour la mémoire.
Tableau des MIPS par partition
Elaboration de la configuration des serveurs

La deuxième étape consiste à dimensionner et à configurer les serveurs mainframe.
Cette étape permet de vérifier la capacité des serveurs à répondre aux besoins, d’iden-
tifier les points de rupture et de définir les évolutions de serveurs.
PAGE 67
Dans le cas de figure présenté ci-dessus, les capacités des serveurs sont calculées avec
l’outil zPCR d’IBM. Cet outil a l’avantage de prendre en compte l’impact du nombre de
partitions, de moteurs logiques, et de moteurs spécialisés sur la capacité du serveur.
La capacité évolue en fonction de ces paramètres.
La capacité réelle issue de zPCR est ensuite comparée avec les besoins MIPS valorisés
dans le Capacity Planning, pour afficher les MIPS disponibles (free space) et identifier le
point de rupture. Dans le cas présent, on constate la nécessité de changer de technolo-
gie de serveurs début 2013.
A ce stade, il est possible, voire nécessaire, d’effectuer des simulations de configurations
en prenant en compte les différents modèles de serveurs, le nombre de serveurs du Da-
tacenter (dans notre exemple, nous sommes en mono serveur) et aussi les différences
de technologie (z10, z196, etc.).
Une fois de plus, l’outil zPCR se montre très utile pour réaliser ces différentes configu-
rations et comparaisons.
L’ensemble de ces éléments sera donc pris en compte pour définir les scénarios d’évolu-
tion des serveurs, faire acter le scénario retenu, et intégrer les décisions dans le budget
d’investissement.
Elaboration du Capacity Planning MSU

Si les MIPS évoqués précédemment représentent une quantité de ressources mise à dis-
position des partitions et des plates-formes (ressources garanties par la configuration
des serveurs et le paramétrage de PR/SM), les MSUs servent à valoriser le niveau de
facturation des logiciels MLC d’IBM. Il s’agit donc ici de la notion de R4H (moyenne sur 4
heures glissantes de la consommation des partitions) calculée tous les mois pour l’outil
SCRT d’IBM. Le calcul de cette valeur peut s’effectuer de différentes manières suivant la
mise en œuvre, ou non, du soft capping.
Le Capacity Planning MSU, que nous avons mis en œuvre, est donc élaboré en prenant
en compte :
•L es logiciels MLC d’IBM utilisés sur les différentes partitions actives sur les ser-
veurs z
• Les hypothèses d’évolution d’activité de ces partitions
• Les hypothèses d’évolution de logiciels et de leurs versions
• La mise en œuvre du Softcapping
• Le niveau de facturation actuel des différents logiciels (qui constitue la base de
départ)
• Les changements de technologie hardware qui auront un impact sur la valorisation
des MSUs (z9/z10 : technologie dividende, z196 : AWLC)
A partir de ces éléments, nous établissons le tableau de Capacity Planning MSU sur 3 ans. Ce
tableau est valorisé par trimestre, et par produit. La valorisation s’effectue en déterminant
un pourcentage de croissance annuelle appliqué sur la base (1er trimestre du tableau). Le
pourcentage de croissance est calculé en prenant en compte le Capacity Planning MIPS et
(surtout) la politique d’entreprise sur la facturation logicielle (mise en œuvre de softcap-
ping, maitrise affichée des coûts logiciels, engagement contractuel, etc.)
Ce tableau servira donc à :

•A fficher les évolutions de logiciels (ajout/retrait de produit, changement de version)
•A fficher les niveaux de facturation prévus par logiciel MLC (z/OS, CICS, DB2, etc…)
•P aramétrer les outils de gestion du Softcapping
•V aloriser le budget prévisionnel de l’année suivante
•A ider à gérer (ou à mettre en œuvre) des contrats logiciels de type ESSO
PAGE 68
LiVRE BLANC
Tableau des MSUs par logiciel

Un changement de version de logiciel implique, en général, un changement de tarifica-
tion et la négociation d’un SVC avec IBM.
Le Capacity Planning MSU formalise uniquement la période de recouvrement des 2

versions d’un même produit. L’impact d’un SVC, qui permet de ne facturer qu’une seule
version pendant la durée de la migration (durée du SVC à négocier avec IBM), n’est pas
formalisé dans ce tableau. Celui-ci ne sera pris en compte que dans la valorisation du
budget.
Suivi du Capacity Planning MIPS

Le Capacity Planning MIPS étant élaboré sur des hypothèses parfois fluctuantes, pour
pérenniser ce processus et en tirer tous les bénéfices, il est indispensable de mettre en
place un processus de suivi. Celui-ci doit être en mesure d’afficher sur la période en
cours les comportements des plates-formes et des serveurs par rapport aux prévisions,
ainsi qu’un minimum d’historique.
Les constats sur la période en cours permettront d’identifier d’éventuelles dérives (à la

hausse ou à la baisse), et de déclencher des analyses plus fines pour comprendre l’ori-
gine de ces dérives. Le résultat des analyses et la comparaison avec les indicateurs de
service, permettront de réaliser des actions :
•D
e correction, par exemple au niveau d’une plate-forme (augmentation anormale
de la consommation CPU sans augmentation de l’activité) pour revenir à une situa-
tion dite normale
• D’actualisation exceptionnelle du CP car de nouvelles hypothèses vont modifier

durablement des comportements. Les modifications peuvent être à la hausse (nou-
veau besoin) ou à la baisse (surévaluation du besoin, baisse d’activité, …)
• Des modifications sur les investissements et les évolutions d’infrastructure (antici-

pation sur un upgrade, ou report d’un upgrade)
Cette analyse est importante pour maîtriser toute dérive (détecter et corriger certaines
anomalies de comportement), pour ajuster les besoins de ressources au bon moment, et
enfin (et surtout) pour maîtriser et pérenniser ses investissements.
La partie Historique permet d’afficher les tendances et de vérifier la cohérence des pré-
visions de besoin dans le temps (tendance à surévaluer les besoins). Ce type d’informa-
tion est très utile lors de l’actualisation annuelle du plan de capacité.
Ici, le suivi est effectué mensuellement, sur la période de pointe des serveurs et des
plates-formes. Dans nos exemples de graphe ci-dessous, la pointe est positionnée pen-
dant la période TP (10h-12h).
PAGE 69
Graphe MIPS par serveurs :
Ce graphe permet d’afficher les besoins de MIPS au niveau d’un serveur (CP), et du
niveau maxi de consommation atteint dans le mois pendant la période de charge (TP).
Etant donné que les mesures sont effectuées au ¼ d’heure, il ne s’agit pas de pointe ins-
tantanée. Enfin, ce graphe ne représente pas la quantité de MIPS installée.
Graphe MIPS par plates-formes :
La plate-forme PF2 a connu une phase significative d’accroissement d’activité en juin

2010, puis un pic d’activité exceptionnel en janvier 2011. La courbe de tendance basée
sur les pointes TP valide l’expression des besoins dans le temps.
PAGE 70
LiVRE BLANC
La plate-forme PF10 a connu une décroissance en 2010, puis un arrêt complet en juillet
2011.
Suivi du Capacity Planning MSU

En collectant diverses informations (SCRT, SMF, …), il est possible de suivre les niveaux
réels de facturation des logiciels MLC, de valoriser les contributions des plates-formes
fonctionnant sur les serveurs mainframes, et d’établir les profils de facturation pour la
journée de pointe et pour le mois.
Les différentes restitutions d’information permettent de vérifier la cohérence du Capacity

Planning MSU, d’identifier des différences de comportement, d’ajuster (si nécessaire
et si mis en œuvre) le niveau de softcapping, d’anticiper des impacts budgétaires (à la
hausse ou à la baisse).
Profil du mois :
Ici, on peut constater que le maximum est atteint le 1er du mois, et que ce maximum (au-
delà de 2 700 MSUs) n’a été atteint qu’une seule fois dans le mois. Les autres pointes se
situent en général autour de 2 000 à 2 200 MSUs. Si l’on souhaite réduire son niveau de
facturation, il sera donc nécessaire d’agir uniquement sur cette journée de pointe, dans
la mesure du possible.
PAGE 71
Profil de la journée de pointe :
Ce graphe permet de faire les constats suivants :

• Le maximum de facturation (R4H) se situe dans la tranche horaire 12h-13h.
Celui-ci est lié aux 4 heures d’activité TP précédentes (8h – 12h)
• Ce maximum n’est atteint qu’une seule fois dans la journée. Pour maïtriser et
réduire son niveau de facturation, il faudra donc agir sur la période TP ou sur l’inter-
valle 12h-13h
Suivi par logiciel :

Le plan de capacité MSU a été réalisé et valorisé au trimestre en raison de fluctuations
fortes entre 2 mois. Les états SCRT étant produits tous les mois, les graphes ci-dessous
affichent le niveau de facturation mensuel, la moyenne trimestrielle de facturation et le
capacity planning.
Cas d’un changement de version de produit :

PAGE 72
LiVRE BLANC
Contribution par plate-forme :
La contribution par plate-forme est déterminée à partir du niveau de facturation du z/

OS et de la contribution de chaque partition. Les partitions étant rattachées à une plate-

forme, il est ensuite facile de totaliser les contributions des partitions et d’afficher la
quote-part de chaque plate-forme.
Ce type d’information peut servir à définir des clés de refacturation des logiciels MLC.
PAGE 73
4 CONCLUSION
Arrivé à la fin de ce copieux volume, le lecteur l’aura déjà compris : la maîtrise des coûts
s’aborde de multiples manières et demande plus d’un angle d’approche. Car le coût est
lui-même constitué d’un ensemble complexe d’éléments qui s’agrègent et interagissent
et qu’il s’agit de dénouer l’un après l’autre et tous ensemble. Au moment de le maîtri-
ser, il existe de nombreux leviers d’économie dont chacun ne forme qu’une partie d’une
solution globale dont la construction demande du temps et doit s’adapter au contexte de
chaque utilisateur.
Certaines opérations, l’optimisation des Workloads par exemple, demandent d’avoir déjà
atteint un niveau d’expertise conséquent dans la connaissance de ses consommations
et l’identification de ses points faibles. D’autres, comme la consolidation physique des
machines, constituent la première étape d’une vaste remise en cause par cascade de
nombreux éléments de la chaîne de coûts. D’autres encore, comme la négociation de
nouveaux modèles de licences avec les éditeurs, sont sans cesse à questionner et à ré-
inventer. Dans une telle approche, on constate aisément qu’il reste toujours des marges
de manœuvre, toujours des pistes à explorer et des travaux à conduire.
Mieux maîtriser les coûts de la plate-forme Mainframe contribue à la rendre plus pé-
renne car plus compétitive. Mais cela contribue aussi à créer des modèles pour demain.
Si nous revenons à notre introduction, si nous repartons de cette spécificité du Main-
frame auquel ses quelques décennies d’aînesse donnent souvent un temps d’avance,
nous pouvons faire un pari. Dans dix ans, dans cinq ans, dans trois ans, les démarches
dont nous avons traité ici se verront reproduites dans les environnements distribués, il
s’y posera les mêmes questions, il s’y explorera les mêmes solutions. Ce dont nous vous
avons parlé, ce n’est pas une histoire de Mainframe, c’est une histoire d’informatique.
PAGE 74
LiVRE BLANC
5
ANNEXE
GLOSSAIRE DES TERMES TECHNIQUES

ET ACRONYMES UTILISÉS
L’astérisque signale les termes relatifs aux licences et contrats.
ALS DRDA
Architecture Level Set Distributed Relational Database Architecture
ensemble des fonctionnalités matérielles requis standard d’interopérabilité pour DB2.
par un OS pour s’exécuter. Les ALS permettent
de différencier des générations de matériel et ESCON
d’environnements d’exploitation. Enterprise System Connection
architecture et protocoles utilisés pour
AWLC* l’acheminement des entrées-sorties sur
Advanced Workload Licence Charge grands systèmes (remplacé par FICON).
une licence MLC réservée aux machines de
génération z196. ESSO*
Enterprise services and software option
un contrat global de fourniture de logiciels
CICS avec IBM qui procure de sérieuses remises
Customer Information Control System sur un package de logiciels en échange d’un
moniteur transactionnel d’IBM capable de engagement sur trois ans.
gérer un très grand nombre de transactions
simultanément avec une forte économie de EWLC *
moyens. Entry Workload Licence Charge
tarification IBM à l’usage pour les Mainframes
CoD d’entrée de gamme.
Capacity-on-demand
modèle contractuel dans lequel l’utilisateur FICON
dispose de ressources physiques dormantes Fiber Connectivity
(Processeurs, mémoire, stockage, etc.) qu’il déclinaison de Fibre Channel pour les liens I/O
ne paye qu’au moment où il les active. Moyen sur z Architecture.
d’éviter une mise à jour classique.
FWLC*
Crypto Express 3 Flat Workload Licence Charge
co-processeur dédié aux opérations tarification IBM fixe (vs vWLC : Tarification
cryptographiques sur les machines z Series. à l’usage). Les produits non éligibles à la
tarification à l’usage sont généralement
DB2 facturés en mode « Flat ».
le SGBDR d’IBM souvent utilisé sur ses
machines de gamme z. Geoplex/GDPS
Geographically Dispersed Parallel Sysplex
DFHSM une extension de Parallel Sysplex qui permet
Data Facility Hierarchical Storage Manager d’automatiser la reprise sur un site de secours,
utilitaire de gestion du stockage qui vise à de façon à garantir une continuité de service
simplifier le placement des données sur le même en cas de sinistre majeur.
support le plus approprié en termes de rapport
coût/performances, par exemple en plaçant sur HiperSockets
des disques lents ou des bandes des données technologie de communication hautes-
peu ou plus accédées. On parle de stockage performances entre partitions hébergées au-
hiérarchique ou désormais de tiering. dessus d’un même hyperviseur. Il s’agit en fait
de réaliser l’équivalent de liaisons TCP/IP en
mémoire entre LPARs faisant éventuellement
fonctionner différentes familles de systèmes
PAGE 75
d’exploitation.
HMC LPARs
Hardware Management Console Logical PARtition
console d’administration IBM basée sur partition logique qui fait apparaître un sous-
Linux pour les systèmes partitionnés et SMP ensemble d’une machine comme un serveur
des différentes familles de serveurs IBM. distinct. Sur z, les LPARs sont gérées par
HMC permet en particulier de configurer l’hyperviseur PR/SM. Un Sysplex ou un Parallel
et d’administrer les partitions logiques et Sysplex peut être composé de plusieurs LPARs.
les profils de partitions, de reconfigurer L’isolation entre LPARs sur une même machine
dynamiquement les LPARs, d’activer et est si forte qu’on peut les considérer comme
d’administrer les ressources Capacity on des systèmes réellement distincts.
Demand.
MLC*
HyperPAV Monthly Licence Charge
evolution du dispositif PAV (Cf ce sigle) qui vaste famille de licences à facturation
permet une gestion plus fine et plus dynamique. mensuelle selon l’activité enregistrée.
ICF MTBF
Internal Coupling Facility Mean Time Between Failure
une partition dans laquelle s’exécute temps moyen entre deux pannes, valeur
uniquement du code nécessaire notamment statistique indicative de la fiabilité d’un
au partage intègre des données et à la système.
synchronisation des partitions z/OS en
environnement Sysplex. MWLC*
Midrange Workload Licence Charge
IFL une licence MLC qui s’applique à VSE et une
Integrated Facility for Linux douzaine de middlewares.
processeur dédié à l’exécution de Linux sur z et
bénéficiant d’une tarification attractive. OOCOD*
On Off Capacity On Demand
IMS modèle de tarification qui autorise l’activation
Information Management System et la désactivation de processeurs et d’unités
une base de données hiérarchique développée mémoire pour répondre à des pics de charge,
par IBM en 1966, devenue depuis un système de avec une facturation trimestrielle à l’usage.
gestion de transactions complet toujours utilisé.
OSA Express 3
IPLA* carte d’interface 4 ports 10 Gbits Ethernet pour
International Product Licence Agreement mainframes System z10.
une licence de type OTC (achat + maintenance).
OTC*
Linux One time charge
système d’exploitation inspiré d’UNIX dont modèle de licence simple correspondant à la
il reprend les principes, développé sur un logique achat + support.
modèle collaboratif et placé sous une licence
dite Libre (droit d’accès aux sources, droit de PAV
redistribution, partage des modifications). Parallel Access Volume
technologie permettant de passer plusieurs
Linux for z commandes d’entrées-sorties en même temps.
système d’exploitation Linux for S/390
(Architecture 31-bit) ou Linux for zSeries Plate-forme
(Architecture 64-bit) fonctionnant sur des désigne l’ensemble des partitions dédiées au
Mainframes en partage avec l’infrastructure z/ fonctionnement d’un Système d’Information.
OS et pouvant utiliser un ou des processeurs Un serveur Mainframe héberge en général
IFL En LPAR (z9, Z10) en natif ou avec z/VM plusieurs plates-formes qui correspondent à
(accueille des centaines de serveurs) ou FICON des clients différents pour un hébergeur, ou
(mode FCP) permettant l’accès aux SAN. à des typologies différentes (production, pré-
production, développement, etc.).
PAGE 76
LiVRE BLANC
Power7 Blade SAS
des ”lames“ serveur (serveurs intégrés sous Serial Attached SCSI
la forme d’une carte enfichable) équipées des interface informatique qui fait passer des
processeurs RISC Power7 d’IBM, celui qui commandes SCSI (très utilisées pour le

anime les gammes Unix du constructeur. Une stockage) sur une interface série, remplaçant
fois installées dans un châssis zEnterprise du SCSI parallèle avec de meilleurs débits et de
Blade Center Extension relié au Mainframe, ces moindres contraintes physiques.
lames fonctionneront comme un sous-système
du Mainframe. Dans cette configuration, le SATA
Mainframe conserve le rôle de contrôleur global Serial Advanced Technology Attachement
des traitements et délègue certaines tâches aux interface informatique pour relier des
lames Power7. périphériques de stockage de masse (souvent
des disques durs) à un système. La S-ATA a pris
PSLC* le relais de l’interface ATA.
Parallel Sysplex Licence Charge
licence utilisable dans les configurations SLA
Sysplex (cluster), qu’elles comportent plusieurs Service Level Agreement
machines ou une seule. contrat dans lequel se formalise la qualité
de service requise entre un prestataire et
R4H un client. SLA qualifie aussi souvent les
Rolling 4h Average éléments caractéristiques du contrat de
unité de mesure propre à IBM basée sur service (performances attendues, modalités de
l’utilisation des resssources d’une partition fonctionnement, etc.).
ou d’une plate-forme au cours des quatre
dernières heures (moyenne des 48 dernières Solution Edition*
mesures de consommation MSU instantanées). série d’offres packagées incluant matériel,
logiciel et support et orientées autour de grands
RPO blocs fonctionnels : sécurité, développement,
(Recovery Point Objective) Linux, SAP, Websphere, etc.
objectif de point de reprise informatique :
objectif de la maîtrise d’œuvre quant à la Soft Capping*
perte de données maximale tolérable en cas une fonctionnalité qui assure la maîtrise de la
d’incident. Généralement exprimée sous forme facturation à l’usage des logiciels en instaurant
d’une durée : un RPO de 15 minutes signifie pour une partition (LPAR) une limite maximum
que toutes les données enregistrées jusque 15 de consommation de MSU calculée sur une
minutes avant le sinistre seront récupérées. moyenne 4 heures (R4H).
RTO SSD
Recovery Time Objective Solid State Drive
délai de reprise : durée cible nécessaire à la disque dur sans pièces mobiles, le stockage
reprise des activités métiers suite à incident s’effectuant non plus sur des plateaux
ou déclaration d’un incident. Généralement magnétiques en rotation mais sur des puces
exprimée sous la forme d’une durée : un RTO mémoires.
de deux heures signifie que deux heures après
l’apparition d’un incident ou sa déclaration Sub Capacity*
le service utilisateur devra être de nouveau la possibilité de facturer un logiciel pour une
disponible. fraction de processeur et non pas pour un
processeur complet. La plupart des licences
SALC* MLC comportent des options sub capacity.
Select Application Licence Charge
une licence MLC applicable uniquement S&S
à Websphere MQ sur des machines sous Subscription and support
certaines licences MLC (AWLC, AEWLC, WLC ou maintenance associés aux logiciels IBM IPLA
EWLC). (zOTC).
PAGE 77
Sysplex & Parallel Sysplex z/Architecture
un System Complex ou Sysplex est l’association l’architecture interne des générations récentes
au sein d’une même unité logique de plusieurs de machines z compatibles 64 bits.
processeurs fonctionnant comme un système
unique. Le Parallel Sysplex est l’application zELC*
de ce mode de fonctionnement à plusieurs zSeries Entry Licence Charge
machines (jusque 32) constituées en cluster et licence à facturation mensuelle réservée aux
fonctionnant avec une seule image système à petites machines mainframe (zSeries 800, z890,
des fins de performance et/ou de disponibilité. z9 BC et z10 BC).
SzLC* zIIP
System z Lifecycle Charge System z Integrated Information Processor
licence spécifique au support z/OS. un processeur spécialisé, équipé d’un
microcode spécifique, initialement conçu pour
VU* décharger les processeurs généralistes de
Value Unit certaines tâches liées à l’exécution de DB/2.
unité de valeur propre à IBM, appuyée sur le Le domaine d’utilisation des ZiiPs a depuis été
nombre de MSUs, de moteurs, ou d’autres étendu à d’autres traitements avec des logiciels
unités de base, et utilisée pour la facturation de IBM et non-IBM.
certains utilitaires logiciels dont les outils DB2,
IMS et CICS, les produits Tivoli pour z/OS, et zNALC*
autres. System z New Application Licence Charge
licence z/OS à prix réduit pour des LPARs dans
VWLC* lesquelles s’exécutent certaines applications
Variable Workload Licence Charge qualifiées par IBM : SAP, Siebel, Peoplesoft et
licence dérivée de WLC. autres.
Websphere MQ z/OS
nouveau nom de MQ Series, un service de système d’exploitation pour Mainframes lancé
communication entre applications en mode en 2011 et héritier d’une lignée qui remonte
message avec utilisation de files d’attente. aux années 60. z/OS prend la suite d’OS/390 et
Cet ensemble d’outils permet en particulier combine les capacités de MVS (Multiple Virtual
l’échange d’informations et la réalisation de Storage) avec les Unix System Services qui
transactions entre plates-formes hétérogènes assurent l’exécution de programmes Unix sur
(zOS, Unix, Windows, etc.). la plate-forme.
WLC* z/TPF
Workload Licence Charge Transaction Processing Facility
modèle de facturation mensuelle de licence à un système d’exploitation uniquement
l’usage applicable aux machines fonctionnant transactionnel (temps réel) pour mainframes,
avec z/OS ou z/TPF en mode z/Architecture utilisé principalement par les applications
64 bits. devant absorber un débit transactionnel très
important. Ex : Systèmes de réservations
zAAP de compagnies aériennes ou ferroviaires,
System z Application Assist Processor transactions cartes bancaires, etc.
un processeur spécialisé, équipé d’un
microcode spécifique, conçu pour effectuer z/VM
certains traitements Java et XML. Ces génération la plus récente des hyperviseurs
processeurs ont la particularité de ne pas Mainframe développés par IBM dès les années 60.
modifier le nombre de MSU de la plate-forme
à laquelle ils sont associés, ce qui évite une z/VSE
augmentation des coûts logiciels. Depuis le une autre souche de systèmes d’exploitation
lancement des ZaaPs, plusieurs éditeurs ont Mainframe d’IBM, descendant du DOS/360
adapté leurs logiciels pour en tirer parti. qui équipait les premières générations de ces
machines.
PAGE 78
A propos du
Le Club des Responsables
d’Infrastructures et de Production
Le Réseau Social des Responsables d’Infrastructures et de Production
Un objectif : Rendre ses membres plus performants dans leur métier
Un Crédo : Indépendance vis-à-vis des fournisseurs
Un Cercle de confiance pour :
• Partager visions et retours d’expériences
• Echanger et travailler collectivement sur les technologies, les ressources humaines, les organisations
et processus, les approches financières des projets, les relations avec les offreurs
• Pousser un projet en interne en s’appuyant sur les travaux du CRiP
• Promouvoir les fonctions d’Infrastructure et de Production au sein des Entreprises
• Créer un réseau de communication rapide et efficace entre dirigeants
Philippe SERSOT
Président du CRiP
CTO CA-CIB
Partager nos expériences
J’ai trouvé très intéressante l’initiative du CRiP de réunir des Responsables de production en charge
d’informatiques clientes variées dans un cercle où n’interviennent pas les fournisseurs. Cela permet de
confronter ses propres idées aux retours d’expériences d’autres sociétés plus avancées sur certains sujets. Une
démarche d’autant plus indispensable que nous nous trouvons, dans le métier de la production informatique,
particulièrement exposés à des situations de grands changements, tels que la virtualisation dans ses multiples
dimensions ou le cloud computing. J’apprécie particulièrement ce souci d’apporter, partager et recevoir tout
en même temps ces indispensables retours d’expériences.
Jean-Paul AMOROS
GDF SUEZ
CTO/Directeur de la Production Informatique,
membre du Bureau Exécutif du CRiP
Le Bureau exécutif du CRiP (CTO Alliance France) 2011-2012

Jean-Paul AMOROS Jean-Pierre DUMOULIN Philippe MICHON
CTO – Directeur des Infrastructures CTO – PSA PEUGEOT CITROEN CTO - Directeur de la Production
Groupe – GDF Suez Informatique - ALLIANZ
Patrick DURIEZ
Pierre AUGUSTE CTO - Directeur Infrastructure Jean-Philippe MURE
CTO – Directeur de l’ingénierie des et Production - CASINO CTO - Directeur de la Production
Infrastructures – SFR Informatique - GROUPAMA
Olivier HEITZ
Marc BÉGUÉ CTO - Directeur des opérations Francis ROBERT
CTO - Sous-directeur Exploitation et de la qualité de services - CTO - Directeur de l’Agence
Architecture - CNES BOUYGUES TELECOM technique de l’AP-HP
David DECOVEMACKER Daniel JONDET Philippe SERSOT

CTO – AUCHAN Hypermarchés CTO - GENERALI CTO – CA CIB (Crédit Agricole
Investment Bank)
Thierry DESVIGNES Marc LIMODIN
CIO - DSI – CNP ASSURANCES CTO - Directeur de la Production Lionel VERLAINE
Informatique - CTO - Directeur de l’Ingénierie et de
Frédéric DIDIER LA BANQUE POSTALE la Gouvernance des Infrastructures
CTO - Directeur Production et Outils de l’exploitation IT –
Informatique – CREDIT FONCIER ORANGE FT
PAGE 79
Plus de 135 grandes entreprises
françaises adhèrent ou sont
en cours d’adhésion au CRiP
TOTAL CREDIT FONCIER GROUPE PREVOIR
MAAF EDF PIERRE FABRE
L’OREAL ESSILOR INTERNATIONAL AGIRC-ARRCO
GROUPAMA SI LOUIS VUITTON MALLETIER COFACE
DARVA GENERALI BUREAU VERITAS
CREDIT AGRICOLE SA GDF SUEZ COFIDIS
ADP GSI SFR CFAO
AEROPORTS DE PARIS SI2M VALEO
ERDF VENTE PRIVEE.COM KIABI
GIE ALLIANZ INFORMATIQUE I-BP CNAV
EIFFAGE AIR FRANCE MATMUT
AIR LIQUIDE MACIF SIMPLY MARKET
MINISTERE DES FINANCES CARREFOUR GROUPE GROUPE AGRICA
RENAULT NATIXIS BOUYGUES CONSTRUCTION
LA FRANCAISE DES JEUX GROUPE ADEO DARTY
SWISS LIFE OECD DIRECT ENERGIE
KEOLIS ORANGE FT GROUPE BANQUE PALATINE
AUCHAN INTERNATIONAL PMU ISS SERVICE
TECHNOLOGY ARKEMA AIRBUS
AVIVA RESEAU FERRE DE FRANCE BNP Paribas
SOCIETE GENERALE RHODIA Uneo
AXA TECH SAINT GOBAIN Unibail Rodamco
LAFARGE SANOFI AVENTIS Legrand
MUREX CA SILCA Decathlon
NEXTER GROUP CAISSE DES DEPOTS Tarkett
NORBERT DENTRESSANGLE LA BANQUE POSTALE
Etablissement français
BOUYGUES TELECOM CREDIT AGRICOLE CIB du sang
CASINO CANAL + GIE PROD (ARAMICE)
THALES GROUP APHP GCE TECH (CAISSE D’EPARGNE)
CNES PSA PEUGEOT-CITROËN BIBLIOTHEQUE NATIONALE
VALLOUREC ALSTOM DE FRANCE
MANPOWER SCOR DISIC (BUREAU DU 1er MINISTRE)
RTE STIME EAU DE PARIS
BIC POLE EMPLOI DASSAULT SYSTEMES
CHOREGIE DEXIA INSERM
FRANCE TELEVISIONS LA POSTE LOMBARD ODIER
AMUNDI SNCF MINISTERE DE LA JUSTICE
DISNEY GENERALE DE SANTE MINISTERE DES TRANSPORTS
CREDIT IMMOBILIER DE FRANCE VOLVO IT (SETRA)
DANONE SPIE POMONA
DCNS ETAM MIPIH
CNP ASSURANCES SUPERMARCHES MATCH RIO TINTO
INA EULER HERMES AG2R LA MONDIALE
CPSIAT – ARMEE DE TERRE PRAXIS SERVIER Etc…
Le CRiP (Association Loi 1901) compte 135 grandes entreprises ou entités utilisatrices des
technologies de l’information, adhérentes ou en cours d’adhésion. Il rassemble une communauté
de plus de 1200 membres, responsables d’infrastructure ou de production.
Le CRiP est un cercle de confiance, lieu d’échanges et d’informations entre les différents
membres confrontés aux mêmes défis financiers, technologiques et organisationnels.
PAGE 80
Charte d’Ethique et
d’Engagement du CRiP
Le Club des Responsables d’Infrastructure et de Production est constitué sur la base de
valeurs et de principes d’action et de comportement, fondés sur des rapports de confiance
permanents entre ses membres.
Les membres sont les représentants des sociétés adhérentes du CRiP.
Principes d’action
· Respect de la loyauté
Les membres du CRiP ont pour principe la loyauté à l’égard des autres participants afin
d’instaurer et de maintenir des relations de confiance durables.
· Participation active
Les sociétés adhérentes au CRiP et leurs représentants membres du CRiP s’engagent à
contribuer activement à la vie du Club en apportant leur expérience et leur savoir-faire aux
travaux collectifs.
Les sociétés adhérentes s’engagent

- à répondre dans un délai convenable aux différents questionnaires qui pourraient leur être
envoyés
- à faire participer au moins un de leurs représentants à au moins un groupe de travail
- à favoriser la participation de leurs représentants aux plénières du CRiP
- à promouvoir le CRiP au sein de leur organisation
Les membres représentants s’engagent

- à se comporter en ambassadeur du CRiP et à promouvoir le CRiP auprès de leurs pairs et
des fournisseurs
- à participer activement dans la mesure de leurs compétences, de leurs moyens, et de leurs
autorisations internes aux conférences CRiP/ itiForums, soit en tant que membre d’un co-
mité de programme, à travers un témoignage, une table ronde ou en aidant à la production
de contenu
Principes de comportement
· Confidentialité
Chaque membre du CRiP s’engage à ne pas divulguer à des tiers les informations profes-
sionnelles présentées, sauf accord explicite des membres émetteurs et du bureau exécutif du
Club. Chacun des participants, membre permanent ou occasionnel, s’interdit d’utiliser direc-
tement ou indirectement, à des fins personnelles, des informations sensibles qu’il pourrait
détenir dans le cadre du Club.
· Conflits d’intérêts
Chaque membre du CRiP se doit d’éviter toute situation de conflit entre les intérêts du Club
et ses intérêts personnels ou ceux de ses proches.
Le Club est un club d’utilisateurs.
Cependant certains de ses membres peuvent appartenir à des sociétés adhérentes qui pos-
sèdent dans leurs missions une offre de service pour les autres adhérents. Il est impératif
dans ce cas que les représentants membres de ces dites sociétés aient un comportement
irréprochable et n’utilisent pas ce cercle de confiance pour promouvoir les offres de services
de la société qui les emploie.
PAGE 81
Les 17 Groupes de travail thématiques
Le mode de fonctionnement
Actuellement, 17 groupes de travail thématiques se réunissent tout au long de l’année.
Les travaux de ces groupes sont présentés à l’ensemble des membres à l’occasion des CRiP
Thématiques et de la Convention annuelle du CRiP.
STOCKAGE MÉTIERS
Animé par Animé par
François DESSABLES Marc LIMODIN
Architecte SAN Stockage Directeur des Techniques
PSA PEUGEOT-CITROËN et des Infrastructures
LA BANQUE POSTALE
Objectifs :
Identifier et partager les bonnes pratiques dans le domaine Objectifs :
du stockage, établir le cadre d’usage des différentes Traiter de l’évolution des métiers de l’infrastructure et de la
technologies. production, des problématiques de ressources humaines et
des problématiques d’organisation.
Thèmes :
- Virtualisation du stockage/de la sauvegarde Thèmes :
- Déduplication - Panorama des métiers et de leurs changements
- Sauvegarde sur disques - Sous-traitance
- Réplication CRiP Thémat -G estion des ressources Livre Blanc
- Convergence LAN-SAN ique humaines de production Métiers
- Architectures Stockage
(Prévu Juin 2012)
13 décembre
Livre Blanc 2011
Analyse et Tendance
du Stockage V.2
(édité en Juin 2011)
BASES DE DONNÉES
Animé par
Jean-Paul VEZARD
Ancien Responsable DBA à
la Société Générale
DATACENTER & Objectifs :

Etudier les problèmes d’optimisation des SGBD.
EFFICACITÉ ENERGÉTIQUE Thèmes :

- Métrologie
Livre Blanc
Animé par -S olutions de tolérance
aux pannes Consolidation
Dominique ROCHE et Mutualisation
Responsable Standardisation - Méthodes de mutualisation
- SGBD open source (1er trimestre 2012)
Infrastructure,
ORANGE – FT Group
Objectifs :
Identifier les meilleures pratiques en production pour le datacenter
ITIL
Animé par
de demain et pour l’optimisation de la consommation des composants
d’infrastructure. Anne JAFFRE
Directeur des Techniques
Thèmes : responsable Qualité IT, ESSILOR International
- Optimisation énergétique Et Eric BOUVET, responsable Service
- PUE, définition d’indicateurs Management, ARKEMA
- Outillages de mesure
- Bonne gestion du froid Objectifs : Les Assises
- Green IT, design de site Rassembler et documenter les bonnes ITIL
pratiques d’utilisation d’ITIL et des CMDB 5 avril 2012
Livre Blanc CRiP Thémat
Analyse et Tendance, ique Thèmes :
DataCenter-G - Bénéfices d’ITIL
vers le Datacenter idéal V.2 reen IT
(édité en juin 2011) 19 janvier 2012 - Identification des processus ITIL prioritaires
- Adoption d’ITIL v3 et difficultés de mise en oeuvre
- Outils à adopter en soutien d’une démarche ITIL
Dossier Technique Datacenters : - Mise en œuvre de CMDB
Efficacité Energétique et indicateurs - Forces et faiblesses des outils CMDB et de Service desk
de performances - Mesure de la performance des processus
(édité en mars 2010) -R eprésentation et nommage des composants IT en CI
dans la CMDB
PAGE 82
LOW COST VIRTUALISATION
Animé par
Frédéric DIDIER
SERVEURS &
Directeur Production Informatique
CREDIT FONCIER
POSTES DE TRAVAIL
Animé par
Objectifs : Marie-Christine MOULLART
I nventorier les pratiques d’infrastructure de rupture capables Responsable Exploitation /
de fournir des services à bas coût et les pratiques associées. Direction Infrastructures et Support
GENERALI
Thèmes :
- Logiciels open source Objectifs :
- Bring-your-own-PC Recenser les expériences et les solutions
- Appliances analyser les enjeux, décrire la démarche projet.
- Différenciation des classes de service dans le datacenter
- Utilisation de services et matériels grand public Thèmes :
-S
olutions, arguments en faveur de la virtualisation
Fiche Pratique : La démarche Low Cost, décembre 2011 bonnes pratiques, pièges et limites, impacts sur les projets
les hommes et les services, les gains financiers et de niveaux
de services
CLOUD COMPUTING Dossier Technique CRiP Thémat
ique
Animé par Hyperviseur Hyper vi se ur s
Patrick JOUBERT (édité en Décembre 2010) s 20 12
15 mar
Architecture et Technologie
Transformation Director
Poste de Travail
Société Générale
Stéphane GEISSEL
manager technico-financier Nouvelle
SI grand public
SFR Génération
Objectif :
Etudier les évolutions du poste de travail d’entreprise en
Objectifs : 2012, définir les bonnes pratiques d’usage, établir les
Comprendre et analyser les technologies du cloud computing avantages économiques
pour déterminer leurs conditions d’usage.
Thèmes
Thèmes : - Réseaux sociaux d’Entreprise
- Sécurité et Cloud : quelle check-list de sécurité utiliser dans - Migration Windows 7
nos opérations Cloud ? -C lients légers, virtualisation du poste de travail, zero client,
- Gestion des aspects contractuels du Cloud (question sera etc.
portée par un GT commun Syntec numérique - e-SCM – CRiP) - Consumérisation des terminaux
- Le Paas : pour quels besoins ? - Tablettes, smartphones.
- Cloud et Informatique Durable - Démarche Bring-your-own-Device
- Facturation à la demande et refacturation interne en mode
cloud.
- HPC et Cloud : tour d’horizon, progrès depuis la campagne
2010-2011
ARCHITECTURE
Livre Blanc
Enquête et Analyse de Tendances,
Les Assises
TECHNIQUE
Modèles économiques du Cloud
Computing, Incidence sur les
métiers de l’Infrastructure et
du Cloud et de
Réseaux Socia s
D’ENTREPRISE
Animé par
de la Production, Cloud et HPC 2 février 2012ux
(édité en Juin 2011) Noël CAVALIERE
Responsable d’Architecture d’Entreprise
PSA PEUGEOT CITROEN
Mainframe
Animé par Sébastien PONS
Bruno KOCH Responsable de l’architecture Infrastructure,
Directeur Délégué des normes et standards
Architecture Système Mainframe CREDIT AGRICOLE CIB
GCE TECH (CAISSE EPARGNE)
Objectifs :
Objectifs : Analyser les modèles de standardisation et de mise en oeuvre
Gérer, optimiser et mieux maîtriser les coûts sur Mainframe, de modules opérationnels pour la construction du SI.
identifier les bonnes pratiques, inventorier les évolutions et
optimisations possibles. Thèmes :
- Perception de l’architecture technique d’entreprise
Thèmes : - Définition du métier d’architecte technique
- Modèles de facturations - Bonnes pratiques
- Panorama de l’offre logicielle CRiP Thémat
ique - Référentiels et outils de cartographie
- Rationalisation et consolidation Maîtrise des co
- Tendances du marché ûts
Mainframe
17 Novembre
Livre Blanc 2011
Mainframe - Z/OS
(Novembre 2011)
PAGE 83
PRA GOUVERNANCE
Animé par Animé par Animé par
Luc VRIGNAUD François TETE, Maryse NICLI
Responsable Division Président d’honneur et Responsable Départements Projets,
Support et Sécurité Secrétaire Général Club Intégration et Correspondants Métiers
MACIF de la Continuité d’Activité GENERALI
Objectifs : Objectifs :
Etablir le cadre technique et opérationnel des plans de Déterminer les conditions de mise en place de modèles
reprises d’activité. de gouvernance dans l’informatique de production.
Thèmes : Thèmes :
- Concepts et vocabulaire PRA - Opérations d’alignement métier
- Architectures - Gouvernance des contrats
- Cohérence applicative -V aleur ajoutée dans des environnements
- Critères de déclenchement fortement externalisés
- Maintien en conditions opérationnelles
- Validité probante d’un PRA
Fiche Pratique Alignement Stratégique
Livre Blanc de la Production Informatique aux
Plan de Reprise d’activités Métiers de l’Entreprise V.2
(PRA) (éditée en Juin 2011)
(édité en février 2011)
En association avec
AUTOMATISATION & Réseaux, mobilité,

ORCHESTRATION collaboratif
Hugues FONDEUX Eric Cambos
Chargé de Mission Evolution de l’Infrastructure Network & Telecom Manager
PSA PEUGEOT CITROEN CREDIT AGRICOLE CIB
Objectifs : Objectifs :
Etudier l’automatisation des processus d’exploitation Traiter de l’ensemble des problématiques liées aux réseaux
informatique et établir les bonnes pratiques associées. d’entreprise, en particulier la gestion de la mobilité et
l’exploitation des outils de travail collaboratif.
Thèmes :
- Gestion de fermes de serveurs et de Clouds Thèmes :
- Provisioning - Haute disponibilité des réseaux
- Accélération des PRA - Convergence SAN-LAN
- Traitement automatisé d’incidents - Le collaboratif Les Assises
-L a mobilité, les nouveaux terminaux du Cloud et de
Réseaux Socia s
- Outils du marché
- Difficultés rencontrées (tablettes, smartphones, ByoPC)
- Analyse de rentabilité - Réseaux et Cloud Computing 2 février 2012ux
ANALYSE DES COÛTS

DE LA PRODUCTION CRiP Toulouse
Sasun SAUGY Marc Bégué
Chargé de Mission Infrastructure & Production
Sous-Directeur Exploitation Architecture
MINISTERE DES FINANCES ET DE L’ECONOMIE
CNES
Objectifs :
Établir un modèle standardisé d’analyse des coûts qui prenne
réellement en compte les spécificités de la Production.
Objectifs :
Thèmes : Traiter localement de problématiques nationales et de ques-
- Inventaire des bonnes pratiques tions propres à la région toulousaine
- Analyse des modèles existants
- Méthodes de benchmarking des coûts Thèmes :
- Construction d’un référentiel de coûts - Licencing logiciel
Infrastructure et Production - Calcul hautes performances
- Métiers de l’Informatique et de la production
- Spécificités du marché régionale sud-ouest
Fiche Pratique :
référentiel d’Analyse des coûts d’Infrastructure Autres Groupes en cours de constitution :
et de Production (Prévu pour Juin 2012) CRiP Rhône-Alpes, CTO Alliance UK,
CTO Alliance Luxembourg
PAGE 84
Les livrables du
Les Observatoires des Directeurs d’Infrastructures et En quatre ans d’activité, bon nombre de documents
de Production sont une initiative du CRiP. Ces obser- ont déjà été publiés. Parmi les plus significatifs,
vatoires regroupent l’ensemble des documents pro- mentionnons :
duits par les groupes de travail à l’usage des membres - Livre Blanc Enquête et Analyse des Tendances Serveurs
du CRiP. - Enquête et Analyse des Opérations informatiques
- Enquête et Analyse des tendances liées au Datacenter
Ces documents sont de plusieurs types : - Livre Blanc Meilleures Pratiques du DataCenter V1 & V2
• Enquête et Analyse des tendances - Enquête et Analyse des Tendances du Stockage V1 & V2
• Livre Blanc : les meilleures pratiques - Enquête et Analyse des Tendances CMDB
• Guide de rédaction d’appel d’offre - Cloud Computing : Définitions et Concepts, Enquête et
• Fiches pratiques Analyse des Tendances
- Fiches Pratiques Alignement Stratégique de la
Production Informatique aux Métiers de l’Entreprise
Les Enquêtes et Analyses de tendances sont issues V1 & V2
de questionnaires renseignés par les membres du - Dossier Technique Datacenters : Efficacité Energétique
CRiP. L’analyse des résultats recueillis permet de me- et indicateurs de performances
surer et d’observer l’évolution des enjeux des CTOs et - Dossier d’Analyse Technologique : Les Hyperviseurs
de leurs infrastructures. En outre, elle met en relief serveurs x86
les grandes tendances liées aux principaux challenges - Livre Blanc PRA Définitions, Concepts, Bonnes Pratiques
des productions informatiques. et Enquête
- Livre Blanc Cloud Computing, enquête et tendances,
Dans le cadre de l’Observatoire des Directeurs d’In- modèles économiques, conséquences sur les métiers de
frastructures et de Production, chaque groupe de tra- la Production, Cloud et HPC
vail actif apporte une contribution importante dans - Fiche pratique Que va apporter la CMDB ?
l’élaboration de documents de référence. - Livre Blanc Mainframe : Maîtrise des coûts, Enquête et
analyse des tendances.
Il existe actuellement, 17 groupes de travail actifs du
CRiP : Stockage, Data Center et Efficacité Energé- A paraître :
tique, ITIL, Mainframe, Cloud Computing, Architecture - Fiche Pratique Architecture Technique d’Entreprise
Technique d’Entreprise, PRA-PCA, Virtualisation et indicateurs de performance associés
des serveurs et des postes de travail, Bases de don- - Livre Blanc : Consolidation et mutualisation des bases
nées, Automatisation et Orchestration, Gouvernance, de données
Analyse des coûts de production, Réseaux – Mobilité - Fiche Pratique : La démarche low-cost
– Collaboratif, Poste de Travail Nouvelle Génération,
Low-Cost, Métiers. Plusieurs Groupe sont en forma- Tous ces ouvrages deviennent inéluctablement une
tion fin 2011 (Sécurité, Systèmes et plates-formes, référence importante pour les CTOs. Ils permettent
Archivage, Big Data. de s’affranchir d’études parfois longues et coûteuses
et de se « benchmarker » par rapport aux grandes
tendances actuelles. Plus généralement, ils
constituent des outils reconnus pour l’amélioration de
la productivité.
Nicolas COURAUD
Responsable de la coordination
des travaux du CRiP
Le Cercle CTOs
Animé par Philippe Sersot, Président du CRiP, CTO de CA-CIB

Les CTOs des grandes productions françaises se rencontrent périodiquement dans ce cercle de
confiance exclusif. Au sein de cet espace d’échanges ouverts et en toute confidentialité, ils abordent
les questions stratégiques qu’ils jugent essentielles. Ils partagent en direct leurs expériences afin de
renforcer leur expertise et de prendre ainsi des décisions plus efficaces dans les domaines en rapide
évolution de l’infrastructure et de la production.
PAGE 85
> Les Assises du Cloud et des Réseaux
Sociaux d’Entreprise - 2 février 2012
> Les Assises ITIL - 5 avril 2012
Le CRiP a décidé d’élargir son format «CRiP Thématique» et de participer, pour
certains sujets, à un nouveau format d’événement d’une journée organisé by
itiForums, «les Assises». Comme pour les CRiP Thématiques, un accent sera mis
sur les retours d’expérience «vraie vie», mais avec également une vue applicative
et métier, les avancées des groupes de travail du CRIP ainsi que sur les
éclairages d’experts et d’analystes. Les Assises apporteront également une vue
rapprochée des offres et de la stratégie des principaux fournisseurs de solutions
en France tant sur le volet infrastructure que sur le volet applicatif et métier,
essentiels dans ces révolutions en marche.
Programme et Inscription sur www.itiforums.com
Les conférences CRiP Thématiques programmées en 2012

L’Etat de l’Art et la Traduction Opérationnelle des Services
et Technologies dans la vraie vie de l’Entreprise
Stockage > 13 décembre 2011
DataCenter-Green IT > 19 janvier 2012
Hyperviseurs > 15 mars 2012
Une relation privilégiée avec itiForums

Véritable associé du CRiP, ITIFORUMS est
chargé de la communication, de la production
et de la diffusion des documents et vidéos issus
des travaux du CRiP, de l’organisation des
évènements (Convention, CRiP Thématiques,
CERCLE i), du référencement fournisseurs,
de la relation avec les partenaires stratégiques
du CRiP, et de la relation avec les partenaires
fournisseurs du CRiP (présence de porte-
parole aux évènements propriétaires, voyages
d’étude, etc..)
Le réseau social des professionnels

de l’Infrastructure et de la Production
ItiForums interconnecte et informe les
différents groupes – utilisateurs, membres
du CRiP, fournisseurs de services et de
technologies – qui composent la communauté
de l’Infrastructure et de la Production.
Retrouvez les contenus produits par le CRiP sur www.itiforums.com

PAGE 86
Contacts
Club des Responsables d’Infrastructures et de Production
contact@crip-asso.fr
www.crip-asso.fr
En application de la loi du 11 mars 1957, il est interdit de reproduire ; sous forme de copie,
photocopie, reproduction, traduction ou conversion de ce livre blanc que ce soit mécanique ou
électronique, intégralement ou partiellement le présent ouvrage, sur quelque support que ce
soit, sans autorisation du CRiP.
15 rue vignon
75008 PARIS
www.crip-asso.fr
Création : fred.lameche - www.anousdejouer.fr

2011 11 18 11 42 15 Livreblanc Mainframe Web

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2011 11 18 11 42 15 Livreblanc Mainframe Web

Transféré par

Droits d'auteur :

Formats disponibles

Club des Responsables

Assistance éditoriale : Renaud Bonnet Novembre 2011

3. Maîtrise des coûts sur plate-forme z 28

3.2 Réduire ses coûts d’infrastructure 53

Pourtant la virtualisation a vu le jour sur un Mainframe trente bonnes années avant

Le monde distribué d’ailleurs ne cesse de s’inspirer de ce modèle, de l’imiter, de le ré-

Reconnaissons aussi une spécificité peu attrayante du Mainframe : les licences et

Les participants actifs du Groupe de travail Mainframe

Les contributeurs au Groupe de Travail

Le Groupe de Travail Mainframe remercie

En termes de consommation moyenne calculée en MSU, la situation apparaît très nuan-

1.2 Position du z vis-à-vis des plates-formes distribuées

Cela n’étonnera personne : la part des applications strictement cantonnées à la plate-forme

MAINFRAME : Maîtrise des coûts en environnement Mainframe

1.3 Spécificités sectorielles du z :

Dans le domaine Banque-Finance-Assurance, la manipulation transactionnelle de grandes

MAINFRAME : Maîtrise des coûts en environnement Mainframe

IBM semble conscient que de nombreuses entreprises se trouvent confrontées à ce tour-

Techniquement, le Mainframe reste en avance en termes de virtualisation, de scalabilité et

La nouvelle machine zEnterprise a la capacité de faire cohabiter sur la même plate-forme

De façon concrète, l’utilisation du Mainframe comme plate-forme de consolidation globale

MAINFRAME : Maîtrise des coûts en environnement Mainframe

On notera que pour la technologie z196, cette prime au renouvellement technologique

L’adjonction de processeurs spécialisés permet, pour un investissement modique de

Une alternative à cette architecture est parfois observée : un site monoserveur et un

2.1.2 SAN & Réseau

MAINFRAME : Maîtrise des coûts en environnement Mainframe

Logiciels embarqués dans les baies de stockage

Mutualisation avec d’autres environnements

Evolution de la géométrie du stockage Mainframe

Aujourd’hui on peut dégager les quelques tendances suivantes :

Cas particulier de l’EAV (Extended Address Volume) :

MAINFRAME : Maîtrise des coûts en environnement Mainframe

• IBM reste globalement stable et conservateur (Virtualisation sur disque + bande ou

Ces systèmes restent compétitifs et même incontournables quand :

2.1.5 Architecture technique & Organisation

MAINFRAME : Maîtrise des coûts en environnement Mainframe

La bande passante n’étant plus désormais un goulot d’étranglement, cette tech-

Infogérance : En avoir ou pas

MAINFRAME : Maîtrise des coûts en environnement Mainframe

Disponibilité continue & Haute disponibilité

Néanmoins, ce problème de surcoût et de complexité lié à des architectures cluster

On peut faire néanmoins quelques remarques :

Ces facteurs, quoique généralement pris en considération, ne figurent qu’à l’arrière-

2.2 Analyse et positionnement des fournisseurs de logiciels

•L  e contexte technologique général : la montée en puissance de l’informatique distri-

MAINFRAME : Maîtrise des coûts en environnement Mainframe

2.2.1 Fournisseurs Principaux

Les trois incontournables

• BMC a surtout une assise solide dans le domaine de la supervision.

2.2.2 Fournisseurs Secondaires

Les spécialistes de taille importante

• Software AG : ce grand éditeur allemand pourtant bien implanté mondialement -

Les acteurs de niche

• Macro4 : a développé une concurrence à Compuware exclusivement dans le domaine

MAINFRAME : Maîtrise des coûts en environnement Mainframe

• Syncsort : acteur uniquement actif dans les domaines du tri et de la manipulation de

2.3 Résultats de l’enquête

> Pour les Systèmes d’exploitation

1. I BM omniprésent avec ses multiples générations de systèmes d’exploitation

> Pour les Moniteurs transactionnels

IBM avec par ordre de popularité CICS, Websphere et IMS

1. IBM avec DB2

1.2 Position du z vis-à-vis des plates-formes distribuées

1.3 Spécificités sectorielles du z :

• IBM reste globalement stable et conservateur (Virtualisation sur disque + bande ou

2.2 Analyse et positionnement des fournisseurs de logiciels

•L e contexte technologique général : la montée en puissance de l’informatique distri-

• BMC a surtout une assise solide dans le domaine de la supervision.

• Software AG : ce grand éditeur allemand pourtant bien implanté mondialement -

• Macro4 : a développé une concurrence à Compuware exclusivement dans le domaine

• Syncsort : acteur uniquement actif dans les domaines du tri et de la manipulation de

1. I BM omniprésent avec ses multiples générations de systèmes d’exploitation