Many times, TSG will get involved with clients that have strong developers on staff that come from a database development background and are unfamiliar with the capabilities of Enterprise Content Management (ECM). As database systems expand from just the data to add related documents, the database paradigm approach will typically lead to database entries with file pointers to point/store the related documents. This post will address the shortcomings of a database approach by sharing how leverage of an ECM system simplifies and shortens the development process as document related capabilities are added to the system.
Document Functions
In most situations, we see that the database application was developed first with a user request that got added later. The database paradigm typically starts with the user request “We would like to store these documents with the data”, rather than a content management need from the beginning. A good example would be contracts related to a particular project or sale. In this case a contract management system for the data might have been created with database tools. A developer could easily build a simple upload to a file system and then add an entry to the sale/project data to point to that file. When requested, the developer could add a download of the file itself. This is the approach many clients begin with that is pretty simple. Once users experience some document capabilities, they may be quick to request additional capabilities including:
- I would like to know who added the document and when (Audit – Attributes)
- I would like only certain people to be able to see or change/update the file (Security)
- I would like to version the file based on changes we discussed (Versioning- Check-in/Check-out)
- I would like to render the file to PDF (Renditions)
- I would like to scan files into the system (Scanning)
- I would like to annotate the file but only have selective people see my annotations (Annotate)
- I would like to store related emails/documents with the document (Relationships/Folders)
- I would like to be able to full-text search all the documents (Searching)
For the above functions, a database developer can quickly see the difficulty of adding the database entries as well as the functionality all in custom database code and entries. Often times, database developers will justify the database approach in that ECM tools are, at their core, built on databases that point to file systems. The key thing to understand is that the database model and functions include ALL the document management capabilities to begin with rather than the database developer having to develop from scratch.
Enterprise Content Management System Capabilities
Another difficulty of the database/file system approach is maintaining system integrity. Key to the backup/restore/migration/upgrade of ECM is the ability to snap shot, at a point in time both the file system and the related data (attributes). We have seen system errors where directories of files have been deleted due to system error/hard disk failure or other outage situations. ECM systems give the ability to restore the data/documents as well as maintain system integrity.
API/Service Orientated Architecture
The best approach for extending database applications to include ECM capabilities is via the API or Service Orientated Architecture (SOA). OpenContent is TSG’s SOA for Documentum and Alfresco but also includes support for Solr/Lucene and limited SharePoint. JavaDocs for our SOAP release are still available below:
https://www.tsgrp.com/OpenSource/javadocs/soapwebservices/
Look for an updated document with our 2.1 release before the end of the year.
Database developers should recognize that building an SOA layer to a customized database as well as the supporting backup/recovery synch points with security and all the other functions will require a considerable amount of work. Developers would be better served to leverage and reuse capabilities of ECM products rather than incur the cost, expense, instability and effort of building themselves.
Summary
Many applications start out as database-focused custom applications. Database developers should recognize, as they add document capabilities, that leveraging ECM tools like Alfresco or Documentum, will reduce their coding and support efforts while producing a more reliable and stable system.
Let us know your thoughts below:
Hi Dave,
I 100% agree with your post!. I Just like to add another key point into this matter. The application focus: Content-Centric applications vs Database/Transactional applications are different by nature as they involve different concepts and requirements and functionality.
Beside this central point there is also the “Best Practice” concept and staff skills. Would a developer team be able to match the functionality of an ECM system that took many years of R&D to be built? Probably not. This is the essential concept behind any “licenseable” software, not just ECM. Right?
Saludos,
Jorge S.