Présentation événement dette technologique micropole
-
Upload
micropole-group -
Category
Documents
-
view
160 -
download
4
Transcript of Présentation événement dette technologique micropole
LA DETTE TECHNOLOGIQUE
26 JUIN 2015
POURQUOI ET COMMENT MAITRISER SA DETTE TECHNOLOGIQUE
Pourquoi ? 1
Comment ? 2
La belle histoire 3
Questions / Réponses 4
8:45 – 9:00
9:00 – 9:40
9:40 – 10:00
10:00 – 10:15
Pourquoi ? 1
Comment ? 2
La belle histoire 3
Questions / Réponses 4
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 x.x
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
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
Pourquoi ? 1
Comment ? 2
La belle histoire 3
Questions / Réponses 4
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 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é
COMMENT MESURER OBJECTIVEMENT ?
Zo
ne
d
e
To
lé
ra
nc
e
Infraction 0
De
tte
Te
ch
no
log
iqu
e
Plus l’application contient d’infractions, plus la dette
technologique va augmenter
Source: http://blog.castsoftware.com/
Global
Ax
e A
Ax
e B
Ax
e n
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
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
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 D
ocu
men
t A
xe d
e m
esu
re
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)
Cri
teri
a
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
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)
Intermediate
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
mechanismExist Not exist
Intermediate
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
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èse Ré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
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
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
Pourquoi ? 1
Comment ? 2
La belle histoire 3
Questions / Réponses 4
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
Wealth Management
Information System
Market 2 Market 4 Market 3 Market 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
AXES DE MESURE ENVISAGÉS
Page 20
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
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.
De
tte T
ech
no
.
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
Exploiter les résultats
PROCESSUS DE CALCUL DE LA MESURE
Page 22
Mesurer
Collecter 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
LES PREMIERS RESULTATS
Page 23
0
1
2
3Obsolescence
Standard
Redundancy
Interface
Code Quality
Arch.Principles
0
1
2
3Obsolescence
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
3Obsolescence
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…)
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
Pourquoi ? 1
Comment ? 2
La belle histoire 3
Questions / Réponses 4
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
Page 27
91-95 rue Carnot | 92300 Levallois-Perret - FR
Djamel SOUAMI
Directeur-Associé
Tél +33 (0) 670 484 124 [email protected]
91-95 rue Carnot | 92300 Levallois-Perret - FR
Philippe LEFORT
Senior Consultant
Tél +33 (0) 1 74 18 79 31 [email protected]
50, ave J.F. Kennedy | L – 2951 Luxembourg
Emmanuel PICHON
Head of Strategy & Architecture