Implementing Government-as-a-Platform in Massachusetts

CIO / EOTSS Policy memo to the Office of Governor C. Baker

Disclaimer: this memo was written as an assignment for the DPI-662 class ‘Digital Government’ taught by David Eaves at the Harvard Kennedy School of Government

Government-as-a-Platform (GaaP) is the necessary, bold next step to improve public service efficiency, unlock innovative solutions and make Massachussets a frontrunner in Digital Government by 2020. As starting points, CIO recommends creating an authentication product and a citizens’ registrar.

1. Context & Motivation

• The State of Massachussets, historically ranked average for its digital government performance, has significantly improved its online presence by redesigning mass.gov in September 2017, relying on strong user-centricity and data-driven principles. Encompassing MA’s 100+ agencies under one umbrella website was vital and well delivered.
• To create the additional online services targeted by our Phase III for mass.gov, we shall give to Departments, private & public entities, and citizens a digital field, or “platform”, with building blocks with which they can create their own innovative online public services at reduced cost and development time ; like highways enable buses, ambulances and truck activities to develop. Called ‘Government-as-a-Platform’ (GaaP), this approach departs from the mere digitization of existing public services and has been deployed in the UK, Estonia and India.
• Based on UK feedback, the following benefits are expected from any GaaP implementation: simpler development & testing of innovative public services; efficiency gains by reducing duplication of efforts (e.g. with unified databases) and errors; enhanced cooperation between formerly siloed departments; personalised and more frequent relationships with our constituents. On top of these benefits, Massachussets would also be the first US State to implement GaaP.
• Apart from login.gov unique online identification system, there is no ongoing competing GaaP project at Federal level/USDS, nor at City level to our knowledge, that would cannibalise or duplicate any GaaP initiative in Massachussets.
• So GaaP experimentation is highly recommended.

2. Vision of a Massachussets GaaP

• Massachussets GaaP would provide departments, public & private partners distinct tools/products per digital layer: (1) at the application/activities layer, we would provide (1a) unified applications for tasks or services previously duplicated across departments (e.g. payment, notification/outward messaging, authentication) and (1b) tools to unify and simplify the development of applications by departments themselves: cloud hosting services, code elements, UI/UX friendly front-end solutions (like a Government wordpress); (2) at the data layer, we would manage united databases that are used by various departments, containing up-to-date information accessible through APIs, the registrars (e.g. population, geographical database).
• Even though GaaP is an emerging approach to Digital Government, some best practices shall be adopted: (i) build simple, transparent and open systems (accepting feedback and code/rules editing), with common languages/formats (e.g. Python, JSON, CSV); (ii) start by creating ourselves a strong and appealing feature; (iii) be open to experimentation and adjust products based on data.
• All stakeholders shall be represented in Massachussets GaaP governance at each layer with no unilateral power granted. A GaaP Supervisory Board shall include representatives from Governor’s Office, the Office of the State Auditor, the House Committee on Technology & Intergovernmental Affairs, EOTSS, key private subcontractors notably for cloud services (e.g. Amazon if AWS) or Federal services providers (ex VitalChek for life records), mayors and independent members from the civil society (e.g. academics). In order to avoid bottlenecks, GaaP developments conducted by departments shall be reported to Supervisory Board, but no validation shall be required. Any Board Member can call a vote if he/she expresses doubts on a particular development, and a 2/3 Board majority can reject the development proposed or usage of data & services by GaaP stakeholders. This scheme consequently prevents cloud services providers from reusing public data for its own purposes, and from modifying the services.
• On a day-to-day basis, GaaP should be managed by MA Digital Services teams, comprising designated 2–5 GaaP products managers (estimate) and leveraging existing capabilities, notably for UI/UX design and data science. Following Estonian’s X-Road model, registrars shall be put under the responsibility of one Department.

3. Implementation Roll-out & Next Steps

• Accordingly with best practices, MA Digital Services should start by pushing their own first GaaP product. Product selection should prioritize (i) existing duplicated services to be unified across departments, in order to involve all Departments from scratch (payment, authentication…); (ii) services with existing high demand to have high impact (top popular searches on mass.gov include drivers’ licenses renewal and fishing permits); (iii) products requesting low technology & roll-out costs — to reduce overall costs of experimentation and hypothesis testing (i.e. start with resources sharing rather than additional services like cloud hosting services); (iv) products/services that can easily attract future interest from other public & private players, in order to trigger innovative services; (v) products which require establishing GaaP on two layers (like data & application) so as to prove by example the benefits of an integrated application/registrar model; (vi) products that can be developed rapidly.
• From all the criteria above, the creation of a citizen registrar merging existing permits, housing and other legal databases is recommended as starting point, and should be coupled with a unique identification application for each citizen across Departments.
• The pilot registrar/identification mentioned above shall be completed in no less than 6 months. The first MVP, to be issued rapidly (e.g. 1 month) should be simple (i.e. just uniting two databases released in CSV format, like fishing permits and IDs, and creating a unique authentication for the services), so as to let also the system evolve. It will then be the responsibility of each Department to connect to the Population Registrar to update its digital services.