applying the dfd specification - dell emc · pdf fileapplying the designed for documentum...

11

Good Application DesignApplying the Designed for Documentum Specification

October 2004

Eric Merhoff - Senior Staff Engineer, Documentum Architecture GroupNaveen Jain – Staff Application Architect, Designed for Documentum

Documentum Developer Conference 2004San Ramon, CA

22

Introductions

Eric MerhoffNaveen JainAamir FarooqNaveed AgboatwallaRajesh Kasanagottu

33

Session Objectives

Communicate how the Designed for Documentum Specification can be applied by partners and customers to ensure good application designDrive understanding of what the Designed for Documentum logo stands for

44

Agenda

What is the Designed for Documentum specification?How does the Designed for Documentumspecification apply to you?The Application PortfolioWhat is the future for the specification?

55

A little context for the specification?

Designed for Documentum (DfD) is a logo that partner offerings can earn

PartnerOffering

Ecosystem

DCTMCore

The goal is to drive a fast growing ecosystem of offerings

Product of the Application Logo Program

The DfD Specification describes, in detail, the technical, documentation and support requirements for applications to earn the DFD logo

66

Objectives for the DfD Specification

Set one standard that all customers and partners can follow– Provide guidelines and best practices for meeting

the requirements– Establish baseline for all offerings

Classify offerings as “Application”, “Solution”, or “Integration”Differentiate offerings that address specific needsDrive partner alignment with new and emerging Documentum technologies and initiatives

77

How it’s usedPartners

– Planning– Design– Quality Assurance

Logo Program– Evaluate compliance– Partner guidance

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

88

Approach

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

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

99

Agenda


1010

Documentum Product Stack

Documentum Interfaces, Components, and Tools

Server Extensions

Content Server

Content Repository

Content Services

EDM

WCM

DAM

Compliance

Collaboration

Records Mgmt.

Portals

ERP

CRM

Custom

Majority of the applications use our Content Repository and Content ServicesDesign / Architectural issues at application foundation layer are more expensive to fix

1111

Documentum Product Covered by Specification


Server Extensions

Content Server

Content Repository

Content Services

EDM

WCM

DAM

Compliance

Collaboration

Records Mgmt.

Portals

ERP

CRM

Custom

1212

How the specification were developed ?

Met various Documentum Engineering experts from most of the product areasWorked with Documentum Consulting and Product ManagersIncorporated input from our partners

1313

Uncovering Complex applications?

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?

1414

How each criterion is described?

DescriptionSignificanceExampleExceptionsTest Cases

1515

How criteria are categorized?

StabilityInstallation / MigrationInteroperabilityComponentizationMaintainabilityDocumentationSecurityScalabilityProcessInternationalization

1616

Stability Criteria – Objectives & Criteria

ObjectiveThe product should remain stable while performing

primary functions and should not lose data during execution

Representative Criteria1.1.1 Performs all primary functions while remaining

stable1.1.2 Does not cause loss of data during execution1.3.4 Does not overload attributes1.3.5 Does not override attributes1.1.15 Documents known exceptions and

unsupported Documentum functionality

1717

Overloading of attributes

org_app_doc

org_app_subdoc1 org_app_subdoc2

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

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

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

1818

Overriding of attributes

DescriptionDo 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

dm_sysobject

dm_document dm_folder

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

1919

Stability Criteria – Trends

More partner offerings need to use transactions to avoid losing data during execution

– beginTrans()– abortTrans()– commitTrans()

Most of the offerings do not document known exceptions and unsupported Documentum functionality

Case Study

2020



2121

Installation, Migration – Objectives & Criteria

ObjectiveThe product should be easy to install, uninstall and

migrate from one version to another

Representative Criteria1.2.3 Installation process pre-checks the validity of the

Installation environment1.2.2 Completely defines the install order with respect

to requisite products1.2.9 Provides complete and clean uninstall1.2.1 Does not cause loss of data during installation,

upgrade and removal1.2.5 Provides complete list of compatible products

2222

Installation, Migration – Trends

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

Very few offerings do clean un-installFor some offerings migration requires re-configurationFor most offerings installer does not identifies all files installed on the machine

Case Study

Expert Opinion

2323



2424

Interoperability – Objectives & Criteria

ObjectiveThe product should work in harmony with Documentum

products and also other Designed for Documentum partner offerings

Representative Criteria1.1.14 Handles errors related to incompatible server

version1.2.2 Completely defines the products it is compatible with1.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

2525

Use Appropriate Naming convention

