Most companies have either digitized or are in the process of digitizing their documents. Often times this has involved purchasing (or subscribing) a document management software (DBMS). As to which software to use, there are varying and competing options galore. Feature sets distinguish them from each other, yet somethings are the same across the board.
Almost all document management solutions have a scanning interface. This allows the user to attach a capture device such as a scanner and use it to convert paper documents to a digital format. Some of the options will allow you to simply drag an object (it could be a picture, a document or any other file) into the DBMS. This is a desirable feature because it practically gives the user the ability to store almost any type of file in the DBMS. Consumer grade knock-offs are limited in this and only allow for scanned documents to be stored in the system.
It is particularly helpful if the DBMS allows for a document to be 'printed' into the system. How does this work? The DBMS creates a printer object in the Operating system. Users who use this print object automatically convert a normal print job into a PDF or image (such as TIFF or Bitmap) and then this gets stored in the DBMS. This is a very popular and useful tool with Enterprise users who like the fact that they don't have to print to paper first. Plus, it is easier to track and use an electronic copy of the 'paper' than if they had printed it outright. In my opinion, this should not just be a feature, this should be a necessary functionality.
When a document or an object is stored in a DBMS, a set of metadata needs to be attached to it. Most systems store this in a database system, most commonly the Microsoft SQ server. The metadata is a set of fields that define information about the document or object. Most organizations just need a few group of index fields. As an example, a college will have a field for the student ID number, first name, last name, year, faculty, just to name a few. It is generally assumed that every student file or document that needs to stored in the DBMS will need this information. The beauty of this is that when it comes to retrieval (or search) for the document, there are several ways to search for the document both separately and together. So you can search for a student with a first name "Joe" and in the faculty of "Science". This search may be too general, but you get the idea, metadata is crucial in being able to quickly and smartly find documents in a DBMS.
Keeping the metadata in a database system is not just easy but also desirable. By having the data stored in a standard database, it allows other applications or even developers to access it as input for other applications. As you might imagine, it's with features like this where you get the sense that the various DBMS systems diverge. The more serious enterprise level DBMS's will either allow you to access the relevant data , sometimes directly in SQL. Security is almost always an issue, so direct access to SQL is unlikely. Most of the times though, a DBMS system will have a development interface (API) that allows developers to interact with the data in real time. The DBMS company will also have a trove of sample Code to guide a developer through their API. A connection class in the API will ensure that unless you have the proper permissions, you cannot view the data.
In the next article I will go into more details on capture methods for DBMS.