System Architect Examination — knowledge map

The 42 core concepts of System Architect Examination and how they connect. Click a node in the map above to explore related terms and prerequisites; the list below indexes every concept with its definition and links to its prerequisites and related concepts.

Concepts (42)

• Coupling

  A measure of how strongly modules depend on one another; lower coupling means better design. From strongest (worst) to weakest it runs content > common > external > control > stamp > data, with data coupling (passing only the needed data as arguments) being the most desirable. Good design combines high cohesion with low coupling, and a system architect minimizes interfaces so that the ripple effect of changes stays localized.

  Prerequisites: Cohesion

• Requirements definition

  An upstream software development process step that clarifies the functions and performance the users or client require and fixes the scope of what will be built. Misunderstandings here directly translate into costly rework in later stages.

• Client-server system (three-tier client-server)

  A distributed model that splits functions between clients that request services and servers that provide them. In a three-tier client-server design, the presentation tier (screen), function/application tier (business logic), and data tier (persistence) are separated so each can be deployed and scaled independently. The architect decides which tier runs on which host based on load characteristics and security boundaries.

  Prerequisites: Centralized vs. distributed processing

• Vertical (functional) vs. horizontal (load) distribution

  Vertical (functional) distribution assigns different layers or functions to separate machines, e.g., a presentation host apart from a database host, raising per-function independence. Horizontal (load) distribution replicates machines that perform the same function and uses a load balancer to spread requests, increasing throughput and availability. Combining both to design scalability is a typical architect judgment.

  Prerequisites: Load balancer (L4/L7)、Throughput

• Availability rate

  The proportion of time a system operates correctly. Availability = MTBF ÷ (MTBF + MTTR); it rises as time-between-failures grows and repair time shrinks. A core availability metric, also used as an agreed SLA target (e.g., 99.9%).

  Prerequisites: MTBF (mean time between failures)

• Non-functional requirements

  Requirements concerning the quality aspects of a system — such as performance, availability, security, and maintainability — rather than the functions themselves. They must be clarified alongside functional requirements during requirements definition.

  Prerequisites: Requirements definition

• Throughput

  A performance metric expressing the amount of work a system can process per unit time, such as transactions per second or bytes per second of data transfer. It improves by increasing concurrency, adding hardware resources, or removing bottlenecks. The architect estimates the required peak throughput and designs a configuration with adequate capacity margin to meet it.

• Entity-relationship diagram

  A conceptual modeling technique used in database design to diagram entities and the relationships between them. It explicitly shows the cardinality between entities (one-to-one, one-to-many, many-to-many) and is used as a precursor to logical database design and normalization.

• UML (Unified Modeling Language)

  A standardized modeling language for diagramming object-oriented system design and analysis results in a unified notation. It includes multiple diagram types for different purposes, such as class diagrams (static structure), use case diagrams (interaction between a system and its users), and sequence diagrams (time-ordered message exchange between objects).

  Prerequisites: Use case diagram

• MTBF (mean time between failures)

  For a repairable system, the average operating time from one failure to the next. A larger value means fewer failures and higher reliability. Computed as total operating time ÷ number of failures.

• Load balancer (L4/L7)

  A device that distributes load across multiple servers. An L4 load balancer distributes based on IP address and port; an L7 load balancer can interpret application-layer information such as HTTP URL paths and cookies, enabling path-based routing and cookie-based session persistence. Health checks automatically remove failed servers from rotation.

• Centralized vs. distributed processing

  Centralized processing concentrates processing and data on one core system, making management and consistency easy but creating a single point of failure and a hard performance ceiling. Distributed processing spreads work across multiple nodes to raise availability and scalability at the cost of more complex communication, consistency, and operations. The architect balances the two against reliability requirements, cost, and the operations team's capacity.

• Clustering (HA cluster, load-balancing cluster)

  A technique that binds multiple servers together so they appear as a single system to users. A high-availability (HA) cluster aims to keep running by failing over to other nodes when one fails, while a load-balancing cluster distributes requests across nodes to raise throughput and concurrency. The architect chooses the configuration based on whether availability or performance is the goal, and designs for shared-disk arrangements and split-brain prevention.

  Prerequisites: Failover and failback、Throughput、Vertical (functional) vs. horizontal (load) distribution

• Orchestration vs. choreography

  Two control styles for coordinating microservices. Orchestration has a central conductor (orchestrator) invoke each service in turn to govern the overall flow, which is easy to follow but concentrates dependence on that conductor. Choreography places no central control; each service publishes and subscribes to events and coordinates autonomously, yielding loose coupling but making the overall flow harder to trace.

  Prerequisites: Coupling

• Polyglot persistence

  The idea of using the data store best suited to each kind of data: a relational database for business data needing strong consistency and joins, a key-value store for simple high-speed lookups, a document database for hierarchical documents, and a graph database for traversing relationships. Instead of forcing everything into one database, the architect accepts the trade-off of maintaining consistency across stores and higher operational cost.

  Prerequisites: Document-oriented database、Key-value store (KVS)

