1 experiencias en modernizacion de entornos mainframe eduardo aldao director de innovación...

1

EXPERIENCIAS EN MODERNIZACION DE ENTORNOS MAINFRAME

Eduardo AldaoDirector de Innovación

Septiembre 2014

2

¿Quien es ABANCA?

3

Con la siguiente distribución de operaciones por canal

Datos a Jun2014

Oficinas14.91%

ATMs29.64%

Banca In-ternet

25.79%

Banca Móvil

29.55%

B. Telef0.11%

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

Con un Hub Internacional formado por

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

Donde estamos

MAINDATACENTER

HOT BRS

7

8

Infraestructura Core

9

Arquitectura Lógica

Presentation LayerO2K (NSDK, .NET)

Electronic Banking

ATM’s

Apolication 1

Apolication 2

Apolication 3ESB

CH

ANN

LE

Other Channels

Mul

ticha

nnel

(.N

et)

Business Layer – SOA Architecture

CORE Banking

zSeries

DB2

BUSINESS SERVICESSOA ARCHITECTURE

Oracle

SQL Server

SAP (RRHH)

ESB

Ext

erna

l

Business Services-Metropolis

OpenText

back-endsystems

Teradata

External Systems

MUREX

Extenal Entities

Other applications

Servies offered by other Entities

ESB

Cor

e (L

_Tra

nsa,

APB

, CG

ALD

000)

CGDN Registry / APB Repository

Process Orchestation – Electronic Files

10

11

EDW: Áreas funcionales soportadas

OperationalSystems Iflex

(Miami, Geneva)Promosoft(Portugal)

ALM

Planificación/ Presupuestos

Objectivos

PlanificacionTargeting

Estados financieros

FERMAT

Blanqueo

Regulación

TRIAD

TVA

Data Mining

Inteligencia de clientes

ARM

SRV

Oficinas

FSI

OBI

SRC

Frontales

Oracle BI (Essbase)

ETL & DQINFORMATICA Powercenter

Data Warehouse Teradata(17 TB)

Modelo común de información

Spanish networkRetail Business

MUREX Wholesale and capital markets

business

Scoringreactivos

Alertas de riesgos

Gestión de Vencimientos

Riesgos

Scoring proactivos

12

Posicionamiento en funcionalidad

13

Capacidad Desarrollo

Descripcion %Productivo 94,84%No Producti vo 5,15%

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

Rating de Calidad

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

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

transaccionesCICS

PlanificadorOPC

BBDDDB2

10 mm de transacciones día punta.

3.500 MIPs

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

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

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

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

Resultado

Inviable una migración parcial

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: 7KAmortizació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

Metodología

Mayo 2013 Sept. 2013

Fase I - POC

14 meses

Fase II

25

Gobierno

Steering Comitee(Mensual)

•D. Medios•D. Tecnología•Control de Medios

Comité Operativo(Semanal)

•D. Infraestructura.•D. Arquitectura.•D. Tecnología

Porting del Mainframe(EXODO)

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

Planificación Fase I

27

Problemas detectados en Fase I

Comparación de cadenas entre entornos EBCDIC y ASCIISoluciónAnalisis 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 DTCSoluciónPlanteamiento 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ónImplementació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 escrituraSoluciónAnálisis e implementación de medidas correctivas junto con Microsoft y Micro Focus

28

Tiempos de respuesta

29

Arquitectura destino

30

Arquitectura BBDD

31

Planificación Fase II

32

Fase de PruebasDefinició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