Proyecto de Modernización

Proyecto Confa Migración del ambiente de pruebas y producción de Oracle JDE 9.1 que se encontraba sobre una plataforma IBM i a la nube de Amazon Web Services – AWS en plataforma x86

Recomendamos a IKTINUS como proveedor estratégico de proyectos de base tecnológica, el cual cuenta con los conocimientos técnicos especializados en diferentes tecnologías de punta, entre ellos los necesarios para analizar, dimensionar, aprovisionar y poner en correcto funcionamiento nuestra plataforma ERP Oracle JD Edwards EnterpriseOne 9.1 en la nube de Amazon Web Services – AWS. Éste nos asesoró, acompañó y brindó la consultoría con la culminación del proyecto exitosamente, donde migramos de una arquitectura IBM iSeries hacia una arquitectura Intel x86, alojada en los servicios que provee la nube de AWS, arrojando este proyecto excelentes resultados, mejor desempeño, buena relación costo beneficio y permitiendo a nuestra empresa tener un gran avance tecnológico.

Con este proyecto se realizó una migración de alto nivel de complejidad, contando con el respaldo de un proveedor tecnológico comprometido, responsable, con experticia y experiencia en la ejecución de las actividades programadas, lo cual permitió una adecuada implementación, cumplimiento en tiempo y costos, y así, ofrecer tranquilidad en el proceso de actualización tecnológica de toda la Organización.

Carlos Andrés Duque Quintero
Gerente de tecnología – Confa

Un viaje de System i (previamente denominado AS/400) hacia Amazon Web Services fue un proyecto que tomó lugar en Confa, Caja de Compensación Familiar de Caldas; organización que por su compromiso social, tiene como una de las prioridades la reducción de costos en servicios de terceros, para dar cada vez mas presupuesto y oportunidades para fomentar, desarrollar y madurar los servicios que mejoran la calidad de vida de la comunidad afiliados y beneficiarios de la caja en el departamento de Caldas, Colombia.
El proyecto consistió en la migración de plataforma de la solución Oracle JD Edwards EnterpriseOne 9.1, la cual utilizan para desarrollar varias de sus funciones de misión crítica. Proyecto que, desde un principio, varios consideraron imposible de ejecutar debido a la heterogeneidad de las plataformas (AS/400 y x86).

El proyecto fue ejecutado con base en las guías de migración y modernización de Amazon Web Services, siguiendo el orden y la lógica de las fases de análisis, implementación, transición y operación.
A continuación, encontrarán un resumen de las actividades más críticas del desarrollo del proyecto, las cuales les pueden servir de guía:

Estudio de Viabilidad

Desde la fase inicial de análisis de la viabilidad de la migración, fue fundamental profundizar en la arquitectura de la aplicación para determinar su nivel de portabilidad hacia otras plataformas de sistemas operativos, bases de datos, servidores de aplicaciones JAVA, etc. Esto fue lo primero que hizo posible la migración, teniendo en cuenta que la plataforma JD Edwards EnterpriseOne está construida sobre una fuente de código portable a otras plataformas lo que la hace multiplataforma.

Licenciamiento

Asegurar la conformidad legal por parte del cliente del uso de tecnologías de Oracle es una actividad de prioridad uno. Por medio de este arduo análisis se determinaron los tipos de productos que se requerían y se podían utilizar sin incurrir en costos de licenciamiento adicionales; ya que el contrato actual que el cliente tenga con Oracle relacionado al producto JD Edwards EnterpriseOne, puede o no incluir el uso de las plataformas y tecnologías de uso exclusivo para Oracle JD Edwards EnterpriseOne como Oracle Database y Weblogic en sus ediciones estándar.

Datos

Igual de importante es certificar que los diferentes mecanismos, herramientas y procedimientos que se utilicen para ejecutar los ETLs (Extracción – Transformación – Carga) mantengan la compatibilidad e integridad de los diferentes tipos de datos entre las instancias relacionales fuente (DB2 AS/400) y destino (Oracle Database). Para complementar la estrategia de aseguramiento de la integridad de la información se determinó, en conjunto con los líderes de procesos operativos, la ejecución de reportes de control durante la fase de transición antes de iniciar el proceso sobre la plataforma de AS/400 y finalizado el proceso en la plataforma de Amazon Web Services, permitiendo evidenciar la igualdad de resultados de dichos reportes entre ambas plataformas, demostrando la integridad de los datos después del proceso de transformación.

Integraciones

