Una transformación digital exitosa requiere una disrupción interna, y la intención de los CIO de adoptar un futuro digital a menudo debe alterar sus modelos operativos de TI para cumplir con la transición. Más que en cualquier otro contexto, esto es evidente cuando se trata de desarrollar software y servicios.

Para crear software más rápido, los CIO están abandonando los viejos hábitos de la cascada en favor de metodologías ágiles en las que se asocian con las partes interesadas del negocio para crear aplicaciones rápidamente en sprints iterativos. Y algunos creen que pueden acelerar aún más el desarrollo de software implementando una filosofía emergente conocida como DevOps.

DevOps, una combinación de “desarrollo” y “operaciones”, describe la estructura organizativa, las prácticas y la cultura necesarias para permitir un desarrollo ágil rápido y operaciones escalables. DevOps automatiza el ensamblaje de software, aprovechando la integración, el desarrollo y la implementación continua para mejorar la experiencia del cliente, responder más rápidamente a las necesidades del negocio, y asegurar que esa innovación se equilibre con las necesidades de seguridad y de operaciones. Se puede considerar a DevOps como la metodología ágil pero reforzada.

Y se está poniendo de moda. El 50% de las 237 organizaciones encuestadas afirmaron que están implementando DevOps, según Forrester Research. “El impulso de DevOps se está dando en todos los sectores de la industria”, escribió el analista Robert Stroud en el informe de investigación. “El número de consultas se centra cada vez más en cómo las organizaciones tendrán éxito considerando la presión de la producción acelerada de aplicaciones y servicios -sin personal adicional”.

La transición hacia DevOps no es fácil, debido a los compartimentos estancos de las organizaciones, los obstáculos culturales y los problemas en la gestión del cambio. Aquí, los ejecutivos de TI de Intuit, MetLife y Red Hat hablan sobre su experiencia en hacer el cambio hacia DevOps y ofrecen consejos para los CIO que buscan sumergirse en DevOps.

 

El cambio a DevOps

La combinación de ciberseguridad y DevOps para un fabricante de software cuyos 4.500 desarrolladores han desarrollado aplicaciones utilizando el proceso de cascada durante años no es una tarea fácil, pero sí es la prioridad número 1 para Shannon Lietz, directora de DevSecOps de Intuit. El cambio ha requerido que los desarrolladores sean responsables del valor que crean para los clientes. “Es un cambio cultural”, afirma Lietz. “Mientras más cerca se puede llegar al cliente, más enriquecedora se vuelve la experiencia para los desarrolladores, para las otras personas dentro de la empresa y para sus clientes”.

“Hay una dedicación científica que hace que DevOps sea práctico y exitoso, y descubrí que tratar de introducir ciencia en una empresa es muy difícil”, afirma Lietz. “Es una forma diferente de operar”.

Para MetLife, la introducción de DevOps ha ido de la mano con la innovación. En los últimos años, MetLife se ha embarcado en DevOps paralelamente con la adopción de servicios de nube de Microsoft e IBM, así como la adopción de tecnología de contenedores Docker, según Alex Seidita, chief technology architect de la compañía de seguros con 150 años de antigüedad.

ModSquad de MetLife, un equipo de innovación compuesto por ingenieros, profesionales cibernéticos y desarrolladores ha adoptado la nube, la metodología Agile y DevOps para “aprender rápido, fallar rápido y producir rápido”, afirma Seidita. El ModSquad opera bajo el mantra, “uno no debe esperar saberlo todo para comenzar algo”.

El fervor religioso alrededor de los contenedores, microservicios y otras herramientas que hacen posible a DevOps, lograron atraer al CIO Mike Kelly a Red Hat en agosto del 2016. Kelly, quien se unió a la productora de software de código abierto después de un periodo como CIO en McKesson, estaba molesto con la forma en que la función del CIO había evolucionado a la de un comprador de software.

Los CIO de la empresa compraron software empaquetado para garantizar la eficiencia del proceso y gestionaron los cambios asociados a esas aplicaciones, afirma Kelly. Pero las manos de los CIO estaban atadas en términos de personalizar el software para cosas que eran demasiado únicas o difíciles de cambiar.

“Siempre sentí que iba a seguir adelante con estos grandes proyectos e iba a encontrar a alguien que no estaba feliz”, afirma Kelly, quien introdujo DevOps en McKesson. “Con DevOps, la cultura y la metodología ágil cambian. Ahora contamos con herramientas en la proverbial caja de herramientas para ayudar a resolver estos problemas permanentes”.

Las 12 mejores prácticas para implementar DevOps

