System Architect ExaminationStudy guide

Covers the four layers of enterprise architecture (EA)—BA (business architecture), DA (data architecture), AA (application architecture), and TA (technical architecture)—and the judgment skill of aligning IT planning with business strategy and, from the gap between the current state (As-Is) and the target state (To-Be), making the optimal planning decision in light of return on investment.

Covers requirements elicitation, drawing requirements out of stakeholders; requirements analysis, organizing requirements and resolving contradictions; the difference between functional requirements and non-functional requirements; requirements traceability, tracking the correspondence between requirements and deliverables; and the judgment skill of properly building consensus on requirements, including change management during development.

Covers the characteristics of representative business-modeling notations—DFD (data flow diagram) for depicting the flow of business, the E-R diagram for data structure, UML (use case diagrams, etc.) for the interaction between the system and users, and BPMN for the overall flow of a business process—and the judgment skill of choosing the notation appropriate to the purpose of contrasting the current business (As-Is) against the desired business (To-Be).

Covers using the non-functional requirements grade, which systematically organizes non-functional requirements such as performance, reliability, availability, and security, and the judgment skill of translating easily-vague non-functional requirements into measurable indicators and building stakeholder consensus on them to prevent rework.

Covers functional allocation—deciding whether a required function is realized in hardware, software, or a manual procedure—and the practice of method selection, choosing the most appropriate architecture by weighing trade-offs across performance, cost, availability, and maintainability.

Covers the trade-off between centralized processing, which concentrates processing in one place, and distributed processing, which spreads it across multiple sites or machines, and how to judge processing placement between two-tier (logic held on the client) and three-tier (separating presentation, application, and data) client/server architectures.

Covers the presentation, application, and data tiers as the Web evolution of three-tier client/server, stateless design in which a server holds no client state, externalizing session state to an external store, and scaling out—adding server instances to handle load.

Covers SOA, which loosely couples functionality as services, its evolution into microservices—services split fine enough to deploy independently—how to judge service boundaries along domain lines, and how to accept the distribution tax of eventual consistency and operational complexity.

Covers the differing roles of message queues (MQ), ESB, and API Gateway for asynchronous service integration, loosely coupled integration via event-driven architecture, and the ever-present concerns of message ordering, duplicate delivery, and eventual consistency in asynchronous integration.

Covers the two yardsticks for module-decomposition quality: cohesion (the strength of relatedness among elements within a module—higher is better) and coupling (the strength of dependency between modules—lower is better), including their orderings and kinds, and how to diagnose the root cause of "a single change rippling across a wide area" using these two axes and decide on a fix.

Covers the three pillars of object-oriented design—encapsulation, inheritance, and polymorphism—the SOLID principles for change-resilient design (single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion), and how to choose among UML diagrams (class, sequence, state-transition) to visualize different design decisions, together with judging how to respond to a real requirement change.

Covers the intent of representative examples from the three GoF design-pattern categories—creational (Singleton, Factory Method), structural (Adapter, Facade), and behavioral (Observer, Strategy)—and building the judgment to select the right pattern for a design problem at hand.

Covers the difference in call direction among a library, a component, and a framework—your code calling the other versus the other calling your code, i.e. the Inversion of Control (IoC)—along with REST API design principles (resource orientation, statelessness, HTTP method semantics) and versioning strategy, together with judging how to choose a reuse approach for existing assets and how to preserve compatibility for a public API.

Covers the distinction between response time, which drives user experience, and throughput, which measures processing capacity; the utilization (ρ)-to-wait-time relationship under the basic M/M/1 queueing model; and the judgment to diagnose bottlenecks and size capacity, built through business-requirement scenarios.

Covers the five RASIS metrics for measuring system reliability, availability calculation for series/parallel configurations, and the distinctions among fault tolerant, fail-soft, and fail-safe behavior under failure, learned through cost-versus-reliability tradeoff judgments.

Covers judging which redundant configuration to choose from a target availability, the HA cluster, which makes multiple servers behave as one system, DR (disaster recovery) and BCP (business continuity plan) for large-scale disasters, and RTO (recovery time objective)/RPO (recovery point objective), which quantify recovery targets.

Covers defense in depth, which compensates for the limits of perimeter defense; the zero trust mindset, which trusts nothing by default even internally; the distinction between authentication (verifying identity) and authorization (determining permissions); and secure by design, which builds security in from the earliest design stage, along with threat analysis, learned through architecture judgments tailored to business requirements.

Covers how a hypervisor (Type 1 / Type 2) drives server virtualization and storage virtualization, the characteristics of containers (Docker), which share the OS kernel and start up fast and light, and the judgment involved in orchestrating many containers automatically with Kubernetes.

Covers choosing among IaaS/PaaS/SaaS, which differ in the division of responsibility between the customer and the cloud provider, selecting among public/private/hybrid cloud, and the migration-strategy judgment between lift and shift and re-architecting when moving an existing system to the cloud.

Covers choosing between RDB, which emphasizes transactional consistency, and NoSQL, which emphasizes schema flexibility and horizontal scale; replication, which balances read performance with data protection; sharding, which raises write throughput via horizontal partitioning; and the judgment behind performance improvement and relaxed consistency via caching.

Covers choosing between L7 load balancing, which inspects application-layer content to route traffic, and L4 load balancing, which routes quickly at the transport layer; CDN, which distributes content to edge locations; DNS, which handles the hierarchy and redundancy of name resolution; and design judgment for redundant paths and latency optimization during failures.

Covers REST APIs for loosely coupled HTTP-based integration, ETL for extracting, transforming, and loading data across systems, EAI for mediating heterogeneous in-house systems, and the criteria for choosing between synchronous integration (the caller waits for a response) and asynchronous integration (processing continues without waiting).

Covers the trade-offs among big-bang migration (cutting over all at once), phased migration (cutting over in stages by scope), and parallel migration (running old and new side by side for a period), data migration/conversion/verification, a pre-cutover rehearsal and rollback on failure, and the go/no-go decision on whether to proceed with the cutover.

Covers unit testing that verifies individual modules, integration testing that verifies interaction between modules, system testing that verifies the whole system meets business requirements, acceptance testing confirmed by the requester, performance testing that checks response under expected load and load testing that probes the limits, and the reliability growth curve that visualizes whether testing progress is on track.

Covers the sequential waterfall model, iterative development in small increments and its leading form, agile (Scrum), CI (continuous integration) that automates build and test and CD (continuous delivery/deployment) that automates through to release, and the four categories of maintenance by nature: corrective, adaptive, preventive, and perfective maintenance.