It’s fair to say that “what is a cube anyway?” is one of the first questions people ask us when we are pitching Digital Place and the idea of reusable cubes. In this blog post Gavin Beckett, Placecube’s Chief Product Officer, sets out the core concepts of cubes, their features and how they help councils reduce cost and speed up delivery of well-designed digital services.
In my previous blog posts, and our pitches over the last two years, we’ve talked about Placecube’s take on the idea of “Lego government” – the idea that it’s time to move beyond closed proprietary monolithic systems at one end of the spectrum, and coding from scratch every time at the other end, to a place where reuse of modern, internet age, digital services built on open standards and open APIs enables the public sector to stop reinventing the wheel for the things they do in common.
At their simplest, Cubes are packages of programming code that are deployed as a single unit to meet a defined purpose or user need – a building block for a joined up digital experience. They are based on a modular approach to programming and could be constructed using a microservices architecture, but could also be implemented in a coarser grained “traditional” modular framework like OSGi – which is the approach Placecube use to build Digital Place. So cubes are composed of one or more atomic modules that use services to communicate with each other, through published standard APIs, hiding their implementation details.
One of the benefits of a modular approach is that we can deploy new cubes into an existing SaaS instance of the platform without needing to take down the whole service. Customers can then hook up the new cube with other components of their Digital Place instance through the standard APIs – so for example if Dorset chose to adopt the View My Council Tax Bill service that Greenwich co-designed and developed with us, they would just swap out the payment connector and the back-office system connector cubes for their specific systems.
Many Cubes are designed to provide commonly used features like content management, document management, search or case management. We call these feature cubes. We have also produced a set of Service Cubes – these bundle together a combination of feature cubes to produce the user experience, business logic and interfaces that have been designed to provide a service which meets a user need. Service cubes are constructed based on the needs uncovered in user research, as we work with our local authority or business customers to build a specific service they need to provide to their users. They can be anything from the View My Council Tax Bill example mentioned above, to Report a Housing Repair, or the Apply for a Taxi Licence cube we are building with Lewes & Eastbourne.
We build Service cubes in line with public sector digital service good practice: the Government Digital Service Standard, and the Local Government equivalent – the LGDSS. Our Service Cubes have been built with councils that work in ways that align with these standards – starting with user research, designing the service, prototyping and testing an Alpha, thinking about how to manage if the service is offline, and releasing incrementally and iteratively.
We design cubes to be reusable, configurable without re-coding to suit local requirements. A good example is the way that our Service Cubes for things that need location data can be configured to use a variety of different integration cubes that all lookup postcodes in a council’s Local Land and Property Gazetteer, but using different implementations – from the Ordnance Survey Places API, through system APIs provided by suppliers like ESRI, or by reading a DTF7.3 data feed. In this way, councils can reuse a “Book a Bulky Waste” service and simply reconfigure where the integration goes. And because each integration connector we build is also implemented as a reusable cube, councils have the control to migrate from their legacy systems to new ones without paying us for existing connectors – as an example, they might choose to switch to using the GOV.UK Pay connector instead of our connector for Capita’s Pay360 payment system – any digital services they have built simply need the payment field configuration updated to point to the new connector.
Councils can swap out integration cubes for their different back-office systems
Because Cubes can access the other services of the Digital Place platform, they can also expose data about their usage, enabling tracking inside the Analytics cube, or extraction through an open API into the customers own BI system.
Service Cubes are designed to implement common service patterns that meet user needs, with a customisable user experience. We think that good user research should uncover needs for service outcomes that people hold in common as human beings, and that good service patterns can be designed so that most people across the UK will be able to use the digital services we build to meet those needs.
Once we understand how to describe bins, how people expect to interact with payment services, what helps people to understand how to upload a document, or how best to ensure people can give active consent for data capture and processing, these patterns can be used across services and across organisations. If these common service patterns have been informed by collaborative user research across multiple organisations – as is the case in the Local Digital Fund projects – then we would expect them to be even more reliable as guides to what works well in the UK.
We have implemented a style guide and pattern library for our Cubes that reuses the GOV.UK Design System wherever possible, and most of our customers are choosing to adopt that for the user experience. That said, we recognise that each local area may have the need to configure content and visual design elements to fit local language or branding differences – and Cubes are designed to make this easy. You don’t need to commission consultancy from Placecube to edit the content or styling of your services.
So far, everything I have described is about Cubes built inside Digital Place, as collections of OSGi modules. But this isn’t the only way to build Cubes. We want to ensure that Digital Place operates as an open ecosystem – and that means supporting code that’s built in other languages, outside the core platform, but that can talk to the services it provides. This relies on the native support for OpenAPI in Digital Place, and the ability to wrap web apps built by other organisations in popular JavaScript frameworks like React, Angular or Vue in such a way that they can be deployed as widgets alongside Cubes we’ve built ourselves.
We believe that this open, modular, standards based approach offers local public services a real difference – and our growing number of customers seem to agree!
In my next post we will look at how this approach to providing open source reusable cubes on a SaaS platform is being used in one of the Local Digital Fund Round 5 projects.
