CPSA-F: Software Architecture Foundations for Real Design Decisions

The iSAQB Certified Professional for Software Architecture – Foundation Level (CPSA-F) is a current entry-level architecture certification focused on the decisions, communication, and technical reasoning required to design maintainable software systems. The current official Foundation curriculum is version 2025.1, valid from April 1, 2025. iSAQB states that the curriculum revision reorganized learning goals around architectural tasks while leaving the examination itself essentially unchanged.

The CPSA-F examination is a multiple-choice assessment of roughly 40 questions, normally around 75 minutes, with a passing requirement of 60 percent of the available points. Licensed certification bodies administer the exam. Formal attendance at an accredited training course is common but is not an examination prerequisite. The credential therefore tests architecture knowledge directly rather than completion of one prescribed training path.

Architecture starts by understanding the problem before choosing a structure

Software architecture is the set of significant decisions that shape a system and are difficult or costly to change later. Those decisions should begin with goals, requirements, constraints, stakeholders, and quality expectations rather than a preferred technology. A team that begins with ‘we want microservices’ or ‘we want serverless’ has selected a solution before proving that the problem requires it.

Foundation-level candidates should be able to distinguish functional requirements from quality requirements and constraints. Functional requirements describe behavior the system must provide. Quality requirements concern characteristics such as performance, availability, security, modifiability, usability, and operability. Constraints limit the solution space through laws, existing platforms, organizational standards, budgets, skills, deployment environments, or compatibility obligations.

Architectural thinking asks which requirements are architecturally significant. A small feature request may have little structural impact, while a requirement for multi-region failover or strict data residency can change deployment, data, integration, and operational design across the system.

Quality attributes become useful when expressed as concrete scenarios

Terms such as scalable, secure, maintainable, or reliable are too vague to guide design by themselves. Architects need scenarios that identify a stimulus, operating context, affected part of the system, expected response, and measurable response target. A performance requirement might specify a percentile latency under a defined workload; an availability requirement might define recovery and allowed data loss after a regional outage.

Concrete quality scenarios expose tradeoffs. Strong consistency can conflict with availability and latency. Aggressive caching can improve performance while increasing staleness and invalidation complexity. Extensive abstraction may improve substitution but reduce simplicity. Architecture is rarely about maximizing every quality attribute at once; it is about making explicit choices that fit priorities.

The contrast between high availability and fault tolerance is a useful example: related quality goals can demand different designs, costs, and recovery assumptions.

Decomposition should create understandable responsibilities and controlled dependencies

Architects divide systems into building blocks to manage complexity. Good decomposition gives components clear responsibilities, limits unnecessary coupling, and makes important dependencies visible. Cohesion asks whether a component’s responsibilities belong together. Coupling asks how strongly components depend on one another and how expensive those dependencies are to change.

Candidates should understand common decomposition strategies such as layers, components, services, domains, and technical subsystems without assuming one is universally superior. A layered monolith can be an excellent architecture when boundaries are disciplined. A distributed system can become harder to change when service boundaries are poor or when every request crosses multiple synchronous dependencies.

Interfaces are part of the architecture because they define contracts between building blocks. Stable, explicit interfaces reduce accidental coupling. They should clarify responsibilities, data formats, error behavior, versioning, timing expectations, and security assumptions where those details materially affect consumers.

Architectural patterns are reusable options, not answers that select themselves

Patterns such as layers, pipes and filters, client-server, event-driven architecture, microservices, ports and adapters, and broker styles capture recurring design approaches. Their value comes from known forces and tradeoffs. A pattern is appropriate when its consequences support the system’s quality goals and constraints.

Cloud-native design has made distributed patterns more visible, but distribution introduces latency, partial failure, operational overhead, observability needs, data-consistency questions, and security boundaries. A practical example is cloud-native application architecture, where data placement and service behavior matter as much as the application code.

The CPSA-F mindset is therefore pattern-literate but not pattern-driven. Candidates should be able to explain why a pattern fits, what problem it solves, what new problems it introduces, and what evidence would show that the decision remains appropriate.

Documentation should communicate decisions to specific audiences

Architecture documentation is not a single giant diagram. Different stakeholders need different views: developers may need building blocks and interfaces, operators need deployment and runtime behavior, security specialists need trust boundaries and data flows, and managers may need context, risk, and major decisions.

Useful documentation combines views, explanations, and rationale. A diagram without definitions can be ambiguous, while prose without structure can be difficult to navigate. Architects should document important decisions and their reasons so later teams understand not just what was chosen but which alternatives and constraints shaped the choice.

