¿Cómo deberíamos hacer DevOps?
En los últimos años el término DevOps es cada vez más popular en todas las organizaciones, debido al protagonismo que está teniendo la tecnología en una gran parte de las industrias. Gracias a esto, es posible hablar de las ventajas estratégicas y competitivas que brinda DevOps para las empresas. En la actualidad, hay cada vez más compañías que están adoptando su práctica y todo lo que conlleva implementarlo.
Cuando una organización quiere adoptar el enfoque DevOps, en ocasiones comete errores en la implementación y quiero compartirles en este artículo un error muy común que denominaremos, asignación de responsabilidades en los equipos TI y los inconvenientes que tienen las personas que conforman esos equipos.
Es necesario identificar los tipos de organizaciones con las que nos podemos encontrar. Por ejemplo, el Dr. Roberto Fernández define tres tipos: funcional, matriz y de mercado, de las cuales la más predominante es la funcional, porque optimiza la experiencia, la división del trabajo y la reducción de costos, (Gene Kim 2016) así mismo plantea que:
“Estas organizaciones centralizan la experiencia, lo que ayuda a permitir el crecimiento profesional y el desarrollo de habilidades, y a menudo tienen estructuras organizativas jerárquicas altas. Este ha sido el método predominante de organización para las Operaciones (es decir, los administradores de servidores, los administradores de redes, los administradores de bases de datos, etc., están todos organizados en grupos separados).”
De esta manera, cuando llega el enfoque DevOps a las organizaciones funcionales se pretende conformar una nueva área o equipo y ese es el error.
Centralizar la responsabilidad de su práctica a un solo equipo, está en contra de lo que plantea DevOps. Esto se debe, a que las organizaciones crean un grupo separado con sus propias visiones, objetivos y responsabilidades; convirtiéndolo en cuello de botella que afecta la productividad de las compañías.
“El enfoque DevOps no puede ser un nuevo silo”
Hay organizaciones que lo pueden tener más claro y visionan que todos los equipos de TI realicen DevOps y esto es bueno. Sin embargo, cuando analizamos el interior de los equipos, podemos observar que la responsabilidad recae sobre una persona, cometiendo el mismo error de separar las prácticas en los equipos.
DevOps no debe estar centralizado en un equipo o persona
Cuando las personas van a los equipos de tecnología para tomar sus aplicaciones, automatizar, crear algunas pruebas y flujos de trabajo, en ocasiones lo realizan con dos intenciones:
1Pretenden hacer grandes cambios y avances muy rápidos para obtener resultados a corto plazo.
2Procuran masificar las prácticas y todo lo que conlleva el proceso de implementación.
Este puede ser un escenario errado, debido a que no están compartiendo la información y las responsabilidades. Además, las personas se vuelven indispensables, porque son las únicas que en realidad son capaces de implementar DevOps, dando la falsa ilusión que los equipos hacen DevOps.
A su vez, como un equipo es el único que ejecuta las prácticas y, en algunos casos, es solo una persona, esto impide que lleguemos a todas las áreas requeridas dentro del proceso.
En algunos casos, el avance logrado con las implementaciones realizadas se vuelve obsoleto e implicaría retornar a los equipos donde está centralizada la práctica para actualizar sus aplicaciones. Lo anterior, hace que cuando tenemos una gran demanda de equipos y aplicaciones, requieran más personas para abarcar la necesidad, por lo tanto, sería imposible cumplir con la demanda.
Una ventaja de esta situación es que permite obtener cambios positivos a la hora de vender y mostrar los resultados a los demás equipos, invitando a la planificación e implementación de DevOps.
¿Cómo implementar DevOps de la mejor manera?
Para lograr una mejor implementación, tendremos que plantearnos un objetivo de la siguiente manera:
1Definir un objetivo basados en la razón por la cual debemos adoptar DevOps y a partir de este, identificar las personas que harán parte del proceso.
2Identificar las funciones y las responsabilidades de los participantes, lo que permite definir de manera clara y precisa el lugar que tiene cada persona en la implementación.
(Kim, Humble, Debois y Willis, 2016) nos dan un ejemplo de objetivo que sirve como punto de partida para implementar DevOps:
“Obtener resultados más eficientes y con efectividad, así como permitir mejores ambientes de trabajos con un aprendizaje continuo”.
Siempre debemos estar alineados con el objetivo planteado y cuestionarnos: ¿Quién quiere más efectividad? ¿Quién desea eficiencia? ¿Quién apetece trabajar en mejores ambientes? ¿Quién anhela un aprendizaje continuo? Exacto, ¡todos! Estas son preguntas fundamentales, ya que permiten determinar los elementos claves del proceso como la calidad, conocimiento, experiencia, eficiencia y eficacia.
Del objetivo que planteamos, extraemos los elementos de fundamental importancia y debemos transmitir a los equipos de tecnología. De esa manera, todos los integrantes pueden cumplir con el objetivo, generar valor y ventajas competitivas. Además, aprenden algo nuevo y logran una satisfacción personal y profesional.
¿Quiénes serán los responsables de llevar estos elementos a los equipos de TI?
Lo ideal es definir un habilitador. Este puede ser una persona o un equipo que sean los encargados de realizar campañas y capacitaciones de las prácticas correctas para implementar DevOps. Por lo tanto, un habilitador no debe de realizar automatizaciones, pipelines y flujos de trabajo entre otras.
Y, ¿por qué es necesario un habilitador?
(Kim, Humble, Debois y Willis, 2016) explican que, un habilitador es quien formaliza las políticas, herramientas y los estándares de la implementación DevOps . Además, los teóricos plantean un concepto que denominaron las tres formas o principios.
Uno de esos principios, es el continuo aprendizaje y experimentación, y determina que las personas tienen que estar aprendiendo, ya que DevOps tiene que evolucionar a través de la innovación, experimentación, teorización y reflexión.
El habilitador será el encargado de guiar y no limitar las capacidades de los integrantes de TI, para así, potencializar la innovación y experimentación a la hora de entregar las prácticas de una manera controlada y organizada.
Como resultado, entregará retroalimentaciones que permitan mejorar los procesos, hacerlos más rápidos y con mayor calidad. A través de esto, los equipos podrán articularse para continuar aprendiendo y compartiendo sus experiencias.
En conclusión, el equipo o persona que habilita DevOps debe proteger y capacitar a los equipos de tecnología, para resguardar los intereses del equipo, evitar posibles errores y que se puedan desarrollar las prácticas. Debemos tener claro que: “DevOps es un tema de todos” por tal motivo implica un cambio en la cultura organizacional.
Si estás interesado en conocer más sobre DevOps, te recomiendo las siguientes lecturas:
- “The Unicorn Project” por Gene Kim.
- “The Phoenix Project” por Gene Kim, Kevin Behr and George Spafford.
- “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations” por Gene Kim, Patrick Debois, Jez Humble and John Willis.
