Skip to main content

This article explores architecture.

1. Definition and Purpose

  • Serves as a working model of a system.

  • Describes the system’s current state.

  • Prescribes how the system is expected to evolve over time.

  • Functions as both a functional blueprint and a roadmap for future development.

2. Architecture as a Process

  • Acts as a bridge between:

    • Requirements

    • Constraints

    • System realization (implementation)

  • Ensures that the conceptual design meaningfully leads to a workable system.

3. Analogy: Architecture as House Design

  • Homeowners → stakeholders with expectations and requirements.

  • Carpenters → implementers who must build with available materials (building blocks).

  • Architect → creates a design that satisfies needs while remaining practical to construct.

4. Role of Elegance

  • Elegance matters for architectural clarity and quality.

  • Primarily appreciated by other architects.

So how does this relate to software?

Intangibility and Abstraction:
Software operates beyond the physical realm, making it challenging to perceive and measure directly. Its impact lies in logic and functionality rather than material presence.

Example:

  • API design: You cannot “see” an API, but its abstract definition governs how systems communicate.

  • Cloud infrastructure: A virtual machine exists only as a software abstraction, not as a physical server the user touches.

  • Encryption algorithms: Their “effect” is invisible—data looks the same physically, but behaves differently based on logic.

  • Duality of Behavior:
    Software encapsulates both static elements (like code structure) and dynamic behavior (runtime processes), requiring attention to both for effective design and management. Example:

  • Static: A class definition in Python describing attributes and methods.
    Dynamic: The same class generating objects behaving differently at runtime.

  • Static: A database schema.
    Dynamic: Queries executed at runtime, transactions, deadlocks, and performance variations.

  • Static: Microservice configuration files.
    Dynamic: Services scaling up or down depending on load.

  • Inherent Complexity:
    The organization of software is intricate, involving layers of systems, logic, and dependencies. This interweaving of components is what we know as complexity, which demands thoughtful architecture and ongoing management. The design considerations here should be 'durable'

Example:

  • A web application with multiple layers (UI, API, business logic, data access, caching, authentication).

  • Dependency chains where updating one library breaks unrelated parts of the system.

  • Distributed systems like Kubernetes, where interactions among nodes, controllers, and workloads create emergent complexity.

  • Relativity of Quality:
    Quality in software is subjective and context-dependent, shaped by the needs and expectations of users, and providers. No universal standard can define the "perfect" software product.

Example:

  • Performance trade-offs:

    • A real-time trading system needs millisecond latency.

    • A batch-processing app can tolerate slower speeds.

  • UI expectations:

    • Designers prioritize polish.

    • Engineers might focus on functionality.

    • Users just want ease of use.

  • Security tolerance:

    • A banking app needs strict security.

    • A simple hobby app may accept less stringent controls.

  • Integrated Lifecycle and Distribution:
    Software development includes planning for packaging, distribution, and updates. The end-to-end process involves mechanisms to ensure reliable and predictable delivery and maintenance for users. Example:

  • Mobile apps:

    • Require packaging (.apk, .ipa), signing, App Store review, and update pipelines.

  • Desktop software:

    • Needs installers, auto-updaters (e.g., Electron apps), rollback mechanisms.

  • DevOps pipelines:

    • CI/CD workflows that package, test, deploy, monitor, and update software automatically.

Which brings me to one of my favorite parts of computing: durable systems—machines built so well that they keep working. Like voyager.

Computers are boxes, with toggles at a myriad of layers, the power switch is one layer and button.

We usually think of computers as these sleek boxes with blinking lights and a handful of buttons. Press power, everything wakes up. Press it again, everything sleeps.

There are decades of experience and knowledge, it's why your phone gives you haptic feedback when you touch it, the glass is not moving.  The vibration in the haptic motor is giving you a sensory input that your touch was received.

But lets explore the other considerations:

The Flight Data Subsystem (FDS) and a single eight-track digital tape recorder (DTR) provide the data handling functions.

How is that? How can a digital magnetic tape serve as a medium to record instructions and pass them to the other components?

There's an excellent talk about this by Bruce Waggoner here

To get the most out of it:

  • Start at minute 6 for the fundamentals of how the system works

  • Watch minutes 9–14 to understand how the computers operate and how they kept things simple, reliable, and extremely robust

  • Jump to minutes 17–19 for a look at how the engineering team planned, questioned, diagrammed, and communicated ideas clearly enough to survive decades of handoffs and mission changes

How did they explore the planning, asking questions and convey those in useful diagrams?

Voyager’s longevity isn’t magic—it’s architectural discipline.

It’s documentation.
It's modular thinking.
It’s choosing components that are just smart enough to do the job.