Shaping the future of Equinor IT
Here’s how microservices, cloud-native apps, open source and API’s have shaped Equinor IT in the last four years. Plus, how Industry 4.0 and the Internet will shape the next.
When shaping the future of energy, we need a clear direction in how we’re going to do it – and IT is no exception. That’s why our Chief Engineer IT is tasked with building and implementing the directions we want to take, together with leading advisors, networks and employees.
This February, Knut Erik Hollund stepped down from the role after his four-year tenure as Chief Engineer IT. We figured that would be a great starting point to showcase where we’ve been heading these last years - and where we want to go.
“For us, moving away from monoliths and into a cloud-native world has been the focus for the last four years,” Knut Erik says.
“There are trains constantly leaving the station, and if we’re not on board we might not be the ones that shape the future of energy. Having this sense of urgency does make you worry, but it’s also healthy. It means you have a need to move forward and get things done.”
Knut Erik Hollund
Keeping up with the fast-paced world of tech is no easy task, but there really is no alternative. Ray Kurzweil’s law of accelerating returns tells us that “the history of technology shows that technological change is exponential, contrary to the common-sense “intuitive linear” view. So, we won’t experience 100 years of progress in the 21st century — it will be more like 20,000 years of progress (at today’s rate)”. Not capitalizing on this incredible evolution will mean we fall behind.
So, how are we going to make sure we’re able to keep up speed and be able to iterate and develop software quickly? Let’s take a look!
Stay in the Loop
From monoliths to microservices
In Equinor IT, we take an agile approach to what we do. This means we learn, fail, develop and most important of all iterate quickly. Doing this on monolith’s, however, can be a real pain. Since it’s large software with everything it does bundled into one, it’s difficult to iterate without having to push updates for the entire thing.
“Some might call them legacy software, but I don’t think that’s a good term. They’ve served us extremely well, and some of them still do, but we won’t be able to do what we want and need with this monolithic approach,” Knut Erik explains.
“Moving away from monoliths towards cloud-native microservices has been and will be one of our guiding principles. This will enable us to develop applications we need that scale and adapt to a user’s needs more easily.”
Knut Erik Hollund
The tech giants among us are all working in this cloud-native approach with a world of microservices: small specific software that caters to a specific task that together with many other microservices make up a product. If we look at Spotify, the playlist you see is a specific service that handles everything you do with your playlist – and nothing more. The result is Spotify runs on several microservices.
“You might think that more moving parts make for more problems, but it’s the other way around. Thanks to API’s, they communicate with ease and if there’s a need for the software to scale from 10 to 1000 users it all happens automatically,” Knut Erik says.
All about API's
As applications and the Internet will take a much bigger place on stage in the years to come, most of us will soon be expecting to do our work using nothing but our web browser. This brings a whole new world of requirements to how we work and how we develop the software people use.
“If we’re going to keep up with technology and make progress, we need to develop software in a modern way. A cloud-native approach of DevOps, continuous deliveries, microservices and containers let us do just that.”
Knut Erik Hollund
“We haven’t crossed the finish line, but we’re moving ahead in the right direction,” he adds.
Now that we’ve established that we’re going to be cloud-native and based on microservices, it’s time to have a look at what makes these microservices communicate. And the ways that we can use, share and liberate data – thanks to API’s. That’s why the Equinor API strategy was launched in 2019, a strategy now embraced by many of our people and development teams.
Equinor’s API strategy
The goal of our API strategy is to deliver several operational and strategic benefits to Equinor:
- Increase efficiency in software development: development teams can develop new applications faster through reusing existing APIs providing data and processing capabilities
- Increase agility in software architecture: we can create a more agile software architecture, making our software systems more adaptable to change, through building our applications on top of APIs and applying microservice architecture principles
- Revitalize legacy applications: building modern APIs on top of legacy systems means we can extract more value by making their abilities broadly and easily available
- Enable innovation: we can potentially gain new insights and build new services that bring added value to the company by combining data in new ways
- New business opportunities: strengthening APIs enables us to build better relations with new or existing partners, expand business areas or provide APIs where users pay for consumption
Read more about our API strategy on Github.
Making data accessible for everyone
Without them, we won’t be able to develop microservices that let us keep up the speed – they’re truly the core element that provides interfaces between apps, data and services. With proper management, API’s can be an enabler for innovation and faster development of both digital products and new business models.
“Now, we see that teams focus on creating API’s that make data more accessible for everyone, as well as an increased understanding of why API’s matter. It’s one of the areas where we’ve really made progress, and I hope we’ll continue to."
Øyvind Rønne, leading advisor software engineering architecture and platform
An API is like a contract, specifying which operations and data types are supported. A key principle is that applications shall only communicate through APIs, and not share internal resources like databases.
“When obligations of an application are defined through APIs, the team can make changes to the internal implementation without affecting others. This makes APIs a foundation for a loosely coupled architecture, supporting team autonomy and agility,” Øyvind explains.
He tells us that among the teams that have succeeded in taking an API first approach is the team behind the Timeseries API, who have done a lot of work in creating documentation and accessibility for users outside of Equinor. They’ve been able to create a good experience for developers and users of their API alike.
“Thanks to the strategy and the increased focus on APIs, we now have teams with a lot of competence and experience with this kind of work in Equinor. They can in turn share their knowledge with other teams and make development easier, which is of great benefit to us,” Øyvind says.
Want to find out more on what putting your API first means? The team behind the Timeseries API have got some answers for you.
Want to join us?
Whether you're a student, graduate or have years of experience - we might be looking for you! Hit the button below to explore our career options.
Security as a first-class citizen
With a change to cloud-native applications also comes a change in how we view application security (AppSec). The traditional approach would be to use a flat network infrastructure with a high level of trust. If you are connected to the corporate network – we trust you. Security is handled by the big corporate firewall. But that’s an approach that just won’t fly in the world of cloud-native applications where we need new trust models, like “zero trust”.
“We have to accept that we will never be 100% secure and neither will our systems. It means we have to find the right level of insurance and bring appsec into the DevOps cycle. Security has to be a priority every step of the way, not just right before launch.”
Lars Kåre Skjørestad, leading advisor software engineering security
That’s why we’re launching an AppSec team in Equinor. Both Lars Kåre and Knut Erik will be joining the AppSec team, tasked with helping change the culture around application security. After all, software is no longer just present in typical applications – it is “eating the world”. Most tangible things in our personal and professional life are supported by software.
“In the cloud, security can’t be an afterthought – it has to be a mindset and something you continuously work on. That’s why we’re focusing on building an application security team to help our teams and build an appsec community,” Lars Kåre says.
The Internet – the new corporate network
When moving everything into a cloud-native world, the world of networks and access control also has to change. Today, access to certain tools, data or services is restricted to specific networks or hardware. The future, however, will be more about checking to see if you have authorization instead of where or what you’re accessing it from.
“Since we’re moving everything into the cloud, we need to be able to maintain the same level of security as we have on our internal networks. It’s a shift towards providing access to services on-demand.”
Elisabeth Haver, leading advisor network infrastructure
Elisabeth is the leading advisor for network infrastructure and works on the Client Network Upgrade Project – CNUP among us friends. The work is done in two tracks: one focuses on replacing the current infrastructure (switches, routers etc.), and the other focuses on how authorization and access etc. will work on the client side.
“This is all part of our current Internet first strategy, and it’ll be exciting to see how advancements in wireless technologies can improve the user experience,” Elisabeth says.
Some of the work they’re doing is finding a secure access service edge (SASE) provider. SASE bundles software-defined networking with network security functions and delivers them from a single service provider.
“We want to make it safer and easier for people to do their jobs. There’s been a big shift in the equipment we use and have available, and if we’re going to make the most out of it we need a much more streamlined setup.”
With thousands of units to upgrade and replace, they really have their work cut out for them - but the hope is to be done within the next few years.
Net zero by 2050
Climate change presents a fundamental challenge to society and business as usual is not an option. That's why our aim is to become a leading company in the energy transition and become a net-zero company by 2050.
Staying open and collaborative
Sharing isn’t just something we do internally, it’s also something we do with the world – especially in the world of software. The default setup for software development in Equinor is open source. The reasoning behind it can be found on a corporate level as well as on a developer level:
“Since the very first days of the company, our achievements have depended on our ability to collaborate with others and it will likely become even more important in the future. For software development, open source then becomes the most important tool in helping us support that goal - both as users and maintainers of open source projects.”
Thorvald Johannessen, leading advisor open source
Even when we’re the sole contributor and user, being open and transparent to the outside community results in side effects that we benefit greatly from internally. Open source also makes it easier to share and work together within the company as it helps in building culture and practices tailored for openly working together.
Collaboration within software development has many aspects to it. An open model is also a tool for establishing healthy feedback loops to support our product development. Some of the software we develop internally can be incredibly specific and targeted at a small group of experts in Equinor. But as we all know, the quality of the end-product depends on a developer’s access to users.
“Open source can allow us to test our products on other platforms and in new settings. All of this increases the value of our product and increases the value for our internal users. Building a community with users and supporting them in solving their problems, can in that way benefit us directly,” he adds.
“All in all, open source is a great tool that we have at our disposal, and we have come a long way in demonstrating its value for us. But I believe we have yet to fully utilize its potential in solving the common challenges our industry faces. To achieve that, we have to collaborate.”
Take a look at our code
Want to take a look at our open source projects? You can! Just head on over to our Github repositories.
Industry 4.0 - the future of Equinor
The world of industry has changed several times, and we’re entering one of the latest changes – Industry 4.0. It’s characterized by interoperability, when different ecosystems exchange information that’s commonly understandable – which allows communication and collaboration. Things just work in the background, so you don’t have to worry.
“Industry 4.0 is a digital transformation of industries where the boundary between physical assets, industrial production and the digital world is becoming more and more blurred and intertwined. Industrial assets become intelligent and are able to connect, communicate and collaborate on specific tasks – relying on interoperability,” Steffan Sørenes, leading advisor Plant IT architecture, explains.
“The energy transition will require fast scaling, and competitive developments and operations. Business as usual is not an option and this is where Industry 4.0 comes into play. As Albert Einstein once said: “we cannot solve our problems with the same thinking we used when we created them.”
Steffan Sørenes, leading advisor plant IT architecture
For us, the lack of interoperability can mean a supplier’s vibration sensor is unable to communicate with a contractor’s engineering software – which again is unable to talk to Equinor software.
Increasing the autonomy on our facilities, and letting robots and drones do the unsafe work, let us take our colleagues out of harm’s way entirely.
“On top of that, unmanned assets require fewer modules, making them cheaper to both build and operate. This kind of interoperability doesn’t just reduce costs, it can also help lower our CO2 footprint, bringing us closer to the goal of becoming a net-zero company by 2050,” Steffan says.
Here’s the tale of Taurob - our first autonomous robot heading offshore, and the software development that’s making it come to life.
While no one knows exactly what the future holds, what we do know is that you can stay up to date on what we do in our software community by signing up to our newsletter! Hit the link below to sign up and you’ll get an email notification each time we publish a new story.
Until next time, stay safe and take care!