En el AWS Cloud Experience realizado recientemente en Santiago de Chile, empresas como Cencosud destacaban que actualmente podían llegar a desplegar decenas de cambios a producción diariamente. A su vez, el mismo Amazon informaba también la enorme cantidad de cambios que se realizan a diario en su portal Amazon.com, todo esto gracias a los nuevos enfoques ágiles y las arquitecturas basadas en microservicios.
En contraparte, si revisamos empresas tradicionales como el sector financiero e, incluso, compañías del sector industrial, hoy en día se pueden encontrar con infinidades de situaciones en donde los encargados de la gestión de cambios pueden rechazar una solicitud por falta de un documento. Una vez superado esto, los entes responsables de Operaciones, Seguridad TI y Riesgo Tecnológico emplean sus mejores argumentos para intentar evitar que desde el Área de Desarrollo de Software se despliegue alguna pieza de software en producción.
Esto se debe a que la gestión de cambio requiere de documentación y varios niveles de autorización dependiendo del impacto con el que está catalogada una solicitud. Por su puesto, un RFC (Request for change) clasificado de alto impacto requerirá mayores autorizaciones y documentos que los soporten, mas no una solicitud estándar que necesitaría menores aprobaciones.
Si nos concentramos en el concepto de DevOps, veremos que es un enfoque que resulta muy atractivo para los que trabajamos en TI: Operaciones y Seguridad trabajando de la mano con el equipo de desarrollo desde un inicio, quienes, en combinación con herramientas de automatización correctas, garantizan agilidad en los desarrollos, pruebas, integración y en el despliegue. Pero es justamente en esta etapa donde se encuentran los principales obstáculos para cambiar viejos estilos de trabajo.
En el despliegue continuo planteado por DevOps, el software se construye de tal manera que pueda ser liberado en producción en cualquier momento, sin tener que esperar el día de la semana correspondiente al CAB (Change Advisory Board). Esto pareciera indirectamente causar el derrumbe de lo planteado por la gestión de cambios de ITIL.
A pesar de todo, esta gestión de cambios ha existido por muchos años, porque además de generar estabilidad en el proceso, permite auditar cada cambio, muy necesario sobre todo para organizaciones que tienen regulaciones gubernamentales. DevOps por su lado, en la búsqueda de acelerar el proceso de cambio, podría estar omitiendo éste y otros importantes puntos.
Iniciar con el enfoque DevOps requiere un importante cambio organizacional, en donde se dé prioridad a los despliegues por sobre la protección del ambiente productivo, pero debemos considerar que esto no se puede realizar eliminando de raíz los procesos actuales en la empresa.
Haciendo importantes cambios en la definición del CAB, las modificaciones correctas y eliminando cosas innecesarias en el proceso de autorizaciones y documentación, se generará mayor confianza en los responsables de la gestión de cambio, lo que traerá como consecuencia que, solicitudes que antes se consideraban críticas, se empiecen a clasificar como estándar, agilizando el cambio y permitiendo el despliegue continuo.
Esta libertad de movimientos no debe estar reñida con el rigor en los objetivos y las métricas. Al fin y al cabo, detrás de todo proyecto TI hay un cliente al que servir. Se trata de ser más ágiles, no menos rigurosos. La implicación del cliente es fundamental, ya que el prototipado será continuo en todas las fases y los requisitos tendrán que ir ajustando sus prioridades con la misma agilidad con la que se ofrecen los resultados.
