Los tipos de datos de la empresa

🌐 También en 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 2 de 6 del capítulo Entender los datos de la empresa, capítulo 4 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Salesforce es un sistema entre muchos · Siguiente: Los sistemas alrededor de Salesforce

La pregunta que responde este módulo: ¿Qué tipos de datos tiene una empresa, y por qué pertenecen a lugares distintos?

Un registro de cliente. Una lista de países. Un pedido. La definición de un campo. Cinco años de totales de ventas. Cuatro millones de fotos de entregas. Todo son datos, pero desde la arquitectura no son lo mismo. Cambian de forma distinta, crecen de forma distinta, se usan de forma distinta y tienen dueños distintos, y no deberían vivir automáticamente en el mismo lugar. Así que cuando alguien dice “necesitamos estos datos en Salesforce”, mi siguiente pregunta es: ¿qué tipo de datos son? La respuesta empieza a decirme qué hacer con ellos.

Empieza por el tipo, no por el objeto

Quienes trabajamos con Salesforce traducimos los requisitos en estructuras casi al instante: cliente, cuenta; foto, archivo; estado, lista de selección. Al final eso es útil. A nivel de empresa, primero quiero saber con qué tipo de información estoy tratando. Hay muchas formas de clasificarla (el cuerpo de conocimiento de DAMA es la referencia estándar), y a mí me resultan útiles seis tipos: maestros, de referencia, transaccionales, metadatos, analíticos y no estructurados. Las categorías no son la arquitectura. Son una forma de hacer mejores preguntas.

Datos maestros: las cosas que conoce el negocio

Los datos maestros describen las cosas duraderas alrededor de las que funciona un negocio: clientes, productos, precios, empleados, proveedores, ubicaciones, activos. En una organización de Salesforce para ventas, son tus cuentas y contactos, tus productos y tus listas de precios. En Steve Trucking, un socio minorista es un dato maestro. Keystone no es un evento; es una organización con la que Steve Trucking tiene una relación continua. Los nueve centros de distribución también son datos maestros.

Los datos maestros sobreviven a las transacciones que los usan: un socio minorista puede tener millones de entregas. Así que la primera pregunta sobre ellos es siempre ¿quién es su dueño? Puede que no sea Salesforce. El ERP puede ser dueño de los productos. Salesforce puede ser dueño de los prospectos mientras el ERP pasa a ser la referencia una vez que son clientes. Una plataforma de MDM puede ser dueña de la identidad de un cliente en toda la empresa, armada a partir de varios sistemas. El capítulo 6, Datos maestros e identidad, profundiza. Por ahora, reconoce la forma.

Datos de referencia: el vocabulario que comparte el negocio

Los datos de referencia son el vocabulario controlado que se usa para clasificar otros datos: códigos de país, divisas, categorías de producto, códigos de motivo, estados. Los estados de entrega de Steve Trucking (programada, cargada, en reparto, llegando, entregada, instalada, excepción, devuelta) son datos de referencia. No son entregas; son las palabras que se usan para describir las entregas.

Parecen pequeños e inofensivos, a menudo una lista de selección con ocho valores. No confundas pequeño con poco importante. Si Salesforce dice Delivered, el ERP dice Complete y un socio minorista envía D, alguien tiene que definir qué significa cada uno y cómo se corresponden. En los datos de referencia se esconden los supuestos de integración.

Datos transaccionales: lo que pasó

Los datos transaccionales registran la actividad: un pedido realizado, un pago hecho, una entrega completada, un caso abierto. En esa misma organización de ventas, son las cotizaciones y sus partidas, los pedidos y sus productos, los pagos: cada uno apunta a un cliente y a un producto. El millón de entregas al año de Steve Trucking son transaccionales, y también lo son sus actualizaciones de estado: unas ocho por entrega, así que ocho millones de cambios de estado al año, en un negocio que crece un 30% anual.

Es una curva de crecimiento completamente distinta de la de los datos maestros. Tres socios minoristas arriba; millones de filas debajo. Aquí es donde importa el Número de Ceros de Steve: no puedes mirar Socio minorista → Entrega → Estado y darle el mismo peso a cada caja. Con los datos transaccionales pienso de inmediato en el volumen, la velocidad, la retención, el historial, el archivo, la integración y cómo necesita la gente encontrarlos de verdad. La Parte 2 pasa mucho tiempo ahí.

Metadatos: datos sobre los datos

