Harmonic Design: A Unified Software Engineering Framework

Published March 2026

A Unified Software Engineering Framework

Author: William Christopher Anderson
Date: March 2026
Version: 1.0

Executive Summary

Four things are true of every long-lived software system. It has a backend that must evolve. It has an interface that must evolve. It has tests that must survive both kinds of evolution. And it has a project plan that must anticipate, sequence, and resource all three kinds of work. These four concerns are typically treated as separate disciplines, governed by separate frameworks, owned by separate mental models.

Harmonic Design is the framework that eliminates this separation — and the friction it causes — by unifying all four concerns under a single structural discipline.

Harmonic Design synthesizes four frameworks — Volatility-Based Decomposition (VBD) for backend system architecture, Experience-Based Decomposition (EBD) for interface architecture, Boundary-Driven Testing (BDT) for test strategy, and Project Design (PD) for project planning and execution — into a unified practice governed by a single structural map. That map is drawn once, from the volatility of the problem domain, and read at every layer.

The structural parallel is exact. A Manager in the backend corresponds to an Experience in the interface; both are the primary subject of integration tests (real orchestrator, dependencies mocked) and of E2E tests (full stack); both map to integration milestone work packages in the project plan. An Engine corresponds to a Flow; both are the primary home of unit tests; both map to core work packages where most estimation effort concentrates. A Resource Accessor corresponds to an API Accessor; both are exercised in unit tests for translation logic and mocked at the boundary in integration tests; both map to boundary work packages at integration points with external systems. Utility is Utility everywhere — in the architecture, in the tests, and in the project plan as shared infrastructure work. The roles carry the same responsibilities, the same communication rules, the same test profiles, and the same project planning characteristics at every layer because they isolate the same axes of anticipated change.

The consequence of this coherence is significant. A change in business logic touches one Engine, one Flow, one set of unit tests, and one work package in the project plan — structurally bounded, predictably scoped, estimable from the architecture. A new user journey adds one Experience, one or more Flows, one E2E scenario, and one set of dependency edges in the project network. Testing difficulty at any layer signals the same class of structural problem: a boundary is in the wrong place. Estimation difficulty signals the same thing: if a work package is hard to estimate, the component it represents likely spans multiple volatility axes.

One mental model explains the whole system. One diagnosis applies everywhere. One structural map governs what to build, how to verify it, and how to plan, estimate, schedule, and execute the work.

Harmonic Design synthesizes its constituent frameworks into a unified whole. Each pillar retains its full set of rules, role definitions, and validation approach — but HD governs how they connect, how they reinforce each other, and how structural decisions at one layer propagate through all four. The result is a framework where volatility-first reasoning, applied consistently across backend, interface, tests, and project planning, produces structural isomorphism and predictable change propagation across every layer.

Abstract

Harmonic Design is a unified software engineering framework that applies a single organizing principle — isolating change along its natural axes — consistently across backend system architecture, interface architecture, test strategy, and project planning. HD synthesizes Volatility-Based Decomposition (VBD), Experience-Based Decomposition (EBD), Boundary-Driven Testing (BDT), and Project Design (PD) into a coherent whole: four pillars governed by one structural map, producing one mental model that holds across every layer of a software system and the project that delivers it. This paper describes the organizing principle, the structural isomorphism that connects the four pillars, the communication and state-flow rules that hold universally, and the emergent properties that arise when all four are practiced together. It offers validation criteria for HD coherence and positions the framework relative to existing methodologies.

1. Introduction

1.1 The Problem with Separate Frameworks

Software teams rarely suffer from a lack of frameworks. They suffer from frameworks that do not speak to one another.

A team might apply Domain-Driven Design to their backend, atomic design to their component library, coverage targets to their test strategy, and agile ceremonies to their project management. Each framework is locally sensible. Together, they produce a system where the backend’s bounded contexts do not correspond to the frontend’s component hierarchy, the test strategy was written by convention rather than derived from the architecture, and the project plan was estimated from user stories rather than from the system’s structural dependencies. When something changes, the engineer must simultaneously reason in four different structural languages. The seams between frameworks become the places where coupling hides and where plans fail.

The problem is not that the frameworks are wrong. It is that they answer different questions and produce different structural models. A system built across incompatible models carries hidden translation costs at every layer boundary — including the boundary between the system and the plan to build it.

1.2 The Unifying Principle

Across four frameworks — VBD, EBD, BDT, and PD — developed independently and for different domains, the same insight recurs:

Software should be organized by how it changes, not by what it currently does.

This is the claim of VBD: architect backend components around axes of anticipated change, not around functional domains. It is the claim of EBD: structure interface components around the axes of interface volatility — functional, structural, cross-cutting, environmental — not around screens or technical layers. It is the premise of BDT: tests are not a discipline separate from design; they are a mirror of the structure, and their difficulty is diagnostic evidence about where boundaries are wrong. And it is the foundation of PD: project plans derived from the architecture produce accurate estimates, because the components that constitute the work are the same components that isolate change, and the dependencies that constrain sequencing are the same dependencies that define communication rules.

The same volatility axes appear at every layer. The same four roles — an orchestrating tier, an execution tier, an external-boundary tier, a cross-cutting tier — emerge at the backend, at the interface, in the test profile of each tier, and in the work package classification of the project plan. The same communication rules — state flows downward, results propagate upward as events, horizontal coordination within a tier is prohibited — hold universally. The same validation mechanism — trace a core scenario through the hierarchy without bypassing communication rules — applies to VBD, EBD, BDT, and PD alike.

This is not coincidence. It is the consequence of asking the same fundamental question at every layer.

1.3 What HD Is

Harmonic Design is the practice of applying volatility-first reasoning coherently, simultaneously, across backend architecture, interface architecture, test strategy, and project planning — producing a system whose layers are structurally isomorphic and whose project plan is derived from the same structural map.

Coherent has a specific meaning here. In physics, coherent waves are in phase — they reinforce each other rather than interfering. In Harmonic Design, the four structural models are in phase: the boundaries drawn for volatility reasons in the backend correspond to the boundaries drawn for volatility reasons in the interface, which correspond to the test scope at each level of the spiral, which correspond to the work package boundaries and dependency edges in the project network. They reinforce each other. A structural insight at one layer informs all layers simultaneously — including the project plan.

Harmonic Design is a framework in its own right. Its contribution is not new roles, communication rules, test types, or estimation formulas — those belong to its constituent pillars. HD’s contribution is the structural discipline that connects them: the isomorphism rules, the coherence criteria, the diagnostic signals that cross layers, and the governance model that ensures all four pillars evolve together. Practicing the pillars in isolation produces good results. Practicing them as Harmonic Design produces structural properties that none achieves alone.

1.4 Scope and Relationship to Constituent Frameworks

This paper assumes familiarity with VBD, EBD, BDT, and PD. Readers unfamiliar with any of these frameworks are strongly encouraged to consult the individual papers before proceeding; this paper does not repeat the detailed role definitions, communication rules, estimation formulas, or worked examples that each contains. Instead, it focuses on the connections between them: the structural isomorphism, the coherent communication model, the project planning isomorphism, and the emergent properties that arise from practicing all four together.

2. The Organizing Principle

2.1 Volatility as Architectural Truth

Every design decision is a bet about the future. The question is whether the bet is placed consciously or by default.

Traditional decomposition strategies organize systems by what they do: functional layers, domain boundaries, technical tiers. These are structurally coherent bets about the present. They become structurally incoherent bets about the future when the system begins to evolve — because the things that change together are rarely the things that do the same kind of work.

Volatility-first decomposition inverts the organizing question. Instead of asking “what does this component do?”, it asks “how does this component change, and what causes that change?” Components that change for the same reason — and at the same rate — belong together. Components that change for different reasons belong apart, regardless of their current functional relationship.

This is the organizing principle of VBD, EBD, BDT, and PD. Applied to backend systems, it produces Managers, Engines, Resource Accessors, and Utilities. Applied to interface systems, it produces Experiences, Flows, Interactions, and Utilities. Applied to test strategy, it produces a test pyramid whose levels are determined by structural scope rather than convention. Applied to project planning, it produces work packages whose boundaries match component boundaries, dependencies that mirror architectural dependencies, and estimation targets whose volatility characteristics are already known. The principle is the same. The domain of application differs.

2.2 The Four Universal Axes

The four axes of volatility that VBD identifies in backend systems appear in equivalent form at the interface layer:

The axes are not identical — the specific pressures that drive functional change in a backend service differ from those that drive change in a form field. But the type of change follows the same pattern, and the appropriate structural response is the same: isolate each axis in a dedicated role, enforce communication rules that prevent axis contamination, and let configuration drive composition within each axis.

Figure 1a — Volatility capture in VBD. Each role has a primary affinity for certain kinds of volatility, but it is the coordination between roles — the Manager invoking Engines and Accessors, Engines calling Accessors for persistence or reference data, Utilities consumed by all — that captures volatility as a system. The mental model: the Manager owns the what (what needs to happen and in what order), the Engine owns the how (business logic and rules), the Resource Accessor owns the where (where data lives and how it is accessed), and the Utility provides the with what (shared capabilities).

