...

Additionally, the application should have the capability to consume external data for some of its parts. For example, PIA, STRA and Risk Assessment documents are 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.

PIA & STRW

Process IntegrationProcess 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.

Build Options

Backstage.io

Service Now

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

Off the shelve

Recommendations

• Decouple front end from the backend

• Develop front end using react