La migration des données en environnement Big Data
La donnée s’installe peu à peu au cœur de l’activité de nombreuses entreprises, tous secteurs confondus. Tous les nouveaux usages que mettent en place les entreprises s’appuient sur la donnée.
La capacité d’une entreprise mettre en place une stratégie de data management est devenue un enjeu clé. D’autant que, sur le plan technique, ces dernières années ont vu naître les environnements Big Data qui amènent avec eux leurs logiques propres.
Certes, les entreprises effectuent depuis toujours des migrations de données pour des questions de performances ou d’accessibilité aux données. Mais, jusqu’à récemment, ces changements s’effectuaient toujours avec une logique inchangée, dans un monde SQL où on passe d’un état tabulaire à un autre état tabulaire. Autrement dit, des migrations sans impact métier.
L’arrivée de technologies NoSQL ou Hadoop impose de réfléchir à la donnée différemment. De purement technologique, la migration devient une opération embarquant des enjeux métiers et organisationnels. Une migration qui peut parfois cacher des coûts indirects.
Chaque application est pensée pour un usage particulier
On peut remarquer que l’arrivée de ces nouvelles technologies correspond à celle de méthodologies de développement repensées, en particulier l’agile. Des méthodes qui portent des logiques alignées avec celles des environnements Big Data.
Auparavant, on concevait un système informatique un peu comme un bâtiment. On partait de l’expression des besoins pour écrire les spécifications fonctionnelles, qui permettaient alors de définir les spécifications techniques sur lesquelles reposait le développement. Ce qui avait du sens, car on traitait la donnée toujours de la même manière.
Alors que, dans le Big Data, il faut d’emblée réfléchir au besoin unique pour lequel l’application est développée. Tous les besoins font l’objet d’un développement spécifique directement lié à la manière de stocker la donnée, tout simplement parce que la structuration de la donnée se fait à l’usage et non plus au stockage.
Cette approche colle à la logique de l’agilité et privilégie les développements itératifs sur des durées courtes par des équipes pluridisciplinaires embarquant des experts techniques, tant côté développement qu’exploitation et métiers. Ce constat vaut pour Hadoop, et pour les technologies NoSQL orientées documents, graphes ou colonnes.
Dans le Big Data, stockage et usage ne font qu’un. Le métier doit donc être embarqué dans la technique. Si cette logique correspond à celle prônée par les méthodologies agiles, elle implique de profondes modifications de l’organisation du travail dans les entreprises, passant par un rapprochement des métiers et de la DSI. Ce facteur reste un frein dans l’adoption des technologies Big Data, le nouveau schéma organisationnel remettant également en cause le fonctionnement actuel de certaines équipes MOA (maîtrise d’ouvrage).
> À LIRE AUSSI : Stratégie data-centric : l’importance de la vision
Eviter le marécage de données (ou data swamp)
L’arrivée du Big Data passe au révélateur les rigidités des organisations informatiques, qui ont beaucoup misé sur le découpage transverse des fonctions de maîtrise d’ouvrage et de maîtrise d’œuvre et sur l’autonomisation de l’exploitation.
Le fait de ne pas avoir intégré l’exploitation à la DSI freine la constitution des équipes pluridisciplinaires nécessaires à une adoption bien pensée des technologies Big Data. Une tendance naturelle des entreprises qui font cohabiter de multiples équipes verticales, mais qui oblige à aligner de multiples compétences pour conserver, en interne, la maîtrise de ces outils. En la matière, les urbanistes ont un rôle clé à jouer pour minimiser le nombre d’outils déployés.
Les data lakes multi-usages (besoins décisionnels, transactionnels, analytiques, GED…) partent d’une réflexion centrée sur l’optimisation des coûts et non sur les besoins métier. Ces initiatives peuvent donc parfois se transformer en marécages de données.
En la matière, le choix d’une technologie ou d’une sélection restreinte de technologies pour couvrir tous les besoins apparaît plus pertinent. Surtout quand cette approche est couplée à la mise en œuvre d’API permettant d’exposer ces sets de données. Cela donne naissance à une architecture de type Data as-a-Service.
La rédaction vous conseille
> Les 10 raisons d’une migration cloud dans un projet Big Data
> Quels coûts directs et indirects pour votre migration Big Data ?
