Arquitectura técnica y de DevOps

La consultoría de DevOps consiste en acortar la distancia entre una decisión y un sistema en producción, y mantenerla corta a medida que crece el entorno. Abarca la arquitectura de entrega, los entornos, el proceso de lanzamiento y aprobación, la capa de plataforma compartida sobre la que se basa cada equipo y las prácticas de fiabilidad que forman parte integrante de todos ellos, en lugar de estar al margen. Vivaldi opera un nivel por encima de la entrega: nosotros decidimos la arquitectura y el modelo operativo, y vuestros equipos de ingeniería y socios de desarrollo se encargan de implementarlo. Vivaldi lleva desde 1999 ofreciendo asesoramiento en estrategia empresarial y tecnológica.

• Desde 1999estrategia empresarial y tecnológica
• Más de 200estudios de caso publicados
• 10 oficinasen cuatro continentes
• 5x«Best of Consulting, Strategy and Innovation» de WirtschaftsWoche
• La arquitectura, no el personalNosotros diseñamos el modelo; vuestros equipos y socios se encargan de ponerlo en marcha

Cuando las empresas nos contratan

El detonante casi nunca es una decisión relacionada con las herramientas. Es el momento en el que alguien de alto rango se da cuenta de que un equipo de ingeniería competente está provocando retrasos en las entregas y nadie sabe a dónde se va el tiempo.

• La segunda funcionalidad tiene el mismo precio que la primera. No se ha reutilizado nada, porque no hay nada compartido que se pueda reutilizar. Este es el coste que nunca aparece en el primer análisis de viabilidad.
• El proceso está automatizado y, aun así, el lanzamiento tarda seis semanas. La automatización termina donde empieza la aprobación, y el proceso de aprobación se diseñó para lanzamientos trimestrales.
• La factura de la nube ha superado las previsiones. La distribución de la carga de trabajo se decidía proyecto por proyecto, por lo que nadie se encargaba de determinar el coste en función del volumen real.
• Una función de inteligencia artificial o de datos está a punto de entrar en producción. La capa del modelo, la ruta de datos y el modelo de lanzamiento deben estar definidos antes de que se implemente el primer sistema, y no adaptarse a posteriori en función de este.
• La entrega se ha ralentizado a medida que el entorno ha ido creciendo. Cada equipo vuelve a abordar cuestiones como la identidad, los secretos, el registro, la implementación y la reversión, y esta ralentización se interpreta como un problema de plantilla.

Por qué los programas de DevOps se estancan tras la implantación de las herramientas

Las herramientas casi nunca son el factor limitante. La mayoría de las organizaciones que afirman tener dificultades con DevOps ya han adquirido el pipeline, la plataforma de contenedores y la suite de observabilidad, y el plazo desde la toma de decisiones hasta la puesta en producción no ha variado.

Tres razones, en el orden en que solemos encontrarlas.

• El proceso hasta la producción es un comité, no un flujo de trabajo. La automatización termina donde empieza la aprobación. La compilación lleva horas y el lanzamiento, seis semanas, y la parte rápida es precisamente la que recibió financiación.
• Cada funcionalidad se desarrolla como si fuera la primera. Al no existir una capa de plataforma compartida, cada equipo debe volver a ocuparse de la gestión de identidades, los datos confidenciales, el registro de eventos, la implementación y la reversión. El coste se refleja en el segundo proyecto, y no en el primero, por lo que el análisis de viabilidad nunca lo tiene en cuenta.
• No hay retroalimentación. El departamento de producción apenas aporta información al equipo sobre lo que utiliza. Sin una vía de retroalimentación que permita aplicar los resultados a la definición del alcance y la dotación de personal de la siguiente tarea, el sistema del día 300 es el mismo que el del día 1, pero con más tráfico.

El primero es un problema de gobernanza, el segundo, un problema de arquitectura, y el tercero, un problema de modelo operativo. Ninguno de ellos se resuelve comprando más herramientas, y por eso gran parte de este gasto da lugar a equipos competentes que, aun así, no consiguen sacar nada adelante.

Qué incluyen nuestros servicios de consultoría de DevOps

Cuatro líneas de trabajo. Cada una de ellas puede abordarse por separado, y el diagnóstico suele señalar a una de ellas como la verdadera limitación.

1. Arquitectura de implementación y el camino hacia la puesta en producción

El proceso desde una modificación incorporada hasta un sistema en funcionamiento, explicado de forma clara y concisa.

• El punto en el que termina la automatización y comienza la aprobación humana debe establecerse deliberadamente en función de la importancia relativa y la reversibilidad, y no por defecto.
• Estrategia de entorno: así, las pruebas te dan una idea de cómo será la producción
• Diseño de lanzamiento y reversión, ya que la capacidad de deshacer cambios sin grandes costes es lo que hace que los lanzamientos frecuentes sean seguros
• Las métricas que permiten predecir todo lo demás: plazo de implementación de los cambios, frecuencia de implementación, tasa de fallos en los cambios y tiempo de recuperación

2. Una arquitectura en la nube que se adapta a los cambios de opinión

Las decisiones de arquitectura son compromisos sobre lo que se podrá cambiar más adelante. Dejamos claros esos compromisos antes de que se adopten por accidente.

• Distribución de la carga de trabajo y la curva de costes en función del volumen real, en lugar del volumen piloto
• Portabilidad cuando realmente vale la pena, y dependencia deliberada cuando sale a cuenta
• Una capa de modelos que sigue siendo sustituible, en la que los modelos se eligen en función de la carga de trabajo, de modo que el cambio es una decisión de implementación y no implica una reconstrucción.
• La residencia de los datos, la tenencia y el aislamiento se deciden antes de implementar el primer sistema, ya que adaptarlos posteriormente supone un proyecto en sí mismo.

3. Una capa de plataforma, por lo que la segunda funcionalidad resulta más económica

El sustrato compartido que, de otro modo, cada equipo tendría que crear por su cuenta: identidad, secretos, implementación, registro, rastreo, atribución de costes y el camino allanado que hace que la vía segura sea también la más fácil. Nosotros lo definimos y establecemos quién es el responsable. Tu equipo de plataforma o tu socio de desarrollo se encarga de crearlo.

• Qué se estandariza a nivel central y qué deciden los equipos por sí mismos, por escrito
• Autoservicio, donde los equipos son la vía más rápida, y cola solo cuando sea realmente necesario.
• El coste se imputa al equipo que lo gasta, por lo que la compensación es visible allí donde se produce.
• El modelo de propiedad tras el compromiso, denominado así para que la plataforma no se convierta en una dependencia nuestra

4. La fiabilidad y la vía de retroalimentación

La fiabilidad es, ante todo, un conjunto de acuerdos, más que un conjunto de paneles de control.

• Niveles de servicio acordados con la empresa, en lugar de fijados únicamente por el equipo de la plataforma
• Una revisión de incidentes que da lugar a cambios en el diseño, en lugar de una revisión que solo genera un documento
• La observabilidad centrada en las preguntas que la gente se hace a las tres de la madrugada
• El proceso de retroalimentación a partir de los resultados de la producción para definir el alcance y la financiación de la siguiente capacidad

Cómo funciona un proyecto de arquitectura técnica y DevOps

1. Diagnóstico. Rastreamos dos o tres cambios recientes desde la toma de decisiones hasta la puesta en producción y registramos dónde se produjo cada retraso. Entrevistamos al equipo de ingeniería, al de seguridad, al de la plataforma y al responsable del negocio, y comparamos la información obtenida con los datos de entrega de los que ya dispones. El resultado es una visión de dónde se invierte realmente el tiempo de entrega, que rara vez coincide con lo que supone el equipo.
2. Decidir. El modelo de prestación de servicios, el diseño de las autorizaciones, los compromisos relativos a la nube y a la ubicación de las cargas de trabajo, y los límites de la capa de la plataforma compartida. Las decisiones deben incluir por escrito las excepciones, incluyendo aquello que se haya decidido deliberadamente no estandarizar.
3. Especifica: la capa de la plataforma, el modelo de lanzamiento y reversión, los acuerdos de fiabilidad y las medidas, redactados de tal forma que un equipo de ingeniería o un socio de desarrollo pueda implementarlos sin que nosotros estemos presentes.
4. Pasa el relevo. Se designa un responsable para cada componente, se establecen los controles de revisión que garantizan la integridad de la arquitectura y se define el modelo de medición, de modo que la siguiente funcionalidad resulte más económica que esta sin necesidad de un segundo proyecto.

