Be Software Architecture Wise
Be Wise Apps

Read in English · Lire en français · Auf Deutsch lesen

Sección 11.7 de 11.8 · Avanzado · 24 min de lectura

Liderazgo, influencia y toma de decisiones

Videolección

5 min · narrado en inglés, con subtítulos
Solo escuchar (audio)
Leer la transcripción

Un diseño sólido que nadie adopta tiene el mismo efecto que no tener ningún diseño. En esta lección aprenderás cómo lideran e influyen los arquitectos en las decisiones sin autoridad formal.

Piensa en una guía de montaña que conduce a un grupo de escaladores experimentados. No puede ordenar a nadie que suba la montaña. La gente la sigue porque conoce la ruta, explica los riesgos con honestidad, escucha cuando alguien detecta un peligro, admite cuando no está segura y ya ha acertado antes. Cuando el grupo no se pone de acuerdo sobre la ruta, se asegura de que todos sean escuchados, acuerda cómo se tomará la decisión y después ayuda a todos a comprometerse con ella. La mayoría de los arquitectos están en la misma posición.

La mayoría de los arquitectos no dirigen a las personas que construyen lo que ellos diseñan. Tienen responsabilidad sin autoridad formal, así que lideran mediante la influencia. En 1959, John French y Bertram Raven describieron el poder que viene con un puesto: la autoridad y la capacidad de recompensar o castigar. Los arquitectos rara vez tienen mucho de ese poder, y una decisión impuesta por el rango se acata, pero nadie la hace suya. La influencia duradera se basa en el poder que pertenece a una persona: la experiencia, la información y las relaciones. En The Trusted Advisor, la confianza crece con la credibilidad, la fiabilidad y la intimidad, es decir, que las personas se sientan seguras para plantearte cuestiones difíciles. Y disminuye con la autoorientación: la sensación de que te sirves a ti mismo, como cuando necesitas ganar cada discusión. Acierta primero en las cosas pequeñas, cumple lo que prometes y di lo que no sabes.

Muchas discusiones de arquitectura tratan en realidad del proceso: quién decide, a quién hay que consultar y cómo se resolverán los desacuerdos. Acuerda eso primero y buena parte de la tensión desaparece. Hay dos métodos que a menudo se confunden. El consenso busca una propuesta que todos apoyen activamente. Genera un compromiso fuerte, pero es lento y da a cualquier persona un veto efectivo. El consentimiento adopta una propuesta salvo que alguien plantee una objeción razonada. La pregunta pasa a ser: ¿hay alguien que no pueda vivir con esto, y por qué? Suficientemente bueno por ahora, suficientemente seguro para probarlo. Cuando no se puede llegar a un acuerdo, alguien tiene que decidir. Disagree and commit pide a las personas que defiendan su postura a fondo antes de la decisión y que la apoyen por completo después, con su discrepancia registrada.

El ascensor del arquitecto de Gregor Hohpe ofrece una imagen memorable. Las grandes organizaciones son como edificios altos. En el ático, los directivos fijan la estrategia y los presupuestos. En la sala de máquinas, los ingenieros construyen y operan los sistemas. Entre ambos hay muchas plantas de gestión, donde la información se filtra y se distorsiona por el camino. El arquitecto viaja en el ascensor entre ellos: sube riesgos, restricciones, costos y opciones, y baja la estrategia, las prioridades y sus motivos. Un arquitecto que nunca deja el ático se convierte en una torre de marfil. Uno que nunca deja la sala de máquinas se convierte en un experto ignorado. El valor está en conectar las plantas.