Has trabajado con metadatos durante todo el curso: la definición de un objeto, el tipo de un campo, su descripción, sus relaciones. Toda la empresa los tiene: esquemas del almacén de datos, mapeos de integración, catálogos de datos, contratos de API y, para cada campo, un dueño, un nivel de confidencialidad, una definición, un linaje y una regla de retención. Los valores son datos; la descripción de lo que significan son metadatos. Como dijo el capítulo 3, Flag2__c no le dice nada a nadie, y eso importa más ahora que la IA lee los metadatos para averiguar qué significan los datos.

Datos analíticos: datos que hicimos a partir de otros datos

“¿Cuál es nuestra tasa de puntualidad por socio minorista en los últimos cinco años?” no es una transacción. Es una pregunta analítica, que se responde derivando datos nuevos de millones de entregas: porcentaje de puntualidad, tasa de daños, ingresos por socio, calidad de las instalaciones, tendencias de los equipos. Y es otro trabajo. El despachador que pregunta “¿cuál es la siguiente parada del camión 217?” no necesita recorrer cinco años de historial. La dirección que compara cinco años de puntualidad por región, sí. Por eso los datos analíticos suelen vivir en un almacén de datos, un lakehouse o una plataforma de analítica construida para ese trabajo. Que Salesforce pueda guardar algo no convierte la plataforma operativa en el lugar donde ejecutar cada análisis sobre ello.

Datos no estructurados: lo que no cabe en filas

Documentos, PDF, imágenes, audio, video, correos electrónicos, transcripciones, artículos de conocimiento. En Steve Trucking, las fotos de las entregas: unas cuatro por entrega, más con las instalaciones, de cuatro a cinco millones al año. Una foto no es solo otro campo. Es grande, puede mostrar el interior de la casa de alguien, tiene sus propias reglas de retención y se busca de otra forma, si es que se busca.

Este tipo importa más cada año, porque ahora la IA puede hacer cosas útiles con información que antes quedaba fuera del modelo estructurado. Una transcripción son datos. Un manual en PDF son datos. Una foto de instalación son datos. Eso no significa que pertenezcan al núcleo de Salesforce. Significa que pertenecen al panorama.

Click to enlarge

Seis tipos, cuatro preguntas cada uno. Las respuestas cambian de un tipo a otro, y de eso se trata.

El tipo es solo la mitad de la pregunta: la carga de trabajo

Saber qué tipo de datos tenemos no basta. También quiero saber qué estamos haciendo con ellos. Aquí importan tres cargas de trabajo, y confundirlas produce mala arquitectura.

Operativa: hacer funcionar el negocio. Un despachador actualiza una entrega, un equipo completa una parada, un agente abre un caso. Muchas lecturas y escrituras pequeñas: encuentra esto, actualiza aquello, muéstrame las paradas de hoy. Esto es OLTP, procesamiento de transacciones en línea, y Salesforce es muy bueno en ello; es donde viven los administradores y los desarrolladores.

Analítica: entender el negocio. Cada entrega de cinco años, agrupada por socio y centro de distribución, comparada año contra año, cruzada con finanzas. Ahora estamos recorriendo y agregando. Esto es OLAP, procesamiento analítico en línea, y es para lo que están hechos los almacenes de datos, los lakehouses y las plataformas de analítica. Dicho de forma sencilla: la organización hace funcionar el negocio; los almacenes y los lagos de datos lo analizan. Un error clásico es poner esa carga de trabajo en la plataforma operativa y sorprenderse cuando crecen los ceros. Si alguien quiere recorrer cantidades enormes de historial una y otra vez, no lo trates como “un informe más”. Pregunta si es la plataforma correcta. La Parte 2 vuelve a esto en Diseñar para la escala (coming soon) (no conviertas el núcleo en tu almacén de datos), y la Parte 3 muestra cómo se construyen las estructuras analíticas en Más allá de lo relacional (coming soon).

Streaming: datos en movimiento. Eventos, telemetría, cambios de estado, lecturas de sensores. Los camiones de Steve Trucking envían unas 200,000 lecturas de GPS al día. Al despachador le importa dónde está el camión 217 ahora. ¿Necesita Salesforce guardar cada lectura minuto a minuto de cada camión? Quizá no. “¿Dónde está ahora?” y “¿cuáles fueron las tendencias de eficiencia de las rutas el trimestre pasado?” vienen de la misma fuente y llevan a decisiones de almacenamiento completamente distintas.

¿Qué tan rápido tiene que moverse?

