Ejemplos de deuda técnica en la implementación de sistemas de BI

El desarrollo y despliegue de sistemas de BI es un proceso bastante rápido y económico, pero su mantenimiento a lo largo del tiempo es costoso. Esto se puede imaginar a través de la metáfora de la deuda técnica.

Deuda técnica: denota los problemas acumulados en el código o la arquitectura del programa relacionados con el abandono de la calidad en el desarrollo de software y que causan costos laborales adicionales en el futuro.

A menudo existen razones estratégicas bien fundamentadas para asumir la deuda técnica. No toda la deuda es mala, pero toda deuda necesita servicio. La deuda técnica se puede pagar refactorizando el código, mejorando las pruebas, eliminando el código muerto, reduciendo las dependencias, ajustando la API y mejorando la documentación. El objetivo no es agregar nueva funcionalidad, sino hacer posibles futuras mejoras, reducir errores y mejorar la capacidad de mantenimiento. Aplazar tales pagos conduce a costos complejos. La deuda oculta es peligrosa ya que aumenta en silencio.

Ejemplos de deuda técnica en BI:

• Hay un almacén de datos en el proyecto de BI, pero de hecho es una copia de la base de datos de trabajo. Como resultado, los beneficios de almacenamiento, como la frecuencia de actualización de datos, se pierden y los datos pueden perderse o dañarse.
• Al cargar y actualizar datos (ETL), los datos no se verifican / corrigen. Los errores se transfieren a la aplicación.
• Los nombres de campo y variables no óptimos dificultan la edición y el uso de la aplicación en el futuro.
• Una estructura de modelo / datos inicialmente seleccionada incorrectamente de la aplicación genera problemas durante el funcionamiento y la modificación de la aplicación.
• BI , , ( ). , .
• BI — . BI. , - .
• , , ().
• BI, , - , .

Solo el conocimiento de esto, desafortunadamente, no proporciona ninguna métrica para la administración. ¿Cómo medir la deuda técnica en un sistema o estimar el valor total de esta deuda? El hecho de que el equipo todavía esté trabajando no es evidencia de un bajo nivel de deuda, ya que el valor total de la deuda se hace evidente solo con el tiempo.

Algunas preguntas útiles a tener en cuenta:

1. ¿Qué tan fácil es probar completamente un algoritmo completamente nuevo para calcular métricas?
2. ¿Con qué precisión se puede medir el efecto de un nuevo cambio en un sistema?
3. ¿Qué tan rápido pueden ponerse al día los nuevos miembros del equipo?

Esperamos que este artículo pueda servir como incentivo para desarrollos adicionales en el campo de BI, incluida la mejora de los métodos de prueba, los patrones de diseño y más. Pero el punto más importante es que la deuda técnica es un problema que tanto los programadores como los gerentes deben tener en cuenta.