Las decisiones equivocadas salen caras más tarde.

Traducir los objetivos de calidad en una arquitectura verificable

«Rápido», «seguro» y «escalable» no bastan como requisito. Para un proceso de búsqueda necesitamos, por ejemplo, el volumen de datos previsto, los usuarios simultáneos y un tiempo de respuesta aceptable. Para la aprobación de un pedido, además, deben estar definidos los permisos, el registro y el comportamiento ante un fallo. Describimos estos escenarios de calidad con un desencadenante, un estado operativo y la reacción deseada. De ahí se derivan decisiones técnicas y pruebas posteriores.

Los objetivos pueden entrar en conflicto: una verificación exhaustiva de cada solicitud aumenta el esfuerzo de procesamiento; una vista de datos especialmente actualizada puede generar un acoplamiento adicional. Exponemos estos conflictos de objetivos y los priorizamos junto con los responsables. Por eso la arquitectura no contiene solo componentes, sino también hipótesis, límites y evidencias. Un prototipo de carga responde a una pregunta distinta de la de un diseño de interfaz interactivo. Ambos reciben un encargo de verificación concreto y un final definido.

Límites del sistema, soberanía sobre los datos y responsabilidades

Cuando un pedido, una factura y una ficha maestra de cliente existen en varias aplicaciones, debe quedar claro quién puede modificar qué información. Delimitamos los ámbitos de responsabilidad de negocio y diferenciamos sus conceptos. «Cliente» puede significar datos y reglas distintos para ventas, contabilidad y soporte. Un modelo de base de datos común para todos los ámbitos simplifica al principio la implementación, pero puede vincular fuertemente entre sí los cambios posteriores.

Analizamos los límites de los módulos, las dependencias y los traspasos entre equipos. Un despliegue independiente solo merece la pena cuando la independencia obtenida justifica el esfuerzo adicional en interfaces, monitorización y gestión de errores. La decisión entre una aplicación modular y servicios distribuidos depende también del tamaño del equipo, la responsabilidad sobre los releases y la capacidad operativa. La matriz de responsabilidades, el contexto del sistema y las decisiones de arquitectura documentadas dejan constancia de quién puede modificar un límite y qué otros equipos deben participar.

Inversión, deuda técnica y una hoja de ruta viable

Un concepto de arquitectura debe poder financiarse e integrarse en la operación en curso. Analizamos juntos el esfuerzo de desarrollo, las licencias, la migración de datos, la infraestructura y el mantenimiento a largo plazo. La deuda técnica ya existente se evalúa según qué cambios dificulta o qué fallos favorece. No todo componente anticuado debe sustituirse de inmediato; un componente pequeño y estable puede ser menos arriesgado que su sustitución mal preparada.

La hoja de ruta vincula las etapas de negocio con los requisitos técnicos previos. Antes de un nuevo portal de socios, por ejemplo, puede ser necesario aclarar primero la gestión de permisos. Cada etapa recibe un resultado, puntos de decisión y dependencias identificadas. Para los costes utilizamos hipótesis y rangos verificables mientras existan incógnitas relevantes. Así puede comparar ofertas y decidir si un estudio adicional es más conveniente que un encargo de implementación precipitado.