¿Se puede ayudar a solucionar la entropía de las empresas?
Javier Lisbona
Hybrid Cloud & DevOps Tech
Finalizado el Tour de Francia, tuve que empezar a buscar nuevas alternativas para realizar esas famosas siestas españolas, cortas pero intensas. De esas siestas que se duerme poco tiempo pero que te levantas con el sofá marcado en la mejilla y con una pérdida total del espacio-tiempo. Tratando de alcanzar mi objetivo, estaba leyendo el último libro de Dan Brown cuando me dio por fijarme en una palabra que utiliza de manera recurrente: ENTROPÍA. Tras hacerme el listo y pasar por alto la palabra unas cuantas veces creyendo saber lo que significaba, decidí buscar ayuda en el mismo sitio donde buscamos la mayoría de los mortales, en Google que todo lo sabe. ¿Qué me dijo?
“Magnitud termodinámica que indica el grado de desorden molecular de un sistema.”
Indagando un poco más, me di cuenta que el término en cuestión me empezaba a molar bastante. También Google me hizo recordar La Segunda Ley de la Termodinámica que nos dice que los sistemas aislados tienden al desorden, ya que en ellos la entropía nunca puede disminuir y como mucho permanecerá constante. La evolución espontánea de un sistema aislado se traduce en un incremento de la entropía. A ver, para que yo me entere un poco, la entropía es pues una magnitud que nos da el grado de desorden o caos de un sistema. Cuanto mayor es la entropía, mayor es el desorden.
A día de hoy no tengo claro por qué llegué a la siguiente conclusión. Realmente no sé si es que me había metido demasiado en el papel de Dan Brown en sus libros, pero empecé a pensar en la entropía de mi día a día, concretamente en mi trabajo, en concreto, en mi trato diario con las empresas.
La entropía en muchas empresas en España está patente, campando el desorden y el caos por toda la organización. Lo que me llevó a pensar que mi trabajo consiste en dar una respuesta positiva a la pregunta que forma el título de este artículo… Y ahora voy a tratar de explicarme.
En España las empresas tienen buenas ideas, lo sé, lo veo a diario. Lo que observo es que desarrollar esa idea no es tan sencillo. Si alguien tiene una buena idea, ¿cómo la entregamos a los usuarios finales lo más rápido posible? Lo que pretendemos es que el tiempo de ciclo entre una idea y un software (sí amigos, actualmente todo en esta vida tiene un código por detrás, pensadlo…) utilizable sea lo más corto y seguro posible (no nos podemos olvidar que el software no genera ingresos hasta que esté en manos de sus usuarios finales).
Por lo tanto, es ese “tiempo de ciclo” el que se nos complica un poco. Normal, ya que en dicho ciclo se llevan a cabo un conjunto de tareas para nada triviales:
- Primero pensar si la idea es tan buena para convertirla en un proyecto de nuestra empresa y asignarle un presupuesto, que como todo en la vida variará, no será fijo… habrá cambios (Gestión de Portfolio).
- Si damos el paso, tenemos que realizar una buena toma de requisitos (Gestión de Requisitos) y convertir dichos requisitos en un conjunto de tareas que se deben repartir entre el equipo… y por supuesto, habrá cambios y tendremos que tenerlo bajo control. Una herramienta de versionado de código nos ayudará (Gestión del Cambio y de la Configuración).
- Ese código binario realizado por nuestros desarrolladores habrá que transformarlo en código ejecutable (Compilación) y desplegarlo en un primer entorno para comprobar que funciona correctamente con una batería de pruebas (Gestión de Pruebas).
- Si todo va bien, habrá que desplegarlo a otros entornos pre-productivos donde se lanzará una batería de pruebas más exhaustivas.
- Y, por último y, si todo va bien, se desplegará en un entorno final (Gestión de Releases y Despliegues).
Y aquí no acaba la cosa, porque hay que monitorizar que todo vaya bien y obtener un feedback de que lo que estamos haciendo lo hacemos bien. (Validar que todo es correcto, es decir, ver que lo que hemos hecho funciona [verificar] y comprobar que es exactamente lo que quieren los usuarios finales [validar]).
Lo dicho, se ve que no es algo trivial, a lo que en estos tiempos modernos hay que añadir que disponemos de diferente infraestructura donde realizarlo: en tu CPD de toda la vida on-premise, con máquinas físicas o virtuales, en la nube, pero ¿en qué nube?…en nube pública, en nube privada o en una solución híbrida…o mejor en contenedores..…. buffff, se complica la cosa claramente.
Es fácil de entender que la entropía campee a sus anchas en las empresas, los sistemas o departamentos aislados se traducen en un incremento de la entropía como bien dice La Segunda Ley de la Termodinámica. El desorden puede aparecer tanto en una tarea específica (en la planificación de tareas, por ejemplo) como en la coordinación entre varias tareas (compilación y despliegue son dos tareas que están muy unidas ya que el que despliega tiene que conocer que código compilado debe desplegar).
Todo esto nos lleva otra vez a la pregunta original. ¿Es posible mantener nuestra prioridad dentro de un orden entendiendo como prioridad satisfacer al cliente mediante la entrega temprana y continua de un software valioso?
Pues lo bueno de este artículo es que existe una respuesta afirmativa a la pregunta inicial. Sí, se puede, y se hace en muchas empresas en España, aumentando los comentarios y mejorando la colaboración entre los equipos de desarrollo, pruebas y operaciones responsable de la entrega (evitar sistemas aislados… ¡qué grande La Segunda Ley de la Termodinámica!). Es algo que se lleva haciendo hace mucho tiempo pero que recientemente los americanos han denominado DevOps.
DevOps no es más que es un enfoque de entrega de software ágil que promueve una colaboración más estrecha entre las líneas de negocios, el desarrollo y las operaciones de IT. Reúne a todos para mejorar la agilidad y reducir el tiempo necesario para abordar los comentarios de los clientes. Con entrega continua, implementación continua y monitoreo continuo de aplicaciones, podemos responder al mercado más rápido y crear experiencias de usuario atractivas, escalar nuestros proyectos DevOps con éxito sin interrumpir nuestro negocio y desarrollar una cultura de inicio que combine negocios, desarrollo y operaciones.
Sin embargo, muchas empresas realizan un acercamiento DevOps erróneo, desde mi humilde punto de vista: se centran en la compra o adquisición de una herramienta o conjunto de herramientas para aplicar todos estos principios directamente sobre ellos. La estadística me dice claramente que, como ya he dicho, es un acercamiento erróneo ya que nos olvidamos del punto de partida más importante y valioso: las empresas las forman personas. Hay que tener en cuenta a las personas desde el primer momento en dicho acercamiento DevOps, ya que son ellas las que van a realizar las tareas mencionadas anteriormente, creando la organización de la empresa, fijando la arquitectura que utiliza la misma y son los que generan los procesos internos de las empresas.
La idea es sencilla: realizar un acercamiento a estos principios basándonos en la organización de la empresa (personas…sí, lo sé, soy muy pesado pero es que es el elemento clave de la colaboración), la arquitectura de la empresa y los procesos de la misma, sin fijarnos en un principio ni en las herramientas que vamos a utilizar, ni el código que vamos a desarrollar (con independencia de la tecnología que vayas a emplear: Java, JavaScript, .NET…) ni en la infraestructura en la que nos vamos a apoyar.
No os preocupéis por lo demás, ya que una vez estén concienciadas las personas y que tengan claro cómo tienen que proceder, con colaboración, comunicación, transparencia (…vamos, como un único equipo), se consiguen todos los puntos típicos DevOps: Continuous Integration, Continuous Deployment, colaboración, automatización, trazabilidad, reutilización etc. Se llega por lo tanto a crear una continua mejora (Continuous Improvement) en la empresa que es la verdadera lucha contra la entropía de la empresa.
Como ya habréis deducido soy informático y trabajo en el mundo DevOps, en diferentes áreas y con diferentes empresas. Para luchar contra la entropía ayudo a las empresas con con los DevOps workshop, que tratan de solucionar los problemas comentados en este artículo basándome en la experiencia y en las buenas prácticas.
La única manera de controlar la entropía en una organización es querer hacerlo.
Si es así, no dudéis en contactar conmigo.
Echa un vistazo a este vídeo sobre “Un proceso DevOps inteligente”.
Postdata:
Finalmente, espero que os estéis preguntando lo más importante: ¿conseguiste tu principal objetivo?
Recordad la siesta, la famosa siesta española… sólo os diré que echo mucho de menos las etapas llanas del Tour de Francia