DevOps versus Bimodal IT

Hace un tiempo, reflexionaba yo sobre la viabilidad de aplicar metodologías Agile de forma generalizada en una empresa compleja con un mapa de sistemas complejo.

Y mi sensación, que en el fondo todavía mantengo, es que la aplicabilidad de Agile no es el todo general, que los proyectos más complejos precisan algo más de planificación y visión a largo plazo, y un ciclo de vida que, al menos al principio, no se adapta a la velocidad y metodología de Agile. Pensaba yo que ciertos proyectos deben seguir una gestión de proyectos más tradicional (en general los más complejos y los que más determinan la arquitectura y mapa de sistemas) y otros, sin embargo, se beneficiaría de un enfoque agile (aquellos de planteamientos funcionales más sencillos, con mayor orientación hacia el cliente y con más peso en los aspectos de interfaz de usuario).

Y en eso descubrí el concepto de Bimodal IT, creado por Gartner y que se parecía mucho a lo que yo había pensado. Bimodal IT distingue, en efecto, dos tipos de proyectos y dos formas de gestionarlos. 

Los sistemas que se denominan 'sistemas de registro ('record systems'), es decir, los que soportan la columna vertebral de los procesos y datos corporativos, se gestionarían en el modo 1 según el modelo en cascada más tradicional y buscando sobre todo la fiabilidad. 

Los sistemas que denominan de relación ('engagement system'), los dedicados a interaccionar con el cliente y crear un vínculo con él, se gestionarían en el modo 2, que sería 'agile' y donde lo que primaría sería la velocidad y capacidad de respuesta.

Me encuentro ahora leyendo 'The DevOps Handbook' para profundizar en DevOps que, como ya vimos, es heredero de, aunque no se limita a, la filosofía agile. Y veo que uno de sus autores, Jez Humble, hace poco más de un año dedicó en su blog, 'Continuous Delivery', un post en que criticaba esa filosofía promovida por Gartner.

Tres son los argumentos que esgrime Jez Humble en contra de Bimodal IT

• Reduccionismo: Opina Humble que es una simplificación el pensar que con esos dos modos se resuelve toda la problemática.


• Acoplamiento entre los sistemas de registro y los de interacción: Afirma en este sentido Humble que la modificación de un sistema de relación (modo 2) suele precisar de modificaciones en los sistemas de registro (modo 1), por lo que no es correcta una separación drástica entre ambos tipos de sistemas y entre ambos modos.


• La fiabilidad no está reñida con la velocidad: Aquí, Humble va más allá y, por decirlo de alguna manera, 'niega la mayor': no es cierto que la fiabilidad esté reñida con el tiempo de respuesta. Jez Humble entiende que DevOps da respuesta a ambas necesidades y, por tanto, no es necesaria la famosa gestión bimodal.

Jez Humble en acción

Finaliza Humble su artículo en un tono algo más conciliador y entreve que, quizá, la gestión bimodal sea útil como un primer paso, en el caso de empresas con una gestión muy tradicional, para acercarse a DevOps. Un primer paso que en opinión de Humble no puede exceder de unos meses.

Un debate, en cualquier caso, muy interesante y más que necesario y realista. Mi experiencia me lleva a estar más cerca del modelo de Gartner... y mi esperanza a estar más cerca de Jez Humble y DevOps.

¿Conclusión?

Supongo que no hay otra: debemos aspirar al modelo DevOps, pero ser muy realistas y cuidadosos en la transición... y ser muy conscientes de la realidad (la realidad, no la aspiración) de nuestras compañías. Quizá no estemos tan cerca de un DevOps o un Agile como quisiéramos...