Solution Development – Self Service Complete
Site Provisioning (Tier 5) Web Hosting
Explanation of Hosting Tiers
The Web Hosting High Level Requirements team identified 5 tiers of website hosting and described them in the
Hosting Levels and Options for Campus document. The Requirements team recommended focusing on Tiers 3, 4
and 5 and the Solutions team will be submitting a separate solution for each of the three tiers being considered.
The “Self-service Complete Site Provision” tier (Tier 5) will be the first solution created. This tier encompasses
the most use cases and has the greatest potential for cost savings. Please see the Web Hosting Services Work
Grid for a mapping of hosting tiers to use cases.
Solution Overview
Solution Description
Describe the general purpose, overall usage, or goal to accomplish with this solution.
Self-service is the key to success for Tier 5 hosting. A good solution must be simple and easy to use.
Tier 5 hosting covers the majority of use cases that have been identified. The goal of a Tier 5 hosting
solution is to provide a range of flexible, easy to use, cost effective, high quality website builder
platforms. These platforms should allow the customer to manage their account with the ability to
deploy a website quickly using high-quality templates. Campus solutions identified in Phase 1 below will
be kept and enhanced in the near term providing Tier 5 hosting to campus while an additional cloud
service is being implemented. The cloud-hosting provider will deliver reliable hosting and high quality
templates. These templates should be created and maintained by the vendor with the university having
the ability to add appropriate branding, contact, and copyright information. This approach should see
the vendor doing the hard work of creating and maintaining the templates while allowing campus to
foster consistency and adherence to campus branding, copyright and web accessibility standards. The
adoption of a suitable cloud-hosting provider should make this tier 5 solution a quick, high-impact, lowcost win.
We propose a two phase solution:
Phase 1 – Enhance, promote, create a consolidated entry point, and train for existing web builder
platforms on campus as needed. These services include:




Google Sites
The WordPress installation at https://publish.illinois.edu
The campus Web Toolbox at http://illinois.edu/toolbox
Confluence Wiki at https://wiki.cites.illinois.edu
1
Phase 2 – Secure a contract with a cloud hosted website builder platform such as
http://squarespace.com. The existing Campus Web Hosting Agreement Committee is in the process of
developing an RFP for this type of service. Members of the Campus Web Hosting Agreement Committee
overlap with the members of the IT Power Plant Web Solutions team. The implementation of the cloud
service ultimately chosen by the Web Hosting Agreement committee should be done through the IT
Power Plant Web Implementation team.
Target Group for Solution
Identify the customers, users, and stakeholders that will be impacted by this solution, and how they will
be impacted.
The Web Solutions team is using the following definitions in referring to customers, users and
stakeholders:



Customers are those who are building websites.
Users are website visitors.
Stakeholders are those who need to provide websites, need information from websites or
support web sites or web hosting platforms.
All groups stand to benefit from web builder platforms that allow websites to be created quickly with
high quality templates. Customers opting for a Tier 5 hosting solution would be those who need a basic
website, a site configured quickly, and/or those who have limited technical knowledge or resources. The
end users visiting the sites this tier will support are found both on and off campus. Stakeholders include
any campus individual or unit who would have to spend funds on design and deployment of a website if
this service didn't exist. Additional stakeholders are units who would no longer have to support web
infrastructure for basic websites if their currently hosted sites or future sites can be moved into these
site builder options.
Existing Solutions & Use Case Gap Analysis
Identify and describe existing related solutions and the unit that is responsible for those solutions.
Identify the gaps between existing solutions and the use cases identified that are related to this solution.
Document any new Use Cases discovered during this review.
Use Cases Not Covered by Any Existing Solution
Web teams in units charged with creating sites
for entire units
High Profile Site
Sandbox sites for app development
Homegrown LMS
Research site to provide access to data (large
datasets)
Student requests site for projects (where specific
technologies are required)
For large units, not appropriate for tier 5. For
smaller units, unmet need – existing tier 5
solutions lack sufficient features and polish
not appropriate for tier 5
not appropriate for tier 5
not appropriate for tier 5
Unmet need, stretch integration between
existing hosting options and UofI Box
Unmet need
2
Faculty requests websites for professional
organizations
Staff requests conference/event site
not appropriate for tier 5, except when
Illinois.edu hostname is acceptable
Unmet need
Existing Solution A - PIE
http://publish.illinois.edu (P.I.E.) is a blog and microsite publishing service based on the WordPress
open-source content management system. PIE consists of a multi-site installation of WordPress,
custom code for user account management and site provisioning, and a set of prebuilt site templates
that meet campus identify and state accessibility standards, and include University of Illinois branding
elements. P.I.E. partially fills the role of self-service complete site provisioning service. Customers can
request a site through a web form and it is automatically created. Customers can request a domain
through campus Host Manager, and map that domain name to their P.I.E site.
P.I.E is managed by Technology Services, with the help of IT Professionals from various campus units.
Use Cases
 Everyone gets a website
 Faculty CV
 Faculty Project
 Retain former faculty sites
 Research website needed to compete for grants
 Research group wants separate site for each research project
 Research lab wants promotional site
 Research group wants site
 Course website to allow students to publish content
 Course website to communicate to students
 Student requests site for projects
 Student group public website
 Retain former student sites
 Student portfolio
 Web cam use
 Livestreaming sites
