(DRAFT for Industry Comment)

Statement of RequirementsandRFP Vendor Questions

The Provision of govCMS - A Whole-of-Government Content Management System

FIN/026/17

Date issued: December 2017

Version: 1.6

DRAFT FOR COMMENT

RFP for the provision of govCMS – a whole-of-government content management system

Table of contents

Purpose of this exposure draft

How to provide comment and feedback

1Conditions for Participation in the RFP

Mandatory requirements

2Background to govCMS

Introduction

Analysis of government websites

Overview of the govCMS Service Delivery Framework

3Objectives of govCMS

Cost savings to agencies

Easier compliance for agencies

Promote use of open-source SaaS solutions

Other benefits for government

4govCMS implementation and transition approach

Sites and key metrics

SaaS platform

PaaS platform

Pricing scenarios

Migration scenarios

SaaS platform

PaaS platform

5govCMS operational considerations

Compliance policies and standards

Facility to share artefacts between agencies

Backup and ability to restore individual websites

Disaster recovery of individual websites or the whole managed platform

Web protection services including DDoS, WAF and CDN

6Scope of requirements and required services for GovCMS

Solution requirements

Service requirements

Service desk support

Business management

Infrastructure management

Site on-boarding

Site management, change management and publishing workflow

Technical account management

govCMS training

7Vendor questions

Responses requested

Relevant experience

Scope of services

Proposed content management system solution

Purpose of this exposure draft

  • This exposure draft statement of requirement (SoR) is released to industry to generate comment and feedback on the govCMS requirements identified in the SoR.
  • Your comments are encouraged, and may be used and incorporated in the request for proposal (RFP) documents, which are expected to be released in early 2018.
  • You are invited to make suggestions about any aspect of the SoR, including the description of the services, any requirements which in your view are inappropriate or inflexible, and on how the SoR could be drafted to facilitate innovative proposals.
  • Finance anticipates inviting proposals from entities which can meet, either themselves or as part of a consortium, all requirements in the SoR. Finance does not anticipate accepting proposals from entities which only meet certain aspects of the requirements.
  • The information contained in the SoR is subject to change and you should not rely on this SoR as reflecting the final version of the RFP.
  • Finance may select one or more respondents to the RFP.

How to provide feedback

  • All feedback must be received by Finance no later than close of business
    Friday 19January 2018.
  • You may:
  • Provide comments on the blogpost this document was originally published on
  • Email the govCMS team at
  • Send written feedback or comments to
    Attn: govCMS Service Manager
    Online Services Branch
    ICT Division
    Department of Finance
    1 Canberra Avenue
    FORREST ACT 2603

1Conditions for Participation in the RFP

Mandatory requirements

1.1The solution must use Drupal open-source software as the Software-as-a-Service Content Management System.

1.2The solution must support multiple versions of Drupal, specifically version 7 and version 8 operating in production simultaneously on both the SaaS and PaaS govCMS platforms.

1.3The solution (for any version of Drupal) must be able to support a fully managed common codebase, site-by-site extensions to the common codebase, and fully bespoke codebases (which may or may not use parts of the common codebase).

1.4'The solution must use public cloud infrastructure that can be IRAP assessed and accredited as meeting the Australian Government security requirements at Unclassified DLM (UD).
Reference:

1.5Responding suppliers must be willing to co-fund the establishment of the security accreditation of the solution; both infrastructure and application layer, and agree to continue co-funding ongoing review and re-accreditation activities over the life of the contract. Suppliers not already listed on the ASD CCSL must obtain ASD certification for their platform.
Reference:

1.6All responses must describe a solution that meets the full statement of requirement and specifically addresses all the service requirements, pricing and migration scenarios.

1.6.1Finance will only consider partial responses from a single organisation if they are part of a consortium bid, or where there is documented evidence of a sub-contractor partnership between suppliers.

1.6.2Responding suppliers can be suppliers contracted under the govCMS Drupal Services Panel. For clarity, a supplier engaged under the contract established by this RFP will not be automatically added to the Services Panel.

