SDA Study Guide (Based of the 7 slides)

Lesson 1: The Core of Software Architecture

Software Architecture is defined as the fundamental organization of a system,
embodied in its structural elements, their relationships to each other and to the
environment, and the principles governing its design and evolution. It focuses on the
highest-level, most significant decisions that are the hardest and most costly to change
once implementation begins.

Key Components of Architecture

1. Elements (Structural Blocks): These are the major, reusable building blocks of
the system. Think of them as the primary services or modules.

 Example: In an e-commerce platform, the elements would be the

Inventory Service, the Checkout Service, the Customer Database, and
the User Interface (UI) Layer.

2. Relationships (Connectors): These define the interactions and communication

rules between elements. A relationship dictates the technology and protocol used.

 Example: The Checkout Service has a relationship with the Payment

Gateway, defined by a REST API call or a Message Queue connection.
This is a critical architectural choice affecting speed and reliability.

3. Principles (Guiding Rules): These are the overarching, high-level design

decisions and assumptions that guide all subsequent, low-level choices.

 Example: A principle might be "All services must be designed to be

stateless," meaning no critical data is stored locally within a service. This
principle dictates how sessions are managed and directly improves the
system's Scalability and Availability.

The Nature of Architectural Decisions (ADs)

A decision is considered Architecturally Significant if it profoundly affects the

system's entire structure, requires coordination across multiple teams, and is costly or
difficult to reverse.

 Example of an AD: Deciding to use a Microservice Style for the application

(affects every team, component, and deployment strategy).

 Example of a Non-AD: Deciding on the specific code formatting conventions

within a single module (a low-level implementation detail).
Lesson 2: Architectural Concerns (Quality
Attributes)
Architectural Concerns, often called Quality Attributes (QAs), are the non-
functional requirements that describe how well the system performs in specific
areas. When these are critical, they become Architecturally Significant
Requirements (ASRs) the primary drivers of the design.

Core Quality Attributes

Quality Attribute
Detailed Focus Impact
(QA)
The system's operational
Design tactics like redundancy
uptime, or the probability
(having multiple servers ready) and
that it is running and ready
Availability failover (switching instantly to a
for use when needed.
backup system) are applied to
Measured in "nines" (e.g.,
achieve this.
99.999%).
The ease and cost of making
changes, including bug The Decoupling of components
fixes, updates, or adding (making them independent) is the
Modifiability
new features. High primary tactic. High Modifiability is
Modifiability means changes the opposite of high Coupling.
are localized.
The system's responsiveness
Tactics include Load Balancing
(latency) and throughput
(distributing requests) and Caching
Performance (capacity). It is concerned
(storing frequently accessed data
with timing and resource
closer to the user).
consumption.
The system's ability to
Tactics involve layered defenses
protect its assets (data, code,
like authentication (who you are),
Security services) from unauthorized
authorization (what you can do),
access, modification, or
and encryption (scrambling data).
denial of service.
The constraints on the
budget for development, Often forces a trade-off against
deployment Availability or Performance (e.g.,
Affordability/Cost
(hardware/cloud), and choosing cheaper, less powerful
maintenance over the servers).
system's lifetime.
Driven by modern practices like
The ease and speed with Continuous
Agility / which the system can be Integration/Continuous
Deployability built, tested, and released Deployment (CI/CD), which favors
into production. smaller, independently deployable
units.
The Trade-off Analysis (The Heart of Architecture)

The most important task for an architect is managing trade-offs because QAs almost
always conflict. A decision that maximizes one QA often degrades another.

 Example: To maximize Security, an architect might require complex data

encryption before every database write. This added computational step
directly increases Latency, thus lowering Performance. The architect must
decide which ASR (Security or Performance) has priority in that specific
context.

Lesson 3: Software Architecture Views

Since no single diagram can satisfy every stakeholder, a complete architecture is
documented using specialized Architecture Views. A view focuses on a subset of the
system's elements and relationships to address a specific set of stakeholder concerns.

