En este primer diálogo hablamos con Carlos Guardiola y Francisco Maregil, miembros del Comité de Marketing y Eventos y responden a cuestiones relativas a la Asociación, la agilidad empresarial así como uno de los conceptos asociados a la misma: DevOps.
Carlos L. Guardiola Ortuño
Francisco J. Maregil Nieto
La tecnología avanza a pasos vertiginosos. La agilidad empresarial en esta constante evolución es una premisa que se ha impuesto. BAC es una asociación que se ha creado al hilo de dicha premisa. ¿Cuáles considera que son las mayores necesidades del mercado empresarial español (medianas y grandes empresas) en este sentido?
Carlos Guardiola: “Los retos a los que se enfrentan las medianas y sobre todo las grandes corporaciones en la agilidad empresarial tienen particularidades respecto a pequeñas organizaciones y Start-ups. La gestión de los sistemas legados, el foco y la presión regulatoria y el escalado necesario para que la transformación sea efectiva a nivel global son algunos de ellos. El mercado de grandes y medianas organizaciones debe tener respuesta a estos retos particulares y en ellos se focaliza nuestra asociación mediante la compartición de experiencias.”
¿Qué objetivos se han propuesto a corto plazo?
Francisco Maregil: La BAC nace con la visión de ayudar a las grandes y medianas corporaciones a detectar y responder a los cambios con rapidez y confianza. Con esta visión queremos proporcionar un marco de colaboración para desarrollar y difundir modelos y herramientas de agilidad empresarial. A corto plazo se ha traducido en la realización de eventos como el Congreso BAC (https://businessagilitycorp.com/congreso-bac-2016/) y los desayunos de trabajo que estamos organizando entre los socios para compartir las experiencias de éxito y los retos que se han tenido que afrontar. Aprovechamos para animar a otras grandes corporaciones que estén abordando esta transformación hacia la agilidad empresarial a incorporarse a la asociación.
Para lograr la agilidad empresarial combinan varias metodologías, entre ellas DevOps. ¿Qué diferencias encuentran entre esta y el resto de metodologías que aplican? ¿DevOps por sí sola es suficiente para conseguir resultados óptimos en una organización?
CG: Dentro de la Asociación, estamos incorporando diferentes perspectivas de agilidad empresarial. Estas abarcan las siguientes:
- Las utilizadas por las áreas de negocio para detectar y comprender mejor las necesidades del cliente y usuario final (técnicas de Design Thinking incluyendo mapas de empatía, el viaje del cliente, el prototipado, etc.)
- Las utilizadas por los equipos de diseño, construcción y operación de productos mediante prácticas ágiles (Agile y DevOps) que permiten lanzar al mercado las soluciones en tiempos antes inalcanzables y recibir el feedback de los usuarios para mejorarlos en ciclos mucho más cortos.
- Enfoques globales de búsqueda de eficiencia y mejora continua que permiten a los equipos enfocarse en las labores que realmente generan aportan valor y eliminar desperdicios (usando técnicas de la filosofía Lean).
Todas estas prácticas están ayudando en hacer realidad la transformación digital de grandes organizaciones cuya capacidad de adaptación era antes más compleja dado su tamaño.
La principal diferencia entre la aproximación DevOps y el resto de prácticas ágiles es que DevOps es la única que incide directamente en la entrega de sistemas para que estén disponibles para el cliente / usuario. Todas las demás aplican al diseño o construcción de un producto o sistema adaptado al cambio (por tendencias del mercado, nuevos intereses de los consumidores, etc) y DevOps y es la práctica que transmite la agilidad a la hora de que esas soluciones lleguen al mercado. De manera que el ciclo de evolución del diseño del producto, el de construcción y el de entrega estén alineados.
Por tanto no es suficiente en sí misma, y de hecho en nuestra experiencia, suele ser la última técnica Agile que se aplica. Ya que por lo general la aproximación ágil / LEAN al diseño de productos o servicios es el primer punto de interés de las áreas de negocio que ven cómo los cambios en sus sectores o la entrada de terceros (p.e., el ecosistema FinTech) les obliga a replantear su aproximación a la creación de valor para sus clientes.
¿Cómo trabaja su asociación? ¿Cómo se adentran en el mundo empresarial y cómo van a conseguir los objetivos que persiguen?
FM: La Asociación nació a principios de 2.016. Su origen está en la puesta en común de algunos profesionales de grandes corporaciones de los retos que suponen estas prácticas en sus organizaciones y la ayuda que supondría un foro para compartir estas experiencias (https://businessagilitycorp.com/agilidad-empresarial/). Progresivamente más compañías se fueron uniendo a la misma y se lanzó un I Congreso de Agilidad Empresarial que supuso un gran éxito en este objetivo de foro de colaboración. Actualmente la asociación dispone de Comités de Eventos y Conocimiento que organizan diferentes actividades (webinars, desayunos, “Lean Coffee”, etc.) en las que cada vez más socios pueden aprovechar la ventaja del conocimiento y experiencia adquirido en diferentes organizaciones.
¿Qué representa DevOps en la Transformación Digital de las empresas?
CG: DevOps ayuda a las organizaciones a afrontar la “última milla” en el lanzamiento de sus productos y servicios digitales. En las organizaciones de tecnología de grandes organizaciones suele existir barreras organizativas entre los departamentos de desarrollo, pruebas, operaciones e infraestructuras tecnológicas. DevOps persigue romper estos muros mediante una visión extremo a extremo del flujo de entrega y con ello evitar retrasos en el lanzamiento de los productos. En el mismo sentido, habilitando la entrega continua de funcionalidades, busca recoger rápidamente el feedback de los clientes sobre las mismas y mejorar el producto a ritmos difíciles de pensar hace pocos años.
Para unos DevOps es una metodología, para otros un cambio cultural… ¿Cómo lo definiría?
FM: No existe una definición compartida para DevOps, e incluso dentro de la asociación tenemos debates abiertos y estamos organizando eventos donde se debate sobre la importancia de cada una de las dimensiones de la transformación DevOps.
Creemos que el peso del cambio cultural es muy importante, pero debe equilibrarse con otras dimensiones como la organizativa, el establecimiento de métricas de rendimiento, procesos que se enfoquen en optimizar los flujos de valor y las herramientas que los habiliten. Con esta visión integral podemos maximizar las ventajas que DevOps promete.
Quizá el resumen sea que DevOps en sí es una metodología (porque es una forma de trabajo) que requiere un cambio cultural para aplicarla. ¿Por qué un cambio cultural? Porque supone romper con estructuras y procesos que vienen de tiempo atrás y que por tanto están interiorizados en las empresas y las personas. Precisamente, es algo para lo que ha surgido BAC. En una empresa de nueva creación, o una startup, es normal que desde el primer día se siga una aproximación DevOps al despliegue de producto. Por tanto, no hay cambio cultural. La cultura ya está presente. Es precisamente en grandes empresas, como los socios de BAC, donde es necesario hacer el trabajo de transmitir esta cultura, esta nueva forma de entender el despliegue de productos y servicios.
¿Qué ventajas y beneficios se obtienen al usar DevOps para el entorno empresarial?
CG: Algunas de las principales ventajas que hemos comprobado son:
- La mejora del TTM (time to market), gracias a la puesta en producción de nuevas soluciones y con una evolución más alineada con las necesidades de negocio (esto se consigue gracias a poder realizar varios ciclos de entrega de solución incluso diariamente).
- La mayor robustez de las soluciones entregadas, dado que el propio equipo que construye la solución se responsabiliza de su mantenimiento (como expresó uno de los ponentes del Congreso, uno de los principios es “el que lo construye lo opera”).
- La implicación extremo a extremo de toda la organización en el diseño del producto o servicio, y la visión compartida del mismo. Hacer a toda la organización (negocio, desarrollo, sistemas…) partícipes, y por tanto en cierta medida “dueños”, de un producto desde que nace hasta que llega al mercado es un factor clave de éxito de empresas nacidas digitales.
¿Es apta para todo tipo de compañías?
FM: Rotundamente sí, más allá de las dificultades que supone su adopción en grandes empresas, todo esfuerzo en alinear a los diferentes silos del departamento de tecnología en una misma dirección mejorará la situación actual. En función de cada organización se tendrá que incidir más en una u otra de las dimensiones de la transformación DevOps para alcanzarlo.
¿Qué desafíos implica para la empresa?
CG: Algunos ya los hemos mencionado, como las dificultades tecnológicas asociadas a sistemas legados muy monolíticos y con altos acoples entre los componentes; las dificultades para modificar estructuras organizativas existentes; pero quizá el principal consiste en el cambio necesario en la mentalidad y actitud de los equipos y líderes para adoptar una mentalidad ágil basada buscando pequeñas entregas de valor a través de estructuras organizativas más horizontales en las que se adquiera confianza en los equipos de trabajo.
Como en cualquier cambio que aplica a la forma de trabajo de una empresa, pensamos que hay un desafío inherente en las personas: no sólo en su capacidad de adaptación al cambio, sino en cómo la organización les hace partícipes de ese cambio y en cómo se transmite su necesidad. Hay que tener cierta empatía con las personas a las que después, de muchos años pidiéndoles que hagan las cosas según determinados procesos, midiendo lo bien que los siguen, y seguramente con salarios variables asociados a los mismos; ahora se les dice que quizá todo aquello no era la mejor aproximación, y que hay que aplicar una nueva.
¿Y para el CIO? ¿Qué retos se deben superar?
FM: Si tuviéramos que centrarnos en uno, y desde las experiencias que compartimos en la Asociación, sería la necesidad de alinear áreas del departamento de sistemas generalmente enfrentadas y enfocadas a diferentes objetivos (la estabilidad en el caso de Operaciones y la presión de tiempos por incorporar funcionalidades nuevas en el caso de Desarrollo). Siempre en los casos en los que tenga sentido un enfoque DevOps dentro de los servicios de la organización de sistemas, el CIO debe tener claro que afrontará una importante resistencia al cambio de modelo desde estructuras jerárquicas poco horizontales.
CIO y DevOps, ¿cuál es su relación actual?
CG: Alineado con la anterior respuesta, las iniciativas DevOps que más oportunidades tienen de resultar exitosas están esponsorizadas por el CIO. Es complicado impulsar estas iniciativas desde las áreas de Desarrollo u Operación sin contar con esta esponsorización a nivel de CIO, pero también lo es sin el firme convencimiento de los implicados en la necesidad del cambio. En una de las organizaciones que forman parte de la BAC tuve la ocasión de guiar un ejercicio con todo el equipo directivo de tecnología con la participación del rol de CIO trabajó iniciativas de mejora de su flujo de entrega y aportó este compromiso mutuo que claramente está ayudando en la transformación.
Por otro lado, también las direcciones de arquitectura TI suelen ser impulsoras de estas iniciativas, dada la visión trasversal que pueden aportar de la problemática que los silos tradicionales.
¿Cuándo y cómo implementarlo?
FM: En ocasiones, el disparador es un proyecto que requiere una fecha de implantación muy exigente, la necesidad de mejorar la calidad de una aplicación o sistema con una gran deuda técnica. Sin embargo, cada vez son más las organizaciones que ven la transformación DevOps como el paso necesario para completar la agilidad empresarial. No es necesario tener un disparador concreto sino darse cuenta de la necesidad de evolución constante que los clientes exigen a las soluciones digitales y entender cómo DevOps puede ayudar. En cuanto al cómo, también existen diferentes aproximaciones entre los socios, pero compartimos que un buen enfoque es estudiar cuál es la situación de partida de la organización y actuar sobre las dimensiones organizativa, de cambio cultural, diseño de metodologías ágiles y de integración continua, establecimiento de métricas e implantación de las herramientas que sean necesarias en función de cada organización. Adicionalmente, suele acompañarse la transformación con cambios de arquitectura de aplicaciones orientadas a servicios o microservicios para facilitar la independencia de equipos y la automatización de la provisión de plataformas e infraestructura para evitar cuellos de botella en el flujo de entrega
Además, como en cualquier cambio de paradigma donde existe una hipótesis de posible mejora que hay que poner a prueba, recomendamos dar esos primeros pasos en situaciones con cierto nivel de “control” de manera que permitan mostrar resultados ejemplarizantes, por así decirlo. De forma que esa hipótesis de mejora se pueda validar pronto y no haya dudas sobre el plan de transformación a DevOps, la inversión o su retorno.
¿Cómo liderar el cambio de una compañía con DevOps?
CG: La transformación debe tener un alto nivel de esponsorización como hemos comentado anteriormente, pero también son necesarios agentes del cambio que lideren los equipos DevOps y los equipos de plataformas con el enfoque de facilitadores de los equipos que realmente construyen dicho cambio. Desde otras asociaciones como DASA (DevOps and Agile Skills Association http://www.devopsagileskills.org/) enfocadas a la formación de perfiles DevOps se indica también otro rasgo de estos líderes que me parece fundamental, que es “coraje para actuar” ya que encontraremos mucha resistencia al cambio que requerirá esfuerzos importantes para perseverar y líderes con un fuerte convencimiento de las mejoras que aporta la transformación
¿Qúe debe tener en cuenta una empresa antes de implementar una estrategia DevOps?
FM: Debe ser consciente que el valor real de la adopción de DevOps no es la implementación de una metodología o unas herramientas, sino que requiere una transformación global que debe afrontarse en todas sus dimensiones y con una visión estratégica. También debe entender que para determinados servicios, productos o proyectos el enfoque DevOps no sea el más adecuado (por ejemplo cuando el proyecto tiene requisitos definidos claramente, que se espera no cambien, o el producto o servicio resultante no vaya a requerir un alto ritmo de evolución), un enfoque de tradicional de gestión de proyectos y servicios puede ser más adecuado.
¿Cuáles son los pasos a seguir para una correcta implantación?
CG: Un primer paso ya lo hemos apuntado anteriormente. Una fijada la situación actual y objetivo, algunas líneas de acción resultantes podrían ser:
- Actuar sobre la arquitectura de aplicaciones para facilitar el desacople que permita la mayor independencia posible de las aplicaciones
- Identificar y capacitar a los equipos con los que se abordarán los primeros pilotos y diseñar una estructura organizativa objetivo
- Establecer las métricas de la trasformación y de dichos equipos para medir las mejoras que la adopción de DevOps aporta
- Establecer una metodología ágil de desarrollo y procedimientos que habiliten la integración, entrega y despliegue continuos
- Diseñar e implementar los habilitadores tecnológicos (herramientas de automatización del ciclo de vida de aplicaciones, provisión de infraestructuras, integración y despliegues continuos, automatización de pruebas de regresión y aceptación, etc.) que evitarán la frustración de los equipos que aborden la implementación.
- En este post puede ampliar esta información: https://www.linkedin.com/pulse/cerrando-el-círculo-de-la-agilidad-empresarial-5-maregil-nieto
Problemas que pueden surgir de una mala implantación y cómo solucionarlos.
FM: Algunos motivos de una adopción no totalmente exitosa suele proceder de adoptar una visión sesgada por alguna de las dimensiones, típicamente la basada en herramientas y procesos. Sin embargo son las personas los principales agentes del cambio y, en ocasiones ni siquiera es preciso un cambio organizativo, simplemente creando un entorno colaborativo que facilite la comunicación entre equipos de desarrollo, pruebas, operación e infraestructura podemos conseguir grandes mejoras.
Otro de los problemas habituales es la creación de áreas de responsabilidad difusa o solapada, especialmente en grandes organizaciones como las que son miembros de BAC, donde los diferentes departamentos habitualmente trabajan con el apoyo de proveedores externos, cuyas responsabilidades vienen delimitadas por contratos pre-existentes.
La agilidad de la mano de esta tecnología. Ejemplos prácticos.
CG: Precisamente la Business Agility Corporation es el foro en el que estamos compartiendo estos ejemplos prácticos. Por ello queremos invitaros a que os unáis a nosotros y participéis en las actividades de la asociación para aprovechar estas experiencias.
Soluciones DevOps desarrolladas por su compañía. Características principales. ¿Qué aporta la misma al segmento empresarial?
FM: Dentro de la Asociación participan grandes organizaciones de diferentes sectores (telecomunicaciones, banca, utilities, Retail, …) y también proveedores de soluciones y servicios relacionados con la agilidad empresarial. Estos últimos podemos aportar en el ámbito de la Asociación de las soluciones tecnológicas y modelos de adopción de referencia en el mercado.
Limitaciones con los que puede encontrarse una empresa a la hora de su implantación. ¿Cómo eliminarlos?
CG: Al establecer los retos y desafíos para el CIO y la organización hemos hablado de los principales. Algunos retos tecnológicos se puede superar con enfoques como la APIficación o la orientación a arquitecturas de microservicios, el uso del Cloud con modelos PaaS, y otros asociados al cambio cultural contando con agentes del cambio internos o proporcionados por expertos externos. Sin embargo, en ocasiones existen barreras que son más complicadas de superar. Es importante entender si DevOps es realmente la mejor solución a la problemática que afrontamos y hasta dónde es viable actuar en cada una de las dimensiones para obtener beneficios de forma rentable.
Retos a los que se enfrenta un desarrollador de DevOps.
FM: Cada organización puede tener retos más particulares, pero compartimos que, dentro de un equipo DevOps, quizá el principal reto es el cambio de los roles tradicionales muy especializados. Por ejemplo el rol de programador ya no es sólo de desarrollo y codificación sino que pasa a un enfoque multifuncional en el que contribuye también en la toma de requisitos, realización de pruebas. Pero cuidado, el objetivo no es “saber de todo” sino conseguir “entre todos más como equipo”. Sin embargo, estos retos se ven recompensados por la mejora en el día a día que supone el uso de soluciones de integración continua o la autonomía que proporciona el trabajo en equipos ágiles de desarrollo. Una experiencia que prácticamente todas las organizaciones de la BAC compartimos es que las personas que forman parte de estos equipos Ágiles / DevOps nunca quieren volver a los equipos de desarrollo tradicionales, lo que da idea de lo potente que la transformación DevOps es en cuanto a la mejora del entorno de trabajo y el foco en las personas.