Tradeoffs o compromisos (traducción comúnmente aceptada) son aquellas situaciones en las que balanceamos, considerando beneficio y pérdida, atributos de calidad de un sistema software-intensivo. Wikipedia agrega la idea de «sacrificio» [1]. Sacrificio es el resultado de haber tratado el tradeoff entre dos o más propiedades cualitativas. Primero reconocemos la existencia de una situación en la que existe un compromiso entre una u otra alternativa y luego decidimos en beneficio de una de las alternativas sacrificando el beneficio de la otra (u otras).

Los tradeoffs o compromisos están siempre presentes en todo diseño de sistema software-intensivo. En mi opinión, difícilmente podríamos hablar de ingeniería de software si no existieran pues es aquí donde ponemos en marcha gran parte de las herramientas, técnicas y métodos de la ingeniería para decidir finalmente cuál será la estructura (arquitectura) del sistema de software en cuestión y que implica el haber tomado una determinación acerca de los compromisos existentes entre los varios atributos de calidad asociados.

Sin embargo, rara vez estas características cualitativas, y con mayor razón los compromisos entre estas, son evidentes en el desarrollo. En la práctica, la experiencia termina tomando un rol protagónico haciendo del diseño un asunto de satisfacción de problemas [2]. ¡De ahí la importancia de contar con miradas frescas y no solo experimentadas en el diseño de un sistema!

Un caso que he observado en varias ocasiones se da en el compromiso entre las propiedades «confidencialidad» y «disponibilidad». En concreto, para asegurar la confiabilidad parece del todo claro que la superficie de ataque debe ser reducida. Por otro lado, y para su aseguramiento, la disponibilidad va a requerir de una serie de registros, en su mayoría «logs» automáticos, que ineludiblemente van a terminar agrandando la potencial superficie de ataque. Un ejemplo concreto muy básico: los ingenieros de seguridad no quieren que un potencial atacante pueda determinar si el rechazo al ingreso en un sistema se debe a que el nombre de usuario o la contraseña estaban incorrectos; los ingenieros encargados de la disponibilidad quieren mantener un archivo de registro en el que se especifique si fue el nombre de usuario o la contraseña (o ambos) los que estaban incorrectos para determinar con precisión, y en el menor tiempo posible, el problema que eventualmente pueda ser reportado por un usuario. La siguiente figura muestra una simplificación de un análisis de tradeoffs haciendo uso de signo + y signo – para indicar si la operacionalización (logs exhaustivos) tiene incidencia positiva o negativa, respectivamente, sobre los atributos de calidad.

No todos los casos son sencillos de resolver como el mencionado. En el ejemplo, muy probablemente los ingenieros determinarán que el «costo» o sacrificio que implica perder datos para asegurar la disponibilidad puede ser pagado a cambio de mayor confidencialidad (¡aunque esto siempre depende de los objetivos del negocio!). Me ha tocado ver también casos en los que el debate es fervoroso, situaciones en las que la «confidencialidad» se enfrenta a asuntos mandados por normas institucionales o legales y que exigen de parte de la «disponibilidad» un acabado registro de los eventos y operaciones del sistema.

Las evaluaciones de arquitectura son instancias formales en las que se hacen evidentes estas propiedades cualitativas, sus compromisos y se discute la resolución de estos últimos. En las evaluaciones también se discuten objetivos e impulsores del negocio y escenarios de uso actuales y futuros, lo que permite aportar en la toma de decisiones de diseño para atender y manejar el compromiso.

[1] «Trade-off», https://es.wikipedia.org/wiki/Trade-off. Última revisión: enero de 2021.

[2] «Software Designers Satisfice», Antony Tang y Hans van Vliet, ECSA 2015.