Be Wise Apps
Leer en español · Lire en français · Auf Deutsch lesen
Section 1.4 of 1.8 · Beginner · 18 min read
What an architect does: responsibilities, skills and kinds of architect
Video lesson
5 min · narrated, with captionsListen only (audio)
Read the transcript
What does a software architect actually do? The job title means different things in different companies, but behind the variety there's a common core. Let's find it.
On a building project, the architect doesn't lay every brick. But they decide the things that would be ruinous to get wrong. They explain those decisions to the builders and the clients. And they check on site that the plans are followed, adjusting when the ground turns out softer than expected. A software architect does the same for a software system.
So here's a working definition. The architect is whoever takes responsibility for the significant decisions being made well, understood by others, and kept true as the system changes. Notice the word whoever. Architecture is a role before it's a job title. In many teams nobody is called architect, and technical leads or senior engineers do the work. What matters is that someone clearly owns it. When nobody does, architecture still happens, but by accident.
Mark Richards and Neal Ford describe eight expectations of an architect. Make architecture decisions, and keep analysing whether the architecture still fits as things change. Keep current with trends, and have diverse exposure, so you can compare many technologies. Ensure that agreed decisions are actually followed, ideally with automated checks. Know the business domain well enough to talk to stakeholders in their terms. And have interpersonal skills, and understand politics. Few of the eight are purely technical. Nearly every decision will be challenged, so negotiation and persuasion are core skills, not extras.
The International Software Architecture Qualification Board, or iSAQB, describes the architect's tasks as a cycle. It starts with clarifying the requirements and constraints. Then designing the structures, and cross-cutting concepts such as persistence and communication. Next, communicating and documenting the architecture, and accompanying its implementation alongside the people who build it. Then evaluating it, especially for risks to meeting the requirements, which leads back to clarifying again. At the centre are decisions. Every task feeds them and revisits them, and the cycle repeats throughout the system's life.
What skills does this take? Richards and Ford describe a knowledge pyramid with three layers: things you know, things you know you don't know, and things you don't know you don't know. A typical developer is rewarded for depth. The top layer, real expertise, is tall, and the middle layer is a thin band. For an architect, the middle layer is much wider: things you know exist but haven't mastered. Knowing that five ways exist to solve a problem, and what each is good and bad at, is what lets you compare options. An architect who knows only one database will recommend it every time.
Here's the cycle for one need: a hospital's booking system must send reminders by text message. The architect first clarifies: about twenty thousand a day, what happens if the text provider is down, and no clinical details, for privacy. The design: the booking service publishes events, and a separate notification component sends messages from a queue. So a text outage never blocks bookings. Then the architect writes a one-page decision record with the options and reasons, and presents it to the team and the information governance lead. While it's built, the architect pairs with a developer, reviews the retry logic, and adds an automated check that blocks clinical fields from the message template. Three months later, the architect checks: during a provider outage, reminders queue for thirty minutes, and clinicians confirm that's acceptable. Most of the effort went into clarifying, communicating and checking, not drawing.
Should architects write code? Most experienced voices say stay hands-on, but off the critical path. Build a proof of concept to test a risky option before the team commits to it. Write fitness functions: automated checks of architectural rules, such as the domain code never depending on the web framework. Fix bugs, do small pieces of debt work, and review code regularly, which shows how decisions are really being implemented. And watch for the classic traps: the ivory tower whose designs teams quietly work around, the bottleneck every decision must pass through, and the frozen expert whose judgement is stuck years in the past.
That's the architect's role. The full section covers the different kinds of architect, a week in the life, and a sample fitness function. Next, in Section one point five, we meet the people an architecture serves. See you there.
What you need to know
- Architects take responsibility for significant decisions being made well, understood and kept true as a system changes; architecture is a role before it is a job title.
- Richards and Ford describe eight expectations: make decisions, continually analyse, keep current, ensure compliance, have diverse exposure, know the business domain, have interpersonal skills and navigate politics.
- The iSAQB curriculum lists architects' tasks as clarifying requirements, designing structures and cross-cutting concepts, communicating, accompanying implementation and evaluating, done iteratively.
- Kinds of architect include enterprise, solution, software or application, data, security and cloud or infrastructure; staff and principal engineers often carry the same responsibilities.
- Architects value technical breadth (knowing many options and their trade-offs) over deep expertise in a few, as shown by the knowledge pyramid.
- Architects should usually stay hands-on without owning critical-path code: proofs of concept, fitness functions, bug fixes and code reviews.
What architects are for
If architecture is the set of significant decisions and structures of a system (Section 1.1), the architect is whoever takes responsibility for those decisions being made well, understood by others and kept true as the system changes. That sounds simple, but the role is one of the least consistently defined in software. In one company an architect is a senior engineer who still writes code daily; in another, a member of a central team who reviews designs and maintains standards; in a third, a person who mostly talks to business leaders and vendors.
Behind the variety there is a common core. Architects make or guide decisions that are costly to reverse, look after the qualities of the whole system rather than one part, and connect technical choices to business goals. The rest of this section describes what that involves, what skills it takes and how the role is organised.
Eight expectations of an architect
Mark Richards and Neal Ford, in Fundamentals of Software Architecture (O'Reilly, 1st edition 2020, 2nd edition 2025), describe eight core expectations of an architect, whatever the job title or company. They are paraphrased below, with an example of each from a food-delivery company.
The eight expectations (after Richards and Ford)
| Expectation | What it means | Example |
|---|---|---|
| Make architecture decisions | Define decisions and principles that guide technology choices, usually by guiding the team rather than dictating specific products. | Deciding that restaurant integrations go through one adapter layer, rather than choosing each restaurant's library. |
| Continually analyse the architecture | Reassess whether the architecture still fits as technology and business change, and look for decay. | Noticing that the courier-matching service now takes 40% of all deploy failures and asking why. |
| Keep current with trends | Follow developments in technology and practice, because architectural decisions are long-lived. | Understanding new managed database offerings before the next capacity review. |
| Ensure compliance with decisions | Check that agreed decisions and principles are actually followed, ideally with automated checks. | Adding a build check that fails when the app calls the payment provider directly. |
| Have diverse exposure and experience | Know a wide range of technologies, frameworks and platforms well enough to compare them. | Comparing message brokers on ordering, durability and operating cost. |
| Have business domain knowledge | Understand the business well enough to talk to stakeholders in their terms. | Knowing how restaurant payouts and refunds work before redesigning payments. |
| Possess interpersonal skills | Lead, collaborate, mentor and resolve disagreement; most architecture work is done through other people. | Facilitating a session where two teams agree an event contract. |
| Understand and navigate politics | Gain support for decisions in an organisation where budgets, priorities and ownership are contested. | Securing agreement from finance and operations before retiring an old reporting system. |
Notice how few of the eight are purely technical. Richards and Ford stress that nearly every decision an architect makes will be challenged by someone (developers, other architects, product owners, project managers), so negotiation and persuasion are core skills, not extras. An architecture that is correct on paper but not understood or accepted will not be built as intended.
The iSAQB view of architects' tasks
The International Software Architecture Qualification Board (iSAQB), whose Foundation Level curriculum (CPSA-F) is widely used in Europe, describes architects' tasks and responsibilities in a similar way. In summary, architects: clarify and scrutinise requirements and constraints; decide how to decompose the system into building blocks with their dependencies and interfaces; decide on cross-cutting concerns such as persistence, communication and user interface; communicate and document the architecture; accompany its realisation and implementation; analyse and evaluate it, especially for risks to meeting the requirements; and explain the consequences of architectural decisions to other stakeholders.
The curriculum also stresses that these tasks are iterative: architects work in cycles, revisiting requirements and decisions as feedback arrives, rather than designing once and handing over. Section 1.8 looks at how this fits into iterative and continuous delivery.
The architect's work as a cycle
Kinds of architect
Titles follow the levels of architecture described in Section 1.2. Exact responsibilities vary widely between organisations, so treat the table below as typical rather than definitive.
| Kind | Focus | Typical outputs |
|---|---|---|
| Enterprise architect | The whole organisation: capabilities, application portfolio, technology standards, alignment with strategy | Capability maps, target-state roadmaps, standards, investment advice |
| Solution architect | One business problem or programme spanning several systems, vendors and teams | Solution designs, integration designs, vendor evaluations |
| Software or application architect | The structure and qualities of one system or a group of closely related systems | Component structures, decision records, quality scenarios, technical guidance to teams |
| Data architect | How data is modelled, owned, stored, moved, governed and analysed | Data models, data ownership maps, pipeline and platform designs |
| Security architect | Identity, access, protection of data and the placement of security controls | Threat models, security patterns, control requirements |
| Cloud or infrastructure architect | Compute, network, storage, environments and platforms | Landing zones, network designs, platform standards, cost models |
A role or a job title?
Architecture is a set of responsibilities before it is a job title. In many organisations, especially smaller ones and those organised around autonomous product teams, nobody is called "architect". The architectural work is still done, by technical leads, senior engineers or the team collectively. What matters is that someone clearly owns the significant decisions and the system-wide qualities. When nobody does, architecture is still produced, but by accident.
Many technology companies use a technical career track for senior individual contributors, with levels such as staff engineer and principal engineer. Will Larson's Staff Engineer (2021) describes four common archetypes of such roles, one of which is explicitly called the Architect: a person responsible for the direction and quality of a critical technical area. Others (the Tech Lead, the Solver and the Right Hand) also carry substantial architectural responsibility. In these organisations, the architect's work is done by people who are also engineers.
Martin Fowler's 2003 article Who Needs an Architect? contrasts two caricatures: an architect who makes all the important decisions alone, and one who works closely with the team, mentors developers and helps them make good decisions themselves. Fowler argued strongly for the second. Most practitioners now agree that architects who dictate from a distance tend to produce designs that teams quietly work around.
Technical breadth versus depth
Developers are usually rewarded for depth: knowing one language, framework or platform extremely well. Architects need a different profile. Richards and Ford describe a knowledge pyramid with three layers: things you know (where you have real expertise), things you know you do not know (you know they exist and roughly what they are for, but could not build with them today), and things you do not know you do not know. Expertise in the top layer must be maintained, which takes time. The middle layer is cheap to grow and is what lets you recognise options.
An architect's value lies largely in technical breadth: knowing that five ways exist to solve a problem, what each is good and bad at, and which deserves a closer look. An architect who knows only one database will recommend it every time. Breadth comes at a price, because time spent widening the middle layer is not spent deepening the top; architects therefore deliberately let some old expertise fade and invest in knowing about more things. Richards and Ford warn of the opposite failure, the architect whose views were formed by one bad experience years ago and who rejects every option that resembles it.
The knowledge pyramid
Should architects write code?
Practitioners genuinely disagree here, and the disagreement is useful because both sides are right about something.
The case for coding. Architects who code understand the real cost of their decisions, notice when a principle is painful in practice, keep their technical judgement current and keep the respect of the developers who must implement their designs. Architects who stop coding for years risk designing systems that are elegant on a whiteboard and awkward in an editor.
The case against. An architect's time is spread across many teams, meetings and decisions. An architect who owns critical-path features becomes a bottleneck: the team waits for code that is delayed by the architect's other duties. Their attention is also needed on cross-team concerns that no single team will look after.
The common resolution. Most experienced voices, including Richards and Ford, recommend that architects stay hands-on in ways that do not put them on the critical path. Examples include building a proof of concept to test a risky option before the team commits to it; writing fitness functions, automated checks that verify architectural rules such as "the domain module must not depend on the web framework"; fixing bugs and doing small technical-debt work; building tools and automation for the team; and reviewing code regularly, which shows how decisions are actually being implemented.
import pathlib, re
FORBIDDEN = re.compile(r"^\s*(from|import)\s+flask\b", re.M)
def test_domain_does_not_depend_on_web_framework():
offenders = []
for path in pathlib.Path("shop/domain").rglob("*.py"):
if FORBIDDEN.search(path.read_text(encoding="utf-8")):
offenders.append(str(path))
assert not offenders, f"Domain code imports Flask: {offenders}"A week in the life of a software architect (illustrative)
| Day | Main activities | Expectation exercised |
|---|---|---|
| Monday | Planning with two product teams; spotting that a new loyalty feature needs data the order service does not expose; drafting options | Make decisions; know the business domain |
| Tuesday | Workshop with the data protection officer and security on storing customers' addresses; writing up a decision record | Interpersonal skills; ensure compliance |
| Wednesday | Two-day proof of concept of a managed event-streaming service to test ordering guarantees under load | Diverse exposure; keep current |
| Thursday | Code reviews on the payments team; adding a fitness function after spotting a forbidden dependency; one-to-one mentoring | Ensure compliance; interpersonal skills |
| Friday | Reviewing incident reports and lead-time metrics for signs of architectural decay; meeting finance about cloud costs; reading | Continually analyse; navigate politics; keep current |
Worked example
Worked example: one decision, five tasks
A hospital's appointment-booking system must send reminders by SMS. The software architect works through the iSAQB tasks for this one need.
| Clarify requirements | Asks how many reminders per day (about 20,000), how quickly they must go out, what happens if the SMS provider is down, and whether messages may contain clinical details (they may not, for privacy). |
|---|---|
| Design | Proposes that the booking service publishes "appointment booked" events and a separate notification component sends messages from a queue, so an SMS outage never blocks bookings. |
| Communicate | Writes a one-page decision record with the options considered (direct call versus queue) and the reasons; presents it to the team and the information governance lead. |
| Accompany implementation | Pairs with a developer on the first version, reviews the retry logic, and adds a fitness function that blocks clinical fields from the message template. |
| Evaluate | Three months later checks delivery times and failure rates; finds reminders queue for 30 minutes during a provider outage and confirms with clinicians that this is acceptable. |
Most of the architect's effort went into clarifying, communicating and checking, not into drawing the design.
The decision was recorded with its reasons, so a future team can revisit it if the context changes.
Questions people ask
How do I become an architect?
Usually by doing architectural work before having the title: owning cross-cutting decisions on your team, writing decision records, widening your technical breadth deliberately, learning the business domain and practising explaining trade-offs to non-technical people. Certifications such as the iSAQB CPSA-F can structure that learning but do not replace experience.
Does every team need an architect?
Every team needs architectural responsibility to be clearly owned, but not necessarily a dedicated person. Small teams often give it to a technical lead; larger organisations may have architects who each support several teams.
What is the difference between a technical lead and an architect?
A technical lead is usually responsible for one team's technical delivery and spends much of their time coding; an architect is usually responsible for decisions and qualities that span teams or systems. The roles overlap heavily, and in many organisations the technical lead is the architect for that team's system.
How much time should an architect spend in meetings?
There is no correct figure, but a useful test is whether the meetings produce decisions, shared understanding or removed obstacles. Gregor Hohpe's image of the architect riding an elevator between the boardroom and the engine room is a reminder that both ends need regular visits.
Check your understanding
Why do Richards and Ford include politics among an architect's expectations?
Because almost every architectural decision will be challenged by someone, and a decision that cannot win support across budgets, priorities and teams will not be implemented as intended.
Which layer of the knowledge pyramid should an architect deliberately grow, and why?
The middle layer, things you know you do not know, because knowing that options exist and what they are good for lets an architect compare solutions.
Name two ways an architect can stay hands-on without becoming a bottleneck.
Any two of: building proofs of concept, writing fitness functions, fixing bugs or small debt items, building tools and automation, and reviewing code.
Sources and further reading
Have a question about this section? ArchitectBot, the course’s AI study assistant, answers from the course first.
Ask: “I'm a senior developer who has just been asked to act as architect for my team. What should I start doing differently, and what should I stop doing?”