Implementar DevOps…y huir ágilmente
Un buen amigo mío (ajeno al entorno IT) me dijo hace no mucho, cuando le explicaba frente a un castizo vermú los modelos DevOps y lo positivo de su implementación, la frase de Peter Drucker «La cultura se come a la estrategia para desayunar», dejándome toda mi argumentación y capacidad de raciocinio reducida al tamaño de la aceituna que daba vueltas entre los hielos. Claro, cuando se plantea la evolución a DevOps como una estrategia y no como un cambio cultural, lo de «aquí siempre lo hemos hecho así…» o «si, si, pero ahora tenemos que cumplir los plazos, ya lo haremos en fase 2…» siempre se impondrá frente a las nuevas asunciones.
Creo que algo peor a que no te compren una idea o un proyecto es, que te la compren con matices del tipo «vale, pero que no sea demasiado disruptivo para los equipos» o con un «tú vete haciendo y que los demás te imiten…». Son los aspectos de Perogrullo que todos aprendemos en primero de consultor con las tan manidas bolitas solapadas: procesos, personas y tecnología. Ay, las personas…¡el eslabón más débil de cualquier cadena y a la vez el más difícil de romper intencionadamente!
Adoptar DevOps es mucho más que una magnífica consultora de primer nivel haciendo unos maravillosos tensores multidimensionales (cual concepto matemático) con los perfiles T, squads, teams, procesos, o mucho más que herramientas que faciliten en mayor o menor medida la ejecución de las tareas que tradicionalmente chocan entre Dev y Ops, poniéndolas en manos de Dev, pero que no pueden hacerlo sin Ops. Se trata de una auténtica transformación cultural, gradual, pero continua, con el objetivo en la mente del Centro de Excelencia DevOps futuro, y con el mecenazgo de la Dirección, que debe traspasar a las áreas de negocio en cómo hacer los productos. Y por supuesto, no es binario, puede haber proyectos tradicionales, con sus etapas de análisis, diseño, construcción y pruebas, y otros productos desarrollados con integración continua, despliegue continuo y todos sus artefactos de configuración y despliegue de infraestructura.
El problema, bajo mi punto de vista, es cuando DevOps se interpreta como una suite de herramientas que quitará de enmedio por fin a los talibanes de Ops o la excusa para desarrollar probando en producción, o cuando simplemente es una declaración de intenciones con muy buen principio pero que finaliza en un anti-patrón DevOps de los que nos advierte el autor de «DevOps Topologies». Es más, ni siquiera se adopta un modelo AGILE, sino una tergiversación diabólica consistente en decir agilidad cuando se quiere decir improvisación.
Por eso, cuando la cultura no pueda ser vencida por la estrategia, es preferible quedarse mirando la aceituna del vermú…al menos sabemos cómo acabará. Y remitiéndonos al título, cuando la transformación organizacional para adoptar DevOps no esté garantizada, huye ágilmente.
Miembro del Grupo de TRabajo ITSM4DevOps del Comité de Estándares de itSMF España