Es una realidad que los procesos de desarrollo en sistemas legacy como el IBM i – AS/400 pueden representar un auténtico dolor de cabeza. Para cualquiera de las áreas, ya sea el área de desarrollo e infraestructura por ser una tarea titánica, y para las otras áreas de la empresa que no son de TI porque los cambios que les exige el negocio no se logran en tiempo y forma.
Cuando se tienen sistemas legacy pero no se cuentan con elementos de desarrollo tales como documentación, base de conocimiento, control de versiones, herramientas de colaboración, y demás, derivan en un sistema muy poco flexible que en la mayoría de los casos retiene el crecimiento del negocio. La diferentes unidades de negocio pierden la posibilidad de contar con aplicaciones clave para mejorar la operación, y la tecnología en vez de ser un aliado para potenciar el negocio se vuelve el enemigo de progreso.
Desafortunadamente, el IBM i ha sido un sistema que ha envejecido con complicaciones. Cada vez es más complicado encontrar personal que conozcan a profundidad este sistema, y los que están actualmente laborando se van retirando de la escena laboral paulatinamente. Lo que nos deja con un sistema que se dirige hacia una obsolescencia inminente. Dado el panorama, muchas empresas optan por dejar su sistema IBM i – AS/400 relegado, y comenzar a desarrollar de forma satelital en sistemas más “modernos y populares” tales como Linux, Windows, Unix y demás. Sin embargo, desarrollan satelitalmente aplicaciones pero no logran migrar la base de datos donde se encuentra el núcleo del negocio y la mantienen en el IBM i (DB2).
Desarrollar satelitalmente al IBM i – AS/400 constantemente deriva en un desorden que genera tecnología que funciona, pero que es complicada de mantener. A pesar de ello, parece ser la única solución posible para poder ofrecer tecnología vanguardista a las diferentes áreas de la compañía. Sin embargo, modernizar y mantener desarrollos en IBM i – AS/400 también es posible. Para poder ofrecer a las diferentes unidades de negocio tecnología flexible y en constante evolución, se debe implementar una cultura de continua integración, testeo y entrega de software en el IBM i (DevOps) y esto es algo totalmente posible.
En los últimos años DevOps ha tomado gran importancia en el mundo de TI, convirtiéndose en la principal metodología para desarrollar e implementar software. DevOps continúa transformando la forma en que las empresas desarrollan, implementan, monitorean y mantienen sus aplicaciones, acelerando el tiempo de entrega.
DevOps fusiona los equipos de desarrollo (Dev) y operaciones (Ops), permitiendo que las organizaciones creen vínculos más fuertes entre estos dos equipos y se tenga un desarrollo más rápido de las aplicaciones y un mantenimiento más sencillo de las existentes.
Si usted todavía no está convencido de la necesidad de adoptar DevOps en su proceso de desarrollo, aquí mencionamos algunos de sus beneficios:
La automatización de DevOps consiste en incorporar las tecnologías que ejecutan tareas con poca intervención humana en los procesos que facilitan y generan una mayor colaboración entre múltiples equipos de su empresa (producto, ingeniería, seguridad, TI, operaciones, etc.).
A través de la automatización se implementan las actualizaciones constantes de las aplicaciones en la producción con mayor rapidez, permite agilizar los procesos, ampliar los entornos y crear flujos de trabajo de integración, distribución e implementación continuas (CI/CD).
La mayor ventaja de DevOps es que obliga a las empresas a “optimizar todo el sistema”, no solo el área de TI, con la finalidad de mejorar el negocio en conjunto. En otras palabras, Al facilitar la relación entre varios departamentos se facilita el trabajo y se incrementa su calidad.
Las empresas que adoptan la metodología DevOps, obtienen mejores resultados en cuanto a la velocidad y estabilidad del desarrollo e implementación de software, y también logran el requisito de garantizar que su producto o servicio esté disponible para usuarios finales, con lo cual brinda un alto nivel de éxito en la entrega.
En la metodología DevOps el componente más importante son las personas, no las herramientas, y esto es porque las personas pueden aumentar en gran medida sus probabilidades de éxito. Dado que los sistemas automatizados son esenciales para el éxito de DevOps, un especialista en automatización puede desarrollar estrategias para la integración e implementación continuas, asegurando que los sistemas de producción y preproducción estén completamente definidos por software, y estos a su vez sean flexibles, adaptables y altamente disponibles.
Existen muchos desafíos en la transición a DevOps. Su empresa debe reestructurarse para mejorar la forma en que se va a trabajar. Sin embargo, las empresas subestiman la cantidad de trabajo requerido en una transformación DevOps. Según un estudio reciente de Gartner, el 75% de las iniciativas de DevOps hasta 2020 no alcanzaron sus objetivos debido a problemas relacionados con el aprendizaje y el cambio organizacional.
La clave para realizar una transición exitosa a DevOps es utilizar métricas para medir el progreso, documentar los casos de éxito y saber qué áreas necesitan mejoras. Para asegurar el éxito empresarial, ahora y a futuro, se deberá vigilar todas las métricas críticas para asegurar el progreso y dar seguimiento al desarrollo que se está implementando.
DevOps también enfrenta otros obstáculos. Dados los importantes cambios organizativos y de TI involucrados, de acuerdo a una encuesta a ejecutivos de TI, los principales desafíos para el éxito de implementación de DevOps son:
Los esfuerzos por implementar DevOps pueden verse envueltos en complejidad. Los líderes de TI pueden tener dificultades para expresar el valor comercial de su trabajo a los altos mandos de la empresa. También se enfrentan a que los equipos de trabajo presenten resistencia al cambio, desaprender muchos años de hacer las cosas de cierta manera, compartir sus prácticas y aprender de los demás, e integrar y orquestar las herramientas adecuadas puede volverse un problema.
Una metodología DevOps requiere cambios de metas y procesos. Las métricas de DevOps se complican o pueden fallar por razones como:
Evidentemente DevOps es una filosofía un tanto compleja para explicarla detalladamente en un único artículo. Lo que es una realidad es que cada vez se suman más profesionales especializados en DevOps y eventualmente habrá mucha oferta de personal en el mercado laboral. El mayor problema para el IBM i es que la gran mayoría de las herramientas que te ayudan a implementar DevOps (Jira, Github, Dockers, Jenkins, Selenium, etc) están hechas para ambientes open source y no para IBM i – AS/400.
Sin embargo, es aquí donde entran herramientas como ARCAD Software, la cual te provee de herramientas poderosas que hacen posible la adopción de DevOps en el IBM i – AS/400. Con Arcad, la compañía podrá contar con una herramienta muy poderosa que permite tener este flujo de continua integración, testeo y entrega de software que tanto hace falta en el IBM i. De igual manera, posibilita la opción de utilizar herramientas open source si es que ya las utilizas en tus otros sistemas, o si deseas comenzar a utilizarlas también.
Implementar DevOps en el IBM i es todo un reto y en muchas ocasiones resulta un proyecto tan abrumador que mejor se opta por no hacer nada. Contáctanos para poder hablar sobre este tema a detalle y encontrar la mejor forma de lograrlo en tu proceso de desarrollo. Sin duda es una tarea titánica pero no imposible.
