Designing Documentum Applications a ... - Dell EMC Isilon...2010 EMC Proven Professional Knowledge Sharing 4 Introduction Designing one application is relatively easy. It is most important

EMC Proven Professional Knowledge Sharing 2010

Designing Documentum Applications, a Multi-Dimensional Challenge Jacob Willig

Jacob Willig, LazymenSenior Documentum [email protected]

2010 EMC Proven Professional Knowledge Sharing 2

Table of Contents Table of Contents .............................................................................................................. 2 Introduction ....................................................................................................................... 4

Article structure .......................................................................................................... 5 Intended Audience ..................................................................................................... 6 Background and Focus .............................................................................................. 6 Note to reader ............................................................................................................ 6

1. Organizational Goals ................................................................................................. 7 1.1 Reduce cost ...................................................................................................... 7

1.1.1 Licenses ........................................................................................................ 7 1.1.2 Personnel ...................................................................................................... 7 1.1.3 Hardware ....................................................................................................... 8

2. Additional Challenges in Documentum Application Development ............................. 9 2.1 Documentum Development Paradigm .............................................................. 9 2.2 Business Logic redundantly defined ................................................................ 11 2.3 Monitoring inefficient and laborious ................................................................. 11 2.4 No OOTB Ingestion Service available ............................................................. 12 2.5 Extra restrictions added by Company Policies ................................................ 12

3. Design Dimensions .................................................................................................. 14 3.1 Dimension 1: Operational Efficiency ............................................................... 14 3.2 Dimension 2: Reuse ........................................................................................ 14 3.3 Dimension 3: Required Skill Sets .................................................................... 14 3.4 Dimension 4: Required Learning Curve .......................................................... 15 3.5 Dimension 5: Flexibility of an organization to optimize its workforce............... 15 3.6 Dimension 6: Number of Required Personnel ................................................. 15 3.7 Dimension 7: Required Support Effort ............................................................. 16 3.8 Dimension 8: Total Operational Cost .............................................................. 16 3.9 Dimension 9: Development and Deployment Caused Issues ......................... 16 3.10 Dimension 10: Return on Investment on Short Term ...................................... 17 3.11 Dimension 11: Return on Investment on Long Term ....................................... 17 3.12 Dimension 12: Redundant Implementation of (Business) Logic ...................... 17 3.13 Dimension 13: Operational Downtime ............................................................. 18 3.14 Dimension 14: Data Loss and Corruption ....................................................... 18


3.15 Dimension 15: Diversity Utilized Techniques .................................................. 18 3.16 Dimension 16: Ability to be Utilized by External Applications .......................... 18

4. Solutions .................................................................................................................. 19 4.1 Dedicated Enterprise Commitment ................................................................. 20 4.2 Documentum Services Control Script ............................................................. 20 4.3 Ingestion Service ............................................................................................. 21 4.4 Functional and Technical separation between applications ............................ 22

4.4.1 Content Server ............................................................................................ 24 4.4.2 Ingestion Server .......................................................................................... 24 4.4.3 Taskspace Server ........................................................................................ 25

4.5 Log Management ............................................................................................ 25 4.6 Explicit separation of Support roles ................................................................. 26

4.6.1 Documentum Technical Support ................................................................. 26 4.6.2 Documentum Application Support ............................................................... 26 4.6.3 Documentum Functional Support ................................................................ 27

4.7 Release Management ..................................................................................... 28 5. Final Remarks .......................................................................................................... 28 Biography ........................................................................................................................ 29 Appendix 1 – Terms and Abbreviations .......................................................................... 30 Appendix 2 – Available Actions Ingestion Service .......................................................... 31 Appendix 3 - DCTMCTRL Documentum Control application .......................................... 32

Disclaimer: The views, processes, or methodologies published in this compilation are those of the authors. They do not necessarily reflect EMC Corporation’s views, processes, or methodologies.


Introduction Designing one application is relatively easy. It is most important to deliver what the

customer / business requires. They need it for their daily operations and typically provide

the budget. Designing another application is just as easy if you host it in a separate

environment. Things become more complex when you want to host the second

application on the same environment. You must consider these extra dimensions of

complexity while designing. The more applications that are built and hosted on the same

environment, the more complex the situation becomes.

These dimensions of complexity do not apply only to IT development. There are very

