SmartStart: a federated service life event story

SmartStart

SmartStart was the first “life event service” to be delivered by the New Zealand Government. The project set out to make it easier for New Zealanders having a baby to navigate their way around government services and to access services in an integrated manner. The web application was released on 5 December 2016, providing information organised around a timeline, and access to three integrated services through birth registration. SmartStart is overseen by a diverse stewardship group with representatives from four government agencies and two non-government organisations.

SmartStart technology underpinnings

SmartStart was developed by a cross-agency service delivery team in Department of Internal Affairs (DIA) in partnership with Catalyst. The product was supported by the Service Innovation programme team from DIA. SmartStart was built on a modern technology stack that makes it flexible to change, functionally extendable and able to integrate with other government services for a better user experiences. Development takes a microservices approach. It is a good example of how taking a federated approach can drive benefits for users, for agencies, and for the whole system.

A “Federated Services Model” reference architecture preceded SmartStart to try to encourage a more integrated approach to delivering government services in a whole of system way. The model broadly encourages modular API-enabled architecture with reusable components where there are common requirements, driving systemic improvements and thinking. Beyond the documentation however, there was not a significant amount of reference implementations or technical support in how to practically apply the reference architecture.

Decisions made

Decisions around SmartStart (especially architecture and technical decisions) were made with the best information available at the time. SmartStart received sign off from the relevant DIA technical and security governance boards before release, which provided assurance and oversight to the technical decisions made.

When the SmartStart service was designed, there was some debate about the best way to meet the reference architecture.It was decided to develop the first iteration of the service on a new development platform rather than existing government web infrastructure such as Govt.nz, which is built on the New Zealand Government's Common Web Platform (CWP). CWP offers an integrated approach, but is not currently enabled with a microservices approach. Generally speaking, shared services or platforms are great for efficiencies within government but not conducive to a wide range of external service providers building new services, products or value, unless they are API platforms.

The design did seek to draw on reusable content and other APIs where possible. The very first iteration required a migration from simple content on web pages to modular content enabled by an API. The Govt.nz team were able to both initially support the modularisation of relevant Govt.nz content, and deliver the content capability via an API (i.e a federated solution) for the required content for SmartStart.

Aligning with the bigger vision

Other aspects of SmartStart that align with the vision of integrated services include:

• Cloud-based service with automated environment creation.
• Seamless RealMe login, built modularly so that others could use it to manage a simple customer profile.
• Django-based framework of APIs for dynamic front end. SmartStart's React.js is currently taking a responsive approach, but this could be dynamic.
• Used the concept to take a modular design approach to the platform specifically to be able to scale, and mix and match into the future.
• Transactional APIs are being integrated from DIA and other agencies on an ongoing basis, as per user need prioritisation and availability of those APIs.
• Reuse of components in two other products (Discover service and Te Hokinga ā Wairua - End of Life Service).

APIs used in the service today (with more coming):

• Preferences API for storing data
• Traditional authentication mechanism API
• Interacts with the Birth Register Online (BRO) API, which is built to seamlessly integrate with SmartStart
• SmartStart-relevant content from Govt.nz coming in as an API. They started with some static JSON to start and then was able to consume from Govt.nz directly. (Govt.nz as a service for content). There was a good relationship with the content experts at Govt.nz which was beneficial.
• Piwik web analytics through an API, allowing user journey mapping.
• Frontend and backend of SmartStart are separate, enabling rapid frontend iteration, similar to the MyMSD model.
• The Family Services Directory published by MSD has been transformed into a machine-readable CSV hosted on data.govt.nz to generate and use the CKAN JSON API.

Reuse of the ecosystem

As the SmartStart infrastructure was designed from the outset to be a platform that could accommodate future Life Event services it was able to be reused and extended for the End of Life service, launched in June. Any enhancement built and rolled out for one service on the platform automatically becomes available for other services. This has meant that the services.govt.nz platform build for SmartStart has been continuously improved. (For background about Life Events, see the Easier Access to Government Services page on ict.govt.nz.)

The existence of this platform means that future services can be built to take advantage of the robust existing infrastructure so that more resources can be directed to building the service itself rather than on bootstrapping its infrastructure. The platform is not prescriptive about the technology used to build those services and demonstrates the capability to run heterogeneous technology.

There has already been cross-pollination of capabilities across the life event services. This lowers the cost to develop new customer-driven features that are consistent across the range of life events that customers experience.

Technical lessons learnt

A “technical debt register” was prepared quite early in the SmartStart journey to try to capture lessons learned for subsequent life event services and to track anything that should be considered moving forward. The register suggests a more API-driven approach to transactional or content/data services. This recommendation is being implemented through continual improvements made since SmartStart was launched.

Some good technical lessons came from the experience. Firstly, government processes often simply don’t support the speed of modern agile service design and delivery. Things like changing names (and confirming DNS domains), design approvals and other decision making was too slow for the rapid pace of modern service development. This mismatch cost significant time, money and churn.

Conclusion

Catalyst built a secure, modern, modular and robust service which uses best practice technical and architectural approaches for the requirements provided, based on customer needs and sound service design mechanisms. This message gets lost whenever there is any discussion about SmartStart “not aligning with a preferred architecture approach” when it has actually been a good exemplar for designing and developing future services. The services are integrated, extendable, resilient and responsive to changing user needs over time.

The SmartStart team were focussed on building a customer-centred service that could be responsive to changing customer needs. This required a more modular infrastructure than existed at the time. The priority of the SmartStart team was to deliver value for users quickly, and backfill as required, rather than trying to boil the ocean in one go. As far as we can see, the approach taken got the balance right in delivering value in a timely manner through prioritising user needs, but building on a modular, extendable and integratable architecture that could be improved over time.

Finally, both the SmartStart and Catalyst teams involved have agreed to open source as much of the infrastructure components as possible to support reuse and to provide a reference implementation for federated services developed by service delivery teams in other agencies.