45‑Minute Review: Master the Eight Architecture Types for the Soft Exam

Date: 2026‑07‑29 Stage: Phase 2 – Specialized Architecture Goal: Identify the architecture category a business scenario belongs to and compose a combined solution with justification and cost.

Eight Architecture Types

Information‑system architecture

Layered architecture

Cloud‑native architecture

SOA architecture

Embedded‑system architecture

Communication‑system architecture

Security architecture

Big‑data architecture

Compressed Reference

Information‑system – solves enterprise‑level alignment of business, data, applications and technology. Keywords: enterprise, cross‑department, baseline, target, migration. Means: four‑domain architecture (business, data, application, technology), gap analysis, migration roadmap.

Layered – solves responsibility division inside a single application. Keywords: presentation, business, data‑access, MVC, DAO. Means: layered structure, unidirectional dependencies, interface segregation.

Cloud‑native – solves continuous delivery and elastic operation in the cloud. Keywords: elasticity, containers, observability, automation, resilience, zero‑trust. Means: service‑orientation, automated pipelines, health‑checks, circuit‑breaker, tracing.

SOA – solves heterogeneous system integration via stable contracts. Keywords: service, contract, ESB, orchestration, Web Service. Means: service encapsulation, standard interfaces, enterprise service bus, workflow orchestration.

Embedded – solves real‑time control on resource‑constrained dedicated devices. Keywords: real‑time, RTOS, BSP, drivers, HW‑SW co‑operation. Means: hardware abstraction layer, drivers, RTOS task scheduling, watchdog, safe‑state handling.

Communication – solves reliable, timely data transmission across nodes. Keywords: OSI, TCP/UDP, QoS, routing, convergence. Means: protocol layering, reliable transport, redundant links, flow‑control, congestion‑control.

Security – solves identity, permission, data protection and audit. Keywords: CIA, AAA, security zones, zero‑trust, audit. Means: authentication, authorization, encryption, defense‑in‑depth, audit logging.

Big‑data – solves storage and computation of massive, diverse, fast data. Keywords: sharding, replication, batch, stream, storage‑compute separation. Means: distributed storage, horizontal scaling, batch‑stream processing frameworks.

Knowledge Shelves

1. Information‑system Architecture

Focus: business goals, shared data, supporting applications, technology stack, migration from current to target state.

Four domains: business, data, application, technology.

Typical stem: a conglomerate’s subsidiaries have inconsistent processes, duplicate applications, and need a three‑year digital blueprint.

Solution: build baseline and target architectures, perform gap analysis, define a phased migration roadmap.

2. Layered Architecture

Typical layers: presentation, business logic, data‑access, data.

Goals: clear responsibilities, reduced coupling, easier replacement, improved maintainability and testability.

Typical stem: page code concatenates SQL, business rules are scattered in the controller, changing the database impacts many pages.

Solution: separate responsibilities into the four layers, enforce interface‑based dependencies, let the business layer manage transactions.

Correction: merely placing files into Controller/Service/DAO directories does not constitute real layering; responsibilities, dependency direction and transaction scope must be verified.

3. Cloud‑native Architecture

Core capabilities: service‑orientation, elasticity, observability, resilience, full‑process automation, zero‑trust, continuous evolution.

Typical stem: traffic fluctuates sharply; the system needs auto‑scaling, rapid releases, self‑healing, and end‑to‑end request tracing.

Solution: adopt cloud‑native design – elastic scaling, automated CI/CD pipelines, health checks, distributed tracing, and resilience patterns.

Note: using containers, public cloud or Kubernetes alone is an implementation means, not the architecture itself.

4. SOA Architecture

Core concepts: service, interface, contract, loose coupling, service registry & discovery, ESB, orchestration.

Typical stem: ERP, CRM, WMS and partner systems use different protocols; the business needs to reuse capabilities and execute cross‑system processes.

