Bill Curtis deja claro en esta entrevista que se debe medir la calidad estructural de las aplicaciones de negocio y demanda incorporar la deuda técnica en la planificación del mantenimiento. Como solución destaca las funciones de CAST Application Intelligence Platform para elaborar planes adecuados a cada empresa.
¿Considera que las organizaciones destinan suficientes recursos para medir la calidad de las aplicaciones y gestionar la deuda técnica? Las organizaciones de TI siempre han luchado para asignar suficientes recursos que garanticen la calidad de sus aplicaciones de negocio. Pero de manera particular, muchas realizan un trabajo pobre de evaluación de la calidad de las aplicaciones software que reciben de sus proveedores de outsourcing o integradores de sistemas. Al analizar la calidad estructural (a diferencia de la corrección funcional) de las aplicaciones de negocio, se observa una falta crónica de recursos. Los fallos estructurales son la causa principal de los problemas operacionales, por lo que es necesario prestar más atención a la calidad estructural, ahora que se ha observado y cuantificado daños valorados en más de 100 millones de euros.
¿Considera que existe demasiada deuda técnica en las empresas?
Con el crecimiento de los problemas operacionales y el coste de todo lo relacionado con el mantenimiento consumido por la mayor parte de los presupuestos de aplicaciones, hay una deuda técnica demasiado elevada.
¿Qué buenas prácticas hay que llevar a cabo para conseguir una gestión adecuada de la deuda técnica?
En primer lugar, se deben establecer disciplinas rigurosas en las prácticas de desarrollo y mantenimiento. Si siempre se está en modo ‘apaga fuegos’ es imposible tener control sobre la deuda técnica. En segundo lugar, se debe medir la calidad estructural de las aplicaciones, ya que todos los ejecutivos saben que no pueden controlar lo que no se mide. En tercer lugar, hay que establecer prioridades para los tipos de calidad que cada aplicación debe lograr (robustez, seguridad, facilidad de mantenimiento, rendimiento, etc.) y determinar qué proporción del esfuerzo se dedicará a bajar deuda técnica frente al desarrollo de nuevas funcionalidades. La reducción de la deuda técnica se debe incorporar en la planificación del mantenimiento para cada aplicación crítica de negocio.
¿Qué tecnologías son las más susceptibles a esta deuda técnica?
Nosotros hemos visto más deuda en lenguajes como Java, que se usa muy frecuentemente para el desarrollo de nuevas aplicaciones, frente a lenguajes como ABAP, que se utilizan para personalizar paquetes comerciales. Esto no es sorprendente dado el contexto de su uso. Sin embargo, desde que las aplicaciones Java se desarrollan de forma habitual empleando métodos ágiles, el menor tiempo destinado a evaluar problemas estructurales puede contribuir a incrementar la deuda técnica, más allá del efecto del lenguaje. De hecho, el concepto de deuda técnica surgió de la comunidad Agile.
¿Qué factores de calidad estructural (tamaño, seguridad…) tienen más impacto en la deuda técnica?
La mayor cantidad de deuda técnica está relacionada con factores de coste como cambiabilidad y mantenibilidad. Sin embargo, esto no debe ser interpretado como una señal de que estas son las áreas principales críticas de las que preocuparnos. En aplicaciones de negocio críticas la robustez, eficiencia, rendimiento o seguridad pueden ser más críticas, debido a los daños que pueden causar en su operación y funcionamiento. Cada aplicación necesita que se establezca un conjunto de prioridades que sirvan para sustentar las decisiones acerca de cuáles son los problemas de calidad que corregir.
¿Qué aportar una empresa como Cast Software?
El producto CAST Application Intelligence Platform (AIP) de CAST Software detecta las violaciones de las buenas prácticas de codificación y arquitectura y en base a esto cuantifica la deuda técnica. Esta información permite a los directivos y gerentes de TI estimar su exposición a la deuda, así como elaborar un plan para la corrección de los defectos más graves. Actualmente, la mayoría de las aplicaciones modernas se desarrollan con múltiples tecnologías/lenguajes de programación, por lo que CAST AIP ha sido diseñado para dar respuesta a esta realidad y analizar, de forma conjunta, todas las capas que conforma el aplicativo, con la finalidad de detectar fallos estructurales que afecten a dichas capas y sus relaciones. Esta capacidad única no puede ser ofrecida por herramientas freeware o comerciales que únicamente analizan un lenguaje o no son capaces de analizar la aplicación como un todo, así como la interacción entre sus capas. En resumen, hacemos visibles los problemas estructurales, especialmente aquellos que afecta a múltiples capas del un aplicativo.
¿Se pueden prevenir este tipo de incidencias relacionadas con la deuda técnica y calidad de software?
Desde que la gente comenzó a construir cosas, siempre han existido los errores. El principio de ‘Jidoka’ propone el uso de tecnologías inteligentes para mejorar las capacidades humanas con la finalidad de detectar dichos errores. Mediante la integración de nuevas y potentes tecnologías como CAST AIP en el proceso de desarrollo y el establecimiento de prioridades en la calidad para orientar tanto el uso como la inversión en los recursos de calidad, las organizaciones de TI pueden reducir drásticamente sus costes de propiedad y los riesgos a los que exponen a su negocio.
