LearningTree

Methods for Architecture
Development

A complete reference covering iterative & incremental design, view-based architecture development, and top-down vs. bottom-up architecture approaches.

01
Chapter One · Architecture Methods

Iterative and Incremental Architecture Development

Architectural design is not a one-time task — changes and adaptations are necessary throughout the project. Early and continuous feedback is essential to avoid costly late-stage redesign.

🔁

Iterative

  • Repeat the same steps in cycles — refine each pass
📈

Incremental

  • Deliver working slices — smaller steps, lower risk
💬

Continuous Feedback

  • Stakeholders, context & customers feed every iteration
Traditional: Waterfall / V-Model
Characteristics
  • Next phase starts only when previous is fully completed
  • The entire team works on the same phase at a time
  • No feedback until all phases are complete
  • High cost of late changes — problems found at testing are expensive
Waterfall Flow — Sequential Phases
01 Requirements Define what to build 02 Design Plan how to build it 03 Implementation Actually build it 04 Testing Verify it works 05 Maintenance Keep it running ⚠ One-way flow — no feedback until the end
Problem: In real projects requirements change. A fully sequential approach means feedback only arrives after all work is done — making changes extremely costly.
Agile Software Development
Agile Principles
  • Early and frequent delivery — working software sooner
  • Close cooperation with customers throughout
  • Embraces changing requirements — even late in development
  • Simplicity — maximizing the work not done
  • Continuous improvement within the development process
Agile Cycle — Continuous Loop
AGILE SPRINT ↺ iterative 01 Planning 02 Design 03 Defining 04 Testing 05 Deploy 06 Feedback Each sprint 1–4 weeks · loop continues until done
Why Agile is better for architecture: Agile allows architectural decisions to be validated earlier, adapted as requirements evolve, and refined continuously — avoiding the high cost of late discovery.
Waterfall vs Agile — Comparison
DimensionWaterfall / V-ModelAgile
PhasesSequential, one at a timeIterative cycles (sprints)
RequirementsFixed upfrontEvolving and embraced
FeedbackOnly at the endEarly and continuous
Change CostVery high if lateLower — built-in adaptability
Customer InvolvementMostly at start and endThroughout the project
RiskProblems discovered lateRisks surfaced early
Iterative and Incremental Design
Iterative
  • Doing the same steps repeatedly in cycles
  • Each cycle refines and improves the previous result
  • Enables continuous feedback and course correction
Incremental
  • Multiple smaller steps rather than one giant leap
  • Each increment delivers a partial but working solution
  • Reduces complexity through smaller focus per iteration
  • Risk is reduced — partial solutions are testable and deliverable
What drives Architecture Design — Feedback Relationships
influences changes changes changes changes Influencing factors Requirements Architecture design Context & stakeholders Customer
All four inputs feed into architecture design. Influencing factors shape Requirements; both, along with Context & stakeholders and Customer feedback, drive and continuously change the architecture — making iteration essential.
Benefits of Iterative & Incremental
Reduces Risk
  • Issues discovered early in small iterations
  • No big-bang integration failure at the end
Provides Early Feedback
  • Stakeholders see working results sooner
  • Architecture validated against real requirements
Better Quality
  • Continuous improvement built into each cycle
  • Influencing factors, requirements & customer feedback feed back into each design iteration
📋 Chapter 1 — Summary
  • Architecture development draws from Agile: small, iterative cycles reduce risk and surface feedback early
  • Waterfall: sequential, high late-change cost, no feedback until end
  • Agile: iterative, embraces change, early and continuous feedback
  • Iterative: same steps refined each cycle — enables continuous course correction
  • Incremental: smaller steps, partial but working solutions delivered progressively
  • Architecture design is not a one-time task — it evolves with requirements and feedback
  • Continuous feedback from influencing factors, requirements, context & customers → better quality outcomes
02
Chapter Two · Architecture Methods

View-Based Architecture Development

"Views are projections of the software architecture" — each view represents the system from a specific perspective, emphasising certain aspects while omitting others to manage complexity.

🌐

Context View

  • System as a black box — external actors, interfaces & protocols
🏗️

Building Block View

  • Static decomposition — components, layers, dependencies
⚡

Runtime View

  • Dynamic behaviour — interactions, processes, sequence flows
🖥️

Deployment View

  • Infrastructure mapping — servers, containers, network topology
