Arquitectura de datos · en detalle
Proceso, entregables, precios y cuándo lo necesitas de verdad.
Antes de que nadie escriba un pipeline, alguien tiene que decidir dónde va a vivir el dato, cómo fluye y quién paga el almacenamiento. Este es el trabajo que evita que la deuda técnica se acumule más rápido que el valor que extraes.
Proceso paso a paso
El trabajo de arquitectura sigue una secuencia fija.
No puedes diseñar el almacenamiento antes de saber qué preguntas hace el negocio. No puedes elegir herramientas antes de haber mapeado las fuentes existentes.
Inventario y recogida de requisitos
Entrevistamos a los stakeholders de finanzas, operaciones y TI. Documentamos cada fuente de datos en uso actualmente — ERP, CRM, hojas de cálculo, APIs externas. Mapeamos qué informes lee realmente la gente y en qué KPI confían. Esto no va de lo que los datos podrían hacer. Va de lo que el negocio necesita que hagan el próximo trimestre.
Entregable: mapa del estado actual mostrando cada sistema, su función y quién depende de él.
Diseño de la arquitectura
A partir del inventario, diseñamos el estado objetivo. Elegimos entre plataformas cloud (Azure, AWS, GCP), decidimos entre lakehouse o warehouse, definimos las zonas de datos (raw, curated, gold) y especificamos los patrones de control de acceso. Modelamos las entidades clave — cliente, producto, transacción — y definimos cómo se relacionan. Cada decisión queda documentada con su razón.
Entregable: diagrama de la arquitectura objetivo con capas, elección de herramientas y estimación de coste por componente.
Secuencia de construcción y gobierno
Creamos un plan de implementación por fases: qué pipelines se construyen primero, cuándo migra cada informe, qué corre en paralelo. Definimos convenciones de nomenclatura, estructuras de carpetas y patrones de despliegue. Especificamos quién aprueba los cambios de esquema y cómo se monitoriza la calidad del dato. Este es el plano que seguirá ingeniería durante los siguientes 6-12 meses.
Entregable: roadmap de implementación con fases, dependencias y reglas de gobierno.
Registro de decisiones y revisión
A lo largo del proyecto mantenemos un registro de las opciones descartadas: por qué no elegimos Snowflake, por qué no usamos patrones de data mesh, por qué ciertas fuentes se quedan fuera de la plataforma. Esto evita que equipos futuros reabran decisiones ya tomadas. Al final, presentamos el paquete completo y hacemos una sesión de revisión técnica con tu equipo de TI.
Entregable: registro de decisiones con el razonamiento de cada elección importante, más una sesión de entrega.
Entregables detallados
Qué recibes realmente
Son documentos de trabajo, no presentaciones. Los equipos de ingeniería los usan para escribir pipelines. Finanzas los usa para prever el gasto en cloud. TI los usa para configurar permisos.
Mapa del estado actual
Un diagrama con cada sistema que actualmente guarda datos del negocio: ERP, CRM, hojas de cálculo, bases de datos legadas, herramientas SaaS. Cada nodo incluye el responsable del dato, la frecuencia de actualización y qué procesos de negocio dependen de él. No es decorativo — es la base para planificar la migración. Si una fuente no está en este mapa, no existe en la arquitectura objetivo.
Diagrama de la arquitectura objetivo
Un diseño por capas que muestra la zona de ingesta, las capas de transformación y los puntos de consumo. Especifica la plataforma cloud (Azure Data Lake, Databricks, Snowflake), define las capas medallion (bronze/silver/gold o equivalente) y traza el flujo de datos desde el origen hasta el dashboard. Incluye el equilibrio entre cómputo y almacenamiento y el coste mensual estimado por capa. Esto es lo que le enseñas al CFO cuando pregunta a dónde va la factura de cloud.
Roadmap de la secuencia de construcción
Un plan estilo Gantt que muestra en qué orden se construye cada pipeline, con sus dependencias. Especifica quick wins (informes que pueden salir en producción en 4 semanas) frente a trabajo estructural (modelos dimensionales que tardan 3 meses). Cada fase incluye el valor de negocio esperado — así es como justificas la inversión continuada cuando el CTO pregunta si el proyecto va bien.
Registro de decisiones y opciones descartadas
Un registro escrito de las decisiones de arquitectura: por qué elegimos Databricks sobre Snowflake, por qué usamos tablas delta en vez de parquet, por qué ciertas fuentes se quedan en el sistema antiguo. Incluye el compromiso de cada decisión y las condiciones bajo las que la revertirías. Esto evita que las nuevas incorporaciones propongan soluciones que ya evaluaste y descartaste por buenas razones.
Gobierno y estándares de nomenclatura
Reglas sobre cómo se nombran las tablas, cómo se versionan los esquemas, quién aprueba los cambios que rompen compatibilidad y cómo se enrutan las alertas de calidad del dato. Incluye estructuras de carpetas en el data lake, convenciones de etiquetado para el reparto de costes y patrones de control de acceso (RBAC vs ABAC). Sin esto, cada equipo crea sus propias convenciones y acabas con cinco esquemas de nomenclatura distintos seis meses después.
Modelo de coste y disparadores de escalado
Una hoja de cálculo con el coste mensual proyectado por componente al volumen de datos actual, más los umbrales de escalado. Especifica cuándo pasar de serverless a clusters aprovisionados, cuándo añadir más almacenamiento y qué pasa con la factura si el volumen de datos se duplica. Esto permite a finanzas planificar presupuestos y a TI saber cuándo renegociar contratos.
Caso relacionado
Industrial: data warehouse de SAP sobre Databricks
Un cliente industrial necesitaba una plataforma de datos escalable para sustituir el reporting manual. Diseñamos una arquitectura medallion sobre Databricks con ingesta automatizada de la capa Bronze desde tablas de SAP ECC, pipelines de CI/CD multientorno para dev/test/prod, y patrones de gobierno que permitieron a su equipo colaborar sin romper producción — convirtiendo meses de planificación en una arquitectura funcionando en 4 semanas.
Leer el caso completo →Precios y qué los afecta
Contexto de precios transparente
Proyecto base de arquitectura
€45/hora
Estimado 120–160 horas · 3–4 semanas
Qué hace que el precio suba
- Número de sistemas origen: integrar 15 fuentes de datos lleva más tiempo que integrar 5. Cada sistema requiere análisis de extracción, revisión de la documentación de la API y mapeo de esquema.
- Requisitos normativos: el cumplimiento de RGPD, SOC2 o auditorías específicas del sector añaden capas de gobierno. Necesitamos definir políticas de retención de datos, reglas de anonimización y registros de acceso.
- Despliegue multirregión: si los datos tienen que vivir en regiones de la UE y EE. UU. simultáneamente, la complejidad de la arquitectura se duplica. Definimos patrones de replicación, SLA de latencia y reparto de costes por región.
- Complejidad de migración de sistemas legados: migrar desde un SQL Server on-premise de 15 años con tablas sin documentar requiere ingeniería inversa. Reservamos tiempo para el perfilado de datos y para descubrir la lógica de transformación.
Qué mantiene el precio bajo
- Proyectos desde cero: si empiezas de cero sin sistemas legados, no hay análisis de migración. Diseñamos el estado objetivo directamente.
- Una sola plataforma cloud: diseñar solo para Azure es más rápido que un híbrido AWS+GCP. Sin redes entre nubes ni federación IAM.
- Herramientas estándar: usar Databricks + Delta Lake (patrones ampliamente documentados) es más rápido que stacks open-source a medida que requieren un diseño a la carta.
- Requisitos claros: si los stakeholders del negocio ya saben qué KPI necesitan y en qué informes confían, nos saltamos el descubrimiento y vamos directos al diseño.
Refuerzo de equipo
€42,5/hora
Un arquitecto integrado en tu equipo durante 6+ meses
Asesoría continua
€45/hora
Revisiones de arquitectura trimestrales
Preguntas
Preguntas frecuentes: arquitectura de datos
¿Necesito un arquitecto si solo uso Power BI sobre un fichero Excel?
No. Si tus datos caben en Excel y Power BI funciona bien, no tienes un problema de arquitectura. Tienes un problema de reporting, que se resuelve con trabajo de BI. La arquitectura se vuelve necesaria cuando el volumen de datos supera lo que Excel puede manejar, cuando varios equipos necesitan acceso simultáneo, o cuando el cumplimiento normativo exige trazabilidad de auditoría y control de acceso.
¿Cómo sé si debo construir en Azure, AWS o GCP?
Si ya usas Microsoft 365 y tienes un acuerdo empresarial, Azure suele salir más barato por el licenciamiento agrupado. Si tu equipo de TI tiene mucha experiencia en AWS, AWS evita costes de reciclaje. Si necesitas herramientas de ML específicas que solo existen en GCP (como BigQuery ML), eso decide la elección. Evaluamos los contratos existentes, las habilidades del equipo y los requisitos de herramientas — no hay una respuesta universal.
¿Cuál es la diferencia entre un data lake, un data warehouse y un lakehouse?
Un data lake guarda ficheros en bruto (CSV, JSON, parquet) en almacenamiento cloud. Es barato y flexible pero requiere trabajo de ingeniería para consultarlo. Un data warehouse (Snowflake, Synapse) guarda tablas estructuradas optimizadas para consultas SQL. Es rápido para BI pero caro a gran escala. Un lakehouse (Databricks, Fabric) combina ambos: almacenamiento de ficheros en bruto con el rendimiento de consulta SQL. Para la mayoría de proyectos modernos, el lakehouse es la opción por defecto salvo que tengas una razón concreta para separarlos.
Siguientes pasos
El trabajo de arquitectura va primero.
Si estás decidiendo entre plataformas cloud o necesitas mapear tu panorama de datos actual antes de construir pipelines, aquí es donde empiezas.
O vuelve a todos los servicios