People

For contributors and contacts, see here.

SaaS Catalogue

SaaS Catalogue will be a web-based application used by users to assist them with finding, assessing and procuring SaaS. Users will be able to browser software, see information about the products 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.

In the future, SaaS catalogue will not only serve as a place to see available products, but also as an entry point to the procurement process as well. This will allow SaaS catalogue to automatically track which software is in use by whom.

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.

Filtering

One of the major shortcomings of the current Airtable solutions is content filtering. The default Airtable filtering system provides too many options and is difficult to understand:

New SaaS catalogue should support a simpler, more approachable filtering system, similar to the one below:

With this approach, the user will be able to filter the contents of the directory through a 2-step approach - first by selecting a filter type, and then by selecting from one of the filtering options by clicking a button(s).

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.

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

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.

Ultimately, however, users would like to have an app store experience, such that they can acquire actual software from the catalogue, similar to that of the Software Center. While meeting that exact experience may be challenging given the complexity of the procurement process, app store approach should serve as a model to be followed to the highest extent possible.

Software licenses come in 3 varieties - enterprise (government wide), corporate (ministry-wide) and personal. Enterprise agreements don’t require SaaS procurement process, corporate 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. Note that there are instances where even though PIA/STRA process has been completed within a ministry, it may need to be repeated with some variations for another team within the ministry if they have different requirements. Other factors such as a change in number of users may also require re-assessment.

Other Features

Airtable SaaS Directory UX Research carried out by the SaaS Adoption Team produced a set of features that users perceived as desirable:

• Ability to report bugs

• Ability to search - by title, but also possibly by description

• Searching by tag

• Simple UI

• Search faceting

• Search autocomplete

• Software features listed in bullets, and what they mean in terms of solving business problems

• Product comparison (user have to compare any product over $1000 to other 3 products)

• Dark mode theme

• App store experience - users would like to walk away from the directory with software that’s ready to use, similar to that of Software Center

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 (although additional data sources can be programmed in, see side notes below)

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

Backstage side notes

Backstage POC developed by the Developer Experience team contains SaaS catalogue data that was consumed through a JSON file using custom backstage type (instead of consuming yaml files via GitHub). Developer Experience sees backstage as a tool for developers to access information about software products aggregated from various sources, such as GitHub, but also Copperleaf (DIO application inventory tool), private cloud project registry and common components from digital.gov.bc.ca Strapi API. It is the intention of the system, then, to consume SaaS catalogue products from an external system used by the SaaS adoption team, not to necessarily to have it as a part of the core process. For example, public cloud resources in backstage POC are consumed from Airtable.

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). In addition to the ability to create custom applications, the platform also comes with a broad range of low- and no-code solutions in the form of packages that can be assembled to produce automated workflows.

Presumably SaaS catalogue may be constructed in ServiceNow either in its entirety (frontend and backend), or the backend could be constructed in ServiceNow with an API fed into a custom frontend (e.g. React).

Advantages

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

• 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, if done internally

• OCIO’s provisioning model of the ServiceNow has barriers towards implementing custom solutions (they prioritize simple things such as changing voicemail or requesting a new phone), thus building SaaS catalogue through ServiceNow may take a prohibitively long time.

• Custom functionality is typically outsourced by OCIO and is expensive

• May require purchase of packages to implement some aspects of the system

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 it 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 the entry point to the procurement process and API integrations)

• Building API-first may be awkward

Standalone

The application may be built from using standard technologies such as Node.JS, React, and a SQL database. Since the frontend is developed separately from the backend, and all solutions involve the construction of the frontend (likely standalone React or similar app), primary work will consist in building a robust backend.

The work will consist of building a set of API endpoints for the API-first approach that would interface with a database backend and a management user interface, similar to that of Airtable with any custom features specific to the particular business needs of the project. For this approach, use of open source software may be valuable, such as an open source alternative to Airtable nocodb.

Advantages

• Full flexibility of functionality

• Compatible with any future requirements, provided good architecture

• Front end and back end will be decoupled, giving an option to swap out either one later

Disadvantages

• Takes the most work to develop

SaaS Governance tools

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 while another service Octa provides SaaS governance in combination with SSO integration. For this approach, it is necessary to exhaustively determine the roadmap of the project to ensure the product is capable of meeting desired user needs.

Advantages

• Does not require development

• Support is provided

• May contain additional features

Disadvantages

• May not cover all use cases

• May not integrate with external systems

• May not provide APIs

Airtable Interface Designer

Airtable introduced a way to build custom interfaces without any code through the Interface Designer feature. This feature allows users to create alternative interfaces to the standard Airtable management UI using spreadsheets (see Fig.2). Users can then selectively view specific fields through respective UI elements and also update data in the Airtable backend.

Advantages

• Does not require development

Disadvantages

• Restrictive features may not meet exact requirements

• May not support more complex business needs

• Airtable backend may need to be replaced to support API integrations etc which would cause frontend redesign as well

Airtable API with custom frontend

Another possibility is to use the existing Airtable backend to manage the data and use the Airtable API to build a new frontend with React or some other framework. This approach will provide the best effort-to-value ratio for the end user by deferring the backend work and focusing on the user experience.

Backend improvements can be done incrementally to address acute pain points, while clarifying the full set of requirements to determine whether a brand new backend is actually necessary or can be accomplished using a hybrid solution of Airtable backend in combination with auxiliary tools such as CHEFs and automation scripts.

Advantages

• Does not require building a new custom backend

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

Disadvantages

• Airtable APIs may not be optimally suited to drive all front end features, resulting in additional code to bring data into a desirable format

• 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 and more advanced business processes

• Continued use of Airtable backend may result in an unstable, difficult to maintain system

Recommendations

• Decouple front end from the backend and develop them separately

• Develop front end using React or a similar framework first, while maintaining the current Airtable backend as a management interface

• Fully understand the product roadmap to avoid developing one feature at a time using a system that may not meet final goals, however:

• Assess whether Airtable backend can be augmented to address current deficits related to data entry (for example automating data input from CHEFs), API integrations (for example by running a standalone script to do periodic imports from external systems) and process integration (for example by using CHEFs in combination with automation scripts to drive those processes)

• Determine if available SaaS governance tools are capable of meeting the business needs. Check for the availability of APIs for the possibility of driving the existing frontend using the off-the-shelf product instead of Airtable

• If none of off-the shelf products are appropriate and sufficient developer resources are available, develop a custom backend application and host it on a cloud

• If developing a custom management backend in the future, try to avoid developing the management interface from ground up, instead leveraging existing packages, like nocodb