Planification d’une plateforme de données unifiée

Cet article aide les décideurs à établir le modèle organisationnel nécessaire pour créer et maintenir des produits de données précieux au sein de l’organisation.

Les organisations doivent décider où réside la responsabilité des données et comment elles dirigeront les ressources vers les produits de données qui comptent le plus. Sans priorité claire en matière de propriété et d’investissement, les initiatives de données peuvent se disputer les ressources, dupliquer les efforts et créer des produits de données qui n’ont pas de valeur commerciale soutenue. Cet article aide les organisations à établir des domaines de données, à hiérarchiser les investissements dans les produits de données, à choisir un modèle d’exploitation et à développer les fonctionnalités nécessaires pour prendre en charge ces priorités.

Arbre de solution et de décision

Architecture conceptuelle d’une plateforme de données unifiée pour l’IA et l’analytique.

Arbre de décision

Le flux pose une série de questions oui-ou-non. Chaque « Oui » mène à des conseils spécifiques. La première question pose si l’organisation a besoin d’aide pour comprendre les priorités des données ou créer des compétences pour obtenir plus de valeur à partir des données. Si c’est le cas, l’aide consiste à préparer des personnes par le biais de rôles, de formation et d’activités de préparation. La deuxième question pose la question de savoir si l’organisation a besoin d’un moyen unifié d’accéder aux données entre les clouds et les charges de travail pour prendre en charge l’analytique et l’IA. Si c’est le cas, l’aide consiste à utiliser Microsoft Fabric comme plateforme de données unifiée. La troisième question pose si l’organisation a besoin d’aide pour transformer les données opérationnelles en valeur métier ou en alimentant en toute sécurité les données dans des systèmes IA, tels que Microsoft Foundry. Si c’est le cas, la recommandation est d'intégrer les services Azure avec Fabric. La quatrième question pose si l’organisation a besoin d’aide pour contrôler l’accès aux données ou pour sécuriser les données de manière cohérente. Si c’est le cas, l’aide consiste à définir des bases de référence de gouvernance et de sécurité à l’aide de Microsoft Purview et des contrôles associés. La cinquième question pose si l’organisation a besoin d’aide pour définir des normes organisationnelles cohérentes pour traiter, sécuriser et consommer des produits de données pour l’analytique et l’IA. Si c’est le cas, l’aide consiste à définir des normes opérationnelles pour les produits de données, la sécurité et la gestion du cycle de vie. Le flux se termine par l’adoption de l’IA et l’adoption d’agents IA une fois que la plateforme et les normes de données unifiées sont en place.

L’arbre de décision de Microsoft pour vous guider dans votre plateforme de données unifiée.

1. Modèle d’exploitation

Comment devez-vous distribuer les responsabilités ? Les organisations doivent utiliser un modèle d’exploitation fédéré qui combine la gouvernance à l’échelle de l’organisation avec la responsabilisation des domaines de données. L’organisation doit établir des politiques qui s’appliquent à tous les domaines de données. Chaque domaine de données doit avoir autorité sur ses données et ses produits de données au sein de ces politiques. Les organisations doivent documenter cette division d’autorité.

1.1 Domaines de données

Quelles responsabilités devons-nous décentraliser ? Un domaine de données définit une limite organisationnelle pour la responsabilité sur les données et les produits de données connexes.

Vue d’ensemble des domaines de données.

• Création des domaines de données : les domaines de données doivent s’aligner sur les limites organisationnelles au sein desquelles un responsable peut définir des priorités et contrôler l’investissement. Les unités commerciales ou les lignes de produits fournissent souvent des périmètres efficaces, car elles ont déjà établi un leadership et des budgets. Les domaines de données ne doivent pas refléter l’emplacement où résident les données ou quelle technologie les stocke. Si aucun responsable n’a suffisamment d’autorité sur les données associées et les produits de données, définissez une limite différente.

• Propriété des données : attribuez un propriétaire principal à chaque domaine de données. Le propriétaire est responsable des résultats métier et des produits de données du domaine et a besoin d’une autorité suffisante pour définir des priorités et arbitrer des besoins concurrents.

