Skip to content

Stovepipe System

Prime #
1211
Origin domain
Software Computing
Subdomain
enterprise architecture → Software Computing
Aliases
Silo Architecture

Core Idea

A stovepipe system is the structural pattern in which a collection of capabilities is built as a set of vertical stacks — each handling its own data, infrastructure, identifiers, conventions, interface, and operational tooling — with no horizontal layers shared across stacks. Functions that logically belong to a shared concern (storage, identity, communication, logging, classification, authority over a domain object) are duplicated inside each stack and isolated from the other stacks' versions of the same concern. Cross-stack interaction is either impossible or routed through expensive, brittle, custom integrations bolted on after the fact.

The structural commitment is vertical concentration of all concerns inside each functional silo, with no horizontal sharing layer. Each vertical is internally consistent and locally efficient; the system-of-systems it composes is globally incoherent. The local optimization of each vertical produces global pathologies: duplicated work, conflicting definitions of the same entity, inability to compose capabilities, integration projects that multiply with the number of stack-pairs to be joined, and maintenance cost scaling super-linearly because every cross-cutting change must be repeated across all stacks. The pattern is sharply distinct from healthy modularity (modules with defined horizontal interfaces), from coupling (excess interconnection between modules), and from a monolith (a single undifferentiated stack). It isolates one specific configuration — parallel verticals that should be sharing horizontal infrastructure but are not — and points at one corresponding intervention: extract horizontal layers and replace the duplicated functions with a shared substrate. The verticals themselves are not the defect; the absence of a shared horizontal layer between them is.

How would you explain it like I'm…

Towers With No Bridges

Imagine three friends each build their own tall tower of blocks, side by side. Each tower has its own everything and none of them share. If one tower wants a block from another, there's no bridge between them — you'd have to build a clumsy little ramp just for that, every single time.

Stacks That Don't Share

A stovepipe system is when you build a bunch of separate tall stacks that should be sharing things but don't. Each stack has its own copy of everything — its own storage, its own way of naming things, its own tools — and they're walled off from each other. Inside, each stack works fine on its own. But put together, the whole thing is a mess: the same work gets done over and over, the stacks disagree about what things even mean, and connecting any two of them takes a special, fragile custom bridge. The fix is to pull out the shared parts and make one common foundation that all the stacks use.

Silos, No Shared Layer

A stovepipe system is a collection of capabilities built as vertical stacks, where each stack handles its own data, infrastructure, identifiers, conventions, and tooling, with no horizontal layers shared across stacks. Things that logically belong to a shared concern — storage, identity, logging, classification — get duplicated inside each stack and isolated from the other stacks' versions. Each vertical is internally consistent and locally efficient, but the system they compose is globally incoherent: duplicated work, conflicting definitions of the same entity, inability to combine capabilities, and integration projects that multiply with the number of stack-pairs you want to join. It's distinct from healthy modularity (modules with defined interfaces), from coupling (too much interconnection), and from a monolith (one undifferentiated stack). The defect isn't the verticals themselves — it's the missing shared horizontal layer between them, and the fix is to extract those horizontal layers into a common substrate.

 

A stovepipe system is the structural pattern in which a collection of capabilities is built as a set of vertical stacks — each handling its own data, infrastructure, identifiers, conventions, interface, and operational tooling — with no horizontal layers shared across stacks. Functions that logically belong to a shared concern (storage, identity, communication, logging, classification, authority over a domain object) are duplicated inside each stack and isolated from the other stacks' versions of the same concern, and cross-stack interaction is either impossible or routed through expensive, brittle, custom integrations bolted on after the fact. The structural commitment is vertical concentration of all concerns inside each functional silo, with no horizontal sharing layer. Each vertical is internally consistent and locally efficient, but the system-of-systems it composes is globally incoherent: the local optimization of each vertical produces global pathologies — duplicated work, conflicting definitions of the same entity, inability to compose capabilities, integration projects that multiply with the number of stack-pairs to be joined, and maintenance cost scaling super-linearly because every cross-cutting change must be repeated across all stacks. The pattern is sharply distinct from healthy modularity (modules with defined horizontal interfaces), from coupling (excess interconnection between modules), and from a monolith (a single undifferentiated stack). It isolates one configuration — parallel verticals that should be sharing horizontal infrastructure but are not — and points at one intervention: extract horizontal layers and replace the duplicated functions with a shared substrate. The verticals themselves are not the defect; the absence of a shared horizontal layer between them is.