Figure 1b — Volatility capture in EBD. The same pattern at the interface layer. The Experience orchestrates the user journey, Flows execute goal-directed sequences, Interactions handle atomic user actions, API Accessors isolate backend communication, and Utilities provide shared interface capabilities. Again, it is the coordinated structure — not any single tier — that localizes change.

3. The Structural Isomorphism

3.1 One Map, Four Readings

The central claim of HD is structural isomorphism: the role taxonomy of VBD, the tier taxonomy of EBD, the test scope taxonomy of BDT, and the work package classification of PD map onto each other exactly. They are four readings of the same underlying structural map.

Figure 2 — The Harmonic Design Structural Map: four tiers, each reading identically across VBD, EBD, BDT, and PD. The tiers are structurally isomorphic — the same position in each framework carries the same responsibilities and constraints. Note: VBD and EBD are parallel frameworks, not a call chain. A Manager does not call a Flow; an Experience does not call an Engine. Each framework governs its own layer. The isomorphism is structural, not communicative.

The table form makes the correspondence precise:

BDT note: Integration tests exercise the Orchestration tier — a real Manager or Experience with Execution and External Boundary dependencies mocked. The External Boundary tier’s own unit tests cover translation logic only; the tier is mocked at the seam in integration tests and real in E2E.

PD note: The work package type determines estimation characteristics. Core work packages (Engines/Flows) carry the highest functional volatility and therefore the widest estimation ranges. Integration milestones (Managers/Experiences) are estimated primarily by the number and complexity of seams they coordinate. Boundary work packages (Accessors) are estimated by the complexity of the external system contract. Shared infrastructure (Utilities) is typically estimated with the tightest ranges, as cross-cutting concerns change least frequently.

3.2 What Isomorphism Means in Practice

Structural isomorphism means that a developer who understands VBD can read the EBD structure without relearning. The role names differ; the structural position and responsibilities are the same. An Experience orchestrates, does not execute, and communicates downward — exactly as a Manager does. A Flow executes one goal’s logic, does not coordinate siblings, and communicates results upward — exactly as an Engine does. A Utility is consumed, never coordinates — in both frameworks identically.

More practically, it means that when a developer encounters a structural problem in one layer, they know where to look in the other layers. An Engine with too many responsibilities will have a corresponding Flow with too many responsibilities. A Manager that is doing its own business logic will have a corresponding Experience doing its own API calls. The misalignment propagates coherently — which means fixing it in one layer guides fixing it in the others.

For teams, isomorphism reduces the cognitive load of full-stack development. There is one structural model, read at four levels. A senior engineer does not need to context-switch between “backend thinking,” “frontend thinking,” “test thinking,” and “planning thinking” — they apply the same volatility analysis, draw the same tier map, and verify the same communication rules. The domain of the code changes; the structural discipline does not.

4. The Universal Communication Model

4.1 State Flows Downward; Results Surface as Events

The communication model is identical in VBD and EBD, determines the mock structure in BDT, and defines the dependency edges in PD.

In VBD: orchestration intent flows downward from Manager to Engine to Resource Accessor. Results return upward through function returns and structured response types. Managers do not receive unsolicited signals from Engines; they invoke and receive. Engines do not coordinate with sibling Engines; they are invoked and return. Resource Accessors do not apply business logic; they translate and return.

In EBD: configuration drives the Experience, which passes shared state downward to Flows. Flows pass props and callbacks to Interactions. Interactions emit atomic events upward to their parent Flow. Flows emit completion events upward to the Experience. The Experience holds the accumulated journey state and is the only tier that communicates outward to the backend API.

In PD: the same downward flow determines the project network. Manager work packages depend on Engine work packages, which depend on Accessor work packages. The dependency direction in the project network mirrors the communication direction in the architecture. This is not a convention — it is a structural consequence. You cannot build a Manager before the Engines it coordinates exist; you cannot integrate before the components being integrated are complete.

Figure 3a — VBD backend communication: state invoked downward, results returned upward.

Figure 3b — EBD interface communication: config drives Experience, state passes down, events propagate up. Experience alone calls the backend.

4.2 The Prohibited Patterns Are the Same

The communication rules in VBD and EBD prohibit the same structural violations, expressed in the terms of their respective domains:

These are not parallel analogies. They are the same prohibition — horizontal coordination within a tier, and external coupling below the orchestration tier — applied to the specific roles and artifacts of each layer.

4.3 Consequence for Test Structure

In BDT, where you place mocks follows directly from these communication rules. You mock at the role boundary because the role boundary is where the communication rule enforcement happens. If an Engine must not call sibling Engines, a unit test for that Engine needs exactly one mock: the Resource Accessor below it. If a Manager must not call peer Managers synchronously, an integration test at the Manager-to-Engine seam needs exactly the Engine mocked — not the Manager’s peers. The test topology is derived from the communication topology. There is nothing to negotiate.

4.4 Consequence for Project Structure

In PD, the communication topology becomes the project network topology. Dependencies between work packages follow the same direction as dependencies between components:

• Utility work packages have no upstream dependencies and form the leaf nodes of the project network.
• Accessor work packages depend on Utility and infrastructure work packages.
• Engine work packages depend on Accessor work packages.
• Manager work packages depend on Engine and Accessor work packages.
• Integration milestones depend on the Manager work packages that compose them.

This ordering is not arbitrary. It is the natural consequence of the communication model: you cannot build what orchestrates before you build what is orchestrated. The project network is derived from the architecture. There is nothing to negotiate here either.

5. The Four Frameworks as Pillars

The following sections briefly characterize each framework’s core contribution within Harmonic Design. Each framework is documented in full in its individual paper; what matters here is understanding how each pillar carries the same structural weight in the unified practice.

5.1 VBD — The Backend Structural Model

Volatility-Based Decomposition establishes the structural model for backend systems. It identifies four volatility axes and assigns each to a dedicated component role: Managers for non-functional/orchestration concerns, Engines for functional business logic, Resource Accessors for environmental and infrastructural concerns, and Utilities for cross-cutting concerns. It enforces communication rules that prevent volatility contamination across role boundaries and validates the structural model against a small set of core use cases.

VBD’s primary contribution to HD: the role taxonomy, the volatility axis framework, and the proof that organizing backend systems by anticipated change produces systems that can absorb that change without widespread refactoring.

The key rule that carries into HD: boundaries should reflect volatility, not current functional grouping.

5.2 EBD — The Interface Structural Model

Experience-Based Decomposition applies the same volatility-first logic to interface systems. It establishes three behavioral tiers — Experiences, Flows, and Interactions — plus Utilities, each isolating one of the four interface volatility axes. It enforces the same downward state flow and upward event propagation model. It adds one critical rule with no backend equivalent: the Experience is the exclusive communicator with the backend API. Flows never call the API. The Experience accumulates complete journey state across all its Flows and decides when and what to emit.

One clarification worth stating explicitly: the tier hierarchy describes behavioral scope, not a rigid nesting requirement. An Experience can directly host an Interaction when the scope is genuinely minimal — a single dropdown, a confirmation toggle, a preference that requires no multi-step sequence. The tier exists to contain a complete goal-directed sequence; when the goal is atomic, no Flow is needed between the Experience and the Interaction. The rule is that Interactions never coordinate laterally or bypass upward — not that a Flow must always be present.

EBD’s primary contribution to HD: the demonstration that the same structural logic that governs backend systems governs interface systems, with the same tier count, the same communication discipline, and the same validation mechanism.

The key rule that carries into HD: the orchestrating tier (Experience / Manager) is the only tier that crosses the system boundary outward.

5.3 BDT — The Test Strategy Map

Boundary-Driven Testing maps the test spiral to the structural models defined by VBD and EBD. It establishes that the test type is determined by the structural tier under test: Engines and Flows belong at unit scope, seams between tiers belong at integration scope, complete journeys belong at E2E scope. It treats mock placement as an architectural statement — you mock at boundaries because boundaries are the architecturally significant seams — and reads test difficulty as structural evidence.

BDT’s primary contribution to HD: the demonstration that structural coherence and testing tractability are the same thing. A system with correct boundaries is easy to test. Testing difficulty is diagnostic of structural problems, not of test strategy problems.

The key rule that carries into HD: the test spiral is not a testing methodology; it is a structural map. Fix the structure and the tests follow.

5.4 PD — The Project Planning Model

Project Design derives the project plan from the architectural decomposition. Components become work packages. Dependencies between components become the project network. The critical path through that network determines the project duration. Compression and decompression of that path determine the feasible range of schedules. Risk is quantified objectively from the float distribution across all activities. The result is not a single plan but a set of viable options — typically three — spanning conservative, balanced, and aggressive approaches.

PD establishes several principles that carry directly into HD. The activity inventory is architecture-derived: each component identified during VBD or EBD decomposition becomes a work package with a predictable lifecycle (design, implementation, unit testing, integration). Each pair of connected components generates an integration activity. Each core use case generates a system-level verification activity. The one-to-one rule — each component assigned to one developer — is a direct consequence of the same boundary discipline that governs the architecture: if a component cannot be built by one developer within the project timeline, it should be decomposed further, and this is an architectural problem, not a staffing problem.

