Evaluation, Decision-Making and Governance

Welcome to Chapter 11, Evaluation, Decision-Making and Governance. The earlier chapters taught you how to describe what a system must achieve, how to structure it, and how to make it fast, reliable, secure and economical. This chapter is about the work that surrounds those decisions over a system's whole life: checking them before money is committed, keeping them true as hundreds of changes land every month, and justifying them in business and ethical terms.

The chapter is written for experienced developers, technical leads and architects who make or guide significant decisions. It is where the course comes together, so it builds on every earlier chapter. It links back most often to Chapters 1 to 4: trade-offs, technical debt, quality attribute scenarios, Conway's law and decision records. Chapters 5 to 10 help, but are not essential. The level is advanced, but every section begins with a short explanation for newcomers. And it leads to Chapter 12, which applies the whole discipline to systems built around artificial intelligence models.

The running example is the food delivery platform used since Chapter 2. You will see its architecture evaluated, risk-stormed, protected by fitness functions, governed, reorganised around teams, and partly modernised. Section eleven point one covers formal evaluation with the Architecture Tradeoff Analysis Method, or ATAM: its nine steps across two meetings, who takes part, and its outputs, such as risks, sensitivity points, trade-off points and risk themes. Section eleven point two explains why monthly review boards so often fail, and what works instead: risk-storming, the pre-mortem, architecture katas and written design reviews. Section eleven point three turns one-off evaluation into continuous protection. A fitness function is an objective check of an architectural characteristic, ideally automated, such as a dependency rule or a load test with percentile thresholds. Section eleven point four asks how an organisation of many autonomous teams keeps its architecture coherent, through principles, standards, guardrails and gates, the advice process and technology radars.

This diagram from Section eleven point four contrasts two ways of governing. In gate-based governance, a team designs, then waits in a review board's queue for weeks. If the design is rejected, it is redesigned and waits again. Only after approval can the team build and release. In guardrail-based governance, the team decides, and its change passes through a pipeline with guardrails: policy as code and fitness functions that check objective rules automatically. It can reach release in minutes. Underneath sit the supports: the advice process for significant decisions, principles and a technology radar for shared direction, and a paved road of templates and platform. Guardrails leave people free for the decisions that need judgement. And in the advice process, anyone may make an architectural decision, after seeking advice from those affected and from experts, and recording it.

Section eleven point five takes Conway's law seriously as a design tool. It presents Team Topologies: four team types, three ways for teams to interact, and the limits of a team's cognitive load. Section eleven point six deals with the systems that already exist: why big-bang rewrites so often fail, and the incremental techniques that work. Section eleven point seven covers the human side of the role: leading without formal authority, building trust, facilitating decisions, handling conflict, and communicating with executives. And Section eleven point eight closes the chapter with two arguments an architect must make well: the business case, with net present value and payback, and the ethical case, including foreseeable harms and sustainability.

This diagram from Section eleven point six shows one of those techniques, the strangler fig: replacing a legacy system piece by piece while it keeps running. First, intercept. Clients call a routing facade, which still sends all traffic to the legacy monolith. Nothing changes in behaviour yet. Next, the first slice. The facade sends one feature, order tracking, to a small new service, with temporary data synchronisation between old and new. Slice by slice, most of the traffic moves across, until only billing is left in the old system. Finally, all traffic goes to the new services, and the legacy system is switched off. The migration is finished only when the old system and the temporary code have both been removed.

Architecture is not finished when the diagram is drawn. Its decisions have to be tested, protected while the system changes, made by the right people, carried by teams whose structure fits them, and justified to sponsors and society. The most effective architects make this work light and continuous, rather than heavy and occasional. Short risk reviews, instead of annual audits. Automated guardrails, instead of approval queues. Advice, instead of permission. And incremental migration, instead of rewrites. The discipline that ties it together is the one this course began with: name the quality you need, make it measurable, decide deliberately, write down why, and keep checking.

By the end of the chapter, you will be able to explain when to evaluate an architecture, and run either the ATAM or a lightweight review such as risk-storming, with a risk register and owners. You will be able to design fitness functions that turn quality attribute scenarios into automated checks. You will be able to plan an incremental modernisation, using the strangler fig, branch by abstraction and parallel runs. And you will be able to calculate net present value and payback for a business case, and review an architecture for ethical and sustainability concerns.

You can read the chapter in order, or go straight to the section you need. If an idea from an earlier chapter is unfamiliar, follow the link back to it. Allow about three and a half hours to read the whole chapter. At the end of each section there are self-check questions. Answer them in your head before you look at the answers. When you are ready, there is an optional chapter test, which takes about forty five minutes. It has twenty multiple choice questions and two written answers. The pass mark is eighty per cent.

That is the shape of the chapter. Start with Section eleven point one, on architecture evaluation and the ATAM. See you there.