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
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?
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
Documentum Interfaces, Components, and Tools
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationMaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationMaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationMaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
How criteria are categorized?
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationSupport & MaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationSupport & MaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationSupport & MaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationSupport & MaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
How criteria are categorized?
StabilityInstallation / MigrationInteroperabilityComponentizationSupport & MaintainabilityDocumentationSecurityScalabilityProcessInternationalization
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
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?
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
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?
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
Documentum Interfaces, Components, and Tools
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
6161