Current Limitations






P.I.E offers a selection of fewer than 10 themes
Custom themes are not currently supported (insufficient staff resources)
Requests for additional themes are generally denied (insufficient staff resources)
A selection of commonly used plugins is available, however customers are not empowered to install
their own plugins
Disk space is limited to 500MB per website
Some use cases are difficult to achieve with limited templates, disk space, and plugins.
3
Scope of Current Usage
P.I.E. has been used to build 2370 websites, including examples of all of the use cases listed above.
Adoption of this platform could be increased with expanded templates, disk space, plugins, and support.
Existing Solution B – Google Sites
Google Sites is a website and wiki page-creation tool offered by Google as part of the Google Apps for
Work productivity suite (GoogleApps@Illinois). Google Sites is available to faculty, staff, and students
through campus licensing. Google Sites are created through a web-interface, do not require web
development or programming skills and can integrate components from hosted google apps such as
Docs, Sheets, Calendars, Slides, and Drive.
Use Cases
 Everyone gets a website
 Faculty CV
 Faculty Project
 Retain former faculty sites
 Research website needed to compete for grants
 Research group wants separate site for each research project
 Research lab wants promotional site
 Research group wants site
 Course website to allow students to publish content
 Course website to communicate to students
 Student requests site for projects
 Student group public website
 Retain former student sites
 Student portfolio
Current Limitations
 Available themes have not been vetted for accessibility and identity standards conformance
 Google Sites has limited built-in functionality. Reliance on Google Apps features is almost a
necessity
 Many themes are low-quality, dated and unprofessional
 Limited documentation and support
 Custom domains must be approved first by Technology Services security
 Attachments are limited to 20MB
Scope of Current Usage
Google Sites has only recently been made available to all campus personnel. Some sites were built
when students first gained access to it but it doesn’t appear to be widely used yet.
Existing Solution C - Illinois Wiki
Illinois Wiki is an installation of the commercial Wiki product Confluence from Atlassian. A wiki is a
particular form of editable website, generally consisting of content arranged in a page hierarchy, with
extensive features to enable browser-based collaborative page creation and editing.
4
The primary use case for requesting and using an Illinois Wiki Space is to enable group authoring and
editing of content. Content can be made available to the general public or to restricted audiences.
Possible restrictions include campus community members only, specific individuals or AD groups, and
official course rosters. Access can also be granted to off campus collaborators. Various levels of editing
and commenting privileges can also be extended to any of the previous groups or individuals which have
login privileges. The general public is not permitted anonymous edit access.
Use Cases
Knowledge base (public, campus, or restricted)
Course website to allow students to publish
content
Course website to collect assignments
(currently, but not ideal unless collaboration is
required for the composition of the
assignments)
Course website to communicate to students
(currently, but not ideal unless collaboration is
required)
Research group wants separate site for each
project
Research group wants site
transition to enterprise LMS
transition to more general web hosting
solution or P.I.E
ideal if collaboration is required,
otherwise P.I.E or Google Sites
ideal if collaboration is required,
otherwise P.I.E. or Google Sites
Current Limitations
 At present, Illinois Wiki space owners have limited options for templating and integration of custom
components (plugins) that would enable them to develop spaces that look and behave like “regular”
websites.
 A wiki is designed to be a collaborative tool and there is a significant performance penalty to that
feature set. Customers who want websites that are primarily meant for one-way communication to
visitors should select a different solution.
 By policy, search engines (Google, Bing, etc.) are blocked from indexing Illinois Wiki pages. This
