Dans un SI moderne, le Big Data est à tous les étages

Le Big Data impose de repenser toute l’architecture des SI traditionnels, des front-end jusqu’aux back-end. Il doit être une propriété naturelle de n’importe quelle partie du SI, c’est en cela une véritable philosophie de la gouvernance IT.

Lorsqu’on essaie d’insuffler du Big Data dans un SI traditionnel, une évidence s’impose rapidement : il se propage à toutes les couches du système. Alors qu’est ce que cela donne dans un SI traditionnel “legacy” (animé par un mainframe et un SI de services type java J2EE par exemple) ?

Ici, l’architecture est assez complexe, les différentes couches du SI sont interconnectées avec des briques techniques intergicielles (ESB, EAI et ETL), des applications internes (types CRM, gestion documentaire, plus globalement tout ce qui sert à faire du suivi opérationnel) et des applications externes (type selfcare, c’est à dire les portails clients, les espaces adhérents, etc.). Mais au final, l’activité des sociétés utilisant ce type d’infrastructure ne génère pas énormément de données, ce n’est pas le coeur business qui pose problème. En fait il y a deux problèmes de “chaque côté” du SI.

Un BI qui ralentit le système…

Le premier problème vient du BI (Business Intelligence). Car avec les débuts du data marketing, en voulant mieux comprendre les attentes des utilisateurs, les sociétés ont commencé à intégrer des sources de données très volumineuses (reporting sur les sites, nature des clics, flux twitters…). Et les SI traditionnels se sont montrés bien trop lents pour gérer efficacement cette quantité de nouvelles données.

Pour répondre à cette problématique, les entreprises ont, dans un premier temps, changé de système ETL, concentré toutes ces données à un même endroit (les fameux data lakes) pour y “pluguer” des applications qui essayent de les exploiter au mieux. Mais la concentration de nombreuses données hétérogènes non urbanisées génèrent de nouveaux problèmes : la récurrence des doublons, des formats, et plus généralement de “data quality”. De plus, les applis sont compliquées à manipuler et souvent réservées aux data scientists.

… et des applications qui l’engorgent

En parallèle, un autre problème apparaît avec la prolifération des applications. Il survient dès lors qu’on met à disposition des services pour les utilisateurs. Car si les services sont simples et pertinents (c’est le but), ils vont être largement utilisés. Ce qui va générer une augmentation très importante du volume des données, et sur-solliciter l’ensemble du SI puisque toutes les couches techniques vont être impactées (tout va passer par l’ESB puis par l’EAI puis par le SI Open ou le SI Legacy). Si on ajoute à cela le premier problème issu du BI évoqué plus haut, et les effets secondaires sur les applications internes (problème de boucles rapides pour le CRM par exemple) c’est simple : tout le système s’écroule. On voit bien que dans cette configuration legacy le problème du Big Data se répand à l’ensemble du SI, sur tous les socles et à toutes les étapes.

Que faire alors ? Pour rappel, la problématique Big Data apparaît dès lors que le coût d’analyse d’une donnée avec un algorithme A sur un volume V de données pendant un delta temps T est supérieur au résultat business, c’est à dire au ROI.

The Big Data problem

Augmenter les capacités “physiques” du SI va coûter extrêmement cher, et réduire le nombre de services disponibles pour les utilisateurs le temps de corriger un problème est plutôt gênant. On a donc affaire à un problème de coût ou un problème d’agilité.

Le Big Data est une propriété du système

Pour augmenter l’agilité et rendre le déploiement d’applications plus rapide et moins coûteux, tout en minimisant l’impact de ce déploiement (sans avoir à reprogrammer l’ESB pour lui signifier qu’un nouveau service est à intégrer, et faire de même pour l’ETL), il faut créer des applications “nativement Big Data”.

Qu’est-ce que cela veut dire ?

Tout simplement qu’il s’agit d’applications naturellement intégrables, composées de petits blocs applicatifs avec de faibles responsabilités (c’est à dire des micro-services) mais très réactifs. Ce type d’application peut activement proposer des informations “directement consommables” par n’importe quelle autre partie du système, surtout si dès sa conception il intègre un protocole de qualité de la donnée (auto documenté et consolidé dans un registre global de flux, et plus généralement d’architecture du SI). On évite ainsi les problèmes de data quality et de propagation de la complexité dans le SI, et donc du coût de calcul (les technologies déployées sont pensées à la base pour supporter les gros volumes de données et les hautes fréquences). Le SI devient alors très agile dans sa production et sa consommation de données.

Une réponse adéquate à la problématique Big Data est donc de penser les applications et l’ensemble des systèmes comme “data centric”, pour exposer de la donnée de qualité et qualifiée. Le Big Data n’est donc pas un enjeu de “niche”, qui n’intéresse qu’une partie du SI, puisque le Big Data est partout dans le SI. On ne peut donc parler de “projet Big Data”, mais d’une propriété naturelle de n’importe quelle partie du système, transverse à toutes les couches applicatives.

Par Antoine Michel, CTO de Zengularity

contact@zengularity.com