Ahora, una decisión disputada. El equipo de plataforma quiere todos los servicios en un clúster de Kafka para toda la empresa, y pagos se opone con fuerza. El facilitador replantea la pregunta en torno al problema real: publicar los eventos de pedido, para que los demás servicios dejen de estar en la ruta del pedido. Antes de cualquier reunión, el facilitador habla con cada parte por separado. Pagos debe mantener los datos de las tarjetas fuera de los sistemas nuevos y no puede asumir más trabajo de guardias. Finanzas quiere limitar los costos de operación. Cada uno se registra como un interés, no como una posición. En el foro asesor, el grupo acuerda criterios ponderados antes de examinar ninguna opción, como las garantías de entrega y la carga operativa para los equipos de producto. Después llegan cuatro opciones, incluida una de quienes discrepan: pagos aporta la opción D, que mantiene las llamadas síncronas con reintentos y circuit breakers. Un spike de dos semanas prueba B y C con una carga similar a la de producción. En una ronda de consentimiento se propone la opción B: Kafka para los eventos de pedido, operado por el equipo de plataforma como servicio. Pagos objeta que podría verse arrastrado a operar el broker, así que la responsabilidad del equipo de plataforma se escribe en su API del equipo. Quien toma la decisión acepta B, y el registro de decisiones recoge las opciones, las puntuaciones, los resultados del spike, la discrepancia y los desencadenantes de revisión. La discrepancia cambió el resultado y quedó registrada, no descartada.

Con los directivos, plantea cada tema en los términos que ya gestionan: ingresos, costos, riesgo, plazo de comercialización, experiencia del cliente, regulación y personas. Lleva opciones en lugar de un único plan, cada una con su costo, su riesgo y aquello a lo que renuncia, y di cuál recomiendas y por qué. Deja claro qué decisión necesitas y para cuándo. Por último, un arquitecto que toma personalmente todas las decisiones se convierte en un cuello de botella. Ejerce de mentor y de coach con otras personas, patrocínalas con tu credibilidad y delega decisiones dentro de unos guardrails establecidos.

La sección completa trata la negociación, los modos de conflicto, las trayectorias profesionales staff-plus y las trampas de decisión en grupo. A continuación, en la Sección once punto ocho, la última de este capítulo, veremos la ética y el caso de negocio. Nos vemos allí.

Lo que necesitas saber

Liderar sin autoridad

La mayoría de los arquitectos no dirigen a las personas que construyen lo que ellos diseñan. Los equipos dependen de los responsables de ingeniería, las prioridades corresponden a los responsables de producto y los presupuestos, a los directores. Aun así, se espera que el arquitecto se asegure de que las decisiones significativas se tomen bien y se respeten en muchos equipos, que es la responsabilidad central descrita en la Sección 1.4. La distancia entre la responsabilidad y la autoridad formal es la condición que define el puesto, y salvarla es una cuestión de influencia.

El estudio clásico de John French y Bertram Raven sobre el poder social (1959) distinguió las bases de poder que vienen con un puesto (la autoridad legítima, la capacidad de recompensar y la capacidad de castigar) de las que pertenecen a una persona (la experiencia y el poder referente, es decir, el respeto y la identificación que sienten los demás); más tarde Raven añadió el poder informativo, la capacidad de aportar hechos que hacen cambiar de opinión. Los arquitectos rara vez tienen mucho poder posicional y, cuando lo tienen, usarlo sale caro: una decisión impuesta por el rango se acata, pero nadie la hace suya, y las personas que no estaban de acuerdo dejan de contarte los problemas. La influencia arquitectónica duradera se basa casi por completo en la experiencia, la información y las relaciones.

No se trata de una habilidad blanda añadida al trabajo técnico. Un diseño sólido que nadie adopta tiene el mismo efecto que no tener ningún diseño, y un diseño mediocre que los equipos entienden y apoyan a menudo da mejores resultados que uno brillante que esquivan. El resto de esta sección trata la influencia como un conjunto de prácticas que se pueden aprender: generar confianza, facilitar decisiones, gestionar el conflicto, comunicarse hacia arriba, hacer crecer a otras personas y evitar las trampas en las que caen los grupos.

Generar confianza y credibilidad