decision was made due to concerns that space owners control access to their spaces and could
easily inadvertently expose private content.
Scope of Current Usage
Illinois Wiki is home to 3593 wiki spaces. These include examples of most of the above use cases.
Historically, however, the wiki has been used for many purposes that are not well-aligned with the wiki
concept, due to the absence of a more general web hosting solution on campus, and perceived or actual
deficits in campus online learning platforms.
Existing Solution D – Illinois Toolbox
Web Tools (a.k.a. Webmasters Toolbox) is a locally-developed suite of hosted components that can be
added to campus websites, to provide enhanced functionality without the need for custom
development or programming. Components include calendars, blogs, surveys, forms, campus maps, list
5
builders, file managers, and email management. These components were developed and are
maintained by the Web Services group within the Office of Public Affairs.
Use Cases
Staff requests conference/event site
Staff request unit website for variety of reasons
(depends on the reason)
Only specific components of a
conference site such as calendars and
forms.
Only specific components of sites
provided
Current Limitations
Web Tools does not offer features for creating full websites – it is a set of components that can be
integrated into, or used along with, a website that is developed elsewhere on campus. The toolbox also
lacks an API for better integration with other web technologies.
Scope of Current Usage
Web Tools was first made available over 10 years ago, and has been in continuous improvement since.
Thousands of instances of Web Tools components are live at this time on U of I websites.
Use Case Gap Analysis
The self-service Tier 5 solution isn’t meant to cover all use cases. Any use cases not covered by this
solution will be addressed in subsequent Tier 4 and Tier 3 hosting solution recommendations.
Non-Functional Requirements
Technical Requirements
Describe the technical requirement expectations such as capacity, scalability, availability, reliability,
performance, network, data management (data types, databases, data classification, etc), capacity,
reuse, recovery, system, hardware, portability, standards…
The following technical requirements are primarily aimed at the cloud hosting solution being
recommended. On campus hosting options can meet some of these technical requirements, but not all
of them.
Performance:
95% of the time, website response time should be at 2.0 seconds or under of a page source
delivery for the customer (account creation and login and editing functions) as measured from
an end-point outside of the University network, using a basic faculty workstation or one with
similar specifications, measured at any point in the working day between 9:00am and 5:00 pm.
6
The response times for the end-users will be highly dependent on what our customer creates.
However, as a principle, at this level of functionality the software should not let them create
anything with a rendering response time higher than 10 seconds and 90% of all page loads
should be under 5 seconds as measured from an end-point outside the University network,
using a basic faculty workstation or one with similar specifications, measured at any point in the
working day between 9:00am and 5:00 pm.

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no
special feedback is necessary except to display the result.

1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will
notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0
second, but the user does lose the feeling of operating directly on the data.

10 seconds is about the limit for keeping the user’s attention focused on the dialogue.

For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they
should be given feedback indicating when the computer expects to be done. Feedback during the delay is
especially important if the response time is likely to be highly variable, since users will then not know what to
expect.
Neilsen, Jakob. "Response Times: The 3 Important Limits." Evidence-Based User Experience Research, Training, and
Consulting. Nielsen Norman Group, 1 Jan. 1993. Web. 25 Nov. 2015.
Scalability:
Scalability is a primary requirement of this solution and could be considered one of its primary
functions. Scalability should be measured in terms of account creation/management, number of
sites created and managed, and number of end-users loading final site pages.
Account Creation: The solution has to be able to accommodate 0-46,000 customers and easily
authenticate and associate with University of Illinois user accounts.
Site Creation: Not everyone on campus will create a site, but some users will create multiple
sites. With those considerations, it is estimated that the solution as a whole must be able to
handle approximately 50,000 site creations.
System must be able to accommodate an average of 10,000 visitors per day to a site.
Site Management:
The nature of the use cases this solution addresses deems that site management is distributed
to the various site owners. No consolidated site management technique needs to be in place.
However, customer support needs to be available which means that some technical personnel
must be able to view the managing account, configuration, and files. Multiple people must be
able to manage a single site.
Capacity: approximately 44,000 students (Office of Inclusion and Intercultural Relations), 2,729
Faculty Members (Office of Public Affairs). 50,000 possible sites
Availability: Availability success metrics should be measured as an annual number. Tool
availability should maintain a 95% uptime or better, including planned downtime. This allows for
a total of 145 hours of annual time of unplanned failures as well as planned upgrades. Site
availability for end-users should be 99.9%. Due to clustering, caching and other technologies
available, no planned downtime should be required for end-user website availability. This
number allows for 2.91 hours annually for unplanned downtime.
7
Reliability:
Reliability measures are generally used to calculate the probability of failure for a single solution
component. For this requirement we will use the mean time between failures (MTBF); the
average time interval, expressed in hours that elapses before a component fails and requires
service. The equation is: (total elapsed time - sum of downtime)/number of failures. And the
requirement in this case should be at 90% or better. This allows for a total of 291 hours of loss
of some functionality annually, for all functions across possibly 50,000 sites.
Cohabitation/Migration:
System must provide customers with a way to export/copy their content for local backups and
for migration to another host or platform.
Recoverability/Backups:
 Vendor must provide backups/restores, and customer must be able to initiate restoration via
user interface (automatic process)
 Vendor must document backups/restoration practices and procedures
 Vendor must provide a service level specification on backup creation, retention, etc.
 System must provide a versioning/history system (at the item level) that will allow customermanaged rollback of site content to a previous version, with a minimum of one revision, but
preferably more.
Maintainability:
 System must provide a way to take an individual site offline temporarily, either by the content
owner or by university administrators or university IT Pros.
System Maintenance:
 All maintenance responsibilities (OS, Application, etc.) are the vendors.
 Security patches and bug fixes must be applied as soon as possible after being released (OS,
Application, etc.)
Security:
 Must provide the option for each site (at content owner’s initiation) to use SSL/HTTPS
 Login process/administrative interface must use SSL/HTTPS (strong-enough encryption in some
form)
 Vendor is responsible for remediating any problems caused by system exploits, hacks, etc.
 Campus security personnel must be able to access sites that have been compromised.
