La arquitectura de datos para pymes no es un término reservado para empresas con departamentos de ingeniería. Es el nombre que le damos a algo muy concreto: decidir dónde viven tus datos, quién los actualiza y cómo hablan entre sí para que las decisiones no dependan de que alguien sepa dónde está el Excel correcto.
Este artículo está orientado a directores y responsables de operaciones en empresas de 10 a 100 personas que tienen datos dispersos en varios sistemas y no pueden tomar decisiones ágiles con ellos. No necesitas equipo de datos para leerlo ni para aplicarlo.
El problema que nadie nombra bien
Ficticia SaaS factura 2,3 millones de euros al año. Tienen HubSpot con tres años de historial de clientes, Stripe con cada transacción registrada desde el primer día y un Google Sheet que el responsable comercial actualiza cada lunes con las previsiones del trimestre. No les faltan datos.
Lo que les falta es poder responder a tres preguntas antes del lunes por la mañana: ¿qué canal de adquisición les da más margen neto, no solo más volumen? ¿Qué clientes de los que firmaron este trimestre tienen más probabilidad de renovar? ¿Cuánto cuesta realmente captar a un cliente de cada segmento?
Tres preguntas razonables. Pero sin una arquitectura que conecte esas tres fuentes, responderlas requiere dos horas de exportaciones manuales, un VLOOKUP que siempre falla en alguna fila y una conversación incómoda sobre si los números del CRM y los de Stripe cuadran o no.
Analogía
Imagina que tienes tres contables, cada uno con su propia caja registradora, y al final del mes intentas cuadrar el balance hablando con los tres por separado. Los datos están. La arquitectura no.
El problema no es la cantidad de datos que tienes. Es que nunca has decidido dónde viven, quién los actualiza y cómo hablan entre sí. Eso es exactamente lo que resuelve una arquitectura de datos, y no necesitas un equipo de cinco ingenieros para montarla.
Por qué fallan las soluciones habituales
Cuando una empresa llega a este punto, suele tomar uno de tres caminos. Los tres tienen el mismo problema de fondo: resuelven en el lugar equivocado.
Contratan un analista de datos
El analista llega, ve el estado de los datos y pasa los primeros dos meses limpiando. Para cuando tiene algo útil, el contexto ha cambiado y la dirección ya no recuerda para qué lo contrató. Sin arquitectura previa, el analista construye sobre arena.
Compran un BI caro
Tableau, Power BI, Qlik. Herramientas potentes conectadas a datos sin estructura. El resultado: dashboards que muestran las métricas equivocadas de forma muy bonita. Nadie los usa pasadas seis semanas.
Montan un data warehouse «de verdad»
Llaman a una consultora. Propuesta de 80.000€, arquitectura para escalar a 100 millones de registros, proyecto de ocho meses. Para una empresa de 20 personas con 500.000 filas de datos, es matar moscas a cañonazos.
El error común
En los tres casos, el problema no es la herramienta elegida. Es haber saltado a la solución sin definir primero qué preguntas necesitas responder y cuál es la fuente de verdad de cada dato.
La arquitectura de datos no empieza por el software. Empieza por un documento de una página donde defines tres cosas: qué preguntas tiene que responder el sistema, de dónde viene cada dato y quién es el responsable de mantenerlo actualizado. Todo lo demás viene después.
La arquitectura mínima viable de datos
No necesitas un data lake. No necesitas Kafka ni Spark. Necesitas que tres capas funcionen bien, que cada una tenga una responsabilidad clara y que no intenten hacer el trabajo de las otras dos.
Las tres capas de la arquitectura mínima viable. Cada capa tiene una sola responsabilidad.
Capa 1 — Ingesta: mueve datos desde sus fuentes originales hasta un lugar centralizado. No transforma nada, no interpreta nada. Solo transporta. Herramientas como Airbyte o Fivetran hacen esto con conectores preconfigurados para los 200 sistemas más habituales.
Capa 2 — Almacenamiento y transformación: aquí viven los datos en bruto y también las versiones limpias, tipadas y con las métricas calculadas. BigQuery para quien ya está en Google Cloud; DuckDB si quieres empezar en local sin coste. dbt gestiona las transformaciones como código versionable, no como scripts sueltos en carpetas.
Capa 3 — Consumo: donde el dato se convierte en decisión. Un dashboard en Metabase o Looker Studio que cualquier persona del equipo puede leer sin saber SQL. O una alerta automática que llega al correo cuando una métrica sale del rango esperado.
El principio clave
Cada capa hace una cosa y solo una. Ingesta no transforma. Transformación no visualiza. Consumo no almacena. Cuando una capa intenta hacer el trabajo de las otras dos es cuando los proyectos de datos se vuelven imposibles de mantener.
Caso práctico: Ficticia SaaS en 4 semanas
Ficticia SaaS: empresa B2B de gestión de proyectos, 18 personas, 340 clientes activos, tres fuentes de datos que nunca han hablado entre sí. Las tres preguntas que no podían responder: margen neto por canal de adquisición, probabilidad de renovación por segmento y coste real de captación por tipo de contrato.
Semana 1 — Definición y mapeo
Antes de tocar ninguna herramienta: documento de una página con las tres preguntas de negocio, el campo exacto de cada sistema que las responde y quién es el propietario de cada dato. HubSpot: deal.source, deal.amount. Stripe: invoice.status, subscription.plan. Sheet: márgenes por tipo de contrato.
Semana 2 — Ingesta
Airbyte instalado en una VM de 20€/mes en Google Cloud. Conectores de HubSpot y Stripe configurados en dos horas, sincronización incremental cada 6 horas. El Google Sheet se carga con un script Python usando gspread. Todo aterriza en BigQuery en esquemas separados: raw_hubspot, raw_stripe, raw_sheets.
Semana 3 — Transformación
dbt construye tres modelos: dim_customers (cliente unificado con atributos de HubSpot y Stripe), fct_revenue (ingresos con margen calculado cruzando Stripe y el Sheet), fct_renewals (historial de renovaciones con tasa por segmento). Cada modelo tiene tests automáticos de unicidad y nulos. Si un campo rompe, el pipeline lo sabe antes de que lo note el equipo.
Semana 4 — Consumo
Metabase conectado a BigQuery. Tres dashboards, uno por pregunta de negocio. Cada lunes a las 7:00 el responsable de ventas recibe un email automático con el resumen de la semana generado desde los mismos modelos dbt. El Google Sheet sigue existiendo — pero ahora es solo un formulario de entrada, no la fuente de verdad.
Tiempo hasta primer dashboard
4 sem.
Desde cero, sin equipo de datos
Coste mensual del stack
~190€
VM + BigQuery + Metabase OSS
Preguntas desbloqueadas
3
Las que justificaron todo el proyecto
Horas manuales ahorradas
~6h/sem
Exports, VLOOKUPs y conciliaciones
El stack según el tamaño de tu empresa
No existe un stack universal. La elección correcta depende de cuántos datos mueves, cuánto puedes gastar y si tienes alguien que pueda mantenerlo o necesitas que se mantenga solo.
Criterio de decisión
Si puedes empezar con DuckDB y Looker Studio, empieza ahí. Migrarlo hacia arriba cuando crezcas es trivial. Empezar con Snowflake cuando no lo necesitas es costoso y te atrapa en contratos. Escala el stack cuando el stack actual deje de ser suficiente, no antes.
Los 3 errores que lo convierten en un proyecto de 6 meses
Error 1 — Modelar sin preguntas definidas
Construir tablas en dbt antes de saber qué preguntas tienen que responder. El resultado es un warehouse técnicamente perfecto que nadie usa. La arquitectura debe derivarse de las preguntas, no al revés.
Error 2 — Limpiar los datos antes de ingestarlos
El instinto natural es limpiar primero. El problema es que si el dato cambia en origen, tienes que repetir toda la limpieza. Ingestar siempre en bruto, limpiar en la capa de transformación con dbt. El dato en bruto es sagrado.
Error 3 — Un solo responsable que no documenta
La arquitectura más robusta técnicamente colapsa en el momento en que esa persona se va de vacaciones dos semanas. Cada modelo dbt debe tener una descripción legible por alguien sin contexto técnico. La documentación no es opcional — es parte de la arquitectura.
¿Por dónde empezar?
Antes de elegir ninguna herramienta, dedica dos horas a escribir un documento con tres columnas: la pregunta de negocio, el sistema donde vive el dato que la responde y el campo exacto dentro de ese sistema. Si no puedes rellenar esa tabla, la arquitectura puede esperar — primero necesitas saber qué quieres medir.
Si puedes rellenarla, el siguiente paso es montar la ingesta con Airbyte y BigQuery, donde el 80% del esfuerzo tiene sentido concentrarse. Las transformaciones en dbt y la visualización en Metabase vienen después, cuando ya tienes los datos en un sitio centralizado y limpio.
Framework de decisión — ¿cuál es tu punto de partida?
¿Puedes listar las 3 preguntas que el sistema debe responder?
No → Para aquí. Empieza por el documento de una página antes de tocar ninguna herramienta.
¿Tienes menos de 50.000 filas nuevas al día?
Sí → DuckDB + dbt Core + Looker Studio. Coste cero, operativo en una semana.
¿Tus fuentes tienen conector en Airbyte o Fivetran?
Sí → Úsalos. No construyas conectores propios hasta que no quede otro remedio.
¿Alguien del equipo puede mantener el stack?
No → Prioriza las versiones cloud gestionadas. El coste adicional es menor que el coste de que nadie lo mantenga.
¿Ya tienes stack y nadie lo usa?
Sí → El problema no es técnico. Revisa si las preguntas que responde son las que el equipo necesita responder.
¿Cuántas decisiones importantes de tu empresa siguen dependiendo de alguien que sabe dónde está el dato, en lugar de un sistema que lo entrega solo? Ahí está el coste real de no tener arquitectura.
¿Te ha resultado útil?
¿Tienes un problema que
los datos podrían resolver?
Sin formularios largos. Una conversación de 30 minutos para ver si tiene sentido.
Hablamos