Luego la latencia. En clase lo digo así: tiempo real es esperar en la puerta a que alguien vuelva. Lo mandas afuera y te quedas ahí, porque no puedes seguir hasta que regrese. Eso es síncrono. Casi tiempo real es verlo salir y seguir con otra cosa; cuando vuelve poco después, te ocupas de ello. Eso es asíncrono. Y luego está por lotes: nadie sale por la puerta de uno en uno. Los datos esperan y se mueven en grupo según un horario: cada hora, cada pocas horas o a diario. Hay muchas situaciones en las que el proceso por lotes basta, y algunas en las que no. Saber cuál es cuál es el trabajo. Esos tres no son solo términos de integración; son decisiones de arquitectura.

Toma la integración habitual con el ERP. Se crea un producto nuevo en el ERP a las 11 de la mañana. ¿De verdad ventas necesita venderlo antes del mediodía? He visto las dos respuestas. Algunos clientes lo quieren lo antes posible; otros dicen: si todavía no te hemos enviado ese SKU, no podemos esperar que ya lo vendas. Así que los productos suelen ir a diario, a veces más rápido. Los clientes, como mínimo a diario; he visto cada hora y, en casos extremos, casi tiempo real. Los pedidos son distintos: el cumplimiento tiene que empezar, así que casi tiempo real. El vendedor cierra el trato y sigue con lo suyo, y el pedido llega al ERP en unos segundos o en un minuto o dos. No hay una única latencia correcta para “los datos de la empresa”. Pregunta qué necesita realmente el negocio, y no hagas todo en tiempo real porque suena impresionante. El tiempo real tiene un costo.

Las cuatro preguntas detrás de las categorías

No necesitas ir por ahí anunciando “¡esto son datos transaccionales!”. La clasificación está para provocar cuatro preguntas sobre cada conjunto de datos importante:

• ¿Quién es su dueño? ¿Qué sistema es la referencia? Lo divido en tres: ¿dónde se crea, dónde se edita y dónde se referencia? El capítulo 6 profundiza en esto (¿Dónde se crea, se edita, se referencia, y con qué rapidez?).
• ¿Qué tan rápido cambia? ¿Una vez al año, a diario, de decenas a cientos de veces por segundo?
• ¿Qué tan grande se vuelve? ¿Diez registros, diez mil, diez millones, diez mil millones?
• ¿Cuál es su ciclo de vida? ¿Vive para siempre, se archiva, tiene que eliminarse, pierde valor con el tiempo?

Esas cuatro me dicen mucho más que “¿puede Salesforce guardar esto?”. Y juntan lo que ya hemos aprendido: la propiedad, el ciclo de vida, el Número de Ceros, dónde viven los datos.

Un solo negocio produce todos los tipos

En Steve Trucking, el socio minorista es un dato maestro; el vocabulario de estados son datos de referencia; cada entrega es transaccional; las definiciones de sus campos son metadatos; el informe de puntualidad a cinco años es analítico; la foto de la instalación es no estructurada; y la señal de GPS es streaming. Todo son “datos de Steve Trucking”. Nada de eso significa que pertenezcan a la misma base de datos. Ese es el cambio.

Más allá del examen: lo que cambia la IA. Para responder una sola pregunta, un agente puede necesitar un registro de cliente estructurado, una transacción reciente, un manual en PDF, una transcripción de servicio y telemetría en vivo. Los datos no estructurados y de streaming pasan a ser partes de primera clase de la arquitectura aunque no pertenezcan a la base de datos del CRM, y el arquitecto todavía tiene que saber quién es dueño de cada fuente, qué tan actual es y si el agente debería confiar en ella.

Lo que decide aquí un arquitecto

• Qué tipo de datos es cada conjunto de datos importante, y quién es su dueño.
• Si su carga de trabajo es operativa, analítica, de streaming o una mezcla.
• Qué tan rápido cambia, y qué tan rápido necesitan ver el cambio de verdad los otros sistemas.
• Cómo el volumen y el ciclo de vida determinan dónde vive y por cuánto tiempo.
• Si Salesforce debería ser su dueño, guardar una copia, referenciarlo o dejarlo en algún lugar más adecuado para la carga de trabajo.

Cuando alguien te da un requisito, no saltes a qué objeto, qué campo, qué API. Primero pregunta qué tipo de datos son, quién es su dueño, qué tan rápido cambian, qué tan grandes se vuelven, cuánto tiempo viven y qué intentamos hacer con ellos. Una cuenta, un evento de entrega, un agregado a cinco años y una fotografía pueden importarle al mismo negocio sin ser el mismo problema de arquitectura.

Explora

• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2.ª edición (2017): la referencia estándar sobre categorías de datos y gestión de datos.
• El planteamiento de Steve Trucking, sección 4 (volúmenes).