1. LA DETTE TECHNOLOGIQUE
26 JUIN 2015
POURQUOI ET COMMENT MAITRISER SA DETTE TECHNOLOGIQUE

2. Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
8:45 – 9:00
9:00 – 9:40
9:40 – 10:00
10:00 – 10:15

3. Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
Pourquoi maîtriser sa dette technologique

4. DETTE TECHNOLOGIQUE ? MOI ? … JAMAIS !
Page 4

5. LE PROCESSUS BUDGÉTAIRE INFORMATIQUE
Page 5

6. LE CYCLE DE VIE D’UNE APPLICATION
Page 6
Refonte
Etude – Projet
Evolution
importante
Evolution
mineure
?
Go Live
?
No Go
R x.x

7. LE CYCLE DE VIE DU PATRIMOINE
Page 7
Dé-commission
Projet
Evolution
importante
Evolution
mineure
?
Go Live
?
No Go
Version
N
Dé-commission
Projet
Evolution
importante
Evolution
mineure
?
Go Live
?
No Go
Version
N
Dé-commission
Projet
Evolution
importante
Evolution
mineure
?
Go Live
?
No Go
Version
N
Stratégie Business
Stratégie IT
Contraintes budgétaires
Eléments de contexte
Engagements
et arbitrages
Dé-commission
Projet
Evolution
importante
Evolution
mineure
?
Go Live
?
No Go
Version
N
Réglementation

8. Cas 1: Sans maitrise de la dette Cas 2: Avec gestion de la dette
LA DETTE TECHNOLOGIQUE ?
t t+1 t+2 t+3 t t+1 t+2 t+3
Maintenance
Projets
Dette technologique
 Dette « Ce que l’on doit à quelqu’un » (Centre National De Ressources Textuelles et Lexicales)
 Si la dette n’est pas maitrisée, les intérêts grossissent, rendant de plus en plus difficile tout nouvel investissement, rendant votre
système de plus en plus entropique.
 Technologie « Ensemble cohérent de savoirs et de pratiques dans un certain domaine technique, fondé sur des principes scientifiques »
(Larousse)
Définition
Page 8
 La dette technologique est constituée par une succession de décisions
managériales et de choix technologiques sur l’ensemble du patrimoine applicatif
Impacts sur les budgets et le ratio Projet/Maintenance

9. Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
Comment maîtriser sa dette technologique

10. QUOI MESURER ?
Page 10
« Business leaders demand that IT leader « do more with less » to free resources for innovation and growth »
Source Forester
« Time to market »
trop long
Stratégie métier supportée de façon
non optimale
Risques accrus de rupture de l’activité
Coûts trop élevés
Contexte de réduction du
budget de maintenance IT
Technologies
vieillissantes des
applications
Portefeuille applicatif trop
grand/imbriqué et complexe
à gérer
Manque d’agilité des
applications
Redondance applicative
résultant des différentes
fusions/acquisitions
Incapacité à gérer et
partager des informations
métiers
Dépendance vis-à-vis des
compétences critiques
Performance aléatoire
Besoin d’exploiter les
nouvelles technologies
avec agilité

11. COMMENT MESURER OBJECTIVEMENT ?
Zonede
Tolérance
Infraction
0DetteTechnologique
Plus l’application contient
d’infractions, plus la dette
technologique va
augmenter
Source: http://blog.castsoftware.com/
Global
AxeA
AxeB
Axen
Appli. 1
Appli. 2
Appli. n
 L’obsolescence
 L’agilité
 La redondance
 La qualité des interfaces
 Le respects des principes et normes
 Les compétences
 La qualité du code
 …
Des axes de mesures
 Le portfolio des applications et des
projets
 Les principes d’architecture
 Les normes et standards
 L’état de l’art du marché
 …
Des référentiels
 = Application
L’application est l’unité de mesure la
plus appropriée. C’est le point de
rencontre entre l’IT et le métier.
Une maille

12. NOTRE DÉMARCHE
Page 12
Patrimoine
IT
Plan Do
Act Check
Eviter la régression
Périmètre
et Critères
Mesure
Plan d’action
• Réduire la dette
• Pérenniser la mesure
Premier résultats
Roue de Deming (PDCA)
Patrimoine
IT

