Ética, sostenibilidad y el caso de negocio

Por qué los arquitectos necesitan casos de negocio

El trabajo de arquitectura compite por el dinero y las personas con todo lo demás que una organización quiere hacer. Una migración, una plataforma, un programa de resiliencia o el pago de una deuda rara vez producen una funcionalidad que un cliente pueda ver, así que es fácil aplazarlos en favor del trabajo que sí la produce. Los arquitectos que consiguen financiación para ese trabajo no suelen ser los que tienen los diseños más elegantes, sino los que saben expresar el argumento en los términos que usan los responsables de decisión para comparar inversiones: cuánto cuesta, qué rinde, en cuánto tiempo, con qué certeza y qué ocurre si no lo hacemos. Ese argumento estructurado es un caso de negocio (business case).

Esta es la cara orientada al negocio de todo lo que este curso ha dicho sobre los compromisos. Un caso de negocio es un registro de decisión para una inversión: contexto, opciones, criterios, consecuencias y una recomendación, con las consecuencias expresadas en la medida de lo posible en dinero, tiempo y riesgo. No sustituye al criterio arquitectónico, y gran parte de lo que protege la arquitectura (la seguridad, el aprendizaje, la opcionalidad) es difícil de valorar en dinero. Pero poner cifras honestas donde se pueden poner, y decir con claridad dónde no se puede, da derecho a ser escuchado sobre el resto.

Las organizaciones usan formatos distintos. El Green Book del Gobierno del Reino Unido, publicado por HM Treasury, estructura los casos del sector público en torno a cinco preguntas: el caso estratégico (por qué hace falta el cambio), el caso económico (qué opción ofrece el mejor valor), el caso comercial (si se puede contratar), el caso financiero (si es asequible) y el caso de gestión (si se puede llevar a cabo). La mayoría de las empresas usan algo más ligero, pero vale la pena responder a las mismas preguntas para cualquier inversión de arquitectura significativa.

Opciones, costos, beneficios y riesgos

Todo caso de negocio debería comparar al menos tres opciones: no hacer nada (la línea de base), hacer lo mínimo y la opción recomendada, además de cualquier alternativa seria. No hacer nada rara vez sale gratis. El contrato de soporte del sistema heredado sube, la tasa de incidentes crece con el tráfico y los cambios se vuelven cada vez más lentos; esa deriva es la línea de base con la que se miden los beneficios de las demás opciones, y omitirla hace que toda inversión parezca peor de lo que es.

Los costos y los beneficios deberían enumerarse por categorías para que no se olvide ninguno ni se cuente ninguno dos veces. Los riesgos deben figurar explícitamente en el caso: tanto los riesgos que la inversión reduce, que pueden valorarse como pérdidas esperadas evitadas (probabilidad multiplicada por impacto), como los riesgos de la propia inversión, como un sobrecosto o las interrupciones durante la migración. El costo del retraso de Don Reinertsen, de The Principles of Product Development Flow (2009), es una perspectiva adicional útil: el valor que se pierde cada semana que un trabajo no se entrega. Dividir el costo del retraso por la duración (weighted shortest job first, primero el trabajo más corto ponderado) ofrece una forma defendible de ordenar trabajos que compiten entre sí.

Por último, estructura la inversión como una serie de etapas con puntos de decisión en lugar de un único gran compromiso. La migración incremental de la Sección 11.6 es un buen ejemplo: cada paso entrega algo y genera pruebas, así que la financiación puede liberarse paso a paso y el programa puede detenerse si los beneficios no aparecen. Las compuertas por etapas de este tipo convierten una apuesta arriesgada en un conjunto de opciones más pequeñas, que es el razonamiento sobre la reversibilidad de la Sección 1.6 aplicado al dinero.

Valor actual neto y periodo de recuperación

