Sustainability

Intención y convención editorial

Sustainability describe aquí la capacidad de satisfacer necesidades de servicio con impacto de recursos y de ciclo de vida justificado, evitando compromisos que dificulten innecesariamente sostener el sistema y su contexto futuro. La evaluación necesita señalar qué impacto, horizonte y población interesa; no significa «todo lo bueno de una arquitectura».

La literatura de Sustainability Design and Software: The Karlskrona Manifesto, ICSE 2015 trata sostenibilidad como preocupación sistémica y multidimensional, incluyendo efectos a lo largo del tiempo. Ese marco fundamenta el alcance, sin convertir cada beneficio técnico en una demostración de Sustainability.

El Atlas prioriza impacto ambiental y de recursos, junto con la capacidad de sostener responsablemente el sistema durante su lifecycle. architectural-drivers identifica stakeholders y obligaciones; utility-trees prioriza escenarios. Este atributo no domina universalmente costo, seguridad o continuidad. Los ejemplos de Orders que siguen son propios, no evaluaciones ambientales del Atlas.

Dimensiones sin una suma de qualities

Dimensión	Pregunta que puede importar
Ambiental	¿Qué consumo de energía, materiales y otros recursos e impactos genera el sistema?
Técnica / longevity	¿Puede seguir siendo útil y mantenido mientras cambian dependencias y condiciones?
Económica	¿Existen recursos y valor suficientes para sostenerlo durante el horizonte considerado?
Organizacional / social	¿Cómo afecta su continuidad a equipos y participantes, y qué cargas les impone?

La literatura citada también distingue una dimensión individual. No desarrollamos todas con igual profundidad ni presentamos la tabla como taxonomy universal. Un análisis ambiental no demuestra automáticamente viabilidad económica o consecuencias sociales aceptables; hay que reconocer qué quedó fuera de la evaluación.

Arquitectónicamente interesa cómo decisiones sobre cómputo, datos, fronteras, actualización y operación condicionan esos resultados. El alcance tampoco autoriza calcular un puntaje agregado de arquitectura o certificar sostenibilidad global a partir de una mejora local.

Impacto ambiental y recursos

Importan energía, hardware requerido, movimiento de datos, crecimiento de almacenamiento y trabajo computacional innecesario. Según la frontera también pueden importar agua, materiales y residuos. Reducir todo a electricidad o carbono omite impactos que podrían ser relevantes para los stakeholders.

Conviene separar consumo durante operación del ciclo de vida del equipamiento. Green Software Foundation: Hardware Efficiency trata emisiones incorporadas y vida útil del hardware. Las exigencias del software pueden influir en sustitución de equipos: crecimiento injustificado de memoria o retirada de plataformas soportadas puede cambiar cuánto hardware se necesita.

Eso no prescribe conservar cualquier equipo indefinidamente. Seguridad, soporte y capacidad requerida pueden justificar renovación. La comparación debe considerar impacto de fabricar y retirar hardware, consumo operacional y utilidad restante, sin transformarse aquí en una política de procurement.

Energía, intensidad y emisiones

La energía consumida puede expresarse en kWh. La intensidad de carbono de la electricidad relaciona emisiones con energía, por ejemplo gCO2e/kWh, para una ubicación y período. Emisiones operacionales y energía no son unidades intercambiables: igual consumo puede corresponder a emisiones diferentes según su contexto energético.

La Software Carbon Intensity Specification v1.1.0 distingue energía, intensidad de carbono y emisiones incorporadas del hardware. Estas últimas corresponden a creación y disposición del equipo, con una parte atribuida al software. SCI combina emisiones operacionales e incorporadas por una unidad funcional declarada.

SCI evalúa una dimensión de impacto, no Sustainability completa ni una puntuación general de arquitectura. No es requisito del Atlas. Tampoco una declaración comercial de energía renovable sustituye automáticamente el método de cuantificación y sus reglas.

