Architecture Design and Evaluation 1

Main ideas and lessons

• Purpose of the course (Class 1)

  • The course studies how to design software architecture and how to evaluate software architectures, assuming students already know object-oriented analysis and design.
  • The first class focuses on:
    • Understanding what software architecture is
    • Understanding design principles and evaluation/architecture tactics
    • Understanding representative architectures (examples)

• Why “architecture” matters beyond object-oriented design

  • Object-oriented analysis/design starts from use cases and functional requirements, producing structures and behaviors.
  • A purely functional approach that aggregates per–use case interaction analyses can scale, but tends to produce poor architectures:
    • Dirty/low-quality packaging
    • Complicated message passing
    • Hard mapping to the technical stack
    • Monolithic structures
    • Poor quality attributes
  • Key lesson: Early architecture design must produce good decomposition and quality attributes, not just “aggregate correctness.”

• Ideal architecture decomposition

  • The “ideal” target is that the whole software is decomposed into logical components (not just implementation-level modules).
  • These logical components communicate via interfaces, enabling:
    • Extensibility and substitution (swap implementations)
    • Choosing appropriate technical stacks per component
    • Localization of impact (changes in one component don’t ripple everywhere)
  • Architecture should embody design decisions about overall structure/behavior.

Methodology / conceptual steps (architecture design & evaluation workflow)

• Define and document requirements

  • Understand functional requirements from use cases (from earlier course content).
  • Then ensure architecture supports quality requirements (quality attributes).

• Use architecture modeling before implementation

  • Create architecture models representing design decisions.
  • Apply analysis to the model before coding:
    • Consistency checking
    • Performance checking
    • Architecture pattern quality verification
  • Benefit: identify risks/problems before implementation, supporting management decisions and better change-cost prediction.

• Implement and test against the architecture

  • After architecture is defined, implementation must be built so that:
    • The implementation conforms to the architecture
    • Tests check whether it satisfies the architectural intent and requirements.

Definitions and core concepts

• ISO/IEC/IEEE 42010 definition (source of the course’s architecture definition)

  • Software architecture is a fundamental concept describing:
    • Properties of a system in its environment
    • Elements and their relationships
    • Principles behind design and evolution
  • Architecture is also tied to design decisions about system structure and behavior and helps represent/justify how those decisions satisfy requirements and evolution.

• Architecture and evolution

  • Architecture supports evolution (e.g., adding new services/devices/functions) with concrete steps rather than vague guidance.
  • Evolution should allow:
    • Reduced change cost
    • Better prediction of change impact
    • Easier management of modifications

Examples of representative architectures (Netflix, AWS, Microsoft / IoT)

• Netflix representative architecture (web + microservices)

  • Structure described at a high level:
    • Edge service layer
      • Web/API gateways (handle request/response types)
      • Streaming/API services (handle video streaming types/APIs)
    • Mid-tier service layer
      • Implemented as microservices
      • Many internal service types (described as 600+)
      • Each functionality as a microservice enabling independent deployment and scaling
    • Communication styles:
      • Edge ↔ mid-tier and mid-tier ↔ services using service registry and messaging (mentions lists/queues such as S3/SQS-like components)
  • Lesson: Microservices support modifiability and evolution by minimizing propagated changes.

• AWS cloud architecture pattern example: availability zones for robustness

  • Uses design guidance to improve robustness/availability.
  • Example mechanism:
    • Deploy systems across multiple availability zones
    • Use load balancing to dispatch requests
    • Survive data-center-level failures because systems remain running in other zones
  • Lesson: Architecture patterns help implement resilience and availability goals.

• Microsoft reference architecture example: IoT system

  • Three core “subsystems/components” and their roles:
    • Sensing / Data generation
      • IoT devices collect raw data (e.g., engine pressure/temperature)
    • Stream processing + storage (as needed)
      • Data goes to processing for real-time insights or to storage for later use
    • Business integration + actions + UI/reporting
      • Insights drive business decisions (e.g., adaptive maintenance scheduling)
      • UI/reporting tools visualize device status
  • Notes:
    • Select only needed components (e.g., if no streaming processing is needed, skip that part).
    • Architecture can be implemented via Azure-like cloud services or other infrastructures.