El dinero de ahora vale más que el dinero futuro: puede invertirse, y el dinero futuro es menos seguro. Para comparar flujos de caja que llegan en años distintos, los equipos de finanzas convierten cada uno a su valor de hoy, usando una tasa de descuento que refleja el costo de capital de la organización y el riesgo de la inversión. Normalmente la tasa la fija el departamento de finanzas, y los arquitectos deberían usarla en lugar de elegir la suya propia.

El valor actual neto (NPV) de una inversión es la suma de todos sus flujos de caja, cada uno descontado a hoy: NPV = Σ C_t ÷ (1 + r)^t, sumado para los años t = 0 a n, donde C_t es el flujo de caja neto del año t (negativo para los costos) y r es la tasa de descuento anual. El flujo de caja del año 0 es la inversión inicial y no se descuenta. Un NPV positivo significa que la inversión rinde más que la tasa de descuento; al elegir entre opciones de riesgo similar, la de mayor NPV es la que crea más valor.

El periodo de recuperación (payback) es más sencillo: cuánto tiempo pasa hasta que el flujo de caja acumulado se vuelve positivo. A los directivos les gusta porque es fácil de entender y porque recoge el riesgo de forma aproximada (cuanto antes se recupera el dinero, menos puede salir mal), pero ignora todo lo que ocurre después del punto de recuperación. El periodo de recuperación descontado hace el mismo cálculo con flujos de caja descontados. Presenta tanto el NPV como el periodo de recuperación, y muestra lo sensibles que son a las estimaciones que más importan.

def npv(rate, cash_flows):
    """cash_flows[0] is year 0 (the investment, usually negative)."""
    return sum(c / (1 + rate) ** t for t, c in enumerate(cash_flows))

flows = [-420_000, 150_000, 190_000, 190_000, 190_000]
print(round(npv(0.10, flows)))        # 145911
print(round(npv(0.15, flows)))        # 87663

pessimistic = [flows[0]] + [c * 0.7 for c in flows[1:]]
print(round(npv(0.10, pessimistic)))  # -23862

La deuda técnica en dinero y tiempo

La Sección 1.7 explicó la deuda técnica como principal (el costo de corregir un problema) e interés (el costo adicional que se paga en cada cambio mientras el problema sigue ahí), y estimó el interés de un módulo enmarañado. Un caso de negocio necesita esas mismas magnitudes en una forma que finanzas reconozca. El interés se convierte en un costo anual; el principal se convierte en la inversión; y saldar la deuda se convierte en una inversión cuyo rendimiento es el interés que se deja de pagar, más cualquier reducción de riesgos y las oportunidades que se habilitan.

Se pueden convertir varios tipos de pruebas. Tiempo de los desarrolladores: días adicionales por cambio, a partir de comparaciones con cambios similares en otras partes o de estimaciones de los desarrolladores, multiplicados por el volumen de cambios y por una tarifa diaria con costos totales. Retraso: tiempos de entrega más largos multiplicados por el costo del retraso del trabajo afectado. Incidentes: el número y la duración de los incidentes atribuidos a la deuda, multiplicados por su costo. Riesgo: la probabilidad y el impacto de los fallos que la deuda hace más probables, como una brecha de seguridad a través de un componente sin soporte. Oportunidad: las iniciativas de negocio que la deuda bloquea por completo.

Ten cuidado con las cifras de deuda que producen las herramientas de análisis estático, que normalmente indican un esfuerzo de corrección estimado (cuánto se tardaría en corregir cada problema señalado). Eso es una estimación del principal, no del interés, y no dice nada sobre si el código se modifica alguna vez. La deuda en código que rara vez se toca cuesta poco; los hotspots de la Sección 1.7 son donde realmente se pagan los intereses, y donde saldar la deuda tiene el mejor rendimiento. Presentar la deuda como una cartera de pequeñas inversiones, cada una con un rendimiento y un periodo de recuperación estimados, suele ser mucho más persuasivo que una única cifra llamativa de deuda total.