Solution: encapsulate business capabilities as services with standard contracts, use an ESB for protocol conversion and message routing, orchestrate workflows.

Correction: SOA ≠ Web Service; ESB is a common infrastructure, not the entirety of SOA; contracts stabilise calls but do not freeze internal implementations.

5. Embedded‑system Architecture

Characteristics: purpose‑specific, tight HW‑SW coupling, limited CPU/memory/power, emphasis on real‑time, reliability and safety.

Typical structure: hardware → HAL/BSP → drivers → RTOS → middleware & applications.

Typical stem: an automotive brake controller must process sensor signals within a defined deadline and recover automatically on task exception.

Solution: use RTOS scheduling, interrupt mechanisms, watchdog timers, and safe‑state handling to guarantee timeliness and reliability.

Correction: “real‑time” means producing the correct response within the deadline, not merely being fast on average.

6. Communication‑system Architecture

Key issues: data expression, processing entity, destination host, path selection, retransmission policy, slow‑receiver handling, congestion handling, link‑failure switching.

Typical stem: remote‑consultation video shares the network with office traffic; video requires low latency, low jitter, and rapid recovery after link failure.

Solution: select a real‑time‑oriented transport protocol, apply QoS to prioritize video, deploy dual devices/links with fast convergence for high availability.

Correction: flow control avoids overwhelming the receiver; congestion control avoids overwhelming the network; QoS guarantees latency, jitter, loss and bandwidth per business level.

7. Security Architecture

Goals (CIA): confidentiality, integrity, availability.

Access‑control chain (AAA): authentication, authorization, audit.

Typical stem: medical data is sensitive; doctors, patients, operations staff and partners have different permissions; the system must prevent lateral attacks and record all data‑access actions.

Solution: define security zones and trust boundaries, apply least‑privilege, separation of duties, MFA, encryption, auditing, defense‑in‑depth and zero‑trust.

Correction: internal network location is not an identity; zero‑trust requires continuous verification of subject, device, environment and behaviour.

8. Big‑data Architecture

Core issues: massive, diverse, high‑velocity data storage; node‑failure recovery; batch processing of historical data; real‑time stream computation; scalable storage‑compute.

Typical stem: the platform generates billions of logs and device events daily; it must produce next‑day reports and detect anomalies within seconds.

Solution: use distributed storage with sharding and replication; batch processing (e.g., Spark) for historical reports; stream processing (e.g., Flink) for real‑time detection; choose integrated or separated storage‑compute based on load.

Correction: Kafka handles ingestion and buffering, not full stream computation; HDFS provides storage, not indexed queries; specific product names are not architectural reasons.

Key Distinctions

Information‑system vs. Layered : enterprise‑level alignment vs. intra‑application responsibility division.

SOA vs. Cloud‑native : heterogeneous integration vs. elasticity, resilience and continuous delivery in cloud environments.

Embedded vs. Edge computing : device‑internal real‑time control vs. computation placed near the data source for low latency and autonomy.

Communication vs. Security : reliable, timely transmission vs. identity, permission and data protection.

Big‑data vs. Data Warehouse vs. Data Lake : distributed storage/computation vs. cleaned, subject‑oriented analytical data vs. low‑cost raw data storage.

Combined Example – Regional Health Platform

Regional health authority ↓ Business goals, unified standards, migration roadmap → [Information‑system]
↓ Patient/Doctor/Operations portals → Presentation → Business → Data‑access → Data layers → [Layered]
↓ New services (appointment, payment, report, notification) → Elastic scaling, automated release, observability, fault‑recovery → [Cloud‑native]
↓ Service contracts, ESB, orchestration → Connect hospital HIS, LIS, PACS with insurance systems → [SOA]
↓ Bedside devices, wearables, medical terminals → RTOS, drivers, real‑time acquisition, fault‑safe → [Embedded]
↓ Campus network, dedicated network, TCP/UDP, QoS, redundant links → [Communication]
↓ Identity, least‑privilege, encryption, audit, security zones → [Security]
↓ Distributed storage, batch, stream, data lake & warehouse → [Big‑data]

