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.
Requirements
API Integration
To allow integrations with other system, 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.
...
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.
...
Requirements
PIA, STRA and Risk Assessment System Integrations
Application should have the capability to consume external data for some of its partsit components. For example, PIA, STRA and Risk Assessment documents are 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.
...
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.
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
...
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
...