Campus Content Management System SLA 2015

UC San Diego Campus CMS SLA
Campus Content Management

System Service Level Agreement
(SLA)
Table of Contents
1.
General Overview................................................................................................. 3
1.1
2.
Service Owners.............................................................................................. 3
Service Description.............................................................................................. 4
2.1
Service Scope................................................................................................ 4
2.1.1
Hannon Hill Cascade Server CMS............................................................4
2.1.2
Google Site Search (GSS)........................................................................4
2.1.3
Google Analytics...................................................................................... 4
2.1.4
eforms..................................................................................................... 4
2.2
CMS Features................................................................................................. 4
2.2.1
Create Website........................................................................................ 4
2.2.2
Create, Edit and Publish Web Pages........................................................5
2.2.3
Metadata................................................................................................. 5
2.2.4
Versioning................................................................................................ 5
2.2.5
Document and Image Hosting.................................................................5
2.2.6
Friendly URLs........................................................................................... 5
2.2.7
Content Templates................................................................................... 5
2.3
Limitations..................................................................................................... 6
2.3.1
Hosting video files................................................................................... 6
2.3.2
Online forms & Web Applications.............................................................6
2.3.3
Custom JavaScript or Embedded Dynamic Code.....................................6
2.3.4
Wiki and Blog features............................................................................. 7
2.4
Search............................................................................................................ 7
2.5
Web Hosting................................................................................................... 7
2.5.1
ACT Web Hosting..................................................................................... 7
2.5.2
Client Web Hosting.................................................................................. 7

Page | 1

2.6
Security, Access Levels & Roles.....................................................................7
2.7
Analytics and Web Traffic Reporting...............................................................7
2.8
Content Backup............................................................................................. 8
2.8.1
2.9
3.
4.
5.
System Architecture....................................................................................... 8
Campus Web Office Responsibilities.....................................................................9

3.1
On Boarding................................................................................................... 9
3.2
Content Migration.......................................................................................... 9
3.3
Training.......................................................................................................... 9
3.4
Testing/QA...................................................................................................... 9
3.5
Deployment................................................................................................... 9
Customer Responsibilities.................................................................................... 9
4.1
Content Guidelines........................................................................................ 9
4.2
Designated Point of Contact........................................................................10
4.3
Verifying Website......................................................................................... 10
4.4
End User Prerequisites.................................................................................10
4.4.1
Business Systems Account for Authentication.......................................10
4.4.2
Supported Browsers and Operating Systems........................................10
4.4.3
VPN Access............................................................................................ 10
Requesting Service............................................................................................. 10
5.1
Existing Clients............................................................................................ 10
5.1.1
6.
Backup and Disaster Recovery................................................................8
Emergency Requests.............................................................................10
5.2
New Clients.................................................................................................. 10
5.3
Hours of Coverage....................................................................................... 11
5.4
Response..................................................................................................... 11
Maintenance or Service Changes.......................................................................11

6.1
Enhancements............................................................................................. 11
6.1.1
Enhancement Requests.........................................................................11
6.1.2
Enhancement Implementation..............................................................11
6.2
Upgrades..................................................................................................... 11
6.3
CMS Restarts................................................................................................ 12
6.4
Assumptions................................................................................................ 12
Page | 2

7.
Pricing................................................................................................................ 12
8.
Reporting, Reviewing, and Auditing...................................................................12
9.
Associated Policies, Processes and Procedures..................................................12

9.1
Domain Names............................................................................................ 12
9.2
URL Guidelines............................................................................................. 13
10.
Alternate SLAs................................................................................................. 13
1. General Overview
This is a Service Level Agreement (SLA) between the Service Provider:
Campus Web Office (CWO)
And the campus community (clients), to document:
Services that allow website owners to use the Hannon Hill Cascade Server
content management system (CMS) to maintain Web content
General levels of response, availability, and maintenance associated with
these services
Responsibilities of the service providers and clients
The process for requesting services
This version of the SLA began April 24, 2015 and will be reviewed and updated as
needed.
1.1 Service Owners

The following Service Owners will be used as the basis of the Agreement and
represent the primary stakeholders associated with this SLA.
Stakeholder
CMS Operations
Manager
Campus Web
Technologies Manager
UNIX Systems
Manager
Responsibilities
Oversees the service offering, promotes the CMS, and
provides a process and governance for the websites that
will be maintained in the CMS
Provides technical and administrative support of the CMS,
including content templates, transports, content types,
roles
Responsible for the infrastructure that supports the CMS
and GSS including Web servers, application servers,
database servers and disaster recovery
Page | 3