Structural Signature

a set of parallel vertical stacks — a shared concern that logically belongs to a horizontal layer — a duplication of that concern inside each stack — an absent horizontal sharing layer — a super-linear integration tax across stack-pairs — a local-efficiency / global-incoherence invariant

The pattern is present when each of the following holds:

  • Parallel verticals. A collection of capabilities each built as a self-contained stack handling its own data, infrastructure, identifiers, conventions, and tooling.
  • A shared concern. A function — storage, identity, communication, classification, authority over a domain object — that logically belongs to all stacks alike.
  • Duplication inside each stack. That shared concern is re-implemented independently within each vertical rather than provided once.
  • An absent horizontal layer. No shared substrate connects the stacks; cross-stack interaction is impossible or routed through brittle custom integrations bolted on after the fact.
  • A super-linear integration tax. Cost scales roughly as N for the verticals plus N(N−1)/2 for pairwise integrations as cross-cutting concerns arise — quadratic rather than linear in N.
  • A local-global invariant. Each vertical is internally consistent and locally efficient while the system-of-systems is globally incoherent: duplicated work, conflicting entity definitions, and uncomposable capabilities.

The components compose so that the defect is located in the missing horizontal layer, not the verticals themselves: the structure distinguishes the pattern from healthy modularity, from coupling, and from a monolith, and points at one intervention — extract the shared concern into a horizontal substrate and retire the N duplicates.

What It Is Not

  • Not modularity. modularity is decomposition into units with defined interfaces; a stovepipe is parallel verticals with no horizontal sharing layer between them — the defect is the missing layer, not the verticals.
  • Not excess coupling. coupling is too much interconnection between modules; stovepiping is the opposite — too little connection, with each silo re-implementing shared concerns in isolation.
  • Not a robustness property. robustness is genuine fault-tolerance; the stovepipe's isolation looks like independence but pays a super-linear integration tax and yields global incoherence, not designed resilience.
  • Not a failure of substitutability. substitutability is whether one component can replace another; stovepiping is about duplication of a shared concern across stacks with no common substrate to substitute into.
  • Not lost economies of scope. economies_of_scope is the cost saving from shared production across products; stovepiping names the architectural configuration that forecloses those savings — vertical concentration with no horizontal layer.
  • Common misclassification. Reading "everything is hard to integrate" as a need to build a system on top. Catch it by asking whether a cross-cutting change requires N parallel edits; if so, the fix is to extract a shared horizontal layer and retire the duplicates, not to add an (N+1)th vertical.

Broad Use

The pattern appears wherever an organization or system has built function-by-function without negotiating shared infrastructure. In enterprise IT each business unit runs its own customer system, inventory system, and reporting tool, each with its own customer record and identity model, so a customer who touches three units appears as three customers and a global definitional change requires N parallel edits. In the intelligence community the canonical case is pre-9/11 agencies each building their own collection, analysis, and dissemination stacks with incompatible information systems, so cross-agency fusion required political coordination because no shared substrate existed; the remediation — a Director of National Intelligence, fusion centers, shared infrastructure — was an explicit horizontal-layer extraction. In healthcare each department historically built its own records, ordering, and scheduling, and the patient whose care crosses departments is reassembled by hand until an enterprise EHR and interoperability standards extract the horizontal layer. In scientific disciplines each field builds its own venues, formats, and naming conventions, so the same gene, compound, or star is named three ways until ontology and shared-database projects intervene. The pattern even reaches biology: parallel evolutionary lineages adapt complete independent suites for the same pressure (eyes, flight, placentation) precisely because horizontal sharing — gene exchange across lineages — is unavailable, permanently stovepiping the solution. Municipal services, programming-language ecosystems, and academic publishing per society all show the same vertical-without-horizontal signature and the same remediation.

Clarity

The label clarifies a pattern that is typically invisible to insiders, because each vertical is internally consistent and locally coherent. The pathology is visible only from the system-of-systems vantage — when a cross-cutting concern arrives and demands N parallel implementations. Naming "stovepipe" makes that system-level perspective available without having to encounter the cross-cutting concern firsthand, which is what converts a diffuse complaint ("everything is so hard to integrate") into a structural diagnosis with a known fix.