En función de la experiencia práctica en la transición hacia DevOps, Lietz, Seidita y Kelly ofrecen las siguientes recomendaciones para garantizar el éxito de DevOps.

* Alinee la estrategia de DevOps con el negocio. La alineación de la estrategia de TI y la de negocios es una insistencia común entre los CIO, pero es igual de importante para DevOps, que se desplomará si TI y el negocio no trabajan en paralelo. “Si no lo hace, simplemente estará generando sorpresas” -probablemente no bienvenidas, afirma Lietz.

* Atornillar a los programas existentes. No conciba a DevOps como un proyecto de ciencias; más bien, atorníllelo a los programas existentes para que esté sujeto a los plazos de producción típicos. “Elija uno, dos o tres proyectos en los que pueda correr un pequeño riesgo pero que no tengan un tiempo ilimitado”, afirma Seidita. “Querrá que la gente participe en las tareas y pongan algo en producción”.

* Abarque con amplitud. Para que DevOps funcione, la cultura es esencial. Sea lo más inclusivo posible para poder “cambiar los corazones y las mentes”, afirma Seidita, agregando que es importante no excluir a las personas porque esto podría crear problemas. “Debe ser amplio e inclusivo para que las personas sientan que participan y contribuyen al proceso”.

* Concéntrese en lo que lo hace único. Cuando elija implementar DevOps, elija proyectos que agreguen valor y diferencien al negocio. “No intente hacer DevOps para su sistema ERP principal”, afirma Kelly.

* Elija plataformas probadas. Las herramientas son otro componente esencial de DevOps. Desde la administración de la configuración hasta las plataformas de producción continua, elija herramientas que tengan redes conocidas. Apostar por lo desconocido es muy arriesgado.

* Busque habilidades internas. No hay suficiente talento de DevOps en el mercado, por lo que debe atraer al talento experimentado en toda la organización. Búsquelos para que contribuyan a los proyectos. “Pueden darle la perspectiva adecuada para observar algo”, afirma Lietz. Ella afirma que Intuit contempla un “liderazgo sin fronteras”, en el que los gerentes pueden atraer a los miembros dispuestos del equipo a nivel de toda la empresa. En la mayoría de los casos, aceptan ayudar porque saben que están trabajando en algo que forma parte de la estrategia comercial.

* Evite el problema de las “clases de ciudadanía”. Muchas organizaciones cuentan con ingenieros que toman riesgos trabajando en tecnologías emergentes e ingenieros que se mantienen en tecnologías previas, como los sistemas ERP. Esta diferencia puede generar resentimiento. “Uno tiene que ser muy práctico y auténtico para tener la conversación con sus asociados y explicarles que esto no es algo binario”, afirma Kelly. Las personas que trabajan en entornos de tecnología previa son tan importantes como los que hacen DevOps, afirma.

* El tiempo siempre es un factor. No subestime la importancia del tiempo, especialmente para las empresas que cotizan en bolsa que reportan información financiera trimestral. Lietz afirma que las empresas deben comprometerse con la creación de valor para un trimestre específico y lograr que todas las partes interesadas se centren en aprender algunos de los canales de desarrollo. El aprendizaje debería ocurrir tanto para las partes interesadas de negocios como para TI con el fin de asegurar la alineación entre la misión y el resultado.

* No piense a muy largo plazo. Dada la alta velocidad de DevOps, algunas organizaciones pueden tener la tentación de resolver problemas que están lejos en el futuro. Eso puede llevarlos a perder la oportunidad de crear valor iterativamente, o incluso a tener que retirar un producto, malgastando el tiempo de todos.

* Adopte la escritura de historias. Piense en esto como un plan para crearles valor a sus clientes. Comience con un verbo, como “habilitar” una característica específica de un producto para hacerlo más seguro. Si no se crea un arco narrativo que traza cómo planea cubrir las necesidades de sus clientes, es probable que no construya los mejores productos, afirma Lietz.

* Evite la burocracia. La burocracia puede ser un asesino de DevOps, especialmente en las organizaciones de TI que están maduras y cuentan con reglas centradas en tomar pedidos. “No creo que haya una manera de tomar una decisión”, afirma Lietz. “La experimentación es clave y en el momento en que añada burocracia a DevOps, perderá”.

* Aprendizaje iterativo. Asegúrese de que las personas estén listas para embarcarse en este viaje y cometer algunos errores. “No los vincule a un modelo financiero riguroso en el que necesite decirme cuánto va a gastar el próximo año”, afirma Seidita. “Avance de a pocos”.

Ver fuente