NAB has surfaced the first details of a – so far – nine-month effort it is calling NAB Engineering Foundation (NEF), comprising standardised practices and “repeatable quickstarts” to help developers get code into production faster.

The NEF has, until now, remained largely out of public view, despite being a significant effort now understood to be used by in excess of 100 squads of engineers across the bank.

Distinguished engineer Andrew Brydon told a HashiCorp financial services executive summit earlier this month that the NEF was born in early 2020 to solve “complexities” in the way developers wrote code, particularly for the cloud.

The NEF came about in part because minor variations in the way that different development teams approached problems and coded components led to bigger “complexities” at the bank.

“Teams were individually building the same components for the cloud and applications on the cloud in slightly different ways,” Brydon said.

“Teams borrow from each other, of course, all the time, but they take things, they fork them and they update them, and we’ve found that this lack of standardisation actually inhibits some of the speed to delivery sometimes. 

“It also has some other knock-on impacts. Moving engineers between teams can become harder because there’s a retraining element that’s involved in doing that.”

Inside the NEF

The NEF is presented to developers and squads as “a product … to download and deploy”. 

Technically, it comprises “multiple different components … that we pre-integrate to provide a development template for all development teams to use,” Brydon said.

Within the NEF, HashiCorp’s Terraform Enterprise (TFE) is used “to support the standardised heavy-lifting of deployment of infrastructure”, while Jenkins Templating Engine (JTE) powers a reusable, “standard CI/CD pipeline”.

“Bearing in mind that we are a heavily regulated organisation, TFE allows us to build in an element of our compliance requirements via Sentinel [HashiCorp’s policy-as-code framework],” Brydon said.

“Terraform modules are actually also open source within our organisation. So, we have a GitHub organisation, which contains all the reusable Terraform modules for the teams to be able to deploy within their workspaces.”

The bank’s developers also attend a “standard set of bootcamps”, covering topics such as “developing infrastructure-as-code with Terraform, developing on Java and Javascript, and containers on a templated container services platform”.

“We’ve run a series of bootcamps internally to train up our engineers to work in this standard approach,” Brydon said. 

“You have to train people on how to do things to ensure that they know what to do, and we’ve seen that as one of our key pillars to enable this in our organisation. 

“Any new engineer that joins the bank goes through this training. [Once they are] registered in GitHub, we send them an email to help them lift into our bootcamps.”

Brydon said standardisation should allow developers to introduce more customer-focused innovations and features much faster.

“We’ve been very systematic around how we’ve worked internally with teams and understood their requirements, and standardising in this way is a real productivity benefit,” he said.
“It means that we’re focusing on [the] velocity of software development, and if you’re familiar with some of the quotes around Spotify, if you focus on velocity then quality is a fast follower. 

“So that’s one of the things in the back of our minds as we have been doing this.”

The bank is building a library of what it calls “repeatable quickstarts” that are designed to help developers put resilient new features into production much faster. 

iTnews understands more of these repeatable quickstarts will be built through FY21.

Innersource adoption

Another part of the NEF is NAB’s adoption of innersource, a set of software engineering practices used to create an open source-like culture inside of an organisation.

Brydon said that innersource ensured that the central capability that is the NEF didn’t become a bottleneck to innovation over time.

“We use an open source or innersource approach within the organisation, and that means that any team can provide updates and contribute updates into this capability,” he said. 

In a LinkedIn post, NAB said internal branding for the innersource programme was only launched to the bank’s developers last month.

“Earlier this year we launched our NAB innersource programme to break down the silos in the enterprise and enable our developers to work on code in the open,” the post said.

“We are seeing real tangible benefits from this with reduced delivery costs through reuse of components, faster time to customer value, mentoring, innovation and higher engagement.”

The innersource model means NAB developers no longer engage in ad hoc sharing of code.

Instead, they can access code created by other teams but also innovate on top of it, which other teams can then immediately take advantage of.

“We see the innersource model is a key thing to being able to scale anything in terms of modern software development in an organisation like ours,” Brydon said.

“I’ll give you an example of increasingly how effective this can be. 

“We needed to move to a new version of [Terraform] modules for Azure. In NAB, you can only deploy Azure environments via TFE. That’s something we’ve done as a standard. 

“We needed to update 40 modules at once, and via this innersourcing ‘crowdsourced’ model that we have, we could do that within a few days.”

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here