Adrian McGrath recently wrote a post called “The Problems with Shared Network Folders“.
It’s a great post, and Adrian is someone that I have a lot of respect for. He’s a smart guy, and I learn a lot from him. In the post (read it here ), Adrian discusses the disadvantages and limitations of using Shared Network folders.
- Duplication of documents and confusion as to what the latest version is
- Complex file and folder naming conventions
- Lack of consistent folder structures
- Redundant documents
- Ineffective search
- Inaccessibility of information
- Lack of subscription and notification
- Limited ability to synchronise documents offline
- Inability to cross reference and relate documents
- Lack of document governance and control
- Compliance, Risk & Legal Admissibility
- Impeded collaboration
- Storage and maintenance costs
In essence Adrian is correct. Using Shared Network drives does have limitations, but in the spirit of debate, I’d like to make a few comments on what he says.
Duplication of documents and confusion as to what the latest version is.
Complex file and folder naming conventions
Lack of consistent folder structures
These are all indeed real problems. Are they inherent to Shared Folders? Not really – these can also happen with Document Management Systems.
Governance plays a large part in ensuring that these sort of things do not happen. Information Architecture is critical in ensuring that a suitable structure exists, defined by folder, and metadata, so that every document has a correct location.
However, this does require enforcement. Without enforcing such a system, even EMC systems can end up overly complex and with duplicated (and therefore redundant) documents. A lot of these systems, however have de-duplication functionality built-in (Documentum), and, if not (SharePoint), there is often a third-party tool that will do this.
Can’t argue with this. Unless some sort of indexing application is implemented, searching will be very inefficient.
There are many applications that allow Shared Network folders to be indexed. These include applications such as Google Desktop, Windows Search, X1, etc. SharePoint, also, has the ability to index information in file shares, as well as making the search results a little bit more meaningful.
Inaccessibility of information
Adrian is definitely right here. Most (if not all) companies are quite strict with their network security. Users are not able to make ad-hoc changes.
However this can also occur in an ECM system depending on how much “freedom” a user has. I have seen some situations where, because the security policies in the ECM system were so strict, that users have resorted to exporting a document to a file share, so that it can be shared with others, or worse, e-mailed to an external party.
A good governance model helps to reduce this, as does training. If the users are aware of why something is enforced then there is, often, a better chance of compliance.
Lack of subscription and notification
Limited ability to synchronise documents offline
Inability to cross reference and relate documents
No arguments here
Lack of document governance and control
Compliance, Risk & Legal Admissibility
I’ve mentioned governance in my comments above. A good plan is required to ensure that documents are not haphazardly placed in seemingly random locations. And, as Adrian mentioned, Most ECM systems provide an audit trail keeping a record of the “actions” upon a document (when a document changes status, etc).
However, this is only effective for versions of the documents that are within the document management system. Once it is outside of the system (a user exports, or e-mails, a document) there is no audit trail. (Often this is done to collaborate with someone who does not have access to the ECM system.) This can create compliance issue. Again – good training, and governance, helps to reduce this risk.
Storage and maintenance costs
As Adrian mentioned, the amount of storage space required in a file share can be quite high, as users store more, and more content. And he is correct that because of the scattered nature of such content, this leads to inefficiencies.
ECM systems tend to handle the storage of content in one of two ways:
- Content is stored in a file system on a hard drive. Usually the content will have some meaningless name, and might also be encrypted. Metadata about the content (including it’s location) is stored in a database. Access to the content is via the CMS (native interface, or API).
- Content, and metadata, are stored in databases. The content is usually stored as a BLOB.
If the ECM system is configured to keep create a version every time a document is checked out, and then checked back in again, the number of “duplicate” versions can increase quite quickly, thereby requiring extra space. Of course, setting a lower limit for the number of version kept can help reduce this. Configuring the system to purge all minor versions of a document (e.g. 0.1, 3.2, etc) when a major version (e.g. 1.0, 3.0) is created also ensures that disk space is kept to a minimum.
Keeping documents in the database as a BLOB also presents extra maintenance. As with a file system, the databases can grow exponentially. Often extra work is required to ensure that the database still performs efficiently.
I am convinced that to be able to keep content in a system that allows adding meaningful metadata, auditing, security, document life cycles, and workflows, is critical if a business needs to track, control or route content. Often these activities will exist to match the requirements of a business process, and to make it more efficient.
However there are a few situations where using a file share is still of value.
my next a later post I will go into this more…