interesting examples outside of IT that have many parallels. The IKEA product design

process is one.

Designing a product that is fully attuned to customers’ needs is not good enough. IKEA

designers are challenged to care for many dimensions of complexity whilst designing a

new product:

- retail price - appeal - durability - material - transportation - reuse of components - usefulness - ease of assembly by customer - environmental impact

Many IKEA products are composed of smaller (generic) components that are easy to

produce, ship, replace, and assemble.

(see http://designinnovationinstitute.org/behindikea_trans.html where IKEA designer

Knut Hagberg offers a nice example of how they designed the Mörker lamp).


As many and likely more considerations are applicable while designing Document

Management applications on a Documentum Platform. A central support team must

support new applications. They need to be compatible with the platform while at the

same time maintainable and upgradable without interfering with other applications and

with the least possible (expensive) effort and resources (hardware and people).

Most design considerations can be categorized into separate dimensions that have a

certain correlation. If one consideration (beauty and style) is maximized, it typically

negatively affects other considerations (efficient shipping, ease, and cost of production).

We should maximize as many different dimensions as possible. This is a growing

challenge as still more dimensions are discovered while improving quality of design.

In this article, I will discuss all dimensions involved when designing new Documentum

based applications for an existing Enterprise wide Documentum Platform. We will focus

on Documentum applications, but the discussion easily applies to many other IT

development contexts.

Article structure

Before we define the dimensions, we need to know more about the design

considerations and consider the reasons given by the organization for implementing a

Document Management System (Chapter 1).

In addition to organizational goals, additional challenges can and will be presented while

designing Documentum based applications. We discuss these challenges in more detail

(in Chapter 2).

From this context, we will identify several Design Dimensions. All of these dimensions

are related in some way and maximizing one dimension negatively influences others

(Chapter 3).

Finally, I will present several solutions that helped me to maximize many of these

dimensions, while at the same time fulfilling better more short and long term business

requirements (Chapter 4).


See Appendix 1 for a table of used abbreviations.

Intended Audience

This article is intended for anyone interested in implementing a Document Management

System as an enterprise wide platform hosting many (partly unrelated) information flows.

The language might be very technical in some parts, but less technical readers can

simply skip these technical sections without losing the overview of this article.

Those who have several years of experience with Documentum will acknowledge many

of these challenges and hopefully be inspired by the solutions.

Background and Focus

I have used experiences from several projects and different clients to write this article.

They wanted to reduce paper document processing by introducing digital document

processing using the Documentum suite. Hence, the focus of this article is on the

Archiving, Retrieval, and Task processing functions of the Documentum suite.

Note to reader

All solutions discussed in this paper are result of my personal attempts to find solutions

for challenges experienced during my activities in the last few years. The value of

several of these solutions is considered high by several experts in the Document

Management field and some of them argued not to publish them at all. Several planned

solutions have been left out, or only briefly discussed, for this reason.

The ideas that are discussed in this article are shared to inspire fellow Documentum

Experts to join me (and others) in pursuing a more generic approach to implementing

Documentum and to stop reinventing the wheel in Point Solution implementations.


1. Organizational Goals There are three requirements that drive the introduction of a DMS:

• reduce cost

• increase quality of service

• comply with (legal) regulations

All design dimensions originate from one or more of these three base requirements.

1.1 Reduce cost

Cost reduction is the one driver of all requirements. Poor quality of service and violations

of legal obligations both eventually translate into cost. These are discussed separately.

There are also some direct costs associated with the use of a DMS:

- Licenses

- Personel

- Hardware

1.1.1 Licenses

Cost of licenses is typically related to the number of seats, so fewer seats require a less

cost. Some licenses are related to the amount of CPU’s, so less hardware reduces cost.

Both can be achieved by increasing Operational Efficiency and Throughput (Dimension

1) as well as maximizing Reuse (Dimension 2)

1.1.2 Personnel

Cost of personnel can be broken down:

- Required skill sets and Critical Resources (Cost of required personnel)

- Required Learning Curve (Startup Time new operational and support personnel)

- Operational Effort (Amount of operational personnel required)

- Support Effort (Amount of support personnel required)

Skilled resources are more expensive, more difficult to replace, and difficult to find.

Reducing the required skill set and number of skilled resources can drastically reduce