13. PÉRIMÈTRE ET CRITÈRE
Page 13
 Définir le périmètre
 Les périmètres applicatifs
• Type d’application: application front office, application technique,
Matériel, …
• Géographie/Organisation: Pour quelle population d’utilisateurs
finaux
• Responsabilité: Dans certains cas (mode SAS, externalisation de l’IT,
ou contrat inter-entité, …), la responsabilité de l’IT doit être
identifiée afin d’en définir son contour
 Les acteurs à solliciter
 La gouvernance de la dette technologique
 Définir Les critères de mesure
 Regroupement des critères par famille = axe de mesure
• Décrire par axe de mesure, les critères envisagés.
 Bien identifier les données nécessaires
• Données brutes = données qui feront l’objet de la mesure et sans
lesquelles la mesure ne peut avoir lieu
• Référentiel = les données à challenger, la cible à atteindre et que
l’on va mesurer
• En cas de discussion, n’hésiter par à pondérer les critères les uns par
rapport aux autres,
Objectifs
DocumentAxedemesure
Obsolescence technique
Une application est considérée Obsolète lorsque la
couverture de son support contractuel (par défaut
5 ans après sa date de commercialisation) ne
dépasse pas 3 ans (par rapport à la date de la
mesure)
Criteria
Date de fin de support (DFS) vs date de la mesure
(DM)
Par convention; les extensions de support contractualisées ne seront
pas prises en compte.
Date de la mesure
Fin de support
1
0 y.+1 y.+3 years
0 2 3
Evaluation de l’Obsolescence
Delta = DFS – DM
Carte d’un axe de mesure: Obsolescence
Anticiper la conduite du changement = Construire un cadre et des
critères partagés par tous les acteurs impliqués

14. MESURE
Page 14
 Collecter toutes les données nécessaires
 Pour chaque donnée, s’assurer de la complétude et la qualité
de l’information
• La qualité de la donnée peut être challengée par une mesure sur un
périmètre restreint
Cette étape est essentielle pour la légitimité du résultat final
 Définir le mode opératoire de la mesure
 Mesure objective et calculée
• Exemple: Obsolescence par un delta entre 2 dates
 Exploitation de mesures existantes
• Lorsqu’elle existe, il est toujours intéressant de réutiliser une
mesure déjà existante. Il suffit juste d’adapter le résultat sur un
barème commun.
 Mesure par évaluation partagée
• A défaut de donnée suffisante, l’échange et la validation collégiale
de l’attribution d’une note peut être mise en place. Les acteurs à
impliquer doivent être reconnus de tous
Objectifs
Name % ID % Criteria description 0 1 2 3
C0 100% SOFT components alignement All are align > 2/3 > 1/3 < 1/3n/a
Category Criteria
60%General
Grade meaning
Efficient Not efficient
Quality Code (Cross-approved assessment)
Interm
ediate
Evaluation
C1.1 25% Documentation
C1.2 25% Comments
C1.3 25% Naming convention
C1.4 25% Code modularity
C2.1 25% Monitoring code
C2.2 25% Audit track
C2.3 25% Integration mode
C2.4 25% Release management
Free 100% C3 100% Impress assessment Good impress Bad Impress
60%General Efficient Not efficient
Transverse
mechanism
Exist Not exist
Interm
ediate
Evaluation
OR
40%
Exemple de Mesure par évaluation partagée: la qualité du code
 Monter un atelier de travail dédié à ce
sujet
 Conseil: après chaque atelier, projeter
les résultats sur l’ensemble des
applications, afin de conforter ou non, le
niveau des exigences mais aussi le
ressenti globale

15. Les pires et les meilleures
Par application
PREMIERS RÉSULTATS 1/2
Page 15
 Construire les premiers résultats
 Par application, en résultats bruts
 En regroupant les résultats sur la/les dimensions métiers
