De que ITIL es un castillo medieval, DevOps es los Borg de Star Trek y de cómo la historia se repite

Gracias a Juanjo Figueiras llegué a un curioso post que clasificaba los sistemas en frágiles, robustos y anti-frágiles:
– Frágiles, lo que todos conocemos, sistemas programados a lo pistolero a los que no hay por donde poner ya orden.
– Robustos, sistemas construidos y gestionados con ITIL. Son como castillos medievales, robustos, pero inamovibles e inflexibles.
– Los anti-frágiles, son los sistemas DevOps (te dejo un post sobre qué es DevOps) son como el colectivo Borg, el de Star Trek. Un colectivo cuyo objetivo es el descubrimiento de nuevas vidas y nuevas civilizaciones para mejorar la sociedad. Con cada cambio y adaptación del sistema (el colectivo Borg) se hace más resistente y evoluciona. Las organizaciones anti-frágil aceptan los cambios, y no se esconden detrás de los muros del castillo.
Hay varios post en otros tantos blogs hablando del tema, todos ellos desde el punto de vista de sistemas (no tanto desde desarrollo), y todos ellos plagados de comentarios a favor y en contra de ITIL o de DevOps, y que si la culpa no es de ITIL, que si es de quien lo mal implementa, etc.
Mientras leía lo anterior, no dejaba de pensar, pensaba y pensaba… -esto me suena-, y mira tú que intentaba recordar de qué, pero no caía, -mmm esto yo ya lo he vivido-, pero nada, – será un déjà vu-, -será la edad-, hasta que…. –aaaahh caí, ya lo tengo, esto es lo mismo que pasaba (pasa) en las milenarias conversaciones (discusiones) de que si CMMI o que si lo ágil, pero ahora donde pone CMMI se pone ITIL y donde ágil se pone DevOps-. Que alivio. Digo alivio por haberlo recordado, claro… vaya si se me olvida.
La agilidad llegó primero al mundo del desarrollo software, y posteriormente está llegando al mundo de sistemas, bajo el nombre, y con sus particularidades, de DevOps. Antes de que la agilidad se popularizara en desarrollo, modelos de procesos como CMMI-Dev habían sido populares.
En el mundo del desarrollo el enfrentamiento lo provocó principalmente la mezcla de aquellos que no sabían evaluar CMMI de manera pragmática y útil para las empresas (conviene recordar aquello de el AUDITATOR TIC esta ahí fuera. No se puede razonar con él. Si estás a tiempo huye (o finge una baja de unos días), con aquellos que no sabían implantarlo, ni diferenciar un modelo de procesos de una metodología (¿CMMI o Métodos Ágiles?) con los que prometían que con lo ágil tendríamos el proyecto perfecto sin esfuerzo, sin documentar, sin tomar requisitos, sin salir de casa, sin frotar, ni alcarar, etc.
Afortunadamente, en el mundo de desarrollo esa época de confusión pasó (desgraciadamente no para todos) y muchos han sabido quedarse con lo mejor de cada casa y evitar lo peor de cada cosa.
Y parece que ahora la historia comienza en el mundo de sistemas….
Me encantaría escuchar tu opinión sobre este tema….

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “De que ITIL es un castillo medieval, DevOps es los Borg de Star Trek y de cómo la historia se repite”

  1. La mejor definición de ITIL que escuché en mi vida fué precisamente en mi certificación: «ITIL es implementar y cumplir lo que proveedor – cliente pacten en un contrato (SLA), al menor coste posible», eso me parece de todo menos inflexible, tampoco implica que sean sistemas robustos, serán tan robustos como marque el SLA, por ejemplo, si no se acuerda high availability el sistema no será robusto, pero es lo que se ha acordado. ITIL es en término de la edad media, un pacto entre caballeros.

  2. Interesante post. Es como dices, es revivir la historia pasada sobre Agile vs metodologías de desarrollo tradicionales. Ahora pienso lo mismo que entonces. No es una contra otra, es una con otra. No todos los sistemas, equipos de trabajo o problemáticas se cubren en forma completa con Agiles, así como tampoco pasa lo mismo con Devops.
    La cuestión es tomar lo mejor de cada mundo, saber cuando aplicar una y cuando otra, pero no perder el foco en el aseguramiento de la calidad y el servicio.

  3. Interesante post, comentas sobre muchos comentarios sobre DevOps en sistemas… pues llevo un tiempo buscando y no encuentro tantos cómo comentas, si puedes compartir sería genial.
    Por otro lado lo que creo que todas estas metodologías o frameworks tienen en común … coge lo que te interesa y descarta el resto, en cada casa sabes qué funciona y qué no o por lo menos qué estás dispuesto a probar.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *