Por Gregor Hohpe, Estratega Empresarial en Amazon Web Services.
Los ejecutivos de hoy tienen mucho en sus manos. El entorno empresarial no solo cambia más rápida y dramáticamente que nunca, sino que el conjunto de tecnologías disponibles también evoluciona a un ritmo sorprendente. Esas tecnologías ya no son “cosas que TI hace muy abajo en la sala de máquinas”; se han convertido en un ingrediente crítico para que el negocio logre la agilidad necesaria sin sacrificar la calidad, la confiabilidad o la seguridad. ¿Cómo pueden los ejecutivos construir un puente entre la estrategia comercial y las decisiones de diseño técnico para que no se distraigan y estén listos para tomar el timón cuando sea necesario? Afortunadamente, podemos inspirarnos un poco en un grupo de personas que también necesitan tomar decisiones críticas que a menudo dependen de la tecnología que los mantiene en marcha: los pilotos.
Los pilotos son altos ejecutivos: están a cargo de llevar a todos a salvo a su destino. También operan máquinas increíblemente confiables pero asombrosamente complejas. Para tomar decisiones críticas, deben comprender el equipo que están controlando y el entorno en el que están operando. Aunque los pilotos no necesitan hacer esto solos, dependen del apoyo del control de tráfico aéreo, el personal de tierra, los centros de mantenimiento y los servicios meteorológicos. — nunca pueden delegar su responsabilidad. Veamos cómo los ejecutivos, especialmente aquellos en un viaje a la nube, pueden aprender una o dos cosas de cómo los pilotos entrenan y operan.
Los pilotos deben estar preparados para tomar decisiones críticas para la seguridad, a menudo con poca anticipación y en base a datos incompletos o contradictorios…
Gestión de la complejidad a 35 000 pies
Los pilotos deben estar preparados para tomar decisiones críticas para la seguridad, a menudo con poca anticipación y en base a datos incompletos o contradictorios. Unámonos a la cabina del vuelo 236 de Air Transat de Toronto a Lisboa a mitad de camino en un vuelo tranquilo a través del Atlántico. Los pilotos notaron que el motor #2 mostraba una temperatura de aceite más baja y una presión de aceite más alta de lo normal. Asesorados por el centro de mantenimiento para monitorear la situación, continuaron hasta que media hora más tarde les llamó la atención un desequilibrio de combustible entre el ala izquierda y la derecha. Decidieron corregirlo bombeando combustible del tanque izquierdo al derecho. Los siguientes 45 minutos transcurrieron sin problemas, hasta que de repente el motor #2 se apagó por falta de combustible. Afortunadamente, todos los jets bimotores están diseñados para operar de manera segura con un solo motor. Por desgracia, otros 10 minutos más tarde, el motor N°1 también se incendió, dejando el avión sobre el océano sin absolutamente nada de combustible y sin motor a reacción en marcha. Esto también significó que prácticamente todos los sistemas hidráulicos y eléctricos se apagaron, convirtiendo este increíble avión Airbus 330 con 293 pasajeros a bordo en poco más que un planeador primitivo. A través de un pequeño milagro y mucha habilidad del piloto, el avión aterrizó de manera segura en una base aérea militar en las Azores a 75 millas de distancia.
Lo que pasó en ese vuelo tiene una explicación técnica. Los motores a reacción son turbinas de giro rápido que se lubrican con aceite, al igual que los motores de los automóviles. El aceite se enfría mediante un dispositivo intercambiador de calor que enfría el aceite del motor en circulación calentando también el combustible que fluye desde las alas hacia los motores. El vuelo 236 sufrió una fuga de combustible cerca del motor porque una manguera de combustible mal instalada rozó contra el capó del motor y se rompió. El aumento del flujo de combustible debido a la fuga hizo que el intercambiador de calor enfriara el aceite del motor más de lo normal, lo que provocó un bajo nivel de combustible, una temperatura más baja del aceite y un aumento de la presión del aceite (el aceite más frío tiene una viscosidad más alta).
Todas las advertencias que los pilotos vieron en la cabina se originaron en un solo problema: la manguera de combustible rota. Si los pilotos hubieran estado al tanto del mecanismo del intercambiador de calor, podrían haber razonado que existe una conexión entre el desequilibrio del combustible y la baja temperatura del aceite que observaron. Entonces se habrían dado cuenta de que transferir combustible a un tanque con fugas sobre el océano es una muy mala idea.
Los pilotos deben tomar decisiones rápidas ante la complejidad y la incertidumbre. Es por eso que entrenan extensamente y siguen procedimientos estrictos.
Ejecutivos como pilotos
Los pilotos deben tomar decisiones rápidas ante la complejidad y la incertidumbre. Es por eso que entrenan extensamente y siguen procedimientos estrictos. Aunque es poco probable que los ejecutivos de TI modernos se queden sin combustible al cruzar el Atlántico, operan en un entorno similar que es muy complejo y crítico para el negocio. Echemos un vistazo más de cerca a cómo los ejecutivos de TI modernos pueden beneficiarse de operar como pilotos:
Prepárese para tomar el control
Una gran parte de cualquier vuelo se lleva a cabo en piloto automático, lo que evita la fatiga y la distracción del piloto al manejar el trabajo de rutina, como mantener la aeronave en una ruta de vuelo prescrita. Los pilotos especifican el rumbo y la altitud al piloto automático y el avión prácticamente vuela solo. Sin embargo, un piloto automático no reemplaza la capacidad del piloto para volar y comprender la maquinaria que opera. Es por eso que los pilotos entrenan regularmente, ¡sin piloto automático! Al volar manualmente, los pilotos entienden la dinámica del entorno técnico en el que operan, incluida la forma en que responde a las entradas y cómo las diferentes partes interactúan o interfieren entre sí.
Los ejecutivos de TI también están acostumbrados a volar en piloto automático. Eso se llama “gestión por objetivos”: los ejecutivos financian un proyecto de TI y especifican los entregables y los plazos. El piloto automático en esta configuración son los mandos intermedios: detectan pequeñas desviaciones del plan y las corrigen para que todo avance sin problemas. Hace una o dos décadas, eso funcionaba bien porque la lenta tasa de cambio tanto en el entorno empresarial como en la tecnología disponible hizo que fuera relativamente fácil mantener las cosas estables. Pero el turbulento entorno de TI actual es muy diferente. La innovación tecnológica tiene lugar a un ritmo nunca antes visto, lo que, combinado con los rápidos cambios en el entorno empresarial, mantiene a los CIO y sus departamentos de TI alerta.
Los ejecutivos de TI deben poder tomar el timón cuando las cosas se complican, al igual que los pilotos. Para hacerlo, deben comprender lo que sucede en la “sala de máquinas” de TI, donde operan los sistemas técnicos y se toman las decisiones críticas. Comprender las dependencias entre los sistemas y las tecnologías les enseña a los ejecutivos de TI cómo reaccionar ante lecturas inusuales de los instrumentos, tal como lo hacen los pilotos. ¿Es esa “luz roja” una simple advertencia o un problema grave? Los pilotos no pueden simplemente “esperar y ver”. Lo mismo es cierto para los ejecutivos de TI en el entorno de rápido movimiento de hoy.
La gerencia intermedia es el piloto automático de TI. Se encarga de los ajustes de rutina para que los ejecutivos puedan concentrarse en tareas críticas. Pero un piloto automático también puede enmascarar problemas. Por lo tanto, los ejecutivos deben estar preparados para tomar el timón cuando las cosas se pongan difíciles.
Los pilotos automáticos, por muy útiles que sean, también ocultan problemas potencialmente críticos. Debido a que compensarán automáticamente las desviaciones, un problema puede pasar desapercibido hasta que se vuelve grave. Por lo tanto, es importante que los pilotos y los ejecutivos de TI no confíen ciegamente en los pilotos automáticos. Esa es una de las razones por las que en Amazon adoptamos “inmersión profunda” como uno de nuestros 16 principios de liderazgo . Se espera que los ejecutivos de Amazon se sumerjan en los detalles de lo que están administrando, sin piloto automático.
Paseo por la sala de máquinas
Antes de que cualquier piloto se suba a un avión, hacen un recorrido: están en la pista, mirando neumáticos, sensores y tomas de aire del motor. Quieren asegurarse de que todo esté en buen estado de funcionamiento. No confían ciegamente en sus diales y medidores. Aunque los mecánicos mantienen el equipo meticulosamente, es importante que los pilotos no se separen de las máquinas que operan. Después de todo, tienen una responsabilidad de extremo a extremo: no se puede decir “ese no es mi departamento” cuando se está quedando sin combustible en el Atlántico. Los recorridos también subrayan que caminar sobre la pista y patear los neumáticos no está por debajo de un piloto, a pesar del prestigioso título de trabajo.
Del mismo modo, los ejecutivos de TI modernos necesitan comprender la maquinaria que controlan. Esto no significa que necesiten leer o incluso escribir código, pero deben comprender los componentes clave, las ramificaciones de elegir una solución sobre otra y las interdependencias críticas. ¿Qué infraestructura técnica se necesita para habilitar formas modernas de trabajo, como DevOps o desarrollo Agile? ¿Puede una estrategia de plataforma impulsar la armonización y al mismo tiempo impulsar la innovación? ¿Cuáles son los ingredientes clave para que una estrategia de este tipo tenga éxito, tanto desde el punto de vista técnico como organizativo? Los altos ejecutivos que tienen en mente respuestas claras a tales preguntas no solo tomarán mejores decisiones, sino que también se convertirán en patrocinadores más sólidos de las iniciativas de TI relacionadas.
Los ejecutivos de TI modernos necesitan visitar la sala de máquinas para comprender la maquinaria que controlan.
“Administrar dando vueltas” era una frase común en los años 70 y 80. La creciente complejidad de la TI actual puede asustar a los ejecutivos y evitar que visiten la sala de máquinas, pero en realidad es más importante que nunca: esos motores determinan si su empresa prosperará.
¡Pregunte “por qué” mucho!
En sistemas complejos, es difícil entender cómo se interconectan las piezas. Cuando todo funciona bien, es posible que nunca se sepa acerca de un intercambiador de calor de combustible y aceite. Irónicamente, cuando sucede algo inusual, una fuga de combustible en el peor de los casos, aprendemos cómo se comporta la sala de máquinas. ¡Pero solo si hacemos suficientes preguntas!
Las juntas de seguridad aérea hacen muchas preguntas para llegar a la causa raíz de un problema. No se detienen en las cuestiones técnicas; también analizan los procedimientos, las prácticas de gestión y las pautas reglamentarias. Las causas de los retrasos y fallas en los proyectos de TI pueden ser igualmente diversas. Por lo tanto, los ejecutivos deberían participar en retrospectivas y hacer muchas preguntas de “por qué”. El método de los “cinco porqués” fue iniciado por Toyota para llegar al fondo de un problema preguntando repetidamente por qué sucedió algo. El punto aquí no es identificar a la “parte culpable”, sino resolver la verdadera causa raíz de un problema, no simplemente curar los síntomas.
Todo va de acuerdo al plan puede ser el estado más cómodo. Pero lo inesperado presenta la mayoría de las oportunidades de aprendizaje, si hace suficientes preguntas.
Por lo tanto, la próxima vez que algo no salga según lo planeado, saltar a una solución rápida podría perder una de las oportunidades de aprendizaje más valiosas. Un problema no se resuelve cuando desaparece mágicamente, sino cuando se comprende y se rectifica la causa raíz. Eso solo puede suceder cuando primero pregunta muchos “por qué”.
Utilice modelos para combatir la complejidad
Los pilotos e incluso los mecánicos no pueden desmontar todo el avión para entender cómo funciona. En cambio, se basan en manuales, esquemas y dibujos de ingeniería. Estos documentos son modelos abstractos: resaltan las partes importantes, especialmente qué componente está conectado a qué otros. También omiten muchos detalles, como la longitud exacta de un cable o una manguera de combustible, por lo que pueden reducir la complejidad sin perder aspectos importantes.
Los modelos de arquitectura son herramientas igualmente importantes para los ejecutivos que actúan como pilotos. Dichos modelos proporcionan abstracciones significativas que eliminan el ruido y resaltan opciones importantes y sus compensaciones. Esa es la única forma de conquistar la inevitable complejidad técnica de la TI actual. Sin tales modelos, manejar la complejidad puede ser como jugar a Whack-a-mole: resuelves un problema solo para que surja otro, aparentemente al azar, como cuando los pilotos equilibraron los tanques de combustible solo para quedarse sin combustible en menos de un minuto. hora despues Debido a que los problemas en los sistemas complejos a menudo surgen entre las partes, como una línea de combustible o una integración de software defectuosa, es importante utilizar modelos que representen las conexiones entre las piezas.
Sin modelos de arquitectura, resolver problemas de TI será como jugar a Whack-a-mole.
Los equipos de arquitectura son una gran fuente para tales modelos. Es por eso que los equipos de arquitectura moderna deben estar estrechamente conectados con los ejecutivos de TI. Pueden crear claridad y ayudar a tomar decisiones mejores y más transparentes. Dichos arquitectos conectan a los tomadores de decisiones y la sala de máquinas de TI, un concepto al que me refiero como ” montar el ascensor del arquitecto “.
Concéntrese en la gramática, no en el vocabulario
La jerga excesiva mantiene a muchos ejecutivos de TI fuera de la sala de máquinas. Conectarse con la gente en la sala de máquinas puede parecer tener que hablar un idioma extranjero. “Estamos a favor de un flujo de IaC declarativo, pero envolvimos la API en un lenguaje OO para ayudar a la refactorización frecuente”, es lo que podría escuchar. Es posible que sienta la tentación de ignorar esos detalles hasta que el siguiente mensaje sea “un error tipográfico en nuestra biblioteca IaC compartida desactivó nuestro sistema de producción porque apagó todos los servidores”. En ese momento, tomar el timón será difícil y culpar al pasante no va a funcionar.
Para empeorar las cosas, el vocabulario de TI cambia todo el tiempo: ¿es DevOps, DevSecOps, Post-DevOps, NewOps o NoOps? ¿Es todo más o menos lo mismo o deberíamos llamarlo SRE (ingeniería de confiabilidad del sitio)? Ese debate por sí solo fácilmente podría durar horas.
Afortunadamente, no es necesario memorizar un diccionario gigante de términos de TI. Para dominar un nuevo idioma, debe dominar dos elementos: el vocabulario, que proporciona el conjunto de palabras disponibles, y la gramática, que define cómo se pueden combinar estas palabras para expresar algo significativo. Como ejecutivo, incluso si actúa como piloto, es casi imposible dominar el vocabulario de TI actual: cambia con demasiada frecuencia y no existe un diccionario ampliamente aceptado.
Mantenerse al día con el vocabulario de TI actual es difícil. Por lo tanto, concéntrese en la gramática para comprender las relaciones.
Por lo tanto, los ejecutivos que actúan como pilotos deben centrarse en la gramática de TI: ¿Qué combinaciones de palabras tienen sentido? ¿Puedo establecer prácticas de DevOps antes de pasar a la nube? ¿El uso de plataformas sin servidor afecta la forma en que implemento DevOps? ¿Debe la empresa tomar parte en tal transición? Esas preguntas revelan la gramática del lenguaje de TI y las conexiones relevantes.
Bienvenido a bordo
Cuando abordamos un avión, una experiencia que muchos de nosotros nos hemos perdido mucho, como pasajeros, no necesitamos pensar en todas las complejidades de la maquinaria que nos lleva a nuestro destino. Sin embargo, los ejecutivos no son pasajeros de primera clase; ¡Están sentados en la cabina!
Gregor Hohpe
En su función como estratega empresarial en Amazon Web Services, Gregor asesora a los líderes tecnológicos en la transformación tanto de su plataforma tecnológica como de su organización. Basándose en su experiencia como Smart Nation Fellow del gobierno de Singapur y como arquitecto jefe en Allianz SE, conecta la estrategia corporativa con la toma de decisiones técnicas y viceversa. Le gusta compartir sus pensamientos sobre la arquitectura y los arquitectos en sus libros, incluidos The Software Architect Elevator y Cloud Strategy.