• CI/CD

  CI (continuous integration) automatically builds and tests code on every change to catch defects early. CD has two meanings: continuous delivery automates everything up to a release-ready state but keeps a manual approval for the production release, while continuous deployment automates all the way to production.

• DevOps

  A philosophy and culture in which development and operations collaborate closely, using automation and CI/CD to deliver software faster and continuously.

  Prerequisites: CI/CD

• Virtualization

  Technology that uses software to create multiple virtual computers (virtual machines) on a single physical computer (server virtualization); storage, network, and desktop resources can likewise be virtualized. It allows hardware resources to be used efficiently and enables consolidation and flexible reconfiguration.

• MTTR (mean time to repair)

  The average time from a failure until recovery. A smaller value means faster recovery and better maintainability. Computed as total repair time ÷ number of failures; it is part of the denominator in availability = MTBF ÷ (MTBF + MTTR), assessed together with MTBF (mean time between failures) for reliability and maintainability.

  Prerequisites: Availability rate、MTBF (mean time between failures)

• Architecture pattern

  A reusable, proven template for recurring problems in a system's overall structure. Representative examples include layers, client-server, event-driven, microservices, and pipes-and-filters, each with its own strengths, weaknesses, and applicable context. Whereas design patterns address class- and object-level design, architecture patterns address coarser overall structure, which the architect selects against quality-attribute requirements.

  Prerequisites: Client-server system (three-tier client-server)、Design patterns (GoF patterns)

• Cohesion

  A measure of how strongly the elements inside a single module are focused on one purpose; higher cohesion means better design. From weakest to strongest it runs coincidental < logical < temporal < procedural < communicational < sequential < functional, with functional cohesion (doing exactly one job) being ideal. When partitioning modules, a system architect organizes responsibilities so each module is highly cohesive, improving maintainability and reusability.

  Related: Module partitioning techniques (STS/TR/common-function)

• Design patterns (GoF patterns)

  Reusable solutions to recurring problems in object-oriented design, catalogued as 23 patterns by the Gang of Four (GoF). They fall into three categories: creational patterns (Factory Method, Singleton, Builder, etc.), structural patterns (Adapter, Facade, Proxy, etc.), and behavioral patterns (Observer, Strategy, State, etc.). A system architect uses them as a shared vocabulary to convey design intent and to secure quality and maintainability through proven structures.

• Data-oriented approach (DOA)

  A methodology that designs information systems on the stable foundation of data structure, which changes less than processing. The data handled by the business is modeled and normalized with tools such as E-R diagrams, and processing functions are built on top of that data model. It assumes that processing changes often with business change while data structure stays relatively stable, serving a system architect as a basic policy for building maintainable, long-lived data assets.

  Prerequisites: Entity-relationship diagram

• Layered architecture

  A structural pattern that divides software responsibilities into layers, where an upper layer depends in principle only on the layer directly beneath it. Separating concerns improves maintainability, replaceability, and testability, so swapping one layer's implementation seldom ripples to others. A presentation / business-logic / data-access three-layer split is typical; note this logical layering differs conceptually from the physical three-tier client-server deployment.

  Prerequisites: Client-server system (three-tier client-server)

• Module partitioning techniques (STS/TR/common-function)

  A family of techniques for splitting a program into maintainable units. STS partitioning divides a data flow diagram at its maximum-abstraction input and output points into Source, Transform, and Sink; TR (transaction) partitioning routes processing by the type of input transaction; common-function partitioning extracts functions shared by several places into independent modules. A system architect chooses among them by the nature of the processing to obtain a high-cohesion, low-coupling structure.

  Prerequisites: Coupling

  Related: Cohesion

• Saga pattern (compensating transactions)

  A pattern for keeping updates that span multiple microservices consistent when each service has its own database. Rather than one ACID transaction, it chains each service's local transaction and, if a step fails partway, runs compensating transactions in reverse to undo the completed steps, achieving eventual consistency. It has two implementation styles: orchestration, where a central orchestrator directs each step, and choreography, where each service proceeds autonomously via a chain of events. It is chosen when the design wants to avoid two-phase commit for distributed transactions.

  Prerequisites: Orchestration vs. choreography

• Use case diagram

  A UML diagram that shows the functions a system provides to the outside (use cases) and the people or external systems that use them (actors). Actors are drawn as stick figures and use cases as ovals, connected by lines that make the system boundary explicit, with include and extend relationships adding detail. A system architect uses it early in requirements analysis to agree on the scope of functions from the user's viewpoint and to visualize that scope.

• Container virtualization

  A lightweight virtualization approach in which multiple application runtime environments (containers) share the host OS kernel, with processes and file systems isolated via namespaces. Compared with hypervisor-based virtualization (which runs a full guest OS), it starts faster and has less overhead, but it depends on the host kernel, so it cannot run a kernel of a different OS type. Docker is a representative implementation.

  Prerequisites: Virtualization

