Imagine you wanted to call a friend to ask for help with a project you were working on. Instead of just pressing the call button in his contact, you had to figure out which phone he had, who his cell phone provider was or what technology his provider used. 

Would you bother making the call if it wasn’t an important one? In a way, this was the case of our time series data: time-stamped measurements coming from devices such as sensors in the field. 

The team started working in 2018 and Erik Aareskjold Idland was one of the main developers on the Timeseries API. While some might take an approach of assigning a bunch of people to “just get to work”, they took another approach entirely.

Flexibility is a key part of why they view their API as their main product - even though they maintain the backend streams and databases that feed the API with data. 

“There’s no guarantee that the database we have today will run on the same technology in the future. Things are always changing, but because of the API we can change everything when we need and users won’t notice a thing,” Erik says.

If they let people connect directly, it would make them a little “stuck” if they want to start using a different database or technology, developer Jan Henrik Endsjø Høiland explains:

Today, the database that gathers and contains all the data is an open source time series database. 

It’s no small-scale operation that’s being carried out when it comes to collecting the data. If we look behind the Timeseries curtain, there’s an exporter running, which connects to 30+ systems to gather data using product specific APIs for those source systems.  

“The exporter continuously exports time series datapoints from different sources, as process historians, into our ingestion pipeline, which then ends up in the database,” Jan Henrik says.

Have you ever clicked a link and it took forever to load the actual website? To put it simply, ain’t nobody got time for that.

That’s why optimizing throughput and keeping the latency down, such as optimizing the delay between a sensor producing a value it’s available to customers is a priority. 

 “It can be a challenge to get the best performance out of the database in every use case since we’re not the ones who develop the database itself,” he adds.

The most recent addition to the Timeseries team is Runar Ask Johannessen. While he might be fresh out of school, he was thrown into the deep end of the pool right away - with more than capable lifeguards close by. Runar specialized in machine learning during his studies and enjoys seeing a different side of things.

So, your API is up and running and ready to provide your users with the data they need and want - time to pat yourself on the back for a job well done and head home? Far from it! What happens outside of developing code API is just as important in an API-first mindset, Steffan Sørenes explains:

Steffan is our leading advisor in IT architecture and a part of the Timeseries API team, where he’s a “part time salesman”, as the team puts it. Pitching the product and getting hold of “customers” isn’t a part of the job you should take lightly - just like you should give new users a proper welcome.

“We run a 30-minute onboarding session for every new client, where we walk them through documentation and how to use the API. But we also tell them to give us any feedback they may have, both what needs improving and what works well,” Steffan says.

“Their feedback together with constant monitoring and logging gives us insight into how our users actually use the API - or what they don’t use. It lets us be proactive in how we improve the product,” he adds.  

The perhaps biggest user of their API is Equinor’s own Integrated Operations Center (IOC), which features daily monitoring of equipment and assisting in more long-term support for production optimization and energy efficiency. 

IOC developers Harald Kjøde and Jo Lyshoel explains that the Timeseries API makes their work a whole lot easier: 

“Not only can we easily add more data sources through their API, but it also makes collaborating with external partners much easier,” Jo Lyshoel adds.

One of our external partners is 4subsea. Their industrial IOT data storage and analytics platform 4insight® gathers data from sensors and other systems and adds analytics to create insight. 4insight includes data connectors configured to communicate with various external APIs - making it possible to adapt to different clients’ infrastructure.  

Their 4insight® platform gathers data from sensors and other systems and adds analytics to create insight. By connecting the APIs, they can share data and insights which contributes to empowering Equinor’s engineers to make informed critical decisions.

But work is far from over and the team is currently working on getting data from our wind farms into the service, as well as looking into ways of expanding and improving their API.

While in Equinor the strategy is to always think of the API first, the Timeseries developers all believe that this is something everyone should consider - especially if there’s a chance that it isn’t just one single person or frontend that can make use of the data. This approach makes it much easier to create value out of what you’re making, Jan Henrik explains. 

So, if you’re working on a software project both big and small, APIs are the way to go - especially if you want to make life easier for your users. 

With that, our little venture into the world of timeseries data and APIs is over. But make sure you subscribe to our Loop newsletter, and you’ll get a notification swooshing into your inbox as soon as we publish a new story.  

Until next time, stay safe and take care!