Problems with Check-In/Check-Out Systems

Before developing Columbus we evaluated many Document Management Systems (DMSs), and had the chance to examine the consequences of using them. The closer we looked, the more problems we found.

All of the commercial DMSs that we evaluated work on a check-in/check-out (CI/CO) basis. That is, they store user data with encrypted file names on a protected server and copy them into an accessible area on request.

This can at first seem attractive as they prevent unauthorised access to data. But users can impose security quite simply and more flexibly with their existing server operating system and, as will be seen, this 'vault'-based approach introduces many undesirable side-effects.

The Vault

Vaults are intentionally closed environments ensuring that every addition, removal or change is controlled through the DMS and recorded. Most software applications however, are designed to work with a file system and many will simply fail when a vault is present.

For instance, if a CAD drawing is expecting to open other reference files when it loads, it will simply fail unless the user has gone through often tortuous lengths to put those files in the vault and establish DMS links to them. Linking to the reference file may not be sufficient as you may also need to define which version of the reference file to load. Starting to get confused yet?

The same problem exists where one wishes to create an OLE link from, say, a Word document to an Excel spreadsheet for the purposes of creating a pie-chart in a report.

In both cases, if the required content is in the vault, users can't browse the file system to find it. This is a big problem as most software packages assume one can do this. For instance, AutoCAD allows users to visually browse the file system looking for blocks or x-refs to attach. This isn't possible with a classic DMS.

Another related problem is when users want to double-click the linked spreadsheet to edit it or use 'refedit' in AutoCAD to edit an x-ref. To do this they must first check out the reference file from the DMS for editing, otherwise it will be read-only and any changes will be lost. Assuming the DMS allows this, in checking it out to themselves, users will have deprived all their colleagues of the opportunity to work on the file.

If that were not enough, many packages create new 'reference files' as they progress. Unless the user manually tells the DMS that these files are part of the document, they will be lost. In most cases these files will be created on the fly without the user even being aware of their existence. So there is little or no chance of these tools working correctly with a commercial DMS unless extensive customisation is undertaken and maintained.

URL's and the Web

Most modern applications allow users to place links or bookmarks to other documents in the form of URLs. Unfortunately CI/CO systems do not allow users to link to the source documents because these have encrypted names and are in a protected area. Some DMS have tried to solve this problem, but they force users to use the DMS's methods to create their links and/or web pages.

System Unavailability

Any complex system can crash and will require periods when it has to be made unavailable for maintenance. Because CI/CO systems are 'closed' users can't get to their data when the system is down. On these occasions no users will be able to work. Although system crashes are rare, hardware upgrades, software upgrades and patches are common.

Future Proofing

CI/CO systems are continually updated to meet the requirements of the software packages they serve. This is necessary because of their invasive behaviour and becomes a problem when favourite applications change and the DMS won't handle it. Vendors thrive on this 'customisation' activity.

Updating Software

CI/CO systems are generally known as 'middle ware' because they sit somewhere between the user's software and a database. For the whole system to function correctly each module must be compatible with the next. As more are added the chance of ensuring compatibility reduces. For instance, in the case of AutoCAD with a certain DMS, all of the following must be compatible:

Client operating system + AutoCAD + CAD plug-in + DMS Client software + Network protocol + DMS server software + Oracle + Server Operating system.

This only covers the base software and not any customisations which are required to make it work for users. Adding those would further complicate the list.

Even when it is possible to get all of these packages in a suitable version, the hardware at each workstation may not be sufficient to handle it.

Multi-user Systems

MAP is one of a set of products that allow users to treat separate documents as if they were one, and at the same time allow many people to work on data simultaneously. For example an AutoCAD project may be divided into many individual files for both management and practical reasons. Products like MAP allow you to treat all the files as if they are one big database from which you can select and edit any portion. This way many users can work on the same drawings at once without conflict. The problem with a CI/CO system is that once a user has checked out a file, others can't edit it. In other words, a CI/CO system inhibits the use of these collaborate working methods. Vendors try to get around this problem by suggesting that a team leader checks out all the required files to a group 'workspace' and that he then checks them all back in when a revision needs to be noted. This is clearly impractical as the chances of everyone being simultaneously ready to come out of AutoCAD and record a change are minimal.

Multi-user Products

Many tools are becoming multi-user. Examples include software for project planning, CAD and simple databases such as MS Access. The problem users will find when trying to use a CI/CO system with these tools is that once they have checked a file out for editing, their colleagues can't get to it.

Vendors try to get around this problem by suggesting that a team leader checks out all the required files to a group 'workspace' and that he or she then checks them all back in when a revision needs to be noted. This is often impractical, forcing users to keep the file checked out, which defeats the reason for having the DMS and may mean that the file is not backed up.

Home Working

CI/CO systems make working from home very awkward. Taking work home requires a strict discipline to ensure that work is checked back into the system correctly. The process involves:

• Check documents out to the user's 'workspace'.
• Copy them onto (say) a memory stick.
• Work at home.
• Copy from memory stick back into the 'workspace'.
• Use the DMS to check back the changes.

The last step can easily be forgotten and will go completely wrong if, in the course of working at home, users create some additional supplementary files which they fail to either record as new documents or as dependencies of the original.

Email

Most systems try to act as an alternative to an existing e-mail system but lack the features of dedicated e-mail software, e.g. workflow process control. Confusion will arise over which system should be used and when. Also, the management of two sets of address books and data can become impractical.

Ease of Use

A system should only be introduced because it makes certain tasks easier or saves money. All the commercial DMS are replete with dialogue boxes offering a multitude of options which only serve to confuse the poor users who have enough problems getting to grips with their favourite applications, let alone another maze they have to navigate to use them. As for cost, DMSs are very expensive and one would have to be very imaginative to argue that they will save any money.

Searching

DMSs require users to provide all the data, including keywords, type and description, so that they can use their search engine to find the data later on. This is both time consuming and frustrating. More importantly though, subsequently users can only search based on the data they put in.

It Depends On Who You Ask

One of the most disturbing findings was that the managers in companies that had adopted these systems were typically very positive about them whereas their staff told the opposite story. We can only assume that the managers were not prepared to admit their expensive mistake or had not used the system.