• Document-oriented database

  A NoSQL model that stores data as semi-structured documents (e.g., JSON-like). Its flexible, per-document schema lets different documents hold different fields, suiting hierarchical or variable-structure data.

• Key-value store (KVS)

  A simple NoSQL data model that manages data purely as key-value pairs. Being schemaless, it scales out easily and suits use cases like session management or caching, where reads/writes are simple and speed matters.

• Waterfall model

  A development approach that proceeds through phases — requirements definition, design, implementation, testing — in sequence, on the premise that, in principle, work does not return to a previous phase. It is easy to plan but not well suited to mid-project requirement changes.

  Prerequisites: Requirements definition

• Activity diagram

  A UML behavioral diagram that represents a sequence of business or processing flow as a chain of actions (rounded boxes). It can express branching/merging and concurrent processing (fork/join), and swimlanes can partition work by actor or role, making it well suited to modeling business flows and procedures. Its purpose differs from a state machine diagram, which shows the state changes of a single object.

  Prerequisites: State transition diagram (state machine diagram)

• Component diagram

  A UML structural diagram that represents the physical software parts (components) making up a system, together with the interfaces they provide and require and their dependencies. It shows coupling between parts via provided interfaces (ball) and required interfaces (socket), helping examine the split into units of reuse or deployment. Its subject differs from a deployment diagram, which shows runtime node placement.

  Prerequisites: Coupling

• Deadlock

  A stalemate in which multiple processes or transactions each wait for a resource held by another, so none can proceed. It arises when the four conditions of mutual exclusion, hold-and-wait, no preemption, and circular wait hold simultaneously; countermeasures include prevention by unifying the resource acquisition order, avoidance by scheduling resource requests, and detection via a wait-for graph followed by rolling back one party. The architect designs lock granularity and acquisition order to suppress deadlocks.

  Prerequisites: Rollback and checkpoint (recovery)

• Failover and failback

  Failover is the mechanism or action of automatically switching processing to a standby system when the primary fails, preserving availability. Failback is returning processing to the original primary once it has recovered, from the standby that took over. The architect must design for data consistency and session takeover during failover, and for the brief interruption of switching back during failback.

• Jackson method (JSP)

  A program design technique (Jackson Structured Programming) that derives program structure from the input and output data structures. Data is modeled with the three basic constructs of sequence, selection, and iteration, and the program's control structure is mapped mechanically from the input/output data structures. It rests on the idea that data structure dictates process structure, which helps a system architect assure structural correctness.

• Non-functional requirements grades

  A system and set of tools published by IPA for acquirers and suppliers to concretely agree, as graded levels, on non-functional requirements such as availability, performance/scalability, operability and maintainability, migratability, security, and system environment/ecology. It makes abstract, easily overlooked non-functional requirements visible as items and levels, preventing mismatched understanding of required levels and cost estimates. The architect uses it to elicit non-functional requirements without omission and fix them as premises for architecture design.

  Prerequisites: Non-functional requirements

• Process-oriented approach (POA)

  A methodology that analyzes and designs information systems centered on business processing functions. Functions are decomposed step by step with tools such as data flow diagrams (DFDs), and the inputs and outputs each function handles are defined. Data structure tends to be dragged along by changes in functions, which can hurt maintainability, so it is contrasted with the data-oriented approach (DOA) that treats data structure as a stable base. A system architect chooses between them according to the nature of the target business.

  Prerequisites: Data-oriented approach (DOA)

• Rollback and checkpoint (recovery)

  Rollback is a recovery operation that, on transaction failure, restores data to the state before the transaction began, preserving consistency. A checkpoint periodically flushes in-memory updates to disk and records a consistent reference point in the log, so on failure recovery can roll forward using only the log after the last checkpoint, shortening recovery time. The architect designs the checkpoint interval and log operation to balance performance against the recovery time objective.

• Common frame (SLCP-JCF)

  A framework (SLCP-JCF, the common frame) that standardizes the work content and terminology across the whole software lifecycle from planning through development, operation, maintenance, and retirement, so that acquirers and suppliers can transact with a shared understanding. It organizes work into processes, activities, and tasks and clarifies contract scope and responsibility sharing, but does not prescribe concrete procedures or methodologies themselves. The architect frames the transaction and division of requirements definition and design in common-frame terms to prevent misunderstandings.

  Prerequisites: Requirements definition

• State transition diagram (state machine diagram)

  A diagram that represents the states an object or system can take and the transitions that move it from state to state on events. Each transition can associate a triggering event, a condition that must hold (guard condition), and the action performed, letting state-dependent behavior be defined exhaustively. It suits modeling control targets whose possible states are finite and well defined, such as embedded control or order progression.

• Warnier method

  A design technique that derives program structure from the input data structure, from a set-theoretic viewpoint. It expresses hierarchically with brackets how many times, when, and where data appears as nested repetitions, and builds the program top-down by combining the three control constructs of sequence, selection, and iteration. It contrasts with the Jackson method, which handles the correspondence between both input and output data structures. A system architect uses it to design processing driven by data structure.

  Prerequisites: Jackson method (JSP)