People
...
Contributors
Alex Struk - Senior Full Stack Developer, Digimod
Allieren Ward - Senior Content Design Lead, Digimod
Arlen Tees - Product Owner, SaaS Adoption TeamDigimod
Bahaa Harmouche - Service Design Lead, SaaS Adoption Team
Daniel Hirner - Senior Product Owner, SaaS Adoption Team
Nia King - Web Content Strategist, Digimod
Nate King - Front End Developer
Rebekah Ford - Scrum Master, SaaS Adoption Team
Shea Phillips - Product Owner, Developer Experience
Contacts
Daniel Surdu - Senior Security Architect, digital STRA
...
SaaS Catalogue will be a web-based applications application used by users to assist them with finding, assessing and procuring SaaS. Users will be able to browser software, see it’s 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:
...
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.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 enterprise (government wide), enterprise corporate (ministry-wide) and personal. Corporate Enterprise agreements don’t require SaaS procurement process, enterprise 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.
...
Build Options
Backstage.io
...
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
UI development Development may be simplified do the low-code approach to the application building
...
Will require developers learning how to develop in the new environmentUser interface will either be built into ServiceNow or will still have to be constructed separately using APIs, 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.
...
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
...
The application may be built from ground up 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 build 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 in functionality of the appof 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
Need to maintain the application on OpenShift
Off the shelve
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
Likely won’t May not cover all use cases
Likely won’t May not integrate with external systems
Likely won’t May not provide APIs
Airtable API with custom frontend
Another possibility is to use the existing backend together with it’s administrative interface for managing 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 build building a new custom backend
Decouples front end into a separate project - can connect it later to a different backend
...
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 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 similar framework Try 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
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 management interface from ground up, leverage existing packages, like nocodb or build an interface in Service NowGiven 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