The Trusted Advisor (2000), de David Maister, Charles Green y Robert Galford, ofrece un modelo útil. La confianza crece con la credibilidad (sabes de lo que hablas), la fiabilidad (haces lo que dices) y la intimidad (las personas se sienten seguras para plantearte cuestiones difíciles), y disminuye con la autoorientación (la sensación de que sirves a tus propios intereses, como tener razón, parecer inteligente o proteger tu diseño). La aportación del modelo para los arquitectos es que la autoorientación está debajo de la línea: divide todo lo demás. No se confía en un arquitecto brillante y fiable que necesita a ojos de todos ganar cada discusión.

En la práctica, la credibilidad se construye de formas pequeñas y visibles. Acierta en las cosas pequeñas antes de pedir que confíen en ti en las grandes. Mantente lo bastante cerca del código para entender su costo real: escribe el spike, revisa el pull request, asiste a una revisión de incidentes. Di lo que no sabes y cómo lo averiguarías. Cumple cada compromiso, sobre todo los aburridos. Reconoce el mérito de los demás en público y asume tus propios errores, también en público. Explica el razonamiento que hay detrás de cada principio para que las personas puedan aplicarlo en situaciones que no previste.

La confianza también depende del clima que te rodea. La investigación de Amy Edmondson sobre la seguridad psicológica, que comenzó con un estudio de 1999 sobre equipos de trabajo, descubrió que los equipos cuyos miembros creen que es seguro admitir errores y cuestionar a los demás aprenden más y rinden mejor. Los arquitectos influyen en ese clima más de lo que creen. Reaccionar a las malas noticias con curiosidad en lugar de buscar culpables, pedir objeciones de forma explícita (¿qué haría que esto fracasara?) y agradecérselas a quien las plantea es lo que permite enterarse de un diseño defectuoso mientras todavía es barato de corregir.

Facilitar decisiones

Muchas discusiones de arquitectura son en realidad discusiones sobre el proceso: quién decide, a quién hay que consultar y cómo se resolverán los desacuerdos. Acordar los derechos de decisión antes de discutir el fondo quita buena parte de la tensión. La Sección 11.4 describió el proceso de consejo (advice process), en el que cualquiera puede tomar una decisión siempre que pida consejo a los afectados y a quienes tienen experiencia; otras organizaciones usan un foro de revisión de arquitectura, un responsable de decisión designado para cada dominio o matrices de roles como RACI. El mecanismo concreto importa menos que el hecho de que se conozca de antemano.

Dentro de los derechos de decisión que se apliquen, el arquitecto suele ser el facilitador: la persona que plantea la pregunta, se asegura de que estén presentes las personas y las pruebas adecuadas y guía al grupo hacia una decisión que perdure. Distintos métodos de decisión convienen a distintas situaciones, y elegir el método de forma deliberada forma parte del trabajo.

Hay dos métodos que a menudo se confunden. El consenso busca una propuesta que todos apoyen activamente; genera un compromiso fuerte, pero es lento y da a cualquier persona un veto efectivo. La toma de decisiones por consentimiento, desarrollada en la sociocracia de Gerard Endenburg en los Países Bajos a partir de la década de 1970, adopta una propuesta salvo que alguien plantee una objeción razonada de que causaría un daño o haría retroceder al grupo. La pregunta pasa de ¿están todos de acuerdo? a ¿hay alguien que no pueda vivir con esto, y por qué? Una frase de la práctica sociocrática resume bien el umbral: suficientemente bueno por ahora, suficientemente seguro para probarlo. El consentimiento funciona especialmente bien para las decisiones de puerta de doble sentido, que se pueden revisar a medida que llegan pruebas. El consenso aproximado (rough consensus) del IETF, descrito en la Sección 4.8, es un pariente cercano.

Cuando no se puede llegar a un acuerdo, alguien tiene que decidir, y ya debería estar claro quién. Disagree and commit (discrepar y comprometerse), que también se trata en la Sección 4.8, pide a las personas que defiendan su postura a fondo antes de la decisión y que la apoyen por completo después. Solo funciona si el desacuerdo se escuchó de verdad, la discrepancia queda registrada (en el registro de decisiones de arquitectura, con sus motivos) y existe una señal acordada que reabriría la cuestión.

