Sustainable information systems and carbon-aware design

Sustainability becomes an architecture concern when design choices materially affect resource consumption, infrastructure intensity, retention behaviour, processing volume, or operating patterns. At that point it is no longer just a reporting topic. It becomes a design topic within Phase D.

The goal is not to force a carbon calculation into every conversation. The goal is to identify where architecture choices have meaningful environmental consequence and then treat that consequence honestly in the trade-off. Most architecture choices have no meaningful sustainability consequence. But some do, and those are the ones this module is about.

TOGAF addresses sustainability through G242, "Sustainable Information Systems," and through the broader G248 sustainability architecture guidance. Both guides position sustainability as a design concern that should be integrated into existing architecture trade-offs rather than treated as a separate workstream.

The G248 guide provides a structured framework for integrating sustainability into enterprise architecture. The framework identifies the key decision points where sustainability reasoning should be applied and the levers through which architecture choices affect environmental impact.

Principle 1: Measure before you manage

The enterprise should understand which parts of its technology estate consume the most resources before attempting to optimise. Without measurement, sustainability becomes guesswork. The architecture should identify the top resource consumers and ensure that monitoring or estimation is in place for at least the largest workloads, data stores, and infrastructure components.

Principle 2: Proportionality

Resource consumption should be proportionate to the business value it delivers. High-frequency telemetry for safety-critical systems is justified even if it consumes significant compute. A dashboard that refreshes every five seconds when users check it twice a day is not. The architecture question is not "can we reduce consumption?" It is "does the resource intensity match the business need?"

Principle 3: Design for lifecycle, not just deployment

Sustainability applies to the full lifecycle of a technology choice, not just the initial deployment. A platform that is efficient to run but requires replacement every three years may have a larger lifecycle footprint than a platform that runs less efficiently but lasts ten years. The architecture should consider total lifecycle resource consumption, not just operational efficiency.

Principle 4: Record where sustainability changed the decision

The architecture record should show that sustainability was considered and whether it materially affected the decision. This prevents sustainability from becoming either a rubber stamp or a veto. The Architecture Board should be able to ask "which design choice was affected by sustainability reasoning?" and get a concrete answer.

Carbon-aware design is a set of specific, actionable patterns that reduce the carbon footprint of technology workloads without sacrificing business value. These patterns apply to Phase D technology decisions.

Pattern 1: Demand shifting

Move flexible workloads to times when the electricity grid is cleanest. Batch processing, data transformation, model training, and report generation can often run during periods of high renewable energy supply without affecting business outcomes. A nightly batch job that processes the same data set could run at 2 AM when wind generation is highest rather than at 6 PM during peak demand.

Pattern 2: Demand shaping

Adjust the intensity of workloads based on carbon signal. A dashboard that refreshes every five seconds during peak carbon intensity could switch to thirty-second updates, then return to high-frequency when the grid is cleaner. The user experience changes minimally. The carbon impact changes significantly at scale.

Pattern 3: Right-sized retention

Set data retention policies by design rather than by default. Many enterprises retain everything indefinitely because nobody defined a retention policy. The result is growing storage, growing processing demands for indexing and backup, and no corresponding business value. Architecture should define retention tiers: hot data for active use, warm data for occasional access, cold data for regulatory compliance, and explicit deletion for data that has no ongoing value.

Pattern 4: Workload matching

Ensure that compute intensity matches business decision frequency. A batch job that processes the same data set nightly when the business only needs weekly updates is consuming six times more resource than necessary. The architecture question is whether the workload pattern matches the business need, not whether the infrastructure can handle the load.

Pattern 5: Infrastructure efficiency

Choose platforms and hosting models that maximise utilisation. The difference between running workloads on hardware that is fully utilised and hardware that is 15 per cent utilised is significant at scale. Shared platforms, serverless execution models, and container-based scheduling all improve utilisation ratios.

The weak pattern is to add a sustainability paragraph to the architecture document that never alters a decision. That may look complete, but it tells the learner nothing about how sustainability works as architecture reasoning.

The stronger pattern is to identify the specific decisions where sustainability is materially relevant, test whether the current design is proportionate, and record the outcome. Sometimes the existing design is already appropriate. Sometimes a simple change in retention policy, polling frequency, or batch scheduling produces a meaningful improvement with no operational penalty.

The test is simple: can the architecture team point to a specific design choice that sustainability reasoning changed or confirmed? If the answer is always "no," the sustainability work is decoration, not architecture.

Sustainability is one input to the trade-off, not a trump card. A telemetry pipeline that is carbon-efficient but cannot detect safety alarms in time is not a good architecture. A data-retention policy that saves storage but deletes regulatory evidence is not a good architecture.

The G248 framework makes this explicit: sustainability reasoning must be balanced against safety, security, resilience, and regulatory compliance. When sustainability and safety conflict, safety wins. The architecture record should show the trade-off explicitly so that the Architecture Board can review it.

The practical discipline is straightforward. For each sustainability recommendation, ask: does this change affect safety, resilience, or regulatory compliance? If yes, document the trade-off and ensure the appropriate stakeholders review it. If no, proceed with the sustainability improvement.

In London Grid Distribution, sustainability shows up through infrastructure intensity, large-scale information handling, telemetry and monitoring decisions, and the wider public-value context of grid transformation.

The telemetry pipeline. SCADA telemetry ingests sensor data at high frequency for safety-critical monitoring. That frequency is justified for alarm detection. But routine analytical reporting may only need fifteen-minute averages. A tiered ingestion model (high-frequency for alarms, lower frequency for routine analysis) applies the workload-matching pattern without compromising safety.

Data retention. The LTDS publication pipeline requires certain data to be retained for regulatory audit. But much of the analytical working data has no regulatory retention requirement. Right-sized retention would separate regulatory data (retained as required) from analytical working data (retained only as long as it has business value).

Batch processing. Network planning calculations and load-flow analyses run periodically. If these workloads are flexible in timing, demand shifting could move them to periods of high renewable generation on the GB electricity grid.

The public-value context. A distribution network operator that manages grid decarbonisation while ignoring the carbon footprint of its own information systems faces a credibility problem that architecture can help address. This is not about virtue signalling. It is about consistency between the enterprise's mission and its own operational choices.

• Retention, workload, and platform choices are all visible sustainability levers in London.
• The point is disciplined trade-off, not vague virtue signalling. Safety and regulatory compliance always take precedence.
• Carbon-aware design patterns (demand shifting, demand shaping, right-sized retention, workload matching) apply directly to London's technology architecture.
• The public-value context of grid transformation adds weight to sustainability reasoning without overriding safety or operability.