Migrando un CORE Bancario de COBOL a JAVA #2

Ingresé a una nueva empresa del sector financiero, desde el inicio en las entrevista me comentaron que se trataba del proceso de transformación de uno de sus cores financieros, este CORE estaba hecho en COBOL y la “idea” era transformalo a JAVA como lenguaje “moderno”, este proyecto ya había iniciado desde hace más de 1 mes y ya habían realizado pruebas de transformación 1 año antes, por lo cual yo me integré a una plantilla como de 6 desarrolladores más.

Cuando tuve la primera reunión con mi jefe Directo, este me comentó que la estrategía que tenían para poder migrar el core de COBOL a JAVA, era literalmente así:

Toma los archivos COBOL,

Pero estos archivos COBOL no eran comunes…

1.- a veces los flujos tenian pocas dependencias “archivos”

2.- a veces más de 150 archivos COBOL por proceso, de un tamaño variable.

3.- a veces de más de 14 mil lineas de código por cada archivo

Análizas cada archivo, lo entiendes y haces el símil en JAVA, así de facil…

yo me quedé con cara de…

En ese momento le pregunte, qué usaban como herramienta de construcción o para poder integrar dichos coboles a lo cual respondió:

NTP , tu entrega las clases JAVA con el mismo nombre del archivo COBOL y listo. En ese momento pensé que esto no iba enserio, y me llegaron las preguntas de:

Donde está el arquitecto del proyecto? los líderes técnicos? la estrategia de modernización o el plan de como hacer las cosas?

Ninguna de mis preguntas tenía respuesta, no existián así comenzó todo…

Como se acordó en ese momento tuvimos una junta con los demás desarrolladores para poder obtener cada uno los componentes a migrar, llámese procesos o transacciones o como tal partes de la arquitectura del CORE.

Tuve una asignación un poco peculiar, ya que eran los componentes de una cache pero en COBOL, la cache tenía como objetivo recuperar datos de carga inicial para su uso en todos los flujos, algo así como un E-cache o un Redis pero en COBOL…, si COBOL.

Comencé leyendo los archivos COBOL y lo primero que dije, oye esto es muy parecido a ensamblador pero con C++, COBOL es un lenguaje estructurado y de ejecución secuencial, ademas existen muchas versiones de COBOL, esta si era una versión en especifico.

Muchas veces pensé, esto es muy fácil, pero cuando me daba cuenta del resultado de la traducción de manera manual del código COBOL a JAVA, el código JAVA me parecía bastante mal, pero es que si!!!!!, solo traducía el código estructurado de COBOL a JAVA estructuradamente!!!, JAVA no es estructurado, pero bueno en ese momento ejecutaba por ejecutar, pero si trataba de darle la capacidad orientado a objetos, pero era imposible, por la naturaleza del todo.

15 días después todos entregaron sus componentes migrados a JAVA sin funcionalidad, por ahora no podiamos responder las siguientes preguntas:

¿Cómo haces un prueba unitaria del código que se tradujo?qué parámetros les pasas

¿Qué resultados esperas obtener ?

**literalmente solo tradujiste el código a JAVA sin entender su propósito más que la funcionalidad lógica de COBOL**. ***

¿Cuales son las entradas y salidas?

¿Cómo sabes que lo que migraste es el programa inicial o que parte del programa en especifico era lo que tradujiste?

Todas esas preguntas no tenían respuesta.!!!!!

Pero algo si puedo comentar que pasaba…

Todos en el equipo estaban muy entusiasmados por estar llevando acabo este gran proyecto de migración, bueno no todos. pero si la mayoría.

Una de las cosas que pasaba muy seguido es que se criticaba mucho el código implementado.

qué patrones de diseño se están usando? Se aplicaba ahorro de memoria? Pruebas al código implementado

La tecnología para acceder a base de datos? Los estándares de desarrollo? Cuestionamiento del uso de Spring Framework? La ley de no usar frameworks, para no generar dependencias? etc.

Nos centrábamos demasiado en el como y no en el que. exactamente el problema que teníamos o el objetivo que buscábamos. repito el objetivo nuevamente.

Migrar de COBOL a JAVA los actuales flujos del CORE Financiero.

El equipo fue creciendo cada mes, se integraban de 3 a 5 personas por mes. Lo cual al inicio se pensó que entre más gente más código se podía traducir. Teníamos todo el equipo muchas ideas del como hacer las cosas, aveces sobrepasando del que se buscaba.

