La larga espera entre el lanzamiento de ITIL 3 e ITIL 4, junto con el aumento de DevOps y las prácticas de gestión de la nube, ha amenazado la relevancia de ITIL.
Si bien ITIL todavía tiene un hogar en muchas empresas, otras han restado importancia al marco ITSM de larga data a favor de DevOps o prácticas propias. La pregunta para muchas empresas es si deben elegir ITIL frente a DevOps, o si pueden desempeñar roles efectivos uno al lado del otro.
Nota del editor: Este artículo se publicó originalmente en marzo de 2020 y se actualizó en diciembre de 2021.
¿Qué es ITIL?
El marco de gestión de servicios de TI de ITIL surgió en la década de 1980 cuando los centros de datos se descentralizaron y adoptaron arquitecturas más diversas, lo que provocó discrepancias en los procesos e implementaciones y servicios de TI inconsistentes o subóptimos. Es un conjunto de pautas y mejores prácticas diseñadas para estandarizar la forma en que las empresas seleccionan, planifican, brindan y mantienen los servicios de TI, y para mejorar la eficiencia y la previsibilidad de la entrega de servicios de TI. ITIL también ayuda a alinear las acciones y los gastos del departamento de TI con las necesidades del negocio y cambiarlos a medida que el negocio crece o cambia de dirección.
ITIL v4, lanzado en 2019, anima a las organizaciones a evaluar e implementar los aspectos que son más importantes para sus necesidades e integrar la gestión de servicios de TI con otras áreas del negocio. Los principios de ITIL 4 también abordan prioridades alineadas con marcos como DevOps y Agile: enfoque en el valor, progreso iterativo, colaboración, visibilidad y transparencia, simplicidad y automatización.
¿Qué es DevOps?
DevOps se refiere en términos generales a una colección de prácticas y herramientas que combinan el desarrollo de software y las operaciones para acortar los ciclos de vida y respaldar la entrega de desarrollo continuo. El proceso de DevOps es básicamente un bucle infinito de pasos: planificar, codificar, compilar, probar, lanzar, implementar, operar, monitorear y, a través de la retroalimentación, planificar nuevamente.
Desde una perspectiva, DevOps es una filosofía que fomenta la cooperación y la colaboración entre los dos grupos de TI históricamente divididos y en silos: los desarrolladores de aplicaciones y los equipos de operaciones de TI. Desde otro punto de vista, DevOps es una cadena de procesos que combina metodologías de integración continua y entrega continua o implementación continua para crear e implementar aplicaciones de manera eficiente. Una interpretación más restringida de DevOps es la adopción de herramientas, automatización e infraestructura programable para implementar código listo para producción en un calendario de lanzamiento rápido.
Cómo ITIL se quedó atrás de DevOps
Históricamente, algunos han criticado a ITIL como una lista de verificación rígida de prácticas prescriptivas que es demasiado difícil de manejar, extensa y requiere mucho tiempo, y fácilmente interrumpida por necesidades e iniciativas a corto plazo. La larga espera de ITIL v3 a ITIL 4 impulsó aún más las preguntas sobre la agilidad y la capacidad de respuesta de ITIL como estándar para las tecnologías emergentes y los desafíos operativos, así como sobre la organización que lo respalda.
ITIL cayó en una grieta burocrática durante el lapso de ocho años entre la versión revisada de ITIL 3 (también conocida como ITIL 2011) e ITIL 4. Una explicación del retraso fue el cambio de propiedad de ITIL. Su propietario inicial, la Agencia Central de Informática y Telecomunicaciones (CCTA) del Reino Unido, una agencia gubernamental que brindaba soporte de TI y telecomunicaciones, se fusionó con la Oficina de Comercio Gubernamental. En 2013, Axelos, una empresa conjunta entre Capita, una empresa de servicios profesionales, y la oficina del gabinete del Reino Unido, tomó posesión de ITIL.
Sin DevOps o mensaje en la nube de ITIL durante esos años, las organizaciones buscaron otros marcos. Su opción era adoptar DevOps o desarrollar otros procesos internamente, especialmente cuando las empresas se enfrentaban a la presión de cumplir con las expectativas de los clientes en torno a la entrega rápida de nuevas aplicaciones y funciones. Ciertamente, el limbo de ITIL desencadenó algunos choques culturales en el camino, ya que los incondicionales de ITIL intentaron aferrarse a la metodología mientras las operaciones de TI y las pilas de tecnología cambiaban rápidamente a su alrededor.
Durante esa larga espera entre ITIL 3 y 4, las organizaciones también desarrollaron estrategias de migración a la nube. Los modelos de gestión de la nube comenzarían como ad hoc, pero madurarían gradualmente hasta convertirse en enfoques de gestión de servicios más formales. Los primeros en adoptar la nube podían iterar y aprovechar las lecciones aprendidas sin las restricciones arbitrarias de una metodología de la industria. Si bien algunas prácticas de administración de la nube tienen sus raíces en ITIL, fueron moldeadas en gran medida por los primeros en adoptar, los proveedores de servicios en la nube, los integradores de sistemas y los proveedores de plataformas de administración de la nube (CMP) de inicio.
ITIL 4, incluso con algo de soporte en la nube y DevOps, entró en un mercado en el que las organizaciones ya estaban haciendo ambas cosas. Por ejemplo, las prácticas de ITIL 4 aún impulsan el comando y el control de arriba hacia abajo, mientras que DevOps fomenta un equipo empoderado. Además, las organizaciones comenzaron a poner a prueba las estrategias de integración continua / desarrollo continuo (CI / CD), mientras que otras estaban en sus iniciativas de nube y DevOps basadas en contenedores, microservicios y computación sin servidor.
Además, las 34 prácticas y las cuatro funciones centrales de ITIL 4 aún fomentan los silos operativos y de datos, que mantienen separados a los equipos de desarrollo y operaciones. Esta es una gran diferencia entre ITIL y DevOps, ya que este último tiene como objetivo romper los silos para mejorar la colaboración, la resolución de problemas y los informes durante todo el ciclo de vida de la entrega del producto.
Todos esos factores se suman a esto: muchas organizaciones tienen menos probabilidades de reescribir los procesos de gobierno y administración para ITIL 4, particularmente cuando ya gastaron dinero y tiempo en la elaboración de sus propios procesos.
ITIL vs.DevOps: ¿Pueden coexistir?
Para muchos, la falta de sinergia entre ciertas prácticas de ITIL y DevOps las hace fundamentalmente incompatibles. Otros aún afirman que los dos marcos pueden y deben coexistir: ITIL establece procesos para gobernar la prestación de servicios y DevOps les infunde agilidad, automatización y colaboración en equipo.
La mayoría de las empresas tienen una combinación de infraestructuras heredadas y modernas. ITIL refuerza la estabilidad y confiabilidad que se adaptan especialmente a los sistemas heredados, mientras que la velocidad de DevOps brilla con arquitecturas distribuidas, en contenedores y en la nube. ITIL y DevOps están comenzando a compartir puntos en común: ITIL 4 finalmente comenzó a abordar las prácticas de TI modernas, incluida la automatización, los contenedores y los microservicios.
Desafortunadamente, la elección de ITIL o DevOps puede convertirse en un conflicto de esto contra aquello debido a la política corporativa y las diferencias culturales. Por ejemplo, los ejecutivos de back-office a menudo prefieren ITIL para su regulación e informes, pero los equipos de desarrollo y operaciones necesitan la integración continua / el desarrollo continuo que DevOps proporciona para mantenerse al día con las demandas de los clientes. La supervisión rígida y los gastos generales de ITIL pueden obstaculizar los proyectos y la moral de los empleados tanto como la microgestión, mientras que DevOps resuelve rápidamente esos problemas a través de iteraciones y (idealmente) autopsias sin culpas.
Para que DevOps e ITIL coexistan, una empresa necesita campeones que puedan salvar estas brechas organizacionales, de modo que las organizaciones puedan elegir las mejores prácticas que ofrece cada metodología.
Gestión de la nube como término medio
Muchas organizaciones que priorizan la nube han recurrido a los CMP como la única plataforma importante de gestión de servicios que necesitan, y algunas empresas también han adoptado CMP como una clase de gestión de servicios. Un CMP elimina la complejidad de las tareas de operaciones en la nube y admite una variedad de opciones de informes personalizables. La implementación de un CMP también permite a los equipos utilizar datos operativos para seguridad e inteligencia operativa procesables.
Algunas empresas abandonan ITIL por un CMP y un proceso creado internamente. Por ejemplo, las organizaciones escriben sus propios procesos y marcos de gestión de la nube que pueden incluir ITSM. Los CMP administran los activos y recursos de TI en entornos de múltiples nubes. Las funciones de administración de costos de CMP también ayudan a las organizaciones a optimizar el gasto en la nube y eliminar el desperdicio de recursos. Además, estas herramientas garantizan el cumplimiento de la configuración unificada y el monitoreo de la actividad, y automatizan las tareas clave de administración y operaciones de la nube para mejorar la productividad y la eficiencia de las iniciativas de la nube.
Es posible que una empresa determinada trabaje tanto con ITIL como con DevOps a pesar de sus diferencias inherentes, pero tal hazaña requiere un puente entre culturas. Los defensores de ITIL deben ver que adoptar la agilidad de DevOps no significa renunciar al control. Del mismo modo, los proponentes de DevOps deben aprender que los principios de gestión de servicios no equivalen a «prevención empresarial».
Sin embargo, para muchas empresas, el compromiso es adoptar principios de gestión de servicios mediante la creación de sus propias mejores prácticas internas o el aumento de su plataforma de gestión en la nube con la nueva generación de prácticas DevOps.