It also clarifies what the problem is and is not. The trouble is not the existence of verticals — verticals can be virtuous, enabling focused excellence, domain-specialized teams, and local optimization. The trouble is the absence of horizontal sharing between them. The healthy alternative is not the elimination of verticals but explicit horizontal layers paired with vertical specialization. By separating "verticals exist" from "no horizontal layer connects them," the concept prevents the over-correction of dissolving useful specialization in the name of integration, and focuses attention on the missing layer rather than the present silos.

Manages Complexity

The pattern condenses a wide spectrum of cross-substrate complaints — "Why can't we just do X?", "Why is the data different in their report?", "Why does this take six teams to coordinate?" — into a single diagnostic move: find the duplicated functions that should be shared, identify the missing horizontal layer, and design the extraction. The complement of the diagnosis is equally compact: the interoperability standard or shared service that operates across stacks.

The compression sorts the available interventions. Identify the shared concern — which function is being duplicated across stacks. Extract a horizontal layer — refactor one stack to call a shared service and migrate the others. Standardize the interface — agree on a common contract even without a shared implementation. Establish a system-of-systems authority — a body whose remit is cross-stack coherence rather than any single stack's performance. Decommission redundant capability — sometimes the right move is to delete one stack and absorb its function. These options are not a grab-bag; they are an ordered menu generated by the structure, and having the structure in hand is what lets an analyst choose among them deliberately rather than reaching reflexively for "build another system on top," which usually adds an (N+1)th vertical.

Abstract Reasoning

Holding the stovepipe as a unit licenses a generalizable claim about system-of-systems engineering economics. The cost of N parallel verticals scales as N for each stack's internal investment plus roughly N(N−1)/2 for pairwise integrations as cross-cutting concerns arise. The same total capability built on a shared horizontal layer scales as N for the verticals plus 1 for the layer plus N for layer integrations — linear rather than quadratic in N. As N grows, the stovepipe penalty becomes overwhelming, which yields a sharp prediction: stoveping is sustainable when there are few verticals, few cross-cutting concerns, and high isolation, and it collapses when there are many verticals and many cross-cutting concerns.

The abstraction also licenses a historical prediction. Organizations that grow through acquisition or through autonomous function-by-function buildout tend to accumulate stovepipes, because each addition arrives with its own complete vertical. Remediation typically lags growth, producing a characteristic late-stage "integration crisis" once cross-cutting demands become unmanageable. This is a structural forecast, not a contingent observation: it follows from the quadratic integration cost meeting a growing N. Reasoning from the pattern, one can therefore anticipate the crisis before it arrives, and recognize that the moment to extract a horizontal layer is before the pairwise integration cost dominates — a judgment unavailable to anyone who sees only locally well-functioning silos.

Knowledge Transfer

The structural roles map across substrates, and with them a constant-shape intervention vocabulary travels. The parallel verticals correspond to business-unit systems, intelligence agencies, hospital departments, scientific disciplines, evolutionary lineages, or publishing societies; the shared concern to identity, storage, classification, or communication that logically should be horizontal but is physically duplicated; the absence of horizontal substrate to the missing master record, shared service, or agreed contract; the integration tax to the bespoke bridge each cross-stack interaction requires. Because the roles correspond, a practitioner who has extracted a horizontal layer in one domain recognizes the same opportunity in another without retranslation.

The interventions inherit that portability. From enterprise architecture come the "shared service," "platform team," "master data management," and "single source of truth" patterns, all of which operationalize horizontal-layer extraction. From government reform come the fusion center, the shared-services agency, and the interagency working group — governmental forms of the same extraction. From healthcare interoperability come the master patient index and standardized clinical-data exchange, which generalize to any domain where entity-identification is duplicated. From open-source ecosystems come container runtimes, observability standards, and packaging manifests that defeated polyglot stovepipes. From scholarship come cataloging standards, shared bibliographic databases, and ontology frameworks. Across all of them the constant-shape intervention is isolate the shared concern, build it once, retire the N duplicates, and the constant-shape constraint is that migration is socially expensive — each stack has owners with incentives in their vertical — so the intervention requires a system-of-systems authority that the original verticals lack. The transfer is reliable because the underlying structure — vertical concentration of shared concerns with no horizontal layer — is recognizable across substrates even where the software vocabulary does not apply, surviving the strip-the-jargon test intact.

Examples

Formal/abstract

