Arquitecto de datos: cuándo y cómo contratarlo en tu startup

Hemos comentado esta situación con varias startups: el equipo de datos saca dashboards como puede, producto pide métricas “fiables” que cambian según quién las consulte, y alguien en negocio quiere lanzar una funcionalidad con IA cuando ni siquiera está claro cuál es la fuente correcta de clientes, eventos o pricing.

‍

Ese punto confunde a muchos equipos. Piensan que les faltan más manos para construir. A menudo les falta otra cosa. Diseño.

‍

Mi opinión es simple. No contrates un arquitecto de datos porque “suena a rol maduro”. Contrátalo cuando tus problemas ya no son de ejecutar tareas, sino de decidir cómo deben encajar los sistemas, las reglas y la gobernanza antes de que el coste de seguir improvisando se vuelva permanente.

‍

El caos de datos que te avisa que necesitas ayuda

‍

He visto este patrón demasiadas veces en scaleups. Empiezas con un producto, una base de datos bien conocida por el equipo y unos cuantos procesos ETL razonables. Luego entran Mixpanel, Stripe, HubSpot, el data warehouse, varios microservicios, un CRM cambiado a mitad de camino y una capa de analítica hecha con prisas para responder a ventas, finanzas y producto.

‍

Nadie diseñó el conjunto. Se fue acumulando.

‍

Entonces llegan los síntomas. Los pipelines fallan cuando más los necesitas. Los dashboards tardan en cargar o devuelven cifras distintas para la misma pregunta. El equipo de producto quiere usar modelos o features basadas en datos, pero nadie puede garantizar de forma seria de dónde sale cada dato, quién lo transformó o si sigue siendo válido. Si tu stack ya empieza a parecerse al tipo de entornos que se suelen asociar a big data en empresas modernas, el problema no es solo volumen. Es estructura.

‍

Cuando el problema no es el equipo, sino el plano

‍

Muchos CTOs responden al caos contratando otro data engineer. A veces ayuda durante unos meses. Luego vuelve el mismo problema, solo que sobre una base más compleja.

‍

Eso pasa porque un ingeniero adicional arregla tramos de carretera. No rediseña la ciudad.

‍

Si cada nueva necesidad exige un pipeline nuevo, una excepción nueva o una definición nueva de una métrica, ya no tienes un problema de capacidad. Tienes un problema de arquitectura.

‍

La señal más clara es esta: tus mejores ingenieros pasan más tiempo conciliando sistemas, aclarando nomenclaturas y deshaciendo decisiones antiguas que construyendo cosas nuevas. Ahí ya estás pagando el precio de no tener una visión de datos coherente, aunque todavía no lo llames así.

‍

Las señales que suelen aparecer primero

‍

• Métricas inconsistentes. Marketing, producto y finanzas no usan la misma definición de cliente activo, ingreso o conversión.
• Integraciones frágiles. Cualquier cambio en una app o API rompe procesos aguas abajo.
• Dependencia personal. Solo una o dos personas entienden cómo fluye la información de punta a punta.
• Prioridades bloqueadas. IA, reporting avanzado o internacionalización se frenan porque el dato base no está ordenado.

‍

No necesitas un título rimbombante para admitirlo. Necesitas a alguien que piense la arquitectura antes de seguir echando cemento.

‍

Qué hace realmente un arquitecto de datos

‍

Tu equipo ya puede tener buenos data engineers y aun así seguir construyendo sobre arena. Ahí entra el arquitecto de datos. Su trabajo no es sacar más pipelines. Su trabajo es decidir qué datos existen de forma oficial, cómo se relacionan, dónde viven, quién puede usarlos y qué reglas evitan que el sistema se rompa cuando la empresa crece.

‍

IBM describe la arquitectura de datos como la disciplina que organiza la recopilación, transformación, distribución y consumo del dato, y la sitúa como base para analítica, operaciones e IA en su guía sobre arquitectura de datos. Esa definición sirve, pero para contratar bien conviene bajarla a tierra. En una startup o scaleup, este perfil pone orden en decisiones que ya no deberían resolverse ticket a ticket.