DEPLOYMENT VIEW RUNTIME VIEW BUILDING-BLOCK VIEW CONTEXT VIEW same system, 4 perspectives 🧑 Stakeholder Dev · Architect · DevOps · PM VIEWS 👁
What Is an Architecture View?
Definition
  • A representation of a system from a specific perspective/viewpoint
  • Each view has its own, individual focus
  • Certain aspects are emphasised; others are intentionally omitted
  • Specialisation of views → better handling of complexity
Key Rules for Views
  • Views are not entirely independent — some information may appear in multiple views
  • Views must be consistent — they must not contradict each other
  • Together, views provide a complete picture of the architecture
iSAQB Architecture Views — The Four Views
iSAQB ARCHITECTURE VIEWS Context View · context demarcation — High-level view — Interfaces — System as a black box — External actors & systems — Communication protocols Runtime View · dynamic behaviour — Interactions between blocks — Performance & synchronisation — Processes & threads — Lifecycle of instances — System startup & shutdown Building-Block View · static structure — Building blocks & layers — Interfaces & dependencies — Relations & responsibilities — Static decomposition — Packages, classes, modules Deployment View · infrastructure — Deployment units — Nodes & computers — Processes & networks — Hardware & containers — Availability & capacity Architecture all views combined ◈ consistent

Views must not contradict each other  ·  Together they give a complete picture of the architecture

🌐
Context View
  • System depicted as a black box
  • Shows all external actors (systems, users)
  • All interfaces to the outside world
  • Interface type (network, batch, USB, file…)
  • Communication protocols (HTTP, WebSockets…)
  • Communication patterns (sync/async, push/pull…)
  • Overview of most important use cases from external perspective
System «black box» User actor Ext API system DB HTTP REST JDBC
🧱
Building-Block View
  • Describes static decomposition of the system into building blocks
  • Libraries, sub-systems, partitions, packages, classes, functions
  • Describes relationships between building blocks
  • Interfaces, dependencies, associations, inheritance
  • Helps developers understand the system
  • Supports project management with work package definition
«system» UI Layer «module» Service «module» Data «module» Auth Cache uses
⚡
Runtime View
  • Describes interactions between building blocks at runtime
  • How system components interact during execution of a use case
  • Includes processes and threads
  • How the system starts and terminates
  • Building block instance lifecycles at runtime
  • Helps developers & operations understand runtime behaviour
Client Service DB request() query() result response
🚀
Deployment View
  • Deployment of runtime elements (apps, Docker containers, libraries) to hardware components
  • Servers, hosts, virtual machines
  • Logical & physical channels between components
  • Technical components: databases, servers, storage devices
  • Runtime attributes: availability, capacity of networks and memory
  • Helps DevOps/SREs manage environments, spot bottlenecks & risks
Web Server «app» frontend «app» backend DB Server «db» PostgreSQL port 5432 TCP/IP Internet / CDN HTTPS
Relevance of Each View — Audience
ViewPrimary AudienceKey PurposeCommon Diagram
ContextAll stakeholders, PMs, clientsSystem scope, external interfaces, use casesContext Diagram
Building-BlockDevelopers, architects, PMsStatic structure, components, dependenciesComponent / Class Diagram (UML)
RuntimeDevelopers, operationsDynamic interactions, use-case flowsSequence / Activity Diagram (UML)
DeploymentDevOps, SREs, operationsInfrastructure mapping, bottlenecks, costsDeployment Diagram (UML)
Other View Models — Industry Context
Notable Approaches
  • Kruchten (4+1): Logical, Process, Development, Physical + Scenarios
  • Hofmeister et al.: Conceptual, Module, Execution, Code View
  • Clements et al.: Module, Component & Connector, Allocation View
  • C4 (Simon Brown): Context, Container, Component, Code
  • iSAQB: Context, Building-Block, Runtime, Deployment
C4 Model — Simon Brown
  • Context — system in its environment
  • Container — apps, data stores, microservices
  • Component — components inside a container
  • Code — UML class diagrams
  • Reference: c4model.com
Example — Mobile Fitness App: All Four Views

The same Mobile Fitness App is examined through each of the four iSAQB views. Each view targets a different stakeholder audience and captures a different dimension of the system — together they provide a complete, non-contradicting picture.

🌍
View 1 — Context View

