The Pensions Dashboards Programme: building an ISP

Here at Heywood Pension Technologies we have been working on the implementation of our Integrated Service Provider (ISP) for several months. 

 

 

The ISP is a service that sits between the PDP Central Digital Architecture and multiple Pension providers. The service accepts Find and View requests from the Central Digital Architecture and returns matching pensions and subsequently, their values and administrative data to scheme members. The components can be seen in the diagram on the right:

In this blog I want to discuss some of the technical aspects of the ISP implementation.

Cloud Hosting – Infrastructure as a Service (IaaS)

There are many compelling reasons for choosing to host modern solutions in a public cloud environment and this is the route we explored for hosting of the ISP:

• Reliability: the PDP requires a high availability of 99.5% uptime. This allows less than 1 hour per week of unplanned downtime. Cloud services are distributed across a number of servers offering resilience should components fail, all managed by the suppliers’ dedicated teams.

• Scalability and Flexibility: services can scale automatically based on demand. When a large number of people access the Pensions Dashboard, for example, following a TV advert at peak viewing time, the cloud environment can seamlessly provide additional resources to ensure we can continue to deliver within our SLAs.

• Agility: by using the cloud we spend less time managing IT infrastructure and more time developing software, which allows us to innovate and deliver value more rapidly.

When we started to look at hosting options for the ISP, we were just starting to consider where we might host one of our other emerging products. We wanted to extend our existing knowledge of public cloud services, so we formed a digital development partnership with experts in Cloud led transformation, Kainos.

Following a lengthy assessment period, working closely with Kainos, we chose Amazon Web Services (AWS) to provide our Infrastructure as a Service environment. Amazon is the market leader in this sector and ticked all the boxes with regards to the services we needed for our ISP solution, including the requirement to ensure all data is UK based.

Infrastructure as Code (IaC)

Rather than having to build physical servers within a data centre, install operating systems and configure databases, all of the infrastructure we require is created with Infrastructure as Code. This gives huge advantages over the traditional methods in cost and time savings, removal of human error and reduction of risk. Should we wish, we can wipe and rebuild our infrastructure, to configure a test environment for example, in a matter of minutes and be confident that it is an exact copy of our development environment.

ISP Design & Development

As an Alpha participant, Heywood are one of the first suppliers to be able to connect to the PDP architecture.

With our hosting environment in place and infrastructure configured to support our ISP and future products, we designed our solution for the ISP following the release of the PDP technical specifications and regular workshops. As well as our Altair customers, we have also designed for non-Altair customers. For both sets of customers, we will have a regular update of personal data to support the “Find” process. This data will be securely encrypted. For the “View” data which includes membership data and calculated values, requirements quickly emerged that led us to design two modes of operation for these data updates: a file based update where we hold all of the information in the ISP, and an API-led option where we go and collect “View” data directly from the underlying pensions administration system.

 

With over 80 Altair customers and many non-Altair providers looking to use our ISP to connect their members to their pensions, we started the iterative approach to develop our ISP solution. We began with what we called ‘Alpha Lite’, a lightweight, subset of functionality required for the ISP that allowed us to test that we could turn the PDP’s requirements into a working solution. Doing so with a cut-down version first helped us solve critical challenges sooner. Then iteratively, more and more of the requirements are then added to this backbone of the solution.

ISP Endpoints (APIs)

An API endpoint is simply one end of a communication channel – a mechanism to allow the PDP Central Digital Architecture to talk to our ISP. Our ISP endpoint will expose three API methods that the Central Digital Architecture will connect to.

• Find: this method will receive Find requests, initiated by the Pension Finder Service and containing the pension owners personally identifiable information data. This will be used to search for matching pensions.

• View: once a dashboard user is made aware that a pension has been found they will have the opportunity to retrieve the details of that pension, including the value data.

• PAT Refresh: allows the Authorisation server to request a new Protection API Token (PAT).

Before any find requests are sent the ISP, the Dashboard users are authenticated and must give their consent for their data to be sent to every endpoint registered in the industry.

What's next?

Last week it was our turn to connect to the PDP test environment and start to expand our testing to the full end-to-end transactions. We will continue to work through the wider requirements with the PDP. Please watch this space for the next update on the Heywood Pension Technologies ISP journey.

If you would like to learn more, please contact us.

 

Ian is a Heywood Product Owner and has a long history of working with customers to create software solutions. Ian is a member of the team responsible for developing the Heywood ISP; his key focus is maximizing value for customers and managing the delivery of the product with a clearly prioritized timeline of activity.