Contact Us / Get a QuoteDocument Management Nuts & Bolts
A practical guide to understanding document management system requirements
Introduction
This white paper intends to help business and high-level technical evaluators understand the breadth and scope of the components that make up an engineering document management system—whether it’s on a LAN, a WAN, or the Internet.
Because engineering document management is a mission critical application that touches many people in an organization, it’s my goal to give you a solid foundation in the high-level technical requirements and business considerations of a document management system as early as possible in your research/evaluation process. That way you are 1) better prepared to do a great job asking questions and comparing vendor products; and 2) you are on track for a truly successful implementation, knowing how all the pieces of the puzzle fit together.
Whether you are a team of one or many, whose job it is to understand all the interacting parts of a document management system, this paper is a must-read. For those of you who are new to document management, this material will help you connect your business knowledge with the technical requirements and give you the vocabulary you need for further exploration.
So, let’s get started!
Part 1: Client Software Requirements
Client software requirements define how users interact with the system.
Data Creators vs. Data Consumers
To understand fully the ways users interact with a document management system, you need to appreciate the differences between data creators and data consumers. When it comes to client requirements, you’ll need to consider both groups.
In a design engineering-centric world, data creators are those users who work inside the CAD applications. They create and revise existing CAD documents. In today’s global organizations, data creators are certainly designers and can be engineers or project leads responsible for specifications, analysis, or project and product success. Creators contribute data and documents to the system. They are also your power users and require a more powerful workstation.
Data consumers are the people that need to work with the data submitted by the data creators. Data consumers have different needs and often access the system using a different interface than the data creators. Generally, data consumers access the system to view, print or redline via a streamlined user interface and then, often only part time. Most document management deployments are accomplished using more than one type of client. It’s rare that a company deploys just one type of user interface to access the system. So let’s look at some of the different client deployment methodologies.
Client Workstation Deployment
The first client we’ll discuss is the client that is installed on a local workstation. It is a classic install where the actual program files – such as Word or Excel or Outlook – are installed on each individual’s workstation, as seen in the figure to the right.
Network Client Deployment
A network client deployment is where the document management client is installed on the server in one location. Users in this method use a desktop shortcut to launch the application (see figure below).
Generally, IT appreciates this lightweight deployment because they can install the application in one location and serve updates out to everyone easily. The trade-off is that user performance might take a hit. It’s also important to keep in mind not all document management systems support a network deployment well.
Client Browser Deployment
For many companies today, it’s becoming more important to deploy a client through a browser (see figure on right). Browser access can mean access via the Internet but many also deploy a browser client behind the firewall. These deployments are relatively thin and from an IT perspective should be close to no-touch.
For example, if a person can open a browser and point to a URL and the application of the data housed in it is immediately available.
Remote Client Options
A remote client deployment is yet another option. This entails Citrix, terminal services, or similar technologies, which are popular, centralized methods for IT to deploy access to a document management system. The important thing to understand when using this method is that not all document management systems are friendly to this environment. This method may also require that the CAD applications are deployed on the central server and not all CAD applications support this. So it’s necessary to identify up front if this is a requirement for your organization and whether your chosen document management system supports it.
Part 2: Application Server Software
In the last section, I discussed the nuts and bolts of a document management solution as it relates to client workstation deployment. In this section, I’ll talk about the server-side components, application server software, and the database engine components of the system.
Application Server Software
The application server software is the silent piece of the document management system that users don’t see—but IT does. It’s the brains of the document management solution installed on the server. 
You can think of the application server software as an information broker. It’s what every user connects to and it facilitates data exchange between each user, the database, and the document vaults.
There are a couple of ways you can deploy the application server software. The figure on the right illustrates a deployment where all the server side components are installed on one server, including the application server software, the vault server software, and the database engine.
The figure below illustrates another type of deployment where the application server software is installed on a different server than the database engine. Flexible and scalable document management systems support this modular deployment strategy.
In fact, often there are more server side components, which may be distributed across multiple servers. Architectural flexibility in this regard is solution dependent. In small-to medium-size deployments, I like to recommend keeping all the application server software components on one server, if possible. In larger organizations where user and document counts are higher, multiple servers may be required.
When the database and the application server software are on different servers, make sure you have at least a gigabit ethernet connection between them. Otherwise, you are likely to encounter a performance bottleneck.
The Database Engine
There are three different categories of database engines that document management systems support: Well-known name brands like Microsoft SQL Server and Oracle; less familiar, yet commercially available databases; and proprietary databases developed and supported by the document management vendor.
I am often asked, “Which database is best?” In my mind, the most important question is not “Which database is best” rather, “Which database will best meet my company’s business needs?” If your company has a database standard that IT supports, then the decision is made. If your company has no mandated database engine, then you’ll need to select one.
If you’re a small company without consistent access to database experts, I don’t recommend choosing a “high-end” database solution for your implementation. If you do have DBA expertise in house, then a “high end” solution could be a good choice.
Beyond the basic criteria of price, performance and scalability, the main driver in today’s interconnected business environment is access to your data—whether it be through open database connectivity protocols like ODBC or vendor-provided APIs. You also want the document management systems’
schema to be open and accessible. Your data is your most critical knowledge asset—so make sure you can access it.
As a final thought, I encourage you to understand database engine licensing requirements, as they can be difficult to decipher. Most database vendors offer varied licensing options that can make a significant difference in your company’s overall investment. Take time to fully understand the options before making your final selection. In many cases, database licensing is un-metered and compliancy depends on your understanding of the licensing requirements and the honor system.
Parts 1 & 2 | >> Parts 3 & 4 | Part 5