• Bon moyen d’illustrer et de communiquer sur la stratégie IT
Objectifs
Vision par synthèseRésultats bruts
Asset Rating Grading Factor 1 Factor 2 Factor 3 Factor 4 Factor 5 Factor 6
Asset 1 2,68 /3 3,00 /3 1,00 /3 3,00 /3 3,00 /3 2,10 /3
Asset 2 2,64 /3 3,00 /3 1,50 /3 3,00 /3 2,50 /3 2,42 /3
Asset 3 2,56 /3 3,00 /3 1,00 /3 3,00 /3 2,50 /3 2,10 /3
Asset 4 2,51 /3 3,00 /3 0,30 /3 1,20 /3 2,88 /3 1,29 /3 2,40 /3
Asset 5 2,47 /3 3,00 /3 1,31 /3 1,88 /3 2,38 /3 2,52 /3
Asset 6 2,41 /3 3,00 /3 0,75 /3 1,50 /3 3,00 /3 0,37 /3 0,00 /3
Asset 7 2,35 /3 3,00 /3 0,60 /3 1,65 /3 2,38 /3 0,66 /3 2,20 /3
Asset 8 2,34 /3 3,00 /3 0,60 /3 1,80 /3 2,80 /3 1,29 /3 0,00 /3
Asset 9 2,32 /3 3,00 /3 1,00 /3 3,00 /3 2,25 /3 1,01 /3 0,62 /3
Asset 10 2,30 /3 3,00 /3 0,97 /3 1,01 /3 3,00 /3 0,62 /3
TOTAL Rating per Factor
Asset 160 1,34 /3 1,00 /3 0,00 /3 1,50 /3 2,00 /3 1,56 /3 0,64 /3
Asset 161 1,23 /3 1,00 /3 0,00 /3 1,50 /3 2,00 /3 1,28 /3
Asset 162 1,20 /3 3,00 /3 1,00 /3 1,50 /3 0,00 /3 0,31 /3 0,00 /3
Asset 163 1,00 /3 1,00 /3 0,00 /3 1,50 /3 1,33 /3 1,31 /3 0,00 /3
Asset 164 0,88 /3 1,00 /3 0,00 /3 3,00 /3 1,17 /3 1,28 /3
Asset 165 0,79 /3 1,00 /3 0,00 /3 1,12 /3 0,88 /3 0,59 /3 0,00 /3
Asset 166 0,74 /3 1,00 /3 0,00 /3 3,00 /3 0,00 /3 0,00 /3
Asset 167 0,70 /3 1,00 /3 0,00 /3 2,62 /3 0,00 /3 0,00 /3
Asset 168 0,53 /3 1,00 /3 0,00 /3 1,12 /3 0,00 /3 0,69 /3 1,28 /3
Asset 169 0,53 /3 1,00 /3 0,00 /3 1,12 /3 0,00 /3 0,59 /3 1,28 /3
Asset 170 0,42 /3 1,00 /3 0,00 /3 1,18 /3 0,00 /3 0,87 /3 0,00 /3
Couverture de la dette technologique
du patrimoine applicatif
0 0,2 0,4 0,6 0,8 1 1,2 1,4 1,6 1,8 2 2,2 2,4 2,6 2,8 3
Forte Dette
identifiée= = = = = = = = = = = = = >
Pas de dette
identifiée
14% 46% 34% 6%
Classer les résultats par ordre, en vue de permettre des comparaisons
Définir les priorités d’axe de mesure en les pondérant selon la
stratégie IT voulue

16. PREMIERS RÉSULTATS 2/2
« Il est temps d’exposer sa dette technologique »
Exemple 1: liste de socle technique (usage interne IT)
Socle technique Editeur Type
Nb
appli
Moy.
Appli
Val. =
Note*Nb
Windows 2012 Microsoft Système 45 3,00 /3 135,0
Oracle 11 Oracle Base de donnée 27 3,00 /3 81,0
AIX 6.x IBM Système 54 1,33 /3 71,8
AIX 7.x IBM Système 26 1,73 /3 45,0
Windows 2008 Microsoft Système 12 3,00 /3 36,0
Oracle 12 Oracle Base de donnée 12 2,33 /3 28,0
DB2 for z/OS 11 IBM Base de donnée 20 1,33 /3 26,6
Linux 6.x RedHat Ent. Système 26 1,00 /3 26,0
WAS 8.x IBM Serveur d'application 11 1,67 /3 18,4
WAS 7.x IBM Serveur d'application 7 2,61 /3 18,3
DB2 for z/OS 10 IBM Base de donnée 8 1,33 /3 10,6
SQL Server 2008 Microsoft Base de donnée 3 2,00 /3 6,0
SQL Server 2012 Microsoft Base de donnée 2 2,33 /3 4,7
Communication avec
les fournisseurs
Exemple 2: Valorisation d’un Domaine métier par la dette technologique de
ses applications (usage externe)
Hiérarchie de la dette
pour un domaine
Page 16
Communication
avec les métiers

