People

Daniel Hirner - Senior Product Owner, SaaS Adoption Team

Bahaa Harmouche - Service Design Lead, SaaS Adoption Team

Rebekah Ford - Scrum Master, SaaS Adoption Team

Daniel Surdu - Senior Security Architect, digital STRA

Bethany Frei - Manager, digital PIA

Andy Teppin - CITZ Service Now contact

Stephen Gidden - CSAM - interested in Service now for Software Asset Management

SaaS Catalogue

SaaS Catalogue will be a web-based applications used by users to assist them with finding, assessing and procuring SaaS. Users will be able to browser software, see it’s information such as price and description as well as see which ministries and individuals already have subscriptions.

Access to existing subscriptions will allow users to see who has already gone through the process and which documentation has been previously fulfilled. Documentation includes PIA, STRA, SOAR and Risk Assessment.

Airtable

Current SaaS directory is built with Airtable. First level of catalogue lists SaaS options that are in use in the government.

The directory is managed through the Airtable management interface through a series of spreadsheets:

The details view for an individual SaaS product contains details for the product such as description, categories as well as links to Subscriptions and Compliance Assessments views.

When user clicks the subscriptions link they are taken to the subscriptions view page that contains a listing of the subscriptions across government ministries for that product:

Clicking on the compliance assessments link takes user to listing of available compliance assessments, these have linkages to the appropriate subscriptions.

Compliance assessment details reveal information about PIA, STRA and legal review status, among other things.

Users can contribute to the catalogue, by filling out a CHEFs form. The information from this form must be copied over manually to Airtable. Submission is 3 step process consisting of product information, subscriber information and compliance assessment:

Requirements

PIA, STRA and Risk Assessment System Integrations

Application should have the capability to consume external data for some of it components. For example, PIA, STRA and Risk Assessment documents will be processed externally in their own systems. When a document gets filed in one of those systems, it would be desirable that it appears automatically in the appropriate section of the SaaS catalogue.

Updates tracking

SaaS software frequently undergoes changing, such as subscription model, price, privacy updates etc. This may cause PIA, STRA and Risk Assessment documents to become out of date. Thus there needs to be a mechanism to find most appropriate and most up to date documents for the current version of the software.

API First

To allow integrations with other systems, SaaS catalogue should be built with an API-first approach. All CRUD (Create, Read, Update and Delete) operations should be performed through an internal API with a future possibility of opening that API to external systems, if necessary.

Process Integration

Currently the data collection process for the catalogue is cumbersome and requires research and manual data entry to function. Additionally, catalogue serves only as an informational resource for the users and is not a functional part of the actual procurement process.

To simplify data collection and to keep track of all of the applications, it would be desirable for the user to use the SaaS catalogue as the entry point to the procurement process. For example, if the software the user is interested in is not listed in the catalogue, they may submit a new application that will instantiate that application in the catalogue and will make them the first subscriber.

If, on the other hand, the application is already in the catalogue but the user’s ministry has not gone through procurement, then by applying through the catalogue their subscription will be added to the existing application listing.

Additionally, when users submit new subscription application, this should trigger the application in PIA/STRA/Legal Review systems as well.

Software licenses come in 3 varieties - corporate (government wide), enterprise (ministry-wide) and personal. Corporate agreements don’t require SaaS procurement process, enterprise agreements make software available for the whole ministry and need to be done only once, while personal agreements are done on the one-off basis.

Build Options

Backstage.io

Backstage is a platform for creating developer portals. One of the features of backstage is a software catalog. Software catalog is built from yaml files that are typically stored with the source code of software that is pulled in by Backstage from GitHub.

SaaS catalogue items may be registered in the software catalogue and a UI may be built using React or similar approach by consuming the backstage API

Advantages

• Software metadata is managed through GitHub, allowing for version tracking and external systems integrations

Disadvantages

• Complex data relationships may be difficult to replicate

• No visual interface to publish updates - needs to be source controlled

• Would still need to build a UI since backstage UI is not user friendly

ServiceNow

ServiceNow is Application Platform as a Service (APaaS) that allows users to create IT process automation products. One of the features of the platform is the ability to create applications. The applications are written primarily with JavaScript and some version of a SQL database. Of note is that digital STRA is currently implemented using ServiceNow (Daniel Surdu).

Advantages

• Integration with STRA process may be simplified due to the co-existence on the same platform

• UI development may be simplified do the low-code approach to the application building

Disadvantages

• Will require developers learning how to develop in the new environment

• User interface will either be built into ServiceNow or will still have to be constructed separately using APIs

WordPress

Given that currently digital.gov.bc runs on WordPress, SaaS catalogue could be developed as a plugin. Gravity Forms may be leveraged for user input and new submissions mapped onto custom post types. Authentication may be accomplished with MiniOrange plugin to provide IDIR login protection. Once the custom post type is created, it exists in a draft state until an administrator verifies the information and publishes the post, causing to appear in the catalogue.

The front end can be accomplished using some JavaScript framework, such as React or Vue. Data can be consumed via a REST API endpoint exposed through the standard WordPress mechanic.

Advantages

• No need to deploy and maintain a separate application.

• Leverage plugins ecosystem to perform some of the functions.

Disadvantages

• Application won’t be standalone and require WordPress to run

• No choice for backend language - will have to be PHP

• May not be appropriate for more complex future functionality (as entry point to the procurement process)

• Building API-first may be awkward

Standalone

The application may be built from ground up using standard technologies such as Node.JS, React, and SQL database.

Advantages

• Full flexibility in functionality of the app

Disadvantages

• Takes the most work to develop

• Need to maintain the application on OpenShift

Off the shelve

It may be worth exploring what type of off-the-shelf software is available that could support the business case. For instance, Service Now includes a SaaS license Management product.

Advantages

• Requires least effort

Disadvantages

• Likely won’t cover all use cases

• Likely won’t integrate with external systems

• Likely won’t provide APIs

Airtable API with custom frontend

Another possibility is to use the existing backend together with it’s administrative interface for managing the data and use Airtable API to build a new frontend with React or some other framework.

Advantages

• Does not require build a new custom backend

• Decouples front end into separate project - can connect it later to a different backend

Disadvantages

• Requires continued Airtable subscription

• Backend features might be restricted by the platform and cause issues with more advanced features, like API integrations with external services, such STRA management system

Recommendations

• Decouple front end from the backend

• Develop front end using react or similar framework

• Try to avoid developing management interface from ground up, leverage existing packages, like nocodb or build an interface in Service Now

• Given that STRA, PIA, and legal review systems don’t yet exist or have APIs, it’s advisable to construct these parts of the SaaS catalogue as standalone virtual microservices that can later be swapped for actual APIs