Role and Task of Software Architects
Domain 2: Role and task of software architects
This domain tests the architect's responsibilities, authority, and working style. iSAQB treats the architect as someone who makes and communicates significant technical decisions, aligns them with stakeholders, and guides implementation without owning every code change. The exam probes stakeholder analysis, decision-making, governance, and the boundary between architecture and project management.
Core rules
- Identify stakeholders and their concerns early: product owner, developers, operations, security, management, users.
- Own architecturally significant decisions; document context, alternatives, rationale, and consequences.
- Communicate in the audience's language: business impact for management, interfaces and protocols for developers, runtime and failure modes for operations.
- Govern by principles, reviews, and fitness checks, not by approving every commit.
- Escalate conflicts with evidence: quality scenarios, prototypes, cost estimates.
- Maintain technical responsibility while respecting project-management authority over schedule and budget.
Worked example
A team wants a new message broker for an order service. The architect discovers operations lacks on-call capacity, the product owner needs a two-week release, and security requires audit trails. The architect runs a short spike, compares a managed queue with a self-hosted broker, records an ADR choosing the managed service, and defines a review checkpoint for retry and dead-letter handling. Reasoning: the decision is cross-cutting and expensive to reverse; it addresses operability, delivery speed, and auditability. The architect does not write all producer code.
Traps
Acting as a super-developer or surrogate project manager loses marks. Ivory-tower decisions without stakeholder input are equally wrong. Avoid decisions with no recorded rationale, and avoid promising to document later. Do not promise quality attributes without measurable scenarios or operational support.