Stovepipe System

Prime #

1211

Origin domain

Software Computing

Subdomain

enterprise architecture → Software Computing

Aliases

Silo Architecture

Core Idea

A stovepipe system is a collection of capabilities built as parallel vertical stacks — each handling its own data, identity, conventions, and tooling — with no horizontal layer shared across them. Shared concerns are duplicated inside each stack, so each vertical is locally efficient while the system-of-systems is globally incoherent, paying a super-linear integration tax. The defect is the missing horizontal layer, not the verticals.

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.

Broad Use

• Enterprise IT: each business unit runs its own customer and inventory systems, so a customer touching three units appears as three customers.
• Intelligence agencies: pre-9/11 agencies each built incompatible collection and analysis stacks; cross-agency fusion required bespoke coordination.
• Healthcare: each department builds its own records and ordering, and a patient crossing departments is reassembled by hand.
• Scientific disciplines: each field names the same gene, compound, or star three ways until shared ontologies intervene.
• Open-source ecosystems: polyglot stacks duplicate runtimes and observability until container and packaging standards extract the layer.
• Biology: parallel lineages independently evolve eyes, flight, and placentation precisely because horizontal gene exchange is unavailable.

Clarity

It makes a pattern that is invisible to insiders — each vertical is locally coherent — visible from the system vantage, and separates "verticals exist" (often virtuous) from "no horizontal layer connects them" (the actual pathology).

Manages Complexity

It condenses diffuse complaints ("why is the data different in their report?") into one diagnostic move — find the duplicated shared concern and design its horizontal extraction — and an ordered menu of interventions.

Abstract Reasoning

It licenses a system-of-systems economics claim: \(N\) verticals cost \(N + N(N{-}1)/2\) (quadratic) against $2N+1$ (linear) for a shared layer, predicting a late-stage "integration crisis" as \(N\) grows.

Knowledge Transfer

• Enterprise architecture: "shared service," "master data management," and "single source of truth" all operationalize horizontal-layer extraction.
• Government reform: fusion centers and shared-services agencies are the governmental form of the same extraction.
• Healthcare → any domain: the master patient index generalizes wherever entity-identification is duplicated; the constant-shape move is isolate, build once, retire the N duplicates.

Example

The pre-9/11 U.S. intelligence community built separate vertical stacks with incompatible formats and identity models, so a fused cross-agency picture required bespoke political coordination per pair; the remediation — a Director of National Intelligence, fusion centers, shared infrastructure — was an explicit horizontal-layer extraction.

Relationships to Other Primes

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

Not to Be Confused With

• Stovepipe system is not Modularity because a stovepipe has no horizontal sharing layer, whereas modularity is decomposition into units with defined shared interfaces.
• Stovepipe system is not Coupling because stoveping is too little connection (duplicated concerns in isolation), whereas coupling is too much interconnection that ripples changes across modules.
• Stovepipe system is not Robustness because its isolation is an incidental byproduct paying a quadratic tax, whereas robustness is engineered graceful degradation.