Livre blanc : réduire la dette IT simplement et massivement pour migrer un SI !
Introduction
Les grandes entreprises empilent les technologies depuis que l’informatique existe – Et elles continueront à le faire. La « bassine » se remplie de technologies, mais aussi de données ! Et cette bassine ne se vide que trop peu. Les conséquences sont délétères : les coûts explosent, et les impacts écologiques vont croissants.
En 2018, 78% des budgets informatiques ont été dépensés uniquement pour maintenir les systèmes vs les investissements dans l'innovation ? (Cisco, IT Operations Readiness Index, 2018)
A l’heure actuelle, la majorité des CIO (59%) trouve difficile d’intégrer de nouvelles applications ou technologies et de faire évoluer les applications existantes (65%) en raison de la dette technique IT (MuleSoft 2019 Benchmark Report). La dette technique IT, c’est en moyenne 50% du contenu des SI. Donc la réduction de la dette technique, c’est un besoin impérieux pour les équipes IT d’amélioration de la gouvernance de la donnée. Ce devrait être une nécessité avant migration.
La volumétrie
Pour ne parler que de stockage, le Cabinet IDC nous indique que la volume de données dans le monde pourrait atteindre plus de 27 000 Zo en 2035. Mais toutes ces données échangées et stockées seront-elles exploitées, exploitables, sécurisées ?
Ce qui est certains, c’est
que quand il s’agit de migrer les systèmes qui les contiennent, ou tout
simplement de les administrer, les équipes IT sont souvent perplexes quant à la
conduite à tenir….
L’hétérogénéité/La complexité
____________
On peut associer la vision des systèmes à un « plat de
lasagne » superposant les couches techniques et applicatives au fil du
temps.
Il serait encore plus pertinent de pousser la métaphore jusqu’au
« plat de spaghetti », car les couches ne se superposent pas, mais
s’entrecroisent dans une harmonie toute relative. Aussi, ces systèmes
deviennent impossibles à subdiviser : des liens inextricables régissent
les relations entre les sous-ensembles : domaines métier, applications,
processus, infra. Les couplages se matérialisent par des bases de données
partagées, des moyens infra mutualisés, et autres. Les effets combinatoires produisent une infinité
d’interractions difficilement descriptibles. On voit ainsi souvent des
schémas d’architectures techniques / fonctionnelles placardés sur les murs des
services informatiques des entreprises avec des flèches partant dans tous les
sens. Leurs dénominateurs communs, c’est d’être parfaitement incomplets tant
les interractions sont nombreuses, et d’avoir une obsolescence quasi immédiate
tant les systèmes sont mouvants !
Par ailleurs, les chaines d’alimentation sont souvent impossibles à
déconstruire et à expliciter. D’innombrables ruptures empêchent les « data
engineers » de comprendre comment la donnée se construit et circule à
l’intérieur des systèmes. L’opacité
est telle qu’elle en devient insoluble. On finit souvent par l’accepter et par vivre
avec.
L’uniformisation, une cible inatteignable ?
____________
Il existe souvent un
désir d’uniformisation qu’aucune volonté humaine ou technique ne peut permettre
de faire émerger spontanément : le poids des « legacy systems
», la volonté du métier d’aller vite vers les nouvelles technologies pour
gagner en souplesse et en efficacité, font de ces systèmes uniformes ciblés un
fantasme. Les
systèmes sont en mouvement, en transformation perpétuelle. Le rajout
d’une technologie n’implique que très rarement le retrait d’une autre. A cela
s’ajoute que les fusions, acquisitions, cessions sont légion dans notre monde
économique intégré, et elles apportent mécaniquement leur lot de complexité
additionnelle. Un SI
simple et efficace comme au premier jour, restera un horizon inatteignable.
Le big bang, un big plouf ?
____________
Les big bangs qui visent à révolutionner les SI en y mettant des moyens colossaux, essentiellement humains, sont à notre connaissance systématiquement des échecs. Il est en effet impossible de faire de l’analyse d’impact exhaustif de changements de cet ordre. Les tiers qui agissent sur ce type de projets sont en but à toutes avec les myriades de facteurs de complexité qui n’avaient pas été envisagés. C’est le mythe de Sisyphe remit au goût du jour !
Il apparait à l’usage que les solutions qui semblent fonctionner
pour faire évoluer un système sont d’avantages des solutions techniques, itératives,
automatisées, partagées au plus grand nombre, au plus proche du terrain.
Elles permettent d’ajuster la cible aux obstacles qui se présentent continuellement, en donnant les moyens à l’ensemble des équipes de travailler dans un processus de changement continu, d’évolution résolue, plutôt que de révolution avortée.
Comment ?
6 étapes
Les applications métiers diverses, bien que souvent surnuméraires ne
sont pas réellement à l’origine de la complexité. La complexité va se
retrouver davantage dans ce qui constitue la mémoire et l’intelligence de
l’entreprise : le stockage, le processing, et l’exposition de la donnée.
En sommes, dans la composante « analytics » des systèmes
d’information.
Aujourd’hui,
La baisse des coûts du stockage, la naissance des architectures big data, de
l’IoT, l’avènement du Cloud …ont créé des opportunités fortes de collecte
infinie et décentralisée de données de tous types, permettant d’envisager un
modèle d’entreprise « data driven ».
Mais le
corolaire de tout ça, c’est aussi une hyper complexité délétère, d’autant que ces systèmes génèrent presque mécaniquement de
l’opacité via des biais techniques qui empêchent une lecture transversale et
exhaustive.
Comme nous
l’avons dit, la complexité résiste à toute approche centralisée qui viserait à
reprendre un contrôle rapide et exhaustif d’un SI.
On ne peut
pas imaginer que l’effacement de la dette technique, ou qu’une bascule vers le
Cloud puissent être opérés d’un coup de baguette magique.
Les
interractions techniques, les effets combinatoires de ces interractions rendent
les Big Bang largement voués à l’échec. Nous pensons qu’il faut donner indifféremment à
toutes les équipes, et en particulier aux équipes de data engineers les moyens
de comprendre et d’agir de façon itérative, souple, adaptative. Le changement
doit se faire en continue, en automatisant au maximum les processus
Les données qui servent réellement ont une empreinte dans les bases
d’audit. En parcourant parallèlement tous les flux permettant de produire ces
données utilisées par les métiers, on opère mécaniquement
une discrimination entre les composants des systèmes qui sont utiles de ceux
qui ne le sont pas.
Nous identifions continuellement
ce potentiel de simplification, que ce soit des tables répliquées, obsolètes,
des procédures ou jobs ETL inutiles, ou encore des dashboards oubliés dans un
coin, répliqués, abimés, ou présentant des données corrompues.
Les équipes techniques auront à loisir de
supprimer ou d’archiver la « matière morte » en temps continu. On
pourra ainsi amener le système à sa juste mesure dans un temps raisonnable,
sans opérer de révolution.
Par ailleurs, les traitements « utiles » sont intriqués dans
la cinématique d’ensemble. Nous proposons d’opérer une réduction massive du
nombre de traitements en générant
automatiquement du code
« ensembliste » qui va factoriser tout ce qui peut l’être (surtout les curseurs dans le code
procédural). On amènera ainsi le système à son optimum, avec en plus une
compréhension facilitée du processing de la donnée.
Nous proposons avant tout de donner de la clarté dans les systèmes, de
les rendre intelligibles aux équipes de data engineers qui s’y frottent
quotidiennement. Il ne s’agira en aucune
sorte d’une RAZ, mais d’une optimisation du patrimoine, et de la compréhension
qui peut en être faite.
Nous proposons une solution donnant la
possibilité de « traduire » des flux.
A l’issue du « parsing » du code
procédural ou du langage objet analysé, nous produisons un « arbre
syntaxique ». Il s’agira typiquement d’analyser des langages très présents
dans les legacy systems et dont la prégnance rend les évolutions difficiles :
Perl, Cobol, PL/SQL…etc.
openAudit® détectera l'endroit où la donnée est
stockée, et là où elle est traitée, quelle que soit la technologie de
processing (procédural / objet).
openAudit® génèrera
ensuite dynamiquement un "arbre algorithmique" agnostique,
standardisé, simple de compréhension pour tous.
L’arbre sera stocké dans une base de données
avec une arborescence qui permettra par ailleurs de faire des comparaisons et
du "diff" - nous produisons pour cela du "Yaml" (fichiers
intuitifs, descriptifs et concis).
L’ensemble de la
communauté IT d’une entreprise sera à même de comprendre le sens de cet arbre
algorithmique très simple, et très factuel.
Cet arbre algorithmique
permettra typiquement de construire à la volée du NodeJS, du Python, du Java… etc.
Ces langages objets sont très présents dans le Cloud, ce qui peut présenter un
intérêt certain si l’ambition est de migrer vers le Cloud.
Certaines solutions de dataviz existent depuis 30 ans, et sont toujours
présentes et hyper utilisées dans d’immenses groupes internationaux.
Sauf que les besoins métier évoluent sans cesse, le désir d’autonomie,
de data en « self-service » ont continuellement imposé de nouvelles
solutions, toujours plus « expériencielles », toujours plus
puissantes, toujours plus simples, maintenant largement hébergées dans le Cloud
(PowerBI, Tableau, Looker…).
Les solutions initiales
ne sont pour autant jamais décommissionnées, elles conservent une forte
communauté d’utilisateurs, des caractéristiques de robustesse, et une
maintenabilité éprouvée. L’idée sera plutôt d’en
réduire l’emprunte se façon progressive, jusqu’à un décommissionnement
envisageable à long terme.
Nous proposons de
construire un « méta modèle », c'est à dire un jeu de données unique
pour l'ensemble des technologies de reporting que l’entreprise utilise, une
espèce de "super couche sémantique".
Les basculement
inter-technologique pourront se faire en temps continu, progressivement, avec
en plus une réelle possibilité de faire des « roll back ».
L’intérêt sera aussi de donner un accès au métier à toute la donnée décisionnelle constituée.
Pour les équipes IT,
ce sera la possibilité de superviser efficacement tous les usages de
l'information.
Pour le contrôle de
gestion, ce sera la promesse à terme de rationaliser les systèmes
d'information, pour baisser les coûts.
L’évolution des systèmes d’information, et plus encore la partie analytics
de ces systèmes n’est pas une option, mais une obligation : la compétition
internationale impose aux entreprises une lecture toujours plus fine de leur
business, et les oriente vers des stratégies « data driven ». Le
corolaire, c’est la massification de la collecte des données, et une
hétérogénéité des composants des systèmes qui va croissante avec l’explosion du
Cloud, des architectures big data.
Comment dans ces conditions les faire évoluer au rythme attendu ?
Nous pensons que cela passera dans un premier temps par une
compréhension fine et partagée des systèmes (cartographie), et tout à la fois
des armes pour les simplifier en continu.
Dans un second temps, il s’agira à l’aide d’outils d’opérer une bascule
progressive vers les architectures techniques et fonctionnelles ciblées, sans
heurts, ni fracas, mais avec la précision que permettent des outils
d’interopérabilité technique tels que ceux que nous avons développés. Ainsi,
petit à petit, sereinement, le passé peut s’éloigner, et le futur se faire
jour.
Commentaires
Enregistrer un commentaire