Elegir un método de decisión

MétodoCómo funcionaÚsalo cuandoPrincipal riesgo
Decidir en solitarioDecide la persona responsable, quizá tras una consulta rápidaPuertas de doble sentido, emergencias, decisiones de alcance limitadoConocimiento que se pasa por alto; poco compromiso de los demás
Consultar y luego decidir (proceso de consejo)Quien decide debe pedir consejo a los afectados y a los expertos; después decide y registra por quéLa mayoría de las decisiones de arquitectura en equipos autónomosSe pide consejo por cumplir y luego se ignora
ConsentimientoAdoptar salvo que quede una objeción razonada y de peso; las objeciones mejoran la propuestaDecisiones que afectan a un grupo y se pueden revisarObjeciones usadas indebidamente como vetos por preferencia
ConsensoContinuar hasta que todos apoyen la propuestaGrupos pequeños, valores o principios de mucho peso que necesitan un compromiso profundoLentitud; bloqueo; decisiones tomadas por omisión
VotaciónVotación por mayoría o ponderada entre los participantesElegir entre opciones que son todas aceptablesUna minoría perdedora sin compromiso; popularidad por encima de las pruebas
DelegarConfiar la decisión, con restricciones, a un equipo o a una persona más cercana al trabajoLa decisión es local y las restricciones se pueden enunciarDelegar sin el contexto o sin las restricciones

El conflicto y la política organizativa

La política organizativa es simplemente la forma en que grupos con intereses distintos, recursos limitados y sus propias carreras toman decisiones. No es una corrupción del trabajo de arquitectura, sino su entorno. Ignorarla no hace que un arquitecto tenga más principios, solo que sea menos eficaz. Las herramientas de capítulos anteriores se aplican directamente: el mapa de partes interesadas y la matriz poder/interés de la Sección 1.5 muestran quién se ve afectado y quién puede bloquear, y los registros de compromisos de la Sección 1.6 hacen visibles las posiciones.

Getting to Yes (1981), de Roger Fisher y William Ury, sigue siendo la guía más útil sobre la negociación basada en principios, y sus cuatro ideas se trasladan directamente. Separa a las personas del problema: la responsable de pagos no es obstruccionista, le preocupan los datos de las tarjetas. Céntrate en los intereses, no en las posiciones: no debemos usar Kafka es una posición; no podemos asumir más carga de guardias es un interés que varios diseños podrían satisfacer. Inventa opciones de beneficio mutuo antes de decidir. Insiste en criterios objetivos, acordados antes de comparar las opciones. Su idea de la mejor alternativa a un acuerdo negociado (BATNA) también es útil: saber qué ocurre si no se llega a un acuerdo indica a todos cuánto vale el acuerdo.

El modelo de modos de conflicto de Kenneth Thomas y Ralph Kilmann (1974) describe cinco formas de responder al conflicto, según el peso que des a tus propias inquietudes y a las de la otra parte. Ninguna es siempre la correcta; la habilidad consiste en elegir de forma deliberada en lugar de recurrir a la costumbre.

Algunos hábitos prácticos ayudan en todos los casos. No sorprendas nunca a una parte interesada en una reunión pública con una propuesta que le afecta; habla antes con ella, en privado (las organizaciones japonesas llaman nemawashi a esta consulta preparatoria). Cuando haga falta escalar, hay que hacerlo juntos: ambas partes presentan el desacuerdo y las opciones a la persona que puede decidir, en lugar de presionar cada una por separado. Y mantén los desacuerdos sobre los diseños separados de los juicios sobre las personas, tanto en lo que dices como en lo que escribes.

Cinco modos de conflicto (según Thomas y Kilmann)