The integration economics make the pattern precise. Take \(N\) capabilities, each needing the same shared concern — say, a canonical identifier for a domain entity. In the stovepiped configuration, each of the \(N\) verticals re-implements its own identity scheme, costing \(N\) units of internal investment. When cross-cutting demands arise — every pair of stacks that must reconcile their entities — the system pays a pairwise integration tax: a bespoke bridge for each of the \(\binom{N}{2} = N(N-1)/2\) stack-pairs, which is \(\Theta(N^2)\). The total cost is therefore \(N + N(N-1)/2\), quadratic in \(N\). The horizontal-layer alternative builds the shared identity substrate once: \(N\) for the verticals, plus $1$ for the layer, plus \(N\) for each vertical's single integration to the layer — total $2N + 1$, linear in \(N\). The crossover is sharp: for small \(N\) with few cross-cutting concerns the quadratic term is negligible and stovepiping is locally rational, but as \(N\) and the density of cross-cutting demands grow, the \(N^2\) term dominates and the penalty becomes overwhelming. This yields a structural forecast rather than a contingent one: an organization growing function-by-function accumulates verticals until the pairwise integration cost meets a rising \(N\) and produces a characteristic late-stage "integration crisis." The dictated intervention — extract the shared concern into a horizontal substrate and retire the \(N\) duplicates — is the move that converts the quadratic cost curve into a linear one.

Mapped back: The cost model instantiates every role — parallel verticals, a duplicated shared concern, an absent horizontal layer, and a super-linear integration tax — and shows the defect is the missing horizontal layer (the \(N^2\) term), not the verticals themselves.

Applied/industry

In the U.S. intelligence community before 9/11, separate agencies each built complete vertical stacks — their own collection, analysis, and dissemination systems with incompatible data formats, identity models, and classification handling. The shared concern (a fused, cross-agency picture of a threat actor) logically belonged to a horizontal layer that did not exist, so reconciling information across agencies required bespoke political coordination for each pair — the quadratic integration tax made visible as institutional friction. The remediation was an explicit horizontal-layer extraction: a Director of National Intelligence, fusion centers, and shared infrastructure that provided the cross-stack substrate the verticals lacked. The identical structure governs hospital information systems: each department historically built its own records, ordering, and scheduling, so a patient whose care crosses departments is reassembled by hand and the same patient appears as three records until an enterprise EHR and a master patient index extract the horizontal identity layer. And in enterprise IT after acquisition-driven growth, each business unit runs its own customer, inventory, and reporting systems, so a customer touching three units appears as three customers and any global definitional change requires \(N\) parallel edits; the master-data-management or shared-service pattern is the horizontal-layer extraction, and it requires a system-of-systems authority because each vertical's owners have incentives in their own silo.

Mapped back: Across intelligence agencies, hospital systems, and post-acquisition enterprise IT the same roles recur — parallel verticals, a duplicated shared concern, an absent horizontal substrate, and a super-linear integration tax — and the same intervention transports: extract the shared concern into a horizontal layer once, retire the duplicates, and stand up an authority empowered for cross-stack coherence.

Structural Tensions

T1 — Local Efficiency versus Global Coherence (scalar). Each vertical is internally consistent and locally optimal while the system-of-systems is incoherent, so the pathology is invisible from inside any silo and visible only from the system vantage. The failure mode is insider blindness: every stack owner reports health while integration is impossible, and no one owns the global view. This is the local-global tension. Diagnostic: ask whether a cross-cutting concern would require N parallel edits; the pathology lives at the system level, not in any vertical's self-assessment.

T2 — Extract Horizontal Layer versus Add Another Vertical (sign/direction). The reflexive fix for integration pain is "build a system on top," which usually adds an (N+1)th vertical rather than a horizontal layer, deepening the problem. The failure mode is integration-by-accretion: each integration project spawns a new stack, raising N and the quadratic tax. Boundary with additive_bias — the additive search distribution disfavors the subtractive extract-and-retire move. Diagnostic: does the proposed fix retire the N duplicates and provide the concern once, or add a new component that itself must integrate? Only extraction bends the cost curve.

T3 — Horizontal Extraction versus Healthy Specialization (scopal). The frame warns that verticals are virtuous and the defect is the missing layer, but over-correcting toward integration dissolves the focused excellence that specialization provided. The failure mode is over-centralization: forcing a shared substrate where local optimization was the right answer, producing a monolith that serves no vertical well. Boundary with procedure_work_mismatch's standardization tension. Diagnostic: is the duplicated concern genuinely common across stacks, or only superficially similar? Extracting a falsely-shared concern destroys legitimate specialization.