• Investissement dans les produits de données : chaque domaine de données doit déterminer quels produits de données proposer et soutenir en fonction de ses priorités métier.

• Budget du domaine : les domaines de données doivent déterminer comment utiliser leur budget pour prendre en charge leurs données et leurs produits de données au sein des exigences à l’échelle de l’organisation.

• Modifications de domaine de données : les limites du domaine de données doivent rester stables jusqu’à ce que la responsabilité organisationnelle change de manière significative. Les organisations doivent passer en revue les périmètres après les modifications de l’organisation ou lorsque les décisions inter-domaines périodiques créent une responsabilité peu claire. L’escalade répétée peut indiquer que la structure du domaine de données ne reflète plus l’autorité de décision organisationnelle.

1.2 Responsabilité centrale

Quelles responsabilités devez-vous centraliser ? Centraliser les décisions nécessitant une cohérence entre les domaines de données. La responsabilité centrale doit se concentrer sur la politique à l’échelle de l’organisation et les fonctionnalités partagées nécessaires pour l’appliquer.

• Politiques à l’échelle de l’organisation : l’organisation doit établir des exigences de gouvernance et de sécurité qui s’appliquent à tous les domaines de données. Il doit également établir les normes que les produits de données doivent respecter pour la réutilisation organisationnelle. Ces politiques définissent les limites dans lesquelles les domaines de données prennent leurs propres décisions.

• Garde-fous de la plateforme : l’organisation doit traduire les politiques à l’échelle de l’organisation en garde-fous de la plateforme. Microsoft Fabric prend en charge l’administration centralisée et déléguée à l’échelle du locataire et d’autres étendues. L’organisation doit contrôler de manière centralisée les paramètres qui peuvent créer une exposition à l’échelle de l’organisation, comme le partage externe ou l’accès invité. Il doit déléguer des paramètres de configuration lorsque les domaines de données peuvent prendre des décisions indépendantes sans augmenter le risque à l’échelle de l’organisation. Les organisations doivent examiner régulièrement les paramètres du locataire, car Microsoft Fabric introduit de nouvelles fonctionnalités et paramètres. Consultez la présentation de la gouvernance et conseils.

• Fonctionnalités partagées : l’organisation doit fournir des fonctionnalités de plateforme partagée lorsque la centralisation améliore la cohérence ou réduit la duplication des efforts liés à la plateforme. Ces fonctionnalités peuvent inclure Microsoft Fabric et Microsoft Purview. L’organisation doit établir la façon dont les domaines de données accèdent aux capacités partagées et les financent. Les domaines de données doivent conserver l’autorité sur les investissements qui soutiennent leurs propres données et produits de données.

• Exceptions : l’organisation doit établir un processus d’exception documenté pour les domaines de données qui ne peuvent pas répondre à une politique ou à une exigence de plateforme partagée. Chaque exception approuvée doit identifier le dirigeant responsable et les conditions de maintien de l’approbation.

2. Hiérarchisation des données

Comment devez-vous hiérarchiser les initiatives de données ? Les décideurs doivent maintenir une feuille de route hiérarchisée de produits de données qui prennent en charge les objectifs métier définis. Un produit de données est un ensemble réutilisable de ressources de données organisées autour d’un objectif métier défini. Les organisations doivent commencer par le résultat métier plutôt que les données disponibles. Cette approche dirige l’investissement vers des produits de données avec des consommateurs identifiables et une valeur mesurable.

• Objectifs métier : chaque produit de données proposé doit prendre en charge un objectif métier défini. Un objectif métier peut dépendre des produits de données provenant de plusieurs domaines de données. Chaque domaine de données reste responsable des produits de données qu’il fournit. Les décideurs doivent financer un produit de données uniquement lorsque son sponsor peut expliquer le résultat qu’il permet d’obtenir et comment l’organisation reconnaîtra cette valeur. Le résultat pourrait améliorer une décision importante. Il peut activer l’automatisation ou fournir des données fiables à réutiliser.