ModoQué significaÚtil cuandoSi se abusa de él, lleva a
CompetirDefender con firmeza tu propia posiciónCuestiones de seguridad (safety), de seguridad de la información o legales en las que debes mantenerte firmeAcatamiento sin compromiso; la gente deja de plantear problemas
ColaborarTrabajar juntos para satisfacer plenamente los intereses de ambas partesDecisiones importantes en las que las inquietudes de ambas partes son legítimasDecisiones lentas sobre asuntos que no lo requerían
TransigirCada parte renuncia a una parte de lo que quiereHay poco tiempo y ambas partes tienen el mismo poderDiseños que no satisfacen a nadie y son incoherentes
EvitarAplazar o esquivar la cuestiónLa cuestión es trivial o los ánimos necesitan tiempo para calmarseProblemas que crecen hasta convertirse en crisis
ComplacerCeder ante la posición de la otra parteEstabas equivocado, o la cuestión les importa mucho más a ellosPérdida de credibilidad y principios abandonados

Comunicarse con los directivos

La Sección 4.8 trató cómo adaptar un mensaje a su público y empezar por la respuesta. Los directivos merecen algo más de atención, porque tienen los presupuestos y la autoridad de los que depende el trabajo de arquitectura, y porque los arquitectos suelen perderlos por explicar demasiado y pedir demasiado poco.

Plantea cada tema en los términos que los directivos ya gestionan: ingresos, costos, riesgo, plazo de comercialización, experiencia del cliente, regulación y personas. Lleva opciones en lugar de un único plan, cada una con su costo, su riesgo y aquello a lo que renuncia, y di cuál recomiendas y por qué. Cuantifica donde puedas hacerlo con honestidad, y di qué grado de confianza tienen las cifras; un rango con una base explícita es más creíble que una falsa precisión. Deja claro qué decisión o qué apoyo necesitas de ellos y para cuándo. Prepárate para la pregunta ¿qué harías si fuera tu dinero? Y no dejes nunca que un directivo se entere de un riesgo grave primero por otra persona.

A las personas de alto nivel a menudo les interesa menos cómo funciona un sistema que si sus responsables lo tienen bajo control. Mostrar que los riesgos se conocen, tienen responsable, se miden y se están reduciendo (por ejemplo, mediante un registro de riesgos de arquitectura o las funciones de aptitud de la Sección 11.3) genera más confianza que cualquier diagrama. La Sección 11.8 muestra cómo presentar el trabajo de arquitectura en la forma que usan los directivos para comparar inversiones: el caso de negocio.

El ascensor del arquitecto

