¿Transformación Digital? No sin DevOps!!

Se me repite la ocasión en que vuelvo a casa despues de un curso de DevOps Foundations. Probablemente disponer de tres horas de tranquilidad después de tanta actividad hace que me aparezcan algunas ideas y me den ganas de escribir.

Una de las slides que presento en la versión para managers de este curso está sacada del documento State of DevOps Report 2015, publicado por Puppet Enterprise y que representa un informe sobre el estado de la cuestión que han venido publicando desde 2013 y que se ha ganado el respeto de la comunidad.

La primera vez que vi esta gráfica se me pusieron los pelos de punta y creo que es de una importancia tan grande que es necesario dedicarle un post, una noticia en el periódico y hasta un libro si fuera necesario con tal de hacer entender a todos los directivos del pais lo que significa.

Vamos a ir por partes: en el eje vertical tenemos tenemos la frecuencia de despliegues en la organización., pero atención, representada en una escala logarítmica donde 1 significa un despliegue al día… pero es que 2 significan 10 despliegues al día y 3 significan 100 despliegues al día; no nos dejemos engañar por la inocencia de esa gráfica.

En el eje horizontal tenemos, en escala también logarítmica, el tamaño de los equipos de desarrollo. Asi que me he permitido el lujo de calcular “a ojo” los valores de la curva, meterlos en un excel y hacer una gráfica parecida pero con escala lineal, para no suavizar el impacto del puñetazo que nos dan estos datos

¿Y qué significa esto? Pues básicamente que

a) Los “low performers” (aquellos que con sus prácticas actuales no llegan a más de 100 desarrolladores y que aún así están haciendo como mucho tres o cuatros despliegues a la semana.

b) El rendimiento de los “low performers” cae rápidamente cuando crecen en número de desarrolladores. Esto es típico de las aproximaciones tradicionales: al añadir más personal, crece la desorganización y el waste y por lo tanto la eficiencia cae en picado. En la siguiente gráfica he quitado a los high performers para poder percibir esta situación:

c) Con respecto a los “Mid Performers”, podemos ver que soportan relativamente bien la incorporación de cada vez más personal y lentamente aumentan el número de despliegues al día. Fijémosnos en que esto significa, desde el punto de vista del negocio, que podemos llegar a doblar el número de desarrolladores (e incurrir en costes mucho más elevados, ya que el aumento de costes no es lineal al numero de personas) y aún así no llegan al despliegue diario (en el fondo, quizás aqui el aspecto importante de verdad es que puedes doblar los recursos, pero no doblarás la velocidad de despliegues, sino que se mantendrá relativamente constante)

d) Finalmente, los “High Performers”. Estos son los preocupantes. Estos se mantienen más o menos cercanos hasta llegar a los 300 desarrolladores. Entonces comienza su escalada brutal: pasan a los cinco despliegues al día y rápidamente con capaces de llegar a los 80 despliegues al día apenas triplicando los recursos (osea, triplico los recursos y multiplico por 15 los resultados (!!!)

Posiblemente en estos momentos estés pensando que eso en el fondo son unos números más o menos trucados, quizás que en tu empresa hay doscientos programadores y que eres capaz de hacer 40 despliegues a la semana (que son unos 5 al día) y que eso está chupado, o simplemente que “¿y para qué quiero yo hacer tantos despliegues al día?”.

Perdón, que me ha faltado la última excusa, bastante frecuente además, la de “si, claro… pero ¿cuántos de esos despliegues son buenos? ¿Qué nivel de fallos tienen estos tios a esa velocidad?”. Te lo respondo en la siguiente tabla, tambien sacada del mismo State of Devops Report 2015

Ok, pues esto nos muestra que se está produciendo una brecha inmensa que está separando a los high performers del resto del mundo a una velocidad pasmosa y eso es un problema.

Ahora piensa en todos aquellos que están hablando sobre Transformación Digital. En el fondo están tratando de aplicar soluciones del mundo digital a los problemas que tienen sus clientes y buscando nuevas vías de contactar con ellos, de mantenerlos ligados a su marca, productos y servicios y rompiendose la cabeza para innovar en sectores que posiblemente sean muy tradicionales: ¿cómo ofrecer novedades en el sector banca, seguros, retail?

Y resulta que todo el concepto de Transformación Digital se basa en cuatro palabras: experimentar, innovar, aprender y digitalizar. Una empresa que aborde una iniciativa de transformación digital tiene que ser consciente de que esto no es un proyecto con inicio y fin, sino una transformación: ahora eres una cosa y luego serás otra, pero esa otra cosa, ese punto de destino es móvil y cambiante; las empresas transformadas ya no son empresas rígidas sino que son empresas líquidas que se adaptan de forma continua a un entorno, a un mercado y a unos clientes que cambian continua y rápidamente.

¿Y cómo puedes conseguir eso en un entorno digitalizado? Pues con velocidad. Necesitas que en IT tu flujo de aportación de valor sea muy rápido y que tu lead time sea muy corto con un nivel de acierto elevadísimo… y eso es exactamente lo que están consiguiendo los high performers de nuestra gráfica de arriba.

Resulta que los high performers han llegado a una situación en la que su lead time de experimentacion es muy corto, su capacidad de desplegar pruebas en los entornos de produccion es altisima, su riesgo muy bajo y su capacidad de recuperarse ante los errores es increible… los high performers pueden probar nuevos productos, nuevas lineas de negocio y nuevas maneras de comunicarse y satisfacer a sus clientes 200 veces más rápido que una empresa “normal”: o espabilamos o se nos comen!!

Así pues, la próxima vez que te plantees la transformación digital de tu compañía piensa primero en los cimientos sobre los que debes consruir ese cambio:

• una cultura de colaboración
  
• una organización transversal que huye de los silos verticales
  
• equipos multidisciplinares
  
• flujo de valor
  
• aprendizaje
  
• automatización
  

En definitiva, Lean-IT, Agile y DevOps o lo que nosotros llamamos Agile IT Management.

Y esos cimientos debes construirlos rápido: los high performers llevan años haciéndolo así que no te van a dejar respirar.

No tardes y empieza ya!

IT4IT: L’enfant terrible

En verano de 2014 The Open Group dió a conocer su nueva propuesta de modelo de arquitectura para las TIC llamada IT4IT. Posiblemente no me hubiera llamado mucho la atención si no hubiera sido porque el anuncio de publicación me llegó del mismísimo Charlie Betz, persona a la que sigo asiduamente desde hace al menos unos diez o doce años y autor al que admiro y respeto profundamente. Si lo anuncia Charlie, la cosa es importante!

La primera imagen que le llevas de IT4IT ya es de por sí impactante: un modelo de cadena de valor al estilo Porter con las piezas fundamentales que componen el negocio de las TIC

Eso llama mucho la atención, pero lo más impactante de todo es lo que se muestra en la parte superior: las cadenas de aportación de valor, los cuatro grandes flujos:Strategy to Portfolio, Requirement to Delivery, Request to Fulfill, Detect to Correct. Son las cuatro grandes áreas en las que podemos clasificar el trabajo que se hace en un departamento de IT, los cuatro grandes flujos de valor, el pipeline que todos desean automatizar y mejorar… es una aportación inocente, que muestra las TIC ordenadas en cuatro grandes flujos, pero lo cambia todo:

a) El concepto de servicio sigue existiendo junto con el del ciclo de vida, pero aparece sólo si tu quieres (inicialmente está diseñado para unas TIC orientadas a servicios, pero si lo tuyo no es la orientación a servicios, puedes mover en el pipeline aplicaciones, infraestructuras, o lo que quieras: hablé con un señor holandés que lo utiliza para el uniforme y equipamiento de la policía)

