Good Application Design Applying the Designed for Documentum Specification Eric Merhoff - Senior Staff Engineer, Documentum Architecture Group Naveen Jain – Staff Application Architect, Designed for Documentum

Documentum Developer Conference 2004 San Ramon, CA

October 2004

1

Introductions z Eric Merhoff z Naveen Jain z Aamir Farooq z Naveed Agboatwalla z Rajesh Kasanagottu

2

Session Objectives z Communicate how the Designed for

Documentum Specification can be applied by partners and customers to ensure good application design z Drive understanding of what the Designed for

Documentum logo stands for

3

Agenda z What is the Designed for Documentum

specification? z How does the Designed for Documentum

specification apply to you? z The Application Portfolio z What is the future for the specification?

4

A little context for the specification? z Designed for Documentum (DfD) is a logo that partner

offerings can earn z The DfD Specification describes, in detail, the technical, documentation

and support requirements for applications to earn the DFD logo z Product of the Application Logo Program

z The goal is to drive a fast growing ecosystem of

Partner Offering

offerings DCTM Core

Ecosystem

5

Objectives for the DfD Specification z Set one standard that all customers and

partners can follow – Provide guidelines and best practices for meeting the requirements – Establish baseline for all offerings z Classify offerings as “Application”, “Solution”, or

“Integration” z Differentiate offerings that address specific

needs z Drive partner alignment with new and emerging

Documentum technologies and initiatives

6

How it’s used z Partners

– Planning – Design – Quality Assurance z Logo Program

– Evaluate compliance – Partner guidance z Customer

– Reference for evaluation offerings – Bar for 3rd party custom solutions – Guidance for internal development

7

Approach z Organization

– Categories of criteria – Basic and classification specific criteria that are required – Specialty designation criteria z Lifecycle

– Evolving and maturing – Collaborative with customers and partners and other groups within Documentum/EMC – Influenced by experience and input gained through customer and partner facing activities – Changes will go through open review – Reasonable expectations (i.e. timeframe) for adjusting to changes

8

Agenda z What is the Designed for Documentum

specification? z How does the Designed for Documentum

specification apply to you? z The Application Portfolio z What is the future for the specification?

9

Documentum Product Stack z Majority of the

Server Extensions Content Server Content Repository

Custom

Content Services

CRM

ERP

Portals

Records Mgmt.

Collaboration

Compliance

DAM

WCM

EDM

Documentum Interfaces, Components, and Tools

applications use our Content Repository and Content Services z Design /

Architectural issues at application foundation layer are more expensive to fix

10

Documentum Product Covered by Specification

Custom

CRM

ERP

Portals

Records Mgmt.

Collaboration

Compliance

DAM

WCM

EDM

Documentum Interfaces, Components, and Tools Content Services

Server Extensions Content Server

Content Repository

11

How the specification were developed ? z Met various Documentum Engineering experts from

most of the product areas z Worked with Documentum Consulting and Product

Managers z Incorporated input from our partners

12

Uncovering Complex applications? z Is the application – handling large number of documents? – using virtual documents extensively? – having users spread over geography? – processing large number of workflows? – integrated with other applications? – to be used in validated environment?

13

How each criterion is described? z Description z Significance z Example z Exceptions z Test Cases

14

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization 15

Stability Criteria – Objectives & Criteria z Objective The product should remain stable while performing primary functions and should not lose data during execution z Representative Criteria 1.1.1 Performs all primary functions while remaining stable 1.1.2 Does not cause loss of data during execution 1.3.4 Does not overload attributes 1.3.5 Does not override attributes 1.1.15 Documents known exceptions and unsupported Documentum functionality 16

Overloading of attributes org_app_doc org_app_subdoc1

Org_app_status is defined at org_app_doc level and inherited by sub-types.

org_app_subdoc2

Description Custom attribute org_app_status should not be used with different business meanings at the subordinate level or at the same level

Significance Will likely require costly and lengthy reengineering and testing, first to identify the bug and then fix it

17

Overriding of attributes dm_sysobject dm_document

r_version_label attribute is defined at dm_sys_object level and is not used at dm_folder level.

dm_folder

Description Do not reuse such attributes. Better sub-type dm_folder object

Significance - Can create problems with future versions of the product - Problems would require interruption in service, delay in ability to