• Cas d’investissement : chaque produit de données proposé doit avoir un cas d’investissement qui identifie sa valeur attendue et les ressources nécessaires pour le fournir et le maintenir. Le cas d’investissement doit identifier la criticité métier du produit de données. L’organisation doit utiliser cette classification comme donnée d’entrée pour définir les exigences en matière de fiabilité, de déploiement, de supervision, de capacité et de modification. Les décideurs doivent évaluer si la valeur attendue justifie l’investissement total sans décider de la conception technique.

• Priorité du portefeuille : les organisations doivent comparer les produits de données proposés à l’aide de critères cohérents pour la valeur métier et la faisabilité. Les dépendances doivent déterminer le séquencement après que les responsables établissent une valeur relative. Chaque examen devrait aboutir à une décision de financer, de différer ou de rejeter la proposition. Les produits de données à valeur élevée avec des prérequis réalisables doivent normalement faire l’objet d’un investissement plus précoce. Les organisations doivent reporter une proposition lorsqu’un prérequis critique n’est pas prêt. Ils doivent rejeter une proposition lorsque sa valeur attendue ne justifie pas l’investissement.

• Investissement continu : les organisations devraient réévaluer les produits de données financés à mesure que les priorités métier et la valeur réalisée évoluent. Les domaines de données doivent fournir suffisamment de preuves pour indiquer si chaque produit de données continue de prendre en charge son résultat prévu. Les décideurs doivent continuer à investir lorsqu’un produit de données fournit une valeur suffisante et conserve une responsabilité clairement définie. Ils doivent réduire l’investissement ou mettre hors service un produit de données lorsque sa valeur ne justifie plus son coût.

3. Effectifs

Comment devons-nous doter les domaines de données en personnel ? La feuille de route du produit de données doit orienter les besoins en effectifs. Les organisations ne doivent pas établir d’équipes permanentes avant l’existence d’une demande soutenue.

• Personnel dédié : un domaine de données doit utiliser un personnel dédié lorsque la demande soutenue justifie une expertise persistante. Ce modèle s’adapte également aux domaines de données qui prennent en charge les produits de données stratégiquement importants ou dépendent fortement des connaissances métier. Le domaine des données doit financer des effectifs dédiés par le biais de son budget approuvé.

• Personnel partagé : l’organisation doit fournir un personnel partagé lorsque plusieurs domaines de données ont besoin d’une expertise similaire, mais que la demande individuelle est intermittente. Les spécialistes mutualisés peuvent fournir des fonctionnalités telles que l’ingénierie des données ou l’administration de plateforme. Les spécialistes partagés doivent hiérarchiser le travail en fonction de la feuille de route du produit de données.

• Personnel externe : un domaine de données doit utiliser des fournisseurs externes lorsque le besoin est temporaire ou hautement spécialisé. Les fournisseurs externes peuvent également accélérer la livraison jusqu’à ce que l’organisation développe une capacité interne. Le domaine de données doit identifier les connaissances qui doivent être transférées en interne avant la fin de l’engagement.

4. Skilling

Comment devons-nous obtenir les compétences dont nous avons besoin ? Les décideurs doivent identifier les lacunes de capacité à partir de la feuille de route approuvée, puis sélectionner des méthodes de développement pour combler ces lacunes.

• ** Développement appliqué*** : La formation doit répondre à un écart de capacité identifié et se connecter au travail actif du produit de données lorsque cela est pratique. Cette approche donne aux personnes un cadre dans lequel appliquer de nouvelles connaissances. Il donne également aux dirigeants des preuves que la formation améliore la capacité de livraison.

• ** Validation des compétences** : les identifiants (certifications et compétences appliquées) peuvent valider les compétences pertinentes sur la plateforme. Ils doivent soutenir la stratégie des capacités plutôt que de la définir. Les organisations doivent sélectionner les formations Microsoft Learn actuelles et les certifications basées sur les rôles après avoir identifié les rôles et les fonctionnalités dont elles ont besoin. Voir Titres de compétences Microsoft.

5. Gestion des coûts et FinOps

