Ya decidí modernizar mi core. ¿Y ahora qué?
Una empresa decide modernizar sus sistemas core generalmente por motivación económica.
El consumo de mainframe se factura por la unidad de capacidad MSU y, como la plataforma está en el centro de la operación desde hace décadas, reemplazar el hardware puede costar decenas de millones de dólares.
Por eso, la conversación suele empezar en finanzas: ¿cómo reducir el consumo y los tiempos de procesamiento para lograr la disponibilidad 24×7? Luego, se suman tecnología y negocio; porque las áreas comerciales necesitan lanzar productos y campañas, y un core que tarda en cambiar deja de ser un habilitador para convertirse en un freno.
En este video vas a aprender cómo la conversación de modernización suele abrirse por el costo (MSU/MIPS) y se completa con agilidad de negocio; el análisis inicial y el tablero de métricas que son la base de todo el programa de modernización, que se puede reducir consumo sin migrar de plataforma, y cómo se gobiernan los programas de gran escala.
Primer paso: entender dónde está parado el core
Un programa serio no empieza modificando código sino con un análisis de reingeniería y modernización que incluye relevamiento integral de procesos batch, online e integraciones, mapa de aplicaciones y dependencias, y detección de cuellos de botella de performance y costo. De ese análisis sale el roadmap que ordena el resto de los frentes.
En paralelo se diseña un tablero estratégico de métricas (MIPS, tiempos de batch, disponibilidad, incidentes y costos), que fija la línea de base y permite mostrar la mejora a los comités y a la dirección a lo largo del programa.
Qué se puede mejorar sin cambiar de plataforma
Aun si la decisión es quedarse en el mainframe, hay varias palancas para la modernización. Una es migrar de COBOL antiguo a COBOL 6, priorizando los componentes según criticidad y beneficio, con un piloto controlado, una migración masiva y una etapa de estabilización, aprovechando las capacidades del compilador para reducir consumo.
Otra, optimizar las integraciones host to host.
Y una tercera es ir acotando el rol del core con el patrón strangler: no se apaga nada, se optimiza, se deja en el core lo más importante y el resto se lleva afuera de a poco.
Cómo se organiza un programa de este tamaño
Un programa integral de escala nacional puede extenderse unos 30 meses, con frentes que se solapan (COBOL 6, optimización online, de configuración y batch, APIficación y desacople de canales) y que se gobiernan como un único programa, con una PMO y comités conjuntos entre la entidad bancaria y el proveedor.
