How to Avoid Having Your Documents Held Captive

We worry about documents being accessed or manipulated without proper controls, but how often do we worry about documents being held captive?  It’s easy to say there are billions of documents being held captive from their owners’ control in various ways.  Honestly the number is in the trillions.  Documents are locked inside defunct or arcane systems with no easy way out except the help of a “very particular set of skills. Skills someone has acquired over a very long career.”

The issue is that most organizations ignore signs and problems and find themselves in situations that there’s almost no way out.  Organizations still use proprietary hardware platforms to manage documents.  Documents continue to be stored in systems that are showing signs of capacity issues.  Decisions are made based on lowest best-case options without considering a backup plan or exit strategy.  Platforms continue to be used from defunct vendors.  Any of these scenarios can hold an organization’s content captive.

But organizations can avoid having documents held captive by following some simple rules.

#3 – Avoid Solutions from “Two Guys and a Computer”

From scratch solutions are not the answer to document problems, yet hundreds of these solutions are still deployed every year.  I’m not talking about building a custom solution on top of an ECM platform.  I’m talking about building the whole document management architecture from scratch against a file system with some sort of database.

I’ve talked about this before, no good comes for building from scratch and there’s no reason to do it.  Sure two people can easily pull together the next greatest thing but often that’s not the case.  Managing documents may sound easy but in the end it’s not, especially when it reaches hundreds of thousands of documents.  Then you’re stuck with a hundred thousand documents stored in some proprietary system with no easy way off.

#2 – Maintain Legacy Repositories

The worst thing you can do with stale document collection is to stop maintaining it. Neglected repositories are a nightmare that does not go away.  Odds are you will not be able to just delete the whole thing.  Letting the software go out of date can be a big challenge.  At times, repositories will require critical updates like schema changes.  Ignoring critical updates can make migrating off a nightmare.  This is true if  your documents are stored in proprietary hardware platforms.

This goes beyond the software itself.  Not keeping staff skilled on the solution can be a challenge.  It will not be easy, or inexpensive, to hire a contractor because these skills disappear from the job market.  If those skills are available depends on how popular the repositories were.  Technologies may live on like COBOL, invented in 1951, has done.  It’s also critical to track vendor viability.  Once the vendor goes away, your access to skilled individuals is really limited.

#1 – Insist on Open Standards and APIs

In general, the best thing to do is make sure that your repository has an API and supports open standards like ODBC, JDBC, or CMIS.  Supporting standards and APIs allow the platform to grow to support new features and capabilities from various sources.  These standards allow repositories to talk to other systems.

Those same standards ensure that your documents are accessible.  Supporting standards may even make up for ignoring rules two and three.  You will have a way off of a “from-scratch” platform that supports ODBC or JDBC.  Even proprietary API that provides access can be used to ensure access to content.  This is really important in cloud options which often do not support many of the open standards.  I’ve talked about exit strategies in the past.

The Prime Directive

If there is a “prime directive” it should be that when choosing a document platform or solutions, how you can get your content off of that platform is as important as any other feature.  Vendors should not be afraid of migration related questions.  A vendor that focuses on meeting its customer’s needs keep the customer documents in their repository.  In fact it might show an air of confidence.  Besides, who wants a vendor that’s worried about how to “lock-in” their customer’s documents?

Comments are closed.

Create a website or blog at

Up ↑

%d bloggers like this: