Stovepipe Anti Pattern

One of the AntiPatternsBook's anti-patterns. Actually, they mention three versions of stovepipe ArchitectureAntiPattern: AutogeneratedStovepipeAntiPattern, StovepipeEnterpriseAntiPattern?, and StovepipeSystemAntiPattern?.

See also: StovepipeSystem

AutogeneratedStovepipeAntiPattern refers to porting an existing system to a distributed system, without adjusting the design to account for the distributed nature. StovepipeEnterpriseAntiPattern? refers to "islands of automation" within an enterprise that are designed independently with little commonality or interoperability. StovepipeSystemAntiPattern? refers to similar architecture between the subsystems of a single system. In either of these two, point-to-point integration is the rule, leading to an n-squared model of complexity. The lack of abstraction results in brittle, difficult to maintain architectures.

A better definition may be that found at [], "a stovepipe system is a system procured and developed to solve a specific problem, characterized by a limited focus and functionality, and containing data that cannot be easily shared with other systems."
Is there an interesting etymology to this term? Are actual stovepipe systems difficult to design, expand, debug, etc.?

That's a good question, but I don't know. The older citations I find seem to come from U.S. Government systems and date to about 1995. I haven't made an exhaustive search, however. I looked into the term a few years back and came to the conclusion that it originates from the fact that stovepipes do not connect to each other. Each provides an independent pathway from a particular furnace to the sky. I don't recall what led me to this conclusion. -- GeorgeDinwiddie

Speaking as someone who used to work on some of those U.S. Government systems, I don't think this is correct. Whenever I've seen this term used, it is in reference to systems that had one input module, one output module, and a long string of "processing" modules in between. What makes this a stove-pipe is that each module is closely tied to its precursor and to its successor. There is no way to remove a module from the pipe without leaving a gaping hole for the smoke to pour out of. Reuse of a module is complicated, for similar reasons.

That experience was in the late eighties. But according to, it was originally a logistics term: '[in] 1966 The new Stovepipe special supply support system was implemented. It was an innovative logistics system with operational readiness as the paramount consideration.' -- PaulKrause

I would very much like to see the 1966 Redstone reference mentioned above (don't see anything about it at that site). I have 1988 and 1989 references for the coining of the terminology "functional silo syndrome" in corporate management and a later reference linking the "silo" and "stovepipe" terminology (see,, and where I have added this info - just search for "functional silo syndrome"). So far, I have not found any actual references predating the 1988 ones and would like to know if they exist. -- SusanLynn?

I also used to work with U.S. Government systems and I first heard the term around 1995 - but it was in reference to the structure of an organization, not a system. In particular, an agency or department that is prohibited from communicating with its cohorts due to security constraints was referred to as a 'stovepipe'... information goes into the department and emerges as a finished product but no one outside of the department is allowed to share with it during its processing. Kinda like doing your black-work (euphemism for classified work) in a dirty iron stovepipe. -- GreggCooke

In the real world, stovepipes tend to rust and have to be replaced. A cheap solution used to be to merely weld another section of pipe onto the section that was rusted through and smoking. This solution invariably had to be repeated on the new section, resulting in a kind of recursive tree structure of stovepipes. Well, not really that bad, but to a programmer it could conceivably work out that way. -- DaveBabbitt
You get it in C++ when every single CPP includes every single possible H file in the system. Like MFC does.

The cure is Lots of Little Classes, borne of RefactorMercilessly.

Lots of little classes don't make any difference as the same include pattern will result. What is needed are abstract interfaces between well designed layers. -- AnonymousDonor

Yeah, well, I can tell you that a stovepipe is a Bad Thing™ when shooting any kind of autoloading firearm. Guess the anti-pattern holds, eh?
BTW, this is similar but not identical to the military intelligence sense of "stovepiping", in which a piece of intel is passed up to the highest levels, bypassing the usual chain of command, as if it were being shot up a stovepipe directly to the sky.
When I first heard the term, it referred to people in one department building applications, usually in some user programming tool such as MS Access(TM), that performed a specific, limited task or created a report, and this was used only in their department. There was no communication with other departments about what they were doing, so other departments wound up creating a similar application or tool, and sometimes these different apps reported conflicting data or stepped on one another's data. -- Henry Stinson
CategoryAntiPattern CategoryArchitectureAntiPattern

EditText of this page (last edited October 22, 2013) or FindPage with title or text search