Su trabajo principal es fijar decisiones que otros dejan implícitas

‍

Si nadie define el modelo, el modelo aparece igual. Aparece mal, repartido entre tablas, eventos, dashboards y excepciones.

‍

Eso es lo que corrige un arquitecto de datos. Toma decisiones de diseño antes de que el equipo siga multiplicando parches:

• Modelado de datos. Define entidades, relaciones, dominios y reglas para que cliente, pedido, evento o factura signifiquen lo mismo en toda la empresa.
• Diseño de flujos e integración. Decide cómo se conectan producto, CRM, ERP, herramientas analíticas y sistemas de IA sin duplicar lógica en cada esquina.
• Gobernanza. Establece ownership, estándares, trazabilidad, calidad y políticas de acceso.
• Seguridad desde el diseño. Ordena permisos, clasificación del dato y controles antes de que llegue una auditoría o un incidente.
• Escalabilidad técnica. Elige patrones y límites para que el sistema aguante más volumen, más equipos y más casos de uso sin reescribirse cada seis meses.

‍

Su entregable es claridad operativa

‍

Un buen arquitecto de datos deja decisiones visibles. Define principios, diagramas, contratos de datos, taxonomías, criterios de calidad y límites entre sistemas. Luego acompaña a ingeniería para que eso se implemente bien.

‍

Puede revisar código. Puede participar en decisiones de plataforma. Pero si pasa el día apagando fuegos en ETL, has contratado a una persona de arquitectura para hacer trabajo de ejecución.

‍

Mi recomendación es simple. Si buscas a alguien para diseñar el mapa y además mantener toda la fontanería diaria, todavía no has separado problemas. Estás intentando ahorrar una contratación y acabarás comprando más deuda.

‍

Lo que sí cambia cuando aciertas

‍

Este rol rara vez brilla en una demo. Se nota en la velocidad real del equipo durante los siguientes trimestres.

‍

Empiezas a ver menos discusiones sobre qué métrica vale, menos integraciones frágiles, menos dependencia de dos personas que “se saben el sistema”, y menos proyectos parados porque nadie entiende de dónde sale el dato bueno. También aparece algo que los CTOs agradecen tarde. Mejor capacidad de decidir. Con una arquitectura clara, cada nuevo producto, dashboard o caso de IA se evalúa más rápido y con menos riesgo.

‍

Ese es el valor de fondo. El arquitecto de datos no añade complejidad. La recorta antes de que se vuelva estructural.

‍

Arquitecto vs Ingeniero de Datos vs MLOps

‍

La peor contratación en datos no es la cara. Es la equivocada. Si llamas “arquitecto” a alguien cuando en realidad necesitas construcción, pagas de más y avanzas lento. Si fichas un data engineer cuando el agujero es de diseño, acumulas más deuda.

‍

La separación entre arquitecto e ingeniero está bastante clara en el mercado español. ESIC resume bien esa diferencia en su comparativa sobre arquitecto de datos vs ingeniero de datos. El arquitecto se centra en diseño y planificación estratégica. El ingeniero ejecuta la construcción y optimización de pipelines y sistemas.

Un modelo mental que sí sirve

‍

Si tu organización fuera un coche de carreras, yo lo resumiría así:

• Arquitecto de datos. Diseña el chasis, la distribución del peso, las tolerancias y el plano completo.
• Ingeniero de datos. Monta el motor, conecta piezas, optimiza el flujo y se asegura de que el coche corra.
• Ingeniero MLOps. Lleva el coche a pista, despliega modelos, monitoriza comportamiento y mantiene el rendimiento en producción.

‍

Este vídeo ayuda a aterrizar esa separación en entornos técnicos reales.

‍

Qué problema resuelve cada perfil

‍

Arquitecto de datos

‍

Lo necesitas cuando la pregunta central es: “¿Cómo debería estar diseñado esto para no romperse después?”

‍

