Día 29 – ¿Quién pidió esto? Negocio vs Arquitectura
📖 Basado en DMBOK2 – 4.1.1 Business Drivers
🎭 Acto V – Fundar sobre cimientos sólidos: La Arquitectura del Dato
✨ Storytelling
Cristina entró a la reunión con el ceño ligeramente fruncido.
—“¿Otra vez van a rediseñar la arquitectura?” —pensó mientras tomaba asiento frente al arquitecto de TI, quien mostraba orgulloso un nuevo diagrama con hexágonos, nubes y flechas de colores.
—“Este modelo nos da más escalabilidad y desacopla los servicios”, explicaba entusiasmado.
Cristina levantó la mano.
—“¿Y eso en qué ayuda a reducir los reclamos por pedidos erróneos en la app?”
Silencio. Respiración contenida.
El arquitecto miró al gerente comercial. El gerente comercial miró al piso. Nadie tenía una respuesta clara.
Ese fue el momento exacto en el que Cristina lo entendió:
“No hay arquitectura técnica si no responde a una necesidad de negocio.”
🧠 Reflexión narrativa
La arquitectura de datos no debe ser una expresión artística de TI ni un lujo visual. Es una respuesta estratégica a los impulsores del negocio: eficiencia operativa, cumplimiento regulatorio, mejor experiencia del cliente, reducción de costos, escalabilidad, velocidad de respuesta…
Si no se conecta con eso, es solo un dibujo más para la pared.
Y peor aún: se convierte en una barrera, no en un facilitador.
📌 Claves técnicas según el DMBOK2
📍 ¿Qué son los Business Drivers?
Son factores que motivan el cambio organizacional y que deben guiar el diseño de la arquitectura de datos. Pueden incluir:
- Reducción de tiempos en procesos clave
- Mejora de calidad de información para decisiones
- Cumplimiento de regulaciones (como GDPR o ISO 8000)
- Necesidad de integración post-fusión o adquisición
- Exigencias de trazabilidad en la cadena de suministro
📍 Recomendación del DMBOK2
El diseño arquitectónico debe alinearse con los objetivos del negocio y adaptarse a las prioridades cambiantes de la organización.
📍 Errores comunes
- Arquitecturas que responden más a modas tecnológicas que a necesidades reales
- Falta de colaboración entre áreas de negocio y equipos de TI
- Documentos de arquitectura que no pueden ser entendidos por el negocio
📍 Ejemplo práctico
Una cadena de retail quería reducir los errores de inventario. La arquitectura propuesta incluyó integración en tiempo real entre ERP y POS, dashboards para operaciones y almacenamiento de datos históricos. Todo el modelo se construyó sobre ese driver específico: disminuir errores en stock.