The Software Architect Elevator (O'Reilly, 2020), de Gregor Hohpe, ofrece la imagen más memorable de este trabajo. Las grandes organizaciones son como edificios altos. En el ático, los directivos fijan la estrategia y los presupuestos; en la sala de máquinas, los ingenieros construyen y operan los sistemas; entre ambos hay muchas plantas de gestión, y la información que pasa por ellas se filtra y se distorsiona por el camino. El ascensor del arquitecto (architect elevator) de Hohpe se desplaza entre el ático y la sala de máquinas y lleva información en ambas direcciones: baja la estrategia y sus motivos a las personas que construyen los sistemas, y sube las realidades técnicas (restricciones, riesgos, costos y opciones que el negocio no sabía que tenía) a las personas que toman las decisiones estratégicas.

La idea de Hohpe es que el valor del arquitecto está en conectar las plantas. Un arquitecto que se queda en el ático se convierte en un estratega de torre de marfil cuyos planes ignoran lo que es técnicamente posible; uno que se queda en la sala de máquinas se convierte en un experto respetado cuyas advertencias nunca llegan a las personas que podrían actuar en consecuencia. Usar bien el ascensor significa cambiar de lenguaje y de nivel de detalle en cada planta sin cambiar el fondo, que es exactamente la habilidad de adaptarse al público de la Sección 4.8 aplicada a toda una organización.

Viajar en el ascensor

El ascensor del arquitecto de Gregor Hohpe: un arquitecto viaja entre el ático y la sala de máquinas, llevando información en ambas direccionesÁticojunta y directivos: estrategia, presupuestoPlantas de gestióncarteras, programas, organizaciónProducto y arquitecturaroadmaps, diseño entre equiposSala máquinascódigo, infraestructura, operacionesSubir:riesgos, límites,costos, opcionesBajar:estrategia, prioridad,los motivosNunca deja elático: torrede marfilNunca deja la salade máquinas:experto ignoradoEl valor del arquitecto está en conectar las plantas
Según Gregor Hohpe: el arquitecto conecta la estrategia del ático con la realidad técnica de la sala de máquinas, traduciendo en ambas direcciones.

Hacer crecer a otros arquitectos

Un arquitecto que toma personalmente todas las decisiones significativas se convierte en un cuello de botella, y la capacidad arquitectónica de la organización se va con él. Por eso hacer crecer a otros forma parte del rol, no es un extra opcional. Ayuda distinguir tres actividades. La mentoría comparte tu experiencia y tus consejos. El coaching hace preguntas que ayudan a alguien a llegar a su propia respuesta, lo que desarrolla el criterio más rápido. El patrocinio usa tu credibilidad para dar oportunidades a alguien: recomendarle para dirigir un diseño, poner su nombre en la propuesta, invitarle a la reunión con los directivos.

Entre las técnicas prácticas están trabajar en pareja en diseños y revisiones, dejar que ingenieros con menos experiencia redacten el ADR de una decisión y revisarlo con ellos, hacer katas de arquitectura (Sección 11.2) como práctica, delegar decisiones dentro de unos guardrails (salvaguardas) establecidos y explicar en voz alta tu razonamiento durante las discusiones de diseño, para que los demás vean cómo se sopesan los compromisos y no solo la conclusión.

Muchas organizaciones ofrecen hoy una trayectoria profesional técnica paralela a la de gestión. Staff Engineer: Leadership beyond the management track (2021), de Will Larson, popularizó el término staff-plus para los contribuidores individuales staff, principal y de nivel superior, y describió cuatro arquetipos habituales a partir de entrevistas con personas en esos puestos. The Staff Engineer's Path (O'Reilly, 2022), de Tanya Reilly, organiza el trabajo en torno a la visión de conjunto, la ejecución de grandes proyectos y el crecimiento de los ingenieros que te rodean. En su charla de 2019 "Being Glue", Reilly también llamó la atención sobre el trabajo de coordinación (desbloquear a las personas, escribir el documento que falta, detectar el hueco entre equipos) que mantiene vivos los proyectos pero que a menudo no se recompensa en los ascensos; los arquitectos deberían fijarse en quién lo hace y asegurarse de que cuente.

Arquetipos staff-plus (según Will Larson)

ArquetipoEnfoqueContribución arquitectónica típica
Tech lead (líder técnico)Guía el enfoque y la ejecución de un equipo, en colaboración con su responsableAsume las decisiones de arquitectura del equipo y las mantiene alineadas con el sistema en su conjunto
ArquitectoResponsable de la dirección, la calidad y el enfoque de un área críticaEstablece principios, revisa diseños y vela por las cualidades clave en varios equipos
Solucionador (solver)Se adentra en problemas difíciles y ambiguos y encuentra una salida, a menudo pasando de uno a otroResuelve la migración atascada, la crisis de rendimiento o el límite poco claro
Mano derechaAmplía el alcance de la atención de un directivo, tomando prestados su ámbito y su autoridadImpulsa iniciativas técnicas para toda la organización y conecta la estrategia con la ejecución

Las trampas de decisión, de nuevo

La Sección 1.6 enumeró los sesgos individuales que distorsionan las decisiones arquitectónicas: el anclaje, el costo hundido, el pensamiento de grupo, el desarrollo dirigido por el currículum, el bombo publicitario (hype) y el sesgo de confirmación. Dirigir decisiones en grupo añade trampas propias, que surgen del estatus, el cansancio y la inercia organizativa más que del razonamiento individual.

Trampas de grupo y organizativas

