Definición de Restricciones

Nivel intermedio — identificar, documentar y comunicar los límites que acotan las opciones arquitectónicas antes de diseñar.

Idea central Las restricciones definen el espacio de soluciones posibles. Diseñar sin conocerlas es planear una ruta sin saber qué caminos están cerrados: terminas con soluciones técnicamente correctas pero imposibles de implementar.

01 —

El problema

Situación típica: el arquitecto presenta una solución basada en microservicios con Kubernetes. El CTO pregunta: "¿Tenemos a alguien que sepa Kubernetes?" Silencio. El arquitecto no preguntó sobre el equipo antes de diseñar. // una solución elegante que nadie puede operar no es una solución

El equipo solo conoce Java pero el diseño asume Go. El presupuesto es de $50K pero la arquitectura requiere licencias de $200K. El lanzamiento es en 3 meses pero el plan técnico requiere 9.

02 —

Taxonomía de restricciones

1. Restricciones de negocio

Restricción	Qué limita	Pregunta para descubrirla
Presupuesto	Tecnologías, infraestructura, equipo	"¿Cuál es el presupuesto total? ¿CapEx o OpEx?"
Tiempo (time-to-market)	Alcance, calidad técnica	"¿Cuál es la fecha límite no negociable? ¿Por qué?"
Roadmap de producto	Prioridades de desarrollo	"¿Qué features son obligatorios para el lanzamiento?"
Modelo de negocio	Opciones de hosting, SLAs	"¿Es SaaS multi-tenant o on-premise?"

2. Restricciones técnicas

Restricción	Qué limita	Pregunta para descubrirla
Equipo disponible	Stack tecnológico, complejidad	"¿Qué tecnologías domina el equipo actual?"
Sistemas legacy	Integraciones, migraciones	"¿Qué sistemas deben mantenerse sin cambios?"
Deuda técnica	Tiempo para nuevos features	"¿Qué problemas técnicos heredamos?"

3. Restricciones regulatorias

Restricción	Qué limita	Pregunta para descubrirla
GDPR/Privacidad	Almacenamiento y procesamiento de datos	"¿Dónde residen los usuarios? ¿Qué datos son PII?"
Sector (HIPAA, PCI-DSS)	Cifrado, auditoría, certificaciones	"¿Qué certificaciones necesitamos?"
Jurisdicción de datos	Ubicación de servidores	"¿Hay países donde NO pueden estar los datos?"

03 —

Explícitas vs. implícitas

Explícitas — te las dicen directamente: "el presupuesto es $100K", "debe cumplir GDPR", "lanzamos el 1 de marzo".

Implícitas — hay que inferirlas:

"Nuestro equipo siempre ha usado .NET" → no puedes asumir que aprenderán Go en 3 meses
"Usamos AWS para todo" → probablemente hay contrato enterprise que limita opciones
"El sistema actual es crítico" → no puedes hacer big-bang replacement

04 —

Cuándo documentarlo formalmente

Documenta formalmente si...	Basta con notas informales si...
El proyecto tiene múltiples stakeholders	Es un proyecto interno pequeño
Hay decisiones de compra/licencia	Solo usas tecnología interna conocida
El equipo no conoce el contexto completo	Todos conocen las limitaciones

No documentada no significa que no exista

Una restricción no escrita sigue limitándote — solo te sorprende más tarde, como el caso de Kubernetes sin equipo que lo sepa. Pero documentar formalmente cada restricción de un proyecto interno pequeño donde todos ya conocen el contexto es burocracia sin retorno. Usa la tabla de arriba para calibrar cuánto esfuerzo merece.

05 —

Practica: banco regional

"Somos un banco regional en México. Necesitamos modernizar nuestro sistema de préstamos personales que tiene 15 años. El equipo actual son 6 desarrolladores COBOL y 2 Java. Tenemos contrato con Oracle hasta 2026. El regulador (CNBV) nos exige trazabilidad de todas las decisiones de crédito. Queremos lanzar una versión piloto en 6 meses con 10% de las sucursales. El presupuesto aprobado es 3 millones de pesos mexicanos (~$175K USD)."

Extrae todas las restricciones de este brief — explícitas e implícitas — y clasifícalas en las 3 categorías.