Describe the six core responsibilities of an architect, apply each to a concrete system, decompose a system into well-bounded parts, capture and design within constraints, evaluate technology choices against drivers, design integration, turn quality attributes into measurable targets and tactics, and plan for evolution with fitness functions
Architecture responsibilities are the areas for which the architect is accountable: ensuring the system has a sound structure, respects its constraints, uses appropriate technologies, integrates cleanly, achieves its quality attributes and can evolve over time.
Figure 1 — Architecture responsibilities (TOC)
TOC responsibility
Definition
Structure
Decomposing the system into parts with clear responsibilities, boundaries, dependencies and data ownership
Constraints
Identifying, validating and designing within fixed limits — technology, regulation, organisation, budget, legacy
Technology choices
Selecting platforms, frameworks, databases and infrastructure that meet drivers at acceptable cost and risk
Integration
Defining how parts of the system and external systems communicate — styles, contracts, consistency
Quality attributes
Setting measurable targets for performance, availability, security, etc., and choosing tactics to meet them
Evolution
Keeping the architecture adaptable: managing change, technical debt, migrations and fitness over years
Table 1 — The six TOC responsibilities
2Why It Exists
In teams without clear architectural responsibility, structure fragments, technologies proliferate, integrations become ad hoc and quality attributes are discovered in production. Naming the responsibilities makes it possible to assign ownership, plan work and review designs systematically.
The responsibilities also matter because architectural concerns are mostly cross-cutting. A feature team owns its backlog, but nobody owns the fact that availability depends on the weakest of twelve services, or that three teams have each chosen a different way to publish events. Without a named owner these concerns are settled by accident, one pull request at a time, and the cost appears only later as outages, migrations or slow delivery. Listing the six responsibilities gives each concern an accountable person and a set of artefacts, so reviews can ask concrete questions: is the structure enforced, are constraints validated, is every quality attribute measured? It also makes the architect's role explainable to managers who ask what architects actually deliver.
Figure 2 — Who does what
3Core Concepts
3.1 Structure
Figure 3 — Structure: decomposition and boundaries
Structural decision
Example
Decomposition style
Modular monolith vs microservices
Boundaries
Bounded contexts from capabilities
Dependencies
Allowed directions, no cycles
Data ownership
One master per entity
Shared platform
Identity, observability, messaging
Table 2 — Structural responsibilities
3.2 Constraints
Constraint
Architectural response
Must use Azure
Azure-native services, skills plan
Card data scope (PCI)
Isolate payment component, tokenisation
8-person team
Few deployables
Mainframe core
ACL, CDC
Table 3 — Designing within constraints (Chapter 2.3)
3.3 Technology choices
Figure 4 — Technology choice criteria (TOC)
TEXT
Technology radar entry (example)- ADOPT: Java 25 LTS, Spring Boot 4, PostgreSQL 17, Kafka 4 (managed)- TRIAL: Spring Modulith 2, GraalVM native images for CLI tools- ASSESS: Kafka share groups (KIP-932)- HOLD: new SOAP services, self-hosted Kafka
// Fitness function: checkout latency must stay within budget as the system evolves@Testvoid checkoutStaysWithinLatencyBudget() {var stats = loadTest("/api/checkout", Duration.ofSeconds(60), 200); // rps assertThat(stats.p99()).isLessThan(Duration.ofMillis(300));}
Evolution practice
Purpose
Fitness functions
Protect key qualities automatically
Technical debt register
Visible, prioritised debt
Reversible decisions
Keep options open
Incremental migration
Strangler, branch by abstraction
Table 6 — Designing for change
4How It Works Internally — Responsibilities Across the Lifecycle
Phase
Main responsibilities
Inception
Drivers, constraints, candidate structures
Design
Structure, technology, integration, QA tactics
Build
Guidance, reviews, fitness functions
Run
QA monitoring, incident learnings
Evolve
Debt management, migrations, re-architecture
Table 7 — Responsibilities over time
4ADeep Dive — Responsibility Boundaries in Teams
Model
Architect's position
Risk
Ivory tower
Designs, hands over
Designs ignored, unrealistic
Embedded
Part of a team
Loses system view
Architecture as facilitation
Runs decision process across teams
Needs strong communication
Community of practice
Architects + senior devs share responsibility
Needs clear decision rights
Table 8 — Operating models
5APIs / Features / Syntax
Responsibility
Tools / artefacts
Structure
C4 container/component views, Spring Modulith, ArchUnit
Constraints
Constraint register, ADRs
Technology
Tech radar, evaluation matrices, PoCs
Integration
Context maps, OpenAPI/AsyncAPI
Quality attributes
QA scenarios, SLOs, load tests
Evolution
Fitness functions, debt register, roadmap
Table 9 — Artefacts per responsibility
6Practical Examples
6.1 Unowned quality attribute
A B2B portal had no availability target; each team assumed "someone" handled it. A single-AZ database failure caused a 5-hour outage. Afterwards the architect owned an availability target (99.95%), multi-AZ design and a failover test schedule.
6.2 Technology sprawl
Twelve teams chose four message brokers and three JSON libraries. A technology radar with ADOPT/HOLD rings and a lightweight approval process reduced new variation to near zero.
6.3 Worked example — responsibility checklist for a new system
Responsibility
Output
Structure
Container diagram, module boundaries
Constraints
Constraint register (10 items)
Technology
Stack ADRs
Integration
Context map, API/event catalogue
Quality attributes
6 QA scenarios with targets
Evolution
Fitness functions, roadmap
Table 10 — Architect's deliverables
6.4 Worked example — structure decision
Option
Fit
Microservices (12)
✘ team of 10
Modular monolith (6 modules)
✔ start
Extract later
Payments first (PCI)
Table 11 — Structure matches team and drivers
6.5 Worked example — technology evaluation
Criterion
PostgreSQL
MongoDB
Transactions across entities
✔
◆
Team skills
✔
◆
Reporting
✔
◆
Decision
PostgreSQL
—
Table 12 — Criteria-based choice
6.6 Worked example — integration map
Link
Style
Web → API
REST
Orders → Payments
REST (auth), events (outcome)
Orders → ERP
ACL + batch
Table 13 — Integration responsibility in one table
6.7 Worked example — QA tactics catalogue
QA
Tactics
Performance
Cache, index, async, pool sizing
Availability
Redundancy, retries, circuit breakers
Security
AuthN/Z, encryption, audit
Table 14 — Reusable tactics
6.8 Worked example — debt register
Debt
Impact
Plan
Shared DB with billing
Blocks independent releases
Events by Q3
No tracing in legacy module
Slow incidents
OTel agent
Table 15 — Evolution responsibility made visible
6.9 Worked example — ArchUnit as structural guardrail
6.15 Worked example — measuring architecture health
Indicator
Responsibility
Deployment frequency
Evolution
SLO attainment
Quality attributes
Integration incidents
Integration
Architecture rule violations
Structure
Table 21 — Metrics per responsibility
6.16 Worked example — balancing responsibilities
Tension
Resolution
New tech vs constraints
Trial within guardrails
Performance vs evolution
Optimise hot paths only
Table 22 — Responsibilities interact
6.17 Worked example — handover to teams
Artefact
Team uses it for
Module boundaries + rules
Daily coding
QA scenarios
Tests
ADRs
Understanding why
Table 23 — Architecture enables teams
6.18 Worked example — interview answer
Responsibility
One-line example
Structure
Split by capability
Constraints
Data residency → single region
Technology
Kafka for events
Integration
Outbox + events
QAs
p99 < 300 ms
Evolution
Fitness functions
Table 24 — Covering all six
7Common Problems & Mistakes
Only technology choices treated as architecture.
Unowned quality attributes.
Unvalidated constraints.
Ad-hoc integration decisions per team.
No evolution plan or debt visibility.
Ivory-tower designs without team involvement.
Most of these mistakes come from treating architecture as a set of documents or technology picks rather than ongoing accountability. Reducing the role to choosing frameworks leaves structure, integration and quality attributes to chance, and the gaps show up in production, like the B2B portal whose availability nobody owned. Unvalidated constraints are subtler: an outdated "no cloud" rule or an assumed vendor mandate can quietly rule out the best option for years. Ad-hoc integration produces a mixture of styles, contracts and consistency approaches that no one can reason about as a whole. The cure for all of them is the same pattern: an owner for each responsibility, an artefact that makes it visible, and an automated or regular check that it still holds.
8Performance & Production Considerations
Aspect
Guideline
Accountability
Each responsibility has an owner
Artefacts
Diagrams, registers, ADRs, SLOs
Verification
Fitness functions, reviews
Metrics
Health indicators per responsibility
Operating model
Facilitating, embedded with teams
Table 25 — Operational guidelines
9Architecture & Design Considerations
Cover all six responsibilities for every system.
Turn each responsibility into artefacts and checks.
Share work with teams, keep accountability clear.
Revisit responsibilities as the system evolves.
10Interview Questions & Answers
Q1BasicConcept
What are the main responsibilities of an architect?
An architect is accountable for six areas: structure, constraints, technology choices, integration, quality attributes and evolution. Structure means decomposing the system into parts with clear boundaries, dependency rules and data ownership. Constraints are the fixed limits, such as regulation, budget, team size or legacy platforms, that every design must respect. Technology choices select platforms and frameworks against the drivers. Integration defines how parts and external systems communicate and stay consistent. Quality attributes turn vague goals like "fast" or "reliable" into measurable targets with tactics. Evolution keeps the system changeable for years. The key word is accountable: the architect does not do all the work, but makes sure each concern is consciously decided, documented and verified.
Q2BasicConcept
What does the structure responsibility cover?
Structure covers how the system is divided and how the parts are allowed to relate. It starts with the decomposition style, for example a modular monolith or a set of microservices, and the boundaries, ideally bounded contexts derived from business capabilities rather than technical layers. It also defines dependency rules, such as which modules may call which and the rule that there are no cycles, and data ownership, so each entity has exactly one master. Shared platform concerns like identity, observability and messaging belong here too. Good structure keeps most changes inside one part, and it should be enforced in code with Spring Modulith verification or ArchUnit rules rather than living only in diagrams.
Q3IntermediateTrade-off
How should technology choices be made?
Technology choices should be made against the system's drivers, not popularity or personal preference. Start from the quality attributes and constraints the choice must satisfy, then compare two or three candidates on fit, team skills, ecosystem maturity, operational cost, licensing and how reversible the choice is. Gather evidence where claims matter: a short spike, a benchmark or a cost model. Record the decision in an ADR with the rejected options and consequences. At organisation level a technology radar with Adopt, Trial, Assess and Hold rings prevents sprawl, for example standardising on PostgreSQL and managed Kafka so twelve teams do not run four brokers. Prefer boring, well-supported technology for anything hard to reverse.
Q4IntermediateDesign
How do quality attributes become actionable?
Quality attributes become actionable when each one is turned into a measurable target and a set of tactics that are tested. "The system must be fast" is useless; "checkout p99 latency under 300 ms at 2,000 requests per second" can be designed for and verified. Quality attribute scenarios describe the stimulus, environment and expected response, and SLOs express the operational target, such as 99.95% availability over 30 days. For each target the architect chooses tactics, for example caching and asynchronous side effects for performance, or multi-AZ redundancy and circuit breakers for availability. Finally the targets are checked continuously through load tests, fitness functions and SLO dashboards, so regressions are caught before customers notice them.
Q5Senior EngineerConcept
What is a fitness function?
A fitness function is an automated, objective check that an architectural characteristic still holds as the system evolves. The term comes from evolutionary architecture by Ford, Parsons and Kua. Examples include an ArchUnit rule that no class outside the payments module accesses its internal package, a Spring Modulith verify test that fails on illegal module dependencies, or a load test asserting that checkout p99 stays under 300 ms. Because they run in CI or on a schedule, fitness functions turn architecture decisions into guardrails instead of documents people forget. Good ones are cheap, fast and tied to a specific driver; a slow performance test may run nightly while structural rules run on every build.
Q6Senior EngineerTricky
How does an architect handle constraints?
An architect identifies constraints early, validates them, records them and then designs within them. Validation matters because many stated constraints are really preferences, outdated policies or assumptions. "We must use Oracle" may apply only to finance, and "no cloud" may have been replaced by a data processing agreement. Each confirmed constraint goes into a constraint register with its source and owner, and is linked from the ADRs it shapes. The design then responds explicitly, for example isolating the payment component to keep PCI scope small or limiting the number of deployables for an eight-person team. Constraints are revisited when context changes, because a constraint that no longer applies silently restricts every future option.
Q7Technical ArchitectDesign
How do you avoid ivory-tower architecture?
You avoid ivory-tower architecture by working with the teams who build and run the system rather than handing designs over the wall. In practice the architect spends time embedded with teams, runs decisions as a facilitated process where engineers bring evidence and options, and reviews designs with tech leads and SRE. Designs are made executable: module boundaries enforced by ArchUnit or Spring Modulith, quality targets expressed as SLOs and tests, and ADRs written where developers read them, in the repository. A community of practice spreads decisions across teams. The warning signs of an ivory tower are diagrams that do not match the code, decisions teams quietly ignore and architects who never attend incident reviews.
Q8Solution ArchitectScenario
How would you structure your first 90 days as architect of an existing system?
I would spend the first 30 days learning: recover the real structure from code, traces and deployment, interview stakeholders about business drivers, and read the incident history. That produces a current-state container view, a constraint register and a technical debt register. In days 30 to 60 I would agree measurable quality targets with product and operations, such as SLOs for the critical journeys, and start an ADR log for past and pending decisions. In days 60 to 90 I would put the first fitness functions into CI, for example dependency rules and a latency budget, and agree an evolution roadmap that sequences the most valuable debt repayments. Throughout, small visible wins build trust.
Newsletter
Get new tutorials every week
New ArchitectMind tutorials and interview questions, once a week. No spam, unsubscribe anytime.
Your subscription could not be saved. Please try again.
Almost done! Check your inbox and click the confirmation link to complete your subscription.
Architect
