[ ] ICYMI Lisez la partie 1 La plateforme de données non évolutive De nos jours, de nombreuses plateformes de données sont conçues de manière ascendante, en commençant par la collecte de données « susceptibles d’être utiles plus tard » et en rassemblant progressivement des solutions au fur et à mesure des besoins. Cette approche conduit inévitablement à une mise en œuvre fragmentée, à des coûts croissants et à une dette technique. La conception de systèmes de données nécessite une expertise spécialisée dans la modélisation des données, les systèmes distribués, la sécurité et la conformité. La plupart des entreprises ne peuvent tout simplement pas se permettre de consacrer des équipes dédiées à l’infrastructure de données à leurs débuts et doivent créer et adapter leurs systèmes de données au fur et à mesure de leur croissance. Cependant, le chemin à parcourir pour faire évoluer les systèmes existants peut être assez difficile. Les équipes doivent souvent choisir entre de longues migrations tout en conservant plusieurs systèmes dupliqués, ou une conversion complète et coûteuse du système. La décision de Netscape de réécrire son moteur de navigation en 1997 lui a coûté son activité de navigateur et sa domination du marché au profit d'Internet Explorer, car elle ne pouvait pas rivaliser avec les versions rapides de fonctionnalités d'Internet Explorer, ce qui a finalement conduit à une baisse de sa part de marché. De nombreuses entreprises commencent avec des solutions personnalisées et migrent vers des plateformes de fournisseurs au fur et à mesure de leur croissance. Cependant, même à l'échelle à laquelle les entreprises peuvent se permettre des plateformes de fournisseurs, elles peuvent toujours ne pas correspondre à leurs cas d'utilisation et les utilisateurs internes doivent s'adapter à de nouveaux flux de travail. De nombreuses entreprises finissent par créer des solutions personnalisées sur des plateformes de fournisseurs au fur et à mesure de leur croissance. Les équipes d'infrastructure internes doivent désormais maintenir leurs systèmes d'origine, exploiter les plateformes de fournisseurs et prendre en charge les implémentations personnalisées sur ces plateformes, tout en formant les utilisateurs à différents outils et en gérant la sécurité et les intégrations sur plusieurs systèmes. En raison du manque de planification et de progrès organique à mesure que l'entreprise évolue, ce qui était au départ une solution moins chère devient beaucoup plus coûteuse et complexe à exploiter. Concevoir des plateformes de données capables d'évoluer avec la croissance de l'entreprise est aujourd'hui plus réalisable qu'auparavant. Au cours de la dernière décennie, de nombreuses organisations ont établi des modèles clairs d'utilisation des données : les équipes produit ont besoin de données sur le comportement des utilisateurs, les équipes marketing suivent les performances des campagnes, les équipes financières surveillent les indicateurs de revenus et les équipes de sécurité analysent les modèles de menaces. Ces cas d'utilisation courants sont bien établis en termes de données dont ils ont besoin et de la rapidité avec laquelle ils en ont besoin. Plutôt que de découvrir les besoins par le biais de migrations coûteuses et de la mise à niveau des solutions des fournisseurs, il est possible de créer une plateforme de données capable d'évoluer de manière durable en termes de coûts et d'efficacité opérationnelle. Concevoir des plateformes de données À la base, une plateforme de données peut être définie par deux éléments fondamentaux : les données dont vous avez besoin (modèles de données) et la rapidité avec laquelle vous en avez besoin (exigences de latence). Même avec un cas d'utilisation vaguement défini, la compréhension de ces deux composants nous permet de déduire systématiquement les besoins en matière de mécanisme de collecte de données et d'infrastructure. Prenons l'exemple de la détection des risques de fraude. En règle générale, le risque de fraude nécessite trois composants de données : l'identité, la transaction et la gestion des dossiers. Chaque composant de données peut être mappé à l'infrastructure en fonction des besoins de latence. La vérification de l'identité et des transactions nécessite un traitement de flux pour les détections de fraude en temps réel, le traitement de la base de données gère la surveillance et les alertes en continu, et les lacs de données prennent en charge les tâches plus longues telles que l'analyse des modèles et la formation des modèles. Modèles de données Un modèle de données définit la manière dont les données doivent être organisées et normalisées. Il spécifie un ensemble de champs et leurs caractéristiques : le format, le type et les règles de chaque champ. Les schémas permettent la découverte des données, tandis que les définitions des champs individuels déterminent les politiques de gouvernance et les exigences de conformité. Des modèles de données bien définis permettent une collecte et un traitement standardisés des données dans toute l’organisation. Prenons l’exemple des données utilisateur : le marketing en a besoin pour le suivi des campagnes, le service client pour la gestion des dossiers, les équipes produit pour l’analyse comportementale et les équipes de gestion des risques pour la détection des fraudes. Sans modèle de données utilisateur partagé, chaque équipe crée sa propre version des profils utilisateur et de la logique de suivi. Les équipes finissent par créer des intégrations complexes pour résoudre et réconcilier les données utilisateur entre les systèmes. Un modèle de données partagé servant de source unique de vérité simplifie la collecte et la mise en œuvre des données, tandis que des normes cohérentes facilitent grandement la gestion de la sécurité et de la conformité. Définir des modèles de données complets est souvent difficile pour les équipes individuelles, car elles se concentrent généralement sur leurs besoins immédiats. Les équipes marketing se concentrent sur les domaines liés aux campagnes, tandis que les équipes de gestion des risques se concentrent sur les attributs de vérification d'identité. Sans une vision globale de la manière dont les mêmes données remplissent différentes fonctions, les équipes créent souvent des modèles de données incomplets ou étroitement ciblés qui nécessitent un traitement et des intégrations supplémentaires entre les systèmes. Exigences en matière de temps Les exigences temporelles définissent la rapidité avec laquelle les données doivent être traitées et mises à disposition. Les fenêtres de traitement vont du temps réel (secondes) pour les décisions immédiates au temps quasi réel (minutes) pour la surveillance, en passant par le traitement par lots (heures) pour les applications d'analyse et d'IA/ML. Ces exigences temporelles correspondent à des choix d'infrastructure spécifiques : streaming pour le temps réel, bases de données pour le temps quasi réel et lacs de données pour le traitement par lots. Sans cadre, les équipes produit construisent souvent une infrastructure redondante pour des besoins similaires : une équipe peut utiliser Kafka tandis qu'une autre utilise MSK pour le streaming, ou une équipe peut choisir DynamoDB tandis qu'une autre utilise Cassandra pour les bases de données. Cela crée une complexité inutile car les équipes gèrent plusieurs systèmes avec des contrôles de sécurité et des intégrations dupliqués. En standardisant les composants d'infrastructure, les équipes produit n'ont plus besoin de déployer leur propre infrastructure et les équipes plateforme peuvent réduire les frais opérationnels en gérant moins de systèmes. Cette standardisation permet également de meilleurs contrôles de sécurité, des intégrations rationalisées, une observabilité simplifiée et des coûts optimisés. Plateforme de données génériques Une architecture de plateforme de données nous permet de déduire systématiquement les spécifications de collecte de données, les exigences d'infrastructure, les contrôles de sécurité et les capacités d'intégration. Cela permet de répondre directement à la complexité et à la spirale des coûts à laquelle de nombreuses organisations sont confrontées aujourd'hui. Plutôt que de faire construire des systèmes distincts par des équipes qui ont du mal à les prendre en charge, un cadre cohérent simplifie la sécurité, la conformité, l'intégration et la gestion des coûts dans toute l'organisation. Sans une mise en œuvre cohérente, les équipes de plateforme doivent constamment choisir entre la maintenance des systèmes existants, la réalisation de migrations coûteuses ou la création de nouvelles fonctionnalités. Les équipes de plateforme finissent par consacrer la majeure partie de leur temps à la maintenance de systèmes disparates et à la gestion des migrations au lieu de fournir des fonctionnalités essentielles à l'entreprise. Une approche basée sur un framework permet aux organisations de faire évoluer leurs plateformes de données sans migrations perturbatrices. Les petites organisations peuvent commencer avec les composants nécessaires et s'étendre au fur et à mesure de leur croissance, et les grandes organisations peuvent standardiser leurs systèmes existants une fois sans réécriture constante. À venir Dans la troisième partie de la , nous verrons comment ce cadre peut être mis en œuvre au niveau pratique. Nous verrons comment les composants courants de la plateforme de données tels que le streaming, les bases de données, l'entrepôt de données et le lac de données peuvent être assemblés pour prendre en charge différents cas d'utilisation métier avec des contrôles de sécurité et de conformité cohérents. À mesure que les organisations se développent, cette approche modulaire permet aux équipes de faire évoluer les composants individuels de manière indépendante tout en conservant des interfaces et des contrôles standardisés, éliminant ainsi le besoin de migrations constantes. Avec un cadre d'architecture de plateforme de données clair, les organisations peuvent créer des applications de données qui évoluent avec leur activité plutôt que de la limiter. série « One Off to One Data Platform »
![featured image - Plateforme de données One Off to One : concevoir des plateformes de données avec une intention évolutive [Partie 2]](https://hackernoon.imgix.net/images/a-bump-of-numbers-scatter-atop-a-scale-p0147e74ie60vwfjj5lggl1e.png?auto=format&fit=max&w=3840)
