One of the common questions I am asked in the course of talking to organizations interested in document management is that of architecture. Where does the software reside, how is it maintained, etc. This is a good question, and the answer depends a lot on the organization’s IT infrastructure, support staff, and how the organization wants to interact with their document management system. There are typically three different architectures an organization can choose from, each with advantages and disadvantages. While exploring every single advantage and disadvantage of each is beyond the scope of this entry, I’ll try to highlight some of the most important differences in the following summary of each.
Traditional Client / Server Architecture: In this arrangement, the document management software is comprised of a server component which resides on a server within the organization. The server software usually interacts with a database server also residing on the network, though some applications will use a built in database engine. A client application is installed on each workstation, and configured to interact with the server. Sometimes a client application installed on an end user’s workstation is referred to as a “thick” client.
An advantage of this configuration is that often times there is more functionality available to the end user within a thick client opposed to other configurations. Heavy duty document editing or redacting is usually easiest within a thick client, and when it comes down to page level security usually your best bet is to use a thick client. Probably the biggest disadvantage of this configuration is the deployment and maintenance of the client software on each workstation. Every update or hot fix needs to be applied to each workstation, and if the organization isn’t using automated deployment tools, this can become a big task.
Web Server Based Architecture: Many document management solutions provide the ability to access information through a web browser rather than an application loaded on the end user’s computer. This architecture is often referred to as a “Thin” client. Any workstation in an organization with a web browser, and possibly some browser plug-ins, will have the ability to log into and access the document management system. Quite often, organizations can provide for access to the system from outside of their firewall for employees working from home or traveling, or to provide portal or collaboration functionality to individuals within and outside the organization. Just as with the previous configuration, the server software will reside on a server within the organization, and will interact with a database of some kind also on the network. The addition of a web server, such as Microsoft’s IIS, Apache, or a proprietary web server will be needed to serve the information to end users.
The overwhelming advantage of this configuration is the ease of maintenance. From an IT perspective, management of the document management solution is reduced to very few applications and devices. Rather than a visit to each workstation PC to apply a hot fix, upgrading the server application is all that is required. A disadvantage of this configuration is a mirror of the advantage of the previous configuration. More often than not, functionality is streamlined to work within a web browser, and the most granular levels of security get harder to manage within a thin client.
One important consideration is that many document management solutions will provide for a mixed environment of both thick and thin client users. If there is a need for both, be sure to inquire about this with the software vendor.
Hosted / ASP / SAAS Architecture: With the ever growing speed of internet access, there is a growing demand for hosted software applications. Document management is no different in this regard. Similar to a thin client architecture, a hosted solution provides access to the document management solution through a web browser. The difference between the previous two configurations is that in a hosted solution, an organization pays a third party to host and manage the server side of the solution. Organizations providing hosted solutions have taken great pains to provide the highest level of security, end to end encryption of data, speed of access and guaranteed uptime. For many small organizations without an IT staff or the internal architecture to support a document management system, this can be a very nice option. Server side software updates, patches, nightly backups, etc., are all taken care of behind the scenes providing for a relatively low maintenance solution while still providing a very robust document management system.
The main advantages of a hosted solution are as stated, the relatively low maintenance required on behalf of the organization, and the ability to access the system from wherever a user may have internet access. The main disadvantage is the same with any thin client configuration, the functionality is streamlined to work in a browser, and the most granular of page level security is difficult to manage. Also a disadvantage, while not always being a fault of the host, is the speed of access to the system. If an organization or user is connected through a slow or unreliable internet connection, the quality of access speed made be an issue. Most solution hosts will work with an organization to determine a solution to any connection issues.
While I’ve mentioned three main architectures, there is also the possibility of overlapping architectures. One arrangement I’ve seen more and more of is an organization who has a traditional document management solution for their day to day operation, that also makes use of a hosted solution to provide an off-site backup of their information (using automated tools), and to use a hosted solution to provide a publishing portal for information needed by users outside the organization. The bottom line is there are a lot of interesting ways an organization can address their document management needs, and usually they’ll make use of one of the above mentioned architectures.
via http://dmtalk.com/index.php/2009/01/architecture-considerations/