PD’s primary contribution to HD: the demonstration that the same structural map that governs what to build and how to verify it also governs how to plan, estimate, schedule, and execute the work. The architecture is the plan.

The key rule that carries into HD: you cannot estimate what you have not designed. The architecture must precede the estimate, because the architecture defines the work.

6. The Project Design Isomorphism

6.1 The Architecture Is the Plan

The deepest structural connection between PD and the other three pillars is not analogical — it is definitional. In Project Design, the project plan is not constructed from requirements, user stories, or feature lists. It is derived from the architectural decomposition. This means the same structural map that VBD uses to organize backend components and EBD uses to organize interface components is the map that PD uses to organize the project.

Every VBD component — every Manager, Engine, Resource Accessor, and Utility — becomes a work package. Every EBD component — every Experience, Flow, Interaction, and Utility — becomes a work package. Every dependency arrow in the architecture diagram becomes a precedence relationship in the project network. The critical path through the project is the critical path through the architecture’s dependency graph. The architecture is the plan.

This is not a metaphor. When an architect draws a dependency from SchedulingManager to EligibilityEngine, that arrow means two things simultaneously: at runtime, the Manager invokes the Engine; in the project plan, the Engine work package must complete before the Manager work package can begin integration. The same arrow. Two readings. One structural truth.

6.2 Work Package Classification Follows Tier Classification

The tier classification in VBD and EBD directly determines the characteristics of each work package in PD:

Orchestration tier (Manager / Experience) — Integration Milestone Work Packages. These work packages are primarily integration work. The Manager or Experience itself contains minimal logic — it orchestrates. Its work package is therefore dominated by integration effort: wiring the seams, verifying the contracts, handling the error propagation paths. Estimation for these work packages focuses on the number and complexity of seams, not on algorithmic complexity. They are typically on or near the critical path because they depend on everything below them.

Execution tier (Engine / Flow) — Core Work Packages. These are where the domain logic lives, and where most estimation effort should concentrate. Engines and Flows carry the highest functional volatility — they embody the business rules and user-facing logic that change most frequently. This volatility translates directly into estimation uncertainty: the work packages for Engines and Flows should carry the widest estimation ranges. They are the components most likely to require design iteration, and the components whose scope is most likely to be affected by requirement changes during execution.

External Boundary tier (Accessor / API Accessor) — Boundary Work Packages. These work packages are defined by the complexity of the external system they interface with. The component itself is simple — translation logic only, no business rules. But the work to build and verify it depends on the external system’s contract stability, documentation quality, and availability for integration testing. Estimation for boundary work packages should account for external system risk, which is often the dominant factor.

Cross-Cutting tier (Utility) — Shared Infrastructure Work Packages. Utilities are the most stable tier — they change least frequently, they have no domain-specific knowledge, and they have no upstream dependencies. Their work packages are the most parallelizable and carry the tightest estimation ranges. They form the leaf nodes of the project network, enabling early construction starts.

Figure 5 — Work package classification derived from the structural map. Each VBD/EBD tier maps to a PD work package type with distinct estimation characteristics.

6.3 Dependencies Mirror Communication Rules

The communication rules enforced by VBD and EBD — state flows downward, results propagate upward, no peer coordination — produce a specific dependency topology. That same topology is the project network.

In the architecture: Managers invoke Engines; Engines invoke Accessors; Accessors invoke external systems. No Engine invokes a sibling Engine. No Accessor applies business logic.

In the project plan: Manager work packages depend on Engine work packages; Engine work packages depend on Accessor work packages; Accessor work packages depend on infrastructure. No Engine work package depends on a sibling Engine work package (because the components do not communicate). No Accessor work package depends on an Engine work package (because Accessors do not call Engines).

The prohibited patterns in the architecture are the prohibited patterns in the project plan. If an Engine calls a sibling Engine — a communication rule violation — the corresponding project network would show a dependency between peer work packages, creating a cycle or an unnecessary coupling that complicates the critical path. The communication discipline that produces clean architecture also produces clean project networks.

6.4 Risk Maps to Volatility

In PD, risk is quantified objectively from the float distribution across all activities. Activities with zero float are on the critical path and carry maximum risk. Activities with large float can absorb delays.

In HD, the volatility axis framework provides an additional dimension to this risk analysis. The most volatile tiers — Engines and Flows, which carry functional volatility — are the most likely to experience scope change, design iteration, and estimation error during execution. VBD already identifies these components as the functionally volatile tier. PD already identifies the most schedule-sensitive activities through float analysis. When both analyses converge on the same components — when a functionally volatile Engine with a wide estimation range is also on the critical path with zero float — the risk is compound, and the project plan should reflect this.

Conversely, the most stable tiers — Utilities, which carry cross-cutting volatility that changes infrequently — are the safest components on the schedule. Their estimation ranges are tight, their scope is unlikely to change, and their position as leaf nodes in the network means they have the most float. The volatility analysis and the float analysis agree: these are low-risk work packages.

This convergence is not a coincidence. It is a structural consequence of deriving both the architecture and the project plan from the same volatility map. The architecture identifies what changes most. The project plan identifies what is most schedule-sensitive. When both are derived from the same map, the high-volatility components and the high-risk activities are the same things — which means risk mitigation strategies (assigning the best resources, providing wider estimation ranges, investing in design iteration) target the right components automatically.

6.5 Staffing Follows Architecture

PD establishes the one-to-one rule: each component is assigned to one developer. This is a direct application of Conway’s Law — the interaction between team members mirrors the interaction between the components they build. A well-decomposed architecture with minimized inter-component coupling naturally minimizes inter-developer communication overhead.

In HD, this principle extends further. Because the architecture already organizes components by volatility tiers, and because volatility tiers map to estimation characteristics and risk profiles, staffing assignments can be made tier-aware:

• The best resources are assigned to critical-path Engine work packages — the most volatile, most uncertain, most estimatively risky components.
• Boundary work packages (Accessors) are assigned to developers with the most experience with the specific external systems involved.
• Utility work packages are assigned flexibly — their tight estimation ranges and high float make them the most forgiving assignments.
• Integration milestone work packages (Managers/Experiences) are assigned to senior developers who understand the seam contracts — because integration work is primarily coordination work, and coordination requires structural understanding.

Team boundaries align with volatility boundaries, which align with component boundaries, which align with work package boundaries. One structural map governs all four.

7. Coherence Properties

When VBD, EBD, BDT, and PD are practiced together as HD — when the same volatility map governs the backend, the interface, the test strategy, and the project plan simultaneously — emergent properties appear that none of the individual frameworks produces in isolation.

7.1 Change Locality Across All Layers

In an HD system, a change in requirements touches exactly one component at each tier, across all layers — including the project plan.

A new pricing rule touches one Engine in the backend. At the interface, the same change might modify one Flow that presents pricing information. In the test suite, the unit tests for that Engine are updated, the unit tests for that Flow are updated, and the integration test for the Manager-to-Engine seam is updated if the contract changes. In the project plan, the change is one new work package, one new dependency edge, one recalculation of the critical path. Everything else is unaffected.

This is stronger than any individual framework achieves alone. VBD localizes backend change. EBD localizes interface change. BDT localizes test change. PD localizes planning change. HD localizes change across all four simultaneously, because the boundaries at each layer correspond. The blast radius is structurally bounded at every layer, not just one.

The project plan absorbs architectural change the same way the architecture absorbs requirement change. A new Engine means one new work package, one new dependency edge, one recalculation of the critical path. The plan does not need to be replanned from scratch. It absorbs the change structurally, because its structure mirrors the architecture’s structure.

7.2 Test Scope Determinism

In an HD system, a developer never has to ask “what kind of test should I write for this?” The answer is structurally determined.

If the component is an Engine or a Flow — execution tier, functional volatility — write unit tests. Mock the Accessor or API boundary below. Assert all contract states.

If the component is a Manager or Experience — orchestration tier — write integration tests at each of its seams. Mock the Engines or Flows it orchestrates. Verify that it correctly handles every state each dependency can emit.

If you are verifying a complete user journey — full stack — write an E2E test. No mocks. Real infrastructure.

The test pyramid is not a recommendation. It is a consequence of the structure. A system with correct HD boundaries produces a correctly shaped pyramid naturally, without any team convention or coverage mandate.

7.3 Estimation Accuracy from Volatility Alignment

In an HD system, estimation targets are volatility-aligned. This means the components being estimated are already classified by their anticipated rate of change, and the estimation approach can be calibrated accordingly.

High-volatility components (Engines, Flows) get wider estimation ranges — because they embody the business rules and user-facing logic most likely to change during execution. These are the components where design iteration is most likely, where scope clarification takes the longest, and where estimation error is historically largest. The architecture already identifies them. The estimation process can account for their uncertainty from the start, rather than discovering it during execution.

Stable components (Managers, Utilities) get tighter estimation ranges — because their scope is well-defined, their logic is minimal (orchestration or cross-cutting), and their change rate is low. The architecture already identifies their stability. The estimation process can trust their scope.

