Una noticia de esta semana confirma que el mercado de software para mainframes se mueve, aunque es natural que le pesen los achaques de la edad. BMC Software (fundada en 1980 y hoy controlada por el fondo KKR) ha adquirido Compuware (siete años más vieja y, desde 2014, propiedad del equity fund, Thoma Bravo). La cifra no ha sido revelada pero estará en torno a 2.000 millones de dólares más la deuda. Lo curioso del caso es que en mayo de 2018 Compuware estuvo a un paso de comprar BMC, por entonces en manos de un mal consorcio financiero con intereses dispares. Por si no ha quedado claro: este mercado peculiar es terreno de caza para inversores con buen olfato y mucha paciencia. 
Esta vez, la iniciativa ha venido de la mano del nuevo CEO de BMC, Ayman Sayed, quien considera crucial esta fusión para contrarrestar la imprevisible estrategia de Broadcom tras su adquisición de otra compañía independiente del mismo segmento, antes llamada CA Technologies. Sin olvidar, por supuesto, el papel tutelar que por su propio peso ejerce IBM.
BMC tiene 6.000 empleados y factura unos 2.000 millones, según su página web. Por su lado, Compuware no publica cifras, pero presume de tener como clientes a 46 de las 50 mayores empresas del ranking Fortune. La principal aportación de la adquirida será su fuerte experiencia en las técnicas Agile y DevOps de desarrollo de software, según su CEO, Chris O´Malley. Su rama de software APM (application performance management) ya fue desagregada años atrás y cotiza en bolsa con el nombre de Dynatrace.
Todo lo anterior, con permiso de los lectores, quiere ser la introducción a otra crónica menos coyuntural. Es sobradamente conocido que, aunque desde hace décadas se predica la muerte inminente del mainframe, estos sistemas continúan formando parte intrínseca del corazón informático de grandes organizaciones, para las que su rendimiento y capacidad transaccional no han sido igualados por arquitecturas más modernas. Lo que no sale tanto a la superficie es el hecho de que gran parte de las aplicaciones distribuidas, web y basadas en la nube, de uso corriente hoy en día, suelen depender de estas plataformas de robustez probada.
La mala noticia que inspira el párrafo precedente es esta: tres de cada cuatro responsables del desarrollo de aplicaciones para mainframe reconocen que encuentran graves dificultades para aumentar a la vez la calidad, la velocidad y la eficiencia en sus desarrollos y en el test de los códigos que escriben. La encuesta, promovida por Compuware en seis países (entre ellos España), ha sido elaborada por la consultora Vanson Bourne. Su referencia es la automatización de las pruebas de esta categoría de software, que parece haber perdido el favor de los programadores jóvenes y no tan jóvenes.
La llegada de metodologías como Agile y DevOps, que se vislumbraba como una solución al problema, no ha dado los frutos esperados, a tenor de las respuestas de 400 responsables de TI de grandes organizaciones. Más de la mitad de los profesionales de desarrollo de estas aplicaciones afirman que la mayor barrera para llevar a cabo el testing necesario es… el tiempo que requiere su integración en los sistemas. Como suena: a pesar de los pesares, no existe automatización de estas pruebas en el entorno mainframe, a diferencia de las aplicaciones móviles, distribuidas o web, en las que son práctica corriente desde hace años.
No es un asunto baladí, ya que el 51% del tiempo de que disponen los equipos de desarrollo se destina a ejecutar estas pruebas cuando se lanzan las nuevas aplicaciones mainframe e incluso sus funcionalidades aisladas del conjunto. Los métodos manuales siguen imperando con el paso de los años, a despecho de las advertencias de Compuware. Son, por así decir, el lastre en estos procesos: cuando esta plataforma no está implicada, en lugar del 51% el tiempo que se destina al testing no llega al 40%. Las cosas, en lugar de mejorar, empeoran: un 92% de los equipos especializados están invirtiendo actualmente más horas en probar software que hace años. Lo que no es sino una manifestación de que ha aumentado la complejidad, algo que la encuesta del lado español agrava: el porcentaje escala hasta el 96%.
No se trata meramente de una cuestión de velocidad, sino de calidad, evidencia el 85% de las respuestas. Los entrevistados alertan del riesgo de que los procesos manuales puedan llegar a introducir errores de código, en su intento por acelerar la puesta en producción. No en vano un 35% de los responsables de desarrollo admiten tener dificultades para visualizar y comprender las dependencias generadas en el código de las aplicaciones por el deseo de garantizar que los cambios no van a producir resultados inesperados.
Dicho de otro modo, el mensaje del estudio es el siguiente. O se acelera la automatización de estas pruebas o no será viable acompasar la dinámica del mercado. De hecho, el 80% de los encuestados asegura que de no alcanzarse el nivel de automatización requerido, podrían darse situaciones indeseadas, con código defectuoso entrando en producción.
La presión a que se ven sometidos estos profesionales les lleva en algunas circunstancias a tomar atajos que no derivan en una mayor calidad del software. Así, no sorprende que la principal preocupación de las empresas (50%) apunte a la potencial introducción de vulnerabilidades o código defectuoso en producción. Lo que conduce directamente a la segunda preocupación (38%), esto es que una incidencia termine afectando negativamente la experiencia del cliente. Refrendando esta postura, el 90% de los entrevistados cree que la única manera de aliviar la presión es recurrir a la automatización del testing.
Curiosamente, la menor de las inquietudes es que salga perjudicada la facturación (28%), si bien es cierto que otras con mayor porcentaje – como la interrupción de las operaciones o la pérdida de tiempo de los desarrolladores – son causantes de un descenso de los ingresos.
Completando el análisis, el informe aborda los recursos humanos: el 40% de quienes han respondido la encuesta afirman que para estas pruebas de software es necesario contar con personal especializado que es cada vez más difícil de encontrar en el mercado, ya que los profesionales con experiencia en COBOL son un activo escaso.
La realidad que desvela el informe de Compuware es que el margen de mejora es anchísimo: un 7% de las organizaciones tienen resuelta esta automatización de los test de software para entornos mainframe. El 93% que no automatiza se reparte entre un 37% que dice no hacerlo porque no dispone de herramientas, y un 56% que se justifica afirmando que no lo hace pero lo contempla para el futuro.
La situación que diagnostica Compuware – y pronto heredará su nuevo propietario, BMC – tiene forzosamente que revertirse, sostienen los responsables del desarrollo de aplicaciones. No les falta voluntad, porque de ello depende buena parte de la capacidad de las empresas para innovar en sus TI. El 82% subraya que si no pueden automatizar las pruebas de software, se quedarán atrás en los objetivos de innovación y acabarán defraudando la expectativa del cliente.
Dicho sea de una vez: la automatización se califica como el gran salvavidas para estos equipos de desarrollo, en todas sus vertientes: testing funcional, testing de integración y testing unitario. Punto interesante este último, que el estudio identifica como extremadamente importante en las etapas más tempranas de desarrollo, cuando aún no se han colado errores de código o son de más sencilla corrección.
La automatización, subraya en sus conclusiones el estudio, permitiría driblar la escasez de programadores expertos en COBOL. Y como nada se hace porque sí, Compuware ha tomado esta iniciativa porque dispone de una herramienta – Topaz for Total Test – que, apoyándose en datos de la consultora Forrester, ha permitido ahorrar millones de dólares gracias a la aceleración de la puesta en producción, al reducir sustancialmente (un 83%, nada menos) los errores de código.
No ahondar en esa línea, esta es la conclusión final, sería agravar los cuellos de botella o, en otra figura retórica conocida, poner palos en la rueda de la innovación. A saber qué opina BMC: probablemente lo mismo.
[informe de David Bollero]