1 1 EXPERIENCIAS EN MODERNIZACION DE ENTORNOS MAINFRAME Eduardo Aldao Director de Innovación Septiembre 2014

2 2 ¿Quien es ABANCA?

3 3 Con la siguiente distribución de operaciones por canal Datos a Jun2014 Oficinas: Operaciones contables; ATMs: Operaciones contables y de consulta; B. Internet: Operaciones contables y de consulta; B. Móvil: Operaciones contables y de consulta; B. Telefónica: Operaciones contables La operatoria online (Internet + Móvil) ya supone el 55% de las interacciones con clientes

4 4 Con un Hub Internacional formado por

5 5 Y dando servicio de – Housing integrado Evo Banco. Banco Etcheverria. – Partnered Housing (como Tecnocom, IPM, Halcash, CxG) Típicos mecanismos de housing donde el partner tiene control total de su infraestructura. Los Partners revenden servicios de housing y hosting. – Hosting (Telepay, Paynopain, OSG,…) El Banco suministra servicios de virtualización (con granjas VMWare), almacenamiento y comunicaciones.

6 6 Donde estamos

7 7

8 8 Infraestructura Core

9 9 Arquitectura Lógica Presentation Layer O2K (NSDK,.NET) Electronic Banking ATM’s Apolication 1 Apolication 2 Apolication 3 ESB CHANNLE Other Channels Multichannel (.Net) Business Layer – SOA Architecture CORE Banking zSeries DB2 BUSINESS SERVICES SOA ARCHITECTURE BUSINESS SERVICES SOA ARCHITECTURE Oracle SQL Server SAP (RRHH) ESB External Business Services- Metropolis OpenText back-end systems back-end systems Teradata External Systems MUREX Extenal Entities Other applications Servies offered by other Entities ESB Core (L_Transa, APB, CGALD000) CGDN Registry / APB Repository Process Orchestation – Electronic Files

10 10

11 11 EDW: Áreas funcionales soportadas Operational Systems Iflex (Miami, Geneva) Iflex (Miami, Geneva) Promosoft (Portugal) Promosoft (Portugal) ALM Planificación/ Presupuestos Objectivos Planificacion Targeting Estados financieros FERMAT Blanqueo Regulación TRIAD TVA Data Mining Inteligencia de clientes ARM SRV Oficinas FSI OBI SRC Frontales Oracle BI (Essbase) ETL & DQ INFORMATICA Powercenter Data Warehouse Teradata (17 TB) Data Warehouse Teradata (17 TB) Modelo común de información Spanish network Retail Business Spanish network Retail Business MUREX Wholesale and capital markets business Scoring reactivos Scoring reactivos Alertas de riesgos Gestión de Vencimientos Riesgos Scoring proactivos

12 12 Posicionamiento en funcionalidad

13 13 Capacidad Desarrollo

14 14 Gartner constata disponemos de la mayor capacidad de transformación de negocio de las entidades analizadas en el 2012 en Europa “Hay un enfoque importante en la eficiencia y evidencia claro de ello es un alto índice de utilización y una elevada productividad” Gartner: Benchmarking TI ABANCA

15 15 Rating de Calidad

16 16 ¿Y porque nos planteamos un proyecto de migración? Solicitud de reducción de costes de la Dirección General. Disponer de una versión de Core Bancario low cost que nos permita instalarlo a coste razonable en otros países. La rescritura del resto de aplicaciones Core del Mainframe a Metropolis/Java es un proyecto largo y costoso. Incrementar la capacidad de crecimiento y escalabilidad a bajo coste. Modernizando nuestros aplicativos Core obtendremos aún mayores ratios de eficiencia.

17 17 Que hay que migrar 9.000 programas PL/I CICS 16.881 programas PL/I Batch 105 programas PL/I CICS/Batch 2.030 fuentes cobol y 10.397 copys cobol 10.388 JCLs estáticos. 1.221 JCLs dinámicos. 800 ficheros con datos VSAM. 18.000 tablas DB2. 460 TB de datos. Lenguajes de programación PL/I y Cobol Monitor de transacciones CICS Monitor de transacciones CICS Planificador OPC Planificador OPC BBDD DB2 BBDD DB2 10 mm de transacciones día punta. 3.500 MIPs

18 18 El proyecto En enero del 2012 comenzamos a evaluar estrategias, riesgos y proveedores. 1.Evaluación de estrategias: Porting de código de PLI a Cobol, Java, C. Mantener el PLI en arquitecturas de entornos abiertos. 2.Evaluación de proveedores: GFI/Oracle, HP/Oracle Tecnocom/HP/Microfocus, Microsoft/Microfocus, Microsoft/RainCode IBM Cornerstone. Todos con experiencia en migraciones y casos de éxito. Evaluación del código y de la solución por parte de todos los proveedores.