the operating costs as well as reduce the organizational risks these critical resources

pose. Minimizing Required Skill Sets (Dimension 3).


Not only is dependency on specific employees unwanted, the cost of replacement is an

important factor. Employee turnover is peaking. Reducing the Required Learning Curve

(Dimension 4) can drastically reduce the cost of unavoidable turnover, as well as

Increase the Flexibility of an organization to optimize its workforce (Dimension 5) by

quicker replacement of inefficient employees.

Most Documentum applications are implemented to support an organization’s primary

process. Targeting a minimum required effort of operational personnel helps them to

perform more tasks per day, reducing Number of Required Personnel (Dimension 6) as

well as maximizing Organizational Efficiency and Throughput (Dimension 1).

Implemented support procedures affect the amount of resources required to operate

them as well as the skill set needed to understand and perform the procedures. This

maximizes Reuse (Dimension 2), eases the Required Support Effort (Dimension 7), and

minimizes the Required Learning Curve (Dimension 4) for new support personnel.

1.1.3 Hardware

I have already mentioned the relation between certain licenses and used CPU’s. Other

than additional license costs, these core server components also have a base hardware

cost. Reducing CPU and other server hardware components reduces Total Operational

Cost (Dimension 8). Finding the proper balance between required hardware and

providing enough performance and throughput, as well as enough development, test,

and load test environment is a challenge but not always a priority. The latter can be

defined as reducing Development and Deployment Caused Issues (Dimension 9).


2. Additional Challenges in Documentum Application Development

Developing a Documentum application poses some additional challenges. Some of the

most important challenges faced during the last ten years:

- Documentum Development Paradigm

- Business Logic redundantly defined

- Monitoring is inefficient and laborious

- No OOTB Ingestion Service available

- Extra restrictions added by Company Policies

2.1 Documentum Development Paradigm

During the past ten years, several practical (ab)uses of designing and implementing

Documentum based applications have been noticed:

- Every new application = a new Repository

- Every new application = a new development team

- Every new development team implements their personal (different) best practices

- Projects cover building a new application, but no after care

- Future enhancements not considered and thus very difficult to achieve

- Attempts to push for generic solutions and reuse failed or made very difficult

- The more applications that were created and reached Production status, the

more difficult support teams’ task

The Documentum Development Paradigm is the reason for this reoccurring pattern.


The paradigm finds its roots in the way many organizations fund their new

developments:

- New development is funded by Business rather than Concern; hence Business

Requirements are the priority.

- The design generic components typically are not allowed by the funding business

as this stretches an already tight budget and does not directly improve the

fulfillment of set requirements.

- Funds are limited and drive priorities, hence pushing for short term delivery to the

business posing the requirements.

- Considering the long term targets negatively affects the budget, hence it is not

typically allowed.

- The Documentum suite does not provide use-ready applications; some form of

customization and configuration is needed to facilitate the requirements.

- Documentum skilled development experts are scarce, hence expensive and

hired for a limited time. They are rehired for every new project resulting in a high

turnover among experts.

- Even reuse of the same development experts does not prevent them from using

different solution strategies, as their focus is on fulfilling business requirements.

This drive for fulfilling project specific business requirements tends to result in

locally optimized solutions that do not necessarily positively affect the total

Documentum platform.

- Business does not directly care for other current solutions and future

developments.

- Funding is limited to the project and ends when the project becomes a Going

Concern.

- Support must accept whatever is built, rather than determining the best solution

given other current and future uses of Documentum.

Additional related design dimensions:

- Maximize Return on Investment in the Short Term (Dimension 10)

- Maximize Return on Investment in the Long Term (Dimension 11)


2.2 Business Logic redundantly defined

Business Logic tends to get redundantly defined within a Documentum application.

Some form of business logic is applied during ingestion of new documents (inside client

application processing the ingestion or inside XML Applications). Workflows tend to

implement a lot of business logic in the form of automated tasks performing business

specific actions. Documents being updated can have TBO’s enforcing (often

redundantly) even more business logic. Typical forms of redundant logic:

- Validation algorithms

- Reingestion procedures

- Meta data management

Additional related design dimension:

- Minimize Redundant Implementation of (Business) Logic (Dimension 12)

2.3 Monitoring inefficient and laborious

The proactive monitoring of services is an essential part of support. Log files are one of