The system as a black box. Shows external actors, systems, and the interfaces/protocols that cross the system boundary. Audience: all stakeholders, PMs, clients.

System Boundary & External Interfaces
  • Mobile App (iOS/Android) — the system under development
  • User — initiates workouts, views history, sets goals
  • HealthKit / Google Fit — reads sensor & health data (OAuth2)
  • Push Notification Service (APNs / FCM) — delivers alerts
  • OAuth2 Provider (Google/Apple Sign-In) — authentication
  • Analytics Backend — receives anonymised usage events (HTTPS)
  • All external calls use HTTPS / REST; background sync via WebSockets
Fitness App «system» iOS / Android User HealthKit / Google Fit OAuth2 APNs / FCM Push Service HTTPS OAuth2 Provider OAuth2 Analytics Backend HTTPS System boundary (solid box) separates internal from external
🧱
View 2 — Building-Block View

Static decomposition of the system: components, modules, interfaces, and their dependencies. Answers "what are the parts and how are they connected?" Audience: developers, architects.

Internal Building Blocks & Responsibilities
  • UI Layer — screens, navigation, state management (React Native / Swift)
  • Activity Module — records workouts, calculates stats, manages goals
  • User Module — profile, preferences, social graph
  • Sync Module — offline queue, conflict resolution, background sync
  • Notification Module — goal reminders, achievement badges, coach tips
  • Analytics Module — session tracking, funnel events, crash reports
  • Dependencies flow UI → Activity / User → Sync → Notification
«system» Fitness App UI Layer React Native / Swift Activity «module» User «module» Analytics «module» Sync «module» Notification «module» uses uses tracks
⚡
View 3 — Runtime View

Dynamic interactions between building blocks at runtime for a specific use case. Answers "what happens step-by-step when X occurs?" Audience: developers, operations.

Use Case: Record a Workout
  • User taps "Start Workout" → UI Layer starts session timer
  • UI Layer → Activity Module: startSession(type, timestamp)
  • Activity Module → HealthKit: read heart rate & GPS data (streaming)
  • User taps "Stop" → Activity Module: finaliseSession(stats)
  • Activity Module → Sync Module: enqueueUpload(sessionData)
  • Sync Module → Backend API: POST /sessions (HTTPS)
  • Backend API → Activity Module (callback): achievement unlocked?
  • Notification Module → APNs/FCM: push "🏆 New Personal Best!" badge
UI Activity Sync Notify API startSession() readSensors() HR, GPS stream finalise(stats) enqueueUpload() POST /sessions 201 + achievement sendPush(badge) 🏆 Personal Best!
🚀
View 4 — Deployment View

Maps runtime artifacts onto physical/virtual infrastructure: servers, containers, cloud regions, networks. Answers "where does everything run and how does it connect?" Audience: DevOps, SREs, ops team.

Infrastructure Nodes & Deployment Decisions
  • User Device (iOS/Android) — runs the compiled app artifact
  • CDN — serves static assets (icons, ML models) globally, low latency
  • API Gateway (AWS ALB / Kong) — TLS termination, rate limiting, auth
  • App Server cluster — 2+ Docker containers (ECS/K8s), auto-scaling, stateless
  • PostgreSQL cluster (primary + 1 read replica) — user & activity data, ACID
  • Redis cache — session tokens, leaderboard aggregations, TTL-based
  • APNs / FCM — external push delivery, fire-and-forget
  • All inter-node communication within private VPC; only API Gateway is public-facing
User Device «app» FitnessApp iOS / Android CDN «node» CloudFront static assets API Gateway AWS ALB / Kong TLS · rate-limit · auth App Servers Container 1 Container 2 ECS / K8s · auto-scale PostgreSQL Primary + Replica RDS Multi-AZ Redis Cache sessions · leaderboard APNs / FCM External Push fire-and-forget HTTPS HTTPS TCP HTTPS Private VPC
Cross-view consistency check: The Activity Module from the Building-Block View becomes the Activity service container in the Deployment View, and its finaliseSession() call appears as the sequence step in the Runtime View — all three describe the same element from different angles. The Context View's APNs/FCM external system reappears as a deployment node in the Deployment View and as the last message in the Runtime View sequence.
📋 Chapter 2 — Summary
  • View = representation of the system from a specific perspective — certain aspects emphasised, others omitted
  • Views must be consistent — they must not contradict each other
  • Context View: system as black box, external actors, interfaces, communication protocols
  • Building-Block View: static structure — components, packages, classes, dependencies
  • Runtime View: dynamic interactions — processes, threads, use-case flows at execution
  • Deployment View: infrastructure mapping — servers, containers, networks, availability
  • Other models: C4 (Simon Brown), 4+1 (Kruchten), Hofmeister, Clements
  • Together, views provide a complete, non-contradicting picture of the architecture
