Cuando digo que soy arquitecto de datos, la siguiente pregunta casi siempre es la misma, y no me extraña: es un título que suena técnico pero que en la práctica describe algo bastante concreto. ¿Y eso qué es exactamente? Es un rol que se confunde con facilidad con el de analista, el de ingeniero de datos o el de consultor de BI, y sin embargo cada uno resuelve un problema distinto dentro de la misma cadena. Un arquitecto de datos diseña el mapa completo: de dónde sale la información, cómo se transforma, dónde se guarda y quién puede tocarla.
La diferencia entre diseñar y construir
Un arquitecto de datos decide la forma del sistema antes de que se construya una sola tabla: qué plataforma se usa, qué arquitectura de capas sigue el dato (por ejemplo, Medallion), cómo se modela para que las consultas sean rápidas y cómo se gobierna el acceso. El ingeniero de datos, en cambio, construye y mantiene los procesos que hacen realidad ese diseño: los pipelines, las transformaciones, la infraestructura. En equipos pequeños una misma persona hace ambas cosas; en organizaciones más grandes son roles separados que trabajan sobre el mismo plano.
Arquitecto de datos vs. arquitecto BI
Un arquitecto BI suele centrarse en la capa de consumo: cómo se estructuran los informes, qué modelo semántico usan las herramientas de visualización, cómo se organiza el catálogo de dashboards. Este otro perfil trabaja una capa más abajo, diseñando todo lo que sostiene esa capa de consumo: el data warehouse, los pipelines de ingesta, el modelado en estrella. En la práctica, ambos roles se solapan mucho —yo mismo trabajo en las dos capas—, pero la diferencia conceptual importa a la hora de contratar: si el problema es ‘los informes no cuadran’, puede que el fallo esté más abajo, en la arquitectura del dato, no en el dashboard.
Qué NO hace este rol, aunque a veces se confunda
No es lo mismo diseñar la arquitectura que analizar los datos para sacar conclusiones de negocio: eso último es trabajo de un analista o de un científico de datos, que consume la estructura ya construida para responder preguntas concretas. Tampoco es un rol de soporte técnico del día a día de las herramientas de visualización, aunque a veces se le pida resolver ese tipo de incidencias menores. Separar bien estas funciones evita contratar a la persona equivocada para el problema que realmente hay que resolver, que suele estar más en la base del sistema que en la superficie donde se ven los informes.
Qué hago en un día normal como arquitecto de datos
En mi puesto actual en Logicalis Spain trabajo dentro de un proyecto de gobierno de Power BI: gestión del ciclo de vida del dato, control de accesos y de las fuentes conectadas. Fuera de ahí, me he especializado en arquitecturas end-to-end sobre Microsoft Fabric: arquitectura Medallion, modelado en estrella, DAX y orquestación de pipelines. Ese trabajo me llevó a certificarme como Microsoft Fabric Analytics Engineer Associate en noviembre de 2025.
Las decisiones que toma un arquitecto de datos
- Qué plataforma de datos usar (Microsoft Fabric, Snowflake, un data warehouse tradicional) según el volumen y el presupuesto.
- Cómo estructurar las capas del dato para que cada transformación sea trazable y auditable.
- Qué modelo de datos usar para que las consultas de negocio sean rápidas sin duplicar información innecesariamente.
- Cómo se gestionan los accesos, para que el gobierno del dato no dependa de la memoria de una sola persona.
Qué preguntar antes de contratar a un arquitecto de datos
Si estás evaluando incorporar a un arquitecto de datos, hay tres preguntas que ayudan a separar experiencia real de conocimiento teórico: ¿qué arquitectura de capas usa por defecto y por qué?, ¿cómo garantiza que un cambio en el origen de datos no rompa silenciosamente los informes finales?, y ¿cómo documenta las decisiones de modelado para que otra persona pueda continuar el trabajo sin depender de que se lo expliquen de viva voz? Un arquitecto de datos que no puede responder con claridad a esas tres preguntas probablemente todavía no ha sostenido una arquitectura en producción el tiempo suficiente.
Herramientas con las que trabaja habitualmente un arquitecto de datos
Más allá de Microsoft Fabric, un arquitecto de datos suele moverse entre varias capas de herramientas: plataformas de almacenamiento (Fabric, Snowflake, un data warehouse clásico), lenguajes de transformación (SQL, DAX, Python) y herramientas de orquestación de pipelines. Ninguna herramienta sustituye el criterio de diseño: son instrumentos para ejecutar una arquitectura ya pensada, no un sustituto de pensarla. Por eso, cuando reviso un proyecto nuevo, empiezo siempre por el mapa del dato, no por el catálogo de software disponible.
Por qué este rol importa antes de contratar herramientas
Es habitual que una empresa compre primero la licencia de una herramienta de visualización y descubra después que no tiene una base de datos ordenada sobre la que construir nada útil. Un arquitecto de datos evita ese orden invertido: primero se diseña cómo va a fluir el dato de principio a fin, y solo después se decide con qué herramienta se visualiza. Es la misma lógica que sigo cuando trabajo por proyecto o por horas, como cuento en la página de inicio.
Formación y trayectoria: cómo se llega a este rol
No hay un único camino. En mi caso pasé por Open Canarias, Plexus Tech y ATK, y trabajé por mi cuenta en Venezuela con Tecnológica Innoven IT, antes de especializarme en arquitecturas de datos sobre Microsoft Fabric. Soy licenciado en Business Administration por la Universidad Alejandro de Humboldt, una formación que ayuda más de lo que parece: quien diseña este tipo de sistemas no solo los hace técnicamente correctos, los diseña para que respondan a decisiones de negocio reales, no solo a un requisito técnico aislado.
Escribo desde Santa Cruz de Tenerife y trabajo en remoto para toda España. Si tienes un sistema de datos que necesita ese tipo de mirada —parte técnica y parte negocio a la vez—, puedes revisar otros artículos del blog o escribirme directamente para hablar de tu caso concreto.