Lo que se pide y lo que se espera
Los requisitos funcionales se escriben solos: el sistema debe registrar pedidos, emitir facturas, enviar avisos. Los otros, los que deciden de verdad la arquitectura, casi nunca se escriben: cuánto tiempo puede estar caído, cuántos datos puede perder, cuánto puede costar al mes, cuántos usuarios debe aguantar el día de más carga.
Nadie los pide, pero todos los dan por hechos. Y cuando el sistema no los cumple, el problema no es técnico: es que nunca se acordaron.
Los atributos que deciden el diseño
- Disponibilidad. Qué porcentaje del tiempo debe funcionar y en qué horario importa.
- Recuperación. Cuánto puede tardar en volver tras un fallo (objetivo de tiempo de recuperación) y cuántos datos puede perder (objetivo de punto de recuperación).
- Rendimiento. Tiempo de respuesta aceptable y carga máxima esperada.
- Seguridad. Qué datos maneja, quién puede acceder y qué normativa aplica.
- Costo. Cuánto puede costar operarlo, y cómo debe crecer ese costo con el uso.
- Operabilidad. Quién lo opera, con qué conocimientos y con qué herramientas.
Todo tiene un precio
Ningún diseño maximiza todo a la vez. Más disponibilidad significa más redundancia, y más redundancia significa más costo. Recuperarse en minutos exige réplicas que cuestan dinero todos los meses. Por eso los atributos de calidad no se piden "al máximo": se negocian y se escriben con un número.
"Alta disponibilidad" no es un requisito. "Disponible el 99,9 % del tiempo en horario laboral, con recuperación en menos de una hora y pérdida máxima de quince minutos de datos" sí lo es, y permite diseñar, estimar y comprobar.
Cómo hacerlos explícitos
- Preguntar por las consecuencias, no por los números: ¿qué pasa si esto está caído una hora un lunes? La respuesta da el número.
- Escribirlos en una tabla corta, con un valor por atributo y quién lo acordó.
- Ligarlos al costo: cada atributo con su impacto estimado en la factura mensual.
- Revisarlos cuando cambie el negocio, no cuando falle el sistema.
Con los requisitos escritos, cada decisión de arquitectura tiene contra qué medirse. Sin ellos, cualquier diseño parece razonable.
Cómo lo aplicamos: Arquitectura Cloud.