Customization

Customization is defined as the amount of change you have made to DDM on top of the base product. These customizations include any of the following elements:

򐂰 Document types with custom meta data fields

򐂰 Binder types with custom meta data fields

򐂰 Changes to the default Binder views, including new columns or action buttons

򐂰 New views added to the Binder

򐂰 Use of the Library or Binder events in the custom Script Libraries

򐂰 Changes to the Notes or Web user interface that include adding your own logo or company color scheme

򐂰 Use of the DDM APIs outside of the product, such as use within a Visual Basic® or C++ application

For purposes of assessing the relevance of your customizations, the type (for example sophistication) of your customizations is more important than how many different

customizations you have done. Find your customizations in Table 4-1. Your level of relevance is the highest “X” that you have.

Table 4-1 Customizations

4.2.2 Hierarchy

Hierarchy is defined as the number of levels of categorization that you use to organize the documents in DDM. By default, DDM requires the following levels of hierarchy:

򐂰 Library

򐂰 File Cabinet

򐂰 Binder

򐂰 Document

A default File Room of “Default” is used if nothing is selected. A default value of “Not

Categorized” is used at the Binder Category level if no Binder Category is selected. If you use every level of hierarchy built into DDM, it may look like the complete hierarchy represented in Figure 4-2 on page 49.

Customization Minimal Average High

Document types with custom meta data X

Binder types with custom meta data X

Changes to default binder views X

New views added to binder X

Use of library or binder events in custom script library

X

Changes to Notes / Web UI (e.g. for branding) X

Use of the DDM APIs outside the product X

Chapter 4. Scenarios: Which might apply to you? 49

Figure 4-2 Complete DDM hierarchy

To determine the level of relevance of your hierarchy in your implementation, look at two factors. First, how much of your existing DDM hierarchy are you using? Second, how

important is the ability to set specific security levels within different levels of the hierarchy? To determine the importance of the hierarchy in your implementation, ask yourself the following questions:

򐂰 Do you use every level of the hierarchy?

򐂰 Do you have anything besides “Default” as your File Room?

򐂰 Do you have anything besides “Not Categorized” as your Binder Category?

򐂰 If you had the opportunity, would you reorganize your document hierarchy to have less levels?

The images below illustrate a breakdown of the hierarchy within DDM to help you further analyze the structure at each relevant level. As you review these, continue to review the questions above, validating the extent to which you currently use the different levels of the hierarchy.

Figure 4-3 illustrates the highest level of hierarchy at the Library level. Security can be set at the Library level.

Figure 4-3 Hierarchy at the Library level

Figure 4-4 illustrates the hierarchy at the File Cabinet Level, with security set at the File Cabinet level.

Figure 4-4 Hierarchy at the File Cabinet level

Figure 4-5 illustrates the hierarchy at the Binder level. Security can be set at both the Binder level and the document level.

Figure 4-5 Hierarchy at the Binder level

Once you review your existing DDM hierarchy, you need to decide whether you want to maintain the exact levels after you migrate or whether you want to simplify to a less complex hierarchy and use tagging to locate files. If you want to maintain the exact hierarchy you have in DDM, you are in the AVERAGE level of relevance square. If you want to move to a flat hierarchy, like Lotus Quickr supports with just a Place and Library, then you would be in the MINMAL level of relevance square. If you have customized the hierarchy to increase the number of levels that DDM supports, including adding more than one binder category, you will be in the HIGH level of relevance square.

Chapter 4. Scenarios: Which might apply to you? 51

The hierarchy of Lotus Quickr is more attuned to the modern day, Web 2.0 thought process of “everything is flat and we let the user tag documents” The tagging process is done by the user completely. They generate the tags, enter them, and use them. The user can locate

documents through a Tag Cloud or through searching. If you prefer a less complex, flatter hierarchy, consider moving to this methodology of classifying documents.

4.2.3 Security

DDM provides multiple options for managing document security, You can have custom security settings at the following levels:

򐂰 Library through Domino.Doc Library Users Groups

򐂰 File Cabinet

򐂰 Binder

򐂰 Document

For many DDM implementations, security is set at the Library level and inherited down to the document without any changes. If your implementation looks like this, then you would be in the MINMAL level of relevance square.

If you have custom security settings at the File Cabinet or Binder level, but everything else inherits from them, you would be in the AVERAGE level of relevance square. Examples of this are as follows:

򐂰 Library with DDM Users groups security settings

򐂰 File Cabinets with custom security

򐂰 Binders inheriting from the File Cabinet

򐂰 Documents inheriting from the Binder

򐂰 Library with DDM Users groups security settings

򐂰 File Cabinets with security inheriting from the Library

򐂰 Binders with custom security

򐂰 Documents inheriting from the Binder

If you have security that is custom at every level of the DDM or have modified DDM to have different security settings, you would be in the HIGH level of relevance square.

4.2.4 Workflow

DDM has two workflow processes that are built into the product. There is a review workflow cycle and an approval workflow cycle that puts a document through process. Each document can go through both review and approval processes when a document is in a draft status. What makes DDM different than many of the document management systems in the same class is that the review and approval cycle are done on a working draft while the previous published version is available to anyone with read access to the document.

Workflow for DDM is set at the document type, so various workflow patterns could be intermixed in a single hierarchy. This allows for complex workflow patterns for even the basic of document management implementations.

If your DDM implementation is not using the review or approval workflow process or you are just using the saving of a document as a version as your publishing process, you would be in the MINIMAL level of relevance square.

If you are using review and approval process for documents and have created custom document types to facilitate the workflow process, you would be in the AVERAGE level of relevance square.

If you have done any of the following within DDM, then you would be in the HIGH level of relevance square:

򐂰 Using DDM Custom Events to intercept the document type review and approval workflow processes

򐂰 Changing the security of a document through customizations during the Workflow process

򐂰 Any integration with external workflow systems

Any any of these cases you will need to understand any workflow customizations before any migration or upgrade.

4.2.5 Combinations

If you discover that your DDM implementation has one of the focus areas as HIGH and the others as AVERAGE or MINIMAL, you are not atypical. You might also find that if you have multiple libraries used by different user departments, the priority matrix might be different for each. The priority matrix is a tool to help you get an understanding of your implementation and what effort level will be required to move to another solution.

If you are having difficulty gathering the information to complete the priority matrix or you are unsure of the correct categorization (perhaps because you are not the original implementor or the solution), the best method is to work with an experienced DDM developer to document your environment and help you determine your next steps. Any time and money spent at this stage of your process to move from DDM to any other system will pay major dividends down the road.

4.3 Customer Scenarios

The three scenarios that are typical for DDM customers are as follows:

򐂰 Document Store

򐂰 Advanced / Team Document Management

򐂰 Robust Document Management System

Each one of these scenarios has a different use case, level of complexity, and requirements. This section will detail each of the scenarios and the characteristics that will help you decide which one is right for your implementation.