Good Application Design Applying the Designed for Documentum Specification

Transcription

1 1 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 Introductions Eric Merhoff Naveen Jain Aamir Farooq Naveed Agboatwalla Rajesh Kasanagottu 2 Session Objectives Communicate how the Designed for Documentum Specification can be applied by partners and customers to ensure good application design Drive understanding of what the Designed for Documentum logo stands for 3

2 4 Agenda What is the Designed for Documentum specification? How does the Designed for Documentum specification apply to you? The Application Portfolio What is the future for the specification? A little context for the specification? Designed for Documentum (DfD) is a logo that partner offerings can earn The DfD Specification describes, in detail, the technical, documentation and support requirements for applications to earn the DFD logo Product of the Application Logo Program The goal is to drive a fast growing ecosystem of offerings Partner Offering DCTM Core Ecosystem 5 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 needs Drive partner alignment with new and emerging Documentum technologies and initiatives 6

3 7 How it s used Partners Planning Design Quality Assurance Logo Program Evaluate compliance Partner guidance Customer Reference for evaluation offerings Bar for 3 rd party custom solutions Guidance for internal development 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 8 Agenda What is the Designed for Documentum specification? How does the Designed for Documentum specification apply to you? The Application Portfolio What is the future for the specification? 9

4 10 Documentum Product Stack CRM ERP Portals Records Mgmt. Collaboration Compliance DAM WCM EDM Documentum Interfaces, Components, and Tools Content Services Server Extensions Content Server Content Repository Custom Majority of the applications use our Content Repository and Content Services Design / Architectural issues at application foundation layer are more expensive to fix 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? Met various Documentum Engineering experts from most of the product areas Worked with Documentum Consulting and Product Managers Incorporated input from our partners 12

5 13 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? How each criterion is described? Description Significance Example Exceptions Test Cases 14 How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization 15

6 16 Stability Criteria Objectives & Criteria Objective The product should remain stable while performing primary functions and should not lose data during execution Representative Criteria Performs all primary functions while remaining stable Does not cause loss of data during execution Does not overload attributes Does not override attributes Documents known exceptions and unsupported Documentum functionality Overloading of attributes org_app_doc Org_app_status is defined at org_app_doc level and inherited by sub-types. org_app_subdoc1 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_document dm_sysobject dm_folder r_version_label attribute is defined at dm_sys_object level and is not used at dm_folder level. 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

7 19 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 How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization 20 Installation, Migration Objectives & Criteria Objective The product should be easy to install, uninstall and migrate from one version to another Representative Criteria Installation process pre-checks the validity of the Installation environment Completely defines the install order with respect to requisite products Provides complete and clean uninstall Does not cause loss of data during installation, upgrade and removal Provides complete list of compatible products 21

8 22 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 Expert Opinion Very few offerings do clean un-install For some offerings migration requires reconfiguration Case Study For most offerings installer does not identifies all files installed on the machine How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization 23 Interoperability Objectives & Criteria Objective The product should work in harmony with Documentum products and also other Designed for Documentum partner offerings Representative Criteria Handles errors related to incompatible server version Completely defines the products it is compatible with Uses appropriate naming conventions Documentum objects definition like object type, methods, jobs, workflow, etc Controlling application Only uses its own configuration file for configuration 24

9 25 Use Appropriate Naming convention Never name an object-type, attribute, tables, columns with names that conflict with Reserve words Never 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 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. r_object_id object_name Logo.gif Logo.gif Logo.gif a_controlling_app Org_wp Org_dam NULLS 26 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 convention 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

10 28 How criteria are categorized? Stability Installation / Migration Interoperability Componentization Maintainability Documentation Security Scalability Process Internationalization Componentization Objectives & Criteria 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. Representative Criteria Uses WDK Theme Styles Guidelines for building components and controls Supports WDK Internationalization & Localization capabilities 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

11 31 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 Componentization Trends Few offerings are ready for Internationalization/Localization Most of them have context sensitive help Few are 508 Compliant 32 How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 33

12 34 Support & Maintainability Objectives & Criteria Objective The product should be easy to maintain with good customer support leading to lower cost of ownership Representative Criteria Defines Offering lifecycle Defines how customer support is available, obtained and performed Error logs and reports contain complete information Support & Maintainability Trends Usually product lifecycle is not defined and made available to customers 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 Few have well defined training program 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

13 37 Documentation Objectives & Criteria Objective Good quality and complete product documentation should be available for administrators and endusers Representative Criteria Provides appropriate offering-level documentation Provides online help Documentation Trends Products from technology partners usually have good quality documentation 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

14 40 Security Objectives & Criteria Objective The product should be able to leverage strong Documentum security model and maintain industry accepted security practice Representative Criteria Does not compromise Documentum security model Maintains accepted security practice Integration with LDAP Security Trends Most of the offerings leverage Documentum Security Model 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

15 43 Scalability Objectives & Criteria Objective The product should be scalable and perform acceptably in real-life implementation Representative Criteria Offering is test for performance in real-life implementations Implements proper session management Expert Opinion Scalability Trends 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

16 46 Development Process Objectives & Criteria Objective Product should be developed using well defined process that spans across all stages of the product lifecycle Representative Criteria 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. 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 47 How criteria are categorized? Stability Installation / Migration Interoperability Componentization Support & Maintainability Documentation Security Scalability Process Internationalization 48

17 49 Internationalization Objectives & Criteria 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 Representative Criteria Uses Unicode standard for all character encoding Supports creation of Language packs Able to read and write data from any language Internationalization Data Dictionary and Unicode Data Dictionary Unicode Expert Opinion 50 Agenda What is the Designed for Documentum specification? How does the Designed for Documentum specification apply to you? The Application Portfolio What is the future for the specification? 51

18 52 Application Portfolio Customers discover your offerings quickly! Organized by class of offering 53 54

19 55 Agenda What is the Designed for Documentum specification? How does the Designed for Documentum specification apply to you? The Application Portfolio What is the future for the specification? 56 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 57

20 58 Expanding Designed for Documentum 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 Entire Documentum Product Stack including DCM Records Manager Information Lifecycle (ILM) Enterprise Content Integration (ECI) Etc. Legato Application- Xtender product Further complete and refine each category of criteria Program Future Develop specification into Architectural Gold Standard Make the Designed for Documentum specification available to developers Make Application Portfolio single place for all quality partner offerings 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 The contributor waives any rights to their input. Application Portfolio You can access application portfolio on documentum.com web site. 60

21 61