TrampaCómo se manifiestaContramedida
Deferencia ante la opinión de quien más cobraLa persona de mayor rango habla primero y la discusión converge hacia su punto de vistaPide a la persona de mayor rango que hable la última; recoge opiniones por escrito antes de la reunión
Escalada del compromisoUna iniciativa que fracasa recibe más inversión porque ya se ha comprometido mucho en ella (Barry Staw, 1976)Fija desde el principio criterios de cancelación y fechas de revisión; revisa con personas que no participaron
Bikeshedding (discutir lo trivial)Largos debates sobre detalles triviales y fáciles de entender mientras la decisión difícil recibe unos minutos (ley de la trivialidad de Parkinson, 1957)Limita el tiempo según la importancia; deja los detalles de puerta de doble sentido al equipo responsable de ellos
Decisión por desgasteGana la opción respaldada por quien más aguanta, una vez que todos los demás están cansadosAcuerda de antemano el método de decisión, quién decide y el plazo
Falso consensoEl silencio se toma como acuerdo; las objeciones aparecen después de la decisiónPide objeciones de forma explícita, por nombre si es necesario, y regístralas
No inventado aquí (not invented here)Las soluciones externas se rechazan porque no se construyeron internamenteCompara construir y comprar con los mismos criterios, incluido el costo de operar lo que construyes
Parálisis por análisisSiempre se pide más información; no se decide nada antes del último momento responsableFija la fecha de la decisión y qué pruebas serían suficientes; toma rápido las decisiones reversibles

Ejemplo práctico

Ejemplo práctico: cómo conducir una decisión disputada sobre un bus de eventos

Este ejemplo se remonta a la decisión que introdujo el intermediario de eventos (broker) de la plataforma de reparto de comida, antes de que existiera la arquitectura evaluada en la Sección 11.1. El equipo de plataforma propone que todos los servicios se comuniquen a través de un clúster de Kafka gestionado para toda la empresa. El equipo de pedidos está entusiasmado, el equipo de pagos se opone con fuerza, finanzas está preocupada por el costo y el CTO quiere una decisión en un mes. Según el proceso de consejo de la empresa, quien toma la decisión es el arquitecto jefe del equipo de plataforma. Se pide a un arquitecto principal que facilite el proceso.