the most important resources when investigating problems or when attempting to identify

potential problems. Unfortunately, the Out of the Box implementation of logging is not

optimal:

- Logging on both Content Server and Application Server all over the place; every

source is configured differently.

- Logging levels are not always proper. Many Errors are reported as Warning,

Errors also lack proper context.

- Log files reside on file systems and cannot be easily accessed by experts.

Separation of Application Support and Technical Support makes this even more

difficult.

- Log file rotation is configured inconsistently and sub-optimally.


- Minimize Operational Downtime (Dimension 13)


2.4 No OOTB Ingestion Service available

There is no Out of the Box service available for ingestion of documents. A great deal of

customization is needed if many different types of documents need to be archived in

Documentum, each requiring their own placement logic. One solution is XML

Applications that do not require any Java coding. An XML Application can be used to

accept an xml content containing metadata and a file location. This results in the proper

folder structure to be created (if not yet there) and replaces the initial xml content with

the true content (using the file location provided in the xml content).

However, XML Applications do have drawbacks:

- XML Applications leave behind an object for every execution (required in order to

make it create folder structures without content)

- XML Applications can corrupt the Repository by improperly resolving concurrent

Folder creation conflicts

- XML Application have very limited logging; errors are limited and often unclear

- Business Logic partly in external DFS Client, and partly in Workflows responsible

for finalizing ingestion after content is initially stored


- Prevent Data Loss and Corruption (Dimension 14)

2.5 Extra restrictions added by Company Policies

Many of the challenges described here originate from a project I have been working on

recently. In addition to the above generic challenges, there are sometimes restrictions

based on company policy. Some examples:

- No Java coding

- Configuration before customization

- All interfacing through Webservices


Java coding cannot be avoided in most cases. Documentum does not provide all

required tools OOTB to fulfill business requirements. BPM has been designed to be

extended by Java code based Activity Templates. TBOs and SBOs can only be added

by Java code.

You can minimize Java coding by ensuring that missing functionality is added

generically. Most missing functionality can be added in the form of generic components

that require little or no future changes. Most of the time, it even concerns modules that

could (should) have been part of the OOTB suite.

Additional related design dimensions:

- Minimize Required Customizations (Dimension 15)

- Minimize Diversity Utilized Techniques (Dimension 16)

- Maximize Ability to be Utilized by External Applications (Dimension 17)


3. Design Dimensions

3.1 Dimension 1: Operational Efficiency

Advantage: Increasing Operational Efficiency minimizes end user effort to operate their

Primary Process.

Disadvantage: Increasing Operational Efficiency requires customization and tends to

conflict with Dimension Reuse. All customizations introduce a non-generic component

and (in)directly introduce a more complex solution, negatively affecting Dimensions

Required Support Effort and Reuse

3.2 Dimension 2: Reuse

Advantage: Maximizing Reuse reduces the Development Effort (cost and time) and can

help reduce Maintenance Cost. A more generic and consistent solution positively affects

the Dimension Minimizing Learning Curve.

Disadvantage: The more generic components become, the less flexible they tend to

become. In the quest for a generic and consistent approach, a more efficient but less

flexible design might be the consequence.

3.3 Dimension 3: Required Skill Sets

Advantage: Minimizing Skill Sets reduces cost by requiring less skilled personnel to

operate the primary process, as well as support and development.

Disadvantage: Less skilled personnel also implies less involvement in the core of the

design and design decisions. Less skilled support personnel will follow the procedures

and guidelines without questioning or understanding them. This is good when aiming for

the status quo, but does not help improve Best Practice. Creative and innovative ways

of doing things are less expected when the skill set is minimized.

Example: The introduction of WDK Development reduced the required skill set for

developing a Documentum application. However, less skilled developers make mistakes

that more skilled developers would never make.


3.4 Dimension 4: Required Learning Curve

Advantage: Skill Sets help reduce learning curves, but any new application has a

learning curve. A consistent, transparent, and predictable design helps reduce the

learning curve. New applications will be introducing more of the same, easing the burden

for all related actors.

Disadvantage: designing generically is more expensive in the short term and requires

skilled developers. This skill is both scarce and expensive.

3.5 Dimension 5: Flexibility of an organization to optimize its

workforce