T4 — Crossover Timing versus Premature Extraction (temporal). Stovepiping is locally rational at small N and collapses at large N, so the right moment to extract is before the pairwise integration cost dominates — but extracting too early pays the horizontal-layer cost before the verticals or cross-cutting demands exist to justify it. The failure mode is premature platform: building a shared substrate for verticals that never materialize or never need to integrate. Diagnostic: where is N relative to the crossover, and is cross-cutting demand density rising? Extraction before the quadratic term bites is wasted; after it dominates is a crisis.

T5 — Shared Substrate versus Single Point of Failure (coupling). Extracting the shared concern into one horizontal layer removes duplication but concentrates dependency — the layer becomes a vulnerability_hotspot whose failure now cascades across every vertical that the silos previously isolated. The failure mode is fragility concentration: trading N independent failure domains for one shared substrate whose outage takes down all stacks. Diagnostic: does the horizontal layer have redundancy and isolation commensurate with its now-universal dependency? Stovepiping's isolation was a robustness property the extraction must consciously replace.

T6 — Extraction Mandate versus Vertical Incentives (coupling). The intervention requires a system-of-systems authority because each vertical's owners have incentives in their own silo and resist migration. The failure mode is authority capture or impotence: the cross-stack authority is either resisted into irrelevance (a sponsor_vacuum) or, if too strong, overrides legitimate vertical needs. Boundary with sponsor_vacuum. Diagnostic: does the system-of-systems authority have real remit and resources against the vertical owners' incentives, or is it a nominal coordinating body? Without enforced precedence, the duplicates are never retired.

Structural–Framed Character

Stovepipe system sits right at the framed side of the middle of the structural–framed spectrum, a framed prime with an aggregate of 0.5 — every one of the five diagnostics scored at the midpoint, a uniformly balanced case rather than a lopsided one. Underneath is a real architectural-economic structure (parallel verticals re-implementing a shared concern with no horizontal layer, paying a quadratic integration tax), and that cost geometry travels; but the prime's home framing in enterprise IT and intelligence organization keeps it from crossing to the structural side.

Each diagnostic reads at the halfway mark, and the reasons are consistent. The vocabulary half-travels: "stovepipe," "vertical stack," "horizontal layer," "shared service," "master data management," and "system-of-systems authority" carry an IT and government-reform lexicon that a new domain must partly translate, even though the underlying \(N + N(N-1)/2\) cost argument is bare. Evaluative weight is moderate — "stovepipe" names a pathology to be remediated, yet the entry is careful that verticals themselves are virtuous and the defect is only the missing layer, which softens the loading. Institutional origin sits at enterprise architecture and the intelligence community, and human-practice-bound is partial: the canonical instances (business-unit silos, pre-9/11 agencies, hospital departments) are human-institutional, but the entry reaches for an evolutionary-lineage instance — parallel lineages independently evolving eyes, flight, and placentation because horizontal gene exchange is unavailable — that genuinely strips the human frame, which is exactly why the score is 0.5 rather than higher. Invoking the prime half-imports a frame (extract the shared concern, retire the N duplicates, stand up a cross-stack authority) and half-recognizes a configuration already present.

The prime's own rationale flags that the ecological extension "feels analogical," and its substrate reasoning calls this an architectural pattern that travels with mild domain flavor. That balance — a real, partly substrate-neutral integration-economics structure carried in an IT/intelligence vocabulary, with one biological instance that nearly escapes the frame but reads as analogy — is precisely the framed-but-central placement the aggregate of 0.5 records.

Substrate Independence