Documentation also has a maintenance cost. The goal is not maximal documentation; it is sufficient, accurate, accessible information about the architecture. Artifacts that are never updated can become more harmful than missing artifacts because they create false confidence.

Documentation should also remain proportional to the decision. A system context diagram may be enough to orient a stakeholder, while a development team may need component responsibilities, interfaces, runtime interactions, deployment views, and recorded architecture decisions. The important quality is consistency: terms should mean the same thing across views, important dependencies should not disappear between diagrams, and a reader should be able to trace a major requirement to the structures that address it. Documentation becomes a living architecture aid when it supports onboarding, reviews, change analysis, and incident learning; it becomes shelfware when it is produced once, disconnected from implementation, and never updated as decisions change.

Architecture evaluation looks for risk before implementation makes change expensive

Evaluation asks whether the proposed or existing architecture can satisfy important requirements and where the largest risks or uncertainties remain. Teams can use reviews, scenario walkthroughs, prototypes, experiments, modeling, static analysis, performance tests, threat modeling, and operational evidence depending on the question.

The key is to evaluate significant assumptions early. If a system depends on a database meeting a latency target under peak load, that assumption can be prototyped. If a third-party service must meet a recovery objective, the contract and test evidence can be examined. If an authorization design depends on role boundaries, abuse cases can be walked through.

Evaluation is not an adversarial ceremony. It is a way to reduce expensive surprises. The architecture should evolve when evidence shows that an assumption is wrong or a tradeoff has changed.

Evaluation is most useful when it is scenario driven. Rather than asking whether an architecture is “good,” the team can test a concrete quality concern: how the system behaves when a dependency is unavailable, whether a new feature can be added without changing several unrelated components, or whether a latency target survives a projected increase in load. Those scenarios expose sensitivity points and tradeoffs that generic design reviews often miss.

Tradeoffs should be recorded because architectural qualities can conflict. Replication may improve availability while increasing consistency complexity. Strong isolation may reduce blast radius while raising operational overhead. A shared platform may lower cost while creating coupling between teams. Architects do not eliminate these tensions; they make them visible, compare alternatives, and document why a particular balance is appropriate for the system’s context. That reasoning is central to professional architecture work and to the CPSA-F emphasis on deliberate design decisions.

Architecture and security should be designed together

Security is an architectural quality because trust boundaries, identity, data classification, deployment topology, interfaces, and failure behavior are structural choices. Adding security controls after the main design is fixed can leave expensive gaps or force awkward compensating controls.

Architects should understand principles such as least privilege, defense in depth, secure defaults, separation of duties, minimizing attack surface, and explicit trust boundaries. They do not need to become specialized penetration testers to design systems that make secure operation possible.

Security architecture is explored more deeply in CISSP security architecture and engineering. For CPSA-F, the important point is that security requirements must influence architecture from the beginning.

Architecture work is collaborative because decisions cross organizational boundaries

Software architects rarely have unilateral authority over every relevant decision. Product owners define priorities, developers understand implementation detail, platform teams shape deployment constraints, security and compliance teams define obligations, and operations teams see failure modes that design documents may miss. Architecture succeeds when those perspectives are integrated.

Communication therefore requires more than presenting diagrams. Architects need to explain tradeoffs, listen for constraints, surface uncertainty, negotiate priorities, and make decisions transparent. They also need to avoid becoming a bottleneck: clear principles and decision boundaries can enable teams to make local choices without constant central approval.

Modern delivery practices reinforce that collaboration. The relationship between architecture and DevOps practices shows why build, deployment, observability, and operability need architectural attention rather than being deferred until release.

CPSA-F is the foundation for deeper architecture specialization

The Foundation Level establishes common language and core practices for requirements, design, documentation, evaluation, and architecture work. iSAQB’s broader iSAQB certifications extends into Advanced Level modules covering areas such as architecture evaluation, domain-driven design, APIs, cloud infrastructure, web security, requirements, enterprise architecture, and other specialized topics.

Candidates should not rush to advanced techniques before the fundamentals are stable. The ability to articulate quality goals, choose boundaries, document rationale, and evaluate tradeoffs is valuable across every technology stack. Advanced patterns become useful only when the architect can explain what problem they solve.

Preparation should therefore practice architecture reasoning. Take a familiar system, identify stakeholders and significant requirements, propose a structure, document the important views, describe alternatives, and test the design against quality scenarios. That exercise mirrors the professional skill the credential is designed to validate.