Ethics, sustainability and the business case

Why architects need business cases

Architecture work competes for money and people with everything else an organisation wants to do. A migration, a platform, a resilience programme or a debt repayment rarely produces a feature a customer can see, so it is easy to postpone in favour of work that does. The architects who get such work funded are usually not the ones with the most elegant designs but the ones who can express the case in the terms decision makers use to compare investments: what it costs, what it returns, how soon, how certain, and what happens if we do not do it. That structured argument is a business case.

This is the business-facing side of everything this course has said about trade-offs. A business case is a decision record for an investment: context, options, criteria, consequences and a recommendation, with the consequences expressed as far as possible in money, time and risk. It does not replace architectural judgement, and much of what architecture protects (security, learning, optionality) is hard to price. But putting honest numbers where they can be put, and saying clearly where they cannot, earns the right to be heard on the rest.

Organisations use different formats. The UK government's Green Book, published by HM Treasury, structures public-sector cases around five questions: the strategic case (why change is needed), the economic case (which option gives best value), the commercial case (can it be procured), the financial case (is it affordable) and the management case (can it be delivered). Most companies use something lighter, but the same questions are worth answering for any significant architecture investment.

Options, costs, benefits and risks

Every business case should compare at least three options: doing nothing (the baseline), doing the minimum, and the recommended option, plus any serious alternatives. Doing nothing is rarely free. The legacy system's support contract rises, the incident rate grows with traffic, and changes keep getting slower; that drift is the baseline against which the other options' benefits are measured, and leaving it out makes every investment look worse than it is.

Costs and benefits should be listed by category so that none is forgotten and none is counted twice. Risks belong in the case explicitly: both the risks the investment reduces, which can be valued as expected losses avoided (probability multiplied by impact), and the risks of the investment itself, such as overrun or disruption during migration. Don Reinertsen's cost of delay, from The Principles of Product Development Flow (2009), is a useful extra lens: the value lost each week a piece of work is not delivered. Dividing cost of delay by duration (weighted shortest job first) gives a defensible way to order competing pieces of work.

Finally, structure the investment as a series of stages with decision points rather than one large commitment. The incremental migration in Section 11.6 is a good example: each step delivers something and generates evidence, so funding can be released step by step and the programme stopped if the benefits do not appear. Stage gates of this kind turn a risky bet into a set of smaller options, which is the reversibility thinking of Section 1.6 applied to money.

Net present value and payback

Money now is worth more than money later: it can be invested, and later money is less certain. To compare cash flows that arrive in different years, finance teams convert each into its value today, using a discount rate that reflects the organisation's cost of capital and the risk of the investment. The rate is normally set by the finance department, and architects should use it rather than choose their own.

The net present value of an investment is the sum of all its cash flows, each discounted to today: NPV = Σ C_t ÷ (1 + r)^t, summed over years t = 0 to n, where C_t is the net cash flow in year t (negative for costs) and r is the annual discount rate. The year-0 cash flow is the initial investment and is not discounted. A positive NPV means the investment returns more than the discount rate; when choosing between options of similar risk, the one with the highest NPV creates the most value.

The payback period is simpler: how long until the cumulative cash flow turns positive. Executives like it because it is easy to understand and because it captures risk crudely (the sooner the money is back, the less can go wrong), but it ignores everything after the payback point. The discounted payback period does the same calculation with discounted cash flows. Present both NPV and payback, and show how sensitive they are to the estimates that matter most.

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

Technical debt in money and time

Section 1.7 explained technical debt as principal (the cost of fixing a problem) and interest (the extra cost paid on every change while it remains), and estimated the interest on one tangled module. A business case needs the same quantities in a form finance recognises. The interest becomes an annual cost; the principal becomes the investment; and repaying the debt becomes an investment whose return is the interest no longer paid, plus any risk reduction and enabled opportunities.

Several kinds of evidence can be converted. Developer time: extra days per change, from comparisons with similar changes elsewhere or from developers' estimates, multiplied by change volume and a loaded day rate. Delay: longer lead times multiplied by the cost of delay of the affected work. Incidents: the number and duration of incidents traced to the debt, multiplied by their cost. Risk: the probability and impact of the failures the debt makes more likely, such as a security breach through an unsupported component. Opportunity: business initiatives the debt blocks outright.

Be careful with the debt figures produced by static analysis tools, which typically report an estimated remediation effort (how long it would take to fix every flagged issue). That is an estimate of principal, not of interest, and it says nothing about whether the code is ever changed. Debt in code that is rarely touched costs little; the hotspots of Section 1.7 are where interest is actually paid, and where repayment has the best return. Presenting debt as a portfolio of small investments, each with an estimated return and payback, is usually far more persuasive than a single headline figure for total debt.

Ethics: what the professional codes ask