Identificamos las diferentes aplicaciones satélites que se integran con Oracle JD Edwards EnterpriseOne y determinamos el tipo de integración: de salida (Outbound), entrada (Inbound) y de factores de alto impacto a la operación como integraciones tipo batch o en tiempo real.

Relación de Cómputo

Estando en una plataforma de nube como Amazon Web Services, es de gran flexibilidad la expansión y contracción de capacidades de cómputo; sin embargo, es de vital importancia proyectar los recursos de cómputo en una arquitectura x86 que provea como mínimo el mismo nivel de servicio que el entorno actual en AS/400 y a un costo mucho menor. Esto se logró a través de una fase de análisis donde se aplicaron las relaciones de desempeño entre las dos tecnologías de procesamiento RISC (Power 7) e INTEL (x86).

Desempeño Transaccional

A nivel de desempeño uno de los retos más grandes fue monitorear y recolectar las métricas de desempeño de tráfico de almacenamiento (throughput) y escritura y lectura en disco (IOPS). Estas métricas son de suma relevancia para poder decidir qué tipo de servicio y almacenamiento aprovisionar especialmente para la base de datos relacional, donde en este caso fue Oracle Database en modalidad de servicio administrado de Amazon Web Services con el servicio de AWS RDS. Por lo general estas métricas se deben tomar de los procesos y transacciones de mayor impacto a la operación del negocio, teniendo en cuenta que los tiempos de servicio deben mantenerse u optimizarse.

Arquitectura

Como gran ventaja de migrar hacia Amazon Web Services, se optó por segmentar la arquitectura de las diferentes capas de la aplicación de forma distribuida en contraste a como se tenía en el entorno de procesamiento en AS/400 bajo la modalidad AIO (All In One) donde todo el procesamiento de las capas ocurre en el mismo nodo solo con la opción de separar por subsistemas.

Pruebas – Lógica de Negocio

Determinar la viabilidad total de la migración de AS/400 hacia Amazon Web Services depende totalmente de la calidad de las pruebas de todos procesos del negocio que actualmente se encuentran en operación en la solución de Oracle JD Edwards EnterpriseOne en su entorno productivo. En esta fase fue fundamental el nivel de soporte que como aliados estratégicos (Partner) proveímos, mitigando interrupciones en el ciclo de pruebas por retardos en responder a los incidentes que se van presentando.

Optimización (Tuning)

Debido al cambio de plataforma y reconociendo el alto poder de cómputo de la plataforma de System i (AS/400) es necesario identificar y optimizar algunas operaciones de lógica y operaciones CRUD de la base de datos con el fin de proveer tiempos de respuesta óptimos. Así mismo se implementaron prácticas de optimización en las capas de datos, aplicación y presentación.

Entrenamiento

Uno de los beneficios de mayor efecto en el área de TI es haber transformado la forma de gestionar, administrar, gobernar y operar la plataforma de Oracle JD Edwards EnterpriseOne y los componentes de Middleware que la conforman. Para lograr una mayor eficiencia en actividades de gestión de la plataforma, fue esencial desarrollar un plan de entrenamiento de los servicios de Amazon Web Services incluidos en la arquitectura y las prácticas de administración en la plataforma de Amazon Web Services.

Simulación de Transición

Una de las fases más críticas desde la perspectiva del negocio, es la claridad en los tiempos de indisponibilidad del servicio durante el proceso de transición en el que se realiza la migración final de AS/400 hacia Amazon Web Services. Una vez activa esta nueva plataforma, los usuarios interactuarán con esta solución en la operación.

Para suministrar de forma clara este dato a la dirección del negocio, se ejecutaron varias simulaciones en las que se tomaron tiempos de ejecución de cada una de las actividades a realizar en la fase de transición, optimizando y mejorando procedimientos que incurrieran en reducción de tiempos. Esto permitió cumplir y exceder las expectativas del negocio en cuanto a la disponibilidad del servicio de nuevo a la operación.

Transición

Un cronograma de transición hora a hora es indispensable para esta fase, contemplando todo tipo de ocurrencia que pueda presentarse y desencadenar una interrupción en el proceso. Este es el plan que se sigue paso a paso durante la fase de transición final desde su inicio hasta la liberación para la operación.

Soporte

Para una mayor tranquilidad durante la primera semana de operación en la nueva plataforma es preciso estructurar un plan de soporte a usuarios finales donde se defina un plan de atención inmediato a las incidencias de acceso, conexión y experiencia que se les pueda presentar interactuando con la solución en el nuevo modelo de servicio.