Usability:
 System must be usable by the majority of our customers without any mediation.
Interoperability:
 Must support the web browsers (application and versions) that account for 95% of visitors to
the vended solution sites
8



Must support current majority share web browsers (mobile support not required) for content
management
Must support current major OS, current version
Vendor must provide high quality responsive templates
Site statistics:
 System must provide content owners with access to site analytics data. Rraw logs do not meet
this requirement.
Legal Requirements
RFP, FERPA, HIPAA, Audit








Must meet IITAA Implementation Guidelines for Web-Based Information and Applications
requirements
Products chosen must support the development of accessible websites
Website creators must be notified in some manner that these sites are not appropriate for FERPA or
HIPAA data
Website creators must be notified in some manner that cloud servers might be located outside the
United States
All templates must strive to meet accessibility guidelines
All solutions must support SSL
Must follow the University’s policies on permanent cookies which complies with the State Agency
Web Site Act (Public Act 093-117). See http://www.vpaa.uillinois.edu/policies/cookies.cfm.
Must comply with the University Web Privacy Notice:
http://www.vpaa.uillinois.edu/policies/web_privacy.cfm
Accessibility Requirements
Reference to “Minimum Functional Accessibility Requirements for Software Candidates” (Attached)
An Accessibility Checklist and Accessibility Requirements help is available from Technology Services
(Keith Hays - [email protected] )



Products chosen must strive to meet the W3C Web Content Accessibility Guidelines (WCAG) 2.0,
Levels A and AA. The RFP must invite vendors to describe how their product meets federal and state
accessibility laws and guidelines. See the “Accessibility Requirements for Procured Software” and
IITAA Implementation Guidelines for Web-Based Information and Applications.
Products chosen must support the development of accessible websites
All university branded templates must meet accessibility guidelines
Usability Requirements
9
Because Tier 5 hosting is aimed at non-technical as well as technical customers, usability is crucial. The
usability factors important in a web hosting environment include (as determined by locally conducted
usability tests against candidate systems):
 Ease of learning: Customers must be able to figure out how to choose templates, add and enter
content and launch their sites with little to no help beyond provided documentation.
 Efficiency of use: Experienced customers should be able to accomplish tasks quickly
 Subjective satisfaction: Customers should be led through a clear progression of steps in the
process of creating and editing a site
These factors are from http://www.usability.gov/what-and-why/usability-evaluation.html and all must
be considered when choosing a product.
Security Requirements
FERPA, HIPAA, COPA, Social Security Numbers, Privacy
Security Requirements help is available from Technology Services (Chuck Geigner - [email protected] )






Data Classification: Because Tier 5 hosting is intended to be almost completely user maintained,
there should only be Public data on Tier 5 hosted sites. These sites are not appropriate for High
risk, Sensitive or Internal data.
Accounts/Credentials/Authentication/Remote Access: Access to the Tier 5 hosting solutions
must be through approved campus authentication mechanisms such as Shibboleth or Active
Directory.
Encryption, SSL, Ciphers, and Keys: The hosting options must adhere to current acceptable
encryption, hash algorithms and ciphers.
Vendor must properly secure any sensitive data (passwords, access tokens, etc.) [e.g. passwords
must not be stored in clear text or weakly encrypted)
Audit Logs: Access logs and web event logs must be available to campus IT Security personnel
investigating security events. These logs must cover a minimum period of one month.
Privacy: Any web technologies must follow the university’s Web Privacy policy at:
http://www.vpaa.uillinois.edu/policies/web_privacy.cfm.
Other Non-Functional Requirements
Administrative management, communication, quality




Designated campus IT Pros must have administrative access to all sites or be able to gain such access
if needed
Designated campus IT Pros must be able to deactivate accounts/sites if needed
Illinois CNAMES must be able to be pointed to sites. Note, some vendors are not approved by
campus security for CNAMEs
There must be vendor provided documentation intended for and accessible by content owners
10
Recommended Solution
The recommended solution could include modifications to an existing solution, a solution that is under
development, or a new solution not yet created. More than one proposed solution for a set of Use Cases is
acceptable, but should be documented in separate templates. “Cloud first” should be part of the consideration
of the solution review. An outsourced solution should be one of the solutions considered and documented.
Overview of Solution
Provide a brief solution narrative describing the recommended solution. What was compelling about
this recommended solution? What are the tradeoffs of choosing this solution over alternative solutions?
The recommended solution is designed to be implemented in a phased process with the phases
overlapping. Because Tier 5 hosting is expected to be the most cost effective option, offering a range of
hosting platforms and tools at this tier is desirable in order to maximize the number of customers
choosing Tier 5 hosting.
Phase One
First:
1. Build a web services information landing page to market existing campus web hosting solutions
2. Build an interactive flowchart to help customers choose the best hosting option for their
project. This guided self-assessment process should lead the customer through a series of
questions and, at the end of the process, steer the user to the appropriate solution(s) and the
next steps. If the site isn’t appropriate for Tier 5 hosting, the customer will be led to other
options. By building the documentation and self-service flowchart in phase one, these resources
will be ready to advertise new hosting options in phase two. In addition, because self-service is
the key to keeping Tier 5 hosting costs down, starting with easy to use information portals is
imperative.
3. Start building the consolidated support team.
Next:
Two of the self-service options that already exist on campus, Google Sites and Publish, need to be
enhanced and brought up to enterprise service standards.
Google Sites needs documentation, user guides and high quality, up-to-date templates and themes
along with dedicated support in order to serve the entire campus population better.
The campus WordPress installation at http://publish.illinois.edu needs:
 A well-defined process for developing and approving themes and plugins so more can be offered
 Additional default storage
 Opportunity for users to acquire more storage
 More high quality documentation
 New user websites need to be updated to have more intuitive default content and layout
