How the internal technology platform creates value at NAV
Using internal platforms at scale in the public sector, managed as products and inspired by Team Topologies
By Bente Lønnquist Busch, Director of Teams Service Platform at NAV
“The mission of our platforms is to enable fast flow by reducing cognitive load for our users.
“We had already seen the effects of making a compelling platform vs the more traditional mindset of IT operations delivering an obligatory platform. Team Topologies has strengthened our belief in thinking of our internal technology platforms as products.”
“We have adopted the concept of team interaction modes, where X-as-a-Service is the goal. Collaboration is necessary to get fast feedback in early stages of development. However, we enter collaboration with awareness of who will be responsible for what after collaboration ends, and particularly keeping business logic out of the platform.”
Bente Lønnquist Busch, NAV
What is NAV and what does our digital operation look like?
NAV (Norwegian Labour and Welfare Administration) is the largest public agency in Norway. Our mission is to assist people into work, and we provide a series of benefits related to pensions, disease, unemployment, and others. We normally provide services to around 2,5 million citizens every year. In 2020, this number reached over 3 million, as the first year of the COVID-19 pandemic.
The mission of NAV is to assist people into work
Our digital operation consists of over 100 teams which are responsible for something technology related, big or small. This number is steadily increasing as we are in the middle of a major digital transformation and investing heavily in refactoring our older monolithic systems into smaller digital products. At the time of writing, 75% of our digital teams are cross-functional product teams. We seek to group teams together in product areas which have high cohesion, and aim for little coordination and low coupling between product areas. We give teams and product areas the autonomy to figure out how to best meet the needs of their defined user group and particular life situation.
FIGURE 1: AN ILLUSTRATION OF PRODUCT AREAS IN NAV. SEVERAL TEAMS ARE COUPLED TOGETHER IN DOMAINS. THE TEAMS ARE STAFFED WITH CROSS-FUNTIONAL COMPETENCE, HOWEVER THE COMPOSITION OF EACH TEAM DIFFERS SOMEWHAT.
What is our take on having an internal technology platform?
Over the past 3ish years, we have developed platform products which support our digital product teams. They were not bought as a suite or built by a large three-year project. They had their origin from some software developer, data scientist or designer who felt that there was something missing in order for them to perform their craft efficiently, and started to make features that fixed that problem. Over time, these features were adopted by others, and in turn dedicated people set about maintaining them. They became the platform teams. The next evolutionary step was to think of this set of features as one or more platform products, and develop them with the same mindset as any other digital product. A guiding principle has been to make the platform attractive to use through reducing the cognitive load for the product teams, as recommended by the book Team Topologies.
FIGURE 2: AN ILLUSTRATION OF HOW THE INTERNAL TECHNOLOGY PLATFORM SUPPORTS THE PRODUCT AREAS IN NAV.
We have a small number of coherent internal platforms, not a cumbersome single platform
We currently have three groups of platform products:
The application platform, NAIS (NAVs Application Infrastructure Service) delivers everything our digital teams need to develop and run an application. It provides an effective deployment pipeline (CI/CD), a Kubernetes container environment, logging and monitoring, and security stuff like authentication and secrets handling. The main user group is software developers.
The data platform offers data handling and analytical capabilities for storage, processing and visualization, as well as supporting services like data catalogues for data discovery and governance. The main user groups are developers who want to share data and analysts who want to use data.
The design system is a library of design components, guidelines and good practices. The main user groups are designers and front end developers.
FIGURE 3: AN ILLUSTRATION OF HOW THE INTERNAL TECHNOLOGY PLATFORM IS STAFFED WITH SEVERAL PLATFORM TEAMS. THE TEAMS ARE COMPOSED OF PEOPLE WITH SOMEWHAT MORE HOMOGENEOUS COMPETENCES THAN THE PRODUCT TEAMS, SPECIALISED IN THE PLATFORM DOMAIN THAT THEY ARE SERVING.
Services supporting the actual platform products are documentation, support, procurement and vendor relations, and technical security and risk evaluations. The platform products are in continuous evolution. For example, in addition to these three, we see the potential of providing platform products more specifically towards front end development, and are exploring this during the fall.
Making internal platforms work well: competent people, product mindset, and strong opinions
The platform teams are staffed with some of our most competent people (in my humble opinion). The intention behind that prioritisation is that the effect of their work is multiplied with the number of teams using the platform. Instead of mediocre or even bad x 100, the effect we want is outstanding x 100.
We have a product mindset. It can be tempting to make a platform with state-of-the art technology and spend a lot of time testing and experimenting with what Netflix and Spotify use. However, a product mindset means to focus on three things and develop solutions where they overlap: 1) the users' needs 2) what is a possible technical solution 3) what is viable for the team and our business. Most of the experimentation happens in the product teams, and the platform teams make it available only after it has proven it's worth.
Our platform teams are opinionated. Yes, we are focusing on user needs. Still, we are responsible for making an attractive platform or a "golden path". In practice, we sometimes diverge from what the users express as their needs. For example, we can explore a new technology or technique without it being an expressed request from a user. And vice versa, we can deny a request that comes from several teams.
What benefits are we seeing from product-focused internal platforms?
There are several major benefits to providing a technology platform in an organisation like NAV. Not only because of the scale of our digital operation, but also in order to comply with regulatory demands.
Supporting speed, adaptability and learning: As many other organisations, we are striving for high speed in our digital operation. The ability to learn and adapt faster is necessary in this ever faster changing environment. One proxy to measure this is the number of deployments made to production, since our ability to push code to production indicates how long it will take to fix a mistake, and will in turn increase our willingness to test and experiment. This graph shows how NAV has evolved from 6 big releases every year in 2012, to 1,250 deployments per week so far in 2021:
Cognitive load: The platform products allow our product teams to use their mental capacity on the end-user, and not spend time on under-the-hood stuff like infrastructure or choosing an accessible colour palette.
Autonomy vs alignment: From a corporate perspective, one effect of high autonomy is losing alignment. At NAV, we see that building in certain compliance and security measures in the platform to provide the product teams with guardrails. For example, all use of third-party solutions like open source libraries, cloud platforms and SaaS products, are compliant in terms of procurement regulations. All icons and design elements are compliant in terms of universal accessible design. Our platform services available in public cloud are set up restricted to EU data centers in order to stay compliant to GDPR and conform to the Zero Trust Security model.
Competence and knowledge sharing: When the internal technology platform is perceived as a compelling product, it is widely adopted and used. In turn, everyone has competence on how to use the platforms. There are several benefits: For one, it lowers the "cost" (e.g. time to get up and running) of people switching product teams, since the tool stack and methodology is more or less the same. Secondly, it further supports and enforces the strategy of loose coupling, autonomy and distributed responsibility, as it facilitates a forum for knowledge sharing. If a software developer in one team posts a question on Slack on how to perform a specific operation on NAIS, a software developer from another team is just as likely to answer as the NAIS team members themselves.
What inspiration have we had from Team Topologies?
Large parts of the mindset were already in place [before the book was published] but Team Topologies gave us a vocabulary and common mental models, which made it easier to communicate.
The mission of our platforms is to enable fast flow by reducing cognitive load for our users. We had already seen the effects of making a compelling platform vs the more traditional mindset of IT operations delivering an obligatory platform. Team Topologies has strengthened our belief in thinking of our internal technology platforms as products.
We have stayed true to keeping the responsibilities of the platform teams to platform only, and not content or domain specific business logic. This has been necessary to maintain end-to-end ownership in the product teams, and to allow the platforms to scale without bloating the platform teams in terms of head count. We have adopted the concept of team interaction modes, where X-as-a-Service is the goal. Collaboration is necessary to get fast feedback in early stages of development. However, we enter collaboration with awareness of who will be responsible for what after collaboration ends, and particularly keeping business logic out of the platform. Collaboration or facilitating can be necessary for support or to secure adoption of a product.
Using Team Topologies illustrations, a simplified view of our digital product organization would look like this from the platform perspective:
FIGURE 4: AN ILLUSTRATION OF HOW THE INTERNAL TECHNOLOGY PLATFORM TEAMS SUPPORT THE PRODUCT AREAS AND PRODUCT TEAMS. THE INTERACTION MODES VARIES DEPENDING ON THE MATURITY OF THE PLATFORM SERVICE, WHERE “AS-A-SERVICE” IS THE DESIRED PATTERN ON A HIGH MATURITY SERVICE, AND “COLLABORATION” IS COMMONLY USED WHEN DEVELOPING A NEW SERVICE.
Next steps: applying a conscious mindset to teams across the whole organization
With over 100 digital teams in NAV and this number steadily increasing, we see potential benefits of applying a more conscious mindset to our teams across the whole organization. What is our purpose? Who are our users? Which services and teams do we have dependencies to, and how are our interaction patterns with them? We believe that this may help us continually shape the architecture of our organization in a manner that is optimal for teams’ fast flow, and ultimately helps us deliver the world’s best welfare services to our users.
More details:
NAV: https://nav.no/
Bente Lønnquist Busch: https://www.linkedin.com/in/bentebusch/
To learn more about key ideas from Team Topologies like the four types of teams, the platform as a product approach, or how to align teams with true value streams, have a look at our Team Topologies Academy courses and learning paths.