Edgar Alonso
Data Governance
Día 44 – Lo que impulsa un buen modelo no es técnico, es estratégico
📘 Referencia: Capítulo 5.1.1 – Business Drivers
🎯 Arco narrativo: Acto VI – Dibujar el dato, diseñar el conocimiento
✨ Storytelling
Cristina estaba por revisar un modelo lógico recién enviado por el equipo técnico.
Abrió el archivo.
Columnas bien nombradas. Relaciones correctas. Tipos de datos asignados. Todo parecía estar “en orden”.
Pero había algo que no cuadraba.
—“¿Por qué estamos modelando categorías de producto si el negocio está pidiendo una vista de categorías de cliente?” —preguntó al arquitecto de datos.
Silencio.
—“Bueno… porque el sistema tiene esa estructura.”
—“¿Y el negocio tiene esa necesidad?”
—“No sé, pero técnicamente es viable…”
Cristina respiró hondo.
Lo entendió todo.
El problema no era el modelo.
Era que el modelo respondía a la arquitectura…
pero no al negocio.
“Un modelo de datos que no parte de los objetivos estratégicos es solo un dibujo bien hecho… pero inútil.”
🧠 Reflexión narrativa
Muchas veces, el modelado de datos se convierte en un ejercicio técnico desconectado de las prioridades de negocio.
Pero según el DMBOK2, el punto de partida para todo esfuerzo de modelado deben ser los impulsores de negocio (Business Drivers).
¿Por qué estamos creando este modelo?
¿Para mejorar la experiencia del cliente?
¿Reducir costos?
¿Cumplir con una regulación?
Si no tenemos claro el “para qué”, los modelos acaban reflejando las bases de datos… no las decisiones que se deben tomar.
📌 Conceptos clave del día
| Concepto | ¿Qué implica? |
|---|---|
| Business Drivers | Razones estratégicas que justifican el modelado de datos. Deben provenir del negocio, no solo de TI. |
| Value Alignment | El modelo debe responder a la necesidad, no solo al sistema. |
| Impacto organizacional | El modelado debe facilitar decisiones, procesos y métricas del negocio. |
| Modelos como representaciones del negocio | Un buen modelo cuenta la historia de la empresa… no solo su estructura técnica. |
🎯 Recomendaciones prácticas
- Antes de modelar, agenda una reunión con stakeholders para entender objetivos.
- Revisa OKRs o KPIs actuales que podrían verse impactados.
- No valides solo con TI: valida con negocio.
- Asegúrate que el modelo responda a una necesidad documentada.