Gestión ajustada y automatización
Como se muestra en el número de E-3 de febrero de 2019 en la página 66, la idea DevOps tiene numerosos precursores y modelos a seguir, que influyeron principalmente en la C (Cultura), la M (Medición) y la S (Compartir) del concepto Calms. Pero al menos igual de importantes son los aspectos de Lean Management (L) y, sobre todo, la Automatización (A).
Aunque en la década de 1990 empezaron a surgir nuevos enfoques para desarrollar software de forma más rápida y flexible, hubo que esperar hasta 2009 para reunir todos los elementos de Calms en un único concepto.
El objetivo de este enfoque es conseguir que la colaboración entre desarrollo y operaciones de TI sea tan ágil y flexible como el propio desarrollo: Desde los primeros DevOps Days en Gante, las experiencias de desarrollo y de otras divisiones de la empresa se han agrupado en el concepto DevOps, como las recogidas en el manual DevOps.
Cambio de cultura a todos los niveles
La implantación de DevOps exige mucho de los implicados. Todos tienen que cambiar sus actitudes, expectativas y formas de trabajar. Así, en tiempos de DevOps, la era de los prestigiosos proyectos a gran escala ha terminado.
En su lugar, pasa a primer plano la gestión empresarial de un proyecto de desarrollo. Se da la vuelta a la cuestión básica: en lugar de preguntarse cuánto costará el proyecto, hay que definir qué funcionalidades de software nuevas o mejoradas pueden realizarse con un presupuesto determinado y manejable.
Si la respuesta está disponible, la dirección debe estar satisfecha con ella y confiar en que los participantes en el proyecto creen que se trata de objetivos realistas. Al mismo tiempo, hay que evitar el control detallado desde arriba.
"Lo que cuenta desde el punto de vista de la gestión es únicamente el resultado comparado con el plan, no el control de los pasos individuales. Esto es lo que se entiende por Lean en el concepto DevOps. Tanto los altos directivos como los jefes de departamentos especializados, que dependen especialmente de sus colegas de informática, deben someterse a este cambio de perspectiva".
recomienda James Roberts, Director Técnico de Basis Technologies.
Esto también supone un gran cambio para los gestores de lanzamientos. Ya no obtienen su reputación de presentar y gestionar grandes obras, sino de completar con éxito muchos proyectos pequeños, cada uno de ellos sólo para grupos de usuarios seleccionados en los departamentos especializados.
Dado que los proyectos individuales son gestionables, su comprensión de su papel debe cambiar de líder a entrenador, motivador y formador. También tienen que garantizar que la composición del equipo se mantenga estable a largo plazo.
El espíritu de equipo surge no sólo de la alineación en torno a un objetivo común, sino también de las relaciones fiables y de confianza entre los miembros del equipo. Dado que los grandes proyectos estratégicos en el mundo DevOps se dividen en muchos proyectos pequeños, iterativos y detallados, esto es estructuralmente posible.
Los miembros del equipo, a su vez, deben estar dispuestos a alejarse un poco de su especialidad y compartir sus conocimientos con todos los miembros del equipo. Sólo así podrán comprender mejor los retos de los demás.
Sólo a través del intercambio en el equipo aprenden los desarrolladores qué problemas plantean sus artefactos a los administradores de servidores, almacenamiento y otros, tanto a la hora de proporcionar el entorno de pruebas adecuado como de transferir los cambios al entorno de producción.
Este "compartir" (S) institucionalizado más allá del pensamiento y las fronteras de los silos es el aspecto que crea confianza a través del entendimiento y sienta las bases de la normalización: Normalización del enfoque, pero también de las herramientas con las que se trabaja.
Al comprender exactamente cómo funciona un entorno de pruebas y por qué sus colegas de la empresa han elegido éste y no otro, los desarrolladores pueden evitar desde el principio muchas reparaciones y riesgos en el posterior funcionamiento productivo.
Esto se corresponde exactamente con una de las ideas centrales del método de desarrollo ágil Scrum, según el cual los equipos interdisciplinares son capaces de producir mejor y más rápido productos nuevos y de alta calidad.
Esta doble estandarización es el requisito previo para el componente DevOps esencial de la automatización (A). Solo un entorno estandarizado para la supervisión, las pruebas y la garantía de calidad puede ofrecerse como un autoservicio con el que los desarrolladores puedan trabajar de forma independiente.
Si quieren probar un cambio de código para ver si realmente ofrece la nueva función deseada y qué impacto tiene en el sistema global, ya no tienen que esperar al equipo de operaciones, sino que pueden ponerse a trabajar directamente.
Las operaciones informáticas, por su parte, pueden concentrarse plenamente en la garantía de calidad de los cambios ensamblados en una versión y su aplicación en producción.
Para mejorar continuamente la interacción entre el desarrollo y el funcionamiento, la medición (M) de los parámetros también debe automatizarse.
Por ejemplo, evaluaciones de la rapidez y la puntualidad o información sobre la calidad, como el número de errores detectados y su evolución en el tiempo.
Acelerado a SAFe SAP
Es el cambio cultural el que provoca el cambio estructural, y no al revés. Al mismo tiempo, el cambio no tiene por qué venir de arriba al principio; al contrario, suelen ser las iniciativas de los desarrolladores afectados y de sus colegas en la empresa las que provocan la revolución DevOps a la manera de los movimientos de base.
Así lo demuestran una y otra vez los estudios, como el Informe sobre el estado de DevOps de 2018. Estos pioneros tienen tanto más éxito cuanto más manejable es la tarea que emprenden y cuanto más urgente es desde la perspectiva de la empresa o de un departamento especializado clave.
En esta fase, los clientes actuales de SAP pueden recurrir al concepto Accelerated SAP, que ya describe el trabajo ágil à la Scrum. Una vez que hayan demostrado la nueva cultura y su superioridad, pueden y deben implicar a la dirección a varios niveles y convertirlos en patrocinadores de la revolución DevOps.
Este apoyo desde arriba es crucial para el éxito. Porque los equipos de DevOps no pueden vivir en dos mundos al mismo tiempo, no pueden trabajar según el modelo de cascada por un lado y los métodos ágiles por otro, las pérdidas por fricción serían demasiado grandes.
Esto significa, en particular, que la dirección libera a los miembros de los equipos DevOps de sus tareas anteriores. Deben poder concentrarse por completo en los nuevos procesos y, posiblemente, en las nuevas herramientas.
De este modo, cada vez más áreas de TI pueden convertirse a DevOps pieza a pieza. Los gestores pueden encontrar una descripción de su nuevo papel en el marco Scaled Agile for Enterprises o SAFe de Scaled Agile, que guía no solo a los equipos individuales, sino también a todos los niveles de gestión por encima de ellos en la dirección de DevOps.
La confianza es clave, especialmente en el entorno SAP, donde la desconfianza hacia DevOps es quizá mayor debido a la complejidad y las dependencias internas y externas de los distintos componentes de los entornos SAP.
Los desarrolladores y administradores de SAP dependen, más que casi ningún otro grupo de las TI corporativas, no sólo de las relaciones personales, sino también de las herramientas que pueden ayudar a generar esta confianza.
Necesitan herramientas que puedan mapear de forma fiable todas las dependencias y poner a prueba las nuevas versiones, incluidos sus efectos en los entornos productivos.
Estas herramientas incluyen, en particular, herramientas para pruebas de regresión automatizadas. Las herramientas adecuadas cubren prácticamente todo el entorno productivo y, por tanto, ofrecen resultados tan próximos a la realidad que el código probado positivamente puede implantarse con un riesgo muy reducido.
Este es el requisito previo para la entrega de versiones en entornos SAP productivos a intervalos cortos. En la jerga de DevOps, esta cadena de entrega se denomina Continuous Delivery Pipeline o, en el marco SAFe, Agile Release Train con los pasos individuales de exploración, integración y despliegue.
Sin embargo, en caso de que surjan problemas como pérdidas de rendimiento o errores funcionales notables, estas herramientas de automatización también deben ofrecer la opción de hacer retroceder la versión sin interrupción, tal y como los usuarios están acostumbrados a hacer desde la nube.
Automatización
Si hay una falta de confianza en la automatización de la parte de operaciones, las operaciones son y siguen siendo el cuello de botella que impide la introducción de DevOps en el entorno SAP de una empresa.
¿No es de extrañar que muchos clientes actuales de SAP ya estén utilizando DevOps en sus TI, pero no en su propio entorno SAP, sino en soluciones de terceros?
Definitivamente, las herramientas de automatización desempeñan un papel más importante en los entornos SAP que en otras áreas. Es más, aunque la cultura se encuentre en los inicios de DevOps, la automatización es igual de importante en los entornos SAP.