Ética: qué piden los códigos profesionales

Las decisiones arquitectónicas determinan lo que los sistemas hacen a las personas que los usan y a las personas a las que afectan sin su consentimiento, así que los arquitectos tienen responsabilidades éticas además de técnicas. Hay dos códigos profesionales especialmente pertinentes. El Código de Ética y Conducta Profesional de la ACM (ACM Code of Ethics and Professional Conduct), actualizado por la Association for Computing Machinery en 2018, empieza con unos principios generales: contribuir a la sociedad y al bienestar humano, reconociendo que todas las personas son partes interesadas en la informática; evitar daños; ser honesto y digno de confianza; ser justo y actuar para no discriminar; respetar el trabajo necesario para producir ideas nuevas; respetar la privacidad; y respetar la confidencialidad. Entre sus responsabilidades profesionales están ofrecer evaluaciones completas y rigurosas de los sistemas informáticos y de sus impactos, incluido el análisis de los posibles riesgos, y diseñar sistemas que sean seguros de forma robusta y utilizable; sus principios de liderazgo piden un cuidado especial con los sistemas que pasan a integrarse en la infraestructura de la sociedad.

El Código de Conducta de la BCS, de BCS, The Chartered Institute for IT, del Reino Unido, se organiza en torno a cuatro deberes: hacia el interés público (incluidos la salud pública, la privacidad, la seguridad, el bienestar, el medio ambiente y la igualdad de acceso), hacia la competencia y la integridad profesionales, hacia la autoridad pertinente (el empleador o el cliente) y hacia la profesión. El Código de Ética de la Ingeniería de Software conjunto de la ACM y la IEEE Computer Society (1999) añade ocho principios, empezando por el interés público, que prevalece sobre los intereses del cliente y del empleador.

Para los arquitectos, estos códigos se traducen en obligaciones concretas. Analiza los efectos previsibles de un diseño, no solo su corrección funcional. Informa con honestidad a los responsables de decisión sobre los riesgos, incluidos los que preferirían no oír. Niégate a diseñar sistemas destinados a engañar o a causar daño, y escala la cuestión cuando te lo pidan. Registra en el registro de decisiones las discrepancias por motivos éticos. Y sabe a quién acudir si la escalada interna fracasa: en el Reino Unido, por ejemplo, la Public Interest Disclosure Act 1998 protege a los trabajadores que denuncian determinados tipos de irregularidades.

Los patrones oscuros y otros daños previsibles

La tabla enumera los daños que con más frecuencia están al alcance de un arquitecto. Varios se tratan a fondo en otras partes: la privacidad y la seguridad en el Capítulo 8, la accesibilidad como cualidad en la Sección 2.7 y el sesgo en los sistemas de aprendizaje automático en el Capítulo 12. La accesibilidad es cada vez más una restricción legal además de ética; en la UE, el Acta Europea de Accesibilidad (European Accessibility Act) se aplica a muchos servicios de consumo, incluido el comercio electrónico, desde el 28 de junio de 2025.

El diseño manipulador merece una mención especial porque a menudo se solicita deliberadamente. Harry Brignull acuñó en 2010 el término patrón oscuro (dark pattern) para las interfaces diseñadas para engañar a las personas y llevarlas a decisiones que de otro modo no tomarían; ahora prefiere el término patrones engañosos (deceptive patterns). Entre los ejemplos conocidos están los precios por goteo (drip pricing, comisiones que solo se revelan al final), el confirmshaming (hacer que la opción de decir que no resulte vergonzosa), la falsa urgencia y escasez, las casillas de consentimiento premarcadas y las suscripciones fáciles de iniciar y difíciles de cancelar. Los reguladores han actuado: la Ley de Servicios Digitales de la UE (Digital Services Act, 2022) prohíbe a las plataformas en línea diseñar interfaces que engañen o manipulen a sus usuarios, y la Federal Trade Commission de EE. UU. publicó en 2022 un informe de su personal técnico sobre los patrones oscuros. Muchos de estos patrones necesitan soporte arquitectónico (una API de precios que oculta las comisiones hasta el proceso de pago, un flujo de cancelación que pasa por un servicio de retención), así que los arquitectos están en posición de detectarlos y cuestionarlos.