2. Service Description
2.1 Service Scope
The general offering described in this document is for qualifying academic and
administrative departments that meet the guidelines for service outlined at:
http://cwo.ucsd.edu/prod-serv/cms/
and want to use the Campus CMS to manage their website content.
The CMS contains templates that reflect current UC San Diego branding and are
accessibility (ADA) conformant. It provides a user-friendly way for website owners to
update content and a stable environment with dedicated support staff.
In addition, complimentary systems are coupled with the campus CMS to enhance
the service offering. The following software systems make up the campuswide
service offering:
2.1.1
Hannon Hill Cascade Server CMS
Cascade Server is a powerful Web content management solution that gives
people the freedom to manage their Web content through a user-friendly
interface. Designed around XML and for any network environment, users can
access Cascade Server through any Internet-connected browser. Cascade
Server helps organizations maintain a high quality, standards-compliant
website, while providing deployment flexibility, a zero footprint client, and
fast implementation.
http://hannonhill.com/
2.1.2
Google Site Search (GSS)
Google Site Search is a Google-hosted search solution that provides universal
search. It includes enterprise-specific relevance algorithms in a single, easyto-deploy solution.
https://www.google.com/work/search/products/gss.html
2.1.3
Google Analytics
Websites maintained in the campus CMS are connected to Google Analytics,
which allows statistical reporting page views and other metrics to assist
clients with analyzing the behaviors of their Web visitors.
2.1.4
eforms
The CWO provides customizable electronic forms (eforms) for sites in the CMS
provided they arent used to collect Personally Identifiable Information (PII) or
used for applications for academic programs. eforms will be retained for one
full year from the date of creation and may be disabled or removed if they
are deemed inappropriate or cause any security issues.
Page | 4

2.2 CMS Features
2.2.1
Create Website
The CWO will work with the client to develop a recommended site architecture
and navigation structure based on the clients goals and objectives. In most
cases, the client will develop the site content.
2.2.2
Create, Edit and Publish Web Pages
Clients have the ability to freely edit their Web pages within the confines of the
CMS after the initial site deployment. Editing of content occurs in two ways:
through the WYSIWYG interface or through the HTML editor. Once edits are
made, clients can publish the changes to a staging environment for review
before publishing to the live environment1.
2.2.3
Metadata
Standard metadata sets are included in the UC San Diego templates. Specific
metadata elements will be reviewed in training and orientation with the client.
2.2.4
Versioning
The CMS supports versioning of Web pages so the client can retrieve previous
versions of a page, compare it with current versions, and republish older
versions if need be.
2.2.5
Document and Image Hosting
The CMS supports the hosting of documents and images that are linked or
appear on an associated Web page. The maximum file size is 10MB.
2.2.6
Friendly URLs
Content maintained in the CMS is delivered with human readable URLs. These
URLs are considered search engine friendly based on the semantics matching
the content of the Web page (e.g., http://roosevelt.ucsd.edu/about/ would be the
URL for Roosevelt Colleges About Us section).
2.2.7
Content Templates
The Campus CMS provides templates that reflect UC San Diego branding and allow
clients to display content in a variety of layouts:
http://cwo.ucsd.edu/support/documentation/templates-styles/.
As the service offering matures, the CWO will offer more templates to campus
clients. When this happens, all clients will notified of the new templates, their
features, and how to implement them within their website.
1 Publishing rights may be restricted to the staging environment if the content is

part of a portal, e.g., TritonLink.
Page | 5

