Platform Service Design
Platform Service Design describes how the GaaP (Government as a Platform) model relates to and can become a component of the main Service Design methodology.
Platform Service Design describes how the GaaP (Government as a Platform) model relates to and can become a component of the main Service Design methodology.
The core principle of GaaP is the modular approach to interconnecting Government services, achieved through API integrations.
So the essence of Platform Service Design is a similarly modular approach, a modeling overlay that envisages different organizational possibilities if built upon API exchanges.
A great example is IEG4’s Blue Badge module, an application workflow developed to implement a specific UK Local Government requirement, and accordingly ties in with the central systems required to facilitate that requirement, such as Gov.UK Pay integration.
Thus Platform Service Design is a process of two steps: 1) Value stream mapping: Identifying cross-cutting workflow steps, and 2) Integrate via API Platform.
This sets the scene for the concept of “Lego Government”. Rather than the traditional approach of building Government services via dedicated line of business applications, they are created via coupling together modular components.
Pathway Design System – Atomic Service Design
One pioneer of the Platform model is the Scottish NES Digital Service, building out that approach for Healthcare apps.
Very helpfully they also document an innovative design process for mapping service requirements on to the platform, through their blog on Service Patterns & the NDS Pathway Design System.
A service pattern is a repeatable design solution for a common problem, designed on standards of ‘what good looks like’.
Service patterns in health and social care are sets of practical guidelines for building services (or bits of services) that are repeated across the sector – something like getting a referral, being informed of treatment options, getting discharged.
API Gateway Platform
The API Gateway Platform is the principle design and technology implementation for facilitating this type of data exchange and systems integration. It’s often a mix of standards and vendor tool selections.
Underpinning the business logic and service design layer the core technology architecture is the API Gateway platform.
Value Journeys
Value Stream Mapping will identify business processes that span across multiple departments and organization, in terms of data flow required to facilitate transactions. A simple example, retail stores that process credit card payments using their tech.
In government there is a highly developed web of these types of interdependent relationships, particularly around eligibility – Your status as being on Universal Income may later influence what services you can access, how much you pay for them and so on.
This PublicTechnology interview explores in detail how the DWP are working with APIs. For example when the NHS undertakes a real-time check for prescription charge exemption they call the DWP passport benefit API which validates the enquiry.
They also perform this check for the Department for Education for free school meals entitlement and for local authorities for the disabled Blue Badge award.
Microservices
They make the critical point that they endevour to reuse existing APIs wherever possible, and where they don’t they develop them via ‘microservices‘ – Small snippets of code intended only for this purpose. This enables very rapid solutioning, only four weeks in some cases.
As the DWP describes:
“Once we identified – or built – the API that met the requirement, we deployed it onto our current shared API Gateway which was already hosted in our internet-facing cloud. This meant that all the infrastructure was already in place so, once the API was tested and proven to be suitable, it could be deployed really easily through the existing shared infrastructure. Historically, the process of building the underlying infrastructure could take months; we deployed new APIs, or extended throughput on existing APIs within two days. This would not have been possible without the API Library or the shared API Gateway.”
Hosting their API gateway in a cloud environment allowed the team to scale up in near real-time, after completing assessment of forecasted API volumes. This microservices approach will build the pathway towards the future, with the hope that eventually they will be able to “join up services across government and one initiative is that we’re creating a central cross-government API Registry that will enable us to share what APIs we already have available, as well as being able to see what APIs other government departments have available.”