Suele entrar cuando aparecen discusiones sobre dominios, ownership, seguridad, estandarización, federación de fuentes, crecimiento internacional o integración de sistemas heredados con nuevos productos.

‍

Ingeniero de datos

‍

Lo necesitas cuando el problema es: “¿Quién construye y mantiene esto bien?”

‍

Si te falta gente que implemente ETL, ELT, orquestación, data warehouses, streaming o calidad operativa del pipeline, probablemente lo tuyo es contratar un ingeniero de datos para construir la capa de ejecución, no un arquitecto.

‍

MLOps

‍

Lo necesitas cuando el cuello de botella está en pasar modelos a producción, monitorizar deriva, versionar artefactos, automatizar entrenamiento o operar inferencia con fiabilidad. No resuelve un modelo de datos roto. No arregla taxonomías inconsistentes. No sustituye arquitectura.

‍

Cómo decidir sin liarte

‍

Hazte una sola pregunta. ¿Tu freno principal está en diseñar, en construir o en operar modelos?

‍

Si el equipo discute qué sistema manda, qué definición es la válida y cómo conectar todo sin duplicidades, necesitas diseño. Si ya sabes eso y no das abasto implementando, necesitas construcción.

‍

Muchos CTOs intentan que una sola persona cubra los tres frentes. En una startup pequeña puede pasar durante un tiempo. En una scaleup ya suele acabar mal.

‍

Cuándo contratar tu primer arquitecto de datos

‍

Mi postura es clara. La mayoría de startups lo contratan demasiado pronto o demasiado tarde.

‍

Demasiado pronto, cuando aún tienen una sola base de datos seria, un producto principal y un equipo pequeño que puede coordinarse hablando. Demasiado tarde, cuando ya han montado un puzzle de sistemas que nadie quiere rediseñar porque “ahora no hay tiempo”.

‍

UNIR recoge una duda muy real del mercado español: aunque el 41,7% de las empresas de 10 o más empleados usa análisis de big data, muchas organizaciones todavía no tienen claro si necesitan un arquitecto dedicado o si esas funciones pueden quedar dentro del equipo de ingeniería, según su análisis sobre el papel del arquitecto de datos y la duda de cuándo incorporarlo. En startups esa ambigüedad es todavía mayor.

Cuándo es overkill

‍

Si estás en alguno de estos escenarios, yo no lo contrataría todavía:

• Un solo producto y una sola fuente core de datos. No necesitas urbanismo para una cabaña.
• Equipo técnico muy pequeño. Si aún no tienes una función de datos mínimamente estable, primero cubre ejecución.
• Prioridad inmediata de entrega. Cuando lo urgente es montar reporting básico o un pipeline inicial, un perfil de arquitectura dedicado puede quedar infrautilizado.
• Decisiones aún reversibles. Si casi todo está por construir y el coste de cambiar stack o modelo sigue siendo bajo, puedes sobrevivir con liderazgo técnico fuerte y algo de asesoría puntual.

‍

Cuándo ya vas tarde

‍

Aquí sí me pondría serio. Contrata o, como mínimo, asigna esa responsabilidad de forma explícita si ves varias de estas señales juntas.

‍

Tus sistemas core ya no se hablan bien

‍

Cuando conviven producto, CRM, billing, soporte, marketing y analítica con definiciones distintas y reconciliaciones manuales, ya no basta con “mejor documentación”. Alguien tiene que decidir modelo, integraciones y ownership.

‍

BI y producto discuten la fuente de verdad

‍

Este es un clásico. Una métrica sale de un dashboard, otra del warehouse, otra de la base transaccional. Si eso ocurre de forma recurrente, estás dañando velocidad y confianza interna al mismo tiempo.

‍

Quieres lanzar IA sobre cimientos poco fiables

‍

Muchos equipos quieren acelerar con LLMs, scoring o automatización cuando todavía no dominan lineage, permisos o calidad de atributos. Mala idea. Un caso de uso de IA sobre datos mal definidos solo produce decisiones más rápidas, no mejores.

‍

Mi consejo directo: no pongas a un equipo de ML a compensar con feature engineering una arquitectura de datos desordenada. Es caro y suele acabar en frustración.