This calibration is not possible when estimating from requirements or user stories, because requirements do not carry volatility information. A user story about “pricing calculation” gives no structural signal about whether the work is an Engine (high volatility, wide range), a Manager (low volatility, tight range), or an Accessor (external system risk). The HD structural map provides that signal before estimation begins.

7.4 Structural Legibility

An HD system has one structural model, not four. Any engineer who understands that model — the four tiers, their volatility axes, their communication rules — can navigate the backend, the interface, the test suite, and the project plan using the same conceptual vocabulary.

This has compounding effects on team organization and onboarding. An engineer learning VBD implicitly learns EBD’s tier structure, because the structural logic is the same. An engineer who understands why Engines do not call sibling Engines automatically understands why Flows do not call sibling Flows. A project manager who understands the dependency graph in the project network automatically understands the communication topology in the architecture — because they are the same graph. The mental overhead of learning a new layer is reduced to learning the domain-specific vocabulary, not a new structural theory.

7.5 Diagnostic Consistency

Testing difficulty in HD is a single diagnostic, not four separate ones. When something is hard to test at any level — hard to unit test, hard to write integration tests for, hard to write stable E2E tests for — the diagnosis is always the same: a boundary is in the wrong place.

Hard-to-unit-test Engine: it has absorbed Accessor responsibilities, or it is calling a sibling Engine. Hard-to-unit-test Flow: it is making API calls it should not make, or it is aware of sibling Flows. Hard-to-write-integration-test-for Manager: its seams are not well-defined, or its Accessors are embedded rather than injected. Unstable E2E: the Experience does not represent a complete, semantically stable journey.

Hard-to-estimate work package: the component it represents spans multiple volatility axes — an Engine that also does orchestration, an Accessor that also applies business rules. If the component were correctly decomposed, each resulting work package would be estimable in isolation.

The same structural analysis resolves all of these. There is no separate “test problem” or “estimation problem” to debug. There is only a structural problem, and the structural model tells you exactly where it is.

7.6 Risk Quantification from Architecture

In a conventional project, risk is assessed subjectively — experienced practitioners identify likely failure modes and assign probability and impact scores. In an HD system, risk is quantified objectively from two converging sources: the float distribution in the project network (PD) and the volatility classification of each component (VBD/EBD).

Activities with zero float are on the critical path — maximum schedule risk. Components with high functional volatility carry maximum estimation uncertainty. When a zero-float activity corresponds to a high-volatility Engine, the risk is compound and quantifiable. When a high-float activity corresponds to a stable Utility, the risk is minimal and the float can be traded for staffing flexibility.

This convergence means risk mitigation is architectural, not managerial. You do not manage risk by adding buffers to a plan estimated from requirements. You manage risk by ensuring that high-volatility components have adequate float in the project network, that the best resources are assigned to volatile critical-path activities, and that the architecture itself minimizes the number of high-volatility components on the critical path — which is an architectural decision, not a project management decision.

7.7 Configuration-Driven Composition at Every Layer

VBD establishes the principle that configuration should drive composition — that architectural variants should be produced by supplying different configuration, not by writing different code. EBD applies the same principle at the interface layer: an Experience composes different Flows based on the configuration it receives, without changing the Flows themselves.

In an HD system, this principle holds across all layers simultaneously. The same configuration that selects a backend policy variant (a Manager receives different Engine parameters) also drives interface composition (an Experience presents different Flows) and is verified by the same E2E scenario with different configuration inputs. Configuration is a first-class citizen of the architecture, not an afterthought.

8. Configuration as a First-Class Citizen

8.1 The Configurability That Correct Structure Enables

Every team wants systems that can be configured rather than recoded. Few achieve it consistently, because configuration-driven behavior requires structural preconditions that are rarely designed for explicitly. Harmonic Design creates those preconditions as a natural consequence of correct decomposition.

The precondition is simple to state: configuration can only drive behavior when the things that vary are cleanly separated from the things that stay the same. In a system where business rules are interwoven with orchestration logic, where API calls are embedded in flows, where test scaffolding is entangled with component logic — configuration has nowhere to attach. Every configuration variant requires a code change.

In a Harmonic Design system, the structure creates natural attachment points at every tier:

• Managers receive configuration that determines which Engines to invoke and in what order — without embedding that logic inside any Engine.
• Experiences receive configuration that determines which Flows to compose, in what sequence, under what conditions — without embedding that logic inside any Flow.
• Engines and Flows receive parameterized inputs that shape their behavior — without knowing where those parameters came from or what else is running alongside them.

The result is a system where new behavioral variants are produced by writing configuration, not code.

8.2 Configuration-Driven Composition in Practice

The most powerful expression of this principle is not configuration that tweaks a parameter — it is configuration that assembles entire systems.

When Managers are stable orchestrators and Engines are stateless executors, a Manager can be driven entirely by a configuration schema: which Engines to invoke, in what order, under what conditions, with what inputs. A new workflow is a new configuration block, not a new codebase.

When Experiences compose Flows based on configuration, and Flows render Interactions based on their own configuration, an entirely new user journey — different steps, different conditions, different validation — can be created from a YAML file. The code is infrastructure. The configuration is the product.

This is not a theoretical capability. It is the practical outcome of structural discipline applied consistently. Teams that practice Harmonic Design find themselves building systems that derive new capability entirely from configuration — and eventually, systems that use configuration to generate more systems.

8.3 Software Factories

The most complete expression of configuration-driven Harmonic Design is the software factory: a system whose structural model is stable enough that new instances of that model can be assembled from configuration alone.

A factory built on Harmonic Design principles has the following shape:

• A fixed set of Managers representing the orchestration patterns of the domain. These do not change when new products or workflows are added.
• A fixed set of Engines representing the business rule primitives of the domain. New rules are new Engine configurations, not new Engine classes.
• A fixed set of Experiences and Flows representing the interaction patterns of the domain. New journeys are new Experience configurations, not new interface components.
• A configuration layer — YAML, JSON, a schema, an administrative UI — that assembles these structural elements into new product instances.

The factory itself is a Harmonic Design system. It consumes configuration at its orchestration tier and produces running systems at its output tier. The configuration is the specification; the structural model is the execution engine. New capability is produced from configuration without touching the factory’s codebase.

This is not code generation. Code generation produces new source code from templates. A Harmonic Design factory produces running behavior from structural assembly. Structural assembly is safe, testable, and reversible — because the structural elements being assembled are themselves governed by the same boundary rules, test profiles, and communication contracts as the factory that assembles them.

8.4 Configuration Absorbs Change

The most consequential capability of configuration-driven Harmonic Design is that it changes the relationship between requirements and code. In a conventional system, a change in business requirements produces a change in code. In a configuration-driven Harmonic Design system, many classes of requirement change produce only a change in configuration.

This is not a small distinction. It means:

• A new validation rule is a new configuration entry, not a pull request.
• A new user segment with a different onboarding path is a new Experience configuration, not a new frontend component.
• A new document type that a system must process is a new processing rule configuration, not a new Engine class.
• A new organizational policy that changes how workflows are sequenced is a new Manager configuration, not a refactoring of orchestration logic.

The system absorbs these changes because the structure anticipated them. The volatility that would have been expressed as code churn is instead expressed as configuration variation — contained, reviewable, deployable without a build.

8.5 Configuration-Driven Systems End to End

This principle applies equally at every layer — backend and interface alike. The Harmonic Design system that is fully driven by configuration does not have a configurable frontend and a hardcoded backend. Both layers are configurable, and both are configurable for the same structural reason: the volatile parts (rules, flows, compositions) are separated from the stable parts (orchestration patterns, execution primitives, rendering infrastructure).

Backend: A Manager driven by configuration invokes different Engines in different orders for different tenants, segments, or policy contexts — without a single tenant-specific code path. An Engine parameterized by configuration applies different rule sets to the same computation — without branching on tenant identity inside the rule. A new workflow is a new configuration block. A new policy variant is a new parameter set. The backend codebase does not grow when the business grows; the configuration does.

Interface: An Experience driven by configuration composes different Flows for different user segments, organizational contexts, or product variants — without a single conditional branch in the Experience code. Each Flow renders different Interactions based on its own configuration. The result is an interface that presents entirely different product experiences from the same structural code.

End to end: When both layers are configuration-driven, a new product variant is a new configuration package. Upload it, and both the backend behavior and the interface composition change simultaneously — no code deployment, no build pipeline, no feature flag cleanup. The new variant is immediately available to whatever context the configuration targets.

What this enables in practice:

• White-labeling without branching codebases. Configuration supplies branding, behavioral rules, and workflow sequences at both layers. The codebase is shared.
• Multi-tenant variation without tenant-specific code. Configuration describes what each tenant sees and how the backend serves them. Both layers compose accordingly.
• Regulatory compliance variants without forking. A different compliance rule set is a different configuration block. The Engines that enforce it are the same Engines that enforce all other rule sets.
• Capability extension by upload. New rules, new document types, new process definitions, new assets — uploaded as configuration, interpreted by the structural model, immediately operational.
• Phased capability rollout without feature flags embedded in logic. A capability is present when its configuration is present. When the configuration is absent, the capability does not appear — no conditionals, no dead code paths.