17. PLAN D’ACTION
Page 17
 Améliorer les résultats
 Faire les arbitrages: dettes acceptées / dettes à réduire
• L’exhaustivité non obligatoire / crête des résultats à prioriser
 Rechercher les quick-wins
• L’utilisation des résultats peut faire émerger des actions à effet
démultiplié (Réduction de la dette sur un composant technique qui
impact la dette de plusieurs applications)
 Préparer la prochaine mesure
 Challenger les axes de mesure
• Nouvel axe à prendre en compte
• Identification d’axes à surveiller pour la prochaine mesure (en vue
de voir l’efficacité d’un plan d’action, par ex.)
• Pertinence des axes de mesures et critères associés
• Gérer l’historique
 Intégrer la mesure de la dette en continu
 Ajouter la mesure dans le cycle de vie de l’application et plus
largement dans le processus de gestion du patrimoine applicatif
Objectifs
Leviers sur les plans d’actions
Optimisation du plan
d’action des migration
des bases de données
Tendre vers une mesure de la dette calculable à la demande
Dé-commission
Projet
Evolution importante Evolution mineure
?
Go Live
?
No Go
Version N
La dette comme facteur de décision
de la vie de l’application
Input du
Go / No Go
Input de
la revue

18. Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
Retour d’expérience BNPP WMIS

19. LE CONTEXTE
Page 19
UNE BANQUE PRIVÉE INTERNATIONALE INTÉGRÉE À
UN GROUPE BANCAIRE MONDIAL DE PREMIER PLAN
Des objectifs
Wealth Management
Information System
Market 2 Market 4Market 3Market 1
Un patrimoine applicatif distribués
sur plusieurs sites
1 entité IT
o Identifier et communiquer son
statut technologique,
o En améliorer la gestion par
une meilleure anticipation et
des actions plus structurées
o Réduire les coûts (support
et projet)
o Anticiper les évolutions
o Mieux prioriser les
investissements métiers

20. AXES DE MESURE ENVISAGÉS
Interface de données
• Agilité , Exploitation, et Normalisation,
• Evaluation des types de protocoles utilisés et
ventilation sur les applications
Principes d’Architecture
• Exploitation des réserves Major/Medium/Minor,
identifiées lors des revues de projets
Alignement sur les standards
• Appartenance ou non aux catalogues des standards
Redondance
• 2 axes : Fonctionnel et Technique
• Par regroupement sur classification standard groupe
(Eagle et GTRM)
Evolutivité
Qualité du Code
• Réutilisation d’une évaluation existante (SonarQube)
quand c’est possible
Ratio CTB/RTB
• CTB = Change The Bank
• RTB = Run The Bank
Obsolescence
• En lien avec la date de fin du support
Axes de mesure retenus Non retenus
• Ratio CTB/RTB non retenu. Impactés par d’autres
facteurs (périmètre d’utilisation, périmètre fonctionnel…)
• Evolutivité difficile à mesurer et potentiellement redondant
avec d’autre axe
• Compétences non traitées
 La Dette Technologique est envisagée en fonction des
enjeux technologiques de WMIS
Compétences
• 2 axes: Fonctionnel + Technique
• Evaluation des managers sur base d’une grille
de compétence prédéfinie

21. LE PÉRIMÈTRE DU PATRIMOINE MESURÉ
Page 21
WMIS Software
Business package
Technical
Software
Infra.
Application
Server base (Web server, RDBMS, OS)
Technical Software Non Infra.
Middleware
Hardware
 Hors périmètre
o Application: les spécifités locales sont marginales, de plus elles sont difficiles à collecter avec un volume important
o Technical Software Infra: concernent tous les outils techniques nécessaires à la gestion de l’infrastructure. Cette
couche est gérée par nos partenaires, leurs impacts ont été jugés faibles
o Hardware: gérés par nos partenaires. Considérés comme dépendants du triptyque OS, DB, et Serveur d’application.
DetteTechno.
Géré par partenaire infra
Géré par WMIS
Donnée prise en compte pour la mesure
Note de la mesure au niveau WMIS Software
 Les dépendances entre ces différentes