‍

La regulación ya importa de verdad

‍

Cuando GDPR, políticas de acceso, segregación de entornos o auditoría empiezan a tocar procesos críticos, la improvisación sale muy cara. El arquitecto de datos no sustituye a seguridad ni legal, pero sí incorpora esas exigencias al diseño desde el principio.

‍

Vas a cambiar de escala de negocio

‍

Expansión internacional, nuevas líneas de producto, adquisiciones o migraciones grandes suelen romper diseños válidos para una etapa anterior. Ahí el rol deja de ser opcional y pasa a ser palanca.

‍

Un marco simple para decidir

‍

Yo usaría este filtro en comité de dirección técnico:

1. ¿Tenemos más de un dominio de negocio importante compartiendo datos?
   Si la respuesta es sí, la arquitectura empieza a importar mucho más.
2. ¿Las decisiones de datos ya afectan producto, finanzas y compliance al mismo tiempo?
   Si sí, no basta con resolverlo por tickets sueltos.
3. ¿El coste de rediseñar después sería alto?
   Si migrar, unificar o reetiquetar dentro de unos meses va a doler mucho, anticipa el diseño.
4. ¿Nadie es dueño de los principios?
   Si todo el mundo construye pero nadie define estándares, el vacío ya existe.

‍

No hace falta que el primer paso sea una contratación full time. A veces sirve una fase intermedia con un líder de arquitectura part time o una responsabilidad muy clara en un principal engineer. Pero si el problema ya es sistémico, retrasar la decisión solo encarece la siguiente.

‍

Cómo contratar y evaluar a un arquitecto de datos

‍

Este rol se entrevista fatal en muchas startups. Les pasan un test de SQL, les preguntan por Spark, Hadoop o Kafka, y luego se sorprenden cuando fichan a alguien muy técnico que no sabe alinear arquitectura con negocio.

‍

Error de base. No estás contratando solo conocimiento de stack. Estás contratando criterio.

‍

Qué debe conocer de verdad

‍

En España, los requisitos técnicos más recurrentes para este perfil incluyen modelado de datos, SQL/NoSQL, ETL, Python, Java, Scala y plataformas de big data como Hadoop, Spark y Kafka, además de seguridad y cloud, según el análisis de ISDI recogido por INESDI sobre qué hace un arquitecto de datos y qué stack suele dominar.

‍

Eso no significa que debas escribir una vacante con veinte herramientas y pedir experiencia profunda en todas. Evalúa por dominios:

• Diseño de modelos. ¿Sabe estructurar entidades, eventos, dominios y relaciones?
• Integración. ¿Ha unido sistemas heterogéneos sin multiplicar deuda?
• Procesamiento. ¿Entiende batch, streaming, ETL y ELT lo suficiente para decidir bien?
• Gobernanza y seguridad. ¿Piensa en acceso, calidad, trazabilidad y cumplimiento?
• Cloud y escalabilidad. ¿Ha trabajado con arquitecturas que crecen sin reescribirse cada trimestre?

‍

Cómo entrevistarlo sin perderte en buzzwords

‍

Usa entrevistas basadas en decisiones, no en definiciones. Si quieres profundidad real, apóyate en un enfoque de entrevistas por competencias para perfiles técnicos y llévalo a escenarios concretos.

‍

Preguntas que sí separan a un buen candidato de uno decorativo:

• Cuéntame una arquitectura de datos que hoy diseñarías de otra forma. ¿Qué falló y qué aprendiste?
• Te damos nuestro stack actual y nuestros objetivos de negocio a dos años. Dibuja cómo evolucionarías la arquitectura.
• ¿Dónde pondrías las fronteras entre data engineering, analítica y ownership de dominios?
• ¿Cómo resolverías el conflicto entre acceso amplio al dato y control sobre información sensible?
• ¿Qué decisiones dejarías abiertas y cuáles cerrarías ya?
• ¿Cómo evitarías que una adquisición o un nuevo producto dupliquen entidades críticas?