Neither the backend nor the interface knows which variant it is serving. The backend knows how to orchestrate Engines and invoke Accessors. The interface knows how to compose Experiences, assemble Flows, and render Interactions. That is the entire codebase. The variation lives in the configuration.

8.6 Dogfooding the Structure

The deepest expression of this pattern is a system that uses its own structural model to extend itself. A Harmonic Design system that produces new workflows from configuration can also define new configuration schemas using the same workflow machinery — because a configuration schema is itself just another workflow, driven by an Experience, composed of Flows, assembled from Interactions.

This is the point at which Harmonic Design becomes more than an architectural methodology: a way of building systems that know how to build more of themselves. The structural model is recursive. The factory can configure new factories. The boundary discipline that makes leaf components testable and replaceable also makes the factory composable at the system level.

Assets, rules, processes, and capabilities can all be uploaded as configuration. The running system interprets them, routes them through the appropriate tier, and makes them available immediately — without a deployment, without a code review, without a build pipeline. The code is stable. The system is not static.

Twenty years of consistent engineering practice produces a consistent observation: the teams that achieve this level of configurability are not the teams with the best technology — they are the teams with the most disciplined boundaries. The factory emerges from the structure. The structure comes from the discipline. The discipline is Harmonic Design.

9. How Change Propagates in a Harmonic Design System

The following example traces a single requirement change — adding a tiered user segment to an onboarding system — through all four layers of an HD system. The purpose is to demonstrate that the structural map is the same at every layer, and that the change propagates through corresponding tiers.

The change: The system must now present a different onboarding path for enterprise users versus individual users. Enterprise users require an organizational profile flow; individual users skip it.

9.1 Backend Change (VBD)

A new SegmentEngine is added to evaluate user segment from the incoming request. The OnboardingManager is updated to call SegmentEngine before determining which downstream Engines to invoke. The SegmentEngine is unit tested in isolation — given user attributes, returns the correct segment type. An integration test at the Manager-to-Engine seam verifies that the Manager routes correctly based on each segment value the Engine can return. No other components change.

9.2 Interface Change (EBD)

The OnboardingExperience is updated to receive segment state from the backend (already present in the API response) and use it to determine which Flows to compose. An OrgProfileFlow is added for enterprise users. The OnboardingExperience skips it for individual users. OrgProfileFlow is unit tested in isolation — given shared state, steps through Interactions, emits completion. An integration test at the Experience-to-Flow seam verifies that the Experience correctly skips or includes OrgProfileFlow based on segment. No existing Flows change.

9.3 Test Change (BDT)

One new unit test suite for SegmentEngine. One new unit test suite for OrgProfileFlow. Two new integration test paths — one for enterprise, one for individual — at the Manager-to-Engine seam and the Experience-to-Flow seam. Two new E2E scenarios: enterprise onboarding and individual onboarding, each verifying the complete journey in the real system. No existing tests change.

9.4 Project Plan Change (PD)

One new core work package for SegmentEngine (design, implementation, unit testing). One new core work package for OrgProfileFlow (design, implementation, unit testing). Two new integration activities at the Manager-to-Engine and Experience-to-Flow seams. The SegmentEngine work package depends on the existing Accessor work packages (it reads user attributes). The OrgProfileFlow work package depends on the existing Interaction work packages it composes. Both new work packages are inserted into the project network with their dependency edges. The critical path is recalculated. If the new Engine is on the critical path, it receives priority resourcing. If it is not — because it has float via an alternative path — it can be staffed flexibly.

The project plan absorbed the architectural change the same way the architecture absorbed the requirement change: one new component per tier, one new work package per component, recalculate the network. No replanning from scratch. No disconnection between what was designed and what was planned.

Figure 4 — Change Propagation in an HD System: the same tiered change — one component per tier, per layer — propagates through a feature addition without cross-tier or cross-layer spillover.

9.5 What the Propagation Pattern Reveals

The change propagated through exactly one new component per tier, at both the backend and interface layers, with corresponding test additions and a localized update to the project plan. Existing components did not change. Tests for existing components did not change. The project plan absorbed the change through insertion, not replanning. The structural boundaries contained the change at every layer.

This is not a feature of the specific example. It is the promised behavior of volatility-coherent boundaries: components that change for different reasons are separated, so a change to one reason touches only those components. The feature was added in one Engine, one Flow, and the orchestrating tier that coordinates them — plus the tests that verify each and the work packages that plan each.

A team that did not practice HD would experience the same requirement as a cross-cutting change: logic scattered across multiple Managers, flows embedded in Experience components that now need awareness of segment, tests that can’t be scoped because the structure has no stable seams, and a project plan that must be replanned because the work does not decompose into predictable packages. The same requirement, a different structural experience, because the boundaries were drawn differently.

10. Validation

10.1 The HD Coherence Test

A system is coherent under HD if the following statements are all true:

Structural:

• Every backend component can be classified as a Manager, Engine, Resource Accessor, or Utility without ambiguity
• Every interface component can be classified as an Experience, Flow, Interaction, or Utility without ambiguity
• The tier hierarchy is consistent: Managers coordinate Engines; Experiences coordinate Flows; no peer coordination exists within a tier
• Utility components in both layers have no domain-specific knowledge and no coordination responsibility

Communication:

• No Engine calls a sibling Engine; no Flow calls a sibling Flow
• No Accessor applies business logic; no API Accessor makes business decisions
• No Flow makes direct backend API calls; only Experiences call the backend
• Any cross-tier communication that appears is justified by an explicit configuration or composition mechanism

Test:

• Every Engine and Flow has a unit test suite; all dependencies are mocked; all contract states are asserted
• Every Manager-to-Engine, Engine-to-Accessor, and Experience-to-Flow seam has integration tests; dependencies are mocked at the outer boundary
• Every core use case / core user journey has an E2E test; no mocks
• Testing difficulty at any level can be traced to a specific structural boundary problem

Project:

• Every component maps to exactly one work package in the project plan
• Every dependency in the architecture maps to a precedence relationship in the project network
• Work package estimation ranges are calibrated to the volatility classification of the corresponding component
• The critical path through the project network corresponds to the critical path through the architectural dependency graph
• Staffing assignments follow volatility boundaries: best resources on volatile critical-path components

Coherence:

• The boundary that separates a Manager from an Engine corresponds to a boundary that separates an Experience from a Flow, a test scope boundary in BDT, and a work package boundary in PD
• A change in business logic touches one Engine, one Flow, the tests for each, and one work package in the plan — not more
• The test pyramid is naturally shaped by the structure, not enforced by coverage policy
• The project plan absorbs architectural changes through insertion and recalculation, not replanning

10.2 Failure Modes and What They Signal

When a system fails the HD coherence test at one layer, it almost always fails at the corresponding position in all layers.

The diagnostic is always structural. When testing is painful at one layer, check the corresponding tier in the other layer. When estimation is painful for a work package, check whether the component it represents has a clean volatility classification. The same boundary problem will be present.

11. Naming the Practice

11.1 Why This Needs a Name

The four frameworks addressed in this paper — VBD, EBD, BDT, and PD — each have names that position them as domain-specific tools. This is appropriate for learning and for consulting the frameworks individually. But it has an unintended consequence: it encourages teams to treat them as separable options, adopting one and ignoring the others.

The unified practice requires a name that signals that it is unified — that the four frameworks are not a menu but a coherent whole. A team that adopts VBD without EBD will have a well-structured backend and a poorly structured interface; the structural mismatch will surface as friction at the API boundary. A team that adopts EBD without BDT will have a well-structured interface and no principled way to test it. A team that adopts BDT without VBD or EBD will be applying a test strategy to a system whose structure cannot honor it. A team that adopts VBD, EBD, and BDT without PD will have a well-structured, well-tested system — and a project plan estimated from user stories that bears no relationship to the architecture that was so carefully designed.

The four frameworks are effective in isolation. They are designed to work together.

11.2 Harmonic Design

The name is drawn from musical acoustics. A vibrating string produces not one frequency but many simultaneously — a fundamental tone and a series of harmonics above it. The harmonics do not contradict the fundamental; they are expressions of the same underlying physical law at different scales. Each harmonic is complete in itself. Together they produce something richer than any single frequency alone.

VBD, EBD, BDT, and PD are harmonics of the same fundamental: organize by anticipated change. Each is complete in isolation. But practiced together, they produce something qualitatively different from their sum. Structural boundaries reinforce each other across layers. A design decision at one layer resonates into all layers. A structural problem at one layer is audible at all layers. A planning failure signals an architectural misalignment, and an architectural insight simplifies the plan. This mutual reinforcement — the hallmark of harmonic structure — is what the name captures.

With four harmonics, the practice reaches its natural completeness. The fundamental (organize by anticipated change) resonates through what to build (VBD), how to present it (EBD), how to verify it (BDT), and how to plan and execute the work (PD). These four concerns — structure, interface, verification, and delivery — span the full lifecycle of a software system. There is no fifth concern that the fundamental addresses. The four harmonics are complete.

