CBA intends to treat its software like “food in the fridge”, where its codebase is kept constantly fresh and anything older than three months is considered past its ‘best before’.
In this week’s iTnews Podcast, chief digital officer Fredrik Lindström and CIO for technology for the bank’s retail division and distinguished engineer Brendan Hopper discuss the bank’s transformation of its software engineering practices, team and culture.
They also talk at length about CBA’s broader digital goal to move beyond apps and online services that replicate existing processes or experiences, and into “digital-first”, highly personalised services that have no prior equivalent.
On the software engineering front, CBA laid out ambitions in June to onboard 600 software engineers, adding to the 5000 that the bank already has on staff.
The recruitment drive came about in part when Lindström joined last year and “looked at the ratio of engineers to non-engineers in my workforce”.
“It was not at all where it needed to be,” Lindström said.
“It was probably down towards the high 30 percent numbers. If you believe that to do digital you need to produce software, it’s probably not a good ratio.
“To be productive, I figured we needed to get to a much, much higher number.”
While “upsizing significantly” on the workforce front, the bank is arguably doing even more behind-the-scenes to restructure the way its teams develop and maintain its codebase.
Hopper said that CBA is in the process of structuring itself “the way a tech company does”.
That includes re-arranging people into tribes and squads and embedding engineers in “cross-functional persistent teams” aligned to business functions and/or specific products, where they can essentially sit “closer to the problem”, instead of sitting externally and having business requirements fed to them.
But more broadly and - to use Hopper’s words, “as much as possible, we're trying to align ourselves front-to-back so that engineering teams can be in control of their own products, feel a sense of pride in what they're building, and work independently.”
“We're changing how we operate so that engineers are actually spending the bulk of their time doing engineering,” Hopper said.
“We’re also investing a fair amount into the 'factory' that engineers used to produce software - like the desktop experience, the CI/CD pipelines, and how we manage and think about code - to make it efficient, productive and in some ways democratic so all the engineers can contribute to how they work.”
Again, Hopper sees the big tech companies - and particularly their magnetism when it comes to attracting talent - as a repeatable model that the bank can use.
“If you look at the tech companies, in some ways, everything from the experience, the IDEs that people write their code in, through to how they deploy, how they look at each other's code, how they manage code as a community, how they define APIs, and ultimately how you test and deploy that code, it's almost like their ‘secret sauce’,” Hopper said.
“I think in some ways, it's almost like the central nervous system of engineering.”
Hopper said the bank allowed developers to choose the tools that make up the “path to production” for code, though it had a default pipeline and set of tooling that could be used in the first instance.
The choice also extended to language selection, again with some guardrails.
“We're trying to let developers to some extent self-select what languages they code in, particularly if they're going to move towards more modern languages that are fit-for-purpose for their individual task,” Hopper said.
“But we're also working hard on maintaining that balance, so if you want to use a new language, you have to have a certain number of people to write standards and specifications around that and to do peer review across the organisation on each other's code.
“So we're very focused on finding that balance.”
The tech strategy
At a high level, CBA’s technology strategy is “quite simple to think about but quite difficult to execute,” according to Hopper.
Barring a few exceptions, the strategy treats software assets that are and aren’t considered core to the bank’s operations differently.
“For the things that aren't differentiating [us from anyone else], as much as possible we want to use software-as-a-service and move them out of the way, not spend too much time, not waste a lot of our smartest people on that,” Hopper said.
“For the spaces that differentiate, we are focusing on high quality reusable software components that are understood by our entire community, which form good APIs that eventually become software assets that any developer can use and interact with.
“For core things, we want to have one API that does something and minimise how much is strictly related to one business unit or one product.”
Hopper noted that some undifferentiated systems would still need to be maintained internally, where perhaps there is no equivalent as-a-service replacement.
“We’ll probably put them in a modern wrapper and containerise them so we don't have to worry so much about patching or testing, and we can go a little bit faster,” he said.
Innersource adoption
For the “truly differentiating stuff”, Hopper said CBA intends to structure its development and maintenance around innersource, an increasingly popular set of software engineering practices used to create an open source-like culture inside of an organisation.
Hopper said the approach is a considerable departure from past software engineering practices, both within CBA but also more broadly in banking and other sectors where innersource is finding a home.
“Software's food in the fridge,” he said.
“[If] you approached software a few years ago, your customer-facing assets had to change every month, and your backend assets maybe had a five year expiration date.
“Not any more. Everything has to be constantly kept fresh. The things that touch the customer might have to be refreshed every week. The backend may have to be refreshed every month.
“Anything older than three months, you should really consider before you take a bite [out of it].”
In practical terms, innersource adoption means having all source code in one place where “all of your engineers have access to look at it and inspect it”.
People are then given “dedicated time to groom and improve the code, and to focus on tech debt.”
“You treat tech debt as just another first order type of work alongside features,” Hopper said.
“You make sure that all of your ecosystem is being used, and end-to-end is being maintained properly, and if you don't really use something, if it's not being leveraged, get rid of it, work out how you decommission it from your codebase and from production.”
The bank is still “quite early” in its adoption of innersource, which Hopper said would apply not just to CBA-based coders “but also to our vendors and partners” that also have a role in software development.
“Then we're starting to work out how we metricate the review of other people's code,” he said.
“How do we actually start rewarding engineers for looking around and understanding the ecosystem and helping outside of their space?”
The bank is contemplating links between innersource participation and career progression.
“For example, if you write a module that's used by a lot of engineers who rate it highly and who highly vote on it being good, that helps you get a promotion,” Hopper said.
“If you review a lot of code and find a lot of issues and areas for improvement, and you coach a lot of engineers, that means you're probably at a more senior level than someone who doesn't.
“So [we’re] tying how we think about engineers and their careers with how we think about maintaining the ‘food in the fridge’ that is our software.”
Hopper said that several initiatives internally had presently been flagged as “innersource initiatives” including the creation of cloud-bative patterns as part of CBA’s ongoing cloud transformation.
“We're fully embracing innersource for that so [when] there's a project and there's funding available, if people want to work on a reusable component for cloud, we expect our entire engineering team to be able to chip in and develop that.”
Subscribe to The iTnews Podcast at Apple Podcasts, Google Podcasts, Spotify, Amazon Podcasts or wherever else good podcasts are found. New episodes will be released every Monday.
