Después de una sesión de premortem con stakeholders, el arquitecto de software no solo ajusta prioridades: interviene directamente en el código para blindar el sistema. Esta guía explica cómo traducir esas conversaciones en pruebas, patrones y prototipos que preparan la evolución de la arquitectura.
¿Qué cambia en tu equipo después de hablar con los stakeholders?
Las técnicas de conversación con stakeholders tienen un efecto inmediato sobre el rumbo técnico. Puedes terminar reordenando prioridades del equipo o asumiendo tú mismo intervenciones para extender o reparar el diseño previo.
En el caso del premortem, tu rol como arquitecto se vuelve activo: agregas nuevos escenarios de prueba para validar cómo se comporta el sistema frente a condiciones especiales. Aquí entra en juego el behavior-driven development, una práctica que conecta la conversación de negocio con pruebas ejecutables.
¿Qué es un premortem en arquitectura de software? Es una conversación previa con stakeholders donde imaginas que el sistema falló y trabajas hacia atrás para identificar las causas. Esas causas se convierten en escenarios de prueba.
¿Cómo escribir nuevos tests a partir de un premortem?
Una de las intervenciones más directas es escribir tests sobre un feature ya establecido. Y aquí viene lo interesante: estas pruebas tienen una estructura clara que nace del premortem.
En este tipo de pruebas puedes apoyarte en tres elementos:
- Un background común, que establece las condiciones de semilla que llevaron al comportamiento inesperado.
- Escenarios positivos, que validan que el sistema responde bien cuando los datos son correctos.
- Escenarios negativos, que validan las condiciones problemáticas descubiertas en el premortem.
Un ejemplo concreto: facturas de importación y exportación con datos incompatibles entre sí. Con ese escenario validas que el sistema maneja las excepciones y las condiciones de error como esperas, en vez de descubrirlo en producción.
¿De qué otras formas puede intervenir un arquitecto en el código?
Escribir tests no es la única vía. Como arquitecto, tienes varias herramientas para intervenir directamente y dar ejemplo al resto de los equipos.
Pruebas de concepto para validar alternativas
Las pruebas de concepto te permiten explorar alternativas, diseños y herramientas. Algunas terminan integrándose al diseño holístico del sistema; otras se desechan, y eso también es un resultado válido. Lo importante es que la decisión queda respaldada por evidencia técnica, no por intuición.
Patrones de manejo de excepciones
Implementar tú mismo los patrones de manejo de excepciones tiene un efecto pedagógico. Cuando los demás equipos ven cómo aplicas la técnica, adoptan un estándar consistente en lugar de inventar soluciones aisladas para el mismo problema.
Patrones de transacciones de negocio distribuidas
Las transacciones distribuidas son difíciles de sostener mentalmente para muchos desarrolladores. Por eso, implementar tú el patrón sirve como referencia viva: muestra cómo coordinar operaciones entre servicios sin perder consistencia ni claridad.
¿Por qué un arquitecto debe escribir código y no solo diseñar? Porque la intervención directa en pruebas, patrones de excepción y transacciones distribuidas marca el estándar técnico que el resto del equipo seguirá.
¿Cómo prepara esto la evolución de la arquitectura?
Comunicarte con stakeholders no técnicos e intervenir en el aspecto técnico del sistema es, en el fondo, la preparación para que la arquitectura evolucione. Son dos caras de la misma moneda.
Las técnicas de refactorización son muy poderosas, y cuando las aplicas de forma continua empiezas a notar señales: tu arquitectura y tu diseño necesitan moverse hacia otro lugar. Existen formas cuantitativas para identificar esos momentos, y es ahí donde una arquitectura que empezó limpia puede necesitar migrar a otros estilos o abordar nuevos casos de uso de manera novedosa.
¿Cuál de estas intervenciones aplicarías primero en tu equipo: nuevos tests, pruebas de concepto o patrones de excepción? Cuéntame en los comentarios.
