Existe-t-il un fournisseur unique pour la gestion des données? Pas encore

Les architectes peuvent choisir, et choisissent effectivement, un fournisseur de services cloud principal et/ou un système Hadoop pour héberger leurs données. Déplacer, transformer, cataloguer et gérer les données est une autre histoire, alors les architectes viennent me voir après avoir baissé les bras. à la recherche de solutions pour apprivoiser le tissu informationnel, pensant qu'il leur manque quelque chose: « N'y a-t-il pas une plateforme unique? ils demander.

Malheureusement non. Il n’existe que les meilleurs outils ou plateformes de gestion de données en transition.

Il y a une histoire derrière tout ça. Les sociétés de middleware de gestion de données ont tendance à être relativement petites. Les fournisseurs de gestion de l'information tels qu'IBM, Oracle et SAP sélectionnent les petits fournisseurs de gestion de données et ajoutent leurs offres en tant que solutions à leur portefeuille global de plates-formes à vendre en tant que catalyseurs de leurs systèmes Big Data et Cloud. Les petits fournisseurs ne disposent pas des fonds nécessaires pour développer de manière préventive leurs capacités alors que les marchés évoluent vers de nouvelles architectures telles que le Big Data et le Cloud. Les grands fournisseurs résolvent la règle des 80 % selon laquelle les entreprises gèrent leurs activités sur une technologie traditionnelle fiable. Ainsi, la gestion et la gouvernance des données sont à la traîne par rapport aux tendances du Big Data et du Cloud. En fin de compte, les deux fournisseurs ont adopté une stratégie attentiste, renforçant leurs capacités et réorganisant leurs solutions uniquement lorsque les clients ont commencé à manifester un plus grand intérêt (c'est dans la RFI/RFP).

Nos évaluations Forrester Wave documentent cette histoire. Comme Forrester a constaté que 50 % des entreprises construisaient des lacs de données Hadoop en 2011 et que l'analyse/BI passait bientôt au cloud. par la suite, les fournisseurs de gestion de données de nos Waves commençaient tout juste à comprendre comment travailler dans ces environnements et les exécuter de manière native. en 2015. Même aujourd’hui, bon nombre de ces fournisseurs proposent toujours un outil sur site et un autre outil cloud. Les plus récents ne peuvent fonctionner que dans le cloud.

Les sociétés de capital-risque et de capital-investissement se sont lancées très tôt dans le financement des startups du Big Data. Mais peu de startups ont vu le jour alors qu’il existait déjà tout un marché d’outils open source pour l’ingestion, les pipelines, la sécurité et les métadonnées. Où était l’argent là-dedans? Ainsi, le marché s’est tourné vers la proposition de valeur plus sexy de l’apprentissage automatique, et l’argent des investisseurs a suivi. Pourquoi se soucier des données quand vous pouvez avoir des informations ?

Eh bien, les entreprises se soucient des données. Ils l’ont toujours fait et le font toujours. Il s’agit du plus grand domaine de dette technique et de talents dans une organisation. L’échec des lacs de Big Data et les blocages dans des domaines de systèmes à grande échelle tels que l’IoT et l’IA proviennent tous de bases de données en retard. C'est un scénario de la charrue devant les boeufs.

"Super!" vous dites. "Belle leçon d'histoire. Alors qu'est-ce qu'on fait faire?"

Reconnaissez les nouveaux outils pour ce qu’ils sont. Ignorez les étiquettes de plateforme et de solution appliquées aux noms de produits et aux offres. Ce qui est disponible, ce sont des fonctionnalités vaguement consolidées pour des cas d’utilisation de données spécifiques. Le potentiel de solutions complètes existe dans les produits commerciaux. Les interfaces et expériences utilisateur sont meilleures que l’open source. Il existe davantage de fonctionnalités de communication et de collaboration. Les fournisseurs savent que la conformité réglementaire et le support en matière de sécurité sont des enjeux majeurs pour toute entreprise. Et s'il n'y a pas de connecteurs pour les principales plates-formes cloud et Hadoop, ou pour les principales applications BI et métier, c'est une rupture. La stratégie de base pour acquérir ces outils se résume à connaître votre utilisateur et ses processus, l'ouverture des référentiels de métadonnées et les modèles d'abonnement. En fin de compte, vous devez trouver une solution pour aujourd'hui et vous donner une marge de croissance (consultez ce que mon collègue Noel Yuhanna vient de publier sur pérennité). Vous refactoriserez votre plate-forme le plus tôt possible.

Maintenant, voici ce que vous devez savoir sur les principaux outils de gestion de données :

• Gestion des métadonnées. Vous aurez besoin de deux ou trois catalogues de données: un pour la gestion des métadonnées physiques et logiques dont les ingénieurs de données ont besoin pour créer et gérer des systèmes; un pour les gestionnaires de données afin de gérer les métadonnées logiques, la sémantique et les politiques de données; et éventuellement un troisième catalogue de données qui prend en charge les capacités de recherche et de consommation permettant aux analystes BI et aux data scientists d'utiliser les données si le catalogue de gouvernance des données destiné aux gestionnaires de données ne fait pas l'affaire. Oui, Collibra, EDQ et Informatica sont des partenaires communs. L'utilisation de Navigator ou d'Atlas dans l'écosystème Hadoop n'est pas non plus inhabituelle pour les lacs de données.
• Gestion des données de référence. L'outil MDM relationnel traditionnel est généralement utilisé pour prendre en charge les mappages complexes de données entre les systèmes. Il vit au cœur des bases de données et de l’intégration. Ensuite, vous trouvez un MDM basé sur des graphiques pour gérer des vues complexes pour les clients et les produits plus proches de la BI et systèmes d'applications métier lorsque les modèles logiques nécessitent plus de préparation et de conversion en modèles sémantiques ou métier des modèles. Ensuite, il y a le MDM DIY vivant dans la virtualisation des données et Kafka qui éclaire le modèle de données et le mappage pour les vues BI, les microservices et les ESB.
• Intégration de données. C'est là que le plaisir commence puisque l'ETL, la virtualisation des données, un bus de données, le streaming, la réplication, les outils d'ingestion et la préparation des données vivent tous indépendamment ou dans un pipeline intégré. Les modèles de charge de travail définissent quels outils d'intégration de données sont utilisés et où dans le flux de données ou dans l'écosystème (cloud/sur site) ils sont nécessaires. Votre architecture de données adopte des modèles de référence alignés sur les transactions, les processus métier, les charges de travail d'automatisation, d'analyse et d'analyse (OLAP) et opérationnelles (OLTP). Votre architecture de référence est conçue d'abord pour les flux de données, et non pour les sources de données comme c'est le cas traditionnellement.
• Profilage et traçabilité des données. Autonome ou intégré: faites votre choix. Mais l’essentiel est que si le profilage et l’analyse du lignage sont intégrés, il y a de fortes chances qu’ils soient orientés vers la solution fondamentale. Profil de référentiels pour la capture de métadonnées et de sources de données. Profil d’outils de gouvernance des données pour les métadonnées logiques et commerciales et le lignage source. Profil de catalogues de données pour les métadonnées physiques et logiques, les relations entre les données et le lignage source. Certains peuvent profiler les métadonnées du flux de données. Les outils autonomes ont tendance à se concentrer sur l’analyse des métadonnées, du modèle, du lignage et du flux de données pour l’analyse des causes profondes. Gardez à l'esprit qui utilisera l'outil, ce qu'ils doivent savoir et que le profilage et l'analyse du lignage sont obligatoires pour que toutes les responsabilités en matière de données puissent comprendre les données.

Pour en savoir plus sur Forrester sur les technologies émergentes, cliquez sur ici.

Par Michele Goetz, analyste principale

Ce message a été initialement publié ici.