DevOps and ITSM: From clash of cultures to happy coexistence

DNB is Norway's largest financial services group and one of the largest in the Nordic region, but we see ourselves very differently to most banks.

We are very much a tech company that delivers financial services — and we have the IT budget to back that up.

With an annual spend of over $490 million, we have more than 1,200 internal IT employees and 800 external contractors managing around 800 business applications and 230 active IT projects.

The vast majority of our services, including loans, savings, advisory services, insurance and pension products, are delivered online. And our tech capabilities mean we are radically different to traditional institutions — our customers can get mortgage approvals in minutes, for example.

However, we can’t afford to stand still. We must continue to meet the constant demand from customers for new and better services.

A delicate balancing act
But to meet this demand for new digital services, it’s critical that we strike the balance between driving innovation and having the right processes in place to support this. It’s about balancing time to market with the need for control and meeting regulatory obligations.

Internally that means finding a balance between our developer team — often seen as the ‘rebels’ — and our change managers, who are focused on controlling risk.

For our devs, agile is very much the watchword, driven by the ever-present need to focus on our customes’ needs and deliver new services. The mantra in agile is ‘people over tools’ and our teams have embraced that ethos whole-heartedly. We have more than 100 different Jira teams, all with different set-ups to deliver their projects.

For our change team however, compliance is key. We have to be able to demonstrate a clear audit trail on every change that might impact our customer-facing services, directly or indirectly.

In a large bank we cannot let either side “win”. Both have to coexist and achieve their goals, without impinging the other. It may seem like a paradox, but we need our dev teams to work flexibily while following auditable processes.

The importance of architecture
Since 2017 we have been moving more and more of our operational capabilities onto ServiceNow – developing workflows that refine our processes and provide that all-important audit trail.

Our ServiceNow journey started with IT Service Management (ITSM) for a best of breed approach to a crucial function. From there we have grown our use of the ServiceNow^® platform significantly, incorporating IT Operations Management, Software Asset Management, Security Operations, and Governance, Risk and Compliance among other capabilities.

What it’s taught us is that architecture is very important to creating the standards for processes. But when creating a culture that can be both ‘daring’ and ‘robust’, we also saw huge potential in DevOps.

Adopting DevOps
The light bulb moment came at Knowledge^® 2019 when we saw a presentation about ServiceNow’s ‘auditable DevOps’ module.

Although we had adopted some elements of DevOps thinking in our agile working processes, we were not a true DevOps organisation. ServiceNow’s new capability presented us with an opportunity to move our people in the right direction.

We immediately began a pilot focused on the team managing ‘change tickets’.

It’s been a massive learning curve – but the great thing about ServiceNow is that we have been able to cycle through multiple iterations of processes, testing and learning at every stage of our DevOps implementation.

We have also been able to test multiple variations on policies. The tool is so configurable that we have been able to try many different approaches to strike the right balance between having to set requirements in the policies and allowing flexibility in delivery.

What we’ve learnt in embracing DevOps is that we do need to lock in some minimum standards for processes and minimum expectations on aspects like testing before changes can be approved.

This may impede on flexibility initially, but with fewer deviations more automation in the ticketing pipeline and greater agility in development is possible – which is ultimately what everone wants.

Now we have a solution that will enable us to move the whole organisation over to working in an agile way, within ServiceNow.

Achieving happy coexistence
Perhaps the biggest lesson we have taken away from our experience is that this sort of ‘cultural change’ is not something that can be imposed or enforced. It has to be a collaboration between teams.

Indeed, having champions on the developer team who saw what the change management team was trying to achieve was incredibly valuable.

So while it’s been a bit of a whirlwind since going live with the first version in October 2019, it has also been an incredibly rewarding experience. Crucially we have a very clear road map to roll out an automated change process connected to the various DevOps pipelines in the organisation and this will play a huge part in meeting our business objectives - both commercial and regulatory.

© 2020 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc. in the United States and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are associated.