Definitivamente, la migración a la nube está en marcha. Pero, para garantizar que las aplicaciones críticas operen de manera eficiente y rentable en el nuevo entorno hay que prestar especial atención a todo lo relativo al rendimiento tecnológico. Asegurar que sea óptimo —también en la nube— es crucial para evitar interrupciones en la operativa, garantizar la satisfacción de los clientes, tanto externos como internos, y maximizar el retorno de la inversión en infraestructura y servicios cloud. Hoy por hoy, sin embargo, muchas de las empresas inmersas en este proceso no lo están consiguiendo.
Según un estudio propio, que ha contado con la participación de una veintena de empresas de los sectores de banca, seguros y utilites, aquellas organizaciones que cuentan con entornos tecnológicos complejos asumen sobrecostes “inesperados” de en torno al 45% de sus presupuestos tecnológicos destinados a la migración a la nube.
Ello se debe fundamentalmente al diseño del software y a la ausencia de una política real relacionada con la gestión de su rendimiento tecnológico. Un análisis más profundo muestra que las causas más comunes de esta desviación se encuentran en:
- Los costes ocultos de los servicios cloud. Estos incluyen los derivados de su complejidad, que exige perfiles muy especializados, escasos en el mercado y, por tanto, con una alta remuneración.
- El procesamiento de picos inesperados, una situación que es especialmente onerosa en las aplicaciones que corren en el mainframe.
- La migración de componentes cuyo comportamiento dinámico en la nube es inadecuado debido a que no se diseñaron para ejecutarse en ese entorno. Muchos componentes que se migran son innecesarios y, de hecho, la experiencia nos demuestra que entre un 10% y un 25% están obsoletos.
Como consecuencia, la mayoría de las empresas reconoce no haber logrado aún los objetivos fijados en sus proyectos de migración cloud e incluso están replanteándose sus estrategias, plazos y objetivos en la nube. Además, en el caso de las entidades del sector financiero, estos sobrecostes se suman al 15% que sufren históricamente a causa de las ineficiencias del software y la ausencia de políticas para su optimización. Es este último aspecto, precisamente, el que menos contribuye a resolver la enorme complejidad que implica la nube, como la califican las empresas, que reconocen gestionar el entorno de forma reactiva, es decir, cuando aparecen problemas que afectan a la operatia y, por ende, a la cuenta de resultados.
Pero este escenario no se debe a que cloud sea complejo en sí mismo, sino a que el nuevo entorno se suma a los ya existentes, dado que las migraciones no son totales. Además, la mayoría de las empresas también reconoce que la nube ha añadido complejidad al desarrollo de nuevas aplicaciones.
En este contexto, y especialmente cuando en el viaje a la nube se embarcan aplicaciones como el core financiero de una entidad bancaria, es imprescindible optimizar el rendimiento antes, durante y después de la migración.
Operaciones críticas
La migración de aplicaciones críticas al cloud implica trasladar sistemas esenciales para la operativa diaria, que gestionan las transacciones financieras o las de la cadena de suministro. Cualquier merma de su rendimiento tendrá repercusiones tan significativas como pérdidas financieras, disminución de la satisfacción del cliente y daño a la reputación.
En este proceso es vital garantizar que las aplicaciones migradas funcionen con la misma o mayor eficiencia que en sus entornos originales, poniendo mucho cuidado en aquellos componentes que no han sido diseñados para el entorno cloud. La falta de planificación y de herramientas para la mejora continua del rendimiento genera problemas como latencias inesperadas, tiempos de respuesta prolongados y, en consecuencia, sobrecostes en infraestructura.
En busca del CPO (Chief performance officer)
El logro parcial de los objetivos de las empresas en su tránsito a la nube se debe en gran medida a los problemas en el diseño del software. Esto se suma a la tendencia a replicar en cloud la organización ineficiente de las TI, divididas, por un lado, en infraestructura y operación, y, por otro, desarrollo. En este tipo de organización, la nube y el outsourcing son los caminos habituales para reducir costes. Pero en demasiadas ocasiones consiguen lo contrario, porque no resuelven el problema de fondo: una estructura escindida que impide tener una visión global del rendimiento TI.
Ambas funciones justifican su labor e incluso proponen optimizaciones, pero el problema sigue irresuelto y seguirá así mientras no se conecten los dos entornos y se ataque la principal causa raíz que lastra su rendimiento, la baja calidad del software. Para ello, el área I&O debe ser capaz de encontrar la aguja en el pajar, es decir, determinar qué componentes son muy sensibles al coste y al servicio, y crear un rediseño optimizado. Esta es, sin exagerar, una función ineludible.
La mayoría de las empresas reconoce que no ha logrado aún los objetivos que se fijaron en sus proyectos de migración cloud
Hay empresas que han emprendido esa vía de conexión al tiempo que progresan en su camino a la nube. Han cogido el toro por los dos cuernos y, con el liderazgo de una nueva figura —con apelativos como IT for IT Projects manager o Head of Special Projects, entre otros— miden el rendimiento bajo parámetros clave para el negocio.
En Orizon denominamos a este perfil CPO (chief performance officer), un hacedor y guardián del rendimiento capaz de correlacionar variables financieras (ingresos) y operativas del negocio (número de clientes, transacciones…), y de manejar KPI representativos del rendimiento de la función TI: costes y tiempos de respuesta, disponibilidad y cumplimiento de los acuerdos de nivel de servicio (ANS), entre otros.
La cloudificación convierte al CPO en una figura capital ante los CEO, los CFO y las comisiones de tecnología de los consejos de administración. Su labor es continua, como lo es la mejora del rendimiento, y su visión y capacidad de actuación deben abarcar tanto lo existente —la conocida deuda técnica— como el nuevo software; además de gestionar el cambio, porque, como en cualquier transformación, encontrará resistencia.
