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