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 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