Un peu d'histoire récente
La déferlante BIG-DATA soulève la question de l’usage des
technologies (déjà) plus anciennes, et notamment celle du Master Data Management (MDM).
La vocation initiale d’un MDM est d’établir un « point
de vérité » sur périmètre restreint dit « de la donnée de référence» (1) ,
avec une plus value qualitative de premier ordre, car souvent associée à des
outils de Data Quality Management (DQM) : validation d’une adresse,
dédoublonnage etc …
La mise en œuvre des projets MDM est/à été très variable
d’une entreprise à l’autre : projet de consolidation des informations client
pour la Business Intelligence (B.I) et injection dans les bases Marketing, projets
règlementaires, vision 360 avec ou sans ouverture (directe) de consultation
temps réel vers des outils de gestion de la relation client (CRM), utilisation
radicale comme d’un « fichier client » au coeur du S.I etc …
Les outils MDM et « leurs
ancêtres » ont très rapidement été complétés par une ouverture temps réel
de leur solution, avec les frameworks associés (mise à jour temps réel, lecture, création et exposition
de services, intégration aux outils tiers CRM, partenariats divers des éditeurs),
plaçant ainsi parfois la solution au cœur des systèmes opérationnels (et
quelque part la rendant incontournable à grand frais de licences et de support).
Un glissement des offres MDM vers un périmètre plus large
que les seules « données de références » s’est également opéré au fil
des années, incluant des données de type « transactionnelles »
(équipements client, interactions …), avec plus ou moins de bonheur dans le
rapport coût/gains et réactivité des équipes au regard d’architectures
plus conventionnelles.
Au passage, le grand retour de la vision 360°, vieux truc
des années 90 (« portrait client » etc…), en dit long pour « vendre »
aussi des projets BIG-DATA qui vont pourtant bien au-delà des données patrimoniales de l’entreprise:
toutes les entreprises n’ont pas à ce jour une vue 360 satisfaisante sur leurs
propres données patrimoniales (attention
toutefois aux projets qui ne se limiteraient qu’à ça sans vision stratégique
sur le reste des informations non patrimoniales, on est plus dans les années 90 !)
Au même titre que les inerties diverses, les instabilités et
les jeux des reventes, fusion, acquisition de sociétés ne sont pas étrangers aux difficulté de construction d'une vision 360°…
les S.I apparaissent et disparaissent parfois très vite dans la vie d’un grand
groupe.
Là ou le BIG-DATA fait de l’ingestion de masse de données en
tous genres, le MDM, plus réduit en périmètre d’information, par ses fréquents mécanismes
de mise en qualité préalable, nécessite une réflexion plus approfondie, et plus
longue, à mener dans les projets.
La qualité n’est pas gratuite, et les reprises de
« stock » de données et arbitrages entre 2 informations
contradictoires pénalisent souvent les délais de mise en œuvre (ne pas faire cette
reprise de stock réduirait les chances de plus-value et la
finalité recherchée sur le moyen terme).
La consolidation fait en effet souvent émerger des
évènements déclencheurs de processus ou précedures opérationnelles liés au métier que les automatismes ne peuvent pas
forcément/facilement résoudre à postériori, car trop dépendants de règles
métiers différentes : un groupe banque-assurance qui rapprocherait ses données
et détecterait une adresse différente pour un même client, à la fois client bancarisé
et client de l’assurance, devrait gérer des procédures différentes de changement
d’adresse entre le métier de banquier et le métier d’assureur (…), et sur des dizaine
ou centaines de milliers de cas parfois, même si le pourcentage peut-être
faible au final sur tout un portefeuille.
Ces travaux peuvent aussi révéler quelques fraudes latentes.
Ils apportent quoiqu’il en soit une plus-value sur une
meilleure connaissance de ses propres données et sur ses clients.
Le NOSQL à la conquête de fonctions qualité de premier niveau
L’offre Nosql du marché « commence » à englober
des fonctionnalités de « premier niveau » comparables aux outils DQM,
tel que le dédoublonnage (pour ne citer que celle là), fonction clef d’une
centralisation qualitative de l’information.
Tout cela reste à ce jour embryonnaire et sans comparaison face aux puissants algorithmes des solutions MDM, mais bien réel.
Les premières bases NoSql ACID ont également fait leur
apparition.
Des outils d’administration des données, plus fonctionnels,
directement liés à l’aspect « métier » de l’information traitée, sont
en outre également en voie d’enrichissement dans ces solutions émergeantes, tout
en restant très concurrentielles au niveau de leurs tarifs.
Une réflexion digne d’un « Pivot en lean-startup » est elle à faire au niveau des
stratégies I.T et de l’outillage, compte tenu de ces évolutions récentes ?
Tout est, bien évidemment, dans les enjeux et la finalité
que l’on souhaite atteindre. Mener de nos jours des projets de plusieurs années
avant de livrer un résultat tangible pour l’entreprise semble hasardeux compte tenu
des niveaux de rupture constatés sur les marchés .
Se ré-interroger sur ses stratégies IT en permanence est devenu
incontournable :
- Aller vite et faire « moyen » au lieu de faire « mieux » mais dans longtemps ?
- Réduire ou pas la voilure au niveau de la qualité des données, aller à l’essentiel ?
- Livrer un résultat par des itérations successives dont les plus importantes ne dépasseraient pas 2 mois montre en main ?
- Envisager un scénario de rupture pour basculer ses données d’un outil MDM vers un outil Nosql ( les bases Nosql sont beaucoup plus larges et universelles dans le spectre fonctionnel des données utilisées, c'est-à-dire bien au-delà du carcan des données dites « de référence» ) ?
- Faire porter à des architectures Nosql la « haute disponibilité » en lieu et place des progiciels éditeurs plus classiques (souvent plus coûteux) ?
- Faire cohabiter MDM et Nosql (c’est d’ailleurs fort compatible) ? En permanence ? Ou seulement pour une phase de transition vers Nosql ? Ou simplement « en attendant les prochaines évolutions » ?
- Se projeter aussi en fonction des évolutions réglementaires et des fonctionnalités requises (chiffrement, habilitations …)
- (…)
Se ré-interroger aussi sur ses projets passés et sa capacité
à les mener à bien :
- Ou a-ton perdu du temps ? Ou en a-t-on gagné ? Pourquoi ?
- Utilise-ton vraiment ce qui a été produit ?
- De quoi a-t-on le plus besoin ? De centraliser l’information plus que d’un point de vérité « absolue » ? Peut-on, doit-on décorréler les deux aspects dans une trajectoire S.I ?
- (…)
Les réponses sont très probablement à partager sans tabous
entre toutes les directions métiers, les CDO et CIO, en s’appuyant sur un
constat plus large établi auprès des équipes.
A l'heure où les entreprises font parfois les fonds de tiroir pour investir dans des start-ups et financier leurs investissements numériques, revisiter ses choix technologiques pourrait apporter de substantielles économies par des solutions en rupture avec le passé.
Vers un rapprochement des solutions Hadoop-Nosql ?
Hou là ... on entend déjà des cris d'orfraie...
Hadoop, Nosql : là aussi, on peut s’attendre à des
évolutions et des rapprochements au niveau des solutions qui seront proposées à terme (sur les couches hautes de
l’architecture, certaines fonctions et modules conjoints dans un premier temps)
Une donnée, qu’elle soit stockée pour une optimisation temps
réel (NoSql), ou pour une exploitation de type B.I (Hadoop) , reste la même et
répond aux mêmes exigences d’extraction initiale, de description, de règles de gestion,
de métadonnées multiples, disons plus simplement, d’administration générale et
fonctionnelle … même si les caractéristiques techniques de son exploitation
peuvent varier et/ou cohabiter selon les exigences de sa consommation (usage)
en temps réel pour le WEB ou en requêtage de masse à des fins statistiques.
Un mode de pensée en rupture avec le passé semble nécessaire
quant aux architectures mêmes des données, à leur place occupée au sein du
système d’information et à la façon de les administrer efficacement.
Les solutions de type "appliance" (infrastructure de type boîte noire) pourraient aussi grandement évoluer au cours des 10 prochaines années (certains en propose déjà , avec derrière...un SGBDr !)
L’UX en entrant principal à l'architecture des données
Les pratiques d’administration de la donnée sont originellement issues du monde de la gestion, les nouvelles solutions vont probablement bousculer ce dernier, en tentant de faire cohabiter « gestion structurée » et « ingestion destructurée » et "non modélisée" de l’information.
Avec la réduction des fonctions de type back-office poussée
par le numérique, porter au front-office la bonne information, partie
intégrante des métiers du front, est une préoccupation qui en permanence doit
accompagner les modélisations ainsi que les « grandes cinématiques »
de traitement de la donnée, de là à parler d’UX (expérience utilisateur) et le
pas est franchi…
En repartant des frontaux de communication et des situations
utilisateur (Web, Mobile, Agences, téléphone …), et selon l’étendue
fonctionnelle des services apportés, on s’aperçoit vite que cette « grande
cinématique » s’impose d’elle-même avec la nécessité d’alimenter dans un
temps asynchrone réduit les bases de données NoSql… doivent elle être ACID (2) ?
Peut-être bien que oui… mais attention à ne pas reconstruire le passé avec de
vieux réflexes, parce que les logiques et les impératifs sont
différents.
Refondre les applicatifs des S.I opérationnels n’aurait
aucun sens : y inscrire des informations pertinentes, à leur « périphérie »,
accessibles en temps réels semble être une voie plus pertinente sur le court
terme, sans mettre en péril un existant S.I parfois bien plus âgé…
Fédérer par le partage plutôt qu’unifier
Pour de grands groupes, constitués de plusieurs entités aux
systèmes d’informations distincts, ou simplement un S.I très hétérogène, plutôt qu’une gouvernance « intrusive »,
il peut-être opportun d’offrir des « services centralisés d’information complémentaires »
en lieu et place de lourds projets de refonte complète de l'existant, souvent menés jadis dans une logique d’hyper-centralisation de solution et qui
semble ne plus avoir de sens aujourd’hui : les variations de l’environnement externe à l’entreprise sont
trop grandes.
La vision centralisatrice des solutions applicatives patrimoniales est censée
apporter une économie d’échelle et optimiser les achats I.T et la maintenance : elle peut aussi être source d'effets tunnels magistraux.
Vu les courants actuels, fédérer et partager plutôt
qu’unifier semble parfois plus indiqué ( à moduler selon les contextes ...) : le coût de l’unification est parfois
démesuré et ne colle pas toujours avec l’échelle de temps économique, elle n’est
pas sans rappeler ces bonnes vieilles pratiques héritées des logiques mainframe. Une base NoSql centralisée interrogeable à moindre frais par des applicatifs patrimoniaux hétérogènes est sans doute plus pragmatique qu'une refonte de ces applicatifs et de l'ensemble de leurs modèles de données respectifs vers un modèle "classique" unifié (soit des services de création, lecture, mise à jour asynchrone en parallèle , "en plus" de l'existant plutôt que de réécrire l'existant).
Les bases Nosql peuvent être aussi, et surtout, une solution adaptée
pour les canaux où le prospect et le client sont l’utilisateur final, en facilitant
l’affirmation et l’ image d’un « groupe », d’une « Marque »,
dans une approche client en cohérence avec son histoire, et qu’il
constatera de manière visible et tangible dans les interfaces numériques et
services qui lui sont proposés, en accédant aux informations qu’il attend,
avec, ou sans MDM en amont du système d’alimentation...
- La donnée de référence trouve de multiples descriptions dans la littérature : fournisseurs, produits, personnes , elles se caractérisent par une certaine « persistance/permanence » de l’information. Les autres données, parfois appelées « transactionnelles » varient davantage dans le temps : les contrats, les équipements, les interactions client …
- ACID : Atomicité (l’opération est faite ou pas : pas de statut entre les deux), Cohérence (la base reste opérationnelle après l’opération, possibilité d’annuler, touche à l’intégrité fonctionnelle), Isolation (équivalent d’un verrou temporaire pendant l’opération qui est seule à modifier l’information), Durabilité (Cohérence et intégrité de la base en cas de défaillance système et autre … avec possibilité de reprise de l’opération) Plus classiquement : commit-point/Sync-point, Rollback, locking, Recovery des SGBDr …
Aucun commentaire:
Enregistrer un commentaire