Advantage: Being able to adjust the workforce to demand can drastically reduce cost.

Easy replacement of inefficient elements helps increase efficiency and throughput thus

limiting costs and increasing quality of service.

Disadvantage: A high turnover in the workforce tends to negatively influence

commitment and overall knowledge. The workforce is able to maintain status quo, but is

less able to develop and implement best practices.

3.6 Dimension 6: Number of Required Personnel

Advantage: Limiting the number of required personnel reduces the cost or increases

throughput.

Disadvantage: Over-automating an application also can increase the complexity of the

applications’ design. All the hidden automations need to be maintained. Also, performing

certain procedures manually does help the organization to maintain a certain level of

knowledge about the backend of the application. If operating with minimal resources, the

risk and impact of downtime is exponentially increased.


3.7 Dimension 7: Required Support Effort

Advantage: Ensuring new applications have a limited impact on the support organization

helps total time to production as well as easing the learning curve. More of the same is

always easier and less costly than a total new application with a thick operation and

support manual.

Disadvantage: Maximizing this dimension tends to limit the ability to achieve a

maximized operational efficiency. Totally tuning the user interface to the specific

requirements tends to deviate from earlier user interface designs. What is more efficient

for one application can negatively affect the efficiency of other applications. A drive for

consistency forces a decision for one of those designs or a less optimal design for all

applications.

3.8 Dimension 8: Total Operational Cost

Advantage: Reducing total cost is obviously a positive effect.

Disadvantage: Reducing total operational cost does take time and requires skilled

resources. Financing the purchase of the initial hardware tends to be funded by projects

and is less of an issue as the priority is on timely delivery. A proper load test with

corresponding design improvements is regularly skipped in favor of earlier delivery.

Improvements in efficiency and resource utilization more often are sought to ease

bottlenecks rather than to deliver an optimized application to reduce hardware impact.

3.9 Dimension 9: Development and Deployment Caused Issues

Advantage: Every actor benefits from a flawless design, implementation, and support.

The earlier a mistake is discovered, the least amount of effort and cost is required to fix

it. Workarounds are always a waste.

Disadvantage: Efforts required to reduce flaws and mistakes take time and resources

during the development and testing phases. Time is not always an option; testing often

is skipped or only partially performed. Everyone knows this is a mistake, but it is still

common.


3.10 Dimension 10: Return on Investment in Short Term

Advantage: Short term costs are typically funded by the project requiring the new

application. Timely delivery and maximized requirements fulfillment are favored over the

impact on support organization and long term effects. Minimizing short term costs fulfills

the goals set by the business.

Disadvantage: A drive for short term goals yields short term results. An application

fulfilling most business requirements is created, but it may be an unsupportable monster.

In the end, the local business will be affected but by that time the funds come from other

sources and it is someone else’s problem.

3.11 Dimension 11: Return on Investment in Long Term

Advantage: An organization is best served by aiming for long term benefits. A good solid

long term return on investment is better than an inexpensive solution that has a very

expensive future impact.

Disadvantage: Short term benefits can decide the future of a new application. Not being

able to meet short term benefits can kill projects regardless of long term benefits.

3.12 Dimension 12: Redundant Implementation of (Business) Logic

Advantage: Preventing redundant implementation of logic prevents ambiguity. If the logic

needs to change while it is implemented with two different techniques in two different

places, it needs to be altered at the same time in both locations. If not, ambiguous

behavior will result.

Disadvantage: It is not always possible to prevent redundancy. Restricting the use of

specific technologies (no Java coding allowed) can force the redundant definition of the

same logic in different locations. It can also be more efficient to redundantly implement

functionality. Some techniques are simply best tuned for parts of the application.

Disallowing redundancy can have a negative impact on performance.


3.13 Dimension 13: Operational Downtime

Advantage: Downtime is costly and should be prevented. Designing error free

applications helps prevent downtime.

Disadvantage: Designing error free and extensive (load and concurrency) testing is

costly and negatively impacts time to production.

3.14 Dimension 14: Data Loss and Corruption

Advantage: Data loss and corruption is unwanted.

Disadvantage: The required effort to prevent data loss and/or corruption can outweigh

the consequences. However, this often is not just a matter of opinion bust simply needs

to be considered. Too often this is demanded late in the project or even after it is taken

into production.

