DevOps: Razones para no rendirse

El resultado final es fácil de identificar: o una organización abandona completamente DevOps o la desvía hacia esa área donde otros procesos y tecnologías han sido implementados por un solo equipo y finalmente mueren.

Niños problemáticos

En casi todos los casos de fallo de DevOps, las personas son el problema. Eso no quiere decir que la gente socave deliberadamente el sistema, pero las personas construyen, gestionan y gestionan las TI. Y la amplitud de personas en una organización tiene una gran influencia en el éxito o fracaso de DevOps (o cualquier otra iniciativa de TI).

Dicho esto, veamos algunos problemas que contribuyen a que las organizaciones de abandono de DevOps deben evitar en sus intentos de evaluar / implementar DevOps.

Aislamiento del equipo

Una reacción empresarial estándar es separarse de un equipo para observar una nueva tecnología / proceso y aislarlos del resto de TI.

Una de las claves del éxito en DevOps es la comunicación, y ninguna aplicación o cartera de aplicaciones funciona en el vacío. La necesidad de analizar el espacio del servidor, la seguridad, el enrutamiento y una serie de otros temas con TI central significa que el aislamiento no funcionará. Una cosa es borrar la carga de trabajo del equipo piloto para permitirles centrarse en evaluar DevOps para la organización, pero otra muy diferente es aislarlos (funcional y geográficamente, lo que sea). Si encuentran algunas oportunidades de optimización de rápido impacto en las operaciones estándar, ¿no desea compartirlas con el departamento de TI más amplio?

Poniendo las herramientas del lado correcto, pero faltando el lado de la cultura

Tarde o temprano, todas las herramientas de whiz-bang se implementan, y la cultura se convierte en el foco principal. Eso incluye no solo las comunicaciones entre las diferentes partes del equipo de DevOps, sino también la mentalidad de "poder entrar y salir" que prevalece más en DevOps que en un entorno de TI más dividido.

Obtener la cultura y las comunicaciones antes de tiempo es importante para el éxito. Y el éxito es importante para obtener mayores ganancias en la capacidad de TI para satisfacer las demandas del negocio.

Agregar a la carga de trabajo de los miembros del equipo sobrecargados

Esta es quizás la trampa más común que causa que las organizaciones dejen DevOps o minimicen su exposición a las prácticas de DevOps. DevOps tiene la promesa de una mayor productividad y una menor acumulación de pedidos. Pero es una promesa. Implementar herramientas y forjar nuevas relaciones y nuevos caminos de comunicación ... estas cosas toman tiempo. Y ese tiempo se agrega a las cargas de trabajo existentes, a menos que se tomen medidas para aligerar las cargas de trabajo existentes.

El equipo que trabaje de 10 a 12 horas al día simplemente manteniendo las luces encendidas no ralentizará nada que requiera una inversión definitiva de más horas-hombre a menos que así lo exija la empresa. Pedirles que comiencen a trabajar en él es una receta para el fracaso; lo mejor que puede esperar es una automatización que les haga la vida más fácil de otra manera.

No gestionar / cumplir las expectativas de varios líderes

Lo que los líderes de línea de negocio (LoB) y el CIO esperan de DevOps son cosas diferentes. Mientras que una respuesta vagamente similar -incrementada a las necesidades del negocio normalmente se comparte al 100 %- los detalles muestran preocupaciones diferentes.

Depende del CIO administrar lo que los que están debajo de él en TI esperan / demandan de DevOps, y lo que esos pares en la línea de negocios esperan de él. No hay reducción en el compromiso de los equipos de LoB; de hecho, uno podría argumentar que hay un aumento, ya que las TI ya no son el cuello de botella. Y, quizás lo más importante para algunas organizaciones, DevOps no hace que la informática le importe a los lectores más que las nuevas metodologías anteriores. El LoB todavía debe definir lo que se necesita y obtener requisitos en TI.

Descubre la innovación

Para asegurar el éxito empresarial, ahora y a futuro, es imprescindible maximizar el retorno de la inversión existente en software, a la vez que innovar y adoptar nuevas tecnologías. Los retos que hay abordar para competir en un mundo de TI Híbrida incluyen DevOps, Seguridad, Gestión de riesgos y Análisis predictivo. Puedes obtener más información sobre cómo abordar estos retos e innovar en este enlace.