Harmonic rather than coherent or unified because the word carries the right connotations: resonance, mutual reinforcement, structure that emerges from a shared fundamental rather than being imposed from outside. A harmonic system is not forced into alignment — it finds alignment naturally when all parts are tuned to the same principle.

Design because the practice governs how systems are conceived, structured, verified, planned, and evolved — not just implemented. It applies before the first line of code, persists through all phases of a system’s life, and informs decisions across backend, interface, test strategy, and project planning equally.

12. Relationship to Existing Practices

12.1 Domain-Driven Design

Domain-Driven Design (Evans, 2003) organizes systems around the conceptual model of the business domain. Bounded contexts define where one model ends and another begins. HD does not conflict with DDD; it adds a dimension to it. Bounded contexts are often natural volatility boundaries — a domain model that changes for one reason is a natural VBD Manager scope. HD can be read as a structural model that operates within DDD bounded contexts, governing how each context organizes its own components rather than how contexts relate to each other.

The distinction: DDD draws boundaries between domains. HD draws boundaries within tiers at every layer. Both are necessary in large systems.

12.2 Clean Architecture

Martin’s Clean Architecture (2017) organizes systems by dependency direction: high-level policy should not depend on low-level detail. The Dependency Rule — source code dependencies point inward, toward higher-level policy — maps closely onto HD’s tier hierarchy: Engines depend on nothing domain-specific, Managers depend on Engine and Accessor interfaces, and Accessors depend on external systems. HD adds the volatility-based reason for these dependency directions: Engines are inward because they are the most volatile; Accessors are outward because they isolate environmental volatility.

Harmonic Design and Clean Architecture agree on the communication topology. HD explains why that topology is correct.

12.3 Atomic Design

Brad Frost’s Atomic Design (2013) provides a vocabulary for hierarchical component composition in interfaces: atoms, molecules, organisms, templates, pages. This addresses structural composition at the visual level. EBD — and by extension HD — addresses structural composition at the behavioral level: Interactions, Flows, Experiences.

Both taxonomies are valid and non-competing. An Interaction (EBD) might be composed of several atoms and molecules (Atomic Design). An Experience might correspond to a page template. The two models answer different questions: Atomic Design asks how visual elements compose; EBD asks how behavioral intent composes.

12.4 Test-Driven Development and Behavior-Driven Development

TDD treats tests as a design tool: writing tests before code forces clarity about interfaces and responsibilities. BDD extends this to behavior specifications. HD extends further: the structure of the system determines the structure of the tests, which in turn validates the design of the system. TDD and BDD inform how you write tests at a given level. BDT tells you which level a given component belongs to.

TDD and BDD can be practiced within an HD system without conflict. HD provides the structural scaffolding; TDD/BDD provides the micro-design discipline within each structural tier.

12.5 Critical Path Method and Earned Value Management

CPM (Kelley and Walker, 1959) and EVM (Fleming and Koppelman, 2010) provide the mathematical foundation for Project Design’s network analysis, float calculation, and progress tracking. HD does not replace these techniques — PD integrates them. What HD adds is the source of the network: the architectural decomposition. In conventional CPM, the activity list and dependencies are constructed manually. In HD, they are derived from the architecture. The network is not an estimate of the work — it is a structural consequence of the design.

12.6 Agile Methodologies

Project Design — and by extension HD — is not opposed to agile delivery. The distinction is between planning and execution. PD provides the planning discipline that determines what is built, in what order, with what resources, and at what cost. Agile methods provide the execution discipline that governs how the work is performed day to day. The Feed Me or Kill Me decision maps to Sprint Zero or PI Planning commitment. Sprint velocity maps to the earned value rate. The S-curve maps to the cumulative flow diagram or burnup chart.

Good agile combines architectural discipline with iterative delivery. Bad agile uses agile terminology as a justification for skipping architecture and project design. HD provides the structural foundation that makes agile delivery effective.

13. Observations from Practice

The following observations are drawn from applying Harmonic Design across multiple systems over an extended period. They are not prescriptive — they are patterns that have emerged consistently enough to warrant documentation.

13.1 The Structure Reveals Itself Gradually

Teams adopting HD for the first time tend to produce architectures that are partially volatility-aligned. Some components are clean VBD roles; others are hybrids that span two tiers. This is normal and expected. The structural map becomes clearer with each requirement change, because changes reveal which components are truly volatile and which are stable. The first decomposition is a hypothesis. The first six months of requirement changes are the experiment. By the end of the first year, the boundaries that survive are the right boundaries.

13.2 Testing Difficulty Is the Earliest Signal

Before the architecture reveals its weaknesses through requirement changes, the test suite reveals them through testing difficulty. A component that is hard to unit test is almost always misclassified or mis-scoped. Teams that pay attention to testing difficulty as a structural diagnostic — rather than as a complaint about the testing framework — catch boundary problems months before they manifest as change-locality failures.

13.3 Estimation Accuracy Improves with Structural Maturity

On first application, HD-derived project plans are better than requirement-based estimates but still imperfect — the team has not yet calibrated its estimation ranges to the specific volatility characteristics of its domain. After two or three project cycles, the calibration tightens. Teams learn that their Engines take longer than expected (because functional volatility is underestimated) and their Utilities take less time than expected (because cross-cutting concerns are overestimated). The structural map provides the calibration framework; repeated application provides the calibration data.

13.4 The Plan Absorbs Requirement Changes Without Replanning

This is the observation that most surprises teams new to HD. When a requirement change adds a new Engine and a new Flow, the project plan update is mechanical: insert two work packages, add dependency edges, recalculate the critical path. There is no replanning meeting. There is no argument about scope. The structural map determines what the change is, and the project network absorbs it. Teams accustomed to requirement changes triggering full replanning sessions find this disorienting at first — and then indispensable.

13.5 Configuration-Driven Systems Compound

Systems built with strict HD boundary discipline tend to become more configurable over time, not less. Each new Engine added with clean boundaries is another Engine that configuration can compose. Each new Flow added with clean state isolation is another Flow that configuration can sequence. The configurability is not designed in — it emerges from the structural discipline. After several years of consistent practice, teams find themselves building new capabilities entirely from configuration, without writing new code. This is not an aspiration; it is a consistent empirical observation.

13.6 Conway’s Law Works Both Ways

HD aligns team boundaries with component boundaries, which aligns with volatility boundaries. When this alignment is maintained, Conway’s Law becomes an asset: the team structure reinforces the architectural structure. When it is not maintained — when team boundaries cross volatility boundaries — the architectural discipline degrades, because the organizational pressure to coordinate across team boundaries introduces the same coupling that HD is designed to prevent. Organizational alignment is not optional; it is a structural precondition.

13.7 The Fourth Pillar Changes the Conversation with Management

Before PD, the conversation between engineering and management is adversarial by default: engineering estimates, management negotiates, both sides distrust the outcome. After PD, the conversation is structured: here are three options with quantified cost, schedule, and risk; which do you prefer? The options are not opinions — they are structural consequences of the architecture. Management selects from the feasible zone. Engineering executes the selected plan. The adversarial dynamic is replaced by a decision-making protocol. Teams that adopt PD as part of HD consistently report that the most significant change is not in planning accuracy — it is in the quality of the relationship between engineering and management.

14. Conclusion

Software systems fail over time not because of poor initial design, but because change accumulates faster than the architecture can absorb it. The conventional response — adopt a framework, apply it to one layer, and manage the other layers by convention — does not solve the problem. It solves one layer of the problem and leaves the others unaddressed.

Harmonic Design is the practice of solving all four simultaneously. Not by introducing new concepts, but by recognizing that four independently developed frameworks — VBD, EBD, BDT, and PD — share the same organizing principle, the same structural map, and the same communication rules. They are not separate tools. They are one tool, applied at four layers.

The structural isomorphism is the central insight. A Manager corresponds to an Experience corresponds to E2E scope corresponds to an integration milestone work package. An Engine corresponds to a Flow corresponds to unit scope corresponds to a core work package. A Resource Accessor corresponds to an API Accessor corresponds to integration scope corresponds to a boundary work package. Utility corresponds to Utility everywhere. Once a team sees this correspondence, the four frameworks become one. Learning one teaches the others. A problem in one layer predicts a problem in the corresponding position in the others. A fix at one layer guides the fix at all layers.

The emergent properties of this coherence — change locality across all layers, test scope determinism, estimation accuracy from volatility alignment, structural legibility, diagnostic consistency, risk quantification from architecture, configuration-driven composition — are not achievable by any individual framework applied to a single layer. They require the full system: backend, interface, test strategy, and project plan organized by the same map, enforcing the same boundaries, communicating by the same rules.

The addition of Project Design as the fourth pillar completes the practice. VBD governs what to build. EBD governs how to present it. BDT governs how to verify it. PD governs how to plan, estimate, schedule, and execute the work. All four are readings of the same structural map. All four are tuned to the same fundamental. The architecture is the plan.

Software engineering has accumulated many frameworks for managing complexity. Harmonic Design is a framework that unifies four of them under a single structural discipline — and demonstrates that practicing them as one produces a kind of structural coherence that none achieves alone.

