A Stovepipe Enterprise is a management anti-pattern that happens when different groups in a single company are responsible for designing their own systems from the ground up, completely independently of the other groups, and with no cross-group direction. What results is that each team has their own environment, standards, architecture, and data sources and none of the groups can work effectively with one another's systems.
What you end up with is similar to a pipe organ: lots of individual pipes, none interacting with one another, each only able to produce a single sound. Individually they are something, but together they could be much, much more.
The Rundown
- Name: Stovepipe Enterprise
- AKA: Silos
- Summary: An organization allows its teams to develop completely independently of one another, resulting in "silos" or "pipes" of groups whose systems cannot work together well, if at all.
- Type: Management
- Common?: DUNNNNN...! dun dun dun dun dunnnnnnnnnn!
Tell Me a Story!
I have a sneaking suspicion that any organization of sufficient size eventually becomes a stovepipe enterprise, all other things being equal.
Without an overall guiding vision, a benevolent dictator at the helm, people tend to organize into like-minded groups, which results in software that fits with these preconceptions. We all want to fit in.
Up until recently, this was precisely what was happening to my company.
When I got here seven years ago (!), we were fully-independent cowboy coders. We each maintained our own little apps and our own little standards, and didn't really work in teams.
Then, our growing stage began. Our director of IT (we'll call him Bill) started organizing us developers into groups. At first, it was really just "put these guys over here so we can manage them more easily" type of stuff, but later each group got a dedicated manager, and then started subdividing into programmer-lead teams.
This process took a few years, but at the end of it, programmers were working as units, getting software done much more quickly, and generally producing better results.
On the one hand, we were now developing better software much more quickly than we had been. On the other, the teams had developer their own infrastructures, and so each team was, for example, getting common data from disparate sources. None of the teams' systems could talk to one another easily, resulting in the company having to maintain a great many different data sources for different teams.
So now we find ourselves in a difficult situation. We are, in many ways, a stovepipe enterprise, though not to some irretrievable extent. Obviously this whole "get the same data from different sources" thing cannot continue. But how do we get the teams to use the same source? And who decides what that source is?
The solution to the stovepipe enterprise is a counter-intuitive and incredibly rare one. What we need, what my company thankfully already has, is a benevolent dictator.
Of course, "benevolence" is in the eye of the beholder.
Strategies to Solve
The benefit of a benevolent dictator, and why it works in business as opposed to government, is that there's a single point of responsibility for all company-wide decisions. That person now can direct each team how they see fit, and decide the "canonical" way to do things across teams, such as accessing common data.
In our particular case, our benevolent dictator is our IT director Bill. Around eighteen months ago, he split off a few developers from several teams into a single "infrastructure" team, which is charged with making and maintaining the services the entire company IT division needs (and if you think this sounds like exacerbating the problem instead of solving it, you weren't the only one).
This infrastructure team is only just now coming out with new company-wide platforms, systems through which we can access common company data. Let me tell you, they have been a joy to use. For one, we now have a single source of truth for this data, so if it's ever wrong, we know where to fix it.
For another, we have a solitary point of contact for any of these services if they accidentally fail or don't yet do what we need. It's been refreshing to know that we only need to consume one service, use one API, instead of wading through the muck of disused software only to find that our princess is in another castle.
Our benevolent dictator is slowly, surely, pulling us out of our stovepipes. I've always had faith that we were going to get there, and now, we've started seeing the results.
Summary
A stovepipe enterprise occurs when an organization's teams are independent to the point of not being able to work with each other, and their software systems cannot interact.
The solution is usually guidance from above, in the form a benevolent dictator, willing to make difficult decisions and fall on their sword should the need arise. If you've got one of the people at your company, consider yourself lucky.
Does your company suffer through being a stovepipe enterprise? Did you find that elusive benevolent dictator, or did you solve this problem another way? Share in the comments! Or else head on back to the series index page to see some more anti-patterns.
Happy Coding!