La forma más sencilla de hacer visibles los daños es buscarlos a propósito, en los mismos momentos en que buscas los riesgos técnicos. Añade una pregunta sobre daños al modelado de amenazas y a las revisiones de diseño: ¿quién podría resultar perjudicado por este sistema si funciona tal como está diseñado, si falla o si se usa de forma indebida? Prácticas como el consequence scanning (análisis de consecuencias), desarrollado por el think tank británico Doteveryone, dan a los equipos un formato breve y estructurado para esta conversación durante la planificación.

Sostenibilidad: software verde

El software no quema combustible, pero la electricidad y el hardware que usa sí, y las decisiones arquitectónicas fijan gran parte de esa huella durante años. La Green Software Foundation, creada en 2021 bajo la Linux Foundation, publica seis áreas fundamentales de las prácticas de software verde: la eficiencia en carbono (emitir el menor carbono posible), la eficiencia energética (usar la menor energía posible), la conciencia del carbono (hacer más cuando la electricidad es más limpia y menos cuando es más sucia), la eficiencia del hardware (usar el menor carbono incorporado posible), la medición y los compromisos climáticos (entender exactamente cómo se logra una reducción).

La computación consciente del carbono aprovecha el hecho de que la intensidad de carbono de la electricidad varía según la hora y la región con la combinación de eólica, solar, gas y otras fuentes. El desplazamiento de la demanda (demand shifting) traslada el trabajo flexible, como los procesos por lotes, el entrenamiento de modelos, las copias de seguridad y la generación de informes, a momentos o regiones en los que la electricidad es más limpia; la modulación de la demanda (demand shaping) reduce lo que hace el software cuando es más sucia, por ejemplo sirviendo contenido multimedia de menor resolución o aplazando los recálculos no urgentes. Los servicios de datos de la red eléctrica, como la Carbon Intensity API para Gran Bretaña, y las herramientas de código abierto, como el Carbon Aware SDK de la fundación, proporcionan las señales. Como ilustración sencilla, un proceso por lotes nocturno que usa 400 kWh emite unos 120 kg de CO₂e a unos ilustrativos 300 g por kWh a primera hora de la noche, pero unos 48 kg si se traslada a una noche ventosa a 120 g por kWh.

El carbono incorporado, es decir, las emisiones de fabricar y desechar el hardware, es la razón por la que importa la eficiencia del hardware: un mayor aprovechamiento de menos máquinas, escalar a cero cuando no hay actividad y alargar la vida útil de los dispositivos (incluidos los teléfonos de los clientes, al no exigir hardware nuevo en cada lanzamiento) lo reducen. La especificación Software Carbon Intensity de la fundación, publicada como ISO/IEC 21031:2024 y presentada en la Sección 2.7, combina las emisiones operativas y las incorporadas por unidad funcional, como por pedido entregado, y excluye las compensaciones (offsets) para que solo las reducciones reales mejoren la puntuación.

Entre las palancas arquitectónicas están el ajuste del tamaño (right-sizing) y el autoescalado, eliminar los entornos ociosos, los límites de conservación de datos (los datos almacenados tienen un costo en energía y en hardware), los formatos de datos eficientes y la caché, elegir regiones con redes eléctricas más limpias cuando la latencia y la residencia de datos lo permitan, y cuestionar si cada funcionalidad necesita una llamada a un modelo grande. Cuidado con el efecto rebote, la versión moderna de la observación de William Stanley Jevons sobre el carbón en 1865: la eficiencia que abarata algo puede aumentar su uso total, así que mide las emisiones totales además de la intensidad.