This illustrates that a single complex system can simultaneously employ all eight architectures, each addressing a distinct layer of the problem.

Sample Case‑Analysis Process (Step 1)

Extract problem statements from the stem.

Map each problem to the corresponding architecture.

Mapping example (converted from the original table):

Unify business, master data, application map and technical standards → Information‑system architecture.

Heterogeneous vendor protocols (HIS, LIS, PACS) → SOA.

Mixed presentation, business rules and SQL → Layered architecture.

Peak traffic elasticity, rapid release, full‑link monitoring → Cloud‑native architecture.

Device timing and offline alarm requirement → Embedded‑system architecture.

Video low latency, low jitter, fast recovery after link failure → Communication‑system architecture.

Sensitive data with role‑based permissions and full audit → Security architecture.

Billions of logs, historical reports, real‑time anomaly detection → Big‑data architecture.

Answer Construction (Step 3)

For each identified problem write a “Problem → Solution → Reason” clause. Example for heterogeneous integration:

Problem: Hospital systems use different protocols.
Solution: Encapsulate capabilities as services, define standard contracts, use an ESB for protocol conversion and message routing.
Reason: Isolates vendor interfaces and avoids point‑to‑point coupling.

Repeat the same pattern for the other seven problems.

Why a Single Architecture Is Insufficient

Each architecture addresses a different concern—enterprise planning, application structuring, runtime delivery, system integration, device control, communication reliability, protection, and massive data processing. No single architecture can satisfy all these distinct requirements; a combined approach is necessary.

Typical Costs / Risks

SOA and integration platforms increase service‑governance, interface‑version management and centralized operations cost.

Cloud‑native adds distributed‑call overhead, automation platform, observability tooling and operational capability cost.

Excessive layering may increase call‑chain depth and boilerplate code; improper responsibility separation can cause penetration calls.

Embedded devices face resource limits, HW‑SW co‑debug, upgrade and on‑site maintenance difficulty.

Network redundancy raises equipment, link, configuration and failure‑drill costs.

Strict security controls may impact usability; keys, permissions and audit rules need continuous upkeep.

Big‑data platforms risk data consistency, batch‑stream metric alignment, privacy compliance and high compute cost.

Identification Questions (Sample)

Group needs unified business, master data, application map and technical standards, plus a three‑year migration roadmap.

Presentation layer directly accesses the database; business rules are scattered; the system is hard to maintain and test.

Large‑scale traffic fluctuation requires auto‑scaling, auto‑release and full‑link monitoring.

ERP, CRM, WMS and partner systems have different protocols; reuse of services and cross‑system processes are required.

Automotive controller has limited resources and must execute brake tasks within a fixed deadline.

Video conference needs low latency, low jitter and rapid recovery after link failure.

Medical system must verify identity, restrict permissions, encrypt data and audit all accesses.

Platform generates billions of events daily; needs historical statistics and second‑level anomaly detection.

Corresponding architectures:

Information‑system architecture

Layered architecture

Cloud‑native architecture

SOA architecture

Embedded‑system architecture

Communication‑system architecture

Security architecture

Big‑data architecture

Core Memorisation

Information‑system: align business, data, applications, technology.
Layered: separate responsibilities, control dependencies.
Cloud‑native: elasticity, resilience, observability, automation.
SOA: service contracts, heterogeneous integration, process orchestration.
Embedded: resource‑constrained, real‑time control, HW‑SW co‑operation.
Communication: layered transport, QoS, redundancy.
Security: CIA, AAA, defense‑in‑depth, zero‑trust.
Big‑data: sharding, replication, batch‑stream processing, horizontal scaling.

These eight verbs—align, layer, elastify, integrate, control, transmit, protect, compute—summarise the purpose of each architecture.