Iniciamos con un flujo en especial del CORE, llamemos le X001 el cual era un flujo muy básico pero que como tal se podía considerar como un flujo. Se vieron que coboles se usaban y estos eran pocos, por lo cual comenzamos a reescribir la funcionalidad de dicho flujo X001, nos fue muy fácil reescribir la funcionalidad ya que era un flujo muy pequeño pero significativo para darnos cuenta de la magnitud del problema. Para el tema de la persistencia propuse el uso de Spring JDBC template, ya que era una tecnología muy usada y tenía una amplia comunidad.

Otro compañero propuso el uso de MyBatis una herramienta la cual me agrado bastante ya que no era un ORM que te generaba los querys en tiempo de ejecución sino que podías hacer SQL nativo, muy parecido a JDBC. realizamos pruebas de diferentes vendors de persistencia, tanto ORM como JPA. Realizamos pruebas de estrés, carga. etc. por cada técnologia obtuvimos los tiempos de respuesta de cada una.

Las tecnologías revisadas fueron:

JDBC Nativo JPA Store Procedures MyBatys *Spring JDBC

Y aquí comienza algo que para mí siempre lo había buscado y que no dejo ahora de hacerlo.

PROPONER IDEAS, PROPONER TECNOLOGÍA, PROPONER INNOVACIÓN, PROPONER MODELOS DE IMPLEMENTACIÓN.

Esto me marco desde ese entonces, por que mi jefe nos daba la oportunidad de opinar con base a nuestros criterios y experiencia, siempre y cuando pudieras demostrar su uso y sus beneficios, así mismo tener mucha experiencia en dicha tecnología. Regresando al flujo X001, logramos traducir la funcionalidad exacta del proceso.

Usamos el siguiente Stack:

Spring Boot Spring JDBC DBCP para el pool de conexión Jboss EAP 7 Spring Rest Template Java 8 Junit

y aquí surge otro reto, que se unio al objetivo inicial .

Recordemos que el objetivo:

Migrar de COBOL a JAVA los actuales flujos del CORE Financiero.

Pero como segundo:

Generar un estilo de Arquitectura orientado a MicroServicios. De esto hablaré más adelante.

Continuando con el flujo X001, fue liberado a producción, la implementación no era muy buena pero la premura de dar resultados ya era lo que nos motivó bastante para poder salir a producción.

Uno de los más grandes errores es confundir la forma de trabajar con las metodologías ágiles. Ser agil se cree que es hacer las cosas rápidas aunque esten mal hechas. :(

yo creo que hacer las cosas agiles es igual a hacer las cosas bien.

Yo creo mucho en hacer las cosas bien, en el menor tiempo posible, pero bien.

Análizando bien, Diseñando bien, Codificando bien.

Regresando nuevamente al flujo X001. aprendimos bastante, pero aún existían muchas preguntas sin responder y ninguna estrategía para poder realizar la traducción de coboles de manera automatizada o manual.

En el siguiente artículo seguire narrando todos los retos e ideas que surgieron con base a todas las necesidades que teniamos…

episodio 3:

[embed]Migrando un CORE Bancario de COBOL a JAVA #3 Como les conté en el articulo anterior…medium.com

— — — — — — — — — — — — — — — — — — — — — — — — — —

Todo el año 2021 estaré impartiendo diferentes tranings, bootcamps y workshops de Apigee, Cloud y Microservicios en APIXCLOUD Service y Certificatic en la CIUDAD DE MÉXICO, les comparto el link donde vienen los telefonos y redes sociales de contacto.

BOOTCAMP : ARQUITECTO EN APIGEE Y MICROSERVICIOS CLOUD NATIVE:

🔻 Sede: APIX&CLOUD — Services / MODO ONLINE CON INSTRUCTOR EN TIEMPO REAL

🏆 Instructor: Jovani Arzate

⏰ Horario: 8:00am a 2:00pm.

⏳ Duración: 64 Horas dividido en 10 sesiones tomando 6 horas cada domingo.

🔻SOLO 15 LUGARES

📲 Contáctanos 👉 wa.link/v22o0v, contacto@apixcloudservice.com

#openapi #apificacion #apidevelopers #certificatic #microservices #k8s #containers #apis #apigee #patterns #domaindrivendesing #cloudnative #docker #servicediscovery #tracing #logs #monitoring #faulttolerance #eventdriven #scaling #apigateway #servicemesh #governance #arquitectura #cloud #12factores #contractfirst #apifirstdevelopment #rest #swagger #microservicios

Jovani Arzate Cabrera| Entrepreneur | Public Cloud Specialist | Cloud Governance | API Evangelist | API Architect | Apigee | Microservicios | AWS | Azure | GCP