‍

Qué buscar en las respuestas

‍

No busques la herramienta perfecta. Busca estas señales:

• explica trade-offs sin postureo
• baja a ejemplos concretos
• distingue claramente diseño de implementación
• habla con naturalidad de negocio, no solo de sistemas
• sabe decir “esto aún no lo cerraría” cuando corresponde

‍

Red flags claras

‍

• responde todo con nombres de productos y ningún principio
• quiere rehacerlo todo desde cero
• desprecia constraints de negocio o plazos
• no sabe articular gobernanza, seguridad o ownership
• confunde ser senior con opinar fuerte sobre cualquier tecnología

‍

Un buen arquitecto de datos mejora decisiones. Un mal arquitecto produce diagramas bonitos que el equipo ignora a la segunda semana.

‍

Presupuesto y encaje real

‍

Ve con presupuesto serio o no abras la búsqueda. En España, el mercado sitúa este perfil alrededor de 70.000 € y con frecuencia en la banda de 69.000 a 74.000 € para perfiles senior, tal como recoge INESDI en la referencia anterior. Si intentas ficharlo como si fuera un mid-level “con algo de diseño”, atraerás perfiles híbridos útiles, sí, pero probablemente no al tipo de persona que ordena una arquitectura compleja.

‍

Mi recomendación práctica:

• define primero el problema arquitectónico
• delimita qué parte seguirá haciendo el equipo de ingeniería
• evita una JD enciclopédica
• involucra a CTO, data lead y alguien de negocio en la entrevista final
• pide un ejercicio de arquitectura con tu caso, no un take-home genérico

‍

Ejemplo de Job Description para Arquitecto de Datos

‍

Una buena JD para arquitecto de datos no vende “tecnología puntera”. Vende un problema complejo y relevante. El candidato senior quiere saber qué tiene que arreglar, qué autoridad tendrá y cuánto apoyo real recibirá.

Puedes adaptar esta plantilla:

Tu misión

‍

Diseñar y evolucionar la arquitectura de datos de la compañía para asegurar que producto, analítica e iniciativas de IA trabajen sobre una base escalable, segura y coherente.
[Personaliza aquí el contexto real. Integración post-adquisición, crecimiento multi-país, gobierno del dato, etc.]

‍

Retos en 3, 6 y 12 meses

‍

• Primeros meses. Mapear sistemas, detectar deuda crítica y definir principios de arquitectura.
• Siguiente fase. Alinear modelo de datos, ownership y estándares con ingeniería, producto y negocio.
• Después. Dejar una hoja de ruta ejecutable para escalabilidad, seguridad y consumo analítico.

‍

Responsabilidades

‍

• Diseñar modelos de datos y principios de integración entre sistemas.
• Definir estándares de gobernanza, calidad, seguridad y acceso.
• Colaborar con data engineers, analistas, ML engineers y líderes de producto.
• Revisar decisiones técnicas de alto impacto.
• Priorizar deuda arquitectónica según impacto de negocio.

‍

Imprescindibles

‍

• Experiencia diseñando arquitecturas de datos en entornos complejos.
• Solidez en modelado, integración y escalabilidad.
• Capacidad para traducir objetivos de negocio a decisiones de arquitectura.
• Criterio para trabajar con equipos multifuncionales.

‍

Deseables

‍

• Experiencia en sectores regulados.
• Haber participado en migraciones, unificaciones de sistemas o despliegues internacionales.
• Contexto previo en startups o scaleups.

‍

Lo que yo añadiría siempre

‍

Incluye quién decide qué. Si no aclaras autoridad, el puesto nace roto. También aclara qué no llevará esta persona. Si va a diseñar arquitectura, no debería acabar absorbida por tickets operativos diarios.

‍

Si estás valorando incorporar tu primer arquitecto de datos, o quieres contrastar si realmente necesitas ese rol o uno más cercano a data engineering o MLOps, en Kulturo ayudamos a CTOs y founders a definir el perfil correcto y a contratarlo sin perder meses en búsquedas mal planteadas.