CBA has built a multi-agent workflow that covers every step required to prepare an application for migration to the cloud, enabling the bank to move \u201c20-to-30\u201d applications a quarter.<\/p>\n
<\/p>\n
\n CBA’s Ash Moollan.
\n <\/p>\n
The workflow is branded \u2018Lumos\u2019 and is essentially an \u201cAI-first\u201d reimagining of the application modernisation and migration process.<\/p>\n
\u201cTwelve (12)-to-18 months ago, I stood in front of my team and I said, \u2018We’re going to migrate X number of applications to the cloud’ \u2026 and everyone in my team, including myself, felt like that task was daunting,\u201d general manager of cloud acceleration within the office of the CTO Ash Moollan told an AWS financial services symposium in Sydney.<\/p>\n
\u201cSo, we thought about how we [could] apply an engineering-led approach and mindset to how we migrate applications to the cloud. What would it look like to migrate this AI-first, agent-first, the smart way?<\/p>\n
\u201cEssentially, for every step of that [migration] journey, we’ve put AI first and agentic first in how we pull that together.\u201d<\/p>\n
The work, conducted in collaboration with AWS\u2019 professional services arm ProServe, came about as a way to both make the standard AWS migration framework \u201cCBA-relevant\u201d and to increase the volume of application migrations that were possible in a specific timeframe.<\/p>\n
\u201cLast year, my team migrated about 10-ish applications in one year. Our ambition was –\u00a0 let\u2019s just say – to do more,\u201d Moollan said.<\/p>\n
\u201cWhere we ended up at the end of this quarter, we’re now migrating in the ballpark of 20 to 30 applications per quarter.\u201d<\/p>\n
Moollan said that in the past year, his team had scoped \u201c370 legacy applications\u201d as potential modernisation and migration candidates.<\/p>\n
\u201cWe’ve done a bunch of application assessments and let me tell you, it was not easy,\u201d he said, likening the process to \u201cdocumentation archaeology\u201d to understand the application well enough to proceed with its modernisation and migration to cloud.<\/p>\n
Aside from fragmented documentation, a slide displayed other challenges slowing CBA\u2019s application modernisation and cloud migration efforts, including cloud readiness assessments taking six or more weeks per application and the time and effort needed to remediate technical debt.<\/p>\n
Lumos – built into the bank\u2019s cloud migration portal – is designed to help with this and more – using AI agents to handle particular steps, with a human in the loop to provide oversight and request additional changes where needed.<\/p>\n
AI agents are used across the assessment to migration workflow: for requirements gathering, network and code analysis, solution architecture and cyber document generation, code transformation, UI testing and continuous feedback steps.<\/p>\n
To start, an agent summarises and analyses a conversation with an application owner, drawing out key points and converting them into requirements.<\/p>\n
Moollan said this ensured there was no miscommunication or mistakes made in scoping a migration candidate.<\/p>\n
Another agent is used to analyse and understand the codebase of the application, to describe \u201cwhat this application actually does, the various functions, capabilities and how [these are]\u201d, and to understand \u201cany network connectivity that it discovered as part of that code analysis\u201d, such as API calls, database and storage connections and so on.<\/p>\n
This allows the cloud readiness of the application to be determined, highlighting any potential issues in the code that require remediation or dependencies that require upgrading.\u00a0<\/p>\n
Moollan said that an AI-generated component diagram and sequence diagram is also produced to show how the application functions.<\/p>\n
Once the application is understood and determined to be a modernisation and cloud migration candidate, \u201ca number of agents\u201d work together to create design and cyber documentation.<\/p>\n
A writer agent prepares the documents, ensuring they are CBA-relevant by running checks against the bank\u2019s technical knowledge base, and a validator agent \u201creviews the content written by the first agent, and it’ll orchestrate between a workflow agent to do at least three iterations to refine and upgrade the quality of what is being produced,\u201d Moollan said.<\/p>\n
Moollan noted there is also a human in the loop to challenge what has been written and have it refined further.<\/p>\n
The result is then fed to another agent \u201ctrained on cyber knowledge\u201d to prepare \u201ca security zone diagram on which resources should be deployed in what security zone within the organisation\u201d, and to generate required documentation.<\/p>\n
In addition to using agents to build an understanding of what an application does and how to migrate it to the cloud, agents are also involved in making changes to the application to prepare it.<\/p>\n
Agents \u201cprepare the code base\u201d for work that is then carried out by other agents.\u00a0<\/p>\n
\u201cThere’s an agent that uses the open source OpenRewrite [auto-refactoring engine] that does a code transformation and a framework upgrade, and there’s the AWS Q Developer CLI [which] reviews the code that OpenRewrite produces and makes changes if there are issues with it, so these two work hand in hand in order to upgrade that application,\u201d Moollan said.<\/p>\n
Moollan said a number of iterations were typically required, and changes were only accepted and merged into the codebase with human oversight.<\/p>\n
Once Lumos has done its work, the DevOps Hosting Platform or DHP is used to deploy the application to the cloud and for \u2018day two\u2019 operations.\u00a0<\/p>\n