Résumé
- Définit data products des API nécessitant une documentation claire.
- Explique que data contracts les conditions d'utilisation et le cycle de vie.
- Met l'accent sur la lignée et métadonnées la gestion des données dynamiques.
- Soutient gouvernance conservant les données dans leur environnement d'origine.
Chapitres
En parlant de contrats, nous n'avons toujours pas de définition universelle non plus. Que pensez-vous des data contracts? Nous considérons donc un produit de données comme une API pour, euh, les données.
Et comme pour les API, vous voulez une documentation qui explique clairement ce dans quoi vous vous engagez, n'est-ce pas ? Et ce que tout cela signifie. D'après ce que j'ai compris, toutes les différentes manifestations data contracts , euh, qui apparaissent actuellement, sont très similaires avec quelques différences mineures.
Je pense que l'idée sous-jacente qui consiste à décrire ce que c'est, comment cela peut être utilisé, les conditions dans lesquelles cela est fourni, s'il y a des frais croisés, tout cela est standard dans tous les contrats. Le script SQL qui, vous savez, peut être derrière une jointure ou un ensemble de données, sera fourni, euh, et data contracts un cycle de vie, n'est-ce pas ?
Comme pour data products, il sera possible de gérer un produit de données depuis sa création jusqu'à sa suppression, à la fin de sa durée de vie utile. Les données ne sont pas statiques. L'une des questions que les gens se posent est : « Mes données sont-elles au bon endroit ? »
Mais, enfin, peut-être aujourd'hui, mais avez-vous pensé à la filiation et avez-vous pensé aux métadonnées? Avez-vous réfléchi à ce que ces données signifient réellement pour leur classification ? Parce que cela a des conséquences en aval sur qui a accès à certains de ces ensembles de données ou data products certains des data products la durée pendant laquelle ils peuvent les utiliser ou à quelles fins.
C'est là que le contrat entre en jeu, n'est-ce pas ? Il s'agit de s'assurer que les conditions générales de fourniture de ce produit de données sont bien respectées lors de la livraison du produit de données.
Mais l'emplacement des données et leur gestion sont complexes lorsque les données sont complexes et désordonnées, et nous essayons de simplifier tout cela. Donc, selon notre façon de penser, les données devraient rester à leur emplacement naturel. Mais si vous utilisez des données Salesforce, laissez-les dans Salesforce, d'accord ?
Si vous avez besoin d'intégrer ces données dans un tableau de bord vous présentez, alors extrayons les données dont nous avons besoin pour le tableau de bord Salesforce et et, et plaçons-les là. Mais ce que nous avons constaté, c'est que les gens créent ces immenses marécages de données, ces lacs de données, qui sont simplement pollués par toutes sortes de données différentes, J'aime les marécages de données. J'aime ce mot.
Ce que nous aimerions faire, c'est garder cela aussi propre et simple que possible en laissant les données là où elles se trouvent naturellement, puis en fournissant la possibilité d'exercer une gouvernance celles-ci.
