Resumen
- Define los productos de datos como API que requieren una documentación clara.
- Explica que los contratos de datos cubren los términos de uso y el ciclo de vida.
- Hace hincapié en el linaje y los metadatos para gestionar datos dinámicos.
- Apoya la gobernanza al mantener los datos en su entorno nativo.
Capítulos
Hablando de contratos, tampoco tenemos todavía una definición universal. ¿Qué opinas de los contratos de datos? Consideramos que un producto de datos es una API para, eh, datos.
Y al igual que con las API, quieres documentación para que quede claro en qué te estás metiendo, ¿verdad? Y qué significa todo eso. Y tengo entendido que todas las diferentes manifestaciones de contratos de datos que, eh, están surgiendo ahora mismo, son muy similares con algunas diferencias menores.
Creo que la idea subyacente de describir qué es, cómo se puede utilizar, las condiciones en las que se proporciona, si se cobra por ello, es estándar en todos los contratos. El script SQL que, ya sabes, puede estar detrás de una unión o un conjunto de datos, se proporcionará, eh, y los contratos de datos tendrán un ciclo de vida, ¿verdad?
Al igual que con los productos de datos, habrá la posibilidad de gestionar un producto de datos desde su creación hasta que se elimine, al final de su vida útil. Los datos no son algo estático. Una de las cosas de las que habla la gente es: «¿Tengo mis datos en el lugar adecuado?».
Pero, bueno, tal vez hoy, ¿pero has pensado en el linaje y has pensado en los metadatos? ¿Has pensado en lo que estos datos significan realmente para su clasificación? Porque tiene consecuencias posteriores sobre quién tiene acceso a algunos de estos conjuntos de datos o a algunos de los productos de datos, durante cuánto tiempo pueden utilizarlos o con qué fines.
Ahí es donde entra en juego el contrato, ¿no? Asegurarse de que los términos y condiciones en los que se proporciona ese producto de datos se cumplan realmente en la entrega del producto de datos.
Pero dónde residen los datos y cómo se gestionan, ¿verdad?, es complejo cuando los datos son complejos y desordenados, y estamos tratando de simplificar todo eso. Por lo tanto, según nuestra forma de pensar, los datos deben residir en su hogar natural. Pero si estás utilizando datos de Salesforce, déjalos en Salesforce, ¿verdad?
Si necesitas incluir esos datos en un panel de control que vas a presentar, extraigamos los datos que necesitamos para el panel de control de Salesforce y los colocamos allí. Pero lo que hemos visto es que la gente está creando enormes pantanos de datos, lagos de datos, que están contaminados con todo tipo de datos diferentes. Me gustan los pantanos de datos. Me gusta la palabra.
Lo que nos gustaría hacer es mantenerlo lo más limpio y sencillo posible, dejando los datos donde naturalmente pertenecen y, a continuación, proporcionando la capacidad de aplicar la gobernanza sobre ellos.