Por qué las empresas eligen « Vivaldi » para la arquitectura técnica y de DevOps

Hay tres razones que se repiten constantemente en los escritos con los que ganamos.

• No vendemos la implementación. No nos encargamos de gestionar los procesos, ni de operar plataformas, ni de revender servicios en la nube, por lo que la arquitectura no viene determinada por lo que nos pagarían por desarrollar a continuación. Las empresas que se encargan de la implementación se eligen después de tomar la decisión, y no antes.
• La arquitectura se evalúa desde un punto de vista comercial. El criterio que tenemos en cuenta es el coste de la siguiente funcionalidad en comparación con la anterior, junto con el plazo de entrega, la frecuencia de implementación, la tasa de fallos en los cambios y el tiempo de recuperación. Una arquitectura que no cumple ninguno de estos criterios se defiende basándose únicamente en cuestiones de gusto.
• La gobernanza se considera parte de la arquitectura. El diseño del proceso de aprobación, la responsabilidad y la vía de retroalimentación desde la producción hasta la definición del alcance se especifican en el mismo documento que la capa de la plataforma, ya que la parte más lenta de la mayoría de los entornos de entrega es aquella que ningún ingeniero controla.

Cómo evaluar una empresa de consultoría de DevOps

Merece la pena planteárselo a todas las empresas de tu lista de finalistas, incluida la nuestra.

• ¿Cuál será finalmente el plazo de entrega y cómo lo sabremos? Una empresa que no pueda comprometerse con una tendencia clara en cuanto al plazo de entrega, la frecuencia de implementación y el tiempo de recuperación está vendiendo actividad.
• ¿Cuánto cuesta la segunda funcionalidad tras este trabajo? La esencia misma de una capa de plataforma es que el coste se reduzca. Si no es así, habrás financiado una migración.
• ¿Qué compromisos en materia de nube estás asumiendo? El margen de los distribuidores, los niveles de los socios y los acuerdos de gasto comprometido influyen en el asesoramiento sobre la arquitectura. Pregunta cuáles son esos compromisos y si la recomendación cambiaría sin ellos.
• ¿Qué ocurre con nuestros controles de aprobación? Una empresa que automatiza el proceso y no modifica el comité de aprobación solo ha mejorado la parte rápida de un proceso lento.
• ¿Quién se encarga de gestionar esto dentro de un año? Si la respuesta es la consultora, lo que has comprado es una dependencia operativa en lugar de una arquitectura.

¿Empresa de consultoría de arquitectura, empresa de ingeniería de plataformas o distribuidor de servicios en la nube?

Trabajos relacionados

La arquitectura técnica rara vez es la única limitación. Tres elementos relacionados:

• API e integración de sistemas si la limitación radica en que los sistemas no pueden comunicarse entre sí, y no en que las actualizaciones sean lentas.
• Estrategia de datos si la plataforma funciona correctamente, pero los datos subyacentes no se pueden recuperar o no están gestionados.
• Productos y plataformas digitales si la cuestión pendiente es qué se debe crear, antes de plantearse cómo se comercializa.

Este trabajo forma parte de nuestra práctica de Estrategia Tecnológica Empresarial en Vivaldi, la consultora estratégica responsable de «Demand Landscape» e «Interaction Field», donde se defiende que la arquitectura de plataforma es lo que permite que los productos de la era de la IA salgan al mercado, y no una partida de costes que aparece debajo de ellos.

Consultoría de DevOps en EE. UU. y en todo el mundo

Nuestro trabajo de arquitectura técnica se lleva a cabo desde diez oficinas repartidas por cuatro continentes, y el equipo de EE. UU. tiene su sede en Nueva York. La mayoría de los proyectos son multirregionales desde el principio, ya que las decisiones más difíciles de revertir son las regionales: dónde se almacenan los datos, qué régimen de aprobación se aplica a un lanzamiento y qué requisitos de mercado acaban marcando la norma por defecto para todos los demás mercados. Decidir todo esto de una vez, de forma deliberada, resulta más económico que ir descubriéndolo país por país.