Smart is the buzzword of this decade. There are smartphones, smartwatches, and even smart TVs… but there’s still a lot of things that aren’t smart. Take energy — why can’t we measure our usage habits, charge home batteries during off-peak times, or produce our own energy to share with neighbors when they need it?

These are just some of the possibilities in a future of connected energy, which First Utility, the United Kingdom’s biggest challenger energy and broadband provider, is working towards. APIs are shaping up to be a crucial element in this connected energy future, so at our 2018 Platform Summit in Stockholm, we invited Anu Shahi, the First Utility Head of Engineering, to tell us a bit about their success utilizing an API and microservice architecture.

First Utility and the Energy Switching Experience

First Utility energy monitoring portal utilizes back office APIs. Taken from Slides

To give some context, First Utility was founded in 2008. With the UK energy market dominated by the “Big 6” — British Gas, EDF Energy, E.ON UK, npower, Scottish Power, and SSE — it wasn’t until 2012 that interest in First Utility picked up. Over the course of a long six years, First Utility managed to find the right product-market fit and have grown a user base of over 800 thousand active customers.

Naturally, this has raised some challenges from the business perspective. For starters, there was the issue of building an encouraging energy switching experience to help onboard new customers. Most of this was achieved just by offering competitive prices (compared to those of the Big 6), and at the time First Utility’s tech included a bulky, monolithic PHP web app and not a lot more.

Of course, they needed to take basic orders for energy, take payments, and process the requests. This included a few front office APIs, especially for signing-up new users and determining the pricing, which would relay data to the back office APIs by means of an event orchestration layer. Then, those backend APIs could take charge of order processing, billing, and payments.

Baby Steps with Energy Management

The next stage in First Utility’s journey was that of energy management. Now that users could sign up for the platform and power their houses, it was time to focus on customer satisfaction (which has always been a key point for First Utility) and “serve customers effectively”.

This meant creating pretty mobile and web apps that customers could use to read their bills and submit meter readings. Again, APIs were crucial for making this work. It was an API gateway that controlled interaction with the back office APIs, and, as was standard for the time, the various apps would simply authenticate via the gateway, obtain their tokens, and then call into the back office APIs for the data they needed. Unfortunately, security measures were somewhat primitive with a focus on just API keys, and only then did they move to use OAuth 2.0.

Finally, in terms of user identity, which was increasingly important data given their customer-centric approach, First Utility had employed LDAP as a rudimentary credential store.

First Utility uses fine-grained mapping for microservices, with an outlying gateway for clients to consume. Slides

Lift-off by Energy Engagement

Now it was time for energy engagement. First Utility needed a platform where their growing user base could better engage with the service — somewhere customers could “make energy visible” and more relevant to themselves, such as seeing what time of day they were using the most energy.

You guessed it, this was too driven by APIs (and to an extent, analytics). Their research found that customers best engaged with the data when their energy usage was compared to others, so First Utility built a comparison feature for similar homes. This called for advanced analytic models to match up similar households, with machine learning even coming into the equation. It was the APIs on top that helped bring this data to the users.

For the platform itself, containers had been gaining popularity, so they moved the architecture away from virtual machines and into lightweight containers, packing functionality up in what could be called microservices. Some examples of these services included individually built modules for smart meter management, energy usage, and similar home comparisons.

And as a nod to the power of microservice architectures, this structure allowed them to move from their scrum-style releases every three weeks to pushing out changes four or five times a week and more.

The identity model enables the platform to scale for other energy-related services. Slides

Broadband and First Utility

It was January of 2016 when First Utility decided to launch their broadband services, which they consider their second core product (with 50 thousand active users). A big concern was whether there was anything to digitize in the status quo for broadband servicing, but with some more product-market fit they had found another niche.

At the time, users’ identities were tied to their energy accounts. Since energy and broadband were two very different services, a new challenge was to decouple these distinct identities. The end goal was to create a model for user identity that could be connected to a network of various related utilities, assets, and appliances (such as electric vehicles or battery storage).

To create this complex model, Anu helped design a graph data structure with DataStax’s DSE. One thing led to another and First Utility walked away with their Digital Identity Management API to facilitate the connecting of customers to new services. This was stitched together with a digital identifier, which would authenticate mint tokens once and for all, so that every API call could be associated to the relevant customer.

At this point, First Utility made the move to a central IDP (identity provider) — in this case, Curity. It was time to do away with the API gateway and replace everything with individual OAuth clients. They chose to embrace OpenID and started storing credentials on Amazon’s Aurora as part of a move towards using the cloud. Needless to say, they were happy with the results.

Benefits of Curity

Anu had definitely become a Curity fan, and he commented on some of the reasons why in his presentation. It’s built on open standards (like OpenID Connect, OAuth 2.0, SCIM); it’s flexible (allowing First Utility to mint tokens and use whatever backing stores); it’s operationalized (so you can deploy changes straight into Curity); and it facilitated integration hooks (meaning they could listen for customer events and hook into them).

Funnily enough, the whole First Utility-Curity collaboration took place over Slack, and it’s only been at our Platform Summits that the teams have had a chance to meet!

A Connected Energy Future

Looking to the future, Anu says the “energy landscape will change [over the next 10 or 20 years]” towards a shared and connected infrastructure of energy assets and appliances. He hopes the identity and API model he outlined will allow First Utility to grow with this trend and connect customers’ energy so that some of those possibilities we outlined in the introduction to this article — and more — might one day become a reality.