Multi-tenancy
Needed by whom and when
UC Berkeley is depending on the multi-tenancy capabilities of CollectionSpace. This is a major part of our campus justification for funding, and it is also being used by our deploying collections in grant proposals to funding agencies.
Overview
In the Wikipedia definition (quoted April 15, 2011):
"Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance."
Multi-tenancy UCB user stories for prioritization
Multi-tenancy: CSpace administrator can install and manage a multi-tenant environment where two or more tenants share system resources (hardware and server software) while keeping some resources virtually distinct (e.g., customizations, authorities, media).
Prioritization of user stories
As definitions and priorities are clarified, the user stories above should be moved into relative order below.
Must have for 1.x-MUSEUM (when they go live in system)
Placeholder for required functionality. As a general rule, functionality that you need and use now should go here or where you have existing data. However, this is up to the museum. We will have to balance requirements against resources and timelines.
Placeholder
MUSEUM could wait six to twelve months
What could wait? These will be re-prioritized at a later date.
Placeholder
MUSEUM would like to have this eventually
These are nice to have but not a near term requirement.
Placeholder