ESciDoc Solutions Going Productive

MPDL

This page should contain a checklist of all tasks needed to make an eSciDoc solution productive.

Functional Readiness
Functional readiness lists all general functionalities (not solution specific) which should be implemented before going productive:
 * User administration for the MPDL and for the responsible persons (power user) from the institutes (e.g. via Identity provider/Single-Sign-On)
 * General management functions for the solution (e.g. batch-operations, root account) and corresponding roles have to be available
 * Data interoperability through RSS-feed, OAI-PMH
 * Ability to find the data via Google and Google Scholar
 * Integration of a PID for items and containers
 * Main scope of the productive release and all predecessors
 * Statistics service (based on the requirements of the solution)
 * Clear functional documentation publicly available (CoLab)
 * Successfully passed (automated) integrity tests

GUI Readiness
GUI readiness lists all general GUI aspects (not solution specific) which should be implemented bevore going productive:
 * Look and feel of the solution (based on the general application layout)

Technical Readiness
Technical readiness lists all general technical aspects (not solution specific) which should be implemented bevore going productive: --> A stable running system is needed!
 * Specification of a back-up concept
 * Specification of release procedure concept for the live server (see ESciDoc Solutions Servers) incl. definition of initial data sets for all servers except the live one
 * Specification of a bug fix release concept for the live server (how often shall bug fixes be released, what triggers a bug fix release)
 * Specification of a framework release and migration concept for the live server
 * Reassurance of cross-browser usability (see also http://googlewebmastercentral.blogspot.com/2008/09/workin-it-on-all-browsers.html)
 * Successful automatic tests
 * Specification of a server maintenance concept (e.g. responsible persons, acceptable server time-out)
 * Permanent service monitoring for checking performance/scalability
 * Regular log file analysis as quality assurance
 * Implementation of log file anonymization
 * Clear technical documentation of the code public available

Capacity Planning

 * Definition of performance and scalability goals (e.g. no request should take longer than 2 secs, 50 concurrent user should be possible)
 * Estimation of the system resource demands and ceilings, e.g. required growth of disc space per year and available disc space at present.
 * Permanent service monitoring for checking performance/scalability

Links:


 * http://www.slideshare.net/jallspaw/velocity2008-capacity-management1-484676
 * http://www.amazon.com/Art-Capacity-Planning-Scaling-Resources/dp/0596518579 (available in robert's office)

Security

 * The login page should be served via HTTPS to prevent passwords from being sent in cleartext over the wire.
 * Test data (in particular test user accounts) must be removed from the system.

Organizational Readiness
Organizational readiness lists all general organizational aspects which should be clarified bevore going productive:
 * Definition of the responsibilities at the MPDL and the institutes
 * Definition of contact persons at the institute /at the MPDL
 * Definition of involved persons (on institutes and MPDL side) and their responsibilities
 * Clarification, if enough personnel is available (at the MPDL)

Communication / Support
Communication / support lists all aspects concerning the communication about the productive solution and its support, which should be clarified bevore going productive:
 * Specification of a communication concept, which includes the communication within the MPG and extern
 * e.g. the Communication Concept for PubMan
 * Establishing of a support team
 * Clarification of availability and responds times of the team
 * Specification of training plans (how, how many, which period, different target groups)
 * For online training: identification of useful tools
 * Documentation of help text(s), e.g. FQA, screencast, context sensitive help
 * Setup and integration of a blog
 * Evtl. establishing of one or several mailing list(s) for different purposes and target groups
 * Introduction of the solution to a large community by visiting (international) conferences
 * Production of promotion material
 * Evtl. creation of incentives for using the system

Policies
Policies lists all aspects which should be covered by one or several policies bevore going productive:
 * Data privacy policy
 * License policy for the content
 * Persistence policy of data and URL space
 * Terms of use (usage policy)
 * Document format policy (includes all regulations relevant for the used formats)
 * Editorial policy
 * LTA policy
 * Clarification about who signs of the policies (e.g. mpdl, mpg, fiz)
 * imprint

Service Level Agreements
Service level agreements lists all aspects which should be covered by one or several service level agreements before going productive:
 * Definition of what kind of service we will offer (incl. how often bug fix releases will be offered, what our maximum server time out is, how long we need to restore data in case of a server break down)
 * Definition of the availability of our support team and the training we can offer
 * Definition, if and in which scale we will provide consulting for individual institutes
 * Clear distinction between core solution services (are available at no charge to community members and customers) and premium services (specialized services designed to meet extra ordinary needs of community members), which has to be defined as a MPDL project

Additional Material

 * Table overview with prioritization and responsibilities

Related Pages

 * Faces Going Productive
 * PubMan Going Productive

Reading

 * reading on repository management
 * further ideas on repository policies
 * further ideas on readiness, sent by Robert