matched to the most common use case. The default page that comes up after a customer
chooses a theme is confusing.
 Full time, dedicated IT Pro support
11
The campus Confluence wiki at http://wiki.cites.illinois.edu is already an enterprise level service with
documentation and widespread usage. The wiki service needs dedicated full time staff support to keep it
updated. In addition, strategies for increasing the scalability of the wiki service need to be addressed to
be ready for a possible increase in usage.
The campus Toolbox suite of web building tools at http://illinois.edu/toolbox is an enterprise level
service. The Toolbox suite of tools would benefit greatly from API development versus its current standalone interface presentation of its services. Toolbox developers need to be engaged in this discussion of
API development. Documentation about the tools should be added to the web documentation
developed in this phase.
Phase Two
Phase two, which can be carried out simultaneously with phase one, involves the procurement,
university systems integration and documentation of a commercial, cloud hosted web builder service.
The Campus Web Hosting Agreement committee is currently working on an RFP for such a service. The
vendor chosen should be able to provide high quality themes and templates on highly available and
scalable infrastructure. If there are fees, the procedure for paying any fees must be easy and integrated
into the self-service process of creating the website from the initial launch of the service.
High Level Diagram
Provide a high-level model or diagram of the recommended solution
12
13
Technology
Identify all hardware, infrastructure, or software technologies required for the solution. Describe the
probable platform or general architecture of the recommended solution.
Phase One:
Documentation and flowchart technology: No additional software or hardware is needed to create the
web services information landing page or the web services flowchart for customers. They can be created
with current Technology Services website software.
Google Sites: No additional hardware or infrastructure is needed for Google Sites. While usable in its
current state, software in the form of university branded, accessible templates and themes would most
likely increase its adoption.
WordPress Publish: Publish needs more disk space in order to accommodate increased default storage
quotas and sites with additional storage requirements. The acquisition of high quality proprietary
themes would be helpful as well as university branded themes.
Wiki: Proprietary plugins to extend the functionality of the wiki are needed. A list is being compiled by
the wiki administrator.
Toolbox: APIs developed for current toolbox services.
Phase Two:
Commercial Cloud Hosted Web Builder: Because this option is a cloud hosted service, there is no
hardware or infrastructure associated with it. Some or all of the following custom software will need to
be written:
 Components to add to commercially developed themes to make them university branded such
as headers, footers and Block I images.
 Integration with campus authentication methods
 Self-service account creation/activation forms
 The means to pay for the service through the self-service account activation if fees are assessed
 Billing software or billing integration with existing billing methods
 Site decommissioning software – this should be integrated with the billing software so users can