03
Chapter Three · Architecture Methods

Top-Down vs. Bottom-Up Architecture Development

Architecture can be developed from the big picture down (Top-Down) or from existing components up (Bottom-Up). In practice, most projects use a combination of both.

⬇️

Top-Down

  • Start from high-level requirements & decompose into components step by step
⬆️

Bottom-Up

  • Start from existing components, libraries & patterns — compose upward
Approach Overview
Top-Down
  • Starting point: Vision of the complete system
  • Decomposition into smaller sub-problems (analysis)
  • Refine from black-box system → white-box components → detailed design
  • Consistency and clean-cut interfaces from the start
  • General understanding of the problem before implementation
Bottom-Up
  • Starting point: Existing components, libraries, solutions
  • Composition — building larger systems from parts
  • Typically reuses existing components from vendors or internal R&D
  • Beneficial when components are innovative and require R&D
  • Good when different vendors develop those components
TOP-DOWN System Vision «black box» — entire system as one unit decompose ↓ Sub-system A Sub-system B Module A1 Module A2 Module B1 Module B2 Cls A Cls B Cls C Cls D Cls E Cls F Cls G Cls H L0 L1 L2 L3 ⬇ Decomposition Coarse → Fine Start: system vision Best for: greenfield · clear requirements vs. BOTTOM-UP Existing Components / Vendor Parts SDK A Lib B API C Mod D Module X Module Y Composed Sub-System compose ↑ Final System architecture emerges from integration ⬆ Composition Fine → Coarse Start: existing components Best for: R&D · IoT · vendor parts

Top-down decomposes a vision into detail  ·  Bottom-up composes detail into a system  ·  Most projects combine both