3.15 Dimension 15: Diversity Utilized Techniques

Advantage: Limiting the utilized techniques reduces the required skill sets to maintain

the applications.

Disadvantage: It is not always possible to prevent the use of certain techniques, as they

could be the only available or most efficient option.

3.16 Dimension 16: Ability to be Utilized by External Applications

Advantage: A loosely coupled architecture is favored over a tangled web of interacting

applications.

Disadvantage: Enforcing a single technique for interacting with the Documentum

Platform can prevent the use of much more efficient interfacing techniques for specific

external applications


4. Solutions It is impossible to maximize all design dimensions. Even just realizing all of them while

designing can be a big step forward. However, it is possible to come up with creative

solutions to positively affect many of these dimensions, contrary to many experts’

expectations.

It does require a great deal of skill, determination, and generic thinking. These types of

skilled experts seem to be very scarce. It is disappointing to realize so little effort seems

to be put into this exercise.

Hopefully, this article helps other experts to undertake this exercise and surprise the

community with innovative and effective solutions that others might not consider.

The solutions described below did provide an Enterprise wide Document Management

platform that is flexible enough to quickly adopt new document types being archived.

New applications still introduce unwanted deviations, but the battle continues and we are

winning.

Solutions discussed:

- Dedicated Enterprise Commitment (not really a solution, but important)

- Documentum Services Control Script

- Ingestion Service

- Functional and Technical separation between applications

- Log Management

- Explicit separation of Support roles

- Release Management


4.1 Dedicated Enterprise Commitment

A dedicated enterprise commitment is required to properly balance the weight business

naturally brings. Properly limiting solutions in the form of generic components and

centrally managed selective best practices helps prevent the wild growth of technologies

and customizations. Most applicable solutions seem to be a central group of experts

able to support the enterprise wide platform as well as dictate procedures and

guidelines. They act as guardians of the platform. This group should aim for the best mix

of solutions to maximize the interests of the enterprise as a whole.

4.2 Documentum Services Control Script

Control over the Documentum services OOTB is limited. There is a control application

for the Windows version, but even that is limited in functionality.

Documentum documentation instructs administrators to manually start and stop the

services in a specific sequence using multiple startup and stop scripts. This is inefficient,

fault prone, and requires both technical insight and understanding about what these

scripts are doing and, more importantly, what to do when something goes wrong.

A proper service control script/tool can achieve the following:

- Reduce required level of Documentum knowledge for operators

- Reduce required effort for control activities as start, stop, clearcache type of

activities

- Enable integration with monitor tools and other service control tooling

- Ensure control procedures are always performed exactly the same over and over

again. This enforces a Best Practice for these procedures, as well as a

predictable result every time.

- Stepping stone for more advanced features like, compareconfig, run_script,

install_docapp, install_dar


There are also disadvantages to this approach:

- A script can be operated by general support personnel without any

understanding of Documentum. Anyone can operate it, but having anyone

pushing the buttons can be very dangerous. Potential consequence:

o Unrecognized issues

o Not able to solve issues without help

o Unable to understand and extend script

o If the script fails, there is not enough knowledge to perform required

actions without it

- Changes to the script require a expert in both scripting language and

Documentum

See Appendix 3 for an overview of functions it is able to perform.

4.3 Ingestion Service

The Documentum Suite does not provide any adequate Ingestion Service OOTB. To

facilitate Ingestion of many different (independent) Information Flows, flexible

straightforward tooling would be convenient.

The following characteristics are desirable:

- Configurable without much Documentum expertise required

- No Java / DotNet coding

- Proper ‘shielding’ of flows, inter-flow interference protection

- Highly concurrent and thus thread safe

- Proper error handling and reporting

- Stable and high performance (throughput)

- Easy to document the configuration, so that all parties involved can understand it


A new Ingestion Service has been developed, capable of performing all required

business logic related to placement of content or processing of metadata updates in a

central location. It introduces flexible configuration through an intuitive xml file, proper

logging, and tuned for multithreading and high performance.

It is based on Action Sequences that define a generic operation. Simply defining a

sequence of Actions is enough to configure how a specific type of document needs to be

processed when being ingested or reingested.

Actions that are Documentum specific (applylifecycle, createdocument, checkout, etc)

are generically implemented with limited Java coding. No additional Java coding is

