When it comes to information silos, there's no shortage of blame. Sometimes the business or organizational structure takes the blame. Sometimes it's legacy systems and, by association, IT. Sometimes people claim it's political cowardice. Sometimes the consultant is thrown under the bus.

In the end, the result is the same: The silos remain.

I've spent a lot of time this year trying to puzzle out the persistence of silos, including a look at why businesses (not to mention government) keep building them,whether it's even possible to eliminate silos and, more recently, the potential of just bridging silos.

Unconsciously, I think I'd given up on the issue. Sure, I write about it, because that's what I do. “One version of the truth...eliminating silos, information integration, yada yada yada.” But inside, it just felt hollow. I'd started to believe you might win a few battles, but ultimately, silos always win the war.

But a recent piece by Michiko Diby, a D.C.-based consultant, has caused me to rethink this issue. Oh, not the idea that silos will persist - because, let's face it, they will - but the idea that silos should always be “overcome” in some way.

Diby argues that, sometimes, silos are simply too powerful AND the existing process works well enough. Knowing when these two conditions – powerful silos and a “good enough” process - exist can make the difference between losing your job and keeping it.

And yet, it's a lesson IT seems to always learn the hard way, often even ignoring or dismissing clues end users may give:

I’ve heard IT [project managers] brush that good info about silos under the rug, assume that users don’t know what they want, or take a ‘dumb user’ approach to siloed lack of will. But I’ve seen projects drag on way past deadlines because of turf wars. I’ve seen good projects killed at the last minute because certain groups refused to use them. I’ve seen very good senior people let go because of new system-induced political battles. Change is hard and change is near impossible if people are unwilling.

It's important to note that this isn't just about people being stuck in their ways. Diby gives several examples of times when users may not have liked the existing approach, but ended up finding it less painful than the solution. In particular, she talks about the VA's Electronic Contract Management System, which was supposed to integrate all contract data and provide more insight into contract procurement.

It was a complete failure. People hated it. They refused to use it, because it actually took them more time to do their jobs than the old system – in at least one case, a week longer. I can't say I blame them, can you?

Whether it's information integration or automation, companies too often start bulldozing to build a new solution when they should first excavate with an archeologist's toolkit to learn more about the existing solution. If they had, they might realize that while the current approach might not be eloquent or perfect; it works – and that's no small thing. In other words, Diby writes:

“If it ain’t broke enough, don’t fix it... sometimes the seemingly antiquated way of doing things is that way for very good reason. And the day-to-day operation you’re seeing on the surface is the tip of an iceburg of years of reasons as to why the process is not automated. As an IT PM, you need to find out what those reasons are.”

But how, you may be asking, are you supposed to know when the silo will win? Diby offers some excellent advice for how to do this.

She also suggest you check out the Information Systems Audit and Control Association's ValIT framework, which outlines how to better understand existing systems and address silos – not necessarily remove them.