Software Architect · Módulo 21
La arquitectura no existe en el vacío. Tiene que ayudar al producto a ganar dinero, reducir riesgo y moverse a la velocidad correcta.
Business value · cost · risk · optionality · roadmap
Una buena decisión técnica tiene que tener sentido de negocio: velocidad, confiabilidad, menos riesgo, ahorro o una capacidad nueva.
El precio arquitectónico tiene que ser visible
El presupuesto de una obra no son sólo los ladrillos: incluye mantenimiento, reparaciones, seguro y tiempos muertos.
El total cost of ownership cubre desarrollo, operaciones, soporte, capacitación, migraciones, vendor lock-in, incident response y opportunity cost. Una decisión puede ser barata de construir y cara de operar.
El arquitecto traduce trade-offs técnicos a business terms entendibles: "Esta integración entrega un mes antes, pero suma diez horas semanales de soporte manual" o "Este refactor reduce el riesgo de perder pagos".
La optionality tiene un precio
Podés construir una casa pensando en agregar un segundo piso después. Pero los cimientos reforzados se pagan ahora.
A veces la arquitectura compra future optionality: poder entrar a una nueva región, agregar enterprise SSO, cambiar de payment provider, escalar el equipo. Eso vale la pena cuando la probabilidad y el valor del escenario futuro son suficientemente altos.
La mala optionality son abstracciones "por las dudas". La buena optionality es un camino de migración preparado para un escenario de negocio probable.
El arquitecto ayuda al producto a no confundir belleza técnica con efecto económico.
Ejemplo: posponer multi-region
Un negocio no monta logística internacional antes de entender la demanda en su primera ciudad.
Un startup lanza en una sola región pero modela los datos para poder agregar un region field y data residency más adelante. El multi-region deployment no se implementa ahora porque no hay clientes enterprise. El ADR fija el trigger: el primer contrato con un requisito de data residency.
Ese es un balance sano: no pagamos de más ahora y no cerramos el camino al crecimiento.
Antiejemplo: refactor sin product narrative
Podés cambiar el piso del taller. Pero si las máquinas quedan paradas un mes, hay que explicar qué gana el negocio a cambio.
El equipo pide un trimestre de rewrite porque "el código es malo". El negocio escucha que el roadmap se frena sin un retorno claro. Sin vínculo con cycle time, incident rate, hiring, compliance o revenue, suena como un deseo interno de ingeniería.
Las mejoras técnicas hay que atarlas a un product outcome o un operational outcome medible.
- ¿Qué propiedad de negocio compra esta decisión? - ¿Cuál es el total cost of ownership? - ¿Qué riesgo se reduce y qué tan real es? - ¿Cómo explicaría esta decisión sin detalles técnicos?