Menos CPU no equivale a una reducción proporcional de carbono. Hardware, energía de baseline, utilización, ubicación, tiempo y asignación entre workloads pueden cambiar la relación. GSF: Energy Efficiency explica que consumo y utilización del hardware requieren contexto; bajar una métrica aislada no demuestra una disminución física equivalente.

Medición, proxies e incertidumbre

Una evaluación puede combinar medición energética, datos de hardware, intensidad eléctrica y modelos de emisiones. GSF: Measurement distingue métodos y datos necesarios para cuantificar impacto. Hay que declarar frontera, período, unidad de trabajo, fuente, método de atribución y supuestos de estimación.

CPU, memoria, GB almacenados y bytes transferidos permiten investigar recursos. Factura o costo por pedido pueden orientar preguntas económicas. Son proxies, no mediciones directas de emisiones. Su utilidad depende de la hipótesis: menos transferencia muestra menos datos movidos, sin indicar por sí sola cuánto carbono se evitó.

La información puede ser parcial, especialmente sobre infraestructura compartida o administrada. Conviene registrar cobertura e incertidumbre y evitar precisión falsa. Comparar alternativas requiere fronteras consistentes: excluir una dependencia externa en una opción y contarla en otra puede desplazar impacto fuera de la medida.

También hay que observar impacto absoluto y por unidad. En un ejemplo aritmético, reducir consumo por pedido no garantiza menor consumo anual si el volumen crece más. Eso no invalida la mejora; delimita qué demuestra. No hace falta una digresión sobre efectos económicos para reconocer ambos resultados.

Decisiones enfocadas y evidencia

Eliminar trabajo innecesario puede reducir cómputo; adecuar recursos a demanda puede evitar capacidad permanente sin utilidad; localizar datos puede reducir transferencias repetidas. Son decisiones candidatas respaldadas por una necesidad concreta, no una checklist universal. architectural-tactics permite explicar su efecto esperado y comprobarlo.

Cambiar ubicación u horario de trabajo flexible puede modificar contexto energético, si datos y servicio permiten esa variación. Restricciones de residencia, deadlines, disponibilidad y costo de traslado deben permanecer satisfechas. Una tarea interactiva no se vuelve flexible por desear una electricidad diferente.

La evidencia debe verificar resultado útil, recursos y consecuencias. Una optimización que procesa menos pedidos o reduce corrección no conserva servicio. retry puede conseguir progreso y multiplicar trabajo; backpressure puede limitar acumulación cooperativamente. Sus canonicals mantienen sus objetivos operacionales, más amplios que Sustainability.

Datos y evidencia operacional

Retención, duplicación, replicación, backups y telemetría generan consumo de almacenamiento, procesamiento y transferencia. No todo dato repetido carece de utilidad: recuperación, obligaciones y diagnóstico pueden justificar copias y horizontes diferentes.

Más logs, métricas y traces pueden favorecer operability, investigación de seguridad y diagnóstico de fallos. También amplían resource footprint y costo. El objetivo es evidencia útil con detalle y retención justificados; reducir observación ciegamente puede dificultar recuperación y aumentar impacto posterior.

La arquitectura necesita identificar qué obligación conserva cada conjunto y qué consecuencias tiene retirarlo. Este documento no desarrolla data lifecycle management ni prescribe períodos de retención universales. Una reducción que impide investigar un incidente o recuperar datos puede incumplir el escenario relevante.

Costo, performance y resiliencia

cost-efficiency evalúa costo económico y recursos respecto del servicio requerido. Sustainability examina además impactos y horizonte de vida. Eliminar trabajo innecesario puede favorecer ambos, pero menor precio no garantiza menor efecto ambiental; otra ubicación puede tener contexto energético distinto. Mejorar impacto tampoco garantiza menor costo.

