Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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.

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.

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.

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

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.

  • No labels