LA DETTE TECHNOLOGIQUE
26 JUIN 2015
POURQUOI ET COMMENT MAITRISER SA DETTE TECHNOLOGIQUE
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
Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
Pourquoi maîtriser sa dette technologique
DETTE TECHNOLOGIQUE ? MOI ? … JAMAIS !
Page 4
LE PROCESSUS BUDGÉTAIRE INFORMATIQUE
Page 5
LE CYCLE DE VIE D’UNE APPLICATION
Page 6
Refonte
Etude – Projet
Evolution
importante
Evolution
mineure
?
Go Live
?
No Go
R...
LE CYCLE DE VIE DU PATRIMOINE
Page 7
Dé-commission
Projet
Evolution
importante
Evolution
mineure
?
Go Live
?
No Go
Version...
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
Main...
Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
Comment maîtriser sa dette technologique
QUOI MESURER ?
Page 10
« Business leaders demand that IT leader « do more with less » to free resources for innovation and...
COMMENT MESURER OBJECTIVEMENT ?
Zonede
Tolérance
Infraction
0DetteTechnologique
Plus l’application contient
d’infractions,...
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...
PÉRIMÈTRE ET CRITÈRE
Page 13
 Définir le périmètre
 Les périmètres applicatifs
• Type d’application: application front o...
MESURE
Page 14
 Collecter toutes les données nécessaires
 Pour chaque donnée, s’assurer de la complétude et la qualité
d...
Les pires et les meilleures
Par application
PREMIERS RÉSULTATS 1/2
Page 15
 Construire les premiers résultats
 Par appli...
PREMIERS RÉSULTATS 2/2
« Il est temps d’exposer sa dette technologique »
Exemple 1: liste de socle technique (usage intern...
PLAN D’ACTION
Page 17
 Améliorer les résultats
 Faire les arbitrages: dettes acceptées / dettes à réduire
• L’exhaustivi...
Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
Retour d’expérience BNPP WMIS
LE CONTEXTE
Page 19
UNE BANQUE PRIVÉE INTERNATIONALE INTÉGRÉE À
UN GROUPE BANCAIRE MONDIAL DE PREMIER PLAN
Des objectifs
W...
AXES DE MESURE ENVISAGÉS
Interface de données
• Agilité , Exploitation, et Normalisation,
• Evaluation des types de protoc...
LE PÉRIMÈTRE DU PATRIMOINE MESURÉ
Page 21
WMIS Software
Business package
Technical
Software
Infra.
Application
Server base...
Exploiter les résultats
PROCESSUS DE CALCUL DE LA MESURE
Page 22
MesurerCollecter la donnée
Chargement des données brutes
...
LES PREMIERS RESULTATS
Page 23
0
1
2
3
Obsolescence
Standard
Redundancy
Interface
Code Quality
Arch.
Principles
0
1
2
3
Ob...
Attentes
 Obtenir des indicateurs objectifs et communicables à notre métier
Périmètre
 Les facteurs sont parfois un comp...
Pourquoi ?1
Comment ?2
La belle histoire3
Questions / Réponses4
A RETENIR
Page 26
La Dette
Technologique
La mesurer permet …
Comment la mesurer
Les pré-requis:
- Des applications référen...
Page 27
91-95 rue Carnot | 92300 Levallois-Perret - FR
Djamel SOUAMI
Directeur-Associé
Tél +33 (0) 670 484 124
dsouami@mic...
Prochain SlideShare
Chargement dans…5
×

Présentation événement dette technologique micropole

742 vues

Publié le

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
742
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
26
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Présentation événement dette technologique micropole

  1. 1. LA DETTE TECHNOLOGIQUE 26 JUIN 2015 POURQUOI ET COMMENT MAITRISER SA DETTE TECHNOLOGIQUE
  2. 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. 3. Pourquoi ?1 Comment ?2 La belle histoire3 Questions / Réponses4 Pourquoi maîtriser sa dette technologique
  4. 4. DETTE TECHNOLOGIQUE ? MOI ? … JAMAIS ! Page 4
  5. 5. LE PROCESSUS BUDGÉTAIRE INFORMATIQUE Page 5
  6. 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. 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. 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. 9. Pourquoi ?1 Comment ?2 La belle histoire3 Questions / Réponses4 Comment maîtriser sa dette technologique
  10. 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. 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. 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. 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. 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. 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. 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. 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. 18. Pourquoi ?1 Comment ?2 La belle histoire3 Questions / Réponses4 Retour d’expérience BNPP WMIS
  19. 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. 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. 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. 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. 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. 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. 25. Pourquoi ?1 Comment ?2 La belle histoire3 Questions / Réponses4
  26. 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. 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

×