Architectural decisions shape what systems do to the people who use them and the people they affect without consent, so architects carry ethical responsibilities as well as technical ones. Two professional codes are particularly relevant. The ACM Code of Ethics and Professional Conduct, updated by the Association for Computing Machinery in 2018, opens with general principles: contribute to society and human well-being, acknowledging that all people are stakeholders in computing; avoid harm; be honest and trustworthy; be fair and take action not to discriminate; respect the work required to produce new ideas; respect privacy; and honour confidentiality. Its professional responsibilities include giving comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks, and designing systems that are robustly and usably secure; its leadership principles ask for special care with systems that become integrated into the infrastructure of society.

The BCS Code of Conduct, from BCS, The Chartered Institute for IT in the UK, is organised around four duties: to the public interest (including public health, privacy, security, wellbeing, the environment and equal access), to professional competence and integrity, to the relevant authority (the employer or client) and to the profession. The joint ACM and IEEE Computer Society Software Engineering Code of Ethics (1999) adds eight principles beginning with the public interest, which takes precedence over the interests of client and employer.

For architects, these codes translate into concrete obligations. Analyse the foreseeable effects of a design, not only its functional correctness. Tell decision makers honestly about risks, including risks they would prefer not to hear. Refuse to design systems intended to deceive or to harm, and escalate when asked to. Record dissent on ethical grounds in the decision record. And know where to turn if internal escalation fails: in the UK, for example, the Public Interest Disclosure Act 1998 protects workers who report certain kinds of wrongdoing.

Dark patterns and other foreseeable harms

The table lists the harms most often within an architect's reach. Several are covered in depth elsewhere: privacy and security in Chapter 8, accessibility as a quality in Section 2.7, and bias in machine-learning systems in Chapter 12. Accessibility is increasingly a legal constraint as well as an ethical one; in the EU, the European Accessibility Act has applied to many consumer services, including e-commerce, since 28 June 2025.

Manipulative design deserves particular mention because it is often requested deliberately. Harry Brignull coined the term dark pattern in 2010 for interfaces designed to trick people into choices they would not otherwise make; he now prefers the term deceptive patterns. Familiar examples include drip pricing (fees revealed only at the end), confirmshaming (making the no option feel shameful), fake urgency and scarcity, pre-ticked consent boxes and subscriptions that are easy to start and hard to cancel. Regulators have acted: the EU Digital Services Act (2022) prohibits online platforms from designing interfaces that deceive or manipulate their users, and the US Federal Trade Commission published a staff report on dark patterns in 2022. Many of these patterns need architectural support (a pricing API that hides fees until checkout, a cancellation flow routed through a retention service), so architects are in a position to notice and challenge them.

The simplest way to make harms visible is to look for them on purpose, at the same moments you look for technical risks. Add a harms question to threat modelling and design reviews: who could be hurt by this system working as designed, by it failing, or by it being misused? Practices such as consequence scanning, developed by the UK think tank Doteveryone, give teams a short, structured format for this conversation during planning.

Sustainability: green software

Software does not burn fuel, but the electricity and hardware it uses do, and architectural decisions fix much of that footprint for years. The Green Software Foundation, launched in 2021 under the Linux Foundation, publishes six core areas of green software practice: carbon efficiency (emit the least carbon possible), energy efficiency (use the least energy possible), carbon awareness (do more when electricity is cleaner and less when it is dirtier), hardware efficiency (use the least embodied carbon possible), measurement, and climate commitments (understand exactly how a reduction is achieved).

Carbon-aware computing exploits the fact that the carbon intensity of electricity varies by hour and by region with the mix of wind, solar, gas and other sources. Demand shifting moves flexible work, such as batch jobs, model training, backups and report generation, to times or regions where electricity is cleaner; demand shaping reduces what the software does when it is dirtier, for example by serving lower-resolution media or deferring non-urgent recalculation. Grid data services, such as the Carbon Intensity API for Great Britain, and open-source tools such as the foundation's Carbon Aware SDK provide the signals. As a simple illustration, a nightly batch job that uses 400 kWh emits about 120 kg CO₂e at an illustrative 300 g per kWh in the early evening, but about 48 kg if moved to a windy night at 120 g per kWh.

Embodied carbon, the emissions from manufacturing and disposing of hardware, is the reason hardware efficiency matters: higher utilisation of fewer machines, scaling to zero when idle and extending device lifetimes (including customers' phones, by not demanding new hardware for each release) all reduce it. The foundation's Software Carbon Intensity specification, published as ISO/IEC 21031:2024 and introduced in Section 2.7, combines operational and embodied emissions per functional unit, such as per order delivered, and excludes offsets so that only real reductions improve the score.

Architectural levers include right-sizing and autoscaling, removing idle environments, data retention limits (stored data has an energy and hardware cost), efficient data formats and caching, choosing regions with cleaner grids where latency and data residency allow, and questioning whether every feature needs a large model call. Beware of the rebound effect, the modern form of William Stanley Jevons's 1865 observation about coal: efficiency that makes something cheaper can increase total use, so measure total emissions as well as intensity.