19 19 Claves de la decisión 1.Asegurar la continuidad del negocio. 2.Minimizar el riesgo. 3.No congelar el desarrollo durante la duración del proyecto. 4.Mínimo impacto en las áreas de desarrollo. 5.Ahorro de costes. 6.Garantía del proveedor. 7.Involucración en el proyecto. Estas fueron las variables fundamentales, con distintos pesos, que nos ayudo a construir la matriz de decisión.

20 20 Primer paso En Noviembre realizamos un Rapid assessment con Microfocus Validación del inventario de Software. Identificación de los cambios necesarios. Detectar componentes o partes de software obsoleto. Identificar puntos de contacto con otras aplicaciones. Aislar los potenciales componentes candidatos para un piloto. Determinar si podemos realizar migraciones parciales o un BigBan Obtener el esfuerzo necesario para realizar una migración y el grado de compatibilidad del Software. Imprescindible para la evaluación de un escenario de downsizing que pueda terminar en diciembre de 2014, con costes inferiores a los analizados en mayo pasado y con una arquitectura de menor riesgo.

21 21 Resultado 72% del código directamente compilable en el nuevo entorno. FIXED DECIMAL or BINARY maximum precision exceeded. STATEMENT option, keyword parameters and ANS statement not supported in Open PL/I pre-processor. 29 sentencias CICS no soportadas (0,05% del total). Temas solucionados por Microfocus en su compilador

22 22 Resultado Inviable una migración parcial

23 23 Presentación de la propuesta En mayo del 2013 se presento el proyecto 7K al consejo de administración. Inversión: 6K. Ahorro recurrente: 7K Amortización primer año. Dos Fases: Fase I (POC). Prueba de concepto y punto de salida del proyecto. Inversión mínima para realizar un piloto. 2 transaciones On Line (logon de usuario, posición de cliente) 14 Jcls. (movimientos de cuentas) Fase II (Implantación del proyecto). Aprobación de la Fase I del proyecto.

24 24 Metodología Mayo 2013Sept. 2013 Fase I - POC 14 meses Fase II

25 25 Gobierno Steering Comitee (Mensual) Steering Comitee (Mensual) D. Medios D. Tecnología Control de Medios Comité Operativo (Semanal) Comité Operativo (Semanal) D. Infraestructura. D. Arquitectura. D. Tecnología Porting del Mainframe (EXODO) Porting del Mainframe (EXODO) Puesta a cero entorno (RESET) Puesta a cero entorno (RESET) Arquitectura Infraestructura PMO (Seguimiento) Seguimiento Proveedores Procura Pmo Comité Semanal de Pruebas D.Procura D.PMO D.Control Equipo de pruebas

26 26 Planificación Fase I

27 27 Problemas detectados en Fase I Comparación de cadenas entre entornos EBCDIC y ASCII Solución Analisis de 10.000 programas para determinar el posible impacto. Se detectan pocas incidencias sobre las comparaciones potencialmente conflictivas (54), hay que modificarlas manualmente, el proveedor asume que no habrá impacto ni en plazos ni en coste. SQL Server 2012 AlwaysOn no soporta adecuadamente MS DTC Solución Planteamiento basado en Microsoft Failover Cluster con Log Shipping y Availability Group que soporta MS DTC. Criptografía, Análisis de la funcionalidad de los comandos Esfera. Solución Implementación por los Labs de Atalla de 6 verbos criptográficos no soportados actualmente. Tiempos respuesta en ejecución de la PoC tanto en Tx Online como en ejecución JCLs escritura Solución Análisis e implementación de medidas correctivas junto con Microsoft y Micro Focus

28 28 Tiempos de respuesta

29 29 Arquitectura destino

30 30 Arquitectura BBDD

31 31 Planificación Fase II

32 32 Fase de Pruebas Definición de tres entornos de referencia: 2 entornos Mainframe (Lpar) 1 para desarrollo y pruebas unitarias. 1 espejo de explotación para pruebas automáticas. 3 entornos de Referencia 2 desarrollo y pruebas unitarias. 1 espejo de explotación mainframe pruebas unitarias. 1º.- Pruebas unitarias. De transacciones y JCLs. 2º.- Superada la prueba unitaria, la transacción pasa a pruebas automáticas. La misma transacción se lanza automáticamente en los dos entornos espejo y se comprueban automáticamente los resultados. Al menos una vez a la semana, se clonan los entornos de explotación y se lanza todas la operaciones de un día en ambos entornos (Mainframe y Referencia) en simultaneo. Se comprueban resultados. Se realiza un cuadre contable. (en base a comprobación estados M1 y M2) Se comprueban valores de tablas en BBDD 3º.- 4 meses de Paralelo. 4º.- 1 mes de pruebas funcionales con usuarios finales.

33 33