Performance puede mejorar al hacer menos trabajo o mediante más memoria, réplicas y hardware. Por eso «más rápido» no demuestra menor impacto. Una comparación útil conserva workload y comportamiento, mide recursos y revisa los nuevos costos de implementación y mantenimiento.

Redundancia y capacidad de reserva pueden proteger Availability y resiliencia, y aumentar consumo. Reducirlas solamente para bajar footprint puede retirar una obligación crítica. bulkhead puede conservar recursos protegidos con capacidad ociosa deliberada. quality-attribute-trade-offs compara el margen requerido con su impacto, sin recomendar eliminar protección.

Lifecycle, Evolvability y Operability

evolvability trata adaptación sostenida. Dependencias reemplazables y fronteras revisables pueden evitar reescrituras, convivencia prolongada o infraestructura duplicada; no garantizan que una migración reduzca impacto. Una transición puede necesitar mantener dos soluciones y formar equipos antes de retirar la anterior.

operability trata comprensión y control en ejecución. Poder sostener tareas sin carga humana creciente importa al lifecycle, pero facilidad operacional no equivale a Sustainability. Un sistema fácil de gestionar puede consumir muchos recursos o trasladar impactos a otra organización.

deployability puede permitir cambios graduales y retiro efectivo de versiones. Sus mecanismos también requieren entornos, builds y estados temporales. Conviene incluir transición y retiro en el horizonte evaluado, en lugar de medir solamente el estado objetivo y olvidar su costo para alcanzarlo.

Plataformas sin garantías ambientales

Cloud no significa sostenible por definición, ni on-prem significa lo contrario. serverless-architecture puede aprovechar infraestructura compartida para ciertos workloads y conservar overhead, límites, movimiento de datos y poca visibilidad sobre asignación física. Containers cambian packaging; no demuestran impacto reducido.

Hay que evaluar recursos efectivos, infraestructura, contexto energético y vida útil. Una etiqueta tecnológica o un informe agregado del proveedor puede aportar contexto y seguir sin describir la frontera de nuestra capacidad. No recomendamos aquí una región, proveedor o profile universal.

Escenario: duplicar volumen de Orders

Campo	Escenario propio
Source	Stakeholders de plataforma y sostenibilidad responsables de Orders.
Stimulus	El volumen anual de pedidos se duplica mientras la funcionalidad de negocio permanece materialmente igual.
Artifact	Orders y su infraestructura de runtime y datos.
Environment	Producción normal en el entorno de hosting aprobado.
Response	Procesa el workload adicional adaptando recursos y evitando crecimiento innecesario de cómputo, almacenamiento y transferencia.
Response Measure	Escenarios requeridos de performance y disponibilidad satisfechos; consumo por pedido correcto dentro del objetivo acordado; crecimiento proporcional de capacidad permanentemente provisionada requiere justificación mediante demanda y obligaciones del servicio.

Faltan baseline, mezcla y distribución temporal, frontera de recursos, unidad de consumo y objetivo de eficiencia. Duplicar volumen anual no describe el pico. Crecimiento lineal puede ser legítimo para trabajo necesario; el escenario no impone scaling sublineal a todo sistema.

Las pruebas representativas, atribución de consumo y revisión de capacidad ofrecen evidencia sobre recursos. Si emisiones son un target real, faltan energía, intensidad y datos de hardware con metodología declarada. Este escenario, formulado mediante quality-attribute-scenarios, no permite afirmar reducción de carbono ni toda la sostenibilidad del lifecycle.

Límites y revisión

Medir sin contexto vuelve vaga la evaluación; medir una dimensión no elimina las otras. Conservar supuestos, efectos pendientes y criterios de retiro permite revisar decisiones cuando cambian demanda, dependencias o evidencia.

El resultado útil es un compromiso explicable: servicio preservado, impacto justificado para su alcance y obligaciones futuras visibles. No es sinónimo de factura baja, carbono bajo, arquitectura modificable ni de una preferencia tecnológica.