Si la cultura funciona, también lo hace la tecnología

El movimiento DevOps -una combinación de cultura, práctica y herramientas que ayudan a las organizaciones a entregar aplicaciones y servicios a muy alta velocidad- está muy influido por el concepto CALMS, que significa Cultura, Automatización, Lean, Medición y Compartir.

La cultura y el intercambio -podría y debería decirse más bien la comunicación en el caso de este último- están al principio y al final, forman el marco de todo el concepto, por así decirlo. Pero, ¿por qué ambas partes -desarrollo y operaciones- tienen que aprender a hablar más entre sí? La pregunta puede parecer ingenua en el mejor de los casos, superflua o incluso tonta en el peor.

Y, sin embargo, ha surgido una y otra vez desde el colapso del bombo de Internet en 2000 y 2001. A raíz de ello, se habló mucho de la industrialización de las TI, también en SAP. Desde entonces, la tecnología ya no se consideraba un fin en sí misma, sino que tenía que servir a la empresa y subordinarse a sus necesidades.

Normas como ITIL (Biblioteca de Infraestructura de TI; recopilación de mejores prácticas para la gestión de servicios) se convirtieron en el centro de atención de muchos clientes de SAP, con la ayuda de las cuales la TI debía alinearse de forma coherente con el negocio.

Y, sin embargo, el debate está estallando de nuevo con toda su fuerza desde que las TI corporativas están siendo desafiadas por los grandes proveedores de la nube. Son sobre todo los usuarios quienes hacen sentir a sus colegas informáticos su descontento con su trabajo.

Porque esperan el mismo nivel de disponibilidad, rapidez, sencillez y comodidad al que se han acostumbrado como consumidores. Es casualidad que en el Manifiesto Ágil, una especie de carta magna para el desarrollo ágil de software, la orientación al cliente ocupe el primer lugar de la lista?

Así pues, cada vez está más claro que ITIL no ha cumplido todas o incluso muy pocas de las expectativas que se le habían atribuido. Pero, ¿cuál es la razón? En efecto, ITIL consiguió acercar la TI a la empresa. Pero la TI inherente

El conjunto de normas no puede resolver la contradicción entre desarrollo y explotación. Al fin y al cabo, la tarea fundamental de los desarrolladores es responder a los cambios en los requisitos de la empresa lo más rápido y bien posible y ponerlos en práctica.

Por otro lado, la tarea fundamental de las operaciones de TI es garantizar la estabilidad y fiabilidad de los servicios de TI que se ven comprometidos por los cambios en el código del programa. Sin embargo, ITIL nunca se diseñó para resolver este conflicto fundamental de objetivos, mientras que los grandes proveedores de nube parecen estar consiguiéndolo.

Confianza en lugar de miedo

La mayoría de las empresas están organizadas según el principio de la división del trabajo. Cada uno es experto en su campo y domina de memoria las tareas de su área de responsabilidad. Pero como sólo los expertos en un mismo campo hablan el mismo idioma, surgen a su alrededor muros invisibles que van de la mano de la barrera lingüística.

Unas pequeñas puertas entre ellos permiten entregar los resultados del trabajo. Lo que ocurre dentro de las paredes permanece invisible para los demás. Quien ha entregado sus resultados está libre de responsabilidad y no tiene que preocuparse por el resultado global: el modelo de cascada perfecto.

"En los proyectos organizados según este modelo, los miembros individuales del equipo suelen centrarse casi exclusivamente en el éxito de sus respectivas tareas, no en el éxito del conjunto.

Cuanto más amplio y estratégico sea el proyecto, más probable es que se acepten los errores o retrasos que casi inevitablemente se producen para cumplir, al fin y al cabo, los objetivos primordiales y los compromisos con los departamentos especializados".

James Roberts, Director Técnico de Basis Technologies, lo sabe por experiencia.

"Desgraciadamente, vemos este planteamiento con los clientes actuales de SAP una y otra vez y todavía con bastante frecuencia".

Allí donde las fronteras de los silos forman parte de la vida cotidiana, los desarrolladores SAP y sus colegas de operaciones informáticas no se comunican entre sí, o al menos no lo suficiente. Los primeros son responsables de los cambios, la personalización, etc., y entregan los resultados de su trabajo sin entender ni comprobar si contienen problemas para sus colegas de la administración de servidores, almacenamiento o redes, del control de calidad o de la gestión del entorno de pruebas.

Si el software no funciona como se espera, los desarrolladores no se responsabilizan, mientras que el departamento de operaciones de TI tiene mucho trabajo buscando soluciones para minimizar el número y la duración de las interrupciones.