required unless a new generic type of action needs to be added.

If TBO’s and SBO’s internally do not implement any business logic, but call the Ingestion

Services Action Sequences, the need for any Java customizations is limited to a bare

minimum.

See Appendix 2 for an overview of available types of actions.

4.4 Functional and Technical separation between applications

Generic reuse offers advantages, but needs to be implemented smartly. It is important to

maintain a functional and technical separation between applications. The use of

dedicated prefixes per application and strictly enforcing them in all Naming Conventions

throughout the configuration are the main tools. It is impossible to cause functional

interference between applications when configuration items are named with the prefix.

Avoid duplication of functionality. However, some duplication in configuration is favored

over generic implementation where it concerns business functionality:

- object model

- lifecycles

- workflows

- ingestion related configuration

- taskspace applications and related forms


Although duplication of functionality is a risk as it can result in differences between

implementations, this risk can be mitigated or reduced by documenting and enforcing

best practices. With every new release of one of the Applications, you can decide to

update old components to the latest best practice guidelines. This ensures

independence from other applications being deployed with improved design. It also

delays the moment of update to a suitable point in time for that specific application.

It is up to the guardian of the platform to urge the old applications to update to improved

best practices as soon as efficiently possible. The more that applications differ in applied

technology, the more complex the total environment becomes to maintain. For this

reason, EMC limits the support on specific versions of their Documentum products. A

similar concept could potentially be introduced regarding applications hosted on a

Documentum Platform.


4.4.1 Content Server

A clean separation on both the functional and

technical levels for Content Server

components can be achieved by:

- Applying an unique prefix per

application for all configurable

items, like:

o Object Type

o Lifecycles

o ACLs

o Workflows

o Groups and Roles

- Separate Cabinets for archived documents

4.4.2 Ingestion Server

The Ingestion Server has been designed to concentrate all configurations into a single

xml configuration file per application. It enables the definition of all automated activities

required to properly process incoming documents and metadata. It is also able to

reingest documents that already are in the system and needed metadata enrichment

before final placement. An experimental TBO was able to efficiently trigger this service

into applying a chain of activities on an object. This way, all automated business logic is

effectively concentrated in one configurable place instead of redundantly defined in

several places in the Repository (TBO’s, XML Applications, Workflows, SBO’s,

Lifecycles, etc)

Documentum OOTB Services

Platform Fixes and

Customisations A

pplic

atio

n1

App

licat

ion

2

App

licat

ion

3

App

licat

ion

4

App

licat

ion

5Content Server Taskspace Server

Ingestion Server


4.4.3 Taskspace Server

If customization at the Taskspace Server level is required, it is best to separately define

customizations per application by prefixing the custom files and locating them in

separate custom folders.

4.5 Log Management

There are several inconveniences concerning the default error logging inside the

Documentum Suite.

1) Logging is hidden in files and needs to be actively monitored to notice

operational issues

2) Log files are spread across the platform

3) Many log settings are different and thus inconsistent

4) Log files reside on the servers running the Documentum software components.

Hence, they are only accessible by Technical Support. Technical Support most

likely will have to forward many, if not all, errors to get Application Supports’

proper analysis

Technical Support is typically responsible for monitoring of error logs; Application

Support has the best ability to understand these errors and deal with them. Application

Support, however, should not have access to the Filesystem of the OS and therefore

cannot monitor these log files directly.

Solution:

1) Enable SMTPAppenders on all logging sources. This way all ERROR type

loggings will be emailed to the proper team without Technical Support having to

actively monitor these logs and forward any found Errors.

2) Send all error log emails to Application Support, so no error is unnoticed and can

be dealt with quickly and without the need to monitor the inbox.

3) Reconfigure all log settings across the platform and configure them to be

consistent. Have a central log location with proper and consistent log levels.


4.6 Explicit separation of Support roles

Define specific support roles and their responsibilities to reduce required Skill Sets and

limit the number of critical resources.

The following separate roles will be discussed below:

- Documentum Technical Support

- Documentum Application Support

- Documentum Functional Support

4.6.1 Documentum Technical Support

We typically consider that a technical support team is expert in the product it supports.

However, with proper tooling, this expensive skill set is not a requirement for Technical

Support of a Documentum Platform.

Skill set:

- General Technical Support skills