The 4+1 View Model (Kruchten's Model)

This model organizes the architectural description into four views, driven by
scenarios.

Primary Concern
View Focus Area Elements Depicted
Addressed
Functional Structure:
How the system is Major services,
1. Logical decomposed into abstract modules, APIs, and Functionality,
View components, classes, and their functional Maintainability.
modules to satisfy user dependencies.
functions.
Concurrency and
Execution: How the system Active components,
Performance,
executes at runtime, thread pools,
2. Process Concurrency,
showing parallel processes, messaging queues,
View Deadlock
threads, and how they and synchronization
Avoidance.
communicate and mechanisms.
synchronize.
Implementation
Structure: How the code is
Implementation
organized for the Modifiability,
3. units, source folders,
development team source System
Development version control
code organization, library Buildability,
View repository structure,
dependencies, build Reuse.
and build scripts.
structure, and configuration
files.
4. Physical Deployment Topology: Physical servers, load Availability,
View The mapping of software balancers, firewalls, Scalability,
elements onto hardware network links, and Disaster Recovery.
 Primary Concern
View Focus Area Elements Depicted
Addressed
nodes (servers, VMs, cloud
clustered databases.
regions, network topology).

The +1: Scenarios

Scenarios (like "A power outage occurs in Region A" or "The user adds 50 items to
the cart") are used to drive the design (Analysis) and validate the final architecture
(Evaluation) across all four views, ensuring they are consistent.

Use Case: Views in Cloud Migration

A company moving from on-premise servers to the cloud:

 The Logical View remains mostly the same (the functions of the services
don't change).

 The Physical View changes drastically, replacing physical servers with cloud
services (like EC2 instances and managed databases). The new physical view
is critical for the DevOps team to implement the new infrastructure.

 The Development View may change to include new dependencies on cloud

SDKs and specialized deployment pipelines (CI/CD tools).

Lesson 4: Architectural Styles and Patterns

Architectural Styles and Patterns are proven, reusable organizational templates that
simplify design by providing pre-defined structures and rules for component
interaction. They are mechanisms for reusing recommended solutions.

Styles vs. Patterns vs. Reference Architectures

 Architectural Style: A system-wide template that defines the overall

organization and constrains the element relationships (e.g., Layered Style,
Microservice Style).

 Architectural Pattern: A solution to a localized, recurring problem, often

applying only within a subsystem (e.g., Model-View-Controller (MVC)
pattern for UI design).

 Reference Architecture (RA): An architecture that guides or constrains

other architectures, typically within a specific industry or domain (e.g.,
 TOGAF for Enterprise Architecture, or AUTOSAR for the automotive
industry).

Key Architectural Styles in Detail

1. Layered Style (Multi-Tier)

 Structure: Components are organized into horizontal layers (e.g.,

Presentation, Business Logic, Persistence).

 Key Constraint: Communication is often restricted to adjacent layers (e.g.,

Presentation calls Business Logic, which calls Persistence).

 Best for: Small-to-medium-sized applications with stable requirements and

strong focus on Maintainability and Testability.

 Example: A traditional enterprise ERP (Enterprise Resource Planning)

system where data security and organized isolation of business rules are
paramount.

2. Microservice Architecture Style (MSA)

 Structure: The application is a collection of small, independently deployable

services, organized around business capabilities. Each service runs in its own
process and owns its own data store.

 Key Constraint: Services communicate via lightweight protocols (APIs or

messaging), treating other services as black boxes.

 Best for: Large, highly complex systems with extreme requirements for
Agility, Scalability, and Availability.

 Example: A large streaming service like Netflix, where the Recommendation

Service can be updated and scaled independently of the Billing Service.

3. Publish-Subscribe Style
  Structure: Components (subscribers) register interest in specific events
(topics) and are notified by a message broker when a publisher sends a
message to that topic.

 Best for: Decoupling components where events need to be broadcast to many

unknown consumers asynchronously.

 Example: A banking system where the Deposit Service (publisher) sends a

"New Transaction" event to a message queue, and the Fraud Detection Service,
the Notification Service, and the Audit Log Service (subscribers) all react to the
event without the deposit service knowing they exist.

Lesson 5: ADL, Frameworks, and Decisions

Formalizing the Architecture

1. Architecture Description Language (ADL)

An ADL is a domain-specific language designed to express software architectures

formally.

 Purpose: To describe the components, connectors, and configurations with

high precision, removing ambiguity and enabling machine analysis.

 UML: While not strictly an ADL, the Unified Modeling Language (UML)
is widely used in architecture activities (e.g., using Component Diagrams or
Deployment Diagrams) and often serves as a primary description mechanism.

 Advanced ADLs: Some ADLs are capable of generating analysis reports

(checking for deadlocks or performance bottlenecks) or even generating
skeletal code based on the structural description.

2. Architecture Framework (AF)

An AF captures the conventions, principles, and practices for describing and

managing architectures within a specific community or domain.

Example: TOGAF (The Open Group Architecture Framework) provides a

comprehensive, structured approach for developing and managing an Enterprise
Architecture, guiding all IT decisions across an entire organization, not just a
single system.

Architecture as Significant Decisions (ASDs)

Architecture design is a creative process of making decisions that profoundly affect
the entire system. Documenting these decisions is crucial.

1. Architecture Rationale

The Architecture Rationale is the documented explanation of why a specific

Architectural Decision (AD) was made. It provides the essential context and
justification.

 Key Content:

ASR Addressed: The specific requirement that drove the choice.

Alternatives Considered: The other options that were rejected.

Trade-offs/Criteria: The specific metrics or principles used to select the final

option (e.g., "Performance was prioritized over Modifiability").

Benefit: It protects the system from arbitrary future changes by ensuring that any
new team understands the constraints under which the original design was
created.

2. Architectural Technical Debt (ATD)

ATD reflects a design choice that is sub-optimal but accepted for short-term gain
(e.g., to meet a tight deadline). This incurs a future, often much higher, cost for
correction.

Example: An architect implements a quick, insecure file transfer protocol to ship

the initial product. The ATD is the future cost of refactoring the entire file system
to a secure, encrypted protocol, which may take months of effort and introduce
high risk.

Lesson 6: The Software Architecture Process

Architectural design is an iterative cycle where the architect constantly refines the
design based on analysis and testing. The process comprises three major activities:
Analysis, Synthesis, and Evaluation.

The Three-Phase Cycle

1. Architecture Analysis (Discovery):

 Goal: To rigorously gather and formulate the ASRs and understand the
constraints (context) of the system.
 Output: The definitive list of system-wide decisions and guiding principles (e.g.,
"The system must operate entirely within the EU cloud region for data
compliance").

2. Architecture Synthesis (Design):

 Goal: To develop concrete solutions selecting styles, patterns, components, and

tactics to satisfy the ASRs identified in Analysis.

 Core Task: Trade-off Resolution. Finding the optimal balance point between
competing ASRs (e.g., choosing a slower, layered structure over a faster,
monolithic one to achieve better Modifiability).

3. Architecture Evaluation (Verification):

 Goal: To validate whether the designed solutions truly satisfy the ASRs.

 Action: Identifying gaps, risks, and necessary rework. (If the design fails the
evaluation, the architect returns to Synthesis to adjust the design.)

Architecting Methods and Tactics

 Architecting Method: A high-level, structured procedure that guides the overall

design process. (Example: Attribute-Driven Design (ADD), which explicitly
chooses architectural styles and makes design decisions based on prioritizing the
highest-impact quality attributes).

 Architectural Tactics: Low-level, reusable design techniques that address a

single quality attribute goal. These are the building blocks of the Synthesis phase.

Example: The Monitoring tactic is used to achieve the Modifiability ASR by

ensuring changes can be detected quickly. The Active Redundancy tactic is used to
achieve the Availability ASR by having multiple working copies of a component
ready to take over.

Lesson 7: Software Architecture Evaluation

Architecture Evaluation is the final, disciplined process of assessing the
architecture's "goodness" and verifying its conformance to the ASRs before
committing to expensive implementation. The key focus is the analysis of trade-offs.
The Four Questions of 'Goodness'

Evaluation seeks to answer these core questions about the documented architecture:

1. Fitness for Use: Does the architecture satisfy all functional and quality
requirements (ASRs)?

2. Robustness and Evolution: Is it stable and capable of accommodating expected

future changes and growth?

3. Feasibility: Is it technically and financially possible (cost-effective) to construct

and operate the system based on this architecture?

4. Clarity: Is the architecture clear, understandable, and consistent across all views
for the development and maintenance teams?

Formal Evaluation Methods

These structured methods provide rigor to the evaluation process:

1. ATAM (Architecture Tradeoff Analysis Method): The industry standard for

identifying and analyzing risks and trade-offs. ATAM uses a structured process of
eliciting and analyzing scenarios (high-risk use cases) to expose the inherent
compromises in the design.

2. SAAM (Software Architecture Analysis Method): An earlier method focused

primarily on analyzing the architecture's modifiability and how well it supports
expected use cases.

3. Active Reviews: A review where reviewers use guiding questions or checklists to

systematically look for specific design errors in the documentation, such as
inconsistencies (conflicts between views) or ambiguities (unclear descriptions).

Architecture Metrics and Reasoning

Evaluation also relies on quantitative and qualitative measures to assess specific

properties.
Metric Definition Impact on QA
The degree of interdependence
Goal: Minimize. High coupling
between components. High coupling
Coupling severely reduces Modifiability and
means a change in one component
Deployability.
requires changes in many others.
The degree to which the elements Goal: Maximize. High cohesion
inside a component belong together improves Maintainability and
Cohesion
(i.e., they are highly related in testability because the component
function). has a single, clear purpose.

Use Case: Measuring Coupling

In a Microservice system, the evaluation team discovers that the Product Catalog Service
(PCS) directly calls the internal database of the User Profile Service (UPS) to get user
preferences.

 Finding: This represents high coupling between the PCS and UPS
implementation details.

 Evaluation Recommendation: The architect must redesign the relationship,

forcing the PCS to only call the official API of the UPS. This decouples the two
services, ensuring that the UPS team can change its internal database schema
without breaking the PCS thereby preserving high Modifiability and Autonomy.