Los desarrolladores, por su parte, ven interrumpido su trabajo una y otra vez cuando no pueden probar sus artefactos inmediatamente, sino que tienen que abrir tickets y esperar a que el entorno de pruebas adecuado esté listo para ellos desde el punto de vista técnico y temporal. Ambas partes están insuficientemente satisfechas con el trabajo de sus colegas. Así, el silencio amenaza poco a poco con convertirse en desconfianza.

Con una cultura de este tipo y las estructuras correspondientes, las expectativas de los usuarios no pueden cumplirse en la era de la nube. Las empresas tienen que encontrar la manera de pasar de una cultura de desconfianza a una cultura de confianza.

Unas pruebas de regresión automáticas adecuadas, que permitan reorientar el control de calidad hacia el desarrollo, como en el caso de las pruebas shift-left, podrían remediar en gran medida esta situación.

Corregir errores e incorporar cambios a corto plazo en los requisitos incluso antes de que una nueva versión salga al mercado suele ser entre 20 y 40 veces más barato, especialmente en el entorno SAP.

Fabricación de modelos

Puede resultar sorprendente, pero la idea de una mejor cooperación, por ser responsable y basarse en la confianza, es mucho más antigua que la industria informática. Se aplicó por primera vez en la industria manufacturera, hace unos ochenta años. Porque, evidentemente, los problemas de la división del trabajo y el especialismo son tan antiguos como éstos, y no producto de las nuevas tecnologías y formas de trabajar.

En respuesta a estos problemas, el físico y estadístico Walter Shewhart desarrolló el bucle de control PDSA (Planificar-Hacer-Estudiar-Actuar), que el alumno de Shewhart, William Edwards Deming, amplió hasta convertirlo en teoría.

Sin embargo, el programa de gestión desarrollado por el ingeniero y doctor en física matemática no encontró inicialmente usuarios ávidos en Estados Unidos, sino en el Japón de posguerra.

El sistema de producción de Toyota, que convirtió a la empresa en el mayor fabricante de automóviles del mundo en tan sólo unas décadas, ejemplifica la influencia de las ideas de Deming, que sólo fueron percibidas y aplicadas parcialmente por un público más amplio y, en especial, por los directivos de EE.UU. en la década de 1980.

Conceptos como la gestión de la calidad total, en la que la calidad se mide en todo momento y en cada punto de la cadena de procesos, en contraste con el muestreo aleatorio, o la producción justo a tiempo, ahora universalmente conocida y practicada, representan este cambio de percepción.

Lo más destacado y revolucionario de este planteamiento era que cada uno no sólo era responsable de su área, sino que la calidad en cada paso se hacía transparente para todos y especialmente para la dirección.

El principio subyacente: Los errores ocurren. Pero si no se detectan o sólo se identifican al final del proceso de producción, puede ser demasiado tarde para tomar medidas correctoras o puede resultar muy laborioso y costoso, tanto en tiempo como en dinero. Además, faltan los puntos de medición que permiten realizar evaluaciones para mejorar continuamente el proceso.

Todo continuo

Los métodos de aseguramiento y mejora continuos de la calidad son habituales desde hace tiempo en la industria manufacturera. Su base es la responsabilidad, la transparencia, los ciclos cortos y la orientación al equipo, que se trasladan al mundo de las TI de forma muy similar gracias a DevOps.

La integración continua, las pruebas continuas, la entrega continua y la mejora continua son elementos de un enfoque DevOps de éxito. Esto persigue el objetivo de que cualquier cambio esté disponible tan pronto como lo esté, sin riesgos e idealmente sin intervención humana.

Las formas de trabajar y las funciones deben adaptarse en consecuencia para lograr realmente los resultados que son posibles con DevOps, como ya ha sucedido en la fabricación.

Hay que derribar los silos y sustituir los ámbitos de responsabilidad claramente definidos por el trabajo en equipos multidisciplinares. Con un único objetivo en mente: mejorar la colaboración. Es la clave para alcanzar los objetivos empresariales definidos a través de DevOps.

La cultura, como ya se ha mencionado, es de hecho una parte esencial del concepto DevOps y afecta en particular a los componentes C, M y S del enfoque CALMS. No se pierda la segunda parte del artículo en el próximo número, que trata del impacto de la automatización (A) y la gestión ajustada (L) en las estructuras y procesos de trabajo. También aprenderá más sobre el papel que desempeñan diversas herramientas para hacer de DevOps una norma sencilla incluso en entornos SAP complejos.