Stovepipe system is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its domain breadth is wide: the vertical-stack-without-horizontal-sharing pattern recurs with the same structural force across enterprise IT (each business unit re-implementing its own customer and identity model), intelligence agencies (the pre-9/11 stacks whose remediation was an explicit horizontal-layer extraction), healthcare (departments each building their own records until an enterprise EHR), scientific disciplines (the same gene named three ways until shared ontologies intervene), and even biology, where parallel evolutionary lineages adapt independent suites for the same pressure precisely because horizontal gene exchange is unavailable. The structural-abstraction component sits at the middle: the load-bearing object is a genuine integration-economics structure — parallel vertical stacks re-implementing shared concerns, paying a super-linear integration tax for the missing horizontal layer — but the "stovepipe" metaphor and the architectural framing carry an IT/intelligence home flavor, and the biological instance reads as analogy rather than a clean substrate-neutral case. Transfer evidence is strong: the diagnosis (count the re-implemented shared concerns; the failure is the missing horizontal layer, not the vertical depth) and the remedy (extract the shared layer) transport across IT, intelligence, healthcare, and scientific-naming cases. A wide reach carried in a mildly domain-flavored vocabulary is exactly what fixes the composite at 3.

  • Composite substrate independence — 3 / 5
  • Domain breadth — 4 / 5
  • Structural abstraction — 3 / 5
  • Transfer evidence — 4 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Stovepipe Systemsubsumption: ModularityModularity

Parents (1) — more general patterns this builds on

  • Stovepipe System is a kind of, typical Modularity

    A stovepipe is a degenerate modular decomposition: parallel verticals WITHOUT a horizontal sharing layer, so each silo re-implements shared concerns. is-a a (defective) modular configuration — the file is explicit the defect is the missing horizontal layer, not the verticals. Owner may prefer to treat it as the absence-of-horizontal-factoring rather than a modularity child.

Path to root: Stovepipe System → Modularity

Neighborhood in Abstraction Space

Stovepipe System sits in a sparse region of abstraction space (95th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.

Family — Returns To Scale & Scope (6 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The most important confusion is with modularity, because both describe systems decomposed into separable parts, and a stovepipe can be mistaken for a virtuously modular architecture. The decisive difference is the horizontal interface. Modularity is decomposition into units that communicate through defined, shared interfaces — each module hides its internals behind a contract, and shared concerns are factored into common layers the modules call. A stovepipe is decomposition into parallel verticals with no horizontal sharing layer at all: each silo re-implements identity, storage, and classification independently, and there is no common substrate to call. So a stovepipe is not "too much modularity" or "bad modularity" — it is the absence of the horizontal factoring that makes modularity healthy. The distinction is load-bearing because the remedy follows from it: a modular system needs interface discipline; a stovepiped system needs an entirely new shared layer extracted and the N duplicates retired. A practitioner who sees clean vertical boundaries and concludes "this is nicely modular" misses that the verticals share nothing horizontally, which is exactly the pathology.

A second genuine confusion is with coupling, and here the trap is that the two are near-opposites that both register as "architectural trouble." Coupling is excess interconnection — modules so entangled that a change in one ripples into others, and the cure is to decouple, to reduce the dependencies. Stovepiping is insufficient connection — verticals so isolated that they cannot compose and each must re-implement shared concerns, and the cure is to add a shared horizontal layer. Reaching for the coupling intuition in a stovepiped system is actively harmful: the reflex to "reduce dependencies" deepens the isolation that is the actual disease. The discriminating question is whether the pain comes from changes rippling across modules (coupling) or from the same concern being duplicated across modules with no way to share it (stovepiping). They demand opposite moves — separate versus unify — so misdiagnosing one as the other inverts the remedy.

A third confusion is with robustness, the nearest existing prime by embedding. The link is seductive: a stovepipe's isolation looks like fault-tolerance, since each vertical's failure is contained and cannot cascade to the others. But that isolation is incidental, not designed, and it comes bundled with global incoherence and a super-linear integration tax — the system pays quadratic integration cost and cannot compose its capabilities, which no one would choose as a resilience strategy. Genuine robustness is the engineered property of degrading gracefully under perturbation; stovepiping's isolation is an accidental byproduct of never having built the shared layer. The distinction surfaces sharply at remediation time (T5): extracting the horizontal layer removes the accidental isolation and concentrates dependency into a single substrate, which must then be made robust deliberately. So robustness is something the extraction must consciously replace, not a property the stovepipe was providing on purpose. A practitioner who defends a stovepipe as "robust by isolation" confuses an unplanned side effect for a design virtue and will resist the very extraction that would let real robustness be engineered.

For a practitioner, the distinctions sort by what the pain actually is. If modules communicate through defined interfaces, it is healthy modularity; if changes ripple across over-connected modules, it is coupling (decouple); if the system genuinely degrades gracefully by design, it is robustness; and if parallel verticals each re-implement a shared concern with no horizontal layer and pay a quadratic integration tax, it is a stovepipe system — the only one whose remedy is to extract the shared concern once and retire the duplicates.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.