Integrated Design¶
A design process jointly evaluates and revises coupled choices across specialties against shared whole-system goals.
Core Idea¶
Integrated design is a process for resolving coupled design choices across specialties against shared whole-system goals. A choice in one domain changes the feasible or desirable choices in another: building-envelope geometry can affect daylight and thermal loads; hardware architecture can alter which software functions meet timing and energy constraints. When such dependencies matter, separate local optimizations can lock in incompatible commitments. Integrated design makes the cross-effects visible early enough to revise the choices together.[1][2][3]
The defining event is not a meeting attended by many specialists. It is the feedback loop from one specialty's proposal through shared system evaluation back to revisions by the affected specialties. A charrette, common model, simulation, prototype or coordinated review can support that loop, but no single tool is mandatory. In a whole-building guide, an early multidisciplinary team sets goals and uses building simulation to evaluate linked envelope and system choices. In embedded-system co-design, a shared model helps allocate functions between hardware and software under performance constraints.[1][2]
Nor does integration require every component to remain entangled forever. The team may deliberately modularize a design and reduce coupling so that later work can proceed independently. That is itself a jointly evaluated design decision, not the opposite of integrated design. The key question is whether the important cross-effects were analyzed before interfaces or specifications became difficult to change.
Structural Signature¶
- Whole-system objective: measurable or otherwise explicit requirements define what success means across specialties.
- Coupled variables: at least two specialties control choices that constrain each other.
- Shared representation or evidence: diagrams, simulation, prototypes or requirements make those dependencies discussable and testable.[1][2]
- Cross-specialty decision path: affected experts can influence one another's choices before commitment.
- Iteration: results feed back into design revision until a coherent combination is selected.
- Interface or decoupling choice: where feasible, the team can reduce future dependence by choosing clearer boundaries, but only after evaluating their effects.
Condensed: shared goals + coupled variables + cross-specialty evidence + revisable joint tradeoffs = integrated design.
Sig role-phrases: shared system objective; specialist-controlled coupled variables; common design evidence; cross-specialty decision path; revision before commitment.
What It Is Not¶
- Not merely multidisciplinary attendance. A meeting may collect opinions while decisions remain separate and unalterable.
- Not necessarily an early charrette. A charrette is one documented mechanism; shared models and repeated technical reviews can also support integration.[1]
- Not guaranteed to produce a smaller HVAC system, lower cost or any fixed performance gain. Outcomes depend on goals, constraints, design options and implementation.
- Not equivalent to systems integration after construction. Combining fixed subsystems late may reveal conflicts but has less freedom to redesign their constitutive choices.
- Not the absence of modularity. Interfaces chosen with knowledge of cross-effects can reduce future coupling.
- Not any “holistic” label. The relevant dependence, shared evaluation and actual revision must be identifiable.
- Not the Wikipedia seed's failure taxonomy as a universal law. “Silent,” “partial” and “disparate” design are useful terms from a particular literature, not mandatory stages of every unsuccessful project.
Scope of Application¶
In whole-building design, architecture, structure, mechanical systems, daylighting, users and operations can interact. The Los Alamos guide calls for an early multidisciplinary team, agreed performance goals and building-energy simulation. The design charrette is described as a way to align participants early; later design still needs repeated decisions and checks. An orientation change might improve daylight while worsening glare or cooling demand, so a single-discipline “best” choice is insufficient.[1]
In embedded hardware/software co-design, functions can be implemented in either hardware or software under constraints on performance, flexibility, energy and architecture. NIST researchers describe a shared feature-based model that connects component choices and configurations. Earlier co-design research explicitly begins from system-level specifications and performs hardware/software partitioning and architecture generation. This is integrated design even though no building charrette is involved.[2][3]
In product and production-system design, a product's geometry can constrain assembly tooling and sequence. The broad identity would be present if product and manufacturing choices are jointly revised under common requirements, but this entry relies primarily on the directly sourced building and embedded settings. It does not assert that every concurrent-engineering process is interchangeable with integrated design.
Clarity¶
Consider a building team. The architect proposes broad glazing for daylight; the mechanical engineer predicts a larger cooling load; an energy model shows that shading and glazing specification could preserve useful daylight while reducing thermal demand. The team revises form and systems together. This is stronger than an architect submitting a fixed facade to a mechanical engineer who can only size equipment around it.
Now consider an embedded controller. A time-critical function might be realized in firmware or dedicated logic. The hardware choice changes power, cost and update flexibility; the software choice changes processor load and timing. A shared model allows the two specialties to revise the partition before the board and code interfaces are frozen.[2][3]
Manages Complexity¶
Integrated design organizes a high-dimensional problem by making cross-specialty dependencies explicit. It reduces surprise rework from choices that looked locally sound but failed at system level. It can also add coordination overhead, so its value is greatest where coupling is material. A useful process does not demand that everyone decide everything together; it identifies the interfaces with significant cross-effects, supplies shared evidence, and escalates the few decisions that cannot be safely separated.
Abstract Reasoning¶
Map each design variable to the specialty that controls it and each system-level goal it affects. Draw dependencies: for example, facade configuration → solar gain → cooling load → equipment size. Identify decisions with strong two-way or cascade effects and keep them revisable. Evaluate combinations with models or prototypes that all affected specialties trust, rather than adding isolated optimums. Record tradeoffs, then either commit to an integrated solution or deliberately decouple through an interface whose costs have been tested.[1][2]
The diagnostic question is: Which design decision changes another specialty's feasible choices, and can the team revise both before commitment?
Knowledge Transfer¶
The general pattern is joint optimization under coupling. The design-domain identity adds artifacts, specialist responsibilities, requirements, simulation or prototypes, and staged commitment. An analogy to coordinating unrelated tasks lacks the coupled-design residual unless the tasks change each other's feasible solutions.
Examples¶
Building envelope and HVAC¶
The Los Alamos guide's sample goals, not measured project results, include 50% less energy use than an ASHRAE 90.1-compliant building, daylighting that offsets electrical lighting, and initial cost no more than 5% above a conventional building (printed p. 14). Its p. 16 caution adds a constraint: daylight that causes work-surface glare or inadequate light fails indoor-environment quality even if it appears to reduce electric-light load. Follow the decision path: the architecture and lighting proposal is not “maximize glazing”; it is to choose window, shading, lighting and controls together, test energy and work-surface conditions, and revise whichever variables violate a shared goal. The guide recommends energy simulation for envelope/system decisions (p. 12). It does not report that a specific LANL project actually achieved the sample 50% target or record a numerical model iteration; those outcomes are not asserted here.[1]
Mapped back: sample energy, daylight, comfort and budget goals are the shared objective; envelope, lighting and controls are coupled variables; simulation and glare check are shared evidence; architects, lighting and mechanical specialists can revise the package before specifications harden. The conditional revision is the method prescribed by the guide, not a fabricated observed meeting.
Embedded hardware and software¶
Zha, Fenves and Sriram's original NIST abstract specifies an extended Core Product Model, UML representations of embedded artifacts/components/features, feature–component mapping and a virtual prototype assembled from hardware and software components. It states that a case study appears in the paper, but the accessible abstract does not expose that case's device, measured result or revision history. A constructed execution of the paper's stated procedure is a time-critical feature with two candidate mappings: software on a processor retains update flexibility but must meet the timing requirement; dedicated logic may ease timing at the cost of hardware commitment. Mapping the same feature to both candidate configurations, testing timing and adaptability against the common specification, and revising the allocation before architecture generation is the co-design operation. No performance numbers or observed outcome are attributed to NIST.[2][3]
Mapped back: the time-critical feature is the shared objective; processor allocation versus dedicated logic are coupled hardware/software variables; feature–component model and virtual prototype are shared evidence; the allocation is revisable in the constructed execution. The original abstract establishes the method, not the specific constructed choice's outcome.
Stormwater budget transfer in the LANL guide¶
The same guide gives a more concrete illustrative design option on printed p. 17: infiltrating stormwater on site can eliminate a detention pond and storm sewers, and the resulting savings can be applied elsewhere in the project while respecting an overall budget. Trace the coupling: site and civil design change the drainage solution; cost analysis changes the funds available to other building features; a whole-project decision evaluates both. The guide does not specify a dollar amount or identify a completed building for this illustration, so the example demonstrates a decision mechanism, not a measured saving at a named facility.[1]
Mapped back: overall budget and sustainability are shared objectives; drainage layout and allocations elsewhere are coupled variables; the guide's comparison of pond/sewers versus infiltration is joint evidence; choosing infiltration would revise the site design and the remaining budget allocation together.
Ceremonial meeting near miss¶
Each specialist has already finalized a subsystem. They attend one presentation where no one may change scope or interfaces. The project is multidisciplinary, but it lacks the revisable joint tradeoff at the center of integrated design.
Mapped back: specialist agents and subsystem decisions exist, but shared evaluation and a revision path are absent; attendance cannot substitute for the missing constitutive roles.
Structural Tensions¶
Local performance versus whole-system fit. A daylighting specialist can increase daylight and reduce electric-light demand, yet an unshaded arrangement may produce glare at work surfaces; optimizing the local metric alone can defeat indoor-environment quality. A whole-system constraint protects occupants and the energy target, but may require giving up some daylight or paying for shading/controls. The guide treats both lighting and IEQ as goals, not one as universally subordinate. Diagnostic: what work-surface and energy evidence would justify the chosen daylight/thermal package?[1]
Early exploration versus commitment discipline. Keeping envelope and systems open permits simulation-informed revisions and avoids forcing the mechanical team to compensate for a frozen facade. Extended iteration, however, consumes design time and can postpone procurement or cost certainty; a team must eventually commit to a coordinated package. Freezing too early transfers unresolved conflicts into costly construction changes, a consequence the LANL guide explicitly warns about. Diagnostic: which linked variables have enough shared evidence to freeze now, and which still carry consequential uncertainty?[1]
Broad coordination versus bounded interfaces. Bringing every specialist into every choice may surface hidden dependencies, but spends scarce attention on decisions that could be handled behind stable interfaces. Modularizing early reduces coordination cost and enables parallel work, but an interface drawn before its cross-effects are understood can hide a real constraint and force later redesign. Integration therefore includes deciding which interfaces warrant joint evidence and which are safe to decouple. Diagnostic: does changing this variable measurably alter another specialty's feasible or desirable solution?[1][2]
Structural–Framed Character¶
Integrated design sits in the mixed structural–framed range. Its dependency-and-feedback loop is recognizable beyond any one artifact: a variable controlled by one specialty changes another specialty's feasible choice, and system evidence feeds back into revision. Yet evaluative weight is substantial: “better” is determined by chosen energy, comfort, timing, cost or maintainability goals, not by a context-free invariant. Human practice matters because specialists have decision rights, requirements are negotiated, and commitments become expensive to reverse. The process can be supported by models but cannot be reduced to model execution alone.
The sources have identifiable institutional settings rather than a single origin for every use of the name. Los Alamos describes a federal-laboratory building-delivery practice with project teams, requests for proposals, charrettes and commissioning; NIST describes an engineering research method for embedded hardware/software configuration. “Integrated design” vocabulary travels between them, but the travel is not proof that their charrettes and UML features are interchangeable. Import of a method would require taking one setting's tools and governance into another; recognizing a similar dependency-and-revision loop does not. A product team may have the structure without using this label, while a building team may use the label ceremonially without a revision path. Its character: a mixed, practice-mediated design-process abstraction whose portable coupling loop is real but whose evidence, authority and success criteria remain domain-framed.[1][2]
Structural Core vs. Domain Accent¶
The portable skeleton is coupled decisions → shared evaluation → revised combination before commitment. Its design-domain mechanism adds artifact specifications, specialists with authority over variables, whole-system performance requirements, models or prototypes and deliberate design freeze. Remove these and the same causal shape might describe scheduling or governance coordination, but it would not yet be integrated Design. Conversely, a gathering of design specialists without coupled-variable revision has the accent without the skeleton.
The named method fails the prime bar because it is a practice family defined by design artifacts and project decision rights; its “shared goals” cannot be assessed without particular values and constraints. The live broad Design prime is the strict genus: every integrated design instance intentionally shapes an artifact under interacting purposes and constraints. Interdependence and Feedback are component analogies, not automatic DAG ancestors. A future substrate-neutral prime would need independent cases of coupled choice and joint revision outside design, with its boundary against generic collaboration made explicit. The building and embedded sources show two design subdomains, not that wider proof.
Instantiates / Related Primes¶
This entry is a kind of Design.
- Design: the process creates an artifact under requirements and constraints.
- Interdependence: choices in one subsystem change choices elsewhere.
- Feedback: whole-system evaluation revises local proposals.
Design is the strict genus in this placement. Interdependence and Feedback remain conceptual relationships, not additional parent edges.
Relationships to Other Abstractions¶
Current abstraction Integrated Design Domain-specific
Parents (1) — more general patterns this builds on
-
Integrated Design is a kind of Design Prime
Integrated design is a specialized design process with coupled cross-specialty revision.Integrated design intentionally shapes an artifact under interacting purposes and constraints; cross-specialty joint revision specializes the live Design genus.
Neighborhood in Abstraction Space¶
Integrated Design sits in a sparse region of the domain-specific corpus (97th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Software Evolution Laws & Code Smells (17 abstractions)
Nearest neighbors
- Performative Architecture — 0.78
- System of Systems Engineering — 0.76
- Capability Management in Business — 0.76
- Change impact analysis — 0.76
- Goal programming — 0.76
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
Design Thinking emphasizes a family of human-centered problem-framing and iteration methods, which may be used in integrated design but does not by itself require coupled specialties. Systems Integration often assembles components and may occur after major design choices. Co-design in embedded engineering is a strong instance; participatory co-design with users is a different emphasis that can overlap without being identical. Concurrent Engineering can include related joint product/process design but should be compared by the actual dependency and revision structure.[2][3]
References¶
[1] Los Alamos National Laboratory, Sustainable Design Guide, Chapter 2 “Whole-Building Design,” hosted by U.S. Department of Energy, early team, goals, simulation and charrettes. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l
[2] Zha, Fenves and Sriram, “A Feature-Based Approach to Embedded System Hardware and Software Co-Design,” NIST (2005), original shared-model research. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j
[3] Abid et al., “Hardware/Software Co-Design Methodology for Design of Embedded Systems” (1998), original system-level specification and partitioning research. registry ↩a ↩b ↩c ↩d ↩e