upgrade - Likely require costly and lengthy reengineering and testing

18

Stability Criteria – Trends z More partner offerings need to use transactions

to avoid losing data during execution – beginTrans() – abortTrans() – commitTrans() z Most of the offerings do not document known

exceptions and unsupported Documentum functionality Case Study

19

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization 20

Installation, Migration – Objectives & Criteria

z Objective The product should be easy to install, uninstall and migrate from one version to another z Representative Criteria 1.2.3 Installation process pre-checks the validity of the Installation environment 1.2.2 Completely defines the install order with respect to requisite products 1.2.9 Provides complete and clean uninstall 1.2.1 Does not cause loss of data during installation, upgrade and removal 1.2.5 Provides complete list of compatible products 21

Installation, Migration – Trends

z More offerings need to – validates installation environment before installing the product – Define order in which pre-requisite software should be installed – Define complete list of compatible products along with version numbers z Very few offerings do clean un-install

Expert Opinion

z For some offerings migration requires re-

Case Study configuration z For most offerings installer does not identifies all files installed on the machine 22

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization 23

Interoperability – Objectives & Criteria z Objective

The product should work in harmony with Documentum products and also other Designed for Documentum partner offerings z Representative Criteria

1.1.14 Handles errors related to incompatible server version 1.2.2 Completely defines the products it is compatible with 1.3.2 Uses appropriate naming conventions • Documentum objects definition like object type, methods, jobs, workflow, etc • Controlling application

1.3.8 Only uses its own configuration file for configuration 24

Use Appropriate Naming convention z Never name an object-type, attribute, tables,

columns with names that conflict with Reserve words z Never name custom object-types, controlling

app, etc according to standard prefixes like dm_ or dmi_ or i_, etc. z Use a prefix of according to domain name and

the product/project name e.g. wells_wp_doc 25

Use Controlling App attribute z In dm_sysobject there is an attribute a_controlling _app that

identifies the application or applications that can modify the object. If NULL, then any application can modify the object.

r_object_id

object_name

a_controlling_app

09…

Logo.gif

Org_wp

09…

Logo.gif

Org_dam

09…

Logo.gif

NULLS

26

Interoperability – Trends & Future z Trends & Challenges

– More offerings need to check for incompatible server version during execution – Lot of the offerings are not using “a_controlling_app” attribute – Most offerings are not using any standard naming convention z Future Expert Opinion – Offering does not limit itself to specific RDBMS – Offering should avoid using update queries because they bypass BOF – Offerings should supports replicated content model – Offerings should supports Federated Repository Case Study

27

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization 28

Componentization – Objectives & Criteria z Objective The source code of the products should use best practices of componentization to enhance code reuse, extensibility of components and consistency in terms of error handling, Internationalization, Branding, 508 Compliance, etc. z Representative Criteria 2.1.3 Uses WDK Theme Styles 2.1.4 Guidelines for building components and controls 2.1.6 Supports WDK Internationalization & Localization capabilities 2.1.7 Provides context sensitive online help 29

Top Ten Guidelines for building components and controls 1. Make sure components follow naming and location

guidelines as per WDK Application Development guide or new Component naming and location guidelines are documented and are made part of development process

2. Design Components to run in a container 3. Create new container for components only when

existing containers cannot be used

4. Make sure that components do not contain controls for

OK/Cancel/Help buttons. Controls for OK/Cancel/Help buttons should be provided by the container

5. Make sure that components definition includes help

context id

30

Top Ten Guidelines for building components and controls 6.

Follow naming and location guidelines for component’s behavior class or develop and document new component behavior class naming and location guidelines and are make them part of the development process

7.

Use WDK Accessibility services for Section 508 compliance as defined in WDK Application Development guide

8.

Use component scope and filters instead of hard coding the context sensitive behavior of the component

9.

Make sure that component can be launched stand-alone in a browser and also from within the parent application in a browser

10. When launched with invalid parameters, the component

gracefully handles the exception

31

Componentization – Trends z Few offerings are ready for

Internationalization/Localization z Most of them have context sensitive help z Few are 508 Compliant

32

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 33

Support & Maintainability – Objectives & Criteria z Objective The product should be easy to maintain with good customer support leading to lower cost of ownership z Representative Criteria 1.6.1 Defines Offering lifecycle 1.6.2 Defines how customer support is available, obtained and performed 1.1.11 Error logs and reports contain complete information