1.7Responding suppliers must accept the “Web Development Services Head Agreement” as written. This is a standard Commonwealth contract. Specific terms and conditions that arise out of negotiations will be agreed and documented under a specific module attached to the Head Agreement. A copy of the Head Agreement and any draft module will be attached to the RFP when issued.

2Background to govCMS

Introduction

2.1There are around 1200 websites across the Australian Commonwealth Government, and more managed by state and local government agencies. Many of the sites are static, with limited complexity and consume significant resources from an internal IT department, or through an external hosted arrangement.

2.2Many websites use commercially licensed software, which incur annual maintenance costs to keep up to date. Other websites are hosted on outdated and unsupported platforms that are unwieldy to update,or are unable to offer a contemporary online experience.

2.3Many small agencies do not have the resources to meet government website standards around security accreditation and accessibility obligations.

2.4govCMS is an important service offering for Australian Government agencies. It represents a tangible implementation of the direction to simplify Government ICT and eliminate duplicated, fragmented and sub-scale activities across agencies by requiring use of shared or cloud services where minimum efficient scale hurdles are not met.

2.5govCMS supports more effective web channel delivery functions within Government, and enables agencies to redirect effort from non-core transactional activities, towards higher-value activities that are more aligned with core agency outcomes (Figure 1).

2.6govCMS enables the Australian Government to do this at a lower overall cost.

Analysis of government websites

2.7govCMS classifies government websites according to the following patterns:

Website pattern / Definition (general)
Pattern 1: Templated / Relatively small number of pages, rarely updated content, no complex functionality, no integration of the website with back-end systems, no registration or login functionality
Pattern 2: Content Rich / Moderate to large number of content based pages, some complex and interactive functionality, above standard search and other features. May include registration/login functionality
Pattern 3: Feature Rich / Moderate to large number of content based pages, highly customized pages and content, extensive application-based functionality such as registration/login functionality, dynamically generated content, personalisation, powerful search functionality, two-way integration with backend systems
Pattern 4:
Resource Archives / Small to large number of content pages, with some degree of advanced functionality, more than 20GB of files and assets, including documents, multimedia, images – can be “fixed” archives or site that grow rapidly over time as new content and resources are published
Pattern 5:
Distributed Content Publishing / Sites providing content as an API, centrally managed and shared or deployed across multiple front-end sites – which may include traditional websites, javascript web apps, mobile apps, kiosks, call centres, shopfront information displays

2.8There is a clear skew towards larger numbers of smaller, less complex sites (pattern 1 websites). The pattern of complexity is starting to change over time with a growing emphasis on patterns 3, 4 and 5.


Figure 2: Number and complexity of websites

2.9A feasibility study outlined three demand projection scenarios for the first four years of the programme (to end of June 2019):

2.9.1Conservative - the low end of the projection range - 182 websites on-boarded.

2.9.2Intermediate - the mid-point of the of the projection range - 298 websites on-boarded.

2.9.3Ambitious - the high end of the projection range - 437 websites on-boarded.

2.102.5 years into the programme, we are right on the intermediate projection, with 180 sites live, 65 agencies signed up, and more than 30 sites in the confirmed development pipeline.

2.11Figure 3 illustrates this year-by-year ramp-up in the number of websites expected to be migrated onto the GovCMS platform.


Figure 3: Four-year forecast of total number of websites on-boarded to govCMS

Overview of the govCMS Service Delivery Framework

2.12The govCMS Service Delivery Framework guides the planning and delivery of govCMS service offerings, including the processes, capabilities and assets that underpin service delivery. It is designed to be agnostic with regard to the sourcing of service providers, and applies equally to fully in-sourced service delivery, fully outsourced delivery or co-sourced delivery scenarios.


Figure 4: govCMS Service Delivery Framework

2.13The govCMS Service Delivery Framework covers three broad areas, outlined below and illustrated in Figure 4:

2.13.1Service planning. Includes the processes required to bring services from concept to implementation, and drive ongoing service improvement. These processes are largely independent of day-to-day service delivery, but provide assurance that investment is focused on services that are relevant and genuinely valuable to users, and delivered in a way that is reliable, efficient, sustainable and continually improving.

2.13.2Service delivery. The service delivery area of the framework is organised into four stages that reflect the customer engagement lifecycle, beginning with the recruitment of agencies as customers, and continuing with the implementation of a GovCMS solution, the operational management of that solution, and potentially the off-boarding of that solution from the GovCMS platform. These services rely on a range of service enablers.

Lifecycle stage / Description
Recruitment / Includes the promotion of govCMS to agencies, targeting and selection of agencies for on-boarding, assessment of needs, and establishment of agreements.
Implementation / Implementation includes the project-driven planning and execution activities required to transition agencies onto govCMS as well as the ongoing adoption of new services by agencies as their needs and priorities evolve over time.
Operation / Processes concerned with delivery and support of services so as to ensure value for the customer and the service provider. Focused on maintaining stability in service operations, allowing for changes in design, scale, scope and service levels.
Off-boarding / Includes the removal of agency sites from govCMS, associated archiving and handover of content, and termination of agreements.

2.13.3Service enablers. Includes the supporting processes, delivery capabilities and re-usable assets that underpin the successful delivery of services to the users. Without these enablers, the services could not be delivered. Each service relies on a specific configuration of enablers, so that a many-to-many relationship exists between services and enablers.

3Objectives of govCMS

Cost savings to agencies

3.1govCMS seeks to deliver cost savings to agencies through coordinating government activity and economies of scale.

3.2Coordinating multiple government agencies to use a common and scalable cloud based technology platform to host websites seeks to reduce the total cost to the Commonwealth of maintaining their web presence.

3.3The use of a Software-as-a-Service cloud based platform seeks to gain economies of scale cost savings as more agencies migrate to the common platform, and to achieve ongoing savings through price reductions of cloud infrastructure over time.

Easier compliance for agencies

3.4govCMS seeks to make it easier for agencies to comply with government policies and standards in areas such as security, accessibility, privacy and government digital design standards. The govCMS platform is designed in a way that makes it easier for agencies to increase compliance and reduce individual agency compliance costs.

Promote use of open-source SaaS solutions

3.5govCMSuses open-source tools and software to share artefacts between agencies and the community.

3.6Sharing code, modules and applications between agencies has already demonstrated the ability to reduce development costs. We expect all code and modules developed for use in the open source platform would be made available for all government agencies (and the wider open source community) to freely utilise any Drupal modules developed.

3.7Use of open-source software is in line with the Australian Government policy encouraging agencies to adopt open-source software where possible.

3.8govCMS seeks to utilise the market to enhance the current service with low upfront investment required from Finance.

3.9govCMS intends to use a Software-as-a-Service vendor to reduce the requirement for upfront investment to establish, maintain and enhance the platform The ideal vendor would play a significant role in the:

3.9.1provisioning and management of platform infrastructure that is flexible, scalable, elastic and appropriately containerised

3.9.2maintenance, testing and deployment of Drupal distributions and code bases

3.9.3tools and workflows to support continuous integration and automated testing across development, staging and production environments

3.9.4delivery of a common framework for site theming that implements the DTA UI Toolkit

3.9.5support of the govCMS community via 24x7 service desk, and other activities such as the provision of training, mentoring and skills accreditation

3.9.6security accreditation of the hosting infrastructure

3.9.7security management of the common codebase(s) accredited and managed by Finance

Other benefits for government

3.10Increased productivity following transition of non-CMS websites on to a CMS.

3.11Workforce skillset benefits through wider use of a standardised CMS, enabling the development of a common skillset across the Australian Public Service, reduced stand-up time for new websites using standardised website deployment in a CMS.

3.12Improved delivery of mobile responsive websites.

3.13A more standardised user experience for citizens dealing with government through shared design assets and patterns.

3.14Opportunities for collaboration.