2.2.7.1
Accessibility
The CMS templates are built and tested to be conformant to Web Content
Accessibility Guidelines: http://www.w3.org/TR/WCAG/ and comply with UCOP policy:
http://www.ucop.edu/electronic-accessibility/initiative/policy.html.
2.2.7.2
Overriding Design Elements
The CMS templates work hand in hand with HTML and CSS to provide the layout of
CMS pages. The CWO also offers sitewide themes with alternative styles
combinations of background colors and modern Web fontsthat allow sites to be
uniquely branded while maintaining consistency, responsiveness, and accessibility.
If the client creates or modifies their CMS site-specific CSS file, the CWO is not
responsible for fixing broken elements that may occur as a result of overriding CSS
elements. If the client cannot support the site-specific CSS, the CWO will revert the
site back to using the standard CSS only.
2.2.7.3
Access to Create or Modify Templates
The CWO is responsible for the integrity of the CMS templates. The templates are
designed and built in a way to share common elements and structures. This allows
the CWO to deploy enhancements and fixes in one location that will benefit all CMS
clients.
Under our general service level, The CWO does not provide clients the ability to
modify or create new templates to ensure stability across the system.
2.3 Limitations
2.3.1
Hosting video files
While clients have the ability to embed videos within their web pages, the CMS
does not support the hosting of multimedia, Flash, or video files. The primary
reason is these files are typically large and database intensive. Multimedia
servers are optimized for hosting video files and the CWO can refer clients to onand off-campus resources that provide this type of service.
2.3.2
Online forms & Web Applications
At this time, the CMS will not support the development of web applications. The
primary function of the CMS is to manage web content and does not provide a
platform for developing web applications.
The CMS can, however, produce a decorator that contains the header and
footer elements of the website. Clients with advanced technical skills can
leverage the decorator to provide integration of their web applications with their
CMS site.
The CWO can create customizable electronic forms (eforms) for sites in the CMS
provided they arent used to collect Personally Identifiable Information (PII) or
Page | 6

used for applications for academic programs. eforms will be retained for one full
year from the date of creation and may be disabled or removed if they are
deemed inappropriate or cause any security issues.
2.3.3
Custom JavaScript or Embedded Dynamic Code
Websites managed in the CMS can leverage add-ons such as image slideshows
and other pre-defined widgets. If the client wants to embed code that pulls in
functionality, videos, or other dynamic content, we ask them to use our predefined widgets: http://cwo.ucsd.edu/support/documentation/templatesstyles/kitchen-sink.html or ask the CWO for assistance. Clients can request
enhancements on the CWO Uservoice page: http://cwo.uservoice.com/. If the
client embeds dynamic code that is deemed to be detrimental to the health of
the CMS or poses a security risk, the CWO reserves the right to remove such
code.
2.3.4
Wiki and Blog features
At this time, interactive features such as updating Web pages in real-time
(wiki) are not available. The CWO can refer clients to other solutions that
provide this type of functionality.
2.4 Search
Campus CMS sites are indexed by Google Site Search (GSS), and include the search
box in the header of their website.
The search box includes a search this site feature. This allows search results to be
limited to the site the user is on. The user can also toggle to the campus wide and
people directory search.
2.5 Web Hosting

2.5.1
ACT Web Hosting
ACT provides a website hosting service powered by Amazon Web Services (AWS) for
sites maintained in the CMS. ACT uses a Web server cluster to propagate content
across multiple physical servers. This maximizes uptime in case one of the servers
becomes disabled for any reason.
The web server cluster runs Apache and exceeds the specifications recommended
by Hannon Hill for the CMS. More information can be found in the System
Architecture section below.
2.5.2
Client Web Hosting
Provided clients maintain a web server environment that meets the requirements
for website hosting they can host their website in a datacenter outside of ACT. An
evaluation of the clients datacenter will take place to ensure it meets hosting
requirements: http://cwo.ucsd.edu/prod-serv/cms/next-steps/host-own.html.
Page | 7

If the client chooses this option, they are waiving the right to have ACT sysadmin
support on their website maintenance. Risks include network-related outages that
can affect website uptime.
2.6 Security, Access Levels & Roles

The campus CMS is integrated with the campus Single Sign-On (SSO) system. Once
logged in, users will be able to work within the CMS for a period of 8 hours before
their session times out. After 8 hours of inactivity, a user will be prompted to log
back in with their SSO credentials.
CMS clients can delineate two groups of users: those that have the ability to publish
to the staging environment only and those that can publish to both staging and
delivery. No further granularity can be supported at this time.
2.7 Analytics and Web Traffic Reporting

With each new website added to the CMS, clients will get access to their own
website profile within the Google Analytics dashboard. This allows them to use all
the reporting features Google Analytics provides.
2.8 Content Backup

2.8.1
Backup and Disaster Recovery
The CMS database architecture uses a masterslave replication relationship.
Replication is configured at the safest possible setting. In the event of a crash the
most that can be lost is one database transaction.
Campus or regional incidents that cause major power/system outages are of the
highest priority, and the Campus CMS fits into the overall ACT Disaster Recovery
Plan. The CMS takes advantage of AWS availability zones for backup and disaster
recovery.
2.9 System Architecture