- Limited or General Documentum Suite knowledge

- Procedural and precise (no cowboys)

Responsibilities:

- Operate the Documentum related services (stop, start, clear cache, etc)

- Monitor the Documentum related services

- Install Packages (Fixes, Releases)

4.6.2 Documentum Application Support

Skill set:

- Documentum experts

- Deep inside knowledge of both product and running applications

- Able to create new guidelines and procedures with gained insight and knowledge

Responsibilities:

- Guardians of Platform

- Proactive monitoring internal product behavior

- Small Development efforts (fixes and small releases)

- Guidance and review of Developers of large Development efforts

- Capacity Management


4.6.3 Documentum Functional Support

Skill set:

- Knowledge of Businesses serviced with Documentum Platform

- Functional insight in and understanding of released Applications on platform

- General knowledge of Documentum Platform capabilities to perform basic

support

- Able to translate business requirements and requests into proper functional

requirements

- Able to acquire proper understanding of issues experienced by end users and

translate them into a proper issue description / resolution

- Able to perform most common problem resolutions and assist business in better

understanding on how their requirements are translated in product behavior.

Responsibilities:

- First line support (second if behind Support Desk) Incident Management

- Release Management

- Change Management

- License Management


4.7 Release Management

Strict procedures for Release Management can and should ensure consistent

environments.

Several unwanted situations:

- Undocumented changes

- Mistakes

- Inconsequent procedures

- Trial and Error

Separating the responsibility of packaging from installation has several advantages:

- Documentum Functional Support is responsible for Change Management and

coordinating Release Management

- Documentum Application Support is responsible for packaging and applying

quality control before any package is released for deployment

- Documentum Technical Support is responsible to deploy the packages and

ensure a proper Release History is maintained including Release Reports for

every deployment to every environment

5. Final Remarks The solutions discussed in this article are my current best practices and will likely be

improved and further refined in the future. They are inspired by a broader vision to

create easier and better ways of doing things in the new and mostly unexplored field of

Document Management.

I am convinced we are just touching the surface of what is possible with Document

Management and how to properly implement it as an Enterprise platform.


I encourage everyone inspired by this article to consider using more generic ways of

implementing Documentum, to share ideas and to let me know where my Best Practices

might contain flaws. All remarks will help to improve existing best practices and bring us

closer to a truly Enterprise wide Document Management platform.

Biography

I have been working daily with the Documentum suite since 2001. I have been involved

in, and responsible for, many implementations for customers in the Banking and

Insurance sectors.

I have made an effort to understand the technical backend of many Documentum

functions (to solve problems and reverse engineer and decompile code). With this, I

developed a thorough understanding of the inner workings of the product. I have also

been involved in more architectural responsibilities.

During my career, I started building many Point Solutions trying to discover more generic

ways of working. Two years ago, I had an opportunity to help implement Documentum

on an Enterprise wide scale in a platform architecture. This project gave me an

opportunity to start dealing with the challenges associated with designing a Document

Management Platform. Mistakes were made, lessons were learned.

I hold an EMC Content Management Foundations Associate level certification.


Appendix 1 – Terms and Abbreviations OOTB Out of the Box, an application component

that is provided at basic installation and

without customization.

DFS Documentum Foundation Services

DMS Document Management System

DFC Documentum Foundation Classes

WDK Documentum Web Development Kit

XML Application Technology inside Documentum

Repository, with which documents can be

stored by storing a XML containing meta

data and a file location

CPU Central Processing Unit, aka Processor

Core component in any Computer / Server


Appendix 2 – Available Actions Ingestion Service • Object Functions

o updatemetadata o copy o move o checkcreatefsp o updatedocument o createdocument o cancelcheckout o destroy

• Workflow Functions o startworkflow o completeworkitem o abortanddestroyworkflow

• Lifecycle Functions o setlifecycle o promote o demote o suspend o resume o cancelscheduledpromote

• Retention Functions o setretention o removeallretentions

• Lock Functions o requestlock o releaselock

• Context Functions o getpropertiesfromobject o getpropertiesfromquery o getpropertiesfromline

• Loop Functions o loopqueryresults

• Special Functions o noaction o runactionsequence o sendemail

• Debug Functions o pause o testfailedaction o exceptionaction


Appendix 3 - DCTMCTRL Documentum Control application