b) Está pensado para ser un modelo normativo: plantea una arquitectura para “el negocio de las TIC”, de la misma manera que eTOM lo plantea para el negocio de las Telco, BIAN para la banca o ACORD para los seguros. La arquitectura estará detallada en niveles, llegando incluso al nivel de atributos y tipos de dato.

c) Si se consigue su adopción, se habilitará un mecanismo increiblemente potente para normalizar el trabajo, integrar procesos multicompañia, evaluar proveedores de sourcing, definir aplicaciones o “ERP para IT”… Piensa en las posibilidades que te daría que el concepto de incidencia fuera homogéneo entre todos tus diferentes proveedores de soporte.

d) Es un modelo con Lean, Agile y DevOps “en el ADN”. Ha nacido pensado para eso

Más tarde, en Noviembre de 2014 me escapé a las jornadas CAS2014 en las que pude hacer un ejercicio importante de inmersión en el mundo de los agilistas, les observé, atendí a sus presentaciones y saqué algunas conclusiones; y una de estas conclusiones fue precistamente “hace falta una teoría unificadora que permita a las TIC ver el flujo completo. Todos necesitamos ver el pipeline”. Y eso me llevó a continuar mirandome IT4IT con muchísimo respeto: no era un modelo más de esos que hay cientos; esta vez hay algunos detalles diferentes.

Durante el congreso gigaTIC15 tuve la oportunidad de presentar junto con Walter Henríquez una charla sobre la evolución que ha vivido Cuatrecasas Gonçalves Pereira después de cuatro años de utilización de técnicas Lean en su centro de soporte, y sobre los retos que se le plantean a la organización en un futuro próximo. La utilización algunos de estos conceptos de IT4IT me vino de perlas para explicar algunas de las problemáticas que tienen Cuatrecasas y cuáles serán las vías de mejora en el futuro:

a) La dedicación del personal a diferentes cadenas de valor sin estar formalizada esta dedicación, hace que se le presete poca (o demasiada) atención a los flujos segundarios

b) La escasa participación transversal de las diferentes unidades organizativas a los diferentes flujos hace que la visión sea de silos en lugar de transversal (pero no organizados alrededor de procesos tradicionales, sino agrupados entorno a cadenas de valor, todo muy Lean)

Finalmente, esta semana se ha celebrado en Madrid el congreso Enabling Boundaryless Information Flow, organizado por The Open Group y que contaba con un track especial de IT4IT en el que presentaba el mismísimo Charlie Betz.

¡¡Cómo me lo iba a perder!!

Así que me planté en Madrid, atendí a todas las presentaciones de IT4IT en las que pude descubrir algunos detalles que explicaré más adelante y por si fuera poco pude asistir como invitado especial a las reuniones de los grupos de trabajo de IT4IT en los que se trataron aspectos del futuro del modelo de arquitectura que no te puedo contar porque me hicieron firmar un acuerdo de confidencialidad, así que lo único que puedo decir de lo que aprendí por la tarde es que en Octubre habrá magníficas noticias.