Real Story Group. Make Better Technology Decisions.

Kas Thomas

In defense of silos

9-Jul-2009

Tags: Document Management (ECM), Industry Standards

The word "silo" (referring to a single, monolithic resource repository of some kind, often dedicated to a single vendor's applications) has such negative connotations these days that to suggest silos are actually good or necessary is to risk excommunication from the IT priesthood. Nevertheless, the sheer pervasiveness of information silos (and the eagerness with which people buy new ones) should give us a hint as to what's really going on: Silos do, in fact, serve a purpose. They enforce encapsulation. And that's an important thing.

We should be clear on the fact that purveyors of large enterprise software systems, in particular those who offer ECM, WCM, and DAM systems, are in business to sell you silos. And there's nothing inherently wrong with that. The problem comes when resources that need to be made available to multiple applications are spread across silos not built with sharing in mind. Encapsulation becomes a detriment in this case.

At a high level, there are various ways to approach the problem. One is to try to consolidate silos. Another is to build a cobweb of point integrations between silos and the applications that need access to them. Yet another is to leave silos "as is" and front them with an abstraction layer designed to hide the patchwork nature of the data infrastructure. The problem with the latter approach is that one abstraction layer seldom fits all. You can end up with a zoo of connectors between silos and abstraction layer and still not achieve your interoperability goals.

The problem becomes more acute by the day as silos proliferate and content finds its way to the edges of the network rather than to any central spot. In just a few short years, IT managers have gone from cattle ranchers to cat herders. What's a cowboy to do?

The key thing to realize, I think, is that federation and interoperability strategies, in order to be successful, require standards-based communication between participants. If silos obey certain standards around CRUD-and-query, access control, security, payload formats, and wire protocols, a unifying abstraction layer can be more like a bus or backplane, and less like one of those spaghetti-wire switchboards you see in 1940s movies.

In an ideal world, no one would ever have to know or care how many silos an organization has, as long as they're connected in a transparent manner, so that applications (and users) can have a natural-feeling logical view into what looks like a purpose-built single silo (appropriate to the app in question). One gets to this point only when silos and applications start speaking the same core languages, protocols, and data exchange formats. CMIS is an example of an attempt to execute on this philosophy -- an attempt to enable interoperability of siloware via a meta-protocol built atop standards. This is a good thing. The alternative is anarchy.

If history has taught us anything, it's that silos aren't going away. Marketing appeals built around silo-busting are therefore not really credible. Silos are, in fact, good and necessary, or we wouldn't have them. It's how you wrap your arms around them that counts.