That coherence is the goal. Harmonic Design is the path.

Appendix A: Glossary

• Boundary Violation — An instance where a component invokes another in a way that crosses its permitted communication paths, signaling structural misalignment.
• Change Propagation — How a modification flows through all four layers when boundaries are correctly aligned.
• Coherence — The state where all four pillars reflect the same structural boundaries and the same volatility classifications.
• Communication Rules — Constraints on inter-component invocation that hold across all pillars and prevent dependency erosion.
• Configuration-Driven Composition — The practice of assembling components through external configuration rather than hardcoded structure, enabling change absorption without code modification.
• Core Scenario — A high-level behavior (use case, user journey, test scenario, project milestone) that validates structural decisions at every layer.
• Diagnostic Signal — A difficulty indicator (testing difficulty, estimation difficulty, boundary pressure) that reveals structural misalignment.
• Framework Cross-Reference — The mapping table showing equivalent concepts across VBD, EBD, BDT, and PD.
• Harmonic Design — A unified software engineering framework that applies volatility-first reasoning consistently across backend architecture (VBD), interface architecture (EBD), test strategy (BDT), and project planning (PD), producing structural isomorphism across all four layers.
• Layer — One of the four system concerns addressed by HD: backend, interface, tests, project plan.
• Peer Prohibition — The universal rule that components at the same tier must not invoke each other directly.
• Pillar — One of the four constituent frameworks of Harmonic Design: VBD, EBD, BDT, or PD.
• Structural Isomorphism — The property where component roles, communication rules, and volatility boundaries correspond exactly across backend, interface, test, and project layers.
• Structural Map — The single decomposition drawn from volatility analysis that governs all four pillars simultaneously.
• Tier Correspondence — The mapping between equivalent roles across pillars: Manager↔Experience↔E2E scope↔Integration Milestone WP.
• Volatility Axis — A dimension along which change is expected: functional, non-functional, cross-cutting, or environmental.
• Volatility-First Reasoning — The practice of using anticipated change as the primary driver of all structural decisions.

Appendix B: Framework Cross-Reference

Appendix C: HD Adoption Checklist

A team beginning to adopt Harmonic Design should verify the following at each layer:

Backend (VBD):

• Every component is classified as Manager, Engine, Resource Accessor, or Utility
• Engines do not call sibling Engines or hold workflow logic
• Managers do not embed business rules
• Accessors do not apply policy; they translate and return
• Communication rules are enforced by code review and structural convention

Interface (EBD):

• Every component is classified as Experience, Flow, Interaction, or Utility
• Flows do not call sibling Flows or make direct API calls
• Experiences hold accumulated journey state and are the sole API communicators
• Interactions are atomic; they emit events and receive props
• Utilities have no domain-specific knowledge

Tests (BDT):

• Every Engine and Flow has a unit test suite with all Accessor/API dependencies mocked
• Every Manager-to-Engine, Engine-to-Accessor, and Experience-to-Flow seam has integration tests
• Every core use case and user journey has an E2E scenario
• Test difficulty at any level is treated as a structural signal, not a testing problem

Project Plan (PD):

• Every component maps to exactly one work package
• Dependencies in the project network mirror dependencies in the architecture
• Estimation ranges are calibrated to volatility tier: widest for Engines/Flows, tightest for Utilities
• The critical path is identified and the best resources are assigned to it
• At least three project options (conservative, balanced, aggressive) have been presented to management
• Risk is quantified from float distribution, not from subjective assessment
• Staffing assignments follow the one-to-one rule: one component, one developer
• Staged delivery aligns with the architectural tier hierarchy: Utilities first, Managers last

Coherence:

• Backend tiers correspond to interface tiers (Manager to Experience, Engine to Flow, etc.)
• A change in requirements touches one component per tier, per layer, and one work package in the plan
• The same core scenarios validate structural boundaries in VBD, EBD, BDT, and PD
• The project plan absorbs architectural changes through insertion and recalculation, not replanning
• Estimation difficulty at any work package can be traced to a volatility classification problem in the corresponding component

Appendix D: Case Study — Healthcare Scheduling Platform

This appendix presents a fictional but realistic example of Harmonic Design applied end-to-end across all four pillars. The system is a healthcare scheduling platform that allows patients to book appointments with providers, checking eligibility, searching for available providers, and selecting time slots.

D.1 VBD Decomposition (Backend)

The backend is decomposed into the following components:

Managers:
– SchedulingManager — orchestrates the complete appointment booking workflow: receive patient request, check eligibility, search providers, reserve time slot, confirm appointment.
– NotificationManager — orchestrates notification delivery across channels (email, SMS, push) after booking events.

Engines:
– EligibilityEngine — evaluates whether a patient is eligible for a requested appointment type based on insurance, referral requirements, and plan restrictions.
– ProviderMatchEngine — matches patients to providers based on specialty, location, network participation, and patient preferences.
– SlotAllocationEngine — resolves time slot availability against provider calendars, handles conflict detection, and applies scheduling rules (minimum gap between appointments, maximum daily load).
– ConfirmationEngine — generates confirmation records, assigns confirmation numbers, and produces the confirmation payload for both patient and provider.

Resource Accessors:
– PatientAccessor — reads and writes patient records from the patient database.
– ProviderAccessor — reads provider profiles, credentials, and network participation from the provider directory.
– CalendarAccessor — reads and writes provider calendar entries from the calendar system.
– InsuranceAccessor — calls external insurance verification APIs to validate coverage and benefits.
– NotificationAccessor — sends notifications through external email, SMS, and push notification services.

Utilities:
– DateTimeUtility — timezone conversions, business hour calculations, recurring schedule generation.
– ValidationUtility — input validation, sanitization, format verification.
– AuditUtility — audit trail generation, compliance logging.

D.2 EBD Decomposition (Interface)

Experiences:
– AppointmentBookingExperience — the complete patient-facing booking journey. Receives configuration, composes Flows, accumulates journey state (selected provider, selected slot, confirmed appointment), and makes the single API call to the backend when the journey is complete.

Flows:
– ProviderSearchFlow — guides the patient through searching for a provider: enter specialty, enter location, view results, select provider. Emits the selected provider upward to the Experience.
– TimeSlotSelectionFlow — presents available time slots for the selected provider, allows date navigation, and captures the patient’s slot selection. Emits the selected slot upward.
– PatientInfoFlow — collects or confirms patient information: demographics, insurance, contact details. Emits completed patient info upward.
– ConfirmationFlow — presents the appointment summary, captures patient confirmation, and displays the confirmation number. Emits confirmation status upward.

Interactions:
– SpecialtyPickerInteraction — dropdown for selecting medical specialty.
– LocationInputInteraction — location entry with autocomplete.
– ProviderCardInteraction — displays a single provider’s information; emits selection event.
– CalendarGridInteraction — renders available time slots in a calendar view; emits slot selection event.
– InsuranceFormInteraction — insurance information entry fields; emits form completion event.
– ConfirmationSummaryInteraction — read-only appointment summary display.

Utilities:
– FormValidationUtility — client-side validation rules.
– FormatUtility — date, time, phone, and address formatting.

D.3 BDT Test Strategy

The test strategy maps directly to the structural decomposition:

Unit tests:
– EligibilityEngine: given patient attributes and insurance data (mocked via InsuranceAccessor), returns correct eligibility determination for each coverage scenario.
– ProviderMatchEngine: given patient criteria and provider list (mocked via ProviderAccessor), returns correctly ranked and filtered matches.
– SlotAllocationEngine: given provider calendar (mocked via CalendarAccessor), resolves availability correctly including conflict detection and scheduling rules.
– ProviderSearchFlow: given provider list (via props from Experience), renders search UI, steps through Interactions, emits selected provider.
– TimeSlotSelectionFlow: given available slots (via props), renders calendar, emits selected slot.
– Each Interaction: given props, renders correctly, emits correct events on user action.

Integration tests:
– SchedulingManager to EligibilityEngine seam: real Manager, mocked Engine — verify Manager routes correctly based on every eligibility status the Engine can return (eligible, ineligible, pending-referral, coverage-expired).
– SchedulingManager to SlotAllocationEngine seam: verify Manager handles slot-available, slot-taken, no-slots-available responses.
– AppointmentBookingExperience to ProviderSearchFlow seam: verify Experience passes correct state and handles Flow completion correctly.
– AppointmentBookingExperience to TimeSlotSelectionFlow seam: verify Experience receives selected slot and transitions to the next Flow.

E2E tests:
– Happy path: patient searches for provider, selects slot, confirms appointment — end to end with real infrastructure.
– Ineligible patient: patient is denied booking due to insurance restriction — verify the system handles gracefully without partial booking.
– No available slots: patient searches, no slots match — verify empty state and alternative suggestions.

D.4 PD Project Plan

The project plan is derived directly from the architecture:

Work Packages (derived from components):

Critical Path: DateTimeUtility (5) -> CalendarAccessor (10) -> SlotAllocationEngine (15) -> SchedulingManager (15) -> Backend-UI Integration (10) = 55 days