The Campus CMS is hosted at the Torrey Pines datacenter. It is a clustered
environment with load balancing and redundancy built into the architecture design.
All of the hardware exceeds the minimum requirements recommended by the
vendor. A detailed system architecture diagram of the production environment is
included below.
Page | 8
3. Campus Web Office Responsibilities

3.1 On Boarding
The CWO will work with new clients to migrate their content into the CMS. This
includes performing a content analysis if a website already exists and
recommending a site structure and hierarchy. The milestones for website migration
will be documented in a Statement of Work (SOW).
3.2 Content Migration

The CWO is responsible for migrating the clients content into the CMS. This is to
ensure a clean, accessible website. The CWO will:
Create a new shell using the latest templates and CSS.

Train staff and designees on how to update the website before deployment
so staff can make ongoing updates.
Validate that the site meets the stated customer and target user goals.
Page | 9
Align website with current UC San Diego branding.

Ensure the site meets all UC San Diego style guidelines, usability, and
accessibility including conformance to section 508 guidelines for
accessibility and quality criteria.
3.3 Training
Prior to the website launch, the CWO will train the client on how to update their
website in the CMS. In person and hands on training will be conducted. Training
documentation can be found online at
https://cwo.ucsd.edu/support/documentation/.
3.4 Testing/QA
The CWO will perform testing of the client website in supported browsers and
mobile devices, including accessibility according to UC policy:
http://www.ucop.edu/electronic-accessibility/initiative/policy.html.
3.5 Deployment
The CWO will assist in all aspects of the client websites initial deployment including
coordinating DNS changes with the Hostmaster and redirects that need to change
as a result of ACT hosting the website.
4. Customer Responsibilities
4.1 Content Guidelines
The client website shall be UC San Diego-related, the target audience consisting
primarily of prospective students, current students, faculty and staff, or related
audiences. The client is responsible for using appropriate, professional language
throughout the site. If at any time the client deviates from these guidelines, the
CWO has the right to remove offending content.
4.2 Designated Point of Contact

When the Statement of Work (SOW) is created, one designated point of contact
shall be assigned for the CWO to work with. This point of contact will coordinate all
activities from the clients side.
4.3 Verifying Website

Clients have the responsibility of reviewing and approving their website prior to
initial launch. It is up to the client thereafter to keep their site current. The CWO is
available to help answer specific questions and provide support.
4.4 End User Prerequisites

The following outlines some prerequisites CMS users will need:
Page | 10

4.4.1
Business Systems Account for Authentication
Clients can self register for a Business Systems account:
http://blink.ucsd.edu/go/access.
4.4.2
Supported Browsers and Operating Systems
The following browsers are used to test web sites managed in the CMS. These
browsers make up 95% the website traffic to UCSD sites, according to Google
Analytics.
Recent releases of Chrome (Mac & PC)

Recent releases of Firefox (Mac & PC)
Internet Explorer 711 (PC)
Safari 7 (Mac)
Display capable of 1024 x 768 resolution or higher
4.4.3
VPN Access
Clients who want to access the CMS off-campus can do so through the use of Virtual
Private Network (VPN): http://blink.ucsd.edu/go/vpn.
5. Requesting Service
5.1 Existing Clients
Clients can contact the CWO through email cwo@ucsd.edu. This will log a ticket in
our tracking system which can be triaged to a team member help. Turnaround time
for contacting the client is generally one business day. More information about how
to contact the CWO: http://cwo.ucsd.edu/contact/.
5.1.1
Emergency Requests
If the request is an emergency, contact the ACT Help Desk at (858) 534-1853.
5.2 New Clients

Clients will be sequenced to come in to the CMS in the most efficient manner
possible. Ultimately sequencing will depend on staffing and the guidance provided
by the Campus Website Steering Committee (CWSC). Typically, the CWO is
migrating anywhere from 410 websites at any given time.
5.3 Hours of Coverage

Typical hours of coverage are from 8 a.m. 5 p.m., Monday through Friday. Help
Desk hours for incidents are 7 a.m. 7 p.m., Monday through Friday.
For after-hours incidents, clients can reach the Operations Center at Torrey Pines
Center South by calling (858) 534-1853 and appropriate technical staff will be
contacted. On weekends, incidents logged with the Help Desk will be triaged to the
necessary points of contact for investigation.
Page | 11