take down sites and stop the billing or sites can be turned off if payments stop
14
Scalability
Describe how the solution is scalable. Describe the attributes and characteristics that makes the solution
a scalable model and able to accommodate future growth.
Phase One:
Documentation and flowchart: The web services information landing page and flowchart can be scaled
up to accommodate any number of web services.
Google Sites: Google Sites is obviously scalable because it is Google.
Publish: Publish can be scaled if needed by adding additional servers, database servers, memory and
disk space. It could possibly be moved to cloud infrastructure in the future if we are able to maintain
the integration with campus tools that exists now. This move would allow the service to be easily
scalable because of the nature of cloud hosting.
Wiki: There are strategies built into the Atlassian Confluence software that allow for scalability including
clustering. In addition, it could be possible to move the wiki service to cloud infrastructure in the future.
Toolbox: The web toolbox is already highly scalable.
Phase Two:
Because the phase two commercial hosted solution would be in the cloud, it would be technologically
scalable by definition. However, the contract with the vendor would need to specify how fees are levied
for increasing usage.
Staffing
Implementation FTE
The following staff roles will be needed to ensure a smooth rollout of the new web hosting
services:
Dedicated web team
3 FTE Application Specialists – Dedicated application specialists, in addition to current staff
associated with the existing services, will be responsible for the actual hosting options both on
and off campus. They will interact as service experts with the documentation group, project
manager, marketing staff, vendors and additional IT Pros on campus.
Roles that are needed for successful launch of the web hosting services, but would not continue
to be permanent members of the dedicated web team
1. 1 FTE Project manager – The services of a project manager will be invaluable throughout the
implementation phase. This person can coordinate the work of documentation writers,
15
campus identity management integration specialists, and application specialists and
marketing campaigns.
2. Documentation services – Because the Tier 5 hosting is self-service, high quality
documentation and the service decision flowchart must be developed by professionals. The
documentation has to be extensive, thorough and easy to use when the services are
launched. This up-front effort will be rewarded later with fewer customer problems and
confusion with the production services.
3. Campus identity management integration specialist – All services must be integrated with
campus identity management tools.
4. Programming services – Programming services will be necessary to create and edit the selfservice account generation forms, decision flow chart, metrics collection and processing,
and fee paying software if fees are to be collected.
5. Designer services to create themes (which may include headers, footers and color palettes)
that can be added to vendor supplied templates and to provide oversight and specifications
for any outsourced template designs.
6. Marketing services – For the most beneficial targeted advertising of the services to faculty,
students and staff.
Ongoing Support FTE
Estimate the FTE number of staff needed to provide ongoing support for this solution.
Dedicated Web Team
The team of at least 3 FTE application specialists will continue to support Google Sites, PIE,
Illinois Wiki and the cloud based hosting after launch. These specialists will work with the
documentation writers to continuously improve user guides. They should spearhead the effort
to create and monitor a user forum where users can ask questions and receive answers from
fellow service users. The application specialists can correct or enhance answers offered by
service users when necessary. Commercial hosting companies use this model to allow for
crowdsourced user support. The applications specialists serve as the concierge for all the web
services. They are also service managers responsible for the technical aspects of the
publish.illinois.edu WordPress software and the wiki software, but not the underlying
infrastructure.
Additional staff needed on a periodic basis
1. Documentation writer – Because Tier 5 hosting relies heavily on users finding answers to
their own questions rather than consulting helpdesk personnel or IT Pros, on-going
documentation improvement is very important. The documentation person will interact
with the application specialists to ensure accuracy and up to date information in user
guides.
2. Service strategist role – The service strategist will be responsible for service governance,
refresh cycles, service usage monitoring, vendor relations and coordinating additional
marketing efforts if needed.
3. Programming support – Occasional ongoing support as dictated by changes/upgrades to
upstream services.
4. Designer services oversight – Periodic support will be needed as any locally developed
templates need refreshing.
16
Costs
Identify potential costs or saving opportunities, especially at the campus level. This does not necessarily
need to be actual costs.
Implementation Costs
Identify initial or one-time costs associated with build-out, implementation, transition, and
migration of the solution.
Phase One: Because phase one involves enhancing existing solutions, the costs associated with
the phase are primarily personnel costs. There will be some cost associated with increasing disk
space for PIE and for the possible purchase of plugins for the Wiki and templates for PIE and
Google Sites. It would be ideal for Publish to be moved to standard VM hosting as the wiki uses.
Phase Two: The major cost of phase two is the contract with the outside vendor for the cloud
web builder services. There will also be personnel costs involved with launching the service as
outlined in the Staff – Implementation FTE section above.
Ongoing Support Costs
Identify costs associated with staff support, service support plans, monthly/yearly service costs,
lease costs, or other recurring costs.
As with any service, ongoing support costs include:
 Cloud service support plans and contract renewal costs
 Google Sites support plans and contract renewal costs
 Documentation development – By providing documentation, direct consulting costs will
be lower
 Application specialists to support the services
 Minimal infrastructure costs to support integration components. 2-5 hosts to support
development/QA/test/prod environments for integration items
Refresh or Enhancement Costs
Identify potential costs associated with the solution to maintain or enhance the system, such as
hardware and software upgrades, and the frequency of those costs.
Ongoing periodic support may be needed to keep our campus authentication and account
generation methods working on cloud hosted solutions as vendors upgrade and update their
services. We will continue to need documentation updates as the services change. Template
components will need to be refreshed as branding standards and web design trends change.
The cloud solutions will have no hardware costs. The campus hosted Publish and Wiki are on
virtual hardware and some costs will be incurred when that infrastructure has to be refreshed,
but this is not specific to web hosting.
17
Solution Benefits
Identify the benefits of this solution, especially in consideration to other potential solutions. Describe
why this is the recommended solution.
All our peer institutions offer some level of web hosting to their campuses. These services are outlined
in the Peer Institution Review. Web hosting is a basic IT need for practically every faculty, student and
unit on this campus. The benefits of providing campus wide web hosting include:
 Increased security when non-managed web hosts can be removed from service and web
hosting platforms are known and accessible to security personnel
 Increased customer satisfaction when web hosting options are clearly defined, cost