Parallel paths through InsuranceAccessor (15) -> EligibilityEngine (15) = 30 days from utility start, with 10 days of float relative to the critical path.

The UI critical path runs: FormValidationUtility (5) -> InsuranceFormInteraction (5) -> PatientInfoFlow (10) -> AppointmentBookingExperience (15) -> Backend-UI Integration (10) = 45 days. This path has 10 days of float relative to the backend critical path.

Three Options:

Conservative (70 days, lowest risk): All-normal durations plus 15-day decompression buffer. Risk index approximately 0.35. Staffing: 4 developers peak.

Balanced (55 days, moderate risk): All-normal durations, no buffer. Risk index approximately 0.50. Staffing: 6 developers peak. Best resources assigned to SlotAllocationEngine and EligibilityEngine (highest functional volatility, critical path or near-critical).

Aggressive (42 days, highest risk): Critical-path compression on SlotAllocationEngine (15 to 10 days) and SchedulingManager (15 to 10 days). Network restructuring to enable parallel Engine development against Accessor interfaces. Risk index approximately 0.70. Staffing: 8 developers peak. Requires top resources on all critical-path activities.

D.5 Mid-Project Requirement Change: Adding Telehealth

Midway through construction, a new requirement arrives: the platform must support telehealth appointments in addition to in-person visits. Patients should be able to choose between telehealth and in-person when booking.

How the change propagates through all four layers:

VBD (Backend):
A new TelehealthEngine is added. It evaluates whether a requested appointment type is eligible for telehealth, generates virtual meeting room configurations, and produces telehealth-specific confirmation details. The SchedulingManager is updated to invoke TelehealthEngine when the appointment type is telehealth — a configuration-driven routing decision. A new VideoAccessor is added to integrate with the video conferencing platform. No existing Engines change.

EBD (Interface):
A new VisitTypeFlow is added, positioned before ProviderSearchFlow in the AppointmentBookingExperience. It presents the patient with a choice between in-person and telehealth. A VisitTypeInteraction (radio button group) emits the selection. The Experience uses the visit type to configure downstream Flows — ProviderSearchFlow filters by telehealth-capable providers when applicable; TimeSlotSelectionFlow shows virtual slots. No existing Flows change their internal logic; they receive different configuration from the Experience.

BDT (Tests):
New unit tests: TelehealthEngine (given appointment request, returns telehealth eligibility and room config), VisitTypeFlow (renders visit type selection, emits choice). New integration tests: SchedulingManager to TelehealthEngine seam (verify routing for telehealth vs. in-person), AppointmentBookingExperience to VisitTypeFlow seam (verify Experience handles telehealth selection and configures downstream Flows). New E2E scenario: patient books a telehealth appointment end to end. No existing tests change.

PD (Project Plan):
Three new work packages: TelehealthEngine (core, 10 days, depends on PatientAccessor), VideoAccessor (boundary, 10 days, depends on infrastructure), VisitTypeFlow (core UI, 5 days, depends on VisitTypeInteraction). One new Interaction: VisitTypeInteraction (5 days). Dependency edges are inserted. The critical path is recalculated. If TelehealthEngine is not on the critical path (because it runs parallel to SlotAllocationEngine with sufficient float), it can be staffed with available resources. If it is on the critical path, the project duration extends by its net impact after float consumption.

The structural map contained the change at every layer. One new Engine, one new Accessor, one new Flow, one new Interaction, corresponding tests, corresponding work packages. Existing components absorbed the change through configuration. The plan absorbed the change through insertion and recalculation. No replanning session was needed. No existing code was modified (only the Manager’s routing configuration and the Experience’s Flow composition configuration).

Figure 6 — Telehealth change propagation: new components (highlighted) inserted at each layer, existing components unchanged.

References and Influences

William Christopher Anderson
Anderson, William Christopher. Volatility-Based Decomposition in Software Architecture. February 2026.
Anderson, William Christopher. Experience-Based Decomposition. March 2026.
Anderson, William Christopher. Boundary-Driven Testing. March 2026.
Anderson, William Christopher. The Design of Projects: A Practitioner-Oriented Articulation. February 2026.

Harmonic Design synthesizes these four frameworks. The role taxonomies, volatility axes, communication rules, estimation methodologies, and validation mechanisms in this paper are taken from these sources. HD’s contribution is the recognition of their structural isomorphism and the articulation of the coherence properties that emerge from practicing all four together.

Juval Lowy
Lowy, Juval. Righting Software. Addison-Wesley, 2019.

The Manager-Engine-Resource Accessor taxonomy that underlies VBD — and by extension the orchestration-execution-accessor tier structure that appears in all four HD frameworks — originates in Lowy’s IDesign methodology. The project design methodology that derives project plans from architectural decomposition also originates in IDesign. HD extends IDesign’s backend structural model across the interface, test, and project planning layers.

David L. Parnas
Parnas, David L. “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM, 1972.

Parnas’s information hiding principle — that modules should be designed around design decisions likely to change — is the intellectual foundation of volatility-first decomposition. HD is the system-scale extension of this principle, applied simultaneously at the backend, interface, test strategy, and project planning levels.

Eric Evans
Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.

DDD’s bounded context concept and HD’s tier boundaries are complementary rather than competing. HD operates within bounded contexts, governing how each context organizes its internal structure.

Robert C. Martin
Martin, Robert C. Clean Architecture. Pearson, 2017.

Martin’s Dependency Rule and boundary discipline align with HD’s communication model. HD provides the volatility-based account of why those dependency directions are correct.

Martin Fowler
Fowler, Martin. “The Practical Test Pyramid.” martinfowler.com, 2018.

BDT builds on Fowler’s test pyramid by grounding its levels in structural tiers. HD extends this further by making the test pyramid a consequence of the structural isomorphism across all four layers.

James E. Kelley and Morgan R. Walker
Kelley, James E.; Walker, Morgan R. “Critical-Path Planning and Scheduling.” Proceedings of the Eastern Joint Computer Conference, 1959.

The Critical Path Method provides the mathematical foundation for the network analysis, float calculation, and critical path identification used in Project Design and, by extension, in the HD project planning layer.

Quentin W. Fleming and Joel M. Koppelman
Fleming, Quentin W.; Koppelman, Joel M. Earned Value Project Management. Fourth Edition. Project Management Institute, 2010.

Earned value management provides the tracking and projection techniques used during project execution in the PD pillar of HD.

Frederick P. Brooks Jr.
Brooks, Frederick P. The Mythical Man-Month. Addison-Wesley, 1975.

Brooks’s observation that adding people to a late project makes it later is reflected in PD’s treatment of staffing, compression limits, and the one-to-one rule that aligns with HD’s component boundaries.

Author’s Note

The author does not claim to have originated the ideas that Harmonic Design draws on. Volatility-based thinking has antecedents in Parnas, Lowy, and others. The test pyramid predates this paper by decades. Experience-centered design has a long history in the HCI and UX literature. Architecture-derived project planning has antecedents in CPM, EVM, and IDesign. The frameworks articulated in VBD, EBD, BDT, and PD name and structure these ideas for consistent application — they are the author’s articulations, not the author’s inventions.

Harmonic Design is the novel contribution. The specific recognition — that VBD, EBD, BDT, and PD are harmonics of the same fundamental principle; that their structural tiers are isomorphic; that practicing all four together produces properties none achieves alone; that the architecture is the plan; and that this coherence is what enables the configuration-driven capability described in Section 8 — has not, to the author’s knowledge, been articulated before. After twenty years of practicing this way across many systems and organizations, the author has not encountered another practitioner who applies all four frameworks as a unified discipline, or who describes the resulting configurability and planning predictability as structural consequences rather than architectural features.

The configurability properties described in Section 8 are not theoretical. The author has built production systems driven entirely by configuration — backends that derive complete workflow behavior from schema, interfaces that compose from YAML, and factories that extend their own capability through configuration uploads without code deployment. The project planning properties described in Section 6 are equally empirical — the author has planned and delivered projects where the project network was derived from the architectural decomposition, where requirement changes were absorbed through work package insertion rather than replanning, and where management selected from three quantified options rather than negotiating a single estimate. These outcomes were not engineered in as features. They emerged from the structural discipline described in this paper, applied consistently over time.

The four pillars govern the complete lifecycle: VBD governs what to build, EBD governs how to present it, BDT governs how to verify it, and PD governs how to plan and execute the work. With all four in place, the structural map drawn from volatility analysis governs every phase of a software system’s lifecycle — from initial decomposition through project planning, implementation, testing, and ongoing evolution. The architecture is the plan. The plan is the architecture. They are one map, read four ways.

Harmonic Design is a framework, but not in the sense of a tool to be picked up and applied mechanically. It is a framework in the sense of a structural discipline — one that compounds over time, producing qualitatively different kinds of systems the longer it is applied with consistency.

Distribution Note

This document is provided for informational and educational purposes. It may be shared internally within organizations, used as a reference in architectural and design discussions, or adapted for non-commercial educational use with appropriate attribution. All examples are generalized and abstracted to avoid disclosure of proprietary or sensitive information.