5.4 Response
Based on the severity of the incident, and current state of known issues, response
time will vary. Generally, a one-day turnaround should be expected for lower level
incidents and up to 48 hours during increased volume.
6. Maintenance or Service Changes

With any software system, regular maintenance is necessary. Advanced notice to
clients about regular maintenance is important to the CWO to ensure continuity of
service.
6.1 Enhancements
The campus CMS is an out of the box solution. This means the underlying software
code cannot be manipulated to change the systems core functions. However, the
campus CMS has certain configurations that can enable and disable certain
features. In addition, Hannon Hill offers plug-ins that allow for additional features to
be added to the system.
6.1.1
Enhancement Requests
Enhancement requests can be sent to the CWO Uservoice page at
http://cwo.uservoice.com/ and will be implemented based on client votes and
feasibility.
6.1.2
Enhancement Implementation
Enhancements are logged and prioritized by the CWO. Implementation will be based
on feasibility and overall benefit to the entire CMS user group. Clients will be
notified of the new feature or change prior to implementation. In some cases clients
may be asked to test the enhancement.
6.2 Upgrades
CMS upgrades will be generally performed to keep in line with each major release of
the CMS. Typically, the CWO will wait until several point releases are available
before upgrading to a new version. We will coordinate the upgrade installation
through each environment, test to ensure the upgrade didnt break any current
configurations, and fix any broken configurations due to the upgrade. The CWO
coordinates all change management activities associated with the upgrade
including communicating with clients regarding any associated downtime and
additional features or capabilities available to the clients available in the latest
software release.
6.3 CMS Restarts

CMS restarts occur on a weekly basis on Sundays at 5 a.m. to keep things fresh in
the system so response time is maximized for clients. A cron job runs to reboot the
Page | 12

servers. The CMS is down for approximately 510 minutes when the servers are
rebooted.
6.4 Assumptions
Major CMS software upgrades will be treated as projects that will be managed
by the CWO.
Changes to services and new features will be communicated and documented
to all stakeholders via the Campus Web Office mailing list and Campus Web
Office website http://cwo.ucsd.edu/.
Service will be provided in adherence to any related policies, processes, and
procedures.
7. Pricing
As of the Effective Date of this agreement, the CWO does not charge for any
services provided to the client. The CMS service is structured in a way to maximize
efficiency to internally fund this service by ACT and still provide the most benefit
possible to the clients.
8. Reporting, Reviewing, and Auditing

This Agreement is valid from the Effective Date outlined herein and is valid until the
Date of Termination. The Agreement should be reviewed at a minimum once per
fiscal year; however, in lieu of a review during any period specified, the current
Agreement will remain in effect.
The Designated Review Owner (Document Owner) is responsible for facilitating
regular reviews of this document. Contents of this document may be amended as
required, provided mutual agreement is obtained from the primary stakeholders and
communicated to all affected parties. The Document Owner will incorporate all
subsequent revisions and obtain mutual agreements/approvals as required.
Designated Review Owner: Allisa Becker
Review Period: Annually
Previous Review Date: April, 2015
Next Review Date: April, 2016
This Agreement will be posted to the following location and will be made accessible
to all stakeholders:
Document Location: http://cwo.ucsd.edu/prod-serv/cms/next-steps/sla.html
Page | 13

9. Associated Policies, Processes and Procedures
9.1 Domain Names
The CWO will handle registering domain names on behalf of the client. If the client
has an existing domain name and wishes to host their website within the ACT
datacenter, they will need to transfer ownership of the name to ACT.
Domain names for top level websites should abide by the following format:
http://sitename.ucsd.edu/. Content rendered under the site will fall underneath
this URL structure.
9.2 URL Guidelines

Content maintained in the campus CMS is delivered with human readable URLs.
URLs reflect the Web site taxonomy, e.g. http://roosevelt.ucsd.edu/about/.
10.
Alternate SLAs
This SLA outlines support services by the Campus Web Office to UC San Diego
clients. Given limited staff, resources and budget, the CWO services are limited to
the parameters specified above.
We understand certain units on campus may have resources to augment or
supplement the services provided by the CWO. In some cases it is possible to
negotiate terms outside our standard SLA. In these cases, clients may be giving up
the right to have the CWO support them. Please contact the CWO for more details.
Allisa Becker, CMS Operations Manager
Page | 14

Campus Content Management System SLA 2015

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Campus Content Management System SLA 2015

Uploaded by

Copyright:

Available Formats

UC San Diego Campus CMS SLA