Warehouses, pipelines y las pantallas sobre las que alguien actúa.

Qué construimos

Ocho formas que suele tomar este trabajo. La mayoría de los proyectos son dos o tres a la vez.

• Warehouses y modelos semánticos

  Un único almacén alimentado de forma programada, y un modelo encima que nombra las relaciones para que la gente pueda consultarlo sin que un analista traduzca primero.

• Pipelines entre sistemas

  Ingesta, transformación y conciliación programadas, corriendo donde los datos ya viven.

• Vistas consolidadas

  Un lugar que lee de varios sistemas operativos a la vez, con cada perfil viendo su propia versión.

• Dashboards de monitoreo

  La pantalla que un equipo deja abierta, con los indicadores que de verdad cambian lo que alguien hace después.

• Movimientos de volumen y migraciones

  Mover conjuntos grandes entre sistemas sin perder filas, historial ni la posibilidad de conciliar lo que llegó.

• Interfaces de exploración

  Mapas, filtros y drill-downs para material demasiado grande o demasiado granular para leerse como tabla.

• Estructura a partir de documentos

  Clasificación y extracción de PDFs, escaneos y formularios manuscritos que nunca nacieron como datos.

• Corpus para asistentes

  La capa de recuperación desde la que responde un asistente: chunking, embeddings y permisos, antes de elegir ningún modelo.

  Qué construimos con IA

Dónde se rompe habitualmente

Todos estos proyectos empezaron con datos que la organización ya tenía. Ninguno empezó con un problema de almacenamiento.

• Está en varios sistemas

  El Banco Interamericano de Desarrollo monitorea préstamos a través de sistemas operativos que nunca se construyeron para hablarse entre sí. Smart Portfolio lee de todos ellos hacia un único conjunto de indicadores, con reglas de acceso que le dan a cada rol su propia vista de los mismos datos.

  Banco Interamericano de Desarrollo. Construido sobre .NET y SQL Server, con Azure Data Factory moviendo datos entre sistemas de forma programada.

• Dos sistemas, dos protocolos, un warehouse

  Un operador manejaba su negocio entre una plataforma core que sólo exponía SOAP y un CRM que hablaba REST. Construimos un gateway REST sobre la interfaz SOAP para que el resto del parque pudiera leerla siquiera, y después pipelines diarios hacia un warehouse y un modelo semántico, con los dashboards construidos sobre el modelo y no sobre las tablas crudas.

  Entregado sobre Microsoft Fabric, con un data engineer en el equipo.

• No está en una forma que alguien pueda leer

  India Policy Insights de Harvard contiene datos de salud y población con una granularidad que derrota a una planilla. Lo construimos como mapas interactivos, para que quien define políticas pueda comparar distritos y encontrar lo que importa sin abrir una herramienta GIS ni preguntarle antes a un analista.

  Harvard University. Datos geoespaciales de alta granularidad sobre PostgreSQL, renderizados en el navegador.

• Llega después del momento en que hacía falta

  EmpowerHealth corre varios programas de cuidado a la vez, y un reporte semanal llega tarde para cambiar lo que pasa en cualquiera de ellos. La analítica se actualiza mientras los programas corren, así que el equipo ve un programa desviándose cuando todavía hay algo que hacer al respecto.

  EmpowerHealth. Analítica en tiempo real sobre programas en paralelo, bajo HIPAA.

Para qué es el dashboard

La parte difícil de una pantalla de monitoreo no es agregar indicadores. Es decidir cuáles se ganan el espacio, y qué debería hacer que alguien haga cada uno.

• Empezamos por la decisión, no por el dato

  La primera pregunta no es qué puedes medir. Es qué se supone que alguien haga distinto cuando un número se mueve. Un indicador que no cambia el comportamiento de nadie es un costo de mantenimiento con un gráfico encima.

• Quién ve qué se resuelve antes que el esquema

  En la mayoría de este trabajo, distintos roles tienen derecho a distintas porciones de los mismos datos. Eso no es una capa de permisos agregada al final. Define cómo se construyen los indicadores, y equivocarse después significa reconstruirlos.

• El modelo va antes que la pantalla

  Un dashboard construido directo sobre las tablas de origen se rompe la primera vez que una fuente cambia. Un modelo semántico en el medio nombra las entidades y sus relaciones una vez, así las pantallas de arriba siguen siendo legibles y la próxima pregunta no necesita un pipeline nuevo.

En qué trabajamos

• Almacenamiento y modelado

  SQL Server, Azure SQL y Cosmos DB para cargas relacionales y documentales, PostgreSQL donde el resto del stack ya corre sobre él, y Azure Storage debajo. Modelos semánticos encima, para que las relaciones se nombren una vez en vez de reconstruirse por pantalla.

• Movimiento

  Azure Data Factory para transferencia y transformación programadas, e integración directa donde un sistema se puede leer en su lugar en vez de copiarlo. Gateways REST sobre interfaces heredadas cuando el sistema de origen no se puede leer de otra forma.

• La ruta unificada

  Microsoft Fabric donde la ingesta, el almacenamiento, la transformación, el análisis y la visualización deberían estar en un solo lugar y no en cinco, que es la mayoría de las veces cuando un equipo todavía no tiene una plataforma de datos.

• Lo que la gente mira

  Power BI donde un equipo ya vive ahí, y React donde las pantallas van dentro del producto en vez de al costado. GraphQL cuando una interfaz lee de varios servicios y el control de acceso tiene que vivir en la consulta.

• Entradas que todavía no son datos

  Azure Document Intelligence para PDFs, escaneos y formularios, incluidos registros manuscritos, y Word y PowerPoint generados donde la salida tiene que irse del sistema.