Never name an object-type, attribute, tables, columns with names that conflict with Reserve wordsNever name custom object-types, controlling app, etc according to standard prefixes like dm_ or dmi_ or i_, etc. Use a prefix of according to domain name and the product/project name

e.g. wells_wp_doc

2626

Use Controlling App attribute

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.

NULLSLogo.gif09…

Org_damLogo.gif09…

Org_wpLogo.gif09…

a_controlling_appobject_namer_object_id

2727

Interoperability – Trends & Future

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

conventionFuture

– 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

Expert Opinion

2828



2929

Componentization – Objectives & Criteria

ObjectiveThe 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.

Representative Criteria2.1.3 Uses WDK Theme Styles2.1.4 Guidelines for building components and controls2.1.6 Supports WDK Internationalization &

Localization capabilities2.1.7 Provides context sensitive online help

3030

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 container3. Create new container for components only when

existing containers cannot be used4. 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

3131

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

3232

Componentization – Trends

Few offerings are ready for Internationalization/LocalizationMost of them have context sensitive helpFew are 508 Compliant

3333


StabilityInstallation / MigrationInteroperabilityComponentizationSupport & MaintainabilityDocumentationSecurityScalabilityProcessInternationalization

3434

Support & Maintainability – Objectives & Criteria

ObjectiveThe product should be easy to maintain with good

customer support leading to lower cost of ownership

Representative Criteria1.6.1 Defines Offering lifecycle1.6.2 Defines how customer support is available,

obtained and performed1.1.11 Error logs and reports contain complete

information

3535

Support & Maintainability– Trends

Usually product lifecycle is not defined and made available to customersFor 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 infrastructureFew have well defined training programVery few have technical knowledgebase that is available to customers Case Study

Expert Opinion

3636



3737

Documentation – Objectives & Criteria

ObjectiveGood quality and complete product documentation

should be available for administrators and end-users

Representative Criteria3.1.6 Provides appropriate offering-level

documentation2.1.7 Provides online help

3838

Documentation– Trends

Products from technology partners usually have good quality documentationMost of the time Administrator documentation is complete whereas User documentation needs more work

3939



4040

Security – Objectives & Criteria

ObjectiveThe product should be able to leverage strong

Documentum security model and maintain industry accepted security practice

Representative Criteria1.5.2 Does not compromise Documentum security

model1.5.1 Maintains accepted security practice1.5.3 Integration with LDAP

4141

Security – Trends

Most of the offerings leverage Documentum Security ModelMost of the offerings maintain accepted security practice

Case Study

Expert Opinion

4242



4343

Scalability – Objectives & Criteria

ObjectiveThe product should be scalable and perform

acceptably in real-life implementation

Representative Criteria1.3.11 Offering is test for performance in real-life

implementations1.3.9 Implements proper session management

Expert Opinion

4444

Scalability – Trends

Most of the offerings do not have well defined performance test plan

Case Study

4545



4646

Development Process – Objectives & Criteria

ObjectiveProduct should be developed using well defined

process that spans across all stages of the product lifecycle

Representative Criteria2.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.

4747

Development Process - Trends

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

4848



4949

Internationalization – Objectives & Criteria

ObjectiveThe 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

Representative Criteria1.1.1 Uses Unicode standard for all character

encoding1.1.5 Supports creation of Language packs1.1.2 Able to read and write data from any language

5050

Internationalization – Data Dictionary and Unicode

Data DictionaryUnicode

Expert Opinion

5151

Agenda


5252

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

5353

Organized by class of offering…Organized by class of offering…

5454

5555

5656

Agenda


5757

What are we hearing about the program?

Documentum Consulting– “We will like to use the specifications to train our consultants

on building better solutions”

Design Partners– “It would be difficult if not impossible to develop our product

without Designed for Documentum”

Accreditation Partner– “Designed for Documentum program is more thorough than

any other program we have seen in the industry”

5858

Expanding Designed for Documentum Specification


Server Extensions

Content Server

Content Repository

Content Services

EDM

WCM

DAM

Compliance

Collaboration

Records Mgmt.

Portals

ERP

CRM

Custom

Entire Documentum Product Stack including

– DCM– Records Manager– Information

Lifecycle (ILM)– Enterprise Content

Integration (ECI)– Etc.

Legato Application-Xtender productFurther complete and refine each category of criteria

5959

Program Future

Develop specification into Architectural Gold StandardMake the Designed for Documentum specification available to developersMake Application Portfolio single place for all quality partner offeringsAdd 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

6060

Insist on Designed for Documentum!

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

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