34

Support & Maintainability– Trends z Usually product lifecycle is not defined and

made available to customers z For most of the out-of-box products have well

defined support infrastructure, however for partners who are changing from SI to product companies usually need help in setting up support infrastructure Expert Opinion

z Few have well defined training program

z Very few have technical knowledgebase that is

available to customers

Case Study

35

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 36

Documentation – Objectives & Criteria z Objective Good quality and complete product documentation should be available for administrators and endusers z Representative Criteria 3.1.6 Provides appropriate offering-level documentation 2.1.7 Provides online help

37

Documentation– Trends z Products from technology partners usually have

good quality documentation z Most of the time Administrator documentation is

complete whereas User documentation needs more work

38

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 39

Security – Objectives & Criteria z Objective The product should be able to leverage strong Documentum security model and maintain industry accepted security practice z Representative Criteria 1.5.2 Does not compromise Documentum security model 1.5.1 Maintains accepted security practice 1.5.3 Integration with LDAP

40

Security – Trends z Most of the offerings leverage Documentum

Security Model z Most of the offerings maintain accepted security

practice

Expert Opinion

Case Study

41

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 42

Scalability – Objectives & Criteria z Objective The product should be scalable and perform acceptably in real-life implementation z Representative Criteria 1.3.11 Offering is test for performance in real-life implementations 1.3.9 Implements proper session management

Expert Opinion

43

Scalability – Trends z Most of the offerings do not have well defined

performance test plan

Case Study

44

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 45

Development Process – Objectives & Criteria z Objective Product should be developed using well defined process that spans across all stages of the product lifecycle z Representative Criteria 2.1.4 Developed using standard Product Development Process (PDP) • Process is well defined • Process is documented for consumption by various groups • Process covers all stages of the product development lifecycle including conceptual, analysis, design through implementation and support • Evidences are available that the process is being followed. 46

Development Process - Trends z Most of the new products need well defined

process that covers all phases of product development lifecycle. However more established products have very well defined process

Case Study

47

How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 48

Internationalization – Objectives & Criteria z Objective The product should be able to stores and works with data from all languages and locale in one repository and also support Language Packs for localization z Representative Criteria 1.1.1 Uses Unicode standard for all character encoding 1.1.5 Supports creation of Language packs 1.1.2 Able to read and write data from any language

49

Internationalization – Data Dictionary and Unicode z Data Dictionary z Unicode

Expert Opinion

50

Agenda z What is the Designed for Documentum

specification? z How does the Designed for Documentum

specification apply to you? z The Application Portfolio z What is the future for the specification?

51

Application Portfolio Customers discover your offerings quickly! http://www.documentum.com/app_portfolio

52

Organized by class of offering…

53

54

55

Agenda z What is the Designed for Documentum

specification? z How does the Designed for Documentum

specification apply to you? z The Application Portfolio z What is the future for the specification?

56

What are we hearing about the program? z Documentum Consulting – “We will like to use the specifications to train our consultants on building better solutions” z Design Partners – “It would be difficult if not impossible to develop our product without Designed for Documentum” z Accreditation Partner – “Designed for Documentum program is more thorough than any other program we have seen in the industry”

57

Expanding Designed for Documentum Specification

z Entire Documentum

Documentum Interfaces, Components, and Tools Content Services

Server Extensions Content Server

Content Repository

Custom

CRM

ERP

Portals

Records Mgmt.

Collaboration

DAM

WCM

EDM

Compliance

Product Stack including – DCM – Records Manager – Information Lifecycle (ILM) – Enterprise Content Integration (ECI) – Etc. z Legato Application-

Xtender product z Further complete and

refine each category of criteria 58

Program Future z Develop specification into Architectural Gold Standard z Make the Designed for Documentum specification

available to developers z Make Application Portfolio single place for all quality

partner offerings z Add more information about partner offerings on the

Application Portfolio like – Region where they have been implemented/supported – Languages in which they have been tested/implemented. – Industry verticals where they have been implemented

59

Insist on Designed for Documentum!

Contributions You can contribute to the specification by submitting the criterion to [email protected]. The contributor waives any rights to their input.

Application Portfolio You can access application portfolio on documentum.com web site. http://www.documentum.com/app_portfolio

60

61