Case study: Statens Vegvesen – The Norwegian Public Roads Administration

Case introduction

The Norwegian Public Roads Administration (NPRA) (Norwegian: Statens Vegvesen) is a Norwegian government agency responsible for national and county public roads in Norway. This includes planning, construction, and operation of the road networks, driver training and licensing, vehicle inspection, and subsidies to car ferries.

The NPRA is one of the largest government agencies in terms of budget. It manages over 55,000 kilometres of roads.

The NPRA’s internal IT department delivers services to the rest of the organisation and is responsible for the NPRA’s digital transformation.

Stats at a glance:

• Industry: Road infrastructure
• Company Size: 4650 employees
• IT department size: 310 employees
• Location: Norway
• Product: The Norwegian road network, driver training and licensing, vehicle inspection.

Background and challenges

As might be expected of any government agency that’s almost 160 years old (the NPRA was founded in 1864!), the NPRA has a lot of protocols and procedures in place. In an effort to improve efficiency and reduce bureaucracy in governmental organizations, the Norwegian government introduced the /ABE reform/ in 2015.

For the NPRA’s developers, that means increasing automation, stability, and digitization and reducing friction in their daily work. (As of August 2021, they were making good progress.)

To achieve the NPRA’s goals, Andy Aadneram Yu founded one of the first software development teams to use an agile methodology 2018.

Before this effort, the software development teams would release only a once or twice every four months. The release process was long and arduous and required the developers to fill out long forms and work late shifts to get the releases out. If a release failed, they’d have to manually roll back to the previous version. The agile teams now have tens of releases in a single day, but they’re not done yet: They want to be able to go even faster.

As part of the NPRA’s digitization efforts, they also want to consider cloud-hosted offerings for every new acquisition they make. The less they can manage themselves, the leaner they can be.

So the NPRA had a few problems that they wanted to solve:

1. Allow the agile teams to move even faster (and allow other teams to onboard easily)
2. Make the NPRA a more attractive employer for developers
3. Achieve the above goals while maintaining the strict data integrity, security, and privacy policies required to be compliant with new legislation such as Schrems II

Solution

A tried and tested way to increase deployment and developer velocity is to decouple deployment from release with feature flags. The NPRA already had a homegrown feature flag solution in place. However, this solution required the developer to change a static file and redeploy the application. While this works for simple applications, it quickly gets unmanageable and too rigid for complex use cases. There was a clear need for something more dynamic and user friendly. Using static configuration files also made the first version of feature flags unavailable to anyone expect developers.

The second challenge was to make the NPRA a more attractive employer. When an organization is over 150 years old, it takes some real work for it to appear modern and agile. One of the things that scare potential hires off the most is bureaucracy: Not only does a long and complicated release cycle impact the product and the amount of work around a release; it also has a clear impact on employee happiness. People thrive when they have a direct and visible impact on their workplace and on the products they’re working on. With only a single chance to affect the product every few months, it’s easy to feel like nothing you do matters and to get burnt out. They needed something that would give the employees more agency and more chances to impact the product.

Addressing the final challenge — that of maintaining data security and privacy — required either keeping everything on-premise or using a service that they could trust. When the Court of Justice of the European Union passed the Schrems II legislation in 2020, the NPRA implemented a deliberate and strict stance on PII, effectively banning the use of any services that sent any user data to external systems. This stance evolved into a more risk-based assessment done on a case-by-case basis. While this evolution opened the door to more external vendors, it also meant that these vendors and their systems would have to be able to withstand heavy scrutiny by the NPRA’s legal counselors.

Unleash addresses all of the above problems.

As with any feature management tool, Unleash lets you decouple deploys and feature releases, increasing velocity. This also lets the developers focus on development of new features instead of focusing on documents and deployments. With more time to work on the core parts of their profession and on things they can see, developers grow to feel more ownership of the product and become more invested in it.

The NPRA values a bottom-up approach, where they acknowledge that it is the developers themselves that have the most insight into what makes their days better. Developers are builders, and builders want to use tools that fit their needs. One example is Unleash’s custom activation strategies. When the NPRA needed to enable or disable a feature based on their application’s context, they developed their own custom activation strategy to do just that.

It gets even more interesting around data security. As a self-hosted solution, Unleash could have run on their internal systems without ever sending any data around: if no data ever leaves their systems, then there is nothing to address. However, to avoid the extra complexity of managing the system themselves and to align with the goal of using cloud-based solutions, the NPRA wanted to use a managed version of Unleash.

Where other feature management solutions collect comprehensive data about their customers and their customers’ customers, Unleash intentionally avoids this. Unleash stores only the minimal amount of data that it needs for the system to run. In fact, Unleash never sends any Personally Identifiable Information (PII) outside of the customer application. All evaluation happens directly on the clients, and all your user data is as safe as you can make it.

This makes the risk associated with running Unleash as an external service low enough for even security-minded government agencies.

Results

The NPRA has found a way to increase velocity — deployment rate is up by more than 600x from their starting point of once every 4 months — reduce friction, and improve developer happiness. As a result of the transformation that the NPRA has gone through over the past few years, it has become a very attractive employer, both for regular employees and for external consultants. They have found onboarding new users to Unleash to be simple and straightforward; and when they get stuck, they know they can fall back on the documentation to find what they need.

Even with its strict security requirements, the NPRA knows it can use Unleash to manage releases of new features. As part of the acquisition process, the NPRA and Unleash discussed the technical and legal implications of using the hosted solution and how Unleash assures that sensitive data doesn’t get exposed. The risk/impact analysis they performed, marked using a hosted version of Unleash as low risk.

The NPRA uses feature flags to manage the rollout of new features, and Unleash is becoming an integrated part of their environment. As of today, they mostly use the basic on/off functionality that Unleash offers, and are already seeing great value added. Over time, they aspire to move into more advanced use cases, such as gradually rolling out features to their users. Whatever they need, they know that Unleash will be able to support it.

Want to try Unleash?

GET STARTED

TRY OUR DEMO