Comment votre organisation doit-elle gérer les dépenses ? Les organisations doivent établir un processus FinOps continu qui connecte les dépenses avec la valeur des produits de données. Chaque domaine de données doit assumer la responsabilité financière de ses dépenses dans les limites de son budget approuvé. L’organisation doit utiliser ses processus financiers Azure existants pour Microsoft Fabric dans la mesure du possible. Il doit définir des processus supplémentaires spécifiques aux Fabric uniquement lorsque la capacité de Fabric partagée nécessite une allocation de consommation plus détaillée.

5.1 Allocation des coûts

Comment allons-nous allouer des coûts ? Les organisations doivent aligner l’allocation des coûts de Fabric sur leur modèle d’allocation des coûts Azure existant. Les organisations qui utilisent déjà le showback ou la rétrofacturation pour Azure doivent étendre ce modèle à Fabric le cas échéant. La méthode d’allocation doit affecter des dépenses aux domaines de données responsables de sa consommation. La méthode doit également expliquer comment l’organisation distribue les coûts partagés et les avantages liés aux réservations.

• Rapport des coûts Azure : Microsoft Cost Management peut organiser et redistribuer les coûts entre les abonnements, les groupes de ressources ou les balises par le biais de règles d’allocation de coûts. Voir Affectation des coûts.

• Nouveau processus : si vous n’avez pas de modèle établi, commencez par le showback pour donner aux domaines de données une visibilité sur leurs coûts avant d’introduire la rétrofacturation.

• Outils de rétrofacturation : lorsque les domaines de données partagent la capacité Fabric, utilisez l’application de rétrofacturation Microsoft Fabric pour attribuer la consommation de capacité Fabric aux domaines de données appropriés. Consultez l’application de rétrofacturation Microsoft Fabric.

5.2 Prévision des coûts

Comment prévoir les coûts de Fabric ? Les domaines de données doivent prévoir les dépenses attendues dans le cadre de leur processus de budget et mettre à jour les prévisions à mesure que la consommation réelle devient connue. La capacité Fabric est un facteur de coût important, ce qui permet de tenir compte des besoins en capacité planifiés et de la croissance attendue.

Les domaines de données doivent utiliser l’estimateur SKU Microsoft Fabric pour la planification initiale et l’application Métriques de capacité Microsoft Fabric pour affiner les prévisions à l’aide de la consommation observée. Microsoft recommande de commencer par une capacité de Fabric plus petite et d’augmenter la capacité lorsque la demande réelle justifie un investissement supplémentaire. Consultez la planification de la capacité de Fabric.

5.3 Optimisation des coûts

Comment optimiser les dépenses ? Les responsables de domaine de données doivent comparer régulièrement les dépenses réelles avec le budget approuvé et la valeur attendue de leurs produits de données. L’examen doit déterminer si les dépenses restent justifiées ou si l’organisation doit optimiser la consommation ou modifier l’investissement.

• Fréquence de révision : la cadence de révision doit refléter la volatilité des coûts. Les révisions mensuelles correspondent normalement aux domaines de données avec des charges de travail variables ou des pics de consommation périodiques. Les bilans trimestriels peuvent correspondre aux domaines de données avec une utilisation stable et prévisible.

• Outils FinOps : les responsables du domaine des données doivent utiliser l’utilisation de la capacité Fabric avec la facture Azure pour comprendre les facteurs de coût matériels. Microsoft Cost Management affiche les frais d’utilisation d’une capacité de Fabric, et l’application Métriques de capacité Microsoft Fabric fournit les informations d’utilisation de la capacité correspondantes. Consultez Comprendre votre facture Azure pour la capacité Fabric et Évaluez et optimisez votre capacité de Microsoft Fabric.

• Tarification basée sur l’engagement : les organisations peuvent acheter des réservations de capacité Fabric pour des périodes d’un an ou de trois ans. Une réservation couvre l’utilisation de capacité Fabric correspondante, mais ne couvre pas les frais de stockage ou de mise en réseau. Les organisations doivent prendre cet engagement uniquement une fois que l’utilisation est devenue suffisamment prévisible. Réduisez vos coûts avec les réservations de capacité Microsoft Fabric.