couches sont très structurantes pour la mesure
ITAM
(IT Asset Mgt)
La dette technologique WMIS
= vision « Editeur » et non « Intégrateur »
Hors périmètre

22. Exploiter les résultats
PROCESSUS DE CALCUL DE LA MESURE
Page 22
MesurerCollecter la donnée
Chargement des données brutes
- Sur les différentes couches applicatifs
Vérification et Complément
- Les données d’ITAM, ont toutes été vérifiés et complétés le
cas échéant
Paramétrage des mesures
- Saisie des % de pondération
Lancer les calculs
Export des résultats
Saisie des évaluations ad hoc
- Les évaluations sont stockées dans l’outil





Outil de mesure de la dette
technologique
Analyser les résultats et définir
les plans d’actions
ITAM
(IT Asset Mgt)
Mise en forme des résultats




23. LES PREMIERS RESULTATS
Page 23
0
1
2
3
Obsolescence
Standard
Redundancy
Interface
Code Quality
Arch.
Principles
0
1
2
3
Obsolescence
Standard
Redundancy
Interface
Code Quality
Arch.
Principles
Obsolescence
 XMS CH = Obsolescence de plateforme
 PMS = Faux positif => donnée incorrect
 Obsolescence d’un OS mobile  Stratégie interne à définir ?
Redondance
 PMS  Décommissionnement à envisager
Principes d’architecture
 XMS CH & PMS  Urbanisation à revoir
Interface d’échange
 Valorisation du besoin d’un bus échange.
Etude à lancer
…
0
1
2
3
Obsolescence
Standard
Redundancy
Interface
Code Quality
Arch.
Principles
XMS CH
PMS
SPS
Exemple de décision immédiate sur les
applications à dette forte
D’autres reporting ont été définis (vision technologique, vision métier…)

24. Attentes
 Obtenir des indicateurs objectifs et communicables à notre métier
Périmètre
 Les facteurs sont parfois un compromis entre précision et
disponibilité des données
 Dans un premier temps, ¼ des applis ont été couvertes
Les premiers résultats
 Globalement, les premiers résultats étaient attendus et conformes
à la réalité mais ont pu être objectivés
 Pour certains assets, des problèmes de qualité de données
donnent des résultats erronés  challenge la qualité des
référentiels
La démarche
 Implication des différentes équipes (infrastructure, MOE et MOA)
 Implication du management de WMIS via un comité de pilotage
Conclusions
 La qualité des données sources est clé !
 La dette technique permet de valoriser des référentiels de
patrimoine
Prochaines étapes
 Intégration systématique dans notre gouvernance projet
Charges
 Charge Micropole = 4 mois
 Charge Strategy & Architecture = 50 jh
Sollicitation des équipes internes
 Domain Head  8 réunions d’1h30
 Partenaire Infra.  3 réunions
 Asset Expert  15 entretiens réalisés
 5 comités de pilotage
 1 réunion de restitution
Délivrables
 1 document de référence définissant la dette
technique
 2 bases Access
 1 dizaines de feuille Excel (input, reporting..,)
BILAN DE LA MISSION
Page 24
Attentes, exécution et résultats
En chiffres

25. Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4

26. A RETENIR
Page 26
La Dette
Technologique
La mesurer permet …
Comment la mesurer
Les pré-requis:
- Des applications référencées
- Inscrire la mesure dans un processus continu
- Un outillage simple et efficace
Construction de la V1: 3 à 4 mois

27. Page 27
91-95 rue Carnot | 92300 Levallois-Perret - FR
Djamel SOUAMI
Directeur-Associé
Tél +33 (0) 670 484 124
dsouami@micropole.com
91-95 rue Carnot | 92300 Levallois-Perret - FR
Philippe LEFORT
Senior Consultant
Tél +33 (0) 1 74 18 79 31
plefort@micropole.com
50, ave J.F. Kennedy | L – 2951 Luxembourg
Emmanuel PICHON
Head of Strategy & Architecture