📘 Referencia: Capítulo 5.1.2 – Goals and Principles
🎯 Arco narrativo: Acto VI – Del concepto al diseño: modelar con sentido

✨ Storytelling

—”Cristina, necesito que actualices el modelo lógico para incluir las nuevas reglas del canal mayorista.”

La solicitud de su jefe sonaba simple. Pero apenas abrió el archivo .cdm, Cristina sintió el peso de lo que realmente implicaba.

Las últimas veces que compartieron modelos con el negocio, nadie entendió nada. Ni siquiera el área que había solicitado el cambio.

—”¿Esto representa al cliente corporativo o al minorista?” —preguntó alguien en la última reunión.

—”Depende del atributo que mires” —respondió el arquitecto, generando más dudas que respuestas.

Cristina suspiró. No bastaba con hacer un modelo técnicamente correcto.
Si el negocio no lo entendía, el modelo fracasaba.

Decidió entonces cambiar su enfoque.

En lugar de comenzar con la herramienta, empezó con un esquema en papel.
Preguntó primero:
—”¿Qué decisiones deben tomar con este dato?”
—”¿Qué significan cliente, pedido, canal… en este contexto?”

Solo después de esas conversaciones, modeló.

Y esta vez, al presentarlo, nadie preguntó qué significaba cada entidad.
Lo entendieron.

🧠 Reflexión narrativa

La esencia del modelado de datos no está en la documentación técnica.
Está en construir un lenguaje común entre áreas, permitiendo que el dato tenga sentido más allá del sistema que lo contiene.

Un buen modelo no es un documento para archivar.
Es una herramienta de entendimiento, diseño y evolución continua.

🧮 Sección técnica – DMBOK2: Objetivos y principios del modelado de datos

El DMBOK2 establece que el modelado debe cumplir funciones estratégicas, analíticas y operativas, bajo principios claros de calidad y utilidad.

ElementoDetalle según DMBOK2
🎯 Objetivos– Representar conceptos de negocio
– Facilitar el diseño técnico
– Promover el entendimiento común entre áreas
🧭 Principios clave– Abstracción progresiva
– Modularidad y reutilización
– Claridad en nomenclaturas y definiciones
📊 Buenas prácticas sugeridas– Validar los modelos con stakeholders
– Usar estándares de notación (ER, UML, etc.)
– Mantener versiones y trazabilidad
📈 KPIs asociados (recomendados)– % de stakeholders que entienden el modelo
– Nº de errores detectados en validación funcional
– Tiempo promedio de onboarding con base en modelos disponibles
🛠️ Frameworks de soporte– Zachman Framework
– TOGAF (para alineación arquitectónica)
– BPMN (cuando se conecta con procesos)

🧠 Tip práctico

Cuando el modelo no se entiende, no se usa.
Y cuando no se usa, deja de ser un modelo… para convertirse en ruido estructurado.

¿Listo para que tus modelos hablen el idioma del negocio?