Be Wise Apps
Leer en español · Lire en français · Auf Deutsch lesen
Section 1.2 of 1.8 · Beginner · 17 min read
Architecture, design and code: significance, scope and levels
Video lesson
5 min · narrated, with captionsListen only (audio)
Read the transcript
When is a decision architecture, and when is it just design? This lesson gives you practical tests, and shows why the answer isn't always where you'd expect.
Think about planning a house. Some choices fix everything else: how many floors, where the stairs go, where the load-bearing walls stand. Others can be changed on a weekend: paint, shelves, light fittings. Both are design. But only the first kind is architecture, because changing it later means knocking the house about. In software, how a system is split into parts is architecture. How one function is written inside one part is design.
Grady Booch put it neatly: all architecture is design, but not all design is architecture. There's no clean wall between them, just one continuum of decisions, ordered by significance. So the useful question isn't whether something is architecture in the abstract. It's how significant this decision is here, and how much care it deserves.
So what makes a decision significant? First, it's hard or expensive to reverse. Ask: if this turns out wrong in a year, what will it cost to change? Second, wide scope. It touches many components, teams or systems, like the format of customer identifiers used across every service. Third, it decides whether you meet a key performance, availability, security or cost goal. Fourth, it sets a constraint for others, limiting what other teams may choose. And fifth, it involves significant trade-offs, or real novelty and risk, such as a database nobody in the organisation has ever run in production.
This diagram places a decision on the continuum. The left end is more architectural; the right end is more design and code. The first dimension is the cost of reversing: months of work across many teams at one end, minutes for one person at the other. The second is the scope of impact: the whole system or organisation, against one function or class. The third is the effect on key qualities: does the decision decide one, or is its effect local or none? The dots place one example decision, the choice of a message format, on each row. A decision can score differently on each dimension, which is why you look at all three.
Here's how a technical lead at a ride-hailing start-up sorts five decisions. Storing trip locations in a time-series database is costly to reverse and touches trips, billing and analytics. It's architectural, so it gets written up and reviewed. Choosing an HTTP client library inside the pricing service is cheap to reverse and affects one service. That's design, and the pricing team decides. Calculating fares on the server, never on the phone, spans the apps and the back end and protects the integrity of pricing. It's architectural: a governing principle. Representing money as whole pence or cents everywhere looks like a coding detail. But once data and partner systems depend on it, it's very expensive to change. Architectural, despite being low-level. And dark mode colours in the driver app? Trivial to reverse. Design. Notice that two of the three architectural decisions aren't about boxes and arrows at all.
The word architecture is also used at different levels of scope, and job titles follow them. Enterprise architecture covers a whole organisation: its capabilities, information, applications and technology. The best-known framework here is TOGAF, from The Open Group. Solution architecture addresses one business problem that spans several systems, such as a hospital adding online booking that must connect to its existing systems. Software or application architecture, the main subject of this course, concerns the structures and qualities of one system. Below that come detailed design, inside one component, and then the code itself. Each level constrains the one below. On the right, three specialisms cut across every level: data architecture, security architecture and infrastructure architecture.
Why does this matter? Because level of abstraction alone is a poor test. Identifier formats, money and time conventions, and API contracts are often architectural, even though they look low-level. Decisions should be made at the lowest level that has enough context and accountability. Architects who decide class structures become a bottleneck; teams that make system-wide choices alone create costly inconsistency. And good teams shrink the set of architectural decisions. Hiding a vendor behind an interface, or keeping a database private to one service, makes a decision cheap to reverse, and moves it towards design.
That's the line between architecture and design. The full section has more example decisions and who usually makes each kind. Next, in Section one point three, we look at why architecture matters so much. See you there.
What you need to know
- Architecture and design form a continuum: all architecture is design, but only the significant design decisions are architecture.
- A decision is architecturally significant when it is hard or expensive to reverse, has wide scope, determines a key quality attribute, constrains others or involves important trade-offs.
- Level of abstraction alone is a poor test: low-level conventions such as identifier or money formats can be architectural, and some high-level boxes are trivial.
- Strategic decisions set long-term direction for many people; tactical decisions solve bounded, immediate problems, but repeated tactical choices can become architectural.
- Enterprise architecture covers a whole organisation (TOGAF is the best-known framework), solution architecture one business problem across systems, and software architecture one system; data, security and infrastructure architecture cut across all levels.
- Decisions should be made at the lowest level with enough context and accountability, with wider consultation for decisions that affect many teams.
A continuum, not a wall
If architecture is the set of significant decisions and structures (Section 1.1), then design is everything else: the many smaller decisions about how each part works inside. The difficulty is that there is no clean line between them. Choosing to split a food-delivery platform into an ordering system and a courier system is clearly architectural. Naming a variable is clearly not. Between those extremes lies a long middle ground of decisions (an API's error format, a caching rule, how a module is divided into packages) whose status depends on context.
Grady Booch put it neatly: all architecture is design, but not all design is architecture. Architecture and detailed design are points on one continuum of design decisions, ordered by how significant they are. That is why the most useful question is not "is this architecture or design?" in the abstract, but "how significant is this decision here, and how much care does it deserve?".
A second, popular way to draw the line is by level of abstraction: architecture is the high-level view ("boxes and arrows"), design is the low-level view ("classes and methods"). That is a reasonable first approximation but it fails in both directions. A low-level detail can be architectural: the format of an identifier shared by twenty services, or the choice of a time zone convention for stored dates, may cost months to change. And a high-level box can be trivial: whether an internal admin tool is a separate service may not matter at all.
What makes a decision architecturally significant
A decision is architecturally significant when it has one or more of the following characteristics. These are not formal rules from a single standard; they summarise what the SEI, Martin Fowler, Mark Richards and Neal Ford and others say in different words.
Signs that a decision is architecturally significant
| Characteristic | Question to ask | Example |
|---|---|---|
| Hard or expensive to reverse | If this turns out wrong in a year, what will it cost to change? | Choosing an event-sourced data model rather than storing current state |
| Wide scope | How many components, teams or systems does it touch? | Defining the format of customer identifiers used across all services |
| Determines a key quality | Does it decide whether we meet a performance, availability, security or cost goal? | Putting a cache in front of the product catalogue to meet a 200 ms response target |
| Sets a constraint for others | Does it limit what other teams may choose? | Mandating that all services publish events to one shared broker |
| Involves significant trade-offs | Are we giving up something important to get something else? | Accepting eventual consistency between orders and stock to keep checkout available |
| High novelty or risk | Has anyone here done this before? What if the technology fails us? | Adopting a database the organisation has never operated in production |
Mark Richards and Neal Ford, in Fundamentals of Software Architecture, describe the architecture/design spectrum in similar terms: a decision sits further towards architecture the more strategic it is (long-term, many people involved), the more effort it would take to change, and the more significant its trade-offs. Martin Fowler offers a compact version: architecture is the stuff that is hard to change, which also means that one of an architect's goals is to make more things easy to change. Making a decision cheap to reverse, for example by putting it behind an interface, effectively moves it from architecture towards design. This idea, reversibility, is explored further in Section 1.6.
Placing a decision on the continuum
Strategic and tactical decisions
A related distinction is between strategic and tactical decisions. Strategic decisions set direction for a long time and for many people: adopting a cloud provider, choosing between a monolith and distributed services, deciding that customer data will be mastered in one system. They usually need input from several stakeholders and are worth writing down with their reasons. Tactical decisions solve an immediate problem within a bounded area: which library to use for parsing dates in one service, how to structure a particular database query, how to name the endpoints of an internal API.
Strategic does not mean slow. Many strategic decisions can and should be made quickly once the options are clear, and some are reversible if they are structured well. Tactical does not mean unimportant: a poor tactical decision repeated in fifty places (say, every service writing its own retry logic with no back-off) can add up to an architectural problem. Architects watch for tactical decisions that are about to become strategic through repetition, and turn them into a shared principle or platform capability.
Architectural or design? Example decisions with reasoning
| Decision (for an online shop) | Verdict | Reasoning |
|---|---|---|
| Split the system into separately deployable services for catalogue, checkout and delivery | Architectural | Affects every team, deployment, data ownership and failure behaviour; very costly to reverse. |
| Use PostgreSQL rather than a document database as the main store for orders | Architectural | Shapes the data model, transactions and operations skills; migration later is expensive and risky. |
| Use a specific JSON library inside the checkout service | Design | Local to one service and replaceable in a day if hidden behind the service's own code. |
| Require every service to emit structured logs with a shared correlation ID | Architectural | A cross-cutting concern: it only works if everyone follows it, and it determines how quickly incidents can be diagnosed. |
| Name the method that calculates delivery fees | Design (code) | Purely local; renaming is automated by tools. |
| Choose the format of order numbers shown to customers and shared with the warehouse partner | Architectural | Low-level, but it crosses system and company boundaries and is printed on parcels; changing it needs coordination with an external party. |
| Use the Strategy pattern to support several delivery-fee rules | Design | Shapes one component's internals; other components are unaffected. |
| Cache product prices for 60 seconds | Depends | Design if prices change rarely and staleness is harmless; architectural if a stale price creates a legal or financial problem, because it then decides a key quality (correctness). |
Levels of architecture
The word architecture is also used at several levels of scope, and job titles follow these levels. Confusing them causes many misunderstandings: an enterprise architect and a software architect may both be "the architect", yet their work barely overlaps.
Enterprise architecture looks at a whole organisation: its business capabilities (what it must be able to do, such as "assess claims" or "onboard customers"), the information it holds, its portfolio of applications and its technology platforms, and how all of these should change to support strategy. Typical outputs are capability maps, target-state roadmaps, technology standards and decisions about which systems to retire. The most widely used framework here is TOGAF, published by The Open Group, whose current version is the TOGAF Standard, 10th Edition (2022). It provides a method (the Architecture Development Method) and a body of content for planning and governing enterprise change. Organisations use it to varying degrees; many adopt parts of it and some find it heavyweight, and this course describes it only so you can recognise it.
Solution architecture addresses one business problem or programme, typically spanning several applications, teams and vendors: for example, a hospital introducing online appointment booking that must connect a new web front end, the existing patient administration system, an SMS provider and the identity service. The solution architect makes the pieces fit together, often under commercial and contractual constraints.
Software or application architecture, the main subject of this course, concerns the structures and qualities of one system: its decomposition, its runtime interactions, its deployment, its data and its evolution.
Three specialisms cut across all these levels. Data architecture covers how data is modelled, owned, stored, moved, governed and used for analytics (Chapter 7). Security architecture covers identity, access, protection of data, threat models and how security controls are placed (Chapter 8). Infrastructure architecture (often now cloud or platform architecture) covers compute, networks, storage, environments and deployment platforms (Chapter 10).
Levels and cross-cutting specialisms
Who makes which decisions
In a healthy organisation, decisions are made at the lowest level that has enough context and is accountable for the consequences. Architecture is not the sole property of people with "architect" in their title. A reasonable default division looks like this, although every organisation tunes it.
| Kind of decision | Usually made by | Usually consulted |
|---|---|---|
| Technology standards and platforms for the organisation (e.g. approved cloud provider, identity platform) | Enterprise architects, CTO, architecture board | Solution and software architects, security, finance |
| How several systems and vendors combine to solve a business problem | Solution architect | Product owners, enterprise architects, vendor architects |
| The major structure of one system: decomposition, communication style, data ownership | Software architect or the team's technical lead, with the team | Operations, security, other teams affected |
| Design inside a component: classes, patterns, algorithms | The development team | Architect only if a principle or quality is at stake |
| Code-level choices: naming, local refactoring | Individual developers, via code review | Nobody else, normally |
Two warning signs show that the division is wrong. If architects decide internal class structures, they become a bottleneck and the team stops thinking. If teams independently make decisions with system-wide effects (each choosing its own message broker, say), the organisation pays for the inconsistency later. Writing down which decisions need wider consultation, and making it easy to record them, is covered under decisions and trade-offs and, in depth, in Chapter 4's treatment of Architecture Decision Records.
Worked example
Worked example: classifying decisions for a ride-hailing app
A ride-hailing start-up lists five pending decisions. The technical lead uses the three signs (cost to reverse, scope, effect on key qualities) to decide which need a written record and wider review.
| 1. Store trip locations in a time-series database | Reverse: high (data migration). Scope: trips, billing, analytics. Quality: performance of live tracking. Verdict: architectural; write it up and review with data and operations staff. |
|---|---|
| 2. Use a particular HTTP client library in the pricing service | Reverse: low. Scope: one service. Quality: none significant. Verdict: design; the pricing team decides. |
| 3. Calculate fares on the server, never on the phone | Reverse: medium. Scope: apps and back end. Quality: security and integrity of pricing. Verdict: architectural; it is a governing principle. |
| 4. Represent money as integer minor units (pence, cents) everywhere | Reverse: very high once data and partner APIs use it. Scope: every service. Quality: correctness. Verdict: architectural despite being low-level. |
| 5. Use dark mode colours in the driver app | Reverse: trivial. Scope: one screen set. Verdict: design. |
Two of the three architectural decisions (3 and 4) are not about boxes and arrows at all; they are principles and conventions. Level of abstraction alone would have misclassified them.
Decision 4 is the kind most often missed: it looks like a coding detail but becomes very expensive to change once other systems depend on it.
Questions people ask
Is choosing a programming language an architectural decision?
Often, yes. It affects hiring, available libraries, performance characteristics, and how easily code can be shared between components. In a system of many independent services, the language of one small service may be a local choice; the default language for the whole organisation is architectural.
Is a database schema architecture or design?
It depends on who uses it. A table used only inside one service, behind its own API, is design. A schema read directly by several services, reports and partner exports is architectural, because every change must be coordinated across all of them. Many teams make schemas private to one service precisely to move them back into design.
Does agile development mean there is no architecture?
No. Every system has an architecture; agile approaches change when and how it is decided, favouring small, reversible steps and deferring irreversible decisions until enough is known. Section 1.8 covers this.
Who decides whether a decision is significant?
Usually the team and its architect or technical lead together, using agreed criteria such as the signs in this section. Writing those criteria down avoids two failure modes: debating every choice, and discovering after the fact that a team made a system-wide decision alone.
How professionals apply the distinction
Experienced teams turn the continuum into a lightweight routine. They agree a short list of the kinds of decision that need a written record and wider consultation, for example anything that changes a public API, introduces a new data store or technology, crosses team boundaries, or affects a stated quality goal. Everything else is decided by the people doing the work, through normal code review. They revisit the list when something slips through or when reviews feel like bureaucracy.
They also look actively for ways to shrink the set of architectural decisions, because every decision that becomes cheap to reverse is one less that needs to be right first time. Hiding a vendor behind an interface, making a database private to one service, using feature flags for risky behaviour and deploying in small increments all move decisions from the architectural end of the continuum towards the design end.
Check your understanding
Why can a choice about the format of an identifier be architectural?
Because once many services, databases and external partners rely on it, changing it requires coordinated work across all of them, so its cost of change and scope are high.
What is the difference between enterprise and solution architecture?
Enterprise architecture covers the whole organisation's capabilities, information, applications and technology; solution architecture addresses one business problem that usually spans several systems and teams.
How can an architect move a decision from architecture towards design?
By making it cheaper to reverse, for example hiding a technology behind an interface so it can be replaced locally.
Sources and further reading
Have a question about this section? ArchitectBot, the course’s AI study assistant, answers from the course first.
Ask: “How do I decide which of my team's decisions need an architecture review and which the developers can just make?”