Planes de implementación del servicio de aplicaciones influenciados por la estructura del equipo
Los desarrolladores realmente son diferentes. Desde sus roles y responsabilidades hasta su ubicación en la estructura organizacional, los desarrolladores son a menudo el "grupo extraño". Ni siquiera se pueden incluir necesariamente en el término "TI" porque los equipos de desarrollo oscilan entre ser parte de TI y ser parte del negocio.
Incluso cuando DevOps como cambio cultural comienza a afianzarse, la mayoría de las organizaciones siguen organizadas funcionalmente en lo que no se conoce tan cariñosamente como silos de TI. En nuestra investigación sobre el estado de los servicios de aplicação 2019 , descubrimos que casi la mitad de todos los encuestados (46 %) todavía estaban organizados en "equipos de función única" como "Red", "Servidor", "Almacenamiento" y "Seguridad". Más de un tercio (37%) trabajaba en equipos de operaciones combinadas más adecuados para adoptar y aplicar los principios y enfoques de DevOps para la entrega e implementación de aplicação . Sólo el 15% trabajaba en equipos pequeños e interfuncionales basados en unidades de negocio o productos de la empresa.
La estructura importa porque en parte define tu propósito y tus prioridades. Eso, a su vez, determina las métricas con las que se mide el éxito. Las organizaciones aisladas implican métricas aisladas. Podemos ver esto en nuestra encuesta sobre NetOps y DevOps del verano pasado. Observamos diferencias significativas en cómo se midieron los equipos según su estructura. Por ejemplo, las métricas más comunes en todos los tipos de equipos y roles fueron:
- Tiempo de actividad de la red (60%)
- Tiempo de actividad de la aplicação (56%)
- Optimización de procesos (40%)
- Tiempo medio de resolución (39%)
Pero cuando desglosamos eso y miramos las métricas basadas en los tipos de equipo, vemos que cuanto más colaborativo sea, es decir, más fuerte sea el equipo. Similar a DevOps: una estructura de equipo es tal que las prioridades cambian.
|
Función única |
Operaciones combinadas |
Función cruzada |
Tiempo de actividad de la red |
67 % |
54 % |
50 % |
Tiempo de actividad de la aplicação |
53 % |
58 % |
61 % |
Optimización de procesos |
34 % |
45 % |
45 % |
Tiempo medio de resolución (MTTR) |
43 % |
30 % |
44 % |
Ahora bien, ¿cómo se relacionan las métricas con las que se le mide con los servicios de aplicação ? Bastante, en realidad.
Si su objetivo principal es el tiempo de actividad de la red, trabajará para lograrlo e implementará servicios que alcancen ese objetivo. Lo mismo ocurre con el tiempo de actividad de la aplicação . Si esa es su prioridad, tomará los servicios de disponibilidad mucho más en serio que a las personas que se miden por la frecuencia de implementación.
Podemos ver el impacto de una base de encuestados compuesta principalmente por "equipos de función única" en los planes de implementación de servicios de aplicação en nuestra investigación. Es más evidente cuando categorizamos los servicios de aplicação según lo que proporcionan a las aplicações : seguridad, rendimiento, identidad/acceso, disponibilidad y movilidad.
Estos resultados reflejan el impacto de las métricas de un equipo de función única. Los desarrolladores se preocupan principalmente por la disponibilidad, que a menudo incluye objetivos de rendimiento específicos, y planean implementar aquellos servicios de aplicação que respalden tanto la disponibilidad como el rendimiento. Asimismo, NetOps se centra en aquellos servicios de aplicação que respaldan el tiempo de actividad de la red optimizando, escalando y protegiendo los protocolos de red de los que dependen las aplicações .
La estructura del equipo es importante. No sólo por la necesidad de fomentar una cultura más colaborativa, sino por la forma en que impacta en las decisiones, incluidas las elecciones tecnológicas. La diversidad de objetivos genera fricción y frustración. Es una de las razones por las que vemos que servicios de aplicação como el equilibrio de carga, que tradicionalmente son implementados y operados por NetOps, son asumidos por DevOps y se implementan como parte de la aplicação. Porque en las organizaciones con estructuras de equipos de función única, el tiempo de actividad de las aplicação es una prioridad para los desarrolladores, pero no para NetOps.
Para aprovechar realmente DevOps, las estructuras de equipo (y las métricas con las que se miden) deben evolucionar hacia modelos más colaborativos y alejarse de los equipos tradicionales de función única.
Porque los silos pertenecen a las granjas, no al sector informático.