The following is a proposed outline for a project/product plan. It tries to take all aspects of creating and sustaining a product into consideration.
1.0 What is the Product?
Minerva Sulis is part of the "next-generation" computing environment for the MIT community. Currently, one of the major strong points of Athena is that anyone can publish to the web by dropping static content into an AFS locker. Our virtual web hosting project attempts to expand upon that feature to create a viable web hosting option for MIT DLCs. Minerva Sulis expects to build upon this virtual web hosting to create a any easy-to-user console that will allow departmental users to configure their virtual domain to include all the most popular website features, such as a blog, forums, wiki, etc. Along with a few standard templates, it should be very easy to address the most common needs for MIT websites in the community. This product offers more than is typically available from a DreamHost, GoDaddy, or event scripts. mit.edu, in that the components that users choose will have been MIT-ized, able to hook up to MIT infrastructure, use MIT authentication, etc.
2.0 Who is the Customer?
There is a strong need in MIT DLCs to create websites that have a certain amount of scriptable capability. Right now, departmental web presence must either static (AFS locker) or the department must invest in their own web server. Hosting their own server in Server Ops is quite expensive, while the alternative is to stick it under someone's desk and find somebody to administer it. A typical case can be documented in Chemical Engineering.
A larger customer may be found in the Sloan School. They are currently considering MS Sharepoint to perform the kinds of functions that we believe we can offer in a more "MIT way" through the Minerva Sulis console.
"scripts.mit.edu", a student supported and operated forum, offers an equivalent service, but does not offer its customers as much integration with the MIT infrastructure (kerberos logins, Roles authorizaiton, etc.).
3.0 How will it be Built?
ISDA will build this, using DS&PS backend resources as well as front end resources.
3.1 Overview
We intend to leverage as much existing open source software as possible, although we will license software that we consider to have high value to us. Our primarily role is to build the glue that holds it all together as an integrated product, and to integrate MIT infrastructure components into it.
We will build upon other layers of the Minerva project, including general purpose virtual servers, and general purpose virtual web hosting.
3.2 Components
- generalized virtual servers
- this is the base technology and represents a Sulis dependency.
- generalized web servers
- this builds on the our general virtual server technology, but provides a very fixed profile for a web server host so that we can efficiently manage hosts optimized for web use. This is a Sulis dependency.
- The Sulis console. In very brief terms, this is a web accessible configuration console for setting up and managing a Minerva Sulis hosted web application. It would integrate and install a number of other components.
- Open source components, customized as needed to integrate with MIT infratructure. These include:
- a general web content framework like Joomla
- a general purpose blog component (like Joomla, Mambo, geeklog, PostNuke, etc), with features like:
- comments
- rich text editing
- simple workflow
- strong separation between content and styling
- a forum component
- a FAQ page component
- a file library, for providing downloads
- a Wiki for documentation
- a few standardized templates, which could serve as the basis for customization
3.3 Resources
What is needed to build it?
3.3.1 People
The Platform Services team, already well experienced with Athena, will form the core of the backend development team.
We will also need front end developers for the console and components.
number of FTEs, contractors, specific people involved and their roles
3.3.2 Hardware
We will need a development system running our virtual server technology.
We will need a test server to hammer it.
We will need a cluster
of servers for runtime.
3.3.3 Software
We plan to keep this development simple and low-tech. We expect to use PHP as the means for building the console and components.
Virtual server software.
3.4 Timeline
We want to ship something by Q1 FY09
4.0 How to Assure Quality?
a high level Test Plan
4.1 Overview
overview of testing approaches, e.g. "get a thousand monkeys and lock them in a room with the product", plus specific phases of testing (unit testing, integration, user acceptance, etc)
4.2 Resources
who is involved in testing it?
4.2.1 People
FTEs, contractors, specific people and their roles
4.2.2 Hardware
testing-specific hardware
4.2.3 Software
software tools, packages, etc for testing
4.3 Timelines
rough idea of various phases of testing (unit testing, integration, user acceptance, etc), espectially as they relate to the dev timeline
5.0 How do we Support It?
There will be multiple levels of support. Online we will need an FAQ, searchable knowledge base , and wizards for creating things.
We will need to provide experts to help with configuring websites and answering questions on a 9-5 mon-fri basis.
We need a bug tracking system, with closed bugs optionally becoming part of the knowledge base.
CSS will need to be able to handle first level requests and file them against our internal bug tracking.
5.1 Documentation plan
documentation for the end user? help files? developers? support staff? FAQ?
5.2 Customer support
(first, second, third tier, etc)
5.3 Issue Management
how will customer issues be managed? Request Tracker? RT feed to Jira? Triage process?
What about Forums for customer Q&A?
5.3 Customer Services
consulting services to help customers in customizing or doing whatever needs doing to use this product.
6.0 Operations Plan
What will is take to keep this product running, if applicable? (i.e. a centralized service of some kind)
6.1 SLA schedule
what are the SLAs? what do they cost? how do we support those SLA?
6.2 Resources
What operations resources are needed for the respective SLAs?
6.3 Run book
on a very coarse level, what are the major procedures that product operations care about?
7.0 Roadmap
what are the general plans to maintain it? upgrade it? release patches, new versions?
8.0 Outreach Plan
How do we market it to the MIT community? How do we make people aware of it, how do we offer incentives to use it?
9.0 Dependencies
highlight dependencies on other groups both internal/external, HW, SW, etc.
10.0 Risks
Risk/Mitigation strategy for each