Currículum de arquitecto/a de datos: ejemplos y guía para redactarlo

Este currículum es de un arquitecto que llegó al puesto desde el desarrollo de bases de datos y la ingeniería de datos. Fíjate en la estructura: primero el tamaño del ecosistema, después las decisiones de diseño que asumió y, por último, los resultados de coste y calidad. La persona y las empresas son inventadas; las cifras son del tipo que puedes sacar de la consola del almacén de datos, del catálogo y del registro de incidencias.

Arquitecto/a es un puesto de decisiones. La criba consiste en ver si tus decisiones se han puesto a prueba con usuarios reales, volumen real y un presupuesto real.

• El tamaño del ecosistema. Sistemas origen integrados, volumen de datos, número de equipos consumidores o de informes que dependen de ti. Es lo que distingue a quien diseña para una startup de 30 personas de quien lo hace para una aseguradora de 5.000.
• La profundidad del modelado. Qué enfoque de modelado usas y por qué, y si te has enfrentado a lo difícil: seguimiento del histórico, datos que llegan tarde, dimensiones conformadas entre unidades de negocio, datos maestros.
• La plataforma. Snowflake, Databricks, BigQuery, Redshift, Microsoft Fabric o un stack on-premise. Las empresas contratan para lo que tienen en marcha.
• Gobierno del dato y coste. Son las dos razones por las que una empresa crea un puesto de arquitecto/a. Muestra trabajo de clasificación, diseño de accesos y linaje, y demuestra que has controlado el gasto.
• Si dejas las cosas por escrito. Arquitecturas de referencia, registros de decisiones, estándares y revisiones de diseño. Quien solo lo explica de palabra no llega más allá de un equipo.

“Para mí lo deciden dos preguntas. ¿Qué decidiste que luego tuvieron que asumir otras personas, y cuánto costó o ahorró? Cualquiera puede poner Snowflake y dbt. Enséñame una decisión de modelado que defendiste en una revisión de diseño y qué pasó dieciocho meses después.”

Estos títulos se solapan tanto que mucha gente busca los tres a la vez. Cada empresa los usa de una manera, así que lee las funciones de la oferta y no solo el título, y empieza por lo que encaje.

El modelado es la parte del trabajo que ningún pipeline sustituye, y es donde más flojean la mayoría de currículums de arquitectura. Concreta al máximo los problemas de diseño que has resuelto.

• El enfoque que usas y el motivo. Modelos dimensionales para reporting, diseño normalizado para almacenes operacionales, Data Vault cuando los sistemas origen cambian sin parar. Explica por qué lo elegiste en esa empresa.
• Gestión del histórico: cómo registras los cambios a lo largo del tiempo y qué pasa con un registro que llega tarde o fuera de orden.
• Dimensiones conformadas: cómo conseguiste que dos unidades de negocio se pusieran de acuerdo en qué es un cliente. Es un logro tanto político como técnico, y transmite seniority.
• Decisiones de granularidad: a qué nivel modelaste una tabla de hechos y a qué renunciaste.
• Capa semántica y definición de métricas, incluido quién es dueño de una métrica cuando dos equipos no están de acuerdo.
• Datos maestros y de referencia: reglas de emparejamiento, supervivencia de registros (survivorship) y el proceso de stewardship que las sostiene.
• Cobertura de la documentación: qué parte del modelo está documentada y si una persona recién llegada al equipo de analítica encuentra lo que necesita sin preguntar.

La prueba es la misma que para cualquier arquitecto/a: decisión, restricción y resultado medido.

Tres o cuatro líneas: años, tamaño del ecosistema, plataforma, un resultado de diseño y un resultado de coste o calidad.

La mayoría de puestos de arquitectura se crean después de que algo saliera mal: una observación de auditoría, una factura del almacén de datos que nadie esperaba o cifras de informes que no cuadraban. Aborda las dos cosas de frente.

• Coste: gasto antes y después, qué cambiaste y si se mantuvieron los niveles de servicio. Incluye el chargeback o el showback si lo construiste, porque dar a los equipos visibilidad de su propio gasto suele ser lo que hace que el ahorro se mantenga.
• Diseño de accesos: roles, controles a nivel de fila y de columna, cómo trataste los datos sensibles y cómo se revisan los accesos.
• Clasificación: cuántas columnas o tablas se clasificaron y con qué esquema.
• Linaje y catálogo: porcentaje de cobertura y quién lo usa de verdad. Un catálogo que nadie abre no es un logro.
• Conservación y supresión: las políticas que diseñaste, sobre todo donde se aplica normativa de protección de datos (en España y la UE, el RGPD y la LOPDGDD). Las reglas varían según el país y el sector, así que describe lo que construiste para esa empresa en lugar de presentar una regla como universal.
• Resultados de auditoría: observaciones cerradas, evidencias que aportaste y cuánto tardaba la recopilación antes y después.

Dos páginas para un/a arquitecto/a. Una sola columna sencilla, sin diagramas dentro del currículum; la foto es opcional y aquí no aporta. Si quieres enseñar un diagrama, enlaza a un artículo donde lo expliques.

• Usa el vocabulario exacto de la oferta: «modelado dimensional», «dimensión lentamente cambiante», «medallion», «data mesh» si aparece, «gestión de datos maestros», «linaje de datos», «contrato de datos».
• Escribe completos los nombres de plataformas y herramientas: Snowflake, Databricks, BigQuery, Redshift, dbt, Airflow, Kafka, Collibra, Great Expectations, Terraform.
• Pon las dos formas una vez: «extracción, carga y transformación (ELT)», «captura de datos de cambios (CDC)», «datos personales (PII)».
• Describe cada empresa: sector, facturación o plantilla y, si puedes, volumen de datos. Sin eso, el alcance de la arquitectura no se ve.
• Incluye un breve resumen técnico cerca del principio para que quien haga la criba encuentre tu plataforma sin bajar.
• Envía un PDF llamado Apellido-Nombre-Arquitecto-Datos.pdf, con los datos de contacto en el cuerpo y no en el encabezado.