“Six laws” and architecture-related rationale (as stated in the subtitles)

The subtitles claim there are six laws of software architecture, including roles such as:

• Supporting understanding
• Defining upper-level design constructs (e.g., new services/devices in Netflix)
• Enabling reuse and simulation/reuse based on architecture blueprinting
• Providing steps for evolution
• Enabling analysis on architecture models (quality, consistency, performance, pattern verification)
• Identifying risks before implementation, especially when systems become complex (smart IoT, AI systems, heterogeneous technologies)

SOLID design principles (explained via cohesion/coupling intuition)

• Coupling and cohesion

  • Coupling: degree of independence between modules
  • Cohesion: degree to which elements within a module fit together
  • Goal: high cohesion, low coupling for maintainability.

• Mapping SOLID principles to coupling/cohesion

  • Single Responsibility Principle (SRP) → increases cohesion within a module/class
  • Interface Segregation Principle (ISP) → reduces coupling between modules
  • Open/Closed Principle (OCP) and Liskov Substitution Principle (LSP) → relate to risks of substitution and extension without modifying clients

• Concrete explanations/examples given

  • SRP example: a rectangle class should change only for separate reasons:
    • Changes to drawing/geometry vs computation geometry.
  • Dependency Inversion Principle (DIP) example: lower layers should not force upper layers to depend on concrete implementations; instead depend on abstractions via interfaces.
  • ISP example: clients shouldn’t depend on interfaces they don’t use (e.g., copy client vs multifunction printer).
  • OCP example: server changes shouldn’t directly affect clients; clients depend on stable interfaces.
  • LSP/substitution risk example:
    • If a Square is a subtype of Rectangle, passing it where Rectangle is expected can break behavior (width/height constraints conflict with rectangle assumptions).
    • Lesson: Subtypes must be substitutable without violating expected behavior.

Design techniques: patterns and tactics

• Software patterns

  • Reusable solutions to recurring problems.
  • Documented with:
    • Purpose
    • Context
    • Problem
    • Solution
    • Impact
  • Types mentioned:
    • Architecture patterns (focus on architecture design)
    • Reference architectures (often domain-specialized; easier to apply than generic patterns)

• Architecture example catalogs

  • Reference catalogs from well-known industry sources are mentioned (e.g., IBM patterns, AWS cloud patterns, Google cloud patterns, Microsoft patterns, etc.).

• Architecture tactics

  • More fundamental than patterns.
  • Often specified as tactics that help achieve quality attributes.
  • Organized in catalogs by quality attribute, with subcategories and concrete tactics.
  • Examples described for availability:
    • Fault detection tactics (e.g., monitoring, exception detection, ping/ICMP-based reachability checks)
    • Fault recovery tactics (e.g., state resynchronization, restart/repair, reintroduction/rollforward)
  • Also mentions:
    • Tactics catalogs for performance, security, robustness, usability, and domain-specific cases (e.g., big-data cyber security analysis).

Overall takeaways (what students should remember)

• Don’t just aggregate per-use-case designs into a “big structure”; that often yields poor quality attributes.
• Create architecture models before implementation to analyze consistency, performance, and pattern correctness.
• Architecture should support evolution with clear steps and manageable change impact.
• Use principles (SOLID, cohesion/coupling, substitution correctness) to help achieve better modularity.
• Use established knowledge:
  • Architecture patterns and reference architectures for structure decisions
  • Architecture tactics for quality-attribute goals

Speakers / sources featured (as explicitly referenced)

• ISO/IEC/IEEE 42010 (named standard for the architecture definition)
• Netflix (example architecture)
• Amazon Web Services (AWS) (cloud patterns and resilience example)
• Microsoft (IoT reference architecture example)
• CMU (tactics catalog is mentioned)
• IBM (architecture patterns are mentioned)
• Google (cloud/machine-learning architecture design patterns are mentioned)
• AWS (general “AmazonWebServices”) and AWS services such as load balancer / availability zones are referenced (no specific person named)