effective and easy to use
 Cost savings at the unit level, in particular for units or groups that don’t have in house
web teams
 Cost savings in units and groups that will be able to use templates rather than paying for
custom designs
 Value added to units whose IT pros could be freed up from running basic web servers to
do other tasks
The benefit of having a blended solution that includes both on and off campus resources allows more
use cases to be covered by cost effective basic web hosting. Providing just on campus resources
wouldn’t allow us to take advantage of cloud hosting expertise while only cloud hosting makes it more
difficult, at least in the short term, to accommodate existing sites. It is unrealistic to expect all of the
thousands of basic websites found on campus today to move to cloud hosting in a short amount of time.
By keeping the on campus hosting available, migrations can occur to cloud hosting when it is most
appropriate and convenient for the individual sites and their owners.
Solution Risks
Identify risks and possible mitigation strategies specific to this solution.










Lack of adoption because groups increasingly move to other technologies such as Tumblr or
technologies not yet available
Adopting a platform that loses popularity so websites are stuck in an obsolete or proprietary system
and are difficult to migrate
Solution is still too complicated for users to manage on their own and consulting costs are higher
than expected
A lack of appealing templates reduces adoption
A reduction of web hosting infrastructure will lead to a loss of that particular skill set among oncampus IT personnel
Users increasingly want to use services they have already been exposed to when arriving on campus
rather than what we have chosen
Increased number of illinois.edu sites abandoned but still available to the public
A lack of resources to implement the solutions
No appropriate vended solution at a reasonable price available for phase two
GoogleSites is dropped as a product by Google
18
Solution Assumptions and Constraints
Assumptions
There will be the resources to secure a cloud solution and to enhance Google Sites,
publish.illinois.edu and the wiki. These resources include funding for cloud solution contracts
and on-campus personnel to manage web hosting. We also assume there will be a continued
need for websites in the absence of a new technology that replaces this need. We assume staff
transitions and training will occur smoothly. We assume the majority of users will be able to use
this level of hosting with no help from IT Pros.
Constraints
We will be severely constrained in implementing this solution if funding can’t be secured for
cloud hosting at a reasonable cost for campus. In many cases that cost will need to be zero for
units for at least some level of service. The procurement process will also be a constraint
because it can be a very long process. Funding for personnel to coordinate and manage these
web hosting offerings is also crucial to the success of the plan and a lack of staff time will
degrade the services.
Milestones: Implementation
Identify key milestones required for solution implementation, including dependencies and potential
timeline.
Implementation of Phase One (3-6 months) and Phase Two (12-18 months) may overlap.
Dependencies:




Implementation of both phases are dependent on acquiring staff and funding as outlined earlier
in this document.
Ongoing staffing and support for publish.Illinois.edu WordPress
Campus continue contracting with/for Google Sites
Successful completion of RFP for Cloud Hosting
Phase One:
The web hosting landing page and flowchart must be done first. Next documentation and enhancements
to existing services. At the same time, the RFP for the cloud service should be developed, released and a
product chosen.
Web hosting landing page and flowchart:
1. Web hosting landing page advertising existing services developed
2. Decision flowchart created, tested and launched for existing services
Google Sites:
1. Add to the web hosting landing page and flowchart
19
2. Template and theme and/or template component development for Google Sites either on
campus or outsourced
3. Documentation for Google Sites
4. Service marketing
Publish.illinois.edu WordPress
1.
2.
3.
4.
Add to the web hosting landing page and flowchart
Secure more disk space for publish.illinois.edu
Documentation development for publish.illinois.edu
Developing procedures for increasing the number of plugins and themes that can be safely
installed on publish.illinois.edu
5. Update the default site layout to be easier to use
6. Service marketing
Phase Two:









RFP for cloud solution
Choose and procure cloud solution
Build team to implement and support web hosting services
Integrate cloud solution into university authentication
Governance created for policies and procedures
Support model developed and implemented
Documentation development for the Illinois specific parts of the cloud hosting
Addition to the web hosting landing page and flowchart
Service marketing
Compare and Contrast
Provide a brief narrative on why this solution was chosen over the alternative solutions. Use the table to
compare and contrast the recommended solution to other solutions considered (and documented in
Appendix B.)
Items\Solutions
Technology
Scalability
Recommended Solution
Google Sites
publish.illinois.edu
Vended web builder
Google Sites and
vended options are
scalable by definition.
Publish can be scaled
and eventually moved
to cloud hosting if
wanted.
Solution A
Solution B
Solution C
20
Items\Solutions
Staffing:
Implementation FTE
Staffing: Ongoing
Support FTE
Costs:
Implementation
Costs
Costs: Ongoing
Support Costs
Costs: Refresh or
Enhancement Costs
Recommended Solution Solution A
 Project
Manager
 3 FTE
Application
specialists
 Documentation
specialist
 Integration
specialist
 Designers and
campus IT Pros
 Some
additional
software
development
possible
 3 FTE
Application
Specialists
 Documentation