1. Replantear la pregunta¿Kafka para todo? es una posición. El problema de fondo, tras dos caídas en viernes, es que hacer un pedido depende de llamadas síncronas a notificaciones y al despacho. La pregunta pasa a ser: ¿cómo deberían publicar los servicios los eventos de negocio, empezando por los eventos de pedido, para que los consumidores dejen de estar en la ruta del pedido? El alcance y los derechos de decisión se escriben al principio de un borrador de ADR.
2. Escuchar primero en privadoAntes de cualquier reunión, el facilitador habla con cada parte. Pagos: los datos de las tarjetas deben quedar fuera de los sistemas nuevos, y el equipo no puede asumir más trabajo de guardias tras un incidente doloroso con un broker autoalojado. Pedidos: necesita desacoplamiento para los picos. Finanzas: quiere limitar los costos de operación. Seguridad: necesita cifrado y control de acceso por topic. El equipo de plataforma: quiere un único estándar con soporte en lugar de cinco. Cada uno se registra como un interés, no como una posición.
3. Acordar los criterios antes que las opcionesEn el foro asesor de arquitectura, el grupo acuerda criterios ponderados: garantías de entrega y orden por pedido (5), carga operativa para los equipos de producto (5), alcance de cumplimiento normativo (4), costo de operación con el triple del volumen actual (3), conocimientos (3) y reversibilidad (3).
4. Generar opciones, incluidas las de quienes discrepanA: Kafka gestionado, obligatorio para todos los servicios. B: Kafka gestionado para los eventos del dominio de pedidos mediante una bandeja de salida transaccional (transactional outbox); los demás equipos se suman más adelante si quieren. C: los servicios más sencillos de publicación-suscripción y de colas del proveedor de nube. D: mantener las llamadas síncronas y añadir reintentos y circuit breakers. Pagos aporta la opción D y el análisis de costos de C.
5. Reunir pruebasUn spike de dos semanas ejecuta B y C con una carga similar a la de producción: latencia de extremo a extremo, comportamiento durante la conmutación por error del broker y costo mensual estimado. Seguridad confirma que los eventos de pedido pueden diseñarse sin datos de tarjetas, lo que los mantiene fuera del ámbito de las tarjetas de pago.
6. Ronda de consentimientoPropuesta: B, con el equipo de plataforma operando el clúster como X como servicio (X-as-a-Service). Pagos objeta que aun así podría verse arrastrado a la operación del broker; la objeción se resuelve escribiendo la responsabilidad y el horario de soporte del equipo de plataforma en su API del equipo. La inquietud de finanzas se convierte en una alerta de costos y un umbral de revisión. Una ingeniera de pedidos sigue prefiriendo C; puede vivir con B, y su razonamiento queda registrado.
7. Decidir, registrar y comunicarQuien toma la decisión acepta B. El ADR registra las opciones, las puntuaciones, los resultados del spike, la discrepancia y los desencadenantes de revisión (que más de tres equipos lo adopten, que los costos superen el umbral acordado o que pasen seis meses, lo que ocurra primero). El CTO y el CFO reciben un resumen de una página sobre el beneficio, el costo y el riesgo; los equipos reciben una sesión explicativa; la entrada del radar tecnológico se actualiza a Trial.
8. Hacer el seguimientoUna comprobación de compatibilidad de esquemas se ejecuta en el pipeline de cada productor, se vuelve a probar el escenario de la caída y, en la revisión de los seis meses, las pruebas se usan para decidir si ampliar, mantener o revertir la decisión.

El facilitador nunca defendió una opción; el trabajo se centró en el planteamiento, los intereses, los criterios, las pruebas y un método de decisión claro.

La discrepancia cambió el resultado (se redujo el alcance y se hizo explícita la responsabilidad de la plataforma) y quedó registrada en lugar de descartarse en silencio.

La decisión se hizo reversible en la práctica gracias a un alcance limitado y a unos desencadenantes de revisión acordados.

Comprueba lo que has entendido

¿Por qué hablar en privado con las partes interesadas antes de una reunión de decisión?

Para entender sus intereses en privado, evitar sorprenderlas en público y sacar a la luz las objeciones pronto, cuando todavía pueden dar forma a la propuesta.

¿En qué se diferencian la mentoría, el coaching y el patrocinio?

La mentoría comparte tu experiencia y tus consejos, el coaching hace preguntas que ayudan a alguien a llegar a su propia respuesta y el patrocinio usa tu credibilidad para crearle oportunidades.

¿Qué pierde un arquitecto si nunca deja la sala de máquinas?

La capacidad de influir en la estrategia: su conocimiento de los riesgos, las restricciones y las opciones nunca llega a las personas que toman las decisiones de inversión y organizativas.

¿Por qué debería registrarse la discrepancia en el registro de decisiones?

Para que se conserve el razonamiento, quienes discreparon sepan que se les escuchó y, si sus inquietudes se hacen realidad, la organización sepa qué revisar y por qué.

Siguiente · 11.8Ética y negocioCómo defender el trabajo de arquitectura en términos de dinero, tiempo y riesgo, con el valor actual neto y el periodo de recuperación calculados paso a paso; y cómo la ética profesional, los daños previsibles y las prácticas de software verde dan forma a un diseño responsable.Continuar →

Fuentes y lecturas recomendadas

¿Tienes una pregunta sobre esta sección? ArchitectBot, el asistente de estudio con IA del curso, responde primero a partir del curso.

Pregunta: “Dos ingenieros sénior de mi equipo están bloqueados sobre si adoptar un bus de eventos y los dos tienen parte de razón. ¿Cómo facilito una decisión que ambos apoyen de verdad?”