4govCMS implementation and transition approach

4.1govCMS implementation and transition planning is ongoing and will require input from the successful Software-as-a-Service vendor.

Sites and key metrics

4.2As at December 2017 there are 63 sites hosted on the fully-managed (SaaS) version of govCMS. There are 117 sites on the self-managed (PaaS) version of govCMS.

4.3govCMS is a whole-of-government platform and provides services to Commonwealth, state and local government entities.

4.4The most recent version of the list of live sites is available from the govCMS website at

SaaS platform

4.5Two months of data for the SaaS platform shows total bandwidth used is an average of 3.25 Terabytes per month. Note, approximately 70% of this traffic is held at the edge by our current CDN and caching solution.

4.6The largest SaaS site in October 2017 consumed nearly 500GB of bandwidth. The next 6 biggest consumers of bandwidth each used more than 200GB each. The average for the other sites is around 30GB per month, the bottom third of sites only use around 5GB of data per month.

4.7The graph below shows the approximate distribution of bandwidth consumed by different types of sites on the SaaS platform.


4.8In the past year, all sites on the SaaS platform have averaged 50-200,000 pageviews per day, peaking at just over 250,000 pageviews in May. Traffic is growing about 10% per year, this is consistent with general growth in Internet traffic.


4.9The number of SaaS sites live on the govCMS platform increased by 23 over the past year from 40 to 63 sites. For the purpose of the pricing scenario, it would be appropriate to assume traffic and bandwidth will increase by 0.5% for each additional SaaS site.

4.10Database sizes and storage requirements are as follows:

4.10.1There are 200 databases currently in use on the production SaaS platform. Whilst there are only 60 “live” sites many sites have 1 or more clones. When a site is cloned all assets and database content is cloned as well.

4.10.2The average database size is 400 megabytes. Most of the databases are less than 100 megabytes in size, the largest is 2.6 gigabytes.

4.10.3The total database storage requirement for the production SaaS environment, including clones, is 75 gigabytes.

4.10.4Most sites on the production SaaS platform have 10 gigabytes of disk storage used (or less). A small number of sites are larger, up to 50 gigabytes of storage.

4.10.5The total disk space currently used by the SaaS platform, including clone sites, is 2.6 terabytes.

4.11The average number of users visiting govCMS SaaS sites varies from 500 per hour in off-peak periods, to 8,000 per hour. This peak period extends from 10am to 3pm Monday to Friday, AEST time.

4.12Other indicative performance metrics include a server response time of 0.55 seconds, on average, per page request. The average time it take to complete page loading is 3.43 seconds.

PaaS platform

4.13For PaaS sites, ready access to analytics data is not available so exemplar sites are being used. There are approximately 100 sites on the PaaS platform as at December 2017. They have the following average profile:

4.13.110% are very large PaaS sites

  • 3 terabytes of bandwidth per month, some have CDN and edge caching in place, some do not
  • up to 4 million users, 8 million sessions and 24 million pageviews per month
  • average 4,000 concurrent users, peaking at around 9,000
  • 10 gigabytes of file storage and 5 gigabytes for the database is the average, some sites have significantly larger file collections
  1. 50% are medium-sizes PaaS sites
  • 1 terabyte of bandwidth per month, most do not have CDN or edge caching
  • up to 2 million users, 4 million sessions, 8 million pageviews per month
  • average 2,000 concurrent users, peaking at around 5,000
  • 10 gigabytes of file storage and 5 gigabytes for the database is the average, some sites have significantly larger file collections
  1. 40% are small PaaS sites
  • 500 gigabytes of bandwidth per month, almost none have CDN or edge caching
  • up to 1 million users, 2 million sessions and 3 million pageviews per month
  • average 750 concurrent users, peaking at around 2,000
  • 10 gigabytes of file storage and 5 gigabytes for the database is the average, some sites have significantly larger file collections

Pricing scenarios

4.13.4Scenario Baseline – 160(60 SaaS, 100 PaaS) sites at November 2017