Top-Down Approach — Step by Step
Example — Rideshare System  ·  Start from the complete system vision and decompose progressively until every building block is small enough to implement independently.
STEP 1 · LEVEL 0
System Vision
Define the Rideshare System as a single black box. Capture stakeholder goals, quality requirements, and system boundaries — nothing internal yet.
STEP 2 · LEVEL 1
Top-Level Services
Open the black box into major domain services: Rider Service, Driver Service, Matching Engine, Payment Service, Notification Service. Define their public interfaces.
STEP 3 · LEVEL 2
Package Diagrams
Decompose each service into packages. E.g. Rider Service → Auth, Profile, Trip History, Ratings. Driver Service → Onboarding, Location Tracker, Earnings.
STEP 4 · LEVEL 3
Building Blocks
Each package decomposes into concrete classes, interfaces, and modules small enough to assign to individual developers as work packages.
LEVEL 0 — Black Box Rideshare System decompose LEVEL 1 — White Box Services Rider Service Driver Service Matching Engine Payment Service Notification Service LEVEL 2 — Internal Packages Auth Profile Onboarding Location Algo + Pricing Payment pkgs… Notify pkgs… LEVEL 3 — Building Blocks (classes / modules) LoginHandler TokenService ProfileRepo DocVerifier … more building blocks Key insight Each level is a complete white-box view of the one above. Interfaces are defined top-down, ensuring clean contracts before implementation begins. L0 Vision L1 Services L2 Packages L3 Building Blocks
Top-Down Advantages & Disadvantages
✓ Advantages✗ Disadvantages
General understanding of problem before implementationDifficult integration at the end if not carefully managed
Independent of hardware and programming languageExisting solutions & libraries may be ignored
No getting lost in details early onProblems identified late may cause costly changes
Consistency & clean-cut distribution of responsibilitiesLate feedback on whether design is actually suitable
Some problems easier to see from an overall perspectiveRisk of over-engineering abstract layers
Bottom-Up Approach — Characteristics
Example — IoT Smart Factory  ·  Start from existing vendor-supplied sensors and SDKs, validate each one individually, then compose them layer by layer into the final monitoring system.
STEP 1 · COMPONENTS
Identify Existing Parts
Inventory all vendor sensors: Temperature (Vendor A, Modbus), Vibration (Vendor B, BLE), Pressure (Vendor C, MQTT). Each has its own SDK, protocol, and data format.
STEP 2 · WRAPPERS
Build Adapter Layer
Write an adapter/wrapper for each sensor that normalises its output to a common SensorReading interface. Test each adapter in isolation with real hardware.
STEP 3 · COMPOSE
Integrate into Services
Compose adapters into a Data Ingestion Service. Add an Alert Engine that consumes normalised readings. Add a Dashboard UI. Each integration is tested incrementally.
STEP 4 · SYSTEM
Architecture Emerges
The overall IoT Monitoring System architecture emerges from composing proven, tested parts. Add cross-cutting concerns (auth, logging) last. The structure was never designed top-down.
EXISTING VENDOR COMPONENTS Temp Sensor Vendor A / Modbus Vibration Sensor Vendor B / BLE Pressure Sensor Vendor C / MQTT Camera Feed Vendor D / RTSP PLC Controller Vendor E / OPC-UA ADAPTER LAYER — normalise to common interface ModbusAdapter BLE Adapter MQTT Adapter RTSP Adapter OPC-UA Adapter COMPOSED SERVICES Data Ingestion Service collects all sensor data Alert Engine + Dashboard consumes readings, triggers alerts EMERGED SYSTEM IoT Smart Factory Monitoring System Architecture was never planned top-down — it emerged from composing tested, vendor-supplied parts bottom-up
When to choose Bottom-Up: When components are innovative, require R&D, or are supplied by different vendors who develop them independently. Each part is validated with real hardware before being composed into the larger system.
Bottom-Up Advantages & Disadvantages
✓ Advantages✗ Disadvantages
Existing components are typically reusedNot all parts/functions may be needed → increased complexity
Incremental testing → high user satisfactionOrientation towards technical factors, not user requirements
Stepwise integration — validates at each stageDanger of premature optimization
Real sub-problems are the starting pointRisk of uncontrolled growth ("Frankenstein Architecture")
Top-Down vs Bottom-Up — Direct Comparison
DimensionTop-DownBottom-Up
Starting pointComplete system visionExisting components / sub-problems
Design directionDecomposition — coarse to fineComposition — fine to coarse
Feedback timingLate (risk of wrong assumptions)Early (real components validated first)
ReuseMay overlook existing solutionsHigh reuse of existing components
Integration riskIntegration challenges at endRisk of uncontrolled growth
Best forGreenfield projects with clear requirementsR&D, IoT, vendor-supplied components
Typical riskLate feedback, over-abstraction"Frankenstein Architecture"
In Practice: Most real-world projects combine both. Top-down gives overall structure and clean interfaces; bottom-up handles proven components and vendor-supplied parts. The skill is knowing when to switch modes.
📋 Chapter 3 — Summary
  • Top-Down: start with complete system vision, decompose into smaller sub-problems (coarse → fine)
  • Bottom-Up: start with existing components, compose them into a larger system (fine → coarse)
  • Top-Down best for: greenfield projects with clear requirements — clean interfaces from the start
  • Top-Down risk: late feedback, may miss existing solutions, over-abstraction
  • Bottom-Up best for: IoT, R&D, multi-vendor — validates real components early
  • Bottom-Up risk: "Frankenstein Architecture" — uncontrolled growth, premature optimization
  • In practice: most projects combine both approaches — top-down for structure, bottom-up for proven parts
Summary — Methods for Architecture Development
01 · Iterative & Incremental

Iterative & Incremental Development

  • Waterfall: sequential, high late-change cost
  • Agile: iterative, early feedback, embraces change
  • Iterative: same steps refined each cycle
  • Incremental: smaller steps, partial solutions
  • Architecture design is not a one-time task
02 · View-Based Development

View-Based Architecture

  • View = projection of system from specific perspective
  • Context — black box, external interfaces
  • Building-Block — static structure & components
  • Runtime — dynamic interactions at execution
  • Deployment — infrastructure, DevOps, costs
03 · Top-Down vs Bottom-Up

Development Approaches

  • Top-down: decompose from system vision
  • Bottom-up: compose from existing components
  • Top-down risk: late feedback, miss existing solutions
  • Bottom-up risk: Frankenstein Architecture
  • Best practice: combine both approaches