specialists
Solution B
Solution C
Personnel and cloud
hosting contract costs
Service maintenance
and cloud hosting
support contracts
Cloud hosting contract
renewal costs
Transition Planning
The intent of this section is to understand the potential complexity, timeline, and challenges of moving forward
with this recommended solution, especially in consideration to other solutions. Consider that a solution may be
chosen to more quickly fill a shorter-term gap, or to realize a more immediate cost savings and reduction in the
duplication of work, while follow-on solutions may move towards a longer-term strategy. This section should
communicate the potential timeline of a solution so that strategic decisions can be made regarding these
factors.
High-Level Transition Plan
If a migration from current systems to the recommended solution is needed, provide a description of
the high-level transition plans. Describe what systems and data will need to be migrated.
If the proposed recommended solution is a new system, provide a description of a high-level
implementation plan. Describe the primary components that need to be implemented for the solution.
Describe current processes that will need to be reviewed and potentially changed, and a high-level
21
transition plan on how to transition those processes. Identify current processes used in existing
solutions, and which processes will need to be reviewed for potential updates.
The High Level Transition plan details are addressed in other parts of this document.
Milestones: Transition
Identify key milestones required for solution transition, including estimated durations and
dependencies.
Milestones transition details are addressed in other parts of this document.
Appendix A: References
Provide information about white papers, documents, or other materials used as a reference or that support the
recommended solution. This can include links to materials with a short description of the material purpose or
content.
 Campus Web Hosting Survey
 Campus Web Hosting Focus Discussion
 Peer institution review
Appendix B: Alternative Solutions
Describe the alternative solutions reviewed, but were not the recommended solution. Alternative solutions
could include modifications of existing solutions or new solutions not yet created.
We are not recommending alternative solutions.
Appendix C: Other Solutions Considered
Other potential solutions may have been discussed, but were not considered, possibly due to known issues or
reasons that make the solution not be viable. Describe the solutions discussed and the reason why they are not
viable.
22
Other Solution Considered A:
There was spirited discussion about creating an on-campus web-hosting approach to support Tier 5. The
idea focused on building out a Tier 5 layer on a locally built and managed Tier 4 or Tier 3 solution. There
were several concerns expressed:
1. Given that the Tier 4 and Tier 3 solutions have yet to be specified, it seemed preliminary to
suggest they be leveraged into a dual-purpose role to support Tier 5.
2. The scale of potential use of Tier 5 services could easily have forced the expansion in size of the
underlying Tier 4 or Tier 3 solution simply to ensure Tier 5 use cases could be served.
3. Tier 5 seems to be the easiest, early, win for Web Hosting and one that should be
straightforward to procure from a web hosting company. Adding Tier 5 requirements to either
or both Tier 4 and Tier 3 would have dramatically complicated the discussions needed for these
layers.
4. Branding and marketing of the Tier 5 solution would also be problematic because it would really
be a Tier 4 or Tier 3 solution that was being used in a different way.
The committee did feel that it would be nice if a Tier 5 result can easily “fall-out” of a Tier 4 or Tier 3
solution – say Faculty Biographies within a larger Departmental web site. However, the volume of Tier 5
use cases that might be covered would be a fraction of a general Tier 5 solution geared toward the bulk
of use cases.
Other Solution Considered B:
The addition of Google Sites to the campus Google e-mail and Google Apps contract did spark a
discussion of whether Google Sites was sufficient to cover Tier 5 needs - especially if the PIE blogging
site, Wiki site and Webtools are retained and strengthened.
Early adopters of Google Sites expressed dismay at the poor site quality that has so far been evident
while trying to create a quick web site. It was also perceived to not be as simple to use as one might
hope. A good Tier 5 solution needs to be easy to use and allow for high-quality sites to be created –
Google Sites seemed to miss the mark on both counts.
It was felt that Google Sites could become quite important for teaching and learning in situations where
some content has to be made “available” for a limited audience in a short amount of time. In one case,
students in a class needed to create a web presentation based on content that was being sourced from
another (commercial) site. The goal was not the creation of a web site per se, but to use local code
mixed with external content to create a single page that demonstrated an idea - Google Sites is perfect
for this use case.
Appendix D: Use Case Mapping
List the use cases that address or support the recommended solution.
This Use Case Solution Mapping table maps use cases to the solution based on the degree the solution
fits the use case. This solution is not intended to be appropriate for every use case. The degrees of
mapping are:
23



High: The use case maps very well to the solution and the expectation is that the majority of
people with this use case will be able to use one or more of the solutions.
Medium: The use case might be served by the solution, but there are too many variations in the
use case so some variations might need a different solution. For example, the wiki can be used
for the use case “Researchers want website to provide access to data”, but the wiki theme can’t
be changed and the uploaded file size is limited to 10MB. Some researches will be able to use it
with these limitations while others will need a different solution.
Low: While technically the use case could be implemented using the solution, the solution is not
the best tool for it.
24